見えない殺人者 —— なぜ「優秀なエンジニア」ほど、悪い文化の囚人になるのか？
こんにちは。海外のとある都市で、今日も今日とてVisual Studioと睨めっこしているC#エンジニアです。窓の外は異国の風景ですが、画面の中にあるXAMLの記述は世界共通。そう思うと、少しだけホームシックが和らぐ気がします。
さて、今日は少し技術的でありながら、同時に私たちの「働き方」や「生き方」にも通じる、少し重たくて、でも絶対に知っておくべき話をしたいと思います。
皆さんは、「エンジニアの夢を殺すもの」と聞いて何を思い浮かべますか？
終わりのない仕様変更？ レガシーすぎるコード？ それとも、話の通じないプロジェクトマネージャーでしょうか？
確かにそれらも厄介です。でも、私のこれまでの海外での開発経験——特に、言葉の壁や文化の違いがある中で必死にサバイブしてきた経験——から言わせてもらえば、真の殺人者はもっと静かで、もっと巧妙です。
それは、**「悪いコード」ではなく、「悪い文化」**です。
もっと具体的に言うなら、**「進捗が出ているように見える」という幻想（The Illusion of Progress）**です。
私たちはエンジニアです。問題を解決することが仕事です。目の前にバグがあれば潰したくなるし、機能要望があれば実装したくなります。特に海外で働く場合、ビザの問題や契約のプレッシャーがあり、「自分には価値がある」ということを一刻も早く証明したいという焦りが常にあります。
「Hey, look at this! I fixed it!（見てよ、直したよ！）」
そう言ってプルリクエストを送り、チケットを「Done」に移動させる。Jiraのバーンダウンチャートが綺麗な下降線を描く。朝のスタンドアップミーティングで「昨日はこれだけ進みました」と報告し、チームメンバーから「Good job」と言われる。
この瞬間、脳内にはドーパミンが溢れます。「私は進んでいる」「プロジェクトは動いている」「私たちは生産的だ」。そう信じ込めます。
しかし、ここに罠があります。
もし、その「素早い修正」が、長期的なアーキテクチャを無視した継ぎ接ぎだとしたら？
もし、その「新機能の実装」が、既存のテストカバレッジを低下させ、将来的な変更コストを倍増させているとしたら？
もし、私たちが感じている「スピード感」が、実は崖に向かってアクセルを踏んでいるだけのスピードだとしたら？
これが「進捗の幻想」です。
私が日本で働いていた頃も、そして海外に出てからも、多くのプロジェクトがこの罠にかかるのを見てきました。
エンジニアが怠惰だから失敗するのではありません。むしろ逆です。エンジニアが勤勉で、責任感が強く、役に立ちたいと願うからこそ、この罠にハマるのです。
私たちは、目の前のタスクを消化することに夢中になるあまり、そのタスクが「本当に正しい方向に向かっているか」を問うことを忘れてしまいます。
特にWPF（Windows Presentation Foundation）のような、設計の自由度が高く、かつ複雑なフレームワークを扱っていると、この傾向は顕著に現れます。MVVM（Model-View-ViewModel）パターンを厳格に守るよりも、コードビハインドにロジックを書いたほうが、その瞬間は「速い」からです。
「とりあえず動くからいいや」
「来週のリファクタリング期間に直そう」
「お客様がデモを見たがっているから、今はこれでいこう」
これらの言葉は、まるで悪魔の囁きのように聞こえますが、実際はもっとたちが悪い。なぜなら、これらの言葉は**「ビジネスへの貢献」や「柔軟な対応」という、正義の顔をして現れるから**です。
私はこれを**「アンチパターン（Anti-Pattern）」**と呼びます。
一般的にソフトウェア開発の文脈で使われるこの言葉ですが、私はこれを単なるコードの話に留めるべきではないと考えています。これは、私たちの思考の癖であり、組織の力学であり、そして時として人生の落とし穴でもあります。
アンチパターンの恐ろしいところは、それが「一見すると良さそうなアイデア」に見えることです。明らかに悪いアイデアなら、誰も採用しません。誰も while(true) で無限ループするコードを意図的に書いたりしません。
アンチパターンは、その時点では論理的で、効率的で、賢い選択に見えるのです。だからこそ、私たちは無自覚にその罠に足を踏み入れます。
海外で働くようになって、私はこの「無自覚の罠」に対してより敏感になりました。なぜなら、異文化の中で働くということは、暗黙の了解が通じない世界で生きるということであり、すべての判断の背景にある「なぜ？」を言語化し続けなければならないからです。
「なぜ、その修正方法はダメなのか？」
「なぜ、今すぐ動くものを作ることよりも、設計に時間をかけるべきなのか？」
これを英語で説明し、チームを説得するのは骨が折れます。だからこそ、安易な道——つまり、アンチパターン——に逃げたくなる誘惑は強烈です。
しかし、そこで踏み止まれるかどうかが、単なる「コーダー」で終わるか、尊敬される「エンジニア」になれるかの分水嶺だと私は確信しています。
このブログシリーズでは、私がC#エンジニアとして直面してきた具体的な「技術的アンチパターン」を入り口にしつつ、そこから見えてくる「組織やキャリアのアンチパターン」について深掘りしていきたいと思います。
これから海外を目指すエンジニアの方、あるいは今まさに現場で「なんとなくうまくいっていない」閉塞感を感じている方へ。
この話は、C#やWPFの専門知識がなくても通じる普遍的な「仕事のOS」の話です。
まずは、「アンチパターン」とは一体何なのか。なぜ私たちは、それが毒だと知りつつも皿まで舐めてしまうのか。
次章では、そのメカニズムを解剖していきます。一見すると退屈な定義の話に見えるかもしれませんが、敵を知らなければ戦えません。そして、その敵は、驚くほど私たちの「良心」に似た顔をしているのです。
「アンチパターン」の正体 —— 効率化という仮面を被ったシステム崩壊の序曲
前回は、「進捗の幻想」がいかにエンジニアのキャリアを蝕むか、という少し怖い話をしました。今回は、その幻想を生み出す元凶である「アンチパターン」の正体を、顕微鏡で覗くように解剖していきたいと思います。
ここ海外のテックシーンでも、”Anti-Pattern” という言葉は日常的に飛び交います。しかし、多くの人がその本当の意味を誤解しています。「バグ」や「汚いコード」と同義だと思っている人があまりに多いのです。
声を大にして言いたいのは、**「アンチパターンは、単なる『悪いコード』ではない」**ということです。
もっとタチが悪いのです。アンチパターンとは、**「特定の状況下において、一見すると適切な解決策に見えるが、長期的には事態を悪化させる典型的なパターン」**のことを指します。
ここでのキーワードは「一見すると適切に見える」という点です。これが、私たちが何度も何度も同じ過ちを繰り返す理由です。それは毒入りのリンゴではなく、砂糖をまぶした揚げパンのようなものです。その瞬間は美味しくて、エネルギーになり、お腹も満たされる。でも、毎日そればかり食べていたら、確実に体（システム）を壊します。
なぜ私たちは「効率化」という名の毒を飲むのか？
C#とWPFを扱う現場、特にここ海外のスタートアップやアジャイルな現場では、スピードが命です。「Move fast and break things（素早く行動し破壊せよ）」という有名な標語がありますが、これを「コードの品質を犠牲にしてでも機能を出せ」と解釈すると、地獄への特急券になります。
なぜ優秀なエンジニアでもこの罠にハマるのか。理由は大きく分けて3つあります。
- 認知的容易性（Cognitive Ease）：脳は楽をしたがります。複雑なアーキテクチャを設計するよりも、目の前にある既存のクラスにメソッドを一つ追加するほうが、脳のカロリー消費は少なくて済みます。「とりあえずここに書いておけば動く」という誘惑は、生物学的な本能に近いものです。
- 短期的報酬の優先（Hyperbolic Discounting）：人間は、将来得られる大きな利益（保守性の高いコード）よりも、今すぐ手に入る小さな利益（機能が動いた！という達成感）を過大評価します。特に、海外の成果主義的な環境では、今週のスプリントレビューで何を見せるかが評価に直結するため、このバイアスは強烈に働きます。
- コンテキストの欠如：「Best Practice（ベストプラクティス）」という言葉も危険です。GoogleやNetflixがやっているから、という理由でマイクロサービスを採用したり、複雑なデザインパターンを導入したりする。しかし、あなたのチームが3人で、モノリスなWPFアプリを作っているなら、それは「オーバースペック」という名のアンチパターンになります。
具体例：WPFにおける「Smart UI」という甘い罠
さて、ここで私の専門であるC# WPFの現場でよく見る、最もポピュラーで、かつ破壊的なアンチパターンを紹介しましょう。
**「Smart UI（賢すぎるユーザーインターフェース）」**アンチパターンです。
WPFには強力な機能があります。XAMLのコードビハインド（.xaml.cs）に、イベントハンドラをダブルクリック一つで生成できる機能です。
例えば、「ユーザー一覧を取得してグリッドに表示する」というタスクがあったとしましょう。
【アンチパターンへの入り口】
あなたは考えます。「簡単だ。ボタンのクリックイベントの中に、SqlConnectionを開いて、SQLを投げて、結果をDataGrid.ItemsSourceに代入すればいい」
C#
// 【悪い例】Smart UI アンチパターン
// MainWindow.xaml.cs に全てのロジックを詰め込む
private void ShowUsersButton_Click(object sender, RoutedEventArgs e)
{
using (var conn = new SqlConnection("...ConnectionString..."))
{
conn.Open();
var cmd = new SqlCommand("SELECT * FROM Users", conn);
// ... データ取得処理 ...
UserGrid.ItemsSource = dataTable.DefaultView;
}
}
どうですか？ たった5分で実装できます。コード量は少なく、動作は高速。上司に見せれば「Wow, that was fast!（早いね！）」と褒められるでしょう。これが「一見すると適切な解決策」に見える瞬間です。
しかし、これがプロジェクトの初期段階だけで終わればいいのですが、現実はそう甘くありません。
【崩壊の序曲】
1ヶ月後、「ユーザー一覧にフィルタ機能を追加して」と言われます。あなたは同じクリックイベントの中に if 文を追加します。
3ヶ月後、「プレミアム会員だけ文字色を赤にして」と言われます。あなたはXAMLではなく、C#コードの中で行ごとの色変更ロジックをループで回して書きます。
半年後、「このアプリ、Web版も作るからロジックを共有したいんだけど」と言われます。
ここで詰みます。
あなたのビジネスロジックは、UI（ボタンのクリックイベント）という檻の中に幽閉されています。再利用は不可能です。テストコードを書こうにも、UIのインスタンスがないとロジックが走りません。
この「Smart UI」は、初期開発のスピード（効率）と引き換えに、将来の変更耐性とテスト容易性を完全に殺してしまったのです。
本来であれば、MVVM (Model-View-ViewModel) パターンを採用し、ViewModel にロジックを切り出し、ICommand と Data Binding を使うべきでした。初期実装には20分かかったかもしれませんが、その15分の差が、半年後のあなたの週末を救うことになったはずです。
海外現場での「言葉の壁」が生むアンチパターン
さらに、私が海外で働いていて痛感するのは、**「コミュニケーション・アンチパターン」**の恐ろしさです。
技術的なアンチパターンはリファクタリングで直せますが、組織的なアンチパターンはもっと根が深い。
例えば、**「Mushroom Management（キノコ栽培マネジメント）」**という言葉をご存知でしょうか？
「暗闇の中に置いておき（情報を与えない）、時々肥料（クソ）をかける」ことからそう呼ばれています。
エンジニアに対して、ビジネスの背景や「なぜこれを作るのか」を説明せず、ただ仕様書だけを渡して「これを作れ」と指示するスタイルです。
言葉の壁がある外国人エンジニア（私のような立場）は、この状況に陥りやすいです。
「英語で詳しく聞き返すのが面倒だから、とりあえず言われた通り作ろう」
「ミーティングで議論して変な顔をされるのが怖いから、Yesと言っておこう」
これが、先ほどの「Smart UI」のような技術的負債を加速させます。「なぜMVVMが必要なのか」を説明するコストを避けた結果、誰もメンテナンスできないスパゲッティコードが量産されるのです。
私はかつて、あるプロジェクトで「God Class（神クラス）」と呼ばれる、5000行を超える Utilities.cs をメンテナンスしたことがあります。
そこには、データベース接続から、ログ出力、さらには消費税計算ロジックまで、あらゆるものが static メソッドとして詰め込まれていました。
作ったのは、「とにかく仕事が速い」と評判だったシニアエンジニアでした。彼は間違いなく「進捗」を出していました。しかし、彼が去った後、そのコードは誰も触れない「聖域（触ると祟りがある場所）」となり、プロジェクトの足を引っ張り続けました。
彼は悪人だったのでしょうか？ いいえ、彼はきっと、その時々の要求に「最も効率的に」応えようとしただけなのです。それがアンチパターンだとは気づかずに。
承のまとめ
アンチパターンの正体は、**「局所最適化の積み重ねによる、全体崩壊」**です。
- 「今このクラスだけ直せばいい」
- 「今このチケットだけ消化すればいい」
- 「今の上司さえ納得させればいい」
この「今だけ、ここだけ」という思考こそが、アンチパターンを育てる肥料です。
C#やWPFのようなリッチなフレームワークは、できることが多い分、この「間違った近道」も無数に用意されています。
しかし、絶望する必要はありません。アンチパターンには名前があり、兆候があり、そして処方箋があります。
これらを知っているだけで、私たちは「進捗の幻想」から目を覚ますことができます。
次章「転」では、私が実際に体験した、あるWPFプロジェクトでの失敗談をお話しします。「神クラス」が生み出した一時的な英雄と、その後に訪れたチーム崩壊のリアルな記録です。
そこには、技術的な問題以上に、人間の心理やプライドが複雑に絡み合っていました。
WPF開発現場での実体験 —— 「神クラス」が生んだ一時的な英雄と、その後の地獄
「アンチパターン」の定義は分かりました。しかし、知識と実体験の間には深い溝があります。理論を知っていても、現場の熱狂的なスピード感、そして「このプロジェクトを成功させたい」という人間の強い欲求の前では、その知識は簡単に吹き飛びます。
今回は、私が海外のある金融テック企業で関わったWPFプロジェクトにおける、忘れられない「進捗の幻想」が崩壊した瞬間の話をしましょう。
英雄の誕生：進捗が生んだ「God ViewModel」
プロジェクトは、トレーダー向けのリアルタイムデータ可視化ツールをWPFで作り直すというものでした。アジャイル開発で、リリースまでの期間はわずか6ヶ月。
チームには「アレックス」というシニアエンジニアがいました。彼はC#の知識が豊富で、タイピングスピードが異常に速く、何よりも結果を出すのが早かった。
マネージャーは毎週のスタンドアップミーティングで、アレックスがどれだけ多くのチケットを「Done」にしたかを誇らしげに報告しました。私たちのバーンダウンチャートは、まさに理想的な右肩下がりを描き、チームの士気は最高潮でした。「私たちはいけてる」と誰もが信じていました。
しかし、アレックスの作業の裏側では、前回お話ししたアンチパターンが猛威を振るっていました。彼は、プロジェクトで最も重要な画面の ViewModel（仮に TradingDataViewModel とします）を、まるで宇宙の中心のように扱っていました。
- 全てのデータ取得処理: データベースからWeb API連携、果てはリアルタイムWebSocket処理まで、全てこの一つのクラスの中に集約。
- 全てのUI状態管理: アラートの色、ボタンの活性/非活性、ユーザー設定の保存。
- 悲劇の結合: MVVMパターンを建前上は使っていましたが、パフォーマンスを理由に、画面のインスタンスを無理やり
ViewModelに渡して、直接VisibilityやIsEnabledをC#コードから書き換えていました。
この TradingDataViewModel は瞬く間に肥大化し、最終的には7,000行を超えました。彼はこれを「効率化だ」と呼びました。
「別のクラスに分けるのは無駄だ。今はスピードが重要。必要なものは全てここにあるんだから、探す手間がないだろう？」
このロジックは、一見すると合理的です。デバッグも楽に感じます。なぜなら、全ての処理が一行のスタックトレースの中に収まっているからです。私たちは彼を「このプロジェクトのヒーロー」と呼びました。
しかし、私はそのコードを見て、悪寒が走っていました。C#の async/await が使われている場所では、async void が乱用され、例外がサイレントに飲み込まれていました。また、WPFのData Bindingも、複雑すぎて誰も仕組みを理解できないカスタムコンバーターで強引に処理されていました。技術的負債の金利は、すでに毎日複利で膨らんでいたのです。
ツイスト：小さなバグが世界を終わらせた日
プロジェクトは最終ストレッチに入りました。次の月曜日に、最重要ステークホルダーへの最終デモが控えていました。
その週の木曜日、マネージャーから「ごく小さな変更」が降ってきました。
「週末の市場で、新しい取引ルールが適用される。フロントエンドで表示する取引価格に、新しい手数料率（1.01%）を乗じる必要がある」
たった一行の計算式変更です。アレックスは、いつものように自信満々でした。
「5分で直せるよ。手数料計算ロジックは TradingDataViewModel の中にまとめてあるからね。」
彼は自信を持って1.01を掛けるコードを挿入し、自分のローカル環境で単体テストを走らせ、「Done」にチケットを移動させました。デモ前の金曜日、コードはQA環境にデプロイされました。
そして、地獄が始まりました。
- 予期せぬUIフリーズ: ユーザーが画面を起動して数分経つと、アプリケーション全体が完全にフリーズしました。
- データ競合: 変更とは全く関係のない、履歴データのグリッド表示がクラッシュしました。
- 沈黙の例外: 最も恐ろしいことに、クラッシュしてもエラーログが残りませんでした。なぜなら、手数料計算ロジックの中で、無関係のUI要素を更新しようとした際に発生した例外が、親の
async voidメソッドによってサイレントに握りつぶされていたからです。
「神クラス」は、単なる計算ミスを、システム全体を巻き込む**「連鎖的障害（Cascading Failure）」**へと変貌させてしまったのです。
地獄の週末と、アンチパターンが明かした真実
チームは週末、デモを控えて徹夜でバグの原因を追いました。
私が担当したのはクラッシュの原因特定です。結局、判明したのは、新しい手数料計算ロジックが、別のスレッドで動いていたはずの古いデータバインディング処理と共有のグローバル変数を間接的に更新してしまい、結果的にメインUIスレッドでデッドロックを引き起こしていた、という複雑すぎる原因でした。
原因の特定に丸30時間かかりました。
この時、誰もが悟りました。
私たちが信じてきた「進捗」は、実は「借金」だった。そして、この週末に支払う金利があまりにも高すぎたということに。
結局、デモは延期となり、アレックスは肉体的、精神的な限界を迎え、デモ延期の直後に「家族の事情」でチームを去りました。彼は、プロジェクトを爆速で推進した「英雄」として記憶されましたが、残されたのは、誰も手出しできない7,000行の技術的負債、そして疲弊したチームでした。
この経験は、海外で「結果を出さなければ」という焦燥感に駆られていた私にとって、強烈な学びとなりました。
真実のツイスト：
問題はアレックスのスキル不足ではなかった。彼は優秀すぎた。問題は、技術的負債を生み出すスピード（進捗）を称賛し、保守性やテスト容易性（価値）を軽視した組織文化にあったのです。
この「神クラス」は、彼一人が頑張って進捗を生み出すには最高の道具でしたが、チームが協力し、長期的に開発を続けるには最悪の構造でした。
海外で働くということは、成果を可視化することに強烈なプレッシャーがかかります。しかし、そのプレッシャーに負けて「一時的な英雄」になろうとすると、必ず、その代償をチーム全体が、そしてあなた自身が支払うことになります。
この地獄のような週末を経験したことで、私は「進捗の幻想」から完全に目を覚ましました。
私たちが真に目指すべきは、Jiraのチケットを閉じる速さではなく、**「変更に対してどれだけ柔軟に対応できるか」**という、真の持続可能な生産性だったのです。
次章「結」では、この失敗体験から得られた教訓を元に、私たちがどのようにこのアンチパターンから脱却し、エンジニアとして、そして一人のビジネスパーソンとして、真の「価値」を生み出せるようになるのか、その具体的なマインドセットと行動原則についてお話しします。
幻想からの脱却 —— 「進捗」ではなく「価値」を定義し直すためのマインドセット
あの地獄のような週末を経て、私たちのチームは変わりました。
「神クラス」を作ったアレックスが去った後、残された私たちは、焼け野原となったコードベースを前にして、一つの誓いを立てました。
**「二度と、見せかけのスピードに魂を売らない」**と。
これは単なる感情論ではありません。プロフェッショナルとして生き残るための、極めて冷徹で論理的な生存戦略への転換です。
今回のシリーズの締めくくりとして、私が海外の荒波の中で掴み取った、「進捗の幻想」から抜け出し、真のエンジニアリングを取り戻すための3つの指針をお伝えします。
1. 「完了（Done）」の定義を書き換える勇気
まず、私たちが最初に取り組んだのは、Jiraチケットにおける「Done」の定義の再構築です。
それまでは、「機能が動作し、QAチームがOKを出したらDone」でした。これが諸悪の根源でした。
私たちは、ここに以下の条件を必須として加えました。
- 単体テストが書かれていること（カバレッジ目標ではなく、重要なロジックが守られているか）
- SOLID原則に違反していないこと（特に単一責任の原則）
- 「ボーイスカウト・ルール」が適用されていること（来た時よりも少しだけコードを綺麗にして去る）
当然、初期のベロシティ（開発速度）は落ちました。マネージャーやビジネスサイドからは「なぜ急に遅くなったんだ？」と詰められました。
ここで必要なのが、「No」と言う勇気です。
海外で働いていて痛感するのは、「Yesマン」は決して信頼されないということです。
「できます（実は品質を犠牲にすれば）」という嘘の「Yes」は、最終的にビジネスを破壊します。
「できません。今の品質基準を守るためには、このスケジュールでは不可能です。ですが、機能を削れば可能です」という、代替案を伴う「No」こそが、プロフェッショナルの仕事です。
私は片言の英語で必死に説明しました。
「ソフトウェア開発は、借金をして家を買うのとは違う。汚いコードは、毎日利息が増え続けるクレジットカードのリボ払いのようなものだ。今払わないと、来月はもっと払うことになる。私たちは今、その利息を払っている最中なんだ」
この比喩（Financial Metaphor）は、経営陣に響きました。彼らはエンジニアリングは分からなくても、お金の話は分かるからです。
結果として、私たちは「見せかけの進捗」ではなく、「持続可能なペース」を手に入れました。
2. 「消防士」ではなく「庭師」になる
エンジニアは往々にして、トラブルを解決する「消防士」になりたがります。火消しは派手で、感謝され、ヒロイックだからです。アレックスはまさに最強の消防士でした。自分で火種を撒いていることに気づかずに。
しかし、C#やWPFのような、静的型付けで堅牢な設計が可能な言語を使う私たちが目指すべきは、**「庭師（Gardener）」**です。
庭師の仕事は地味です。
毎日水をやり、雑草を抜き、枝を剪定する。一日サボっても何も変わりませんが、一ヶ月サボれば庭は荒れ放題になります。
WPFにおける「MVVMパターンを守る」「XAMLにロジックを書かない」「依存性の注入（DI）を使う」といった行為は、すべてこの「毎日の水やり」です。
今日、あなたが書くその美しいインターフェース（Interface）定義は、半年後の誰か（あるいは自分）を救います。
今日、あなたがリファクタリングして分割したクラスは、将来の仕様変更を「悪夢」から「単純作業」に変えます。
私はチームメンバーにこう言い続けました。
「コードは『書く時間』よりも『読まれる時間』の方が圧倒的に長い。 未来の読者へのラブレターを書くつもりでコーディングしよう」
このマインドセットが定着してくると、不思議なことが起きます。
かつては「面倒くさい」と思われていたリファクタリングやテスト記述が、チーム内での「誇り」に変わったのです。
「見てくれ、このViewModel、依存関係が綺麗に整理されてテストしやすくなったよ」
そんな会話が日常になった時、私たちは「アンチパターン」の呪縛から解放されました。
3. 海外生活という「リファクタリング」
最後に、少しだけ視点を広げて、人生の話をさせてください。
「進捗の幻想」は、コードの中だけの話ではありません。
異国の地で暮らしていると、どうしても「結果」を急ぎたくなります。早く英語が話せるようになりたい、早く現地のコミュニティに馴染みたい、早く昇進したい。
その焦りから、安易な近道（日本人コミュニティだけに依存する、表面的なコミュニケーションで誤魔化す）を選んでしまう。これもまた、人生の「アンチパターン」です。
私が「神クラス」の崩壊から学んだ最大の教訓は、**「近道は、一番遠回りである」**という真理です。
良いコードを書くのに時間がかかるように、良いキャリアや、異文化での信頼関係を築くのにも時間はかかります。
一足飛びに「成功」を手に入れようとするのではなく、毎日コツコツと、自分自身のスキルや人間関係という「コードベース」をメンテナンスし続けること。
時には立ち止まって、自分の行動（実装）が正しい方向に向かっているか振り返る（コードレビューする）こと。
それが、結果として「最高のパフォーマンス」を生み出す唯一の方法なのだと、今では確信しています。
エンジニアという仕事の誇り
C#の生みの親であるアンダース・ヘルスバーグや、多くの偉大なエンジニアたちが築き上げてきたツールやフレームワークは、私たちに「正しく作る」ための力を与えてくれています。
Visual Studioの強力なリファクタリング機能も、ReSharperのようなツールも、すべては私たちが「庭師」として働くのを助けるためのものです。
だからこそ、その武器を使って「ゴミ」を作ってはいけません。
これから海外を目指す皆さん、あるいは今、現場で戦っている皆さん。
もしあなたが「進捗の罠」にハマりそうになったら、深呼吸をして、自分に問いかけてください。
「私は今、見せかけの進捗を作っているのか？ それとも、未来に残る価値を作っているのか？」
答えが後者であれば、どんなに歩みが遅くても、胸を張ってください。
その一歩は、確実に「Done」に向かっています。そして、そんなエンジニアこそが、世界中のどこに行っても、真に必要とされる人材なのです。
長いブログにお付き合いいただき、ありがとうございました。
皆さんのコードと人生が、バグのない（あるいは、バグがあってもすぐに直せる）、美しく堅牢なものでありますように。
Happy Coding!
コメント