システム開発の成果物｜検収前に揃えるべきものと、いらない山

「成果物として設計書一式を納品します。」——安心に聞こえる。だが検収で使う定義がなく、運用で開かれない数百ページは、コストでしかない。

引き継ぎ条項の話（別記事）と近いが、本稿は検収時点で何が必要かに絞る。

成果物は量ではなく、検収と運用の場面で使うものだけを必須にする。

結論：必須／任意（例）

工程	必須になりやすい	任意・削ってよいことが多い
要件	受入基準、スコープ内外	小説のような背景説明の重複
設計	境界、IF、意思決定ログ	自動生成の詳細クラス図の山
実装	リポジトリ、環境再現手順	使わない旧版ドキュメント
テスト	観点、重大バグの記録	形式だけの網羅表
運用	Runbook、監視の見方	開かれない運用マニュアル長文

案件で前後する。重要なのは、一覧を契約前に色分けすることだ。

赤旗

• 「一式」で中身の一覧がない
• ページ数が成果指標になっている
• 検収項目と成果物が対応していない

事例

匿名化した一例。設計書250ページを検収物にしたが、受入は画面の動作確認のみ。文書は未読のまま追加費用の争点になった。分岐点は、検収チェックリストと成果物を紐づけなかったことだ。

別の一例。必須を「受入基準・IF・Runbook・リポジトリ」に限定。文書コストが下がり、検収が早まった。

判断軸

厚くする	薄くする
規制・引継・マルチベンダーで痕跡が要る	単一チームの短い改修
内製化が近い	使い捨てで終わると決まっている（それでもRunbookは残す）

次に確認すること

1. 検収項目と成果物は1対1で対応するか
2. 「一式」の中身一覧はあるか
3. 運用で開く文書はどれか
4. ページ数をKPIにしていないか
5. いらない山の作成費用が見積もりに入っていないか

まとめ

システム開発の成果物議論は、ドキュメント信仰と戦いやすい。検収と運用の場面から逆算して必須を決める。 山を買うな。使うものを買え。

---

成果物・検収設計の相談は、お問い合わせフォーム からどうぞ。