海外C#エンジニアが本音で語る、AIプロジェクト管理導入の「リアル」と「生存戦略」

「AI」という名の黒船、C#エンジニアの僕らが乗るべきか？

どうも！海外の片隅で、今日もC#とWPFと格闘しているITエンジニアです。主にデスクトップアプリケーションの設計と開発、つまりクライアントサイドの「ガワ」と、そこそこのビジネスロジックをゴリゴリ書く毎日を送っています。

さて、みなさん。最近、どうですか。「AI」って言葉、聞かない日がありますか？

僕の周りだけかもしれませんが、特に海外で働いていると、この「AI」というバズワードの圧がすごい。日本の数倍、いや、体感としては10倍くらいの圧で押し寄せてきます。LinkedInを開けば「AIで業務効率化！」「AIを使いこなせないエンジニアは淘汰される！」の大合唱。経営陣が集まるミーティングでは、必ず「ウチのプロダクトにAIをどう組み込むか？」という議題が、半ば強制的にねじ込まれます。

正直に言いましょう。

僕らのような、長年C#とWPF、あるいはWinFormsといった「堅牢なエンタープライズ向けデスクトップアプリ」を主戦場にしてきたエンジニアにとって、このAIブーム、ちょっと「自分ごと」として捉えにくくないですか？

「いや、ウチはMVVMパターンをどう徹底するとか、XAMLのパフォーマンスチューニングとか、.NET 8への移行とか、そういうので手一杯なんで…」

「AIって言っても、Pythonでしょ？」「GPUが必要なんでしょ？」「ウチのクライアントのPC、そんなスペックないよ？」

「データサイエンティスト様のお仕事であって、我々アプリケーション開発者の領分じゃないのでは？」

そんな風に、ちょっと冷めた目で見ている、あるいは「見ないふり」をしている同業者、結構多いんじゃないかと思います。僕も、数ヶ月前まではそうでした。

「AIがコードを書く」と言われても、僕らが日々直面している、あの複雑怪奇な業務要件と、歴史的経緯（いわゆる「レガシー」）によってガチガチに固められた既存コードの海を、AIがどうこうできるとは到底思えませんでした。むしろ、「そんな夢物語より、目の前のバグを一つ潰させろ」と。

でも、海外でエンジニアとして「生き残る」ためには、どうやらそのスタンスではマズいらしい、ということに気づき始めました。

ここが、もしかしたら日本国内で働くのとは少し違う、「海外エンジニアの人生術」に関わってくる部分かもしれません。

海外、特に欧米のIT企業（僕の観測範囲ですが）では、「新しい技術トレンドにどう反応したか」が、個人の評価に直結しやすい傾向があります。それは、単に「流行りもの好き」かどうかではありません。「ビジネスの新しい波（それが本物か偽物かは別として）に対して、どう価値を付加しようと試みたか」という、積極性と適応力が厳しく問われるのです。

「私はC#の専門家ですから」と一線を引くのは、日本では「職人気質」として評価されるかもしれませんが、こちらでは「変化を恐れる人」「新しい価値を生めない人」というレッテルを貼られかねません。特に僕ら外国人は、「替えのきかない存在」であることを常に証明し続けなければならない、という側面もあります。

そんなある日、上司から例のフックが飛んできました。

「ところで、ウチのエンジニアリングチームの生産性を上げるために、AIを導入するロードマップを考えてくれないか？」

出た。出ましたよ。

でも、よく聞いてみると、彼が言っているのは「ChatGPTみたいなものを作れ」とか「AIに WPFアプリのコードを書かせろ」という話ではありませんでした。彼が問題視していたのは、もっと泥臭い部分。

そう、**「プロジェクト管理」**です。

曰く、「なんでウチのプロジェクトはいつも見積もりをオーバーするんだ？」「リソース配分は本当に最適か？」「クライアントからの仕様変更（チェンジオーダー）が、どれだけの影響を及ぼすか、なんで即座にわからないんだ？」

