§ 雑誌掲載のお知らせ §
タイトル・・「要求の仕様化入門」
雑誌名・・・「Software People」Vol ４
出版社・・・・技術評論社
発売・・・・・２００４年４月
品切れについて
多くの書店で、品切れの状態になっているようですが、大型書店や Amazon では在庫が確保されているようです。出版社としては、現段階では増刷の予定はないということですので、こうした大型店を当たってみてください。 （2004/4/26）
▲内容▼
ソフトウェア開発の現場で起きている問題の原因を辿れば、その過半は要求仕様のところに行き着きます。いわゆる「要件開発」が適切に行われていないために、仕様漏れや仕様の衝突（仕様間の矛盾）が、早い段階で解消されないまま、設計作業や実装作業に突入しているのです。中には、そこで仕様の不整合に気付き、急いで調整されるのですが、今度は、要件管理プロセスが施行されていないために、関係する設計モジュール間での調整がコントロールされず、混乱に拍車をかけてしまうのです。そして、設計作業や実装作業の中で発見されなかったものは、バグとなってテスト作業の中で発見されるか、さもなければ、バグを内在したまま顧客に引き渡されるか、市場に出回るのです。
多くの設計者は、顧客が仕様変更を頻発させているといいます。でも、一方で、顧客は要求仕様を書けないとも言います。それでいて、自らも要求を仕様化し、表現するスキルをもっていません。いや、身に付けようともしていないのかもしれません。それは、依頼者である顧客の方でまとめるべきだといいます。でも、これでは何も解決しません。
確かに、ソフト会社のＳＥ（設計者）としては、依頼者である顧客が要求仕様を書くべきだというのは正論です。でも、設計者自身が、まともな要求仕様を書くスキルを持たないかぎり、要求仕様書の状態で仕様漏れや仕様の衝突を発見することはできないでしょう。結局、いつものように、設計作業や実装作業の中で発見し、いつものように混乱し、いつものように疲弊するのです。
この雑誌に公開する内容は、要求仕様の表現に的を絞ったものです。近年、要求仕様に関する文献（ほとんどが翻訳）が多く出版されるようになり、要求仕様、あるいは要件定義というものがどういうものかを知る機会は増えています。しかしながら、これらの文献の中で扱っていないことが一つあります。それは、仕様をどのように表現するかという問題です。何故か、表現方法についてはどこにも扱っていないのです。
しかしながら、仕様の漏れを防いだり衝突に気付くには、要求や仕様をどのように表現するかによって、大きくちがってきます。今回は、私が現役の時に手に入れた方法を元にし、コンサルティングの中で改良を加え、実際の効果を確認してきた方法を、皆さんに公開します。
▲公開に踏み切ったきっかけ▼
このような方法を公開するに至ったのは、
１）多くのソフトウェア・エンジニアが疲弊し、ソフトウェア開発の障害となっている。
２）インドのソフト会社が、要求仕様を「代筆」し始めているのに対して、現場のソフトウェア・エンジニアは何の危機感も抱いていない。
ことを目の前で見たことがきっかけです。このままでは、日本のソフトウェア産業が本当にダメになる。いや、ソフトウェア産業だけでなく、そこに開発を依頼する側も、仕様が書けないままでは作業としての自立性が損ね、結局は多くの産業が空洞化すると感じたからです。これからは、優れたソフトウェアなしには、どのような産業も成り立たないのです。
私のコンサルティングの中でも、「要求の仕様化」のテーマは最大の取り組みとして勧めています。要件管理に取り組む前に、むしろこちらを先に取り組むことを勧めています。その効果は、取り組みの程度にもよりますが、概ね私の予想通りのものとなっています。もちろん、取り組んだ人たちには、驚きのレベルです。
このテーマは、先に出版した「ＳＥの仕事を楽しくしよう」でも、少し触れましたが、本としての主旨と紙数の関係で、深く突っ込むことができませんでした。幸運にも、技術評論社の方から、「Sofware People」の誌上を提供していただけることになりましたので、今まで書きためてきたものをベースに、雑誌の特集記事に相応しいように、仕様の表現に限定した方法論としてまとめることにしたものです。
今回、私にこのような機会を与えて頂いた技術評論社の関係者の皆さんには、深く感謝しております。
（2004年3月2日）