「なんか、このプロジェクト嫌な予感がする…」その直感、言語化できますか？
どうも、みなさん。海外の某所で、C#とWPFをメインに、主に金融系や業務系のエンタープライズ向けデスクトップアプリの設計・開発をやっている、しがないITエンジニアです。
突然ですが、エンジニアとして働いていて、こんな経験ありませんか？
プロジェクトが始まった当初は、みんないい感じで、スケジュールも順調。「今回はイケる！」なんて思ってたのに、中盤を過ぎたあたりから、じわじわと空気が悪くなっていく。
最初は「ちょっとした遅れ」だったはずが、いつの間にか「週末出勤」。
「仕様の軽い確認」だったはずが、クライアントとの「紛糾する会議」。
そして気づいた時には、バグリストは真っ赤、リリース日は目前、チームは疲弊しきって、誰もが下を向いてキーボードを叩いている…。
いわゆる「デスマーチ（Death March）」ってやつですね。
この業界にいると、悲しいかな、一度や二度は経験しちゃう「あるある」です。
僕もね、海外に来てから特に、いろんなプロジェクトに参加させてもらいました。C#のWPFって、結構ニッチながらも、企業の基幹システムとか、一度作ると10年、15年使われるような、絶対に止められないシステムの開発が多いんです。だから、プロジェクトの失敗がマジで「洒落にならない」レベルの損害に繋がることもあって。
そんな中で、僕は数々の「成功」と、それ以上に多くの「失敗（あるいは、失敗しかけたプロジェクト）」の修羅場をくぐり抜けてきました。
そのたびに、プロジェクトが終わってから「なんで、こうなったんだっけ？」って反省会をするわけです。
「あそこの仕様変更がキツかったよな」とか「Aさんの離脱が痛かった」とか、いろいろ理由は出てくる。
でも、本当にそうでしょうか？
僕が多くの経験から学んだ、一つの「人生術」とも言える結論があります。
それは、**「プロジェクトの失敗は、ある日突然『爆発』するんじゃない。それは、ずっと前から存在していた『静かな亀裂』が、ついに限界を迎えた結果だ」**ということです。
ダムが決壊する時って、いきなり全部が崩れるんじゃなくて、最初は壁に小さなヒビが入って、そこから水が「ちょろちょろ」と漏れ出すところから始まるじゃないですか。
プロジェクトも全く同じです。
問題は、僕たちエンジニアが「コードを書くこと」に集中しすぎたり、日々のタスクに追われたりして、その「ちょろちょろ」という小さな漏れ、つまり「静かなる亀裂（The Silent Cracks）」を見逃してしまうことなんです。
特に、僕のように海外で働いていると、この「亀裂」が余計に見えにくい。
なぜなら、言語や文化の壁があるから。
例えば、日本なら「うーん、ちょっとこれは…」と誰かが言いにくそうにしている「空気」で、「あ、ヤバいかも」って察知できるじゃないですか。
でも、海外（特に多国籍チーム）では、その「空気」は存在しないか、あるいは全く違う形で現れます。
こっちのマネージャーが「We are perfectly on track!（完璧にスケジュール通りだよ！）」と笑顔で言っていても、それが「本当に順調」なのか、「部下を鼓舞するためのポーズ」なのか、はたまた「彼は何も分かっていない」のか、真意を掴むのが難しい。
だからこそ、僕たち海外で働くエンジニアは、コードを書く技術と同時に、この「静かなる亀裂」を意識的に、論理的に「検知」するスキルを磨かないといけない。
これは、自分の身を守り、キャリアを守り、そして何より、貴重な人生の時間を「無駄なデスマーチ」から守るための、最強のサバイバル術です。
このブログでは、僕がこれまでのキャリアで「あ、これ、ヤバいやつの前兆だ」と気づいてきた、**プロジェクト崩壊の初期症状＝「静かなる亀裂」**について、徹底的に深掘りしていきます。
特に、以下の3つの「亀裂」にフォーカスします。
- 見えざるスコープクリープ（Unseen scope creep）
- クライアントからの「これ、ついでにやっといて」という悪意なき（あるいは悪意ある）小さな要求が、いかにしてプロジェクト全体を不安定にする雪だるまになるか。
- コミュニケーションの断絶（Communication breakdowns）
- 明確なアップデートや共通認識が「静かに」消えていく恐怖。Slackのレスが遅くなった、定例が飛ばされ始めた…そのサインの意味。
- リソースの歪み（Resource strain）
- 「赤信号」が灯るずっと前から始まっている、チームの過労と予算の圧迫。特定の「ヒーロー（犠牲者）」にタスクが集中し始めたら、それは崩壊のサイン。
「なんか嫌な予感がする」というその直感を、ちゃんと「言語化」できるようになること。
それが、海外でエンジニアとして賢く、たくましく生き抜くための第一歩です。
今回は、まず「起」として、なぜこの「静かなる亀裂」に気づくことが重要なのか、特に海外で働くエンジニアにとって、それがどれだけクリティカルな問題なのかについて、僕の経験を交えてお話ししました。
次の【承】では、さっそく一つ目の亀裂、「見えざるスコープクリープ」の具体的な兆候と、僕が実際に体験した「地獄の入り口」となった事例について、詳しく解説していきたいと思います。
地獄への道は「これ、ついでに」で舗装されている。見えざるスコープクリープの罠
【起】で、「プロジェクト崩壊のサインは、静かな亀裂（Silent Cracks）から始まる」って話をしました。
じゃあ、その「亀裂」の中で、僕たちエンジニアが最も遭遇しやすく、そして最も「断りにくい」ヤツは何か。
それが、一つ目のテーマである**「見えざるスコープクリープ（Unseen scope creep）」**です。
スコープクリープって言葉自体は、聞いたことありますよね。「仕様変更の積み重ねで、いつの間にかプロジェクトの範囲（スコープ）が肥大化しちゃう」ってやつです。
でも、僕がここで言いたいのは、会議室で決まるような「正式な仕様変更」のことじゃないんです。
あれはあれで大変ですが、少なくとも「見える」んですよ。
PM（プロジェクトマネージャー）が頭を抱えて、クライアントと交渉して、スケジュールが引き直されて…と、一応プロセスに乗っかる。
僕が「静かなる亀裂」と呼んで恐れているのは、もっと個人的で、もっと日常に潜む、**「水面下のスコープクリープ」**です。
それは、まるでチャットのDM（ダイレクトメッセージ）のように、静かに、個人的に忍び寄ってきます。
「ちょっとしたお願い」という名の悪魔
僕がまだ海外で働き始めて間もない頃、とあるクライアントの業務システム（もちろんC# WPF製）を開発していた時の話です。
そのプロジェクト、クライアント側の担当者（仮に「マーク」としましょう）が、すごく協力的でいい人だったんですよ。
ある日の午後、マークから僕に直接SlackのDMが来ました。
「やあ、さっきデモしてもらった画面、すごくいいね！ あ、そうだ、ついでに（by the way, just a quick favor…）なんだけど、一覧グリッドの合計金額のところ、もしマイナスだったら赤字で太字にしてくれる？ 5分で終わるっしょ？」
WPFエンジニアの皆さんなら分かりますよね。
DataGridの特定のセルだけ、条件（マイナスかどうか）でスタイルを変える。
ああ、DataTriggerかValueConverterをCellStyleに仕込めば一発だな、と。確かに、慣れてれば10分か15分で終わる作業です。
当時の僕は、「お、マーク、いいところに気づくな。しかも海外に来たからには、”Can-Do Attitude”（できるヤツだと思われたい）！」という思いもあって、二つ返事で「OK、マーク！ 任せとけ！」と返事しちゃったんです。
すぐにコードを修正して、「できたよ！」と返信。
マークからは「Wow, awesome! You are a rockstar! 🚀（最高！君はロックスターだ！）」と、絵文字付きの絶賛が飛んできます。
…気持ちいいですよね、正直（笑）。
これが、全ての始まりでした。
「ついで」が「ついで」を呼ぶ、恐怖の雪だるま
その2日後。またマークからDMが来ます。
「この前の赤字、すごく見やすいって評判だよ！ ところで、もう一つだけ（just one more thing）…マイナスだったら、そのセルだけじゃなくて、行全体を薄い赤色にハイライトできないかな？ その方がもっと分かりやすいと思うんだ」
…なるほど。
WPFのDataGridで、今度はCellStyleじゃなくてRowStyleか。DataTriggerをRowStyleに設定して…まぁ、さっきよりは面倒だけど、30分もあればできるか。
「OK、マーク！ やってみるよ！」
僕はまた、ローカルでさっと修正して、コミットして、ビルドに流しました。
マークからは、また「Perfect! Thanks a million! 🍻」と感謝の嵐。
…もう、お分かりですね？
その週末明け。今度は、マークが僕の席（当時はまだオフィス出社がメインでした）に、ニコニコしながらやってきました。
「やあ、君は天才だ。チームのみんなが、あの行ハイライトを絶賛してる。…ところで、今、ちょっといい？（Got a minute?）」
嫌な予感がしました。
「あのハイライト機能なんだけど、Excelエクスポート機能にも反映できるかな？ ついでに、PDFで出力するレポートにも、同じロジックで色を付けたいんだよね」
……終わった、と思いました。
僕が10分で対応した「セルの色変更」は、WPFの「View（見た目）」だけの話でした。
でも、Excelエクスポート機能やPDFレポート機能は、Viewとは全く別のレイヤーで動いています。
エクスポートロジックのコア部分に手を入れないと、その「条件付き書式」は実装できません。
しかも、そのロジックは僕の担当箇所じゃなく、別のシニアエンジニアが設計した、めちゃくちゃ複雑な部分でした。
おまけに、エクスポート機能は、パフォーマンスのために最適化されていて、ViewのロジIC（ロジック）なんて一切参照していません。
つまり、色付けの「条件（マイナスかどうか）」のロジックを、コア部分に（たぶん）コピペして、再実装する必要がある。
これ、**「ついで」**じゃないですよね？
どう安く見積もっても、調査と実装、テストまで含めたら、最低でも3人日（3MD）はかかる「中規模タスク」です。
僕が「いや、マーク、それは『ついで』じゃなくて、結構大きな変更になるよ。まずPMに相談しないと…」と、しどろもどろに答えると、マークは心底ガッカリした顔で、こう言いました。
「え？ でも、昨日は30分でやってくれたじゃないか。なんで急に『大きな変更』になるんだ？ 君は”ロックスター”なんだろ？」
なぜ、「見えざるスコープクリープ」はヤバいのか
この話、笑い話みたいに聞こえますが、マジで「静かなる亀裂」の典型なんです。
この小さな「ついで」が、なぜヤバいのか。分解してみましょう。
- 工数が見積もられていない（Undocumented）
- 当たり前ですが、僕が「サービス」でやった10分や30分の作業は、プロジェクトの公式な工数（見積もり）には一切入っていません。タスク管理ツール（Jiraとか）にも載っていません。
- PMが把握していない（Invisible）
- PMや他のチームメンバーは、僕がマークと「裏で」そんなやり取りをしていることを全く知りません。彼らから見たら、僕は「割り当てられたタスク（でもない何か）に、勝手に時間を使っている」状態です。
- 期待値がバグる（Expectation Creep）
- これが一番タチが悪い。クライアント（マーク）は、「エンジニアにDMすれば、10分で仕様変更してくれる」という間違った成功体験を積んでしまいました。彼の「普通」のハードルが、僕のせいでバグってしまったんです。
僕の「良かれと思って」やった親切、僕が欲しかった「ロックスター」という承認欲求が、プロジェクト全体を歪ませる「亀裂」の第一打になってしまったんです。
もし僕が、あのままExcelとPDFの変更も「なんとかしますよ…（週末出勤で）」とか言って引き受けていたら？
僕は、自分の本来のタスクを遅らせ、その遅れを取り戻すために残業し、マークは「アイツに頼めば何でもやってくれる」と学習し、さらに無茶な要求をDMで送ってくる…。
そして、僕が疲弊して倒れるか、PMが「なんでスケジュールがガタガタなんだ！」とキレるか、あるいは製品の品質がボロボロになるか…どれかが起きるまで、この負のループは止まりません。
これが、僕の体験した「デスマーチの入り口」でした。
【承】のまとめ：あなたの「親切」が亀裂の始まり
特に僕らみたいに、海外で「外国人エンジニア」として働いていると、現地の同僚やクライアントに対して「役に立つヤツ」「仕事が早いヤツ」って思われたいじゃないですか。
日本人的な「和を以て貴しとなす」精神で、「いや、それはプロセス違反なんで」と角が立つことを言いたくない。
でも、その「小さな親切」や「個人的な頑張り」こそが、プロジェクトのダムに穴を開ける、最初の「静かなる亀裂」なんです。
じゃあ、どうすればよかったのか？
マークに「Wow, awesome!」って言われながら、プロジェクトも守る「人生術」はなかったのか？
もちろん、あります。
それは、「No」と言うことじゃない。
それは、**「可視化（Visibility）」**という武器を使うことです。
僕がマークに言うべきだった、たった一つのセリフ。
「マーク、いいアイデアだね！ それ、すごく重要だと思うから、忘れないように公式のチャネル（JiraでもSlackの全体チャンネルでもいい）に投げといてくれる？ PMにも共有したいからさ！」
これだけです。
これなら、マークの顔を立てつつ、その「ついで」をPMとチーム全員の「見える」場所に引きずり出せる。
そうすれば、それが10分の作業なのか、3人日の作業なのかを、チームとして「公に」判断できます。
「見えざるスコープクリープ」の最大の敵は、「可視化」です。
あなたの身を守るため、そしてプロジェクト全体を守るために、「裏DM」での「ついで」は、全部「表」に出してやりましょう。
…と、一つ目の亀裂だけで、こんなに長くなってしまいました（笑）。
でも、それくらいこの「水面下のスコープクリープ」は根が深い問題なんです。
そして、この「見えざる作業」が積み重なった結果、次なる、さらに深刻な「亀裂」が顔を出します。
それが、二つ目のテーマ、**「コミュニケーションの断絶」**です。
【転】では、なぜチームのSlackが静かになるとヤバいのか、明確なアップデートが消えることが何を意味するのか、その恐怖についてお話ししていきましょう。
Slackが静かになったら赤信号。チームを腐らせる「コミュニケーションの断絶」という病
【承】では、「これ、ついでに」から始まる「見えざるスコープクリープ」が、いかにエンジニア個人とプロジェクトを疲弊させるか、という話をしました。
僕がクライアントのマークからDMで直接、WPFの画面修正を頼まれて、それが雪だるま式に膨れ上がった、あの苦い経験です。
さて、この「見えざるスコープクリープ」が横行し始めると、次にプロジェクトを襲う「静かなる亀裂」は、もっと深刻な症状を引き起こします。
それが、**「コミュニケーションの断絶（Communication breakdowns）」**です。
「え？ スコープクリープ（仕事が増えること）と、コミュニケーション（会話が減ること）って、むしろ逆じゃない？」
そう思うかもしれません。仕事が増えてヤバくなったら、普通は「助けて！」「終わらん！」「どうなってんだ！」って、チャットや会議が「うるさく」なりますよね。
そう、それならまだマシなんです。
「うるさい」うちは、まだエネルギーが残っている証拠。問題が「可視化」されている証拠です。
本当に恐ろしいのは、プロジェクトが炎上する直前の、あの**「不気味な静けさ」**なんです。
なぜ「裏DM」がチームを殺すのか
思い出してください。僕はマークからの「ついで」の依頼を、SlackのDMという「裏」で処理していました。
これ、僕とマークの間では、コミュニケーションが「密」になっているように見えますよね。
でも、プロジェクト全体で見たら、どうでしょう？
PM（プロジェクトマネージャー）や、他のチームメンバー（例えば、僕の変更が影響するかもしれないサーバーサイドの担当者や、QA（品質保証）チーム）は、僕とマークが水面下で「仕様変更」を行っていることを、全く知りません。
僕が「サービス残業」でマークの依頼を片付ければ片付けるほど、公式のタスク管理ツール（JiraやAzure DevOps）に書かれている「表向きの進捗」と、水面下で進んでいる「裏の進捗（というか、負債）」の乖離（かいり）が、どんどん開いていきます。
こうなると、何が起きるか。
まず、公式チャンネルや定例ミーティングが「形骸化」します。
PM「今週の進捗どう？ 遅れとか問題点は？」
僕（心の中）「（ヤバい、マークのExcelエクスポート機能の調査に時間取られて、本来のタスクAが全然進んでない。でも、ここで『マークの依頼で…』なんて言ったら、DMをサボってたと怒られるし、マークにも迷惑がかかる…）」
僕（表向き）「あ、はい。タスクA、順調です。特に問題ありません」
……はい、終わりました。
僕は、プロジェクト全体に対して「嘘」をついたことになります。
この瞬間、僕は「問題を解決するエンジニア」から、「問題を隠蔽（いんぺい）する共犯者」に成り下がったわけです。
こうなると、もう公式の場では誰も本当のことを言わなくなります。
- 「あの機能、本当はAさん（僕）の変更待ちだけど、本人が『順調』って言ってるし、なんか聞きにくいな…」
- 「PMは『オンスケジュールだ』ってクライアントに報告してるけど、現場の感覚と全然違う。でも、波風立てたくないし、黙っておこう…」
【承】で僕がやったような「裏DM」での親切が横行すると、チームの「公式なコミュニケーションライン」は信頼を失い、機能不全に陥るんです。
みんなが「どうせ本当のことは誰も言ってない」と悟り始め、Slackのチームチャンネルは、業務連絡と「お疲れ様です」の挨拶だけが流れる、静かな墓場のようになります。
「言ったつもり」と「静かなる失踪」の恐怖
特に僕らみたいに、海外の多国籍チームで働いていると、この「静けさ」は、さらに別の要因で加速されます。
それが、**言語と文化の壁が生み出す「認識のズレ」**です。
日本国内のプロジェクトなら、阿吽（あうん）の呼吸とか、「行間を読む」文化がありますよね。
マネージャーが「これ、なんとか金曜までに “お願い” できないかな？」と言ったら、それは「金曜までに死んでも終わらせろ」という「業務命令」だと、みんな察します（笑）。
でも、海外、特に英語が共通語の多国籍チームでは、その「察する」は一切通用しません。
だから、みんな「明確に」「ロジカルに」話そうと努力します。
でもね、「明確に言ったつもり」が、相手に「明確に伝わっている」とは限らないのが、この世界の難しいところなんです。
僕が体験した、背筋が凍った例をお話ししましょう。
C# WPFで、ある複雑な金融商品の入力画面を作っていた時です。設計レビューの会議で、技術的にかなり際どい要求（入力中にリアルタイムで、別サーバーのAPIを叩いてバリデーションしてほしい、とか）が出てきました。
僕は、その場で「うーん、パフォーマンスに影響が出るかも…」と懸念を伝えつつ、
“Well, maybe we can try to implement a prototype…”
（うーん、たぶん、プロトタイプを実装してみることはできるかも…）
と答えました。
僕のニュアンスとしては、「保証はできないけど、調査としてプロトタイプを作る『だけ』なら、時間があればやってもいいよ」という、かなり消極的な「可能性」の提示でした。
ところが、その2週間後。
PMがクライアントに提出した進捗資料を見て、僕は目を疑いました。
そこには「（僕の担当機能）リアルタイム・バリデーション：実装確定（Confirmed）」と、バッチリ書いてあるじゃないですか。
慌ててPMに「おい！ 俺は『Maybe（たぶん）』って言っただけだぞ！」と抗議したら、PMはキョトンとした顔で、こう返してきました。
「え？ だって君、会議で『できる（We can try…）』って言ったじゃないか。だから『Confirmed（確定）』で進めてるよ」
……これが、海外（というか、非ネイティブ同士の英語）の怖さです。
僕の使った「Maybe（たぶん、かも）」という日本語的な「逃げ」のニュアンスは完全に無視され、「We can try（我々はトライできる）」という「事実」だけが切り取られて、「約束（Commitment）」に変換されてしまったんです。
これ、僕が悪いんです。
海外のビジネスシーンでは、「Maybe」は「Yes」なんです。「No」と言わない限り、それは「引き受けた」のと同じ。
僕は「No, we can’t do that. Because…（いや、それはできません。なぜなら…）」と、明確に「No」を突きつけるべきだったんです。
この「言ったつもり」「伝わったはず」という小さな認識のズレが積み重なると、エンジニアはどうなるか？
**「静かに失踪（The Quiet Disappearance）」**します。
つまり、会議で発言しなくなるんです。
だって、下手に発言したら、「Maybe」が「Confirmed」にされて、自分のタスクが勝手に増えるんですよ？ 怖すぎますよね。
だから、一番安全な生存戦略は、「会議ではカメラをオフにし、ミュートにし、ただ存在を消すこと」になります。
Slackで質問されても、即レスしない。文章に「証拠」が残ると怖いから、わざと曖昧に返したり、時間を置いたりする。
こうして、あれだけ活発だったチームから「会話」が消えていきます。
明確なアップデートや、技術的な議論、困っていることの共有…そういった「健全なノイズ」が一切なくなり、プロジェクトは「不気味な静けさ」に包まれます。
誰もが、自分の身を守るために「黙る」ことを選ぶ。
でも、その静けさの裏では、【承】で話した「見えざるスコープクリープ」や、「言ったつもり」の「認識のズレ」爆弾が、刻一刻と時を刻んでいるんです。
【転】のまとめ：あなたの「アホな質問」がチームを救う
この「静かなる亀裂」＝「コミュニケーションの断絶」は、本当にタチが悪い。
なぜなら、プロジェクトが「順調だから静かなのか」、それとも「腐敗しているから静かなのか」が、外から見分けがつきにくいからです。
でも、確実に言えることがあります。
「エンジニアが黙り始めたプロジェクトは、必ず失敗する」
僕たちC# WPFエンジニアが扱うシステムって、業務ロジックが複雑なものが多いですよね。
View（XAML）とViewModel（C#）の連携、Model（ビジネスロジック）の設計、DBとのやり取り…これら全てが、密接に絡み合っています。
この複雑なシステムを、コミュニケーション無しで、個々人の「だろう運転」で作れるわけがないんです。
じゃあ、もしあなたのプロジェクトで「あれ、最近みんな静かだな…」という嫌な予感を感じたら、どうすべきか？
これは、海外で生き抜くための「人生術」です。
それは、**「空気を読まずに、アホな質問を公式チャンネルでする」**ことです。
日本人的には「こんな当たり前のこと聞いたら、アホだと思われるかも…」と躊躇（ちゅうちょ）してしまいますよね。
でも、その「当たり前」の認識が、チーム全員でズレているかもしれないのが、この「静かなる断絶」の本当の怖さなんです。
だから、あえてSlackの全体チャンネルで、こう投稿するんです。
「（わざとアホな感じで）すいませーん、ちょっと基本的な確認なんですけど、今週の最優先タスクって、Jiraの【ABC-123】（←チケット番号）の認識で合ってますよね？ マークからDMで別の修正も頼まれてるんですけど、どっち先にやるべきでしたっけ？」
これが、最強の一手です。
この一文で、
- 「静かなチャンネル」に、あえて「ノイズ」を発生させられる。
- 「最優先タスク」という「共通認識」を、全員の前で再確認できる。
- マークからDMが来ているという「裏の動き」を、PMやチーム全員に「公に」暴露（可視化）できる。
これで、PMは「おい、DMで何頼まれてるんだ？ そっちは優先度低いから、まずABC-123をやってくれ」と、公式に「交通整理」せざるを得なくなります。
静けさは破られ、隠蔽されていた問題が「可視化」され、コミュニケーションが（強制的に）再開されます。
コミュニケーションの断絶は、プロジェクトという生命体の「血流」が止まっている状態です。
あなたが「アホな質問」というカテーテルを突き刺して、無理やりにでも血流を再開させるんです。
この「静かな亀裂」を放置すると、ダムの水位（＝隠れタスク、認識のズレ）は上がり続け、ついに最後の亀裂に到達します。
ダムの壁、つまり「リソース（人・予算）」そのものが、限界を迎えるんです。
次の【結】では、これら全ての亀裂が、最終的に「誰か」の犠牲の上にどう爆発するのか。「リソースの歪み」という、プロジェクト崩壊の最終局面についてお話しします。
「あの人が頑張ってるから」は崩壊の序曲。ヒーローの犠牲で成り立つプロジェクトは、必ず沈む
【起】で、プロジェクト崩壊は「静かなる亀裂」から始まると言いました。
【承】で、その第一の亀裂として、クライアントの「ついでに」から始まる「見えざるスコープクリープ」の恐怖を語りました。僕がC# WPFの画面修正をDMで安請け合いし、雪だるま式にタスクが膨らんだ、あの話です。
【転】では、その結果として「裏DM」が横行し、チームが本当のことを言わなくなる「コミュニケーションの断絶」という、不気味な静けさの恐ろしさを解説しました。
さて、今日はついに【結】です。
これら二つの亀裂——「見えない仕事（スコープクリープ）」と「言えない空気（コミュニケーション断絶）」——が重なった時、プロジェクトのダムは最後の、そして最も致命的な亀裂に直面します。
それが、**「リソースの歪み（Resource strain）」です。
もっと生々しく言えば、「特定の誰かの犠牲」**です。
「ヒーロー」の誕生と「ボトルネック」という現実
【承】の物語に戻りましょう。
クライアントのマークからDMで「Excelエクスポートも赤くしてよ」という、3人日クラスの無茶振りをされた僕。
【転】で語ったように、僕はPMにそれを隠し、「（公式タスクは）順調です」と嘘をつきました。
さあ、どうなるでしょう？
僕は「ロックスター」であり続けたいし、マークをガッカリさせたくない。でも、PMにはバレたくない。
僕が取る行動は、一つしかありません。
「サービス残業」そして「週末出勤」です。
僕は、平日の日中はPMから割り当てられた「公式のタスクA」を進めているフリをしながら、頭の半分は「どうやってあのPDFのロジックに手を入れるか」を考えています。
そして、定時後。みんなが「お疲れ！」と帰っていく中、僕は一人オフィスに残り、マークのための「裏タスク」のコードを書き始めます。
もちろん、この時間はプロジェクトの公式な工数には一切カウントされません。
周りから見たら、どう見えるでしょう？
クライアントのマークからは、「あいつは最高だ！ いつでもDMすれば、魔法のように問題を解決してくれる！」と、**「ヒーロー」として崇められます。
PMからは、「あいつは最近やたら残業してるな。でも、タスクAの進捗はイマイチだ。何をやってるんだ…？」と、「非効率なヤツ」と見られ始めます。
チームの同僚からは、「Aさん（僕）が何をやってるか分からない。彼待ちのタスクがあるけど、Slackで聞いてもレスが遅い。彼が『ボトルネック』**だ」と、不満の対象になります。
最悪ですよね。
僕は「良かれと思って」頑張っているのに、マーク以外の全員から、僕の評価はダダ下がりです。
この「リソースの歪み」が恐ろしいのは、【転】で話した「静けさ」とセットでやってくることです。
チームは静かだから、誰も僕が「裏タスク」で溺れていることを知りません。
僕は「ヒーロー」としての（歪んだ）プライドがあるから、誰にも「助けて」と言えません。
こうして、プロジェクトの「見えない負債」は、すべて僕という一人のエンジニアの「時間」と「健康」というリソースに、集中砲火のように浴びせかけられます。
赤信号が灯る「前」の、本当のサイン
ご提示いただいたフックに、「赤信号が灯る（obvious red flags）前のサイン」とありました。
まさに、これなんです。
「プロジェクトの予算が尽きました！」とか「リリースに間に合いません！」というのは、もう「赤信号」です。手遅れです。
そのずっと前に、ダムの壁（リソース）が軋む「ピシッ…ピシッ…」という音が聞こえているはずなんです。
僕が体験した、その「軋む音」の具体例を挙げましょう。
- コミットログが「雑」になる
- 普段は「【WPF-123】会員一覧画面のViewModelに検索ロジック追加」みたいに丁寧に書いていた僕が、「Fixes」「Update」「修正」みたいな、どうでもいいコミットメッセージを連発し始めます。
- なぜなら、「マークのExcel機能の修正」なんて、公式のJira番号がないから書けないからです。雑なログは、「何かを隠している」サインです。
- 特定のエンジニアが「レビュー」に応じなくなる
- 僕が「ボトルネック」になっていく過程です。同僚が書いたコードのプルリクエスト（PR）が飛んできても、「裏タスク」で手一杯の僕は、それを見る時間がありません。「LGTM（Looks Good To Me）」と、中身を見ずにApproveするようになります。
- C# WPFの開発では、不適切な
Bindingや、メモリリークを起こしかねないEvent Handlerの登録ミス、async/awaitの不適切な使い方など、レビューでしか防げないバグがたくさんあります。僕という「リソースの歪み」が、コード品質の「亀裂」に直結する瞬間です。
- 「大丈夫です、忙しいですが」が口癖になる
- これは特に、僕ら日本人エンジニアが海外でやりがちな「最悪のサイン」です。
- PMが「Hey, 大丈夫か？ 顔色悪いぞ」と声をかけてきても、僕は「I’m fine, just busy.（大丈夫です、ただ忙しいだけなんで）」と笑顔で返してしまう。
- この「I’m fine」は、海外のマネージャーにとっては「No Problem（問題なし）」としか翻訳されません。僕がSOSを「隠蔽」したことで、PMは最後のアラートを検知するチャンスを失います。
これらすべての「歪み」が蓄積された結果、どうなるか。
ある朝、僕のPCはログインされることはありませんでした。
そう。僕が、燃え尽きて（Burn out）、会社を休んだからです。
あるいは、僕が無理やり仕上げた「公式タスクA」が、バグだらけでQA（品質保証）から大量に突き返され、リリースが延期になるか。
どちらにせよ、プロジェクトは「詰み」です。
僕という「ヒーロー（という名の犠牲者）」の犠牲の上に成り立っていた砂上の楼閣は、僕一人が倒れただけで、ガラガラと崩れ落ちるんです。
【結】あなたの価値は「時間」だ。エンジニアの最強の人生術
さて、ここまで【起承転】と、プロジェクトが崩壊していく「静かなる亀裂」の連鎖を、僕のWPFエンジニアとしての失敗談を交えてお話ししてきました。
じゃあ、どうすればよかったのか？
このデスマーチを回避し、海外でエンジニアとしてハッピーに働くための、究極の「人生術」とは何か？
それは、僕があの【承】の時点、つまりマークから「5分で終わるっしょ？」とDMが来た、あの瞬間に立ち返る必要があります。
僕が【承】で提示した対策は、「その依頼、公式チャンネルに投げてくれる？」という「可視化」でした。
僕が【転】で提示した対策は、「この認識で合ってますか？」と「アホな質問」をすることでした。
これらは全て、最後の【結】である、この「リソースの歪み」を防ぐための布石です。
エンジニア、特に僕らのような設計や開発を行う専門職にとって、「時間」こそが最強にして唯一の「リソース」です。
僕たちは、魔法使いじゃありません。クライアントが「欲しい」と言った機能を、指を鳴らして生み出せるわけじゃない。
僕たちは、クライアントの「要望（Want）」を、自分たちの「時間（リソース）」を使って、「コード（Value）」に変換する職人なんです。
だから、僕がマークに言うべきだった、たった一つの、しかし最強の「人生術」はこれです。
「No」を言うことではありません。
海外で「No, I can’t.（できません）」とだけ言うのは、ただの「感じの悪いヤツ」です。
「Yes, and…（はい、できます。そして…）」 または 「Yes, if…（はい、もし…ならできます）」
と、「条件」と「コスト」を提示して**「交渉（Negotiate）」**することです。
あの時、僕が「ロックスター」になろうとせず、冷静な「エンジニア」としてこう返していたら、未来は変わっていました。
「OK、マーク！ その赤字にする機能、いいね！
Yes, I can do that.（はい、できますよ）
And,（そして）それは僕の計算だと、ExcelとPDFのロジック修正も含めて、大体**3人日（3MD）**くらいかかりそうだ。
PM（マネージャーの名前）に相談して、今やってるタスクAと、どっちを優先（Prioritize）するか決めてもらってもいい？」
これこそが、僕たちエンジニアが身につけるべき、最強の「人生術」です。
この一言は、
- マークの要求を拒否せず、受け入れている（Yes）。
- 「ついで」ではなく「コスト（3人日）」がかかることを、プロとして明示している。
- 「裏DM」ではなく、PMという「公式ライン」に判断を委ねている。
- 僕の「リソース（時間）」が、タスクAとマークの依頼のどっちに割かれるべきか、「優先順位付け」のボールをマネジメントに返している。
これなら、僕はサービス残業をする必要も、嘘をつく必要も、燃え尽きる必要もありません。
マークは、自分の要求が「タダ」ではないことを学びます。
PMは、プロジェクトの「全体像」を正確に把握し、リソース（僕）を適切に再配分できます。
「静かなる亀裂」は、エンジニアの「自己犠牲」や「過剰な親切心」を栄養にして、育っていきます。
あなたのリソースは、あなたのものです。そして、プロジェクトの貴重な資産です。
それを「裏」で安売りせず、「表」で堂々と「交渉」のテーブルに乗せること。
それこそが、海外というタフな環境で、クライアントからもチームからもリスペクトされ、何より自分自身を守りながら生き抜くための、最も確実で、最もプロフェッショナルな「人生術」だと、僕は信じています。
コメント