システム開発プロジェクトでは、仕様変更は程度の差はあれどあるものです。
その仕様変更決定までの過程によっては、(SIerも含めた)プロジェクト関係者の納得感のある/なしが大きく変わり、それはアウトプットの質まで左右することがあります。
＃「モチベーションが下がる」ってやつです。
仕様の検討/決定をSIer(自分達)とお客様情報システム部と行っているとします。
この情報システム部はお客様エンドユーザから要望をヒアリングし、(SIerと一緒に)仕様に落とし込むのが主なタスクとします。
その仕様確定後に「エンドユーザからこういう要望が出たので変えてください」と、あっさりと仕様変更を出されるとゲンナリしてしまいます。
＃これがモチベーションが下がる原因です。
最初に書いたように仕様変更自体が悪いわけではなく、その過程がポイントです。
(SIerと情報システム部が)決めた仕様も(サイコロを振って決めた適当なモンでなく)、いくつもの案のメリット/デメリットや、プロジェクトの目的に沿っているか？等、様々な側面を少なくない工数、期間を使って検討して決定したわけです。
＃もちろんエンドユーザへのヒアリングも含んでいます。
ですので、その仕様変更を要求してきたエンドユーザに対し、現状の仕様となった背景や理由を説明して…
1：「それでもするのか？」という問いかけ
2：「(いったん決めた)自分の判断を覆してまでする意味があるのか？」をジャッジ
…をした上で、答えて欲しいものです。
そこまで考えていない…ひどい時には、思いつきで言っている…エンドユーザに限って、自分達((SIerと情報システム部)がその仕様変更に対して、QCDに対する影響、メリット/デメリット、他の仕様との整合性等を検討し、少しでもネガティブな要素が含まれる回答…例えば「OKですが、工数が1人日増加します」…をすると理不尽に怒り出したりします。
こういうことが繰り返されると「何いうても、すぐに根拠のない仕様変更されるし…」という気持ちになり、アウトプットの質が下がっていくと思います。
逆に「なぜその仕様変更が必要なのか？」をキチッと関係者で共有でき、落とし込むことができると「それなら、こちらの仕様もこうなるのでは？」「(その理由であれば)こちらの仕様がより良いのでは？」と自分達も積極的な提案、フィードバックを行い、プロジェクトの目的をより高いレベルで達成するアクションを取ると思います。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo credit: Eric Fischer via Visualhunt.com / CC BY
コメント