- 問題はコードだけじゃなかった
- ● “怖いプロジェクト”は、誰も触りたくない
- ● “誰も触らない現状”こそ最大のリスク
- ● チームが“嫌がる気持ち”を整理するところから始めた
- ● “Why” を伝えられないと、改善は絶対に通らない
- チームの“怖い”を“戦略”に変えていく
- ● まずは“安全に話せる場”を作った
- ● 次にやったのは“恐怖の見える化”
- ● “小さな勝利”を積み上げる戦略へ
- ● チームのマインドが変わった瞬間
- ● ステークホルダーを巻き込む“Why の説明”も強化した
- ● チームが自走し始めたところで、次の大きな波へ
- 改善が“イベント”ではなく“文化”になった日
- ● チームの“改善力”が進化すると、次に数字が変わる
- ● ステークホルダーが“価値”を理解し始める
- ● 改善文化が広がると、チーム間の連携まで変わる
- ● ここで、意外な課題が出てくる
- ● 改善の“暴走”を防ぐために導入した2つのルール
- ● いよいよ本丸：モダナイズ計画が始まる
- 改善の先にあったのは、コードではなく“自分の生き方の変化”だった
- ● ① “恐怖は倒すものじゃなく、利用するもの”
- ● ② “10分触ってみる”は人生でも最強の戦略
- ● ③ “小さな勝利”を積む人は、どこに行っても強い
- ● ④ “説明できる人”は、技術より価値が高い
- ● ⑤ 改善は「チームの幸せ」を生む
- ● ⑥ 改善が教えてくれた究極の人生術
- ■ まとめ：読者へのメッセージ
問題はコードだけじゃなかった
海外で働くようになって最初にぶつかった壁は、「技術そのもの」ではありませんでした。もちろん英語が聞き取りづらいとか、知らないツール文化に馴染めないとか、そういう細かいストレスは山ほどあったんですが、もっと根本的な問題は別のところにあったんです。
それは――**“チーム全体の空気感”**でした。
僕が初めて配属されたプロジェクトには、誰も触りたがらない巨大なレガシーシステムがありました。C#、WPF、昔ながらのMVVM。UIもコードもすべてが「歴史的資産」と化していて、少し触るだけで影響範囲が読めない。レビューでもビクビクしながら「どこが動かなくなるかわからないからやめよう」とストップがかかる。
会議になると誰かが必ず言うんです。
“Don’t break it.”
（壊すなよ）
その一言で、改善の芽が摘まれていました。
新しい技術を学んで活かそうなんて、とても言えない雰囲気。
でも、もっと深刻だったのは、誰も問題の本質を言語化しないまま、「このまま何とかやり過ごす」という空気が根付いていたことでした。
開発者は不安を抱え、マネージャーもリスクを避けたい。結果として、プロジェクトは長期的な負債を増やし続けている。
これ、日本でもよくある話ですよね。
でも海外だと、そこに文化的な温度差まで加わるから、さらに複雑です。
たとえばイギリスのチームの場合、
- 「言わなくても伝わるだろう」は通用しない
- ネガティブな感情もロジカルに言語化することが求められる
- 提案するときは、“Why now?”（なぜ今？）を必ず聞かれる
- 楽観ではなく、根拠が重視される
日本で働いていた頃の感覚のままだと、どうしても“言わない優しさ”や“場の空気を読む”という文化を持ち込んでしまいます。でも、それが逆に「問題を言語化しない人」というラベルになり、改善提案のチャンスを逃してしまうんですよね。
そんな中で僕が強く感じたのは、**海外では「改善の話をする前に、まず“空気”を変えなければ何も始まらない」**ということ。
そしてその空気を変える鍵になるのが、今回のテーマである
- People（人）
- Process（プロセス）
- Progress（進化）
という3つの観点でした。
● “怖いプロジェクト”は、誰も触りたくない
レガシーシステムが怖いのは、技術的な理由だけじゃありません。
「触ると怒られる」という文化的な圧力も大きかった。
Pull Request のレビューでは、こんなコメントが飛ぶこともありました。
“I’m not sure this is safe enough.”
“We should avoid touching this area unless absolutely necessary.”
でも“安全第一”のはずが、実際は誰も構造を把握していない。
そして、誰も触らないから、もっと危険になる。
負のスパイラルってこういうことか、とため息をつきたくなりました。
● “誰も触らない現状”こそ最大のリスク
海外のマネージャーがしばしば口にしていたのは、
“Not taking risk is the biggest risk.”
（リスクを取らないことが、最大のリスクだ）
という言葉でした。
でも現場は逆で、“壊す恐怖”に支配されていた。
このギャップを埋めるには、技術よりもまず“心理的安全性”を整えないといけないんだと気づくまで、正直かなり時間がかかりました。
● チームが“嫌がる気持ち”を整理するところから始めた
僕が最初にやったのは、コードに手をつけることではありませんでした。
やったのは、
- チームメンバーが何に不安を感じているのか
- なぜ改善提案が止まってしまうのか
- 何が決断を邪魔しているのか
これらを、英語でも多少ぎこちなくてもいいから、とにかく“言葉にしてもらう”こと。
すると、みんなの本音が出てきたんです。
- 改善はしたいが、時間がない
- 壊すと責められそう
- 自分が変更した部分の責任を持つのが怖い
- テストが不十分で安心できない
- 「今やる意味」を説明できない
これを聞いた瞬間、「あ、これは技術の問題じゃない」とはっきり確信しました。
● “Why” を伝えられないと、改善は絶対に通らない
海外のプロジェクトでは特に、“Why now?” がすべての議論の中心にあります。
だから、改善したいなら、
- なぜ今必要なのか
- 何が起きているのか
- 放置した場合のコストは何か
- 解決したらどれくらいの価値が生まれるのか
これらを言語化しない限り、絶対に通らない。
逆に言えば、本質的な「なぜ」を説明できれば、チームもマネージャーもサポートしてくれる。
このカルチャーに気づいたのが、海外エンジニアとしての大きなターニングポイントでした。
チームの“怖い”を“戦略”に変えていく
レガシーシステムの改善に取り組もうとしても、最初の壁は技術より 「人の恐怖心」 でした。
海外のチームでも、日本と変わらず“触ると壊れる”“誰かに怒られるかも”という心理は必ずあります。
むしろ文化の違いがある分、余計に慎重になることも多い。
しかし、僕はそこで気づいたんです。
「恐怖を否定しても意味がない。
この恐怖を“戦略的な最適化”という武器に変換すればいい」
そこから僕のアプローチは大きく変わりました。
● まずは“安全に話せる場”を作った
エンジニアとして改善を進めるには、技術力よりもまず 心理的安全性 が必要。
そのために行ったのが、カジュアルな問題共有セッションでした。
と言っても大げさなものではなく、
「このコード怖くない？」くらいのノリで始める小さな場。
- コードレビューで感じる不安
- 触りたくない理由
- なぜ改善が進まないのか
- どこの構造が特に不気味か
- どこに“地雷”が埋まっているのか
これをワイワイ話すだけ。
でも、この雑談のような時間が圧倒的に効きました。
みんな、本当に不安を抱えていたんです。
“I want to improve it, but I don’t know where to start.”
“We get blamed if something breaks.”
“We don’t have proper tests. How can I feel safe?”
この“本音”が共有された瞬間、チームはようやく同じ方向を向き始めました。
● 次にやったのは“恐怖の見える化”
恐怖って目に見えないから、議論が感情論になりやすい。
だから僕はチームで Fear Mapping（恐怖のマッピング） を作りました。
やり方は簡単です。
- レガシーシステムのモジュールを一覧化
- 各モジュールに対する“不安レベル”を1〜5で投票
- 「なぜ怖いのか」「壊れやすい理由」を書き出す
- 台帳のように見える化する
すると、あることが見えてきました。
● みんなが“理由もなく怖がっている”部分が多い
ただ過去に誰かが失敗した、とか
構造が複雑に見える、というだけで触っていない。
● 本当に危険な部分は、実は限定的だった
話してみると「そこはテストがあるから大丈夫じゃない？」という部分も多かった。
● “触らないことのリスク”が炙り出された
放置している間にビジネス要件が変わり、後で大炎上する可能性が高い領域もあった。
この “見える化” によって、恐怖は“曖昧な感情”から“分析可能なデータ”に変わりました。
● “小さな勝利”を積み上げる戦略へ
恐怖をデータ化した後にやったのが、
「Small Win Strategy（小さな勝利の積み上げ戦略）」 です。
海外のチーム文化では、
“とりあえず大規模リファクタリングしよう！”という提案は通りません。
理由はシンプルで、投資収益が読めないから。
だからチームでこう決めました。
● 難易度の低い改善から着手
- コードの命名整理
- 不要なデッドコード削除
- ログの改善
- 極一部のMVVMのバインディング修正
● 成果がすぐに見える改善に限定
- ビルド時間の短縮
- UIレスポンスの改善
- 落ちていたテストを復活
● “壊さない成功体験”を共有する
成功した時は必ず Slack で共有。そのたびにチームの空気が少しずつ明るくなっていく。
まるでレガシーの暗闇に、小さな光を灯していくような感覚。
これが効果絶大でした。
● チームのマインドが変わった瞬間
ある日、チームの一人がこんなことを言ったんです。
“Hey, why don’t we modernize this part as well?”
（この部分も改善してみない？）
その一言で、僕は鳥肌が立ちました。
なぜなら、それまでは誰も“改善しよう”なんて言わなかったから。
ここで気づいたんです。
マインドが恐怖から最適化へシフトした瞬間は
「改善したい」という言葉が自然に出る瞬間だ
小さな勝利の積み重ねで、
“レガシーは怖い” → “レガシーを改善することが当たり前”
に変わっていった。
改善の提案が阻まれなくなり、レビューでも
- “Nice improvement!”
- “This makes sense.”
- “We should continue this approach.”
とポジティブな言葉が増えていく。
これは、技術的な変化ではなく、文化的な変化でした。
● ステークホルダーを巻き込む“Why の説明”も強化した
マインドが整ってくると、次は会社を動かすフェーズです。
この段階で重要なのは、ロジカルな“Why”の説明。
海外の企業ではこれは必須です。
そこでチームで “Why ページ” を作りました。
- 現状の技術負債の一覧
- どれだけ時間やコストが無駄になっているか
- 小さな改善の実績
- 改善後に得られたメリット
- “壊す恐怖”がどれだけ軽減したか
- 今後改善すべきポイントとそのROI
これがあると、ステークホルダーとの会議が一気に進む。
「改善＝コスト」ではなく
「改善＝価値と未来への投資」
として理解され始めるんです。
● チームが自走し始めたところで、次の大きな波へ
こうして、
恐怖から小さな成功体験へ、
そこから戦略的最適化へと進んだチームは、
次に “もっと大きな改善” を議論し始めます。
- UIのモダナイズ
- 非同期化によるレスポンス向上
- テスト自動化の導入
- ビルドパイプライン刷新
- 技術負債の集中解消期間の設定
ここからは、「転」に続きます。
いよいよ改善が“チーム文化”として根付くフェーズです。
改善が“イベント”ではなく“文化”になった日
小さな成功体験を積み重ね、チームが改善に前向きになり、
ステークホルダーも理解を示し始めた頃……
ある日、僕は「あ、これは文化になったな」と思う出来事に遭遇しました。
いつものように朝のスタンドアップで報告をしていたとき、
チームの一人が何気なくこんなことを言ったんです。
“I refactored the binding for that view last night.
It was messy, so I made it cleaner.”
（昨日あのビューのバインディングをリファクタしたよ。汚かったから、きれいにしておいた。）
誰に言われたわけでもない。
タスクにも書かれていない。
ただ、良くしたかったから、改善した。
この「自然発生的な改善」こそ、
改善が“文化”として定着した瞬間でした。
技術負債を返す行動が、“仕事の一部”として自然と組み込まれている。
誰かが改善の口火を切らなくても、メンバー自身が必要性を感じて動いていく。
ここまで来たら、チームはもう強い。
● チームの“改善力”が進化すると、次に数字が変わる
改善が文化になると、面白いように数字が変わり始めます。
これは海外企業で特に重視される部分で、
“数字で語れない改善は、改善ではない”と言われるほど。
改善文化が根付いたあと、僕たちのチームに起きた変化はこんな感じでした。
● ① バグ報告数が激減
それまで毎スプリント10件以上来ていたバグが、
2〜3件にまで落ち込みました。
理由はシンプルで、
コードが理解しやすくなったから、壊れにくくなった。
● ② デリバリースピードが約30%向上
改善前は、ちょっとした UI 修正でも
「触ったら壊れるかも」「影響が読めない」という理由で
時間がかかっていた。
でも改善後は、コードの見通しが良くなり、
自信を持って変更できるようになった。
● ③ テストカバレッジが自然に上がった
「安心して触れない」領域にテストを書き足す人が増え、
気づけばテストカバレッジが20%→45%へ。
テストを書く行為が“義務”ではなく、
“安心して開発するための手段” として理解されたからです。
● ④ レビュー時間が短縮
改善前はレビューで「ここは怖い」「このモジュールは危険」
と議論が長引いていたのが……
改善後は、
“Nice refactor!”
“I can follow the logic easily.”
と、ポジティブな短いやり取りに変化。
レビュー時間が短縮され、
チーム全体のスループットが向上しました。
● ステークホルダーが“価値”を理解し始める
数字として成果が出ると、
ステークホルダーが反応し始めます。
あるミーティングで、
プロダクトオーナーがこんなことを言いました。
“We should seriously invest in the modernization plan.
The ROI is clear now.”
（モダナイズ計画に本格投資すべきだ。
投資対効果がはっきり見えてきた。）
以前は、
- 「改善より新機能が優先」
- 「リファクタリングに時間を使う余裕はない」
- 「現状維持でなんとかしてくれ」
こんな雰囲気だったのに、
成果を数字で見せた途端、
“改善＝無駄”から“改善＝価値を生む投資”へと認識が逆転した。
これぞまさに “Why が伝わった瞬間” です。
● 改善文化が広がると、チーム間の連携まで変わる
面白いのは、改善文化の波が 他チームにまで広がっていくことです。
僕たちのチームがやっていた
- Fear Mapping
- Small Win Strategy
- Why ページ
- 自然発生的改善の共有
これらを見た他チームが
“それ、うちでもやりたい”
と言い始めました。
こうなるともう、改善は「個々の取り組み」ではなく、
組織全体のムーブメント になります。
海外企業は、この“ムーブメント”が本当に強い。
一度流行すると一気に広がる。
改善がファッションのように浸透していく。
● ここで、意外な課題が出てくる
改善文化が成熟してくると、
次のフェーズで必ず発生する課題があります。
それは……
改善が“目的化”すること。
つまり、
- 「改善しなきゃ」という焦り
- 「完璧なコードにしたい」という潔癖
- 過剰なリファクタリング
- ROI を考えない修正
こういう“改善の暴走”が起き始めるんです。
ここで重要なのが、
改善は“価値を生むための手段”であり
目的ではないという原則。
実はここからが、
海外エンジニアとして最も学びが深かったフェーズでした。
● 改善の“暴走”を防ぐために導入した2つのルール
改善が文化として根付くと、
逆に“やりすぎ”が問題になります。
そこで僕たちは次の2つのルールを導入しました。
① 改善には必ず「10分ルール」
改善したい部分を見つけたら、まず
「10分だけ触って判断する」
というルール。
- 10分で終わりそうなら、その場で直す
- 10分で終わらないなら、タスクとして起票する
- 起票した改善タスクには必ず ROI を書く
この「10分ルール」はシンプルだけど超効果的。
改善の勢いを止めずに、
暴走だけ防げる。
② 改善タスクには“価値タグ”をつける
改善タスクに、「なぜそれをするのか」をタグ付けします。
#RiskReduction（リスク削減）#Performance（性能向上）#Maintainability（保守性向上）#DeveloperExperience（開発体験向上）
これをつけるだけで、
改善が価値につながることが一目で分かる。
● いよいよ本丸：モダナイズ計画が始まる
改善文化が成熟し、数字も成果として出始め、
ステークホルダーも価値を理解し、
改善が暴走せず適切に管理できる状態になった。
このときようやく、
会社から正式承認がおりたんです。
“Let’s modernize the whole system.”
（システム全体のモダナイズに着手しよう）
ここから、“本当の戦い”が始まります。
- UI の再構築
- MVVM の刷新
- 非同期アーキテクチャの導入
- テスト自動化
- ビルドパイプラインの全面リプレイス
- 技術負債の大規模解消
ここまで来たプロジェクトは、
もはや「改善」ではなく “再創造” の段階に入っていました。
そして……
次の「結」では、
そこから見えた世界、そして得られた人生術・キャリアの教訓 をまとめます。
改善の先にあったのは、コードではなく“自分の生き方の変化”だった
レガシー改善の旅を振り返ると、
実は一番変わったのは コードでもシステムでもない。
変わったのは、
僕自身の考え方、生き方、そしてキャリアの軸でした。
海外チームでレガシー改善を推進するのは、
技術力だけでは絶対に成功しません。
必要なのは、
- 人を動かす力
- 価値を説明する力
- 不安や恐怖に向き合う力
- そして「小さく始める勇気」
これらは、そのまま人生のスキルでもあることに後で気づきました。
ここでは、読者のあなたに「読んでよかった」と思ってもらえるよう、
僕が得た人生術・キャリア戦略をまとめていきます。
● ① “恐怖は倒すものじゃなく、利用するもの”
改善を進める中で、
チームの一番の壁は「恐怖心」でした。
- 壊したらどうしよう
- 過去の失敗の記憶
- 文書化されてないコードへの不安
- 責任を負いたくない心理
これは人生でも同じで、
“初めてのことには必ず怖さがつきもの”です。
でも僕が学んだのは、
恐怖は消そうとすると強くなる。
見える化し、データ化すると味方になる。
コードの恐怖を
「Fear Mapping」
として見える化したように、
人生の不安も紙に書いてみると、驚くほど冷静になれます。
例えば、
- 転職したいけど怖い
- 新しい技術に挑戦したいけど自信がない
- 英語で発言ができない
これも、紙に書いて 分解 → 可視化 → 小さく対応
すれば、改善と同じように前に進める。
改善とは、
恐怖を道しるべに変えていくプロセスなんだと実感しました。
● ② “10分触ってみる”は人生でも最強の戦略
僕がチームに導入して一番効果があったルール。
「まず10分触る」
大事なのは完璧を目指すことじゃなく、
“始める”こと。
これは人生レベルで強烈に効きます。
- 新しい技術の勉強 → 10分だけ触る
- 英語のリスニング → 10分だけ聞く
- 片付け → 10分だけ
- 運動 → 10分だけ
すると不思議なことに、
10分で終わることはほとんどなく、
そのまま続けてしまう。
改善の成功の裏側には、
10分の積み重ねがある。
人生の大きな成功も、
10分の習慣から始まっています。
● ③ “小さな勝利”を積む人は、どこに行っても強い
レガシー改善を成功させたのは、
大規模改革ではなく “Small Win Strategy” でした。
そして人生も同じ。
- 小さな改善
- 小さな挑戦
- 小さな成長
- 小さな自信
- 小さな成功
これらを積み重ねられる人は、
どんな環境でも成長していきます。
逆に、大きな成功をいきなり狙う人は失敗しやすい。
僕が海外で働き始めたときも、
英語が全然聞き取れず心が折れかけたけれど、
毎日 “5分だけ英語ニュース” を続けたら急に聞こえる日が来た。
改善とは 積み重ねのアート。
人生も同じ。
● ④ “説明できる人”は、技術より価値が高い
改善を推進するために必要だったのは、
Why を説明する力。
これは海外では本当に重要で、
技術力よりも評価されることも多い。
- なぜ改善が必要なのか
- どんな価値があるのか
- ROI はどうなるのか
- なぜ今やるのか
- やらない場合のリスクは何か
- 他の選択肢は？
- 小さな勝利は何を示しているのか
これを数字とストーリーで説明できる人は、
自然とプロジェクトを動かす側に回る。
気づけば僕も、
“ただのエンジニア”から
“改善を通じて価値を作る人” として見られるようになっていました。
つまり、
技術は人を動かさない。
説明が人を動かす。
これがキャリアにおける大きな武器になる。
● ⑤ 改善は「チームの幸せ」を生む
改善の最終的なインパクトはコードでも数字でもなく、
チームの空気が明るくなることでした。
- レビューが前向きになる
- 会議が建設的になる
- バグが減ってストレスが軽減
- 残業が減る
- 自信がつく
- チーム間の信頼が増す
改善はチームの文化を健康にします。
海外チームでこの変化を感じたとき、
僕は心から思ったんです。
改善って、結局はみんなを幸せにするための行為なんだなと。
● ⑥ 改善が教えてくれた究極の人生術
そして最後に、
改善のプロセスを通じて僕が得た最も大きな学びはこれです。
“人生もコードも、リファクタし続ければ必ず良くなる”
- 間違ってもいい
- やり直していい
- 小さく直していい
- 怖くてもいい
- 不安でもいい
- 時間がかかってもいい
- 完璧じゃなくていい
大事なのは、
今日より1%良くすること。
これを積み重ねると、
気づいたら自分でも驚くほど成長してる。
海外で働いて痛感したのは、
成長とは“勇気”ではなく、“習慣”の問題だということ。
改善の旅は、
僕に技術以上のものをくれました。
それは 心の持ち方と、生き方そのもの です。
■ まとめ：読者へのメッセージ
ここまで読んでくれたあなたに伝えたい最も大事なことは……
レガシーなのはコードではなく、
行動しない“心”のほうだ。
でも行動は、
10分あれば始められる。
改善の旅は、誰でも今日から始められます。
完璧じゃなくていい。
小さな一歩でいい。
その一歩が、
未来のあなたを劇的に変えるから。
コメント