プロジェクトにおけるテクノロジー动物园：その定義、原因、解決策

プロジェクトにおけるテクノロジー动物园とは

テクノロジー动物园とは、プロジェクトや企業が同じタスクを解決するために過剰な数の異種ツールを使用する状況です。例えば、3つの異なるHTTPクライアント（Alamofire、OkHttp、Ktor）、2つのステートマネージャー（Redux、MobX）、3つのデータベース（Realm、CoreData、SQLite）などです。

动物园と、異なるタスクに対して異なるツールを意図的に選択することの違いは、戦略の欠如です。チームAがReact Nativeを選び、チームBがFlutterを選び、チームCがKotlin Multiplatformを選び、共通の決定がない場合 — それが动物园です。多様性自体は有害ではなく、その制御不能な性質が有害なのです。

プロジェクトの新しいスタックはそれぞれ、開発者の認知負荷を増加させます。効果的に働くためには、使用されるすべてのテクノロジーのニュアンスを覚えておく必要があります。Google（2024）によると、異なるスタック間のコンテキストスイッチングは、統一されたテクノロジー環境での作業と比較して、開発者の生産性を23％低下させます。

テクノロジー动物园の原因

分散型の意思決定が主な原因です。各チームは全体戦略を考慮せずに、自分のプロジェクトのテクノロジーを選択します。バックエンドチームはKotlin、MLチームはPython、モバイルチームはFlutterを使用します。個別には正しい決定でも、一緒になると动物园を生み出します。

合併と買収（M&A） — 企業が他社を買収すると、テクノロジースタックが統合されます。2つのシステムが同じ問題を異なる方法で解決します。例：スタートアップを買収した後、大企業は内部標準がJava Springであるにもかかわらず、Ruby on Railsスタックを取得します。書き直すか、2つのスタックを並行して維持するかという問題が生じます。

流行のテクノロジーの変化 — ハイプサイクルごとに新しいスタックが追加されます。2015年には全員がAngularJSで書き、2017年にはReact、2020年にはSvelteで書いていました。規律がないと、プロジェクトは異なる時代の層を蓄積します。動作するがサポートされていないレガシーモジュールは、迅速に排除する能力なしに異質性を追加します。

动物园がチームとビジネスにとって危険な理由

新しい開発者のオンボーディングは、1つの代わりに5つ以上の異なるテクノロジーを学ぶことになります。プロジェクトに慣れるのに1週間ではなく、新人は使用されるすべてのツールを習得するのに1ヶ月を費やします。生産性までの時間は、プロジェクトのスタック数に比例して増加します。

コンテキストスイッチング — 1日に3つ以上のスタックを扱う開発者は、各切り替え後にコンテキストを復元するために最大30％の時間を費やします。カリフォルニア大学（2023）によると、切り替えごとに元の生産性レベルに戻るのに23分かかります。1日5回の切り替えで — ほぼ2時間のロスです。

セキュリティリスク — 各スタックにはアップデート、脆弱性の監視、ベストプラクティスの知識が必要です。チームはすべてのテクノロジーに同時に精通することはできません。依存関係疲れ — 使用するライブラリの数がチームの追跡・更新能力を超えると — 製品のセキュリティに直接的な脅威となります。

インフラストラクチャの複雑さ — CI/CDは各スタックごとに設定する必要があります。異なるビルドシステム（Gradle、CocoaPods、npm、pip）、異なる環境要件。インフラストラクチャチームはパイプラインを改善する代わりに、異種パイプラインの維持にリソースを費やします。

プロジェクトの問題を診断する方法

スタック棚卸し — 使用されているテクノロジーの完全なリストを作成します：言語、フレームワーク、データベース、CI/CD、監視システム。各テクノロジーについて、プロジェクト/モジュールの数、サポートレベル、プロフェッショナルレベルで習熟している開発者の数を記録します。

Technology Radar — ThoughtWorksの手法で、テクノロジーを4つの象限に分類します：Adopt、Trial、Assess、Hold。Adopt — 推奨スタック、Trial — 実験的、Assess — 評価中、Hold — 使用非推奨。例：FlutterがAdopt、React NativeがHold — チームは何を選ぶべきか理解できます。

保守コスト指標 — 各スタックの保守に毎月何エンジニアリング時間が費やされているかを見積もります。スタックがリソースの10％を消費しているが、モジュールの2％でしか使用されていない場合 — それは交換候補です。「プロジェクト数」対「保守複雑性」の軸を持つスタックヒートマップは、問題領域を明確に示します。

テクノロジースタックを標準化する方法

Architecture Decision Records（ADR） — テクノロジー選択の根拠を含むアーキテクチャ上の決定の文書化。各ADRには、コンテキスト、検討された代替案、選択の論拠が含まれます。Michael Nygard（2022）がこのアプローチを普及させ、今日ADRはテクノロジーの多様性を管理するチームの標準となっています。

Technology Review Board — プロジェクトの新しいテクノロジーを承認するリード開発者の委員会。意思決定は、既存スタックとの互換性、コミュニティサポート、移行コスト、人材の availability などの基準に基づいて行われます。Spotifyは2018年から同様の委員会を使用しています。

新規プロジェクトのゲートウェイ — ルール：新しいサービスやモジュールは承認されたスタックのみを使用します。例外は根拠を添えたADRを通じて可能です。例：新しいマイクロサービスは、チームがJavaがこのタスクに適していないことを証明した場合のみKotlinで書くことができます。どんなテクノロジーでも無制限に使用することは禁止されています。

スタック多様性の段階的な削減

フェーズ1：凍結 — サポート外のスタックでの新規プロジェクトを停止します。Hold象限の各スタックに廃止予定日を設定します。新機能は承認されたスタックでのみ記述されます。レガシーモジュールは動作を継続しますが、拡張されません。

フェーズ2：統合 — 各タスクに1つのツールを選択します。1つのHTTPクライアント、1つのステートマネージャー、1つのデータベース。代替スタックのモジュールは優先順位に従って移行が計画されます。Strangler Figパターンは、システムダウンタイムなしでの置き換えの主要な方法です。

フェーズ3：移行 — 各スプリントで、チームは時間の20％を、古いスタックから承認されたスタックへの重要なモジュールの書き換えに割り当てます。ターゲットアーキテクチャは文書化され、委員会の決定なしに変更されることはありません。プロセスは动物园の規模に応じて6〜24ヶ月かかります。

例：HTTPクライアントの移行

// Before: 3 different HTTP clients in one project
class HttpClientResolver {
    def resolve(moduleName) {
        switch(moduleName) {
            case "payments": return new OkHttpClient()
            case "chat": return new KtorClient()
            case "analytics": return new RetrofitClient()
        }
    }
}