……耳が痛い。

これって、僕らが日々、JiraやAzure DevOpsのチケットと格闘し、Excelのガントチャートとにらめっこし、スプリントプランニングで頭を悩ませている、まさに「ソレ」じゃないですか。

彼は続けました。「AIが、過去のプロジェクトデータから、次のスプリントで発生しそうなリスクを予測したり、この仕様変更がリリース日にどれだけ影響するかを『精度高く』教えてくれたりしないものか？」と。

なるほど。

ここでピンときました。

これは、Pythonエンジニアやデータサイエンティストだけに閉じた話じゃない。

これは、僕ら「現場の」アプリケーションエンジニア、特にシステムの全体像や業務フローを（C#という武器で）設計・実装してきた僕らだからこそ、深く関わるべきテーマなんだ、と。

なぜなら、AIが「予測」や「分析」をするために必要な**「データ」**が、どこにあるかを一番知っているのは、僕ら自身だからです。

今回のブログシリーズで書きたいのは、「AIの作り方」という小難しい話ではありません。

僕らのような、AI専門ではない（むしろ今まで避けてきた）C#/WPFエンジニアが、この「AI導入」という避けられない波にどう立ち向かうか。

どうやってAIを「使う」側に回り、自分たちのプロジェクト管理をハックし、結果として（ここが大事）「海外で働くエンジニアとしての市場価値」をシレッと高めていくか。

これは、技術的なロードマップであると同時に、僕ら自身のキャリアを守るための「生存戦略」の話です。

「AIなんて、自分には関係ない」

そう思っている、かつての僕のような同業者にこそ、読んでほしい。

AIという「黒船」は、僕らを脅かす敵じゃないかもしれません。

うまく乗りこなしさえすれば、僕らのC#キャリアを次のステージに運んでくれる、頼もしい「船」になるかもしれないのです。

次回、「承： AIが欲しがる「エサ」は、実は僕らの足元にある」で、その「船」を動かすための「燃料＝データ」が、いかに僕らの身近にあるか、という話を掘り下げていきます。

AIが欲しがる「エサ」は、実は僕らの足元にある

どうも、続きです。

前回の「起」で、「AIという黒船は、実は僕らのキャリアを次のステージに運ぶ船になるかも」みたいな、ちょっとカッコつけた話で終わりました（笑）。

「AIにプロジェクト管理をさせる」という上司の無茶振り（？）から、僕ら現場エンジニアがどう価値を出すか。そのカギは「データ」にある、と。

で、その船を動かすための燃料、つまりAIに食わせる**「最高級のエサ（データ）」**が、実は僕らの足元に、それも大量に転がっている、という話をしました。

今回は、その「エサ」の正体について、具体的に掘り下げていきます。

海外のカンファレンスやテックブログを見ていると、AIをまるで「魔法の箱」か「銀の弾丸」のように語る人が多すぎます。でも、長年エンタープライズ向けの堅牢なシステム（つまり、バグが出たらマジで怒られるやつ）をC#で作ってきた僕らからすると、そんな夢物語は信じられませんよね。

AIも所詮はプログラムです。その本質は**「めちゃくちゃ優秀だけど、めちゃくちゃ素直な新人」**みたいなもの。

質の高いデータ（良い手本）を食わせれば、驚くような洞察（アウトプット）を返してくれます。

逆に、ゴミみたいなデータ（悪い手本）を食わせれば、堂々とゴミみたいな予測を返してきます。

『Garbage In, Garbage Out (GIGO)』。

これは、僕らがCOBOLの時代から（僕はCOBOL世代じゃないですが！）、いや、それ以前から知っているITの黄金律です。AI時代だからこそ、この言葉の重みが増していると、僕は肌感覚で感じています。

じゃあ、AIに「精度の高い予測」をさせるための、その「質の高いエSA」とは一体何なのか？

