納品後に「あとはよろしく」と言われて何をどう受け取ればいいか

システム開発の発注が完了し、いよいよ納品というタイミングで、開発会社の担当者から「これで完成です。あとはよろしくお願いします」と言われた経験はないでしょうか。10人未満の会社では、この一言をそのまま受け止めて、深く確認せずに検収を終えてしまうケースが少なくありません。しかし、この「あとはよろしく」という言葉の裏には、発注者側が本来受け取っておくべき情報や権利が、実は渡されていないという事態が潜んでいることがあります。

このガイドでは、発注経験の浅い10人未満の会社が、納品のタイミングで最低限確認し、受け取っておくべきものを、実際のやり取りの流れに沿って具体的に解説します。

なぜ「あとはよろしく」で済まされてしまうのか

小規模な発注では、契約書に納品物の範囲が明確に定義されていないことが多くあります。大規模なシステム開発であれば、要件定義の段階で納品物のリスト(ソースコード一式、設計書、操作マニュアル等)が明文化されるのが一般的ですが、10人未満の会社が発注する小規模な案件では、こうしたプロセスが省略され、口頭でのやり取りのまま進んでしまうことが珍しくありません。

開発会社側にも悪意があるわけではなく、単に「小規模な案件だから、そこまで厳密にしなくてもよいだろう」という判断が働いていることが多いのが実情です。しかし、発注者側からすると、納品時に何を受け取れるのかが分からないまま「完成です」と言われても、そのシステムを今後どう運用し、どう保守していけばよいのか、判断のしようがありません。

納品時に確認すべき6つのカテゴリ

納品物を体系的に確認するために、次の6つのカテゴリに分けて整理することをお勧めします。これは大規模な開発だけでなく、10人未満の会社が発注する小規模な案件にもそのまま当てはめられる枠組みです。

1. ソースコード

まず確認すべきは、開発されたシステムのソースコード一式です。ソースコードは、そのシステムを今後改修したり、別の開発会社に保守を依頼したりする際に不可欠な資産です。「今の開発会社に今後もずっとお願いするから大丈夫」と考えていても、開発会社が廃業したり、担当者が退職したりするリスクは常に存在します。

ソースコードを受け取る際は、次の点を確認してください。

• 最新版のソースコード一式が、圧縮ファイルやGitリポジトリの形で提供されるか
• ソースコードの著作権(著作財産権)が発注者に譲渡される契約になっているか、それとも開発会社に留保されたままか
• ソースコードを動かすために必要な環境構築の手順書が付属するか

著作権の帰属については、契約書に明記されていない場合、著作権法上の原則では制作者(開発会社)に権利が残ることになります。発注者が自由に改修・再配布できる状態にしたい場合は、契約書に著作権譲渡の条項が入っているかを必ず確認してください。

2. 設計書・仕様書

システムがどんな設計思想で作られ、どんな機能仕様になっているのかを示す設計書・仕様書も、重要な納品物です。設計書がないと、後から別の開発会社に改修を依頼する際、一から仕様を解析する作業(いわゆるリバースエンジニアリング)が発生し、余計な費用と時間がかかります。

10人未満の会社が発注する小規模な案件では、大規模な要件定義書・基本設計書・詳細設計書といった重厚な文書までは求めなくても、最低限「どんな機能があり、それぞれ何をするものか」を一覧化した簡易な文書だけは受け取っておくことをお勧めします。

3. アカウント・権限情報

意外と見落とされがちなのが、システムの運用に必要な各種アカウント・権限情報です。サーバーの管理画面、ドメインの管理画面、SaaSツールの管理者アカウント、SSL証明書の管理権限など、開発会社が発注者に代わって取得・設定したアカウントは、すべて発注者側に権限が移譲されているかを確認する必要があります。

これらのアカウントが開発会社名義のまま残っていると、契約終了後に開発会社と連絡が取れなくなった際、自社のシステムであるにもかかわらず、管理権限を取り戻せないという深刻な事態に陥ります。

4. データ

