コンピューターのシステムを開発する順序として、まずクライアントのリクエストに基づく要件定義があり、それにもとづいて設計が行われます。
実際にコードを書く開発段階を経てテストが行われ、それからやっと運用に至るのです。
その中でも要件定義は、これから作り上げていくプログラムにとって最も重要な土台となる部分となります。
この記事では、要件定義の基本的な意味合いや役割、そして具体的なフローも含め、要求定義との違いも踏まえながら分かりやすく解説していきましょう。
目次
要件定義とは？
ひと言で表現するなら、要件定義とはシステムを構築するために欠かせない項目についての仕様書です。
これから作るシステムに関連して、備えるべき機能などを細かく挙げたものといってよいでしょう。
クライアントの要求をどのようにシステムに反映させていくかを定義する、いうなれば開発の土台です。
上流工程と下流工程
代表的な開発手法であるウォーターフォールモデルにおいて、工程の全体が「滝」に例えられています。
滝の水が落下する手前の上流にあたる工程と、滝壺に落ちていく下流にあたるものです。
システム全体の仕様をクライアントが求めるものとして設計するための要件定義と、それを業務システムに反映させるための工程である設計が上流工程になります。
上流工程の段階で、システムに関するあらゆることが決定しているのです。
一方、下流工程とは設計書通りにシステムを構築する開発工程、およびそれぞれの機能を確認する単体テストから全体を通した総合テストや保守運用までを指します。
エンジニアが上流工程をこなすためには、下流工程で実際に手を動かして物作りに励んだ経験が非常に活かされるものです。
実際に手を動かしてさまざまな手法やパターンを経験することにより、要件定義において運用が開始された後のイメージが明確になるといえるでしょう。
Thank you for reading this post
要件定義のフロー
要件定義が実際に開発の現場で実行される場合の、具体的なフローを時系列に沿って解説しましょう。
その中で、定義される対象の4種類の要件についても触れておきます。
ヒアリング
多くの場合に、開発企業の営業担当者がクライアント企業の求めるものをヒアリングするところから、案件が始まります。
そのため、システムエンジニアが営業を兼任する企業も少なくありません。
この段階でリクエストのひとつ一つを、システムに持たせるべき機能などに置き換える作業が始まります。
クライアントが望むことの多くは、それまでは手作業であった業務のシステム化です。
また、既存システムの仕様変更や機能追加などもあります。
要求の細分化
クライアントのリクエストの全体像が見えてきたら、実装す べき機能のひとつ一つを、細分化します。クライアントの業務フローを綿密に理解し、すべてが無理なく適切に動くように機能を確定していかなくてはなりません。
この段階で個々の業務フローとリクエスト項目に関して、ひとつとして抜け漏れがないように、注意深く行っていく必要があるのです。
このフェーズにおいて定義されるのが要件であり、さらにどの段階かによって大きく4種類に分かれます。
業務要件
もっとも最初の段階で固められていくのが業務要件です。
実際の業務を分析し、問題を洗い出した上で、どのような解決法を実現すべきかを決めます。
この段階ではシステムはひとまず置いておき、業務そのものにフォーカスするのです。クライアント側の、できるかぎり業務に詳しい人材に参加してもらい、緊密なコミュニケーションを図りながら進める作業となります。
万が一、クライアントと開発企業側の目的が噛み合わないまま開発が開始されると、後から重大な修正や変更を余儀なくされる場合もあり、両者とも時間と労力の浪費につながるのです。そういう事態を招かないために、このフェーズは極めて重要だといえます。
システム要件
現状の業務分析によって、改善するための項目を業務要件として浮き彫りにした後は、それをどのようシステムに反映させていくのかを決めます。
ここで決められていく反映させるための構築の流れが、システム要件です。
一見すると何やら業務要件と同じように感じるかもしれませんが、実際はかなり異なるものとなります。
なぜなら、「業務上の要望」と「システムを通して実現できること」は必ずしも同じではないからです。
例を挙げておきます。
業務要件が「問い合わせがあった企業の所在地が、すぐにわかるようにしたい」だとしましょう。
これを受けて設定されるシステム要件は、直接「回答」を導くものではなく、「速やかにブラウザを経由してその企業の所在地が検索できること」などの「方法」になります。
また、中にはどうしてもシステムに反映させることに無理があるために、対象から外される項目が存在する場合もよくあるようです。
機能要件
システム化の方向性がひとつ前のフェーズで決まってくると、次はシステムにとって具体的に必要な機能について検討する段階です。
開発を通して必ず実現しなければならないものこそ、機能要件となります。
機能要件はヒアリングを丁寧に行うことによって、正確に確認することが可能です。
機能要件の成果物は、次に述べる非機能要件と併せて、設計段階での重要事項となります。
非機能要件
機能要件が定義されても、それだけでは求められるシステムとしては不完全といえます。
個別の機能以外の動作の前提条件やシステムの特性、性能などを定義するのが非機能要件です。
信頼性や運用性、拡張やセキュリティなどに関する要件が含まれます。
例えば、可用性に関して要件として何も定めなければ、求められた機能は動作しても、部分的な故障が起きるとシステム全体が停止するような脆弱性を招くことになるのです。
これらを実現することで、クライアントの満足度を上げることができます。
しかし、非機能要件は必ずしも明確に要望されるものではありません。
スケジュールやコストを意識しながら、クライアントとの合意形成を図ることが大切となります。
要件定義書の作成
クライアントに要求された機能が整理されれば、それをドキュメントとして作成する段階となります。
ここで書き出された要件定義書の内容が、次なる工程である設計に落とし込まれることになるのです。
ただし、すべての要求内容をシステム化できない場合もあるので、この段階で区別しておく必要があります。
機能の範囲が明確になっていなければ、先に続く工程の途中で何か不具合が見つかると、大きく後戻りさせてしまうリスクが生じるのです。
最悪の場合はプロジェクト自体が失敗に終わりかねないので、詳細部分までクライアントとのすり合わせが必要となります。
よって、この段階で全体像がはっきりと確定し、機能においては細分化された状態まで的確に記載されていなければ、設計工程で頓挫しかねません。
このような背景から、要件定義書は開発における重要な基盤となります。運用や保守にまで影響を及ぼすので、矛盾が生じることは許されません。
要求定義との違いを理解しよう
エンジニアの中でもまだ経験が浅い人たちにとって、何が違うのかがわからないという声を時折耳にする要件定義と要求定義について、その違いをできるかぎりわかりやすく述べておきましょう。
要求定義とは、クライアントからの業務改善のための希望であり、「〇〇の場合には〇〇したい」というように、リクエスト項目を挙げたものです。
つまり、業務を改善するために必要な要素を記述したこのアナログなリクエストに対して、ITを用いてデジタル化し、システムに反映させる原点が要件定義となります。
それぞれは「要求定義書」および「要件定義書」という形式で、ドキュメントとして残されるのが一般的です。
要件定義に必要なスキルとは？
プログラミングに関するスキルはもちろん必要ですが、それだけでは不充分です。
それ以外には、「コミュニケーションスキル」「分析スキル」「ドキュメント作成スキル」などが挙げられます。
それぞれを詳しく見ていきましょう。
コミュニケーションスキル
クライアントと自分自身の認識が異ならないように、細部までを注意深くヒアリングし、意思の疎通を図るためのコミュニケーションスキルが求められます。
クライアントやその案件を獲得した営業担当者が、要求するものをことごとく細かいところまで表現できるわけではありません。
よって、要件定義を実行する場合には、クライアントへのヒアリングを経て作業を進める必要があります。どうしても落とし込めない部分も明確にして、先方に伝えなければなりません。
的確に「聴いて」誤解のないよう「伝える」ためのコミュニケーションスキルは、要件定義において欠かせない重要スキルといえるでしょう。
分析スキル
クライアントへのヒアリングで浮き彫りにすべきは、問題と課題です。
問題とは、実際の業務で起こっている不具合で、課題とはこうあるべきだが現状はそうなっていない事実であり、この二つは裏腹の関係にあります。
つまり、「このような問題があるので課題に対応できない」ということです。問題と課題の因果関係の的確な分析によってこそ、要求された内容に相応しい要件として反映させることが可能になります。
だからこそ、分析スキルは要件定義に欠かせないスキルなのです。
ドキュメント作成スキル
クライアントの要求をシステムに反映させるために設定された要件に関して、数値や文章で正確に表現するドキュメント作成スキルが必要です。
分かりやすい表現がドキュメントには必要であり、システムが稼働した後に、改良が必要な場面に開発に関わっていなかった者が読んでも理解できる内容にする必要があります。
そのため、ドキュメント作成時には、表現方法やフォーマットの統一も徹底されていなければならないのです。
また、この工程を終えてからの段階で不具合が発覚して修正や変更が入るのは、納期やコストの面からも何としても避けなければなりません。
このように、要件定義書を書く担当者のドキュメント作成スキルが問われます。
まとめ
開発の初期段階に実行する、クライアントからのアナログな要求をデジタル化してシステムに反映させるための、非常に重要な工程が要件定義です。
綿密な分析によって洗い出された4種類の要件はドキュメント化され、設計する際の基礎部分になるだけでなく、その後の保守運用や改良の機会に立ち返るべきシステムの原点になります。
