要件定義とは？進め方のポイント、基本設計との違いを解説

プロジェクトの最初に行う要件定義は、システム開発において欠かせない工程です。要件定義に不備があると全体に支障をきたし、最悪の場合プロジェクトの失敗につながってしまう恐れがあります。

今回の記事では要件定義の基礎知識、要件定義の進め方についてご紹介します。要件定義についての知識を深め、スムーズにプロジェクトが進むようにしましょう。

要件定義とは

まずは要件定義とは何かについて、ご説明します。

システム開発の最初の工程

要件定義は、システム開発において最初に取り組む工程です。

システムが完成するまでには、例えばウォーターフォール型開発の場合、「要件定義→設計→製造→テスト」の順で流れます。

どのような機能をもつシステムを、いつまでにどのようなスケジュールで作成し納品するかを決め、計画に沿って作業を進めます。

いわば開発の土台で、プロジェクトの成功につながるといっても過言ではありません。

プロジェクトの大元となる要件定義は、クライアントのビジネス上の要求を具体的なシステム開発に落とし込んでいく上流工程の要であり、クライアントのビジネスの理解に加え、さまざまなプログラミング経験が活かされます。

クライアントの要望をまとめたもの

要件定義ではクライアントからのヒアリングを通じ、ビジネス上・システム上の要求を引き出し、クライアントが実装を望む機能の詳細をピックアップします。

開発側はクライアントの要望を受け、システムに実装できる機能であるかを判断します。

開発側・クライアント側の意見を総合的に判断し、「どうシステム化するか」を決定した上で、開発側とクライアントとの間で認識を合わせたものが要件定義です。

認識合わせがなされた要件定義に基づいて、以後、業務シナリオや業務フロー、データモデルなどを作成します。

要件定義を丁寧に行わないと、テストの段階で認識に咀嚼があることに気づき、作業工程がストップして納品が遅れてしまうこともあります。

納期の遅れは顧客満足度の低下につながり、信頼度が下がる可能性もあるため、気をつけなければなりません。

要件定義はシステムに組み込む機能を決める重要な行程ですが、以降の行程が圧迫されるため時間をかけすぎず、効率的に行う必要があります。

要件定義と基本設計の違い

一般的に、システムの開発は「要件定義→基本設計→詳細設計」の順に進みます。

ただ実際は、要件定義の一連の流れに基本設計が組み込まれることも多いため、混同しやすいです。

そこで要件定義と基本設計の違いについて解説します。

クライアントの要望を確認するのが要件定義

クライアントからの要望を引き出し、システムに実装する機能を確認するのが要件定義です。

要望に対し開発側は、どうしたら実現できるかを考え、両者の間で認識に相違がないかチェックします。

クライアントと開発側が認識を合わせた証として、要件定義は、通常、要件定義書という書面にまとめられます。

システムの基本を決めるのが基本設計

基本設計は、実際にシステムを動かすための基本を決める工程です。

要件定義の具体化・詳細化ともいえ、運用規定やセキュリティなどに関する重要な項目も、基本設計でまとめます。

外部設計とも呼ばれるのは、画像やイメージ図などを使うため全体像を見える化するためです。

基本設計の成果物も、最終的には基本設計書という書面にまとめられます。

基本設計には、以下のようなものが含まれます。

機能や画面、システムなどのさまざまな視点から、システムを構築するために必要なものを設計します。

IPA（独立行政法人情報処理推進機構）の参考情報

要件定義の質を上げていくには、個々人で経験を積み重ねるのはもちろん、様々な事例や情報をよく押さえておくことが大切です。

そのためには、IPA（独立行政法人情報処理推進機構）の取り組みが参考になるでしょう。

IPAでは、ビジネスのIT化・DX化推進の観点から、要件定義をはじめとする上流工程の強化に向けた様々な情報発信を行っています。

その中でも主なものをご紹介します。

経営層がITシステム開発に関わることの大切さ

IPAが2006年に発行した『ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ』（独立行政法人情報処理推進機構（IPA）によれば、経営層がITシステム開発の上流に関わることが大切だとあります。

IPAの情報によると 、要件定義の不備がプロジェクトの失敗やシステムトラブル発生の原因となった例は少なくありません。

ビジネスの要求が多様化してきた現在では、システムトラブルが起きた際の影響は広く、与えるインパクトは以前にも増しています。

一つのトラブルが甚大な影響を及ぼす環境でこそ、ステークホルダーからの要望を丁寧に引き出し漏れなく整理する工程が重要です。

そこで、要件マネジメントに関する抜粋内容を記載します。

要件定義マネジメント

要件定義マネジメントは、「立ち上げ・計画立案・監視とコントロール・終結」の4つに分けて作業を行います。

立ち上げ

「立ち上げ」では要件定義の前に行った企画や構想を確認した上で、どこをゴールにシステム開発をするのかなどをもとに、要件定義工程を開始できるか判断します。

目的意識を持ったうえで、ステークホルダーを特定。

またプロジェクトの責任者を明確にするためにオーナーを決め、プロジェクトの開始許可はオーナーによって出されます。

プロジェクト成功のためにも、立ち上げ段階でシステム化すべき箇所を具体的に明確にすることが必要です。

