【書籍紹介】要求仕様書の書き方なんかより先に学ぶべきこと
久しぶりの書籍紹介です。
エンジニアたちが苦手とする分野「要求」に関する本です。
「要求」について本気で勉強したいと思っているエンジニアには、
私はいつも Karl E. Wiegers のこの 2 冊を勧めています。
《要求仕様書の書き方より大事なこと》
「要求仕様書の書き方」や「要求の整理の仕方」などに注力している本は多いのですが、私はそういった本は勧めていません。
いくら正しく明文化しても、エンジニアたちが「要求とは何なのか？」を理解していなければ、意味はないからです。
「We eat breakfast in evening.（私たちは夜に朝食を食べます。）」
という文は、構文テストには合格する。しかし、意味を成すだろうか？
今日は、この 2 冊の本の中からほんの一部ですが、「要求」について抜粋＆解説したいと思います。
◎ソフトウェア要求の真理
ほとんどのソフトウェアエンジニアは、コンピューターサイエンスの教育しか受けていません。なので「要求」もロジカルに効率よく処理しようとしてしまいます。
①要求開発とは、発見と発明のプロセスである
単なるヒアリング（情報収集）ではダメなのです。
特に「要求は何ですか？」は、してはいけない質問です。
②変化は必ず起こる
大事なのは要求を FIX することではなく、変化が分かるようにベースラインを管理することです。
③顧客は常に正しいとは限らないが、顧客のいうことには常に意味がある
ほとんどのエンジニアは、「構文解析」が正しく行えるだけで「意味解析」ができないコンパイラみたいな状態なのです。
④最高の要求仕様書でさえ、人の対話には代えられない
顧客の背後にある真の要因を探り当てなければいけません。
顧客との対話は、その探索のための最大のヒントになります。
⑤要求を完璧なものにしようとしてはならない
不可能なことをやろうとすると泥沼にはまります。
そして泥沼に付き合わされた顧客は非協力的になります。
◎要求に関わるデータ
ソフトウェア開発に関わる人々の「要求」への無理解が、ソフトウェア開発のデスマーチの多さの一因かもしれません。
①開発工数の 30～50% は手戻りコスト、そのうち 70～85% は要求の誤り
後工程になるほど、手戻りコストは指数関数的に増加します。もし要求の誤りをリリース後に発見したら、手戻りコストは数百倍になるでしょう。
②ソフトウェアの欠陥のうち 40～60% は要求の段階で入り込んでいる
プロジェクトの事後分析を行っていると、開始時点で既に躓いているプロジェクトは驚くほど多いです。
③要求工学の教育を受けた会社は、遅延日数を約 7 割減らせた
要求工学は、一流大学の情報学部ですらほとんど教えられていません。
逆に言えば、少しの勉強で大きな改善が見込めます。
◎要求の種類
「要求」に種類があることさえ、ほとんどのソフトウェアエンジニアは理解をしていません。用語も整えられていないのが実情です。
①ビジネス要求
なぜ、その開発プロジェクトを実施しなければならないのか？この要求がなければ、メンバーの意思統一もできずに、迷走が始まるだけです。
②ユーザー要求
ユーザーが満足しなければ意味がありません。
また、「ユーザーの言う通りに作る」という意味でもありません。
③機能要求
開発者が何を実装しなければならないのか？分かりやすい定義のため、この要求しか管理されていないプロジェクトが、驚くほど多いです。
④非機能要求
あらゆる関係者にとって重要な特性。ほとんどの場合 ”誰からも言われない” ために見過ごされ、最悪な品質の製品が生み出されるのです。
《こんなエンジニア、PM、経営者たちに》
「要求」は、ソフトウェア開発の最初のフェーズです。
「要求」に関するノウハウがない組織は、いつまでも失敗を繰り返してしまいます。
「もうデスマーチ・プロジェクトはごめんだ！」
・・・というエンジニア。
「仕様通りに作ってるのに、なぜ顧客から文句を言われるんだ！」
・・・というプロジェクト・マネージャー。
「どうして優秀なメンバーを集めたのに、いつも失敗するんだ！」
・・・という経営者。
ソフトウェア開発で、このような ”痛い目” に ”何度も” あっている人に手にしてほしい本です。その答えが書かれているかもしれないからです。