仕様変更は開発プロジェクトを困難にする最大の要因

昨今のソフトウェア開発業界は、「仕様変更に強いシステムを作る」、「いかにして仕様変更に応じられるようにするか」というような考え方が主流だが、本当にそれでいいのだろうか。

仕様変更に耐えられるシステムというのは、ある意味予測と臨機応変な対応が求められるわけだが、誰もが素早く頭を切り替えられるわけではない。コンピュータに対するいろいろな技術も求められるのに、そこに臨機応変な対応が出来る人となると、極端に少なくなってしまう。

人が足りない、技術者が足りない、プロジェクトマネージャーが足りないというような状況を生み出しているのは、何かプロセスが間違っているのではないか。IT業界は成熟産業ではないというが、大人数で動いているプロジェクトに対して、途中で勝手にゴールを変えてしまうような業界は他にあるのか。

なぜ仕様変更をするのかと考えた時に、技術的に無理なこと、時間的に無理なことを出来ますと言ってしまってあとで仕様を削る、ということがあるために、顧客の無茶な別の要求を飲まざるを得ないケースというのが往々にしてある。見積対象の機能を削除するのだから、別の機能を入れる、いわゆるバーター（交換）取引である。

他には、紙やHTMLで見た時には、なんとなくいいかなと思っていたけど、実際に触ってみると全然駄目ということに気付いたので、画面インターフェースをがっさり作り直しというケースである。クライアント系、WEB系のアプリケーションだと実際によくある。

また、同業他社を意識する顧客の場合は、同業他社が始めたサービスと似たような機能を入れてくれ、と開発途中にねじ込んでくるケースもある。

どのケースも、納期と金額を変えずに、機能だけどうにか追加してくれというのが前提なわけだが、それはお互いの経営陣がリスクを負わずに、開発チームにだけ負担を強いているように思う。予測できないのは開発チームだけが悪いのではなくて、双方の会社全体で対応すべきであるのではないだろうか。

最初のケースでは、削除した分を他の機能で代替するのではなくて、金額の削減も視野に入れるべきである。もっともこのケースについては開発側で対応可能な部分なので、出来るだけ早いうちに未知の機能に対するリスクを潰しておかなければならない。

２番目のケースはGUIを持つアプリケーション開発におけるリスクの１つと初めから認識した上で、重点的に操作感についての対応を取る必要がある。最後の最後で違うと言われないようにしなければならない。

最後のケースは、明らかに横槍である。その機能を入れないと商売にならないと言われても、中途半端なタイミングでの機能追加はプロジェクト全体の破綻に繋がる。プロジェクトを一旦中止して、それまでの作業分の違約金を払って、新たにプロジェクトを組み直すのが理想であるが、契約書にはたぶんそんなことは書いてないので、だらだら今のプロジェクトが続くのが現状である。

商売はタイミングが重要であり、タイミングを外すと利益が出なくなるのは、ビジネスの世界では良くある話だが、だからといってソフトウェア開発について、同業他社の動きに合わせて、仕様を途中で変えたり、納期を繰り上げたりするのは、顧客側のリスクを開発側に転化していることに他ならない。

開発側も出来ることと出来ないことを見定めた上で、無理なものは無理と言わないと、開発チームがえらい人の手の平で右往左往するばかりである。

そういう事態に対して金で解決するために、本来は契約書があるはずなんだけれども、想定外の事態に対しては、「本契約に定めない事項および疑義の生じた事項については、甲・乙双方が誠意をもって協議の上決定するものとする。」としか書いてないのだ。

予測できる仕様変更の可能性については、ある程度契約書に記載できるのではないかなと思うので、理不尽な要求については事前に防衛策を講じて契約書に記載しておくのがいいと思う。もちろん開発側の責務はきちんと果たした上での話だが。

顧客は、自分の言った事がそのままソフトウェアとなって動いているのを見ると、夢が膨らむのである。いろいろ言いたくなるのだ。双方がプロとして自分の責任を果たすようにしようと思えば、最初に契約書レベルで取り決めする以外になさそうである。ビジネスの世界は性善説だけでは成り立たない。