こんにちは！

PM1年目（社会人としては4年目）として、日々大事だな〜とか学んだな〜とかみたいなことを綴ってます。

前回の記事はこちら↓

＊＊＊＊＊

今回は、施策や機能改善の背景や経緯を伝えることの大切さについてです。

誰に伝えるのって部分なのですが、ビジネスサイドやカスタマーサポートの人も大事ですが特にデザイナーやエンジニアといった開発メンバーに対しては伝えすぎかもぐらいに伝えた方がいいと思います。

理由について述べていきたいと思います。

理由その1.なぜその施策をやるのかを知りたい人もいる

これは以前エンジニアをしていた時の私でした。

この機能を作ってと持ってこられたりすると、何でこの機能を作るんだろう、これを実装することによって何が解決できたり、どんなインパクトが与えられるんだろうと思っていて、よく聞いていました。

個人的にビジネスインパクトもきちんと伝えるといいなと思っています。

実際にそう思う人が全員とは限らないかもですが、そこのモヤモヤが残るぐらいであれば、きちんと言語化して残しておく、伝えるということは大事だと思います。

理由その2. なぜやるのかを伝えることができないのであれば、やる意味はないかもしれない

なぜその施策をやるのか、なぜその機能改善をやるのか、それを言語化できず伝えることができないのであれば、そこに問題も課題もないのかもしれないし、そうなるとその実装や修正自体やる意味はないかもしれません。

エンジニアさんとデザイナーさんに手を動かしてもらうのは、すごく貴重なリソースであり、やる意味がないものをやってもらうのであれば、もっと他の有効なことに使えたかもしれないと思います。

この文言追加をしたい理由として、ユーザーにとって勘違いする人もいるからその勘違いを減らすためだよ〜と言われれば、あ、それはやる必要があるなとなります。

理由その3. 他に新たな解決策が出てくる場合がある

こういう課題を解決したいとなった時に、機能ベースで依頼してしまうときも多いです。

けれども、こういう課題があって、解決策がいくつかあるといった時に、どれが技術的にやりやすいか・デザイン的に一番UXがいいかなど、デザイナーさんやエンジニアさんに意見を聞くことで、一番少ない工数で一番効果のある解決案を一緒に考えることもできます。

特に自分の中ではこの解決策がいいと思うとPMとしても、調査の上で意見を持っておくことは大事だと思うのですが、三人寄れば文殊の知恵という言葉通り、新しい解決案が生まれる可能性があります。

以上の理由から、なぜその施策をやるのか、なぜそのプロジェクトをやるのか、経緯を伝えることは大事だと思う理由でした。

もし参考になったという方がいたら、いいねやシェアをしてもらえると書いた本人は大喜びします。

次回は「（仮）PMはエンジニアリング・プログラミングできた方がいいのかについて」についてお話しできればと思ってます。