合意・承認手続き

要件定義書を完成させたら、最終的にプロジェクトのステークホルダーから正式な合意や承認を得るプロセスが必要です。ここで合意を得ていないと、後になって「そんな要件は聞いていない」「予算や納期に収まらない」といったトラブルの原因にもなります。
承認手続きは会社や組織によって異なる場合がありますが、基本的な承認フローの考え方と演習での実践方法を説明します。

8.1 シナリオ設定

1. ステークホルダーの合意形成
   • サロンオーナーや店長、スタッフ代表など、開発側と利用側の主要関係者が、要件定義書の最終版に目を通し、内容を理解・承認する。
   • 経営層・管理部門・関連部門など、社内外の承認プロセスが存在する場合は、そのステップも確認が必要。
2. 契約や発注の手続き
   • 要件定義の結果をベースに、開発費用やスケジュールの見積もりを行い、正式に契約を結ぶケースが多い。
   • 必要に応じて追加契約書や覚書を作成するなど、ビジネス上の手続きに反映させる。

8.2 演習タスク

1. プレゼンテーション（ロールプレイ）
   • 新入社員に要件定義書の内容を関係者にわかりやすく説明するプレゼンを実施させる。
   • 「要件の背景」「システム導入による効果」「費用対効果（概算）」など、ビジネス寄りのアピールポイントを整理。
   • 実際に顧客役や経営者役から質問を受け、回答・交渉の練習を行う。
2. 承認フローの確認
   • どのような順序で、誰に承認をもらうかを一覧化する。
   • 例：
     1. サロン店長（現場責任者）
     2. サロンオーナー（経営者）
     3. 開発会社のプロジェクトマネージャー
     4. 契約・稟議書の最終承認（経営企画部や法務部など）
3. 合意形成に向けた調整
   • レビューで上がった要望や予算面の条件を再度要件定義書に反映するなど、最終的なすり合わせを実施。
   • 重要な変更が発生した場合は、要件定義書を再改版して差分をわかりやすく提示する。
4. 承認書類／議事録の作成
   • 公式な合意の証拠として、要件定義書の承認欄に署名・捺印する方法や、別途承認書を作成する方法を想定。
   • 承認ミーティングの議事録を作成し、メールやドキュメント管理システムで全員に共有する。

8.3 成果物

1. 最終合意された要件定義書
   • 必要な署名や捺印が揃っている正式なドキュメント。
   • 変更履歴・承認履歴が明確に管理されている。
2. 承認の証跡（議事録、承認書など）
   • 合意内容や承認日時、承認者名などを記録し、後からでも「いつ、誰が、どの内容に合意したか」を追えるようにしておく。
   • 電子契約や電子サインシステムを利用する場合も同様に記録を残す。

8.4 ポイント

• 正式な合意前に開発を進めない: 合意が曖昧なまま開発を開始すると、仕様の変更要求が頻発し、コスト・スケジュールが大幅にズレるリスクが高い。
• コミュニケーションを欠かさない: 要件に変更や追加が必要になった場合、すぐに関係者間で共有し、文書化・再承認を得るルールを作る。
• 契約・稟議フローを把握する: 特に社内制度が複雑な場合、稟議書のフォーマットや承認者の順番を早めに把握しておくとスムーズ。
• 「後出し要件」への対処: 合意後に新たな要望が出た場合、対応可否や影響範囲を改めて見積もり、追加費用やスケジュールを提示するなど、明確な手順を決めておく。

このステップでは、新入社員に対して**「合意を取ること」「承認を得ること」がいかに重要かを強調し、実際の業務で起こり得る調整や交渉を体験させます。
最終的に要件定義書が公式に承認されることで、プロジェクトのゴールとスコープが全関係者に共有・確定**され、次の工程（基本設計・詳細設計など）へ安心して進められるようになります。