本コーナーでは技術へのタッチポイントを増やすことを目標に、各分野で活躍されている方をお迎えします。
今回はエンジニアと一緒に製品の価値を高めるプロダクトマネジメントをテーマに小城さんにインタビューします。
【話し手】
小城 久美子（KOSHIRO Kumiko）
小城 久美子
プロダクトマネジメントの体系化によって成功の再現性を高めたいエンジニア出身プロダクトマネージャー。書籍
Twitter @ozyozyo
URL https://
価値を届ける仕事
日高： 小城さんはプロダクトマネージャーとして、またアドバイザーとしても活躍されていますよね。
小城： 今はプロダクトマネジメントを学問としてとらえたいと考えています。世の中にある成功と失敗から学んで、巨人の肩の上に立って成功に早く近付けるようになればいいなと思って。
日高： 学問というとソフトウェアは工学ですがプロダクトマネジメントも似ているのでしょうか？
小城： 工学にも近いですが科学的な要素も感じています。体系立てた手法どおりにやってもうまくいくとは限らず、アプローチも未分化なところがありますが。
日高： プロダクトごとの違いもあっておもしろいですよね。そのように考えたきっかけなどはあるんでしょうか。
小城： 新規事業にPM
日高： 試行錯誤の中で新しい発見はありましたか。
小城： それまでは自分のバックグラウンドが大きく影響していたのだと思います。私はもともとソフトウェアエンジニア出身でしたので、エンジニアの目から見えるPM像しか見えていなかったかなと。
日高： 具体的にどんなことをする仕事なのでしょうか？
小城： プロダクトを育てることとプロダクトを育てるチームを作ること、この2つがPMの仕事だと考えています。
日高： よくあるのは仕様書を書く人というイメージです。
小城： 実際にはそれだけではないんです。プロダクトでお金を稼ぐために、どの仕様書を書くのか道筋を立てる仕事でもあります。広く見渡すことで頭の中にプロダクト全体の白地図ができあがってくるんです。
日高： 地図という表現は納得感があります。これまで見えていない景色がわかるとアプローチも整理しやすいですよね。
小城： 仕様を書くという仕事も、なぜ今その仕様が必要なのかという
日高： 今何をやるべきかを選択すると。
小城： すでに実現できているものではなく、今ない機能って無限に選択肢があるわけです。その中からユーザーが必要としているものを発想し、どれをやるべきか決めるお仕事ですね。
日高： プロダクトを育てる部分ですか。
小城： 具体的には事業計画が背景にあって、それを達成するために必要なユーザー規模などの目標を用意します。ユーザーをインタビューなどを通して観察し、仕様というかたちで意思決定します。エンジニアとのコミュニケーションだけでなくプロダクト全体に関わります。抽象的な言い方をするとユーザーが幸せになる方法を考えるということでしょうか。
日高： PMというお仕事の魅力が伝わってきました。一方、大変さも感じます。何がきっかけでこの仕事を好きになったのでしょう。
小城： 過去、開発者さんと一緒に製品を良くしてユーザーへ幸せを届ける体験ができたことですね。周囲を巻き込んで価値を届けられたのは貴重な体験でした。
日高： 私も書いた本が読者の役に立って価値につながっていると思うとうれしいと感じます。
小城： PMは自分の責任で意思決定をする分、プレッシャーが大きい側面があるかもしれません。自分が絶対うけると思った機能が駄目だったときは罪悪感とも向き合います。喜びとつらさ、どちらも大きいです。
日高： たしかに感情の起伏が大きくなりそうです。不確実性もあって制御が難しい。
小城： 事前にユーザーインタビューをして喜んでもらえる機能へ確度を高める方法、開発リスクを下げるために工数を減らして似た機能で代用する方法などアプローチはいろいろとれますけれども。
日高： そのアプローチを決めるのにも
小城： そうですね。解決策は1つじゃないのでチームにあった方法を探すことになります。
チームをリードする
日高： プロダクトにまつわる協業はエンジニアだけでしょうか。
小城： 大きくビジネス、UX
日高： B2B
小城： どう作っていくかはエンジニアだけではなくデザイナーさんも関係しますね。
日高： その中で難しいことは？ バランスをとることですか？
小城： これは過去の失敗から強く思っているんですが、バランスは取っちゃいけないんです。全員を幸せにしようとするとプロダクトが民主主義的になって尖ることができなくなります。
日高： なるほど。その発想はなかったので驚きました。
小城： それよりも全員で向かう一つの方向性を決めて、それにチームで肉付けしていくととらえたほうがいいと考えています。
日高： たしかに衝突を回避する作業は後ろ向きになりがちですし、同じ方向を目指すほうが生産性も高いですね。
小城： プロダクトが目指すビジョンをどう達成するのかという道筋への共通認識が大事になります。チームメンバーと一緒にプロダクトマネジメントをしていくとき、PMは旗を振る立場というイメージです。
プロダクトの「なぜ」を考えるために
日高： アドバイザーの経験から現場での共通の課題とかはあるんでしょうか？
小城： すべての現場で通用する法則といったものは見つけられていませんが、プロダクトマネジメントが必要だと仰る方々には共通点がありますね。
日高： それはどんな？
小城： モノを作りきってしまって今後成長するための指針がわからないという方がプロダクトマネジメントを必要としていそうです。この次の成長のためにどうしていけばいいんだろうという困り方ですね。たとえばビデオ会議システムに必要な機能は全部載せてみたけど、次はどうしようというパターンも該当します。
日高： 必要な機能を順次追加するのはイメージしやすいですが全部作ったとなると……次を探すのは難しい。
小城： そういうときは
日高： ソフトウェアも継続開発が前提になってきています。リリースしておしまいではない今だからこそ、PMの需要も増しているのかもと思いました。コミュニティや横のつながりもあるんですか？
小城： エンジニアの持つ文化と比べるとそこまで多くないと感じています。2年前にプロダクト筋トレというコミュニティを立ち上げて、もうすぐ3,500人ぐらいの方に参加いただけそうなところまできました。
日高： かなりの規模感です。
小城： コミュニティも複数あったほうがいいなと思いますね。大きなところだとProduct Managers Japan
日高： シェアする内容は業務に関わることが多いんでしょうか。
小城： 具体的な話を深く共有するのは難しい場合も多いのでプロダクトマネジメントの中でもフレームワークを使いこなす方法であったりとか、ほかの人の発信で良かったものなどを紹介し合ったりすることもありますね。
日高： そのあたりはエンジニアの勉強会と変わらないですね。
小城： 最近はたくさん本が出ているので読書した内容を発表し合うLT会などもあります。
プロダクトマネジメントの言語化
日高： 冒頭の
小城： はい。プロダクトマネジメントは非常に幅が広いため知識がないと議論も難しいと感じる一面もあります。
日高： 知っているに越したことはありませんがプロダクトのライフサイクルすべてに関わることも珍しいですよね。
小城： そうですね。プロダクトと人間のライフサイクルを比べると1人のPMが0→1やグロース、クロージングと全部のステージを経験することはなかなか少ないです。
日高： そのようなケースを抽象的に扱うためにも体系化や言語化が必要だと。
小城： 日本では会社ごとにプロダクトマネジメントと呼んでいる領域がずいぶん違うという事情もあります。必要とされるスキルは価値探索をするためのプロダクトディスカバリとユーザーに届けるプロダクトデリバリの2領域に分類できるのですが、会社によって2領域の比重が異なっています。
日高： スキルの分類は初耳でした。この2領域どちらも知ってほしいとなると広大ですね。エンジニアが見ているPMの領域は、どちらかというとデリバリがカバーしている範囲だと感じます。
小城： PMとして働く人でも、自分のやっていることはほんの一部分なのでPMと名乗っていいのかわからないという声も聞こえます。
日高： どういう意味でしょうか。
小城： プロダクトマネジメントの領域が広いので基本的な業務をやっているものの意思決定は上司がしているなど、役割の一部だけを担う場合です。このあたりは会社や組織で求められているPMとしての役割に依存します。
日高： たしかに。PMがプロジェクトマネジメントを兼ねるケースも多いと感じます。
小城： プロダクトとプロジェクトではマネジメントする対象が大きく異なります。プロジェクトマネジメントはデリバリ側で品質・
日高： どちらもプロダクトに関する業務なのは間違いないですが同時に遂行するのは難しいですね。
小城： 担当を2人に分けるべきかは会社や組織がどのステージにいるかという点も影響しますが、2つの役割を兼任している意識は持っていたほうがあとあとを考えるとスケールするはずです。
日高： 日々の業務に追われてしまうとプロダクトを育てる時間が取れなくなると。
小城： ええ、プロジェクトマネジメントで手一杯になってしまってプロダクトマネジメントを疎かにしてしまう原因の一つになり得ます。ただこのあたりはここ数年でずいぶん変わってきたなという印象です。
日高： というと？
小城： 以前はプロダクトマネジメントという名前が付いていなかったので
日高： それが今は解消されはじめていると。
小城： 少なくとも各プロダクトから成功している状態の事例が生まれていて、みなさんが動きやすくなっているのかなと。今はうまくいった成功体験を持った方とそうではない方の2極化が進んできたと感じています。
プロダクトを育てるチーム
日高： 成功体験の有無が問題なのでしょうか。
小城： 知識としては知っているけど自分の経験がないので今がうまくいっているのかどうか判断がつかないという点が問題になります。
日高： 知識を得たあとにもハードルがある。
小城： 知識を得て試したあとには実績でしか
日高： 判断ができる指標がないと困りそうです。
小城： プロダクトの成功指標を設定するにも知識が必要ですね。
日高： たとえば本であれば売上を伸ばすというのは指標になるんでしょうか？
小城： 事業部全体で売上目標があったとしても、部内の各課で行った施策に横軸が通っておらず、別々の方向に努力しても効果は得られにくいですよね。
日高： たしかに。そうすると売上を伸ばすという指標が良くないということか。
小城： 売上につながる誰にどんな価値を提案するのかを測る指標が最適です。たとえば、応用情報のテキストであれば合格者数と実務での活用度合いのどちらを成功の指標にするかで、できあがる本が異なってきます。
日高： なるほど。アプリケーション開発でも画面ごとにやっていては全体の体験が悪くなることもあります。統一した体験を設計する必要があると。
小城： プロダクト戦略として事業的な数値目標に対して、どのセグメントにどんな価値提案をすることで売上を上げるのかをユーザーと対話しながら考えて、機能と仕様に落とし込み、ユーザーに届けるのが全体像です。
日高： これは1人ではできない。
小城： プロダクトはチームで作るものだと考えてください。PMはリードするだけでチームメンバーがそれぞれの専門性を活かして協力し合う。
日高： エンジニアにもできることが？
小城： プロダクトの意思決定の背景をチームメンバーが理解していると振る舞いも変わりますよね。仮説検証のための使い捨てていいコードなのか、将来の価値提案につながる基礎なのか、エンジニアにはソフトウェアのプロとして提案がもらえるとPMとしてもありがたいです。
日高： チームで同じ方角を向いてプロダクトを作ることで個々の立場や視点が活きて強いプロダクトになると。
小城： 細かいところまでPMが入っていくのではなく、チームメンバーそれぞれがプロダクトの価値を高めるために白地図を埋められると強いチームと言えます。
日高： プロダクトを育てるチームを一緒に作りたくなるお話ですね、本日はありがとうございました。
