要求定義とは？要件定義との違いや進め方を解説
- 2022年10月12日
- 読了時間: 10分
更新日：2月5日
要求定義はシステム開発の用語で登場しますが、要件定義と混同したり、中身を決めるときの方法や内容が違ったりして、さまざまな失敗やトラブルを引き起こします。
システム開発をベンダーに依頼する場合には、システム開発を依頼する担当者も要求定義や要件定義の違いを理解した上で、要求定義や要件定義を進めていく必要があります。
本記事では、要求定義と要件定義の違いをわかりやすく解説した上で、要求定義の重要性や陥りやすい失敗事例、進め方のポイントについて解説していきます。
＜目次＞
要求定義・要件定義の違いは？
システム開発会社ごとやシステム開発に関わる企業担当者によって「要求定義」と「要件定義」の言葉の指す範囲や意味が異なる場合があります。
しかし、両者の定義を不明瞭に開発を進めることは、後述するようにさまざまな問題を引き起こします。
本章では、要求定義と要件定義の違いについて、わかりやすく解説していきます。
要求定義とは
要求定義とは、要件定義の前に定めるもので、システム開発の目的やニーズを定義することを指します。
要求定義を行うのは、実際にシステムを利用するユーザーです。現場業務を整理した上で、事前に「システムで何を実現したいのか？」を社内で決めて、要求定義を作成する必要があります。
あくまでも「要望・希望」を書いたもののため、記載項目のすべてが機能やシステムとして実現するわけではありません。しかし、ベンダーに対して最初の要望を提出し、それをもとに要件定義を作成して開発を進めるためにも設計の基礎や大枠となる部分であり、要求をしっかりと整理し形にすることが求められます。
要件定義とは
要件定義とは、システム構築の仕様を定義することです。このフェーズでは主に、システム開発を担当するSIerやベンダーなど開発チームがメインで行う作業領域です。
要求定義はシステム開発の目的を明確にする工程ですが、「要件定義」は、システム開発の目的を実現するために必要な機能や非機能要件、業務要件、運用要件、外部連携システムなどに加え、予算や開発スケジュール等をまとめる工程でもあります。
要するに、要求定義に書かれている目的やニーズから内容を精査して、それらを実現できる具体的な手段・機能を決める作業です。要件が定まったら、要件定義書と呼ばれるドキュメントを作成し記録を残す必要があります。要件定義以降の工程では要件定義書に記載のある内容を元に、システム開発を過不足なく実施していくためです。
開発工程での要求定義の位置付け
システム開発工程を表したものが、上記の「V字モデル」と呼ばれる図です。V字モデルは、開発工程とテスト工程で各作業をリンクさせることで、作業の局所化を可能にしたり、不具合発生時の原因が特定しやすくすることを目的にしています。
例えば、要件定義の内容を総合テストで確認したり、基本設計で定めたことを結合テストで確認するといったことです。
V字モデルを活用することで実施するテスト内容が明確になり、品質向上にも繋がるメリットがあります。
そして、システム開発の工程は上流工程と下流工程の2工程に分かれています。
場合によっては、詳細設計～単体テストまでを中流工程と呼ぶこともあります。
今回、解説をしている要求定義や要件定義は上流工程に位置する開発工程です。
図からも分かるように、要求定義は上流工程の中でも最初に行われる工程であり、要件定義は要求定義で定められたアウトプットである要求定義書をもとに進めていきます。
要求定義で陥りがちな失敗例
システム開発における要求定義は、システム開発自体を成功に導くために重要な役割を担います。本章では、要求定義で起こりうる代表的な失敗事例を紹介したうえで、要求定義の重要性について解説していきます。
失敗1.曖昧な要求定義による認識齟齬
上流工程でよくある失敗としては、要求定義で曖昧な定義付けをすることです。
要求定義のフェーズでは曖昧さをなくすことや用語定義が重要です。
システム発注者が中心となり定めることが多い要求定義は、業界内のルールや当たり前、業界用語をついつい多用してしまうケースがあり、システム開発担当者にはうまく伝わっていない可能性があります。
要求定義の段階で認識の齟齬が発生することで、その後の要件定義、詳細設計にも大きな影響を与えてしまい「納期を過ぎてもシステムが完成しない」「システムの挙動が想定していたものと違う」「開発したものが現場で使われない」といったトラブルを引き起こしてしまう可能性もあるため、注意が必要です。
また、先述した開発工程からも分かるように、要求定義が曖昧な場合、そのあとの要件定義フェーズでも上手く具体化できません。要求定義で検討した内容や決定した事項は、必ず文書に起こし要求定義書と呼ばれるものを作成し、共通認識を得られるように図ります。
システム開発は、あくまで目的を達成するための手段です。手段が目的化しないためにも、明確に要件定義と分けた要求定義を作成する重要度が高まるのです。
失敗2.イメージと異なる成果物が作り出される
もう1つの失敗事例として、要求と異なる成果物が作り出されることで、ユーザー（システム発注者）に使われないシステムが作られてしまうことです。
あるいは、システムをリリースした後に修正が必要な不具合が見つかることです。一度リリースしたシステムに大きな不具合が生じることは、莫大なコストと手間がかかるだけではなく、自社のブランド価値を下げてしまったり、顧客からの信頼を失うことにも繋がります。
このような失敗を避けるためにも、要求定義を定める際には優先順位を定義付けることも重要です。システム開発で実現したい内容は多岐に渡ることもありますが、予算や納期は有限であることほとんどです。優先順位を明確にしておくことで中途半端なシステム開発を防ぎ、肝心な機能が不足するなどの事態を防ぐをことができます。
失敗3.ベンダーへ丸投げ
失敗事例の中には、システム発注者による知識が不十分であることや、システム開発の専門的な知識を有しないことで、ベンダーにプロジェクトを丸投げしてしまうことで失敗するケースがあります。
例えば、「システム開発のことはわからない」「全てベンダーに任せたほうが早い・安心」という理由で安易にシステム開発を丸投げすることにより、「まったく期待したシステムではなかった」「こちらの要求したはずのシステムと違った」などの失敗を招く可能性があります。
あくまでもベンダーの役割は、システムを開発することです。システムで実現したいことは発注者が先に整理しておく必要があります。とはいえ、要求定義の内容を練り上げるためにも、ベンダーとの壁打ちは必要です。
ITに関連する知識が少なく不安がある場合は、プロの目線で、必要な情報を整理してくれるようなベンダーを探すことも重要だと言えます。システム開発を依頼する際は、ベンダーの得意分野や開発実績などを確認すること同時に、発注者側の想いを汲み取り並走してくれるベンダーを選定すると安心でしょう。
要求定義の進め方やポイント
システム開発の失敗の大部分は、要求定義などの上流工程にあるといわれており、事例を通して失敗の要因を理解することは大切です。ここでは、具体的な要求定義の進め方やポイントについて説明します。
現状業務把握のための業務フロー図式化
要求定義を行うためには、まずは現状業務を正確に把握することが大切です。現状業務は、業務担当者間のみではなく、ベンダーも含め正確に把握する必要があります。そのために行うべきこととして、業務フローの図式化が挙げられます。
業務フロー図とは、仕事の流れや作業手順などを図として表したものです。１つの業務であっても、一人の担当者や１部署で完結する作業は稀です。業務フロー図では、１つの業務に対して関係している部署や関係者を明記することも重要です。
そうすることで、業務の全体像の流れと共に、業務に関係する人を視覚的に示すことができ、担当者間だけではなく、他部門やベンダーとも業務内容や仕事ごとの繋がりを相互理解し易くなるメリットがあります。
また、業務フロー図を作成することで、業務での無駄・ムラなど業務上の課題を発見することにつながります。
As-Is/To-Be分析の実施
As-Is/To-Be分析とは、現状と理想像を書き出して課題を特定し、課題を解決するためのアクションプランを策定する分析方法です。As-Isは「現状」、To-Beは「理想像」を意味します。
要求定義を検討するうえでは「こうしたい」という理想像ばかりに目が向きがちですが、システム開発を無駄にしないためには「誰の、何の課題をどうやって解決したいのか？」を言語化することが重要です。
As-Is/To-Be分析では、まずTo-Beを設定することから始めます。次に、As-Isとなる現在の状況を書き出します。To-Beの設定から行うことの目的は、現状から達成できそうな理想像を書き出すのではなく、本当に達成したい目標を考える必要があるからです。理想像と現実を書き出したら、そのギャップを見比べ、どのような課題があるのか、何を解決すべきなのかを考えることにより、課題を浮き彫りにすることが可能です。
以上、As-Is/To-Be分析を用いることで現状と理想像のギャップが把握できるうえ、課題が明確になります。実際に使われるシステム開発で要求定義を明確にするためにも、As-Is/To-Be分析などのフレームワークを上手く活用しましょう。
期間・費用・効果などの導入効果を検証する
当初のシステム開発目的や目標と照らし合わせ、システム開発にかかった期間、累計費用、得られた成果、実際の現場運用などの項目に沿って、評価を導入し、プロジェクトを各工程で振り返る機会を設けることも重要です。
もちろん、システム開発ではV字モデルでも触れたように、各設計工程がテストにより評価されますが、要求定義では各工程のテスト評価が最終的に要求定義を満たしているかどうかで総合的に評価されます。
仕様書の通りに作られているか動作確認をする検証をするだけでなく、システムが要件定義に合致し、要求定義を実現しているかを評価することによりチェックするのです。
また、現場運用やリリース後のフェーズでもしっかりと効果検証を行い、ノウハウを蓄積することによって、大規模開発では特に重要な保守運用や追加機能の開発にも役立てることができます。
まとめ
今回は、要求定義について発注者の視点に立った重要性や課題などについて解説しました。システム開発をスムーズに進めるには、要求定義の重要性や進め方を理解したうえで、次の要件定義につながる要求定義を作成することが重要です。
要求定義を怠ることで招く失敗は、自社にとって大きな損失にも繋がります。システム開発は予算や人員だけではなく、場合によっては顧客の信頼を失うことにも繋がるため、慎重に検討することが必要です。
まずは上流工程の中でも最初の１歩となる要求定義を円滑かつ丁寧に進めることに意識し、システム開発を成功に導いて行きましょう。
