システム開発の要件定義をスムーズに進めるちょっと【邪道な方法】
「開発スタートしてから仕様変更されるのホント困るよな…」
「上流工程が上手くいくと、大抵その後もスムーズにいくのにな…」
要件定義って難しいですよね、「出来た!」と思っても、足りない部分が後で出てきたり、そもそも顧客になかなか納得してもらえないことも多々あります。
要件がまとまらないうちに日にちだけはどんどん過ぎて、開発に使えるはずだった日程が侵食されて、納期直前になってハードワークで乗り切る、そんなこともよくありますね。
いろいろ試行錯誤した所、意外なことに気を付けたら、要件定義がスムーズに進むようになりました。正攻法からちょっと邪道なものまであります。
くわしく紹介します。
後で仕様変更はあるものと考えて早めに進める
私達は全知全能の神でも未来を予言できる超能力者でもありません。
どんなにしっかりと議論しても、後で「これが足りない」とか「こう変えてほしい」ということはあり得ます。
よって後で仕様変更があることを織り込んで、早く工程を進めます。
顧客にも「細かい部分は後で多少変わるかもしれませんが、ひとまずこれで進めていきましょう!」といえば、納得してくれます。
というのも顧客の立場からしても、全ての要件が出せたか不安なので「後で変えられる」と言ってもらえると安心します。
と言っても、「後でいくらでも変えられるんだな」と勘違いされても困るので、「多少」という表現をしておきます。
顧客の立場を理解すれば、アプローチ方法が分かる
あなたの顧客はどの部署に所属していますか?
- 業務を実際に担当している部門なのか
- 情報システム部なのか
によって、顧客心理は大きく変わります。
業務を実際に担当している部門の場合、そのシステムを導入することで業務が楽になることを重視します。また導入が簡単であることも重視するはずです。
ですから、
- このシステムによってどれほど業務が楽になるか
- 操作が簡単にできること
等を、きちんと説明することが大切です。
一方、情報システム部は、
- システムの運用コスト
- 障害が起きにくいか
等を重視します。
どんなに素晴らしい機能を持ったシステムでも運用の手間が大きかったり、障害が頻繁に発生するシステムでは、情報システム部の負担が大きく、業務部門からも文句を言われることになってしまうからです。
なので、誰と要件定義をするかによって、重視すべきポイントを変えるとスムーズに要件がまとまります。
スムーズに要件定義フェーズを完結させることで後工程の期間をきちんと確保し、仕様変更に対応する時間を作れます。
完璧な要件定義をしようとしてずるずると日数を使うよりも、ずっと現実的に機能します。
性格のゆがんだ人には要注意
たまにですが、顧客の中に変な人がいる場合がいます。文句を言うのが仕事だと言わんばかりに、批判ばかりして、プロジェクトを停滞させる人です。
こういう人は自分が顧客だという立場をいいことに、日頃のストレスを開発チームにぶつけてきます。
こういう人が相手だと、いくら顧客の立場を考えたアプローチをしても話はまとまりません。
プロジェクトを停滞させるのが目的の人なんですから、スムーズに進めるよう工夫しても必ずいちゃもんをつけてきます。
こんな場合どうすればいいかというと…、
転職します!!!
「おいっ?全然解決になってないじゃん?」と思われたかもしれませんが、これしか解決方法はありません。これこそが唯一ベストな解決方法なんです。
他人を変えることは難しい、というかほぼ不可能なので、いくら努力しても無駄です。努力のしようがない環境からは離脱するのが懸命です。
いい会社はちゃんとある!
いい会社、いい職場、いいプロジェクトって探せばちゃんとあります。有名な企業じゃなくても、ちゃんと業績が良くて、職場の雰囲気も良くて、合理的な仕事の仕方をしている会社はたくさんあります。
私も以前は大手志向でしたが、いろいろな規模・業種の会社で仕事をすることで、大手や有名企業じゃなくてもいい会社があることがわかり、規模や有名度にこだわらなくなりました。
すると、自分に合った職場に巡り会えるようになったんです。ですから、「努力のしようがないな」という状況であれば、転職も考えてみてください!