「エンジニアのマインドセット：“Please”と“Thank You”を越えて」

なぜ「お願い」と「ありがとう」だけでは足りないのか

海外で働くエンジニアとして、僕はある種の「使える英語」を使いこなすことにずっと囚われてきました。最初は、誰かに何かを頼むときには “Could you …?” と “Thank you” で終わるような会話。礼儀としては完璧です。ですが、設計開発という立場、しかも C#＋WPFで「仕様をこう変えてほしい」「この部分の設計を検討し直そう」という議論においては、その「お願い」と「ありがとう」だけでは、グローバルなメンバーや英語ネイティブのチームメンバーとのやり取りで十分に通じ合えない瞬間が多くありました。

振り返ると、それは「何を」「なぜ」「どのように」という構造を伴ったやりとりが欠けていたからだと思います。たとえば、「このUIの動きを変えてもらえませんか？（Can you change this UI behavior?）」というお願いで終わっていたやり取り。英語的には間違っていません。ただ、エンジニア視点では「なぜ変える必要があるのか」「どういう制約があるのか」「期待する出力／振る舞いは何か」が伝わりませんでした。結果、変更後の仕様が曖昧になり、「あれ、意図とちょっと違う…」が起こったのです。

そこで僕は、“お願い英語”から“構造化されたエンジニア議論”へと転換する必要を強く感じました。つまり、ただ “Please do this” だけではなく、「私たちはこのモジュールをこういう設計パターン（たとえば MVVM）で実装しており、この変更はその一貫として必要です。制約としてメモリ消費が〇〇以上にならないように、UIスレッドをブロックしないようにしてください。期待する出力としては…”というように。これを英語でも、日本語でも“きちんと提示する”ことが、海外で働くITエンジニアにとってのひとつの武器になると感じたのです。

具体的には、僕が最近取り組んだ新機能設計のミーティングで、以下のような流れに切り替えました：

  • 背景（Why）：この機能を導入することで、海外ユーザーからのフィードバックで「レスポンス遅延」が課題になっていた。
  • 現状（What）：現在のWPFモジュールでは ViewModel → View のバインディングが重く、UIスレッドが短時間ながらブロックされる場面がある。
  • 制約／目標（Constraints）：UIスレッドの応答時間を100 ms以下に抑える。メモリ使用量は＋10 MB以内に抑える。MVVM の View-first アプローチを維持する。
  • 出力／振る舞い（Desired Output）：ユーザーがボタンをクリックしてから20 ms以内に操作可能状態に戻る。処理中はプログレス表示し、完了後は通知ポップアップ。
  • 次のステップ（Next Steps）：You と協力して、非同期処理にタスクベース・パターンを導入。来週月曜までにプロトタイプ、木曜までにパフォーマンステスト。

このような構造を“英語＋エンジニア言語”で提示したことで、チームメンバーの理解がぐっと早くなり、「OK、こう作るね」「じゃあこの制約のもとで実装してみる」という流れがスムーズになりました。海外チームでは、英語の礼儀（please／thank you）はもちろん重要ですが、それだけでは“通じる英語”にならないのです。

これを「構造化されたプロンプト提示」に例えると、まさに今話題の Prompt Engineering（プロンプトエンジニアリング）の考え方に近いと言えます。たとえば、LLM（大規模言語モデル）に対して効果的な出力を引き出すためには「コンテキストを提供」「具体的に指示」「フォーマットを指定」（(mitsloanedtech.mit.edu)）という要素が必要であるとされています。エンジニアリングの議論でも同じ構造が有効。背景・制約・出力・手順…といった構造化が、曖昧さを排し、交流を加速させます。

さらに、研究では「構造化プロンプト（Structured Prompting）」が、ただ会話的に頼むよりも明確で再現性ある成果を出すと指摘されています。(oneusefulthing.org) 海外開発の現場では、エンジニア同士の英語議論も、まさにこの「構造化」の恩恵を受ける場面が多いことを、僕自身実感しています。

ということで、これからこのシリーズでは「構造化されたプロンプトの使い方を、エンジニア視点で」「設計／開発議論に応用する方法」「具体的な例（初級→中級→上級）を通じてどう進化させるか」を解説していきたいと思います。

