エンジニアもプロダクトマネジメントを推進し、より楽しい開発を　プロダクトに関する議論を良くするための3つの方法

「他多職種のゴール」を知って手を差し伸べる

小城久美子氏：では後半の「プロダクトマネジメントをエンジニアが推進する」というところで、3つの話をしようかと思っています。

まず1つ目が「『他職種のゴール』を知って手を差し伸べる」という方法での推進の仕方です。（スライドを示して）さて、これもなかなか辛いスライドになりますが、私の過去の失敗からやってしまったことをスライドに起こしています。

相手の仕事を知らないと、例えばビジネスの人がどういうことをしているかを知らないと、急に「ダッシュボードを作ってください」と言われても、すぐに批判者になっちゃうんですよね。「あの人たちはこっちが忙しいのも知らずにあれもこれもって言ってくる」みたいなことになってしまいます。

相手のことを理解できていないと、代替案みたいなのも出せないし、相手のことがわからないからどうしても批判的なことを言う以外に何もできなくなってしまうことがあると思っています。それは「わからないから」ですが、これが広がれば広がるほど、お互いに分裂みたいなことが起きてしまうんですよね。

それが起きないためにはどうすればいいかというのは、相手のゴールを知ることだと思っています。相手が言っていることが良いことか悪いことかみたいなところを批判するんじゃなくて、他職種の人はどうしてそのゴールを目指しているのか。そのゴールは、自分が思っているプロダクトの1本の意思決定の軸と一緒だろうか。

もし一緒だったら、そのHowは違うかもしれないけれど、「エンジニアとして別のHowでもっと良くできる方法があるかもしれない」みたいなことを考えられるようになりますよね。

なので、他職種の人がどういうことをしたいのかというHowのところだけじゃなくて、ぜひWhyのところにまで興味を持って話せると、エンジニアもプロダクトマネジメントを推進できるようになるんじゃないかと思います。

「プロダクトチーム」として議論に参加する

（スライドを示して）もう1つは「『プロダクトチーム』として議論に参加する」と書きました。先ほど話したとおり、プロダクトマネジメントはプロダクトマネージャーだけがするんじゃなくて、チームみんなでやりましょうということです。プロダクトマネジメントの成果物はだいたいロードマップに現れるんです。

ロードマップの中では、「どんな状態を目指したい」みたいなものがあって「その状態って数字でいうとこうだよね」みたいなのが定義されていて、「そのために機能はこうあるべきだよね」という（ことを書く）ような作り方になっているはずです。

もしかしたらロードマップ上ではそれが表されていないかもしれないんですが、ロードマップを作っている人に聞くと、「どの状態か」みたいなものがたぶん出てくると思います。まず初めの一歩としては、目指す状態、「こんな状態を作りたい」「この指標を上げたい」というのに対して、「今作っている機能はエンジニア目線で作ったとしても同じような仕様書になるだろうか」「他にこんなやり方があるんじゃないか」みたいなところの提案をするのが、一番小さな参加の仕方かなと思います。

「目指す状態、直近の目指す状態に対してエンジニアとして何ができるだろう」みたいなところを、プロダクトチームとして議論に参加する。少しそれに慣れてきたら、ロードマップを作るような全体化にも入っていけるんじゃないかと思います。

「エンジニア」として議論に参加する

最後です。（スライドを示して）先ほどは「『プロダクトチーム』として議論に参加する」と書いていましたが、（今度は）「『エンジニア』として議論に参加する」と書きました。

はじめに見たUX、Tech、ビジネスという、「プロダクトマネージャーはここだよ」というスライドですが、それぞれの円がどんどん離れていかないように、それぞれの円をどんどん重ねていくことが、プロダクトとして良い意思決定をするために大事だと思っています。

なので、プロダクトマネージャーだけが中心にいるんじゃなくて、TechとUXの重なりの部分はTechとUXの人でも進めちゃえばいいと思うんですよ。「『ここでこういうことがあるといいよね』というものをロードマップに入れましょう」とプロダクトマネージャーと議論するといいと思います。

ここはTechとビジネスで話せばいいと思います。具体的には、例えばダッシュボード1つ作るにしても、そのためにどういうデータ設計がいいかみたいなこと、ビジネスの人が何を求めているのかを、エンジニアから歩み寄って話していけるとすごく喜ばれると思います。

UXのところ、例えばCSみたいなところで、「Techの力を使うと、Techたちでこういうことができるようになるよ」みたいな話をどんどんしていって、エンジニアが離れていかない。近いところにいればいるほど、すごく効率が良いプロダクト開発ができるんじゃないかなと思っています。

誰かが一歩を踏み出すのを待つのではなく、自分から歩み寄る

長くなりましたが、私の発表は以上になるので、最後にまとめだけを話そうと思っています。

（スライドを示して）「プロダクトマネジメント」といった時に、この4つの階層でプロダクトを捉えてくださいねという話をしました。このWhatやHowは良さの定義が違うと「全部良い」となってしまって、それがコンタミ（コンタミネーション）すると良くないものが生まれてしまうので、ちゃんとFitというところをしっかり通して整合していきましょう。

先ほど「FitとRefineというのは関係する概念ですね」みたいなものをZoomのチャットでもらっていましたが、まさにそのとおりだと思っています。「このFitをより強くするためにRefineをする」みたいな考え方もしてもらえるとうれしいなと思っています。

そして、プロダクトというのはHowのところやWhatのところだけじゃなくて、Coreから含めて最終的にどんな世界観を作りたいのかというのをUIまでに反映させていく。仮説の連鎖をしっかりと見据えて考えてもらえるとうれしいなと思っています。

そのためにはプロダクトマネージャーという専門職の人だけがプロダクトマネジメントをするのではなくて、エンジニアの方、デザイナーの方、ビジネスの方、みんなでプロダクトマネジメントをするチームになってほしいと思います。

それを誰かが一歩を踏み出すのを待つという姿勢ではなくて、エンジニアの方からゴリゴリ、ガリガリと「こういうふうにプロダクトマネジメントをしていこう！」と言ってもらえると、私はPMとしてすごく幸せだなと思うし、過去の自分がモヤモヤとしていたところもそういう動きがもしできていたらもうちょっと楽しく開発できていたんじゃないかなと反省しています。

というところで、今日の私の発表は以上としたいと思います。私は@ozyozyoというアカウントでプロダクトマネジメント系の発信をしているので、もしよければフォローなどよろしくお願いします。今日は金曜日の夜に参加いただき、ありがとうございました。