「大改修」という名の罠から抜け出せ。海外の現場で僕が学んだ、劇的な変化を生む「1%の法則」

海外でC# / WPFエンジニアとしてコードを書き、設計に頭を悩ませる日々を送っている僕から、これから世界に飛び出そうとしている皆さんに伝えたいことがあります。

技術力も大事ですが、それ以上に僕たちの「エンジニア人生」を左右するのは、実はもっと地味で、それでいて強力な「マインドセット」の差だったりします。今回は、僕が海外の現場で手痛い失敗を繰り返しながら学んだ、ある「法則」についてお話しします。

1. なぜ僕たちは「一発逆転」を夢見て、その果てに自爆するのか

どうも。海外でC# / WPFをメインに、デスクトップアプリの設計開発をしているエンジニアです。

皆さんは今、自分の関わっているプロジェクトのコードを見て、「あー、これ全部作り直したい！」って叫びたくなることはありませんか？ 僕は、何度もあります。というか、海外に拠点を移して最初の数年は、毎日そう思っていました。

「このMVVMの設計、誰が考えたんだ？」「XAMLが数千行に膨れ上がって、もはや魔窟じゃないか」「依存関係がスパゲッティすぎて、1箇所直すと3箇所壊れる……」。そんな現実に直面した時、僕たちエンジニアは、ある「甘い誘惑」に駆られます。

それが、「グランド・オーバーホール（大改修）」という名の幻想です。

「一発逆転」を夢見るエンジニアの性

「今のクソコードを修正し続けるのは時間の無駄だ。いっそのこと、最新のフレームワークを導入して、アーキテクチャを一新して、完璧なクリーンコードで書き直そう。そうすれば、開発速度も上がるし、バグも減る。これこそが、チームにとっても会社にとっても最善の道だ！」

……これ、聞いたことありませんか？ あるいは、自分で提案したことは？

僕が海外のシビアな現場で学んだ最初の教訓は、この「一発逆転の思考」こそが、実はチームを崩壊させ、エンジニア自身の精神をすり減らす最大の原因だということでした。

なぜ、僕たちはこれほどまでに大改修に惹かれるんでしょうね。おそらくそれは、僕たちが「ヒーロー」になりたいからです。散らかった現場を一瞬で浄化し、エレガントなコードで世界を救う。そんな物語を信じたい。でも、現実はもっと泥臭いんです。

華やかな計画の裏に潜む「疲弊」の正体

僕が以前参加していたあるプロジェクトの話をしましょう。そのチームは、長年メンテナンスされてきた複雑なWPFアプリケーションの刷新を計画していました。バックエンドはレガシーなC#、フロントのXAMLはコピペの嵐。開発効率は目に見えて落ちていました。

そこでリーダーは決断しました。「向こう3ヶ月、すべての新機能をストップし、アーキテクチャの全面刷新を行う」と。最初はみんな盛り上がりました。新しいDIコンテナを導入し、Rxを駆使してリアクティブな設計にし、テストコードも100%カバーする。エンジニアにとっては夢のような時間です。

ところが、1ヶ月が過ぎた頃から空気が変わり始めました。

  • 仕様の迷宮： レガシーコードの仕様が実は誰もわかっておらず、再現に膨大な時間がかかる。
  • ビジネスの介入： サイドから「どうしてもこの修正だけは先にやってくれ」という割り込みが入る。
  • 設計の歪み： 新設計では表現しきれない特殊なユースケースが次々と発覚する。

結局、3ヶ月で終わるはずだったプロジェクトは半年を過ぎ、1年経っても終わりませんでした。メンバーは疲れ果て、一人、また一人と去っていきました。これが「大改修の罠」の正体です。

2. 海外チームで見つめた「完璧な計画」が失敗する構造的理由

海外で働いていると、同僚たちの多様なバックグラウンドに驚かされますが、共通しているのは「変化に対する適応力の高さ」です。一方で、日本人エンジニア（かつての僕も含めて）は、どこか「完璧な設計図があれば、すべてはうまくいく」と信じすぎている節がある気がします。

大改修が失敗する理由は、エンジニアリングの観点から見ても非常に論理的です。

  1. フィードバックループの遮断： 作り直している間、コードに対する現実の検証が行われません。数ヶ月後に完成しても、その頃には市場の要求が変わっているか、あるいは想定外のバグが山積みになっています。
  2. 認知負荷の爆発： すべてを一度に変えようとすると、脳が処理すべき情報量が限界を超えます。結果として、細かい部分の詰めが甘くなり、レガシーコードよりもタチの悪い「新しいクソコード」を生み出すことになります。
  3. モチベーションの枯渇： 人間、達成感がないと続きません。大きな変化はゴールが遠すぎて、途中で「自分は何のためにこれをやっているんだっけ？」という虚無感に襲われます。

ボイスカウトの教えと「1%」の萌芽

そんな絶望的な状況で、僕にある一人のベテランエンジニア、アレックスが教えてくれたのが**「ボーイスカウト・ルール（Boy Scout Rule）」**でした。「キャンプ場は、来た時よりも綺麗にして去る」という、シンプル極まりない教えです。

