最終成果物の構成を事前に決定し関係者で合意することで、作業の無駄を削減し、コミュニケーションを円滑にし、進捗管理と品質を向上させます。

目的：要件定義のプロセスを設計するため

やること：最終成果物の構成を事前に決定し、関係者で合意する

作業を開始する前に、最も重要なことは「最終的に何を出力するか」を明確にすることです。
つまり、要件定義書の構成を事前に決め、主要な関係者と合意を得ることが不可欠です。

要件定義書の構成を決定します。
これは要件定義の成果物を決めることと同じです。

プロジェクトマネージャー（要件定義責任者が設定されている場合はその担当者）が主導して決定し、主要なステークホルダー（顧客・開発チーム・その他重要な関係者）でその内容について合意を形成します。特に、顧客側の承認者と開発側の責任者が早期に構成案をレビューし、認識を合わせることが重要です。

1. ゴールが曖昧だと、作業の無駄が発生する

要件定義書の構成が決まっていない状態で要件定義作業を始めると、「何をどこまで書けばよいのか」が不明確になり、手戻りや重複作業が発生します。結果として、プロジェクトの遅延やコスト増につながります。

• 作成者の迷いをなくす: 構成が明確であれば、要件定義担当者は「何をどこに書くべきか」で迷うことなく、要件定義作業に集中できます。これにより、要件定義書の作成効率が大幅に向上します。
• 手戻りの削減: 作成途中で構成が変更されると、既に書いた内容の移動や修正、再構成が必要となり、大きな手戻りが発生します。早期に合意することで、このような無駄な作業を避けることができます。

1. コミュニケーションが円滑になる

• 共通認識の形成: 関係者(顧客、開発者、テスト担当者、運用担当者など)が、要件定義書がどのような情報を、どのような順序で提供するのかを事前に理解できます。これにより、レビュー時の議論がスムーズになり、認識のずれを防ぎます。
• レビュー効率の向上: レビューアは、どこに何が書かれているかを把握しているため、効率的にレビューを進めることができます。また、レビューの観点も構成に沿って明確化しやすくなります。

3. 進捗管理がしやすくなる

• 見積もり精度向上: 各セクションの作成にかかる工数をより具体的に見積もることが可能になり、プロジェクト計画の精度が向上します。
• 進捗状況が把握しやすい: 構成項目ごとに作成状況を管理できるため、要件定義フェーズの進捗をより正確に把握できます。

4. 品質の担保

• 網羅性の確保: 必要な項目が事前に定義されていれば、要件定義内容の抜け漏れを防ぐことができます。特に、非機能要件や運用・保守に関する項目など、見落とされがちな重要な要素を確実に盛り込めます。
• 一貫性の維持: 複数の要件定義担当者が関わる場合でも、統一された構成に従うことで、文書全体の一貫性を保ち、品質を安定させることができます。

要件定義書の構成は、大項目レベル(章レベル)までを事前に決定し、関係者で合意を得ることを推奨します。中項目以下の詳細構成は、要件定義作業の進行に合わせて柔軟に調整することができます。

ただし、プロジェクトの規模や複雑度によっては、より詳細な構成まで事前に定義する必要がある場合もあります。重要なのは、「何を記載するか」という要件定義書の全体像を、作業開始前に明確にしておくことです。

要件定義書の構成を決定する際は、以下のステップで行うことを推奨します。

1. システム開発の重心を決める:
   • 開発するシステムが SoR/SoE どちらに重心を置くか判断します。
     • 📄システム開発の重心を定める を参照してください。
2. ベースとなる成果物テンプレートをリストアップし、取得する:
   • 1 で決めた重心(SoR/SoE) に応じて、カスタマイズのベースとなる成果物テンプレートを取得します。
     • 🚫 Post not found の章を参照してください。
     • すべてのテンプレートは 📄テンプレート集 で閲覧・取得できます。
3. プロジェクト特性に合わせてテーラリングする:
   • プロジェクトの規模、顧客の要望、納期等制約などを考慮し、テンプレートをカスタマイズします。
     • 📄要件定義書の構成を決める を参照してください。
4. 関係者と合意する:
   • 構成案を顧客側承認者、開発側責任者、テスト担当者などと共有し、レビューを実施します。必要に応じて修正を加えます。
   • 最終的に要件定義書の構成として顧客と合意します。

テンプレートをそのまま使用せず、必ずテーラリング（カスタマイズ）してください。

標準テンプレートは、多くのプロジェクトに対応できる汎用的な構成ですが、完全に適合するわけではありません。プロジェクトの特性や制約に応じて、テンプレートをカスタマイズする必要があります。

以下に、テーラリングを行う際の主な指針を示します。

要件定義工程の成果物テンプレートは、SoR 向け、SoE 向け、共通の3種類に分類されています。(「SoR 向け」は「SoR 専用」ではなく、「主に SoR で作成する」という意味です)

重心が SoR 寄りであれば 「共通 + SoR 向け」を重点的に、SoE 寄りなら「共通 + SoE 向け」を重点的にそろえるとよいでしょう。

要件定義書には、その章構成や記載内容、表現について品質基準となる完成条件が定められています。
完成条件は相応の理由がない限り、遵守しなければなりません。

📄要件定義書の完成条件

プロジェクトには納期や予算などの制約が多々あります。そのため理想的な成果物を構成することは非常に困難です。成果物の構成は制約と折り合いをつける必要があります。

制約は原因によって強弱が異なります。弱い制約なら交渉によって緩和を目指すことも考慮してください。

次のページ → 📄要件定義のプロセスを設計する