納品は終わっている。請求書も払った。毎月の保守料も払い続けている。それでも「そのシステム、御社のものですか」と聞かれると、はっきり答えられない——そういう会社が、実際にかなりあります。
これは、開発会社が悪いという話ではありません。多くの場合、誰も悪意を持っていないのに、そうなります。ただ、その状態のまま何年も進むと、いざ何かを変えたいときに動けなくなる。この記事は、いま自分がどちら側にいるのかを確かめるためのものです。
「うちのシステム」と言えなくなるのは、いつか
気づくきっかけは、だいたい似ています。
担当者が変わって、連絡が返ってこなくなったとき。小さな修正を頼んだら、想像の3倍の見積もりが来たとき。別の会社に相談したら「ソースコードをいただけますか」と言われて、手元にないことに初めて気づいたとき。
このとき初めて、「作ってもらった」と「自分のものになっている」が別のことだったと分かります。動いている画面は目に見えるので、そこは疑いません。目に見えないところ——コード、ドメイン、サーバーのアカウント——が誰の名義になっているかは、契約のときに確認しないと、あとから調べる機会がありません。
なぜ、確認しないまま進んでしまうのか
ここが正直に言って難しいところです。
発注する側からすると、契約の段階で「ソースコードをください」「ドメインはうちの名義で」と言うのは、相手を疑っているようで言い出しにくい。これから一緒に作ろうという相手に、先に別れ話をするような気まずさがあります。
開発する側にも事情があります。ソースコードを渡す前提だと、他の案件で使っている社内の共通部品を組み込みにくくなる。サーバーを自社アカウントで一括管理したほうが、障害対応は圧倒的に速い。どちらも、悪意ではなく合理性から来ています。
つまり両者ともそれなりに理由があって、結果として誰も確認しないまま数年経つ。だから「聞かなかったほうが悪い」でも「渡さないほうが悪い」でもなく、単に確認の機会がなかっただけ、というケースがほとんどです。
確認すべきものは、5つです
いま手元にあるかどうかを、順番に見てください。全部そろっている必要はありません。何が欠けているかが分かれば十分です。
1. ソースコード本体。ZIPで受け取ったきりでも構いませんが、それが最新の稼働中のものかどうかは別問題です。GitHubなどで管理されているなら、自社アカウントがそのリポジトリを見られる状態かを確認してください。
2. ドメインの名義。`whois`で調べるか、更新料の請求書が誰に来ているかを見れば分かります。開発会社名義のまま連絡が取れなくなると、ドメインが失効した瞬間にサイトが消えます。ここが一番、取り返しがつかない部分です。
3. サーバー・クラウドのアカウント。AWSやGoogle Cloudの請求が開発会社経由で来ている場合、その中身を自社で直接見られないことが多いです。データベースの中身は自社の資産なので、少なくとも「取り出せる状態か」は確認しておきたいところです。
4. 外部サービスの契約者。決済、メール配信、地図、AIのAPI。それぞれ誰のアカウントで契約されているか。これらは月額が発生し続けるので、使っていないものが混ざっていることもあります。
5. 契約書に書かれた著作権の扱い。「著作権は乙に帰属する」と書いてあれば、コードの権利は開発会社側です。この場合でも交渉の余地はありますが、まず現状を知らないと交渉の仕方が決まりません。
欠けていたら、どうするか
いくつか欠けていても、慌てなくていいと思います。順番があります。
先に押さえるべきは、失うと戻らないものです。ドメインとデータ。この2つは、揉めているかどうかに関係なく、最優先で自社側に移すか、少なくとも複製を持っておく価値があります。ソースコードは、極端な話、なければ作り直せます。時間とお金はかかりますが、戻せます。ドメインとデータは戻りません。
そして、これは経験上そう思うのですが、交渉は「疑い」ではなく「引き継ぎの準備」として持ちかけたほうが、たいていうまくいきます。「御社を信用していないので渡してください」ではなく、「うちの担当が変わるので、社内で管理できる状態にしておきたい」。事実として後者であることがほとんどですし、開発会社側も応じやすくなります。
私たちも、渡せる状態にするまで時間がかかりました
偉そうに書いていますが、私たち自身、最初から綺麗にできていたわけではありません。
自分たちのプロダクトで、`index.html`の文字コード指定の位置がずれていて、本番だけ日本語が文字化けしたことがあります。手元では再現しないので、原因が分かるまでしばらくかかりました。こういうことは、書いた本人でも起こします。
それ以来、「自分が今日いなくなっても、他の人がこれを触れるか」を意識するようになりました。詰まりやすい箇所を文章で残しておく、というだけのことですが、これがないと、コードを渡しても実質的には渡したことにならない。ソースコードを受け取るときも、同じ観点で見てもらうといいと思います。ファイル一式より、「どこを見れば動かせるか」が1枚あるほうが、価値が高い場合があります。
最後に
このあたりを一通り自分で確認するのは、けっこう骨が折れます。契約書を読み直し、請求書を並べ、サーバーの管理画面を探す。本業の合間にやる作業としては重い部類です。
もし途中で行き詰まったら、システム立て直し相談で、いま手元にあるものから「何が足りていないか」を洗い出すところをお手伝いしています。前の開発会社との交渉を代行したり、間に入ったりはしません。そこに立ち入ると、どちらの味方かが曖昧になって、判断そのものが濁るからです。あくまで、御社が自分で判断するための材料を作るところまでです。
新しく作るほうの話はAI業務改善システム開発にまとめています。そちらでお受けする場合も、ソースコードとドメインは最初から御社名義でお渡しします。この記事に書いたことを、自分たちがやらないわけにはいかないので。