はじめに

SOW (Statement of Work) を業務の中で聞いたことはありますか。
SOW は、発注と受注のあいだでなにを/どこまで/いつまでに/いくらで/どんな品質で/だれが責任かを合意する設計図です。
ここでは、なるべく簡潔にすぐ使える最小構成で要約してみますので、業務での参考にしてもらえると嬉しいです。

1. まず押さえる「SOWの骨子」

要素	概要	内容例
Scope	やる/やらないの境界	実施: 要件/設計/実装/試験, 除外: 運用/保守
Deliverables	出すものと合格条件	仕様書(PDF)/試験報告(PDF)/ ソース(Git), 重大欠陥0
Schedule	期日/節目	設計完了: MM/DD, 納品: MM/DD
Cost	お金の型と支払	固定/準委任, 検収月末締/翌月末払
Quality	品質のものさし	コーディング規約準拠, 欠陥基準を数値化
R&R	役割と承認者	A=承認, R=実施, C=助言, I=報告
Assumptions	前提/制約	API仕様は発注者がMM/DDまでに提供
Change	変更の段取り	CR申請→見積→承認→着手 (費用/納期/品質の影響を明記)

CR：Change Request（変更依頼）。口頭ではなく文書で変更内容を記し、合意するドキュメント。合意のエビデンスとしても使われる。

2. 「SOWの骨子」のミニマム版ひな型 (コピペ用)

# Statement of Work (SOW)

1) Scope
- 実施: 〇〇の要件定義/設計/実装/試験
- 除外: 運用/保守/関連改修

2) Deliverables & Acceptance
- 成果物: 仕様書(PDF), 試験報告(PDF), ソース(Git)
- 受入基準: 重大0/高1/中以下3以内, 全テスト合格, レビュー指摘解消

3) Schedule & Milestones
- 要件確定: MM/DD
- 設計完了: MM/DD
- 納品/検収: MM/DD

4) Commercials
- 契約: 固定/準委任
- 金額/単価: ¥X,XXX,XXX / ¥XXX,XXX/月
- 支払: 検収月末締/翌月末払

5) Quality & R&R
- 規約: 〇〇準拠
- 役割: 発注A(承認)/発注B(窓口)/受注C(PM)

6) Assumptions/Constraints
- API仕様は発注者がMM/DDまでに提供
- 環境は発注者VPC

7) Change Control
- CR申請→見積→承認→着手 (費用/納期/品質を提示)

3. 実務フローは「決めて書いて回す」

フェーズ	やること	ドキュメント/見える化
発注前	粒度を成果物単位に分解/曖昧語排除	WBS/見積根拠/用語定義
実行中	週１でマイルストーン進捗/逸脱は即CR	進捗表(G/A/R)/議事録→CR票
受入/検収	合否判定表で客観評価	テスト結果×基準＝合否
支払	検収日と支払条件を連動	検収書/請求書

4. 失敗あるある→即効の対策

失敗パターン	ありがち表現	対策ひと言 (置き換え例)
境界が曖昧	「必要に応じて対応」	「毎月最大8時間まで/超はCR」
受入基準が無い	「品質は高めで」	「重大0/高1/中以下3以内で合格」
前提が口頭	「後で送ります」	「MM/DDまでに発注者がAPI仕様提供」
変更が口約束	議事録のみ	「CR様式で承認後に着手」
役割不明	だれが決める？	「A=部長/承認, R=受注PM/実施」

5. １分チェックリスト (発注直前)

項目	Yes/No	メモ
Scopeの実施/除外が１行で区切れている
Deliverablesの形式/受入基準が数値で書けた
Scheduleが日付で埋まっている
Costの契約/支払条件が明記された
R&Rの承認者と窓口が特定できる
Assumptionsが期限つきで列挙されている
Changeの手順/見積/承認が書かれている

おわりに

完璧より「ミニマムでも数値で合意」することが重要です。
まずは上のひな型に埋め、Assumptions/Changeだけは必ず書くようにしましょう。これだけでも多くのトラブルは事前に価格化/可視化できますし、何かあった場合の物差しになります。
ぜひ活用してみてください。