それは、僕らエンジニアが日々、「あー、めんどくさいなぁ…」と思いながら、Azure DevOps (ADO) や Jira、Git に入力している、**「アレ」**です。

具体的にリストアップしてみましょう。AIがプロジェクト管理の精度を上げるために、喉から手が出るほど欲しがっている「お宝データ」トップ3です。

1. プロジェクトスケジュール（見積もり工数 vs 実働工数）

まず、これ。最強のエサです。

ADO や Jira のすべてのタスク（PBI、User Story, Bug）に存在する、あの**「Estimated Time（見積工数）」と「Completed Time（実働工数）」**の、地味な数字。

「どうせ見積もりなんて当たらねえし」

「実働工数のログなんて、金曜の夕方に適当にまとめて入れりゃいいや」

…はい、かつての僕です。耳が痛い。

でも、AIにとっては、その「見積もりと実働のズレ」こそが、とんでもないお宝なんです。

AIは、この「ズレ」のパターンを学習します。

例えば、過去数年分のプロジェクトデータを全部食わせると、AIはこんなことを言い出すわけです。

  • 「”WPF” タグと “UI” タグが両方ついたタスクは、平均して見積もりの 1.4倍 の実働工数がかかっている」
  • 「エンジニアAさんは、”バックエンド” タスクでは見積もりの 0.9倍 で終わらせるが、”フロントエンド” タスクでは 1.3倍 かかる傾向がある」
  • 「”緊急” フラグのついたバグは、その修正自体（Completed Time）は早いが、その後のリグレッションテストで、関連タスクが平均 2.5件 追加発生している」

…怖くないですか？

僕らが「なんとなく」でしか感じていなかった「プロジェクトのクセ」を、AIは冷徹に、数字として白日の下に晒します。

このデータがリッチであればあるほど、「じゃあ、次のスプリントで『WPFのUIタスク』を『Aさん』に任せたら、見積もりは 1.4 x 1.3 = 1.82倍 で見積もっておくべきかも」という、超具体的なリスク予測が可能になります。

「工数ログは、未来の自分を助けるための投資」。

海外の優秀なエンジニアが、なぜあんなに面倒な工数入力を（比較的）キッチリやっているのか、その理由が分かった気がしました。彼らは「管理されたい」んじゃなくて、「未来を予測したい」んです。

2. リソースアロケーション（誰が、何を、いつ）

2つ目は、「誰が、何をやったか」の履歴。

ADO で言えば、Assigned To フィールドの変更履歴や、State （Active, Resolved, Closed）がいつ変更されたか、というタイムスタンプです。

「この手のタスクは、シニアのBさんがやれば3日だけど、ジュニアのCさんがやると（レビューや手戻りも含めて）7日かかる」

これは、プロジェクトマネージャー（PM）なら肌感覚で持っています。でも、それは「Bさん」と「Cさん」がチームにいる間だけ有効な「属人的な知見」ですよね。Bさんが辞めたら、その知見は失われます。

AIは違います。

「シニア（入社5年目以上、C#経験10年以上）が、難易度 “High” のタスクをやった場合」と「ジュニア（入社2年目未満、C#経験3年未満）がやった場合」のパターンを学習します。

これにより、「今度のプロジェクト、シニア1人とジュニア2人で組むなら、このフェーズの納期はこれくらい」という、**「再現性のある」**リソース配分の最適化が可能になります。

僕らC#エンジニアは、自分たちのスキルセット（WPF, .NET Core, SQL Server…）をタグとして持っています。そのタグと、タスク完了までの時間というデータを組み合わせることは、AIにとって「誰に何を任せるべきか」を学ぶための、最高級の教科書になるわけです。

3. 変更要求（チェンジオーダー）の嵐

そして3つ目。これが一番の厄介者であり、一番の「お宝」です。

そう、クライアントや企画担当からの**「仕様変更（チェンジオーダー）」**です。

