Webサイト制作の要件定義書の確認項目
プロジェクトのキックオフ前後に作成する要件定義書。確認の抜け漏れを最小限に抑えるには、どのようなことを記載しておくべきか。そして、メンバーへのスムーズな共有と、その後の円滑なプロジェクト進行のための、良い要件定義書とはどのようなものだろう。自分たち用のメモも兼ねて「Webサイト制作プロジェクトの要件定義書」の確認項目をnoteに整理してみます。
1. プロジェクト概要
1-1. 背景
プロジェクトを発案するに至った背景です。現状の課題、ビジネス要件の変化、ユーザーの変化、社会的要請など、プロジェクトの存在意義や必要性を記載します。
1-2. ゴール
ゴールとは「完了条件」です。何を達成すれば終わるのか、どこに行けば終わるのかを記載します。通常は5W1Hのうち、WHATやWHEREをゴールとします。
1-3. 目的
プロジェクトを何のために進めるのかという意図です。ゴールよりも広い視野で捉えます。5W1Hのうち、WHYが目的となります。
1-4. 目標
プロジェクトが成功したかどうかを判断するモノサシです。いかに達成すれば成功なのかを規定します。目標はKPI（数値目標）として設定します。そのため◯年以内に、◯◯％の達成、◯◯件の問い合わせ、◯◯円以上など、ほとんどの場合で数字が入ります。
1-5. ターゲット
プロジェクトのターゲットユーザー像です。ユーザーの属性情報だけでなく、下記のように感性情報も記載されているとユーザー像がより明確になります。
属性情報
・性別
・年齢
・住まい
・家族構成
・職業
・収入
感性情報
・興味関心のあるものごと
・苦手なものごと
・休日の過ごしかた
・好きな本、雑誌
・好きなファッション
・好きなカフェ・レストラン
・好きなTV、映画、Netflix
・SNSでよくチェックしているもの
すでにペルソナが作成されている場合や、プロジェクト内でユーザーリサーチを行い、これからターゲット像を明確にしていく場合は、その旨を記載します。
2. スコープ
2-1. 自社の作業範囲
自社の作業範囲については、以前noteに書いた記事 Webサイト制作をどれくらいの粒度で分解してタスク化するか に細かく書いたので、こちらの記事では割愛します。
2-2. クライアントの作業範囲
クライアントの作業範囲はプロジェクトによって千差万別ですが、多くの場合で下記のような項目が入ります。
要件定義
・インタビュー、ワークショップなど参加メンバーのアサイン調整
情報設計
・利用する関連サービスの機能要件の確認
・会社案内、社内報など既存の会社情報媒体の提供
デザイン
・画像、イラスト、ロゴなどの提供
・（必要に応じて）撮影のための場所、製品、モデル手配などの協力
コーディング
・有料プラグイン・関連サービス・Webフォントの契約
・現状のサーバー・ドメイン情報の提供
CMS開発
・CMS開発環境の手配
・サーバー・ミドルウェアの設定
コンテンツ
・metaタグ・解析タグの提供
・コンテンツ登録内容の確認と調整
公開
・DNS切り替え
・公開後フォーム送受信テスト
・SNSシェアの表示確認
・解析タグの動作確認
2-3. スコープ外作業
スコープ外作業も上記同様プロジェクトによって異なりますが、多くの場合で下記のような項目が入ります。
リサーチ
・競合Webサイトリサーチおよびレポート
・アンケートによる定量調査
ユーザーテスト
・ローンチ前のユーザーテスト
・公開後のユーザーアンケート
脆弱性診断
・第三者機関による脆弱性診断
アクセシビリティ診断
・第三者機関によるWebアクセシビリティ診断
制作対象範囲
・特設サイトや採用サイトなど関連サイトの更新
・SNSなどWebサイト以外の設定、画像作成
データ保管
・既存サイトのバックアップデータ保管
2-4. 納品成果物／要素成果物
納品成果物とその形式を記載します。その際にオリジナルファイル（.fig / .xd / .aiや、HTML/CSSのソースコード）の納品可否についても記載をします。多くの場合で下記のような最終成果物／要素成果物となります。
最終成果物
・Webサイト一式
要素成果物
・要件定義書 / docs
・WBS・スケジュール / instagantt
・サイトマップ・テンプレートマップ / pdf
・ページリスト・機能要件リスト / spreadsheet
・ワイヤーフレーム / pdf
・デザインコンセプト / pdf
・コーディングガイドライン / pdf
・CMS仕様書 / pdf
・コンテンツ移行計画書 / docs
・運用マニュアル / docs
・公開タイムスケジュール / spreadsheet
注記事項
・デザイン確認はFigmaからプレビュー用URLを発行します。
・資料・デザイン制作における元ファイル（.fig / .xd / .ai 等）は納品物に含まれません。
・HTML/CSSなどのソースコードは納品物に含まれません。
・成果物/要素成果物はサーバーへのアップロード、またSlackやメールでの送信を持って納品とします。
3. スケジュール
3-1. WBS／スケジュール
WBS／スケジュールはinstaganttなどのツールを利用してガントチャートとして作成します。プロジェクト後半では定例MTGの頻度を減らせる場合もあるため、MTGの開催タイミングについてもスケジュールへ記載するようにします。
3-2. マイルストーン
「確定」が遅れると、スケジュール全体に遅延の影響がある重要なタスクをマイルストーンとします。Webサイト制作では、下記の内容をマイルストーンとして設定することが多くあります。
マイルストーン
・要件定義の確定
・主要ワイヤーフレームの確定
・デザインコンセプトの確定
・フォーマットデザインの確定
・CMS開発着手
・新規原稿・画像の登録着手
4. 予算
4-1. 総費用
プロジェクトの予算と、予算の根拠になった見積もりの発行日、見積もり番号を明記します。
4-2. 支払い条件
下記のような請求・支払いに関する条件を記載します。
請求回数
分割（フェーズに分けて請求）、または一括（公開日の月末請求）
支払いサイト
公開日月末締め翌月末支払い
制作の中断、途中キャンセルの場合
その時点までに完了している成果物／要素成果物に対しては100%の支払いとする。制作途中の成果物／要素成果物に対しては50%の支払いとする。未着手の制作物に対しては支払いは生じない。
4-3. 見積もりタイプ
プロジェクトの進行とともに見積もりの精度は上がっていくため、プロジェクト初期の超概算見積もりから確定見積もりまでを、Level AからLevel Cまでの３段階に設定します。
超概算見積 Level C［キックオフ〜プロジェクト計画］
詳細情報が定まっていない状態で、合計金額の大まかな目安を伝える際に提出する。見積額の精度は-30%〜+50%の間に設定される。
概算見積 Level B［要件定義〜デザイン］
制作ページ数やボリューム等、デザイン要件が確定されているため、見積額の精度は-15%〜+25%に設定される。
確定見積 Level A［コーディング〜CMS開発］
CMS仕様や開発工数など、詳細要件の全てが確定されているため、見積額の精度は-0%〜+0%に設定される。
5. 制作要件
5-1. 対象OS／ブラウザ
Webサイト公開時点における各OS／ブラウザの最新版を基本的には動作検証対象とします。スマートフォンは実機で確認を行う機種のモデルを指定します。この際にクライアントが通常利用しているPCの機種／画面解像度の確認を必ず行います。
5-2. 情報設計
情報設計は下記のステップで進め、各段階にてMTGで確認をし、承認をいただきます。
情報設計の進め方
1. Webサイト全体のツリー構造はサイトマップにて決定する
2. Webサイト全体のページ数／URLはページリストにて決定する
3. Webサイト各ページの情報設計はワイヤーフレームにて決定する
※ワイヤーフレームでは情報設計を決めるものとし、デザインのトンマナは定義をしない。
5-3. デザイン
デザインは下記のステップで進め、各段階にてMTGで確認をし、承認をいただきます。
デザインの進め方
1. デザイン着手前にデザインコンセプトにて方向性を決定する
2. Webサイト全体のフォーマットはトップページデザインにて決定する
3. フォーマット決定後は１画面あたり１案とし方向性の異なる複数案を制作しない
※デザイン制作はPC・SPのみとし、タブレット画面のデザインは制作しない。
※デザインの変更は２回までとし、それ以上の変更は追加予算・スケジュールにて対応をする。
5-4. コーディング
コーディングはクライアント提供のガイドライン、または弊社ガイドラインのどちらかに準拠して行います。そのためクライアントへガイドラインの有無を確認します。
5-5. CMS構築
CMS構築はクライアント提供のCMS仕様書、または弊社CMS仕様書のどちらかに準拠して行います。CMS構築後の操作レクチャーは基本的に実施しますが、運用マニュアルの制作は別料金となることを確認します。
5-6. フォント
デザインにおいて最適なフォントを選定することは非常に重要なためWebフォントの利用を強く推奨します。そのためクライアントへAdobeライセンスの有無、およびモリサワパスポートの有無を確認します。
5-7. SEO
SEOはクライアント提供のガイドラインがある場合には準拠します。ガイドラインがない場合は、Webサイト制作における基本的な対策を行います。検索結果の表示順位などの成果を保証するものではないことを確認します。
5-8. アクセシビリティ
アクセシビリティはクライアント提供のガイドラインがある場合には準拠します。ガイドラインがない場合は、Webサイト制作における基本的な対策を行います。JIS規格の達成基準への対応を保証するものではないことを確認します。
5-9. アクセス解析
アクセス解析は情報設計、デザインのための参考として閲覧をすることがあります。解析レポート資料の作成や、現状サイトの改善施策を行うものではないことを確認します。
5-10. 保守・運用
保守・運用はクライアントからの希望がある場合にはヒアリングを行い、保守・運用プランを提示します。希望がない場合は、制作後の瑕疵対応期間は公開後４週間となります。
5-11. ポートフォリオ掲載
Webサイト公開後に、ポートフォリオとしてSNSや自社サイトへの掲載をしてよいか確認します。
6. チーム
6-1. クライアントチーム
プロジェクト参加メンバーの「名前／所属・肩書／PJにおける役割」を下記のように記載します。
クライアントチーム
・佐藤さま / ブランド戦略室 / PMとしてやりとりをメインで行う担当者
・高橋さま / ブランド戦略室 / ブランド戦略室長として意思決定の相談役
・田中さま / 製品企画室 / 製品情報に関する情報提供を行う
・鈴木さま / マーケティング室 / サービス情報に関する情報提供を行う
プロジェクトメンバーが多い場合には、参加メンバーのPJにおける役割が明確になっていないケースが多いため、RACIチャートなどを作成しプロジェクトのフェーズごとに、参加者がどのような役割を持つのかを定義します。
6-2. 自社チーム／パートナー
クライアントチーム同様に「名前／所属・肩書／PJにおける役割」を下記のように記載します。
自社 / パートナーチーム
・重松 / Shhh inc ディレクター / PM・情報設計の担当者、PJの統括責任者
・宇都宮 / Shhh inc デザイナー / アートディレクション・デザインの担当者
・坂田 / Good rings デベロッパー / コーディング・CMS開発の担当者
・木島 / ライター / コンテンツ記事の執筆担当者
・吉田 / フォトグラファー / コンテンツ記事の撮影担当
名前と所属・肩書だけでなく「PJにおける役割」を明記することで、各スコープの制作責任者が明確となり、プロジェクトのコミュニケーションが円滑になります。
7. コミュニケーション
7-1. 会議体
定例MTGを行う日時、コミュニケーションライン、連絡を取り合うことが可能な時間帯を記載します。
定例MTG日時
・毎週水曜日 10:00-11:00
・水曜祝日の場合は翌日の木曜10:00-11:00にて行う
コミュニケーションライン
・通常の連絡はSlackを利用し @のメンションはやりとりをメインで行っている担当者のみとする。ただし専門的なトピックについての連絡の場合は、その担当者にも@のメンションをする。
・@channelや@hereは基本的には利用しない。
・Slackで一つのトピックに対して返信する際には「スレッド」を利用する。
連絡可能日時
・原則、日本時間の平日10:00 - 19:00とする。
・上記時間以外での連絡には返信、リアクションは基本的には行わない。
※時短勤務、海外からの時差などの理由により、上記に勤務外時間が含まれる場合はお知らせください。勤務外時間にメンションなどしないよう注意をします。
特にプロジェクト参加メンバーに時短勤務、週４勤務、海外からの参加メンバーがいて時差がある場合には、連絡可能日時などのコミュニケーションルールを設定することで、勤務時間外にSlackなどで通知がくることへのプレッシャーを緩和し、安心してプロジェクトへ参加できるようになるため重要な確認箇所となります。
7-2. 利用ツール
基本的な連絡はメールか、またはSlackなどのチャットツールとするのか。オンラインMTGの場合はZoom、MeetやTeamsなど、どのツールを利用し、誰がオンラインMTGの管理者となるのかを確認します。
8. リスク
8-1. リスク／回避策
リスクマネジメントについては以前noteに書いた記事 リスクマネジメントを積極的に使い倒す で細かく書いたので、こちらでは割愛します。
9. 調達
9-1. オンラインツール
プロジェクトで利用するオンラインツールの名称、利用用途、所有者を下記のように一覧として整理します。またプロジェクト終了後にプロジェクトスペースをクローズするタイミングの確認をします。
オンラインツール
・Google docs / 原稿確認 / Shhh
・Google spreadsheet / 課題管理 / Shhh
・Google Drive / ドキュメント・画像共有 / Shhh
・instagantt / スケジュール管理 / Shhh
・Figma / オンラインデザイン確認 / Shhh
・Miro / オンラインホワイトボート / Shhh
・Slack / コミュニケーション / クライアント
・Teams / オンラインMTG / クライアント
※データ保存期間は、プロジェクト完了から4週間となります。
9-2. 環境
プロジェクトで利用するサーバー、ドメインなどのWeb環境の名称、利用用途、所有者を一覧として下記のように整理します。
環境
・本番環境Webサーバー（動的環境） / 本番公開用 / クライアント
・開発環境Webサーバー（静的環境） / コーディング確認用 / Shhh
・ドメイン / 本番公開用 / クライアント
・SSL / 本番公開用 / クライアント
・Webフォント / 本番公開用 / クライアント
要件定義書を確認の抜け漏れなく作成するメリット
要件定義書の大項目としては９項目となりました。当然ながら「5. 制作要件」が大きな割合を占めていますが「制作要件以外の項目も抜け漏れなく確認できているか」が、プロジェクト進行へのスムーズな橋渡しのポイントになります。
要件定義書を確認の抜け漏れなく作成する一番のメリットは「グレーゾーンをなくすこと」です。グレーゾーンをなくしプロジェクト全体の輪郭が見えることは「安心」につながります。制作チームが安心して制作に集中できる。プロジェクトに途中から加わるメンバーが共通理解を持ってジョインできる。プロジェクトを安心して他のメンバーへ引き継げる。または、PR・広報の際に信頼できる情報が網羅されてまとまっている。などもありますね。
今回は私たちが普段のプロジェクトで作成している要件定義書をもとに、一般的なWebサイト制作を想定してまとめました。他にも「要件定義ではこういうことを確認しておくと良い」などのアドバイスがあればぜひ教えてください。
Shhh inc.は「大切となるものをつくる」を理念に掲げ、よく尋ね、よく対話をすることを通して、物事に備わる美質を深く理解することを大事にしています。Webサイト制作のご依頼や、ご相談がございましたらお気軽にご連絡ください。様々な事例とともに、私たちの強みや、制作フローについてご案内します。
● Shhh inc.のWebサイト
https://shhh.jp/
● 連絡先
info@shhh.jp
🤫
この記事が気に入ったらサポートをしてみませんか？