SOW ⼤規模サイト・ECサイトの９つの項⽬
このページではI.C.E.が提供する⼤規模サイト・ECサイトにおけるSOWの９つの項⽬について解説します。
特に注意したい記載・確認事項を「MUST」「BETTER」としていますので、SOW作成時の参考としていただければ幸いです。

1. プロジェクト概要
2. プロジェクトの⽬的・ゴール・成功基準
3. 作業範囲と担当、プロジェクト体制
4. WBS・ガントチャート
5. プロジェクト推進にあたっての前提・制約条件・準備事項
6. 開発・制作に関わる要件
7. テストと検収基準
8. 成果・納品物
9. 費⽤・⽀払い・契約⽅法

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

記載・確認事項[MUST]

1. プロジェクト名
2. プロジェクトの概要・背景
3. 公開⽬標[BETTER]

1. プロジェクトコード
2. プロジェクト予算

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

記載・確認事項[MUST]

1. プロジェクトの位置づけ（社内的、事業的にどのような位置づけか︖）
2. プロジェクトの⽬的・ゴール（何を⽬指し、何を達成しなければならないか︖）
3. プロジェクトとして取り組む課題（現状で⾒えているもの）[BETTER]

1. 重要成功要因（Critical Success Factor）、鍵となる成功要因（Key Success Factor）は何か︖
2. プロジェクトに関連するKGIやKPI
注意点• プロジェクトそのものが社内でどのような位置づけで、どのような役割を担うのかコンセンサスをとっておく。
• プロジェクト⾃体に戦略フェイズがある場合はそこで課題を明確化にするため、ここでの課題は認識されたものを記載しておく。
• 課題やKGI・KPIはアウター（対外的）に紐付くものとインナー（社内）に紐付くものを整理しておく。

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

記載・確認事項[MUST]

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

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

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

記載・確認事項[MUST]

1. プロジェクトのプロセス（フェイズ）を設定する（プロジェクト計画、戦略・施策定義、要件定義〜など）
2. プロセス（フェイズ）の中に含まれるタスクを分解し、担当者（担当会社）を割り振る。
3. クリティカルなマイルストーンを明確にする。（外部プロジェクトとの結合、最終公開⽇など）
4. 各プロセスの進捗確認を⾏う定例会議もマイルストーンごとに定義しておく。
注意点• スケジュール作成のために資源（⼈・材料・機器など）と作業期間を⾒積もる必要がある。
• ⾏き過ぎた要素分解を⾏わない。管理できるレベルまでの詳細化を⾏う。
• ステークホルダー間のコミュニケーションを助けるツールとなるためWBSはメンバーと⼀緒に作成することが必要• 計画初期段階においては、全ての作業項⽬を想定できない場合も多い。その場合は、上位の作業項⽬で計画を⽴てておき、プロジェクトを進めながら、作業が明確になった時点で、段階的に計画を詳細化する。
• 複数の会社で構築するプロジェクトの場合、各社のWBSをまとめる必要がある。

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

記載・確認事項[MUST]

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

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

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

記載・確認事項[MUST]

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

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

注意点
●
●

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

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

記載・確認事項[MUST]

1. 制作者側が⾏うテストの内容と担当者
2. 成果物に対し発注者が求めるチェック内容（セキュリティ診断、脆弱性診断、SEO診断、アクセシビリティチェックなど）
3. テスト後のフィードバックの⽅法（BTS（Bug Tracking System）を利⽤する、Issueリストを作成するなど）[BETTER]

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

注意点
●
●
●

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

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

記載・確認事項[MUST]

1. 最終的な納品・成果物と納品期⽇
2. 納品⽅法と納品場所
3. 各種納品物の権利関係[BETTER]

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

注意点
●
●
●

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

9.費⽤・⽀払い・契約⽅法
このプロジェクトに関連するあらゆる費⽤を明確にしておきます。プロジェクトのさまざまな段階で発⽣する⼈件費や間接コストなどを記載します。⽀払いスケジュールや⽀払い⽅法についても取り決めを⾏います。予算についてのステータス（購買部⾨などとの調整が必要な場合）も記載を⾏います。

記載・確認事項[MUST]

1. プロジェクト全体予算（概算⾒積り）
2. 予算のステータス（決裁が降りているもの、これからのもの）
3. 請求タイミング（⼀括、分割、事前）、⽀払いサイト・スケジュール、⽀払い⽅法
4. ⾒積りの詳細化のタイミング[BETTER]

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

注意点
●
●
●
●
●

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