Block社が450のJVMリポジトリをモノレポに統合——依存関係ドリフトをどう解消したか
Cash App・Squareを擁するBlock社が、450超のJVMリポジトリをモノレポに統合した大規模移行の舞台裏が公開された。運用上の課題と設計判断が具体的な数字とともに語られており、同様の悩みを持つ開発組織にとって参照価値が高い事例だ。
出典: Behind the Scenes: Block 450 JVM Repositories Into Monorepo to Reduce Dependency Drift
要点 (事実のみ)
- Block社はCash App・Square engineering組織で約450のJVMリポジトリをモノレポに統合した
- モノレポは現在週約8,800ビルドをサポートし、CI p90タイムは約10分でmainブランチは安定稼働している
- polyrepo時代は依存バージョンのドリフト、重複したアップグレード作業、ダイヤモンド依存問題による実行時障害が頻発していた
- カスタムIntelliJプラグインで「エンジニアが作業中のプロジェクトのみ」をIDEに読み込む仕組みを構築し、依存プロジェクトはpublished JARへ動的に差し替える（OSS実装: github.com/joshfriend/spotlight、github.com/block/artifact-swap）
- AIアシスト開発ツールの導入後、モノレポの広いコンテキストがエージェントの精度向上に寄与しており、標準化の投資が効いているとのこと
徐 聖博の見解
この事例で私が最も注目したのは、移行完了後の「ビルド性能とgitスケーラビリティはAI導入前後で本質的に変わっていない」という発言だ。コード変更の速度が上がった分だけ既存のスケーリング課題が先鋭化しているという話であり、AIツールを導入すれば基盤が勝手に最適化されるわけではない、という当たり前の事実を改めて突きつけている。
受託開発の現場で複数プロジェクトを並走させていると、polyrepoの「各チームが独立して動ける」という設計の誘惑は強い。ただBlock社が指摘するように、その代償はライブラリ更新ごとの「調整コスト」として静かに積み上がる。ダイヤモンド依存問題は理論上の話ではなく、ある規模を超えると本当に実行時障害になって出てくる。私自身、複数クライアント環境でのバージョン整合性に手を焼いた経験が何度かある。
一方で、この記事が正直に語っている「プラットフォームチームへの継続投資がなければモノレポは失敗する」という点は強調しておきたい。中小規模の開発組織がBig Techの事例を見てモノレポに憧れるケースは多いが、専任プラットフォームチームを置けない体制でモノレポを採用すると、「隣のプロジェクトの遅いビルドに全員が引きずられる」という事態が起きやすい。Block社自身が「プロジェクトが似た形をしていること」を前提条件に挙げているように、言語・フレームワーク・スタイルが混在する組織には向かない選択だ。AIエージェントがモノレポの広いコンテキストで精度を上げるという知見は興味深いが、まずその「広いコンテキスト」を維持できる組織規律と投資があってこその話である。
(編集レンズ: 実装・運用視点 / 発注側・中小企業・開発実務への含意)