計画立案

「計画立案」ではプロジェクトを成功させるために、必要な工程と成果物を整理しスケジュールや費用の見積もりを作成したのち、体制を構築します。

計画立案をおろそかにすると、本来は必要であった成果物を省いてしまい、後に手戻りが発生するなどの問題が起きます。

この段階で、成果物を作成する担当者を選定する必要があります。

スケジュールを作成する際にも、どの工程にどのくらいの所要時間がかかるのか、裏付けのある計画にすることが非常に重要です。

監視とコントロール

「監視とコントロール」ではプロジェクトがどのくらい進んでいるかの進捗確認やパフォーマンスの監視、状況に応じて計画の変更を行う作業です。

スケジュールのコントロールは難しく、作業に落とし込まれていないタスクが多くあり、進捗具合を出来高ベースで把握できないなどの問題があります。

要件定義では進捗の遅れ具合が分かりにくく、関係者も多いことからスケジュール遅延の対策が難しいです。

そのため詳細なチェックポイントを設け、進捗の遅れを早期に対処する必要があります。

終結

「終結」では要件定義でとりまとめた内容の成果を評価し、プロジェクトの完了判断を行います。

要件定義についてよりまとまった情報を入手したいと考えている方は、IPAのガイドを読んだり、Webサイトを訪れてみたりしてはいかがでしょうか。

要件定義の進め方のポイント：5W2Hを意識すべし

要件定義のミスは、テスト工程のようなプロジェクトの終盤で発覚することが多く、手戻りが大きくなってしまいます。

要件定義の工程でミスを発見できればすぐに修正できますが、開発の終盤で見つかると設計書の修正からテストまで手戻りが大きく、納期が遅れる可能性もあります。

要件定義段階でのミスをなくすには、クライアントとのヒアリングやその後の認識合わせで、常に5W2Hを意識すべきです。

いつ

プロジェクトを始めるにあたり、納期の設定は必須項目です。

納期に合わせてスケジュールを組み、納期内の完成を目指します。

一般的には早めに設定されることが多いですが、法改正への対策や保守期限切れの対応などが重なると、状況に応じて設定されます。

どこから

どこからの依頼でシステム開発を行うのかも、確認しておきたいポイントです。

対象となるシステムや組織、業務などの範囲設定を行います。

なぜ

システムを開発する際に、「システムを作る」がゴールになってしまうことがよくあります。

膨大な費用がかかるためシステムを作ってはみたが使えない、状況は企業に大きな損失を生みます。

そのため、なぜシステムを開発するのか目的を明確にすべきでしょう。

クライアントにヒアリングを行う際にも「要望」が必要な理由について確認せず、「要望があったから必要だ」と考えがちです。

「要望」の背景が何なのかを理解することが大切です。

誰が

開発したシステムを誰が使うのか、が抜け落ちてしまうことはよくあります。

開発側がどの利用者に向けて作るのか、一定のユーザーには制限をかけるのかなどの把握ができません。

何を

何を作るのか、どのような情報を扱うのかを確認します。

取り扱う情報によってはセキュリティをより強化しなければならないなど、何を作るか・扱うかによって対応する必要があるからです。

どのくらい

利用する頻度やそれに合わせた量などは、ヒアリングで抜け落ちることが多いです。

クライアントからの要望を受けたうえで、どこまでシステムに搭載する機能を作るのか、まで考える必要があります。

利用者が毎日利用するのか、それとも1年に一度程度かの利用頻度によっても、構築する機能は変わってきます。

ヒアリングの時点で、丁寧に要望を引き出すようにしましょう。

どうなるのか

要望を受けて開発したシステムによって、どうなるのかを想定しなければなりません。

作るだけで目的が終わらないよう、「どうなるのか」を明確にするとよいでしょう。

要件定義の進め方の詳細はこちらをご覧ください。https://www.qbook.jp/column/20191204_736.html

その他

5W2Hを意識することも大切ですが、要件定義段階から第三者の評価を入れることも、ミスを減らす有効な方策の一つです。

要件定義に不備があると、下流工程に向かうに連れさまざまな問題が発生します。

そこで上流工程から第三者による品質コンサルティングを導入することで、自分たちで分かったつもりになっている要件や、問題点の出やすい境界値の要件といった、曖昧になりがちな要件を明確化できます。

案件の予算規模や重大性によっては、総合的なコストの削減と品質の向上、開発効率の改善のために、上流工程での品質マネジメントの導入も検討すべきでしょう。

要件定義の進め方の詳細はこちらをご覧ください。https://www.qbook.jp/column/20191204_736.html

まとめ

今回の記事では、要件定義とは何か、基本設計との違いやIPAの取り組み、要件定義の進め方のポイントについてご説明しました。

ビジネス環境の変化やIT技術の進歩などによって、開発プロジェクトの難易度は上がっています。

要件定義ですべてが決まるといっても過言ではなく、要件定義でミスがあると後の工程で取り返しのつかないことになりかねません。

5W2Hを意識したり、場合によっては第三者の品質マネジメントを入れたりなどして要件定義のミスを減らしていくことが、より高品質なソフトウェア開発を実現していきましょう。