Webシステムの受託開発を頼むとき、見積もりと一緒に決めておきたい納品後のこと

他社が作ったシステムの引き継ぎについて相談を受けていると、話の途中で「そもそも最初の契約で何を決めていたのか」に行き着くことがよくあります。手元にあるのは見積書と注文書だけ。ソースコードは受け取っていない。サーバーは開発会社の名義で借りていて、管理画面に入れるのも開発会社だけ。発注した当時の担当の方は、どれも「頼めばやってもらえるもの」だと思っていた、という話です。

開発会社が不誠実だったとは限りません。決めていなかったことは、誰の仕事でもないまま残ります。それが表に出てくるのは、たいてい何年もあと、開発会社と連絡が取れなくなったときや、保守の会社を替えたいと思ったときです。そうなってからの進め方は、開発会社と連絡が取れないシステムと保守移管の進め方の記事に書きました。

この記事はその手前、これから開発を発注する段階の話です。金額と納期に目が行くのは当然ですが、そこに少しだけ、納品のあとのことを足しておいてほしいと考えています。

見積もりの金額は、同じものを比べているとは限らない

2社から見積もりを取ったら、片方が3割安かった。発注の現場ではよくある場面です。ところが中身を並べてみると、高いほうには公開後しばらくの不具合対応とサーバーの構築手順書が入っていて、安いほうには入っていない、ということがあります。

金額を比べる前に、少なくとも次の点がそろっているかを見てください。契約の形が請負か準委任か。納品後に無償で直してもらえる期間と範囲。保守を含むかどうか。納品物に何が入るか。サーバーやドメインを誰の名義で契約するか。どれも、見積書の明細には書かれないことが多い項目です。

IPA（情報処理推進機構）の「情報システム・モデル取引・契約書」は、ユーザーがベンダーに出す提案依頼書（RFP）に、契約書に盛り込むべき重要事項の条件や要求をあらかじめ書いておくよう求めています。例として挙がっているのは、契約類型（準委任か請負か）、再委託、損害賠償責任の範囲・限度額・期間、知的財産権の帰属、第三者ソフトウェアの利用、検収・支払い条件などです（IPA 情報システム・モデル取引・契約書（第二版））。

もともとは企業の基幹システムのような大きな開発を想定した文書なので、小さな発注で正式なRFPまで作る必要はないと思います。それでも「先に条件を書いて、同じ条件で見積もってもらう」という考え方は、規模に関係なくそのまま使えます。

請負と準委任で、約束している中身が違う

契約書の頭に「請負」や「準委任」と書かれていても、その違いを意識して発注している方は多くないかもしれません。

IPAのモデル契約の解説では、請負ではベンダーが仕事を完成させる義務を負い、引き渡した成果物が契約の内容に合っていなければ契約不適合責任を負う、と整理されています。準委任では、善良な管理者の注意をもって作業する義務（善管注意義務）は負うものの、仕事の完成までは約束しません。そのうえで、業務の要件がまだ固まっていないシステム化計画や要件定義の段階は請負になじみにくく、準委任が適切だとしています（IPA 情報システム・モデル取引・契約書（第二版））。

発注する側から見ると、「何を作るかを決める作業」と「決まったものを作る作業」は、別の約束だということです。要件がふわっとしたまま全体を一括の請負で見積もると、何をもって完成とするかで後からもめやすくなります。逆に全部を準委任にすると、どこまで進めば終わりなのかが見えにくくなります。

私たちは、要件が固まっていないなら、まず整理の段階を区切り、作るものが見えてから残りの範囲と金額を決めるほうが、発注する側にとっても判断しやすいと考えています。どの形にするにしても、「この部分はどちらの契約なのか」は見積もりの段階で聞いておいてください。

「納品後○か月は無償で直します」と保守は別のもの

見積書に「納品後3か月の瑕疵対応を含む」といった一文が入っていることがあります。2020年4月に施行された改正民法のもとでは、契約不適合責任と呼ぶのが正確です。

民法の定めでは、請負の契約不適合責任は、注文者が不適合を知ったときから1年以内にその旨を通知すれば権利を行使できます。実際の契約では期間を別に決めることが多く、IPAのモデル契約でも、起算点を検収完了時にしたうえで「○ヶ月／○年以内」と、期間の長さは当事者が決める形にしています（IPA 情報システム・モデル取引・契約書（第二版））。

ここで知っておいてほしいのは、この期間に直してもらえるのは「契約の内容に合っていないところ」だけだということです。モデル契約の解説には、検収のあとにOSがバージョンアップしたことで起きた不具合は、契約の前提になっていたOSと違う以上、契約不適合ではないとされることもある、という例が書かれています。そのうえで、契約不適合責任の期間自体は短くして、その後は契約不適合かどうかを問わず対応してもらう保守契約を結ぶほうが、ユーザーにとってかえって経済的な場面もあると述べています（同）。

業務システムで困りごとが起きやすいのは、むしろ保証の期間が終わったあとです。サーバーのOSやPHPのサポートが切れる。連携している外部サービスの仕様が変わる。SSL証明書の自動更新がいつの間にか止まっている。どれも作ったときのバグではないので、無償で直す範囲には入りません（PHPのサポート切れについてはこちらの記事に書きました）。

だから発注の時点で、「保証の期間が終わったあと、誰がどの費用で面倒を見るのか」まで聞いておくと安心です。保守を同じ会社に頼むかどうかは、そのとき決めればかまいません。避けたいのは、誰も決めていない状態のまま公開日を迎えることです。

