プロジェクトのサマリーを記載します。この概要によってプロジェクトの内容について知ることができるように記載します。

記載・確認事項

[MUST]

• ・プロジェクト名
• ・プロジェクトの概要・背景
• ・公開目標

[BETTER]

• ・プロジェクトコード
• ・プロジェクト予算

このセクションでは通常、プロジェクトの目的やゴールを説明し、これから推し進めるプロジェクトがどのような位置づけを担っているのかを明確にしておきます。また関係者がプロジェクトのゴールとは何かを明確に定義する情報が含まれます。一般的には、プロジェクト関係者がこのセクションの作成に関与し、これらの内容に関係者が同意するようにします。

記載・確認事項

[MUST]

• ・プロジェクトの位置づけ（社内的、事業的にどのような位置づけか？）
• ・プロジェクトの目的・ゴール（何を目指し、何を達成しなければならないか？）
• ・プロジェクトとして取り組む課題（現状で見えているもの）

[BETTER]

• ・重要成功要因（Critical Success Factor）、鍵となる成功要因（Key Success Factor）は何か？
• ・プロジェクトに関連するKGIやKPI

注意点

• ・プロジェクトそのものが社内でどのような位置づけで、どのような役割を担うのかコンセンサスをとっておく。
• ・プロジェクト自体に戦略フェイズがある場合はそこで課題を明確化にするため、ここでの課題は認識されたものを記載しておく。
• ・課題やKGI・KPIはアウター（対外的）に紐付くものとインナー（社内）に紐付くものを整理しておく。

作業範囲は、作業範囲記述書の中で最も詳細なセクションになります。このセクションではプロジェクトを完遂するまでに発生する作業内容を明確にします。発注者、制作者を含めプロジェクトに関わるステークホルダーについても明確にし、各々が関わる作業内容と範囲を定義すると共に、プロジェクトに関わるメンバーの体制と役割を記載します。

記載・確認事項

[MUST]

• ・プロジェクトで発生する作業内容、調整が発生する事項について発注者、制作者の双方で記載する。
• ・記載した作業内容、調整事項についてどちらが担当するのかを明確にする（議論が必要な場合は双方を担当とする）。
• ・プロジェクトに関わる各社のメンバーと役割を記載する。コアメンバーとスポットでのサブメンバーなども定義しておく。
• ・プロジェクトの合意形成における責任者・決裁者を記載する。

[BETTER]

• ・他部門や関係会社、外部パートナーなどで発生する作業・調整事項についても「対象となる、ならない」を記載する。

注意点

• ・制作ガイドラインのワークフローのタスクをみながら、どちらが対応するかを決めておく。
• ・キックオフ段階で決まりきらないものは、事後調整することを前提として記載する。
• ・実施する（対象となる）ことを洗い出し決める方法とやらないことを決める（対象外となる）の両方の視点を持つ。
• ・ここに記載されていない内容については原則対象外となり、見積には含まれない内容となる。
• ・運用・保守などが必要になる場合、体制・コストなどを明らかにした上でサイト公開前に契約を締結しておく。

プロジェクトの対象となる作業範囲を元にステップを設定し、ステップの中のタスクを細かく分解・視覚化し、WBS（Work Brakedown Structure）を作成、それぞれのタスクに担当者と期間を割り振り、関係者全員が把握できるようにします。

記載・確認事項

[MUST]

• ・プロジェクトのプロセス（フェイズ）を設定する。（プロジェクト計画、戦略・施策定義、要件定義〜など）
• ・プロセス（フェイズ）の中に含まれるタスクを分解し、担当者（担当会社）を割り振る。
• ・クリティカルなマイルストーンを明確にする。（外部プロジェクトとの結合、最終公開日など）
• ・各プロセスの進捗確認を行う定例会議もマイルストーンごとに定義しておく。

注意点

• ・スケジュール作成のために資源（人・材料・機器など）と作業期間を見積もる必要がある。
• ・行き過ぎた要素分解を行わない。管理できるレベルまでの詳細化を行う。
• ・ステークホルダー間のコミュニケーションを助けるツールとなるためWBSはメンバーと一緒に作成することが必要
• ・計画初期段階においては、全ての作業項目を想定できない場合も多い。その場合は、上位の作業項目で計画を立てておき、プロジェクトを進めながら、作業が明確になった時点で、段階的に計画を詳細化する。
• ・複数の会社で構築するプロジェクトの場合、各社のWBSをまとめる必要がある。

