その「完璧な計画」、なぜいつも崩壊するのか？
どうも！ ヨーロッパの片隅で、今日も元気にC#とWPFをこねこねしている、現役ITエンジニアです。海外で働きたい、もしくは働き始めたばかりの皆さん、毎日ワクワクしながらコード書いてますか？
さて、突然ですが、皆さんに質問です。
「あなたのプロジェクト、炎上してませんか？（笑）」
ドキッとした人、多いんじゃないでしょうか。
かくいう僕も、キャリアの初期（いや、今でもたまに…）は、数々のデスマーチを経験してきました。日本でも、そして海を渡ったここ、海外でも。
面白いことに、使う言語やツール、肌の色が違っても、プロジェクトが「ヤバい」匂いを放ち始めるときの空気感って、世界共通なんですよね。
特に、プロジェクトのキックオフ。あの独特の高揚感、覚えてますか？
クライアントもチームも集まって、「今回のプロジェクトは絶対に成功させよう！」と意気込む。プロジェクターには、それはそれは美しい「プロジェクト計画書」が映し出される。
色分けされた完璧なガントチャート。
全てのタスクが洗い出され、依存関係が明確に引かれ、マイルストーンが設定されている。見積もり工数もバッチリ。「これならイケる！」と誰もが確信する、あの瞬間。
…でも、どうでしょう。
あれから3ヶ月後。
気づけば、ガントチャートの進捗ラインは、現実から大きく遅れています。スケジュールは真っ赤っか。
ミーティングの空気は重く、「なぜ遅れているんだ」「誰のせいだ」みたいな、犯人探しが始まったりする。
さらに最悪なのが、「スコープクリープ」ってやつです。
「あれ、この機能、最初言ってましたっけ？」
「ああ、それはクライアントのXXXさんからの『ちょっとした』お願いでね…」
この「ちょっとした」が積み重なって、気づけば当初の設計書にはなかった機能が、しれっとマストハブ（Must-Have）扱いでねじ込まれている。僕らエンジニアは、WPFの画面設計（View）とロジック（ViewModel）を泣きながら修正するハメになる。
「またか…」
プロジェクトの遅延（オーバーラン）と、このスコープクリープ。
これって、エンジニアリングの世界じゃ「あるある」過ぎて、もはや「運命」とか「必要悪」みたいに諦めてません？
「計画通りに進まないのがプロジェクトだ」
「クライアントの要望が変わるのは当たり前」
確かに、それも一理あります。
でも、僕はずっと疑問だったんです。
「なんで、あんなに時間をかけて作った『完璧な計画』が、こうも毎回、見事に崩壊するんだろう？」
海外で働き始めて、いろんなバックグラウンドを持つ人たち（本当にいろんな人がいます）と仕事をするようになって、その疑問の「答え」が、少しずつ見えてきました。
結論から言うと、
「僕らが伝統的に使っているリスク管理の手法が、現代の複雑なソフトウェア開発に、まったく追いついてない」
ってことです。
ちょっと堅苦しい言い方になっちゃいましたね。
ぶっちゃけて言いましょう。
僕らが信じてやまない**「ガントチャート」や「WBS（作業分解構成図）」、そして工数を見積もるための「詳細なスプレッドシート」**。
これら「伝統的な」ツールって、実は、**「もうすでに起きている問題」や「目に見えているタスク」**を管理するのは得意なんです。
でも、**「これから起きるかもしれない、ヤバい問題」**を予測するのが、驚くほどヘタクソなんですよ。
「いやいや、ちゃんと『リスク管理表』も作ってるよ」って声が聞こえてきそうです。
わかります。僕も作ってました。「担当者が病気になる：5%」「仕様変更が発生する：15%」みたいなやつ。
でも、本当にプロジェクトを崩壊させるのって、そんな「リストアップできるリスク」じゃないんです。
プロジェクトが本当に炎上するとき、その根本には、計画書やスプレッドシートの「行間」に隠れていた、**「予期せぬ不安定要素（Unforeseen Instabilities）」**が必ず存在します。
例えば、
- 仕様書には書かれていない「クライアントの暗黙の期待」
- 一見シンプルに見えたWPFのUIが、実はとんでもない非同期処理の塊だった
- チーム内の「あの人、ちょっと話しにくいよね」という小さなコミュニケーション不全
- 誰も触りたがらない「秘伝のタレ」状態のレガシーコード
これらは、ガントチャート上の「タスクA：5人日」という青いバーには、決して現れてきません。
これらは、静かで、目に見えず、プロジェクトが順調に見えている間も、水面下で静かに、しかし確実に増殖していく「バグ」みたいなものです。
そして、ある日突然、プロジェクトの「クリティカルパス」と呼ばれる一番弱い部分を直撃し、すべてを連鎖的に崩壊させる。
「計画」が完璧であればあるほど、この「見えない敵」に対応する「遊び（バッファ）」がなくなり、崩壊のスピードは速くなる。
これが、僕が海外の現場で何度も目撃してきた、「プロジェクト・パフォーマンス問題」の恐ろしい正体です。
じゃあ、僕らエンジニアは、この「見えない敵」に対して、ただ祈ることしかできないんでしょうか？
「今回も炎上しませんように」って。
いや、そんなことはない。
この「予期せぬ不安定要素」の存在を最初から認め、それどころか、**「不安定なのが当たり前」**という前提でプロジェクトを組み立てる方法があります。
それは、特定のツール（例えば「Jiraを使え！」みたいな話じゃありません）を導入することではなく、僕らエンジニア自身の「マインドセット」と「働き方」を根本から変えるアプローチです。
このブログでは、教科書的なPMBOK（プロジェクトマネジメントの知識体系）には載っていない、僕が海外のC# / WPF開発の最前線で学んだ、「炎上を未然に防ぐ」ため、いや、「炎上してもすぐに鎮火させる」ための、超実践的なサバイバル術をお伝えしていこうと思います。
次回、「承」のパートでは、なぜ僕らがガントチャートや「神エクセル」を信じてしまうのか、その「甘い罠」について、さらに深掘りしていきます。
これを知るだけで、あなたのプロジェクトを見る目が、きっと変わるはずですよ。
ガントチャートと「神エクセル」という名の幻想
前回の「起」では、「完璧に見えたプロジェクト計画が、なぜいつも崩壊するのか？」という、耳の痛い話をしました。
その原因は、僕らがリストアップできる「既知のリスク」ではなく、計画書の行間に隠れている**「予期せぬ不安定要素」**にある、と。
今回は、「じゃあ、なんで僕らはその『不安定要素』に気づけないの？」という、さらに根深い問題に切り込みます。
その答えは、僕らがプロジェクト管理で「常識」として使っている、あの2大巨頭にあります。
そう。**「ガントチャート」と「神エクセル」**です。
断言しますが、これらを「信仰」している限り、プロジェクトの炎上は防げません。
「いやいや、ツールが悪いんじゃなくて使い方の問題でしょ」
その通り。その「使い方」が、根本的に現代のソフトウェア開発とミスマッチを起こしているんです。
海外の現場でも、もちろんこれらのツールは使われています。名前が「MS Project」だったり、「Smartsheet」だったり、「Google Sheets」だったりするだけで、本質は同じ。
なぜ僕らは、こんなにもこれらのツールに依存し、そして裏切られ続けるのか。
その「甘い誘惑」と「恐ろしい幻想」について、僕がWPFで痛い目を見た実例も交えながら、解き明かしていきましょう。
1. ガントチャートの「甘い誘惑」
まず、ガントチャート。
あれは、なぜあんなにも魅力的なんでしょうか？
誘惑その1：「すべてを管理できている」という全能感
プロジェクトって、本来はカオス（混沌）ですよね。
クライアントの曖昧な要望、チームメンバーのスキル差、未確定の技術仕様…。
考えるだけで不安になる、この「ぐちゃぐちゃ」なものを、時間軸に沿って、タスクという「バー」に分解し、依存関係を「矢印」で結ぶ。
この行為自体が、とてつもない「安心感」をもたらすんです。
マネージャーは、そのチャートを眺めて「よし、全体像が見えた」と満足する。
クライアントは、それを見て「おお、ちゃんと計画されている」と納得する。
でも、これが第一の罠。
ガントチャートは、「カオスを整理した」んじゃなくて、**「カオスに無理やりフタをした」**だけなんです。
僕が昔やった医療系のWPFアプリ開発がそうでした。
「A画面（患者情報入力）→ B画面（検査データ連携）→ C画面（結果表示）」
ガントチャート上は、綺麗な「滝（ウォーターフォール）」が描かれていました。
でも、現実は？
B画面のデータ連携APIが、実はとんでもないクソ仕様で、エラーハンドリングが考慮ゼロだった。そのせいで、A画面の入力チェックを根こそぎ見直すハメになり、C画面の表示ロジックも全部やり直し。
チャート上の「矢印」は、単なる「順番」を示していただけで、そこにある「技術的な地雷」については、何も教えてくれなかったんです。
誘惑その2：「進捗50%」という数字のマジック
ガントチャートの進捗ラインって、気持ちいいですよね。
青いバーが緑色に変わっていく。「進捗率：50%」という数字は、チームに「順調だ」という（誤った）自信を与えます。
でも、ソフトウェア開発における「50%」ほど、アテにならない数字はありません。
「WPFの画面（View）、デザイン通りにXAMLで組めました！ これでタスクの50%完了です！」
若手エンジニアが元気に報告してくれたとしましょう。
素晴らしい。でも、残りの50%は？
「はい、あとはViewModelとバインドして、非同期でデータを取ってくるロジックを書くだけです！」
…地獄はそこからですよね？
- データの読み込み中に、画面が固まらないように非同期処理（async/await）を入れる。
- 読み込み中は、ちゃんとローディングアニメーション（BusyIndicator）を出す。
- APIからエラーが返ってきたら、適切なメッセージをダイアログで表示する。
- ユーザーが入力中に別の操作をしたら、入力内容を破棄するか確認する。
- しかも、そのカスタムコントロール、特定のWindowsバージョンだと描画が崩れるんですけど…？
これら、C# / WPF開発者なら「当たり前」の考慮事項が、ガントチャート上の「画面作成：10人日」というタスクには、一切含まれていない。
見た目が50%（むしろ80%）できていても、本当に面倒な「見えないロジック」は0%かもしれない。
でも、チャート上は「順調」と報告されてしまう。これが、のちに「気づいたら遅延していた」を生む第二の罠です。
2. 「神エクセル」という名の魔窟
さて、もう一方の雄、エクセル（またはスプレッドシート）です。
日本では特に「神エクセル」と呼ばれ、もはやインフラですよね。
海外でも、JiraやConfluenceといった専用ツールを使いつつも、なぜか「ちょっとした管理」には、みんなスプレッドシートを使いたがります。なぜか？
自由すぎるから。
タスク管理、課題管理、バグリスト、仕様変更履歴、テストケース、工数見積もり、担当者アサイン表、メンバーの休暇予定…
これらすべてを、1枚のシート（あるいは1つのブック）でやろうとする。
これが「魔窟」の入り口です。
限界その1：「情報が死んでいる」という現実
エクセルが致命的なのは、そこに書かれた情報が、ただの「テキスト（文字列）」だということです。
つまり、**「情報が死んでいる」**んです。
例えば、課題管理シートにこう書かれていたとします。
「No.101 | 担当: 佐藤 | 優先度: 高 | ステータス: 対応中 | 内容: ログイン画面のバグ」
これを見たマネージャーは「ふむ、佐藤くんが対応中なんだな」と把握します。
でも、その「対応中」って、具体的にどういう状態です？
- 佐藤くんが、今まさにC#のコードをデバッグしている？
- それとも、原因がわからなくて3日間ハマってる？
- もしかして、修正は終わって、テスト待ち？
エクセルは何も教えてくれません。
佐藤くんが「完了」と手で入力するまで、ステータスは「対応中」のまま。
もし、このバグがGit（ソース管理）の特定のブランチと紐付いていて、プルリクエストが作成されたら「レビュー中」に、マージされたら「テスト待ち」に、自動で変わってくれたらどうでしょう？
エクセル管理は、この「現実（コード）」と「管理（シート）」を、完全に分断します。
そして、その「分断されたスキマ」を埋めるために、エンジニアは毎日、進捗報告のためだけにエクセルを「手作業で」更新するという、不毛な時間を費やすことになるんです。
限界その2：「更新」が「作業」になるという非効率
「いや、今はGoogle Sheetsがあるから、同時編集できるし、ロック問題はないよ」
確かに。技術は進歩しました。
でも、問題はそこじゃないんです。
「誰でも」「いつでも」編集できるということは、「誰が」「いつ」「何を」変えたのかが、カオスになるということ。
「あれ、このタスクの見積もり工数、昨日『5日』だったのに『3日』になってる。誰が変えた？」
「このバグ、ステータスが『完了』になってるけど、テストしたの誰？」
変更履歴を追うことはできても、その「意図」までは追えません。
結局、ミーティングの場で「このセル、変えた人いますかー？」という、世界で一番ムダな確認作業が発生する。
さらに、エクセルは「静的」なツールです。
一度フォーマットを作ると、みんなそれを「守る」ことが目的化してしまう。
「あ、このタスク、サブタスクに分けたいけど、シートの行を挿入すると関数が壊れるから、とりあえず『備考欄』に書いとこ…」
こうして、「備考欄」という名の「魔界」が誕生します。
重要な情報が、管理された「列」ではなく、自由記述の「セル」に散らばっていく。
もはや、誰もそのシートの全体像を把握できなくなります。
3. なぜ、これらのツールが「不安定要素」を見逃すのか？
もうお分かりですよね。
ガントチャートもエクセルも、それ自体が悪なのではありません。
これらは、**「既知のタスク（わかっていること）」をリストアップし、「静的に管理する」**ことしかできないんです。
「起」で話した「予期せぬ不安定要素」――。
それは、クライアントの「暗黙の期待」だったり、WPFの「やってみないとわからない技術的負債」だったり、チーム内の「コミュニケーション不全」だったりします。
これらはすべて、**「未知のタスク（わかっていないこと）」であり、「動的（日々変化するもの）」**です。
ガントチャートの「バー」にも、エクセルの「セル」にも、これらを書き込む場所がない。
だから、僕らは「見えているタスク」の進捗だけを追いかけて安心し、水面下で増殖する「見えない敵」に、プロジェクトの終盤で足をすくわれるんです。
「計画」とは、「未来を予測して固定するもの」ではありません。
特にソフトウェア開発においては、「今わかっていることの仮説リスト」でしかない。
それなのに、僕らは静的なツールを「絶対の地図」だと信じ込み、その地図に載っていない「現実の嵐（＝不安定要素）」に気づかないフリをしてしまう。
これが、伝統的な管理手法が失敗する、根本的な理由です。
じゃあ、どうすればいいんだ？
「見えない敵」を「見える化」するには？
ガントチャートの代わりに、僕らは何を「羅針盤」にすればいいのか？
次回、「転」のパートでは、この「予期せぬ不安定要素」の正体を、僕が海外の現場で学んだ方法で具体的に分類し、それらをどうやってチーム全員で「炙り出し」、そして「管理」していくか。
ガントチャートやエクセルを「補完」する、超実践的なテクニックについて、お話ししようと思います。
「見えない敵」の正体：プロジェクトを蝕む「予期せぬ不安定要素」
さて、「起」と「承」で、僕らが愛用するガントチャートやエクセルが、なぜ炎上プロジェクトを防げないのか、その「幻想」についてお話ししました。
理由はシンプル。
それらのツールは、「わかっていること（既知のタスク）」を管理するのは得意でも、プロジェクトを真に崩壊させる**「わかっていないこと（未知の問題）」**を、まったく管理できないからです。
この「わかっていないこと」こそが、僕が「予期せぬ不安定要素（Unforeseen Instabilities）」と呼んでいる「見えない敵」の正体です。
じゃあ、その敵の顔を具体的に拝んでやろうじゃないですか。
そして、どうすればそいつらを「見える化」して、戦うことができるのか。
ここからが、このブログで一番伝えたかった核心（コア）の部分です。
教科書には載っていない、僕が海外のC# / WPFの現場で血と汗で学んだ、超実践的な「敵のあぶり出し方」をシェアします。
「不安定要素」は、この3種類しかいない
僕の経験上、プロジェクトを爆破する「不安定要素」は、突き詰めると以下の3種類に分類できます。
1. 「技術的」不安定要素（Technical Instability）
これはエンジニアにとって一番イメージしやすい敵ですね。
俗にいう「技術的負債」や「やってみないとわからない部分」です。
- 例（C# / WPF）:
- 「一見シンプルなWPFの画面だけど、サードパーティ製のUIコンポーネントが、特定の操作でメモリリークを起こすかもしれない」
- 「この非同期処理（async/await）、DBの応答次第で、UIがフリーズするバグが潜んでるかも」
- 「誰も触りたがらない、あの『秘伝のタレ』レガシーC#モジュールを改修しないといけない」
- 「パフォーマンス要件『3秒以内に表示』って書いてあるけど、数百万件のデータをWPFのDataGridにバインドしたら本当に大丈夫？」
これらは、ガントチャート上の「〇〇画面実装：5人日」というバーには、決して現れません。「5人日」は、あくまで「うまくいけば」の数字でしかないんです。
2. 「人間的」不安定要素（Human Instability）
これが、特に海外で働くと強烈に牙を剥く、最強の敵かもしれません。
「人」にまつわる、あらゆる不確実性です。
- 例:
- チーム内に、スキルは高いけど、絶対に他人とコミュニケーションを取らない「一匹狼」エンジニアがいる。
- クライアントの担当者が「イエス」と言ったけど、その上司（＝真の意思決定者）は「ノー」と思っている。
- 文化の違い。例えば、こちらのチーム（海外）は「できないことは『できない』とハッキリ言う」のが普通でも、オフショア先のチームは「ノーと言うのは失礼」だと考え、ギリギリまで問題を報告してくれない。
- メンバーのAさんが、実はプライベートで問題を抱えていて、パフォーマンスが著しく落ちている（でも誰も気づけない）。
これらも、エクセルの「担当者：Aさん」というセルには現れません。
3. 「要件的」不安定要素（Requirements Instability）
いわゆる「スコープクリープ」の源泉です。
クライアント（あるいは自社の企画部門）が「何を欲しているか」が、実はフワフワしている状態。
- 例:
- 仕様書に「ユーザーフレンドリーなUI」と書いてある。（←世界で一番あてにならない要件）
- 「起」で話したような、「ちょっとした」機能追加が、ミーティングの雑談レベルで日々発生している。
- クライアント自身が、完成形をイメージできていない。だから、僕らが作ったものを見て、初めて「ああ、私が欲しかったのはコレジャナイ」と言い出す。
これらの「不安定要素」は、プロジェクトの初期段階では「霧」のようです。
存在は感じるけど、ハッキリとは見えない。
ガントチャートやエクセルは、「霧がない」という前提で作られた「地図」です。
だから、霧の中を進むと、必ず道に迷うんです。
敵をあぶり出す3つの「レーダー」
じゃあ、どうするか？
「地図」がダメなら、「レーダー」を使えばいいんです。
霧の中に隠れている「敵（＝不安定要素）」を、リアルタイムで検知する仕組みを導入するんです。
僕が現場で「これは効く！」と実感した、3つの「レーダー」を紹介します。
レーダー1：偵察ミッション「スパイク（Spike）」
さっきの「技術的不安定要素」をあぶり出す最強の武器です。
例えば、「数百万件のデータをWPFのDataGridにバインドする」というタスクがあったとします。
マネージャーは「うーん、これ、10人日くらい？」と見積もるかもしれません。
ここで、「待ってください」とエンジニアが言うんです。
「10人日で見積もる前に、まず『1日でいいから』時間をください。本当にその技術でパフォーマンス要件を満たせるか、簡単なプロトタイプ（捨てコード）を作って試させてください」
これが「スパイク」です。
1日かけて試した結果、もし「全然ダメ。仮想化（Virtualization）をガチガチに組まないと無理。10人日じゃ絶対終わりません。20人日は必要です」とわかったら、どうでしょう？
プロジェクト開始早々に、巨大な地雷を1つ、安全に処理できたことになりますよね。
ガントチャートは「見積もる」ことしかできません。
スパイクは「試す」ことで、「未知」を「既知」に変えるんです。
「10人日『かも』」という不安を、「20人日『かかる』」という事実に変える。
これこそが、エンジニアにしかできない最大のリスク管理です。
レーダー2：「動く現実」を映すカンバンボード
「人間的」「要件的」な不安定要素は、日々の「停滞」に現れます。
Aさんのタスクが、なぜか3日間「作業中」のまま動かない。
クライアントのレビューが、なぜかずっと「待ち」状態。
この「停滞」を可視化するのが、カンバンボード（Jira, Trello, Asanaなど）です。
「え、ガントチャートもカンバンも、タスク管理ツールでしょ？」
いいえ、まったく違います。
- ガントチャート ＝ **「未来の計画」**を（静的に）見せるもの
- カンバンボード ＝ **「現在の現実」**を（動的に）見せるもの
僕のチームが特に重視しているのが、**「WIP（Work In Progress = 仕掛中）制限」**です。
例えば、「『作業中』のタスクは、チーム全体で5個まで」とルールを決める。
もし、誰かのタスクが「技術的な地雷」や「クライアントの曖昧な指示」によってストップしたら、ボード上ですぐに「停滞」が可視化されます。
WIP制限があるので、他のメンバーは新しいタスクに進めません。
どうするか？
**「チーム全員で、その停滞したタスク（＝不安定要素）を助けに行く」**んです。
ガントチャート管理だと、「Aさんの遅れはAさんの問題」になりがちです。
でも、WIP制限のあるカンバンだと、「Aさんの停滞は『チーム全員』の問題」になる。
「人間的な不安定要素」（Aさんが困っている）や「要件的な不安定要素」（クライアントの指示が曖昧）が、発生したその日のうちに、チーム全員の「レーダー」に映し出される。これが強みです。
レーダー3：「1週間に1回」のデモという名の「真実の鏡」
「要件的な不安定要素」を倒す、一番カンタンで、一番効果的な方法。
それは、**「クライアントに、毎週、動いているソフトウェアを見せること」**です。
完璧な仕様書を100ページ書くより、
「今週、ここまでできました。はい、このWPFアプリ、触ってみてください」
と、たとえ未完成でも、動くモノ（C#のロジックがちゃんと動くもの）を提示する。
これをやると、クライアントは十中八九こう言います。
「おお、動いてる！ ……あ、でも、ここのボタン、私がイメージしてたのと違う」
「この動作、すごく速いけど、本当はこっちのデータを先に見たいんだよね」
キタコレ！
これこそが、仕様書の「行間」に隠れていた「要件的 不安定要素」が姿を現した瞬間です。
プロジェクトの最終盤、「受入テスト」でこれを言われたら、それは「バグ」であり「仕様変更（＝炎上）」です。
でも、プロジェクトの第2週で言われたら？
それは、単なる「軌道修正」でしかありません。
ガントチャートは、最終成果物（＝納品）しか見ていません。
週次のデモは、「動く現実」を「真実の鏡」としてクライアントに突きつけ、彼ら自身の中にあった「不安定要素」をあぶり出すんです。
どうでしょう。
これらの「不安定要素」は、どれも伝統的なガントチャートやエクセルでは「管理対象外」とされていたものです。
でも、これらこそが、僕らのプロジェクトをいつも台無しにしてきた「本当の敵」なんです。
僕らがやるべきは、「完璧な計画」を立てて、それにしがみつくことじゃない。
「不安定なのが当たり前」という前提に立ち、これらの「レーダー」を使って、「見えない敵」をいかに早く発見し、いかに早く対処するか。
そのマインドセットこそが、僕らエンジニアが身につけるべき、最強の「人生術」であり「サバイバル術」です。
次回、最終回「結」では、この「不安定な世界」を乗りこなし、海外でエンジニアとして「価値」を生み出し続けるために、僕らが目指すべき「真のエンジニア像」について、お話ししたいと思います。
計画（プラン）より適応（アダプト）。カオスを乗りこなすサバイバル術
さて、全4回にわたってお送りしてきたこのブログも、いよいよ最終回です。
「起」では、完璧に見えたプロジェクトがなぜ炎上するのか、その原因は「予期せぬ不安定要素」にあると問題提起しました。
「承」では、僕らが信奉するガントチャートや神エクセルが、実は「わかっていること」しか管理できず、その「不安定要素」から目をそらさせる「幻想」に過ぎないと喝破しました。
そして「転」では、その敵の正体――「技術的」「人間的」「要件的」な3つの不安定要素をあぶり出すための、具体的な「レーダー」（スパイク、カンバン、週次デモ）を紹介しました。
ここまで読んでくれた皆さんは、もうお分かりですよね。
僕らが向き合うべきだったのは、エクセルに引かれた美しい「計画線」ではなく、その裏に隠れていた「不安定さ」という名の、ドロドロとした「現実」だったんです。
「計画通りに進める」こと。
僕らは、キャリアを通じてずっと、これを「正義」だと教わってきました。
でも、ソフトウェア開発、特に今の複雑なビジネス要求に応えようとするなら、その「正義」は、もう捨てなければいけません。
なぜなら、**プロジェクトの初期段階で作られる「計画」は、その時点で最も「情報の少ない」状態で作られた、「ただの仮説」**に過ぎないからです。
そんな不確かな「仮説」に、なぜ僕らはしがみついてしまうのか。
それは、「管理できている」という安心感が欲しいから。スケジュールが「オンタイム（順調）」という言葉で、不安から逃れたいからです。
でも、本当の安心って、そこにはないんですよ。
僕が海外で、多国籍なチームと、数々の修羅場をくぐり抜けて確信したことがあります。
本当の安心とは、**「計画通りに進むこと」ではありません。
本当の安心とは、「計画通りに進まなくても、俺たちなら対処できる」**という、チームの「適応能力（アダプテーション）」のことなんです。
計画（プラン）に固執するな。適応（アダプト）せよ。
これが、僕が皆さんに一番伝えたいメッセージです。
あなたは「作業者」か？ それとも「問題解決者」か？
このマインドセットの転換は、僕らエンジニア自身の「価値」を、根本から再定義することにつながります。
少し厳しい言い方をしますが、
「計画（ガントチャート）に従って、言われた通りのC#コードを書く」
だけなら、それは「作業者（Task Runner）」です。
もちろん、高品質なコードを書くスキル（例えば、WPFでMVVMパターンを駆使して、保守性の高いコードを書くスキル）は非常に重要です。それはプロとしての前提条件。
でも、それ「だけ」だと、あなたの価値は「ガントチャートのタスクをどれだけ速く消化できるか」という「工数」でしか測れません。
一方、「転」で紹介したような「レーダー」を使いこなす人はどうでしょう。
- 「この要件、技術的にヤバい匂いがする。1日『スパイク』して、先に地雷撤去しておこう」
- 「カンバンでAさんのタスクが停滞してる。人間的な不安定要素かも。ちょっと声かけてみよう」
- 「今週のデモで、あえて『クライアントが迷いそうな部分』を先に見せて、要件的な不安定要素をあぶり出そう」
これらはすべて、C#のコードを書く行為（＝実装）ではありません。
でも、これこそがプロジェクトの「炎上」を未然に防ぎ、「不確実性」という名の霧を晴らす、最も価値のある行為です。
これこそが、**「問題解決者（Problem Solver）」**の仕事です。
僕らエンジニアの真の価値は、書いたコードの行数じゃありません。
僕らの真の価値は、「技術」を武器にして、プロジェクトに潜むあらゆる「不安定要素」を特定し、それを「動くソフトウェア」という名の「確実な価値」に変換することなんです。
ガントチャートの奴隷になるな。
不安定要素をハントする、ハンターになれ。
なぜこれが「海外エンジニア」の最強サバイバル術なのか
そして、この「問題解決者」であれ、というマインドセットは、特に僕のような「海外で働くエンジニア」にとって、死活問題になるほど重要です。
日本国内のプロジェクトなら、まだ「阿吽（あうん）の呼吸」とか「空気を読む」とか、あるいは「完璧に書かれた日本語の仕様書」に頼ることもできたかもしれません。
でも、海外では、そのすべてが通用しません。
まず、「人間的」不安定要素が爆発的に増大します。
育った文化が違う。仕事に対する価値観が違う。コミュニケーションの「常識」が違う。
僕が「はい（Yes）」と言う時と、インド出身の同僚が「Yes」と言う時で、その意味するコミットメントの度合いがまったく違ったりします。
次に、「要件的」不安定要素も激増します。
クライアントの言う「Simple UI（シンプルなUI）」と、僕が思うWPFの「シンプルなUI」は、100%一致しません。
言語の壁もあって、仕様書（＝静的なドキュメント）は、誤解を生む「地雷原」にしかならないことすらあります。
静的な「計画」や「ドキュメント」が、日本にいる時以上に、まったく信用できない。
じゃあ、何を信用するのか？
「今、目の前で動いているソフトウェア（＝週次デモ）」
「今、チームの目の前で停滞しているタスク（＝カンバン）」
これら「動的な現実」だけです。
文化が違くても、言語が拙くても、
「This doesn’t work.（これ、動かないね）」
「This task is blocked.（このタスク、止まってるね）」
という「現実（ファクト）」を指差して議論することは、誰にでもできます。
ガントチャートを睨みつけて「計画がー」と議論するより、100倍生産的です。
「転」で紹介した3つのレーダーは、言語や文化の壁を超える、最強の「コミュニケーション・ツール」なんです。
海外でエンジニアとして生き残るために必要なのは、ネイティブ並みの英語力（もちろん、あるに越したことはないですが）よりも、
「いかに『不安定さ』を恐れず、それを素早く『現実』としてテーブルの上に乗せ、チームで対処できるか」
という、「カオスを乗りこなす力」なんです。
結論：カオスを恐れるな。カオスを乗りこなせ。
僕らが生きる現代のソフトウェア開発は、もはや「地図（＝完璧な計画）」を作って、その通りに歩く「ハイキング」ではありません。
何が起こるかわからない荒波の海を、「羅針盤（＝レーダー）」だけを頼りに進む「航海」です。
プロジェクトは、カオスで当たり前。
あなたの仕事は、完璧な「地図」を作ることじゃない。
どんな嵐（＝不安定要素）が来ても、チームという船が沈まないように、リアルタイムで「羅針盤」を読み解き、舵を取り続ける「船乗り」になることです。
この「カオスを乗りこなす力」こそが、C#だろうがPythonだろうが、WPFだろうがWebだろうが、日本だろうが海外だろうが、どこへ行っても通用する、本質的な「エンジニアリング・スキル」です。
そして、不確実なカオスの中から、動く「価値」を生み出すこの仕事は、とてつもなくクリエイティブで、面白い。
これから海外を目指す皆さん、あるいは今まさに現場で戦っている皆さんが、このブログで得た「ヒント」を武器に、ガントチャートの呪縛から解放され、カオスを楽しみながら乗りこなす「問題解決者」として活躍してくれることを、心の底から願っています。
健闘を祈る！
コメント