要求定義の基本
サマリー
要求定義はWhyとGoalを設定するために行う
要求定義はWhatを決める要件定義やHowを決める仕様定義と区別して扱う
要求定義がイケてない時ほど無駄な手戻りが発生するので言語化をサボらない
要求定義はWhyとGoalを設定するために行う
--.icon
Why（なぜやるか？）の設定により、本当に「いま」「その問題を」「その課題を解いて」解決すべきか判断できる
何を解決したいのか、その背景に何があるのか？がわかることで、やるべき理由を精査できる
要求定義を進める中で、本当に今やるべきであるかどうかを検証、納得できる（ないと今やるべきか判断できない）
問題の構造と課題の設定ができていなければWhyは判断できない。要求定義の大前提として問題解決の基本を抑える Goal（何をもって達成とするか？）の設定により、「何を優先して」「どの状態に」すれば良いのか判断できる
どの段階に持っていければMust/Better/Bestなのか、スコープと完了条件を精査できる
要求定義を明確化する中で、下流にある手段や実行を切り離して依頼できるようになる
現実的な制約としてのQCDSが設定できていなければGoalは判断できない 要求定義は要件定義や仕様定義と区別して扱う
--.icon
よくあるのが「要件や仕様を要求に入れちゃう」パターン。WhyとGoalを抜き出して要求を設定する必要がある
要件（What）や仕様（How）は解決策の話であり、前提としてのWhyより先行してしまうと依頼者の満足感しか満たせない
問題は解決できず、被依頼者の問い直しコストやミスリードにも繋がるリスクがあるため、区別するのが望ましい
要望を要求と履き違えるケースも多い。「こうあったら嬉しい」は全て要望でしかなく、分析が足りていない
前提や背景に何があり、問題に割り戻すと何がGapで、本当に解決すべき課題がどこにあたるのか、を見極める
要求が明確でないと、コストとリスクが上がる
Whyを検証できていない場合、やる必要がなかったことに後から気づく（or気づかず終わった風になる）ことがある
方針やスコープを決めていない場合、無駄な方向にリソースを割いていることに後から気づくことがある
依頼者が省略した言語化をアウトソースする形になるため、シンプルにコミュニケーション負荷がかかる
要求のGoalに書かれていることが全てで、全てがチェックできれば要求が達成されるようにする
後から「こんな条件もありました」「この制約を忘れてました」はQCDS全てを狂わせる
要求と思いつき・アイデアは全く違う
要求を満たす上で必要な項目が羅列されており、そこさえ埋めればなんでも良いよ、ができた時点で要求定義のGoalは完了
つまり、結果を確かめる品質保証がなされないと、要求定義は完了できない Goalが網羅されないと要件定義へ進んではいけない訳ではないが、追って要求定義を更新しつづける必要がある
memo.icon
参考資料（特に関係する重要な内容を解説している記事・書籍に絞った）suemura.icon
要求定義・要件定義は開発案件に限った話ではないものの、知見は開発まわりで開拓されてきた歴史があるsuemura.icon
要件（What）や仕様（How）は解決策の話であり、前提としてのWhyより先行してしまうと誰も得しない結果になる
相手の習熟度に合わせて要件や仕様のヒントにしたり与件にしちゃったりする手法もあるsuemura.icon
が、少なくとも要求とは切り離すべき
以下、ログ.icon
チームで仕事をする限り、要求定義が必要
要求定義とは『目的が達成された状態』を定義すること
要求定義はアウトカムベースでチェック（品質保証）される必要がある 要求定義は要件定義・仕様定義に分解され、階層的に品質保証される