仕様変更を言い出すのは誰か？

ソフトウェア開発時の仕様変更は頭が痛い問題だ。限られた時間とリソースの中で開発を進めているのに、仕様変更に伴う追加作業は「既存工程の中で吸収する」なんて言う、いかにも日本人的な対処を余儀なくされることが多い。工程が延びても、コードを書き上げテストを行って動作確認までした成果物に再び手を入れなければならないという精神的なダメージも大きいと思う。

「お客さんの要望だから仕方ない」という理由は分かるし、「仕様変更しなければ製品が売れない」という理屈も納得できる。それは正論だ。しかし、だからと言って、何度も仕様変更を続けて、開発現場に負荷をかけるやり方が正しいとは到底思えないような気がする。モノには限度というものがあり、それを越えた仕様変更は然るべき理由と共に拒否するのが当然ではないかと思う。

そんな度重なる仕様変更に腹を立てて、仕様変更の要求が来る度にTracのチケットを起票したことがある。記載内容はもちろん、仕様変更とその理由、そして要求元であり、開発側としては仕様変更の犯人を吊るし上げるのが目的だ。

ところが、溜まったチケットを集計してみると、意外なことが分かった。

仕様変更を言い出すのはいつも同じ人
「お客さん」と一括りにしてしまうとなかなか見えてこないが、変更要望を出してくるのはいつも特定の人（部門、グループ、組織）であることが多い。対策としては、そのような要注意人物に対して重点的にレビューや説明を行う等の対策を取れば良いことになる。
仕様変更が必要になるのはいつも同じ場所
APIインターフェースの変更など、毎回それなりに理由は付いているのだが、いつも決まって同じ開発者から仕様変更の連絡が来る。それは、実際に作ってみて初めて問題の存在に気がついたためであり、場当たり的にその場しのぎの対応を続けている証拠なのだ。だから、そのような問題箇所には、熟練者に確認をしてもらう等の対策が必要になる。
仕様変更が必要になるのはいつも同じ機能
例えば、UIに対する評価は人それぞれだから、なかなか意見がまとまらない上に、開発の最終段階まで微調整が続くことが多い。だからUIの仕様変更の影響を受けにくいような設計にしておくと、影響を封じ込めるようになる。

障害と同じで、仕様変更は満遍なく存在するものではなく、意外に偏在するものなのだ。その傾向を把握するために、変更箇所の集計は効果が有ったように思う。仕様変更が多いのは仕方ないとは言え、うまく対処するための工夫を能動的に行えば、影響範囲や精神的なダメージをそれなりに上手く抑えられるのではないかと思っている。