プロジェクトの成果物（デリバラブル）とは？種類・例と受け入れの流れ

成果物は英語でデリバラブル（deliverable）といい、「引き渡すべきもの」という意味です。プロジェクトマネジメントでは、プロジェクトが作り出す、完成したかどうかを確かめられる製品・サービス・結果を指します。

ポイントは「確かめられる」ことです。「使いやすいシステム」では、できたかどうかを判断できません。「要件定義書で合意した30の機能を備えたシステム」なら判断できます。成果物を定義するときは、受入基準（どうなったら完成と認めるか）とセットにします。

WBS（作業分解構成図）は、この成果物を細かく分けて整理した図です。プロジェクトのスコープは、どんな成果物を作り、そのために何の作業をするかで決まります。

成果物は「作り出すもの」、タスクは「そのための作業」です。たとえば「設計書」は成果物で、「設計書を書く」はタスクです。

見分けるコツは、成果物を名詞で、タスクを動詞で書くことです。WBS は成果物を中心に分解し、作業の順番や期間はスケジュールを作る段階で決めます。成果物の一覧に「調査する」「調整する」のような動詞が混ざっていたら、作るものが決まっていないサインです。

成果物は、大きく次のように分けられます。

顧客に引き渡す成果物（最終成果物）と、途中で作る成果物（中間成果物）を分けて考えることもあります。設計書のように、中間成果物が次の工程の材料になることも多いです。

予測型のシステム開発を例に、工程ごとの主な成果物を並べます。中間成果物は次の工程の材料になり、最後に本番のシステムと関連文書が引き渡されます。

どの成果物を作るかは、プロジェクトの規模や契約で変わります。必要なものを選んで作るのが基本です。

予測型のプロジェクトでは、成果物は次の流れで「完成」から「引き渡し」まで進みます。PMBOK®ガイド第6版でよく知られた流れで、検証済み成果物（Verified Deliverables）と受け入れ済み成果物（Accepted Deliverables）を区別します。

検証（品質管理）は「仕様どおりに作れたか」を内部で確かめることです。スコープの妥当性確認は「顧客が受け入れるか」を外部と確かめることです。順番は内部の検証が先です。検証していない成果物を顧客に見せると、不具合で受け入れを断られやすくなります。詳しくは スコープの妥当性確認と品質管理の違い で扱っています。

日本の契約の実務では、顧客が成果物を確かめて受け取ることを「検収」と呼ぶことが多く、受け入れ済み成果物に近い考え方です。

アジャイルでは、スプリントごとにインクリメント（使える状態の成果）を作り、スプリント・レビューで関係者に見せて意見をもらいます。完了の定義（DoD）を満たしたものだけを「完了」と扱う点は、検証の考え方と同じです。

成果物と混同しやすい言葉に、アウトプットとアウトカムがあります。

今の PMBOK®ガイドや PMP 試験は、成果物を作ることより、その先のアウトカムと価値を重視しています。成果物が仕様どおりにできても、使われずにアウトカムが出なければ、目的を果たしたとは言えません。スコープの考え方は スコープ・マネジメント で詳しく扱っています。

ECO 2026年版の Process 領域には、スコープを定めて関係者の合意を得るタスクがあります。プロジェクトの終結で、完了の承認を得るタスクもあります。成果物については、次のような場面がよく出ます。

• ✓顧客が成果物の受け入れを拒んだ → まず受入基準に照らして、どこが合っていないかを確かめる。
• ✓検証の前に顧客に見せようとしている → 先に内部で品質を確かめる。
• ✓成果物はできたが使われていない → アウトカムと価値の観点で原因を探る。
• ✓受入基準があいまい → 計画の段階で、関係者と具体的な基準を合意しておく。

成果物の受け入れのタイミングは、マイルストーン として置かれることが多いです。プロジェクトの最初に関係者と成果物の範囲をそろえる場としては、キックオフ・ミーティング が使われます。成果物をめぐる判断は 無料模試30問 でも練習できます。