あなたの書いた要求仕様書に「妥当性」はあるか：上を目指すエンジニアのための要求エンジニアリング入門（5）（2/3 ページ）
上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。
誰が妥当性の有無を判定するのか
妥当性の判断を、技術者が自ら実施することは難しい。技術者が自ら実行することは不当であるといえるくらいである。この判定は、要求実現に対し投資（あるいはコストの投入）を行える人（少なくとも投資に決定権限のある人）に委ねられる。技術者は、この判断を行う外部の顧客、あるいは社内の上級管理者の前で、要求仕様書をまとめた提案書を提示し、プレゼンをすることになるだろう。妥当性確認というだけでははっきりしないが、このフェイズはあなたの真価が問われる局面である。意思決定者の判断基準を事前によく理解することがとりわけ重要である。
意思決定者は、事業ないし業務を遂行した結果に対する責任を負っている。このため、意思決定にも慎重になる。また、妥当性を判断する基準は技術者が想像するよりも多様である。
意思決定者の手元には、通常さまざまなプロジェクト案件が届き、妥当性確認の判断を待っている。つまり、候補プロジェクトがポートフォリオになった状態である。意思決定者は、そのポートフォリオの中から、自社（自部門）の目的実現に効果が大きいとされる案件へと経営資源（予算や技術者など）を優先的に割り当てる決定をしなければならない。さもなければ、意思決定者の責任を果たすことができない。あなたの要求仕様書は、このような判断を待つに値するものであろうか。
要求が明確に記載してあるのは当たり前。それ以外にも、要求実現に必要なコスト、期間、投入が必要な技術者のスキルやその工数など、要求仕様書の実現に必要なさまざまな制約条件も併せて明記しなければならない。
妥当性確認をする前に、客観的な品質を確保する
ポートフォリオにリストされるには、妥当性確認を実施する前に、要求仕様書がそれにふさわしく記述されたか「検証」しておかなければならない。すなわち、要求ないし要求仕様の品質が確保されたかどうかである。第2回で説明した「要求にも品質がある」ことを思い出してほしい。
妥当性確認を受ける段階では、要求が備えるべき品質を確保したうえで要求仕様書が完成していることが望まれる。要求仕様書の作成者は、要求元に質問を繰り返し、あるいはほかの要求との矛盾を解消しながら要求の品質を向上させ要求仕様書に反映していくが、多くの場合、「要求品質ゲート」を通過することになる。このゲートでは、図3に列挙したような要求品質属性を定量的に計測し、できるだけ客観的な品質を確保する。
要求が要求リストに登録され、その中から抽出された要求に検討を加え、要求仕様書となる「要求開発」工程を“見える化”し、要求品質の充足度を定量的に把握することが望ましい。図3は概念的な図であるが、要求が要求開発工程を進むにつれて、要求の品質が向上していくことを示している。図3に示した「最終ゲート」で行うのが要求工程の「妥当性確認」である。それまでの過程で、要求レビューなどを実施し、要求の品質を確保する。確保できずに、後工程で要求の品質に不備が見つかると、要求のバグと判定されることになる。SWEBOKも「要求レビュー」「プロトタイピング」「モデルの妥当性確認」「受け入れテストの実施可能性」の4つに触れている（ただし、ビジネスやマネジメントの観点からの妥当性確認については記載していないので注意）。
図4は、要求の品質のうち「追跡可能性」と「検証可能性」を取り上げたものである。要求がどのように実装されるのか、また実装結果の妥当性が検証可能かを、要求の品質の一部として、要求開発工程で明確にしなければならない。そうすることによって、「追跡可能性」と「検証可能性」という要求の品質が確保できる。
妥当性を確実に生み出すためには？
もし妥当性が確認できなければ、要求仕様書としてまとまった記載がなされているとしても、その要求仕様書は保留あるいは廃棄される。従って、妥当性の判定を得られない要求仕様書は日の目を見ることがない。情報システムの調達コストを賄えない提案依頼書や、他社と競合し負けてしまった提案書などの作成に要した膨大な時間は営業コストや開発コストの一部として処理するしかない。このコストが多額であればあるほど、また長期間要したものであればあるほど、その間の機会損失も多額になり、企業の犠牲もいっそう大きいものになる。
では、妥当性を確実に生み出す方法はないだろうか。これは、「新製品を確実にヒットさせて、もうけるにはどうすればよいか」というたぐいの質問と同様、誰にとっても最も難しい質問である。成功したとしても、「たまたま」である可能性が高い。そうはいっても系統だった方法が欲しいという人は、連載「エンジニアが価値を生むための発想法」を参照してほしい。
Copyright © ITmedia, Inc. All Rights Reserved.