ここではプロジェクトを推進する上でプロジェクトクオリティを担保するための前提条件や準備しておくべき内容、各種の制約・制限事項などを明確にしておきます。事後になって「ああすれば良かった」「そんなルールは聞いていない」などの話にならないように双方でしっかり話をしてすり合わせしましょう。

記載・確認事項

[MUST]

• ・プロジェクトルール（会議体と参加者：本会、分科会など、アジェンダ連絡方法など）
• ・プロジェクトで利用する各種ツール類（チャット、オンラインホワイトボード、ビデオコミュニケーションツールなど）。ツール類のアカウント類はどちらが準備するかなども含まれる。
• ・プロジェクト内の承認フロー（発注者の体制とフロー、社内合意形成プロセス）
• ・権利関係（開発プログラム、デザインの著作権や二次使用に関するルールなど）
• ・法律や法令など遵守しなければならない内容（薬事など）

[BETTER]

• ・各種中間成果物ドキュメントの管理方法
• ・テスト・検収の際の発注者が納品物を受け入れる際のルール（受入方法や体制・フロー、条件など）
• ・エスカレーションプロセス（問題発生時の報告経路）

ここでは開発や制作をおこなうために必要な要件を記載します。プロジェクトに必要な機器や取得しなければならない資格、開発を行うためのプログラム言語、ソースコードの管理方法などを取り決めます。

記載・確認事項

[MUST]

• ・開発するサーバ・インフラ環境（Windows、Linux）
• ・使用するCMS、データベース、外部システム（Saas含む）
• ・使用する開発言語
• ・開発するプログラム等のバージョン管理方法
• ・検証・テスト環境
• ・開発で使用するアプリケーション類、準備・購入が必要なライセンス・アカウントなど
• ・開発にあたって取得・所有しなければならない資格
• ・制作・開発に関する各種ガイドラインの共有（ブランド・デザインガイドライン、コーディングガイドラインなど）

[BETTER]

• ・開発する場所や開発に使用する機器（開発用PCや検証機など）
• ・サーバ・インフラの運用・保守をおこなう場合のSLA（Service Level Agreement）

注意点

• ・開発に使用するソフトウェアのバージョンを明確にしておく。
• ・開発環境はどちらが用意するか記載しておく。

プロジェクトを成功させるために必要なすべてのテストの要件を記載します。WBSに記載された各テスト段階に沿って、テストに携わる関係者、必要なリソースや機器、どの段階でテストを行うかなどの情報を記載します。

記載・確認事項

[MUST]

• ・制作者側が行うテストの内容と担当者
• ・成果物に対し発注者が求めるチェック内容（セキュリティ診断、脆弱性診断、SEO診断、アクセシビリティチェックなど）
• ・テスト後のフィードバックの方法（BTS（Bug Tracking System）を利用する、Issueリストを作成するなど）
• ・権利関係（開発プログラム、デザインの著作権や二次使用に関するルールなど）
• ・法律や法令など遵守しなければならない内容（薬事法など）

[BETTER]

• ・発注者が行う検収を伴うテストの内容と担当
• ・検収・受入の基準（クリティカルなバグが無ければ公開判断を行うなど）

注意点

• ・テストに関する工数は甘く見積もりがちになるため、バッファも含めてきちんと精査をおこなう。
• ・テスト後のデバッグ（修正するための制作・開発）期間と再チェックについても認識しておく。
• ・最終承認ラインと検収フローを明確にし、「誰が何を持って検収するのか」を明確にする。

ここではプロジェクトの中でアウトプットとして求められる、すべての成果・納品物を期日を含めて記載します。成果・納品物には齟齬がないように、具体的で定量化が可能な成果・納品物が含まれます。

記載・確認事項

[MUST]

• ・最終的な納品・成果物と納品期日
• ・納品方法と納品場所
• ・各種納品物の権利関係

[BETTER]

• ・中間的な成果物で納品が必要なもの（要件定義書・仕様書・設計書・サイトマップ、ワイヤーフレーム、テスト計画書など）
• ・納品・成果物について制作者側の保管期間

注意点

• ・中間成果物で納品しないものもあるため齟齬の無いように調整をおこなう。
• ・制作・開発の中で作成した元ファイル（PSD、AIファイルなど）についても取り扱いを決めておく。
• ・使用にあたって権利の更新が必要な素材、ライセンスなどを明確にしておく。

