要求仕様の確定をめぐる話も今回が最後である。納期・品質・コストに影響を及ぼす仕様凍結は、プロジェクトにとって極めて重要な価値があることを顧客に訴える必要がある。
 |
システム品質を確保するためには、開発の各段階でレビューやインスペクションを実施することが効果的だといわれている。しかも問題点の発見・検出は、工程の早期であるほど原価面での効果が大きいだけに、システム仕様がまとまったらなんとしても関係者によるレビューを実施しておきたい。
そのためにも仕様書は、レビューに参加するすべての人が理解できるように記述されていることが肝心である。レビューにぜひ参加してほしいエンドユーザーの代表にもよく理解できるように、形式言語は避け、あいまいさが残っても自然言語で書いたほうがよいであろう。
逆に、顧客特有の業務用語は多くのベンダー開発者にとっては分かりにくい点が多い。特殊な意味で使われている業務用語については、誤解がないように用語集を整備すべきである。
 |
システムの短納期化に伴い、カスタマイズ付きの標準パッケージ活用が進んでいる。しかし、パッケージをスピーディーに導入するには、原則ノンカスタマイズにすべきだ。
過剰にカスタマイズしたことで、仕様決定に手間取るだけでなく、なかなか品質が安定せず、大混乱プロジェクトになってしまった例はあちこちで見られる。苦戦の末、なんとかまとまったケースでも、その後にパッケージのバージョンアップに追随することが、コスト的にも工期的にも無理だと分かり、パッケージの活用自体を断念した顧客もいる。ベンダーは、ゼロ・カスタマイズ、ミニマム・カスタマイズを粘り強く説得すべきである。
顧客の経営者から見れば、各現場の個別要求を取り込むことでコストを増やし納期を遅らせるより、標準機能を早く安く使えるほうがいいということはよくある。顧客とはよく議論しなければならない。
 |
いまやパッケージを中心にシステムを構成する時代だが、たまたまそのパッケージが開発途中であった場合には問題が起こりやすい。仕様が顧客を十分に満足させるものであっても、未完成品であることのリスクの大きさを理解しておかなければならない。
パッケージといっても、ある程度顧客の要望を受け入れなければならないが、とかく半熟製品の場合は、次々と仕様追加・改造要求が頻発してしまう例が多い。少なくとも完成時のパッケージの詳細仕様書だけは、初めからきちんと提示できていないようだと、顧客はいつの間にか「特注品を作ってくれている」と錯覚してしまう。
 |
システムをめぐっては、経営者、システム開発者、システム運用者、システム利用者など、それぞれの利害が必ずしも一致しない多くのシステム関与者がいる。そのため、システムの仕様を決めるときには、それぞれの立場（視座）からシステムを眺め、問題点がないかどうかをレビューすることも重要である。
特に、システム利用者とって真に役に立つ仕様になっているのか、使いにくいことはないか、などをよく見ておかなければならない。できればシステム利用者の代表にレビューに参加してもらうことも必要だろう。システム利用者にとって使いたくないシステム、使いにくいシステムでは、稼働後に仕様の大幅修正が必要になったり、最悪の場合はシステム自体が挫折してしまう危険性すら内包している。
システム仕様は、できるだけ詳細で漏れのないように、そして小さく、早く決めることが求められるが、役に立たない仕様では全く意味がない。
