モバイルファクトリー Advent Calendar 2018、13日目担当のhtk291です。
昨日は @return520 さんの PerlでTwitterのPremium Search APIを叩く でした。
はじめに
2018年初あたりから社内のプロダクトには1byteもコードを書いていませんが、 コードを書く以外のエンジニアのキャリアとしてプロダクトマネージャに興味をもち、社内外で名乗っています。
本日は新規プロダクトにプロダクトマネージャとして関わった際の気付き、学びについてお話をします。
論理よりも信頼と共感
「人」に関する学び
ロゴスだけじゃなくて、エトスとパトスも大事な要素だよ
by アリストテレス
チームに物事を共有するときには論理的な正しさも必要ですが、それが共感できるか、しっかりと意義や目的が共有されて理解されているかが鍵となります。
例えばよくある話として、彫刻家に「こんな像を彫ってほしい。それが終わったら次はこんな像をお願い」と説明するよりも、「私達はこの街に世界一の大聖堂を作ろうとしている。あなたにはファサード部分の彫刻を彫ってほしい。非常に重要な仕事であなたにしかお願いできない」というように、我々チームは何を作ろうとして、その仕事にはどんな意義があるのか、任される仕事はどんな意味があるのかを説明し、共感を得ることが重要です。
実際にチームでは私の説明不足により、メンバーそれぞれで思い描くゴールが異なってしまっていたり、この作業に意味はあるのか等の疑問を生んでしまうこととなりました。
そのような疑問が生じる前に、まずは意義や目的を伝えることで共感を得て、同じゴールに向かおうとしていることを確認してから詳細な仕様の説明に入ることが大事です。
ぼくのかんがえたさいきょうのあぷり
「製品」に関する学び
製品開発というのは、自分が思いついた最新のアイデアや 最高のアイデアを試す場ではないことを忘れてはならない
『INSPIRED: 顧客の心を捉える製品の創り方』
私もそうでしたが、経験の浅いプロジェクトマネージャやチームは、自分達が最もユーザの気持ちを理解していて、自分達が定義したこの仕様なら必ず売れる！といった錯覚をしてしまいがちです。
開発現場で定義した仕様が、本当にターゲットの望むものかどうか。現場が定義するものは仮説でしかありません。早期に検証して、ターゲットと思われるユーザからのフィードバックを得ることが思いもよらないユーザの声を聞けるチャンスとなります。
「開発中のプロダクトを安易に外部に公開できない」という声が聞こえてきそうですが、チームからちょっと離れたところに居るターゲットにヒアリングするだけでも非常に多くのフィードバックを得られることがあります。
社内にいる別チームの方に協力をお願いするだけでも製品にとって有意義な情報となるでしょう。
課題の発見と解決アプローチの選択
「プロセス」に関する学び
それってなんの課題を解決するための機能なの？
by 弊社シニアPdM
課題のないところに解決策はありません。
ですが、プロダクトマネージャや開発チームは「良さそうな機能」を思いつくと製品に取り入れたくなるものです。
そんな場合は、一旦立ち止まって考えることが大事です。
その機能はユーザのどんな課題を解決するための機能ですか？
これが思いつかないのであれば、きっとその機能は「良さそう」なだけであって使われない機能になってしまうでしょう。
私は「良さそう」というだけで思いついた機能を入れたいと思ってしまい、当時のシニアPdMの方から「何を解決する機能なの？その解決になぜこの手段を選択したの？」と何度も問われ考え直す経験をしました。
まとめ
エンジニアからプロダクトマネージャに立場が変わり、次のような気付きがありました。
- チームには目的や意義を伝える
- ユーザの声を聞き、独りよがりにならない
- 解決したい課題のない機能は、必要とされない
現在、コードを書くという業務からは離れていますが、私はプロダクトマネージャとなる選択をして間違っていなかったと考えています。
明日は卒業生の mattak さんです！！
