社内管理ツールを業務で使っている部門から、「この画面を ◯◯_id で検索できるようにしてもらえませんか」という要望が届いた。
それに対して、同僚のエンジニアが「全然できるんですけど、どういう業務か教えてもらえますか」と聞いていた。とてもよいなと思ったので雑にまとめておきたい。
ツールを使った業務に慣れている人ほど、「今のフロー/機能に沿った形でここがこうなるともっと楽になるのに」といった発想で "解決案" を考えてしまう。それ自体は決して悪いことではないし、そういう要望を開発チームがもらうのは常に歓迎すべきことである。
一方で、開発チーム側はその要望の裏にある "業務" を正しく理解しなければならない。仮にすぐに実装できてしまうレベルの話だとしても、そのまま飛びついてしまってはいけない。
先のid検索要望の例でいうと、「idで検索して何をしたいか」が重要。もしかしたら、idで検索した結果ヒットする件数を他のユーザー画面に表示するだけで業務が楽になるかもしれない。もしそうだとすると、検索機能をつけても実はいちいち検索すること自体が面倒な手間になってしまう。
「いつidで検索して、どういう内容を知りたくて、それを業務上どのように取り扱うか」といった内容を正確に理解しなければならない。伝えてもらった解決案の内容ではなく、"業務" を理解するのである。業務を正しく理解しなければ、解決案としての要望がどのくらい正しいものなのかも評価できない。
業務を深ぼって聞いてみると、「そもそも業務上そのフローの一部自体が不要だよね」という話になることもある。機能を作らずよりよい形で改善できるかもしれない。
目の前で困っている人がいて、自分がそれを改善できる状況にあるとシュッと相手を助けてあげたくなってしまう。その感覚は素晴らしいエネルギー源だし、だからこそ自分は「開発チームは実際にサービスを使う人の声を"直接"たくさん聞くほうがよい」と考えている。
解決策を考えるのは楽しいし、ある種の中毒性がある。それで近くの誰かが喜んでくれるのだから、飛びつきたくもなる。その感覚は保ちつつ、グッと堪えて機能要望自体ではなくその裏にある "業務の困りごと" を聞いて理解すること。結果的に同じ機能要望の解決策に帰着するとしても、そのプロセスを経ることがとても大事。
一点気をつけるべきなのは、「要望の裏側にある業務の困りごとを皆が明快に伝えられるとは思わないこと」である。もちろん伝える側にも一定求めたいスキルではあるが、うまく聞き出して理解するのは要望を受けた側の責務くらいに捉えておいたほうがいい。
当然ながら、「要望はいらないんで業務おしえてください」みたいな表現で接しないほうがいい。"話すとめんどくさい人" と認識されて要望すら伝えてもらいにくくなっては本末転倒である。業務を深ぼって聞いていく時に、「そもそも」という言葉を多用しすぎると攻撃的に感じて萎縮してしまう人もいる。
こういったコミュニケーションの取り方は相手との関係性も影響するし正解はないが、「要望ありがとうございます！」のように最初にお礼を言ったり、「もしかしたらもっとよい対応方法があるかもしれないので〜」といった枕詞をつけたり、相手がテキストにおこす負荷を減らすために「10分くらいZoom/Haddleで背景教えてもらえますか :pray:」とお願いしてみたり、相手に寄り添って考えていきたい姿勢が伝わりやすい言葉の引き出しを増やしていくといいかもしれない。
書いてみて思ったが、こういう話は BtoB SaaS のフロントに立ってユーザーと接しているような人は日々当たり前にやっている気はする。
自分もついついそのまま要望を鵜呑みにして飛びついてしまうことがあるが、同僚がちゃんと相手の業務を理解しようとしているのがとてもよかった。
要望を伝える側もその背景を知る側も、相手への敬意を忘れずに。そして、次の曲が始まるのです。
