その開発会社が続けられなくなったら ── 引き継げる状態で作っておく5つの条件

開発会社を選ぶとき、その会社が3年後も続いている前提で話が進みます。当然ですが、保証はありません。私たちも含めて。

この記事は、自社に不利なことを書きます。「うちが続けられなくなったら、どうしますか」。本来は発注側から聞く質問ですが、聞きにくいと思うので、こちらから開けておきます。

会社がなくなる以外にも、担当者が辞める、方針が変わって受託をやめる、値上げで折り合わない、単純に相性が悪くなる。理由はいくらでもあります。どの場合も、問題は同じです。作ったものを、別の誰かが引き取れる状態かどうか。

この状態を作るのに、特別な費用はほとんどかかりません。作り方と、契約の名義と、渡してもらう資料。決めるのは最初の数回の打ち合わせの中です。逆に、決めないまま3年走ってから整えようとすると、まとまった費用と時間が要ります。

引き継げるかどうかは、契約書より作り方で決まる

先に一点だけ。著作権が自社に譲渡されていても、コードがどこにあるか分からなければ引き取れません。権利の条項の読み方はシステム開発の契約書で、発注側が読むべき5つの場所の3つ目に書いたので、この記事では技術と運用の側だけを見ます。

条件は5つです。

どれも、契約したあとに頼むと角が立ちます。提案を受けている段階、つまり相手がまだ受注していない段階で聞くと、たいていすんなり通ります。1つずつ、実際の聞き方と一緒に書きます。

聞くときの前置きも、決めておくと楽です。「疑っているわけではなくて、社内で必ず聞かれる項目なので」。これで十分通ります。実際、少し大きい会社の稟議では、この種の確認が必須になっていることが珍しくありません。

嫌な顔をされたら、それ自体が情報です。5つのうちどれかで渋られたとき、渋った理由を聞いてください。「そこまでやると工数が増えます」なら、いくら増えるのかという話にできます。理由が出てこない場合は、そもそも整理されていない可能性があります。

条件1 ── ソースコードが、発注側の手元にあるか

まず、作られたプログラムそのものが、どこに置かれるかです。

聞き方。 「コードは、どのアカウントのリポジトリに置きますか。うちのアカウントを作って、そこに置いてもらえますか。」

理想は、自社で作ったGitHubなどのアカウントに置いてもらい、開発会社をそこに招く形です。これなら、関係が終わっても置き場所は自社に残ります。逆に、開発会社のアカウントの中にだけある状態だと、連絡が取れなくなった時点で終わりです。

それが難しい場合でも、最低限、読み取りの権限はもらってください。そのうえで、年に一度でいいので自社側にも控えを落としておく。

断られたときは、理由を聞きます。「社内で使い回している共通部品が混ざっているので、全部は渡せない」は、実務としてありえる答えです。その場合、自社のためだけに書いた部分と、使い回している部分を分けてもらえるかを聞きます。ここで答えに詰まるようなら、そもそも境界を管理していない可能性があります。

納品物としてZIPを一度もらって終わり、という形は勧めません。リリース後も何度も直すので、最後の状態がどれなのか、そのうち分からなくなります。

開発が始まったあとの確認方法もひとつ。自社のアカウントから、変更の記録が更新されているかを月に一度だけ見てください。中身が読める必要はありません。日付が止まっていないか、それだけです。止まっていたら、どこか別の場所で作業しているということになります。

なお、ここでいうコードには、画面のデザインデータや、業務で使う帳票のひな形も含めて考えてください。プログラムだけ受け取っても、請求書のレイアウトが開発会社のパソコンの中にしかない、という状態はよくあります。

条件2 ── 動いている場所のアカウントを、自社が持っているか

次が、動いている場所です。ここを落とすと、コードが手元にあっても止まります。

確認するのは4つ。ドメイン、サーバーやクラウドの契約、データベース、外部サービスの利用契約。それぞれ、誰の名義で、支払いは誰のカードかを聞きます。

聞き方。 「ドメインとクラウドは、うちの名義で契約できますか。支払いもうち側にできますか。」

