「PdMはWhyをやれ！」ところでどっからどこまでがWhy・What・Howなの？

そりゃあそうだろ、という方も多いのかもしれません。
ライフイズテックPdMのみことです。

前職でスクラムマスターの方に、「アジャイル開発ではPdMはWhyだけやればいいんだよ〜」と言われていましたが、当時から「Whyって何？」と思っていました。

わからないので周りを参考にしようかなと見渡してみるとPdMはそれぞれがたどってきたキャリアパスも異なるため、

• 自分でデザインまでの人

• 自分でワイヤー書くところまでの人

• 自分で機能を決めるまでの人

• バックログに課題を書くまでの人

などいろいろいて、わからん！となっていました。

で、転職を経て逆にシャープになって自分なりに納得ができるようになったので、残しておきます。
駆け出しPdMの方の参考になれば幸いです。

Why・What・Howとは

一言まとめ

一言でまとめるとこうです。

• Why：あるユーザーが、どんな課題を持っているかを定量・定性から分析し、最も解決すべき課題を決めるところまで

• What：課題を解決する機能を決め、UI/UXをデザインをするところまで

• How：デザインされた機能を、どんな技術でどのようなロジックで開発するか

私がよくやってしまっていたミスとしては、

• 機能まで決めてしまっていた（Whatまで決めてた）

• 実現できるかどうかがわからないので、課題として提案しなかった（Howを考えて諦めてた）

具体例でいうとどんなの？

例えば、もし自分が決済アプリの機能を担当しているとしましょう。

■Why

高齢の方々が、初期セットアップの時点で離脱していることが多いことをログから特定し、実際の高齢のユーザー4-5人程度にインタビューしたところ、「説明で横文字を使っているのがわからなくて諦めてしまう」ことがわかった。これを解決しようと決める。

■What

課題を解決するために、機能のアイディアを出す。
案① とりあえず横文字を使わないで説明を書く
案② 横文字を図式化して理解できるようにする
案③ 必要事項だけを記入したらもっと簡単に初期セットアップができるように機能をアップデートする
など、解決案をいろいろ出す。
そして
・ユーザーの課題が正しく解決できるのか
・コストが掛かりすぎないか
・他の機能の良さを消さないか
・他のユーザーにとっても良いものか
などを、検討し案を決定する。ここではPdMと相談して案②に決めた。
そして、案②について実際に画面イメージを作成し、細かい仕様についても検討してfigma内にコメントを入れてエンジニアに渡す。

■How

もともと初期セットアップは、文字だけで説明する予定で開発がされていたが、画像を入れることになった。
暫定対応としてねじ込むように開発をするか、今後もこういった拡張が発生する余地を残して開発をするかなどの検討事項を洗い出し、デザイナーと相談して決める。
そして開発を進める。

本当にPdMがやるべきことはWhyだけ？

では、WhyとWhatとHowがわかったところで、PdMがやるべきことはなんでしょうか。本当にWhyだけでいいのでしょうか。

上記の例にも出てきたように、PdMはWhyだけではなくWhatとHowにも関わります。
ただし、それは「決める」ことについてであり、「考えること」ではないと思っています。

考えることとしてはほとんどないですが、強いていえば1点「ログの仕込み方」くらいですかね。

ただし前提がある！

上記をうまく回すために必要な力として、以下がとっても大事です。

• ユーザーについて知っていること

• ユーザーについて知らないことを探索できること

これは、PdMは絶対に持っているべき力ではありますが、理想を言えばデザイナーやエンジニアも持っているべき力で、持っている人が多いほど精度の高いプロダクトが作っていけると感じています

以上〜。
こんなまとめを今後もやっていこう。