AIもチームメンバーも、“構造化”で動きが変わる

前回の「起」で話した通り、海外エンジニアとして働くうえで大事なのは「英語力」そのものよりも、「構造化された伝え方」でした。
そしてその構造化の考え方は、今話題の「AIプロンプト設計（Structured Prompting）」と、驚くほど共通点があります。

ここでは、実際に僕が 「AIとのやり取り」と「海外チームとの設計ディスカッション」 の両方で体感した、“構造化がもたらす成果の違い”を紹介します。
これは、単なるAIの使い方講座ではなく、「エンジニアとしての思考整理術」にもつながる話です。

■ステップ1：漠然とした質問から始まる

ある日、僕はWPFのデータバインディングまわりでちょっとした問題にぶつかりました。
ViewとViewModel間の更新が一方向にしか効かない箇所があって、UIが思ったように動かない。
焦ってChatGPTに聞いてみた最初のプロンプトがこちらです。

“Binding not working in WPF. Please help.”

これ、まさに最初の頃の僕の「お願い英語」そのものです。
でも返ってきた答えは、一般的なトラブルシューティングの羅列。
INotifyPropertyChangedを確認せよ、DataContextを見直せ、など、どれも正しいけど「自分の状況には合わない」。
それもそのはず。自分の制約や意図を何も伝えていないからです。

■ステップ2：制約と前提を“設計仕様”のように書く

次に僕は、AIを“チームメンバー”だと思って話してみました。
つまり、プロンプトを「設計レビュー資料」みたいに整理したのです。

Context: I’m building a WPF app using MVVM.
Issue: The View is not updating when the ViewModel property changes.
What I’ve tried: I implemented INotifyPropertyChanged, but the UI still doesn’t refresh.
Constraint: I can’t change the binding mode to TwoWay due to business logic restrictions.
Goal: Find a way to update the View efficiently while keeping OneWay binding.

すると、AIの回答が一気に変わりました。
「CollectionViewSourceを使う方法」や「DependencyPropertyをラップする案」など、制約を踏まえた具体的な代替策を提案してくれたのです。

このとき、僕ははっきり気づきました。

AIは“お願い”では動かない。
でも、“構造化された要件”には反応する。

これ、実は人間のチームでもまったく同じ。
曖昧なリクエストでは動けないけど、制約と目的を明確にすると、誰もが最適なアイデアを出しやすくなる。

■ステップ3：設計会議でも使える「Structured Prompt Thinking」

僕の海外チームでは、AIとのやりとりで身につけたこの“構造化思考”を、そのまま 設計ディスカッション に応用しています。
たとえば、新しいUI機能を提案するときに、次のようなテンプレートを共有しました。

1. Background（背景）  
2. Problem（課題）  
3. Constraint（制約条件）  
4. Expected Behavior（期待する動作）  
5. Metrics（評価指標）

以前は、「これを追加したい」「動きが遅い」といった感覚的な話でミーティングが長引いていましたが、
このテンプレートを導入してから、ミーティング時間が体感で30％短縮。
さらに「責任の所在」や「タスクの明確化」も進み、開発の流れがスムーズになったんです。

このアプローチの面白いところは、AIとのプロンプト設計と同じ構造を持っている点。

  • AIに聞くとき：最適な回答を導くために、条件・目的・出力形式を定義する。
  • 人に伝えるとき：最適な議論を導くために、背景・制約・目的を共有する。

つまり、“構造化”とは単なるスキルではなく、「エンジニアが問題解決を共有するための共通言語」なのです。

■ステップ4：失敗から見えた“構造化不足”の罠

とはいえ、最初からうまくいったわけではありません。
以前、海外のフロントエンドエンジニアと共同開発をしていたとき、僕が曖昧な仕様書を出してしまい、
結果、UIの挙動が想定と違う方向に実装されたことがありました。

そのとき書いていた仕様は、こんな感じでした：

“When the user clicks the button, show a message.”

一見シンプルだけど、これでは何も伝わっていない。
「どんな種類のメッセージ？」「どの層のUI？」「非同期処理中でも可？」「条件は？」

