要件定義工程の進め方

システム開発の上流工程である要件定義では、顧客が抱える課題に対してどのようなシステムを作るのかを概要レベルで決定する。

要件定義が必要なのは「作ったはいいが使えないシステム」という状況を防ぐためで、システム開発におけるWhyとWhat（何のために何を作る）を明確にする工程だともいえる。

ただ、若手エンジニアだと要件定義の進め方がよく分からない人も多いと思うので、今回は要件定義の進め方を説明する。

要件定義工程の進め方【全体概要】

要件定義工程の進め方は下記のとおり。

ざっくり説明すると、
　1.どう進めるのか計画を立てて
　2.どんな業務にしたいのか整理し、
　3.どんなシステムが必要なのか整理し、
　4.要件定義書にまとめ、見積りをする
という流れだ。

1.要件定義の計画作成

要件定義をはじめるにあたって、システム化の方針を明確にし要件定義のスケジュールや体制図を作成する。

と書いたものの、実際の現場では要件定義工程に入る前に計画書を作成している。でないと、顧客から作業費用がもらえないからだ。

また、要件定義をはじめた直後は5W2Hが曖昧なことが多いため、要件定義のなかで明確にしていこう。

2.業務要件の整理

若手エンジニアのよくある失敗例として、「どんなシステム機能が欲しいですか？」というように、業務要件ではなく、システム要件のヒアリングをしてしまうことがある。

いきなりシステム要件をヒアリングすることがなぜ危険かというと、最初は顧客側も現状分析が十分にできていないことが多く、このような状況でシステムの質問をしても、顧客側から話を引き出せなかったり、後々の工程で機能を追加されたりと、トラブルの生じるリスクが高くなってしまうからだ。

ゆえに、要件定義では「システム要件の整理」の前に「業務要件の整理」を行うのである。

業務要件の整理では下記の作業内容を行う。１つずつ説明していこう。

　2-1.現行業務の整理
　2-2.ヒアリング実施と課題分析
　2-3.新しい業務の検討
　2-4.システム化範囲の検討

2-1.現行業務の整理

業務の「あるべき姿（To-be）」と「現状（As-is）」とのギャップが「業務課題」となる。

課題を抜けなく洗い出すためにも、現行業務（As-is）の整理は重要なのだ。

現行業務を整理する手法はいろいろあるが、「業務フロー」を作成するのが一般的で、フロー上に書ききれない詳細な内容は、「業務処理定義書」に記載する。

プロジェクトの特性に応じて、「データフロー」や「ユースケース」を用いて整理することもある。

また、現在は、部分的にシステム化をしている場合がほとんどなので、現行システムの調査も行い、業務フローにシステム機能を追記しておこう。

もし、現行システムの資料が無い場合は、要件の抜け漏れを防ぐためにも、下記のような資料を整理をしておいた方がいいだろう。

2-2.ヒアリング・問題分析・解決策検討

業務部門にヒアリングをしながら課題を分析し、対策を検討するタスク。

対策には、システム化による対策だけでなく、業務プロセスだったり体制の変更なども含める。

それでは下記３つの観点で説明していこう

　１）ヒアリングの実施
　２）問題の分析
　３）解決策の検討

１）ヒアリングの実施

今回のプロジェクトのテーマ（つまり、事業課題）に沿った業務上の問題について、業務部門にヒアリングを行う。

ヒアリングの方法にもいろいろあるが、例えば、日立製作所では、RAカードと呼ばれるアンケートカードを用いて、「問題」「影響」「原因」「願望」という４項目に分けて記入してもらうそうだ。

ヒアリングした内容は、一覧表にまとめて後々確認できるようにしておこう。

２）問題の分析

ヒアリングの結果をもとに、問題・影響・原因を構造的に整理する。

整理するときは、「問題」から整理していく良いだろう。

影響に対しては「だから何？」を繰り返して、「売上／コスト／顧客満足度／コンプライアンス」といった経営レベルの観点につなげよう。

原因に対しても「なぜ？」を繰り返して、「業務プロセス／システム／制度・ルール／組織・担当者／設備・機器」といった観点に落とし込んでおくと対策が検討しやすい。

また、それぞれの問題に対して優先順位を仮決めしておくと、解決策の検討対象を絞ったりシステム化の対象範囲を決めたりする際に役立つだろう。

３）解決策の検討

掘り下げた原因に対しての対策を検討する。

前述した5つの観点で考えると対策が出やすい。（システム化だけが対策ではない）

ここでの”システム”に当たる部分がシステム要件へとつながっていく。

2-3.新しい業務の検討

現行業務の資料に検討した解決策を反映させる。

現行のデータフローやユースケースを整理していた場合は、改善後の資料も整理しておこう。

2-4.システム化範囲の検討

