プロダクトマネジメントって？ ふんわり入門

この記事は [ラクス Advent Calendar 2019](https://qiita.com/advent-calendar/2019/rakus) の3日目の記事です。
昨日は@EichiSandenの[チームでスクラムをはじめた1年のふりかえり](https://qiita.com/EichiSanden/items/f63bcae3556cf56299bb) でした。

スクラムの話ですので、ちょろっと私の話とも絡むところがあったりなかったり。

# はじめに

こんにちは。ラクスのみかたと言います。
普段は、サービスの運用周り担当しており、平たく言うところのSREエンジニアとして仕事をしています。
具体的には、アプリのデリバリ、トラブルの対応、自動化、問題解決のアドバイザという形で開発内に限らず、サービスの運用に関わる事は、何でもやります。

今日はCI/CDの話を・・・ではなく、プロダクトマネジメントについて書いてみたいと思います。

# なぜプロダクトマネジメント？

そもそも、なんでプロダクトマネジメントに興味をもあったのかと言うと、
先に書いたように普段の仕事の関係もあってエンジニア以外のメンバーと接する機会も多いです。
そうなるとユーザーの方の声を聞く機会が開発をメインにしているメンバーよりも多かったりします。

そんな環境だったこともあり、ふつふつとユーザーに取ってもっと価値を高めるにはどうしたらいいんだろ？
という考えが芽生え、プロダクト全体としての価値を挙げねばいけない、そのためにもプロダクト全体をマネジメントする、方法や考え方を学ぼうとなったわけです。

そんなこんなで1年間色々と本を読んだり、勉強会に参加したりですが、
奥が深く簡単には説明が出来ないので、プロダクトマネジメントってなんだろ？自分たちの仕事って関係しているの？
という方の最初の触りとして気楽に読んで頂ければと思います。

# プロダクトの範囲

プロダクトと言った時にどのこまでを範囲と捉えますか？
気になったので、実際に社内で雑談がてら聴いてみましたが、製品そのものだと考えている方が多いようでした。

私は、製品、インフラ、プロモーション、セールス、サポート、お客様に関わるもの全てがプロダクトの範囲と考えています。

クラウドサービスの場合、パッケージとは違い、手元に何かが残るわけではありません。
ユーザーはサービスを利用することで得られる経験に対価を払っています。
よって、経験を作り出すものがプロダクトであり、その範囲は単純に製品そのものでは無いと思います。

- サービスが安定していなくてつながらない・・・
- ぜんぜんサポートしてくれない・・・
- 提案してくれるがぜんぜん問題解決にならない・・・

こういう感じだと、例え製品そのものが良くても、長くお付き合いしたいと私なら思えません。
お客様に良い経験をしてもらうには製品だけでは成り立たないということです。

# プロダクトの体制

実際にプロダクトを運営する体制としては、全体を統括するプロダクトマネージャーと専門チームで構成されます。
プロダクトマネージャーの仕事は多義に渡り、プロダクトがうまく回るようにたくさんの関係者と調整をする必要があります。
ここで勘違いしてはいけないのが、プロダクトマネージャーは決定権を持ちますが偉いわけではありません。
あくまで全体の中でその役割をになっているだけです。

![pm.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/150334/df3597ec-b8a8-c33b-0bdf-48ec42f5c129.png)
[プロダクトマネージャーの役割や仕事、求められるスキルまとめ](https://pm-notes.com/entry/2018/07/15/005521)

プロダクトマネージャーが最終的な決断を下しますが、
そのために必要な情報、選べる選択肢まで考える必要はありません。
それを提示するのは各専門チームの責務であり、これを放棄してしまうと
プロダクトマネージャーへの責任の押しつけになってしまいます。
※実際この悩みは色々なところで耳にしました

私はプロダクトマネージャーはあくまでHUBだと思います。
各チームは自立して責任範疇の業務を遂行し、それらを繋ぐためにマネジメントをするということです。

# プロダクトトライアングル

プロダクトマネジメントの説明でよく使われるもので、プロダクト全体の関係性を表しています。
これでを使ってもう少し実際の現場とプロダクトの関係を噛み砕いて見てみたいと思います。

![pillars_template_roles.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/150334/1956ba3c-8d3f-ceb9-2119-9074aa6bb495.png)
[【翻訳】プロダクトマネジメントトライアングル](https://ninjinkun.hatenablog.com/entry/the-product-management-triangle-ja)

開発、ビジネス、ユーザがあり、その間をプロダクトが繋いでいるのが分かります。
イメージは湧くと思いますが、ちょっと細かすぎるので、キレイに纏めてくださっているものをお借りします。

![trianble.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/150334/4ad96534-273d-fb29-8320-64cf241650b1.png)
[プロダクトマネジメントトライアングルと各社の PM の職責と JD](https://medium.com/@tumada/product-management-triangle-job-description-d18d1855ef65)

だいぶすっきりしていますし、実務に重ねてイメージしやすくなったのではないかと思います。

- 開発者と顧客を繋ぐのは（カスタマーサポート、デザイナ）
 - カスタマー/技術サポート
 - データ分析
 - デザイン

- 顧客とビジネスを繋ぐのは（営業、マーケティング）
 - マーケティング
 - パートナーシップ
 - ビジネスデベロップメント

- 開発者とビジネスを繋ぐのは（開発、SRE）
 - プロジェクトマネジメント
 - 社内外調整/資源獲得
 - プロダクト仕様

ということになります。
で、これらが円滑に回るようにするのがプロダクトマネージャーということになります。

先の話とも重複しますが、専門的な事は各チームに任せれば良いと思います。
それぞれで役割分担をして、全体で見て正しく機能していれば良いのです。

# まとめ
ざざっとプロダクトの全体像とそのマネジメントをする立場について説明をしてみました。
本当に初歩も初歩でここから実際に分析の手法だったり、組織論だったりとあるのですが、
私の様なペーペーだとキレイに纏められないのでそこは専門の書籍でお願いします。

1年間色々と勉強をしに行って感じたのが、今後はどの職種でも
プロダクトマネジメントの考えを理解しておく必要があるということです。

以前にもまして価値の提供に求められるスピードが早くなってきており、
言われるまで待っているというスタンスでは、スピードについていけません。
皆がプロダクト視点を持ち、ユーザー価値を高めるための最短の手を
自分で選べるようになっていく必要があると思います。