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