【ITニュース解説】The Succession Layer — Or, "Our Partner Will Handle It" Is the Most Expensive Sentence in Procurement

「パートナーが対応します」という言葉は、しばしば問題解決を約束する安心感を与えるが、実はビジネスにおいて最も高価な一文になる可能性がある。これは、システムが依存する外部の要素について、責任の所在やその後の継続性が曖昧になる「後継レイヤー」の問題を指す。この問題は、ITシステムを運用する上で、所有権と責任の継承という二つの異なる概念が混同されることから生じる。

ニュース記事では、この後継レイヤーの問題を象徴する三つの出来事が紹介されている。一つ目は、Roku社が開発リポジトリをGitHubからGitLabへ移行した事例だ。Rokuは何も削除したわけではなく、単に場所を移しただけだ。しかし、この移行によって、Rokuのリポジトリを指すすべてのパイプライン、Webhook、パッケージ参照、CIバッジ、ドキュメントリンクは、突然、誰がいつまで維持するのか不明なリダイレクトに依存することになった。システムはエラーを吐かず稼働を続けるが、その背後で重要な依存関係の「大家」が変わってしまった状況だ。

二つ目は、「HTTP2Shell」という、間接的な脆弱性の事例だ。これは自社のコードに新たな脆弱性が見つかったわけではない。自社が利用しているライブラリが、さらに別のライブラリに依存しており、その「中間リンク」のメンテナンスが2021年に停止していたというケースだ。結果として、他者が放棄した責任に対する修正期限を、自社が突然背負うことになった。

三つ目は、GoogleのNestサーモスタットの事例だ。ハードウェアとしてのサーモスタットは金属と電波の塊であり、それ自体は動作し続ける。しかし、それを「スマートサーモスタット」として機能させていた基盤となるクラウドサービスが終了したことで、製品は購入時の価値を失い、「ただのサーモスタット」に戻ってしまった。誰も盗んだわけでも、セキュリティ侵害があったわけでもない。単に、サービスを継続するインセンティブを持つ後継者がいなかったのだ。

これらの事例が示すように、あらゆるベンダーとの関係には「カストディ（保管）」と「サクセッション（継承）」という二つの要素が伴う。カストディは、誰がコード、鍵、ハードウェア、アカウントなどを実際に所有し、管理するかという側面であり、これは契約書に明記され、請求され、監査される。一方、サクセッションは、保管者が応答しなくなったときに、誰がその義務を引き継ぐかという側面であり、こちらは往々にして「当然そうなるだろう」と仮定されがちだ。契約は法的責任を移転できるが、「電話に出る能力」を移転することはできない。メンテナンス担当者が燃え尽きたり、リポジトリが移動したり、製品ラインのスコープが変更されたりすると、法的な義務は維持されても、実務的な義務は消滅することがある。結果として、請求書だけが手元に残り、肝心な相手がいなくなる状況に陥るのだ。

このような状況を避けるためには、システムの依存関係に対する見方を根本的に変える必要がある。そのための最も簡単な監査方法が「午前2時のテスト」だ。顧客に目に見える影響を与える可能性のある全ての依存関係について、「午前2時に誰に電話すればいいのか、その人は次の買収後もそこにいるのか？」という一つの質問を自分に問いかけてみる。ほとんどのチームは企業名を挙げられるかもしれないが、個人名を挙げられるチームは少ない。さらに、「次の買収後もそこにいるか」という質問に正直に答えられるチームはほとんど存在しない。なぜなら、この問いに答えるには、契約書には書かれていない次の事実を知る必要があるからだ。ベンダー側でこのシステムの変更を承認できるのは誰か。アカウント所有者が退職した場合、資格情報は誰が保持するのか。彼らの運用手順書には後継者の名前が記載されているか、それともアカウントはノートパソコンを持った一人の人間にかかっているのか。ベンダーが買収された場合、自社との契約は譲渡されるのか、そもそも譲渡可能なのか、といった点だ。これらの問いから明らかになるのは、失うことが最も許されない重要な依存関係ほど、実は後継者が薄い傾向があるという、不都合な真実だ。重要なインフラストラクチャは三人程度のチームとメーリングリストによって維持されていることが多く、分厚い契約書を持つ大規模なエンタープライズベンダーの方が、実は四半期で代替できるようなものだったりする。

