プロジェクト完了後の収支レビューを形骸化させない―「終わった案件」を次の見積に活かす仕組みづくり
結論、完了後の収支レビューは「最も安く手に入る学習機会」です
結論から申し上げます。プロジェクトが終わった後に収支を振り返る取り組みは、管理会計の中でも投じるコストが小さく、得られる学びが大きい施策です。理由は、その案件で使った工数も外注費も、すでに実績として手元に揃っているからです。新しいツールも追加の調査も要りません。あるのは、終わった案件のデータと、それを見る30分だけです。
それにもかかわらず、多くの会社では検収が済んだ瞬間に案件の数字は誰にも見られなくなり、同じ見積の誤りが次の案件でも繰り返されます。終わった案件は、次の利益を生むための教材だと捉え直すことが出発点です。検収後のわずかな時間の振り返りが、次の案件の採算を確実に押し上げる土台になります。
収支レビューが機能している会社には、共通点があります。それは、見積の精度が案件を重ねるごとに少しずつ上がっていくことです。最初は誤差が大きくても、レビューのたびに係数や標準工数が現実に近づき、やがて受注前の段階で赤字になりそうな案件に気づけるようになります。逆にレビューがない会社は、案件数が増えるほど同じ失敗の回数も増えていきます。経験を積んでいるはずが、学びは蓄積されていない状態です。
なぜ完了後のレビューは後回しにされるのか
私が200社を超える支援で見てきた限り、レビューが行われない理由はほぼ共通しています。第一に、次の案件がすでに動き出しており、現場に振り返る余裕がないこと。第二に、振り返りが「誰の責任だったか」を探す場になりやすく、関わった人が参加したがらないこと。第三に、目的が曖昧で、やってみても何も変わらなかった経験が積み重なっていることです。
つまり、時間の問題というより、進め方の設計の問題です。責任追及の場ではなく、次の見積を良くするための場だと位置づけるだけで、参加者の空気は大きく変わります。私自身、管理部門の立場で同じ壁に何度も直面してきました。「反省会」と呼ぶのをやめて「見積の改善会議」と呼び替えるだけでも、発言の量が変わることがあります。
もう一つ、見落とされがちな理由があります。案件別の収支を出すこと自体に、手間がかかる会社が多いという点です。工数は別のシステム、外注費は会計ソフト、請求は営業の管理表と、データが散らばっていると、レビューの準備だけで担当者が疲れてしまいます。準備が重ければ、レビューは自然と行われなくなります。ですから、案件別の数字を短時間で揃えられる状態をつくることが、実は最初の一歩になります。
収支レビューで最初に見るべき3つの差異
数字で見るべき差異は、次の3つに絞ってください。1つ目は見積と実行予算の差、2つ目は実行予算と最終実績の差、3つ目は当初の想定粗利と最終粗利の差です。項目を増やしすぎると、レビューは細かい数字の確認作業になってしまいます。まずはこの3つが同じ資料に並び、誰が見ても同じ数字だと確認できる状態をつくってください。
見積と実行予算の差は、受注時点の読みの甘さを示します。実行予算と実績の差は、着手後の管理が崩れた場所を示します。両者を分けて見ることで、見積の問題なのか運用の問題なのか、対策の打ち先がはっきりします。この3つが並んでいれば、15分ほどで案件の要点はつかめます。ここでも、予算と実績が同じ物差しで管理されていることが前提になります。
実務で使いやすいのは、差異を金額と率の両方で書き出す方法です。金額だけでは案件規模の違いに引きずられ、率だけでは小さな案件の誤差が大きく見えてしまいます。両方を並べて、差異が大きい項目に印をつけていくと、話し合うべき論点が自然に3つほどに絞られます。すべての差異を説明しようとせず、影響の大きい上位の項目だけを深く掘ることが、30分で終える秘訣です。
差異が想定より小さかった案件も、見逃さずに確認してください。うまくいった案件は、見積の精度が高かったのか、たまたま追加要望が少なかったのかで、次への活かし方が変わります。偶然の黒字を実力だと思い込むと、次の案件で足元をすくわれます。
差異の原因は「人」ではなく「構造」に分解する
差異が見つかったら次は原因を探しますが、ここで「担当者の見積が甘かった」と結論づけて止めてはいけません。個人の能力に原因を求めると、担当が替わっても同じ構造が残るからです。見るべきは、仕様変更の扱い、追加作業の請求ルール、外注先の管理、工数の記録方法といった、案件を取り巻く仕組みの側です。
原因を書き出すときは「なぜ」を繰り返し、人の名前が出てきたら一段深く掘り下げるのが目安です。「Aさんが確認を怠った」で止めずに、「確認が漏れても気づける仕組みがなかった」まで掘ると、対策が運用ルールとして書き出せます。個人を責めずに構造を直す姿勢が、正直な情報が集まる場をつくります。
構造に分解する際の視点として、私は「入口・途中・出口」の3つに分けて考えるようにしています。入口は見積と契約の段階、途中は着手後の進捗と変更の管理、出口は検収と請求の段階です。差異がどこで生まれたかをこの3つに当てはめると、見積の前提の甘さなのか、途中の管理の崩れなのか、請求漏れなのかが整理できます。担当者を責める議論になりにくく、対策も部署をまたいで考えられるようになります。
レビューの場では、事実と解釈を分けて書き出すことも大切です。「工数が想定より増えた」は事実で、「顧客が無理を言った」は解釈です。事実を先に揃えてから解釈を話すと、議論が感情論に流れにくくなり、対策の質も上がります。
具体例、追加要望が無償で吸収されていた案件
一つ例を挙げます。あるシステム開発の案件で、最終的な粗利が想定を大きく下回ったとします。レビューで工数を見ると、仕様確定後の追加要望に対応した工数が、着実に積み上がっていました。担当者は顧客との関係を優先し、追加分を請求せずに吸収していたのです。プロジェクトの現場では、決して珍しい光景ではありません。
このとき「担当者が断れなかった」で終わらせると、次の案件でも同じことが起きます。構造として見れば、追加要望を受けた時点で工数と金額を見積り直すルールがなく、判断が個人任せになっていたことが原因です。対策は、追加要望の受付から見積の再提示までの流れを決めた、変更管理のルールを整えることです。これは営業と現場の双方が使える運用ルールになります。
この例で大切なのは、結論が「追加請求を徹底しよう」という精神論で終わっていないことです。ルールとして残すからこそ、担当が替わっても、新しく入ったメンバーがいても、同じ判断が再現されます。レビューの成果とは、反省の言葉ではなく、次の案件から使える手順や基準として形に残るものです。会議の最後に「今日の学びを、どのルールに書き足すか」を必ず一言で確認する習慣をお勧めします。
振り返りの結果を次の見積ルールに反映させる
レビューの価値は、結果が次の見積に返って初めて生まれます。実務では、見つかった学びを、見積の係数や標準工数、リスク加算のルールに書き戻す作業まで含めて運用を設計します。たとえば、要件が固まっていない段階の案件には一定の予備工数を加える、外注比率が高い案件は管理工数を別枠で見る、といった形です。
ルールは大げさにせず、A4一枚に収まる程度で構いません。ルールを更新した日付と根拠になった案件名も残しておくと、後から見直す際の判断材料になります。営業と現場が同じ見積ルールを使えるようになると、受注時点の採算予測が安定していきます。見積が安定すれば、着地見込みの精度も上がり、経営会議での議論も変わってきます。
反映先を決めるときは、営業の見積書のひな形、標準工数表、案件開始時のチェックリストの3つを候補にしてください。この3つは日常的に使われるため、学びが確実に現場へ届きます。逆に、共有フォルダに保管された振り返り資料は、ほとんど読まれることがありません。学びは、人が意識して思い出すものではなく、仕事の流れの中で自然に目に入る場所に置くものだと考えています。
ルールを増やしすぎないことも重要です。新しい学びを一つ足すなら、古くなったルールを一つ見直す。この新陳代謝があると、ルールが現場で使われ続けます。守られないルールが増えるほど、レビューそのものへの信頼が下がってしまいます。
続けるための最小ルール―頻度・参加者・所要時間
定着させるコツは、最初から完璧を目指さないことです。お勧めは、完了から2週間以内に、プロジェクトマネージャー、営業担当、経理または管理部門の3者で、30分だけ行うという最小構成です。対象も全案件ではなく、規模の大きい案件と、想定粗利を大きく外れた案件に絞ります。
ただし、案件別の収支がすぐ出せる状態になっていることが条件です。集計に半日かかるようでは続きません。プロジェクトごとの予算・実績・見通しを日常的に管理する仕組みの有無が、継続性を左右します。最初の3か月は、回数よりも、必ず実施して記録を残すことを優先してください。ここで習慣がつけば、対象案件を広げるのは難しくありません。
参加者の選び方にも工夫が必要です。プロジェクトマネージャーだけで行うと現場の視点に偏り、管理部門だけで行うと数字の説明に終始します。営業担当が入ることで、見積時の前提や顧客とのやり取りの背景が共有され、管理部門が入ることで、数字の見方が揃います。立場の違う3者が同じ資料を見て話すこと自体が、部門間の認識のずれを埋める機会にもなります。
30分の進め方の目安をお伝えします。最初の5分で3つの差異を確認し、次の15分で原因を入口・途中・出口に分けて洗い出します。続く7分で見積や運用ルールへの反映案を決め、最後の3分で担当者と期限を確認して終わります。時間を区切ることで、議論が愚痴や反省に流れるのを防げます。
現場でよく見る失敗パターン
支援先で繰り返し見てきた失敗は、大きく3つあります。1つ目は、レビューを経営会議の場で行い、報告会になってしまうこと。2つ目は、赤字案件だけを取り上げ、うまくいった案件の要因を残さないこと。3つ目は、学びを議事録に書いたまま、見積ルールに反映しないことです。
特に2つ目は見落とされがちで、黒字案件の中にこそ、再現すべき進め方が隠れています。良かった点と悪かった点を同じ重みで記録し、次の案件で使える形に残していくことが、レビューを組織の資産に変えるコツです。どのパターンも、目的を「次の見積を良くすること」に絞れば避けられます。
失敗を防ぐ簡単な方法は、レビューの最後に「次の見積で変えること」を必ず1つ以上書き出して終わることです。1つでも構いません。変えることが書かれていれば、その会議は記録のためではなく、行動のためのものになります。そして次回のレビューの冒頭で、前回決めた変更が実際の見積に反映されたかを最初に確認します。この小さな往復が、レビューを形骸化させない最も確実な仕組みです。
まとめ
完了後の収支レビューは、追加投資が小さく、効果が積み上がる管理会計の取り組みです。見積・実行予算・実績の3つの差異に絞り、原因は個人ではなく構造に分解し、結果を次の見積ルールに書き戻す。この流れを、30分の最小構成から始めてみてください。
最後に、プロジェクト型ビジネスの経営者や管理部門の皆様へ。案件を終えるたびに数字を見返す習慣は、派手さはありませんが、会社の採算力をじわじわと底上げしていきます。まずは直近に終わった大きな案件を一つ選び、見積と実績の差だけでも眺めてみてください。そこにある差異が、次の見積を良くするための最初のヒントになります。
エンプレックス(現SCSK)でCFOを務めていた頃から、案件ごとの予算と実績が同じ画面で見えることが、振り返りの質を決めると実感してきました。eMplex PBMは、そうした案件単位の収支を日常的に追える状態をつくるための仕組みとして設計しています。終わった案件を、次の利益の種に変えていきましょう。