「担当者は〇〇さんですが、決定は上長に確認してから……」
受託開発でこのやりとりが繰り返される案件は、判断のたびに止まります。誰が何を決めるか決まっていないまま進むと、定例のたびに持ち帰りが発生し、翌週には「まだ確認中です」という状況になります。
意思決定ルールは、プロジェクトが始まってから整えるのでは遅いです。案件開始のキックオフ、遅くとも最初の数週間で合意しておくことで、その後の止まり方が大きく変わります。ステークホルダーの整理とは別の話で、「誰がいつまでに何を決めるか」という運用ルールです。
意思決定ルールがない案件で起きること
ルールがないと、次のような状況が連鎖します。
「担当者は分かったと言っている。でも上長の確認が必要らしく、翌週の定例で聞いてみます」「翌週の定例では上長が不在で、再来週に持ち越し」「再来週は別の案件の判断が優先されてまた持ち越し」——。
これは誰が悪いわけでもありません。顧客側の組織に判断フローがあるのは当然です。問題は、PMがそのフローを事前に把握していないことです。把握していれば、最初から上長確認のある判断は1週間余分に見込んでおけます。
決めること1：意思決定者
案件内で発生する判断の種類ごとに、誰が決裁者かを確認します。
仕様の変更・追加要望の承認・リスク対応の方針は、担当者が決められるのか、部長承認が必要なのか、役員に上げるものかによって、対応にかかる時間が変わります。
全部聞く必要はありません。最初に「機能の追加・変更について最終判断をされるのは誰ですか？」「費用が発生する変更の場合はどなたに確認が必要ですか？」の2点を確認しておけば、多くの場面をカバーできます。
決めること2：判断期限
判断を求めるときに「期限はありますか？」ではなく、最初から「このプロジェクトでは、確認依頼に対して〇営業日以内に返答をいただく約束にしたいです」という形で合意します。
目安は3〜5営業日です。急ぎのものは別途個別に依頼するとして、通常の確認依頼の返答期限をルールとして持っておくだけで、運用が安定します。
決めること3：持ち帰り時の扱い
顧客が持ち帰った場合に、何日以内に返答するかを決めます。また「返答がない場合はどうするか」を事前に合意しておきます。
「〇日以内に返答がない場合は、保留中の扱いとしてスケジュールに影響が出ます」という形で、持ち帰りの扱いをプロジェクト内ルールとして持っておくと、督促がしやすくなります。
決めること4：変更時の再合意
仕様変更や追加要望が発生したとき、それを誰がどのように承認するかを決めます。「口頭でOKをもらえたら進める」のか「書面承認が必要」のかを事前に整理しておくと、後の「言った言わない」を防げます。
変更管理の正式フローを作る必要はありません。「メール承認でよいか」「議事録に記載して次回定例で確認するか」という程度の取り決めで十分です。
キックオフで確認する質問
次の4問をキックオフまたは最初の定例会で確認しておきます。
- 「機能の変更・追加についての最終判断は誰がされますか？」
- 「確認依頼への返答には、通常どれくらいかかりますか？」
- 「持ち帰り確認の場合、何営業日を目安にご返答いただけますか？」
- 「変更の合意はメールでよいですか、それとも別途書面が必要ですか？」
すべて自然な質問として聞けます。「意思決定ルールを決めさせてください」と改まって切り出す必要はありません。
意思決定ルールの合意表
キックオフや初期フェーズで、以下のような表を使って合意内容を整理しておくと、後から参照しやすくなります。
| 判断カテゴリ | 主な判断内容 | 一次窓口 | 最終判断者 | 標準回答期限 | 合意の残し方 |
|---|---|---|---|---|---|
| 仕様変更 | 機能の追加・変更・削除 | 田中担当 | 鈴木部長 | 3営業日 | メール回答＋議事録記載 |
| 追加要望 | スコープ外の新規要件 | 田中担当 | 鈴木部長 | 3営業日 | 変更依頼書（メール可） |
| 費用・工数が変わる変更 | 追加費用・工数が発生する変更 | 田中担当 | 経理部門確認後に承認 | 1週間 | 書面または書面に準ずるもの（扱いは契約内容・社内ルールに従い、必要に応じて法務・契約担当に確認） |
| リリース判断 | リリース可否・日程変更 | 田中担当 | 鈴木部長 | 3営業日 | 議事録記載 |
| 障害・品質問題 | 重大バグ・品質問題への対応方針 | 田中担当 | 鈴木部長（緊急時は電話） | 当日〜翌営業日 | メール確認 |
| 優先順位変更 | 作業優先順位の入替え | 田中担当 | 田中担当（部長承認不要） | 2営業日 | 議事録記載 |
この表はあくまで例です。判断者の名前・期限・合意の方法は、個別の契約や社内ルールに従って決めてください。「書面が必要かどうか」などの正式な扱いは、個別の契約内容を確認してから設定することをお勧めします。
決めておくと後で効くルール
意思決定者・期限の合意に加えて、以下の運用ルールも最初に整えておくと、後のトラブルを減らせます。
- 口頭合意を議事録に残す：「〇〇でいきましょう」という口頭確認は、議事録やメールで「本日の確認通り、〇〇で進めます」と一言残しておく
- 判断期限を過ぎた場合の扱い：「回答なし＝承認」にするか「回答なし＝保留継続」にするかを最初に合意する
- 代理判断者の有無：意思決定者が不在の場合に誰が判断できるかを確認しておく
- 追加費用が発生しそうな場合の確認ルート：「費用が発生しそうな変更は、まず確認してから見積提出する」ことを事前に合意しておく
- 緊急時の連絡経路：障害発生など急を要する場合に誰に・どの手段で連絡するかを決めておく
これらは「ルール化する」というより、「最初の定例で自然に確認する」程度で十分です。全部をフォーマルに文書化しようとすると、顧客側の負担になることもあります。
キックオフでの自然な聞き方
「意思決定ルールを決めさせてください」と改まって切り出さなくても、定例や初回ヒアリングの流れで確認できます。
仕様変更に関する確認
「仕様変更が発生した場合、まず田中さんにご確認し、費用や納期に影響する場合は鈴木部長のご承認が必要、という理解でよろしいでしょうか」
判断期限に関する確認
「確認事項をお送りした際、通常どのくらいの期間で回答いただけますか？目安を知っておくと、スケジュール管理がしやすくなります」
緊急時の連絡先確認
「緊急のご連絡が必要な場合は、田中さんにメール＋電話という形でよいでしょうか。他に連絡すべき方はいらっしゃいますか？」
このように、プロジェクトの実務に即した質問として聞くと、顧客側も答えやすくなります。
まとめ
意思決定ルールは、案件が走り出してから整えるのでは遅く、始める前か始めた直後に合意するものです。
決裁者・判断期限・持ち帰り時の扱い・変更時の再合意の4点を整理しておくだけで、その後の顧客確認待ちが大幅に減ります。「確認します」で止まる頻度が下がれば、PMが督促に時間を使う量も減ります。
案件立ち上げの実務力や受託開発PMスキルを学びたい方は、受託開発PM向けの課題別パックや新任PM向けパックをご覧ください。