「ここのボタンの色、やっぱり赤じゃなくて青にしてほしいな」

一見、C#エンジニアからすれば「は？ XAML の Style を一行変えるだけじゃん。10分でしょ」と思うかもしれません。

でも、現実は違います。

その「共通 Style」を変更したせいで、まったく別の画面の、意図しない部分の表示が崩れた。それに気づかず、QA（品質保証）フェーズでリグレッションバグとして差し戻され、原因特定に半日。修正に2時間。確認に1時間…。

結局、あの「10分の色変更」が、トータルで「1日の遅延」を生んだ、なんてことはザラです。

この「変更要求」を、僕らがどういうチケットタイプやタグ（例： “Change Request”, “Customer Feedback”）で起票しているか。そして、そのチケットがトリガーとなって、どれだけの「関連バグ」や「追加タスク」が生まれたか。

この因果関係こそ、AIが最も学習したい「プロジェクトの隠れたコスト」です。

AIがこれを学習すれば、「この画面の、このコンポーネント（例: CommonStyles.xaml）に手を入れる仕様変更は、過去の履歴から 80% の確率で 2.5日の追加作業を誘発します」と、PMがクライアントに交渉するための「武器（データ）」を渡せるようになります。

ここまで読んで、気づいたことはありませんか？

これらの「お宝データ」の「文脈（コンテキスト）」を、一番深く理解しているのは誰でしょう？

PMでしょうか？違います。彼らは「数字」しか見ていないかもしれない。

データサイエンティストでしょうか？違います。彼らは「C#のあのレガシーモジュールが、いかにクソか」を知らないかもしれない。

そう。僕らです。

現場でコードと格闘している、C#/WPFエンジニアの僕らなんです。

「このタスクの見積もりが3倍に膨れたのは、WPF の DataGrid の仮想化（Virtualization）の仕様をナメていたからだ」

「このバグがすぐ終わったのは、先月似たようなスレッドセーフティの問題をAさんが解決していて、知見が共有されていたからだ」

この**「データに命を吹き込む、生きた文脈（コンテキスト）」**こそが、AIプロジェクトにおける僕らアプリケーションエンジニアの、最大の存在価値（バリュー）なんです。

AIが欲しがっている「エサ」は、ただの数字やテキストの羅列じゃない。

僕らが経験してきた「なぜ、そうなったか」という「知見」が染み込んだ、生きたデータなんです。

さあ、お宝の地図は見えました。

僕らの足元に、AIが喉から手が出るほど欲しがっている「エサ」が大量にあることも分かりました。

でも、問題は「どうやって、そのエサをAIに効率よく食わせるか？」ですよね。

僕らの、C#とWPFでガチガチに固められた（あるいは歴史的経緯でカオスな）既存のワークフローに、どうやって「AIの窓」を付け加えるのか。

次回、「転： C#/WPFの城に「AIの窓」をどう開けるか」で、いよいよ具体的な「統合ステップ」について、僕なりの実践的なロードマップを話してみたいと思います。ここからが、エンジニアの腕の見せ所です。

 C#/WPFの城に「AIの窓」をどう開けるか

どうも！お待たせしました。「転」のパートです。

「起」でAIの波に乗る必要性を痛感し、「承」で僕らの足元に「お宝データ（工数、リソース、変更履歴）」が眠っていることを確認しました。

でも、ここが一番の問題です。

その「お宝」は、Azure DevOps (ADO) や Jira、GitLab の奥深くに、泥だらけのまま埋まっています。

一方、「AI」という最新鋭の分析エンジン（多くの場合、Python とかで動いてる）は、ピカピカのデータセンターで「キレイに精製された燃料」を待っています。

僕ら C#/WPF エンジニアの城は、堅牢だけど、ちょっと古い。

その城に、どうやって「AI」という異世界のテクノロジーと繋がる「窓」を開けるのか？

「全部 Python で書き直せ」？

