要件定義は、白紙の資料から始めません
要件定義の材料は、すでに仕事の中に残っています。顧客や開発会社との打ち合わせなら、Google Driveの議事録や提案資料があります。既存システムを作り直すなら、実際の画面、業務で使っている表計算、コード、問い合わせや障害の記録も材料です。
一人でサービスを作る場合も同じです。ChatGPTに考えていることを話したり、友人とアイデアを話して録音したりすれば、作りたいことと迷っている点が言葉になります。要件定義は、頭の中にあるものを最初からきれいな文書へ直す作業ではありません。
ただし、集めた記録をそのまま開発へ渡しても使えません。会話には、困りごと、思いついた解決策、決まったこと、まだ決まっていないことが混ざっています。そこでBeekleでは、記録を要求へ整理し、今回作る範囲を決め、利用者の目的と完成条件に分けてから実装へ渡します。
会話を、まず「何を実現したいか」に戻します
打ち合わせでは、「承認ボタンが欲しい」「一覧画面を作りたい」のように、解決方法が先に出ます。そのまま仕様にすると、最初に思いついた方法へ開発が固定されます。そこで、誰が何に困り、何を実現したいのかへ戻します。
会話で出た案 | 要求として整理した内容 |
|---|---|
承認ボタンが欲しい | 経理責任者が、権限のある申請だけを承認し、誰が承認したか後から確認したい |
一覧画面を作りたい | 店舗担当者が、欠品しそうな商品を開店前に把握したい |
要求には、対象となる人、現在の問題、実現したい状態、放置した場合の損失、元になった議事録や録音を添えます。解決方法が変わっても、守るべき目的を見失わないためです。
要求：問い合わせの対応漏れを減らしたい
対象：営業担当者と営業責任者
現在の問題：担当者が決まっていない問い合わせや、期限を過ぎた案件が残っている
実現したい状態：今日対応すべき問い合わせをすぐ見つけられる
放置した場合の損失：商談機会の損失、顧客からの信用低下
元の記録：営業定例の議事録要求を拾うと、数はすぐに増えます。どれも必要そうに見える。でも、全部は作れません。次に決めるのは、今回どこまで作るかです。
三つの観点で、今回作る範囲を絞ります
Beekleでは、要求を事業上の価値、技術的な難しさ、現場で使われるかの三つで見ます。売上や費用に効いても、技術的な不確実性が大きければ先に小さく試します。作るのが簡単でも、利用者が使わないものは後回しです。
判断すること | 確認する内容 |
|---|---|
事業上の価値 | 誰が困っており、放置すると何を失うか |
技術的な難しさ | 外部連携、データ移行、権限、安全性などに不確かな点がないか |
現場で使われるか | 今の仕事より楽になるか。入力や確認の負担が増えすぎないか |
そのうえで、今回の目的に欠かせないものをMust、重要だが代わりの方法があるものをShould、余力があれば作るものをCould、今回は作らないものをWon'tに分けます。
Mustは、声が大きい人の要望ではありません。それがなければ、今回届けたい価値が成立しないものです。作る範囲を絞ってから、利用者ごとの目的へ分けます。
Mustを、利用者ごとの目的に分けます
機能名だけでは、誰の仕事をどう変えるのかが分かりません。「経費精算機能」ではなく、「経理担当者が領収書を登録し、経費申請を提出できる」と書きます。このように、利用者が何をできるようになるかを一文にしたものを、開発ではユーザーストーリーと呼びます。
一つの要求から複数の目的が生まれることもあります。経費精算なら、申請する、承認する、差し戻す、支払状況を確認する、は別の目的です。一つにまとめると、どこまで完成したのかも、変更がどこへ影響するのかも分かりません。
ただし、「申請できる」と書いただけでは完成条件になりません。保存までなのか、承認者へ届くところまでなのか。次は、具体的な利用場面にして答えを決めます。
完成条件を、日本語の「前提・もし・ならば」で決めます
完成条件は、どの状態で、何をすると、何が起きれば正しいのかまで書きます。Beekleでは、日本語の「前提・もし・ならば」で具体的な利用場面を表します。この書き方をGherkinと呼びます。
シナリオ：領収書を登録して経費申請を提出する
前提 田中が12,000円の領収書を登録している
もし 田中が経費申請を提出する
ならば 申請の状態が「承認待ち」になる
かつ 承認者が申請内容を確認できる通常の場面を書いたら、処理できない場合と、判断が変わる境目も確認します。権限がない人が承認しようとしたらどうなるか。申請額が上限と同額なら通るのか。実装後に揉めるのは、こうした条件です。
画面の約束と業務ルールも分けます。入力エラーをどこに出すか、どの画面へ移るかは画面の条件です。権限、計算、状態の変化は業務ルールです。両方を一つに詰め込むと、画面が悪いのか、判定が悪いのか分からなくなります。
要求と完成条件を作業に添え、同じ条件で確認します
利用者の目的と具体的な場面は、要件定義書に置いたままにしません。関連する実装作業に添え、作業を開けば、何のために作り、どの状態になれば終わりかを読めるようにします。
実装作業：経費申請を提出する処理を作る
元の要求：月末の転記作業と入力ミスを減らしたい
利用者の目的：経理担当者が経費申請を提出できる
通常の場面：申請すると承認待ちになる
失敗の場面：権限がない人は承認できない
境目の場面：上限と同額なら提出できるBeekleでは、この情報を人の開発担当にも、CursorやClaude Codeのような生成AIにも渡します。作業名だけではなく、元の要求と完成条件まで読ませることで、勝手な解釈を減らします。
実装後も別の正解を作りません。同じ利用場面で動作を確認し、確認した環境、合格か不合格か、画像や動画などの証拠、確認した人と日時を残します。これで、要求から動作確認までが一本につながります。
他社で止まった案件は、三日余りで要求と範囲を組み直しました
Beekleは、前の開発会社で進まなくなったシステムを引き継いだことがあります。資料と実装はありましたが、何を優先し、どの状態なら完成なのかが実装作業までつながっていませんでした。
そこで、すぐにコードを書き足さず、三日余りを使って要求と今回作る範囲を組み直しました。事業上の価値、技術的な難しさ、現場で使われるかを確認してMustを絞り、利用者の目的と具体的な場面へ分け、実装作業に添えました。
その後、約二週間の開発サイクル一回で、当時の管理上の進捗は約60％まで進みました。進み方を変えたのは、生成AIが速くコードを書いたことだけではありません。各作業に、作る理由、完成条件、確認方法が付いたため、実装のたびに仕様を解釈し直す時間が減りました。
ただ、最初にきれいにつなげれば終わり、とはなりません。実際の開発では、途中で要求が変わります。
JiraやGitHub Issuesでは、作業は追えても変更の影響までは追えませんでした
要件定義で最も重いのは、最初に書くことではなく、変更後も仕様と実装を同じ内容に保つことです。「承認者は部長」から「課長」へ変われば、要求の一文だけでなく、利用者の目的、権限の条件、画面表示、判定処理、動作確認まで見直す必要があります。
Beekleでも、以前は議事録や仕様をGoogle Driveに置き、案件ごとにJiraやGitHub Issuesで実装作業を管理していました。担当者や進み具合を追うだけなら、この方法で十分です。
でも、要求が変わったときに、どの文書とIssueを直すべきかまでは分かりません。関連する資料やIssueを人が探し、「ここも変わる」「この確認もやり直す」と一つずつつなぎ直す必要があります。数が少ないうちは何とかなります。変更が重なると、普通にきついです。
JiraやGitHub Issuesが悪いわけではありません。どちらも作業を管理するための道具です。そこへ、要求の整理、完成条件、変更の影響確認、動作確認まで持たせようとしたことに無理がありました。
そこで必要になったのは、別の作業管理表ではなく、会話から要求、完成条件、実装作業、動作確認までの関係を保つ仕組みでした。
要求から動作確認までのつながりを保つために、PM on Railsを作りました
この課題を解くためにBeekleが作ったのが、PM on Railsです。PM on Railsは、顧客の要望を、今回作る範囲、利用者の目的、具体的な利用場面、実装作業、動作確認までつないで管理する開発支援システムです。
使い始めるときに、完成した要件定義書は必要ありません。議事録や資料、ChatGPTとの会話などから要求を整理し、今回作るものと作らないものを決めます。決まった要求は、利用者の目的と「前提・もし・ならば」の利用場面に分け、関連する作業へつなぎます。
PM on Railsは、業務上の判断を生成AIへ丸投げするためのものではありません。事業上の価値、今回のMust、まだ決まっていない業務ルール、顧客として受け入れるかは、人が決めます。生成AIとシステムは、情報の整理、重複や矛盾の確認、変更が影響する場所を探す作業を補助します。
小さな案件なら、この記事の手順を文書と表計算で管理できます。ただ、要求と利用場面が増え、変更が重なると、関係を保つ作業だけで時間を取られます。PM on Railsは、その負担を減らし、人が価値と業務ルールの判断に集中するための仕組みです。
PM on Railsで、要求から実装・動作確認までをつなぐ方法を見る
要件定義が終わったかは、資料の枚数ではなくつながりで判断します
- 要求の元になった議事録、録音、資料、画面、コードをたどれる
- 誰が何に困り、何を実現したいのかが分かる
- 事業上の価値、技術的な難しさ、現場で使われるかを確認している
- 今回必ず作るものと、今回は作らないものが合意されている
- 利用者ごとの目的と、通常、失敗、境目の場面が書かれている
- 実装作業が、対応する利用場面につながっている
- 同じ利用場面で動作を確認し、証拠を残している
- 要求が変わったとき、見直す仕様、実装、確認項目をたどれる
要件定義の目的は、立派な資料を完成させることではありません。会話や資料に散らばった考えを、今回作る範囲、利用者の目的、完成条件、実装、動作確認まで切れずにつなぐことです。