納品完了時に受け取るべきもの一覧（ソースコード・設計書・アカウント）

開発会社から「検収完了です、これで納品は以上となります」という連絡が届いたとき、そのまま「ありがとうございました」で終わらせていないでしょうか。プロジェクトが無事に完了した安堵感から、受け取るべきものを確認しないまま契約を締め、担当者間のやり取りも自然消滅していく——このパターンは、ひとり情シスや総務兼任でシステム担当を任されている会社で驚くほどよく起こります。

問題が表面化するのは、たいてい納品から数ヶ月〜数年後です。軽微な不具合が出て開発会社に問い合わせたら、すでに担当者が退職していて話が通じない。別の会社に見積もりを頼もうとしたら「ソースコードがないと何も手が出せません」と言われる。サーバーやドメインの管理画面にログインしようとしたら、IDもパスワードも社内の誰も知らない。こうした事態は、納品完了のタイミングで受け取っておくべきものを受け取っていなかったことが原因であるケースがほとんどです。

この記事では、システム開発プロジェクトが納品完了に近づいた担当者向けに、開発会社から受け取っておくべきものを「ソースコード」「設計書・ドキュメント」「アカウント・権限」「データ」「契約・法務関連書類」「保守・運用に関する情報」の6つのカテゴリに分けて、チェックリスト形式で整理します。なぜそれが必要なのか、受け取れなかった場合にどうすればよいかも合わせて解説します。

結論: 納品完了時に受け取るべきものは6カテゴリ

先に全体像を示します。プロジェクトの規模や契約内容によって過不足はありますが、以下の6カテゴリが基本の骨格です。

このうち、特に見落とされがちで、かつ後になって困る度合いが大きいのが「アカウント・権限」と「設計書・ドキュメント」です。ソースコードは「納品物」として意識されやすい一方、管理系のアカウントや設計の背景情報は「開発会社が使っているだけの内部情報」と誤解され、引き渡しの対象から漏れやすい傾向があります。

以下、カテゴリごとに具体的な確認項目を見ていきます。

ソースコード一式は「動かせる状態」で受け取る

ソースコードは最も分かりやすい納品物ですが、「ファイルを受け取った」だけでは不十分な場合があります。実際にそのソースコードを使ってシステムを再構築・改修できるかどうかまで確認する必要があります。

確認すべき項目

• 全ソースコード一式（フロントエンド・バックエンド・バッチ処理・インフラ設定ファイルなど、システムを構成するすべてのコード）
• ビルド・デプロイの手順書（どのコマンドで、どの環境に、どうデプロイするか）
• 使用しているライブラリ・フレームワークとそのバージョン一覧
• 環境構築に必要な設定ファイル（.envのひな形など、機密情報を除いたもの）
• Gitなどのバージョン管理システムを使っている場合は、リポジトリそのものへのアクセス権（コミット履歴込み）

ソースコードの受け渡し方法として理想的なのは、ZIPファイルでの一括受領ではなく、GitHubやGitLabなどのリポジトリを、開発会社のアカウント配下ではなく自社（または将来別会社に依頼する際も引き継げる中立的な）アカウント配下に置いてもらう形です。コミット履歴が残っていれば、「いつ・誰が・なぜこの実装にしたか」という変更の背景をたどることができ、後任の開発会社が引き継ぐ際の負担が大きく減ります。

「ソースコード一式をお渡ししました」と言われてZIPファイルを受け取ったものの、いざ改修が必要になって別の開発会社に見せたら「これはビルドできる状態になっていません。設定ファイルが一部欠けています」と言われた——という相談は珍しくありません。受け取った直後に、自社側で（またはセカンドオピニオンとして別の技術者に）実際にビルドが通るかまで確認しておくと安心です。

なお、フルスクラッチ開発で開発されたシステムであれば、この一式がなければ実質的に何も引き継げません。パッケージ製品をカスタマイズしたシステムの場合は、パッケージ本体のライセンスとカスタマイズ部分のソースコードが別物である点にも注意してください。

設計書・ドキュメントは「なぜそうなっているか」を残す

