準備のゴールは「当日決める論点を減らす」こと

事前準備は、資料を完璧に揃えることが目的ではありません。当日の議論を“価値の高い論点”に集中させるために、現状と制約を最低限そろえる作業です。

最低限そろえたい材料

BtoBサイトで、意思決定が速くなる材料は次のとおりです。

• 現状の目的と課題（箇条書きで可）：問い合わせが少ない／採用の母集団が弱い 等
• 主要な数値の現状：アクセス、問い合わせ数、応募数、商談化の流れ（分かる範囲で）
• コンテンツ棚卸し：残す／直す／捨てるの仮分類（ページ一覧があれば十分）
• 既存の運用実態：誰が、どの頻度で、何に困っているか
• 関連システム一覧：フォーム、会員、採用応募など（名称だけでも）

数値が無い場合は、仮説で進めて問題ありません。重要なのは「後で測れる形」にすることです（測り方はPart 2以降で具体化します）。

事前に決めておくと揉めにくいこと

• 参加者の意思決定権の範囲（その場で決められる／持ち帰りが必要）
• “今回やらないこと”の仮置き（優先度が低い要望を一旦退避させる）
• 予算の考え方：上限固定か、優先度に応じて可変か

参加者設計と役割（経営・事業・情報システム・現場・進行役）

欠けると止まりやすい4ロール

ステークホルダー＝意思決定や影響を受ける関係者です。ワークショップは関係者を増やすほど良いわけではなく、「決める人」と「回す人」が揃うかが重要です。

• 意思決定者（経営）：目的の優先順位と投資枠を決める
• 事業責任者：提供価値と導線（何を強く打ち出すか）を決める
• 情報システム責任者：セキュリティ、権限、移行、連携の前提を握る
• 運用の実務者（Web担当／現場）：更新フローと負荷の現実を提示する

進行役は「中立で整理できる人」を置く

ファシリテーター＝議論を整理して合意形成を支える役割です。社内で担う場合もありますが、利害が強い部署が進行役だと、結論が偏ることがあります。進行役は、論点の抜け漏れを防ぎ、決まったことを“成果物”に落とすところまで責任を持つのが理想です。

当日の進め方（アジェンダ例・論点設計・合意形成のコツ）

当日の成否は「話し合った」ではなく「決めて、残した」で決まります。特にベンダー変更を伴うリニューアルでは、途中で人が入れ替わっても迷子にならないよう、意思決定の根拠を残す設計が重要です。

当日の前提ルール（まず最初に宣言する）

• アジェンダ＝会議の進行表として、時間配分を最初に固定する
• タイムボックス＝時間枠を区切って結論を出す進め方で、脱線を防ぐ
• 決定ログ＝「決まったこと／理由／前提／宿題」を1枚にまとめ、会の最後に読み上げて合意する
• 駐車場リスト＝今回扱わない論点を一時的に置くリストで、議論の交通整理に使う
• ログ＝操作やエラーの記録で、運用・保守の判断材料になる（非機能要件で重要）

「言葉で話せるようにまとめられない場合はコンセプトが固まっていない」という考え方の通り、見た目の議論より先に“言語化できているか”をチェックします。みやあじよ　サイト制作方針 (1)

議論の順番はWHY→WHAT→HOW

5W1H＝When/Where/Who/What/Why/Howの観点で整理する方法です。
当日は特にWhy（なぜ）→What（何を）→How（どうやって）の順で進めると、好みや思い付きに流れにくくなります。

当日アジェンダ例（半日モデル）

セッション	目的	進め方	成果物
0.開始・目的確認	何を決める会かを揃える	目的・優先順位・制約を読み上げ	今日のゴール宣言
1.現状と課題	事実と仮説を切り分ける	データ＋現場感を共有し、課題を整理	課題リスト
2.ターゲットと提供価値	誰に何を約束するか	強み候補を比較し、一文に圧縮	価値の一文
3.導線とコンテンツ	何を増やす／減らすか	重要導線を1〜3本に絞る	優先導線
4.要件と優先度	何を作るかの骨格	要件を分類し、優先度を付ける	要件一覧（暫定）
5.体制・次アクション	誰が何をいつまでに	宿題の担当と期限を決める	決定ログ／宿題

合意形成を進めるコツ（揉めやすい場面のさばき方）

• 意見が割れたら「目的に近いのはどちらか」で比較し、好みの議論にしない
• その場で決められない場合は「判断材料」と「期限」を決めて宿題化する
• 参加者の発言量が偏るときは、部門ごとに“必ず一言”のラウンドを作る
• 全員が同意できなくても「反対理由が解消される条件」を言語化して次へ進む
• 終了時に“今日決めたこと”を読み上げ、認識ズレをその場で潰す（後工程の手戻り防止）

