要件定義を担当することになったけど、何から始めればいいの？
要件定義はどうやって進めるの？
そもそも要件定義とは？何のために要件定義をするの？
失敗したらどうしよう・・・何に気をつければいいの？
プロジェクトマネージャーに任命されたら責任は重大です。
システム開発において、スケジュールが遅れる主な原因のうち、50％以上が要件定義の不備に起因すると言われています。プロジェクトの成否は要件定義で決まると言っても過言ではありません。
要件定義は、「企画構想」「要求定義」「要件定義」の3つのステップで進めていきます。いきなり要件定義に着手するわけではありません。
要件定義を正しく進めるためには、そのインプットとなる要求定義を理解する必要があり、さらに要求定義のインプットである企画構想も正しく理解しなければなりません。
ここでは、システム開発における要件定義について、要件定義の目的と進め方、失敗事例と失敗しないための7つのポイントをわかりやすく解説します。少しでも要件定義の参考になれば幸いです。
要件定義の目的とは
要件定義とは、プロジェクトの企画構想で立案したプロジェクト計画書に沿って進めるシステム開発の上流工程で、そのプロジェクトの目的を達成するための業務要求を実現するために、システム化の機能要件の抽出と実現可能な要件仕様を決定する作業です。
文章にすると分かり難いため、まずは下図をご覧ください。
要件定義はこれら3つのステップで進めていきます。この図のように「要件定義」のインプットは「要求定義」であり、「要求定義」のインプットは「企画構想」になります。つまり、要件定義を正しく進めるためには、企画構想の正しい理解が必要不可欠になります。
Step1の企画構想でプロジェクトの目的を正しく理解し、その目的を達成するための業務要件をStep2の要求定義で決定します。その要求定義をもとに、Step3の要件定義でどのようなシステムを構築するのかを決定する流れになります。
Step1：企画構想
通常、要件定義を行う前には、企画構想のステップがあります。ここではプロジェクトの立ち上げ、体制の構築、プロジェクト計画書の立案を行います。経営方針やシステム化方針により、そのプロジェクトの目的、システム化の構想、実現後の効果が決定し、プロジェクト計画書にまとめ上げます。
Step2：要求定義
企画構想で立案されたプロジェクト計画書をもとに、それに向けた業務プロセスの改善や標準化の検討を行います。現状把握から問題・課題を抽出し、実施すべき業務要件を決めます。
Step3：要件定義
要求定義をもとに、システム化に必要な機能要件を抽出し、実現可能な要件仕様の検討、システム化する機能要件と非機能要件の決定、成果物（ドキュメント）作成を行います。
それでは、要件定義の3つのステップごとに、それぞれの進め方を解説します。
Step1：企画構想の進め方
企画構想を理解する
お客様が作成した企画構想のドキュメントをベースに、プロジェクトでやるべきこと、つまり目的を理解することから始めます。また、プロジェクトのステークホルダーを確認することでプロジェクトの全体像を理解します。
しっかりした体制を構築する
部長や課長など、実際の業務を知らない役職者だけでメンバー構成せず、実際に業務を行っている担当者を組み入れることが重要です。
また、プロジェクト参加によって担当者の仕事が増えることがないようにトップダウンで業務軽減の配慮を行ってもらうことも必要です。
そのためには経営層の上層部がプロジェクトに深く関わっていただく必要があるため、体制に不備がある場合はお客様に申し入れましょう。
体制図の書き方とポイントをまとめています。よろしければ参照ください。
要件定義の主体者はお客様（経営層や業務部門）であることを認識いただく必要があります。なぜなら、プロジェクトで構築するシステムの投資を回収できるのはお客様だからです。システム開発会社が投資を回収できませんので、主体者はお客様なのです。
プロジェクト計画書にまとめ上げる
お客様の企画構想より、プロジェクト計画書を作成します。
プロジェクト計画書の書き方とポイントをまとめています。よろしけれ参照ください。
要件定義の活動スケジュールを作成する
日常業務で忙しい担当者にヒアリングをすっぽかされないように、事前に担当者と一緒にスケジュール表をつくってヒアリング時間を確保しましょう。また、作成した要件定義のドキュメントをお客様に確認いただくレビュー時間も確保しましょう。
お客様にレビューいただくため、お客様がドキュメントを見て理解できる言葉（理解できないIT用語を使わない）で表現することが重要です。
Step2：要求定義の進め方
現状を把握する
システム化の対象となる業務すべてを洗い出します。業務の洗い出しは、大きな括りで業務を列挙してから業務ごとに詳細化していくと漏れなくまとめることができます。
| 業務名 | 詳細業務名 |
|---|---|
| 受注業務 | 注文受付、商品確認、台帳登録、仕入先発注、納品登録、・・・ |
| 出荷業務 | 出荷登録、出荷伝票作成、納品伝票作成、・・・ |
| 在庫管理業務 | 在庫棚卸、入庫管理、出庫管理、月末在庫登録、・・・ |
お客様でも現行業務と既存システムの全体像を描ける方は少ないと思います。まずは現行業務の全体像を可視化することから始めましょう。
現在の業務フロー図をまとめる
システム化対象の業務について、業務担当者にヒアリングして業務の流れを図式化しましょう。業務フロー図は縦軸に登場人物や関連システムを列挙し、横軸は時系列でまとめると分かりやすくなります。
また、業務は日々の業務（日次作業）の他に、月末や月初に行う業務（月次作業）、半期毎や年末のみの業務（年次作業）、突発的な業務（臨時作業）がないかも確認しましょう。
業務を漏れなく洗い出す業務フローの書き方をまとめています。よろしけれ参照ください。
ヒアリング時に現在使っている帳票や画面キャプチャ、既存システムの仕様書やマニュアルなど、参考資料として受領しておきましょう。
もし、既存システムの仕様書やマニュアルが無い場合は、既存システムのテスト環境（本番以外の環境）が利用できないか確認しましょう。
問題や課題を抽出する
業務フローをまとめると業務全体の理解が深まります。これにより、お客様と現在の問題箇所の確認、課題の認識合わせができます。確認した問題や課題は要求事項一覧に追記していきます。
実現可能な問題解決の手段を決める
確認した問題・課題について、お客様の要求に合わせて実現可能な解決手段を検討します。解決方法が決まったら、ビフォーアフター図などにまとめます。
ビフォーアフター図とは、現在の問題点と解決後の姿と効果を業務視点で描いたもので、経営層にも理解できる内容でまとめます。できれば、お客様に依頼してビフォーアフター図に作成してもらってもよいでしょう。
Step3：要件定義の進め方
システム化する機能をまとめる
要求定義で抽出された要求事項より、システム化の手段を検討して具体的な機能要件に落とし込みます。この時、システム運用面でも問題ないことを非機能要件と合わせて検討しましょう。
検討結果は要件定義書としてドキュメントにまとめ、必ずお客様の責任者（承認権限がある方）にレビューして承認を得ましょう。
要件の抜け漏れがないか検証する
まとめた機能要件が、要求事項一覧と照らし合わせて抜け漏れがないか確認します。
また、それらの要件が要求内容と合致しているかも合わせて確認します。抜け漏れがなくても内容が間違っていたら意味がないのでしっかり確認しましょう。
目的を達成できる要件かを確認する
まとめた機能要件が、プロジェクトの目的を達成できる実現可能な手段として妥当であるかを確認します。
決められた予算内で実現できないものであれば、これも意味がないのでしっかり確認しましょう。
要件定義の失敗事例
要件定義を失敗する原因を、それぞれのケースでまとめました。これらの事例に当てはまらないように気をつけましょう。
要件の抜け漏れ、内容が曖昧
システム化の対象となる業務の洗い出しが不十分で、本来はヒアリングしなければいけないステークホルダーが漏れてたことが設計フェーズで発覚するケースです。
最悪は、お客様の受入テスト段階で機能漏れが発覚するケースで、こうなると手戻りによるスケジュール遅れ、開発工数の増加により失敗プロジェクトへまっしぐらです。
ステークホルダーがプロジェクトに与える影響、ステークホルダーの特定や理解など、ステークホルダーの管理方法をこちらで解説しています。合わせてお読みください。
目的に合っていない要件定義
経営層と業務部門の担当者とは目的意識が違うため、業務担当者にヒアリングすると目先の現行システムの操作性に関する改善要求が多くなります。
また、業務担当者は自分達が行なっている業務範囲での改善を希望するため、俯瞰して検討しないと後工程の業務で非効率な改善となってしまう可能性もあります。
それらが目的から逸れていなければまだ良いですが、目的からかけ離れた要求事項であれば全く意味がありません。そうならないためにも、プロジェクトに関わる全員が何のためにシステム構築を行うのか、その目的をしっかり理解してもらうことが重要です。
業務プロセスを見直さない
業務担当者は現行のやり方を変えることに保守的の方が多いと思われます。そのため、現行の業務プロセスは一切変更せず、現行プロセスのままシステム化要件を検討することになります。
会社の歴史が長ければ業務も複雑になっているはずで、そのままではシステム化も複雑になるため開発費用も膨らみます。
複雑なシステムは使い難いため、次第に利用されないシステムになっていくでしょう。
システム運用を考慮していない
システムを稼働させる上で日々のバックアップやメンテナンス、改善活動、リリース作業やマニュアル整備など、システムの安定化には運用管理が欠かせません。
それらを考慮せずに要件定義を行うと、運用設計ができていないために運用後のシステムトラブルにつながります。
そうならないために、システム運用部門もステークホルダーに入れることを忘れないようにしましょう。
要件定義が未完了な状態で次の開発フェーズに進む
お客様とのヒアリングが思うように進まず、この先もお客様の時間が取れないために、要件定義が完了していないにも関わらず次の開発フェーズで要件定義の続きをすることを前提に開発を進めようとするケースです。
もし、手戻りが発生した場合、先に進めば進むほど、そのリカバリー工数は大きなものとなります。
目的に影響する未確定要件を先送りすると、取り返すのつかない事態になるかもしれません。
失敗しないための7つのポイント
要件定義を失敗しないために、気をつけておくべきポイントをまとめました。要件定義を実施する時は、これらを自問自答して失敗を回避しましょう。
その1：目的を達成できる要件定義になっているか
システムを構築することが目的ではありません。構築するシステムを活用することで業務や経営に貢献することが目的のはずです。目的が達成できないのであればシステム化する必要はありません。
間違っても業務部門の「御用聞き」になってはいけません。業務部門が強く要求しているからと、そのまま要求通りに開発しても目的から外れていては意味がありません。
その2：目的に合った業務プロセスに見直されているか
「現行踏襲」という名のもと、何も業務プロセスを見直さずに単なるシステムの置き換えになっていないか要注意です。ビジネスを変えるには、現行の業務プロセスも変わるはずであり、見直された業務プロセスに合わせた要件定義が必要です。
システム開発会社が現行システムを理解していないのであれば、「現行通り」「今と同じ」という文言は前提条件に入れてはいけません。必要な現行機能を洗い出して具体的に定義しましょう。
その3：要件定義の前に現行システムの分析を行なっているか
実際にシステムを利用している業務部門自らが、現行システムで利用していない機能、次のシステムで欲しい機能、環境が変わり改善したい機能などを分析する期間を設けて、しっかり検討いただくと要件定義がスムーズに進みます。
その4：要件定義の主体者はお客様であること認識しているか
繰り返しになりますが、要件定義の主体者はお客様（経営層や業務部門）です。要件定義を開始する前にステークホルダー全員で認識し、責任を持って活動していただくことが重要です。
また、要件定義に参画した責任者や担当者は、その要件定義を最も理解しているため、運用テスト（受入テスト）のテストケース作成やテストの実施にも参画するように計画することも重要です。
要件定義の主体者自らがテストを実施することで、目的を達成できるシステムになっているか最終評価できます。
その5：要件定義は準委任契約にしているか
システム開発は一括請負で契約することが多いと思います。ですが、要件定義が完了しないと開発費用全体が明確にならないため、要件定義は一括請負から切り分けて契約する必要があります。要件定義はお客様が主体となって進めるプロセスですので、準委任契約が妥当です。
また、見積もりも計画時点で提示することが多いと思いますが、それでは見積もり誤差が大きいため、要件定義を含めた一括請負は避けるべきです。
見積もりに失敗しないためにも、要件定義は「準委任」で契約し、それ以降は要件定義後に再度見積もりして契約することを要件定義前に合意しましょう。
見積もり方法とポイントをまとめています。よろしければ参照ください。
その6：要求仕様の凍結と変更管理を合意しているか
お客様の要求は変化するものです。そのため、要求仕様を凍結する仕組みが必要です。例えば、要件定義が完了した時点で凍結することをお客様と合意しておくことが重要です。
そうは言っても、要求事項の詳細まですべて決まることは難しいため、残るものは課題として管理し、予算に影響する場合は追加費用をいただくことも合意しましょう。
また、どうしても対応しないといけない追加要求や仕様変更も出てくると思いますが、その時は変更管理のルールを事前に合意しておきましょう。
課題管理の方法とポイントをまとめています。よろしければ参照ください。
変更管理の方法とポイントをまとめています。よろしければ参照ください。
その7：要件定義の完了報告をお客様に行なっているか
先に記述したように、要件定義が完了していないにも関わらず次の開発フェーズに進めることは絶対にやってはいけません。
要件定義が完了したかどうかの見極めのためにも、お客様の経営層（オーナー）、業務責任者、業務担当者に要件定義の成果物を確認していただく場を設けましょう。
この場では、要件定義で未決定となっている課題や新たに発見されたリスク、当初の予算より費用が増加する場合はその見積もりを提示し、投資対効果の再評価を行なっていただいた上で次フェーズへの着手の承認をいただくことが目的です。
要件定義を曖昧なまま放置せず、しっかりお客様に合意を得てから先に進めましょう。
要件定義の主な成果物
要件定義で作成する主な成果物をまとめています。よろしければ参照ください。
要件定義がプロジェクト成功のカギ
要件定義は本当に難しいと感じます。失敗事例に心当たりがある方もいらっしゃるかもしれませんが、要件定義を失敗すると以降の開発フェーズで問題が山積する事態になりかねません。それだけに要件定義は計画的に、かつ、慎重に進める必要があります。
そのためには、要求定義や非機能要件を理解することが重要です。
要求定義や非機能要件について記事をまとめていますので、こちらもあわせてお読みください。要件定義が計画通りに完了することを願っています。