新しい業務の姿が描けた後はシステム要件の整理へと入っていくが、その前に今回のプロジェクトでのシステム化範囲を検討する。

要件定義開始時の範囲から外れていなければ問題ないが、問題分析・解決策の検討を行った結果、システム化範囲が変わってきている可能性があるからだ。

具体的な作業としては、要件定義開始時の５W２HのWhere（対象範囲）やHow（実現手段）をチェックする。

当初と比べてシステム化範囲が拡大している場合、範囲を絞ったり、プロジェクト予算を増やしたりする必要があるだろう。（要件定義のスケジュールが延長となることもある）

3.システム要件の整理

業務要件の整理が終わったら、システム要件の整理を行う。

システム化の範囲やプラットフォームに変更がないかを再検討し、システムの機能要件と非機能要件を具体的にしていくという作業だ。

では、下記２つの作業内容を説明していこう。

　3-1.プラットフォームの検討
　3-2.機能要件と非機能要件の整理

3-1.プラットフォームの検討

プラットフォームとは、システム機能を提供するためのネットワーク、ハードウェア、OS、ミドルウェア（DBなど）のこと。

前作業「システム化範囲の検討」の結果を受けて必要なプラットフォームを整理していく。プラットフォームの変更は、プロジェクトに多大な影響を及ぼすためしっかりと検討しておきたい。

3-2.機能要件と非機能要件の整理

新しい業務を実現するうえでのシステム要件を整理する。

システム要件は「機能要件」と「非機能要件」に分類できる。

機能要件は、画面や帳票といった入出力機能から整理していくと良いだろう。

非機能要件は、IPAの『非機能要求グレード』を参考にすると整理をしやすい。

機能要件と非機能要件は下記の記事でも説明しているので、参考にしてほしい。

機能要件・非機能要件の書き方【サンプル有り】

2018年8月17日

4.要件定義のまとめ／見積り

要件定義のまとめとして、下記の作業を行う。

　4-1.要件定義書の作成
　4-2.基本設計以降の計画作成
　4-3.見積りの算出

4-1.要件定義書のまとめ

これまで作成してきた資料をまとめる作業だ。

>> 「要件定義書の書き方」を見る

4-2.基本設計以降の計画作成

要件定義書の作成後は、基本設計以降の作業を洗い出し、スケジュールを立てよう。

ここで作成した資料は、見積りや、後続工程でのスケジュール・コスト管理にも使用する。

システム開発のＶ字モデル

出典：IPA『ソフトウェアテスト見積りガイドブック』,p.8

4-3.見積りの算出

要件定義書が完成した後には、システム開発の見積りを算出し予算をオーバーしていないかをチェックする。

参考までに、下記に代表的な見積り手法を３つ紹介しておこう。
　１）類推見積り
　２）パラメトリック見積り
　３）ボトムアップ見積り

１）類推見積り

過去の類似プロジェクトから、見積りを類推する方法。

予算獲得時など、上流工程の初期見積りで使われることが多いが、精度が粗いため、要件定義以降ではほとんど使われない。

２）パラメトリック見積り

機能数や画面数などに係数をかけて見積りを算出する。

係数の設定次第で見積り精度が変わってくるが、利用実績の多い企業では係数の信頼度も高く、ユーザー企業の理解も得やすいため、最も利用される手法だ。

３）ボトムアップ見積り

プロジェクトの作業を洗い出し、工数を算出する方法。

作業ベースで見積るので最も精度が高く、プロジェクト開始後のスケジュール・コスト管理にも流用できる。

IPA『ソフトウェア開発見積りガイドブック』,pp.48-59 を参考に記載

さいごに

以上、要件定義の進め方を説明してきた。

ここに紹介してきた要件定義の進め方は、情報処理推進機構（IPA）や日経BPの記事をベースにしているため、やや”お堅い”内容になっている。

私の経験上、自社システム開発ではここまでしっかりとした要件定義をしていない。だが、顧客のシステム開発を請け負う場合には、作業ボリュームに大きい小さいはあるものの要件定義が行われることは認識しておいた方がいいだろう。

この記事が参考になれば幸いだ。

要件定義工程の関連記事はこちら。

要件定義工程の進め方

2021年2月7日

要件定義の目的は「プロジェクト5W2Hを明確にして失敗を減らすこと」

2021年2月6日

要件定義における成果物一覧と書き方（要件定義書サンプルあり）

2021年2月5日

機能要件・非機能要件の書き方【サンプル有り】

2018年8月17日

参考文献

IPA『共通フレーム2013』

IPA『経営者が参画する要求品質の確保』

IPA『ユーザのための要件定義ガイド』

IPA『非機能要求グレード』

IPA『ソフトウェア開発見積りガイドブック』

日経BP『要求定義の方法論を知る』

日経BP『手戻りなしの要件定義［業務の分析・設計］』

経済産業省『情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）＜第一版＞』