案件レビュー会議とは？進捗確認から採算判断へ変える方法

案件レビュー会議とは、案件の状態を点検し、続ける・組み替える・断るを決める会議体だ。だが多くのプロジェクトレビューや案件審査会議は、進捗を読み上げる報告会で終わっている。レビュー会議を機能させる鍵は、議題を「進捗の確認」から「採算の判断」へ組み替えることにある。

報告会と判断の場は、似て非なるものだ。報告会は「把握した」で終わる。判断の場は「決めた」で終わる。同じ「案件レビュー会議」という名前でも、出口がまったく違う。出口が報告のままだと、会議室には正確な数字が並ぶのに、誰も何も動かさないまま解散する。

この記事の要点

• 案件レビュー会議とは、案件を点検し続ける・組み替える・断るを決める会議体。本来は採算判断の場である。
• だが多くのプロジェクトレビューは進捗の報告会で終わり、数字を確認するだけで意思決定が下されない。
• 報告会のレビュー会議と採算判断のレビュー会議は、扱う数字も出口も別物。確定した進捗を共有するか、これから動く限界利益を決めるか。
• 採算判断のレビュー会議で見るべき議題を、そのまま使えるチェックリストにした。
• 最も効くレビューは受注前にある。受注後の進捗レビューでは、採算を動かす手はもう残らない。

なぜプロジェクトレビューは報告会で終わるのか

レビュー会議が報告会になるのは、参加者の怠慢ではない。会議に持ち込まれる材料が、報告しかできない性質のものだからだ。

定例に上がってくるのは、走り出した案件の進捗だ。原価が予算の何%に達したか、納期に対して工程がどこまで進んだか、要員は足りているか。いずれも確定した実績である。確定した数字に対してできるのは、把握と共有だけだ。色分けされたレポートを読み上げ、黄信号の案件に「注視しましょう」と添えて、次の議題へ移る。

問題は、その赤や黄が表示された時点で、採算はもう確定していることだ。原価が予算を超えてからでないと、超過は数字に出ない。進捗が赤を示した瞬間、その赤字は戻らない。進捗管理が事後の作業になる構造はPMOが炎上を止められないのは、無能だからではないに整理した。

報告会のレビュー会議は、終わった勝負の実況中継になる。実況をどれだけ精緻にしても、結果は変わらない。

レビュー会議が報告会から抜け出せないのは、扱う材料が「確定した過去」に偏っているからだ。判断の場にするには、材料を「これから動く採算」に入れ替える必要がある。

報告会のレビュー会議 vs 採算判断のレビュー会議

同じ「案件レビュー会議」でも、報告を共有する会議と採算を判断する会議は別物だ。何が違うかを並べる。

観点	報告会のレビュー会議	採算判断のレビュー会議
扱う数字	確定した進捗・実績	これから動く限界利益・採算
主な問い	今どこまで進んだか	この案件を続けるか・組み替えるか・断るか
開くタイミング	走り出した後の定例	受注前の提案フェーズと節目
参加者の役割	進捗を報告する	採算を根拠に決める
出口	把握した・注視する	意思決定する
残る価値	現在地の共有記録	受注可否・体制変更の決定

両者を分けるのは会議の長さでも参加者の役職でもない。会議が終わるときに、何かが決まっているかどうかだ。

報告の共有にも価値はある。チームが現在地を揃えるのは必要なことだ。だが「案件レビュー会議」という名前を冠した会議が報告だけで終わるなら、経営判断の場が1つ失われている。続けるか断るかを決める場が、別にどこにもなければ、その判断は誰のテーブルにも乗らないまま流れていく。

採算判断のレビュー会議で見るべきアジェンダ（チェックリスト）

報告会を採算判断の場に変えるには、議題を採算指標で組み直す。以下を、レビュー会議のアジェンダ・フォーマットにそのまま転記して使える。各議題は「報告して終わり」ではなく「決めて終わる」ことを前提にする。報告だけで判断を伴わない項目は、レビュー会議の議題から外し、別の共有の場に回す。

限界利益

• この案件の限界利益（売上 − 変動費）は、固定費回収に必要な下限を上回っているか。
• 受注前の見立てと現在の実績で、限界利益はどれだけ乖離しているか。
• 値引き要請や追加対応で、どこまで下げると下限を割るかを把握しているか。
• 決めること: このまま続けるか、単価・スコープを再交渉するか、見送るか。

