- カオスなコードベースと向き合う覚悟
- ■ “全部じゃなくて、一番効くところ”だけに集中する文化
- ■ Strangler Fig パターンが2025年の現場で強いワケ
- ■ “改善の筋肉”をつける最初の一歩は、トラウマ地点を探すこと
- ■ そして最後に知った「本当の地雷」
- 小さな“介入”が大きな改革を生む
- ■ レガシーシステムを殺さず生かす「Strangler Fig」の具体的な進め方
- ■ 「どこから手をつけるべきか？」海外で学んだ確実な判断基準
- ■ ターゲットを定めたら“一気に直さない”のが鉄則
- ■ 海外現場で体感した「改善の最強ブースト」＝自動化
- ■ 海外現場で見た“改善がうまいチーム”に共通する3つの特徴
- 理想と現実のギャップに飲まれる瞬間
- ■ 「やったほうがいい」と全員が思っているのに動かない謎
- ■ “正しい改善”が“正しく伝わらない”ときの地獄
- ■ 改善が拒否される理由は“技術”ではなく“信用”
- ■ では、どうやって信頼を勝ち取るのか？
- ■ 技術的に正しい改善でも“タイミング”を間違えると失敗する
- ■ 海外での改善文化が教えてくれた「最大の真実」
- 小さく始め、大きく変える
- ■ ステップ1：改善のアンテナを立てる（今日から1時間でできる）
- ■ ステップ2：まずは“触って安全な改善”だけ実施する
- ■ ステップ3：改善したら必ず“ガードレール”を置いて帰る
- ■ ステップ4：改善は必ず“説明”とセットで届ける
- ■ ステップ5：改善を“続けられる仕組み”を作る
- ■ ステップ6：改善は“キャリア”を強くする最強の武器になる
- ■ 最後に：小さな改善は、人生すら変える
カオスなコードベースと向き合う覚悟
──「全部作り直す」は最適解じゃない**
海外でエンジニアとして働いていると、チーム文化もプロダクトの歴史も、国ごとにまったく違うんですよね。
僕が初めて海外プロジェクトにジョインしたとき、まず衝撃を受けたのが「コードの遺跡」みたいなレガシー部分が平然と息をしていることでした。
「これ……いつのコード？」
「2011年。」
「メンテしてる人は？」
「誰も知らない。」
いやいや、ホラーか。
でもどの国でも似たような光景にはよく出会います。これは“日本特有”とか“海外特有”みたいな話じゃなく、長く運用されてきたシステムには必ず“歴史の重み”があるというだけ。
そして海外のエンジニアチームではよくこんな会話が起きます。
- 「全部作り直した方が早いのでは？」
- 「いや、リライトは墓場行きのフラグだ」
- 「このコンポーネントだけ strangler fig で置き換えよう」
最初の頃は「strangler fig？何の呪文？」と思っていましたが、これは自然界の“締め殺しのイチジク”という木から取られたソフトウェアアーキテクチャのパターンで、古いシステムをいきなり壊さず、徐々に新しい部品で包み込むように置き換えていく手法のこと。
僕が実際に海外プロジェクトで学んだのは、
👉 成功するチームは、リライトではなく「高レバレッジな小さな介入」を積み重ねる
ということでした。
■ “全部じゃなくて、一番効くところ”だけに集中する文化
海外の現場では、時間も予算も圧倒的にシビアです。
そのため、**「一番効くところだけ変えよう」**という意思決定がとても多い。
例えばこんな感じ。
- UI全体はレガシーでも、ボトルネックの1画面だけWPF MVVMで再構築する
- 影響範囲が大きいバッチ処理はそのままでも、遅延を生んでいる1つのクエリだけ最適化する
- 全テストの整備が無理でも、壊れやすい部分だけE2Eテストを追加する
日本で働いていた頃の自分は、どうしても「100点を目指したくなる」タイプでした。
全部きれいに整えて、根こそぎ改善したい。でも海外ではそのアプローチはあまり歓迎されません。
なぜなら――
「100点を目指して何も出せないなら、60点で小さく出して学ぶ方が強い」
という考え方が当たり前だから。
僕が指摘されたことがあります。
“Don’t boil the ocean.
（地球全体を沸騰させようとするな）”
全部やろうとするな、という英語の慣用句です。
当時かなり刺さった。
■ Strangler Fig パターンが2025年の現場で強いワケ
2025年のソフトウェア開発は、数年前よりもずっと加速しています。
AI支援や自動化が進んで、開発スピードもコード量も増えているのに、レガシーは逆に増え続ける一方。
そんな中で、海外の現場でよく導入されるのが、
Strangler Fig パターン + Targeted Refactoring（狙って直す改善）
の組み合わせ。
実際に僕のプロジェクトで起きたケースを紹介すると：
●「巨大なGod Class」をいきなり直さない
依存が複雑すぎて、正直触れたくない。
でも影響が大きくて、無視するわけにもいかない。
このときチームが取った戦略は、
- 次に改修が入ったメソッドだけ分離する
- 触るたびに、その周辺だけ小さくクリーンアップする
- 新規機能だけは新アーキテクチャ側へ配置する
これだけ。
それなのに半年後には、巨大クラス全体の25%が安全な構造に入れ替わり、
結果的にチームのデリバリースピードが大幅に改善しました。
**「触るところだけ良くする」**は、思っていた以上に強い。
■ “改善の筋肉”をつける最初の一歩は、トラウマ地点を探すこと
僕が海外で学んだ中で、一番現実的で効果があったのはこれ。
「一番痛い場所」から手をつける。
“痛み”が最大の投資対効果を生む場所だから。
海外のシニアエンジニアは決まってこう聞きます。
- 「この1ヶ月で、一番デプロイを遅らせたのは何？」
- 「触るのがいつも怖いコードはどこ？」
- 「バグ修正に毎回時間がかかるのはどのモジュール？」
答えはシンプル：
そこを直せば、チーム全体のスピードが上がる。
100箇所の改善より、1箇所の改善がチームの未来を変える。
Targeted Interventions（狙って効かせる改善）とはまさにそういう思想です。
■ そして最後に知った「本当の地雷」
──新しい問題を作らないためのガードレール
海外では、リファクタリングをするとき必ず言われます。
“Don’t introduce new debt while eliminating the old one.”
（古い負債を消すとき、新しい負債を生むな）
これ、めちゃくちゃ重要。
だから海外チームの多くでは、
小さな改善でも必ずテスト・静的解析・CI/CDの自動化をセットで進めます。
- 「直したところに自動テスト追加して」
- 「品質ゲートに引っかかったら merge すんなよ」
- 「PR出すたびにコードスキャン回るから」
最初は厳しいけれど、
これがあるからこそ“安全に改善できる文化”が育つ。
僕自身、海外に来て初めて、自動化は武器だという感覚が腹落ちしました。
小さな“介入”が大きな改革を生む
──海外現場で学んだ「高レバレッジ改善」のリアル戦術**
「全部直すのはムリ。でも、この一か所だけなら明日から変えられる。」
海外での現場経験を重ねる中で、僕が最も強く実感したことのひとつが、
この“少しずつ変える”アプローチこそチームのスピードを最大化するという事実でした。
起のパートで触れたように、海外の現場では「広く浅く直す」より「狭く深く効かせる」が主流。
ここでは、実際に僕が体験した Targeted Interventions を成功に導く具体的な技術やプロセス を掘り下げていきます。
■ レガシーシステムを殺さず生かす「Strangler Fig」の具体的な進め方
初めてこのパターンを本気で使ったとき、正直かなり半信半疑でした。
「古いシステムを壊さずに新しい部品で包み込むって、どうやるの？」
「結局汚い部分が残ってしまって意味ないんじゃ？」
でもプロジェクトを進めるうちに、考え方が一変しました。
◆ STEP1：呼び出し経路を“見える化する”
海外チームはまず現行のアプリケーションフローを洗い出します。
WPF なら次のように整理していきます：
- どの ViewModel がどの Model を呼び出しているか
- サービス層に依存が集中している箇所
- ユーザー操作の入り口と出口（Command やイベントの流れ）
すると、**「触らなくていい部分」と「触らないといけない部分」**が明確になります。
◆ STEP2：影響最小で置き換えやすい“つなぎ目”を特定する
Strangler Fig は丸ごと差し替えるのではなく、
最初のターゲットとして最も置き換えやすい境界を探すところから始まる。
例えば：
- API 呼び出し部を新しいラッパークラスに切り替える
- 設定管理をレガシー XML → JSON + 新ローダーに移行する
- データアクセス層を Repository パターンに少しずつ移していく
このとき重要なのは、
必ず“分岐ポイント”を新アーキ側に寄せていくこと。
古いコードの中に新しいコードを混ぜるのではなく、
新アーキ側に移っていく流れを作り、そこに吸収していく感覚です。
◆ STEP3：触った部分だけテストを追加して“ガードレール”を作る
海外の現場で本当に驚いたことの一つが、
改善したコードには必ずテストをつける文化が存在すること。
「直したところにガード追加してないと、次触る人が死ぬから。」
これは口癖のようによく聞きました。
小さく改善 → テスト追加 → また改善
この繰り返しが、コードベースの安全性をどんどん強くする。
■ 「どこから手をつけるべきか？」海外で学んだ確実な判断基準
エンジニアが陥りがちなのが、
“技術的に気になる部分”から直そうとしてしまうこと。
僕も昔はそうでした。
でも海外の実務で強烈に言われたのが、
「技術的にやりたいことと、ビジネス的に価値があることを混同するな。」
つまり、直すべき部分には明確な優先順位が必要だということ。
海外チームが実際に使っていた優先度付け基準を紹介します。
◆ 1. 失敗率が高い部分（バグ再発率）
海外では、特に北米企業だとプロダクトの失敗ログがすべて可視化されます。
- アプリが落ちた頻度
- どのクラスで例外が起きたか
- どの画面操作でクラッシュしたか
これがダッシュボードで見えてしまうので、“怖いコード”が一目瞭然。
誰が見ても「この部分から直すべき」という判断になります。
◆ 2. デリバリーを最も遅らせている部分（毎回デプロイで何か起きる）
僕のチームでもありました。
- PRが通らない
- テストが毎回落ちる
- マージ後に予期せぬ副作用が出る
こういう箇所は**チームの生産性を毎週削る“サイレントコスト”**を生むため、
最も優先して手をつけます。
◆ 3. 今後のビジネス価値（将来の機能がそこに依存する）
海外では、プロダクト思考が非常に強いです。
「次の四半期で追加する予定の機能が、このレガシー部分を使うなら今のうちに直す」
という判断がよく行われます。
つまり、
未来の成長を邪魔するレガシーは、今改善する価値がある。
■ ターゲットを定めたら“一気に直さない”のが鉄則
日本では、丁寧にやりたい文化がありますよね。
僕もその気持ちはよくわかる。
でも海外の現場では、
「完璧に直すと必ず失敗する」
とまで言われます。
これは別に品質を軽視しているわけではなく、
レガシー改善は“リスク戦”だから。
◆ だから改善は「三段階戦法」で進む
海外で実際に使われていたのが、この三段階アプローチ：
- Thin Slice（薄く切る）
小さく、影響が最小の断片に区切る - Decouple（切り離す）
依存を減らし、呼び出しをシンプルにする - Replace（置き換える）
新しいモジュールに段階的に移す
この手順が強い理由は、
いつでもロールバックできる構造が残るためリスクが最小になるから。
海外のシニアは「逃げ道を確保してから改善しろ」と必ず言います。
■ 海外現場で体感した「改善の最強ブースト」＝自動化
テスト、コードスキャン、CI/CD。
これらは、起のパートでも触れた通り“改善のガードレール”ですが、
実務ではさらに強烈なメリットがありました。
◆ ◆ 自動化は「改善のスピード」と「チームの信頼」を同時に上げる
自動化がないチームだと、
- 直したのに壊す
- 修正後の動作確認に毎回時間がかかる
- 新しいバグを生む恐怖で誰も触らない
こんな負のスパイラルに陥ります。
反対に自動化が整うと、
- PR 出しただけで安全性が可視化される
- テストが即座に壊れを検知する
- 改善が“心理的に安全”な作業になる
特に海外では、「心理的安全性」の概念が非常に重要視されているため、
こうしたガードレールは文化として深く浸透しています。
■ 海外現場で見た“改善がうまいチーム”に共通する3つの特徴
いろんな国のエンジニアと仕事をした中で、
改善のうまいチームには共通する特徴がありました。
◆ 1. 改善の目的を常に言語化する
「なぜ直すのか？」
これを必ず言う。
- 新しい API に移行するため
- 今後の機能に必要な基盤のため
- バグ発生率を下げるため
目的を全員が分かるように共有するので、
改善が“思いつき”ではなく“戦略”になる。
◆ 2. 小さく出す。早く出す。
海外の現場では、完璧主義はほぼ悪です。
- small PR
- small refactor
- small test addition
この“三小”が徹底されています。
「この変更、大きいね。分割して。」
と言われるのは日常茶飯事。
◆ 3. 直したら必ず自動テストを敷く
改善＝ガードレール追加
これはセット。
ここまで徹底しているからこそ、
Strangler Fig は本当に機能するのだと実感しました。
理想と現実のギャップに飲まれる瞬間
──改善は“技術”よりも“人間”が最大の壁になる**
起と承で紹介してきたように、
Targeted Interventions（狙って効かせる改善）は、
海外の現場で確実に成果を生んだアプローチです。
でも――現実の現場はもっと泥くさくて、もっと複雑です。
コードを改善するのは簡単じゃない。
というより、**コードより難しいのは“チームの心理”**なんですよね。
ここでは、海外で僕自身がぶつかった
改善活動のリアルな壁と、その乗り越え方
を赤裸々にまとめていきます。
■ 「やったほうがいい」と全員が思っているのに動かない謎
海外で改修を進めようとすると、必ずこんな雰囲気が出ます。
- 「直したいけど、今は忙しい。」
- 「あの部分は危険すぎて触りたくない。」
- 「改善より新機能が優先されるよ。」
改善したほうがいいことは、みんな頭では分かっている。
でも手をつけない。動かない。責任を負いたくない。
特に、古い部分ほど「触るのが怖い」という空気が強くなる。
誰も触らない → もっと危険になる → 余計触れなくなる
この悪循環が、現場のスピードをじわじわ削っていきます。
僕も海外に来たばかりの頃、
自分が改善提案をするとチームが微妙な沈黙をする空気を何度も感じました。
「壊れたらどうする？」
「その変更、責任取れる？」
「今の sprint の scope に入ってないよ。」
改善は技術的問題ではなく、心理的抵抗との戦いなんですよね。
■ “正しい改善”が“正しく伝わらない”ときの地獄
僕がとある海外プロジェクトで経験した、今でも忘れられない出来事があります。
● 僕が改善したいと思った部分は「全員が苦しんでいた場所」だった
毎回クラッシュを起こすデータ変換モジュール。
テストゼロ。
コードは2000行の巨大メソッド。
新しい機能を入れるたびにバグる。
チーム全員が「あれは地雷」と口を揃えていた部分です。
「じゃあここをThin Sliceで分割して、テスト追加して、段階的に改善しませんか？」
そう提案した瞬間、メンバーから返ってきたのは意外な反応でした。
- 「今は他の優先課題がある。」
- 「触ったら余計ひどくなる可能性がある。」
- 「その改善、ビジネス的に直接の価値ある？」
まさかの“無反応”と“懸念の嵐”。
改善の必要性は明らかなのに、誰も前に進まない。
■ 改善が拒否される理由は“技術”ではなく“信用”
後から分かったことですが、
あのとき僕が拒否された理由は、技術でもロジックでもありませんでした。
理由はもっと単純で、もっと人間的なものだった。
「お前は新入りだ。
このコードの地雷を本当に理解しているのか？」「この変更が本当に安全なのか信じられない。」
要は、
改善提案をするには“信頼残高”が必要だということを知らなかった。
改善は、
正しい技術
＋ 正しい方向性
＋ チームの信頼
この3つが揃って初めて前に進む。
どれかが欠けると止まります。
海外の現場では、
- 技術の正しさ
- 論理の正しさ
だけでは、人は動かない。
チームがあなたを信じるかどうか。
その改善が本当に“安全で価値がある”と信じてもらえるかどうか。
改善は技術戦ではない。信頼戦だ。
これが転で一番伝えたいポイントです。
■ では、どうやって信頼を勝ち取るのか？
海外で働く中で、僕が最も効果を感じた方法がこれです。
◆ 1. 改善を“自分の好み”ではなく“チームの痛み”に紐づける
「気になるから直したい」
「きれいに書き換えたい」
これは通じません。
海外では、改善の提案には必ず 痛みの可視化 が求められます。
- 「ここが原因で毎週デプロイが遅れている」
- 「このクラスのせいで障害が月3回起きている」
- 「この部分を直すと開発スピードが10%早くなる」
痛み → 改善 → 効果
この流れが明示されて初めて説得力が生まれる。
◆ 2. まずは“壊れにくい改善”を小さく出す
海外のエンジニアは、破壊的変更を異常なほど嫌います。
かつ、
安全で小さな改善を継続するエンジニアには強い信頼を寄せます。
たとえば：
- 不具合になりそうな null チェックを追加する
- ログを少し丁寧にする
- テストを1つだけ追加する
- 新規コードは必ず MVVM 原則に沿う
こうした“小さな安全な改善”を積み重ねることで、
周りの感情が変わります。
「あの人が触ったところは安全だ。」
「PR の質が安定している。」
「判断に一貫性がある。」
こうなったら勝ち。
改善提案が通りやすくなり、一気にアクセルが踏めます。
◆ 3. 改善の提案は“Pull Request”で証明する
海外では、ミーティングで「直したい」と言うよりも、
PR で小さくサンプルを出すほうが圧倒的に早く信頼されます。
- Before / After
- 変更範囲
- 追加テスト
- 安全性の根拠
PR に乗せて伝えることで、初めて「価値」を理解してもらえる。
口で説明するより、動く改善を見せたほうが何倍も説得力がある。
■ 技術的に正しい改善でも“タイミング”を間違えると失敗する
海外では「正しい改善でも、間違ったタイミングでは提案すべきではない」
とよく言われます。
たとえば：
- 新機能の締め切り直前
- 全員火消し作業で忙しい週
- リリース前日のタイミング
- 重大障害の直後（心理的にナーバスになっている）
このタイミングで改善を提案すると、
どれだけ正論でも確実に嫌われます。
改善は、
技術の勝負ではなく“空気を読む技術”も必要。
海外のシニアエンジニアが言っていた一言が忘れられません。
“Right solution at the wrong time is a wrong solution.”
（正しい解決策でも、タイミングを間違えれば誤りになる）
本当にその通り。
■ 海外での改善文化が教えてくれた「最大の真実」
改善は、正義ではありません。
改善は、努力ではありません。
改善は、アートでもありません。
改善は――
信頼 + 安全性 + タイミングで成り立つ、
チームスポーツなんです。
どれか一つ欠けたら動かない。
だからこそ、改善を成功させるには技術だけではなく、
チームとの関係性、文化の理解、タイミングの判断、コミュニケーション力まで必要になる。
そして何より重要なのは、
「チーム全員が改善したくなる空気」を作ること。
成功する海外チームは、
改善を“個人の努力”ではなく“チームの共同作業”に変えていく。
それができた瞬間、
Strangler Fig も、Targeted Refactor も、CI/CD も、一気に機能し始めます。
小さく始め、大きく変える
──明日から“改善できるエンジニア”になるための実践マップ**
改善は才能ではありません。
改善は文化でもありません。
改善は、小さな習慣の積み重ねです。
海外で働きながら、ストラングラーフィグも、ターゲット改善も、自動化も、
そして「人」が最大の壁になる現実も、全部身をもって経験してきました。
でも僕が最終的に気づいた最も大切なことは、
改善は誰にでもできる“人生術”であり、エンジニアのキャリアを一気に飛躍させる武器になる
ということです。
ここでは、読者が“改善できるエンジニア”になるための
明日からの実践ステップを具体的にまとめます。
■ ステップ1：改善のアンテナを立てる（今日から1時間でできる）
まず最初にやるべきことは、
“改善できる場所”を探すことではありません。
やるのはむしろ逆で、
「チームが最も痛がっている場所」を把握する
これだけでいい。
技術的に重要かどうかではなく、
ビジネス的に価値があるかどうかでもない。
まずはチームの声を聞く。
- 毎回ここでクラッシュする
- この画面は更新のたびに壊れる
- この依存関係がカオスで誰も触れない
- このテストが毎週落ちる
- このビルドが遅くてストレス
こういう“痛み”の情報こそ、ゴールドマイン。
海外チームでは、こうした苦情や雑談から改善ポイントを拾う文化があります。
改善の第一歩は、技術ではなく「観察」です。
■ ステップ2：まずは“触って安全な改善”だけ実施する
いきなり巨大な改善に突っ込む必要はありません。
むしろ、いきなり大きく変えると確実に嫌われます。
最初の改善は、小さく、壊れないものだけ。
たとえば：
- Nullチェックを1行加える
- ログのフォーマットを整える
- 例外を catch する位置を整理する
- 名前のわかりにくいメソッドを1つだけリネームする
- 新しいクラスにだけテストを追加する
- コメントで依存関係の説明を補足する
これだけでも十分、チームに貢献できる。
大事なのは、
小さい改善を“安全に”積み上げること。
海外では、これを “credibility micro-wins（小さな信用の勝利）”と呼ぶことがあります。
■ ステップ3：改善したら必ず“ガードレール”を置いて帰る
改善したら終わり？
違います。
改善したからこそ、守る仕組みが必要になる。
- 小さなテスト
- Lint のルール追加
- WPF の binding エラーを拾うログ
- 型チェックを厳密にする
- Nullability を有効化する（C# なら特に）
改善は、テストとセットで初めて改善になる。
海外の現場で最も口酸っぱく言われた言葉です。
改善した部分にテストがあると、
次に触る人の心理的安全性が爆発的に高まります。
■ ステップ4：改善は必ず“説明”とセットで届ける
提案が正しくても、説明が下手だと改善は消えます。
海外の改善文化がすごいのは、
必ず「Why」を説明するところです。
PRの説明を書くときは、こう書きます：
- What：何を変えたか
- Why：なぜ変えたか（痛みの説明）
- How：どう安全性を確保したか
- Impact：誰にどんな良い影響があるか
この4つを押さえると、改善は驚くほど通りやすくなります。
説明力は、改善力そのものなんです。
■ ステップ5：改善を“続けられる仕組み”を作る
改善は、単発でやるものではありません。
続けて初めて文化になる。
そして文化になると、改善は勝手に回り始めます。
海外のチームでは、次のような仕組みがよく使われています：
- 毎週 30 分だけ改善タイムを作る
- CI の結果を Slack に流す
- 技術的負債のリストをチームで見える化する
- “今週の改善ヒーロー”を表彰する（海外はこういう文化が好き）
- リファクタリングのガイドラインを Notion で共有する
改善が「個人戦」ではなく「チーム戦」になった瞬間、
チーム全体のスピードが一気に上がります。
■ ステップ6：改善は“キャリア”を強くする最強の武器になる
海外のエンジニア採用で最も重視されるのは、
「機能を作れるか」ではなく「コードベースを改善できるか」。
なぜなら、機能実装は誰でもできる。
でも、改善できる人は組織のスピードそのものを上げることができるから。
つまり、
改善力のあるエンジニアは“替えが効かない存在”になる。
僕自身、海外でキャリアが大きく伸びたのは、
機能開発よりも改善の実績が評価されたからでした。
たとえば：
- テストがゼロだった領域の自動化を整備した
- ボトルネックになっていた WPF の binding エラーを可視化した
- レガシーXMLの設定管理を段階的に JSON に移行した
- ストラングラーフィグで危険な依存部分を安全に隔離した
こうした改善実績は、
どんな派手な新機能よりも評価されます。
改善できるエンジニアは、チームにとって“レバレッジの塊”になるからです。
■ 最後に：小さな改善は、人生すら変える
このブログを読んだあなたに、最後に伝えたいことがあります。
改善とは、
コードの話ではありません。
改善とは、
“未来を良くするための小さな選択”の連続です。
これは人生にも同じことが言えるんです。
- 今日の自分をほんの少し見直す
- 小さな無駄やストレスを取り除く
- 未来の自分のために、ガードレールを置く
- 無理せず、小さく始めて、小さく続ける
改善は仕事だけの技法ではない。
人生の質を高める最強の習慣なんです。
技術的改善ができるエンジニアは、
人生の改善もできる。
そしてその逆もまた同じ。
あなたが今日、小さな改善をひとつ始めたら、
半年後のあなたは間違いなく別人になっています。
改善は、あなたのキャリアを変える。
改善は、あなたの未来を変える。
改善は、あなたの人生を変える。
さあ――
今日、最初の小さな一歩を踏み出してみませんか？
コメント