仕様変更をすると良くない3つの理由

なんか釣りっぽいタイトルですが、【翻訳】プログラマを悩ませること Top 10みてちょっと触発されたので。仕様変更自体はやむを得ないものだし、それ自体を否定するわけではないですが、現場に悪影響を及ぼす可能性を多くはらんでいると考えます。仕様変更をする時はよく考えてからGoを出すべきですという話。

1. 無茶な要求がでてくる

「AができるんだからBもできるよね」「ここをちょっとこう直すだけだから」という言説をよく見かけます。 簡単にできる修正ももちろんありますが、そうでないものもたくさんあります。特にソフトウェアのようなものは 裏のロジックも含めた実態がぱっと見わかりにくいものですが、あなたが要求していることは建設済みのビルに対して 「今60階のビルだけど、61階にしてくれない? 1つ増やすだけだから簡単でしょ?」とか 「ちょっと横に1mぐらいずらしてくれないかな」と同じようなことを要求しているかもしれません。

2. 期限やリソースが勝手に決まる

もちろんどんなに無茶と思われる要求でも、多くの期限と大量のリソースを投入すれば実現可能かもしれません。 60Fのビルも莫大な費用をかければ61Fになるかもしれません。(建築関係詳しくないですが) ただ、それに対してどのくらいの期間が必要か、という判断を1と同じような「表向き」に見えている 部分からだけの判断だったりすると、不幸なことになります。単純に間に合う、間に合わないの問題ではなく 新たな問題が発生することによって、全体のクオリティにも影響するかもしれません。 突貫工事の事故でビルそのものが倒壊する恐れもあります。

また、特にソフトウェア開発やSE的案件では人月(人数×時間)で開発や修正に必要なコストが計算されますが、 古の伝承でも指摘されている通り、 人数と時間は置き換えることができません。むしろ人数を増やせば増やすほどコミュニケーションコストがあがって ずぶずぶ泥沼に沈んでいきます。あと、開発する人の熟練度も一様ではありません。 Lv1の戦士が100人いてもLv99のボスを倒すことはできないですし、アマチュア作家を100人集めれば 必ず芥川龍之介の文章ができるわけではありません。

3. モチベーションが下がる

仮に期限やリソースが無限に設定できたとしても、度重なる仕様変更はエンジニアのモチベーションをすり減らしていく場合があります。追加の機能などであればまだいいですが、根本的な設計の変更が必要なものだったりすると、今まで頑張ってやってきたものの大部分が無駄になることもあります。穴をほって同じ場所を埋め戻すのを延々と繰り返すという拷問があるそうですが、それと同じようにいつまで頑張っても達成感が得られないような仕様変更が続くと、「どうせまた無駄になるし」みたいな気持ちになって、どんどん仕事が適当になっていくでしょう。

じゃあ、どうしてほしいか

とにかくエンジニア(ないしは実際に作業をする人)を決定に巻き込むことが重要だと思います。 期限や開発者の状況や、変更にどれくらいのコストが掛かるものなのかを関係者みんなで共有することで、 現実的な変更にすることができるかもしれません。もちろんこれはエンジニア側もなぜ難しいのかを 分かるように説明する必要がありますし、変更の目的を実現できるもっと良い案を出していくこともしなければなりません。 実際には、発注側と開発側のお互いが歩み寄ることが重要だと思います。

Comments