「すし屋の注文」とは訳が違う、要求仕様書の書き方：上を目指すエンジニアのための要求エンジニアリング入門（4）（3/3 ページ）
上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。
業務系システムでは、構築したいシステムの要求をまとめた提案依頼書（RFP：Request for Proposal）を作成する。これも要求仕様書の一種である。業務システムの要求をまとめた典型的なRFPでは、ハードウェア／ソフトウェアへの要求や、プロジェクトの進め方という制約条件も含め、図4のような構成となる。
このようなRFPの実例は、RFP研究会のWebサイトで公開されており、二百数十ページにも及ぶRFPの実物を無償で入手することができる。このRFPの実例を見れば、あなたは業務システムを調達するためにどのようなことを表現しなければならないか、経営効果に直結した要求仕様のありようを実践的に理解できるだろう。
このRFPの実例の大半は、情報システム部門ではなく、システムを利用するユーザー部門が自組織を良くしたいと思って書いた「あるべき（To-Be）業務要求」で占められている。つまり、新しいシステムを欲しい人たち、業務改善／改革を望む人たちが自ら、欲しいシステムを定義したのである。しかも、このRFPに基づいて、実際にシステムを調達し効果を獲得したのである。
この実例から、RFPという要求仕様書は表し方さえ分かれば、それまでに一度もRFPを書いたことがない人でも書けることが分かる。だから、書けないと過剰に懸念するよりも、書いてみることがいっそう大切である。実践すれば、役に立つシステムを低コストで調達することが可能になる。
商品企画書や事業企画書に含まれる要求仕様
要求仕様は、要求仕様書だけに限定して登場するわけではない。
携帯電話やカーナビ、デジタル家電のような市販されているシステム機器では、機器の利用者（エンドユーザー）が「もっとこんな機能を追加してほしい」「価格をもっと下げてほしい」といった要求を機器メーカーに届けることができる。メーカーのマーケティング部門や営業部門では、このような要求を「市場の声」「顧客の声」として要求データベースに登録してくれるだろう。しかし、システム機器を使用したいエンドユーザーが、要求仕様書を自ら記述することはない。
マーケティング部門や営業部門は、「売れる（はずの）商品」を明確にして商品開発を促さなければならない。その商品がソフトウェアを必要とすれば、ソフトウェア要求を含んだ企画書を書かざるを得ない。実際に、欲しい機能、優先度、ソフトウェア開発コストに対する上限や出荷時期、競合他社の製品に比べた優位性などの要求事項が記載されている。しかし、記載レベルは一般に浅く、例えば「競合製品に比べ、機能で優れ、価格が安い」という程度の記述である。これでは、とても要求を特定したとはいえない。この企画書から、もっと具体的な何かを明らかにした仕様を明確にしなければならない。
ここでも、IEEE発行の『Software Requirements Engineering』（第2版）p.245〜280に記載されている「IEEE Guide for Developing System Requirements Specifications」（IEEE Standard 123-1998）や、同p.115〜135に記載がある「IEEE Guide for Information Technology - System Definition - Concepts of Operations (ConOps) Document」（IEEE Standard 1362-1998）の仕様書テンプレートが役立つであろう。
ほかにも例えば、事業企画書には新たに創業を提案する事業のビジネスモデルが記載される。さらに、事業を開始することによって作り出される商品の特徴や仕様が記載される。今日のビジネス遂行にはICT（情報通信技術）はなくてはならない。従って、ビジネス要求の一部として、当然のようにシステム要求が記載される。また、「売れる商品」の企画書にはソフトウェア要求が登場する。
あなた（要求アナリスト）が書いた仕様書で要求元が納得するか
このように、要求仕様はいろいろな形で登場する。決して1つの定型的な表現形式に押し込めることのできないものである。また、登場する利害関係者によって、要求仕様書に多種多様な補強策が入ることも避けがたい。
はっきりしていることは、書かれている要求仕様をベースに、その要求の実現にどれくらい犠牲を払えるか（コスト・期間・リソースを消費できるか）が問われる、ということである。誰しも払うべき犠牲に見合ったものか知りたいのである。効果に見合わないものには犠牲を払いたくないのである。
だから、要求仕様書は見積もりやすく書く必要がある。書いた要求仕様書は実現に必要な見積もり額がつく。もしその金額の幅が大きければ、要求仕様書の記載が甘いのである。要求仕様書は「効果に見合った犠牲を払ってでも欲しい何かをはっきり書いてあるかどうか」が問われる。どのように要求仕様書を書こうとも、犠牲を超える価値創出がなければならないのである。
従って、要求仕様を書く人は価値創出に敏感にならざるを得ない。要求アナリストは、価値を生み出す手法に精通することが求められている。例えば、QFD（品質機能展開）、TRIZ（発明的問題解決の理論）、USIT（統合的構造化発明思考法）、VE（価値工学）などの手法である（TRIZ／USITについては、連載「エンジニアが価値を生むための発想法」を参照）。
要求エンジニアリングは、要求の抽出・分析・仕様の記載・妥当性確認・管理について言及してはいるものの、要求を通じて生み出すべき「価値」「価値の種類や定義」「価値の創出」には少しも触れていない。要求仕様を書く人は、要求の背景にある「価値」についても学ばなければ、その役割を果たせない。さもなければ、さらに上流のコンサルタントが登場することになるだろう。なぜなら、顧客は要求を通じて価値を追求しているからである。価値創出・価値提供が明確にならなければ、要求仕様書の書き方を知っていたとしても、書くべきことが分からないだろう。
要求仕様書を次工程にバトンタッチできるか
「要求開発」の次工程は通常、設計開発工程である。ユーザー企業が業務システムを要求し調達する場合であれば、システム調達工程である。ソフトウェア技術者を含め、通常、システムエンジニア（SE）と呼ばれる職種の人たちが活躍する領域である。要求アナリストは、要求仕様書をSEたちにバトンタッチし、職務を完結しなければならない。
次回は、「バトンタッチする前に、バトンタッチに値する要求仕様書を書き上げたかを検証する」という工程を取り上げる。すなわち、要求の「妥当性確認」である。
著者紹介
前田卓雄
匠システムアーキテクツ株式会社 代表取締役
外資系コンピュータベンダのシステムエンジニア、デロイトトーマツコンサルティングを経て独立。主に、ユーザー企業、行政機関、大手システムインテグレータ、ハイテク企業、大手組み込みソフトウェア開発ベンダにおいて、情報戦略の立案、ユーザーが自ら作成するRFP（提案依頼書）作成を支援、ソフトウェアビジネスのプロジェクトポートフォリオ、プログラムマネジメント、プロジェクト管理とプロセス改善、開発プロジェクト管理システムの開発、バグ削減・欠陥予防・ソフトウェア生産性や競争力向上コンサルティングに従事。
Copyright © ITmedia, Inc. All Rights Reserved.