システム開発の成果物とは？工程別の一覧と受け取る前の確認点

成果物は、依頼した仕事から受け取る具体物。作業や効果と分ける

たとえば「申込受付の仕組みを設計する」は作業です。その結果を説明する画面・処理の設計資料は成果物の候補になります。「使い方を説明する」は作業で、操作手順や説明資料は具体物です。「名簿の照合作業を減らす」は目指す効果であり、資料を受け取ったことだけで効果が出たとは判断できません。

「成果物」と「納品物」は、今回の依頼で受け取る対象を確認する

開発中に作るものを広く成果物と呼ぶ場合も、納入する対象を成果物と呼ぶ場合もあります。用語だけで判断せず、今回どれを受け取り、どれは開発側の内部資料で、どれを確認のために閲覧できるかを合わせます。完成したシステムを使えることと、内部のプログラムや全ての設計資料を受け取れることは同じではありません。

受け取る対象は、依頼の範囲や契約、利用するサービスの条件によって異なります。この記事の一覧は全てを必須納品にする規則ではなく、自社が使う目的から質問するための代表例です。

工程別の成果物一覧は、「何に使うか」と組にして読む

開発の工程名や資料名は会社・案件によって違います。基本設計・詳細設計を分ける場合も、短い周期で設計・開発・試験を繰り返し、管理ツールに内容を残す場合もあります。次の区分は、確認する目的から代表例を整理したものです。一つの工程ごとに一冊の資料や一枚の画像を作るという意味ではありません。

要件の資料では、実現したい仕事と対象外を合わせる

要件定義書、業務の流れ、機能・データ・画面や帳票の一覧、性能や利用条件などが候補になります。何を実現するか、誰が使い、どんな条件が必要かを説明するための物です。業務の対象とシステム化する範囲、業務担当が続ける判断も確認します。

IPAの要件定義の説明も、業務の要求を文書化し、システムの機能・非機能の要求を整理して関係者と合意する流れを示し、作成する文書はプロジェクトによって異なるとしています。IPA DX SQUARE：要件定義の説明

設計資料では、画面・処理・データの対応を見る

画面の項目、入力や変更の処理、保存するデータ、他のシステムへ渡す情報などが、要件とどう対応しているかを読みます。発注側が確認する資料と、開発者が実装・変更のために使う詳細資料を区別し、読む人に必要な説明があるかを相談してください。

IPAのアーカイブには、業務の流れ、データ項目、システム間の情報、画面・帳票、運用などを説明する資料の実例分類があります。名前だけをコピーするより、何を明確にする資料かを読む参考になります。掲載サンプルや旧規格の分類を、全案件の必須書式として使う説明ではありません。IPA：要件定義の成果物事例の分類

プログラム・設定は、どこまでを提供し、どう変更できるかを聞く

ソースコードは、人が記述したプログラムの元の内容です。実行するファイル、設定、構築に必要な情報、利用する部品やサービスの説明とは役割が違います。コードを受け取る範囲、対象の版、動かすための前提、保管先と変更する担当を具体に聞きます。自社で実装の内容を判断できない場合は、必要な経験を持つ確認担当や支援の範囲を決めます。

試験記録は、手順の案と実際の結果を分ける

試験計画や確認する項目、条件、手順、期待する結果、実際の結果、問題と再確認の記録などが候補です。「試験済み」という一語では、どの版をどの環境で、どこまで確かめたかが分かりません。計画だけがある状態を、結果が合格した状態へ置き換えないようにします。

移行・操作・運用は、使い始めた後の仕事につなげる

情報を移す対象と手順、確かめ方、日々の操作、問い合わせや障害時の連絡先、更新・バックアップなどの運用に必要な資料を相談します。作業手順を受け取ることと、その担当が必要な操作を行えることは別です。サービス側が担う仕事と自社が担う仕事も分けてください。

同じ「取消を名簿へ反映する」仕事で、資料の中身をつなぐ

この会社の相談で大切なのは、資料名の数ではなく、同じ申込業務が要件から操作までつながることです。取消の連絡内容の確認と、当日の受付での例外判断は、業務担当に残すという役割も残しながら、次のような中身を依頼する候補にします。以下の抜粋は、説明用に作った案です。実際の画面やコード、受領した資料を示すものではありません。

設計資料に「取消は対象外」と書いてあっても、何を取り消す操作なのか、名簿のどの条件へ反映するのかが分からなければ質問が残ります。試験でも、取消の登録を行い、対応する名簿の対象を確かめるように、同じ業務のつながりをたどります。入力を間違えた場合、変更権限がない場合、変更を戻す場合など、業務で必要な例外も確認対象へ相談します。

図で見る問い：取消の連絡を受けた担当が、どの資料のどこを見れば、名簿へ反映する仕組みを確かめられるでしょうか。同じ申込みを扱う要件のメモと設計の条件、試験の案を見てください。

この解説図を原寸で見る

図の読み方：「取消は名簿の対象外」という一つの条件を、要件・設計・確認する案へ結び付けます。資料が並んでいること自体を、実装や試験の完了にはしません。

