はじめに
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/見積根拠/用語定義 |
実行中 | 週1でマイルストーン進捗/逸脱は即CR | 進捗表(G/A/R)/議事録→CR票 |
受入/検収 | 合否判定表で客観評価 | テスト結果×基準=合否 |
支払 | 検収日と支払条件を連動 | 検収書/請求書 |
4. 失敗あるある→即効の対策
失敗パターン | ありがち表現 | 対策ひと言 (置き換え例) |
---|---|---|
境界が曖昧 | 「必要に応じて対応」 | 「毎月最大8時間まで/超はCR」 |
受入基準が無い | 「品質は高めで」 | 「重大0/高1/中以下3以内で合格」 |
前提が口頭 | 「後で送ります」 | 「MM/DDまでに発注者がAPI仕様提供」 |
変更が口約束 | 議事録のみ | 「CR様式で承認後に着手」 |
役割不明 | だれが決める? | 「A=部長/承認, R=受注PM/実施」 |
5. 1分チェックリスト (発注直前)
項目 | Yes/No | メモ |
---|---|---|
Scopeの実施/除外が1行で区切れている | ||
Deliverablesの形式/受入基準が数値で書けた | ||
Scheduleが日付で埋まっている | ||
Costの契約/支払条件が明記された | ||
R&Rの承認者と窓口が特定できる | ||
Assumptionsが期限つきで列挙されている | ||
Changeの手順/見積/承認が書かれている |
おわりに
完璧より「ミニマムでも数値で合意」することが重要です。
まずは上のひな型に埋め、Assumptions/Changeだけは必ず書くようにしましょう。これだけでも多くのトラブルは事前に価格化/可視化できますし、何かあった場合の物差しになります。
ぜひ活用してみてください。