システム開発の成果物。納品時に受け取るべきもの

僕がシステム開発の成果物を確認するとき、最初に設計書の冊数を数えません。資料が多くても、本番で動いている版を特定できず、公開手順を担当者しか知らなければ、委託終了後の運用は止まります。

受け取るべき成果物は、現在の開発会社へ質問できない状況でも、別の担当者が運用、改修、復旧を進められる情報と権限です。ソースコード一式や設計書一式という名前だけでは足りません。どの版を、どの形式で、誰が更新し、受領側が何を実行できたら引き渡し完了かまで決めます。

非エンジニアの経営者が、コードやデータベース設計を自分で検査する必要はありません。経営者が決めるのは、会社へ残す能力です。技術担当者が交代しても顧客への提供を続け、必要な変更を選び、障害から戻せる条件を契約と検収へ入れます。

システム開発の成果物は、三つの作業を再現できる状態で決めます

一つ目の作業は運用です。利用者を追加し、問い合わせを調べ、定期処理と監視を確認し、外部サービスの変更へ対応できる必要があります。操作マニュアルだけでなく、管理画面の入り方、通知の行き先、日々見る記録、判断する担当者が必要です。

二つ目の作業は改修です。稼働中のコードと設定を特定し、変更理由を読み、テストを行い、安全な環境へ公開できる状態を求めます。ソースコードを圧縮ファイルで一度受け取っても、現在の本番版と対応しなければ改修の起点にはなりません。

三つ目の作業は復旧です。バックアップからデータを戻し、直前の公開を取り消し、障害前の版へ切り戻せる手順と権限を残します。手順書が存在しても、必要なアカウントへ入れず、復元を試した記録もなければ、緊急時に使えるか判断できません。

基本設計書や詳細設計書という名前を機械的に増やす必要はありません。規模、開発方式、業務上の危険、法令や社内規程によって必要な資料は変わります。大切なのは、資料名の慣例ではなく、運用、改修、復旧の担当者が情報を使えるかです。

成果物の受領と、著作権や利用許諾の確認も分けます。ファイルを受け取っても、別会社による改変や保守が契約上認められるとは限りません。権利の帰属や第三者部品の利用条件は契約担当者と弁護士へ確認し、成果物一覧では受け取る物と技術的な利用方法を具体化します。

システム開発の納品物は、コード・設定・データ・テストをつなげます

コードは、ファイル一式ではなく履歴を含む保管場所で受け取ります。本番で動く版を示すタグや変更識別子、依存する部品の版、ビルドに必要なファイル、変更履歴まで結び付けます。経営者は識別子の読み方を覚えるより、「現在の本番版をどの画面で特定できますか」と聞いてください。

設定には、環境ごとに必要な項目名、用途、取得元、必須か任意かを示すひな型が要ります。本番パスワードや秘密鍵を設計書やコードへ貼る必要はありません。秘密情報は会社が管理できる安全な保管先で渡し、ひな型には値を入れる場所と発行・更新の担当者を残します。

データ定義では、保存する項目名だけでなく、業務上の意味、入力条件、項目同士の関係、正しい記録を決める担当部署を確認します。既存システムから移した場合は、新旧項目の対応、変換規則、除外した記録、照合結果も必要です。画面に同じ名称が表示されても、請求日と入金日を取り違えれば保守担当者は正しい修正を選べません。

テスト結果には、対象となる版と環境、実行日、確認した条件、期待した結果、実際の結果、未実施や不合格の課題を結び付けます。「全項目合格」という報告だけでは、権限、外部連携、データ移行、復旧を確認したか分かりません。後から同じテストを実行するための手順や自動テストも、コードと同じ保管場所から追える状態にします。

コード、設定、データ定義、テスト結果は別々の箱へ置いて終わりません。同じ版を指しているかを確認します。テスト後にコードだけ変わった場合は、どの確認を再実行したかを更新し、本番版とテスト済みの版が食い違わないようにします。

公開・復旧・管理権限もシステム開発の成果物に含めます

公開手順には、作業コマンドだけでなく、開始を承認する人、公開前に確認する条件、公開後に見る画面、失敗時に止める条件を入れます。切り戻し手順には、戻す版、データの扱い、中止を決める人、利用者への連絡を残します。最新版の文章があっても実行履歴がなければ、安全に戻せるか確かめられません。

管理権限は、IDとパスワードの一覧ではありません。リポジトリ、クラウド、ドメイン、アプリ配信、監視、バックアップ、外部サービスについて、会社側の管理者が利用者を追加・停止できる状態を作ります。請求先、サポート窓口、多要素認証の復旧先も会社側で確認し、共有アカウントへの依存を減らします。

