- 0
- 0
- 4
質問
-
要件定義での意見収集方法について
質問
現システムへの改善要求を聞き出す
何が実装できるか分からないから。」と言われてしまいました。
まさににわとりと卵状態で拉致があかないですね。
ユーザ部門も いろいろ言うのが面倒なので 「と提案してくれ」と言っているだけですね。 ここは脅かしてみましょう
「この場で現状のシステムの不満を出しきってください そのなかでシステム改善できることを実装します この機会に不満がでなければ何の進展もないものと思ってください あとから不満を言われても対応できません」と言い切りましょう
会議の場で「不満を言え」と言っても言いにくいでしょうから、2週間くらいの猶予でアンケートを取るとか、現場の長と個別に会談して意見聴取するとかがいいでしょう
別のアプローチの方法としてはシステムの根幹をなす部分の変更を提案するのもいいでしょう これはユーザではなんともできないので情シスが行う必要があります
ウチは以前は自社開発でしたので、システムの根幹をなす部分の変更をいくつも行いました。時にはユーザ部門のえらいさんが全否定をした時がありましたが、その結果は現場の実情無視のシステムができて、そのえらいさんの評判が一気に落ちてしまったことがあります 反対に現場は「やっぱり情シスのいうことの方が正しかった」と理解してくれました
会社によってシステム部門に対する責任範囲が違うので何とも言えませんが
弊社の場合は業務の改善も含めて提案することを求められているため、
苦労は多いです。
システム部門は現場の方ほど業務を理解できていません。
その上、現場の方に「業務をしらない人に言われたくないよ」と思われないか
、という心配が常に頭をもたげます。
しかし、外から見る目というのは、案外見過ごしがちな問題を
見つけることができたりします。
*
もし、システム部門として業務を理解し提案することもやっていきたいと
考えられるのであれば、アンケートという形ではなく、業務ヒアリングを
始められてはいかがでしょうか？
現システムを含めたビジネスプロセスをヒアリングし、業務フローにまとめ
プロセスの改善を検討することで、新システムの要件はすっきり
（予算・工数が少なく）できると思います。
ヒアリングをしているとアイデアがいろいろ湧いてきますし、
現場からも「実はこうなってたらいいんだけどね」なんて話しを
聞けたりします。
*
逆にシステム部門は出てきた要望のみを実現すればよい、という
考え方ももちろんあると思います。現場からの要望がないのであれば
少なくとも営業部の部長の意見を聞いてみるといいと思います。
システムのリプレースをすることが決まったということはどのような
経緯でそうなったのでしょうか？何かしらの原因があったのだと思います。
まずはそこを改善すること、そして経営層の方のほしい情報がすぐに
見れるようにするなどは、経営を健全にするため必要なことだと
思います。現場だけでなく、上層部の求めるシステムというのも
検討されるといいと思いますよ。
概論ばかりになってしまいましたが、参考になれば。。。
本日、営業部門ではない部門の方とお話しする機会がありました。
その方と話して感じたのが下記の点です。
・現状のシステムをそのまま移行すれば不満はない。
・不満がないので、現場がこうしたいという想いはほぼない。
・よって、業務が楽になる機能、使い易い工夫を、
システム部門から提案する必要がある。
やはり、費用対効果を考えると便利機能を付け過ぎるのは微妙な気がしますが、新システムで色々便利になるといいなという期待だけは伝わってきました。
現在の路線のまま、提案はこちらからする方向で進めてみたいと思います。
ただ、気になるのが「システム部門として受け身になっていないか」という部分です。
現場はシステムの使い方は知っているが、何ができるかを知らないという場合には、
「システム部門から提案をするべきなのか」について、再度ご意見頂けないでしょうか。
ウチは”ハードが老朽化したため”新システムの導入を検討しましたが、ユーザ部門は「現状に不満はない、現状できていることができなくなるのは困る」という意見で、それをもとにパッケージソフトのカスタマイズを試算したら金額がウナギ登りで無理！ よって現システムをそっくり新ハードにコンバートして”費用削減””ユーザ要求満足””新ハードによる高速化””新ファームウェアによる端末近くのパソコンプリンタに出力可能”などを実現してユーザからは絶賛されました。
でも経営層のひとりからは「こんなに金をかけて前と同じシステムとは進歩がない」と酷評されました。（「”こんなに金をかけて”といわれるが前システムの１／６、パッケージソフトのカスタマイズの１／４ですし、新機能もあってユーザは大満足で．．．」と説明をしたのですが、この人は他人の意見なんか聞く人ではなく物別れに終わりました。
弊社の上層部は．．．システムから顧客情報や売れ筋情報を得るという考え方が全くなく．．．
おお！これもウチと同じです。 というか以前の経営層はＩＴがわからないなりに情シスの意見を聞いてくれていましたが、今の経営層は社内の業務改善には関心がなく、Ｍ＆Ａやら事業展開やらしか考えていません。
前述の”こんなに金をかけて”発言も ハードの老朽化ということが理解できずに「同じシステムを金をかけて作るな」と言いたかったのでしょう（もちろん稟議や役員会説明は行ってますのでハードの老朽化ということを知らないはずはないのですけど。
お役に立ちましたか？他にもたくさんの ノウハウが共有されています。
質問
いつもお世話になっております。
短期間にいくつも質問してしまい、大変恐縮です。
今回、伺いたいのが要件定義での意見収集方法についてです。
私の仕事に対する考え方が正しいか、ご意見頂きたいと考えております。
現在、弊社基幹システムのリプレースを検討しており、現在のシステムをベースにした個別開発を行うことに決定しました。
早速、要件定義の一環として、各ユーザー部門から意見を収集しようという話になりました。
計画として、ユーザー部門と打合せを行い、現システムへの改善要求を聞き出すということを考えていました。
ところが、実際に営業部門に話をしに行くと、
「まず、システム部門が営業部門の使用している機能に対して、こんな改善ができるよ！と提案してくれ。何が実装できるか分からないから。」と言われてしまいました。
ここで私が感じたのが、下記の3点です。
①現状で不満がないのならば、改善する必要がないということではないか。
結果として、費用対効果が低い機能を増やすだけではないのか。
②実装ありきではなく、不満を如何に解決するかが重要ではないか。
③上記の想いはあるものの、相手からの意見待ちというのは、
システム部門として受け身になっていないか。
上記を見て頂くと分かるとおり、ユーザー部門の意見を不満に感じながらも、不満を感じているのは受け身だからではないかと悶々としています。
ユーザー部門の幹部が私より立場が上ということもあり、
現在はユーザー部門がいうとおりに叩き台を作成する方向で話を進めています。
システム部門として、どこまでやるべきか。
皆さんはどう思われますか。ご意見よろしくお願い致します。
蛇足ですが、個人的な立場からの意見としては、
「不満に思ってそうなところを探して機能の改善提案しろ！」と言うなら最初からパッケージを選んでくれ・・と感じました。
パッケージを選ぶと業務を変えるのが云々と言われる訳ですが(笑)