このプロジェクトに関連するあらゆる費用を明確にしておきます。プロジェクトのさまざまな段階で発生する人件費や間接コストなどを記載します。支払いスケジュールや支払い方法についても取り決めを行います。予算についてのステータス（購買部門などとの調整が必要な場合）も記載を行います。

記載・確認事項

[MUST]

• ・プロジェクト全体予算（概算見積り）
• ・予算のステータス（決裁が降りているもの、これからのもの）
• ・請求タイミング（一括、分割、事前）、支払いサイト・スケジュール、支払い方法
• ・見積りの詳細化のタイミング

[BETTER]

• ・間接コストの取り扱い（翻訳・通訳、出張費、ツール系の利用料など）

注意点

• ・見積精度について認識を合わせる。（見積プロセスを最初に話して理解いただく）
• ・超概算見積（立ち上げ段階：過去の事例をもとに算出）
• ・概算見積（要件定義前段階：要件をベースに工数×時間単価で算出）
• ・詳細見積（プロジェクト計画最終段階：要件定義が完了、作業もWBSが決定している）
• ・コンペの案件の場合はパートナーが確定した時点で発注額が確定しているケースもあるため双方で確認しておく。

この概要によってプロジェクトの内容について理解できるように記載します。

記載・確認事項

• 1.プロジェクト名
• 2.プロジェクトの背景・課題・目的・対象
• 3.成果物・納品物・バリエーション
• 4.使用範囲・期間
• 5.求める成果、成功基準、KPI
• 6.体制
• 7.スケジュール
• 8.予算

この要件からタスクが細分化されそれぞれの担当者が設計や開発、実制作から運用、権利処理など実務が遂行されます。前提条件や概要で想定されていない可能性も含めて深くすり合わせし、実施することを記載します。

記載・確認事項

• 1.進行ルール（打合せの種類・頻度、各メンバー、アジェンダや資料の分担など）
• 2.利用ツール（コミュニケーションツール、ドキュメント管理、アカウント主体など）
• 3.承認フロー（発注者の体制とフロー、制作スタッフ内の承認プロセスなど）
• 4.商品管理（発注、貸与、保管方法、搬入搬出、返却など）
• 5.制作環境（スタジオ、ロケーション、会場、現場インフラなど、各種発注・申請・契約など）
• 6.スタッフ（アサインの判断・承認方法、工数管理方法など）
• 7.仕様策定（インフラ、サービス、ガイドライン、構成書、コンテ、カンプ、運用マニュアルなど）
• 8.権利処理（出演契約、競合拘束範囲、著作権の利用や保持、契約主体など）
• 9.法令遵守（薬事法、景表法、道交法など）
• 10.情報管理（秘匿、禁止事項、個人情報取り扱い、データ保管、
• 11.危機管理（感染防止対策、警備計画、リスク洗い出し、保険、天候、問題・事故発生時の対応など）
• 12.変更対応（前提や仕様変更による予算やスケジュール変更など随時）

納品や本番へむけて最終的な準備をし、概要や要件を満たしているか確認できるよう記載します。

記載・確認事項

• 1.制作者によるテスト、リハーサル、仮組の概要 / 納品、本番までの見通し
• 2.発注者による検収・評価・受入の基準 / 納品後対応、現場対応の判断
• 3.修正・変更対応の費用負担

ここでは概要で想定したすべての成果・納品物、本番・実施内容について、期日を含めて記載します。

記載・確認事項

• 1.最終的な納品・成果物と納品期日
• 2.納品方法と納品場所
• 3.各種納品物の権利関係
• 4.中間成果物、制作データの納品有無
• 5.データ・素材保管期間・方法

概要の予算に対し見積もりを経て費用（制作費）を確定します。その決定プロセスや支払い（請求）のタイミング、支払い条件などを記載します。

記載・確認事項

• 1.概算見積のタイミング（概要、企画案、企画決定時、制作方法別など）
• 2.詳細見積のタイミング（第一次見積〜実施前の最終見積、事後見積など）
• 3.請求のタイミング（一部前払い、納品時か公開・実施時か、一括、分割など）
• 4.支払い条件、支払い方法
• 5.契約書記載内容（発注書発行の有無、諸条件記載の有無）