要件定義とは、関係者の頭の中にある「当然こうなるだろう」という前提を、言葉と数字に置き換える作業です。開発側に正しく伝わる粒度で書くことと、現場が実際に使える内容になっていることの両方が求められます。この記事では、機能要件と非機能要件の書き方、抜け漏れを潰す3つの俯瞰ツール、現場で使われ続けるための合意事項を順に説明します。
要件定義がないと何が起きるか
よくあるのは、開発が終わってから認識のずれが見つかるケースです。依頼側は「承認はボタン1回で終わる画面」を想像していたのに、開発側は「承認フォームに入力欄が10個ある画面」を作っていた、という具合です。
ずれが起きる原因はほぼ決まっています。
- 「使いやすく」「すぐに」「柔軟に」といった言葉の意味が人によって違う
- エラーや例外のときの動きを誰も考えていなかった
- 暗黙の前提が共有されていなかった
出発点は常にTOBE業務フロー
要件定義でまず押さえたいのは、機能要件はTOBE業務フローを「システムにやらせる単位」に分解したものだという点です。「機能要件」と聞くと画面や入力項目から書き始めがちですが、画面はTOBEを実現する手段にすぎません。TOBEを飛ばして画面イメージから作り始めると、現場で「この業務の流れには合わない」が起きます。TOBEの描き方はTOBE業務フローの記事を参照してください。
機能要件の書き方
1行の要件は、次の型で書くとあいまいさが減ります。
［主語］は［条件］のとき、［目的語］を［動詞］する。
例：システムは修理受付が登録されたとき、担当エリアの技術者に通知メールを送信する。
書いたら、主語（誰が・どのシステムが）、動詞（何をするか）、目的語（何に対して）、条件（いつ・どんな場合に）がそろっているかを確認します。
正常系だけで終わらせない
最も多い失敗は、うまくいくケースだけを書くことです。各機能について、少なくとも次の3種類の異常系を考えます。
- 入力エラー：必須項目の未入力、形式違反、ありえない値
- システムエラー：外部サービスの応答なし、タイムアウト、障害
- 業務上の異常：権限がない人の操作、同時に2人が更新、承認者が期限内に応答しない
ユースケースとして書く場合は、正常な流れ（メインフロー）とは別に、異常時の流れ（代替フロー）を表にしておきます。
| ケース | 発生条件 | 対応 |
|---|---|---|
| A1 | 技術者が2時間以内に受付を確認しない | エリア責任者に自動で再通知する |
| A2 | 通知メールの送信に失敗した | 受付担当の画面に警告を出し、電話連絡を促す |
| A3 | 同じ顧客から重複して受付が登録された | 登録時に重複候補を表示し、統合するか選ばせる |
非機能要件は数値で書く
非機能要件は、性能・可用性・セキュリティ・保守性・拡張性・移行性の6カテゴリーで漏れを確認します。ポイントはすべて数値か具体的な手段で書くことです。
| あいまいな表現 | 具体的な表現 |
|---|---|
| 処理が早い | 一覧画面は操作から3秒以内に表示する |
| 安定して動く | 営業時間（8時〜20時）の稼働率99.5%以上 |
| すぐに復旧できる | 障害発生から4時間以内に復旧する |
| 柔軟に対応できる | 管理者が画面操作だけで受付項目を追加できる |
| セキュリティが高い | 役割ごとにアクセスを制御し、操作ログを1年間保存する |
特に性能は平均ではなくピークで考えます。月初や繁忙期に操作が集中する業務は、その時間帯の同時利用数を書いておかないと、本番で「遅くて使えない」が起きます。数値は業務の実態から決めるものなので、上の値はあくまで書き方の例として読んでください。
抜け漏れを潰す3つの俯瞰ツール
機能を1つずつ書いていくと、機能と機能の「間」が漏れます。そこで業務全体を別の角度から見直すツールを3つ使います。
CRUD図：誰がどのデータを作り・見て・直し・消せるか
データ（エンティティ）を行、ロールを列にして、作成（C）・参照（R）・更新（U）・削除（D）の権限を書き込みます。
| データ | 受付担当 | 技術者 | エリア責任者 | システム |
|---|---|---|---|---|
| 顧客マスタ | CRU | R | R | R |
| 修理受付 | CRU | RU | RU | U |
| 作業報告 | R | CRU | RU |
空欄は「権限なし」と明示します。削除権限を持つのは誰か、マスタを追加・修正できるのは誰か、という問いがここで自然に出てきます。
ステータス遷移：状態と遷移条件を全部洗う
| 現在の状態 | 操作 | 次の状態 | 操作者 | 期限 |
|---|---|---|---|---|
| 受付済 | 担当割当 | 対応待ち | エリア責任者 | 2時間以内 |
| 対応待ち | 訪問完了 | 報告待ち | 技術者 | 当日中 |
| 報告待ち | 報告承認／差戻し | 完了／報告待ち | エリア責任者 | 翌営業日 |
| 任意 | キャンセル | 取消 | 受付担当 | ― |
タイムアウトしたときの遷移、差戻しや取消の経路が抜けていないかを確認します。
操作可能期間：いつまで操作できるか
月次締めのある業務では、「いつまで修正できるか」「締めたあとに直したいときはどうするか」が必ず問題になります。機能ごとに、開始条件・終了条件・締め後の例外手続きの3点を書いておきます。
現場で頻発する3つの書き忘れ
稼働後に問題になりやすい項目として、次の3つは最終レビューで必ず確認します。
- マスタのメンテナンス機能：取引先や商品を追加・変更するのは誰で、どの画面で行うか
- データ移行：過去のデータを移すか移さないか、いつ・誰が・どうやって移し、どれだけ検証期間を取るか
- 印刷・帳票出力：監査や取引先への提出で紙やPDFが必要な業務が残っていないか
現場で使われ続けるための合意事項
要件を正しく書いても、現場に使われなければ意味がありません。要件定義の段階で次のことも決めておきます。
本当にシステム化が必要かを一度問い直す
新規開発の前に、既存のExcelの改修、共有スプレッドシート、既製のクラウドツールで足りないかを比較します。Excelは慣れた人がキーボードだけで高速に入力できるため、画面遷移の多いシステムに置き換えるとかえって遅くなることがあります。現場の操作を観察してから入力画面を設計してください。
一気に作らず、効く部分から作る
業務件数の大部分を占めるパターンだけで最初のフェーズが成立するかを確かめ、残りの例外は手作業で続けるか、次のフェーズに回すか、作らないかを決めます。投資額と効果から回収期間を出しておくと、優先順位の議論がしやすくなります。
現場との合意は書面に残す
- 打ち合わせの頻度（例：週1回30分を4ヶ月）
- テストの範囲と期間（例：本番業務の一部で2週間並行運用）
- フィードバックの反映ルール（軽微なものは翌週、大きなものは次フェーズ）
業務の詳しさ、部署内での発言力、変化への前向きさを持つ現場のキーパーソンを1〜2人見つけ、早めにレビューとテストに参加してもらうと、導入後の定着が大きく変わります。
AIを組み込むときに追加で書くこと
AI機能を含む場合は、精度の許容範囲、誤判定時に人の判断へ戻す流れ、判断理由を担当者に示せるか、応答時間（操作中の処理なら数秒以内が目安）を要件として書きます。倉庫や地下など通信が不安定な現場がある場合は、通信が切れたときの挙動も決めておきます。
よくある失敗
- 非機能要件を書かない：機能だけ決めて、納品後に「遅い」「落ちる」が発覚する
- 異常系を書かない：「担当者が不在のときはどうするか」が本番で初めて問題になる
- 数値にしない：「早い」「安定」のままで、検収の基準がなくなる
- 画面から書き始める：業務の流れに合わない画面ができ、現場が裏で別の管理表を作り始める
- 導入後のフォローを決めていない：半年後には誰も使っておらず、元のExcelに戻っている
この記事のまとめ
- 要件定義は、暗黙の前提を言葉と数字にする作業
- 機能要件はTOBE業務フローから出発し、「主語・条件・目的語・動詞」で書く
- 各機能に入力エラー・システムエラー・業務上の異常の3種類の異常系を書く
- 非機能要件は6カテゴリーで確認し、ピーク時を含めて数値化する
- CRUD図・ステータス遷移・操作可能期間で、機能と機能の間の抜け漏れを潰す
- システム化の要否、フェーズ分け、現場との合意事項まで要件定義の段階で決める
要件定義は、ロードマップのStep 5「決める」にあたるスキルで、同じステップで見積もりにもつながります。状態とデータ構造の設計はステータス管理とテーブル分割の記事で掘り下げています。抜け漏れ事例集や演習付きで学ぶなら、FDEガイドの現場導入のための要件定義を参照してください。スライド・演習問題・テストはlecture.iplot.jpで取り組めます。