エンジニアがはまりやすい要件定義の失敗パターン | 情報・通信 | nikkei BPnet 〈日経BPネット〉（情報元のブックマーク数）
要件定義で分析のための分析、目的がなくなった分析は意味がない。確かになぁ。
「利用部門はその分類を見せられても気付きがないでしょうね」とダメ出しをされた。要は、何を意図した分類なのか分からない、というわけだ。
http://www.nikkeibp.co.jp/it/article/OPINION/20090622/332361/
言われてその通りだと思った。記者は分類を考えているとき、「利用部門との間で重要な課題について合意形成する」という目的をすっかり忘れていた。ひたすら、論理的に矛盾なくすべての問題をカバーできる分類を探した。「分析のための分析」をしていたのだ。
講師が示した模範解答では、論理性をあえて崩し、明らかに重要な問題が目立つ分類になっていた。利用部門がこの分類を見れば、「やはりそこが問題だな」と思うだろう。
大半の場合は根本的課題をわかっているけど、直接言わない。そこをきっちり言うのが要件定義か
大半のケースでは、利用部門は自分たちが抱えている根本的な課題をある程度認識している。分析の結果、「やはりそこが問題だな」という共通認識を持つことができればいいのだ。
http://www.nikkeibp.co.jp/it/article/OPINION/20090622/332361/
そのため、枝葉となる問題や原因はあえてカットし、根本的な課題が浮かび上がるように分析を進めるのがポイントだという。教科書にない実践的ノウハウとはこのことか、と感じ入ったのを覚えている。