体制原価

• 現在の編成のグレードミックスで、原価が当初設計より膨らんでいないか。
• シニア偏重・ジュニア偏重のどちらかに寄って、原価か成功確率を損なっていないか。
• 編成を組み替えると、限界利益はどう動くか。
• 決めること: 編成を維持するか、組み替えるか。

過負荷

• 今のエース依存が、残りフェーズの合算稼働でどこまで悪化するか。
• 関与メンバーの将来フェーズの合算稼働で、過負荷が発生していないか。
• 過負荷が離職・手戻りに転じる前に、配置を動かせるか。
• 決めること: 負荷を分散させるか、追加要員を当てるか。

残工程とリスク

• 残りの工程で、原価が予算を超過する見込みはないか。
• スコープが曖昧なまま走っている箇所、仕様が固まっていない箇所はないか。
• 残工程の最悪ケース原価で、ここから赤字へ転落する分岐点はどこか。
• 決めること: リスクを織り込んで続けるか、スコープを締め直すか。

受注可否（受注前レビューの場合）

• この案件を、自社の人材で利益を残して完遂できるか。
• 編成案を複数並べ、それぞれの原価と限界利益を弾いたか。
• 5議題のいずれかが満たせない場合、断るという選択肢を机に乗せたか。
• 決めること: 取る・条件付きで取る・見送るのいずれか。

受注前に案件を点検する5つの評価観点そのものはプロジェクト事前評価とは？受注前に見るスキル・体制・採算に詳しい。本記事のチェックリストは、その観点を「会議の議題」として運用するための形にしたものだ。

レビュー会議は、いつ開くと効くのか

レビュー会議の効き目は、開くタイミングで決まる。

走り出した後の進捗レビューは、現在地を揃える価値がある。だが採算を動かす手は、もうほとんど残っていない。案件の採算は受注を決めた瞬間にほぼ確定するからだ。赤字が見えた節目のレビューでできるのは、損失を最小化する火消しだけになる。

最も効くのは、受注前のレビューだ。提案フェーズで「この体制で組むと限界利益がいくら残るか」を会議の場で確かめれば、断る・組み替える・単価を交渉するという手がすべて残っている。受注前の解像度を引き上げる考え方はまるで未来から来たような解像度で、採算は受注前に設計できるに整理した。

評価を受注の前に置けば、レビュー会議の出口に「断る」が並ぶ。後に置けば、出口は「どう火を消すか」に狭まる。

つまり案件レビュー会議の設計とは、どの議題を見るかと同じくらい、どのタイミングで開くかの設計でもある。受注後の進捗レビューと、受注前の採算レビューを、別の会議体として持つ。前者で現在地を共有し、後者で採算を判断する。

レビュー会議を採算判断の場にする条件

ここまでを一文にすると、レビュー会議を機能させるとは、議題を採算指標で組み、出口を意思決定にし、受注前にも開くことだ。

だが議題を組み替えるだけでは足りない。会議の場で採算の数字が揃っていなければ、結局は報告の読み合わせに時間が溶ける。限界利益・体制原価・過負荷を、編成を動かすとどう変わるかも含めて一つの画面で見られる状態がいる。数字が揃って初めて、会議は「報告」から「判断」に変わる。

レビュー会議の議題を採算で組み、受注前から判断を下していく。これを案件ごとに積み重ねると、受注前に案件の採算を決める一連の意思決定になる。この考え方が採算設計だ。レビュー会議は、採算設計を組織の運用に埋め込む会議体だと言い換えられる。

採算設計を実務へ落とす手法を、CATCAREERは アサインメントデザイン™ と呼ぶ。提案・営業フェーズで、曖昧な引き合いを編成に分解し、誰を・何人・どう組めば利益が残るかを見立てる。その手法を実装した採算設計クラウドが『CATCAREERアサインメント』だ。レビュー会議の場で、編成を動かすと限界利益がリアルタイムに更新され、AIタクトが編成の現実的な代替案を客観的に示す。採算データは経営者・管理者が握る。採算設計を新しいカテゴリとして整理した内容は採算設計とは。プロジェクト型組織が受注前に利益を作る新カテゴリに書いた。

案件レビュー会議は、進捗を確認して安心するための定例ではない。続けるか・組み替えるか・断るかを採算で決める、経営判断の場である。