エンジニアの「視力」を変える魔法、システム思考の目覚め
こんにちは！海外のとある街で、今日もC#とWPF（Windows Presentation Foundation）に向き合っている現役エンジニアです。
今日は、少し「コードの書き方」から離れて、もっと根本的な、でも劇的にキャリアを変える可能性のある話をしようと思います。特に、これから海外に出たいと考えている人、あるいはエンジニアとして「次のステージ」に行きたいと思っている人には、ぜひ聞いてほしい話です。
皆さんは、「システム思考（Systems Thinking）」という言葉を聞いたことがありますか？
「ああ、なんかビジネス書で見たことある」「マネージャーがやるやつでしょ？」と思ったそこのあなた。正直に言います。かつての僕もそう思っていました。僕ら現場のエンジニアにとって大事なのは、美しいMVVMパターンであり、効率的なLINQクエリであり、メモリリークしない堅牢な設計だ、と。ビジネスのフレームワークなんて、スーツを着た人たちに任せておけばいいと本気で信じていました。
でも、海外の現場に出て、その考えは粉々に打ち砕かれました。
僕が働いている環境は、多国籍なメンバーが集まるチームです。ここでは「言われた通りに動くコードを書く」だけでは、誰も評価してくれません。いや、評価されないどころか、「君はプログラマーだけど、エンジニアではないね」と突き放されることさえあります。厳しいですよね。でも、これが現実なんです。
なぜか？ それは、コードを書くという行為が、ビジネスという巨大なシステムの中のほんの一部品でしかないことを、彼らが骨の髄まで理解しているからです。
「C#が書ける」だけでは通用しない瞬間
僕が渡航して間もない頃、ある大規模な業務アプリケーションの改修プロジェクトに参加しました。WPFを使ったリッチクライアントアプリで、バックエンドとの連携も複雑なシステムでした。
ある日、プロダクトオーナーから「この画面のデータ読み込みが遅いから、キャッシュを使って高速化してほしい」という依頼が来ました。僕は「よし、腕の見せ所だ」とばかりに、最新のライブラリを導入し、ローカルキャッシュの仕組みを完璧に実装しました。単体テストもバッチリ、動作も爆速です。「どうだ！」と言わんばかりにプルリクエストを出しました。
しかし、シニアエンジニアからのレビューコメントは、僕の予想を遥かに超えるものでした。
「このキャッシュ戦略は、システム全体の整合性を破壊するリスクがある。君は、このデータが別のアカウントから更新された時の伝播遅延（Propagation Delay）が、カスタマーサポートのオペレーションにどう影響するか考えたか？」
頭をガツンと殴られたような衝撃でした。
僕は「画面の表示速度」という**局所的な問題（Parts）しか見ていませんでした。しかし、彼はその変更がシステム全体、さらにはカスタマーサポートという組織の動き（Whole）**にどう波及するかを見ていたのです。
これが「システム思考」の正体です。
物事を個別の要素の集まりとしてではなく、相互に影響し合う「つながり」として捉える力。これこそが、これからのエンジニアに求められる真のスーパーパワーなんです。
なぜ今、エンジニアに「システム思考」が必要なのか
日本で働いていた時も、もちろん「全体設計」という言葉はありました。でも、海外の現場、特にスピード感が求められるアジャイルな環境では、この視座の高さが個々のエンジニアに強く求められます。
なぜなら、現代のソフトウェア開発はあまりにも複雑だからです。
マイクロサービス、クラウドインフラ、サードパーティAPIの連携……。僕たちが書くC#のコード一行が、地球の裏側のサーバーに負荷をかけたり、あるいは予想もしないビジネス指標に影響を与えたりします。
WPFで開発していると、よく「依存関係の注入（Dependency Injection）」を使いますよね？ クラス間の結合度を下げて、テストしやすく、変更に強くするためのパターンです。実は、システム思考もこれに似ています。
組織やビジネスも、無数の「依存関係」で成り立っています。
- 開発チームが急いでリリースすると、QAチームの負荷が上がる（負のフィードバックループ）。
- 機能を増やしすぎると、ユーザーが混乱してサポートへの問い合わせが増える（遅れを伴う影響）。
こういった「見えないつながり」をコードを書く前に想像できるかどうか。それが、単なる「コーダー」と、尊敬される「エンジニア」を分ける分水嶺になります。
「木を見て森を見ず」からの脱却。日常業務で始めるシステム思考トレーニング
前回の記事で、僕は「コードだけを見ていても、本当に良いエンジニアにはなれない」という、ちょっと耳の痛い話をしました。システム思考という武器がないと、良かれと思ってやった修正が、システム全体（あるいは組織全体）に思わぬダメージを与えてしまうことがあるからです。
「理屈はわかった。でも、明日の朝から具体的に何をすればいいの？」
「いちいち『組織への影響』なんて考えてたら、Jiraのチケットが消化できないよ！」
そんな声が聞こえてきそうです。わかります。僕も最初はそうでした。納期は迫る、バグは減らない、PM（プロジェクトマネージャー）は進捗を聞いてくる。そんな戦場で、悠長に哲学なんて語ってられないですよね。
でも、安心してください。システム思考は、デスクに座ってうんうん唸ることではありません。日々のコーディング、デバッグ、設計の中に「小さな習慣」として組み込むことができるんです。
この「承」のパートでは、あなたの視点を「木（コード）」から「森（システム全体）」へとスムーズに移行させるための、実践的なトレーニング方法を紹介します。
1. 「氷山モデル」でバグの深淵を覗く
システム思考には**「氷山モデル（The Iceberg Model）」**という有名なフレームワークがあります。物事を目に見える「出来事」だけで判断せず、その下にあるパターンや構造を見よう、というものです。
これを僕らエンジニアの日常、例えば「バグ修正」に当てはめてみましょう。
- 出来事（Events）：「WPFアプリの画面で、検索ボタンを押すとたまにフリーズする」というバグ報告が来ました。→ 多くのエンジニアはここで、「非同期処理の await 漏れかな？」「UIスレッドをブロックしてるな」とコードを修正して終わります。これが「対症療法」です。
- パターン（Patterns）：ここで一歩踏み込みます。「この手のフリーズ、先月も別の画面で起きなかったか？」と過去を振り返ります。→ 調べてみると、データ量が多い時に頻発していることがわかりました。
- 構造（Structures）：さらに深く潜ります。「なぜデータ量が多いとUIが止まる構造になっているんだ？」→ 原因を突き詰めると、実はバックエンドのAPIがページングに対応しておらず、全件データを返していたことが判明。さらに、WPF側の ObservableCollection が大量のデータを一度にバインドしようとして、レンダリングコストが爆発していた、という「構造」が見えてきます。
- メンタルモデル（Mental Models）：ここが一番深いです。「なぜそんな設計が許されたのか？」→ 「とりあえず動けばいい」「バックエンドとフロントエンドのチームが分断されていて、お互いの仕様（APIのレスポンスサイズやWPFの描画負荷）に関心を持っていない」というチームの意識（メンタルモデル）に行き着きます。
どうでしょう？
「出来事」レベルで対応する人は、Task.Run で逃げて終わりかもしれません。でも、「構造」まで見る人は、「APIチームにページング実装を依頼する」という根本解決を提案できます。
明日からバグに遭遇したら、すぐに修正コードを書く前に、**「これは単発の事故か？ それとも構造的な欠陥か？」**と自分に問いかけてみてください。
2. 「フィードバックループ」をコードの中に探す
システム思考の核心は「円環（ループ）」です。AがBに影響し、BがAに跳ね返ってくる。
C#でプログラムを書いていると、直線的なロジック（If A then B）で考えがちですが、現実はループだらけです。
例えば、WPFでよくある「入力フォームのバリデーション」。
ユーザーが不正な値を入力すると、エラーメッセージが出る。ここまでは直線です。
しかし、そのエラーメッセージが画面レイアウトを崩し、その結果「保存ボタン」が押せなくなり、ユーザーがリトライを連打し、それがバックグラウンドで無駄な検証処理を走らせ、アプリが重くなり、さらにユーザーがイライラして……という**「悪循環（Reinforcing Loop）」**が発生することがあります。
あるいは、マイクロサービスとの通信で使う「リトライ処理（Pollyなどを使用）」もそうです。
APIがタイムアウトしたからといって、単純に「3回リトライ」するコードを書いたとします。もし、サーバーダウンの原因が「アクセス過多」だったらどうなるでしょう？ 全クライアントが一斉にリトライをかければ、サーバーにとどめを刺すことになります。
ここでシステム思考ができるエンジニアは、「エクスポネンシャル・バックオフ（指数関数的待機）」や「サーキットブレイカー」を導入し、**「システム全体を安定させるためのループ（Balancing Loop）」**を設計します。
コードを書くとき、**「この処理の結果が、巡り巡ってこの処理自身の入力条件にどう影響するか？」**を想像する。これができるようになると、設計の堅牢性が劇的に上がります。
3. 「時間的遅れ（Time Delay）」を味方につける
海外のプロジェクトに参加して痛感したのは、「今すぐの結果」を求めすぎると失敗するということです。システムには必ず「遅れ」があります。
例えば、新しいアーキテクチャ（例えばMVVMからMVUへの移行など）を導入するとします。
最初の数ヶ月は、学習コストや既存コードの書き換えで、開発速度は確実に落ちます。ここでシステム思考がないと、「新しいやり方は効率が悪い！元に戻そう！」と判断してしまいます。
しかし、システム思考があれば、「これは一時的な遅れであり、学習曲線を超えれば生産性は向上する」という**「Jカーブ」**の構造が見えているので、チームを説得して我慢することができます。
また、WPFのパフォーマンスチューニングでも同じです。メモリリークの修正は、今日やっても効果が見えるのは、ユーザーが長時間アプリを使い続けた「数日後」かもしれません。
「即効性がないから意味がない」と切り捨てるのではなく、**「時間差で効いてくる効果」**を計算に入れる。これも、シニアエンジニアに求められる重要な資質です。
4. あなたの「境界線」を広げる
最後に、これが一番簡単なトレーニングです。
あなたの担当範囲（境界線）を、勝手に少しだけ広げてください。
WPFエンジニアだからといって、XAMLとViewModelだけ見ていればいいわけではありません。
そのデータを提供しているAPIのコード（C#のWeb APIでしょうか、それともGo？Python？）を覗きに行ってみてください。「なぜこのJSONはこの形なんだろう？」と考えるだけで、システムの全体像が見えてきます。
また、あなたのアプリを使うユーザーの「業務フロー」を知っていますか？
彼らは、あなたのアプリを使う「前」に何をしていて、使った「後」に何をするのか。
以前、ある機能追加を依頼された時、ユーザーの業務フロー全体を見たら、「そもそもこの機能は不要で、既存の機能を少し変えるだけで、彼らの作業時間が半分になる」ことが判明したことがあります。
コードを書かずに問題を解決する。これぞ、エンジニアリングの極みですよね。
次のステップへ
「木」ではなく「森」を見る。
バグの裏にある「構造」を見る。
コードの向こうにある「時間」と「人」を見る。
これらを意識し始めると、不思議なことが起こります。
これまで「面倒な仕様変更」に見えていたものが、「システム全体のバランスを取るための調整」に見えてくるのです。そして、あなたの書くコードは、単なる「命令の羅列」から、システムという生態系の中で生き続ける「意味のある細胞」へと進化します。
さて、こうして視座が高まると、次なる壁にぶち当たります。
それは、**「この複雑なシステムの話を、どうやって技術がわからない人たち（マネージャーや顧客）に伝えるか？」**という問題です。
あなたが「構造的な欠陥」を見抜いても、「なんか難しそうなこと言ってるな」と思われてしまっては意味がありません。
そこで次回、「転」のパートでは、システム思考で得た洞察を、誰にでもわかる言葉に変換し、プロジェクトを動かすための**「コミュニケーション・トランスレーション（翻訳）術」**についてお話しします。
エンジニアは、実は最強の「通訳」になれるポテンシャルを秘めているんですよ。
それでは、また次回。
難解な技術を「翻訳」せよ。非エンジニアを味方につけるコミュニケーション術
前回、私たちは「コード（木）」から視点を上げ、「システム全体（森）」を見る目を養いました。
バグの裏にある構造的な欠陥を見抜き、将来のリスクを予見する。これでエンジニアとしてのレベルは確実に上がりました。
しかし、ここで残酷な現実をお伝えしなければなりません。
あなたがどれだけ素晴らしいシステム思考で「正しい答え」を導き出したとしても、それがプロジェクトに反映されるとは限りません。むしろ、無視されることの方が多いでしょう。
「このまま機能追加を続けると、3ヶ月後にアーキテクチャが破綻します！」
とあなたが叫んでも、プロダクトオーナー（PO）はこう言うでしょう。
「わかるけど、来週のデモにはこの新機能が必要なんだ。リファクタリングは後にしてくれ」
そして3ヶ月後、予言通りシステムは崩壊し、デスマーチが始まります。「ほら、言った通りになったじゃないか！」と心の中で叫んでも、後の祭り。誰も幸せになりません。
なぜこんなことが起きるのでしょうか？
あなたの英語力が足りないから？ いえ、違います。
それは、あなたが**「エンジニアの方言」**で話しているからです。
この「転」のパートでは、システム思考で得た洞察を、非エンジニア（ステークホルダー、マネージャー、顧客）に伝え、彼らを動かすための「翻訳術」についてお話しします。これこそが、海外で生き残るための真のサバイバルスキルです。
1. 「技術的負債」を「キッチンの片付け」に翻訳する
僕らエンジニアは、つい専門用語を使いたがります。
「WPFのデータバインディングが複雑化しすぎて、保守性が低下しています。MVVMパターンを整理し、ViewModelを分割する必要があります」
これを聞いたビジネスサイドの人間（特に予算権限を持つ人）の脳内では、こう変換されています。
「（何言ってるかわからないけど）このエンジニアは、金にならない自己満足のために時間を使いたがっている」
これでは承認が降りるわけがありません。ここでシステム思考を使います。彼らの関心事は「コードの美しさ」ではなく、「開発スピード（Time to Market）」と「コスト」です。
僕はよく、これを**「レストランのキッチン」**に例えて説明します。
「今のコードベースは、ランチタイムのピークが終わった直後のキッチンのような状態です。皿は汚れ、鍋は散らかり放題です。
もし、このまま掃除をせずにディナータイム（次の機能開発）に突入したらどうなるでしょう？ シェフ（開発者）は汚れた鍋を洗うところから始めないといけないので、料理が出るまでの時間が2倍になります。
今、2日かけてキッチンを掃除させてください。そうすれば、来月の新機能は予定通り出せます。掃除をしなければ、来月のリリースは確実に遅れます」
こう伝えると、POの目の色が変わります。「MVVMのリファクタリング」は「コスト」に見えましたが、「キッチンの掃除」は「将来のスピードへの投資」として映るからです。
システム思考で見えた「将来の遅れ（Time Delay）」という構造を、相手が直感的に理解できる**メタファー（比喩）**に変換する。これが第一のステップです。
2. 「Causal Loop Diagram」をナプキンの裏に描く
言葉（特に第二言語である英語）だけで複雑な因果関係を説明するのは、至難の業です。
そこで有効なのが、簡単な図解です。システム思考のツールである「ループ図（Causal Loop Diagram）」を、もっとカジュアルに使います。
ある時、クライアントから「もっとエンジニアを投入して開発を加速させたい」という提案がありました。
『人月の神話』を知っているエンジニアなら、これが逆効果だとわかりますよね。でも、それを「ブルックスの法則により……」と説いても響きません。
僕はホワイトボード（あるいはカフェのナプキン）に、シンプルな3つの箱と矢印を描きました。
- [New Engineers] → (増えると) → [Training Time] (既存メンバーの教育コストが増える)
- [Training Time] → (増えると) → [Coding Time] (既存メンバーの作業時間が減る)
- [Coding Time] → (減ると) → [Project Speed] (短期的には遅くなる！)
そして、こう付け加えました。
「見ての通り、人を増やすと一時的にスピードが落ちるループが存在します（Worse-Before-Better）。もし納期が来月なら、人を増やさない方が速いです。納期が半年後なら、今増やす価値があります」
矢印でつながった図を見せられると、人は不思議と納得します。
口頭での議論は「意見の対立（VS構造）」になりがちですが、図を指差しながら話すと「一緒に図の問題を解決する（We構造）」に変わるのです。
UMLやフローチャートのような厳密な図はいりません。**「何が何に影響しているか」**だけの落書きで十分です。
3. 「No」と言わずに「Yes, and…」でトレードオフを提示する
システム思考ができるようになると、無理な要求に対して「それはシステム的に不可能です」と断定したくなります。しかし、海外の文化では、頭ごなしの「No」は「能力不足」や「非協力的」と取られるリスクがあります。
ここで大切なのは、システムの「トレードオフ」を提示することです。
例えば、「セキュリティを強化したい、でもログインの手間は減らしたい」という矛盾する要求が来たとします。
「No, それは無理です」ではなく、こう言います。
「Yes, ユーザー体験を良くするのは大事ですね。
And, もしログインの手間を極限まで減らすと、セキュリティのリスクという別の変数が上がります。
僕たちのシステムでは、A（利便性）とB（安全性）はシーソーの関係にあります。
もしAを取りたいなら、バックグラウンドでの監視コスト（C）にお金をかける必要がありますが、どうしますか？」
システム全体が見えているからこそ、単なる拒絶ではなく、**「選択肢の提示」**ができるようになります。
「Aを立てればBが立たず。でもCという新しい要素を入れれば解決するかも？」という提案は、あなたが単なる作業者ではなく、ビジネスパートナーであることを印象付けます。
4. 言語の壁を超える「ロジックの共通言語」
海外で働いていて痛感するのは、**「流暢な英語よりも、明快なロジックの方が強い」**ということです。
ネイティブスピーカーのように早口で喋れなくても、システム思考に基づいた「論理的な因果関係」は、万国共通の言語です。
「Because A affects B, and B impacts C…」
この構文さえしっかりしていれば、中学レベルの英語でも、相手（たとえCEOであっても）を納得させることができます。
逆に、どれだけ英語がうまくても、視点が局所的で「技術的なわがまま」しか言っていないエンジニアは、会議で発言権を失っていきます。
システム思考は、英語のハンディキャップを補って余りある武器になります。なぜなら、多くの人は「複雑な状況」に混乱しており、それを整理して「ここを押せば解決するよ（レバレッジ・ポイント）」と示してくれる人を求めているからです。
転から結へ：そして「未来の設計者」へ
技術を翻訳し、図で示し、トレードオフを提示する。
これを繰り返していくと、あなたの立ち位置は変わります。
「チケットを消化する人」から、「何を作るべきかを一緒に考える人」へ。
しかし、システム思考の旅はここで終わりではありません。
「コード」から「システム」へ、「システム」から「人への伝達」へ。
その先にあるのは、エンジニア自身が組織のカルチャーや未来そのものを設計する、という究極のステージです。
次回、最終回となる「結」では、システム思考を手に入れたエンジニアが、どのようにキャリアを築き、どんな未来を描けるのか。
**「ただの解決屋から、未来の設計者へ」**というテーマで、このシリーズを締めくくりたいと思います。
エンジニアの仕事は、画面の中だけじゃない。
あなたの書くコードと言葉が、世界を少しだけ良くするシステムの一部になることを願って。
ただの「解決屋」から「未来の設計者」へ。組織を動かすエンジニアになるために
ここまで、僕と一緒に「システム思考」というレンズを通して、エンジニアリングの世界を再定義する旅をしてきました。
「起」では、目の前のコード（Parts）だけではなく、全体（Whole）を見る重要性に気づきました。
「承」では、バグやトラブルの背後にある「構造」や「ループ」を見抜くトレーニングをしました。
「転」では、その洞察を非エンジニアにもわかる言葉に「翻訳」し、プロジェクトを動かす術を学びました。
そして今、この「結」のパートで、皆さんに問いかけたいことがあります。
「このスーパーパワーを使って、あなたはこれから何を作りますか？」
「そりゃあ、バグのない完璧なWPFアプリだよ」
そう答えるかもしれません。もちろん、それは素晴らしいことです。でも、システム思考を身につけた今のあなたなら、もっと大きなものが見えているはずです。
それは、**「組織の未来」**そのものです。
コードで「組織のカルチャー」を設計する（逆コンウェイの法則）
エンジニア業界には**「コンウェイの法則」**という有名な経験則があります。
「システムのデザインは、その組織のコミュニケーション構造を反映する」というものです。つまり、仲の悪い2つのチームが開発すると、連携の悪い2つのモジュールが出来上がる、ということです。
多くのエンジニアは、これを「仕方ないこと」として受け入れます。
しかし、システム思考を持つエンジニアは、これを逆手にとります（Inverse Conway Maneuver）。
僕が以前、巨大なスパゲッティコードと化したWPFのレガシーシステムを保守していた時の話です。チーム全体が疲弊し、誰がどのコードに責任を持つのか曖昧で、毎日のように責任のなすり合い（Blame Game）が起きていました。
そこで僕は、システム思考のアプローチを取りました。
「チームの仲が悪いからコードが汚い」のではなく、「コードの境界線が曖昧だから、チームの責任範囲も曖昧になり、仲が悪くなるのだ」と考えたのです。
僕はアーキテクチャを強引に「モジュラーモノリス」へと変更し、機能ごとに明確な境界線（Interface）を引きました。物理的に、隣のチームのコードを勝手に触れないようにしたのです。
すると何が起きたと思いますか？
「ここから先は君たちの領分だ。APIの仕様を決めるために話し合おう」
という会話が強制的に生まれました。コードの構造を変えることで、人の動きが変わり、会話が生まれ、最終的にチームのカルチャーが「対立」から「協調」へと変化したのです。
これこそが、システム思考の真骨頂です。
あなたはC#のコードを書いているようでいて、実は**「人がどう働くか」というシステムそのものをコーディングしている**のです。
これに気づいた時、エンジニアという仕事は、単なる「仕様書の実装者」から、「組織のアーキテクト（設計者）」へと進化します。
「Staff Engineer」への道：影響力の範囲を広げる
海外のテック企業では、シニアエンジニアの先のキャリアとして**「Staff Engineer（スタッフエンジニア）」や「Principal Engineer（プリンシパルエンジニア）」**という役割が確立されています。
彼らは何をしているのでしょうか？
彼らは、一番コードを書くのが速い人たちではありません。彼らは、**「最もレバレッジ（てこの原理）が効くポイント」**を知っている人たちです。
システム思考がないエンジニアは、100の仕事をこなすために、100の力でコードを書きます。
システム思考があるエンジニアは、システムの「ツボ（レバレッジ・ポイント）」を見つけ、1の力で100の成果を出します。
- 毎回手動で行われるテストがボトルネックになっている（ループの遅延）を見抜き、CI/CDパイプラインを整備する。
- 新人エンジニアが同じようなミスでハマる構造（システムの欠陥）を見抜き、共通ライブラリやドキュメントを整備して「失敗しない仕組み」を作る。
これらはすべて、自分一人の生産性を上げるためではなく、**「組織全体の生産性のループ」**を好転させるための活動です。
僕が海外で生き残ってこられたのは、英語がネイティブ並みに話せるからでも、天才的なアルゴリズムが書けるからでもありません。
この「レバレッジ・ポイント」を見つけて、チーム全体が楽になる仕組みを作り続けてきたからです。
「あいつがいると、なぜかプロジェクトがスムーズに進む」
そう言われる存在になること。それが、これからのエンジニアの生存戦略であり、最高のブランディングです。
予測不可能な未来を「楽しむ」力
最後に、少しメンタルな話をさせてください。
システム思考を学ぶと、世の中がいかに複雑で、思い通りにならないかということを痛感します。
Aを直せばBが壊れる。良かれと思った修正が、数ヶ月後に問題を起こす。
でも、それで絶望する必要はありません。むしろ、その複雑さを楽しめるようになります。
「おっと、ここに手を入れたら、あっちが反応したぞ。まるで生き物だな」
システムを、制御すべき「機械」ではなく、対話すべき「生態系」として捉えるようになります。
WPFのデータバインディングもそうです。
プロパティの変更通知が連鎖し、画面が生き生きと動く様は美しいですよね。
組織もビジネスも同じです。あなたの投入したコードや提案が、波紋のように広がり、誰かの仕事を助け、顧客を笑顔にし、ビジネスを成長させていく。そのダイナミズムを感じられるのは、全体を俯瞰しているエンジニアだけの特権です。
旅の終わりに：あなたの「最初のワンステップ」
長くなりましたが、これで「システム思考」を巡るブログシリーズは完結です。
ここまで読んでくれたあなたには、もう以前のような「木しか見えない視力」には戻れない呪い……いや、祝福がかかっています。
明日、エディタを開いた時、あなたはきっと考えるでしょう。
「この一行は、システム全体にどんな音楽を奏でるだろうか？」と。
いきなり組織を変える必要はありません。
まずは、隣の席のエンジニアが困っている「小さな悪循環」を見つけて、断ち切ってあげてください。
「ここ、いつも手動で直してるの？ シェルスクリプト書いて自動化しといたよ」
その小さな親切（システムへの介入）が、やがて大きなうねりとなり、あなたを「なくてはならないエンジニア」へと押し上げてくれるはずです。
海外の空の下から、あなたのエンジニアリングライフが、より豊かで、よりインパクトのあるものになることを祈っています。
それでは、またどこかのコードベースでお会いしましょう。
Happy Coding, and Keep Thinking in Systems!
コメント