すべての始まり＝「要求」を抽出する：上を目指すエンジニアのための要求エンジニアリング入門（2）（3/3 ページ）
上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。
要求の階層と合意形成
問題や要求は、個人に端を発していたとしても、組織的な問題や要求として理解される。つまり、ある人には問題（あるいは要求）であって、ほかの人には問題（あるいは要求）でない場合がある。組織にとってどのような問題（あるいは要求）なのかを協議し、合意を形成し、それを組織的な要求とするか決めなければならない。組織的な共通の理解と、そこにたどり着くためのプロセスが必要なのである。
もし共通の理解を得ることができなければ、その要求は組織内で理解されないまま消えてしまう。SWEBOKは共通の理解について直接教えることはないが、ソフトウェアエンジニアリングで扱う要求の多くは組織的なことである。
個々人の要求を組織的な要求に変えるためには、合意形成のプロセスに習熟する必要がある。つまり、要求の存在を単に指摘するだけではなく、グループや部門内の要求、組織全体の要求へと、要求に対する組織的な理解を高める努力をしなければならない（図4参照）。この合意形成プロセスでは、多くの場合、問題や要求の抽出と整理・分析のプロセスが重なる。そのため、合意形成に不慣れであると、要求の抽出と整理・分析のプロセスが交じり合って混乱してしまうことになる。
要求を混乱させないためには、要求の整理法に精通していることが望ましい。図5は最も粗い整理法である。ビジネス要求とそれ以外、という程度の整理である。しかし、最も基本的な整理である。
SWEBOKが示すような要求エンジニアリングのプロセスはあまりに簡素過ぎるため、さまざまな個所で補強が必要だ。複数の組織が絡む要求を扱うには、図4で示すような、（1）部門→（2）組織全体という階層的な合意形成のプロセスが欠かせない。実際には、複数のユーザー部門が主体になって要求を出し合い、合意形成するプロセスや、そのプロセスで要求を書き出すために使用するテンプレートが存在する。こうしたツールを使用し、要求抽出プロセスを極めて効率的に進めることができる。
要求は腐りやすい
「要求には鮮度がある」というと、あなたは不思議に思うだろうか。要求は環境や自社のビジネス要求の変化に影響を受ける。新たな要求が次々と顕在化し、それまであった要求は陳腐化する。システムやソフトウェアを要求レベルで見直し、最も有効な要求を後工程に送り出さなければならない。
そのため、要求はハンドリングしやすくしておくことが欠かせない。組織やプロジェクトによっては時間をかけて要求をわざわざ探さなくても、要求をデータベースに登録したり、一覧表にして保存・管理したりしている場合がある。時間軸の競争をするうえでは欠かせない要求管理方法である。もし要求がデータベース化されていないのであれば、まずはデータベース化することを勧める。
要求にも品質がある
品質の優れた要求を維持するようにしよう。システムやソフトウェア製品ではなく、また開発プロセスでもない「要求」に品質があるといえば、奇異に感じる読者もいることだろう。しかし、実際にあるのである。
「IEEE Recommended Practice for Software Requirements Specifications（IEEE Std 830-1998版）」は、要求は次のようなものでなければならないと、要求が備えるべき属性について明記している。
- 「完全である（Complete）」：実装に必要な情報がもれなく含まれている。また、TBD（To Be Determined：未定）事項がない
- 「整合性がある（Consistent）」：ほかの要求と矛盾していない
- 「正確である（Correct）」：正確にユーザーや外部の要求を記述している
- 「必要である（Necessary）」：ユーザーが本当に必要とするものを文書化している
- 「あいまいさがない（Unambiguous）」：要求の読み手全員に一意で解釈される
このような品質を備えたものとして検討されなければ、要求エンジニアリングのプロセスは欠陥のある要求を下流工程に送り出してしまい、結局後で手戻りが発生し、大きな無駄を生成してしまう。また、「宝」を生むはずのプロセスが「欠陥」を生み出し、宝を逃してしまうことになる。
抽出される要求は製品にかかわるものだけではない。本当にさまざまである。だから、要求を集めただけでは、要求に埋もれるだけである。要求エンジニアリングの目標に沿って要求を分析しなくてはならない。要求はすべての始まり。次回は「収集した要求をどのように分析するのか」を取り上げる。
著者紹介
前田卓雄
匠システムアーキテクツ株式会社 代表取締役
外資系コンピュータベンダのシステムエンジニア、デロイトトーマツコンサルティングを経て独立。主に、ユーザー企業、行政機関、大手システムインテグレータ、ハイテク企業、大手組み込みソフトウェア開発ベンダにおいて、情報戦略の立案、ユーザーが自ら作成するRFP（提案依頼書）作成を支援、ソフトウェアビジネスのプロジェクトポートフォリオ、プログラムマネジメント、プロジェクト管理とプロセス改善、開発プロジェクト管理システムの開発、バグ削減・欠陥予防・ソフトウェア生産性や競争力向上コンサルティングに従事。
Copyright © ITmedia, Inc. All Rights Reserved.