成果物（アウトプット）の作り方（要件一覧・優先度・非機能要件）

ワークショップの成果物は、見積とベンダー比較に使える粒度が必要です。理想は「この資料を渡せば、各社が同じ前提で提案できる」状態です。

成果物の最小セット（1〜2枚から始める）

• 目的とKGI（最終的に達成したい成果指標）のたたき台
• スコープ（今回やる範囲）と“やらないこと”
• 要件一覧（機能／コンテンツ／運用）と優先度
• 制約条件（納期、予算枠、体制、既存システム）
• 未決事項と確認先（誰に何を確認するか）

要件一覧の作り方（分類→言い切り→優先度）

要件は「〜できる」「〜したい」だけで終わらせず、判断できる形に整えます。

• 分類：コンテンツ、導線、フォーム、管理、運用、連携などに分ける
• 言い切り：対象ユーザー／目的／完了条件まで書く
• 優先度：MoSCoW＝Must/Should/Could/Won’t（今回はやらない）で整理する
• 前提：不確実なものは“仮”と明記し、確定条件（いつ・誰が・何を）を宿題にする

優先度を決める簡易フレーム（Impact×Effort）

マトリクス＝2つの軸で分類する表です。影響度（目的への寄与）と工数（作る大変さ）で並べると、議論が収束しやすくなります。

• 影響度が高く工数が低い：最優先（早く効く）
• 影響度が高く工数が高い：段階的に実施（フェーズ分け）
• 影響度が低く工数が低い：余力枠
• 影響度が低く工数が高い：今回やらない候補

非機能要件の最低ラインを置く

非機能要件は後回しにされがちですが、ベンダー変更ではここが事故の起点になります。

• パフォーマンス＝表示速度や同時アクセス時の安定性などの性能
• セキュリティ：権限、ログ、脆弱性＝攻撃に悪用される弱点への対応方針
• アクセシビリティ＝年齢や障害の有無に関わらず利用できる設計
• 運用性：更新のしやすさ、担当者が替わっても回るか

成果・KPI設計（目標、指標、運用で追える形への落とし込み）

KPIは増やすほど良いわけではなく、「誰が、どの頻度で、見て動けるか」が設計の中心です。

経営の合意を作る“指標の階段”

• KGI：最終成果（例：問い合わせ数、応募数、商談化率＝問い合わせが商談に進む割合）
• KPI：途中のプロセス（例：重要ページ閲覧数、フォーム到達数、資料ダウンロード数）
• 先行指標：早く変化が見えるもの（例：回遊、滞在、検索流入の増減）

計測と運用までセットで決める

• 計測設計＝どこで何を記録するかを決めること（イベント＝ユーザー行動を計測する記録項目、目標など）
• CRM＝顧客情報を管理する仕組みと連携する場合は、入力項目や重複管理のルールも決める
• レポート頻度（週次／月次）と、見る人・改善アクションの持ち主を決める
• まずはKPIを3〜5個に絞り、改善が回る形にしてから増やす

費用・投資判断の作り方（概算見積、TCO）

この段階で“正確な金額”は出ません。代わりに、見積がブレる原因を潰し、レンジで判断できるようにします。

概算見積の考え方

概算見積＝要件が固まり切る前に、範囲と前提を置いて出す費用レンジです。
ブレを減らすポイントは「ページ数」よりも「作業の種類」を揃えることです。

• 情報設計：構成・導線の設計
• デザイン：テンプレ化の範囲、独自性の度合い
• 実装：フォーム、検索、会員、連携などの複雑さ
• 移行：既存ページ、データ、画像、リダイレクト＝古いURLから新しいURLへ自動転送する仕組みの量
• 運用：更新権限、承認フロー、保守の範囲

フェーズ分けで投資判断しやすくする

フェーズ＝段階のことです。全てを一度に詰め込まず「必須（Phase1）」「伸ばす（Phase2）」に分けると、予算枠の中で合意が取りやすく、スケジュールも守りやすくなります。

TCOで見る（作って終わりにしない）

TCO＝導入後の運用費も含めた総コストです。初期費用だけで比較すると、運用で逆転します。

• 月次の保守範囲（障害対応、軽微改修、セキュリティ更新）
• コンテンツ更新の内製／外注の比率
• 社内工数（運用担当の稼働）もコストとして見える化する

見積を比較するときは、初期費用・月次費用・社内工数を同じ軸に並べ、一定期間（例：1〜3年）の合計で見ると判断がぶれにくくなります。

リスク・トラブル予防（変更管理、権限移管、セキュリティ、運用の落とし穴）

ベンダー変更を伴うリニューアルで揉めやすいのは、「仕様」よりも「決め方」と「引き継ぎ」です。みやあじよの方針でも、目的から逆算し“やること／やらないこと”を明確にして判断のブレを減らすことを重視しています。