システムに蓄積されたデータ(顧客データ、取引データ等)についても、発注者がいつでもエクスポートできる状態になっているかを確認してください。特にクラウド上で稼働するシステムの場合、データの形式が開発会社独自の仕様になっていると、将来他のシステムに乗り換えたくなった際に、データを持ち出せない「ロックイン」状態に陥るリスクがあります。この状態はベンダーロックインと呼ばれ、契約時・納品時の両方で意識しておくべき論点です。

5. 契約書類一式

見積書、契約書、発注書、請求書といった契約に関する書類一式も、整理して保管しておく必要があります。これらは将来、保守契約の内容を確認したり、トラブルが発生した際に契約条件を確認したりする際の根拠資料になります。10人未満の会社では、こうした書類がメールに埋もれたまま整理されていないケースが多く見られますが、最低限、専用のフォルダにまとめておくだけでも、後々の手間を大きく減らせます。

6. 保守・運用に関する情報

納品後、そのシステムをどう保守・運用していくのかについての情報も、忘れずに確認しておきたい項目です。日常的な操作方法、トラブルが起きた際の対処法、問い合わせ先の連絡先などが、何らかの形で文書化されているかを確認してください。

納品物チェックリスト

ここまで紹介した内容を、実際に納品時に使えるチェックリストとしてまとめました。開発会社との最終確認の際に活用してください。

• ソースコード一式を受け取ったか(圧縮ファイルまたはリポジトリ形式)
• ソースコードの著作権譲渡が契約書に明記されているか
• 環境構築の手順書が付属しているか
• 機能仕様が分かる簡易な設計書があるか
• サーバー・ドメイン・各種SaaSのアカウントが発注者名義になっているか
• データベースの接続情報が共有されているか
• 蓄積されたデータをエクスポートする方法が分かるか
• 契約書類一式(見積書・契約書・発注書・請求書)が揃っているか
• 保守・運用に関する情報(操作方法・トラブル対処法・問い合わせ先)があるか

このチェックリストのすべてを完璧に満たす必要はありませんが、特にソースコードとアカウント情報の2つは、後から取り戻すことが難しくなる項目であるため、優先的に確認してください。より詳細な納品物の確認ポイントについては納品完了時に受け取るべきもの一覧(ソースコード・設計書・アカウント)でも解説されていますので、あわせて参照してください。

検収のタイミングで確認する理由

これらの確認は、検収が完了する前、つまり代金の最終支払いが確定する前に行うことが重要です。検収が完了すると、多くの契約では支払い義務が確定し、その後に「実はソースコードをもらっていなかった」と気づいても、開発会社側に強制力を持って追加対応を求めることが難しくなります。

検収書にサインする、あるいは検収完了の連絡をする前に、このガイドで紹介したチェックリストを一通り確認し、不足があれば検収前に開発会社へ依頼してください。検収のポイントや不具合対応の依頼方法については検収で見るべきポイントと不具合対応の依頼方法でも詳しく扱われています。

「あとはよろしく」という言葉を受け取ったときこそ、確認を後回しにせず、その場で必要な資料・情報が揃っているかを一つずつ照らし合わせるタイミングです。検収後に気づいても、取り戻すのに余計な労力がかかります。

「もらい忘れた」ことに後から気づいたら

すでに検収を終えてしまい、後になってソースコードやアカウント情報を受け取っていなかったことに気づいた場合でも、諦める前にできることがあります。まずは開発会社に対して、丁寧に「納品時に受け取れていなかったものがあるので、共有してもらえないか」と依頼してみてください。悪意を持って渡さなかったのではなく、単に伝達漏れであるケースも多く、依頼すれば対応してもらえることも少なくありません。

依頼する際は、契約書に著作権譲渡やデータ提供の条項があるかを確認し、根拠を示しながら依頼すると、よりスムーズに対応してもらえる可能性が高まります。契約書に明記がない場合でも、多くの開発会社は関係継続を重視するため、常識的な範囲での協力は得られることが多いのが実情です。それでも対応してもらえない場合は、専門家(弁護士等)への相談も選択肢に入れる必要があります。

担当者が変わるタイミングでの再確認

