あなたのエンジニアリングチームが遅い本当の理由は人ではなくコードベースだ
(piechowski.io)- コードベース Drag は、あらゆる作業に必要以上の時間がかかるようになるコードベースの状態であり、ダッシュボードやスプリントレポートには現れないため、リーダーシップがこれを「人の問題」と誤解する悪循環を繰り返してしまう
- 長年にわたるコードベース Audit の結果、同じ 5つのシグナル が繰り返し現れ、それを 0〜2 点で定量化する診断ルーブリック「コードベース Drag 監査」が提示されている
- 見積もりの水増し、デプロイ恐怖、「触るな」ファイル、カバレッジの嘘、最初のコミットまでの時間という 5つのシグナルはすべてコードベース品質の問題 に由来し、人の能力不足とは区別される
- 熟練したエンジニアほどコードベースのリスクをより正確に認識して慎重に動くため、むしろ遅く見えるという逆説 が生じ、これを人材の問題と誤認するとプロセスだけが追加される逆効果が起きる
- 4 点以上ならコードベースへの直接投資が必要で、7 点以上は 即時の構造的介入 が求められる水準
コードベース Drag とは何か
- Codebase Drag は、コードベースがあらゆる作業に必要以上の時間をかけさせる現象で、スプリントレポートやダッシュボードには現れない
- 例: クライアントチームが管理パネルに CSV エクスポート機能を追加するのに、2 人のエンジニアが 1 週間を消費 — 実作業は 1 日分だったが、既存コードを安全に変更するための理解に残りの時間が費やされた
- チームの速度低下が繰り返されると、リーダーシップはそれを 人材の問題 と判断し、組織改編、プロセス追加、人員入れ替えで対応するが、次のチームも同じ壁にぶつかる
- 問題の根本はバグでも、欠けた機能でも、一般に言う技術的負債でもなく、コードベースそのもの にある
5つのコードベース Drag のシグナル
1. 謝罪つき見積もり (Apology Estimate)
- 実際には 3 日で終わる機能に対して、エンジニアが 2 週間の見積もりを出す状況で、リーダーシップはこれを 日程の水増し と誤解する
- 実際の理由は、billing モジュールの修正が notification システムにまで波及する モジュール間結合 と、変更時にどこまで影響が及ぶか分からない構造にある
- hidden default scope や深くネストされたコールバックのため、変更影響範囲 (blast radius) はコードの半分を読まなければ予測できない
- 見積もりが一貫して予想の 2〜3 倍かかっているなら、それは見積もり算定の問題ではなく コードベースのコスト問題 である
2. デプロイ恐怖 (Deploy Fear)
- チームが金曜日のデプロイを嫌がったり、デプロイをまとめて大きな単位でまれにしかリリースしないパターンが現れる
- あるクライアントチームでは、水曜日以降デプロイ禁止という非公式ルールを運用していた — 木曜日のデプロイが 3 回、週末障害につながった後に生まれた慣行だった
- ロールバック戦略の欠如、信頼できないテスト、45 分かかるデプロイパイプラインが原因
- DORA 基準でエリートチームは変更失敗率 5% 未満で必要なときに即時デプロイできるが、このチームは週 1 回のデプロイを不安な気持ちで見守る状態
3. 「触るな」ファイル (Don't Touch That File)
- ほぼすべての現場で、「そのファイルは触るな」という言葉が最初の 2 日以内に出てくる
- 30 個の
before_actionが付いた billing コントローラや、git logの上位に現れるのに構造的には何年も手つかずのモデルなど
- 30 個の
git log --oneline --since="2 years ago"を実行すると、最も多く修正されたファイルがいつもその警告されたファイルになる — 小規模なパッチだけが繰り返され、構造的な作業がないなら、症状だけを治療して病気は放置している状態- 真のコストは、そのモジュールにあるべき機能が 別の場所に実装される ことにあり、新規入社者は最初の週のうちにそのファイルを避ける方法を身につける — コードベースは死んだ領域を中心にいびつに成長していく
4. カバレッジの嘘 (Coverage Lie)
- テストカバレッジ 80% という数値は健全に見えるが、実際にはほとんど壊れない serializer・helper・ユーティリティのテストが数値を支えており、お金を扱う中核モデル 3 つにはテストがまったくないことがある
- テストスイートが回帰を検知する代わりに、指標をよく見せるために 存在している状態 — テストが通っても本番は壊れる
- CI 時間が 40 分なので開発者がローカルでのテスト実行をやめる → カバレッジ数値は 2 つの意味で嘘をつく: 重要な部分をカバーしておらず、存在するテストですら実行されていない
- 本当の問いはカバレッジの数字ではなく、「最後にテストが本番前にバグを捕まえたのはいつか」 である
5. 最初のコミットまでの時間 (Time to First Commit)
- 新しいエンジニアにノート PC を渡してから、実際のバグ修正や小さな機能を含む PR を開くまでにかかる時間
- 健全なコードベース: 1〜2 日
- Drag が発生しているコードベース: 2 週間以上
- あるクライアントでは開発環境のセットアップに数週間かかっていたが、修正後は新しい開発者が 15〜20 分で環境構築を完了できた
- 中核原因は setup rot (設定の腐敗) —
bin/setupスクリプトが最後の環境変更以降アップデートされていない、もはや存在しないテーブル・カラムを参照するシードデータ、アプリを起動して衝突して初めて分かる未文書化の環境変数 3 つ - 既存エンジニアは文書化されていない手順をすでに内面化しているため、新規入社者だけがコードベースが要求する暗黙知の規模を正確に可視化する
悪いコードベースで優秀なエンジニアが遅く見える理由
- 5つのシグナルは 複合的に作用 し、すべての作業に、standup で名指しできないオーバーヘッドを加える
- 前職では 2 日で機能を実装していたエンジニアが、このコードベースでは 1 週間かかり、その理由を説明しようとしても言い訳に聞こえてしまう
- 2025 年の METR 研究 では、熟練開発者は AI ツールを使うと 19% 遅くなった — ボトルネックがタイピングではなかった証拠
- 最高のエンジニアほどリスクをよりよく認識し、より慎重に動き、見積もりを厚めに取る — 熟練度の低いエンジニアはリスクを見落としてより速くデプロイし、本番障害を起こした結果、チーム全体がさらに慎重になるという悪循環
- あるクライアントは 10 年間で 6 チームを入れ替えた（完全買収 2 回を含む） — リーダーシップの機能要求 → 負債処理のスキップ → コードが回復不能な状態に → リライトまたはマイクロサービス分離の提案 → システムが 2 つに増えてさらに悪化、というパターンが繰り返された
- リーダーシップが速度低下を人材の問題として読むと、すでに摩擦に苦しむチームにプロセスだけを追加 して悪化させる — 実際に役立つ唯一の介入は、経路 (path) そのものを修正すること
コードベース Drag 監査: 診断方法
- 5 つのシグナルそれぞれを 0〜2 点で採点する:
- 0 点: 問題なし
- 1 点: 部分的な問題
- 2 点: 深刻な問題
- 4 点以上 なら、ほかのどんな対策よりも先にコードベースへの直接投資を行うべき
技術的負債がチームを引きずるときの対処法
- 最も高得点のシグナル 1 つから始める — すべてを同時に直そうとしないこと
- デプロイ恐怖が 2 点: CI の高速化、ロールバック自動化、小さなデプロイ単位の改善を優先
- 謝罪つき見積もりが最上位: 最も広い blast radius を持つモジュールのデカップリングを優先
- 最初のコミットまでの時間が 2 点:
bin/setupの修正と環境の文書化に 1 日投資すれば、その後のすべての採用で回収できる
- Rails のバージョンが何世代も遅れている場合、バージョンアップ は投資を正当化する forcing function になり得る
- 2 週間単位で測定: 最高得点のシグナルを選ぶ → 集中スプリント → 具体的な数値を測定（デプロイ頻度、見積もり精度、最初の PR までの時間など）
- 投資承認を得にくい理由は、やらなかった場合のコストが見えないから — 「技術的負債がある」よりも、「この 3 つのモジュールの結合のせいで、すべての機能に約 2 倍の時間がかかっている」のほうがはるかに説得力のある会話になる
- 7 点以上 は、一般に 1 週間のコードベース監査から始めるべき水準
5件のコメント
マジでレガシープロジェクトはがんのような存在
いっそ最初から作り直したほうがマシなものもあります
私のこと…？
保守コスト削減に本当に重要な文章のようです
だからこそ、新しく書き直したほうが速いケースが出てくることもあるんですよね。
コードベースを整理することが長期的には速度を上げる道だということは誰もが分かっていますが、
よく食べて、運動して、よく眠れば健康になるというのと同じレベルの話ですよね