「案件型ビジネス」という、それ自体が特殊な働き方
まず前提を揃えます。
私が「案件型ビジネス」と呼んでいるのは、商品をパッケージで売るのではなく、案件ごとに見積もり・提案・進行・納品・請求のサイクルを回す働き方の総称です。製造業のように工場ラインで再現する仕事ではなく、SaaSのように一度作って継続課金で回収する仕事でもありません。1案件ごとに、要件・工数・難易度・利益率が違います。
これは経営から見ると、かなり扱いにくい構造を持っています。今月の売上は今月の請求書発行で立つのに、利益率は来月にならないと確定しない。来月の売上見込みは進行中の案件次第で、その案件の進捗は現場のディレクターやエンジニアの肌感覚に依存している。月次の利益が「終わってみないとわからない」業態です。
ZACを提供しているオロさんの広告代理店向け資料でも、案件・契約・プロジェクト単位で業務進行する業種特有の商習慣に対応する機能群が強調されていますが、それは裏を返せば、汎用の会計や販売管理ソフトでは案件型ビジネスの実態が見えないということでもあります。
この「見えにくさ」が、4業種に共通する3つの病の温床になっています。
共通する3つの病
病1：責任所在が、案件の途中で流動的になる
最初の病は、案件の責任者がフェーズごとにぬるっと入れ替わって、誰がいま判断を下すべきかが途中で曖昧になる、というやつです。
キックオフのときは営業が主導します。要件が固まるとディレクターやPMにバトンが渡ります。途中で技術判断が必要になるとエンジニアやデザイナーがメインになり、クライアントへの政治判断が要る場面では再び営業や役員が顔を出します。案件の中で「いま誰が最終判断者か」が、フェーズごとに動くんです。
これがうまく回っているうちは、各人が自分のフェーズでバトンを受け取って走るので問題ありません。ところが、納期間際にトラブルが起きたとき、「これって誰が決めるんでしたっけ」が発生します。
私自身、社内でこの瞬間に何度も立ち会いました。みんなが少しずつ別の認識を持っていて、それぞれの認識の中ではちゃんと辻褄が合っているのに、合わせてみると整合しない。営業は「もう先方に納期延長は伝えた」と思っていて、ディレクターは「先方は何も知らない前提で動いている」と思っている、というような認識ズレが、責任の流動性から生まれます。
病2：見積もりと実工数の乖離が、案件が終わってからしか見えない
2つ目は、お金と時間の話です。
案件のはじめに見積もりを出します。社内の工数も、外注費も、媒体費も、ここで一度仮置きします。ところが、案件が動き始めると、見積もり段階では想定していなかった追加対応、技術的な手戻り、クライアントの心変わりが必ず発生します。
問題は、それがリアルタイムで見えないことです。
ディレクターやPMの頭の中には「これ、見積もりよりだいぶオーバーしてるな」という感覚があります。でも、その感覚は数字にはなっていません。経理は月末に請求書を切る段階で初めて、「あれ、この案件、ずいぶん赤くなってる」と気づきます。経営者の手元には、それから何日か遅れて報告が上がってきます。遅れて気づくということは、対策が取れないということです。次の案件で同じ過ちを繰り返さない、くらいの教訓にしかなりません。
これは業種を問わず共通の構造的問題です。マネーフォワードクラウドERPの広告業向け解説でも、外注費や人件費を含む経費の見える化が、案件型ビジネスの中心的な課題として挙げられています。
病3：案件が終わると、ナレッジが消える
3つ目は、終わったあとの話です。
案件が無事に納品されると、関係者の意識は次の案件に向かいます。Slackチャンネルはアーカイブされ、ドキュメントは案件フォルダの奥に沈み、振り返り会は「無事に終わってよかったね」で締められます。
そして半年後、似たような案件が来たときに、ゼロから考え直します。前回ハマった落とし穴を、また踏みます。前回うまくいった工夫を、誰も思い出せません。
これが起きる根本原因は、ナレッジが「人」に紐付いていて、「案件」には紐付いていないからです。前回担当したディレクターの頭の中にはあるかもしれません。でも、その人が抜けたら一緒に消えます。あるいは、その人がまだ在籍していても、案件と切り離されたメモやドキュメントは、検索でひっかかりません。
私が制作会社のディレクター時代に痛感した話で、過去の議事録を漁って「これだ」と思って探した記録が、結局見つからずに、また同じ議論を会議で繰り返したことが何度もあります。たぶん皆さんも、心当たりがあると思います。
業種ごとに違う、症状と処方箋
3つの病は共通でも、業種ごとに表に出てくる症状は違います。それぞれの「いちばん刺さる症状」と、対応する処方箋を業種ごとに書き分けます。
制作会社：校正と進行管理が分離している
制作会社で特に重症化するのは、「デザイン校正の戻しが、進行管理のスケジュールに反映されていない」症状です。
校正はAUNやBrushupのような専用ツールでやって、進行はBacklogやAsanaで管理して、コミュニケーションはChatworkで——という形になりがちです。校正で2往復増えたという事実が、進行ガントの線を伸ばす操作に繋がりません。気づいたら納期が動かせなくて、現場が徹夜することになります。
処方箋は単純で、校正のラリーを案件のタスクとして登録することです。デザイン校正の修正指示1つひとつが、案件のタスクと同じ場所に並んでいれば、「校正の戻しが増えた＝タスクが増えた＝納期に余白が必要」という認識がチームと共有されます。
広告代理店：「案件×媒体×顧客×外注」の多次元管理
代理店の現場に最初に入ったときに面食らうのは、1案件のなかに媒体費・制作費・外注費が同居していて、そのうえ案件と顧客が多対多になっていることです。経営から見ると、ここまで「軸が増えると指数関数的に複雑になる」業種は、4業種のなかでも代理店が群を抜いています。
ひとつの案件で、Google・Yahoo・Metaの媒体費、制作会社への外注費、フリーランスデザイナーへの直接発注、社内の運用工数が同時に動きます。さらに、同じ顧客から月をまたいで複数案件が並行し、社内の運用担当が顧客ごとに違うのに、媒体側のアカウントは複数案件で共有していたりします。
この多次元構造を、スプレッドシートと汎用プロジェクト管理ツールの組み合わせで扱おうとすると、必ず歪みます。マネーフォワードの広告業のプロジェクト管理解説でも、媒体費・外注費・社内工数の複数原価を案件ごとに紐付ける必要性が指摘されていますが、これは中小代理店にとってはなかなか重い課題です。
処方箋は、「案件」と「顧客」を独立した実体として扱い、両者を多対多で結べる構造を最初から持つことです。案件の中に顧客情報を埋め込む設計だと、同じ顧客の別案件で情報がコピーされて整合しなくなります。広告代理店ほど顧客マスタとプロジェクトが分離している必要性が高い業種はありません。
マーケ会社：施策の検証ループが個人技になる
デジタルマーケティング会社で目立つ症状は、施策のPDCAが個人の頭の中で回ってしまうことです。
「先月のキャンペーン、何が効いたんでしたっけ？」と聞かれて、担当者個人のSlackやNotionを掘らないと答えられない状況、よく聞きます。施策の仮説、実行内容、結果、振り返りが、案件単位ではなく担当者単位で散らばっています。
これは病3（ナレッジ消失）の応用形です。マーケ会社の場合、案件そのものが「施策の集合体」なので、案件の中にどう施策の記録を残すかが鍵になります。
処方箋は、案件の中にナレッジの置き場を持たせ、振り返りを「担当者ノート」ではなく「案件のログ」として書くことです。担当者が辞めても、次に同じクライアントを担当する人が、その案件のナレッジを開けば過去の仮説と結果が読めます。これだけで、「ゼロから考える」が「過去の延長線で考える」に変わります。
社内開発チーム（事業会社）：受託マインドとプロダクトマインドの混在
事業会社の社内開発チームに固有の症状は、受託案件と社内案件が同じチームに混在することです。
社内の事業部から「これ作って」と依頼が来る案件と、自分たちが企画するプロダクト改善案件が同じバックログに入ります。前者は「依頼者が決めること」で、後者は「自分たちが決めること」のはずなのに、混ざると優先度の判断軸がブレます。
処方箋は、「受託案件」と「内製プロジェクト」を案件タイプとして明示的に分け、それぞれの責任所在のフローを別立てにすることです。受託案件は依頼元の事業部が責任者、内製プロジェクトは開発チーム自身が責任者と、フェーズの判断軸を最初に決めておきます。これで病1（責任流動性）の発症が緩和されます。
結局、4業種とも「案件を主語にする」に行き着く
4業種の処方箋を並べると、共通点が浮かびます。全部、案件を主語にするという方向に収斂します。
校正のラリーも、媒体費の集計も、施策の振り返りも、受託と内製の区別も、すべて「案件」という単位の中に情報を集めることで、整合性が取れるようになります。逆に言うと、案件以外を主語にしている（担当者・媒体・ツール・スプレッドシートのシート別など）と、3つの病はそのまま残ります。
これは、ツールというより設計思想の話です。どんなツールを使っていても、「うちは案件を起点に情報を作る」という運用ルールを決めると、見える景色が変わります。SaaSやスプレッドシートを変えなくても、まずはこの主語を決めることから始められます。
ただ、運用ルールだけで人間の習慣を変えるのは限界があります。ツールの設計が「担当者軸」になっていると、案件主語で動きたくても、入力動線がそれを許してくれません。ここで、自分たちの業務に合った道具を選ぶという話が出てきます。
LOGLIKEは、案件型ビジネス4業種に合わせて作った道具
宣伝めいてしまって申し訳ないのですが、LOGLIKEはこの4業種を念頭に置いて私たちが設計したプロジェクト管理ツールです。
ダッシュボードは、経営者が朝に開いて「いま全社で何件動いていて、どれが詰まっているか」を5分でつかめる粒度で作りました。ERPほど重い財務画面ではありません。中小規模の経営者が最初に見る一画面、というポジションです。
ガントチャートは外部共有が前提です。代理店や制作会社のように、案件のスケジュールをクライアントと合意したい業種で、相手にアカウント発行を求めずURLで見せられます。
顧客管理（CRM）とプロジェクトを分離して、両者を多対多で結べる構造にしているのは、代理店や継続支援型のマーケ会社で、同じ顧客の複数案件を並列で持つときに顧客マスタが分断されない、という効きどころを意識したからです。プロジェクトの中に顧客情報を埋め込む設計だと、必ずどこかで整合が崩れます。
ナレッジベースは、案件の中にも、案件を横断する社内ナレッジの位置にも置けます。先日、ある制作会社のクライアントから「半年前の案件で書いたコーディング規約を、今やってる似た案件で開けてすぐ参照できて助かった」という話を聞いて、ああ、設計の意図がちゃんと届いているなと嬉しくなりました。マーケ会社が施策の記録を案件のログとして残す使い方も、同じ道具で完結します。
AI課題生成は、自然言語で案件の概要を入れると、構成するタスクをAIが分解してくれます。
AI予告通知は、遅延リスクを予測して事前に通知します。病2（見積もりと実工数の乖離が遅れて見える）への対症療法という位置づけです。
AIと会議は、プロジェクト分析と議事録自動生成を兼ねた機能で、各案件の状況をAIに問いかけながら決定事項を議事録として残せます。経営者が現場の報告を待つ前に、自分でAIに「あの案件、いま何が起きてる？」と聞ける場所として用意しました。
私たちの位置取りはシンプルで、ZACのようなフル装備のERPでもなく、Notionのような汎用ハブでもない、その中間の粒度の道具です。5〜50人規模で受託型ビジネスを回す会社が「案件を主語にする」を運用とツールの両方で揃えるための、ちょうどいい重さでありたいと考えています。
まとめ：症状ではなく、病を見にいく
症状に振り回されているうちは、たぶんずっと同じ消耗が続きます。校正の戻し、媒体費の混乱、施策の振り返り不足、優先度の判断ミス——その奥にある3つの病、責任流動性・見積もり乖離・ナレッジ蒸発のほうを直接見にいったほうが、結局は早いです。
業種が違っても、構造は同じです。違うのは表に出てくる症状の組み合わせと、解像度です。自社の業種に固有の悩みだけで判断するより、案件型ビジネス全体の構造として見直したほうが、解くべき順番が見えてきます。
業種を超えた共通項を眺めながら、自社の処方箋を組み立てる材料として、この記事を使っていただけたら嬉しいです。LOGLIKEを触ってみたい方は、デモのリクエストから実画面が見られます。気になる業種の症状について、もう少し詳しく聞いてみたい、という声があれば、それも遠慮なく投げてください。私たちもまだ、4業種それぞれの現場から学ぶことが山ほどあります。