目次
1. はじめに
システムは無事にリリースされました。本番稼働も安定しています。
プロジェクトチーム全体がほっと一息ついたその瞬間——「では、成果物の検収に入りましょう。設計書一式・試験成績書・議事録——揃っていますか？」。ベンダーの顔が凍りつきます。発注側も、何がどこまで揃っているか把握できていません。
両者とも、誰も成果物の全体像を把握していなかったのです。
成果物管理の怖いところは、なくてもプロジェクトが進んでしまう点にあります。
コードは書けます。テストは回せます。スプリントは消化できます。けれど成果物管理がなければ、納品直前にすべてが噴き出します。（公共系では、紙製本が必要になることすらあります。）
計画段階で何を作るか決まっていなければ誰も手をつけず、『揃っていない』と気づくのは全員が同時です。
本記事では、この問題に型で立ち向かいます。扱うのは3つだけです。
- 成果物定義一覧——何を・誰が・いつまでに・どこまでやれば「完成」かを明文化する。
- レビュー承認プロセス——承認フローと基準を定義し、品質保証を仕組み化する。
- バージョン管理方法——変更履歴を管理し、差分追跡可能な構造にする。
成果物管理に関するよくある疑問は「よくある質問」を参照してください
2. 成果物定義一覧の作成
成果物の名前・責任者・完了条件を定義し、「あとで揃える」を予防します。
契約段階で成果物の骨格（「基本設計書」「試験成績書」等）は決まりますが、完了条件・レビュアー・期限まで定義されていないことは多々あります。本記事で扱う「成果物定義一覧」は、契約書の成果物を叩き台に、プロジェクト計画段階で「どう完成させるか」を肉付けしたものです。キックオフまでに作り切るのが理想です。
2-1. インプット
- 契約書・提案書（成果物の定義）
- WBS（フェーズごとの成果物の紐付け）
- 過去プロジェクトの成果物一覧（あれば）
2-2. プロセス
STEP 01 契約書の成果物を抽出する
契約書・提案書に記載された成果物をそのまま抽出します。これが一覧の骨格になります。
ただし、契約書に載っているものだけでは足りません。議事録・課題管理表・Q&A管理表など、契約上の成果物には含まれないが検収時に問われる文書があります。
これらは「成果物じゃないから」と言って作らずにいると、検収の席で「議事録は？」「課題管理の履歴は？」と確認した瞬間にベンダーが固まる、という光景は珍しくありません。
発注側としては「当然あるもの」ですが、事前に何が必要かを明示しておかないと、受注側には伝わりません。
心当たりがなければ、末尾のAppendixによくある成果物をまとめていますので、参照してください。
Appendixはこちら
STEP 02 カラムを埋める
抽出した成果物ごとに、成果物名・フェーズ・作成責任者・レビュアー・承認者・完了条件・期限・提出先・納品形式を埋めます。埋めるときのフォーマットとコツは下記の通りです。
- 作成責任者：個人名（例：山田太郎）
- 完了条件：客観的に検証可能な達成基準（例：指摘全件反映・承認者承認済み）
- 期限：YYYY/MM/DD（WBSのマイルストーンに紐付いた具体日）
- 納品形式：PDF正本＋Word原本 / Wiki（Confluence等） / 共有ドキュメント / 紙製本＋PDF
- 【コツ】作成責任者
-
部署名やベンダー名で曖昧に書いた瞬間、責任の所在が溶けて誰もタスクをやらなくなります。必ず「個人名」まで落とし込んでください。
記載例： 開発部 / XX社 ➔ 山田太郎（XX社）
- 【コツ】完了条件
-
「書いたら完成」は完了条件ではありません。作成者以外の第三者（レビュー語や顧客）が客観的に検証できる具体的な達成基準で定義します。ここを曖昧なまま走ると、最後の検収フェーズで100%揉めます。
記載例：
- 設計書： 作成する ➔ 指摘全件反映済み・承認者承認済み
- 試験成績書： テストする ➔ 全ケース実行済み・重要度高の不合格0件・対応計画作成済み・エビデンス添付済み
- 議事録： 書く ➔ 決定事項、TODO、担当記載済み・翌営業日までに配布済み。
- 【コツ】期限
-
「◯月末目処」のような曖昧なスケジュール感は、遅延のボヤを大きくします。WBSのマイルストーン（基本設計完了など）に直結したカレンダー上の具体日を刻んでください。
記載例： 6月末目処 ➔ 2026/06/30（基本設計完了のマイルストーンに紐付け）
- 【コツ】納品形式
-
WordやPDFだけでなく、Wikiや共有ドキュメントも有力な選択肢です。「形式は何ですか？」を検収直前になってステークホルダーに確認しにいくのは論外です。
記載例：
- 契約としての納品 ➔ PDF（正本）＋ Word（原本）
- 日常的な運用保守系 ➔ Wiki（Confluence等・更新頻度が高いもの）
- 議事録・Q&A管理 ➔ 共有ドキュメント（閲覧・検索性を最優先）
- 厳格な監査対応用 ➔ 紙製本 ＋ PDF（原本性が強く求められるもの）
STEP 03 ステークホルダーと合意する
作った一覧は作成者だけのものではありません。
ベンダー委託なら発注側・受注側間で、社内PJならプロジェクトオーナー・関係部署と、キックオフ時点で完了条件・納品形式を合意します。
ここが曖昧なままプロジェクトが進むと、検収時に「これで完成と言えるのか？」が始まります。
2-3. アウトプット
- 成果物定義一覧（1枚）
お問い合わせ メソッドの適用やプロジェクトの推進のご相談はこちら。
3. レビュー承認プロセスの構築
成果物定義一覧で定義したレビュアー・承認者・完了条件に従って、承認まで進めます。
「誰が見るか」「何を基準にするか」は一覧に書いてあるので、それをそのまま実行します。
3-1. インプット
- 成果物定義一覧（2章のアウトプット、レビュアー・承認者・完了条件を参照。）
- レビュー対象の成果物（作成済みの成果物本体）
3-2. プロセス
STEP 01 承認フローに従ってレビューする
ベンダー委託の場合、レビューは通常受注側内部レビューと発注側レビューの2段階で進みます。発注側レビューは最終レビューであり、ここで初めて「受注側内部でレビューされていない」ことが発覚するようでは、全員の時間が無駄になります。
- 作成——作成責任者が成果物を作る
- セルフチェック——作成者自身がレビュー観点で確認する
- 受注側内部レビュー——受注側のレビュアーが観点に基づいて確認し、指摘を出す。この段階で指摘を全件潰す。
- 指摘反映——作成者が指摘を全件反映する
- 発注側レビュー（最終レビュー）——発注側のレビュアーが確認する、受注側内部レビュー済みであることが前提。
- 承認——承認者が最終確認し、承認記録を残す。
発注側レビューは「受注側内部レビューを通過した成果物」を確認する場です。受注側内部で潰せるはずの指摘（誤字・フォーマット崩れ・記載漏れ等）が残っている場合、内容を全て読まずに差し戻すことをルール化します。
「受注側内部レビューを先に通してください」——これだけで双方の時間を守れます。発注側の時間を「受注側がやるべき品質確認」に消費させてはいけません。
STEP 02 レビュー観点に基づいて確認する
「ちゃんと見て」ではレビューになりません。
成果物の種別ごとに「何を確認するか」を定義します。
- 要件定義書：機能要件・非機能要件の網羅性、業務フローとの整合性、優先度・スコープの明確さ。
- 設計書：要件定義書の各要件が設計上どこで実現されているか、対応が取れているか、記載間の矛盾はないか、用語は統一されているか。
- インターフェース定義書：外部システムとの連携仕様に曖昧さはないか、エラーハンドリングの定義はあるか、データ形式・文字コードは明記されているか。
- テーブル定義書：データ型・制約・インデックスの妥当性、正規化の整合性、ER図との一致。
- 試験仕様書：テストケースの網羅性（要件との対応）、異常系・境界値の網羅、判定基準の明確さ。
- 試験成績書：全ケース実行済みか、エビデンスの有無、不合格件数の対応状況、合否判定基準の明確さ。
- 移行計画書：データ移行手順・切り戻し手順の具体性、リハーサル計画の有無、関係者の役割分担。
- 運用保守マニュアル：障害対応フローの具体性、エスカレーション先の明記、バッチ運用手順の網羅。
- 議事録：決定事項・TODO・担当が明記されているか、配布期限が守られているか。
- 課題管理表・Q&A管理表：ステータスが更新されているか、放置されたオープン案件はないか、担当・期限が埋まっているか。
STEP 03 承認記録を残し承認後の成果物を保護する
「誰が・いつ・何を承認したか」を、あとから検索できる形で記録します。同時に、承認済み成果物が無断で書き換えられることを防ぎます。
- 推奨：チケット（Jira・Backlog等）・PRレビュー（GitHub）・Wikiページのコメント承認（Notion・Confluence）・Boxの承認ワークフロー
- 許容：メール（ただし共有メールボックスまたは転送先を統一すること）
- 非推奨：Slackスタンプ・口頭・個人メール
承認記録には「承認した版」を必ず紐付けます。
Gitならコミットハッシュ・SharePoint/Boxならバージョン番号・WikiならページバージョンIDを記録します。承認完了時点で編集権限を制限（ページロック・保護タグ等）します。
承認済みの成果物に変更が入った場合、その成果物は「承認者が承認した内容」とは別物になります。承認記録だけが残っていて、中身が差し替わっている——これは検収上の事故です。
承認後に修正が必要になった場合は、以下の手順を必ず踏みます。
- 承認ステータスを「未承認」にリセットする。
- ロックを解除し、修正を行う。
- レビュー → 承認のフローを再度通す。
- 再承認後、新しいバージョンでロックする。
3-3. アウトプット
- 承認済み成果物（指摘全件反映済み・ロック済み）
- 承認記録（誰が・いつ・何を・どの版で承認したか）
4. バージョン管理方法の確立
成果物定義一覧で定義した納品形式・保管場所に従って、各成果物の変更履歴を一元管理します。
「どれが最新で・何が変わったか」を常に追跡可能な状態にします。
4-1. インプット
- 成果物定義一覧（2章のアウトプット、納品形式・保管場所を参照。）
- プロジェクトのファイル保管先情報（SharePoint・Gitリポジトリ・共有ドライブ 等）
4-2. プロセス
STEP 01 保管場所を一元化する
成果物の正本は1箇所に置きます。
ローカルフォルダ・メール添付・個人のDesktopは禁止です。編集中の作業コピーは許容しますが、確定版は必ず正本置き場に反映します。
STEP 02 履歴管理機能を持つツールを使う
ファイル名にバージョン番号を埋め込む運用（`_v1.0_20250630`等）は避けてください。人手で破綻します。以下のようなツールで履歴を自動管理します。
ファイル名規則が最終手段である理由：人手の運用は必ず破綻します。_v1.1と_v1.2の両方が「最新」と主張する、_finalの後に_final2が生まれる、命名規則を守らないメンバーが1人でもいれば崩壊する——これらは「起きるかどうか」ではなく「いつ起きるか」の問題です。
ツールで履歴管理できる環境があるなら、そちらを使ってください。
STEP 03 変更理由を残す
「いつ・誰が・何を・なぜ変えたか」を記録します。
Gitならコミットメッセージ・Wiki系ならページコメント・Excelなら変更履歴シート。
ツールが何であれ、「なぜ変えたか」まで追える状態にします。
4-3. アウトプット
- 履歴管理された成果物（差分追跡可能な状態）
- 変更履歴（いつ・誰が・何を・なぜ変えたか）
よくある質問
Q. 成果物について：動くシステムを納品すれば、それでよくないですか？
A. システムだけではありません、ソースコード・設計書・試験成績書・議事録——これらもすべて「成果物」です。
そして成果物が揃っていなければ検収は通らず、検収が通らなければプロジェクトは終わりません。
Q. 成果物について：検収って形式的なセレモニーでは？
A. 請負契約では、検収合格＝報酬支払いのトリガーです。
双方の権利と義務の確定行為であり、形式ではありません。準委任でも実務上は成果物の提出を求められるケースが大半です。契約形態にかかわらず、成果物管理は必要です。
Q. 成果物について：公共系や金融系は特殊だと聞きましたが？
A. 特殊です。監査対応で紙製本納品が求められたり、設計書・試験成績書の原本性が問われる世界です。
「ドキュメントは最低限でいい」が通用しない世界があることは覚えておいてください。
Appendix 成果物種別×シチュエーション別 格納ガイド
格納先と納品形式は社内のツール文化に依存します。
現場でよく遭遇する4パターン（A〜D）×成果物種別で、推奨格納先とアンチパターンをまとめました。
- A. 公共・金融・監査厳格
-
監査対応・紙製本・原本性の要件があり、アクセスログと保管年限管理が必須な案件。
- B. エンタープライズ・Microsoft中心
-
社内のMicrosoft 365文化が標準で、Word・Excel納品が前提の案件。
SharePointがファイル置き場の標準。 - C. Google Workspace中心
-
社内のGoogle Workspace文化が標準で、Google Docs・Google Sheets納品が前提の案件。
Google Driveがファイル置き場の標準。 - D. エンジニア主導・モダン
-
内製開発・SaaS系・準委任・運用保守など、契約正本の比重が軽くWiki＋Gitで回す案件。
- アクセスログ・保管年限・権限管理機能を持たないストレージ（社内ファイルサーバー・個人クラウドドライブ・無償プランのDropbox等）に直置きしないこと。
監査で「誰がいつ履歴を見たか」を出せず、成果物ごと差し戻しになります。 - 承認前のドラフトを社外に先出ししないこと。
ドラフトが正本扱いされ、検収時に承認済み版と食い違います。
DOWNLOAD CONTENT
成果物の全量洗い出しから品質採点まで——「成果物管理の型」を完全再現する2つのClaude 専用スキルセットを無料配布！
「成果物管理の型」メソッドを前工程・後工程の2スキルで再現します。
seikabutsu-list は契約書・提案書・WBSを渡すだけで、完了条件・担当・納品形式まで揃えた成果物定義一覧のドラフトを自動生成。
seikabutsu-score は成果物ドキュメントをAIが事前レビューし、100点満点の採点レポート（ゲート判定・欠落項目リスト・AI確信度サマリ）を出力します。
二つのスキルは連携して使用でき、seikabutsu-list が出力した完了条件をそのまま採点基準として seikabutsu-score に渡せます。
【配布内容】methods_ME-012_deliverables.zip
- README.pdf（共通ガイド）
- seikabutsu-list/
- SKILL.md（スキル本体）
- README_list.pdf（利用ガイド）
- templates/
- deliverable-list-template.md
- references/（7ファイル）
- deliverable-master.md
- supplementary-documents.md
- completion-condition-patterns.md
- appendix-a-platform.md
- appendix-b-compliance.md
- appendix-c-delivery-format.md
- appendix-d-team-style.md
- seikabutsu-score/
- SKILL.md（スキル本体）
- README_score.pdf（利用ガイド）
- templates/
- score-report-template.md
- references/（9ファイル）
- scoring-criteria-basic-design.md
- scoring-criteria-detail-design.md
- scoring-criteria-test-plan.md
- scoring-criteria-test-report.md
- scoring-criteria-operation-manual.md
- scoring-criteria-parameter-sheet.md
- scoring-criteria-generic.md
- scoring-calibration.md
- anti-patterns.md
※本スキルはClaude専用の「AIエージェント構築セット」です。他AIでは設計通りの動作にならない場合があります。
※生成AIの特性上、回答の正確性は保証されません。本ツールの利用により生じた不具合・損害・法的トラブル等について、当社は一切の責任を負いかねます。