プロジェクトのキックオフ前後に作成する要件定義書。確認の抜け漏れを最小限に抑えるには、どのようなことを記載しておくべきか。そして、メンバーへのスムーズな共有と、その後の円滑なプロジェクト進行のための、良い要件定義書とはどのようなものだろう。自分たち用のメモも兼ねて「Webサイト制作プロジェクトの要件定義書」の確認項目をnoteに整理してみます。

1. プロジェクト概要

1-1. 背景

プロジェクトを発案するに至った背景です。現状の課題、ビジネス要件の変化、ユーザーの変化、社会的要請など、プロジェクトの存在意義や必要性を記載します。

1-2. ゴール

ゴールとは「完了条件」です。何を達成すれば終わるのか、どこに行けば終わるのかを記載します。通常は5W1Hのうち、WHATやWHEREをゴールとします。

1-3. 目的

プロジェクトを何のために進めるのかという意図です。ゴールよりも広い視野で捉えます。5W1Hのうち、WHYが目的となります。

1-4. 目標

プロジェクトが成功したかどうかを判断するモノサシです。いかに達成すれば成功なのかを規定します。目標はKPI（数値目標）として設定します。そのため◯年以内に、◯◯％の達成、◯◯件の問い合わせ、◯◯円以上など、ほとんどの場合で数字が入ります。

1-5. ターゲット

プロジェクトのターゲットユーザー像です。ユーザーの属性情報だけでなく、下記のように感性情報も記載されているとユーザー像がより明確になります。

すでにペルソナが作成されている場合や、プロジェクト内でユーザーリサーチを行い、これからターゲット像を明確にしていく場合は、その旨を記載します。

2. スコープ

2-1. 自社の作業範囲

自社の作業範囲については、以前noteに書いた記事 Webサイト制作をどれくらいの粒度で分解してタスク化するか に細かく書いたので、こちらの記事では割愛します。

2-2. クライアントの作業範囲

クライアントの作業範囲はプロジェクトによって千差万別ですが、多くの場合で下記のような項目が入ります。

2-3. スコープ外作業

スコープ外作業も上記同様プロジェクトによって異なりますが、多くの場合で下記のような項目が入ります。

2-4. 納品成果物／要素成果物

納品成果物とその形式を記載します。その際にオリジナルファイル（.fig / .xd / .aiや、HTML/CSSのソースコード）の納品可否についても記載をします。多くの場合で下記のような最終成果物／要素成果物となります。

3. スケジュール

3-1. WBS／スケジュール

WBS／スケジュールはinstaganttなどのツールを利用してガントチャートとして作成します。プロジェクト後半では定例MTGの頻度を減らせる場合もあるため、MTGの開催タイミングについてもスケジュールへ記載するようにします。

3-2. マイルストーン

「確定」が遅れると、スケジュール全体に遅延の影響がある重要なタスクをマイルストーンとします。Webサイト制作では、下記の内容をマイルストーンとして設定することが多くあります。

4. 予算

4-1. 総費用

プロジェクトの予算と、予算の根拠になった見積もりの発行日、見積もり番号を明記します。

4-2. 支払い条件

下記のような請求・支払いに関する条件を記載します。

4-3. 見積もりタイプ

プロジェクトの進行とともに見積もりの精度は上がっていくため、プロジェクト初期の超概算見積もりから確定見積もりまでを、Level AからLevel Cまでの３段階に設定します。

5. 制作要件

5-1. 対象OS／ブラウザ

Webサイト公開時点における各OS／ブラウザの最新版を基本的には動作検証対象とします。スマートフォンは実機で確認を行う機種のモデルを指定します。この際にクライアントが通常利用しているPCの機種／画面解像度の確認を必ず行います。

5-2. 情報設計

情報設計は下記のステップで進め、各段階にてMTGで確認をし、承認をいただきます。

5-3. デザイン

デザインは下記のステップで進め、各段階にてMTGで確認をし、承認をいただきます。

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における役割」を下記のように記載します。

プロジェクトメンバーが多い場合には、参加メンバーのPJにおける役割が明確になっていないケースが多いため、RACIチャートなどを作成しプロジェクトのフェーズごとに、参加者がどのような役割を持つのかを定義します。

6-2. 自社チーム／パートナー

クライアントチーム同様に「名前／所属・肩書／PJにおける役割」を下記のように記載します。

名前と所属・肩書だけでなく「PJにおける役割」を明記することで、各スコープの制作責任者が明確となり、プロジェクトのコミュニケーションが円滑になります。

7. コミュニケーション

7-1. 会議体

定例MTGを行う日時、コミュニケーションライン、連絡を取り合うことが可能な時間帯を記載します。

特にプロジェクト参加メンバーに時短勤務、週４勤務、海外からの参加メンバーがいて時差がある場合には、連絡可能日時などのコミュニケーションルールを設定することで、勤務時間外にSlackなどで通知がくることへのプレッシャーを緩和し、安心してプロジェクトへ参加できるようになるため重要な確認箇所となります。

7-2. 利用ツール

基本的な連絡はメールか、またはSlackなどのチャットツールとするのか。オンラインMTGの場合はZoom、MeetやTeamsなど、どのツールを利用し、誰がオンラインMTGの管理者となるのかを確認します。

8. リスク

8-1. リスク／回避策

リスクマネジメントについては以前noteに書いた記事 リスクマネジメントを積極的に使い倒す で細かく書いたので、こちらでは割愛します。

9. 調達

9-1. オンラインツール

プロジェクトで利用するオンラインツールの名称、利用用途、所有者を下記のように一覧として整理します。またプロジェクト終了後にプロジェクトスペースをクローズするタイミングの確認をします。

9-2. 環境

プロジェクトで利用するサーバー、ドメインなどのWeb環境の名称、利用用途、所有者を一覧として下記のように整理します。

要件定義書を確認の抜け漏れなく作成するメリット

要件定義書の大項目としては９項目となりました。当然ながら「5. 制作要件」が大きな割合を占めていますが「制作要件以外の項目も抜け漏れなく確認できているか」が、プロジェクト進行へのスムーズな橋渡しのポイントになります。

要件定義書を確認の抜け漏れなく作成する一番のメリットは「グレーゾーンをなくすこと」です。グレーゾーンをなくしプロジェクト全体の輪郭が見えることは「安心」につながります。制作チームが安心して制作に集中できる。プロジェクトに途中から加わるメンバーが共通理解を持ってジョインできる。プロジェクトを安心して他のメンバーへ引き継げる。または、PR・広報の際に信頼できる情報が網羅されてまとまっている。などもありますね。

今回は私たちが普段のプロジェクトで作成している要件定義書をもとに、一般的なWebサイト制作を想定してまとめました。他にも「要件定義ではこういうことを確認しておくと良い」などのアドバイスがあればぜひ教えてください。

🤫