要件定義とは何か？要件定義の進め方と要件定義書の項目・書き方を解説
要件定義の概要
要件定義とは、ソフトウェア開発の最終成果物であるアプリケーションについての要求分析です。
要件定義を行うためのインプットは依頼者からの要求事項であり、その成果物は要件定義書になります。
要件定義の位置づけは開発のスタートラインになります。何を開発するのか、何のために開発するのか、開発したアプリケーションにはどのような機能があるのか、などあらゆる視点でこれから行う開発を明確に定義します。
つまり要件定義とは開発を進める過程での道標、及びゴール設定になるものです。
要件定義の責任者は依頼者（取得者）
要件定義を解説する前に、必ず確認しておきたいことがあります。それは要件定義の責任者です。
ITシステムを開発するプロジェクトでは要件定義から設計、開発、テストまで、すべて一貫して行うことも珍しくありません。
そのため、すべてをベンダー（開発会社・納入業者）の責任にしてしまいがちですが、要件定義についての最終的な責任は依頼者側（発注者・取得者）にあります。
もちろん、ベンダーも積極的に依頼者にアドバイスを行いながら、費用やスケジュールの面から無理な要求がないかをチェックしていかなければなりません。しかし、先述のとおり、要件定義とは「何を開発するか」「何のために開発するのか」というゴールの設定であるので、ゴールの設定は依頼者側が責任を負わねばなりません。
「こうした要望を伝えていなかった」「ゴールの設定を誤っていた」という責任の所在は依頼者側にあるのだという前提をしっかりと念頭におきながら、要件定義に取り組んでいきましょう。
要件定義の始まりは要求事項の整理から
要件定義のための最初の作業は、要求事項の整理になります。要求事項とは、例えば「アルバイトでも簡単にWebサイトを更新できるようにしたい」「自動で毎月の経費を計算してほしい」などというざっくりとした依頼者の要望のことです。
要求事項は「ニーズ」とも呼ばれますが、最近ではこちらの言葉のほうがイメージが付きやすいかもしれません。
まずは依頼者側が「何を求めているのか」を整理することから要件定義は始まりますが、そのときの注意点を下記に挙げます。
- 依頼者から要求事項一覧を受け取るだけでなく、ヒアリングにより要求内容を十分に理解する
- 要求事項のすべてを満たせないこともあるため、要求事項に優先順位をつける
- 要求事項の背景を確認することで、その要求の意味を明確にする
- 課題については、根本的な問題を掘り下げ、解決方法の選択肢を広げておく
要件定義は依頼者とのコミュニケーション
依頼者から引き出した要求事項に対し、対応方法を示したものが要件定義です。
要求事項の確認に漏れがあれば、開発したアプリケーションの致命的な欠陥になることもあります。
そのため、ヒアリングにより依頼者と開発プロジェクトの間で、認識のズレを無くすことが重要になります。
要件定義フェーズに始まり、設計（外部設計・内部設計）、開発、テスト、納品というITプロジェクトの進行の中で、要件定義の内容の確認は頻繁に行われることになります。
そのため、最終的な責任は依頼者側にあるとはいえ、ベンダー側も顧客たる依頼者とのコミュニケーションを十分に取り、積極的にプロジェクトに関与してもらえるよう促していかなければなりません。
要件定義書の項目
開発案件によって要件定義書の項目は様々ですが、一般的なものを下記に示します。
- 背景/目的/目標：開発の目的を明確にする
- 成果物概要：第三者でも成果物がイメージできるものを図示する
- 動作環境：アプリケーションの動作環境を記載する
- ユースケース：重要なユースケースを挙げる
- 機能要求：要求事項を実現するための機能を検討する
- 入力/出力要求：アプリケーションの入力、出力を明確にする
- 接続性要求：連携するアプリケーションがあれば記載する
- ソフトウェア要求：保守性、信頼性、拡張性の目標とするレベルを定義する
- セキュリティ要求：セキュリティの側面からの対応内容を検討する
- スケジュール要求：要求されるスケジュールを記載する
要件定義書を書く上での注意点
機能要求の整理
大規模な開発になると、要件定義書に多大な機能要求を記載することになります。その場合、要求の最小単位を明確にして構造的に記載することで、下記のようなメリットが得られます。
- 要求全体の理解がしやすくなる
- 設計フェーズでソフトウェア構造を検討するときにプラスになる
- 要求が追加、変更になった場合に影響範囲が捉えやすくなる
曖昧さを排除する
要件定義書において曖昧な記載は危険です。曖昧な内容は、読み手によって解釈が異なりますし、最終的なアプリケーションが顧客たる依頼者からの要求を満たしているかの判定ができないからです。
例えば、ある処理結果までの時間に対する要求であれば、「操作性に問題ない時間で」と記載するのではなく、「処理時間は〇〇秒以内」と具体的に記載するようにします。
非機能要求（非機能要件）にも注意する
要件定義を行う際には、非機能要求にも言及しておく必要があります。
「非機能要求」とは字のごとく「機能要求以外の要求」を意味しています。つまり、機能要求が「システムにこのような動きをしてほしい」というものであるのに対し、どの程度運用しやすくするのか、どのくらい高いセキュリティ設定を行うのかという要望が非機能要求になります。
これらの非機能要求への対応策をまとめ、非機能要件もしっかりとまとめておきましょう。
この非機能要件については、以下の記事もご参照ください。
設計はしない
要件定義とは要求を分析し、アプリケーションの外部の振る舞いを検討する作業です。
その中では、設計的な要素を含んではいけません。設計とは、要件定義の次工程にあたり、完成した要件定義書から設計担当者が行うもので、要件定義の段階においては、設計の自由度を残しておく必要があります。
そのため、実現の可否は確認しつつも、要件定義はあくまでも依頼者の要望の大まかな方針を示していくのにとどめておいた方がよいでしょう。
依頼者からの機能要求を無批判に受け入れない
要件定義をしている中で、時として依頼者側が設計にまで言及することがあります。
例えば、ある課題を解決するために、依頼者から、「〇〇画面のここに、〇〇のボタンを追加してほしい」と要求されることがあります。そして、そのまま要件定義書に記載し開発を進めることになった場合、後から依頼された画面にボタンを設置できないなどの設計の不整合に気付くことがあります。
その場合どうするかが要件定義書に書いてあればよいものの、代替案の情報がない場合は再び要件定義に戻らなければなりません。
このように、設計に関わるくらいの、具体的な「何をどうする」という機能要求を無批判に受け入れてしまうと、実際にその設計の実現ができない場合にトラブルにつながってしまいます。
そのため、要件定義の中で具体的な機能要求が依頼者からでたとしても、その背景、課題、解決方法など、ヒアリングを行い、要件定義書に記載していきましょう。
例えば先ほどの「〇〇画面のここに、〇〇のボタンを追加してほしい」という要求であれば、「なぜその画面なのか？」「どのような意図でボタンが必要なのか？」「どのような課題を抱えているのか？」「他の解決方法はどのようなものがあるのか？」を議論し、当初の要望が実現しなくとも、すぐに別の対応策が採れるような準備をしておきましょう。
要件定義書は常に最新の状態にしておく
すべての開発ドキュメントに言えることですが、変更が入ったときには、すぐにアップデートし、常に最新の状態にしておいてください。
開発が進むにつれて、開発ドキュメントの中でも要件定義書が一番遠い存在となってしまい、ついアップデートを行わず、不完全な要件定義書のまま、その後の開発を進めることになってしまいます。要求の追加、もしくは変更による設計変更が発生したときには、まず要件定義書を、その後に、影響のある設計ドキュメントをアップデートしてください。
よりよい要件定義のための一工夫
キックオフミーティングでスタートラインを確認する
要件定義は、プロジェクト・メンバーの認識を合わせるための絶好の機会でもあります。
ITプロジェクトでありがちなのは、依頼者側でプロジェクトマネジメントを行うIT部門と、実際にそのITシステムを使う営業部門、そして開発を依頼されたベンダーの想定しているものが異なっており、要件定義の中で要領を得ない要求が飛び交ってしまうというものです。
こうしたトラブルを回避するために、まずはキックオフミーティングを開催し、プロジェクトの目的や各部門が想定しているもの、現状のシステムへの不満を話し合い、プロジェクトのスタートラインをあわせておくとよいでしょう。
キックオフミーティングについては、以下の記事もご査収ください。
プロトタイプを活用する
画面仕様に関する要求の確認については、プロトタイプ（試作品）の活用は有効です。
最終的なアプリケーションのような振る舞いをするプロトタイプの作成には準備に時間も工数もかかるため、画面遷移と各画面のレイアウトのイメージが分かる資料を簡単に作成し、紙芝居的な動きを見せるだけでも十分に効果があります。
要件定義は準委任契約で依頼する
経済産業省の「情報システムの信頼性向上のための取引慣行・契約に関する研究会」がまとめた「情報システム・モデル取引・契約書」では、要件定義を外部の組織に依頼する場合は、準委任契約を結ぶことを薦めています[1]「情報システムの信頼性向上のための取引慣行・契約に関する研究会」報告書－モデル取引・契約書＜第一版＞－概要。
準委任契約では完成義務や瑕疵担保責任がないため、要件定義をサポートするというコンサルティング業務の色合いが強い業務に向いているだけでなく、依頼者がベンダーなどの受注側に対して仕事を丸投げしにくくなるという効果もあります。