はじめに
良い要件定義では、完全性(必要なものが漏れていないか)と必要性(不要なものを作りすぎていないか)が両立しています。
この記事では、要件定義で「必要な要件が漏れていないか」と「不要なものを作りすぎていないか」を確認するための5つの観点をご紹介します。
最初に結論
要件定義で意識したい観点および心構えは以下の5つです。
この5つは、冒頭の「完全性」と「必要性」に次のように対応します。
| 観点 | 効く軸 |
|---|---|
| ①テスト可能性 | 漏れ不要を判定できる状態にする（土台） |
| ②ユーザーフローとデータライフサイクル | 完全性（操作とデータの流れから漏れを見つける） |
| ③非機能要件 | 完全性（機能の裏で漏れやすい要件を拾う） |
| ④スコープ | 必要性（境界を引いて不要なものを明確にする） |
| ⑤アウトカム | 必要性（効果のないものを作らない） |
つまり、①で判定を可能にし、②③で漏れを防ぎ、④⑤で不要を防ぎます。
順に説明します。
①この要件は、テストできるか？
要件定義では「この要件はテストできるか？」と問います。
漏れているか・不要かを「判定できる状態」を作るためです。テストできない記述のままでは、そのどちらの判定もできません。
要求を要件にする
要件定義でまず意識したいのはテスト可能性です。
「要件定義なのにテスト？」と思われた方こそ確認していただくと効果が高いです。
要件定義という営みの中では、「要求」と「要件」が混在しがちです。
「要求」は、関係者が求めているもの。
「要件」は、要求のうち、必要な条件や能力を明確化したもの。
テスト可能な形まで明確化して初めて要件として扱える、が本記事の立場です。
例えば、「発注登録の画面を使いやすくしてほしい」は要求です。
これを「発注担当者は、品目と数量の入力から発注登録の完了までを3クリック以内で行える」とすれば要件になります。
前者はテストできませんが、後者はクリック数を数えればテストできます。
なお、クリック数は使いやすさの一側面を代理させた指標にすぎず、何を代理指標に選ぶか自体も関係者との合意対象です。この代理指標の選定もまた、要件定義の仕事です。
つまり、テスト可能性を意識することで、要求を要件に落とし込めます。「要求」のままだと、設計者が解釈で穴を埋めることになり、受け入れ時にも合否の基準が引けず、後続で困るのです。
テスト可能性を確認することで、テスト可能な形になりきれず、判定不能なまま残っている要求を炙り出せます。
書籍『正しいものを正しくつくる』より
「要件」という言葉は人によってこめている意味が異なる場合があるため留意して扱う必要がある。具体的には、要求なのか、要件なのか、仕様なのかをはっきりさせなければならない。
書籍『要件定義のヒアリングリスト427』より
テスト不可能な要求は、開発してもその要求が本当に満たされているのかどうかの検証ができません。テスト不可能な要求については顧客との間で現実的なテスト範囲についての同意を得ておくことです。
品質の取り組みを早い段階に前倒しする
要件定義からテストを考えることでシフトレフト（テストなど品質のための活動を工程の前半に前倒しすること）の効果が期待できます。
結論から言えば、開発の品質が高まり、スピードが上がりやすくなります。
早い段階での「どうやってテストするのか？」という議論は、後続の設計やコーディング、テスト工程の効率と品質を高めます。
また、テストの議論を行うことで、テスト工数を見積もる過程で「ここまで作る必要があるか」に目が向く、など「不要なものが混ざっていないか」に意識が向きやすくなります。
②ユーザーの操作とデータを、最初から最後まで追えるか？
要件定義では、ユーザーフローとデータライフサイクルのセットを書き出します。
「必要な要件が漏れていないか」を確認しやすくするためです。
ユーザーフロー図
ユーザーフロー図は、ユーザーがこの機能をどのように使うかまとめた図です。
BtoB向けのシステムであれば「業務フロー図」と呼ばれることもあります。
以下は、発注業務を題材にしたユーザーフロー図のサンプルです。
差戻しのような例外系の流れは、図に書き出して初めて漏れに気づけることが多いポイントです。
データライフサイクル
データライフサイクルを全て書き出します。
「いつデータが生まれて、いつどの頻度でデータが更新されて、いつデータが消えるのか」を整理します。これにより、漏れが発生しにくくなります。当然、この整理は後続の開発・テストで大いに役立ちます。
以下は、先ほどのユーザーフロー図と同じ発注業務を題材にしたサンプルです。
| 対象 | いつ生まれる | いつ・どの頻度で更新される | いつ消える |
|---|---|---|---|
| 発注明細（発注日・品目・数量・ステータス） | 発注担当が起票したとき | 承認・差戻し・検収のたびにステータスが変わる | 検収完了から法定保存期間が過ぎたとき |
| 品目マスタ | 管理者が品目を登録したとき | 価格改定のたびに管理者が更新する | 削除しない（取扱終了時に無効化する） |
| 取引先マスタ | サービス開始時に旧システムから初期移行し、以後は管理者が追加する | 住所や担当者の変更時に管理者が更新する | 削除しない（取引終了時に無効化する） |
ここで特に漏れやすいのが、ユーザーフロー図に登場しないデータです。サービス開始時に投入する初期データ（移行データ）や、管理者が保守するマスタは、ユーザーの操作からは生まれないため、フロー図だけを見ていると存在自体を見落とします。データライフサイクルを「全て」書き出す価値はここにあります。
最後に、「データ」という言葉を使わずに全て説明できるかを確認します。
「データ」は曖昧な言葉です。「データ」のままだと、"要件に落とし込めているつもり"になります。その「データ」と呼んでいるものは何なのかを明示しておきます。
例えば、「発注データ」という言葉が残っていたら、それは「発注日」なのか、「発注数量」なのかがわかりません。
書籍『プロダクトマネージャーのしごと』より
データという言葉は、一般的かつ日常的に使われるため、それが実際に何を表現しているかほとんど明確にしませんが、確実さや厳密さの印象を手軽に与えることができます。
セットで確認
ユーザーフロー図とデータライフサイクルをセットで確認します。
セットで考えることで「そもそもこのユーザーの操作の前提がおかしくないか？」「この機能（業務）って実はいらないのでは？」などと気づきやすくなるためです。
②の主目的は漏れの発見（完全性）ですが、このように副次的に「不要なものが混ざっていないか」（必要性）にも効きます。
また、データライフサイクルは業務の言葉で書かれたユーザーフロー図と対応づいているため、システム開発に詳しくない（データの生成・更新・削除に詳しくない）ユーザーも、自分の業務からデータ側を辿ってレビューできます。
ユーザーがデータライフサイクルも確認できることで、後続の設計フェーズの後戻りリスクを減らせます。
③性能、負荷、信頼性、セキュリティなどを、一度でも議論したか？
要件定義において、非機能要件を一度は議論します。
非機能要件の欠陥は後から直すには、作り直しに近いコストがかかるためです。
非機能要件は要件定義で意識されないケースが多く見られます。機能の検討で手一杯のうちは、非機能要件まで手が回らないためです。逆に言えば、非機能要件まで議論できているなら、要件定義全体の検討が進んでいる目安になります。
参考になるのは、書籍『アジャイル品質パターン QA to AQ』の「品質シナリオ」です。
プロセスの早い段階で、手軽な方法を利用して、性能、負荷、信頼性、セキュリティなどの重要な品質要求を扱う大まかな品質シナリオを作成し、記述します。
発注業務に当てはめると、例えば次のように書けます。
「月末最終営業日の午前、全拠点の発注担当150人が締め切り前の起票と承認に集中する。承認者が承認操作を行ったとき、システムは3秒以内に完了を返さなければならない」
網羅性をさらに高めたい場合は、IPAの非機能要求グレードを確認するのがおすすめです。
④スコープ外の機能を、3つ言えるか？
この要件定義のスコープは何かを明確にします。機能一覧などで全体像を可視化して、スコープ内外の境界を引きます。
不要なものを含んでいないかを確認しやすくするためです。
また、関係者内・関係者間での認識を揃えるためにも有効です。スコープ外を明示することで、境界を認識しやすくなります。一歩目としては、「スコープ外の機能を3つ言えるか？」あたりから確認していくと良いです。3つという数自体は目安で、1つも挙げられないなら、境界をまだ考えていないサインです。例えば、「相見積・在庫引当・支払処理はスコープ外」のように整理していきます。
書籍『正しいものを正しくつくる』より
期待の存在を捉え、共通認識にしていく活動を「期待マネジメント」と呼ぶ。期待もマネジメントの対象であるということだ。
スコープ外を言語化しないと、関係者それぞれの暗黙の期待が要件に紛れ込み、気づかないうちに作りすぎが起きます。スコープ外の明示は、その期待を管理対象に引きずり出し、共通認識にする活動です。
⑤この機能の効果を、何でどう測るか言えるか？
要件定義ではアウトカム（作った機能そのものではなく、それによって起きるユーザーや事業の変化）と測り方を決めます。
アウトカムを意識することで、本当に効果のある機能に集中して開発できるようになるためです。
この機能によって、ユーザー（顧客）の価値はどれくらい高まるのか、自分たちの収益はどれくらい増えるのか、というアウトカムを意識します。
さらに「どうやって検証するのか？」という効果検証を要件定義の段階から議論します。
この議論自体によって「そもそもこの機能は必要なのか？」と立ち止まることができます。
加えて、要件定義で漏れがちな効果検証のための仕組みを、最初から要件に含められます。⑤の主目的は「不要なものを作らない」（必要性）ですが、このように副次的に漏れの防止（完全性）にも効きます。
例えば「発注起票から承認完了までのリードタイム（平均2日→0.5日）をステータス変更ログのタイムスタンプで測る。だからログ出力が要件に入る」のような話ができます。
書籍『正しいものを正しくつくる』より
仮説検証では「正しくないものを作らない」戦略を取る。「正しくないもの」の理解から、プロダクトについての基準の輪郭を浮かび上がらせる。
「この機能をつくったら良いのでは？」は仮説と考えることができます。
書籍『仮説行動』では次のような主張があります。
仮説生成と仮説検証はセットで考えるべきもの
つまり、機能を考える時点で検証をセットで考えておく必要があります。
おわりに
本記事では、要件定義で意識すると良い5つの観点を紹介しました。
①テスト可能性
②ユーザーフローとデータライフサイクル
③非機能要件
④スコープ
⑤アウトカム
①で判定を可能にし、②③で漏れを防ぎ、④⑤で作りすぎを防ぎます。
要件定義の際に参考になれば嬉しいです。