「順調です」で埋まる進捗会議の正体
毎週の進捗会議で、各チームリーダーが順番に「予定通り進んでいます」「特に問題ありません」と報告する。PLは「分かりました」とうなずき、1時間が過ぎる。翌週、突然「テストで重大な不具合が見つかりました」という報告が上がる——この経験をしたPLは多いのではないだろうか。
「順調です」という報告は、多くの場合、3つのうちのどれかだ。本当に順調か、問題はあるが報告するほどではないと判断しているか、問題に気づいていないか。PLにとって怖いのは後者の2つであり、進捗会議の本来の目的は、この「見えていない問題」を引き出し、チームとして対処することにある。
本記事では、進捗会議を「報告の受け渡し」から「課題の発見と意思決定の場」に転換するための設計手法を紹介する。なお、サンプルはIT開発プロジェクトの週次定例（60分・5〜10人）を想定しているが、考え方は業種・規模を問わず応用できる。少人数チーム（3〜4人）の朝会への応用についても本記事で触れる。大規模プロジェクト（30人超）の会議体系や、ステアリングコミッティの運営については、シリーズ後半で別途取り上げる予定だ。
進捗会議の構造を変える：3つのフェーズ設計
多くの進捗会議が報告会になる原因は、会議の構造が「報告→質疑→次回」の一本道になっていることだ。この構造を以下の3フェーズに変える。
- 状況共有（10分）：事前に共有済みの進捗を「確認」する。報告は最小限に
- 課題抽出と議論（35分）：遅延・ブロッカー・リスクを洗い出し、対策を議論する
- 意思決定とアクション確定（15分）：議論の結果を決定事項とアクションに落とす
ポイントは、フェーズ1（状況共有）の時間を極限まで短くし、フェーズ2（課題の議論）に大半の時間を使うことだ。「何が起きているか」の共有に30分かけ、「どうするか」の議論に10分しか使わない会議は、構造的に失敗している。
なお、この構造変更をPL単独で実行できるとは限らない。PMや上位ステークホルダーが進捗会議に同席し、従来型の報告を求めている場合もある。その場合は、上位への報告は議事録やサマリーで別途行い、「会議そのものは課題解決に集中する」という棲み分けをPMと事前に合意しておく。PMOが定型フォーマットでの報告を義務付けている場合も、事前記入のテンプレートでPMO向けの報告を兼ねる設計にすれば、二重作業を避けられる。
フェーズ1：状況共有を最小化する仕組み
進捗報告を会議中に一から行うのは時間の無駄だ。会議の前に情報を共有し、会議中は「確認」と「差分」に集中する。
サンプル：事前共有のテンプレート
会議の前日（または当日朝）までに、各チームリーダーが以下のテンプレートを埋めて共有ドキュメントに記入する。
進捗報告テンプレート（事前記入）
チーム名：バックエンド開発
今週の完了タスク：ユーザー認証API、DB設計レビュー
来週の予定タスク：顧客検索API、テストデータ作成
進捗状況：● 予定通り / ● やや遅れ / ● 遅延・ブロッカーあり
課題・懸念（あれば）：テストデータの仕様が未確定。フロントエンドチームとの認証連携の仕様すり合わせが未実施。
会議冒頭では、PLが「事前共有を見ました。赤信号・黄信号のチームはありますか」と問いかけるだけでよい。全チームが青信号であれば状況共有は2分で終わる。黄信号・赤信号のチームだけが補足説明を行い、フェーズ2の議論に移る。
この仕組みが機能するには、事前記入を定着させるルールが必要だ。ルールなしだと、記入する人としない人が出てきて、結局会議中に報告し直す羽目になる。ただし、「記入しないと会議に参加できない」という強いルールが使えない場面もある。協力会社のメンバーにPLが強制力を持てない場合や、マルチプロジェクトで多忙なメンバーが「書く時間がない」と感じている場合だ。そうした状況では、記入のハードルを下げる工夫から始めるとよい。箇条書き3行で十分とする、PLが会議前に5分だけ個別チャットで聞き取って代筆する、といった段階的な導入アプローチが現実的だ。
少人数チームの場合：朝会との連携
3〜4人のチームで毎日朝会（スタンドアップ）を行っている場合、週次の進捗会議自体が不要なこともある。朝会で日々の課題が解消されているなら、週次は「朝会で解消できなかった中長期の課題」だけを扱う30分のミニ定例に縮小するとよい。会議の数と時間を減らすこと自体が、チームの生産性向上につながる。
フェーズ2：課題を引き出す5つの問いかけ
進捗会議の核心は、このフェーズだ。「順調です」の裏に隠れている問題を引き出すために、PLは意識的に問いかけを行う必要がある。ただし、問いかけが機能する前提として、「正直に答えても不利益にならない」という心理的安全性が必要だ。遅延を報告すると責められる文化や、協力会社のメンバーが「問題を出すと評価が下がる」と感じている環境では、どんな問いかけも本音を引き出せない。PLにできることは、まず自分から困りごとを開示すること（「私もこの件でクライアントとの調整に苦戦している」など）、そして問題を早期に出してくれたことに感謝する姿勢を一貫して見せることだ。以下の5つの問いかけは、この土台の上で機能する。
問いかけ1：遅延の兆候を探る
「予定通り進んでいるとのことですが、今週のタスクで予定より時間がかかったものはありますか」
狙い：全体は予定通りでも、個別タスクに遅延の兆候がある場合がある。今週は吸収できても、来週以降に影響が出るリスクを早期に発見する。
問いかけ2：他チームとの依存関係を確認する
「来週のタスクで、他のチームからの成果物やレビューを待っているものはありますか」
狙い：チーム間の依存関係が原因のブロッカーは、報告者自身が「自分の問題ではない」と感じて報告しないことがある。PLが明示的に聞くことで表に出る。
問いかけ3：前提条件の変化を確認する
「先週時点の前提条件で変わったことはありますか。要件、環境、体制など」
狙い：前提の変化はじわじわと影響を広げる。「メンバーが1人体調不良で抜けた」「顧客から追加要望が出た」といった変化を会議の場で可視化する。
問いかけ4：来週のリスクを先読みする
「来週、予定通り進まない可能性があるタスクはどれですか」
狙い：過去の報告ではなく「未来のリスク」に目を向ける。問題が発生してから対処するのではなく、発生する前に手を打つ。
問いかけ5：PLの支援が必要なことを聞く
「PLとして私がやるべきこと、あるいは私が誰かに掛け合うべきことはありますか」
狙い：メンバーが「PLに相談していいのか分からない」と感じている問題を引き出す。PLの役割は進捗を「監視」することではなく、メンバーが前に進むための「障害を取り除く」ことだ。
5つすべてを毎回聞く必要はない。プロジェクトの状況に応じて2〜3個を選んで使う。フェーズ間の移行が遅い初期は問いかけ1と4、チーム間連携が増える中盤は問いかけ2と3、という使い分けが目安になる。
フェーズ3：意思決定とアクション確定
フェーズ2で洗い出した課題について、「誰が・何を・いつまでに」やるかを確定する。ここで決まらなかった課題は、パーキングロット（第3回参照）に入れて別途対応する。
サンプル：アクション確定のフレーズ
「今日の議論をまとめます。
・テストデータの仕様 → 田中さんがフロントチームと今週木曜までにすり合わせ
・認証連携の結合テスト日程 → 佐藤さんが来週月曜までに提案
・顧客追加要望の影響評価 → PLが顧客窓口の山田さんと明日調整
抜け漏れはありますか。——では、これで進めます。」
確定したアクションは、会議終了後すぐに議事録またはチケット管理ツールに登録する。口頭の合意だけでは「言った・言わない」が発生する。翌週の進捗会議冒頭で前回アクションの消化状況を確認する仕組みにすると、アクションの完遂率が上がる。
サンプル：進捗会議のアジェンダ（60分）
週次進捗会議 アジェンダ（60分）
ゴール：今週の課題を洗い出し、来週に向けたアクションを確定する
① 前回アクションの消化確認【共有】5分
→ 前回決めたアクションの完了/未完了を確認
② 進捗状況の確認【共有】10分
→ 事前記入の内容を確認。赤信号・黄信号の補足のみ
③ 課題・リスクの議論【相談/決定】30分
→ PLの問いかけで課題を引き出し、対策を議論
④ アクション確定・次回予告【決定】10分
→ 「誰が・何を・いつまでに」を確定
⑤ 予備枠 5分
経験談：進捗会議を変えた2つのケース
失敗談：報告を聞くだけで1時間を使い切っていた
10人体制のプロジェクトで、各チームリーダー4人がそれぞれ15分ずつ報告を行い、60分の会議が終わっていた。報告内容は「今週やったこと」の列挙で、PLの私は「分かりました」を繰り返すだけだった。問題はそこではない。報告が終わった後、課題について議論する時間がゼロだったのだ。
3週間後、テストチームから「環境のディスク容量が足りずテストが止まっている」という報告が上がった。調べると、2週間前の時点でディスクの逼迫が始まっていた。テストリーダーは「自分で対処できると思っていた」と言った。報告の場ではなく「課題を相談する場」として会議が設計されていれば、2週間前の段階でこの問題を拾えていたはずだ。
改善後：事前共有＋問いかけで会議が変わった
翌月から、進捗報告を事前記入に切り替え、会議の構造を3フェーズ設計に変更した。導入直後は順調ではなかった。「事前に書くのが面倒」という声があり、初回は4人中2人しか記入しなかった。問いかけに対しても最初の2回は沈黙が続き、PLの私が「正直に言うと、この件で私も困っている」と自分から切り出すことで、少しずつ発言が出るようになった。3回目あたりからメンバー自身が「書くことで頭が整理される」と感じるようになり、事前記入の定着率も上がった。
最も変化が大きかったのは、問いかけ2「他チームからの成果物を待っているものはありますか」を毎回聞くようにした点だ。この問いかけで「フロントチームがAPI仕様の確定を待っている」「インフラチームがテスト環境の構築を待っている」といったチーム間のブロッカーが毎週2〜3件浮上するようになった。以前はこれらが個別のチャットで断片的にやり取りされ、PLの耳に届かないまま遅延の原因になっていた。
ただし、問いかけが定型化すると、メンバーが「また同じ質問か」と感じて回答が形式的になるリスクもある。3か月目以降は、問いかけのパターンを変えたり、メンバーに「今週一番時間を使った問題は何でしたか」と自由度の高い質問を混ぜたりして、マンネリを防いでいる。
進捗会議の形骸化を防ぐ3つの仕組み
- 前回アクションの追跡：会議冒頭で前回のアクション消化を確認する。未完了のアクションは理由を聞き、次の期限を再設定する。確認をスキップすると「どうせ誰も見ていない」とアクションが放置される
- 四半期に1回、会議自体を振り返る：「この会議の何が役に立っているか。何が無駄に感じるか」をメンバーに問いかける。時間配分の見直し、アジェンダの改善、頻度の変更（週次→隔週）など、会議自体をアップデートする
- 会議を「減らす」判断を持つ：プロジェクトのフェーズによっては、週次が過剰になることもある。保守運用フェーズでは隔週や月次に変更し、課題が少ない時期は30分に短縮するなど、会議の存在意義を常に問い直す。「この会議がなくても回る」と判断できるなら、それはチームが成熟した証拠だ
まとめ：進捗会議は「報告を受ける場」ではなく「課題を解決する場」
進捗会議をPLとして設計する際のポイントは以下の通りだ。
- 3フェーズ設計（状況共有→課題抽出→アクション確定）で、報告に使う時間を最小化する
- 進捗報告は事前記入に切り替え、会議中は「確認と差分」に集中する
- 5つの問いかけで「順調です」の裏にある課題を引き出す
- アクションは「誰が・何を・いつまでに」を明確にし、翌週に消化確認する
- 四半期に1回、会議自体を見直して形骸化を防ぐ
まずは次の進捗会議で、事前記入のテンプレートを導入し、会議冒頭の問いかけを1つ変えるところから始めてみてほしい。
次回（第7回）は、振り返り会議で本音を引き出す仕掛けについて取り上げる。