納品物の一覧は、引き継ぐ人の目で作る

ソースコードを納品物に含めるかどうかは、以前よりよく知られるようになりました。IPAのモデル契約の解説も、開発会社が倒産したときに備えてソースコードや付随する資料の交付を受けるには、納入物にソースコードを明記するか、エスクロウ（第三者に預けておく仕組み）を使う方法があると書いています（IPA 情報システム・モデル取引・契約書（第二版））。著作権の帰属の考え方は保守移管の記事で触れたので、ここでは繰り返しません。

引き継ぐ側として付け加えたいのは、ソースコードだけでは足りない、ということです。他社のシステムを引き継ぐとき、時間がかかるのはコードを読むことより、「これをどうやって動かしているのか」を突き止めることのほうです。どのサーバーに、どんな手順で反映しているのか。設定値やパスワードはどこにあるのか。夜中に何が動いているのか。

モデル契約の解説には、あとから追完（修正）を求められても、当時の開発環境が再現できなければ事実上追完できないこともありうる、という一文もあります（同）。作った会社自身でさえそうなのですから、別の会社が引き継ぐならなおさらです。

納品物の一覧に入れておきたいものを、引き継ぐときに何に使うかと並べてみました。

納品物に入れておきたいもの	引き継ぐときに何に使うか
本番と同じ版のソースコード（変更の履歴ごと受け取れればなおよい）	直す対象そのもの。本番と違う版だと、どこが違うかを調べるところから始まる
動かすための手順（サーバーの構成、反映のしかた、言語やミドルウェアのバージョン）	検証用の環境を作る、本番に修正を出す
設定値の一覧と、パスワードや鍵の保管場所	中身は別の安全な方法で受け取る。一覧がないと、どこに何があるかを探すところから始まる
使っている外部サービスとライブラリの一覧	契約の更新、サポート切れや脆弱性の情報を追う
データベースの構成	データの移行、不具合の調査
定期的に動く処理の一覧	月末や年度末にしか動かない処理を見落とさない
バックアップの取り方と戻し方	障害のときに本当に戻せるかを確かめる

全部を立派な設計書にしてもらう必要はありません。小さなシステムなら、数ページのテキストでも十分役に立ちます。一覧にしておく意味は、何が「ない」のかが発注の時点で見えることにあります。ないとわかっていれば、追加で頼むか、なしで進めるかを選べます。

サーバーとドメインは、自社の名義で契約する

引き継ぎで手間取るのは、技術の話より名義の話であることが少なくありません。サーバーやクラウド、ドメイン、SSL証明書、メール配信などの外部サービスが開発会社の名義で契約されていると、開発会社の協力なしには移せません。連絡が取れなければ、ドメインの更新期限が近づくのを見ているしかない、ということも起こります。

発注のときに、これらをどちらの名義で契約するかを決めておいてください。私たちがおすすめしているのは、契約と支払いは自社の名義にして、開発会社には作業用のアカウントを発行する形です。開発会社がまとめて用意したほうが楽な場面もあるので、そうする場合は、契約が終わったときにどうやって自社に移すのかを先に書いておきます。自社の名義にしておけば、更新の案内も自社に届きます。

顧客情報が入るシステムなら、開発中のテストに本番のデータを使うのか、使うならどう扱うのかも、発注のときに決めておきたい項目です。保守を頼むときの個人情報保護法上の考え方は、保守移管の記事で触れています。

見積もり依頼に書き足す文面

見積もりを頼むメールに次のような文面を足すだけでも、返ってくる見積もりの比べやすさが変わります。自社に合わせて直して使ってください。

お見積もりにあたり、次の点もあわせてお知らせください。
・契約の形（請負・準委任）と、それぞれの範囲
・納品後に無償で対応いただける期間と、その範囲
・その期間が終わったあとの保守の内容と費用の目安（別契約で構いません）
・納品物の一覧（ソースコード、動かすための手順、設定値の一覧、
  外部サービスとライブラリの一覧、定期処理の一覧を含めたいと考えています）
・プログラムの著作権の扱い
・サーバー、ドメイン、外部サービスの契約名義（弊社名義を希望します）
・他社への再委託の予定の有無

返ってきた答えが「含みません」「対応していません」でも、それ自体は悪いことではありません。安い見積もりがなぜ安いのかがわかれば、それで判断できます。困るのは、聞かなかったせいで、何年もあとに初めて知ることです。

契約書の条文の書き方や権利の扱いで迷ったときは、法律の専門家に相談してください。この記事に書いたのは、引き継ぐ側から見て「最初に決めておいてもらえたら助かった」と感じることです。

開発を頼む先を探している方へ

ディレクターズ・リベロは、Webサービスや業務システムの受託開発と、他社が作ったシステムの引き継ぎ・保守の両方を行っています。受託開発では、要件定義書がない段階から「どうしたいか」を一緒に整理し、契約の形（一括・月額・レベニューシェア）は提案とお見積もりの段階ですり合わせます。公開後はサーバー運用保守として、アップデートや改修まで続けてお付き合いします。

新しく作る話ならWeb受託開発、すでに動いているシステムのことならシステム引き継ぎ・保守のページをご覧ください。ほかの会社の見積もりと並べて検討している段階でもかまいません。ご相談は info@directorz-libero.co.jp までどうぞ。