調整段階で、仕様をフィックスしたと考えていたにもかかわらず、ユーザと接する現場レベルで頻繁に仕様変更が発生する。こうした悩みを抱えるＳＩベンダーは多いはずだ。
調整や設計の段階でフィックスした仕様が、テストや導入段階で大幅に変更になれば、当然コストや納期、品質を大きく脅かす。だから我々システム屋としては導入前の調整が如何に大切かと云う事を調整を担当する企業や担当者にいつも伝えているのだが、それでも現場レベルで見渡して「調整が完璧であった」と思える現場というのは皆無に近い。
発生しうる状況を全て網羅した調整というのは無理があるし、長期に渡るプロジェクトについて状況の変化に応じてユーザからの要求が変わる事はむしろ当然の事である。「そういう仕様ですから。」と要求をシャットダウンする事は簡単であるし、管理者にとっては理想の姿かもしれないが、もしその作られるプロダクツの存在価値を問われるような要求を放置したとしたら、サービスの品質としては到底お客様のニーズに応えたものを提供できているとは云いづらいものになる。
一方で、じつはお客様の要望を全て鵜呑みにする事も実は簡単なのである。しかし事前調整から大きくかけ離れた仕様変更を全て受け入れてしまえば、別の仕様変更を招いたり、しわ寄せが下流で下請けしている会社に直撃したりする事になる。
現実のところ、あきらかに常識的に考えて恥ずかしいと感じる仕様や調整についてはフィックス後であってもベンダー側の調整で変更をかけに行くべきだと現場レベルでも感じているし、一人二人のユーザがごねているだけで、全ての作業者がオールストップするような調整しか出来ないベンダーでは、関係者もたまらないだろうし、何よりもユーザ自身も不安になるのではないだろうか。
時は３月。多くのプロジェクトが納期を迎える時期であり、我々の仕事の正念場でもある。我々としては、ある程度振り回されるのは当然覚悟の上である。しかし、どんなに忙しくなろうとも品質をあまり下げたくないと思うのが、現場サイドで考える我々の正直な気持ちであるのだ。
当社のクライアントに求める事としては、現場サイドですら恥ずかしいと思う仕様であれば、納期が厳しくとも変更に応じてあげるべきであると思うし、この時期になってもユーザに振り回されてスケジューリングでエンドの見えない作業であれば、いずれ明らかになる納期が守れ無くなった責任を下請や作業員の品質に転化するのだけはやめてほしいと思う。