「データサイエンティストを10人雇え」？

いやいや、そんなことしたら僕らの仕事がなくなっちゃう（笑）。

冗談はさておき、海外で働くエンジニアとしての「人生術」は、**「今ある武器（C#）を最大限に活かして、新しい価値（AI）と接続する」**ことに尽きます。

僕らがやるべきは、Python エンジニアになることじゃありません。

僕らの「C#の城」から、AI の世界へ繋がる**「堅牢なパイプライン（橋）」**を架けることです。

そして、その橋の設計図こそ、上司が求めていた「AI導入のロードマップ」そのものなんです。

今日は、僕が実際に考え、実行している「3つのステップ」を具体的に共有します。

ステップ1： 【抽出と変換】 泥だらけの「生データ」を C# で「お宝」に変える

まず、ADO や Jira に眠る「生データ」を掘り出さないといけません。

幸いなことに、ADO も Jira も、超優秀な REST API を公開してくれています。

これ、僕ら C# エンジニアの得意分野ですよね？

HttpClient を使って JSON をぶん投げて、System.Text.Json (あるいは Newtonsoft.Json) でデシリアライズする。これ、僕らが毎日 WPF アプリのバックエンド通信でやっていることです。

ここで作るべきは、一つのシンプルな「C# アプリ」です。

それは、Azure Functions かもしれないし、.NET Core の Worker Service かもしれません。

こいつの仕事は、ひたすら「ETL」です。

  • Extract（抽出）:
    • ADO の API を叩いて、過去3年分の「すべてのタスク」情報を引っこ抜く。
    • "Microsoft.VSTS.Scheduling.OriginalEstimate" (見積工数)
    • "Microsoft.VSTS.Scheduling.CompletedWork" (実働工数)
    • "System.AssignedTo" (担当者)
    • "System.Tags" (タグ。これが重要！ “WPF” とか “BUG” とか)
    • "System.History" (いつ State が “Resolved” になったか、など全履歴)
    • Git の API を叩いて、タスク ID に紐づく「コミット履歴」も引っこ抜く。
  • Transform（変換）:
    • ここが、僕ら C# エンジニアの最大のバリューです。
    • データサイエンティストに、この生の JSON をそのまま渡しても、「意味が分からない」と言われます。
    • 僕らは「承」で学んだ**「文脈」**を知っています。
    • 「Tags に ‘UI’ と ‘Performance’ が両方含まれてたら、それは『激ヤバタスク』だ」
    • 「AssignedTo が ‘Junior Developer Group’ に入っていて、OriginalEstimate が 8時間 を超えていたら、レビュー工数が必ず追加発生している」
    • 「History を見ると、”Active” と “Resolved” を3回以上往復しているタスクは、仕様変更（Change Order）が原因だ」
    • この「業務ロジック」を使って、生の JSON を、AI が理解できる**「特徴量（Features）」**に変換する C# のコードを書くんです。
    • IsHighRiskUiTask = true
    • EstimatedReviewCost = 1.5
    • ChangeOrderCount = 3
    • みたいな、キレイなデータ構造（C# の record とかで作るとイケてますね）にマッピングします。
  • Load（格納）:
    • この「キレイになったお宝データ」を、AI が食べやすい場所に置いてあげます。
    • Azure SQL Database でもいいし、Azure Blob Storage に Parquet ファイルとして吐き出すでもいい。
    • これで、AI のための「ビュッフェ会場」が完成です。

この ETL パイプライン、Python チームに作らせることもできます。でも、C# で書くことには大きな意味があります。なぜなら、そのタスクの「文脈」を一番知っている僕らが、自分たちの手でロジックを実装できるからです。この「変換」ロジックこそが、AI の精度を左右する「秘伝のタレ」になります。

ステップ2： 【統合】 既存のワークフローに「AI の予測」をねじ込む

さて、ビュッフェ会場（データレイク）にデータが溜まりました。

