現場からのシステム化要望の伝え方

こんばんは。
コウスケです。

事情によりプロジェクトを抜けて

今は・・・フリーです(笑)
 

*******************************

歌を出しています。

「心の故郷」という曲です

各音楽サイトより配信中です！

詳しくはこちら

*******************************

現場で使っているシステムは
使い続けるうちに
どんどん新しい要望が出てきます。


ある箇所が使いづらいとか
もっと機能を追加してほしいとか
開発側への要望は尽きません。


開発側はその内容を確認して
予算の範囲内で優先順位をつけながら
対応していきます。


この優先順位は
内容の重要度や緊急度、
開発側の稼働量や予算額など

から決まると思いますが、
現場の思いと開発側の思いが
なかなか合わないことが

あるかもしれません。


現場はAの改善を優先してほしいのに
開発側ではBから着手する
というようなこともあり得そうです。


こんな時は
現場からの意見の伝え方

を工夫する方がいいかもしれません。


現場目線の解決策を単純に伝えるだけでは
開発側としては
・現場がそう思うならそれで良いだろう
とか
・その程度なら後回しで良さそう
などと、
現場が本当に優先して

解決したい内容を
開発側がしっかりと

理解し切れない
可能性があります。


僕は
現場から開発側へ要望を伝える時は
・困っていることを相談する
・解決策ではなく解決の方向性を

　伝える
というスタンスで行く方が結果的に
現場が優先して対応してほしい内容で
良い解決策が出るような気がします。


「困っていること」は、
・いつ
・どんな作業の時に
・どんなことが起こったか
・発生頻度や発生場所
・解決できないと困ること
・今暫定的にやっている対応策
などを伝えるべきだと思います。


これを伝えないと
なぜ現場が優先して

対応してほしいと
思っているかが
開発側に臨場感を持って

伝わりません。


そして
「解決策ではなく解決の方向性を伝える」
というのは例えば、
「●●ボタンをつけてほしい」
などといきなり言うのではなく
「○○なことを回避したいのだが
どんな対応策はあるか」
という形で伝えるようなイメージです。


解決策を限定するよりも
制約条件を提示する方が
解決策に広がりが出てくる

気がします。


これらのことで
全てが上手く行く訳ではないですが、
現場の状況を開発側へ
どれだけ理解してもらえるかは
結構重要だと思います。