「デザインは洗練されていたのに、社内の意見がまとまらずリニューアルが頓挫した」そんなWeb担当者からの嘆きを聞くとやるせない気持ちになります。
ディレクター目線からプロジェクトが炎上する原因は、技術やクリエイティブの質ではなく合意形成プロセスにあります。ですが、これからご紹介する5つのステップを押さえれば、対立の芽を事前に摘み取り、本来注力すべき成果創出に集中できるので、参考にしていただければ幸いです！

Step1｜要件を“見える化”して共通言語を作る

まず「誰が・何を・いつまでに」を一枚の要件定義シートに整理。KGI・KPI・必須機能・Nice‑to‑have機能を色分けし、SlackやNotionで常に最新版を確認できる状態にします。曖昧な要望を日本語のまま放置せず、文章＋テーブル＋ワイヤーフレームの三点セットで、部門間の認識をズラさないことが重要です！

Step2｜ステークホルダーを洗い出し、影響度で優先順位づけ

リニューアルは全社プロジェクト。情報システム部や法務、営業のフィールドセールスなど影響を受ける部署を早期にリスト化し、「影響度×意思決定力」のマトリクスで☆3段階評価。
☆3（高影響×高決定力）は制作定例に招き、☆1は月次報告に留めると会議コストが半減します。

Step3｜“静止画”より“動く”プロトタイプで先回り合意

Figmaでクリックプロトタイプを制作し、実際の操作感を社内に体験させます。人は文章より体験で判断する生き物。ここで意見を吸い上げれば、実装フェーズでの手戻り工数を平均40％削減できます。レビューは「改善点」「懸念」「解決策」の3カラムシートで集約し、責任者と〆切を明記しておきます。

Step4｜リスクとコストはリアルタイムで共有・修正

要件変更はコストを伴います。ガントチャートと連動したリスク＆コスト早見表を常設し、「追加リクエスト→即コスト提示→承認or却下」を短時間で回すことで「言った／聞いてない」論争を防止。可視化された数字が、感情的な衝突を理性的な判断に変えます。

Step5｜リリース後24時間以内のフィードバック文化を定着

公開＝ゴールではありません。アクセス解析の初期データと社内外の声をまとめ、リリース翌日までに「Day 1レポート」を制作会社へ共有。早期の小改善が「バグ報告祭り」を防ぎ、プロジェクトの成功体験を社内に浸透させます。次回リニューアルの心理的ハードルも下がり、継続的改善のループが生まれます。

---

炎上は偶然ではなく、プロセスの欠陥で起こります。今回紹介した5ステップは、「見える化」「優先順位」「体験共有」「数字管理」「初期改善」というシンプルな原理で構成されています。まずは要件定義シートとステークホダーマップを作成し、来週の定例に持ち込むと、成果を語れるリニューアルを実現できます。