開発プロジェクトを失敗させないための「開発プロセスチェックリスト」— Beekleの普段行っている開発に沿って
新規事業や業務システムの開発で、こんな悩みはありませんか。
- 顧客の要望を聞いたはずなのに、出来上がったものが想像と違う
- 仕様変更が頻発し、開発側との関係がぎくしゃくする
- 何が完成で何が未完成なのかが曖昧なまま、リリース日が来てしまう
これらは多くの場合、プロセスの問題です。技術力やメンバーの能力ではなく、「どの順番で、何を、誰と合意しながら進めるか」が定まっていないために起きます。
Beekleでは、お客様との会話から要求を引き出し、優先度をつけ、ユーザーストーリーとシナリオに落として、Gherkin（Given / When / Then）で受け入れ条件を握り、BDD（ビヘイビア駆動開発）で実装する、という流れで開発を進めています。本記事では、この流れを各フェーズのチェックリストとしてまとめました。プロジェクト開始前と途中の節目で、「やること」「判断ポイント」「成果物」が揃っているかを確認してください。
フェーズ 1. お客様との対話を記録する
要求の出発点は、必ず一次情報です。担当者の記憶や要約ではなく、生の会話から始めます。
- お客様（または現場担当者）との対話を録音・文字起こしする
- 議事録ではなく「発言そのもの」を残す（要約・解釈は後工程で行う）
- 複数の関係者の声を集める（決裁者・利用者・運用者）
- 対話の場には開発側のメンバーも同席させる
判断ポイント — 「これで十分か？」と迷ったら、もう 1 回ヒアリングを設定する。情報収集の不足は、後工程すべてに波及します。
成果物 — 文字起こしテキスト、参加者リスト、論点メモ。
フェーズ 2. 会話から要求を引き出す
集めた発言を「やりたいこと」「困っていること」「実現したい状態」に整理します。
- 発言の中から「業務上の困りごと」を抽出する
- 困りごとの背景にある「本当に達成したいこと」を言語化する
- 1 つの要求に対して、なぜそれが必要かを 1 文で書けるようにする
- お客様に整理結果を見せて「これで合っていますか？」と確認する
判断ポイント — お客様が「そうそう、これが言いたかった」と言うまで磨き込む。違和感が残ったまま次に進まない。
成果物 — 要求リスト（タイトル + 背景 + 期待する状態）。
フェーズ 3. 優先度をつける（FM／ファンクショナリティ・マトリクス）
すべてを同時にはやれません。各要求をビジネス価値・現場で使えるか・技術コストの 3 軸で評価し、作る／後回し／作らないに振り分けます。
- 各要求を「ビジネス価値（1〜3）」「現場で使えるか（1〜3）」「技術コスト（1〜3）」で評点する
- 評点をもとに作る／後回し／作らないを判定する
- 「作らない」と判定したものを、明示的に書いて合意する（あいまいに残さない）
- 判定結果を一覧で見える化し、お客様・開発側の双方で握る
判断ポイント — 「作る」を増やしすぎない。優先度の本質は「やらないことを決めること」です。
成果物 — FM 形式の優先度判定一覧（CSV / Markdown）。
ブラウザ上で要求文を取り込んで FM 判定できるツールを公開しています： スコープ管理ツール（FM形式）
フェーズ 4. ユーザーストーリーとシナリオに落とす
「作る」と決めた要求を、誰のための機能なのか・どう使われるのかが分かる単位に書き直します。ここが Gherkin・BDD の素材になります。
- 各要求をユーザーストーリー形式で書く（「**〜として、〜したい。なぜなら〜だから**」）
- 1 つのストーリーに対し、利用シーンを具体的なシナリオとして書き出す
- 正常系（うまくいく流れ）だけでなく、異常系・例外パターンのシナリオも用意する
- お客様自身に読んでもらい、「自分の業務として違和感がないか」を確認する
判断ポイント — シナリオが具体的に書けないストーリーは、まだ要求が曖昧。フェーズ 2 に戻って磨き直す。
成果物 — ユーザーストーリー一覧、シナリオ一覧（自然言語）。
フェーズ 5. Gherkin で受け入れ条件を合意する
各シナリオを Gherkin（Given / When / Then）の形に落として、「何ができたら完成と認めるか」をお客様と握ります。
- シナリオごとに「**前提（Given）／操作（When）／期待結果（Then）**」を書き出す
- あいまいな形容詞（「使いやすい」「速い」など）は排除し、測定・確認できる表現にする
- お客様に Gherkin を読んでもらい、「この通りに動けば完成と認める」ことに合意する
- 受け入れテストの実施者・実施タイミングを決めておく
判断ポイント — Gherkin が書けない＝完成条件が決まらない。書ききれない機能は、その時点では作らない。
成果物 — .feature ファイル群（Given / When / Then 形式の受け入れ条件）。
フェーズ 6. BDD でスプリントを回す
合意した Gherkin をそのままテストの土台にして、2 週間など短い区切りで「動くもの」を作って見せていきます。
- 1 スプリントで完成させられる単位に Gherkin（feature）を切り分ける
- スプリント開始時に「このスプリントで Green にする feature」を確定する
- 受け入れ条件を自動テスト化し、ローカル・CI で日次に実行する
- 「未着手 / 実装中 / Green / レビュー / 完了」のステータスを毎日更新する
- スプリント中に新しい要望が出ても、原則は次スプリントに回す（フェーズ 2〜5 を経由させる）
- スプリント終了時に動くものをお客様に見せ、フィードバックをもらう
- ブロッカーが出たら 24 時間以内に関係者で共有する
判断ポイント — 「順調です」という口頭報告だけで満足しない。Gherkin が Green になっていない機能は、進捗ゼロとみなす。
成果物 — スプリント計画、自動テスト結果、スプリントレビュー記録、進捗サマリー。
フェーズ 7. 振り返りと改善
スプリントごとに、プロセスそのものを良くしていきます。
- スプリント終了ごとに「うまくいったこと」「困ったこと」を関係者で話す
- 1 つだけでいいので、次のスプリントで試す改善アクションを決める
- お客様からのフィードバックを次の要求リスト・ユーザーストーリーに反映する
- 完了した機能を「ちゃんと使われているか」リリース後に確認する
判断ポイント — 振り返りで「特にありません」が出る場合、議論が浅い。具体的な事実を 1 つでも引き出す。
成果物 — 振り返り記録、改善アクションリスト、利用状況レポート。
チェックリスト全体を通して大切なこと
要するに、次の流れを守ることに尽きます。
- 要求をまとめる — お客様の発言から「何をしたいのか」を引き出して整理する
- 優先度をつける — 全部はやらない。価値・現場適合・コストで取捨選択する
- ユーザーストーリーとシナリオに落とす — 「誰が／何を／なぜ」と「こう操作したらこうなる」を具体化する
- Gherkin で受け入れ条件を書く — Given / When / Then の形でお客様と握る
- BDD で開発する — 受け入れ条件をそのままテストにし、満たせたら完成と判定する
この流れを通して守るのは、ただ一つ。お客様の発言と、最終的に動くもの・テストするものが、ひもづいて見える状態を保つこと です。
Beekleでは、このプロセスを「お客様との会話を入り口に、自然に要求がまとまり、そのまま開発・管理までつながる」よう設計して日々の開発に活用しています。チェックリストの各項目を、人手とエクセルではなく、製品の機能として標準装備した PM on Rails も提供しています。ご興味のある方は、ぜひお問い合わせください。