判断記録には、採用した技術名だけでなく、守りたかった業務、比べた案、選んだ理由、受け入れた危険、見直す条件を残します。別の担当者が「古い設計だから」と置き換える前に、当時の制約を確認できます。会議録を全て納品するより、後の改修判断に必要な決定を短く追える形が役立ちます。

保守引継ぎでは、未解決の課題、既知の制約、障害履歴、定期作業、監視通知、外部サービスの連絡先、次に更新が必要な時期を渡します。担当者名だけでは、退職や契約終了で情報が切れます。会社の保管場所、責任部署、次回確認日まで置きます。

開発会社を替える可能性があるなら、資料提出だけで引き継ぎ完了にしません。開発会社の変更で並走と復旧試験を行う手順で説明しているように、受領側が小さな変更、公開、切り戻しを実行し、旧会社なしで進められるかを確かめます。

成果物一覧には、更新責任・受領形式・確認方法を書きます

契約書の成果物一覧へ「ソースコード」「設計書」「テスト結果」とだけ書くと、納品日に両社の想定がずれます。成果物ごとに、対象範囲、更新する人、更新する契機、提出時期、受領形式、保管場所、受領者、確認方法を書きます。

更新責任は、作成者の名前だけではありません。仕様を承認した時、データ項目を変えた時、外部サービスを替えた時、公開手順を直した時に、誰が関連資料を更新するかを決めます。開発会社が初版を作り、発注側が業務上の意味を承認し、保守担当者が公開後も更新する成果物もあります。

受領形式は、利用目的に合わせます。署名済みの合意文書を固定形式で残す場面はありますが、設定ひな型、データ定義、手順、判断記録は、更新履歴を追えて編集できる形式が向いています。図の画像だけを受け取る場合も、元の編集データや更新方法が必要かを確認します。

保管場所は個人の端末や委託先のアカウントに限定しません。会社名義の保管先へ置き、発注側の管理者が閲覧者を追加・停止できるかを確かめます。納品日だけ一時的にダウンロードできるリンクでは、将来の保守担当者が最新版へ到達できません。

確認方法には「受領しました」と返事する以外の動作を置きます。コードなら稼働版を特定して安全な環境へ公開し、設定ひな型なら必要な値を別経路で受け取って環境を作ります。データ定義なら重要な帳票の項目を実データと照合し、公開手順なら切り戻しまで試します。

成果物の合否は、システム本体の検収と結び付けます。システム開発の検収で版と受入結果を記録する方法も使い、納品物がそろった日、確認に使った版、不足を通知する窓口と期限を契約前に決めてください。

納品前は、受領側が空の環境から再現します

納品確認を、開発会社による画面共有だけで終えないでください。受領側の技術担当者が新しい作業環境でコードを取得し、手順に沿って必要な部品を準備し、テストを実行し、隔離した環境へ公開します。説明した本人の端末だけで動く状態は、引き渡し完了とは判断できません。

公開まで進めたら、小さな変更を一件加え、レビュー、テスト、公開、切り戻しを同じ資料で進めます。バックアップは保管履歴を見るだけでなく、隔離した環境へ復元して重要な業務データを確認します。管理権限では、会社側の管理者が検証用の利用者を追加し、停止できるかを試します。

社内にエンジニアがいない場合は、契約当事者から独立した技術者へ再現確認を依頼できます。経営者は実行結果として、止まった手順、足りない権限、古い資料、未確認の復旧作業を受け取り、納品前に担当者と期限を決めます。

将来の内製化を考えている会社は、システム内製化で採用前に引き取れる環境を作る手順と同じ確認を、委託契約の終了時だけでなく開発中から行ってください。社内担当者が定例的に資料を開き、公開と復旧へ参加すれば、納品日に大量のファイルを受け取るだけの引き継ぎを避けられます。

成果物一覧を受け取ったら、契約書と見積書も同時に開いてください。顧客への影響が大きい業務を一つ選び、稼働版を特定する資料、設定ひな型、データ定義、テスト結果、公開と切り戻しの手順、管理権限、判断記録、保守引継ぎがどこにあるかを確認します。

見つからない成果物には、資料名だけを足しません。更新する人、受領形式、保管場所、確認する動作、期限を開発会社と決めます。受領側が一連の作業を再現できた時点を引き渡しの合格条件にすれば、成果物を保管庫の資料ではなく、事業を続けるための手段として会社へ残せます。