稟議が止まる理由を分解する
止まる原因は「金額」より「判断材料の不足」です
稟議＝社内で投資や契約を承認するための決裁手続きです。
Webサイトのリニューアルは制作の話に見えますが、決裁者の目線では投資案件として扱われやすいです。止まりやすいポイントは、金額の大小よりも「判断に必要な材料が揃っていないこと」にあります。
たとえば、次のような状態だと稟議は進みにくくなります。
- 目的が曖昧で、何を解決する投資なのかが見えない
- 見積の前提がそろっておらず、比較ができない
- 効果が測れず、投資判断の根拠が弱い
- 検索流入や移行のリスクが怖く、失敗時の影響が読めない
- 体制と役割が不明確で、炎上の芽が残る
逆に言うと、決裁者が迷うポイントを先回りして埋められれば、稟議の通りやすさは大きく変わります。
決裁者は4つの軸で判断しています
稟議の見られ方は、突き詰めると次の4点に集約されます。
- 費用：いくらかかり、何が含まれているか
- 効果：何が改善し、どう測り、いつ判断できるか
- リスク：失敗したときの影響と、回避策があるか
- 体制：誰が責任を持ち、最後まで進められるか
ここが揃うほど、会話が感覚論から「判断」に切り替わります。
稟議に通すための前提整理
目的は「見た目」ではなく「事業の問題解決」に置きます
リニューアルでよくあるつまずきは、話の主語が「サイト」になってしまうことです。見た目を新しくすること自体は目的になりにくく、稟議では特に通りづらくなります。
目的はあくまで事業の課題に置き、サイトはその解決手段として整理します。
みやあじよでは、デザインを「問題解決」と捉え、成果は「売上」「問い合わせ」「採用」など、サイトに設定した目的の達成として考えています。
この考え方で稟議の文章を組み立てると、「なぜ今やるのか」が伝わりやすくなります。
稟議前に作る「前提シート」を1枚にまとめます
関係者の認識がズレたままだと、後半で手戻りが起きます。そこで稟議の前に、最低限の前提をA4一枚に固定しておくのがおすすめです。
- 背景：現状の課題と、放置した場合の影響
- 目的：何を改善するか（成果の方向性）
- 成功条件：何が達成できれば成功と言えるか
- 範囲：対象サイト/対象ページ、やること・やらないこと
- 制約：期限、既存システム、社内ルール、セキュリティ要件
- 決め方：意思決定者と承認フロー
KPI＝成果を測るための数値指標です。
KPIは「増やす数」だけに寄せず、「質」もセットにすると納得されやすくなります。たとえば問い合わせ件数に加え、商談化につながる条件（業種、規模、課題の明確さなど）を定義しておくイメージです。
合意形成は「順番」を決めると進みやすいです
関係者が多いときほど、全員同時に合意を取ろうとすると詰まりやすいです。
情シス（情報システム部門）＝社内ITを管轄する部門です。法務やセキュリティも含め、制約条件は早い段階で回収しておくと後戻りが減ります。
おすすめの順番は次の通りです。
- まず事業側で、目的・優先度・公開期限を固めます
- 次に情シス・法務などの制約条件を先に揃えます
- 最後に広報・営業など運用側の要望を整理して反映します
この順番が決まるだけでも、会議が「要望の出し合い」から「前提に沿った取捨選択」に変わりやすくなります。
費用の作り方と投資判断
見積が割れる理由は「前提の違い」がほとんどです
ベンダー＝制作や開発を外部委託する相手先です。
見積の差は、技術力の差というより「含まれている範囲」の違いで起きることが多いです。そこで稟議では、初期費用だけでなく運用まで含めた形で費用を分解して提示します。
TCO＝初期費用だけでなく運用費も含めた総コストです。
TCOで整理できると、決裁者は「公開後にどれだけ負担が増えるか」も含めて判断できます。
| 費用項目 | 一時費用 | 年間費用 | 根拠・備考 |
|---|---|---|---|
| 要件定義・設計 | 要見積 | — | 目的/範囲/承認フローを確定し、手戻りを減らす |
| 情報設計・デザイン | 要見積 | — | 伝える順序と導線を設計し、成果に直結させる |
| 実装・CMS対応 | 要見積 | — | CMS（コンテンツ管理システム＝ページ更新を管理する仕組み）の選定/設定を含める |
| コンテンツ整備 | 要見積 | — | 原稿作成、写真、既存ページの棚卸し・再編集 |
| 移行・検証 | 要見積 | — | URL移行、表示確認、フォーム・計測の動作確認 |
| 計測・解析設定 | 要見積 | — | CV（コンバージョン＝問い合わせ送信などの成果行動）の定義と計測設定 |
| 保守・運用 | — | 要見積 | 監視、軽微改修、更新代行の範囲を明確にする |
| 改善・追加改修枠 | — | 要見積 | 公開後の改善を前提に、予算枠を確保する |
上振れ要因は「条件」として先に書いておきます
費用が膨らむ要因を、稟議の時点で隠さずに書いておくほうが結果的に安全です。たとえば次のような項目です。
- コンテンツ追加（ページ数・導線・写真撮影など）が増える場合
- 承認者が増え、確認の往復が増える場合
- 移行対象（旧ページ、PDF、フォーム、計測）が想定より多い場合
- 既存システム連携が途中で発覚する場合
「起きたら追加になる条件」が明文化されていると、後から揉めにくくなります。
段階投資にすると稟議が通りやすくなります
全面刷新が必要でも、投資判断を一括で通すのが難しいケースがあります。そんなときは、フェーズ（段階）で区切る設計が有効です。
例として「要件定義→重要ページから公開→残りは改善しながら拡張」という形にすると、最初の決裁を軽くしつつ、次の判断をデータで行いやすくなります。
効果の見立てと成果指標の設計
効果は「何が・いつ・どう測れるか」まで落とします
稟議で強い効果は、期待の言葉ではなく「判断に足る根拠」です。
KGI＝最終的に達成したい目標指標です。KPI＝成果を測るための数値指標です。
KGI→KPI→計測方法、の順で一本化すると、説明がぶれにくくなります。
効果設計で最低限そろえておきたいのは次の3点です。
- 既存値：いまの基準（アクセス、問い合わせ、商談化など）
- 改善レバー：導線、訴求、フォーム、コンテンツのどこを変えるか
- 判定期限：公開後いつ評価するか（例：30日/90日）
| 目的 | 成果指標 | 計測方法 | 目標設定の考え方 |
|---|---|---|---|
| 問い合わせ増 | フォーム送信数、電話タップ数 | 解析ツールのイベント計測＋問い合わせ台帳 | 現状値を基準に、重要ページから段階的に改善 |
| 商談の質向上 | 有効問い合わせ率、商談化率 | フォーム項目整備＋営業の判定結果 | 欲しい条件（業種/規模など）を定義し、訴求で揃える |
| 採用の強化 | 応募数、面接到達数 | 応募フォーム＋採用管理のステータス | 流入経路別に分け、強い導線へ集中投資 |
| 工数削減 | 更新時間、問合せ対応時間 | 作業ログ＋担当者の記録 | 削減時間を見積り、優先度の根拠にする |
計測計画を稟議に含めると、決裁者が判断しやすくなります
CV＝問い合わせ送信など、成果として数える行動です。
公開後に「良かった／悪かった」の議論で終わらないよう、稟議の時点で計測計画を入れておくのが大切です。具体的には、CVの定義、公開前後で比較する指標、レビュー頻度（例：月1回）を明記します。
「投資したあとに検証できる」前提が見えるだけで、決裁者の不安が下がりやすくなります。
リスク整理と対策の作り込み
不安は隠さず、対策と担当をセットで出します
リニューアルは、検索・移行・運用の3領域でトラブルが起きやすいです。
SEO＝検索エンジン経由の流入を増やすための取り組みです。301リダイレクト＝旧URLから新URLへ恒久的に転送する設定です。SSL＝通信を暗号化する仕組みです。
稟議で強いのは「問題が起きない」と言い切ることではなく、「起き得る問題を想定し、止血できる計画がある」ことです。
| リスク | 影響 | 予防策 | 担当・確認ポイント |
|---|---|---|---|
| 検索流入の低下 | 問い合わせ/採用の減少 | URL対応表、301設定、主要ページの構造を精査 | 制作＋社内：公開前後で流入を監視 |
| 計測の欠落 | 効果検証ができない | 計測計画、受入テスト、公開前後の比較手順 | Web担当：CV発火と数値の整合を確認 |
| フォーム不達 | 機会損失 | テスト送信、通知の到達確認、代替連絡手段 | 情シス：メール設定/迷惑判定を確認 |
| 移行トラブル | 表示崩れ/停止 | 検証環境（公開前に確認する環境）での検証、切替手順書、復旧手順 | 制作＋情シス：切替リハーサルを実施 |
公開後に揉めやすいポイントは、責任分界点で先に潰します
公開後のトラブルで揉めやすいのは、「どこまでが保守で、どこからが改修か」といった線引きです。
稟議の段階で、保守範囲・対応時間・連絡経路を明記しておくと、運用が安定しやすくなります。
体制設計と進行計画
兼務体制でも回るように「判断」と「作業」を分けます
従業員10〜500名規模では、Web担当が兼務のケースも珍しくありません。そこで、社内は判断に集中し、制作側が実行に責任を持てるように役割を固定します。
PM＝進行と調整を担う役割です。
一例として、役割は次のように整理できます。
- 事業責任者：目的・優先度の最終決定
- Web担当：要望の窓口、計測、公開後改善の起点
- 情シス／セキュリティ：アカウント、サーバ、社内ルール確認
- 監修者（法務・広報など）：表現チェックと承認
- 制作側：設計・制作・検証、リスク対策の実行
マイルストーンで「承認の節目」を固定します
マイルストーン＝プロジェクトの重要な節目です。
稟議の時点で、要件確定、デザイン確定、原稿確定、受入テスト、公開判定、公開後レビューの承認者を明記します。受入テスト＝納品物が要件を満たすかを発注側が確認するテストです。
承認の節目がないと、後半で要望が増え続け、費用と納期が読めなくなりがちです。
要件定義の進め方と合意形成
要件定義は「要望を翻訳し、優先順位を決める工程」です
要件定義＝必要な要望を仕様として整理し、関係者で合意する工程です。
ここが曖昧だと、見積条件がそろわず、比較も難しくなります。
みやあじよが大切にしているのは、依頼者の中にある「やりたいけれど言葉にしきれていないこと」を整理し、伝わる形に落とし込むことです。稟議では、この「言語化」がそのまま説得力になります。
進め方は“順番”を守ると、手戻りが減ります
おすすめの流れは次の通りです。
- 現状棚卸し：ページ、導線、問い合わせ、更新フローを整理します
- 重要導線の定義：ユーザーシナリオ（訪問者が目的達成するまでの行動の流れ）を描きます
- コンテンツ方針：残す／統合／作るを決め、原稿責任者を置きます
- 非機能要件を整理します：非機能要件＝表示速度やセキュリティなど、機能以外の品質条件です
- 形にして合意します：サイトマップ＝ページ構成の一覧です、ワイヤーフレーム＝ページの骨組みを示す設計図です
この段取りができると、提案の比較と稟議の説明が一気にラクになります。
ベンダー選定と乗り換えの評価軸
比較は「同じ条件」を作ってから始めます
提案資料の見栄えや価格だけで選ぶと、公開後に「想定外」が出やすくなります。稟議を通しやすくする意味でも、比較軸を先に固定し、各社の提案を同じ物差しで評価できる状態を作ることが大切です。
RFP＝ベンダーに提案を依頼するための文書です。
SOW＝作業範囲を文章で定義したものです。
SLA＝保守などの対応品質を取り決める合意です。
| 評価軸 | 重み | ベンダー評価 | コメント |
|---|---|---|---|
| 目的理解と提案の筋 | 高 | 1〜5 | 課題→打ち手→KPIまで一貫しているか |
| 要件定義の進め方 | 高 | 1〜5 | 合意形成、承認フロー、成果物が明確か |
| 移行・リスク対策 | 高 | 1〜5 | URL移行、検証、復旧手順まで含むか |
| 運用設計と改善体制 | 中 | 1〜5 | 公開後の改善サイクルと役割が示されているか |
| 見積の透明性 | 中 | 1〜5 | 含む/含まない、上振れ条件が明記されているか |
| コミュニケーションとPM | 中 | 1〜5 | 会議設計、議事録、進行管理の実務が回るか |
乗り換え時の引継ぎは、範囲を明記しておくと安全です
ベンダー変更では、制作物だけでなく運用資産の引継ぎが論点になります。稟議の段階で、最低限ここまでを範囲として書いておくのがおすすめです。
- ドメイン管理、DNS、SSL証明書の管理主体
- サーバ・CMSのアカウント、権限、バックアップ方針
- 解析ツールやタグの設定、広告連携の引継ぎ
- 原稿、画像、デザインデータ、ソースの受領形式と権利
- 公開当日の切替手順、復旧手順、連絡体制
DNS＝ドメイン名と接続先を結びつける仕組みです。
CMS＝ページ更新を管理する仕組みです。
稟議書の章立てテンプレ
「判断しやすい順」に並べると通りやすくなります
稟議書は説明資料ではなく、判断のための資料です。決裁者が迷いにくい順番で並べるだけで、読みやすさが上がります。
- 背景：現状課題と放置した場合の影響
- 目的：何を解決し、どんな成果を狙うか
- 実施内容：範囲（やること／やらないこと）と成果物
- スケジュール：マイルストーンと承認者
- 費用：初期・年間・上振れ条件
- 効果：KPIと計測計画
- リスク：想定リスクと対策・担当
- 体制：社内／外部の役割分担と意思決定方法
- 比較：ベンダー比較表と選定理由
- 決裁事項：予算、期間、委託範囲、次の判断タイミング
特に「上振れ条件」と「次の判断タイミング」を書けると、決裁者は“引き返せる設計”として受け取りやすくなります。
相談で支援できる領域
意思決定に必要な材料を、短い距離でそろえます
稟議で詰まりやすいのは、「目的が言語化できない」「比較条件が揃わない」「公開後の運用まで線引きできていない」といった整理の部分です。
みやあじよは、整理しきれていない魅力や論点を言語化し、伝わるストーリーに組み立てることも含めてデザインだと考えています。
支援できる領域は、主に次の4つです。
- 要件定義支援：目的・範囲・優先度・承認フローを整理し、見積条件を統一します
- Web制作・リニューアル：設計から公開まで、成果とリスクの両面で進めます
- PM支援：会議設計、進行管理、合意形成、手戻り抑制を担います
- 運用設計：計測計画、更新フロー、改善サイクルを設計します
まとめ
リニューアルの稟議を通すコツは、「熱量」より「判断材料」です。費用・効果・リスク・体制を同じ粒度で整理し、比較できる形にしておくと、社内の意思決定は前に進みやすくなります。
要件定義と比較軸を先に固めるほど、見積のブレと手戻りが減り、段階投資もしやすくなります。稟議資料づくりと並行して、要件定義・ベンダー選定・運用設計までまとめて整理したい場合は、要件定義支援やPM支援から入ると進行が安定しやすいです。
