結論：クライアント社内に複数の意思決定者がいる案件は、決定権者マップの作成・段階的な承認プロセス設計・窓口担当者の集約責任合意・意見対立時の解決パターン、の 4 点で進行リスクを抑える。
「先日のデザイン案、社内で確認したところ部長から修正要望が出まして…」
窓口担当者から「いい感じです」と OK をもらって進めた案件が、後から部長や役員クラスで覆される。制作会社で頻繁に発生する状況です。
クライアントの組織が大きくなるほど、案件に関わる意思決定者の数が増えます。広告キャンペーンなら宣伝部・マーケ部・法務、Web リニューアルなら情シス・広報・経営、ブランディングなら経営層全員。それぞれに発言権があって、それぞれの視点で評価される。
この記事は、クライアント社内に複数の意思決定者がいる案件を、進行リスクを抑えながら進める方法を解説します。
複数意思決定者がいると何が起きるか
意思決定者が複数いる案件で、制作側に発生する問題は 4 つに分類できます。
1 つ目は、後段の覆り。担当窓口の承認で進めた作業が、上位レイヤーで覆される。手戻りが発生し、再制作のコストが利益率を削ります。
2 つ目は、意見の対立。複数の決定者が同時に違う方向の意見を出す。制作側がどちらに従うかで揺れている間に、時間と労力が浪費されます。
3 つ目は、承認の長期化。社内調整が必要な案件は、決裁プロセスが長い。制作側は「待ち」の状態で動けず、納期が圧迫されます。
4 つ目は、責任の所在の曖昧化。問題が発生したとき、誰の判断で進めたのか、誰が承認したのか、これが曖昧だと制作側に責任が押し付けられがちです。
これらをどう緩和するかが、複数意思決定者案件の運営の核心です。
意思決定の構造を最初にマッピングする
キックオフ時に、クライアント社内の意思決定構造を聞き出します。確認すべき項目：
- 窓口担当者は誰か（日常のコミュニケーション役）
- 担当者の判断で進められる範囲はどこまでか
- 担当者を超える決裁が必要なのはどんな判断か
- その場合の決裁者は誰か（部長・役員・複数）
- 関連部署（法務・広報・経営）のチェックが必要か
- 緊急時の判断権者は誰か
これを「決定権者マップ」というタスクとしてタスク管理ツールに記録します。コメント欄に：
窓口：A 部長代理（日常コミュニケーション、軽微な判断）
担当判断：デザインの色味調整、テキストの軽微な修正
上司承認必要：デザインの方向性変更、メッセージの大幅変更
最終決裁：B 部長（公開判断、契約金額変更）
法務確認：個人情報を含む機能の実装時のみ、C 法務マネージャー
緊急判断：A 部長代理が窓口、不在時は B 部長このタスクを案件中いつでも参照できる状態にしておくと、判断の局面で「これは A さんで足りる？それとも B 部長まで？」が即答できます。
窓口担当者の集約責任を取り付ける
最も重要なのは、クライアント側で意見集約をしてもらう運用にすることです。
制作側が複数の決定者から並列に意見を受け取って吸収するのは、構造的に無理があります。A さんの要望と B 部長の要望が矛盾する場合、どちらに従うかを制作側が判断できる立場にない。
キックオフで合意を取る項目：
- 制作側との連絡は窓口担当者に一本化する
- クライアント社内の意見対立は、窓口担当者が調整してから 1 つの依頼として伝える
- 矛盾する指示が制作側に届いた場合、制作側は確認のために作業を一時停止する権利を持つ
この合意があると、制作側は「A さんから X、B さんから X とは反対の要望が届いていますが、社内で調整いただけますか」と差し戻せます。差し戻しが気まずくない関係性を、キックオフで作っておくのが鍵です。
段階的な承認プロセスを設計する
判断の重みに応じて、段階的な承認プロセスを設計します。
軽い判断（テキストの軽微修正、色味の調整）：
- 窓口担当者の OK で進める
- タスクのコメントに「A さん承認」を記録
中程度の判断（デザイン方向性、機能要件の変更）：
- 窓口担当者 → 上司（部長）の 2 段階承認
- タスクのチェックリストで「担当承認」「上司承認」を別々にチェック
重い判断（契約金額の変更、公開タイミングの確定、法務要件）：
- 窓口担当者 → 上司 → 必要な部署 → 最終決裁者
- サブタスクで各段階を独立管理
軽い判断まで全部に重い承認プロセスをかけると、案件が前に進まなくなります。逆に、重い判断を担当承認だけで進めると、後段の覆りリスクが上がる。判断の重みに応じた階層化が必要です。
意見が割れたときの解決パターン
それでも意見が割れる場面は発生します。一般的な解決パターンが 3 つあります。
パターン 1：両案の制作と比較。意見が割れている部分について、両案を作って並べる。クライアント社内で「並べて見れば判断できる」というケースで有効。ただし制作コストが倍になるので、軽微な部分に限定。
パターン 2：制作側の専門判断を提示。「我々の経験上、A 案の方がユーザー反応が良い傾向があります。理由は…」と専門知見を提示して、クライアントの判断を支援する。決定権はクライアントにあるが、根拠を提示することで意思決定を促進。
パターン 3：意思決定の保留化。意見が割れたままでは進めず、クライアント側の社内調整を待つ。納期に影響が出る場合は「いつまでに調整が完了しないと、納期に X 日の遅延が発生します」と影響を可視化。
パターン 3 が最も健全ですが、制作側の利益にも影響するので、3 段階のエスカレーション基準を最初に決めておくのが現実的です。
制作側のスタンス：判断の押し付け合いを避ける
複数意思決定者案件で陥りがちなのは、制作側が「クライアントが決めてくれない」と内心責任を押し付ける状態です。逆に、クライアント側が「制作側が判断してくれない」と感じる状態も発生します。
これは判断の押し付け合いになっていて、健全な関係性ではありません。
制作側のスタンスは：「我々はプロとしての提案と専門判断を提供する。意思決定の最終責任はクライアントにある。意思決定プロセスを進めやすくするための仕組みは、我々が設計する」が基本です。
意思決定マップを作るのも、段階的承認を設計するのも、意見集約の責任を窓口に置くのも、すべて「クライアントが意思決定しやすい環境を制作側が整える」という考え方です。
この役割分担が明確だと、お互いに無理がない関係で長期的に組めます。
大規模クライアントとの長期関係への投資
複数意思決定者がいる案件は、ほぼ例外なく大規模クライアントです。中小企業より社内決裁プロセスが複雑なのは、組織が大きいからです。
これらのクライアントとの長期関係は、制作会社にとって最も価値の高い資産です。1 件で終わらせず、メンテナンス契約・追加案件・他部署への横展開、と関係を広げていく価値があります。
最初の 1 件で複数意思決定者の構造に向き合って、健全な進め方の仕組みを作っておくと、2 件目以降は同じ枠組みで動ける。この最初の投資が、長期関係のリターンを最大化します。
関連記事
キックオフでの合意項目は クライアントとのキックオフをタスク管理で仕組み化する、承認プロセスの設計は クライアント承認のフローをタスクに乗せる方法、修正のキャッチボール対策は デザインフェーズの「修正のキャッチボール」を減らす設計 を参照してください。
クライアントとの共有運用全体の設計は クライアントに進捗を見せる仕組みの作り方、外部メンバーとの仕事を回す全体像は 外部メンバーとのチームタスク管理 完全ガイド にまとめています。
Paqut で、複数意思決定者の案件を運営する
この記事で書いた意思決定マップ運用は、Paqut なら 3 ステップで立ち上がります。
- キックオフ時に「決定権者マップ」というタスクを作って役割をコメントで記録
- 窓口担当者・上司・最終決裁者・関連部署を全員、招待リンクで呼ぶ（追加料金 0 円）
- 各承認フェーズをチェックリストで段階管理し、「どこで止まっているか」を可視化
3 分で立ち上がります。