ソースコードそのものよりも軽視されがちですが、後々の改修や引き継ぎで実務上のダメージが大きいのが設計書・ドキュメント類の欠落です。コードを読めば「何をしているか」は分かっても、「なぜそういう仕様にしたか」という背景は、ドキュメントか担当者への聞き取りでしか分かりません。

確認すべき項目

• 要件定義書（プロジェクト開始時にどんな要望を伝えたか、それがどう仕様に落とし込まれたか）
• 設計書（画面設計、データベース設計、外部連携の仕様など）
• テスト仕様書・テスト結果報告書
• 操作マニュアル・利用者向けの説明資料
• 開発中に発生した仕様変更の履歴（何を、いつ、なぜ変更したか）

この中でも特に価値が高いのが、仕様変更の履歴です。プロジェクトの途中で「この機能はやっぱり不要になった」「この処理はこういう例外に対応するために追加した」といった経緯は、完成したシステムのコードだけを見ても分かりません。数年後に同じ機能を「なぜこんな回りくどい作りになっているんだろう」と誤解して単純化してしまい、当時避けていたはずの不具合を再発させる、という失敗は実務でよく起きます。

すべてを完璧な文書として整備してもらうのは現実的でない場合もありますが、最低限、要件定義書・設計書・主要な仕様変更の記録はテキストやスプレッドシートの形で残してもらうことをおすすめします。ドキュメントが薄い状態で契約が終わってしまうと、後から追加で作成してもらうのは難しくなります。

アカウント・権限は「管理者権限」で受け取る

最も見落とされやすく、かつトラブルに直結しやすいのがこのカテゴリです。開発会社が構築時に取得・利用していた各種アカウントの管理者権限が、いつまでも開発会社側にしかない状態のまま運用が続いてしまうケースが多く見られます。

確認すべき項目（一例）

• サーバー・クラウド基盤（AWS、Google Cloud、レンタルサーバーなど）の管理者アカウント
• ドメインの管理（レジストラのアカウント、DNS設定の管理権限）
• SSL証明書の管理・更新権限
• SaaS・外部サービス連携先（決済代行、メール配信、分析ツールなど）のアカウント
• 管理画面（CMS、ダッシュボードなど）の管理者アカウント
• ソースコードリポジトリの管理者権限

これらのアカウントが開発会社名義のまま、あるいは開発会社の担当者個人のメールアドレスで登録されたままになっていると、契約終了後にログインできなくなったり、担当者の退職と同時にアカウントごと連絡が取れなくなったりするリスクがあります。これはベンダーロックインの典型的な発生パターンの一つでもあります。

理想は、契約開始時点からアカウントを自社名義・自社管理のメールアドレスで取得し、開発会社にはそのアカウントへの「作業用の権限」だけを付与する体制です。すでに開発会社名義で取得されてしまっている場合は、納品完了のタイミングで名義変更またはオーナー権限の移管を必ず依頼してください。

• 各アカウントのログインID・パスワード（可能なら二段階認証の設定情報も）
• アカウントの契約者名義が自社になっているかの確認
• 支払い方法（クレジットカード情報など）が開発会社側に紐づいたままになっていないかの確認

支払い方法の名義は特に見落とされがちです。ドメインやサーバーの利用料が、いつまでも開発会社のクレジットカードから引き落とされている状態では、その会社との取引を終えたくても事実上終えられません。

データは「汎用形式」でエクスポートしてもらう

システムに蓄積された業務データそのものも、忘れずに受け取っておくべき資産です。特にシステムを乗り換える予定がなくても、定期的に自社側でバックアップを保持しておくことは、ランサムウェア被害やサービス側の障害への備えとしても意味があります。

確認すべき項目

• 本番データベースの内容を、特定のシステムに依存しない汎用形式（CSVなど）でエクスポートしたもの
• データベースの構造（テーブル定義、項目の意味）を示すドキュメント
• 画像・PDFなどのファイル類（システム内にアップロードされたもの）一式
• 定期バックアップの仕組みが今後も動き続けるかどうかの確認

データのエクスポートは、システムが稼働している間であればいつでもできると考えがちですが、実際には開発会社との契約が切れた後に依頼すると、対応してもらえない、あるいは追加費用が発生することがあります。納品完了・検収合格のタイミングで、最新の状態のデータを一度エクスポートしてもらい、自社で保管しておくことを強くおすすめします。

