境界線での洗礼：「コードが汚い」は通用しない現実
どうも！海外でC# / WPFエンジニアとして、日々コードと格闘しながら大規模システムの設計・開発に明け暮れている「僕」です。
皆さんは、現場で「このコード、もう限界だよ……」「リファクタリングさせてくれ！」と叫びたくなったことはありませんか？ 僕は何度もあります。特に、歴史の長いWPFプロジェクトを引き継いだ時、巨大なViewModelやスパゲッティ状態のイベントハンドラを前にして、キーボードを打つ手が震えることも珍しくありません。
しかし、海外のタフな現場に出てから、僕は一つの巨大な壁にぶち当たりました。それは、「コードが汚いから直したい」というエンジニアとしての正当な主張が、驚くほどマネジメント層に響かないという冷徹な現実です。
「So what?（だから何だ？）」
数年前、僕があるグローバル企業のプロジェクトに参加して間もない頃、意気揚々とドイツ人のプロジェクトマネージャー（PM）にこう提案しました。
「このViewModel、3,000行あります。何をするにも時間がかかるし、バグの温床です。次のスプリントでリファクタリングの時間をくれませんか？」
日本での経験から、技術的なリスクを伝えれば「そうだね、品質は大事だ」と理解してもらえると信じて疑わなかった僕に、彼は無表情でこう返しました。
「So what?（だから何だ？）」
彼は僕の目を見つめて続けました。「そのコードが『汚い』ことで、具体的にどれだけのビジネス価値が失われている？ そのリファクタリングに2週間かけるとして、その間にリリースできたはずの新機能が生む利益を上回るメリットが、僕に、あるいは投資家にあるのかい？」
僕は言葉に詰まりました。「将来的なスピードが……」と食い下がりましたが、「『将来的』とはいつだ？ 具体的に何パーセント向上する？ その根拠は？」と畳み掛けられ、完敗しました。
合理性とスピードが極限まで求められる現場では、「エンジニアの美学」や「主観的な正義」だけでは1円の予算も勝ち取れません。彼らが求めているのは、エンジニアの「感想」ではなく、**ビジネスを判断するための「データ」**だったのです。
主観をメトリクスへ：感情を「数字」に翻訳する魔法
絶望的なミーティングの後、僕が取り組んだのは、IDEを閉じてExcelとJiraのダッシュボードを開くことでした。エンジニアの「吐き気がする」という感覚を、経営者が理解できる「言語」に翻訳しなければなりません。
そこで僕が出会った概念が、**「Quantifying the Friction（摩擦の定量化）」**です。
1. 「感情」を「サイクルタイム」に変換する
WPFプロジェクトで、特定の「神ViewModel」を触る際、僕たちは無意識に慎重になります。「ここを1行変えたら何が壊れるかわからない」という恐怖です。
僕はチームの過去3ヶ月分のタスクを分析し、「比較的クリーンなモジュール」と「問題のモンスターモジュール」の開発時間を比較しました。結果、後者は平均で2.8倍のサイクルタイムを要していることが判明しました。
これをPMに突きつけました。「このViewModelをリファクタリングすれば、Time to Market（市場投入までの時間）が3倍近くなります。これまで3週間かかっていた新機能が1週間で出せるようになる、ということです」と。
2. 「バグの恐怖」を「変更失敗率（CFR）」に変換する
エンジニアの「触るのが怖い」という感覚を、**変更失敗率（Change Failure Rate）**という数字に変えました。特定のコードベースに対する修正が、どれだけの割合で「新たなバグ」を生んでいるかを算出したのです。
モンスターViewModel周辺の変更失敗率は、驚異の**45%**でした。 「2回修正を出すと、ほぼ1回はバグとして差し戻される。これはプロジェクトにおける最大の不確実性であり、コスト増です。穴の空いたバケツの底を塞ぐ時間をください」 こうなると、交渉は技術的な趣味の話ではなく、「リスク管理」の話に昇格します。
3. 「ビルド待ち」というサンクコスト
密結合な設計のせいで、一部を変えるだけでプロジェクト全体をリビルドしなきゃいけない。この「待ち時間」をチーム全員分集計しました。
「僕たち5人のエンジニアは、週に合計25時間を『画面の立ち上がりを待つ時間』に使っています。これはエンジニア1人分の週の稼働時間の半分以上です」
高額な給与を払っているマネージャーにとって、「給料の半分が待ち時間に消えている」という事実は、耐えがたい損失として映ります。
渋滞の震源地：全社を止めるボトルネックを特定する
数字を武器にしても、「全ての負債を返済する」許可はまず出ません。エンジニアは、どこを直し、どこを「あえて無視するか」という戦術眼を持つ必要があります。
「汚れ」×「変更頻度（Churn）」の視点
2年間一度もバグが出ていない古いクラスがどれほど汚くても、そこに時間をかける価値は低い。本当に解決すべき「摩擦」は、**「Churn（変更頻度）」**が高い場所にあります。
僕はGitのコミット履歴を解析し、以下の2軸でヒートマップを作成しました。
- Churn（変更頻度）: どのファイルが最も頻繁に修正されているか。
- Complexity（複雑度）: どのファイルにロジックが集中しているか。
浮かび上がったのは、全開発者の足を引っ張っている**「累積的なボトルネック」**でした。例えば、全画面で共通して使われる「カスタムデータグリッド」の不備。一人のエンジニアがこの地雷を踏んで原因究明に30分溶かし、それが週に20回、別々のチームで起きていたとしたら。
30 min×20 times=600 min(10 hours)
たった一つのモジュールの摩擦が、組織全体で見れば毎週エンジニア一人分の稼働を丸々飲み込んでいる。この事実を「他チームへの波及効果」として強調する戦術は、グローバル組織では抜群に効きました。
最終奥義：技術負債を「フリクション・ダラー」へ換算する
最後に、これらすべての点をつなぎ、マネジメント層の心を動かす決定打を放ちます。それが、**「フリクション・ダラー（Friction Dollars：摩擦損失額）」**の計算です。
抽象的な「負債」を具体的な「損失額」へ
計算式はシンプルですが、その数字は残酷です。 シニアエンジニアの平均時給を 100 ドルと仮定し、前述の「累積的なボトルネック」による損失時間を掛け合わせます。僕のケースでは、チーム10人が週に平均3時間ずつ、共通モジュールの不備による「不要なデバッグ」に追われていました。
100 USD/hour×10 engineers×3 hours/week=3,000 USD/week
3,000 USD×52 weeks=156,000 USD/year
これをPMに突きつけました。 「あなたが今、このリファクタリングを後回しにすると決めるのは、毎年15万ドル以上（約2,200万円）のお札をシュレッダーにかけて捨て続けると決めるのと同じことです。それでも新機能を優先しますか？」
PMの顔が引き攣りました。「汚いコード」という言葉には動じなかった彼も、具体的な「ドルの垂れ流し」には即座に反応したのです。
結論：メンテナンスは「投資」である
海外で働く中で、僕が最も大きな気づきを得たのはこのマインドセットの変化です。多くのエンジニアは、リファクタリングを「申し訳ないけれどやらせてもらう作業」だと考えがちです。しかし、それではいつまで経っても技術負債は解消されません。
僕たちがすべきなのは、許可を求めることではなく、「システムのROI（投資対効果）を最大化するための戦略的投資」を提案することです。
明日からあなたができるアクション
もしあなたが今、現場のコードベースに絶望しているなら、今日からこの3ステップを始めてください。
- 「摩擦」に時間のラベルを貼る: 開発中のイライラのせいで、今日何分ロスしたかを記録する。
- Churn（変更頻度）を可視化する: Gitの履歴から、最も「触られている」ファイルを探し出す。
- 損失額を算出する: その摩擦がチーム全体で生んでいる「フリクション・ダラー」を計算する。
海外で生き残るということは、自分の価値を数字で定義し、証明し続ける旅です。コードの海で溺れるのではなく、数字という羅針盤を持って、システムを自由自在に操る航海士になってください。
「汚いコード」に文句を言う時間はもう終わりです。さあ、その摩擦を「ドル」に変えて、世界を驚かせるインパクトを生み出しましょう！
コメント