システム開発の納品で受け取るもの ｜ 資料・ソースコード・管理権限の確認

システム開発の納品で受け取るものは、一律には決まっていません。案件ごとの契約と、成果物の一覧で決まります。納品のときは、届いたものを一覧と照らし、「受領済・不足・対象外・別途手続き・対象確認中」の5つに分けて記録します。資料は版と保管場所まで確かめます。ソースコードは、受け取り・使える範囲・権利を分けて確かめます。アカウントは、パスワードを集めるのではなく、管理者と自社に必要な権限を確かめます。

この記事は、新しく作ったシステムの納品（検収の前後）を迎える発注者向けです。業務で使えるかを確かめる受入テストや、稼働中のシステムの保守を後任へ引き継ぐ手順は、関連記事で案内します。

納品の対象を、契約と成果物の一覧で照らし合わせる

最初に、契約書、見積書、成果物の一覧を手元にそろえます。一覧の名前は「納入物明細」「成果物一覧」など、案件によって違います。何が納品の対象かは、これらの書類で決まります。

参考になるのが、IPA（情報処理推進機構）の情報システム・モデル取引・契約書（第二版）です。このモデルでは、作業の内容、期間、役割分担、納入物の明細、検査などを、個別の契約で決める取引条件として整理しています（IPAの講演資料でも同じ整理が紹介されています）。ただし、これは参考のひな形です。自社の契約に自動で当てはまるものではありません。

Ouverでは、成果物・納品条件・保守範囲を案件ごとに確認しています（システム開発の流れ）。

一覧の書き方だけでは対象か分からないものは、すぐに「対象外」と決めず、「対象確認中」として残します。たとえば架空の例で、一覧に「操作説明書」とだけあり、管理者向けか利用者向けかが分からなければ、両方を「対象確認中」にして開発会社に聞きます。対象外かどうかは、契約と照らしてから決めます。

一覧があいまいなときは、納品の前に開発会社と一覧を見直して合意しておくと、後の確認が楽になります。設計や開発に入る前に、目的・業務・範囲をそろえておく準備は、要件定義の記事で扱っています。

コラム要件定義で発注者が準備すること｜目的・業務・範囲をそろえるメモ

受け取った状況を、5つの区分で記録する

次の5区分は、確認を進めやすくするための整理例で、契約上の定義ではありません。届いたものを一覧の項目ごとに記録します。契約に含まれるかで迷うものは「対象確認中」にしておき、推測で埋めません。届いていても中身を確かめ終わるまでは「受領済」にせず、メモに「中身確認待ち」と担当・確認予定日を残します。

記録の例を1件だけ示します。内容は架空で、前の例で管理者向けの説明書が対象だと確かめた後の記録です。

このほか、確認した日と確認した人も書き添えます。この表には、パスワードなどの秘密の値は書きません。「受領済」は検収の完了を意味しません。記録は、契約の検収条件に照らして判断するための材料です。

資料は、読めるか・版が合っているか・どこで管理するかを確かめる

資料は、契約で決めたものが対象です。設計書、操作説明書、運用の手順書などが含まれることがありますが、どの案件にも必ず含まれるわけではありません。届いた資料は、次の3点で確かめます。

読めるか

ファイルを開けるか。特別なソフトが要らないか。社内の担当者が読んで内容が分かるか。

版が合っているか

本番で使うシステムの版と、資料の版や日付が合っているか。開発途中の古い版が混ざっていないか。

どこで管理するか

社内で参照する正しい版（正本）の保管場所を決めたか。管理する人は誰か。資料を直したとき、古い版をどう扱うか。

開けない資料や、版が合わない資料は「不足」として記録し、開発会社に確認します。版の見分け方が分からないときは、表紙や更新の記録に版と日付を書いてもらうよう頼むと、後から確かめやすくなります。

資料が個人のパソコンやメールの中だけにあると、担当者が替わったときに探せなくなります。会社で決めた共有の場所に置き、その場所を記録に書いておきます。

ソースコードは、受け取り・使える範囲・権利を分けて確かめる

ソースコードは、次の3つを別々の項目として確かめます。

1. 受け取り：ソースコードを受け取るか。受け取るなら、どの範囲を、どの形で受け取るか。
2. 使える範囲：自社での改修、他社への改修の依頼、別の用途での再利用などを、どこまでしてよいか。
3. 権利：著作権などの権利を、どう扱うか。

この3つは同じではありません。ソースコードを受け取っても、使える範囲や権利が自動で決まるわけではありません。IPAのモデル契約でも、納入物の所有権と著作権は別の条項で整理されており、著作権の扱いには複数の案が示されています。第三者が作ったソフトウェアの扱いも、別の項目になっています。自社の契約がどうなっているかは、自社の契約書で確かめます。

外部の部品やサービスを使っている場合は、それぞれに別の利用条件があることがあります。何を使っているかを一覧にしてもらうと、確認しやすくなります。受け取ったソースコードが本番と同じ版かどうかも、開発会社に確かめておきます。

分からない点は、開発会社に書面で質問します。権利や使える範囲について法的な判断が必要なときは、専門家に相談してください。

管理者と、自社に必要な権限を確かめる

サーバー、ドメイン、システムの管理画面、外部サービスなどは、誰が管理するかが契約や提供の形によって違います。自社が管理者になる場合もあれば、保守のために開発会社が管理を続ける場合もあります。まず、契約でどうなっているかを確かめます。

避けたいのは、パスワードを表計算の一覧やメール、チャットにまとめて受け取ることです。代わりに、次の点を確かめて記録します。

• 管理者は誰か（自社か、開発会社か）
• 自社の担当者が、自分のアカウントで必要な操作をできるか
• サーバーやドメインなどの契約の名義と、支払っている人は誰か
• ログインできなくなったときの復旧の手続き

外部サービスの権限や名義を自社へ移せるかどうか、どんな手続きが要るかは、サービスごとの利用規約や仕組みによって違います。移せない場合もあります。契約に含まれ手続きが必要なものは「別途手続き」、契約の対象か分からないものは「対象確認中」として残します。契約の対象でも利用規約上移せない場合は、制約と代わりの方法を記録し、関係者で扱いを決めます。開発会社に権限が残る場合は、その範囲と理由を記録します。担当者の異動や退職に備えて、管理者を1人だけにしてよいかも、開発会社と相談しておきます。パスワードそのものはこの記録に書かず、社内で決めた管理の仕組みに保管します。