契約・法務関連書類は「著作権の帰属」を必ず確認する

技術的な成果物だけでなく、契約に関する書類も納品完了時にまとめて確認しておくべき項目です。

確認すべき項目

• 契約書一式（基本契約書、個別契約書、注文書・注文請書など）
• 検収書（検収に合格したことを示す書類。日付・内容の記録として重要）
• 見積書・請求書（費用の内訳を後から確認する際に必要）
• 著作権の帰属に関する条項の内容

この中で最も実務上の影響が大きいのが、著作権の帰属です。著作権法上、プログラムの著作権は原則として作成した開発会社側に帰属します。発注者に著作権を譲渡する、あるいは自由に使用・改変してよいという内容が契約書に明記されていない限り、納品されたソースコードであっても、法的には自由に改変・再利用できない可能性があります。

著作権法第61条は、著作権の譲渡について「著作権を譲渡する契約において、第二十七条又は第二十八条に規定する権利が譲渡の目的として特掲されていないときは、これらの権利は、譲渡した者に留保されたものと推定する」と定めています。つまり、契約書に「著作権を譲渡する」とだけ書かれていて、翻案権（改変する権利）などの条項が明記されていない場合、それらの権利は開発会社側に残ったままと推定されてしまいます。

この推定規定があるため、契約書の著作権条項は「譲渡する」という一言だけで終わっていないか、契約不適合責任に関する条項と合わせて確認しておく必要があります。契約時点で確認しきれていなかった場合、納品完了のタイミングでもう一度契約書を読み返し、疑問点があれば書面で開発会社に確認する、あるいは専門家（弁護士等）に相談することをおすすめします。

保守・運用に関する情報は「引き継ぎメモ」として残す

保守契約を同じ会社と継続する場合であっても、しない場合であっても、システムを実際に動かし続けていく上で必要な運用情報は、口頭の説明だけで終わらせず、文書として残してもらうべきです。

確認すべき項目

• 保守契約の内容（対応範囲、対応時間の目安、費用）
• 障害発生時の連絡フロー（誰に、どの窓口から連絡するか）
• 既知の不具合・制約事項（「この操作をすると稀にエラーが出る」といった注意点）
• 定期的なメンテナンス作業の有無（証明書の更新、ライブラリのアップデートなど）
• 今後発生しうる追加費用の見込み（アクセス増加時のサーバー費用増額など）

特に「既知の不具合・制約事項」は、開発会社の担当者の頭の中にしか残っていないことが多い情報です。担当者が異動・退職すると、この情報は事実上失われてしまいます。納品完了のタイミングで「今のうちに聞いておきたいこと」として、担当者に直接ヒアリングし、簡単なメモでよいので残しておくことを強くおすすめします。

チェックリストにまとめる

ここまでの内容を、実際に使えるチェックリストの形にまとめます。プロジェクトの規模に応じて、該当しない項目は削って構いません。

ソースコード

• [ ] 全ソースコード一式を受領した
• [ ] ビルド・デプロイ手順書を受領した
• [ ] 使用ライブラリ・フレームワークの一覧を受領した
• [ ] リポジトリの管理者権限が自社側にある

設計書・ドキュメント

• [ ] 要件定義書を受領した
• [ ] 設計書（画面・データベース・外部連携）を受領した
• [ ] テスト仕様書・結果報告書を受領した
• [ ] 操作マニュアルを受領した
• [ ] 主要な仕様変更の履歴を確認した

アカウント・権限

• [ ] サーバー・クラウド基盤の管理者権限が自社名義になっている
• [ ] ドメインの管理権限が自社名義になっている
• [ ] 各種SaaS連携先のアカウントを棚卸しした
• [ ] 管理画面の管理者アカウントを受領した
• [ ] 支払い方法（クレジットカード等）が自社名義になっている

データ

• [ ] 本番データを汎用形式でエクスポートしてもらい保管した
• [ ] データベース構造のドキュメントを受領した
• [ ] アップロードファイル一式を受領した

契約・法務関連書類

