Fubuki Journal

リリース直前の「鶴の一声」で全て白紙に…。Web担当者を絶望させる「ちゃぶ台返し」を、仕組みで防ぐ方法

2025年12月18日

公開予定日まであと1週間。最終確認の定例会議で、それまで順調だと思われていたプロジェクトに激震が走る。

「うーん、やっぱりこのデザイン、なんか違うんだよね。もっとこう、インパクトが出ないかな？」

決裁権を持つ役員の一言。通称「鶴の一声」。凍りつく会議室。青ざめるWeb担当者。

これまで積み上げてきた数ヶ月の議論、ワイヤーフレーム、デザイン調整、実装作業……。それら全てが、たった一言で白紙に戻される瞬間です。

Web担当者にとって、これほど絶望的な状況はありません。徹夜での修正対応、関係各所への謝罪、スケジュールの再調整。何より、「これまでの努力は何だったのか」という徒労感が、担当者の心を深く傷つけます。

いわゆる「ちゃぶ台返し」は、なぜ起こるのでしょうか？そして、どうすれば防げるのでしょうか？

「あの人はいつも土壇場でひっくり返すから…」と個人の資質の問題にして諦めてはいけません。これは、プロジェクト管理における構造的な欠陥が引き起こす問題だからです。

今回は、Web担当者を絶望の淵に追いやる「ちゃぶ台返し」を、精神論や根回しではなく、プロジェクト管理の「仕組み」で防ぐための具体的な方法を解説します。

なぜ「ちゃぶ台返し」は起こるのか？

対策を立てる前に、敵を知る必要があります。決裁者は、Web担当者を困らせようとして悪意を持ってちゃぶ台を返しているわけではありません（多くの場合）。彼らなりの理由や不安があるのです。

主な原因は以下の3つに集約されます。

1. プロセスが見えていない（情報共有不足）

Webサイト制作は、家を建てるのと似ています。基礎工事（要件定義・設計）が終わって骨組み（ワイヤーフレーム）ができ、壁紙（デザイン）を貼っている段階で「やっぱり間取りを変えたい」と言われても、簡単には対応できません。

しかし、Webに詳しくない決裁者は、この「後戻りできないポイント」を理解していません。「デジタルなんだから、ちょこっと直すだけでしょ？」と安易に考えているケースが多々あります。

2. 議論が抽象的すぎた（言葉の認識ズレ）

初期段階で「かっこいい感じで」「スタイリッシュに」といった抽象的な言葉だけで合意形成をしてしまうと危険です。あなたの思う「かっこいい」と、決裁者の思う「かっこいい」は、全く別物である可能性が高いからです。具体的なビジュアルがないまま進んでしまうと、最終成果物を見た時に「思っていたのと違う」という反応を引き起こします。

3. 決裁者自身の不安

プロジェクトが大詰めになるにつれ、決裁者もプレッシャーを感じ始めます。「本当にこれで成果が出るのか？」「競合他社より見劣りしないか？」。その不安が、土壇場での「もっと何とかできないか」という指示に繋がってしまうのです。

悲劇を防ぐ3つの「仕組み」

「ちゃぶ台返し」は、担当者のコミュニケーション能力不足のせいではありません。合意形成のプロセスが仕組み化されていないことが原因です。以下の3つの仕組みを導入することで、リスクは劇的に低減します。

仕組み1：後戻りできない「関所（マイルストーン）」を設ける

プロジェクトを一本道で進めるのではなく、要所要所で必ず承認印をもらう「関所（マイルストーン）」を設けましょう。

関所A：要件定義書（プロジェクト憲章）の承認
- サイトの目的、ターゲット、成果指標（KPI）、予算、納期、絶対に譲れない条件などを言語化し、文書で合意します。「ここに書いてあること以外は、追加要望となります」という共通認識を最初に作ります。
関所B：ワイヤーフレーム（構成案）の承認
- デザインに入る前に、骨組みの段階で情報設計や要素の配置を確定させます。「デザインフェーズに入ってからの構成変更は、追加コストとスケジュールの遅延が発生します」と明確に伝え、承認を得ます。
関所C：デザインカンプの承認
- 実装（コーディング）に入る前の最終デザイン確認です。ここでOKが出たら、これ以降のビジュアル変更は原則不可とします。

このように段階的に合意形成を行い、承認の証拠（メールや議事録）を残しておくことで、「あの時OKしましたよね？」と冷静に事実を提示できるようになります。

仕組み2：抽象的な言葉を禁止し、「ビジュアル」で対話する

「かっこいい」「使いやすい」といった言葉は、人によって解釈が異なります。初期段階から、言葉だけでなく具体的なビジュアルを用いて認識をすり合わせましょう。

ムードボードの活用: ターゲットとする雰囲気や世界観に近い他社サイト、画像などを集めた資料を作成し、「目指す方向性」を視覚的に共有します。
早期のプロトタイピング: HTMLで組む前でも、デザインツール（FigmaやAdobe XDなど）を使って「画面遷移がわかるモックアップ」を作成し、実際に触ってもらいながら議論します。HubSpot CMSなどを導入していれば、早期に実際のブラウザで表示されるテストページを作成するのも非常に有効です。百聞は一見にしかず。動くものを見せることで、認識のズレを早期に発見できます。