本 -008- ：要求を仕様化する・技術表現する技術（清水吉男）

［この記事は Doblog に 2005-10-18 18:47:58 付で載せていたものです］

タイトルは長く
　［入門＋実践］　要求を仕様化する技術・表現する技術
　～仕様がかけていますか？　です．
　（技術評論社，2005年11月1日 初版）

「機能」ではなく「要求」を仕様書にまとめる・作り上げるために
システム／ソフトウェア関連の方は一読して損のない一冊だと思います．
筆者（清水吉男）はＣＭＭ（Capability Maturity Model，ソフトウェアを開発する組織の能力を示す基準）に出会い，
プロセス改善のコンサルティングをするようになったとのこと．
ＣＭＭが機能する（役に立つ）には，その前提としてＰＳＰ（Personal SoftwareProcess） => ＴＳＰ（Team Software Process）の技術を習得していることが必要で，
この前提条件を満たしていないままＣＭＭに取り組んでも失敗する可能性が高くなると警告しています．
「特に『要求仕様書』の出来栄えによっては，ＣＭＭと取り組みを根底から覆してしまう危険があると思っています．（残念ながら，いま，この危惧が現実のものになりつつあるようです）」

思うのですが，日本のソフトウェア開発者（組織）は「方法論」が苦手なのではないでしょうか．
方法論とは何かをするための方法・技法を体系化したものだと理解していますが，
どうもその習得や実践に及び腰になっているというか，
体質に合わない（？）と嫌っているか，そんなふうに思います．
方法論を導入する組織でも，
その方法論が拠って立つ基礎（上述の言葉でいうと前提条件）を考えずに導入し，
努力に比した成果が得られない．
その結果，方法論自体の価値を低く見る，役に立たないと評価する．
そんな組織が多いのではないでしょうか．

さて，同書はソフトウェア開発を次のプロセスで捕らえています．
仕様 => 設計 => 実装（コーディング）
この仕様のフェーズで重要なのが「機能仕様」に先立つ「要求仕様」であり，
そこに注力しないために後工程でのバグ，仕様変更の多発に繋がると言っています．
また，同書では「派生開発」（いわゆる改修）時の注意点や，
機能仕様に付随する「品質仕様」の重要性にも言及しています．
「品質仕様」とは「応答性」（何秒後に応答を返すかなど），
あるいは「操作性」「保守性」「耐故障性」などです．
業務系のソフトウェア開発では「耐故障性」を考える必要は（たぶん）無さそうですが，
その他の品質仕様はとても重要で，しかも忘れがちな点かと思います．

Excel を使った（Word ではない）要求仕様書の書き方，
関係者（特に開発依頼者）を巻き込んだヒアリングやレビューの仕方など実践的な話題も盛り込まれています．
開発から遠ざかっている私でも有益なヒントがたくさん得られました．
現役の方々には有益な内容が満ち満ちていると思います．
という訳で，オススメの一冊に加えます．