• [ ] 契約書一式・検収書を保管した
• [ ] 著作権の帰属条項を確認した
• [ ] 見積書・請求書を保管した

保守・運用に関する情報

• [ ] 保守契約の内容（継続する場合）を確認した
• [ ] 障害時の連絡フローを確認した
• [ ] 既知の不具合・制約事項をヒアリングしメモを残した

この記事のチェックリストに沿った確認は、当メディアのシステム管理台帳の考え方とも重なります。受け取った情報は受け取りっぱなしにせず、台帳の形で一元管理しておくと、後任者への引き継ぎや、次に何かトラブルが起きたときの対応がスムーズになります。

いつ確認を始めるべきか: 検収前後のタイミング

「納品完了時に受け取るべきもの」というと、検収がすべて終わった後にまとめて確認する作業のように思えるかもしれませんが、実際には検収の前後で分けて考えるとスムーズです。

検収に合格する前

検収に合格すると、法的には代金の支払い義務が確定し、発注者側の交渉力は相対的に下がります。検収前であれば「この資料一式が揃うまでは検収に合格しない」という形で、資料提供を検収条件に組み込むことができます。ソースコード一式やアカウント情報の引き渡しが、検収合格の前提条件になっていることを契約書やSOW（作業範囲記述書）に明記しておくと、後になって「もらえるはずのものがもらえない」という事態を防ぎやすくなります。

すでに契約書にそうした条項がない状態でプロジェクトが進んでしまっている場合でも、検収に合格する前の段階であれば、「検収合格の連絡の前に、このチェックリストの項目を確認させてください」と担当者に伝えることは十分に現実的な交渉です。

検収に合格した後

検収合格後は、契約上の一連の作業が完了した状態になるため、追加の資料提供を依頼する際の心理的なハードルが上がります。とはいえ、契約書に引き継ぎ協力に関する条項があれば、検収合格後であっても正当な依頼として成立します。また、多くの開発会社は、良好な関係を維持する目的もあって、検収後の資料提供依頼に応じてくれることが実務上は多くあります。

検収合格から時間が経てば経つほど、担当者の異動・退職やプロジェクト資料の散逸によって対応が難しくなっていくため、「合格したらすぐ」を意識して動くことが望ましいといえます。

プロジェクトの契約形態によって変わる注意点

受け取るべきものの基本的な考え方は共通していますが、契約形態によって特に注意すべきポイントが変わります。

請負契約の場合

請負契約は成果物の完成を約束する契約であるため、「何を納品物とするか」が契約書または作業範囲記述書（SOW）に明記されているのが基本です。まずはその納品物リストを見返し、実際に受け取ったものと突き合わせることから始めてください。リストにあるのに受け取っていないものがあれば、それは契約上の未履行として、明確な根拠を持って請求できます。

準委任契約の場合

準委任契約は成果物の完成ではなく業務の遂行そのものを目的とする契約であるため、請負契約のように「納品物リスト」が明確に定義されていないことがあります。保守・運用フェーズや、要件が固まりきっていない開発でこの契約形態が使われることが多く、「どこまでが契約の範囲でどこからが追加費用か」の線引きが曖昧になりがちです。契約終了時に何を受け取れるかについても、契約書上で明記されていないケースが多いため、プロジェクトの節目ごとに「現時点の成果物一式を共有してもらう」ことを習慣にしておくと、契約終了時に慌てずに済みます。

保守契約に移行する場合

開発会社との関係が納品完了で終わるのではなく、そのまま保守契約に移行するケースも多くあります。この場合、「保守契約が続く限りは資料も開発会社が持っていれば十分」と考えがちですが、それは危険な考え方です。保守契約はいつか終わる（あるいは開発会社側の都合で終わらされる）前提で、納品完了のタイミングで一度、自社側にも資料の写しを確保しておくべきです。保守契約中であっても、年に一度など定期的に最新のソースコードとデータのバックアップを受け取る運用にしておくと安心です。

よくある失敗パターンとその予防策

実務でよく見られる失敗パターンを整理しておきます。

これらはいずれも、プロジェクトが順調に進んでいるときには意識しづらい項目です。だからこそ、納品完了という一つの区切りのタイミングで、意識的にチェックリストとして確認することに意味があります。

