「見積もりは合っていた」のに赤字になる、その違和感
まず、自分を責めるのを一回やめてほしいんです。
見積もりが赤字の原因だと思い込むと、対策は「もっと精度の高い見積もりを作る」方向に行きます。過去案件のデータを集めて、工数の係数を細かくして、バッファを厚めに積む。これ自体は悪くないのですが、ここに全力を注いでも、赤字は思ったほど減りません。私も一時期、見積もりテンプレートを作り込むことに熱中していた時期がありましたが、案件の着地はあまり変わりませんでした。
理由はシンプルで、見積もりは「案件が始まる前の一点」の数字だからです。受託の採算が崩れるのは、たいてい始まったあとです。キックオフから納品までの数週間から数カ月のあいだに、見積もりの前提が少しずつ削れていって、最後に赤字として顕在化する。見積書の精度をいくら上げても、その後の進行で前提が崩れたら、入口の正しさは守られません。
つまり、見積もりは正しかった、というのは半分本当で半分嘘です。正しかったのは「立てた瞬間」の話で、進行中にその正しさが維持されていたかは、まったく別の問題なんです。
なぜ受託の採算は月末まで見えないのか
採算が崩れる現場を分解すると、いくつかの構造が見えてきます。順番に意味はなくて、現場で痛い順でもありません。私が思いつく順に書きます。
一番大きいのは、原価が後追いでしか確定しないことです。受託の原価の大半は人件費、つまり中の人がその案件に何時間使ったかです。ところが、その時間は普通リアルタイムには集計されません。デザイナーもエンジニアもディレクターも、目の前の作業をこなすのに必死で、工数を逐一つけている余裕はない。結局、月末になって「だいたいこのくらいやりました」と概算で埋める。だから原価は月次の締めまで確定せず、粗利は締めたあとにしか出ません。
これに重なるのが、工数がそもそも記録に残らない問題です。残業して片付けた分、休日にちょっと見た分、「5分だけ」と言いながら30分話したクライアントとの電話。こういう細切れの工数は、ほぼ記録から漏れます。本人の感覚では「そんなにかかってない」のに、積み上げると見積もりを軽く食い破っている。受託の赤字は、この目に見えない工数の堆積で起きることがかなり多いです。
そして、私が個人的に一番厄介だと思っているのが、追加対応がタダ働き化していく問題です。「ここちょっと直してもらえます?」がメールやチャットで飛んできて、ディレクターが「まあこのくらいなら」と引き受ける。一回一回は小さいんです。でも、追加見積もりも起票もされないまま、案件のスコープだけがじわじわ膨らんでいく。見積もりは初期スコープのままなのに、実工数は膨らんだスコープで動いている。このギャップが、そのまま赤字になります。
最後に、請求のタイミングのズレもあります。制作費はマイルストーン納品ごと、運用フィーは月次固定、外注費の支払いは別サイクル、というふうに、一つの案件でもお金の出入りが複数の時間軸で動きます。だから「この案件、いま時点でいくら使っていくら入る予定か」を即座に答えられる人が、案件の中にディレクターしかいない、という状態になりがちです。
この4つは、どれか一つを潰しても採算は守れません。共通しているのは、全部「進行中はリアルタイムに見えず、終わってから分かる」という点です。原価管理の世界には「週次でアラートを出せる仕組みがなければ、原価管理をしていないのと同じ」という言い方があるそうですが、受託の現場感覚としてもこれは正しいと思います。月末に判明する赤字は、もう手の打ちようがない赤字です。
見積もり精度を上げる現場のやり方
ここまで「見積もりが原因じゃない」と書いてきましたが、見積もりがどうでもいいという話ではありません。入口がガバガバだと進行中の努力で取り返すのはきついので、現場でやっておくべきことは押さえておきます。
過去案件の実績を引くのは、やっぱり効きます。ただし「似た案件の見積もり金額」を引くのではなく、「似た案件の実工数」を引くのがコツです。見積もりは願望が混じりますが、実工数は事実です。LP1本、コーポレートサイト1式、運用1カ月、といった単位で、過去に本当は何時間かかったかを残しておく。これが手元にあるだけで、次の見積もりの説得力が変わります。逆に言うと、実工数を記録していない会社は、毎回ゼロから勘で見積もっていることになります。
バッファの積み方も、もう少し正直になっていいと思います。よく「全体に2割乗せる」みたいな雑な積み方をしますが、これだと安い案件で競り負けるか、高い案件で赤字になるかのどちらかです。私がやっていたのは、不確実性の高い工程だけにバッファを寄せる方法です。要件が固まっていない初期フェーズと、クライアントの確認が読めない校正フェーズ。この2カ所にバッファを厚く置いて、作業内容が明確な実装フェーズは薄くする。バッファは均等に撒くより、危ない場所に集中させたほうが効きます。
それと、これが一番大事なんですが、追加対応の線引きを案件の最初に握っておくことです。「修正は何ラウンドまで」「それ以降は追加見積もり」というラインを、見積書か発注書の段階でクライアントと合意しておく。気まずいから後回しにすると、進行中に必ずタダ働きが発生します。最初に握っておけば、追加が来たときに「ここからは追加対応になります」と言える根拠になります。これは見積もりの精度というより、見積もりを守るための約束事です。
月末を待たずに、進行中に採算を守る
本題はここです。見積もりを入口でちゃんと作ったら、あとは進行中にそれが崩れていないかを見続けるしかありません。
具体的にやることは、案件の採算を「週次で雑に見る」習慣をつけることです。精緻な原価計算を月次でやるのとは別に、ディレクター自身が週に一度、自分の担当案件をざっと見て「この案件、想定よりこの工程が伸びてないか」「追加対応が起票されないまま溜まってないか」をチェックする。数字が荒くてもいいんです。月末の正確な赤字より、進行中の「やばそうな匂い」のほうが、打ち手を残してくれます。
このとき効くのが、案件単位で進捗と残作業が一望できる場所を持っておくことです。タスクが個人ごとにバラバラの場所にあると、案件全体がいま何割で、どこが詰まっているかが見えません。案件を主役にして、その下にタスク・校正・請求がぶら下がる構造にしておくと、週次の見回りが数分で終わります。
予兆の拾い方にもコツがあります。赤字の予兆は、たいてい数字より先に「進捗の滞り」として出ます。あるタスクのステータスが何日も動いていない、確認待ちのまま放置されている、特定の人にタスクが偏っている。こういう兆候は、原価が膨らむ前に出てきます。だから、締切や停滞を自動で知らせてくれる通知の仕組みがあると、人間が毎回見張らなくても予兆を拾えます。私の体感だと、停滞の検知が1週間早いだけで、案件の着地はだいぶ変わります。
工数・採算ツールの率直な整理と、AI工数予測の現在地
進行中に採算を見たいなら、ツールの力も借りたくなります。この領域のツールを、得意不得意がはっきり出るように並べます。等距離で褒める気はないので、率直に書きます。
工数の記録に特化しているのがTimeCrowdのようなツールです。時間を打刻して、誰がどの案件に何時間使ったかをグラフやCSVで出せます。工数を「測る」一点においては強いです。ただ料金は2026年時点でミニマムプランが月額25,000円・初期費用10万円前後と、小さいチームには軽くない投資で、しかもこれ単体ではタスク管理や請求まではカバーしません。工数を厳密に測りたいフェーズの会社には合いますが、入口のハードルは正直高めです。
採算そのものを見るなら、クラウドログやZAC、Web制作向けだとプロカンあたりが本命です。売上・原価・工数原価・損益率を予実で持って、案件別の収支を進行中に可視化できます。赤字リスクの早期発見という意味では、この層のツールが一番ちゃんとしています。一方で、ZACのようなERP級は機能も価格も中堅以上向けで、5〜20人規模の受託会社には重すぎることが多いです。見積もりを取って導入を諦めた会社を、私は何社も知っています。
汎用のプロジェクト管理ツール、たとえばBacklogやAsanaは、タスク管理と進行の可視化には強いものの、採算管理はそのままでは届きません。Backlogは2026年時点でスタンダードが月額17,600円前後と導入しやすい価格で、課題管理の使い勝手は良いのですが、工数原価や粗利の自動集計は守備範囲外です。結局、採算はスプレッドシートを別で回すことになり、月末にそのスプレッドシートが落ちるとツール側のステータスと数字が乖離する、という事故が起きます。
AIの工数予測についても触れておきます。2024年あたりから、過去のデータをもとにAIが工数を自動で見積もる機能が各社で増えてきました。これは便利です。似た案件の実績から初期見積もりの叩き台を出してくれるので、ゼロから勘で積むよりはるかにマシになります。ただ、率直に言うと、AIの工数予測は「過去にちゃんと記録された実工数」がないと精度が出ません。さっき書いたとおり、受託の現場は工数記録が漏れがちです。漏れだらけのデータをAIに食わせても、漏れた前提の予測しか返ってきません。AIに工数を当てさせる前に、まず工数が記録される運用を作るほうが先だと思います。
AIをどこまで使えるか、どこに任せると痛い目を見るか
採算管理にAIを入れる話は、もう少し正直に書きます。これは私自身が現場で試行錯誤している領域です。
AIに任せて効果が出やすいのは、議事録からのタスク化、進捗の停滞検知、それから過去案件を参照した見積もりの叩き台づくりです。クライアント定例の音声から議事録を起こして、「次回までにやること」をタスクとして切り出す。この部分はもう普通に動きますし、入れない理由がありません。停滞している案件を早めに知らせてくれるのも、採算の予兆検知としてかなり実用的です。
一方で、AIに丸投げすると痛い目を見るところもはっきりしています。最終的な採算の判断は、まだ人間が握るべきです。AIが「この案件は赤字になりそうです」と出してくれたとしても、その案件を戦略的に赤字覚悟で受けているのか、本当にコントロールミスなのかは、コンテキストを持った人間にしか判断できません。AIの出した粗利の数字を、ディレクターが一度も見ないままクライアントや経営に共有するのは、構造的に事故を生みます。
採算管理におけるAIは、「判断するための材料を3倍速で集めてくれる助手」くらいの位置づけが、いまのところ現実的です。判断そのものを代わってもらう段階ではありません。
LOGLIKEで案件採算を進行中に見る運用例
ここで少しだけLOGLIKEの話を書きます。先に正直なことを言っておくと、LOGLIKEは工数原価や粗利を自動計算する専用の採算管理ツールではありません。そこを求めるなら、さっき挙げたクラウドログやZACのほうが向いています。LOGLIKEが効くのは、その手前にある「進行中の状態を案件単位で見えるようにして、採算を守る土台を作る」ところです。
LOGLIKEは「案件も、校正も、請求も。すべてが一つに！」をコンセプトにしたプロジェクト管理ツールで、案件を主軸にして、その下にタスク、校正、請求書ファイルがぶら下がる構造を持っています。受託の採算を守るという観点で、いくつか組み合わせて使える機能があります。
見積もりの入口を助ける機能もあります。AI課題生成は、案件の内容を普段の言葉で入力すると、タスクに分解したうえで各タスクの工数見積もりまで自動で出してくれます。コスト推定は信頼度70〜95%という幅つきで概算を返す作りです。さっき「過去の実工数を引いて見積もる」と書きましたが、AIが叩き台を出してくれると、ゼロから勘で積むより出発点が安定します。ただし前に書いたとおり、AIの見積もりは食わせる情報の粒度で精度が変わるので、出てきた数字を鵜呑みにせず人間が一度握り直すのが前提です。
まずダッシュボードで、担当案件の進捗をまとめて見られます。週次の採算見回りを数分で済ませたいときに、案件がいま何割で、どこが詰まっているかを一望できる場所になります。
停滞の予兆を拾うにはAI予告通知が効きます。締切前のリマインドや、進捗が滞っている案件の兆候を拾ってくれるので、赤字の予兆である「進捗の滞り」を、数字が悪化する前に検知しやすくなります。
追加対応のタダ働き化を防ぐ意味では、AIと会議とAI課題生成も地味に効きます。クライアントとの打ち合わせで出た追加要望を、議事録から課題として起票しておけば、「言われたけど起票されないまま実工数だけ増える」を減らせます。追加対応を可視化された課題にしておくこと自体が、追加見積もりの根拠にもなります。
それから請求書管理です。これは誤解されやすいので明記しますが、LOGLIKEの請求書管理は「請求書を発行する」機能ではありません。完了した課題に紐づく請求書ファイルを、案件配下で管理する機能です。請求書の作成自体はfreeeやマネーフォワードなどの会計ツールで行い、出来上がったPDFを案件にぶら下げる使い方になります。これによって、ディレクターが案件ページから「この案件、いくらの請求が立ったか」を確認できるようになります。
LOGLIKEだけで案件の粗利が自動で出る、という話ではありません。ただ、進捗・停滞予兆・追加対応・請求が同じ案件の上に集まっていると、月末を待たずに「この案件、雲行きが怪しい」と気づける確率は上がります。採算を守る勝負は進行中にあるので、その進行中の状態を一箇所に集めておくこと自体に、私はかなり意味があると感じています。
まとめ：見積もりは入口、勝負は進行中
受託の赤字は、見積もりの間違いより、進行中に見積もりの前提が崩れることで起きます。原価が後から確定する、工数が記録に残らない、追加対応がタダ働き化する、請求のタイミングがズレる。この4つが重なって、月末に赤字として顔を出します。
だから打ち手は二段構えです。入口では、過去の実工数を引いて見積もり、危ない工程にバッファを寄せ、追加対応の線引きを最初に握る。進行中は、週に一度ざっと採算を見て、停滞の予兆を数字が悪化する前に拾う。精緻な原価計算を専用ツールでやるかどうかは、この運用が回ってから判断しても遅くありません。
ツールを入れること自体が目的になると、半年後にスプレッドシートがまた一枚増えています。私自身、何度もそれをやりました。まずは進行中の状態を案件単位で見える場所に集めるところから始めるのが、いちばんコストパフォーマンスが良いと思っています。