「すし屋の注文」とは訳が違う、要求仕様書の書き方：上を目指すエンジニアのための要求エンジニアリング入門（4）（1/3 ページ）
上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。
経済環境は依然として厳しい。換言すれば、供給量に見合った需要、つまり要求が限られている。「これは」という需要が欲しい。であれば、有効な需要につながる要求を生み出し、明確にしなければならない。
このような状況の中で、ソフトウェアビジネスに欠かせない要求仕様に取り組むことは極めて重要である。まさに、ビジネスに役立つ「真の要求」開発競争に突入しているといえよう。
要求仕様書は誰が書くべきか
第2回で、要求抽出のプロセスとして、顧客または社内からの不満や機能追加など、発生するさまざまな要求を自社の要求データベースに蓄積していくことを解説した。第3回では、その中から要求を取り出し、「要求分析」を実行して要求を整理分類することを説明した。今回は、整理された要求に基づいて、「何が欲しいのか」を明確にし、文書に表すことをテーマとする。
まずは「誰が要求仕様書を書かなければならないか」について考えてみよう。もちろん、この「誰か」とは、設計担当者でも開発担当者でもない。何かを「欲しい」と望んでいる人が、自ら書く。これが自然だ。やや形式ばった要求仕様書の書き方を習得してでも、要求する人自身が書く、というのが本来の姿である。これは例えば、ある企業に就職したい場合に、本人が履歴書を準備することと似ている。
だが、ちょっと待てよ。履歴書を書く人は職を求めている人だが、履歴書の内容は求めている職のことよりも、自分の経歴や能力、志望動機について書いているではないか。人を求めているのは、実は企業側だ。実際に、企業は人を求めるに当たって「求めている人」の仕様書を書いているのである。われわれが準備している履歴書は、この仕様書に対する、いわば「提案書」のようなものだ。
要求している人の多くは、自ら要求仕様書を書かない。書く力が不足しているのかもしれないし、時間がないのかもしれない。だから、代筆者に当たるコンサルタントが登場する。前回登場した「要求アナリスト（要求エンジニア）」のことである（第3回を参照）。要求アナリストは要求仕様を表現するプロである。今日、上流を目指すエンジニアの目標の1つとなっている。
なぜ要求仕様書を書かなければならないのか
「要求は不満・不足・問題・トラブル・不愉快なこと・期待はずれ……の裏返し」である（第2回を参照）。要求データベースにはさまざまな要求が山積している。しかも、一部は分析され、仕様化を待っている。
すでに要求しているではないか。それにもかかわらず、なぜ「要求仕様書」を書かなければならないのか――こんな不満が噴出するかもしれない。さらに、何を書けばよいのか、仕様化とはどういうことか、そもそもなぜ「仕様化」が必要なのか、どれくらい詳しく書くのか、いったい誰がそれを読むのか、どのように読まれるのか……。こうした疑問が次々と浮かぶことだろう。あなたが要求アナリストを目指すのであれば、これらの疑問に答える必要がある。
例えば、「要求」と「要求仕様」の違いはどこにあるのか、という疑問について考えてみよう。
すし屋で「すし」を「要求」しても、すぐさま「すし」は出てこない。具体的に何の「すし」かを特定して伝えていないからである。特定するには、数量、値段、鮮度などが気にかかる。注文するには業界用語に精通する必要があるかもしれない。「マグロ」1つ取っても、 「クロマグロ」「ミナミマグロ」「キハダ」「トンボ」……といった具合だ。「大間のマグロ」のように、場合によっては産地を伝える必要もあるだろう。
仕様を表して初めて、相手に何を欲しているのかが伝わる。逆にいえば、仕様化できなければ伝わらないのである。だから、仕様化とは何かを特定する作業である。お客さんの要求をよく理解してくれるすし職人（ソフトウェア技術者）は喜ばれる。「いわなくても分かってますよ、何が欲しいのか。お任せください」である。こうした要求の受け手に出くわせば、いつも円滑に事が運ぶであろう。
しかし、実際にはそうはいかない。万が一、想定していないものが出てくれば、いったいわないでもめることになるだろう。もめるのが嫌であれば、望んでもいないものを、面倒を避けたいという理由で食べてしまうことになる。食べてしまえば、望んでいなかったものにすら、法外な金額を要求されて、支払う羽目になるかもしれない。果たして要求者は、こんな事態を受け入れる覚悟ができているだろうか。
個人も企業も、このような失敗を幾度となく繰り返している。もう後悔はしたくない。だから、欲しいものをはっきりさせたいのである。要求仕様を明確にする原点はここにある。とはいっても、すぐにはっきりと文書に表せるだろうか。はっきりさせる道筋を知る必要がある。これは「要求仕様化プロセス」である（第3回で、要求したものを開発する「プロセス要求」について言及したが、これと「要求仕様化プロセス」は別物である。図1を参照）。
Copyright © ITmedia, Inc. All Rights Reserved.