変更管理を先に決める

変更管理＝途中で変更が出たときに、影響（費用・納期・品質）を見える化し、合意してから反映するルールです。
よくある失敗は、口頭の「ついでに」で積み上がり、誰も全体像を把握できなくなることです。

• 変更の入口：誰が要望を出せるか（窓口を一本化）
• 判断基準：目的への寄与が高いか／Phase2でよいか
• 合意の形式：メールでも良いので「内容・理由・費用・納期」を残す
• 優先度の再整理：追加するなら、何を外すかをセットで決める

権限移管と“持ち物”を洗い出す

権限移管＝ドメイン、サーバー、各種ツールなどの管理権限を、適切な担当へ引き継ぐことです。
ここが曖昧だと、公開直前に「ログインできない」「設定が触れない」が発生します。

最低限、次を一覧化します。

• ドメイン管理（DNS＝ドメインの行き先を決める仕組みの設定元）
• サーバー／ホスティング（契約者、支払、更新日）
• CMS＝更新システム（管理者アカウント、権限設計）
• フォーム（通知先、保存先、スパム対策、個人情報の扱い）
• 計測（タグ管理、目標設定、権限）
• メール（送信ドメイン認証、通知が迷惑メールにならない設定）

「誰が」「どのIDで」「どこに保管して」「退職・異動時はどうするか」まで決めると、運用の属人化が減ります。

セキュリティと法務を“要件”として扱う

セキュリティは後付けが難しいので、最低ラインを要件に含めます。

• アカウント：多要素認証（追加の確認手段で乗っ取りを防ぐ仕組み）の方針
• 権限：更新者・承認者・管理者の分離
• ログ：いつ誰が何をしたか追えるか
• 収集：個人情報の取り扱い、保存期間、委託範囲

公開前後の落とし穴を避ける

• リダイレクト＝旧URLから新URLへ転送する設定を、重要ページから優先して整備
• 受入テスト（UAT＝利用部門が実運用目線で確認するテスト）を実施し、合否基準を明文化
• 公開直前の更新凍結（いつから編集を止めるか）を決め、差分対応の手順を用意

ベンダー選定への落とし込み（RFP＝提案依頼書、評価軸、乗り換え計画）

成果物を“同じ土俵の提案”に変換する

RFP＝提案依頼書（同じ前提で提案してもらうための依頼資料）です。
ワークショップの成果物（目的・スコープ・優先度・制約）をRFPに落とすと、見積と提案のブレが減り、比較がしやすくなります。

RFPに入れると効果的な要素

• 目的と優先順位（何を最重視するか）
• 今回の範囲（やる／やらない）
• 必要機能と優先度（Must/Should/Could）
• 非機能要件の最低ライン
• 運用の前提（更新体制、頻度、承認フロー）
• 移行対象（ページ、データ、フォーム、計測）
• 納期の制約と体制（誰が意思決定するか）

表C：ベンダー比較の評価シート（たたき台）

評価軸	確認観点	質問例	判断メモ
要件理解と提案力	目的と課題を踏まえているか	今回の目的に対し、最優先の打ち手は何ですか
進行・PM力	体制、会議設計、合意形成	変更管理はどう運用しますか
運用設計	更新しやすさ、引き継ぎ	運用担当が替わっても回る設計はどう担保しますか
移行とリスク対応	権限・データ・SEOの観点	リダイレクトと計測の移行計画をどう出しますか

PM＝プロジェクト全体の進行・品質・コストを管理する役割です。
SEO＝検索経由の集客を最適化する取り組みです。

乗り換え計画は「契約・成果物・引き渡し条件」まで決める

比較で見落とされがちなのが、納品後の“手元に残るもの”です。

• 成果物：要件、設計資料、デザインデータ、設定情報の範囲
• 引き渡し条件：何を満たしたら完了か（検収＝納品物の受け入れ判断）
• アカウント：契約主体、権限の持ち方、緊急時の連絡経路
• 運用：保守範囲、軽微改修の扱い、優先対応の条件

制作は「目的達成のための手段」です。見た目の好みだけで選ぶと、運用・体制・改善が止まりやすくなります。目的から逆算し、判断軸を固定して選定するのが安全です。

まとめ

要件定義ワークショップの価値は、社内の意見を集めることではなく、経営判断に必要な材料（費用・効果・リスク・体制）を「決めて、残す」ことにあります。
目的と優先順位、スコープ、運用体制、変更管理、権限移管までを先に整えると、見積比較とベンダー選定が現実的になり、リニューアル後も改善が回りやすくなります。

要件定義の設計、ワークショップの進行、RFP作成、ベンダー比較、移行・運用設計まで一気通貫で整理したい場合は、要件定義支援やPM支援として切り出して進める方法も有効です。