幻想の海外テック事情と、蝕まれる生産性：「見えない作業」の正体
やあ、みんな。今日もVisual Studioと睨めっこしてる？
海外でC# WPF（Windows Presentation Foundation）専門のエンジニアとして働いている僕だ。
日本にいた頃、海外のエンジニア事情に対してどんなイメージを持っていたか覚えてる？
「合理的で、無駄がなくて、最新のツールをバリバリ使いこなして、残業なんて絶対しないスーパーマンたち」
正直、僕はそう思ってた。でも、実際に海を渡って、現地の企業のドアを開けて（あるいはSlackのワークスペースに入って）最初に感じたのは、強烈な違和感だったんだ。
今回は、僕が実際に体験した「効率化」にまつわる泥臭い話、そしてそこからどうやってチーム全体の文化を変えていったかという話をシェアしたいと思う。これから海外を目指す人、あるいは日本で「もっと効率よく働きたいのに」と燻っているエンジニアにとって、何かのヒントになれば嬉しい。
1. 憧れの海外オフィスに潜む「レガシーの亡霊」
僕が今の会社に入ったとき、担当することになったのは、ある大規模な製造業向けのデスクトップアプリケーションだった。WPFで作られ、MVVMパターン（Model-View-ViewModel）を採用している、一見すると堅牢なアーキテクチャ。C#のバージョンもそこそこ新しい。
「よし、これならバリバリ機能追加できるぞ」
最初はそう思った。でも、開発を始めて1週間で、僕は「何かがおかしい」と気づいたんだ。
コードは綺麗だ。設計も悪くない。でも、**「開発以外の時間」**が異常に長い。
例えば、ある小さなバグ修正をして、それをQA（品質保証）チームに渡すまでのプロセスだ。
日本なら、CI/CDパイプラインが走って、自動テストが通ればデプロイ完了、みたいな流れを想像するよね？
でも、そこには驚くべきアナログな世界が広がっていた。
まず、ビルドには特定の手順が必要で、それを記述したWordドキュメント（最終更新日は2年前）が存在する。XAMLの特定のリソースディクショナリを手動で書き換えないと、デバッグモードで起動しない謎の仕様。インストーラーを作るためには、誰かのローカルPCにあるバッチファイルを叩く必要がある。
「これ、自動化しないんですか？」と同僚のボブ（仮名）に聞いたとき、彼は肩をすくめてこう言ったんだ。
「ああ、それはずっとそうやってるからね。自動化しようとした人もいたけど、ビルドサーバーの設定が複雑すぎて諦めたんだよ。手でやったほうが早いし、確実だろ？」
この瞬間、僕は悟った。
海外だからといって、全員が効率化の鬼ではない。
むしろ、個人のスキルが高いがゆえに、「面倒な作業も力技で解決できてしまう」からこそ、非効率なプロセスが温存され続けているというパラドックスがあったんだ。
2. 「見えない作業（Invisible Work）」という名の負債
僕が直面したのは、まさにこの「見えない作業」の山だった。
これは技術的負債（Technical Debt）の一部だけど、コードの中にあるわけじゃないからタチが悪い。プロセスやコミュニケーションの中に潜んでいるんだ。
WPF開発者ならわかると思うけど、XAMLのデータバインディングのエラーなんて、実行してみないと気づかないことが多い。本来なら、単体テストやUIテストでガードすべきところを、このチームでは「開発者が手動で全画面をクリックして確認する」という暗黙のルールでカバーしていた。
ある日、僕は単純なUIの変更（ボタンの色を変えるとか、マージンを調整するとか）を行った。
コーディング自体は5分で終わる。でも、その後の確認作業、インストーラー作成、共有フォルダへのアップロード、マネージャーへのメール報告……これらにかかった時間は2時間だ。
5分の価値を生むために、2時間のコストを払っている。
これをエンジニアの時給換算してみると、ゾッとするような無駄遣いだよね。でも、誰もそれを問題だと思っていない。「仕事とはそういうものだ」という空気が、オフィス（とリモートワークのチャットログ）を支配していた。
これが僕の言う「見えない作業」だ。
チケット管理システム上では「UI修正：完了」としか記録されない。その裏にある2時間の単純作業は、誰の目にも触れず、評価もされず、ただ僕たちのエネルギーと時間を静かに吸い取っていく。
3. 「郷に入っては郷に従え」の落とし穴
海外で働くとき、よく言われるアドバイスがある。「現地の文化を尊重しろ」「郷に入っては郷に従え」。
これは人間関係においては真実だ。でも、エンジニアリングのプロセスにおいては、時として猛毒になる。
僕も最初は黙って従っていた。「まだ入ったばかりだし、波風立てたくない」「英語での議論で負けるのが怖い」という気持ちもあった。
でも、その結果何が起きたか？
3ヶ月後、僕は完全に消耗していた。
C#のコードを書く楽しさは消え失せ、来る日も来る日も「手動ビルド」と「Excelへのログ貼り付け」に追われる日々。
「俺は一体、何のために海を渡ったんだ？ 高度なアーキテクチャ設計をするためじゃないのか？ 誰でもできるコピペ作業をするために、わざわざビザを取ったのか？」
ある金曜日の午後、デプロイ手順書の手順を一つ飛ばしてしまったせいで、ビルドが失敗し、チーム全員を1時間待たせてしまったことがある。
同僚は「Don’t worry, happens to everyone（気にするな、誰にでもあることさ）」と優しく言ってくれた。
でも、その優しさが逆に辛かった。
「誰にでもあること」にしちゃいけないんだ。人間はミスをする。だからこそ、システムがそれを防ぐべきなんだ。
この時、僕の中で何かがプッツンと切れた音がした。
「もう、嫌だ」
この感情こそが、全ての改革のスタート地点だった。
4. エンジニアの本能を呼び覚ませ
エンジニアの本質ってなんだろう？
プログラミング言語を知っていること？ アルゴリズムに詳しいこと？
違う。僕は**「怠惰であること」**こそが、エンジニアの最大の美徳であり才能だと思っている。
（これはPerlの開発者ラリー・ウォールの言葉としても有名だよね）
同じことを二度繰り返すのが死ぬほど嫌い。
面倒なことは機械にやらせたい。
自分が楽をするためなら、今は死ぬ気で努力してもいい。
その「怠惰への情熱」を、僕は忘れていた。海外という環境に圧倒され、英語というハンデに縮こまり、現状維持というぬるま湯に浸かっていた。
僕は決意した。この状況を変えよう。
単にCIツールを導入するとか、スクリプトを書くとか、そういう手段の話じゃない。
**「非効率を許さない文化（Culture of Efficiency）」**を、このチームに植え付けるんだ。
でも、これは簡単なことじゃない。
なぜなら、相手は「変化」を恐れる人間たちだからだ。
「今のままで回っているのに、なぜ変える必要がある？」
「新しいツールを覚える時間なんてない」
「お前のやり方が本当に正しい保証はあるのか？」
特にWPFのような、歴史があり、枯れた技術スタックを使っている現場では、「安定稼働」が錦の御旗になりがちだ。「動いているものに触るな」は、ある種の聖域不可侵な掟でもある。
僕一人で「自動化しましょう！PowerShell書きましょう！」と叫んだところで、変人のレッテルを貼られて終わりだろう。
だからこそ、戦略が必要だった。
ただの技術的な提案ではなく、経営層（マネジメント）には「利益」の話を、同僚（エンジニア）には「自由」の話をする必要があった。
ここからの戦いは、コードを書くこと以上にクリエイティブで、そしてタフなものになった。
自分一人のPCの中だけで完結する効率化（スニペットツールを使うとか）はただの自衛だ。でも、チーム全体の「見えない作業」を撲滅するのは、革命だ。
このブログでは、僕が実際にどうやってその「革命」を起こしたのか。
失敗も成功も含めて、リアルな記録を書いていこうと思う。
次回は、まず第一の関門。「マネジメント層への説得」についてだ。
感情論で「辛いから変えてください」と言っても、海外のドライなマネージャーは動かない。
彼らを動かすのは、いつだって具体的な数字と、リスクへの言及だ。
僕がどうやって「見えない作業」を可視化し、彼らの言葉（コストとリスク）に翻訳してプレゼンしたのか。その具体的な手法を紹介しよう。
準備はいいか？
さあ、エディタを閉じて、まずは現状を疑うところから始めよう。
マネジメントを動かすのは「感情」ではなく「数字」：変革の提案術
前回、僕は「手動ビルド」や「Excel職人芸」といった無駄な作業に絶望した話をした。
ここで多くのエンジニア（過去の僕も含めて）がやりがちなミスがある。
それは、マネージャーとの1on1ミーティングでこう言ってしまうことだ。
「この作業、面倒くさいんで自動化したいです」
「最近のモダンな開発現場ではCI/CDが当たり前です。うちも導入しましょう」
「もっといいツールがあるんで、買ってください」
はっきり言おう。これでは100%失敗する。
なぜか？
それは君が**「エンジニアの方言」**で喋っているからだ。
マネージャー、特に技術上がりではないMBAホルダーや、数字にシビアな海外のプロダクトオーナーたちは、君の「面倒くさい（感情）」や「モダンな技術（憧れ）」には1ミリも興味がない。
彼らの脳内を占めているのは、「予算（Budget）」「納期（Deadline）」「リソース（Resource）」そして「投資対効果（ROI）」だけだ。
僕たちがやるべきなのは、エンジニアの悩みを彼らの言語、つまり**「ドルの言葉」**に翻訳することだ。
1. ストップウォッチ作戦：敵を知り、己を知れば百戦危うからず
僕はまず、いきなり提案書を書くのをやめた。
その代わりに、2週間、ある地味な調査を行った。名付けて「ストップウォッチ作戦」だ。
自分の業務時間、そして信頼できる同僚のボブの業務時間を、タスクごとに細かく計測したんだ。
Togglのようなタイムトラッキングツールを使ってもいいし、スマホのストップウォッチでもいい。重要なのは、「コーディング（価値を生む時間）」と「それ以外（価値を生まない時間）」を明確に分けることだ。
特にフォーカスしたのは以下の項目だ。
- ローカルでのビルド待ち時間
- インストーラー作成にかかる手作業の時間
- QAチームへのデプロイ作業（ファイルコピー、メール作成含む）
- 他人が書いたドキュメントを探している時間
- 「あの件どうなってる？」というSlackへの返信に使った時間
2週間後、集まったデータを見て僕は震えた。
WPFアプリケーションのビルド時間は、マシンスペックにもよるが、フルビルドで数分かかることは珍しくない。それに加えて手動の手順が含まれるため、1回のデプロイ作業に平均「18分」かかっていた。
そして、開発チーム全体で、1日に平均「12回」のデプロイが行われていた。
18分 × 12回 = 216分（3.6時間）
チーム全体で、毎日3.6時間が「単なる移動と待機」に消えている。
ここからが「翻訳」の出番だ。
2. 「見えないコスト」を「請求書」に変える
僕はExcelを開き、簡単な計算式を作った。
海外のエンジニアの給与は公開されているレンジや、求人サイト（Glassdoorなど）の平均値を参考に仮置きする。仮に、チームのエンジニアの平均時給を$60（約9000円）としよう。
- 1日の損失：3.6時間 × $60 = $216
- 1ヶ月の損失（20営業日）：$216 × 20 = $4,320
- 1年の損失：$4,320 × 12 = $51,840（約800万円）
この数字が出たとき、これはもう「面倒くさい」というレベルの話ではなくなった。
会社は、何も生まない作業のために、年間5万ドル以上をドブに捨てていることになる。しかもこれは「デプロイ作業」だけの数字だ。他の雑務を含めれば倍にはなるだろう。
この「仮想の請求書」こそが、マネジメントの目を覚ます最強の武器になる。
「効率化したい」ではなく、「年間5万ドルの損失を防ぎたい」と言うのだ。
これで、君の提案は「わがまま」から「ビジネスの改善提案」に昇格する。
3. 「バス係数（Bus Factor）」という名の恐怖訴求
数字で攻めるのが「王道（Positive）」のアプローチだとすれば、もう一つ、海外のマネジメントに強烈に効く「覇道（Negative）」のアプローチがある。
それが**「リスク管理」**だ。
特に、属人化したアナログ作業には「特定の人しか知らない手順」が含まれることが多い。
僕のチームでは、ボブがその守護神だった。彼が休暇を取ると、誰も正しいインストーラーを作れないという事態が発生していた。
これを専門用語で**SPOF（Single Point of Failure：単一障害点）と言うが、もっと人間臭い言い方として「バス係数（Bus Factor）」**という言葉がある。
「もし明日、ボブがバスに轢かれて出社できなくなったら、プロジェクトはどうなりますか？」という問いかけだ。
僕は提案資料の中に、このリスクを明記した。
「現在のデプロイ手順は複雑怪奇であり、ドキュメントは古い。もし明日、シニアエンジニアが病気で1ヶ月休んだら、我々は顧客に修正パッチを届けることができなくなる。これはビジネス継続性（Business Continuity）における重大なリスクである」
欧米の企業は、個人のスキルに依存することを嫌う傾向がある（ジョブ型雇用だからこそ、人が入れ替わることを前提にしている）。
だから、「自動化＝誰でもボタン一つで実行できる状態」にすることは、単なる時短ではなく、**「会社を守るための防衛策」**として響くのだ。
4. 提案の現場：小さく始め、大きく勝つ
準備は整った。
定期的に行われているマネージャーとのミーティングで、僕はスライドを画面共有した。
タイトルは「CI/CD導入の提案」ではない。「開発プロセスにおけるコスト削減とリスク低減に関するレポート」だ。
プレゼンの構成は以下の3段論法で行った。
- Current Situation (現状の出血):
- 具体的なデータを見せる。「我々は毎月$4,000以上を、待機時間と手作業に費やしています」
- リスクを提示する。「主要メンバーが不在の場合、リリースが停止するリスクがあります」
- Proposal (止血策):
- ここで初めて技術的な話をする。「Azure DevOps（またはGitHub Actions）のパイプラインを構築し、ビルドとテストを自動化します」
- 重要なのは、**「新しいことをやる」のではなく「無駄をなくす」**と強調すること。
- Investment & ROI (治療費と完治予定):
- 「この仕組みを作るために、僕の時間の20%を2週間だけください（初期投資）」
- 「稼働すれば、最初の1ヶ月で投資分は回収でき、その後は毎月純粋なプラスになります」
マネージャーの反応はどうだったか？
最初は眉をひそめていた彼も、Excelの計算表が出た瞬間に身を乗り出した。
「Wait, $50k a year? Are you sure about this data?（待ってくれ、年間5万ドル？ 本当にこのデータは正しいのか？）」
「Yes. I tracked it.（はい、計測しました）」
彼はしばらく沈黙した後、こう言った。
「OK. Do it. But don’t delay the main feature development.（わかった、やれ。ただしメイン機能の開発は遅らせるなよ）」
完全な勝利だ。
「面倒くさい」と言っていたら「仕事しろ」で終わっていた話が、数字とリスクを提示することで「やってくれ」に変わったのだ。
5. 完璧を目指すな、まずは「Hello World」から
ここで一つ、これから提案をする人にアドバイスがある。
承認を得たからといって、いきなり「完全な自動化」を目指してはいけない。
WPFのプロジェクトなら、XAMLのコンパイルから単体テスト、UIテスト、署名、インストーラー作成、ストアへのアップロードまで全部やろうとすると、確実に泥沼にはまる。
まずは**「Small Win（小さな成功）」**を目指すんだ。
僕の場合、最初は「コードがプッシュされたら、ビルドが通るか確認するだけ」のパイプラインを作った。
たったこれだけでも、「ビルドエラーのままコミットされる」という事故がゼロになった。
「ほら、これだけで手戻りが週に3回減りましたよ」
と報告すれば、マネージャーの信頼残高が増える。信頼が増えれば、次はもっと大きな改善（例えば自動テストの導入や、インフラのコード化）に時間を割く許可が出やすくなる。
これを**「信頼のループ」**と呼ぶ。
一度「こいつの提案は金になる（効率化になる）」と思わせれば、その後の提案は驚くほどスムーズに通るようになる。
こうして僕は、マネジメント層という「第一の壁」を突破した。
お墨付きは得た。ツールも導入した。
これで全てが上手くいく……はずだった。
しかし、本当の戦いはここからだった。
最も厄介な敵は、上にいるマネージャーではなかった。
隣に座っている（あるいはZoomの画面の向こうにいる）**「同僚たち」**だったのだ。
彼らにとって、僕の持ち込んだ新しいツールやプロセスは、「仕事を楽にしてくれる魔法」ではなく、「自分たちのやり方を否定し、新しい学習を強要する異物」として映った。
次回、【転】。
「変化」を嫌う同僚たちとの冷戦、そしてチーム全体をどうやって「共犯関係」に巻き込んでいったか。
技術の話から、もっとドロドロした人間心理と、チームビルディングの深淵について語ろう。
「変化」を嫌う同僚たち：チーム全体を巻き込む共犯関係の作り方
前回、僕はマネージャーから「CI/CD導入」の許可を勝ち取った。
意気揚々とデスクに戻った僕は、意気揚々とAzure DevOpsのパイプラインを組み、PowerShellでビルドスクリプトを書き上げ、Slackの#generalチャンネルに高らかに投稿した。
「みんな！ これでもう手動ビルドは不要だ！ このボタンを押すだけで、ビルドからテスト、インストーラー作成まで全部自動で終わるぞ！ 素晴らしいだろ！」
期待していた反応は、「Wow! Amazing!」「You are a genius!」の嵐だった。
しかし、現実は違った。
ボブ（古参エンジニア）：「Cool.（いいね）」
アリス（若手エンジニア）：「That looks interesting.（面白そうですね）」
それだけだ。
そして翌日、ボブは相変わらず手元のWordドキュメントを見ながら、手動でmsbuildを叩いていた。
アリスに至っては、「自動ビルドが失敗するのが怖いから」という理由で、ローカルでビルドしたバイナリを共有フォルダに置いていた。
なぜだ？ あんなに便利にしたのに。
僕は最初、彼らの技術的理解度が低いせいだと思った。あるいは、怠慢なせいだと。
でも、それは傲慢な勘違いだった。
彼らは「変化」を拒絶していたんじゃない。
**「余計な仕事を増やされること」**を拒絶していたんだ。
1. 「正しさ」の暴力性を知る
エンジニアというのは、自分のやり方にプライドを持っている生き物だ。
特に、その非効率なやり方で何年もシステムを維持してきたという自負がある。
そこに、ポッと出の日本人がやってきて「君たちのやり方は非効率だ。僕の作った新しいツールを使え」と言い放つ。
これは効率化の提案ではない。「お前たちは間違っている」という攻撃に他ならない。
海外のオフィスでは、日本以上に「自分のテリトリー」意識が強い。
「That’s interesting（面白いね）」という言葉は、イギリスやアメリカの一部の文脈では「どうでもいい」「勝手にやってろ」という婉曲表現（Polite refusal）であることすらある。
僕は完全に「意識高い系のウザい奴」になっていた。
新しいツールは、使う側に学習コスト（Learning Curve）を強いる。
「PowerShell？ わからないから触りたくない」
「パイプラインが落ちたら誰が直すんだ？ お前だろ？」
このままでは、僕が作ったシステムは「僕専用のおもちゃ」になり、僕が退職した瞬間に廃棄されるだろう。
それでは「文化」を作ったことにならない。
僕は戦略を180度転換することにした。
「説得」をやめ、「誘惑」することにしたのだ。
2. トロイの木馬：痛み止めの中に変化を隠せ
人は「将来の利益」のためには動かないが、**「現在の苦痛」**を取り除くためなら喜んで動く。
僕は彼らが日々イライラしている「小さな棘」を探した。
WPF開発あるあるだが、XAMLのデザイナー画面（Design View）が重すぎて、Visual Studioが頻繁にフリーズするという問題があった。
ボブはいつも「F**k! また落ちた！」と叫んでいた。
僕はCI/CDの普及を一旦脇に置き、この問題の解決に動いた。
とは言っても、Visual Studio自体のバグは直せない。
代わりに、僕はプロジェクトファイル（.csproj）の設定を一括で書き換え、デザイナーの読み込みを軽量化し、かつ、開発時だけ特定のリソースを読み込まないようにする小さなスクリプトを書いた。
そして、ボブにこう言った。
「ねえボブ、君が叫んでるのが聞こえたから、ちょっとしたスクリプトを書いてみたんだ。これをダブルクリックすると、VSが落ちにくくなる……かもしれない。試してみてくれない？」
ボブは半信半疑でスクリプトを実行した。
その日、彼の叫び声は聞こえなかった。
夕方、彼が僕の席に来て言った。
「おい、あれ最高だな。魔法かよ」
ここだ。この瞬間だ。
僕はすかさず言った。
「実はそれ、例の自動化パイプラインの一部なんだ。サーバー側でも同じ設定を使ってビルドを高速化してるんだよ」
「マジか。じゃあサーバーのビルドも速いのか？」
「うん。ボタン一つで終わるよ」
「……ボタンの場所、もう一回教えてくれるか？」
これが**「トロイの木馬」戦術**だ。
彼らが欲しい「鎮痛剤（VSが落ちない）」の中に、「変化（自動化スクリプト）」を混ぜる。
一度そのメリット（快感）を味わわせれば、彼らは自分からその技術を使いたくなる。
3. 「マニュアル」を捨てる勇気
もう一つ、僕が変えたのは「ドキュメント」への姿勢だ。
以前の僕は、完璧なWikiページを作っていた。「自動化システムの使い方」という長文のマニュアルだ。
でも、誰も読まない。英語が母国語の彼らですら、技術マニュアルを読むのは嫌いなのだ。
僕はマニュアルを捨て、**「ツールへの組み込み」**を行った。
例えば、Gitの操作。
ブランチを切って、命名規則に従って名前をつけ、プッシュするというルールがあったが、よく間違えられる。
そこで、Start-Task.ps1 というスクリプトを用意した。
これを叩くと、「チケット番号は？」と聞かれる。入力すると、自動で正しいブランチが作成され、Visual Studioが立ち上がる。
「手順を覚えてください」ではなく「何も考えずにこれを叩いてください」にする。
思考停止で使えるものは、誰からも愛される。
結果的に、チーム全員が朝一番にそのスクリプトを叩くのが日課になった。
そのスクリプトの中に、こっそりと「最新のコードをプルする」「依存ライブラリを更新する」という処理を仕込んでおくことで、環境差異によるトラブルも激減した。
これを**「のせられやすさの設計（Nudge Theory）」**と呼ぶ。
正しい行動をとるほうが、間違った行動をとるより「楽」になるように環境を設計するのだ。
4. 共犯者を作る：「教えてくれ」という魔法の言葉
アリス（若手）へのアプローチはまた別だった。
彼女は新しいことへの興味はあるが、失敗を恐れていた。
僕は彼女を「生徒」ではなく「先生」として扱った。
僕はわざと、PowerShellスクリプトの一部を「未完成」あるいは「少しダサい実装」にしておき、彼女に相談した。
「アリス、この部分のロジックなんだけど、君ならC#のLINQを使ってどう書く？ PowerShellだと汚くなっちゃって」
彼女はC#が得意だ。「えっと、私ならこう書きますね」
「なるほど！ それ採用していい？ もしよかったら、ここの部分、君が書き直してコミットしてくれないかな？」
彼女がコミットした瞬間、その自動化システムは「僕のツール」から**「私たちのツール」に変わった。
これが「IKEA効果」**だ。人は自分が手作りに関わったものに対して、不当に高い価値を感じる。
翌週のミーティングで、アリスは他のメンバーに説明していた。
「このスクリプトのこの部分は、もっと効率的に動くように私が直しておいたから、安心して使ってね」
彼女はもう、立派なエバンジェリスト（伝道師）だ。
一番の抵抗勢力になり得た人物を、一番の推進者に変える。
そのためには、自分の手柄を捨ててでも、相手に「コントリビュートした」という実績を与えることが重要だった。
5. 失敗を祝福する文化
自動化が進むと、当然エラーも出る。
ある日、自動デプロイが失敗して、テスト環境が壊れた。
以前の空気なら「誰だ？ 変なことしたのは」という犯人探しが始まっていただろう。
僕はSlackですぐに反応した。
「おっと、パイプラインがバグを捕まえたぞ！ お手柄だ。手動でやってたら、このバグはお客さんのところまで届いていたかもしれない。システムがいい仕事をしたね！」
「失敗」を「検知」と言い換える。
パイプラインが赤くなる（エラーになる）のは、悪いことじゃない。安全装置が作動したという「良いニュース」なんだ。
このリフレーミング（意味の再定義）を繰り返すことで、チームの中に「エラーが出ても大丈夫。システムが守ってくれるから」という**心理的安全性（Psychological Safety）**が生まれてきた。
恐怖がなくなれば、人は新しいことに挑戦し始める。
ボブがついに言った。
「インストーラーの作成部分、もっと速くできそうだから、俺がいじってもいいか？」
「もちろん！ 頼むよ、ボブ」
こうして、僕のチームは変わり始めた。
最初は「僕 vs チーム」だった構図が、「チーム vs 非効率」という構図に変わった。
一度回り出した歯車は、もう止まらない。
彼らは自発的に「ここも自動化できるんじゃないか？」「このテスト、重複してないか？」と議論し始めた。
効率化の文化とは、誰か一人のヒーローが作るものじゃない。
「楽をしたい」という人間の根源的な欲求を肯定し、それを共有できる空気のことだったんだ。
さて、マネジメントを説得し、チームを巻き込んだ。
効率化の仕組みは回り出し、残業は減った。
めでたしめでたし……？
いや、まだだ。
最後に一つだけ、重要なピースが残っている。
それは、**「この文化をどうやって永続させるか」**だ。
僕がいなくなっても、メンバーが入れ替わっても、この「効率化の灯」を消さないためにはどうすればいいか。
そして、浮いた時間で僕たちは「次」に何をするべきなのか。
次回、最終回【結】。
未来の自分を救うための「持続可能なサボり術」と、エンジニアとしてのキャリアのその先について。
この長い旅の結論を話そう。
未来の自分を救う：持続可能な「サボるための仕組み」作り
僕たちが作った自動化システム（CI/CDパイプラインや便利スクリプト群）には、一つだけ重大な弱点があった。
それは**「僕しか直せない」**ということだ。
ボブやアリスも使ってはくれる。小さな修正もしてくれる。
でも、パイプラインのコア部分（YAMLの複雑な定義や、ビルドサーバーのインフラ設定）が壊れたとき、全員が僕の席を見る。
「Hey, fix it.（直しといてくれ）」
これでは結局、僕が「手動作業の奴隷」から「自動化ツールの奴隷」にジョブチェンジしただけだ。
僕が休暇を取ったり、あるいは別の会社に転職したりした瞬間、この文化は死ぬ。
それを防ぐために、僕は最後の仕上げに取り掛かった。
1. 「秘伝のタレ」を捨て、コードに語らせろ
まず着手したのは、徹底的な**「脱・属人化」**だ。
日本の老舗ウナギ屋なら「秘伝のタレ」は価値があるが、ソフトウェア開発においてそれは「負債」でしかない。
僕はWikiに長々と書いていた「トラブルシューティング集」を全部消した。
誰も読まないからだ。
その代わり、**「Infrastructure as Code (IaC)」**を徹底した。ビルドサーバーの設定も、環境変数も、すべてコード化してリポジトリに入れた。
そして、チームに新しいルールを導入した。
「自動化のタスクは、持ち回りで担当する」
WPFの機能実装（Feature work）は得意な人がやればいい。でも、パイプラインのメンテナンスやスクリプトの改修は、スプリントごとに担当者をローテーションさせたんだ。
最初はボブも嫌がった。「俺はXAMLを書きたいんだ、YAMLなんて書きたくない」と。
僕はこう説得した。
「ボブ、君が世界最高のWPFエンジニアなのは知ってる。でも、もしビルドが壊れて、僕が病気で寝込んでたら、君の最高なコードはお客さんに届かない。デリバリーまで含めてがエンジニアリングだろ？」
彼が渋々担当した週、案の定パイプラインが壊れた。彼は半日かけてそれを直した。
翌日、彼は目を輝かせて言った。
「あそこ、もっとわかりやすく書き直しておいたぞ。あんなスパゲッティコード、俺が許さないからな」
これでいい。
全員が「ツールの管理者」になった瞬間、そのツールはチームのDNAになる。
2. オンボーディングこそが最強のテスト
効率化の文化が本物かどうかを試す、最高のテストがある。
それは**「新入社員（New Hire）」**だ。
半年後、チームに新しいエンジニア、マイクが入ってきた。
以前のプロセスなら、彼のPCに開発環境を構築するだけで3日はかかっていただろう。Wordの手順書を読み解き、特定のバージョンのSDKを探し回り、共有フォルダのアクセス権を申請し……。
でも今回は違う。
僕は彼に、たった一つのPowerShellスクリプト（Setup-DevEnv.ps1）と、ReadMeのリンクを渡した。
「マイク、コーヒーを入れてくる間にこれを実行しておいて」
15分後、彼がコーヒーを一口飲む頃には、Visual Studioが立ち上がり、必要なライブラリは全て復元され、ローカルでアプリが起動していた。
「Day 1 Commit（入社初日のコミット）」
これが僕たちの新しい目標になった。
入社したその日に、環境構築を終え、最初の小さな修正を行い、本番（またはステージング）環境にデプロイまで完了する。
これができれば、そのチームの効率化レベルはワールドクラスだ。
マイクは感動していた。
「前の会社では環境構築に1週間かかったよ。ここは魔法の国か？」
この感動こそが、彼を次の「効率化の信者」に変える。彼はその後、誰よりも積極的にこのスクリプトをメンテナンスしてくれるようになった。
文化とは、説教によって伝わるものではない。**「体験」**によってのみ伝承されるのだ。
3. 「浮いた時間」をどう使うか：エンジニアの生存戦略
さて、効率化によってチーム全体で週に数十時間の「余白」が生まれた。
ここで最も重要な話をしよう。
「その時間で、もっと仕事をしてはいけない」
経営者やマネージャーは、空いた時間を見つけるとすぐに新しいタスク（機能追加）を詰め込もうとする。これは「パーキンソンの法則」と呼ばれる現象だ。
もし君が、効率化して浮いた時間で、単に「以前の2倍の量のコーディング」をしてしまったら、君はただの「都合のいい馬車馬」になってしまう。疲弊して燃え尽きるだけだ。
僕はチームで合意を取り、浮いた時間の20%を**「投資（Investment）」**に使うことにした。
Googleの「20%ルール」のようなものだが、もっと泥臭い。
- リファクタリング: WPFの古いコードビハインドをMVVMに書き直す。
- 学習: 新しい .NET の機能を試す、Rustを触ってみる。
- ツールの改善: さらに楽をするためのスクリプトを書く。
マネージャーにはこう説明した。
「この20%は休憩時間ではありません。将来の借金を返済する時間です。これをやることで、来年の開発速度がさらに10%上がります」
海外のテック業界は、技術の移り変わりが残酷なほど速い。
C# WPFは素晴らしい技術だが、Web（BlazorやReact）やモバイル（MAUI）の波は止まらない。
目の前のタスクをこなすだけでは、自分の市場価値（Market Value）は徐々に下がっていく。
効率化の本当の目的は、会社のためじゃない。
君自身が、最新の技術を学び、エンジニアとして生き残り続けるための「時間」を確保するためだ。
4. あなたは「コーダー」か、「エンジニア」か
この一連の改革を通じて、僕自身の評価はどうなったか？
「コードを書くのが速い日本人」という評価は消えた。
代わりに**「チーム全体の生産性を底上げするエンジニア（Force Multiplier）」**という評価がついた。
海外のジョブマーケット、特にシニア以上のポジションで求められるのは、単独でのコーディング能力よりも、この「周囲への影響力」だ。
「君がいると、周りの人間まで優秀になる」
これこそが、最高の賛辞であり、年俸交渉における最強のカードになる。
「C#が書けます」というエンジニアは世界中に五万といる。
でも、「カオスな現場に入り込み、文化を変え、自走する効率的なチームに作り変えることができます」というエンジニアは、どこに行っても取り合いになる。
5. 最後に：日本から世界を目指す君へ
もし君が今、日本の現場で「無駄な会議」「謎の承認フロー」「手動エクセル管理」に殺意を覚えているなら。
おめでとう。君には海外で通用する才能がある。
その「怒り」や「違和感」こそが、君の武器だ。
海外に出れば、魔法のように全てが解決しているわけじゃない。
むしろ、文化の違いや言語の壁もあって、カオスな現場も多い。
でも、だからこそチャンスがある。
「空気を読む」のが得意な日本人だからこそ、その場の空気が淀んでいることに気づき、それを「変える」ための道筋を描けることがあるんだ。
技術（C#やWPF）はあくまでツールだ。
本当の成果物は、コードそのものではなく、そのコードによって生まれた**「自由な時間」と「創造的な文化」**だ。
さあ、Visual Studioを開こう。
でもその前に、周りを見渡してみてほしい。
君の隣の同僚は、つまらない単純作業で死んだ目をしていないか？
君自身は、昨日の自分と同じことを繰り返していないか？
もしそうなら、コードを書く手をとめて、まずは「空気を変える」ことから始めよう。
その先には、きっと君が想像するよりもずっとエキサイティングなエンジニアライフが待っているはずだ。
Good luck. And happy coding!
コメント