「ITのことはよくわからないから、あとはプロのエンジニアにお任せ」でシステム開発を始めると、ほぼ確実に失敗します。発注側のプロジェクト管理は、エンジニアの作業を監視することではなく、ビジネスの目的を1本の開発パイプラインに乗せ続けることです。本記事は、Beekleが推奨する 6ステップのパイプライン を、各ステップの専用記事と無料ツールへ直結させた完全ガイドです。
Beekle推奨：発注側が回す6ステップパイプライン
- アクター（登場人物）を決める — 誰がこのシステムを使うのか
- As-Is / To-Be を可視化する — DX案件なら必須。現状業務と理想業務の差分を絵にする（業務フロー可視化ツール）
- ユーザーストーリー＋EARS — 「誰が・何を・なぜ」を書き、受入条件を EARS 5パターンで分解する（ユーザーストーリー作成ツール）
- FM法でスコープを決める — 何を作る／作らない／後回しを3軸で確定する（スコープ管理ツール）
- Gherkin で機能要件＋非機能要件を仕様化 — Given/When/Then で書き、デモ・受入テスト・自動テストを1本化する
- Laravel + Inertia でプロトタイプ実装 — 1〜2週間で動くたたき台を作り、現場で触ってもらう
このパイプラインに乗っている限り、生成AIの「最初の8割を高速に書く」能力をそのまま受け止められます。1〜5の上流が崩れていると、AIが速く書いた分だけ「使われない機能」が量産されるだけです。
なぜエンジニア丸投げが失敗するのか
エンジニアはシステムの構造を設計するプロですが、皆様の会社のビジネスモデルや現場の業務フローまで熟知しているわけではありません。発注側がプロジェクトに関与しないと、次のリスクが必ず顕在化します。
- 現場の業務フローとシステムが噛み合わず、誰も使わないシステムができあがる
- 開発途中で現場から「あれもこれも」と要望が膨らみ、予算とスケジュールが破綻する
- 「進捗は順調です」と書類で報告されていたのに、納品直前に動かないことが発覚する
典型的な失敗パターンは DX・システム開発で失敗する典型5パターン と システム開発の失敗事例8選 にまとめています。本記事の6ステップは、これらの失敗パターンに対する処方箋として組み立てたものです。
STEP 1: アクター（登場人物）を決める
最初にやるべきは、画面の絵を描くことでも要件を書くことでもなく、このシステムに登場する人と外部システムを全部書き出すことです。たとえば在庫管理なら「店舗マネージャー」「本部発注担当」「物流倉庫スタッフ」「会計システム」「販売POS」。アクターを決めずに要件定義に進むと、誰の困りごとを解決しているのか分からないまま機能だけが膨らみます。
各アクターについて、役割／日常業務／このシステムで困っていること／成功したと感じる瞬間の4点を1〜2行で書きます。これがSTEP 3のユーザーストーリーの種になります。要求と要件の違いに不安がある場合は 要求定義と要件定義の違い を先に読んでください。
STEP 2: DX案件なら As-Is と To-Be を可視化する
新規システム（ゼロからの構築）はSTEP 3に進んで構いませんが、既存業務をシステム化する DX 案件では、ここで現状業務（As-Is）と理想業務（To-Be）の業務フローを可視化します。可視化なしに要件を書くと、「現状の不便」がそのままシステムに移植されます。
可視化は紙でもホワイトボードでも構いませんが、ブラウザだけで完結させたい場合は 業務フロー可視化ツール を使ってください。As-Is と To-Be をスイムレーン形式で並べ、差分（自動化される処理／消える処理／新しく必要になる承認）を視覚化できます。To-Be で「消える処理」が見えると、STEP 4 の FM 判定で「作らない」を判断する材料になります。
STEP 3: ユーザーストーリー＋EARS で要件を書く
アクターと業務フローが揃ったら、要件を 2層構造 で書きます。
- ストーリー本体：「As a 〜 / I want to 〜 / So that 〜」の3要素で、誰が・何を・なぜ を1行に
- 受入条件：そのストーリーが満たされたと判定するシステムの振る舞いを EARS 5パターン（ユビキタス／イベント駆動／状態駆動／オプション／望まない振る舞い）で分解
ストーリーだけでは「具体的にどう動くべきか」が決まらず、EARSだけでは「なぜこの機能が必要か」が抜け落ちます。両方を揃えて初めて、エンジニアと業務担当者の解釈が一致します。書き方は ユーザーストーリーの書き方完全ガイド と EARS（要件記述構文）入門。実例集は 要件定義書テンプレート＋EARS記法とユーザーストーリーの実例集。
書き出しは ユーザーストーリー作成ツール を使うと3要素が揃わない歪なストーリーをツール側で弾けます。
{{CONTACT_CTA_MID}}
STEP 4: FM法でスコープを決める
STEP 3 で書き出すと、ストーリーは通常 30〜80件に膨らみます。全部作ろうとすると予算もスケジュールも破綻するので、FM法（Functionality Matrix） で「作る／作らない／後回し」を3軸で判定します。
- ビジネス価値（★1〜3）：使われると儲かる／コストが下がるか
- 現場で使えるか（★1〜3）：実際の業務オペレーションに乗るか
- 技術コスト（低／中／高）：作る難しさ
1軸でも★1（または技術コスト=高）が付けば「作らない」、★3が2軸以上なら「作る」、それ以外は「後回し」が原則です。詳細は スコープ管理「FM法」の使い方、MoSCoW との比較は 要件の優先順位付け：MoSCoW vs FM法 完全比較、「使われないシステムを作らない」観点は 機能フィルタリング｜FM活用法。発注側がFM以外で背負わなくていいタスクは 発注側がやらなくていい2つのこと も併せて読んでください。
判定はブラウザだけで動く スコープ管理ツール でそのまま回せます。
STEP 5: Gherkin で機能要件＋非機能要件を仕様化する
FMで「作る」と判定された要件だけを、Given / When / Then の Gherkin に書き直します。Gherkin の最大の利点は、3つの役割を1つの記述で兼ねられることです。
- 仕様書として読める（業務担当者が読んで意味が分かる）
- 受入デモのシナリオとしてそのまま動く
- 自動テストのソースとしてCIで毎回実行できる
記法は Gherkin入門、EARSからGherkin・デモ・テストへ一直線につなぐ実践は EARS×Gherkinワークフロー を参照してください。
非機能要件も Gherkin で書く
性能・セキュリティ・可用性などの非機能要件は、別ドキュメントで散逸しがちですが、Gherkin で同じ Given/When/Then 形式に書くと機能要件と同じデモ／テストの線に乗せられます。
Scenario: 在庫検索の応答時間（性能）
Given 商品マスタが10万件登録されている
When 店舗マネージャーがキーワード「冷凍」で検索する
Then 検索結果は1秒以内に表示されるScenario: 権限のない閲覧の遮断（セキュリティ）
Given 一般スタッフ権限でログインしている
When 仕入原価ページにアクセスする
Then 403エラーページが表示される
非機能要件をGherkin化することで、「速度については後で考えましょう」と先送りされて納品直前に発覚する性能事故を防げます。
STEP 6: Laravel + Inertia でプロトタイプを実装する
STEP 1〜5の上流が固まれば、実装は Laravel + Inertia.js + React の組み合わせが最短です。理由は4つ。
- 認証・権限・キュー・スケジューラ・管理画面が標準機能で揃っており、業務システムの「最初に必要になる8割」を自分で書かずに済む
- SPA の操作感を保ったまま、API設計・OpenAPI・JWTなどの境界の設計を後回しにできる（Inertia がコントローラ→React を直結する）
- Eloquent と Inertia は生成AIにとってサンプル量が多い領域で、コード生成精度が高い
- 本番運用に向かうとき、Laravel のままそのままスケールできる（プロトタイプを捨てる必要がない）
Next.js + 任意のORM の構成でも作れますが、認証・権限・queue・cron・admin あたりを自前で組む工数が乗るため、「1〜2週間でプロトタイプ」のスピードは出にくくなります。プロトタイプ段階では フルスタックで完結する組み合わせ を選ぶのが基本です。1〜2週間で作る具体ステップは 生成AIで1〜2週間プロトタイプを作る4ステップ を参照してください。
プロジェクト全体の期間と「90対90ルール」
STEP 6で動くプロトタイプは1〜2週間で作れますが、企画 → 要件定義 → プロトタイプ → 検証 → 本格開発 → テスト → 本稼働 の全体期間は短くなりません。小規模で3〜6ヶ月、中〜大規模で半年〜1年超が目安です。Tom Cargill の 90対90ルール（最初の9割のコードが時間の9割を消費し、残り1割がさらに9割を消費する）どおり、例外処理・同時編集の競合・タイムゾーン・権限の境界条件・本番データのリカバリ手順は最後の1割で時間を吸います。
全工程の進め方は 生成AI開発の進め方｜PoCからプロトタイプ・本番までの全工程 と 段階的に進める方法｜MVP・プロトタイプ活用法、進捗の見方は 進捗管理｜経営者が見るべき3指標、予算の守り方は 予算オーバーを防ぐ要件と進捗の管理術 を参照してください。
まとめ：6ステップに乗せれば失敗しない
発注側のプロジェクト管理は、6ステップのパイプラインを回せるかどうかに集約されます。
- STEP 1 アクター → 誰のためのシステムかを確定する
- STEP 2 As-Is/To-Be → 業務フロー可視化ツール で業務差分を可視化（DX案件のみ）
- STEP 3 ユーザーストーリー＋EARS → ユーザーストーリー作成ツール ／ 書き方ガイド ／ EARS入門
- STEP 4 FM法 → スコープ管理ツール ／ FM法の使い方
- STEP 5 Gherkin（機能＋非機能） → Gherkin入門 ／ EARS×Gherkin
- STEP 6 Laravel Inertia 実装 → 1〜2週間プロトタイプ
Beekleでは、この6ステップを発注側と一緒に回す伴走支援を行っています。要件定義の整理からプロトタイプ検証、段階的なリリース管理まで、不安があればお気軽にご相談ください。
よくある質問（FAQ）
Q1. 6ステップを全部やる時間がない場合はどこを削れますか？
A. STEP 2（As-Is/To-Be）は新規システムでは省略可、STEP 5の非機能要件Gherkin化はMVPでは絞り込み可です。一方 STEP 1（アクター）／STEP 3（ストーリー＋EARS）／STEP 4（FM） はどんな案件でも省略不可です。ここを飛ばすと、後段でAIが速く書いた分だけ手戻りが増えます。
Q2. PMBOKやアジャイルとの関係は？
A. 6ステップはPMBOKの「スコープ／要件管理」とアジャイルの「バックログ／受入基準」を、発注側でも回せる粒度に再構成したものです。PMBOK第7版以降のアジャイル統合とも矛盾しません。
Q3. 進捗が遅れていることはどうやって早く検知できますか？
A. STEP 5 の Gherkin シナリオを「完了の定義」に使うのが最強です。「Scenario X が緑（テスト合格）になったら完了」と定義しておけば、「8割できた」のような曖昧な進捗報告を物理的に防げます。
Q4. 炎上プロジェクトを引き継いだらまず何をすべきですか？
A. 1) STEP 4 のFMを再実施して残スコープを切る、2) STEP 5 のGherkinで「最低限の受入基準」を再定義する、3) ステークホルダーに正直に共有して期待値を再調整する、の順です。希望的観測で続行するほど傷が深くなります。