BOTTIS
Why支援領域対応範囲 シナリオ発信FAQ お問い合わせ

なぜPJは"会議ばかり増える状態"に陥るのか。

停滞しているプロジェクトに入ると、最初に目に入るのは「会議の数」です。 しかし、会議を減らしても問題は解決しません。原因は会議の数ではなく、 会議の中で「何を決めるか」が定義されていないことにあります。

停滞しているプロジェクトほど、会議が増えます。しかしそれは「コミュニケーション不足」ではなく、 会議という場で何を決めるべきかが定まっていないことの現れです。

新しいプロジェクトに入ると、最初に必ず尋ねる質問があります。 「この会議は、何を決めるための会議ですか」——これに即答できるプロジェクトは、 実は多くありません。ほとんどの停滞プロジェクトで、定例会議は 「とりあえず集まって進捗を確認する場」になっています。

そしてその「進捗確認」は、具体的には何をしているのかというと、 各担当者が現状を報告し、誰も決めずに次回へ持ち越される——という繰り返しです。 会議は増えるのに、意思決定は進まない。これが「会議ばかり増える状態」の正体です。

「コミュニケーション不足」という誤診断

停滞の原因として最も多く聞く診断は「コミュニケーションが足りていない」です。 そしてその対策として選ばれるのが、会議の追加、情報共有会の開催、 チャットツールの導入といった「伝達量を増やす」施策です。

しかし、情報が流れていないから停滞しているのではありません。 流れてきた情報をもとに、誰が何を判断すべきかが決まっていないのです。 いくら情報を増やしても、判断の置き場所がなければ、溜まっていくだけです。

停滞プロジェクトの本当の問題は、情報量ではなく、判断量の不足である。

論点設計の3レイヤー

会議を「判断ができる場」に変えるには、そこで扱う論点の種類を分けることから始めます。 BOTTISが現場で使っているのは、以下の3レイヤーです。

レイヤー1 — 事実確認

「今どうなっているか」の共有。これは本来、会議でやる必要はありません。 ドキュメントやダッシュボードで非同期に行えるものです。 会議で時間を使ってしまっている場合は、事前共有に移すだけで会議が半分になります。

レイヤー2 — 方針選定

「複数ある選択肢のうち、どれを選ぶか」の議論。 これは会議で扱う価値がある論点です。ただし、選択肢が整理されていない状態で 会議に持ち込むと、選択肢を作る作業から始まってしまい、決まりません。 選択肢は事前に整理してから会議に持ち込むのが鉄則です。

レイヤー3 — 承認

「議論の結果を、正式に決定する」場。これは短時間で済みます。 承認者がその場にいるか、いないなら持ち帰り判断の期限を決めて終わります。 承認レイヤーが曖昧なまま方針選定レイヤーで議論し続けると、 「議論はしたけど何も決まっていない」状態になります。

意思決定の置き場所

論点を3レイヤーに分けたら、次は「それぞれをどこで扱うか」を決めます。 ここでよく混同されるのが、会議で扱うべきものと、非同期で扱うべきもの の境界線です。

  1. 事実確認 → 非同期(ドキュメント / チャット)
  2. 方針選定 → 会議(ただし選択肢を事前に整理)
  3. 承認 → 非同期 or 会議末尾(期限付き)

この分類をするだけで、ほとんどのプロジェクトで会議時間は半分以下になります。 なぜなら「会議でやる必要のないこと」を、慣性で会議に持ち込んでいたからです。

立て直しの順序

停滞したプロジェクトの会議を立て直す場合、次の順序で進めます。

  1. 現在開催されている全会議を棚卸しする
  2. 各会議で扱われている論点を3レイヤーに分類する
  3. それぞれの論点の「決定者」を明確化する
  4. 事実確認レイヤーは非同期に移す
  5. 残った会議のAgendaを「方針選定」「承認」で再設計する

BOTTISがPMO支援に入るとき、最初の2週間はだいたいこの作業に費やされます。 華やかさはありませんが、この作業を経たあとの会議は、別物のように動き始めます。


会議が多いこと自体は、悪ではありません。問題なのは、会議の中で判断が起きないことです。 判断が起きる会議は、たとえ多くても、参加者に疲労感を残しません。 むしろ「次に何をすべきか」が明確になって終わるからです。

もし今、プロジェクトが会議ばかりで進まないと感じているなら、 会議を減らすことから始めるのではなく、 「この会議で何を決めるのか」を一つずつ書き出すところから始めてみてください。 それだけで見えるものが変わります。