ツールスプロールが忍び寄る仕組みと、それを実際に制御する方法
新しいチームに参加したとしよう。彼らはCIサーバーAを使っている。廊下の向かいのチームはCIサーバーBを使っている。あるチームは独自のレジストリにアーティファクトを保存し、別のチームはまったく異なるレジストリを使っている。誰にでもそれなりの理由がある。技術スタックが違う、特定のコンプライアンス要件がある、あるいは単に特定のツールのワークフローの方が好みだ、といった具合に。
最初はこれで問題ないように見える。各チームはコードをリリースしている。各チームには自律性がある。誰も他のチームを妨害していない。
そして、統合作業が始まる。
チームAはチームBのレジストリからアーティファクトを取得する必要がある。フォーマットが互換性がない。チームCはチームDが管理するシークレットにアクセスする必要があるが、シークレット管理ツール同士が連携しない。新しいチームができるたびに、誰かが統合パターンをゼロから考え出さなければならない。ドキュメントはWiki、Slackスレッド、READMEファイルに散らばる。人がチームを異動すると、接続方法に関する知識も一緒に消えてしまう。一貫した標準がないため、パイプラインの監査は悪夢となる。
これがツールスプロール（ツールの乱立）だ。そして、これはツールの数が問題なのではない。
ツールスプロールは技術の問題ではなく、意思決定の問題である
ツールスプロールは、各チームが自チームの局所的なニーズに基づいてツールを選択し、それらのツールがより大きなシステムの中でどのように連携するかを考慮しないときに発生する。その決定はチームにとっては理にかなっている。しかし、組織にとっては摩擦を生み出す。
よくある反応は、すべてを中央集権化することだ。CIサーバーを一つ、アーティファクトレジストリを一つ、シークレットマネージャーを一つ選び、すべてのチームにそれらの使用を強制する。これで統合の問題は解決するが、新たな問題が生じる。チームは実際の作業に適したツールを選ぶ能力を失う。彼らは強制されたツールを回避し始める。シャドーITが拡大する。人々はシステムを迂回する方法を見つける。
より良いアプローチは、選択肢を取り除くことではない。柔軟性を奪わずに選択肢を制限する、共有されたリファレンスを提供することだ。そのリファレンスこそが、オペレーティングモデルと呼ばれるものである。
オペレーティングモデルとは実際には何か
オペレーティングモデルとは、ツール選択のための標準、統合パターン、境界を定義する一連の決定事項である。これは rigid なルールブックではない。ツールがどのように接続し、どのような最小要件を満たすべきかについての、共有された合意である。
実用的なオペレーティングモデルは、以下の三つの要素から構成される。
標準。 これらは基本をカバーする。アーティファクトがどのようなフォーマットを使用するか、シークレットがツール間でどのように受け渡されるか、システム間の通信にどのプロトコルが使用されるかなど。標準はどのツールを使うべきかを指示しない。ツールが他のツールと相互作用する際に、どのように振る舞わなければならないかを指示する。
統合パターン。 これらはデータとトリガーの流れを記述する。典型的なパターンは次のようになる。コミットがリポジトリに行われる、CIサーバーが同じリポジトリから設定を読み取る、ビルドが定義されたフォーマットのアーティファクトを生成する、アーティファクトが指定されたレジストリに送られる、デプロイツールがそのレジストリからプルする。このパターンは、どのCIサーバーやデプロイツールが使われていても同じである。
ツール選択の境界。 これらは、どのカテゴリのツールが許可されるか、あるいは少なくとも新しいツールが使用される前に満たさなければならない最小基準を定義する。境界の例としては、「すべてのCIツールはリポジトリから設定を読み取ることをサポートしなければならない、合意されたフォーマットでアーティファクトを生成しなければならない、共有シークレットストアと統合しなければならない」といったものがある。ツールがこれらの基準を満たせば、チームはそれを選択できる。
オペレーティングモデルは、初日から完璧である必要はない。存在し、維持される必要がある。真に優れた新しいツールが登場した場合、モデルは更新できる。目標はツールチェーンを固定化することではない。目標は、毎回カスタム統合作業を行うことなく、すべてのツールが他のすべてのツールと通信できるようにすることである。
デベロッパーポータルを配信メカニズムとして
紙の上のオペレーティングモデルは、単なるドキュメントに過ぎない。それが実際に開発者の働き方に組み込まれて初めて有用になる。これを実現する実用的な方法の一つが、デベロッパーポータルである。
デベロッパーポータルは、単なるツールのカタログではない。優れたポータルは、ゴールデンパス、すなわちコードから本番環境に変更を届けるための標準化され、十分にテストされた経路に接続する。開発者が新しいパイプラインを作成したいとき、ポータルは従うべきステップ、各ステップで利用可能なツール、標準的な設定がどのようなものかを示す。開発者は統合をゼロから考える必要はない。ポータルはすぐに使えるパターンを提供する。
ポータルはまた、オペレーティングモデルを見える化する。チームは他のチームがどのツールを使っているかを確認できる。どの統合がサポートされているかを確認できる。従うべき標準を確認できる。この可視性により、チームがモデルに適合しないツールを密かに採用する可能性が減る。
過剰にエンジニアリングせずに始める方法
開始する前に完全なオペレーティングモデルのドキュメントは必要ない。時間をかけて拡張できる、小さく機能する合意事項が必要である。
最も痛みを伴う統合ポイントから始めよう。それはアーティファクトフォーマットかもしれないし、シークレット管理かもしれない。チームがすでに接続に苦労している領域を一つ選ぶ。その一点について標準に合意する。文書化する。見える化する。そして次の痛点に移る。
チームが新しいツールを導入したいときは、三つの質問をする。
- 既存の標準を満たしているか？
- 合意された統合パターンに従えるか？
- これを追加すると何が壊れるか？
答えが不明確な場合、それはオペレーティングモデルを更新する必要があるか、ツールが適合しないことを示すシグナルである。どちらにせよ、会話はツールについてではなく、モデルについてになる。
ツールスプロールを防ぐためのクイックチェックリスト
- 現在のツールチェーンにおける統合の痛点トップ3を特定する
- 各痛点について一つの標準（フォーマット、プロトコル、インターフェース）に合意する
- すべてのチームがアクセスできる場所に標準を文書化する
- 各カテゴリの新しいツールに対する最小基準を定義する
- 四半期ごとにモデルを見直し、ツールやニーズが変わったら更新する
具体的な takeaways
ツールスプロールは、選択肢を禁止したり、すべてを統一すると約束するプラットフォームを購入したりすることで解決するものではない。統合の期待値を明確にすることで解決する。オペレーティングモデルは、システム全体が機能し続けるという境界の中で、チームに自由を与える。一つの標準から始め、それを見える化し、実際の摩擦点からモデルを成長させよう。目標はツールを減らすことではない。目標は、ツールが実際に連携することである。