ソフトウェアエスクローは、日本語ではソースコード預託とも呼ばれ、もっともな不安に答えるために存在します。基幹システムを構築し運用してきたベンダーが事業をたたみ、こちらの手元には、依存しているのに保守できないものだけが残る、という不安です。エスクロー契約はソースコードを中立的な第三者に預けておき、実際にそうなったときにその第三者が利用者へ開示します。

不安そのものは正当です。ところがこの仕組みは誤解されやすく、その隔たりから、毎年費用だけがかかり、いざ必要になった日には役に立たない契約が生まれます。

署名の前に確かめておきたい、居心地の悪い問い: もし明日ソースコードが開示されたとして、社内の誰かがそれを実際に動かせるでしょうか。ビルド手順もなく、インフラ定義もなく、呼び出している外部サービスの認証情報もなく、データもないソースコードの預託は、事業継続計画ではありません。ただのフォルダです。一度も検証されていないエスクロー契約が、まさにそれを開示してしまう例は珍しくありません。

ソフトウェアエスクローが対象とするもの

利用者、ベンダー、エスクロー機関の三者で結ぶ契約です。ベンダーが資料を機関に預け、機関がそれを保管し、あらかじめ定めた開示条件によって、利用者がいつ資料を受け取れるかが決まります。

交渉する価値があるのは、この開示条件の部分です。倒産はもっとも分かりやすく、証明もしやすい条件です。しかし実務ではほかの条件のほうが効いてきます。ベンダーが製品の保守をやめた場合、サポート義務を果たさなくなった場合、あるいは自社の競合に買収された場合です。引き金となる条件の一覧が狭いと、資料がもっとも欲しい曖昧な状況でこそ、機関は開示を拒むことになります。

預託する中身も、ソースコードだけでは足りません。最低限、動くシステムを組み立てられるだけの具体的なビルド手順、依存関係の正確なバージョン、インフラの構成、外部サービスの一覧と認証情報の保管場所を示した文書、そして氏名の分かる技術担当者が必要です。これらがなければ、ソースコードはほとんど価値を持ちません。

そして預託物は更新され続けなければなりません。契約時に一度取っただけで、その後一度も差し替えられていない複製は、もう誰も動かしていないソフトウェアの正確な記録にすぎません。

多くのエスクローが開示時に機能しない理由

誰も中身を確かめていないからです。

標準的な契約書は、技術的な中身は問題ないという前提に立った法律文書です。エスクロー機関は検証サービスを用意しており、その水準は、媒体が読めるかどうかの確認から、預託物を実際にコンパイルしてまっさらな環境で起動してみるところまで幅があります。安い水準はほとんど何も証明しません。高い水準だけが、利用者が本当に知りたいことに答えてくれます。

きちんと検証したときによく出てくる結果は、次のようなものです。誰も文書化していないツールがないとビルドできない。ベンダーが消えれば一緒に消える社内向けパッケージリポジトリに依存している。一覧に載っていなかったサービスの認証情報を要求する。あるいは単純に、本番で動いているものより古いバージョンである。

エスクローに費用を払うのであれば、検証にも払うべきです。検証されていない契約は、リスクそのものではなく、リスクが消えたという感覚だけを移します。検証を加える差額は、最悪の瞬間にそれを知る代償よりはるかに小さいのです。

SaaSの問題

従来型のエスクローは、利用者自身がそのソフトウェアを動かすことを前提としています。ホスティング型のソフトウェアでは、この前提はたいてい成り立ちません。

インターネット越しに使っていたプラットフォームのソースコードを受け取っても、インフラ、デプロイの仕組み、運用の知識、そして自社のデータが依然として必要で、その大半は預託物に含まれていません。仮に一式がそろっていたとしても、立ち上げるには数週間かかり、そのシステムに依存している企業にその時間があることはまれです。

だからこそ、ホスティング型ソフトウェアで実際に効く保護は形が違います。データ抽出の権利はコードよりも重要です。文書化された形式で全データを取り出す契約上の権利を、約束のままにせず定期的に行使することです。継続提供の約束、つまり解約後も定められた期間はベンダーがサービスを動かし続けると合意しておくことは、コードだけでは得られない移行の時間を買います。実際に試したことのある検証済みのエクスポートは、一度も試していないどんな預託物よりも価値があります。

