要件定義

要件定義とは

要件定義は、システム開発の最初の工程で「何を作るのか」を明らかにし、関係者間で合意する作業です。

出発点は利用者の要望(こうしたい)であり、それを実現可能で検証可能な形に落とし込んだものが要件です。「もっと使いやすくしたい」は要望であって要件ではありません。「一覧の検索結果が3秒以内に表示される」まで具体化して、初めて作れるものになります。

この工程が重要なのは、手戻りのコストが後工程ほど跳ね上がるからです。要件定義段階の勘違いは会話で直せますが、リリース後に発覚すれば設計・実装・テストのすべてをやり直すことになります。

機能要件と非機能要件

要件は大きく2種類に分かれます。

機能要件非機能要件
問い何ができるかどのくらいの品質か
商品を検索できる、注文をキャンセルできる3秒以内に応答する、99.9%稼働する
見落としされにくいされやすい

非機能要件には次のような観点があります。

  • 性能 — 応答時間、同時接続数、処理件数
  • 可用性 — 稼働率、障害時の復旧目標時間
  • セキュリティ — 認証方式、データの暗号化、ログの保存期間
  • 拡張性・運用性 — 想定するデータ量の伸び、監視、バックアップ、リリース手順

トラブルの多くは非機能要件の抜けから起きます。機能はすべて動くのに「遅くて使えない」「障害時に誰も気づけない」という失敗は、要件定義の段階で防げるものです。

よい要件の条件

  • 具体的 — 「速い」ではなく「95%のリクエストが1秒以内」
  • 検証可能 — テストで満たしているか判定できる
  • 優先順位がある — すべてが最優先なら、優先順位が無いのと同じです。MoSCoW法(Must / Should / Could / Won't)のような分類が役立ちます
  • 理由が書かれている — 「なぜそれが必要か」が残っていると、後から代替案を検討できます

曖昧な言葉には特に注意しましょう。「適切に」「柔軟に」「なるべく早く」は、読む人ごとに解釈が変わります。

開発プロセスによる進め方の違い

[[ウォーターフォール開発]] では、要件定義を最初にまとめて行い、成果物として要件定義書を作って合意します。後戻りしない前提のため、この時点での網羅性が求められます。

一方 [[アジャイル開発]] では、要件をユーザーストーリーの形で少しずつ詳細化します。書式は「〈誰〉として、〈何〉がしたい、なぜなら〈理由〉だから」です。たとえば「買い物客として、注文履歴を検索したい、なぜなら再注文を素早くしたいから」となります。

[[スクラム]] ではこれらをプロダクトバックログに並べ、優先順位の高いものから開発します。最初にすべてを決めきらず、作りながら学んだことを反映するのがこの進め方の考え方です。

どちらの場合も、要件が [[見積もりとベロシティ]] の前提になる点は変わりません。要件が曖昧なままの見積もりは、ほぼ必ず外れます。

初学者向けポイント

  • ヒアリングでは「何が欲しいか」より「今どう困っているか」を聞きましょう。要望の裏にある課題が分かれば、よりよい解決策を提案できます
  • 文章だけの合意は解釈がずれます。画面のラフや業務の流れ図を見せると、認識の違いが一気に表面化します
  • 「やらないこと」も明記しましょう。スコープ外を書くのが、後の揉め事を防ぐ最も安い方法です
  • 決まったことは [[ドキュメンテーション]] として残します。口頭合意は数か月後に双方の記憶が食い違います

関連技術とのつながり

  • [[ウォーターフォール開発]] — 要件定義を最初にまとめて確定させる進め方
  • [[アジャイル開発]] — 要件を少しずつ詳細化し、変更を前提とする進め方
  • [[スクラム]] — ユーザーストーリーをバックログとして優先順位付けする
  • [[ドキュメンテーション]] — 合意内容を後から辿れる形で残す
  • [[見積もりとベロシティ]] — 要件の精度が見積もりの精度を左右する
  • [[チケット管理]] — バックログに並べた要件を1件ずつのチケットとして追跡する
Q: 非機能要件にあたるものはどれ?
- [ ] 商品を検索できる
- [x] 95%のリクエストが1秒以内に応答する
- [ ] 注文をキャンセルできる
解説: 「何ができるか」が機能要件、「どのくらいの品質か」が非機能要件です。性能や可用性は非機能要件にあたります。

Q: よい要件の条件として適切なものはどれ?
- [x] 具体的で、満たしているかテストで検証できる
- [ ] 「適切に」「柔軟に」といった余地のある表現を使う
- [ ] すべての項目を最優先に設定する
解説: 曖昧な表現は解釈のずれを生みます。また全部が最優先では優先順位が無いのと同じです。

Q: アジャイル開発で要件を表現する形式はどれ?
- [ ] 3層アーキテクチャ図
- [x] ユーザーストーリー(誰として、何がしたい、なぜなら)
- [ ] ER図
解説: アジャイルでは要件をユーザーストーリーとして表し、バックログに並べて優先順位の高いものから開発します。