開発会社が倒産・廃業した場合に備える

やや極端なケースですが、開発会社が倒産・廃業してしまい、納品完了後の資料提供を一切依頼できなくなるという事態も、可能性としてはゼロではありません。特に小規模な開発会社に発注している場合、この可能性を完全に無視することはできません。

このリスクへの最も有効な備えは、「倒産・廃業してから慌てて資料を集めようとするのではなく、納品完了のタイミングで受け取れるものはすべて受け取っておく」ことに尽きます。倒産してしまった後では、担当者と連絡が取れない、会社の資料自体が散逸している、法的な請求先すら不明確になる、といった状況になり、事後の対応は極めて困難になります。

逆に言えば、この記事で紹介したチェックリストを納品完了時にきちんと消化しておけば、仮に開発会社が後になって倒産・廃業したとしても、自社が受けるダメージは最小限に抑えられます。「今は元気に営業している会社だから大丈夫」という前提に頼らず、どの開発会社に対しても同じ水準で資料を受け取っておくことが、結果的にリスク管理になります。

受け取った後の保管方法

資料を受け取って終わりではなく、その後の保管方法も重要です。担当者の異動・退職があっても情報が失われないよう、以下のような点に配慮してください。

• 特定の個人のパソコンやメールボックスだけに保存しない（組織として共有されたフォルダやシステムに保存する）
• パスワード・アカウント情報は、Excelファイルへの平文保存のような管理方法ではなく、パスワード管理ツールなど適切な手段で管理する
• 誰が・いつ・何を受け取ったかの記録を残す（受領日・受領物・確認者を一覧化しておく）
• 定期的に（年1回程度）、保管している情報が最新の状態と一致しているか見直す

こうした保管の仕組みそのものが、属人化を防ぐ土台になります。せっかく受け取った資料も、特定の担当者の頭の中や個人フォルダにしか存在しなければ、結局は属人化した情報に逆戻りしてしまいます。

受け取れなかった場合はどうするか

すべての項目を理想通りに受け取れるとは限りません。開発会社側の事情（すでにプロジェクトチームが解散している、担当者が退職しているなど）で、一部の資料が用意できないと言われることもあります。

その場合にまず確認すべきは、契約書に資料提供・引き継ぎに関する義務が明記されているかどうかです。明記があれば、それを根拠に改めて依頼することができます。明記がない場合でも、検収合格前であれば「検収条件の一つとして資料一式の提出を求める」という交渉の余地が残っています。すでに検収が完了し支払いも終えている段階であれば、交渉力は下がりますが、それでも文書で正式に依頼することが第一歩です。

• 口頭ではなくメールなど記録に残る形で依頼する
• 依頼した日付・内容・相手の回答を記録しておく
• どうしても得られない情報は、「ないもの」として次善の対応（自社でのヒアリング記録作成、専門家への相談）を検討する

すべてが揃わないまま契約が終わってしまった場合でも、今から取り戻せるものがないか、一度棚卸しをしてみる価値はあります。特にアカウント・権限まわりは、今からでも名義変更や権限の追加取得を依頼できる場合が多く、優先して手をつけることをおすすめします。

この確認は「乗り換え」の場面に限らない

ここまで解説してきた内容は、開発会社を変える・変えないに関わらず、どのプロジェクトの納品完了時にも共通して当てはまるものです。「今の開発会社に不満はないから大丈夫」と思っていても、担当者の異動・退職、開発会社自体の廃業、料金改定への不満など、将来何らかの理由で別の選択肢を検討する可能性はゼロではありません。

納品直後、関係が良好で協力を得やすいタイミングこそが、こうした資料を一式揃えておく最後のチャンスです。プロジェクトが完了し安堵しているタイミングだからこそ、このチェックリストを使って一つずつ確認しておくことをおすすめします。

受け取った資料をもとに検収そのものをどう進めればよいか整理したい場合は、検収の考え方とテスト項目を解説した記事も参考にしてください。また、すでに開発会社との関係に不満があり乗り換えを検討している場合は、乗り換え時に必要な資料をまとめた記事、既存システムの権利関係を整理する記事も合わせてご覧ください。