「入門＋実践」要求を仕様化する技術・表現する技術改訂第 2 版(ニュウモン プラス ジッセン ヨウキュウ オ シヨウカスル ギジュツ ヒョウゲン)

相次ぐ「仕様の変更」や「バグの発生」に悩まされていませんか?「要求」とはなにか「仕様」とはなにか、その本質をつかむ! 要求仕様書作りの考え方や具体的プロセスを身に付け、表現技術を磨く! 仕様モレをなくし、ソフトウェア開発工程をスムーズに。

仕様書を書いたはずなのに、実装に入ってから仕様変更とバグが相次ぐ。『要求を仕様化する技術・表現する技術 改訂第 2 版』 (清水吉男 著、技術評論社、2010 年 5 月刊) は、その原因を「要求」と「仕様」の区別が付いていないことに求め、要求仕様書を書くための考え方と表現方法を具体的に示す A5 判の実務書です。正式書名は「【改訂第 2 版】［入門＋実践］」を冠し、副題は「仕様が書けていますか?」。版元が対象として挙げるのは、ソフトウェア開発をスムーズに進めたいエンジニア、相次ぐ「仕様の変更」や「バグの発生」に悩まされているエンジニア、要求の仕様化に関心があるすべてのエンジニアの 3 者です。

全 3 部 15 章の構成、要求仕様のトラブルから要件管理まで

構成は 3 部 15 章です。第 1 部「要求仕様にまつわる問題」 (第 1 章〜第 5 章) は、「曖昧な仕様で作業に入っている」「顧客からの仕様変更が頻発して……」「納期の遅れとなって表面化する」といった節題が示すトラブルの実態から始まり、なぜ仕様のトラブルが起きるのか、要求仕様は不要か? という問いを経て、仕様化の効果と要件開発の重要性を論じます。第 2 部「要求仕様を書く」 (第 6 章〜第 12 章) が本書の中核で、"要求" を書く、要求の階層化テクニック、要求を仕様化する、Excel による仕様化の勧め、派生開発における要求仕様書、画面仕様書のあり方、ヒアリング時の注意の 7 章が並びます。第 3 部「要件管理と計測」 (第 13 章〜第 15 章) は、仕様化を支える要件管理、仕様化の出来栄えを測る、仕様化技術の応用の 3 章で、書いた後の仕様変更のコントロールと計測に踏み込みます。

「振る舞い」から「動詞」へ、改訂第 2 版で深まった要求の表現

版元の概要によれば、第 1 版では要求を表現する際に「振る舞い」に注目し、分割・階層化により振る舞いの範囲を狭くして仕様漏れをなくしていく方法を提唱し、第 2 版ではその方法論をさらに深め、上位要求の表現や分割・階層化したときの下位層の要求を表現する際に「動詞」を意識する視点を全面的に打ち出しています。目次を追うと、その考え方は第 6 章の「要求には「理由」がある」「必要なら「説明」を付ける」「要求のモレを防ぐことが重要」、第 7 章の「要求を階層化して範囲を狭める」「「MECE」の活用」「階層は 2 層ぐらいで止める」、第 8 章の「固有の番号を付ける」「検証可能性について」「「否定表現」などの曖昧な表現を避ける」といった節に具体化されています。要求の書き方を文の単位で扱う本は多くなく、上位の要求をどう割り、下位の要求と仕様をどう対応させるかを手順として示している点が本書の骨格です。

要求と仕様を分けて書く技術が、なぜ手戻りを減らすのか

ソフトウェア開発の手戻りは、工程が後ろへ進むほど修正の費用が膨らみます。実装やテストの段階で見つかる不具合の少なくない部分は、コードの誤りではなく、何を作るかが曖昧なまま作業に入ったことに起因します。要件定義 の成果物が「〜できること」という要求の粒度で止まっていると、開発者はそれぞれの解釈で空白を埋め、顧客はできあがった画面を見て初めて認識の食い違いに気づきます。本書のアプローチは、要求を階層化して範囲を狭め、要求には「理由」があることを明示し、仕様には固有の番号を付けて検証可能性を確保するという書き方で、この解釈の空白を仕様書の段階で埋めようとするものです。仕様が検証可能な文になっていれば、レビューで指摘でき、設計 に入る前に機能の難易が見えるという効果 (第 4 章「設計に入る前に機能の難易が見える」) につながります。第 13 章の「ベースライン設定と合意」「以後の仕様変更をコントロールする」、第 14 章の「レビューでの指摘件数とバグ件数の関係」は、書いた仕様を運用と計測に接続する部分で、仕様書を作って終わりにしない構成になっています。

派生開発と Excel の章、著者 清水吉男の経歴との対応

著者の清水吉男は、版元ページ掲載のプロフィール (刊行時点) では株式会社システムクリエイ代表取締役で、1968 年からソフトウェアの世界に身を投じ、汎用機のソフト開発から途中で組み込みシステムの世界に転向、さらにコンサルティングに転じ、1990 年に CMM と遭遇することで、自らの経験を元にして要求の仕様化技法 (USDM) や派生開発専用の開発アプローチ (XDDP) などを確立して 1995 年にプロセス改善の世界に方向転換し、2010 年に派生開発推進協議会を設立し代表として活動を開始したと紹介されています。その経歴と対応するのが第 10 章「派生開発における要求仕様書」で、"部分理解" の世界であるという前提から、旧状態を表現する、何が変更されるかを表現する、「差分」を書くといった節を経て、変更の要求・追加の要求・移植の要求・削除の要求を書き分けます。第 9 章「Excel による仕様化の勧め」は、「Excel」のほうが細かな使い方ができるという立場から、要求書と要求仕様書を一体化し、要求 TM (トレーサビリティ・マトリクス) へ展開する運用を示します。既存製品への変更や追加が開発の多くを占める組み込みや業務システムの現場で、本書の仕様化技術が求められる理由がここにあります。

前提知識として特定の言語やフレームワークは要りませんが、仕様書を書いた経験、あるいは曖昧な仕様書を受け取って苦労した経験があるほど、各章の指摘が自分事として読めます。プログラミングの演習書ではなく、目次に UML などのモデリング記法の章もないため、図で設計を表現する技法を学びたい人には別の本が必要です。2010 年時点の開発現場を前提に書かれていますが、要求と仕様の区別、階層化、検証可能性、ベースラインといった主題は開発手法やツールの変化に左右されにくく、受託開発で顧客の要求仕様書を受け取る側、社内システムの要件を業務部門から引き出す側、派生開発で差分仕様を書く組み込み開発者のいずれにも、仕様書を書くたびに立ち返る基準として長く使えます。仕様変更とバグの応酬から抜け出したい SE やプロジェクトリーダーには、投じた時間が最初の一件の要求仕様書から効いてくる一冊です。