開発会社の名義・開発会社のカードで契約されていると、乗り換えのときに移管の手続きが要ります。相手が協力的なら数日で終わります。ただ、協力が得られない状況こそ、この記事が想定している状況です。

移管そのものは、多くのサービスで手続きが用意されています。ただ、どの手続きにも相手の操作が1回は必要です。相手が応じない、連絡がつかない、担当者がもういない。このどれかが起きると、そこで止まります。だから、最初から自社名義にしておくのが確実です。

いちばん怖いのはドメインです。メールも同じドメインに載っていることが多いので、止まると業務全体に波及します。ここだけは、何があっても自社名義にしておいてください。

クラウドの管理アカウントは、自社で作って、開発会社には作業用の権限を渡す形が理想です。最初に少し手間がかかりますが、一度やれば済みます。

外部サービスの契約も忘れやすいところです。メール配信、地図、決済、SMS、ファイル保管。どれも月額がかかっていて、どれも開発会社のアカウントで取られていることがあります。契約が切れると、その機能だけが静かに止まります。動かなくなってから気づく種類の事故です。

請求書に外部サービスの利用料がいくら乗っているかも、同じタイミングで見ておきます。月額に何が含まれているかは、運用・保守の中身を項目ごとにで分解しています。

名義を自社にすると、請求も自社に来ます。手間は増えます。ただ、何にいくらかかっているかが毎月見えるようになるので、やる価値はあります。開発会社にまとめて払う形を続けるなら、せめて内訳を年に一度もらってください。

条件3 ── 使っている技術を、他の人も読めるか

ここが、いちばん見えにくいところです。

聞き方。 「これと同じ構成を扱える会社は、他にもありますか。求人を出したら、触れる人は集まりますか。」

答えが「うちの独自フレームワークです」「弊社製のCMSです」だった場合、引き継ぎの相手はかなり限られます。独自のものが悪いわけではありません。速く作れることも実際にあります。ただ、その会社から離れられなくなるのは事実です。

もう一段踏み込むなら、こう聞きます。「このコードを他社に見せたとき、何日くらいで把握してもらえそうですか。」即答できる会社は、他社が入ることを想定して書いています。

広く使われている言語やフレームワークで、一般的な構成になっていれば、引き取れる会社の数は増えます。名前を聞いたら、その場で検索してください。求人サイトにその名前で何件出ているかを見るだけでも、だいたい分かります。

ノーコードやSaaSの上に作る場合も、観点は同じです。その製品が終了したら、あるいは料金が倍になったら、どこへ移るのか。移せる形でデータが出るのか。借りる判断そのものは悪くありません。出口を先に確認しておく、という話です。

独自の仕組みを使うかどうかを金額で考えるなら、こう置き換えられます。将来ほかに移るとき、作り直しになるのか、部分的な移植で済むのか。作り直しになるなら、そのときの費用は今回の開発費と同じくらいかかると見ておくのが安全です。その金額を、独自の仕組みで得られる速さや安さと比べてください。比べたうえで独自を選ぶなら、それは判断であって、事故ではありません。

ついでに書くと、古すぎる技術も同じ問題を起こします。名前は有名でも、今から触れる人を探すのが難しい組み合わせはあります。新しいか古いかではなく、いま求人が出ているかで見るのが実際的です。

条件4 ── ドキュメントが、最低限あるか

分厚い設計書は要りません。更新されないので、むしろ害になります。

要るのは、次の担当者が最初の1日で困らないための紙です。4種類あれば足ります。

構成の見取り図。 どのサービスの上で動いていて、何と何がつながっているか。A4で1枚の図で足ります。

アカウントの一覧。 どこに何のアカウントがあり、誰が管理者か。パスワードそのものは書かず、保管場所だけを書きます。

直して公開するまでの手順。 変更をどうやって本番に反映するか。画面の名前やコマンドまで書いてあると、次の人がその日から動けます。

決めた理由のメモ。 なぜこの作りにしたのか。これが一番あとで効きます。理由が分からないと、次の人は全部作り直したくなります。

聞き方。 「引き継ぎ用に、この4つを残してもらえますか。リリースのときに一緒にください。」

「必要になったら書きます」は、実質「書きません」と同じです。必要になるのは、たいてい書ける人がいなくなったあとだからです。

