【目次】
・会議が増えるほど決められない“あるある”
・まず押さえる：会議体設計の3原則
・ステアリングコミッティの役割：方針と経営判断
・CCB（変更管理委員会）の役割：変更を裁く“関門”
・定例会議の役割：進捗を前に進める実務の場
・3会議のすみ分け早見表
・うまく回す運用ルール
・よくある失敗と立て直し方
・すぐ使えるテンプレ例
・まとめ

会議が増えるほど決められない“あるある”

プロジェクトで困りやすいのが、「会議はいっぱいあるのに、なぜか何も決まらない」状態です。マネジメント初学者の方ほど、会議を増やして情報共有を厚くすれば安心…と思いがちですが、実際は逆に“決める力”が薄まっていきます。

典型的な症状は次の通りです。

  • 同じ議題が別の会議で何度も再掲される（定例→ステコミ→定例…の無限ループ）
  • “相談”と“決裁”が混ざる（誰が決めるのか不明で保留）
  • 変更の判断が属人化する（声が大きい人の意見で決まる）
  • 会議ごとのアウトプットが曖昧（議事録はあるが、次のアクションが動かない）

原因はシンプルで、「会議体ごとの役割分担」が曖昧だからです。
会議の設計で重要なのは、議事録の綺麗さでも参加者の多さでもなく、“何をどこで決めるか”を固定すること。ここが決まると、会議は急に軽くなります。

まず押さえる：会議体設計の3原則

ステコミ、CCB、定例を設計するときは、難しいフレームワークよりも先に、以下の3つを必ず決めます。

原則1：何を決める会議か（決裁対象を定義）

会議は「話す場」ではなく「決める場」です。
だから最初に、会議ごとの決裁対象を定義します。

  • 方針を決めるのか（例：スコープ、優先度、予算、重要リスクへの対応）
  • 変更を決めるのか（例：仕様変更、納期変更、追加要望の採否）
  • 実務を前に進めるのか（例：課題解消、依存関係の調整、次週計画）

原則2：どこで決めるか（会議間の“エスカレーション線”）

同じテーマでも、レベルによって決める会議が変わります。
ここを曖昧にすると、「結局どの会議で決まるの？」が起きます。

  • 定例で解決できるなら定例で閉じる
  • 変更の採否はCCBに集約する
  • 経営判断やトレードオフはステコミへ上げる

原則3：誰が決めるか（責任者を1人に固定）

会議で決めるためには、最終的にYES/NOを言える人が必要です。
よくある失敗は「参加者全員で合意してから…」で、永遠に合意できないパターン。

そこで使いやすいのがRACIです。

  • A（Accountable）最終責任者：決定者（1人に固定）
  • R（Responsible）実行責任者：進める人（複数可）
  • C（Consulted）相談先：意見をもらう人
  • I（Informed）報告先：知らせる相手

会議体ごとに「Aは誰か」を固定するだけで、決定スピードが上がります。

ステアリングコミッティの役割：方針と経営判断

ステコミは一言でいうと、プロジェクトの“舵取り（ステアリング）”の意思決定をする場です。
現場の細かい課題を処理する場ではありません。

ステコミで決めること（決裁対象の例）

  • プロジェクトの目的・成功基準（何をもって成功か）
  • スコープの大きな変更（追加・削減の方針）
  • 優先順位のトレードオフ（品質・コスト・納期の意思決定）
  • 予算／体制／外部調達などの経営判断
  • 重大リスクへの対応（例：リリース延期判断、段階リリース方針）
  • 組織を跨ぐ調整（部門間の利害、意思統一）

ステコミに持ち込むべき論点（持ち込み条件）

定例で揉めている議題を、そのままステコミに持ち込むと混乱します。
ステコミに上げるときは、次の条件を満たす形にします。

  • すでに現場で選択肢が2〜3個に絞られている
  • それぞれのメリデメ（影響範囲、費用、納期、品質、リスク）が整理されている
  • 「決めてほしいこと」が一文で言える（例：A案で進めてよいか）

ステコミのアウトプット

  • 決定事項（方針・承認・却下）
  • 条件付き承認の条件（例：追加予算上限、適用範囲、期限）
  • 次回までの宿題（Aに紐づくアクション）

CCB（変更管理委員会）の役割：変更を裁く“関門”

CCBは Change Control Board。
役割は明確で、変更要求を“採択するか否か”決める関門です。

プロジェクトは、放っておくと必ず変更が流れ込みます。
CCBがないと、変更が静かに積み上がり、納期・品質・コストが壊れます。

CCBで決めること（決裁対象の例）

  • 仕様変更の採否（やる／やらない）
  • 変更の優先順位（どれから入れるか）
  • 変更に伴う計画修正（工数、納期、体制、品質計画）
  • 変更の適用範囲（今回リリースに入れる／次回に回す）
  • 代替案の選定（簡易対応、暫定回避、運用で吸収）

CCBの前提：変更票（Change Request）がない変更は審議しない

CCBが機能しない最大の原因は「口頭変更」です。
必ず、最低限この情報をセットにします。

  • 変更内容（何をどう変えるか）
  • 変更理由（なぜ必要か）
  • 影響（工数・費用・納期・品質・他機能・運用）
  • 代替案（やらない場合の影響、簡易案）
  • 希望期限（ビジネス都合）
  • 推奨案（提案者の結論）

CCBのアウトプット

  • 承認／却下／保留（保留条件を明確に）
  • 優先度と実施タイミング（今回／次回／バックログ）
  • 計画反映指示（WBS・スケジュール・見積更新）
  • 関係者への通知範囲（顧客、運用、テスト、教育）

定例会議の役割：進捗を前に進める実務の場

