要求探検/要件定義十戒 - HifeLacks - serenista@wiki

要求探検

要件定義心得の条。

自分の経験を基にして、要求ヒアリング・要件定義の要諦というか、勘どころというか、べからず集というか、そういうものをまとめる。

(2008.04.07)10個もないわけだが、事例から教訓を集めていけば10個くらいじきにたまるだろうさ。

1. (俺)質問が重要である。それも、質問の中身もさることながら、質問(しようと)することが重要である。
2. (GMW)それは顧客が望んでいるものかどうか、常に問え。
   • 顧客の言っていることが本当に顧客が望んでいることなのかどうか？
3. (GMW)顧客が必要とするものについて顧客よりよく知っていると思っても、顧客より利口だと思ってはならない(ER, p.49)
4. (俺)「何故」を問え。
   • 理由を答えられない要求(要望)は、まず合理性を欠いていることが多い。
     • 発言者の個人的な思い。単なる要望
     • 利害関係者間で整合できていない。対立・競合・葛藤がある
   • 合理的な理由が答えられない要求も上に同じ。
   • 理由が不明瞭な要求は
     • システム化の際には不整合要素になりやすいし、設計・実装に負荷をかけることもある。
     • 実はシステム化構想の中でも“浮いて見える”ことがしばしば。落着き・収まりが悪い。
   • 理由を追及していくうちに、その要求は実は必須のものでなかったと判明する、ということもよくある話で。
   • 何故(と問うこと)がなぜ必要なのか、説明できること。
   • 上手に「何故」を問えて、その答を引き出せた時は大体、要件定義はうまく行く。
5. (俺)質問は単純に「顧客の話が判らない」ところから始まってよい。
   • 顧客のドメインを予め熟知していることなどまずない。同じドメインでも組織が異なれば文化が異なり、慣習・しきたりが異なる。「知っているつもり」「判った振り」こそ危険。(上にGMWの引用がある通り)
   • 従って、謙虚に訊ねるが良策。特にヒアリング初期は。
     • すみません、貴方がたの業務分野に詳しくないので教えてください。
     • 今日のお話の中でこの点が判りませんでした。
   • ただし、勉強はしなければならない。言換えれば質問の内容・レベルは回を重ねるごとに高度にならなければいけない。
     • 勉強もせずに判らないことをすべて質問で済ませようとするのでは信頼は得られない。
6. 要件の記述から曖昧さを取り除くこと。
7. 顧客の要求の総体（要求リスト）を分析(検証)すること。
   • 全体として無矛盾であるかどうか論証すること。無矛盾というと言い過ぎか。全体として整合しているかどうか論証すること。(論証は直観的でもよいが、説明可能でなければならない)
   • 欠落はないか。
8. 問題が何か適切に把握すること。また、問題とは何かを適切に理解すること。

---