その反省から、今では以下のように書くようにしています。

  • Trigger: User clicks the “Save” button
  • Condition: Form is valid and API call succeeds
  • Action: Show message “Data saved successfully” for 2 seconds
  • Constraint: Must not block UI thread
  • Output: Snackbar-style toast on bottom-right corner

この形式にしてから、英語が完璧でなくても誤解が減った。
それは、単語よりも「構造」が伝わるからです。
相手がアメリカ人でもインド人でも、図面のように理解してくれる。

■ステップ5：AI × エンジニア思考の融合

最近では、僕はこの構造化テンプレートをAIとのやりとりにも活用しています。
特に「AIを技術設計アシスタント」として使うときに有効です。

たとえば、C#のWPFアプリで非同期処理を最適化したいとき、以下のようにプロンプトを設計します。

[Context] WPF MVVM app, heavy I/O operations in ViewModel.
[Goal] Improve UI responsiveness without blocking.
[Constraint] Must use async/await pattern, no third-party libraries.
[Expected Output] Example code and performance reasoning.
[Iteration] Suggest optimization if CPU usage > 30%.

この形で投げると、AIが単にサンプルコードを出すだけでなく、
「なぜその設計が良いのか」「パフォーマンス面の考慮はどうか」といった“エンジニア的思考”を返してくれる。

これはもう、AIをただの「ツール」ではなく「共同設計者」として扱う感覚です。
そしてこの思考法は、海外チームとの議論にも完全に応用できる。
結局、AIも人も“構造”で動くんですよね。

シンプルな質問が、“設計ドキュメント”に進化するまで

――AIとの対話を通して見えた、「エンジニア的プロンプト」の正体

前回の「承」では、AIもチームメンバーも“構造”で動くという話をしました。
そして今回は、いよいよ「転」――つまり、抽象的な依頼を、どう構造化していくかという実践編です。

ここからは、僕が実際に体験した「WPFアプリ最適化タスク」を題材に、
プロンプトが進化していく過程を、リアルな会話形式で紹介します。

■ステージ1：ざっくりした質問から始まる

ある日、海外のチームで担当していたWPFプロジェクトのリリース前。
UIレスポンスが遅く、「ボタンを押してから反応が一瞬止まる」という報告が入りました。
僕はとりあえず、ChatGPTにこう聞きました。

“My WPF app freezes when I click a button. How can I fix it?”

ありがちな質問です。
するとAIの返答は──

“You might be blocking the UI thread. Try using async/await or a BackgroundWorker.”

……正論。でも、これだけじゃ足りない。
非同期処理の基本は分かっているけど、**自分のアプリ構造（MVVM＋コマンドバインディング）**ではどうすべきか、が肝なんです。
このままでは、ただの「コピペ修正」で終わってしまう。

■ステージ2：制約を入れる ― “文脈を教える”

次に僕は、AIにエンジニアとしての前提条件を与えました。
まるでチームミーティングで共有するように。

Context:

  • C# WPF app using MVVM
  • Command bound to Button executes heavy I/O (file upload)
  • UI freezes during execution

Goal:
Keep UI responsive using async/await pattern.

Constraint:
Cannot use third-party libraries. Must remain compatible with .NET 6.

すると返ってきたのは、まるで同僚がレビューしてくれたような提案。

public ICommand UploadCommand => new AsyncRelayCommand(UploadAsync);

private async Task UploadAsync()
{
    IsBusy = true;
    try
    {
        await Task.Run(() => UploadFile());
    }
    finally
    {
        IsBusy = false;
    }
}

さらにAIがこう続けました：

“To keep the UI responsive, move I/O to a background thread using Task.Run.
Consider displaying progress with a Progress<T> pattern.”

ここで初めて、「自分の設計パターン（MVVM）」に即した答えが返ってきました。
つまり、“制約を教えた”ことで、AIは「エンジニア的文脈」を理解し始めたのです。

■ステージ3：期待する出力形式を定義する ― “ドキュメントのように伝える”

ただコードをもらうだけでは終わりません。
次に、出力フォーマットを指定してみました。

Please output:

  1. Code example
  2. Explanation (why it works)
  3. Possible optimization points

