Web制作の要件定義｜責任分界・未決事項・受入条件の確認表

Web制作会社を決めた後も、目的やページ、機能を口頭で伝えただけでは制作要件は確定しません。「お知らせを更新できる」「スマートフォンに対応する」「問い合わせを増やす」といった言葉は、人によって完成像が異なるからです。曖昧なままデザインや実装へ進むと、後から必要条件が見つかり、追加費用や公開延期につながります。

要件定義で作るのは分厚い仕様書ではなく、依頼者と制作会社が同じ基準で「作る範囲」「誰が決めるか」「何をもって完成とするか」を判断できる一組の記録です。この記事では、要件の抜け・ズレを防ぐため、小規模・中規模のWebサイトで使える要件一式、責任分界、未決事項台帳、受入条件を順に整理します。制作会社の比較や選び方はホームページ制作会社の選び方へ、発注後の全工程はWeb制作の依頼手順へ分け、本記事は発注先が決まった後の実務に限定します。

要件定義は「選定後・制作前」の判断記録

見積書は金額と前提を確認する資料、契約書は取引条件を定める資料、要件定義は完成物と確認方法を具体化する資料です。三つは役割が異なります。見積段階の仮定をそのまま確定事項にせず、発注後に実データ、既存ページ、運用体制、権限、法務条件を確認して更新します。見積条件を比べる段階はホームページ制作見積の比較表へ分け、本記事では会社選定後の確定作業だけを扱います。

要件は依頼者だけ、制作会社だけで決めるものではありません。事業上の目的、掲載内容、公開判断は依頼者が責任を持ち、実現方法、工数、技術上の制約は制作会社が説明します。どちらかが推測で埋めず、決定・提案・確認・承認の担当を分けることが出発点です。

要件一式は8項目を一つの索引で管理する

資料が複数に分かれても、最新版へたどれる索引を一つ用意します。ファイル名だけでなく、版、更新日、責任者、承認状態、関連する未決事項を記録します。要件本文と会議メモが食い違ったとき、どちらが正式か迷わない状態にします。

要件の区分	最低限残す内容	確認できる証拠
目的・対象者	解決する課題、優先する利用者、対象外	目的文、優先順位、非対象一覧
範囲	対象ページ、機能、言語、端末、外部サービス	サイト構成、機能一覧、対象外一覧
コンテンツ	原稿・画像の作成者、期限、権利、確認者	原稿台帳、素材台帳、承認履歴
機能要件	入力、処理、通知、検索、更新、権限	画面・操作・結果の組合せ
非機能要件	性能、可用性、セキュリティ、保守、対応環境	数値、対象範囲、試験方法
移行・SEO	旧新URL、転送、計測、構造化データ、公開手順	URL対応表、確認結果、戻し方
責任分界	決定、準備、制作、確認、承認、運用の担当	担当表、正式窓口、期限
受入条件	確認項目、合格基準、重大度、残課題の扱い	試験表、結果、公開承認記録

国の情報システム向け資料は規模が異なりますが、機能、画面、データ、外部インタフェース、ユーザビリティ、アクセシビリティなどを漏れなく確認する観点として使えます。デジタル庁の要件定義に関する解説書をそのまま転用するのではなく、自社サイトに必要な項目だけを採用します。

目的・対象者・非対象を同時に決める

目的は「新しいサイトを作る」ではなく、公開後に誰の判断や行動をどう変えるかで書きます。たとえば「初回相談の前に対応地域と支援範囲を確認できる」「採用候補者が仕事内容と応募条件を比較できる」のように、利用者と判断材料を一文にします。問い合わせ件数だけでなく、不要な問い合わせの減少、更新時間、情報の鮮度も評価対象にできます。

同時に、今回優先しない利用者、作らない機能、保証しない成果を書きます。目的を増やし過ぎると全ページが重要になり、判断基準が働きません。要望が目的に貢献しない場合は、将来候補へ移すか対象外とします。目的、優先対象、非対象の三点がそろうと、デザインの好みではなく事業上の必要性で採否を説明できます。

ページ・URL・素材は実物を一覧にする

「既存サイトを移す」という一文では、残すページ、統合するページ、廃止するページ、転送先が決まりません。現行URL、新URL、扱い、担当、原稿、画像、確認者を一行ずつ記録します。リニューアル時の資料集めはホームページリニューアル前の資料一覧と分担し、要件定義では採用する資産と新しいURLの確定に集中します。

写真や図版は、提供者、利用許諾、人物の同意、掲載期限、代替テキストの担当まで確認します。仮画像や仮原稿が残る場合は「後で差し替え」ではなく、差し替える人と期限を未決事項台帳へ入れます。ドメイン、サーバー、解析、フォーム通知先などの権限も、所有者と作業者を区別して一覧化します。

機能要件は操作と結果、非機能要件は数値で書く

機能要件は「できる」だけでなく、誰が、どの画面で、何を入力し、何が起き、失敗時にどう見えるかを書きます。問い合わせフォームなら必須項目、確認画面、送信先、自動返信、同意、迷惑送信対策、保存有無、エラー表示までが一組です。更新機能なら編集できる項目、公開権限、予約、プレビュー、履歴も確認します。

非機能要件は「速い」「安全」「使いやすい」を避け、対象ページ、測定条件、基準、確認時期を決めます。対応ブラウザ、表示速度、バックアップ、障害時連絡、保守時間、権限、ログ保存などを必要な範囲で数値化します。すべてを最高水準にすると費用が膨らむため、事業への影響から優先順位を付けます。

