# 開発プロジェクトを失敗させないための「開発プロセスチェックリスト」— 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形式）](/tools/scope-manager) --- ## フェーズ 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 つでも引き出す。 成果物 — 振り返り記録、改善アクションリスト、利用状況レポート。 --- ## チェックリスト全体を通して大切なこと 要するに、次の流れを守ることに尽きます。 1. 要求をまとめる — お客様の発言から「何をしたいのか」を引き出して整理する 2. 優先度をつける — 全部はやらない。価値・現場適合・コストで取捨選択する 3. ユーザーストーリーとシナリオに落とす — 「誰が／何を／なぜ」と「こう操作したらこうなる」を具体化する 4. Gherkin で受け入れ条件を書く — Given / When / Then の形でお客様と握る 5. BDD で開発する — 受け入れ条件をそのままテストにし、満たせたら完成と判定する この流れを通して守るのは、ただ一つ。**お客様の発言と、最終的に動くもの・テストするものが、ひもづいて見える状態を保つこと** です。 Beekleでは、このプロセスを「お客様との会話を入り口に、自然に要求がまとまり、そのまま開発・管理までつながる」よう設計して日々の開発に活用しています。チェックリストの各項目を、人手とエクセルではなく、製品の機能として標準装備した PM on Rails も提供しています。ご興味のある方は、ぜひお問い合わせください。