多くのホスティング型ソフトウェアにとって、エスクロー契約は習慣で買われた誤った道具であり、その費用は、読めることを自分で確かめた定期エクスポートに使うほうが報われます。

費用と、向いている相手

エスクローは毎年かかる費用です。預託物の規模、受益者の数、検証の水準に応じて、年に数百ポンドから数千ポンド程度が一般的です。検証は別途請求され、意味のある支出はそちら側にあります。

本当に向いているのは、止まると事業に実害が出るシステム、破綻が現実的にあり得る程度に小規模なベンダー、自社で動かすことが現実的なオンプレミス型あるいは自社運用できるソフトウェア、そして規制当局や顧客との契約がそれを求めている場合です。

あまり向いていないのは、どのみちコードを自社で動かさないホスティング型のソフトウェア、代替がすぐ見つかる汎用的なシステム、そして年額が契約金額のうち無視できない割合を占めてしまう小規模ベンダーの場合です。

まず検討すべき代替案は、単純にコードを自社で保有することです。受注生産の開発を自社が発注したのであれば、知的財産権の譲渡と、各リリース時点のリポジトリの複製を契約条件として交渉してください。それだけで機関そのものが不要になります。そして技術デューデリジェンスの手引きで挙げた観点は、そうした引き渡しを実際に使えるものにする観点とまったく同じです。

それでも契約するなら役立てる方法

標準の一覧をそのまま受け入れず、開示の引き金を交渉してください。倒産だけでなく、ベンダーが製品を事実上放置した場合も含めます。

預託物の中身は、誰も読まない別紙ではなく契約本文に明記してください。ビルド手順、インフラ定義、依存関係の一覧、外部サービスの棚卸し、そして氏名の分かる担当者です。

決めた間隔ごと、あるいは主要なリリースごとに更新を義務づけ、実際に更新されたことの証跡もあわせて求めてください。

機関が資料を自らビルドして起動する水準の検証に費用を払い、その報告書を読んでください。問題を見つけた検証は、役目を果たした検証です。

そして自社側の備えも試してください。明日その資料が届いたら、社内では誰が受け取り、その人はまず何をするでしょうか。社内に責任者のいないエスクロー契約は、計画ではなく請求書です。災害復旧の手引きで述べた考え方が、そのまま当てはまります。

Mecanikは自らエスクローに預託した経験も、ソフトウェア開発の仕事の一環として、顧客が本当にエスクローを必要としているかどうかの判断を手伝った経験も持っています。正直な答えは多くの場合、同じ費用でも、検証済みのバックアップと明確な権利の整理に使うほうがより多くの保護を買える、というものです。

よくある質問

ソフトウェアエスクローとは何ですか。 利用者、ソフトウェアベンダー、エスクロー機関の三者で結ぶ契約です。ベンダーがソースコードと関連資料を機関に預け、あらかじめ定めた条件が満たされたときに機関が利用者へ開示します。もっとも多い条件は、ベンダーの倒産や、製品の保守終了です。

エスクロー契約が開示時に機能しないのはなぜですか。 預託物が一度も検証されていないからです。よくある結果は、文書化されていないツールがないとビルドできない資料、ベンダーとともに消える社内向けパッケージリポジトリへの依存、外部サービスの認証情報の欠落、本番より古いバージョンです。預託物を実際にコンパイルして起動する検証だけが、本当の問いに答えます。

ソフトウェアエスクローはSaaSでも有効ですか。 ほとんど有効ではありません。ホスティング型プラットフォームのソースコードを受け取っても、インフラ、デプロイの仕組み、運用の知識、自社のデータが依然として必要で、立ち上げには数週間かかります。データ抽出の権利、解約後の契約上の継続提供期間、定期的に試したエクスポートのほうが、ホスティング型のサービスをはるかによく守ります。

ソフトウェアエスクローの費用はどれくらいですか。 預託物の規模、受益者の数、検証の水準に応じて、年に数百ポンドから数千ポンドが一般的で、検証は別途請求されます。意味のある支出は検証にあり、それを欠いた契約は、リスクではなく、リスクが消えたという感覚だけを移します。

エスクローの代わりになる方法はありますか。 自社が発注した受注生産の開発であれば、知的財産権の譲渡と各リリース時点のリポジトリの複製を交渉するだけで、機関はまったく不要になります。ホスティング型のソフトウェアなら、実際に読めることを確かめた文書化済みのエクスポートのほうが、試していないどんな預託物よりも価値があるのが普通です。