返答は、驚くほど「設計レビュー資料」っぽくなりました。

① Code Example:
（前述の AsyncRelayCommand の実装）

② Explanation:

  • Task.Run prevents UI thread blocking.
  • Using await ensures exceptions are propagated properly.
  • The IsBusy flag allows UI to disable inputs while uploading.

③ Optimization:

  • If file size > 100MB, use chunked upload with streaming.
  • Consider cancellation support with CancellationToken.

まさに、“エンジニアがエンジニアに説明する構造”。
この段階で僕は確信しました。

良いプロンプトとは、設計書のようなものだ。

背景 → 制約 → 目的 → 出力形式を順に並べることで、
AIは「文法的な英語」ではなく「エンジニアリング思考」を理解してくれる。

■ステージ4：反復（Iteration）で“AIとの設計会議”を実現する

次に行ったのが、“反復”です。
つまり、AIの回答をそのまま受け取らず、設計ミーティングのように改良していく。

僕：「This works, but can we show upload progress on UI without freezing？」
AI：「Yes, use IProgress<T> pattern. Here’s how:」

private async Task UploadAsync(IProgress<int> progress)
{
    for (int i = 0; i < 100; i++)
    {
        await Task.Delay(50);
        progress.Report(i);
    }
}

AIがさらに提案してきた：

“Bind the progress value to a ProgressBar in your View via ViewModel.”

その瞬間、まるでAIと一緒にペアプログラミングしているような感覚になりました。
単なる「答えをもらう」から、「共に設計を進める」関係へと変わったのです。

■ステージ5：この考え方をチームに導入してみた

この成功体験を受けて、僕はチームの週次レビューでこう提案しました。

「AIに質問する時も、人にレビューをお願いする時も、“構造化テンプレート”を使おう。」

そのテンプレートはこんな形です：

# Structured Request Template

**Context:** （背景）  
**Problem:** （課題）  
**Constraint:** （制約条件）  
**Goal:** （目的）  
**Expected Output:** （欲しい形式）  
**Iteration Plan:** （確認と再提案の流れ）

この形式をSlackのスレッドやGitHub Issueに導入したところ、
レビュー依頼の往復回数が大幅に減り、ミスも減りました。
理由は単純で、**「相手が思考の文脈にすぐ入れる」**からです。

英語が完璧でなくても、「構造」が明確なら伝わる。
むしろ、「自然な文法より、構造化のほうが理解を助ける」ことを痛感しました。

■ステージ6：AIを“育てる”という発想

ここまで来ると、AIとの関係も変わります。
以前は“答えを出すツール”だったのが、
今では“設計パートナー”として「トレーニングする対象」になりました。

AIに「このチームの開発方針」「採用しているデザインパターン（MVVM、Repositoryなど）」を事前に教え、
「これを前提に考えて」と“priming（初期設定）”を行う。
すると、AIが返す提案がチーム文化に沿ったものになる。

この仕組みをチーム内で共有すると、
「AIがチームの一員みたいに設計思想を理解している」と驚かれました。

AIを正しく“プライミング”すること。
それは、AIに自分たちの設計哲学を教え込むということ。
エンジニアが設計思想をドキュメント化して伝えるのと、まったく同じです。

■まとめ：プロンプトは「思考の鏡」

シンプルな質問から始まり、構造化を重ねるうちに、AIとの会話は“設計会議”になっていきました。
AIは魔法ではなく、自分の思考の構造を映し出す鏡です。
雑に聞けば雑な答えが返る。構造的に伝えれば、構造的に返ってくる。

つまり――

「エンジニアリング思考を持った人ほど、AIを使いこなせる。」

これは、海外チームとのやり取りでもまったく同じ。
“英語力”ではなく、“構造力”が成果を分けるのです。

AIは“部下”じゃない、“相棒”だ。

AIとの仕事に慣れてくると、ふと勘違いしそうになる瞬間があります。
「AIは俺のアシスタントだ。自分の代わりに考えてもらおう」と。
でも、それって少し違うんですよね。

AIは“部下”ではなく、“相棒”です。
たしかに、こちらが指示を出せば即座に応えてくれる。
でも、その「応え方」を決めるのは、自分の質問の質なんです。
つまり、AIを使いこなす力は、結局のところ“自分の思考をどれだけ言語化できるか”にかかっている。

