情報システムのリリース間際の仕様変更について

リリース間際の仕様変更はやめてほしい

業務システムの開発プロジェクトでは、時として、リリース目前での仕様変更が発生することがあります。
そして、仕様が変更となったにもかかわらず、リリース日は変わらないということが多々あります。

しかし、リリース日が変わらないまま、仕様変更を行った場合、プロジェクトがとても困難な状態となります。

プロジェクトメンバーの士気が著しく下がる原因にもなります。

なぜなら、プロジェクトメンバーにとって、リリース間際の仕様変更は、例えば、マラソンを走っていて、あと少しでゴールのタイミングで、やっぱりマラソンで走る距離を後400m増やすことにしたので、あとトラック2周してくださいと言われているようなものだからです。

マラソンでは、ゴールまでの距離を考えたペース配分をし、全力でゴールを目指すと思います。
そして、ゴール直前ではそのまま寝転がりたいくらいにつかれていると思います。
その状態でさらに走れと言われるとおそらく怒りがわいてくるのではないでしょうか。

システム開発プロジェクトでも同様に、要件定義や設計で何をシステム化するのか、どのような機能を作成するのかを検討し、製造工程では、検討した内容をプログラムとして記述していきます。

そのため、リリース間際で仕様変更となると、今までの時間は何だったんだろうと感じる場合もあります。
さらに、仕様が変更されても、期限が変わらない場合は、短い時間で再度仕様の調整を行い、既存の処理に影響を与えないように修正を行い、場合によっては1から再テストを行う必要があります。

そして、期限に間に合わせるために、かなり無理な対応を行う必要が出てきます。
マラソンを走り終わってすぐにでも休みたいのに、さらにそのまま走り続けろと言われているような状態になります。

結果として、プロジェクトメンバーの士気はだんだんと下がっていきます。

仕様変更が許容できる場合

以下のパターンであれば、仕様変更を行うことは、ほとんど問題になりません。

リリース間際ではあるが、仕様変更内容については見積もりを行ったうえで別途期間を設けて対応を行う場合
要件定義～基本設計までの間に発生する仕様変更
フォントの変更や、文言の変更など

まず「リリース間際ではあるが、仕様変更内容については見積もりを行ったうえで別途期間を設けて対応を行う場合」についてですが、この場合は、別プロジェクトとしての対応となります。
そして、見積もりを行ったうえで作業を開始するため、新たな仕様に対応するための影響調査、仕様の調整、ソースの修正等の時間を十分に確保することができます。
そのため、無理な対応をすることなく、場当たり的ではない、本来あるべき姿での対応が可能となります。

次に、「要件定義～基本設計までの間に発生する仕様変更」についてですが、要件定義～基本設計では、どのようなシステムを作ればよいかをユーザーとベンダーが話し合い、決めていく期間となります。
そのため、話し合いの中でシステムの仕様が変わることはよくあると思います。

ただし、リリース日が決まっている場合は、要件定義～基本設計の期間についても、期限がありますので、期限までには仕様を凍結する必要があります。

最後に「フォントの変更や、文言の変更など」についてですが、画面へ表示するフォントや、文言については、比較的簡単に修正できる場合が多くあります。

そのため、リリース間際であっても対応可能な場合が多いです。