「ソフトウェア要求 第3版」といえばソフトウェア開発における要求エンジニアリングの鉄板本である。版を重ねて最新版は第3版だが、ちょっと調べ物をしていたところ、第2版には続編が存在することを知った。サブタイトルが興味深いのと、O'Reillyのサブスクで読めるようなので、読んでみたという話。
- More About Software Requirements: Thorny Issues and Practical Advice (Developer Best Practices) (English Edition)
- 副題は「茨の道と実践的なアドバイス」ということかな。茨の道・・・
この記事の目次
- 全体的な感想
- 抜き書きメモ
- 次に読む候補：Software Development Pearls
全体的な感想
本書は要求開発のバイブルである「ソフトウェア要求 第2版」の補足的な内容となっている。同書の刊行後に著者が頻繁に受けた問合せの答えをまとめた、と序文には書かれている。つまりは要求開発の分野における「FAQ本」とも言えるような内容になっている。「ソフトウェア要求 第2版/第3版」は工学のテキストのような章立て・内容となっているが、本書はそれよりはもう少し砕けた表現で面白く読めた。
シリーズを時系列に並べると以下となる
- 「ソフトウェア要求 第2版」原著 2003年 発刊
- 「続 ソフトウェア要求」 原著 2009年 発刊 ⇒ ★今回取り上げている本
- 「ソフトウェア要求 第3版」原著 2013年 発刊
というわけで、今回取り上げる本は13年前の書籍である。が、それでも学びは多いと思った。13年前と現在の違いといえば、アジャイル開発プロセスの拡大がある。当然のことながら本書ではアジャイル開発プロセスのフォローアップは手厚くないが、エクストリームプログラミングを意識した言及はある（6章前後など）。
なお、最新の（それでも原著2013年の本だけど）「ソフトウェア要求 第3版」はアジャイル開発プロセスを意識した内容となっているので、未読であればまずこちらをオススメする。
なお、本ブログには以下の「ソフトウェア要求 第3版」関連の記事もあるので興味があればどうぞ
抜き書きメモ
I. On Essential Requirements Concepts
このパートは、「ソフトウェア要求 第2版」の要約である
1. Requirements Engineering Overview
「ソフトウェア要求 第2版」の抜粋のようだ。第2版または第3版を読んでいるならスキップできるだろう
2. Cosmic Truths About Software Requirements
ソフトウェア要件に関する宇宙の真実 :-p
- 要件を正しく理解できなければ、プロジェクトの残りの部分をどれだけうまく実行しても意味がない
- 要求開発は、単なる収集プロセスではなく、発見と発明のプロセスである
- 変化は起こる
- 要求では、すべてのプロジェクト関係者の利害が交錯する
- 顧客はソフトウェア品質の最も重要な貢献者である
- 顧客が常に正しいとは限らないが、顧客には常に言い分がある
- アナリストが提案された新規要求について尋ねるべきは「この要件はスコープに含まれるか」である
- 最高の要求文書であっても、人間の対話に取って代わることはできない。また、そうすべきではない
- 要件はあいまいかもしれないが、製品は具体的である
- 完璧な要件は手に入らない
II. On the Management View of Requirements
このパートは、管理者視点での要求管理に関して述べられている
3. The Business Value of Better Requirements
要求のビジネス価値に関して
- 要求開発／要件定義に関する投資（トレーニング、プロセス改善、支援ツールの投入）の費用対効果は明確には示すことはできない
- 一方で要求開発／要件定義の品質のプロジェクトへの影響は多大である
4. How Long Do Requirements Take?
要求開発／要件定義にどの程度の期間をかけるべきか
5. Estimating Based on Requirements
要件と見積もりについて
- 「ソフトウェア見積り 人月の暗黙知を解き明かす」を読め（と本当に書いてある）
- 「完全な要件のセットを作成することは決してないのと同じように、要件実装の完全な見積もりを作成することもできません」
III. On Customer Interactions
パート3は顧客とのやりとりについて取り扱う。なお本書執筆時点で著者はアジャイル開発手法による「オンサイト顧客」というコンセプトには賛同できないとしている。1人の個人が顧客の代表として機能するとは思えないからだ
6. The Myth of the On-Site Customer
本章ではアジャイル開発手法における「オンサイト顧客」コンセプトに関する課題を改めて整理し、代替策を提示している。それはProduct Chamipnである。
7. An Inquiry, Not an Inquisition
要件の引き出しは取り調べではないという話
8. Two Eyes Aren’t Enough
要求ドキュメントのレビューについて
- 著者の見解では、現在最も強力な品質対策は要件ドキュメントのレビューである
- 具体的には、ピアレビューとインスペクションをやれ
- 良いレビューをするためには、レビュアーを教育する必要がある
- 適切なレビュアーを選ぶ必要がある。顧客、開発者、利害関係者にレビューをさせろ
- 誤植や文法上の誤りがあると、レビュー担当者が表面的なエラーにつまづいて本質的なレビューができなくなる恐れがあるので、熟練した編集者に校正してもらってからレビューをすることが望ましい
まじでいいことしか言っていない章だ
IV. On Use Cases
ユースケースについて。筆者は要件調査のためのユースケース手法の利用を強く支持している
9. Use Cases and Scenarios and Stories, Oh My!
ユースケース、シナリオ、ユーザーストーリーの取扱いの整理に関して
10. Actors and Users
アクター／ユーザー（人間には限定されない）に関する話
どのような形であっても、要件の調査を開始するにはユーザークラスを特定して、ユーザ要件を見つけるために誰と話す必要があるかを確認することから始める
V. On Writing Requirements
要件の文書化について
これを行うための定型的な方法はなく、経験に代わるものもありません。
12. Bridging Documents
ソフトウェア要求文書は、ユーザと開発者やテスターをつなぐ一種の「ブリッジドキュメント」と言える、という話
- 本書では、ソフトウェア要求をユーザ中心で検討することについて話している。同様に「ソフトウェア要求文書」も利用者を中心に検討するべきである。この利用者には開発者やテスターも含まれる
- アナリスト、開発者、その他の利害関係者が頭を合わせて、どのような要件仕様を作成するか検討すべきである
13. How Much Detail Do You Need?
どこまで要求を詳細化すべきかという話
- 要件の詳細化レベルに影響を与える要因
- より詳細化すべき
- 開発を外部委託する
- プロジェクトメンバーが地理的に分散している
- 要件に基づいてテストが行われる
- 詳細な見積が必要
- 規制要件などにより要件のトレーサビリティを確保しておく必要がある
- 詳細化が不要
- 顧客担当者の関与度が高い
- 開発者が高いドメイン知識を持っている
- 先例がある
- パッケージソリューションを採用する
- より詳細化すべき
14. To Duplicate or Not to Duplicate
要求文書の複数個所に、特定の要件を（繰り返し）記載すべきかという話。単一のトピック（ユースケースや機能）に関する情報がひとまとめになっていることは閲覧者にとっては有用だが、これを実現するためには情報の複製が必要である。いっぽうで複製は不整合等の問題を発生させるという話
15. Elements of Requirements Style
要求をどのように明確に明文化し記述するかという話（主に言語ルール的な意味で）。筆者は記述ルールはあまり好まないそうだ
16. The Fuzzy Line Between Requirements and Design
「要件」と「設計」の境界についての考察
- 境界は存在しない
- 要件段階でソリューションのアイデアをたくさん盛り込んでしまうと、それは設計上の制約に変化してしまう
- 明確な指針は無いが、要件は「ソリューションの手がかり」程度に留めることが望ましい
VI. On the Requirements Process
要求プロセスについて
17. Defining Project Scope
プロジェクトスコープの定義と、スコープクリークの管理に関する話。スコープが明確でなければ変更が発生しやすいという話
- 大枠ではプロダクトのビジョンと、プロジェクトのスコープを定める（書籍「ソフトウェア要求」第5章が詳しい）
- スコープには「何が含まれないか」も記述するべきである
- 補完する表現手法としては、コンテキスト図、ユースケース図、階層化したフィーチャーとして表現できる
忍び寄るスコープの幽霊に犠牲になったり、変化を抑制しようとして無駄にしないでください。代わりに、プロジェクトの早い段階で明確なスコープ定義を確立し、実用的な変更管理プロセスを使用して、避けられない、そして多くの場合有益な要件の進化に対処します。
18. The Line in the Sand
要件ベースライン管理の話。「砂の上に線を引く」って何のことかと思ったら、「超えてはならない一線を設ける」という慣用句表現らしい
ソフトウェア開発者は、初期の要件開発作業の後に要件を凍結してから、それらの厄介な変更に煩わされることなく設計と構築を進めたいと思うことがよくあります。これは、古典的なウォーターフォールパラダイムです。ほとんどの状況ではうまく機能しません。要件ベースラインを定義してから、そのベースラインへの変更を管理する方がはるかに現実的です。
19. The Six Blind Men and the Requirements
盲人が象を撫でるたとえ話。単一の表現だけで要求を完全に理解することはできないという話。本章の内容は、書籍「ソフトウェア要求 第3版」で言えば「第12章 1枚の絵は1024の語に値する」に記載されているものに近い
VII. On Managing Requirements
要求管理について
20. Handling Requirements for Multiple Releases
段階リリースを行うシステムの要件定義文書をどのように取り扱うか。選択肢は以下だが、一長一短がある
- すべての要件を単一の要求文書に保存する
- リリース別に個別の要求文書を作成する
- 要件管理ツールで管理する
21. Business Requirements and Business Rules
ビジネス要求とビジネスルールの違いに関して
22. Measuring Requirements
要求管理におけるメトリクスについて。以下のようなものを記録すると良い。詳細抜き書きしていないけど、細かいアイデアが列挙されている
- 要求仕様の数量（機能数とか数えられるものを）
- 要求の品質
- 要求ステータスの経時的な追跡
- 変更リクエスト
- 労力
23. Exploiting Requirements Management Tools
要件管理ツールの活用について。うーん、最近はあまりこの手のツールの話は聞かなくなったなぁ
要件管理ツールを使用すると、要件の管理が簡単になりますが、簡単ではありません。このようなツールに投資する前に、チームがそのニーズに最適な製品を選択できるように、ツールの独自の要件を定義してください。
次に読む候補：Software Development Pearls
久しぶりに、要求開発／要件定義／上流工程に関していろいろ調べる中で本書を発見して読んだのだけれども、なかなか面白い本であった。
そういえば「ソフトウェア要求 第3版」も9年前の本であるので、続編は出るのだろうかと調べてみたところ、著者のKarl Wiegersさんの新刊はちょっと違ったタイトルで出ているようだ。
ソフトウェアに関する50年以上の経験と、ソフトウェアチームが150近くの組織で成功するのを25年以上支援してきた経験から、アプリケーションドメイン、テクノロジ、または開発ライフサイクルに関係なく、プロジェクトに適用できる60のレッスンを紹介します。非常に実用的で、100以上の実話の経験で説明されているこれらの原則、視点、および実践は、数十年にわたって有効であることが証明されており、今後何年にもわたって関連性があります。
次はこいつを読んでみようかな
