納品2日前、電話が鳴った金曜の夜
ある制作会社のディレクター、Aさんの話です（ご本人の許可を得て、社名や案件内容をぼかした形で紹介します）。
案件はコーポレートサイトのリニューアル。キックオフから3ヶ月、全8ページのデザインを進めて、コーディングに入る直前のタイミングでした。デザインはクライアントの担当者から「いい感じですね」「上に共有しておきます」と毎回好感触。Aさんも「今回は順調な案件だな」と感じていたそうです。
金曜19時の電話は、その幻想を粉々にしました。社長が急に「全体のトーンが違う」と言い出したのです。担当者はAさんに「先週までは大丈夫そうだったのに、今日の定例で突然」と謝りながら、「月曜までに方向性を変えたデザインを見せてほしい」と伝えました。
週末、Aさんのチームは徹夜でデザインを作り直しました。結果的に納品は2週間延び、追加工数分は会社負担。デザイナーは疲弊し、チームの雰囲気は一気に悪化。売上は出たものの、赤字案件になりました。
この話を聞いて「うちでもあった」と感じた人は、たぶん少なくないと思います。
炎上はなぜ起きるのか——3つの構造的な原因
Aさんのケースを「たまたま運が悪かった」で片付けると、同じことを繰り返します。炎上案件の多くには、構造的な原因が重なっています。その中でも特に頻度が高い3つを挙げます。
原因1：「言った・言わない」が生まれるコミュニケーション
Aさんのケースで最初にボタンを掛け違えたのは、担当者と社長の間で「デザインの方向性がちゃんと共有されていなかった」ことでした。担当者は「いい感じです」と言っていたものの、社長の目には一度も触れていなかったのです。
制作現場でよく耳にするのが「担当者レベルでは合意していたのに、決裁者が覆した」というパターンです。これが起きる根っこには、合意の記録がメールやチャットに散らばっていて、誰がどこまで確認したのかが追えない状態があります。
Web制作の炎上原因を分析した記事でも、「見積もり」「認識の齟齬」「スケジュール」「要件定義」のどれか1つでも満たせていないと炎上しやすい、と指摘されています（株式会社GIG）。そして認識の齟齬のほとんどは、「誰が」「いつ」「何に」OKを出したのかが曖昧なところから生まれます。
原因2：中間マイルストーンがなく、最後まで問題が見えない
Aさんのケースの2つ目の問題は、「社長が最終確認するタイミング」がスケジュールに組み込まれていなかったことでした。
制作会社のスケジュールは「ワイヤー→デザイン→コーディング→納品」と段階が進みます。それぞれの段階で「この時点で誰にOKをもらう」が明確になっていないと、終盤になって決裁者からちゃぶ台返しが入ります。
ガントチャートを引いていても、線が引かれているだけで「ここがクライアント側の確認ポイント」という印がないと意味がありません。マイルストーンが可視化されていないスケジュールは、ただの線です。
原因3：クライアントの期待値とチームの認識に静かなズレがある
3つ目は、もっと静かに進行する問題です。クライアントが「何を期待しているか」と、制作チームが「何を作ろうとしているか」がすれ違ったまま進行してしまうパターンです。
Aさんのケースだと、クライアント側は「担当者から社長への定期報告」を想定していませんでした。一方、制作会社側は「担当者がOKなら大丈夫」と判断していました。どちらも悪気はなく、どちらも誠実に仕事をしているのに、前提がズレていた。厄介なのは、誰も間違ったことをしていない状態で火種が育っていく点です。
LIGの記事でも、トラブル防止の第一歩として「クライアントと目的・ゴールを合わせること」が挙げられています（株式会社LIG）。逆に言えば、ゴールの認識がズレたまま進むと、どんなに丁寧に作ってもひっくり返る可能性が残ります。
二度と炎上させないための5つの仕組み
構造的な問題なら、仕組みで解決できるはずです。Aさんと同じ失敗を繰り返さないために、制作現場で実装しやすい5つの仕組みを紹介します。
仕組み1：キックオフで「決裁者は誰か」を必ず書面化する
まず、案件スタート時にクライアント側の「誰がOKを出したら確定なのか」を確認して、それを議事録やプロジェクト管理ツール上に残します。
実務のコツは、この質問をストレートにクライアントに投げることです。「最終的にどなたの承認が必要ですか？」と聞く。この一言で、担当者自身が「あ、それは社長にも見てもらわないと」と気づくケースは少なくありません。こちらから聞かない限り、担当者レベルで判断できると思い込んでいるクライアントがかなりいます。
Aさんの案件でも、キックオフで「社長の確認はどのタイミングで入りますか？」と一言聞いていれば、定例ミーティングに社長が参加する段取りが組めたはずです。
仕組み2：クライアントにもガントチャートを見せる
社内で引いているスケジュールをクライアントと共有していない制作会社、実はかなりあります。「メールで日程は伝えてある」だけでは、クライアントが自分の締め切りを自分ごと化しません。
ガントチャートをクライアントにも見せると、「この日までにフィードバックを返さないとスケジュールが押す」が一目でわかります。クライアント側の確認遅延による炎上は、これだけで相当減ります。
Backlogやmonday.comでもガントチャートは使えますが、クライアントをユーザーとして招待する必要があり、アカウント数のコストが発生します。LOGLIKEのガントチャートはURLを発行して外部共有できるので、クライアントはログインなしで進捗を見られます。共有のハードルが低いと、クライアントが週に一度でも自発的に進捗を見にきてくれるようになります。
仕組み3：デザイン校正は「ツール上の書面」で残す
デザインの確認をメールやチャットでやっていると、「言った・言わない」問題が起きます。LINEで送られてきた赤字画像、定例会での口頭コメント、メール本文の箇条書き——指示がバラバラの場所に散らばると、拾い漏れが必ず発生します。
校正ツール上で指示を集約すれば、どのデザインのどこに誰が何を書いたかが時系列で残ります。「それは前のバージョンの話」「その指示は聞いていない」という事故は、これだけでかなり減ります。
LOGLIKEのデザイン校正機能はクライアントへの外部共有にも対応しているので、クライアント側に別アカウントを作ってもらわなくても校正指示をもらえます。案件ごとに校正履歴が紐づく設計なので、あとから「この修正、どの段階で決まったんだっけ」を辿るのも簡単です。
仕組み4：対応漏れを「あとで対応」で仕組み化する
炎上案件を振り返ると、「あのとき、このタスクを見落としていた」という話が必ず出てきます。忙しい時期ほど、ちょっとした依頼や気になるポイントが意識から漏れて、後で大きな問題になります。
対応漏れを防ぐには、「今すぐ着手しないけれど、忘れてはいけないこと」を保管する場所が必要です。頭の中やSlackの未読マークでは管理しきれません。
LOGLIKEの「あとで対応」機能は、この用途にぴったりです。プロジェクトや課題画面から「あとで対応」に入れておけば、後で一覧で確認できます。地味な機能ですが、小さな依頼を拾い続けるチームほど効きます。
仕組み5：案件の振り返りをナレッジとして残す
最後は、炎上を起こした後の話です。同じ失敗を繰り返さないために、起きたことを言語化してチームに残しておきます。
振り返り（ポストモーテム）の書き方はいろいろありますが、最低限この3つを書いておくと次に活きます。
何が起きたのか（事実ベース、感情抜き）
なぜ起きたのか（構造的な原因、個人の責任ではなく）
次にどう防ぐか（具体的な仕組みの変更）
これをSlackで流すだけだと、半年後には誰も覚えていません。検索できる形でナレッジとして残しておくと、別案件で似た状況に直面したときに活きます。
LOGLIKEのナレッジベースは案件情報と同じ場所に振り返りドキュメントを置けるので、別ツールに書き出す手間が省けます。定着のコツは、振り返りを個人任せにせず「案件クローズの工程」として組み込んでしまうことです。
個人の頑張りに頼らない設計へ
Aさんのケースを「Aさんの確認が甘かった」で終わらせるのは、一番やってはいけない対応です。個人の注意力に依存した運用は、別のディレクターが担当したときにまた同じ失敗を起こします。
炎上を防ぐのは、根性やスキルではなく仕組みです。「決裁者を確認する」「ガントチャートを共有する」「校正はツール上に残す」「あとで対応を拾う」「振り返りをナレッジにする」——これらをプロジェクト進行のテンプレートに組み込んでしまえば、担当者が誰であっても一定の品質が保たれます。
ベイジの記事では「ミスを減らすための16の取り組み」として、個人のスキルではなく仕組みとチェックリストでエラーを減らす方法が詳しく紹介されています（株式会社ベイジ）。制作会社で働く人なら、一度は目を通す価値のある内容です。
仕組みを作るのは面倒です。でも、一度作ってしまえば、その後の全案件で効いてきます。Aさんのチームは、あの炎上の後にキックオフテンプレートを整備し、ガントチャートのクライアント共有を標準化しました。社内で言う「炎上」の頻度は、以前と比べて明らかに減ったと聞いています。
案件の情報が散らばっていると、仕組みは回らない
ここまで紹介した5つの仕組みは、それぞれ単体のツールでも実装できます。ガントチャートはmonday.comやBacklog、校正はAUNやBrushup、ナレッジはNotion——というように、ツールを組み合わせて運用することは可能です。
ただ、運用している中で壁にぶつかるのが「情報の分散」です。ガントチャートはBacklog、校正はAUN、振り返りはNotion、請求はスプレッドシート。こうなると、ある案件の全体像を把握するのに4つのツールを開かないといけません。炎上が始まっている予兆を拾うには、情報がひとつの場所に集まっている方が圧倒的に有利です。
LOGLIKEは、案件を軸にプロジェクト管理・課題管理・デザイン校正・請求書管理・ナレッジベース・ガントチャートをひとつにまとめたツールです。ガントチャートもデザイン校正もクライアントへ外部共有できて、「あとで対応」で対応漏れを拾い、ナレッジベースに振り返りを残す——この記事で紹介した5つの仕組みを、ツールを跨がずに回せる設計になっています。
正直なところ、既存のツール構成で炎上頻度が十分低く抑えられているなら、無理に変える必要はありません。ただ、「ツールが分散していて案件全体が見えない」「クライアントへの共有でアカウント招待が面倒」と感じているなら、一度試してみる価値はあります。
まとめ
炎上案件は、個人の不注意ではなく構造の問題です。決裁者の特定、マイルストーンの可視化、校正の書面化、対応漏れの拾い上げ、振り返りのナレッジ化——この5つをプロジェクトのテンプレートに組み込めば、炎上の頻度は確実に下がります。
仕組みをゼロから作るのは手間ですが、一度回り出せばチーム全員の負担が軽くなります。まずは次の新規案件のキックオフで、「決裁者は誰か」を書面で確認するところから始めてみてください。これだけでも効果を感じられるはずです。
LOGLIKEでは現在プレリリースキャンペーンを実施中です。案件の全体像を1つのツールで見たい方、クライアントとの情報共有にストレスを感じている方は、無料で試せるので使ってみてください。