要求の旅は終わらない―開発と並走する「要求管理」：上を目指すエンジニアのための要求エンジニアリング入門（6）（3/3 ページ）
プロトタイピングやシミュレーションを利用する
過去に類似例のない新しいことに挑戦するプロジェクトでは、このようなやり方だけでは不安は消えない。そんな不安に悩むくらいだったら、もっと分かりやすい進め方を最初から採用してはどうか。例えば、プロトタイピングやシミュレーションを開発プロセスに取り入れるという取り組みである。
第5回で、プロトタイピングによる期待のコントロールを図示した。しかし、これを実現するにはツール（ソフトウェアを作るソフトウェアなど）を駆使しなければならないだろう。こうしたツールは、機械を作る機械（マザーマシン）と似ている。一朝一夕には準備できない代物である。しかし、より良いもの、確実なものを生み出す技術者には、いつの時代も追求しなければならないものでもある。追求すれば、尽きない面白さが広がっている。
要求管理を通じて「品質を作り込む」
開発プロセスは単に成果物を開発するだけではない。同時に、品質を作り込んでいるプロセスでもある。品質を作り込むためには、要求を構造的に理解しておかなければならない。そして、成果物の品質を埋め込むソフトウェアアーキテクチャや、個々の部品に対する要求品質を指標として定義し、品質を担保できる進め方を事前に決めておかなければならない。
ソフトウェア要求を特徴づける標準的な品質特性は、ISO9126やISO25000を参考にすべきであろう（第3回参照）。これらを出発点にするだけでも、レビューやテストだけに依存するより、かなり前進することだろう。また、QFD（品質機能展開）、シックスシグマ、タグチメソッド、FMEA（製品設計故障モード影響分析）などのメソッドに精通することも求められる。
要求プロセスをかく乱する要求変更
要求ベースラインに基づいて開発プロセスが順調に進み、完了時期もはっきりと見えている。そして、このままプロジェクトを完成させたいと思っている。そんなときに、大本の要求が変わることがある。
要求のベースラインを変更すれば、いろいろなことに影響が出る。成果物やスケジュール、コストはもちろんのこと、リソースの必要量や配置・タイミング、資金、ほかのプロジェクトとの調整（プロジェクトのポートフォリオやマネジメント上の調整）など、影響は想像以上に大きい。だから、変更の要否、重要度、優先度、リソースの追加、スケジュールの変更、採算性などを慎重に検討し、決定しなければならない。
いったん変更を受け入れたのであれば、要求ベースラインを改め、何事もなかったかのように、それまでと同じようにプロジェクトを遂行しよう。要求の変更に対応するには、プロジェクトを掌握し切る力が必要である。この力を生かせると、プロジェクトがダイナミックな生き物であることを実感できるようになるだろう。
CMMIやSWEBOKなど、既存の知識を活用して成長を加速させる
ソフトウェアやシステム開発におけるグローバルな形式知、CMMI（Capability Maturity Model Integration）についても触れよう。図3で示すように、3つのCMMIが存在する。要求側にはCMMI-ACQ（CMMI for Acquisition）、開発側にはCMMI-DEV（CMMI for Development）が提供するガイドが役立つ。
図3 CMMI-ACQ、CMMI-DEV、CMMI-SVCを活用し、能力を向上させるSWEBOK（ソフトウェアエンジニアリング基礎知識体系）が示す要求管理は、要求の変更管理、要求属性、要求追跡の3つだけであり、極めてシンプルである。むしろ、要求エンジニアリングにかかわる数多くの参考文献の紹介が役立つ。システムエンジニアリングの世界では、INCOSEの「Systems Engineering Handbook（現在はV3.1）」が入門書として役立つ。ビジネス領域の知識・スキルのリストとしては、BABOK（Business Analysis Body of Knowledge）のガイドブック（現在はV2.0）が役立つことであろう（参考：BABOK 2.0を読んでみよう - ＠IT情報マネジメント）。
合理的な知識獲得戦略を実践しなければ、多層で複雑、かつ動的なビジネス＋システム＋ソフトウェア＋ハードウェアの構造を理解することは困難だ。人材育成を担う組織も、体系的な育成の道筋を明らかにできなければ、要求開発・管理のプロセスすらうまくいかない。
開発（要求実現）プロセスで、要求がさらに増える
いろいろな工夫・努力を積み重ね、何とか要求をコントロールして実現しようとしても、要求はさらに増える。これが現実だ。「悩みは尽きない」と消極的に見ることも、「需要は尽きない」と積極的に対処することもできるだろう。できれば後者でありたい。
第2回を読み返していただきたい。とりわけ図2「次々と生まれる欲求と要求」を参照してほしい。要求が仕様書に姿を変え、それが実現しそうになれば、その状態を生かす次の欲求・要求が浮かんでくる。止めることはできない。読者が要求を実現している現在進行中のプロジェクトで、それはすでに起きているのだ。次の、その次の、そしてさらにその次のプロジェクトが潜在的に必要になっているのである。開発者が、新たに生まれている潜在的需要を要求者自身に気付かせ、要求を顕在化できれば、次の受注につながるだろう。
要求の特性をよく理解し、自分自身の成長に、そして顧客や自社の発展に生かしてほしい。そして、要求エンジニアリングを自分の強みの1つに、ぜひ追加していただきたい。
著者紹介
前田卓雄
匠システムアーキテクツ株式会社 代表取締役
外資系コンピュータベンダのシステムエンジニア、デロイトトーマツコンサルティングを経て独立。主に、ユーザー企業、行政機関、大手システムインテグレータ、ハイテク企業、大手組み込みソフトウェア開発ベンダにおいて、情報戦略の立案、ユーザーが自ら作成するRFP（提案依頼書）作成を支援、ソフトウェアビジネスのプロジェクトポートフォリオ、プログラムマネジメント、プロジェクト管理とプロセス改善、開発プロジェクト管理システムの開発、バグ削減・欠陥予防・ソフトウェア生産性や競争力向上コンサルティングに従事。
Copyright © ITmedia, Inc. All Rights Reserved.
ITmediaはアイティメディア株式会社の登録商標です。