なぜ「日本語」で話しているのに伝わらないのか
「急いで作ってと言ったのに、技術的な理由でできないと断られた」「要望は伝えたはずなのに、出来上がった画面はイメージと違っていた」——システム開発の現場で発注担当者が感じるストレスは、ほぼすべて「ビジネスの言葉」と「システムの言葉」の翻訳機能が働いていないことが原因です。
翻訳機能は精神論では立ち上がりません。共通の構造があって初めて、両者の言葉が同じ意味で接続されます。Beekleはこの共通構造として、6ステップのパイプライン を推奨しています。本記事は、各ステップで発注側がエンジニアとどう会話するかを、具体例で示します。
共通言語としての6ステップパイプライン
- アクターを決める
- As-Is / To-Be を可視化する（DX案件）
- ユーザーストーリー＋EARS で要件を書く
- FM法 でスコープを決める
- Gherkin で機能＋非機能を仕様化する
- Laravel Inertia でプロトタイプを実装する
会話も依頼も成果物の確認も、すべてこの6ステップのどこの話をしているかを明示するところから始めます。「いつかやる」「優先度を上げて」のような場所のない依頼は、エンジニア側で受け止めようがありません。
STEP 1〜3：「Why」を伝える会話術
エンジニアに最初に渡すべきは 機能リストではなくユーザーストーリー です。「誰が／何を／なぜ」をセットにすると、エンジニアは「なぜ」から技術選択肢を逆算できます。
悪い例（機能のみ）：「訪問先で記録をつける機能が欲しい」
良い例（ストーリー）：
訪問看護師として、利用者宅でその場で看護記録をつけたい。なぜなら、帰社してから30件分を思い出して書くと記憶違いが起きるからだ。
背景が伝わると、エンジニアは「利用者宅のネット環境が不安定かもしれない」「移動中の車内で片手操作が必要かもしれない」と推察し、「オフライン保存」「音声入力」「前回記録の自動呼び出し」といった解決策を比較検討できます。Why が伝われば、How はエンジニアが選んでくれます。
ストーリーの書き方は ユーザーストーリーの書き方完全ガイド、書き出しは ユーザーストーリー作成ツール を使うと3要素の漏れをツールが弾きます。受入条件を曖昧にしないコツは、ストーリーごとにEARS記法で「いつ・どんな条件で・システムが何をするか」を分解することです（EARS入門）。
DX案件で現状業務を引きずっている場合は、ストーリーに進む前に 業務フロー可視化ツール で As-Is と To-Be を可視化してください。「現在の不便」をそのままシステムに移植する事故を防げます。
STEP 4：「捨てる」決定はFMで会話する
「あれもこれも全部大事」という指示は、エンジニアを最も困惑させます。Must / Should / Want の3段階優先度は最低ラインですが、BeekleではFM法（3軸評価）に揃えることを推奨しています。
- ビジネス価値（★1〜3）：使われると儲かる／コストが下がるか
- 現場で使えるか（★1〜3）：実際の業務オペレーションに乗るか
- 技術コスト（低／中／高）：作る難しさ（エンジニア側が埋める）
3軸を発注側とエンジニアで一緒に埋めると、優先度の議論が「印象論」から「3軸の数字を変える議論」になります。トラブル発生時にも「★1のSTEP 4＝作らないものから順に削る」という共通ルールで動けます。詳しくは FM法の使い方 と 使われないシステムを作らない方法、運用は スコープ管理ツール。
STEP 5〜6：言葉ではなく「動くもの」で議論する
人間は、言葉や静止画のデザインだけでは、自分が本当に欲しかったものを判断できません。「使いやすい画面で」という指示は、ある人には「ボタンが大きい」、別の人には「項目が少ない」、また別の人には「今まで使っていた画面に近い」と解釈されます。
このギャップを埋める最強の道具が Gherkin と動くプロトタイプ です。
- STEP 5 で書いた Gherkin の Scenario が画面で順に実行される様子 を、定例会議でそのまま見せてもらう
- STEP 6 の Laravel Inertia プロトタイプを、現場担当者に直接触ってもらう
定例会議では「進捗90%です」という書類を信じず、必ず1〜2週間ごとに動くデモを見せてもらってください。Gherkin の Scenario が緑（テスト合格）になっているかどうかが、最も嘘のつけない進捗指標です。1〜2週間でプロトタイプを作る具体プロセスは 生成AIで1〜2週間プロトタイプを作る4ステップ を参照してください。
まとめ
エンジニアとのコミュニケーションは、根性論ではなく 6ステップの共通構造 に乗せることで安定します。
- 機能リストではなく、「誰が・何を・なぜ」をセットにしたユーザーストーリーで会話する（STEP 3）
- 受入条件はEARSで分解し、解釈の余地を残さない（STEP 3）
- 優先順位は印象論ではなくFM法の3軸で決め、「捨てる基準」を共有しておく（STEP 4）
- 言葉やドキュメントを過信せず、Gherkin の動くシナリオとプロトタイプを共通言語にする（STEP 5・6）
- 1〜2週間ごとに動くデモを確認し、書類上の進捗報告に頼らない
システム開発の成功は、コードの品質以前に、発注者がどれだけ「現場のリアルな文脈」を6ステップに乗せて翻訳できるかで決まります。全体像は プロジェクト管理 完全ガイド を参照してください。
FAQ
Q1. エンジニアが専門用語ばかり使って何と言っているか分かりません。
A. 正直に「分かりません」と伝えて問題ありません。「その技術を使うと、6ステップのどこに効くのか／ユーザーにどんなメリットがあるのか」で説明し直してもらいましょう。優秀なエンジニアほど、平易な言葉で翻訳できます。
Q2. ユーザーストーリーはどのくらい細かく書けばいいですか？
A. 「ボタンの色」などの解決策（How）は書かず、「作業中断ができないから一瞬で入力したい」といった課題と背景（Why）を詳しく書いてください。具体の振る舞いはストーリー本体ではなく、紐づくEARS受入条件のほうに書くと整理できます。
Q3. エンジニアとの定例会議はどのくらいの頻度が適切ですか？
A. 1〜2週間に1回が目安です。進捗報告を聞くだけでなく、必ず「その期間に作った動くもの」を見せてもらい、Gherkin Scenario が緑になっているかとプロトタイプを触って違和感がないかの2点で確認してください。