納品後、しばらく経ってから開発会社側の担当者が変わることもあります。担当者交代のタイミングは、これまでの経緯や、渡されているはずの情報に漏れがないかを再確認する良い機会です。担当者変更時の確認事項については開発会社の担当者が変わったときの引き継ぎ確認でも詳しく解説されていますので、担当者交代の連絡を受けた際には、あわせて自社側の納品物チェックリストも見直すことをお勧めします。

保守契約への移行時にも同じ確認を

納品が完了し、保守契約に移行するタイミングでも、改めて納品物の確認をしておくことをお勧めします。特に月額の安価な保守契約に切り替える場合、契約の対象範囲が「軽微な修正のみ」に限定されることが多く、ソースコードやアカウント情報を後から確認・取得する対応が、保守契約の範囲外として追加費用の対象になってしまうこともあります。保守契約の範囲については月1万円台の格安保守契約、契約時点で「範囲外」を確認するで詳しく扱っていますので、納品完了後の流れとしてあわせて確認してください。

複数の開発会社が関わっている場合の確認

10人未満の会社であっても、初期のシステム構築を担当した開発会社と、その後の追加開発・改修を担当した開発会社が異なるケースがあります。例えば、最初にホームページ制作会社に依頼したシステムを、後から別の開発会社に機能追加してもらったような場合です。

この場合、納品物の確認はより複雑になります。それぞれの開発会社が、自分たちが手がけた範囲のソースコードや情報しか把握していないことが多く、「全体としてどこに何があるのか」を俯瞰できているのは発注者だけ、という状態になりがちです。複数の開発会社が関わっている場合は、次の点を意識して確認してください。

• それぞれの開発会社が、どの範囲を担当したのかを明確に整理する
• 各開発会社から、担当範囲のソースコード・設計書・アカウント情報を個別に受け取る
• 全体を統合した状態のシステムがどう構成されているか、可能であれば図示してもらう

複数の開発会社が関わっている状態は、それだけ管理すべき情報が分散しているということでもあります。1つの開発会社に依頼している場合よりも、意識的に情報を集約する作業が必要になる点を認識しておいてください。

社内での保管体制を整える

納品物を無事に受け取れたとしても、それらが社内でどこに保管されているか誰も把握していないという状態では、意味が半減してしまいます。10人未満の会社では、これらの重要な情報を社長個人のパソコンやメールにしか保管していないケースが多く見られますが、これは新たな属人化のリスクを生みます。

受け取った納品物は、次のような形で社内共有できる状態にしておくことをお勧めします。

1. ソースコード・設計書は、クラウドの共有フォルダに保存する
2. アカウント情報は、パスワード管理ツールなど、複数人でアクセスできる形で管理する
3. 契約書類一式は、紙・PDFいずれでもよいので、専用のフォルダにまとめる

これらの情報を、開発会社とのやり取りの窓口を担う人物以外にも共有しておくことで、担当者が退職・異動した場合でも、システムに関する情報が失われずに済みます。保管場所を1つに決めておき、「システムのことで何か調べたければ、ここを見ればよい」という状態を作っておくだけでも、社内の情報管理の質は大きく向上します。開発会社とのやり取りの窓口が社長ひとりに集中している場合のリスクについては開発会社とのやり取り担当が社長ひとりという状態のリスクと備えでも詳しく扱っていますので、あわせて確認してください。

開発会社が廃業・倒産した場合のリスク

納品物をきちんと受け取っておくことの重要性が最も痛感されるのは、契約していた開発会社が廃業・倒産してしまった場合です。小規模な開発会社やフリーランスに近い体制の会社に発注していた場合、このリスクは決して低くありません。

開発会社が廃業してしまうと、それ以降、その会社に連絡を取ることはできなくなります。ソースコードやアカウント情報を受け取っていなければ、システムに何らかの不具合が起きても、原因を特定することすら困難になります。最悪の場合、システムを一から作り直すことになり、当初の開発費用をはるかに上回るコストが発生することもあります。