継承の問題は、法的な問題ではなく、設計上の決定として対処すべきものだ。契約書で継承を保証することはできないが、システムをそのように設計することは可能だ。主に四つの特性がこの問題解決に役立つ。一つ目は「アドレス独立性」だ。依存関係がどこに存在するかをハードコードしてはならない。自社が制御するレイヤー、例えば自社のミラー、プロキシレジストリ、自社のDNSを通じて、その場所を解決するように設計する。そうすれば、他者がリポジトリを移転しても、それは単なる設定変更として処理され、インシデントにはならない。二つ目は「鍵付きエスクロー」だ。エスクローにソースコードだけを預けても、それは単なる記念品に過ぎない。ビルドシステム、秘密情報のローテーション手順、そして40ものサービスの中で実際にどれが重要であるかを説明するドキュメントも一緒に保管する必要がある。箱が必要になる前に、その箱に何が入っているかを確認しておくべきだ。三つ目は「出口可能なデータ」だ。システムの完全な状態を、見知らぬ人でもインポートできる形式でエクスポートできなければ、自社のデータを所有しているのではなく、アクセスを借りているに過ぎない。四つ目は「自社内の指名された後継者」だ。あらゆる重要なベンダーについて、自社内に二人目の担当者が必要だ。この人物は、一度ログインし、ドキュメントを読み、何が壊れるかを理解しているべきだ。買い手側での「バスファクター」（特定の特定の人物がいなくなると業務が滞るリスク）が1であることは、売り手側での「バスファクター」が1であることと同じくらい致命的であり、これは完全に自社の管理下にある問題だ。

もし自社のスタックの一部を顧客に再販している場合、例えばエージェンシー、SaaS、エージェント製品を運営しているなら、この継承の問題はエンジニアリングの問題である前に、顧客への「開示」の問題となる。顧客は自社のベンダーリストを求めているわけではない。彼らが知りたいのは、「サプライヤーが消失した場合、彼らのサービスはどうなるのか」「そのサプライヤーを代替するまでの間、どれくらいの期間サービスを稼働し続けられるのか」「そして、その回答に対して自社内の誰が責任を持つのか」という三つのことだ。もしこれらの三つの問いに答えられないのであれば、自社はストレス耐性のない依存関係を顧客に販売していることになる。サプライヤーの撤退を優雅に乗り切るチームは、より優れたサプライヤーを持っていたからではない。彼らは、顧客がそのリスクについて、何ヶ月も前に、普通の言葉で、自社から直接聞かされていたチームなのだ。この正直な一文が、何年もの信頼を築くことになる。

今週中に取り組むべき六つの具体的な行動がある。まず、自社の主要な五つの依存関係について「午前2時のテスト」を実施する。それぞれについて、企業名、担当者名、そして「変更を承認するのは誰か」という答えを洗い出す。空欄がリスクの兆候だ。次に、代替できないものは全てミラーリングする。一つの内部レジストリプロキシ、自社で制御するDNSレイヤーを構築する。リポジトリの移転がビルドを壊す可能性があれば、移転が起こる前にその問題を解決しておく。エスクローボックスを開けて、中身を確認する。もしエスクローを契約しているなら、それが単なるソースコードだけでなく、ビルド手順と秘密情報のローテーション手順を含んでいることを確認する。持っていないなら、その費用を見積もる。契約更新時には、譲渡条項を追加する。買収時に譲渡できない契約は、紙切れ同然の価値しかない。契約時には必ずこの質問をするようにする。自社側でのバスファクターを解消する。二人目のエンジニアがログインし、運用手順書を読み、今月中に何か一つ変更作業を行う。アクセス権を持っていることと、実際にアクセスを行使したことがあることは別物だ。最後に、ハンドオーバー段落を作成する。それは「サプライヤーXが消失した場合、何が、どれくらいの期間変更され、誰がその責任を負うのか」という一文だ。そして、顧客が尋ねる前に、最も重要な顧客にそれを送付する。

これらはデモンストレーションでは決して現れないが、サプライヤーが電話に出なくなった四半期には、その全てが顕在化する。そしてその時、最も重要なことは、誰かがすでに「義務を継承するのは誰か」を書き留めていたかどうかだ。