今回受け取る範囲は、開発方法と自社で続ける仕事から選ぶ

後半の受領・内容確認・業務確認を分ける図も使い、受け取る物を、誰がどの仕事で確かめるかへ結び付けます。

独自に開発する部分と、既製品の設定で使う部分、外部サービスを利用する部分では、受け取れる物と必要な確認が変わります。自社の今後の更新や、別担当への引継ぎで何が必要になるかを考え、提供対象と利用条件を個別に確認します。

資料を作らないと決める場合も、その資料が担う説明や確認をどこで行うかを考えます。逆に「念のため全ての資料を」と依頼する前には、誰が何に使うかを確かめてください。今回の確認・運用に必要な情報を欠かさず、使い道のない書式の数だけを増やさないためです。

今回合意した納入範囲は未確認です。ソースコードの提供、第三者の部品や素材、利用するサービスの条件、権利や変更の扱いは、案件の資料と関係担当に確認します。この記事から個別の納品義務や権利帰属を判断することはできません。

依頼には、中身・対応する版・渡す時点・確認する人を書く

同じ仕事を資料へつなぐ図も使い、今回必要な中身と、対応する版・渡す時点を具体化してください。

「操作マニュアル一式」だけでは、誰がどの操作を行うための資料か、更新後の内容か、いつ読めるかが伝わりません。下は同じ申込業務について、依頼内容を具体化するための案です。資料の形式を先に固定するより、使う人の目的と必要な中身から合わせます。

この案には、実際の対象の版・納入日・保管先・確認する担当と方法の回答がまだありません。下記は未確認の条件で、説明用に日付や担当者を作って埋めた例ではありません。

更新されたときは、システムと資料の対応も確かめる

画面の項目や操作が変わったのに手順だけが古いと、受け取った資料を業務で使いにくくなります。対象のシステムの版と資料の版、何が変わったか、どれが最終の対象かを対応させます。確認用の案を受け取る時点と、修正を反映した物を受け取る時点も分けて相談してください。

NASAのソフトウェア調達ガイダンスは、その対象となる調達で、成果物の内容・形式・納入日・レビュー期間・受入手順を具体化することと、納入後の確認・管理を分けて示しています。ここではその区別を、依頼内容を考える参考にしています。日本の民間案件へNASAの規則や全成果物を一律に義務付ける説明ではありません。NASA：Acquisition Guidance（Ver C）

受け取ったこと、内容を確かめたこと、業務で使えたことを分ける

資料の送付連絡やファイルの存在だけでは、中身が依頼を満たすかも、必要な仕事を行えるかも分かりません。確認では、次の問いを同じ成果物と対象の版に結び付けます。

担当者は、誰が内容を読み、誰が操作を確かめ、誰が結果から判断するかを分けて相談します。人数を一律に増やす意味ではなく、社内だけで判断できない内容があれば、適切な支援を依頼するためです。業務担当へ全てのコード品質の判定を任せたり、技術担当だけで業務の扱いを決めたりしないようにします。

図で見る問い：操作手順のファイルが届いたら、それだけで確認完了にしてよいでしょうか。「開けた」「必要な説明がある」「同じ条件で仕事を確かめた」の違いを見てください。

この解説図を原寸で見る

図の読み方：受領欄の記入から、内容や業務の合格を推定しません。不足した説明や結果を対象の資料・版へ返し、確認先と次の対応へつなげます。この例ではいずれも実施していません。

足りない物や食い違いは、対象・箇所・困る仕事を示して返す

たとえば「取消の手順はあるが、誤って対象を変えたときの相談先がない」なら、対象の手順と箇所、業務上困る場面、求める説明を相手へ伝えます。修正版が届けば、修正した箇所と関係する操作を同じ前提で確かめます。「送ってもらった」「修正したと言われた」だけで判断を進めないようにしてください。

受入の操作を組み立てる方法や、残る課題と引継ぎを含めて開発を閉じる条件は、別の判断です。本稿は、まず何を納入対象にし、どの内容を確認するかを具体化する説明です。終結の相談へ進むときは、未解決の課題と引継ぎを分ける終結記録も参考にできます。

まとめ：成果物の名前を、使う仕事と確認する中身へ戻す

システム開発の成果物は、完成したシステム、要件や設計の資料、提供対象のプログラム・設定、試験の記録、移行・操作・運用の資料などです。必要な物は依頼の範囲と開発方法で変わるので、一覧を全部必須にせず、今回の仕事に何が必要かを選びます。

依頼では、使う人と目的、必要な中身、対象の版、形式と保管・アクセス、渡す時点、確認する人と方法を具体化してください。受領・内容の確認・業務で使える確認を分け、足りない条件は質問として残します。

会社・仕事・資料の抜粋は、説明用に作った架空例です。実際の顧客の納品物や稼働画面ではありません。 資料に書いた条件や手順は依頼する内容の案です。合意済みの仕様、受領済みの成果物、実施済みの試験結果ではありません。