データサイエンティスト チームが、そのデータを食わせて、予測モデル（「このタスクは 80% の確率で 2.5日 炎上します」と予測するモデル）を作ってくれたとしましょう。

で？

その予測結果、彼らの PC の中で見せられても、僕らの仕事は1ミリも楽になりません。

僕らエンジニアが欲しいのは、**「ADO のタスクを開いた瞬間」**に、その予測が見えることです。

ここでも、僕らの出番です。

AI チームが作った予測モデルは、大抵、REST API として公開されます。（Azure Machine Learning Studio とか SageMaker とか使えば、簡単に API になります）

もうお分かりですね。

今度は、さっきと逆のパイプラインを作ります。

  1. トリガー: 開発者が ADO で**「新しいタスクを作成した」または「タスクのタグを更新した」**。
  2. 発火: ADO の Webhook が、そのイベントをキャッチして、僕らが作った C# の「Azure Functions」を叩く。
  3. 仲介: C# の Function が、送られてきたタスク情報を、AI 予測モデルの API に投げる。
  4. 予測: AI が「{ “Risk”: “High”, “PredictedOverrun”: “2.5 days” }」みたいな JSON を返す。
  5. 統合: C# の Function が、その予測結果を**「ADO タスクのディスカッション（コメント欄）」に自動で書き込む**。

（カチャッ…ターン！）

できました。

これで、PM が新しいタスクをアサインした瞬間、ADO のコメント欄に AI が自動でこう書き込むわけです。

[AI Bot]: 警告：このタスク（”WPF DataGrid の仮想化対応”）は、過去の類似タスク（#1234, #5678）のデータに基づき、80% の確率で 2.5日 の遅延が発生すると予測されます。

PM も、アサインされたエンジニアも、ADO を離れることなく、リアルタイムで AI の警告を受け取れるようになりました。

これこそが「既存のワークフローへの AI の統合」です。

僕ら C# エンジニアは、二つの異なる世界（ADO と AI）を API で繋ぐ、「最強の通訳」であり「仲介人」になったわけです。

ステップ3： 【継続的学習】 AI を「賢い新人」から「頼れるベテラン」に育てる

これで完成…ではありません。

海外で「コイツ、できるな」と思われるエンジニアは、「作って終わり」にしません。

この AI、最初は「勘違いだらけの新人」です。

「2.5日 遅延する」とか言ってたのに、実際は半日で終わるかもしれない。

大事なのは、**「答え合わせ」**です。

ステップ1で作った ETL パイプラインを、毎日動かし続けます。

AI が「2.5日 遅延する」と予測したタスクが、実際どうなったか？

「（実働工数）-（見積工数）」の**「結果」**を、AI のビュッフェ会場（データレイク）に、毎日追加し続けるんです。

これが、AI にとっての**「復習ドリル」**になります。

  • AI: 「”WPF” タグはヤバいと思ってたけど、”A さん” が担当したら、むしろ早かったな…」
  • AI: 「”B さんのレビュー” が入ると、やっぱりタスクは安定して終わるな…」

AI は、この「答え合わせ（Validation）」を繰り返すことで、勝手に賢くなっていきます。

最初はウザいだけだった AI Bot のコメントが、半年後には「うわ、こいつの言う通りだ…」と、誰もが無視できない「ベテラン PM」の助言に変わっていきます。

この**「学習のフィードバックループ」**を設計し、C# のコードで自動化すること。

これこそが、「継続的なモデルのトレーニングと検証（Continuous model training and validation）」の正体です。

この「AI を育てる仕組み」を作れるエンジニアは、単なる WPF エンジニアではありません。「ビジネスを改善できるエンジニア」として、海外でも圧倒的に重宝されます。

さて、「城」に「窓」が開き、AI との対話が始まりました。

僕らは C# という武器を捨てずに、AI という新しい力を手に入れた。

でも、賢くなった AI が僕らの仕事をどんどん予測できるようになったら…

