　ソフトウェアをきちんと開発するには、さまざまな困難を乗り越えねばなりません。その中で最大と思われるのが、仕様変更でしょう。仕様変更とは、あらかじめ決まっていた仕様が変更になることです。例えば、ある通信手法では目標の応答性能を達成できないことが分かり、違う方法に変更するなど、成果物によってさまざまです。

　仕様変更は、より良い製品開発には必要ですが、開発するエンジニアは非常に過酷です。仕様変更を防ぐことは簡単ではありません。筆者の経験上、仕様変更がないプロジェクトの方が圧倒的に少ないと思います。そんなときでも、エンジニアはミスなく仕様変更に対応したプログラムを作る必要があるのです。

3．なぜ仕様変更が大変なのか

3.1 仕様変更は防げない

※写真はイメージです

　頭の中でできると思っていても、現実には違う場合がたくさんあります。例えば、絵を描くことを考えます。「何を描こう」「どんな色を使おう」「構図はどうしよう」といろいろ考えて描いて、初めて問題があることに気付きます。その場合、当初の計画を修正しながら、絵を完成させる必要があるでしょう。

　ソフトウェア開発でも同じで、仕様書で記述してできると思っても、実際に動作させると、意図通りにならないことがたくさんあります。

3.2 変更は大変

　仕様変更が大変なのは、今まで作成した部分を変更しなければならないことです。例えば、「仕様書を基に設計書を記述していて問題に気付き、仕様書を修正した」などがあるでしょう。この場合、修正が多方面に波及して大作業になりますし、修正ミスも発生します。

3.3 仕様が決まらない

　読者の方によっては、「仕様をきちんと凍結してから、次の作業へ入れば、こんなことは起きない」と思うかもしれません。もちろん、仕様を凍結することは大事ですが、そもそも、仕様が決まらないと凍結できません。

　一つの製品を開発するには、自社、顧客、関連会社のあらゆる人が関わるため、仕様を凍結することは簡単ではありません。仕様変更が頻発すると、コスト、納期、品質でプロジェクト進行に多大な影響を与えます。

　同じ仕様変更でも、物理的な問題、例えば、目標性能が出ないため処理方式を変更する場合は、それほど深刻ではありません。問題は、政治的な問題です。例えば、官公庁系の組織に教育部門と産業振興部門があり、両方の部署で共通の「プログラマー育成事業における電子的な申請・審査・承認システム」を導入する場合です。こんなシステムの開発は、世の中にたくさん存在し、作ること自体は難しくありませんが、両方の部署が「ウチでは、ずっとこうしていた」と従来の方式に固執すると、仕様はなかなか凍結できません。場合によっては、開発期間の90％以上を仕様の凍結に浪費することがあります。

3.4 突然の仕様変更

　上流工程（要求仕様フェーズ、設計フェーズ）での仕様変更は、なんとかなるかもしれませんが、下流工程での仕様変更は最悪です。今まで暗黙知で進んでいたものが、テストフェーズでは一気に顕在化するため、どうしても仕様変更とならざるを得ません。結果、エンジニアが、「もっと早く言ってくれ……」と思いながら残業で対処することになります。