ご好評をいただいております『要求を仕様化する技術・表現する技術』の著者，清水吉男氏にお話を伺いました。

自己紹介を兼ねて，簡単に現在のお仕事とご職歴を教えていただけますか？

1968年からソフトウェアの世界に入る。当初はベンダーからの依頼を受けて汎用機やオフコンのソフトウェア開発，主に新規開発をしてきました。ソフトの内容は，一般のビジネスシステムからオンラインシステムまで多岐にわたります。

その後，Intel8080の出現を機に，組み込みシステムに転向し，PCの周辺機器のソフト，POSシステム，インクジェットプリンタ，電話のデジタル伝送装置などの開発に携わってきました。組み込みシステムの世界では6～7割が派生開発です。当時は，メインの顧客には週35時間で対応できていましたし，現役の20年以上，納期の遅延は1件もない，というのが私の今の活動の原点になっています。

1991年にCMMとの出会いを機に，自ら手に入れてきた技術がプロセスの改善に活かせることに気づいたことで，現在は，プロセス改善のコンサルティングの活動をしています。また，私の会社「システムクリエイツ」は一代で終了しますので，活動の集大成として，これまで手に入れたいろいろな技術を多くの皆さんに使ってもらえるように，文字にして残すことも並行して進めています。

要求の仕様化はなぜ重要なのでしょうか？

「要求仕様書」というのは，ソフトウェア開発の起点であると同時にゴールでもあるという，おもしろい文書です。つまり，これがないと作業が始まりませんし，最後にこの通りに実現していることを確認するときにも使います。

ところが，一般には「細かな仕様は，設計しながら抽出していくもの」という考え方が浸透しています。それは，そこで書かれている要求仕様書の文書の構成や書き方のルールが，「⁠仕様書」を作成する段階で必要なレベルの仕様化ができないことの“⁠言い訳⁠”でもあったのです。

そのため，設計や実装の途中でいろいろと仕様レベルでの矛盾に遭遇したり，必要な仕様が見えてくることで仕様の追加や変更が相次ぎます。実際，ベースライン設定後の仕様変更率が100％を超えることは珍しくありません。でも，そんな状態では，ソフトウェアの開発作業は後戻りばかりで前進しません。

そのような混乱した組織の中にいるSEでも，最初の段階で適切なレベルで仕様化ができることで，仕様の混乱もなく，ほとんどのケースで納期も許容範囲内に収まってくるのです。

製品品質を左右する最大要素は，「⁠プロセス」と「要求仕様」の出来映えです。USDMの表記法によって，そのことが証明できています。

要求仕様を書くのが苦手なエンジニアは多いと聞きます。要求を表現するのはなぜ難しいのでしょう？

最大の問題は「機能仕様」と「要求仕様」の違いを認識できていないことにあるかと思われます。厳密には表現が変わりますし，機能仕様書では「作るための品質要求」が表現されません。そのため，ほとんどの要求仕様書にも，「⁠保守性」などの品質要求が扱われていません。それは，文書の違いを認識できていないことの結果です。

もう一つの問題は，「⁠要求」の存在を理解していないことにあります。「⁠仕様」は漏れないようにと注意していても，「⁠要求」を表現していない状態では，適切な仕様を引き出すことは無理です。

単に，機能別に区分けして仕様を書くというだけでは，どこにどのような内容のことを書けばよいのかわからず，内容が重複したり，それぞれで書かれている内容が異なることも起きてしまいます。

USDMの表記法では，「⁠要求」と「仕様」を階層関係で捉えることで，仕様化作業もはかどります。早い段階で全体の構成を押さえてから，個々の機能要求の展開に入りますので，ボリュームに圧倒されることはありません。

また，“⁠苦手⁠”というのは，おそらく「文章」を書こうとしているからだと思われます。要求仕様書や機能仕様書では，必要な要求や仕様を箇条書きのイメージで簡潔に表現すればよいのですが，一般の要求仕様書では，仕様や説明は入り交じって「文章」を構成しようとしていて，それが抵抗になっているのではないかと思われます。

実際のコンサルティングの中では，要求と仕様の階層の中で，すぐに上手に書けるようになります。

この本の内容は現場のエンジニアにどのように受け入れられているのでしょう？　ご教授されているなかでなにかエピソードがありましたらご紹介ください。

最大のポイントは，設計者が仕様化に参加できるようになったことです。従来なら，設計作業の中で行っていた行為が，早い段階で仕様化に参加することで，後になって仕様の矛盾に気づくという問題がなくなっています。その結果，設計以降の行程（プロセス）が，比率的に確実に短くなっています。

また，要求の発信者である外部の顧客からのヒアリングの段階で，このUSDMのフォームでまとめているところがあります。当然，まとまった内容は顧客にも確認してもらいますので，クライアントもこのフォームを目にすることになります。

今までであれば，「⁠動くものがないとコメントできない」といっていたクライアントも，このフォームで受け入れてくれています。その結果，終盤で発生した機能追加でも，クライアント側から「この3件は別に料金を払います」といってきたケースもあります。 　また，本書の要求仕様書の考え方は，最初は「要求書」であったものが，そこに要求を階層化し，さらに仕様を追加して最終的に「要求仕様書」に“⁠成長⁠”させますので，最初の要求の表現がそのまま残っています。そして，その下に仕様が展開されますので，企画の人たちも，あとで仕様がどのようになっているのかを見るときに見やすくなっているという声も上がっています。

新規開発に取りかかるときに，5万項目ほどの仕様を抽出したケースが数例ありますが，最初に構成を確立し，要求の階層化をしたところで複数に手分けして仕様化しますので，気がついたら5万項目に達していた，という認識でした。書いている最中は，適切に範囲が制限された一つの要求の仕様化に集中できているからでしょう。

現在，次作を執筆中とのこと。どのようなテーマと内容になるのでしょう？

現在，「⁠XDDP」という派生開発専用のプロセスについて執筆中です。昨年の4月に「Software People vol.8」に，その一部を掲載しましたが，現在執筆中のものは，その「全部」になります。いわば「派生開発ハンドブック」のようなつもりで書いています。

「派生開発」がうまくいかない理由は，そこで求められていることと，実際に実施しているプロセスがマッチしていないからです。前述したように，「⁠品質」の最大要素は「プロセス」にあるのですから，プロセスがミスマッチ状態では，バグなどの欠陥はもちろんですが，作業もスムースに運ばないのは当然なのです。

「XDDP」は，これまで，私自身の例（約50例）とコンサルティングの例と合わせて110例を超える実績があり，そのほぼ100％の成功率を誇る派生開発専用の開発手法なのです。なお，変更要求仕様書を作成するところでは，先に出版した『要求を仕様化する技術・表現する技術』と連携する形になります。

また，この他に，「⁠プロセスを自在に設計する技術」や「プロセスとサイズ見積もりに基づいたスケジューリング」なども予定しています。