いよいよ、僕らエンジニアの「本当の価値」は、どこに行くんでしょうか？

コードを書くこと？

いや、AI もコードを書き始めてる。

見積もること？

いや、AI の方が精度が高くなるかもしれない。

次回、「結： 錆びないエンジニアであるために」で、この AI 時代に僕ら C# エンジニアが持つべき「本当の価値」と、僕なりの「生存戦略」の結論を話したいと思います。

錆びないエンジニアであるために

どうも！長らくお付き合いいただき、ありがとうございます。

海外の片隅でC#を書いていた僕が、「AI？ Pythonでしょ？」と斜に構えていたところから、上司の無茶振りを経て、ついにAIを僕らのワークフローに「統合」するまでの道のりを書いてきました。

「起」でAIの波を直視し、「承」で僕らの足元に眠る「データ」というお宝を発見し、「転」で僕らのC#スキルを使って、ADO/Jiraという「堅牢な城」とAIという「異世界」を繋ぐ「橋（パイプライン）」を架けました。

今、僕のチームのAzure DevOps (ADO) では、あの「AI Bot」が元気に働いています。

タスクが作られるたび、コメント欄に「警告：このタスクは炎上確率 75% です」とか「過去の類似タスク #4567 を参照してください」とか、生意気な（いや、ありがたい）助言をくれるようになりました。

「転」で設計したフィードバックループ（答え合わせの仕組み）のおかげで、このBot、最初はアホなことばかり言ってましたが、ここ数ヶ月で急速に賢くなっています。

…さて。

ここで、多くの同業者（特に僕と同じC#やエンタープライズ系）が抱く、一つの「恐れ」と向き合わなければなりません。

「AIがこんなに賢くなったら、俺たちの仕事、いらなくね？」

AIが見積もり精度を上げ、AIがリスクを予測し、最近じゃ（Copilotとかが）コードまで書き始めた。

僕らが長年「職人技」として磨いてきた「工数見積もり」や「バグの勘所」、「堅牢なコード設計」といったスキルが、どんどんAIに代替されていく。

これは、恐怖でしょうか？

海外で「替えのきかないエンジニア」として生き残るために、僕らはどうすればいいんでしょうか？

今日はこのブログの最後に、僕がこのAI導入プロジェクトを通じてたどり着いた、「錆びないエンジニア」で在り続けるための「人生術」について、本音で話したいと思います。

AIが「できること」と「絶対にできないこと」

まず、認めましょう。

「過去のデータからパターンを見つけて予測する」という仕事において、僕らはAIに絶対に勝てません。

  • 「このタスク、前に似たようなのやったな。確か3日かかった」→ 僕らの「経験と勘」。データソースは、僕の脳みそ（せいぜい過去数年分）。
  • 「過去5年間の全プロジェクト、全タスク、全コミット履歴 20万件 を分析した結果、このタスクは 3.2日 かかります」→ AIの「統計と予測」。データソースは、サーバー全部。

勝負になりません。

「見積もり」という作業は、遅かれ早かれAIのサポートが主流になるでしょう。

じゃあ、僕らの価値はゼロか？

いや、逆です。僕らの価値は、別の場所で爆上がりしています。

AIが絶対にできないこと。それは、2つあります。

  1. 「問い（課題）」を立てること。
  2. 「文脈（コンテキスト）」を理解すること。

思い出してください。

「承」で、僕らは「どのデータがお宝か？」を見極めました。

「プロジェクトスケジュール（見積もり vs 実働）」「リソース配分」「変更要求（チェンジオーダー）」…これらがAIのエサになると気づいたのは、AI自身ではありません。

現場の「痛み」を知っている、僕ら人間です。

「なぜ、ウチのプロジェクトはいつも見積もりをオーバーするんだ？」

この「問い」こそが、すべての始まりでした。

AIは、この「問い」を立てられません。「何を解決すべきか？」を定義できないんです。

