要件管理の扱い
List
仮説のサイズ見積もりが前提となる
要件管理の主要なアクションとして、ベースライン設定後の要件変更への対応があります。簡単な仕様レベルの変更であれば再見積もりも難しくありませんが、機能単位の追加があったり、事前に想定されていた設計方針の変更を伴うようなとき、その変更に必要な工数やコストへの影響を検討することが求められます。
このとき、追加される機能の概要が明らかになった時点、または要求レベルに展開した（私の方法では「要求」と「仕様」を区別します）ところで、この機能の中で抽出される仕様の項目数にはじまり、それ以降ソースコードの行数までの“サイズ”を見積もり、それらのサイズ情報から必要な工数を見積もる必要があります。もちろん変更内容や変更依頼が発生したタイミングによっては、そこまで進んでいた設計方法を変更する必要があれば、その手戻り工数も見積もることになります。
この時の見積もりは早い段階で求められるため、まだ仕様に展開される前の機能の概要やせいぜい要求レベルの表現から見積もる必要があるのですが、一般には、見積もりは要求仕様に展開された状態で、仕様の項目数が見えた状態で行われていることが多く、機能や要求レベルでの見積もりには慣れていません。そのため、変更依頼に対する見積もりは大雑把なものになってしまい、依頼者との間の信頼関係を損ねる原因になっています。
このような事態に対応するスキルを手に入れるためにも、ある程度の機能の概要や要求が見えた段階で、つまり要求に対する仕様を抽出する前に、ソース行数までの成果物をサイズに基づいて見積もることを勧めています。この場合、まだ仕様化は行っていませんので、それぞれの要求単位でどれくらいの仕様の数になるか、クラスの数は、ソース行数は、というところから見積もることになりますので、これを“仮説見積もり”と呼んでいるのです。
“仮説”の段階でサイズ見積もりに基づいて工数などを見積もることの第１の狙いは、要求ごとに仕様化した段階で当初の仮説見積もりとの「差」が見えます。工数は、この仮説見積もりに基づいて算出していますので、その「差」を使って以降の成果物のサイズ見積もりを調整し、さらに全体の工数見積もりを調整することにあります。
もう一つの狙いは、仕様化前の段階から、機能の概要や要求のレベルで以降の成果物のサイズ見積もりをしておくことで、ベースライン設定後に発生する要件の変更依頼（設計変更を伴う）によって必要な工数を見積もる際に、すでに個々の要求に対する仕様の項目数が「実績値」として手に入っていることです。変更依頼のタイミングによっては、さらに設計関係の成果物のサイズデータも「実績値」が残されています。そして、これらの仮説見積もりと実績値との「差」は、仮説見積もりのスキルに対する「実績値」でもあり、それが、変更依頼の時の再見積りの信頼にも繋がるのです。一般には、要件管理プロセスに必要なスキルの中に、こうした仮説段階でのサイズ見積もりのスキルの必要性は認識されていないと思われます。
プロジェクトによっては、要求仕様書が作られてから、その項目数のデータに基づいて以降のサイズと工数、コストの見積もりが行われているかもしれませんが、その状況のなかで変更依頼に対する再見積もりのスキルを手に入れるには、何らかの工夫が必要になるでしょう。また、ソフトウェア開発の全体スケジュールの中で、要求仕様書を作成するプロセスがスケジュール管理の“管轄外”に置かれる危険があり、そのことで以降のプロセスに必要な工数を圧迫する要因に繋がっていく可能性があります。そして、こうした形で工数を圧迫していることが、変更依頼に対する必要な工数を確保しにくくなることにも繋がるのです。
このように、“仮説”の段階で、要求の仕様化プロセスからサイズ見積もりに基づいた工数見積もりやスケジューリングが行われていないことが、要求の仕様化プロセスがスケジュール管理から外れてしまったり、全体の工数を圧迫してしまったり、途中の要件の変更依頼に対して適切な見積もりができなかったりする原因に繋がっているのです。
要件の実現性の追跡
私は、要件管理の中に含む機能の中に
１）要件の合意
２）要件の実現性の追跡機能
３）要件の変更制御機能
の３つを含めます。でも一般には、「実現性の追跡機能」は扱われていないと思われます。「CMM」の要件管理の中でも、ベースライン設定後の仕様変更に伴う追跡（正しく変更されたかどうか）は想定されていますが、変更を伴わなく要件の実現性の追跡機能は含まれていないようです。実際のプロジェクトでは、合意された要求仕様の中にアルゴリズム的に実現性が危うかったり、適切なデータ構造や処理構造を選択しないと実現できないような仕様が存在することがあります。保守性などの品質要求が課せられていても、品質を実現する設計技術に確信がないと実現しないことがあります。CPUの性能やメモリーの容量などのリソースの制約も、こうした実現性に制限を与えることがあります。時には、担当者によっても実現性が問題になることがあります。このような状況にあるとき、私は、要件管理の枠の中で適切に「設計」されているか、「コーディング」されているかを追跡して確認するのです。
要求され合意された要件が正しく（適切に）実現できるかどうか不安があるということであれば、「リスク管理」の中で追跡することもできます。実際にリスク管理の中で対応されているかも知れません。あるいは、自分たちの取り組みの対象ということで「課題管理」の中で扱ってもおかしくありません。でも、私は以下のような理由で、実現性の追跡を要件管理の中で扱うように勧めています。
１）関係者が合意したというものの、実際の担当者が要件の解釈を間違える（勘違いする）可能性があります。この場合は「要件管理」の枠の中で対応した方が分かりやすいと考えています。当人は、まったく勘違いしている状態ですから、第３者による最後のテストの段階まで解釈を間違えていたことに気付きません。主要な機能で、これを外すわけにはいかないものや、品質要求など、設計のやり直しになるような要求の実現世鵜の追跡を要件管理で扱うことで、担当者の勘違いや不適切な設計を早い段階で発見できますので、間違っていても手戻り工数が小さく抑えられます。
２）こうした追跡項目は、派生開発でも追加機能が多い時は数１０項目に達します。新規開発であれば、１００項目を超えることも少なくないと考えられますので、リスク管理の中で扱えば、この他のリスクへの対応に支障を来します。
３）派生開発の中で発生する「ペーストシンドローム」（註１）も、一種の担当者の勘違いですので、要件が確実に実現するかどうかを要件管理の枠の中で追跡した方が簡単に対応できます。ソフトウェアの「移植」では、元のソースコードに手を加えることなく移植する場合は、ほとんどトラブルになりません。また、広範囲に手を加えるようなときはそれなりに設計しなおすので慎重に対応します。むしろ、簡単な変更を加えるようなときの方が変更方法を間違えてしまうのです。通常は、仕様のレビューの中で「これは移植で実現しよう」と決めます（註２）ので、ここで「ペーストシンドローム」に陥る危険性が見えます。
４）ベースライン設定後の仕様変更のに発生時期によっては、その時点まで進めてきた設計内容を一部変更する必要があったり、時には設計のやり直しになったりすることがあります。この場合は、設計の変更内容が正しい方法に選択されたことを確認する必要があります。一般に行われている、仕様変更に伴って必要な文書の更新を確認するところでは、どちらかといえば「構成管理」の中で行われるような文書の変更（更新）を間違いなく行うことを確認することとイメージされていることが多く、変更内容の吟味まで扱われないことがあります。
このような理由から、私は要件管理の中で「実現性の追跡機能」を持ち込むのです。
追跡の対象となる要求または要求仕様は、基本的には合意のレビューまでに何度か行われるピアレビューの中で決めていきます。適切に仕様化されている状況であれば、その時点では実現性に不安がある仕様も見えています。対象とするのは、たとえば
・今回のシステムの主要機能
・品質要求
・タイミングに厳しい注文がついているもの
・「ペーストシンドローム」に陥る可能性のある要求
などです。これらの追跡対象を要求仕様書から抜きだして実現性の「追跡リスト」に載せて管理します。また、担当者が決った時点で、機能の難しさとの関係で追跡リストに載せることもあります。
註１：「ペーストシンドローム」と言うのは、一種の「移植」によって新しい機能を実現するのですが、その場合、新しい環境や制約に合わせて、ソースコードの一部の変更を伴うケースを指します。
註２：プロジェクトの最初から「移植」で実現することが決っていることもありますが、最終的に、要求仕様のレビューの中で決定すべきです。