このリスクを踏まえると、契約している開発会社が安定して事業を続けているうちに、納品物をきちんと確認・保管しておくことの重要性がより明確になります。特に創業間もない開発会社や、担当者が1〜2名の小規模な体制で運営されている会社に発注する場合は、このリスクをより強く意識しておく必要があります。

「無料で作ってもらった」「知人に頼んだ」場合の特有の注意点

10人未満の会社では、正式な発注ではなく、知人のエンジニアや、友人が経営する開発会社に依頼して、比較的安価、あるいは好意でシステムを作ってもらうケースもあります。この場合、契約書自体が存在しない、あるいは非常に簡素な合意書だけで済ませているケースが多く見られます。

こうした関係性の中では、「相手に悪いから、細かいことを確認しづらい」という心理が働きやすいものです。しかし、知人や友人経由の発注であっても、このガイドで紹介した納品物の確認は同様に重要です。むしろ、正式な契約書がない分、後から「言った言わない」のトラブルに発展しやすいという側面もあります。

関係性を損なわない形で確認するには、「今後何かあったときのために、念のため確認させてください」という前置きをした上で、事務的な確認として進めることをお勧めします。個人的な関係と、システムの資産管理は別の話であるという認識を、双方が持っておくことが望ましい形です。

小規模発注ほど「口約束」で済ませがちな理由

なぜ10人未満の会社の小規模な発注ほど、納品物の確認が口約束のまま済まされてしまうのでしょうか。理由の一つは、発注金額が比較的小さいため、「これくらいの金額なら、そこまで厳密にしなくても」という心理が働きやすいことです。もう一つは、発注者自身がシステム開発の経験に乏しく、そもそも何を確認すべきかを知らないまま、開発会社の言葉をそのまま受け入れてしまうことです。

しかし、発注金額の大小と、そのシステムが事業に与える影響の大きさは、必ずしも比例しません。数十万円の予算で作られた小規模な業務システムでも、それが日々の業務の中核を担っていれば、失われたときの影響は決して小さくありません。むしろ、金額が小さい発注ほど、契約書や納品物の管理が疎かになりやすい分、意識的に確認する習慣をつけておく価値があります。

ソースコードの著作権をめぐる誤解

ソースコードの著作権について、発注者側によくある誤解を整理しておきます。「開発費用を全額支払ったのだから、当然ソースコードの著作権も自社のものになっているはずだ」と考える発注者は少なくありませんが、これは法律上、必ずしも正しくありません。

著作権法上、著作物(ソースコードも含まれます)の著作権は、原則として実際に制作した者に帰属します。システム開発の受託契約においては、開発費用を支払ったからといって、自動的に著作権まで発注者に移転するわけではなく、契約書に「著作権は発注者に譲渡する」という条項が明記されて初めて、発注者側に著作権が移転します。

契約書にこの条項がない場合、法律上は開発会社に著作権が残ったままになります。この場合、発注者は「そのシステムを利用する権利」は持っていても、ソースコードを改変したり、他の開発会社に渡して改修を依頼したりする行為が、著作権法上の問題になる可能性があります。実務上は黙認されることも多いものの、契約関係が悪化した場合には、この点が争点になることもあります。

10人未満の会社が発注する際、著作権譲渡の条項が契約書にあるかどうかは、契約前の段階で必ず確認しておきたいポイントです。すでに契約が完了し、納品を待っている段階であれば、この条項があるかどうかを今一度契約書で確認し、なければ開発会社に交渉することをお勧めします。多くの開発会社は、追加費用なしで著作権譲渡に応じることもありますが、独自のフレームワークやライブラリ部分については著作権を留保するケースもあるため、譲渡の範囲についても確認しておくと安心です。

クラウド型システムの場合の特有の注意点

近年、10人未満の会社が発注するシステムの多くは、自社サーバーに設置する形式ではなく、クラウド上で稼働する形式(SaaS型・PaaS型)で構築されるケースが増えています。この場合、従来型のオンプレミスのシステムとは異なる、特有の確認事項があります。