彼は、どれほど緊急のバグ修正であっても、必ず「ついでに一つだけ」何かを直していました。全く意味のわからない変数名を直す、巨大すぎるメソッドから3行だけプライベートメソッドを切り出す。

それは、大改修に比べればあまりにも地味で、価値がないように見える作業でした。

3. 不完全なコードを愛し、微調整を積み上げる勇気

僕がアレックスに倣って「小さな改善」を始めると、同僚からは最初、少し冷ややかな目で見られました。

「そんな細かいリネームなんていいから、早く新機能のPR（プルリクエスト）を投げてくれよ」

しかし、僕は続けました。PRを出すたびに、メインの修正とは別に「ついでに直した1%の改善」を含めるようにしたのです。

C#

// Before: 意味の曖昧な変数名とロジック
var result = Execute();
if (x != null && x.IsActive) { ... }

// After: 1%の改善を適用
var customerOrderResult = ExecuteOrderProcessing();
if (ShouldProcess(customer)) { ... }

こうした小さな修正は、レビューの負担も最小限です。そして、この「1%の積み重ね」が、3ヶ月経った頃に驚くべき変化をもたらし始めました。

霧が晴れるように、コードが「話しかけてくる」感覚

ある日、かつて「地雷原」だと思っていたモジュールの調査をしていた時、ふと気がつきました。コードが以前よりずっと読みやすくなっている。一箇所だけなら微差でしかない改善も、100箇所積み重なれば、それはもはや「別のコード」なんです。

しかも、大改修とは違って、この変化は「無痛」でした。大きなバグを出すこともなく、開発を止めることもなく、システムの品質が劇的に向上していた。

この時、僕は確信しました。海外の荒波のような現場で生き残り、質の高い仕事を続けるために必要なのは、天才的な設計能力ではなく、**「今日、目の前のコードを1%だけマシにする執念」**なのだと。

4. メンタルを「非同期（Async）」にアップデートする

実は、この「1%の法則」が本当に真価を発揮するのは、コードの領域よりも、もっと泥臭い「生き残り術」や「メンタル管理」の領域だったりします。

海外で働き始めて最初の一年、僕はネイティブたちの高速な議論に追いつけず、隣の席の天才エンジニアと自分を比較しては絶望していました。そこでまた「自分自身の大改修」を試みようとしました。「来月には完璧な英語を話し、全技術をマスターしてやる！」と。でも、そんな無理な計画はすぐにフリーズしてしまいます。

そこで僕は、自分自身にも「1%の改善」を適用することにしました。

  • 会議で一つだけ、相槌以外の発言をしてみる。
  • ドキュメントの誤字を一つだけ直してみる。
  • 新しいC#の構文（例えば、file-scoped namespacesなど）を一つだけ自分のコードに取り入れてみる。

人生を「同期（Synchronous）」に全部変えようとするのではなく、メインスレッド（日々の業務）は止めずに、バックグラウンドで1%ずつの改善を**「非同期（Async）」**に走らせておく。そう思えるだけで、あんなに苦しかった周囲との比較が消えていきました。

5. 未来の自分へ贈る「複利」のギフト

最後に、皆さんに一つ面白い算数の話をさせてください。

「毎日1%だけ自分（あるいはコード）を改善する」と、1年後にはどうなっていると思いますか？

1.01365≈37.78

なんと、1年前の自分よりも約38倍も成長している計算になります。逆に、毎日1%ずつサボったり、コードを腐らせたりするとどうなるか。

0.99365≈0.025

ほぼゼロ、価値のない人間やプロダクトになってしまいます。

エンジニアの「徳」を積むということ

僕はこれを、密かにエンジニアとしての「徳」を積む作業だと呼んでいます。誰も見ていないところで、将来そのコードを読む誰かのために、1行だけ読みやすくしておく。この「徳」が溜まっていくと、不思議と運も向いてきます。

海外の現場では、技術力と同じくらい「一緒に働きたいと思われるかどうか」が重要です。 「あいつがPRを投げると、なぜかコードが綺麗になる」「あいつと話すと、少しだけ前向きな気分になれる」 そう思われる存在になるための最短ルートが、この1%の法則なんです。

今日から始める小さな一歩

この記事を読み終わった後、あなたにやってほしい「1%の行動」があります。

  1. コードの中の「小さなゴミ」を一つ拾う： 今開いているプロジェクトで、変数名を一つだけ適切に変えてください。
  2. 自分のキャリアに「1%」の投資をする： 英語の技術記事を1段落だけ音読するか、新しいライブラリのREADMEを一行だけ読んでください。
  3. 「不完全な自分」にOKを出す： 100%の完成度を目指して動けなくなるより、1%の改善を365日続ける方が、エンジニアとしてはるかに遠くへ行けます。

大きな山を一気に登る必要はありません。足元の小石を一つどける。その繰り返しが、いつの間にかあなたを最高の景色が見える場所へと連れて行ってくれます。

いつか、世界のどこかの開発現場で、「1%の法則を読んで、今日ここまで来ました」というあなたに会えるのを、楽しみにしています。その時は、最高に美味しいコーヒーを飲みながら、お互いの泥臭い1%の話で盛り上がりましょう！

コメント

タイトルとURLをコピーしました