1. なぜ「日本語」で話しているのに伝わらないのか
「急いで作ってと言ったのに、技術的な理由でできないと断られた」。 「こちらの要望は伝えたはずなのに、出来上がった画面は全くイメージと違っていた」。
システム開発の現場で、経営者や発注担当者が最もストレスを感じるのは、エンジニアとのコミュニケーション不全です。同じ日本語を話しているはずなのに、まるで異国の言葉を聞いているかのように話が噛み合わない。
実はこれ、どちらかが悪いわけではありません。「ビジネスの言葉」と「システムの言葉」の翻訳機能が働いていないことが原因です。 本記事では、技術用語を一切使わずに、エンジニアと正確に意思疎通し、彼らの能力を最大限に引き出すための「発注側の技術」を解説します。
2. 実践手順：文脈を伝える「ユーザーストーリー」の技術
エンジニアに「機能リスト」を渡すのはやめましょう。代わりに、「ユーザーストーリー」を共有してください。これは「誰が」「何を」「なぜ」するのかをセットにした、開発の共通言語です。
手順1：ユーザーストーリーの「型」を使う
ユーザーストーリーには明確なフォーマットがあります。必ずこの型で伝えてください。
「＜誰＞ として」 「＜何＞ をしたい」 「それは ＜なぜ（メリット）＞ だからだ」
悪い例（機能のみ）： 「在庫数を変更できる機能が欲しい」
良い例（ユーザーストーリー）： 「手袋をした倉庫作業員として（誰）」 「スマホでワンタップで在庫数を減らしたい（何）」 「作業中に手袋を外すと、再装着に時間がかかり業務が止まるからだ（なぜ）」
ここまで具体的であれば、エンジニアは「じゃあ文字入力はやめて、＋ーボタンを特大サイズにしましょう」と、「手袋をしている」という制約（文脈）に合わせた最適な技術選定が可能になります。
手順2：言葉ではなく「動くもの」を指差す
人間は、言葉や静止画のデザインだけでは、自分が本当に欲しかったものを判断できません。「使いやすい画面で」という指示は、100人いれば100通りの解釈が生まれます。
最も確実な方法は、開発初期に簡単なプロトタイプ（動くハリボテ）を作ってもらうことです。「これと同じ動きにしたい」「ここをクリックしたらこうなってほしい」と、動くものを指差しながら会話してください。 議論よりも「実物」を共通言語にすることで、認識のズレ（Gap）を劇的に減らすことができます。
手順3：優先順位は「捨てるため」につける
「あれもこれも全部大事」という指示は、エンジニアを最も困惑させます。 全ての要望に対し、以下の3つの基準で優先順位をつけてください。
1. Must（松）：これがないと業務が止まる、サービスとして成立しない。
2. Should（竹）：あった方がいいが、運用（Excelなど）でカバーできるなら後回しでもいい。
3. Want（梅）：あれば嬉しいが、なくても困らない。
特に重要なのは「梅（Want）」を決めることです。トラブルが起きた際、エンジニアが自律的に「梅の機能はカットして、松の品質確保に集中しよう」と判断できる環境を作ることが、プロジェクト成功の鍵です。
4. まとめ
エンジニアとのコミュニケーションにおいて、経営者が意識すべきは以下の点です。
• 機能リストではなく、「誰が・何を・なぜ」をセットにした「ユーザーストーリー」で会話する。
• 「手袋をしている」「薄暗い」といった現場の制約こそが、技術選定の重要なヒントになる。
• 言葉やドキュメントを過信せず、「動くプロトタイプ」を共通言語にする。
システム開発の成功は、コードの品質以前に、発注者がどれだけ「現場のリアルな文脈」をエンジニアに伝えられるかで決まります。まずは「なぜ作るのか」を熱く語ることから始めてください。
--------------------------------------------------------------------------------
よくある質問（FAQ）
Q. エンジニアが専門用語ばかり使って何と言っているか分かりません。 A. 正直に「分かりません」と伝えて問題ありません。「その技術を使うと、ユーザー（現場）にどんなメリットがあるのか、ビジネス的にどう良いのかで説明してください」とリクエストしましょう。優秀なエンジニアほど、平易な言葉で翻訳して説明できるはずです。
Q. ユーザーストーリーはどのくらい細かく書けばいいですか？ A. 「ボタンの色」などの解決策（How）は書かず、「手袋をしているから押しにくい」といった**課題と背景（Why）**を詳しく書いてください。解決策を考えるのはエンジニアの仕事であり、背景さえ伝わっていれば、彼らはプロとして最適な答えを出してくれます。
Q. エンジニアとの定例会議はどのくらいの頻度が適切ですか？ A. 1〜2週間に1回が目安です。進捗報告を聞くだけでなく、必ず「その期間に作った動くもの（プロトタイプ）」を見せてもらい、ユーザーストーリー通りに機能しているかを確認する場にしてください。