要件定義を担当することになったけど、何から始めればいいの？どうやって進めるの？
要件定義と企画構想って、どう関係するの？
企画構想から要件定義の進め方がわからない？
特にプロジェクトマネージャーに任命されたら責任は重大です。
プロジェクトの立ち上げでは、企画構想がとても重要になります。なぜなら、企画構想は要件定義のインプットになるからです。
要件定義は、「企画構想」「要求定義」「要件定義」の3つのステップで進めていきます。いきなり要件定義に着手するわけではありません。
ここでは、要件定義を進める3つのステップ、要件定義の失敗につながる企画構想の問題、問題を回避するポイントをわかりやすく解説します。要点を絞ってまとめましたが、少しでも参考になれば幸いです。
要件定義を進める3つのステップ
要件定義は企画構想から始まります。まずは下図をご覧ください。
要件定義はこれら3つのステップで進めていきます。この図のように「要件定義」のインプットは「要求定義」であり、「要求定義」のインプットは「企画構想」になります。つまり、要件定義を正しく進めるためには、企画構想の正しい理解が必要不可欠になります。
Step1：企画構想
通常、要件定義を行う前には、企画構想のステップがあります。ここではプロジェクトの立ち上げ、体制の構築、プロジェクト計画書の立案を行います。経営方針やシステム化方針により、そのプロジェクトの目的、システム化の構想、実現後の効果が決定し、プロジェクト計画書にまとめ上げます。
Step2：要求定義
企画構想で立案されたプロジェクト計画書をもとに、それに向けた業務プロセスの改善や標準化の検討を行います。現状把握から問題・課題を抽出し、実施すべき業務要件を決めます。
Step3：要件定義
要求定義をもとに、システム化に必要な機能要件を抽出し、実現可能な要件仕様の検討、システム化する機能要件と非機能要件の決定、成果物（ドキュメント）作成を行います。
このように、Step1の企画構想でプロジェクトの目的を正しく理解し、その目的を達成するための業務要件をStep2の要求定義で決定します。
その要求定義をもとに、Step3の要件定義でどのようなシステムを構築するのかを決定する流れになります。
企画構想の問題
ここまで、要件定義の3つのステップを説明しましたが、企画構想が要件定義のインプットになる重要なプロセスであることを理解いただけたと思います。
しかし、その企画構想の内容に問題があったらどうなるでしょうか。
企画構想の内容に問題があるケースを列挙します。これらのケースに該当する場合は、一旦要件定義を進めることはやめて、企画構想の問題を解決することが先です。
目的・目標が曖昧
目的が「○○業務の革新」や「○○業務の効率化」など、曖昧なゴール設定の場合、プロジェクトに関わるステークホルダーによっては捉える解釈が異なってきます。
そのため、目的・目標はステークホルダー全員が誤解しないように具体的に設定する必要があります。
対象範囲が曖昧
プロジェクトの対象範囲（対象事業、対象業務、対象システム）が定義されていない場合、どこまで要件定義を実施すればいいか分からず、ズルズルと要件定義を続けてしまう状態に陥ります。
要件定義が遅れると、以降の開発フェーズすべての納期短縮とコスト増加に繋がるため、対象範囲が不明確な状況で要件定義を開始するのは避けたいところです。かといって、要件定義が未完了な状態で次のフェーズに進むと、以降の開発フェーズで要件定義漏れの手戻りが発生した場合のリカバリー工数は大きな負担となります。
体制（ステークホルダー）が不十分
プロジェクト推進において体制づくりはとても重要です。プロジェクトの対象範囲に見合う体制が作られているか、漏れなくステークホルダーが選出されているかを確認しておく必要があります。
業務の詳細を知らない部長や課長だけで構成された体制では、実際の業務手順やイレギュラー対応まで把握しておらず、業務要件が漏れてしまう可能性が高くなります。
また、それぞれの役割が不明確な体制は責任も不明確となり、主体性がなく、情報システム部門任せになってしまいます。
ステークホルダーがプロジェクトに与える影響やステークホルダーの管理方法についてまとめています。よろしければ参照ください。
期待効果が不十分
企画構想では、プロジェクトで構築するシステムを導入するとどれくらいの効果があるか、プロジェクトで掛かる費用と比較して費用対効果を想定します。ですが、その効果の想定値は業務部門が納得して定義したものかどうかが問題です。
これは企画構想の問題というよりも、プロジェクトに参画するメンバーの心構えができているかという問題になりますが、費用対効果を検証する段階で重要になります。
システム構築の投資を回収できるのはお客様の業務部門になります。
その業務部門が主体的に企画段階から参画していないプロジェクトは、目的意識が低いために主体性に欠けて、要件定義漏れや受入テスト（運用テスト）不足など、弊害をもたらします。
ですから、業務部門のメンバーが期待効果に納得して主体的に進めることが重要になるわけです。
プロジェクトの立ち上げで確認するポイント
このように、企画構想に問題があると要件定義を進めることができません。
企画構想の問題を回避するために、プロジェクトの立ち上げで確認しておきたいポイントをまとめました。
要件定義へ進む前に、これらを点検して失敗要因の芽を摘んでおきましょう。
企画構想に曖昧な部分がないか
企画構想には下記の項目が必要です。それぞれ具体的に記述されているか確認しましょう。もし記述が無かったり、内容に曖昧な部分がある場合は、遠慮せずにお客様に確認して明確にしましょう。
| 項目 | 確認する内容 |
|---|---|
| システム化背景 | なぜシステム化が必要なのか、システム化に至る事情、取り巻く環境 |
| 目的 | システム構築によってどうなりたいのか（目指すゴール、将来の姿） |
| 問題 | 現状の問題点（事業の問題、業務の問題、システムの問題） |
| 課題 | 目的を実現するための課題設定、解決すべきテーマ設定 |
| 経営方針 | 事業や業務の問題・課題を解決する方向、道筋、進め方 |
| システム化方針 | 業務プロセスと構築するシステムの理想の姿 |
| 期待効果 | 構築するシステム導入後に期待する効果（費用対効果） |
| 対象範囲 | プロジェクトの対象範囲（対象事業、対象業務、対象システム） |
| 体制 | お客様のプロジェクト推進体制（ステークホルダー） |
| 予算 | お客様のプロジェクト予算 |
| 活動期間 | プロジェクト期間、構築システムの本稼働時期、運用開始時期 |
企画内容が不十分な場合は無理して要件定義を進めずに、お客様を支援して一緒に作成しましょう。そうすることで企画構想の目的や目標の理解が深まり、要件定義もスムーズに進めることができます。
強引なプロジェクト進行は後々のリスクとなり、最悪は大きな手戻りに繋がります。企画構想も支援できないかお客様に提案してみましょう。
しっかりした体制を構築しているか
部長や課長など、実際の業務を知らない役職者だけでメンバー構成せず、実際に業務を行っている担当者を組み入れることが重要です。
また、プロジェクト参加によって担当者の仕事が増えることがないようにトップダウンで業務軽減の配慮を行ってもらうことも必要です。
そのためには経営層の上層部がプロジェクトに深く関わっていただく必要があるため、体制に不備がある場合はお客様に申し入れましょう。
体制図の書き方とポイントをまとめています。よろしければ参照ください。
要件定義の主体者はお客様であること認識しているか
要件定義の主体者はお客様（経営層や業務部門）であることを認識いただく必要があります。
なぜなら、プロジェクトで構築するシステムの投資を回収できるのはお客様だからです。システム開発会社が投資を回収できませんので、主体者はお客様なのです。
そのためには、要件定義を開始する前にステークホルダー全員で認識し、責任を持って活動していただくことが重要です。
また、要件定義に参画した責任者や担当者は、その要件定義を最も理解しているため、運用テスト（受入テスト）のテストケース作成やテストの実施にも参画するように計画することも重要です。
要件定義の主体者自らがテストを実施することで、目的を達成できるシステムになっているか最終評価できます。
要件定義は「準委任」で契約できるか
システム開発は一括請負で契約することが多いと思います。ですが、要件定義が完了しないと開発費用全体が明確にならないため、要件定義は一括請負から切り分けて契約する必要があります。要件定義はお客様が主体となって進めるプロセスですので、準委任契約が妥当です。
また、見積もりも計画時点で提示することが多いと思いますが、それでは見積もり誤差が大きいため、要件定義を含めた一括請負は避けるべきです。
見積もりに失敗しないためにも、要件定義は「準委任」で契約し、それ以降は要件定義後に再度見積もりして契約することを要件定義前に合意しましょう。
見積もり方法とポイントをまとめています。よろしければ参照ください。
仕上げはプロジェクト計画書の作成
「企画構想の問題」に挙げたケースに該当するプロジェクトは意外と多いのではないでしょうか。これらの問題を放置すると要件定義で後悔することになってしまいます。
後悔しないためにも、「プロジェクトの立ち上げで確認するポイント」について企画構想を点検しましょう。
ここまで来れば、あとはプロジェクト計画書を仕上げて、要件定義に進むだけです。
とはいえ、要件定義が計画通りに進められるかどうかはプロジェクト計画書の内容次第ですので、ここもしっかり準備しましょう。
プロジェクト計画書の書き方とポイントをまとめています。よろしけれ参照ください。
もし要件定義の進め方に少しでも不安がある方は、要件定義の記事をまとめていますので、こちらもあわせてお読みください。要件定義が計画通りに完了することを願っています。