まず、システムが稼働しているクラウドインフラ(AWS、Google Cloud、Azureなど)の契約主体が、発注者名義になっているか、開発会社名義になっているかを確認してください。開発会社が自社の契約の中で発注者のシステムを稼働させている場合、開発会社との契約が終了すると、システムそのものが停止してしまうリスクがあります。

次に、利用しているデータベースやAPIサービスが、開発会社独自の契約に紐づいていないかも確認が必要です。汎用的なクラウドサービスであれば問題ありませんが、開発会社が独自に構築した基盤や、他社に提供していないカスタムのサービスに依存している場合、その開発会社以外では保守できない状態(いわゆるロックイン)に陥りやすくなります。

「無料修正期間」と納品確認の関係

多くの開発会社は、納品後一定期間(1ヶ月〜3ヶ月程度が目安とされることが多い)、軽微な不具合を無償で修正する対応を行っています。この無料修正期間は、契約不適合責任(旧・瑕疵担保責任)に基づくものであることが一般的で、民法上は請負契約の場合、原則として契約不適合を知った時から1年以内に通知する必要があるとされています。

この無料修正期間があるからといって、納品時の確認を疎かにしてよいわけではありません。無料修正期間の対象は、あくまで「不具合の修正」であり、「もらい忘れていた納品物を後から請求する」こととは性質が異なります。無料修正期間中であっても、納品物の不足に気づいたら、できるだけ早く開発会社に連絡し、記録を残しながら対応を依頼することをお勧めします。無償対応と有償対応の境界についてはリリース後の不具合、無償対応と有償対応の境界線で詳しく解説されていますので、あわせて参照してください。

納品後、実際に自分で動かしてみる

書類上の確認だけでなく、納品されたシステムを実際に自分(あるいは社内の担当者)の手で一通り操作してみることも、重要な確認プロセスです。画面上の見た目だけを確認して「動いているようだから大丈夫」と判断してしまうと、実際の業務フローに即した使い方をした際に、初めて不具合や使いにくさに気づくことがあります。

特に確認しておきたいのは、次のような操作です。

• 実際の業務で想定される一連の操作を、最初から最後まで一通り実施してみる
• データの登録・編集・削除といった基本操作が問題なく行えるか
• エラーが起きた際に、どんなメッセージが表示されるか(エラーメッセージが分かりやすいかも重要な観点です)
• 複数人で同時に利用した場合に問題が起きないか(該当する場合)

これらの確認を、検収を確定させる前に行っておくことで、後から「実際に使ってみたら困った」という事態を防げます。特に10人未満の会社では、システムを実際に日常的に使う従業員が、検収のプロセスに関わっていないケースも多いため、可能であれば実際に使う予定の従業員にも操作を体験してもらい、フィードバックを集めてから最終的な検収判断を下すことをお勧めします。

まとめ

「あとはよろしく」という一言で片付けられがちな納品のタイミングは、実は発注者にとって最も重要な確認機会です。ソースコード、設計書、アカウント情報、データ、契約書類、保守情報の6カテゴリを、検収が完了する前に一つずつ確認してください。すべてを完璧に揃えることが難しくても、少なくともソースコードとアカウント情報の2つだけは、優先的に確認・取得しておくことを強くお勧めします。

10人未満の会社にとって、これらの確認作業は決して大きな負担ではありません。納品時にこのガイドのチェックリストを一度通しで確認するだけで、将来「あの時ちゃんと確認しておけばよかった」と後悔するリスクを、大きく減らすことができます。

システム開発は、納品された瞬間がゴールではなく、そこから実際の運用が始まるスタート地点です。ゴールだと思い込んで確認を疎かにしてしまうと、運用が始まってから初めて、本来受け取っておくべきだった情報の不足に気づくことになります。「あとはよろしく」と言われたときこそ、落ち着いてこのガイドのチェックリストを見返し、必要なものが揃っているかを確認する時間を確保してください。それが、その後の運用を安定させるための、最も低コストな備えです。

10人未満という規模の会社にとって、システム開発の発注は決して頻繁に経験することではありません。だからこそ、一度の納品確認を丁寧に行っておくことの価値は大きく、次に別のシステムを発注する際にも、この確認の習慣がそのまま活きてきます。