仕様凍結と仕様変更のバランス

「仕様凍結」という言葉があります。
これは、発注者とシステム開発者と間で、システム仕様を確定させることです。

仕様凍結は、とても大切であると言われます。
仕様が確定しないまま開発が進むと、深刻な手戻り等が発生し易く、それによりシステム開発のＱＣＤが悪化するからであると、私は認識しています。

そのような考え方に、私も基本的には同感であり、同調しています。


私は、ユーザー部門・お客様と構築ベンダーとの間で、仕様凍結を２回設けます。

１回目は、要求仕様の凍結。

２回目は、基本設計の凍結。

この仕様凍結があることをご認識いただくことで、特にユーザー部門やお客様が、要求定義フェーズと基本設計フェーズに真剣に取り組んでいただくことが期待できます。
よって、システム開発終盤での大幅な認識の相違等の発生リスクが低減されます。
また、もう少し前向きな表現で言いますと、ＱＣＤのバランスのとれたシステム開発が実施され、プロジェクトの成功確率が向上するものと考えられます。

よって仕様凍結は、システム構築プロジェクトにおいて、欠くことができない実施事項と言えます。



それを前提とした上でですが、

一方では、仕様変更が必要な時には、柔軟に対応していくことも必要です。

例えば、ユーザー部門やお客様の環境の変化に極力対応していくことは大切なことと考えられます。
凍結された仕様どおりに開発しても、業務要求に変化が生じてしまっているため、使えないシステムになってしまう、という事態も（当然のことですが）避けなければなりません。

また、凍結された仕様に誤りがある場合もあります。
ユーザー部門・お客様の受入テスト時または運用テスト時にそれが明らかになり、残り期間の無い中でお客様の感情も高まり易く、激しいやり取りの末、仕様変更せざるを得ない状況になる場合もあります。
このとき、ユーザー部門・お客様側とシステム開発側とも、不満を抱くことになります。


それらの問題を解決するためには、

プロジェクトの予備（期間、コスト）を保持しておくことと、
テスト期間前半でのユーザー部門・お客様の確認機会を設けることが有効だと、私は考えています。


予備の保持については、言うまでもないと思います。
しかし、ユーザー部門・お客様からの短期開発要請、低価格要請は強まるばかりで、十分な事前検討もできず、予備もほとんど確保できない、という状況が増えているような印象を受けています。

私は、ある程度の予備を保持することは、ユーザー部門やお客様にとって、必ずメリットがあることと思っています。


また、テスト期間前半におけるユーザー部門・お客様の確認機会についてですが、
いろいろ難しい場合も多々ありますが、
私は、ソフトウェア結合テストまたはソフトウェア総合テストの終盤において、ユーザー部門・お客様に出来上がりのソフトウェアをご確認いただくことがたいへん有効であると考えています。

これにより、仕様凍結時点までに発生した、発見し辛いミスや認識の相違が明らかになる場合がありますし、また、環境変化により、このままの仕様では問題があること等も早めに気づき易くなります。

それらの課題について、データーベース構造に影響を与えない範囲での解決策を提示し、早めのタイミングで予備を利用して対応していくことで、プロジェクトのＱＣＤが維持でき、お客様満足の向上にもつながると、私は考えています。


とても一般的で当然のことを記載していると思われるかもしれませんが、
仕様凍結と仕様変更の両方に対応していくことはとても重要であり、その実施を確保する仕組みをプロジェクト計画に盛り込み実践することはプロジェクトの成功要因の一つであると、私は最近、再認識したところです。


＜関連記事＞
　超上流工程からシステム運用テストまでにおける考慮事項