分量の目安を書いておきます。4つ合わせてA4で5枚から10枚。これ以上になると、更新されずに古くなります。古い手順書は、無いよりたちが悪い。書いてあるとおりにやって動かないと、次の人はそこで止まります。

置き場所も決めてください。開発会社の共有フォルダの中だけにある資料は、条件1のコードと同じ問題を抱えます。自社のクラウドストレージに、システム名のフォルダを1つ作って、そこに集めるのが簡単です。

資料が更新されているかの確認は、年に一度で足ります。リリースから1年経ったときに、構成の図が実際と合っているかを見る。ずれていたら直してもらう。月額の中の稼働時間で収まる程度の作業です。

条件5 ── データを、自分で取り出せるか

最後がデータです。実はここが一番重く、一番軽視されます。

システムは作り直せます。3年分の受注履歴や顧客の情報は作り直せません。

聞き方。 「管理画面から、全データをCSVで出せますか。それは誰が実行できますか。」

開発会社に依頼しないと出せない作りだと、関係が切れた時点でデータが取り出せません。管理者が自分でボタンを押せば出る、という画面が1つあるだけで、状況がまったく違います。この画面を作るのに必要な時間は、たいてい数時間です。最初の見積もりに入れてもらってください。

もう一段確認するなら、出したファイルを実際に開きます。項目名が英語の略号だけで、何のデータか分からないことがあります。IDの数字だけが並んでいて、それが何を指すのかの対応表がない、という形も。出せることと、使える形で出ることは別です。取り出したデータを次のシステムへ入れるときに、どこで時間がかかるかはデータ移行で実際に時間がかかるところに書きました。

添付ファイルや画像も忘れずに。表のデータは出せても、見積書のPDFや現場写真が取り出せないと、半分しか移せません。

いちばん確実なのは、定期的なバックアップを自社側にも落としておくことです。月に一度、CSVを1つのフォルダに保存する。それだけで、最悪の事態の被害はかなり小さくなります。

ただし、取り出したデータに個人情報が含まれる場合は、置き場所に注意が要ります。担当者のパソコンのデスクトップに置きっぱなし、という形が一番危ない。社内で決めた保管場所に入れて、誰が見られるかを決めてください。ここは持ち出しの話なので、普段の権限設定とは別に考える必要があります。

この5つを全部そろえるのは、そんなに大変ではありません。ただ、5つ目まで来て気づくと思いますが、どれも「作る前に言っておけば無料、あとから頼むと有料」という性質を持っています。だから契約前に聞いてください、という話になります。

ニカゲツの場合

自分のところの話を書きます。事実として確認できることだけにします。

使っている技術は、Next.jsやCloudflareといった、広く使われているものです。独自のフレームワークや自社製のCMSの上には作りません。他社が引き取る前提で選んでいます。求人でもよく見る名前なので、触れる人がまったく見つからない、ということは起きにくいはずです。

ソースコードの置き場所、ドメインやクラウドの名義、データの取り出し方については、契約のときに確認していただけます。どの形にできるかは案件によって変わるので、ここで一律のお約束は書きません。ただ、聞かれて困る質問ではありません。

ひとつ補足します。こうした確認は、うちに対してだけでなく、比較している他社にも同じように聞いてください。同じ質問を3社にすると、答え方の差が出ます。すぐに答えられる会社、持ち帰る会社、質問の意図を聞き返してくる会社。どれが悪いということではありませんが、少なくとも考えたことがあるかどうかは分かります。

正直に言うと、私たちは小さな会社です。相談した相手がそのまま設計して開発して運用する体制なので、速く進む代わりに、その人が動けなくなったときの影響は大きい。分業している大手のほうが、その点では強い。ここは、選ぶときに天秤にかけていただく部分です。

体制の違いと、それぞれが得意な案件の規模は開発会社の選び方に整理しました。比べた結果、うちが合わないという結論でも構いません。判断の材料が揃っていることのほうが大事だと思っています。

進め方と、リリースまでに何をお渡しするかは進め方のページに出しています。この5つを確認したい場合は、初回の60分でまとめて聞いてください。断られる質問ではないはずです。