僕がWPFのUI設計でよく使うやり取りを例にしてみましょう。
あるとき、「ユーザーがボタンを押したらアニメーション付きで次の画面に遷移したい」と思った。
AIにざっくり「WPFでボタンを押したら画面がふわっと切り替わるコード教えて」と聞いたら、返ってきたのはシンプルなStoryboard例。
でも、正直「ふわっと」って、曖昧ですよね。
動きが速すぎても安っぽく見えるし、遅すぎてもテンポが悪い。

そこで、次にこう聞きました。

“FadeInアニメーションを300msで、EaseOutを使って自然に見せたい。MVVM構成でViewModelから制御できる形にしたい”

すると、AIは一気に構成を整えて、XAMLのアニメーション＋Commandパターン連携＋トランジション管理クラスまで提案してくれた。
この瞬間、僕は気づいたんです。

「AIは、こちらが“どう考えているか”を理解しようとしている」

それってつまり、AIとの対話は思考の鏡なんですよね。
自分の中で曖昧だった設計意図が、AIに説明する過程でどんどん明確になっていく。
その体験が、何よりも“エンジニアとしての思考筋”を鍛えてくれる。

僕が海外で働く中で感じたのは、
「英語が上手いこと」よりも、「自分の考えを整理して伝える力」こそが武器になるということです。
そして今、AI時代のエンジニアにも、まったく同じスキルが求められています。

AIに指示を出すときは、まるで国際チームの同僚に説明するのと同じ。
相手が人間であろうとAIであろうと、
「何をしたいか」よりも、「なぜそうしたいのか」を共有することで、結果の質はまるで違ってくる。

たとえば、プロジェクトのレビューでAIを活用する場面。
僕は最近、Pull Requestの内容をAIに要約させて、
「この変更の目的と影響範囲を、非エンジニアでも理解できる説明文にして」とお願いしています。
するとAIは、技術的な説明を自然言語で整理してくれる。
その出力を見て、チームメンバーが
「この変更、UIのユーザビリティも上がってるね」と気づいたりする。

AIを“作業短縮ツール”として見るのではなく、
**「チームの理解を深める媒介者」**として使う。
この視点を持つだけで、AIとの関係がぐっと変わります。

僕が最初に海外で働き始めた頃、
「相手に伝わるように話す」ことにずっと苦戦していました。
発音や文法よりも、自分の考えを整理することが苦手だったんです。
でも、AIとの対話を通してその力が自然と磨かれていった。

AIに“プロンプト”を考えるという行為は、
実は「自分の考えを設計する練習」なんです。
これはエンジニアにとって、究極の思考トレーニングツールだと思っています。

そして何より、AIとの仕事にはちょっとした“遊び心”も必要です。
コードや仕様の話ばかりじゃなく、
「この設計、ユーザーが触ったときに“気持ちいい”って思うかな？」
そんな感覚的な質問を投げると、意外な答えが返ってくることもある。
「人間の美意識」をAIにどう伝えるか。
そこには、創造性とロジックの境界が見えてくる。

結局、AIをどう使うかは、
自分がどんなエンジニアでありたいかにかかっていると思います。
“効率化”を求めるのか、“創造性”を広げるのか。
そのどちらの道を選んでも、AIはあなたのパートナーになってくれる。

ただし、そのパートナーを“使いこなす”には、
まず自分が「どんな出力を望むのか」を明確にしなければならない。
その力こそが、Engineer’s Mindset なんです。

これからのエンジニアは、
「AIに命令する人」ではなく、「AIと対話し、共に設計する人」になる。
僕たちは今、そんな時代の入り口に立っています。

AIが生成したコードを眺めながら、
ふとコーヒーをすする。
その瞬間に感じる“静かな高揚感”こそが、
エンジニアという職業の未来を照らしている気がします。

次にAIを開いたら、
ぜひ「please」でも「thank you」でもなく、
こう話しかけてみてください。

“Let’s build something together.”

そう言えるエンジニアこそが、
AI時代を“設計する”人たちなんだと思います。

コメント

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