§ 出版のお知らせ §
タイトル・・[入門+実践] 要求を仕様化する技術・表現する技術
出版社・・・技術評論社
A5判／368ページ
価格・・・・定価 ２５８0円（＋税）
ISBN4-7741-2523-7
発売・・２００５年１０月７日
都内大型店では９月末に並ぶようです
ようやく、Software People vol.4（2004年の４月刊）で公開した要求の仕様化方法「要求の仕様化入門」が本の形にまとまりました。雑誌で公開したあと、読者の皆さんから大きな反響があり、急遽、内容と範囲を広げて原稿の作成に取り掛かったものですが、途中、私の本業であるSPIのコンサルティングが忙しくなったために、当初の予定より、６月以上も遅れてしまいました。
本書は、雑誌に公開した内容も、そのほとんどを書き直し、紙数の関係で雑誌では公開できなかった要求の表現や仕様化のテクニックもたくさん盛り込みました。事例もできるだけ多く取り入れましたので、実際の作業の中でヒントになると思います。
今日、CMMなどの取り組みが普及し、プロセス改善や品質改善の動きが盛んになっています。その背景には、90年代に入って、日本のソフトウェアの品質が悪化したことがあると思われます。ソフトウェアの品質が悪化した原因として、
１）90年代に入って納期の短縮要求が市場の要請として表面化したことに対して、分担範囲を狭めて人海戦術で対応したり、必要なプロセスを無造作に省略したりして対応した組織が少なくない。さらに、追い討ちをかけるように、90年代後半からはコストの削減要求が出されており、混乱に拍車がかかった
２）もともと、ソフトウェアの開発現場にエンジニアリングの下地がなく、その上、適切な構成や内容を伴った要求仕様書が書けない状態が続いており、顧客要求をまともに捉えないままに、納期の圧力に屈して設計作業に入ったことでて、かえって手戻り作業が増え、生産性と品質を悪化させた
３）CMMの取り組みの中でも、要件管理の前に適切な要求仕様書が書けることが前提になっていることが見逃され、そのまま要件管理に取り掛かったことで、現場にとんでもない負荷がかり、プロセスが混乱した
ことが背景にあると考えています。
さすがに、最近になって「要求仕様書」の内容に問題があるということで、認識が広がっています。CMMIの方で「要件開発」の必要性が提起されたことや、世界的な「Requirement Engineering」の活動が広がっていること、さらに、MDAなどのモデリングからの要求の抽出の取り組みが、広く認知されてきたようです。
私自身は、「要件開発」には以下のように３つの側面を持っていると考えています。
１）要件の抽出
２）要件の表現
３）要件の洗練
つまり、如何にして顧客要件を抽出するか、抽出した要件をどのように表現するか、さらに関係者が確実に“Specify”するために表現を調整したり洗練する、といった行為が含まれるのです。（私は、“要求”と“仕様”を分けて扱いますが、「要件」というときには、これらを区別せずに両方を含んだ状態を指します）
このような視点から巷の“要求仕様”に対する動きを見ていると、要件の抽出にスポットが当てられていて、要件の表現と洗練については深く扱われていないように見えます。その原因として考えられるのは、“要求”と“仕様”が区別されていないことや、「仕様は、設計を進めながら抽出する」ものという考えが依然として残っていることが影響しているものと思われます。
これに対して本書で紹介するのは、「要求」と「仕様」を区別し、要求には仕様の抽出を促す役割を与え、要求を適切に表現することで仕様を確実に拾い出す方法です。適切な表現の中では、あらたな要求も発見しやすいのです。結果として、本書で紹介する仕様化の方法によって、仕様モレや仕様の衝突は、ベースライン設定の段階でほとんど解消します。ベースライン設定後に変更される“仕様”の変更率を見ればわかります。
要件をどのようにして発見し、抽出するかということは重要なことですが、要件（要求＆仕様）は、関係者に確実に伝わってはじめて価値を持つものです。せっかく抽出された要件も、構成や表現の仕方によっては正しく読み手に伝わりません。また、構成が悪い場合は関連する仕様に気づくことも難しくなりますので、仕様漏れや仕様の誤解などが多く発生してしまいます。
要件をどのように表現するかということは、書き手と読み手が「合意」するために非常に大きな要素なのです。抽出された要件について関係者がSpecifyし、合意するためには、表現を「洗練」しなければならないのですが、そのためには適切な構成の中で適切に表現することが不可欠なのです。
本書で紹介する方法は、私がソフトウェアの世界に復帰して間もない時期に、過去の失敗を繰り返さないために必死になって顧客要求の捉え方を研究しているなかでこの原型を手に入れたものですが、これが手に入ったことが、その後の（２０数年間の）すべてのプロジェクトを「On Schedule」できた最大級の要因になったと考えています。もちろん、要求仕様だけでうまく行くわけではありません。でも顧客の要求を外さなくなったことで、その他の方法を研究する余裕も出てきますし、そこで考えた方法を組合わせることで約束通りに仕上げることができたのです。
たとえば、ＰＦＤによるプロセスの設計やサイズの連鎖をベースにした仮説見積り、プロセスとサイズ見積りを元にしたEvolutionary Svheduling 、派生開発プロセス、要求の仕様化技術を応用したリスク管理など独自の方法を編み出してきましたが、最初にこの「要求の仕様化の方法」が手に入ったことで、その後のアイデアはこれに引っ張られるように出てきたものです。
この方法を本としてまとめる前に、１０年間のSPIのコンサルティング活動の中で取り組んでもらい、そこでの効果を確認してきました。仕様化作業にかかる工数や、その後に変更される件数（経効率）などから、必要以上の負荷はかからないことも見届けてきました。そして階層のルールや、分割の着眼点などを明確にしてきたことで、私以外の人でも、確実に使えることを確認しています。つまり、多くの人の協力を得て、ここまでこぎつけたものでもあるのです。
今、日本のソフトウェア開発において、要求仕様のあり方を見直す動きが出てきた中で、本書が皆さんのお役に立つことを願っています。
なお、本書に収めきれなかった方法や、今後の私のコンサルティング活動の中で発見した対応方法については、適時、このホームページの中で補足していきますので、あわせて活用してください。
（2005年9月17日）