開発期間中に仕様を変更してはいけない理由を説明したい

開発期間中に仕様を変更してはいけない理由を企画部新入社員に説明したい。

最も単純なプロジェクトを除いて、ほとんどの場合、仕様は開発中に変更されます。

理由は次のとおりです。

• プロジェクトの開発またはより可能性の高い統合テストにより、エッジケースから主要なファセットまで、元の仕様が行われたときに気付かなかったことが明らかになります。たとえば、開発者は、順序が正しくないメッセージの確認が到着する可能性があることに気付きます。

• 仕様を決定する実際の状態は凍結されていません。たとえば、ストレートスルー処理仕様に追加する必要がある新しい金融商品が作成されます。

• 締め切りのプレッシャーは、機能の剪定をもたらします。

• プロジェクトへの追加の利害関係者が発見された（たとえば、プロジェクトの途中で、類似したプロジェクトが別の地域で発見され、共通のサブシステムを一元化/共有する必要がある-これは、2年間のプロジェクトの途中で起こったため、大きな再建築）。

• プロジェクトの追加のスポンサーには、新しい仕様要件があります（最も有名な例の1つは、Bradley Fighting Vehicleの開発の歴史です）。

仕様の変更が悪影響を与える理由について（「実行してはならない」とは言えません。理由はたくさんありますが、ほとんどすべてが制御範囲外であり、正当な理由で多くあります）-

• 仕様の変更によりコードが変更され、まだ作成されていないプロジェクトパーツの完成に気を取られます（ご存じのとおり、Joel Spolskyによって伝道され、フォーカスの変更は開発者にとって非常に悪いことです）。

• 一部の仕様変更（場合によっては非常にマイナーなように見える）では、仕様からの仮定に基づいて2つのアーキテクチャのどちらかを選択したため、システムを完全に再設計/再設計する必要が生じる可能性があります。

• TDDの場合、テストに投入された大量の作業が無効になる可能性があります。

• 上記のように仕様の変更が追加の利害関係者からのものである場合、それらは既存の仕様と矛盾し、製品品質の大幅な低下を招く可能性があります（Fighting Vehicle、Bradleyを参照）。

• 仕様変更は、チェンジャー/リクエスターが気づかなかった、または気にかけられなかったいくつかの既存のビジネス要件に違反する可能性があります（これは、実際には最後の箇条書きと同じです）。

これらのすべてが当然のことですが、プロジェクトの納期が延長され（場合によっては大幅に）、欠陥の可能性が高まる可能性があります。

仕様のマイナーな変更が極度の問題を引き起こす可能性のある過去最高の例として、3つの文字を用意しました。

Y2K。

彼らがしたことは、「2000年以降に機能しなければならない」と言うように仕様を変更することだけでした。

さらに、状況によっては、仕様が変更されてはならない場合があります（「正当な理由なしに変更してはならない」とは異なります）。

• 仕様の一部は、インターフェースとなる外部システムの仕様です（または依存します）。

• 仕様の一部は、システムが実装されているハードウェアです（または依存しています）。

• クライアントとの契約要件（制限は、厳密に言えば、変更の事実だけではなく、クライアントとの変更を最初に処理して契約を変更せずに仕様を変更することです）

• システムは、顧客の好みに関係なく、特定の法的要件または規制要件を満たす必要がある場合があります。例：クレジットカードの暗号化、税データの保護。

開発中に仕様の変更を禁止することはプログラマにとって理想的ですが、実際の設定では現実的ではありません。物事が出荷されているときでも、人々は常に変更を加えたいと思うでしょう。止まることはありません。そして、それらの人々の何人かはあなたの給料に署名しているかもしれません。彼らが気にかけるほど、彼らはそれについて考えるようになり、それゆえ彼らはより頻繁にデザインを修正したいと思っています。たとえ最初からやり直すことになっても、完了する前にデザインを変更することを許容できる必要があります。

重要なことは、変更の結果を明確に伝えて、誰もが設計プロセスに対して現実的な期待を持つことができるようにすることです。

変更については適切に議論する必要があり、担当者は変更が納期に与える影響を明確に理解する必要があります。それを得るために、彼は開発者と話をしなければなりません。ただし、進行中の変更の議論は開発者を圧迫し、実際の作業が起こらないようにするため、変更はキューに入れられ、計画された不定期の間隔で議論される必要があります。もちろん、それはあなたが望んでいることです。

理想的には、加えたい変更をメモし、毎週、隔週、毎月、またはどのような調整会議でも取り上げてもらうように指示します。会議中に、要求された機能を実装するために行う必要のある根本的な変更の説明を含む、各変更要求、したがって完了日の影響について説明します。変更の「コスト」が確立されると、変更を含めるかどうかを決定できます。

このプロセスで導入する重要なことは、各変更に関連するコストがあり、複製する必要がある作業が増えるため、プロジェクトに沿って進行するほどコストが高くなるという概念です。開発に携わっていない人は、通常、変更にどれほどの費用がかかるかわかりません。彼らに伝える唯一の方法は、それを提案し、あなたの反応を評価することです。明確に定義された変更レビュープロセスを作成することは、彼らとあなたの両方に役立ちます。

プログラマーは、変更がどれほど簡単にできるかについて非常に楽観的であるか、変更がどれほど不可能であるかについて非常に悲観的である傾向があることに注意してください。元の推定値と結果を比較して、自分が何であるかを理解し、それに応じて調整してください。

おそらく、有効な変更要求とプロセスなしに仕様を変更してはならないと言う方が良いでしょう。仕様変更のリクエストは、スケジュールとコストに影響するため、これらを承認に含める必要があります。

適切な変更管理プロセスがあることを考えると、仕様の変更について「誤り」は何もありませんが、非常に高価になる可能性が高いため、顧客はあまり満足していない可能性があります。いくつかの優れた要件と仕様を事前に取得することでそれらを保護することができ、必要な変更が少なくなります。

私が持っている最も良いアナロジーは、それを家を建てることと比較することです。アーキテクトは計画を作成し、見積もりを出し、顧客は計画に同意します（同意しません）。顧客が追加のバスルームの設置を希望する場合は、作業が停止し、計画を変更する必要があり、新しい見積もりが行われ、顧客は同意します（または同意しません）。

ソフトウェアの作成も同じです。合意がなされたら（設計と見積もりの​​後で）、変更を行う必要がある場合は、新しい計画を立てるために作業を停止する必要があります。新しい見積もりを行うには、承認（または否認）してから作業を再開します。

私が言ったかどうかに関係なく、プロジェクトは新しい変更なしで続行されます。もちろん、常に新しい計画や見積もりを出す時間と資料があります。