要求の仕様化（要件開発）
List
指摘されたカ所を具体的に改善する
要求仕様のレビューで仕様漏れや表現の曖昧さを指摘されたり、バグとして発見された場合は、単に、その指摘や発見に沿って訂正するだけでなく、なぜ、その仕様に気付かなかったのかを考え、実際に要求仕様の「その部分」の構成を変更してみることが大事です。
私が勧める要求仕様（拙著「要求を仕様化する技術・表現する技術」）の書き方では、仕様が漏れる原因として、
・要求の表現が範囲を具体的にイメージさせていない
・時には最上位の要求の表現が抽象的すぎて動きや範囲が見えない
・グループでまとめられていなかったり、グループの括り方が粗かったりしている
・ペースト作文で書かれている
などが考えられます。このほかに、開発するシステムや製品の“ユーザー”の定義が不明確な状態が原因になっていることがありますし、機能間の関係（依存関係、順序関係、排他関係など）を表わす補助成果物（通常は、マトリクスなどの形で表わします）が不足していることで、必要な仕様に気付く機会を持てなかったということもあります。
レビューで指摘されたりバグで発見された仕様漏れは、たとえば上記のどれに該当するのかを判断して、要求仕様書の書き方や構成を（部分的にでも）変えてみることが大事です。漏れが指摘された仕様を、漏れた箇所に書き加えるだけでは、仕様漏れを防ぐスキルは手に入りません。この問題は、バグとして指摘されたときも同じです。発見のプロセスが異なるだけで、「仕様漏れ」が指摘されたことには変わりはないのです。
直属の要求やさらに上位の要求の表現が適切に範囲を表わしていないことで、この仕様に気付かなかったと思えば、その要求の表現を変えてみて、今回指摘された仕様がうまく収まるようにしてみるのです。また下位要求の分割基準を「時系列」などの基準で整理してみることで、その仕様が収まるかも知れません。うまく収まらないことが、漏れる原因なのです。
グループの括り方が悪いと思ったのであれば、実際にグループの表現を変えたり括り方を変えてみて、今回指摘された仕様が収まりやすくなったことを確認することが大事です。また、＜グループ＞による分割整理は、下位要求が１０数個並んでいるような場合にも有効です。分割された要求が何の秩序も持たずに並んでいる状態では、要求（下位要求）そのものが漏れてしまい、その結果として仕様も漏れてしまうのです。
これに対して、“仕様としての表現が曖昧”という指摘は、作成者のスキル以外に、そのチームのメンバーのスキルにも大きく影響受けるために厄介です。自分では、これで分かるだろうと思っていたものが、メンバーには通じなかったということですので、まずは、こういう表現では読み取ってもらえないという、その「事実」を受け入れる必要があります。これは「現実問題」として認めることが大事です。その上で、個人的に「曖昧事例集」のようなものを作ってみることをお勧めします。
・どういう表現が通じなかったのか
・それをどういう表現に変えたことで通じたのかということを書き出して分類しておくのです。Excel のようなソフトを使ってまとめておけば、通じなかった表現と改善した表現を対比させる形で整理できます。また、どのプロジェクトで指摘されたのかということを日付けと一緒に記録しておくことによって、その後に、再び同じような曖昧な表現が指摘されたときは、その事例の下に新たな事例が加わることになります。表現が改善されたパターンはその下に新たな事例は追加されませんので、登録した日付けから、改善されている状況が推測できます。
仕様漏れなどの指摘に対しては、このように対応していけばすぐに曖昧な表現はなくなります。
要求仕様書に対する間違った“お墨付き”
CMMでは、要件管理に取り組むことが出来る前提として、要件管理の能力２（CMMIではSP1.1がこれに近い？）のところで要求仕様についてきちんと文書になっていることが求められています。でも、考えてみて下さい。まったく文書になっていないような組織はありますか？
確かに、そこにあるものは内容や構成については不十分なものかもしれません。途中で仕様変更も少なくありませんし、仕様モレのバグもたくさん発生します。でも、多くの組織では、それ以上（以外）の書き方や要求仕様書としての構成方法があることを知りません。知っていて、出来の悪い文書構成を選んでいるわけではありません。そんな不謹慎な人はいません。
また、「要求仕様書」と言うからには、内容について第三者が「これでは“要求仕様”とは言えない」と注文が付けられるものでもありません。直接の関係者が、そこで表現されている状態で、作ろうとしている機能の仕様について“Specify”出来ていると判断されているのであれば、それが“要求仕様”なのです。（拙著「要求を仕様化する技術・表現する技術」5章3節参照）
そして、要件管理の活動１（CMMIではSP1.2に相当）のところでは、設計作業に取り掛かる前に、関係者が「合意する」ことが求められていますが、「合意」という“セレモニー”もなく、設計作業に取り掛かっている組織はありますか？
たしかに内容の一部については“FIX”を要求しているかも知れませんが、全く合意できていない状態で先に進むことはないでしょう。もっとも、CMMIでは、この「合意」については非常に高いレベルのものが求められているようですが、もともと日本の社会では「コミットメント」の概念はありませんので、従来のような関係者の「合意」か、せいぜい、一歩踏み込んで「確認書」の形で合意したことの証拠を残す程度でしょう。でも、このような「確認書」でも、「コミットメント」に代わるものではありません。
こうした状態の中で、CMMのアセスメント（CMMIではアプレイザルと呼ぶ）では、そこで書かれている「要求仕様書」そのものは承認されるのです。つまり、第三者による判断（ある意味では公的評価）によって、そこにある要求仕様書が、要求仕様書として“お墨付き”が得られたことになるのです。逆に言えば、要求仕様書だけをみて第三者が批評できるものではないのです。
公的な評価によって、そこにある要求仕様書でも“良い”となると、要求仕様に関する問題を仕様の構成や書き方以外のところに求めるのは、自然の成り行きです。そしてこのことが、後になって大きな禍根を残すことになる可能性を含んでいるのです。
時間の入れ替え
多くの組織で書かれている要求仕様書は、要求仕様の作成段階では曖昧さを残されています。というよりも、意図的に曖昧な表現にしていることもあります。そして、具体的なレベルでの仕様は、“設計に入ってから詰めて行くもの”という認識が一般化しています。理由として考えられることは、その方が効果的だというよりも、従来の要求仕様書（実際は機能仕様書）の構成では、個々の機能が独立して展開されており、しかもその中で中心的、代表的な動きについて仕様化されていて、イベントに始まるシナリオの中でその機能の仕様を体系的に捉えるようになっていないために、仕様化プロセスの成果物である要求仕様書では仕様化できない状態にあるものと思われます。つまり、現状の要求仕様書の構成や書き方の中では、効果的な仕様の抽出は捗らないのです。
もう一つの障害は、いわゆる「仕様」のレベルで展開しようとすれば、間違いなく要求仕様の項目数は増加します。数倍から１０数倍に増えるかも知れません。この「増加」に対する不安が、要求仕様作成プロセスにおける仕様化に対する抵抗になっているものと思われます。要求仕様書の構成の問題と、数に対する抵抗の両方が相まって、要求仕様書に曖昧さが残される結果となっているのでしょう。
でも、私に言わせれば、とても書ききれないほどの仕様が存在するなら、それを早い段階で表現しないで実現するという根拠はどこにあるのでしょうか。設計や実装のプロセスで仕様が明らかになったのでは無視できないほどの手戻り工数がかかってしまうことは経験済です。場合によってはそれまでの仕様に基づいて設計されたアーキテクチャでは、新しく発見された仕様は実現しないことも起きてしまうのです。それよりも、設計や実装のプロセスで明らかになるのであれば、要求の仕様化プロセスで明らかにできた方が良いわけです。それが出来ない原因を取り除けば良いわけです。
「USDM」の表記法を使えば、個々の機能の中で実現したいことを「要求」として表現しますが、そこには一つ以上の「イベント」が見え、そこからの流れを「シナリオ」として捉え、階層化した要求で表現したり、＜グループ＞でシナリオの流れを表現する構成になっています。そのため、従来であれば、設計や実装のプロセスを進めていく中でしか見えなかった具体的なレベルの仕様が、初期の要求仕様の作成の段階でイメージできるようになります。
その結果、要求仕様作成のプロセスの工数は従来とくらべて大幅に増加することになりますが、ここで増えた工数は、従来では設計や実装のプロセスの中で使われていたものが、仕様化のプロセスに移っただけであって、工数的には、設計や実装のプロセスの工数が減るので、全体としては工数は増えません。逆に、従来は設計や実装プロセスの中で仕様化されていたことで、仕様間の衝突（コンフリクト）が発見しされにくく、見逃されているケースも少なくないのです。中には他の仕様との関係が気になるというので、設計書やソースコードを辿って、既に設計図やソースコードになった中から「仕様」を見つけることになります。
また、要求の仕様化が設計以降のプロセスの中で行われていた場合は、そこで明らかになった「仕様」は担当者の中で処理され、必ずしも要求仕様書に書かれるとは限りません。そこで書かれている要求仕様書の構成は、そのような具体的な仕様が表現されるような構成になっていないこともあって、設計や実装のプロセスの中で明らかになった仕様は表現されないことが多いのです。分かりやすく言えば、従来の要求仕様書には、設計や実装プロセスで明らかになった具体的レベルの仕様の「居場所」が無いのです。
そうなると、仕様間の衝突（コンフリクト）といっても、それは「たしか１週間前に扱った○○の機能の仕様と衝突しているのでは？」というように、記憶の中で発生しているだけであって、手元の要求仕様書を見てもその仕様は表現されていないのです。そのため、衝突の状況を確認する方法はそれまでに書かれた設計資料やソースコードをたどることになりますので、その際の工数はバカになりません。後になればなるほど、関係する機能も増えますので、仕様を辿る作業は大きな負担になるのです。
でも要求仕様のプロセスで仕様化が進むことで、仕様の衝突の可能性があるときは、そこで体系的に書かれている要求仕様書を見ればわかりますので、この種の手戻り工数は大幅に削減されるのです。そしてこの「差」の工数は、最終的にも「獲得時間」として短くなります。つまり、適切な構成を持つ要求仕様書として早い段階で仕様化することで、プロジェクトを遅らせることはないのです。