受入条件は制作前に試験できる文章へ変える

受入条件は納品時のチェックリストではなく、制作範囲を決める要件の一部です。「適切に表示される」では合否を決められません。操作、入力データ、期待結果、対象環境、証拠を一行にし、制作前に依頼者と制作会社が試験可能か確認します。

曖昧な要望	受入可能な条件の例	残す証拠
フォームが使える	必須漏れは送信されず、正常送信は指定2宛先へ届く	正常・異常の送信記録
スマホ対応	合意した端末幅で横スクロールがなく主要操作ができる	対象幅ごとの確認表
更新しやすい	編集者権限で記事作成、プレビュー、予約公開ができる	操作結果と権限表
旧URLを引き継ぐ	対象URLが対応先へ恒久転送され、リンク切れがない	URL対応表と応答確認
アクセシブル	合意した基準・対象ページ・試験方法を満たす	自動・目視・操作確認

合否だけでなく、不具合の重大度も先に決めます。送信不能、決済不能、個人情報の誤送信などは公開を止める重大事項、軽微な文字ずれは期限付きで公開後対応など、事業影響で区分します。残課題を黙って受け入れず、内容、回避策、修正期限、費用、責任者を記録します。

責任分界は作業担当と承認者を分ける

依頼者は事業要件と掲載内容を決め、制作会社は実現方法と制約を説明します。原稿を制作会社が書いても、事実確認と掲載承認まで委ねたことにはなりません。逆に、依頼者が技術手段を細かく指定すると、制作会社が品質責任を持てない場合があります。作る人、確認する人、最終決定する人を別欄にします。

対象	依頼者	制作会社	承認の証拠
目的・優先順位	決定	整理・影響説明	目的文と決定者
原稿・事実	提供・事実確認・承認	編集・掲載	承認版と日付
設計・実装	要件確認	提案・制作・技術確認	設計版とレビュー記録
法務・個人情報	運用判断・承認	実装・注意点提示	確認者と対象ページ
受入・公開	試験参加・公開決定	試験支援・修正・公開作業	結果と公開承認
公開後運用	運用責任・権限保管	契約範囲の保守	引渡し一覧と連絡先

IPAの「ユーザのための要件定義ガイド」も、利用者側が要件定義へ主体的に関わる重要性を示しています。制作会社へ丸投げするのではなく、依頼者が判断すべき事項を残し、制作会社には判断材料と実現案を求めます。

アクセシビリティ・安全・個人情報を別紙にしない

アクセシビリティは公開直前の見た目確認ではありません。キーボード操作、見出し構造、画像の代替、文字と背景のコントラスト、入力エラーなど、設計・原稿・実装にまたがります。基準を決める際はW3CのWCAG 2.2と、実務向けに整理されたデジタル庁のウェブアクセシビリティ導入ガイドブックを参照し、対象ページと確認方法を合意します。

問い合わせで個人情報を扱うなら、取得項目、利用目的、保存場所、保存期間、閲覧権限、削除、委託先、事故時の連絡を決めます。判断には個人情報保護委員会の通則編ガイドラインを参照し、自社の取扱いを確認します。セキュリティ要件は「十分に安全」ではなく、認証、権限、入力検証、ログ、更新、脆弱性対応などを選びます。Webアプリケーションの確認観点にはOWASP ASVSも使えますが、サイトの機能とリスクに合う範囲を制作会社と決めます。

未決事項と変更要求を同じ表で混ぜない

未決事項は、要件を決めるために不足している判断です。変更要求は、いったん合意した要件を変える提案です。両者を同じメモに入れると、追加費用の対象か、当初範囲の確認か判断できません。未決事項には質問、選択肢、判断者、期限、決まらない場合の扱いを、変更要求には変更理由、影響するページ・機能、費用、納期、採否、承認者を記録します。

口頭やチャットで出た要望も正式な台帳へ戻します。影響確認前に制作へ入れず、「変更しない」「次期へ送る」判断も履歴として残します。期限に間に合わない未決事項は、仮定で進める、対象外にする、工程を止めるのいずれかを責任者が選びます。企業サイト全体の失敗を防ぐ停止条件は企業サイト制作の失敗防止で補完します。

受入から引渡しまでを要件の範囲に含める

公開は制作の終点ではなく、運用へ責任を渡す工程です。受入試験、公開判定、公開作業、公開直後の確認、残課題、権限とデータの引渡しまでを要件へ含めます。サーバーやドメインを移す場合はホームページ移管の手順で所有者と作業順を確認します。

段階	確認するもの	進行条件
受入準備	試験環境、試験データ、担当、日程	要件と試験項目が対応
受入試験	主要操作、表示、権限、通知、移行、計測	結果と不具合重大度を記録
公開判定	重大不具合、残課題、戻し方、連絡体制	公開責任者が承認
公開直後	主要URL、フォーム、解析、転送、検索設定	異常時の停止・復元判断が可能
引渡し	アカウント、データ、ライセンス、手順、履歴	依頼者が受領し保管先を確認
運用移行	更新担当、保守範囲、連絡先、初回点検日	公開後の担当が作業できる

URLを変える場合は、旧新URLの対応、恒久転送、内部リンク、サイトマップ、検索状況の確認が必要です。Google検索セントラルのURL変更を伴うサイト移転を参照し、対象と確認担当を決めます。WordPressでは管理者、編集者などの権限が異なるため、WordPress公式の権限と役割を基に、日常更新に必要な最小権限と管理者アカウントの保管者を確定します。