「転」で、僕らはAIが理解できる「特徴量」を作りました。

「Tags に ‘UI’ と ‘Performance’ が両方含まれてたら、それは『激ヤバタスク』だ」

という「生きた知見」を、C# のロジックに変換しました。

AIに、ADO の生の JSON を 100年分 食わせても、この「激ヤバタスク」の意味は永遠に理解できません。なぜなら、AIは「WPF の UI スレッドを止めると、どれだけクライアントが激怒するか」を知らないからです。

「このタスクの工数が異常に跳ねたのは、クライアントの担当者が交代して、無茶な仕様変更が連発されたからだ」

この、データ（工数の数字）の裏にある、ドロドロした**「人間臭い文脈（コンテキスト）」**。

これこそ、AIが逆立ちしても理解できない、僕ら人間の「聖域」です。

僕らの新しい仕事：「AIの通訳」であり「AIの調教師」

つまり、こういうことです。

これからのAI時代、僕らC#エンジニアの「本当の価値」は、コードを書く速度や見積もりの精度（だけ）じゃなくなります。

僕らの新しい仕事は、**「AIの通訳」であり「AIの調教師」**になることです。

  • 「通訳」とは：ビジネスサイドやクライアントの「なんかウチの業務、非効率なんだよね…」という**「曖昧な文脈」を理解し、それを「OK、じゃあ ADO のこのデータとこのデータを AI に食わせて、遅延予測モデルを作ろう」という「技術的な課題」**に翻訳（通訳）する能力です。「転」でやった、API を使った「ブリッジ（橋渡し）」は、まさにこの「通訳」の仕事そのものです。
  • 「調教師」とは：AI という「めちゃくちゃ優秀だけど、空気が読めない新人」に対して、僕らの世界の「文脈」を教え込むことです。「このデータはゴミだから食うな」「この『激ヤバタスク』のパターンを学べ」と特徴量を設計し、「答え合わせ（フィードバックループ）」を与え続けて、AI を「ベテランPM」に育て上げる。これが「調教」です。

この2つのスキルは、僕らが長年培ってきた「C#」や「WPF」、「MVVM」や「SQL」といった**「専門性（幹）」があるからこそ、輝く「応用力（枝葉）」**なんです。

幹がなければ、枝葉は広げられません。

Python エンジニアやデータサイエンティストは、AI の「調教」はできても、WPF アプリの「文脈」は知らないかもしれません。

逆に、僕らは「文脈」を知っている。だから、僕らが「通訳」と「調教師」をやるべきなんです。

結論： 錆びないエンジニアであるために

海外でエンジニアとして働いていると、「変化への適応力」をこれでもかと問われます。

昨日まで主流だった技術が、今日にはレガシーと呼ばれる。

日本にいた時よりも、そのサイクルが圧倒的に早い。

だからこそ、「C# 一筋 20年！」という「専門性」だけでは、すぐに「替えがきく人」になってしまうリスクがあります。

僕が考える「錆びないエンジニア」とは、

「一つの強固な専門性（C#）を持ちながら、常に新しい技術（AI）に対して『自分の専門性と、どう繋げられるか？』を問い続けられる人」

です。

AI は、僕らの仕事を奪う「黒船」ではありませんでした。

AI は、僕らの専門性を「増幅」してくれる、最強の「武器」であり「相棒」でした。

そして、その武器を使いこなすための「通訳」と「調教」こそが、僕らがこれから磨くべき、新しい「人生術」なんだと思います。

このブログが、かつての僕のように「AI、自分には関係ないな」と思っている、どこかのC#エンジニアにとって、一歩踏み出す「ヒント」や「気付き」になれば、こんなに嬉しいことはありません。

さあ、僕らの城に AI という「窓」を開けましょう。

僕らの C# スキルで、この変化の波を、面白がって乗りこなしてやりましょう。

コメント

タイトルとURLをコピーしました