定例は、プロジェクト実務を前に進めるための会議です。
ここで大事なのは「共有」より「前進」。
“聞いて終わり”の定例は、時間だけ消費します。

定例で決めること（決裁対象の例）

  • 進捗状況の確認と、遅延への手当て
  • 課題の担当・期限の決定（誰がいつまでに）
  • 依存関係の調整（他チーム待ちをどう崩すか）
  • 次週計画・優先度の微調整（ステコミ級は除く）
  • リスクの早期検知（重大化しそうならエスカレーション）

定例で“決めない”こと

  • 大規模スコープの変更（→ステコミへ）
  • 仕様変更の採否（→CCBへ）
  • 部門間の利害調整が必要な政治案件（→ステコミへ）

定例で無理に決めようとすると、決めたつもりの“仮決め”が増え、後でひっくり返ります。

定例のアウトプット

  • 主要論点の結論（決めた／上げる／保留）
  • ToDo（担当・期限・成果物）
  • エスカレーション事項（どの会議に何を上げるか）

3会議のすみ分け早見表

ここが記事の中心です。迷ったらこの表に戻る、という形で運用するとよいです。

  • ステコミ：方向性と経営判断（目的・優先度・予算・重大リスク）
  • CCB：変更の採否（仕様変更・計画変更の関門）
  • 定例：日々の前進（進捗・課題・調整・次アクション）

判断のコツ：その決定は“戻せるか？”

  • 戻せる／影響が局所 → 定例
  • 戻せるが、変更が積み上がると危険 → CCB
  • 戻せない／全体の方向に影響 → ステコミ

うまく回す運用ルール

会議体は作って終わりではなく、運用ルールで決まります。おすすめの最低限ルールをまとめます。

ルール1：議題は「共有」と「意思決定」に分ける

議題タイトルにタグを付けるだけで会議が締まります。

  • 【決裁】～を承認してほしい
  • 【相談】～について選択肢A/Bの意見がほしい
  • 【共有】～の状況報告（※共有は原則、資料で読める形に）

会議時間は「決裁」と「相談」に使い、「共有」は資料で短縮します。

ルール2：決裁議題は“結論ファーストの1枚”を必須にする

決裁者が判断できない資料は、会議を長引かせます。
1枚に入れるべきはこの6点です。

  1. 決めたいこと（YES/NO）
  2. 背景
  3. 選択肢（2〜3）
  4. 比較（コスト・納期・品質・リスク）
  5. 推奨案
  6. 決めない場合の影響

ルール3：承認の定義（何をもって承認か）を固定する

  • 承認＝議事録に残した時点で確定
  • 条件付き承認＝条件が満たされたら自動で確定（再審議しない）
  • 保留＝次回の判断材料が揃うまで決めない（宿題を定義）

ルール4：例外ルート（緊急変更）を決めておく

障害対応や法令対応など、CCBを待てないケースもあります。
その場合は「緊急承認ルート」を事前に定義します。

  • 緊急承認の条件（例：サービス停止、法令違反、重大セキュリティ）
  • 代替承認者（A不在時の代理）
  • 事後にCCBへ報告し、記録と計画反映を必ず行う

“緊急だから”でルールを破るのではなく、緊急用のルールを用意します。

よくある失敗と立て直し方

失敗1：ステコミが課題消化会議になる

症状：課題一覧の読み上げで時間切れ。
立て直し：ステコミの議題を「方針・トレードオフ・重大リスク」に限定。課題は定例に戻し、ステコミには「支援が必要な課題」だけ上げる。

失敗2：CCBが形骸化して“口頭変更”が横行

症状：「ついでにこれも」からスコープ膨張。
立て直し：変更票がないものは受けない運用に戻す。テンプレを軽量化し、提出障壁を下げる（ただし必要情報は削らない）。

失敗3：定例が“共有会”になって前進しない

症状：報告で終わり、決めるべきことが残る。
立て直し：定例の議題を「論点→結論→ToDo」に固定。共有は事前配布の資料に寄せ、会議では論点処理だけする。

すぐ使えるテンプレ例

ここでは、記事内でそのままコピペできる形で例を示します。

9-1. 議題テンプレ（会議共通）

  • 議題名：【決裁／相談／共有】○○
  • 決めたいこと（結論）：
  • 背景：
  • 選択肢：A / B / C
  • 影響（コスト・納期・品質・リスク）：
  • 推奨案：
  • 参加依頼（A/R/C/I）：

9-2. 変更票テンプレ（CCB用）

  • 変更ID：
  • 変更内容：
  • 変更理由：
  • 影響範囲（機能・画面・運用・テスト）：
  • 工数・費用見積：
  • 納期影響：
  • 品質影響・リスク：
  • 代替案：
  • 推奨案：
  • 希望期限：
  • 承認結果（承認／却下／保留）：

9-3. ステコミ用 1枚サマリ（例）

  • 今日決めたいこと：○○をA案で進めてよいか
  • 重要背景：
  • 選択肢比較（表）：
  • 推奨案と理由：
  • 追加で必要な支援：予算／人員／他部門調整
  • 決めない場合の影響：

まとめ

ステコミ／CCB／定例の役割分担が曖昧だと、会議は増えるのに意思決定が進まず、変更が雪だるま式に膨らんでプロジェクトが苦しくなります。立て直しのポイントは、「何をどこで決めるか」「誰が決めるか（Aを1人に固定）」を先に決めることです。
ステコミは方針と経営判断、CCBは変更の採否、定例は実務の前進。さらに議題のタグ付け、決裁1枚サマリ、変更票、緊急ルートの整備まで揃えると、会議体は“増やすもの”から“軽くする仕組み”に変わります。