CloudCIRCUS Meeup#5〜PdMに欠かせないプロダクト愛〜
こんにちは！
クラウドサーカス開発部です。
第5回のMeetupは、Ruby言語のコミュニティ（プロダクト）マネジメントを担うまつもとゆきひろさん、クラウドサーカスのARサービス（LESSAR, COCOAR）のプロダクトマネージャーを務める多田さんとBowNowのプロジェクトマネージャーの馬場さんに登壇いただき、プロダクトマネジメントをテーマにさまざまな視点からディスカッションを行いました。
本記事は、前半と後半に分けてリリース致しました。今回は、プロダクト愛をテーマにプロダクトとの向き合い方についてお伝えさせていただきます。
※今回、YouTubeは諸事情により非公開とさせていただいております。
＜言葉の定義＞
※プロダクトマネージャー：PdM
※プロジェクトマネージャー：PM
※コミュニティマネージャー：CM
自発的に湧き出てくるプロダクト"愛"こそPdMには欠かせない要素
データを取るか？直感を取るか？
渋谷：ありがとうございます。では、次の議題に移りましょう。ビジネスとしてのSaaSプロダクト開発における「データを取るか？直感を取るか？」についてお話しできればと思います。
多田：これはPdMの議論でよく出てくる内容です。データか直感かのどちらを取るかについては、「フェーズによる」というのが結論ですが、多くの場合、データを信じるのが私の意見になります。これはコミュニティ運営とは異なるかなと思います。プロダクトマネジメントは数字で見える部分があるので、データを元に改善案などを考えられることが多いと思います。ただし、フェーズによるという点で、例えば、市場リリースがあまりない市場を攻めていくときは、ある程度自分の仮説を信じて、「こうだろう！」という仮説ベースで進めなければならないので、そのときは直感を信じればいいのかなと思っています。そして、返ってきた結果と仮説の差異をデータで評価して、スケールするにあたってその比重をデータに置き換えていけばいいんじゃないかなと考えています。
渋谷：その辺りはコミュニティマネジメントだといかがでしょうか？
Matz：Rubyの場合、使いやすさがメリットになったりするわけですが、これは数値化できません。また、生産性そのものが測定不能なことが多いです。一般的に時間を基準に生産性を測りますが、同じ作業をしても引っかかるところは引っかかるので、フラットに測定するのが難しいです。従って、Ruby言語の良さに関わるような部分は、だいぶ直感に依存すると思います。
ただし、AさんのRubyの使い方とBさんのRubyの使い方が違う場合、どちらのロジックが通ってるかを見ることになります。これは数字ではなくロジックが大切になります。
多田：とても面白いなと思ったことが、プロダクトを作るときは、作る側と使う側を分けて考えられますが、言語の場合だと作る側と使う側が同じという点です。言語のように作る側と使う側の距離が近いとゴールが測定しにくいのではないかと思いました。主観が強くなるので、複雑化しやすいんだなと思います。
Matz：「誰かのために作っている」だとまた違った態度で開発に望むのだと考えます。
多田：作る側と使う側の距離が近いとユーザー満足度の観点で評価が複雑になるんだなと感じました。
プロダクトマネージャーに必要とされるスキルとは？
多田：まず、PdMの私から聞きたいのですが、PMの馬場さんにとってどんなPdMがいいですか？
馬場：そうですね。この機能を作ることによって、どんな価値をお客さんに提供するのかということや今後の戦略的なロードマップを明確に描けていて、そこに向かって、足並み揃えて進行していけるモチベーションや安心感がある方は非常に有難いなと思います。あと、細かい部分ですが、改善や新機能の要求の部分で、割と明確に要件として出していただけると有難いなと感じます。
多田：良し悪しあるなーと思いつつ、耳が痛いですね（笑）
渋谷：開発要件をどこまで固めるのかという点に関しては、多田さんはいかがでしょうか？
多田：市場の要望や課題などに関してはPdMが伝えるべきだと思いますが、そこを限定するとなると開発者を縛ることになると思います。なので、過度に要件は詰めすぎないと言うことを意識しています。私がもともと開発をやっていたとき、要件を詰めすぎて上手く開発が進まなかった経験があるので、PdMとしてなるべく要件を詰めすぎないようにしていますし、要件よりも課題を伝えると言うことを意識しています。
渋谷：Matzさんに伺いたいのですが、要件を詰めるという点で、Rubyに新しい機能を入れる際は何を基準に採用していますか？
Matz：基本的に、誰かの提案は前向きに受け止めようとは思っています。ただし、私自身が定義する「Rubyの良いとはこういうこと」と合致しているかどうかという点は必ず見ます。プルリクエストを出してくださる人は、Rubyにこの機能がある方がいいだろうと思って提案してくださっているのですが、Ruby全体を見ているわけではないことが多いです。機能面もそうですが、作った機能に付けるネーミングの部分なども、Rubyコミュニティにおける雰囲気やデザインの一貫性の流れを見て、採用するかどうかを決定します。
渋谷：なるほどです。ところで、PdMに必要なスキルについてですが、多田さんはいかがですか？
多田：PdMに求められるスキルについてですが、根本的に自分が担当するプロダクトが好きかどうかがまず必要だと思っています。何がなんでも自分がこのプロダクトを大きくするぞという気持ちがないと厳しいと思います。PdMの職務はそれだけしんどいことが多いからです。あとは好きじゃないこともやらなければならないと思っています。
渋谷：一方で、CMに求められるスキルってなんですか？
Matz：たくさんありますが、一番大事なのは、プロダクトへの愛だと思っています。モチベーションでも熱意でもなんでもいいですが、このプロダクトを自分のプロダクトとして良いものにするんだという気持ちは、外部からはなかなか与えられません。
その人自身が自発的に持てるようになるしかないと思います。そこは結構重要だなと思います。あとは、「どんなモノが良いモノか」「どんなRubyがすばらしいか」CCの場合なら、「どんなBowNowが素晴らしいか」という「良い」を定義する能力が重要になると考えます。その上で、想像力や多くの方の意見を上手く取り入れる力、更には、マーケットのニーズを見出すことも必要になるので、たくさんのインプットを元に、最終的には経験と勘も含めて意思決定をする必要があります。また、責任を取ることやビジョンを定めることが必要になります。そして、一度定めたビジョンをメンバーやステークホルダーに説得力のある言語化をする必要も重要です。特に、経営層に説得できないとメテオフォールが来るので（笑）
多田：それが一番心折れますね（笑）
渋谷：プロダクトに対する愛が持てるかが根底に必要だということは、お2人に共通していますね。となると、努力どうこうではないのかなと思いました。だからこそ、プロダクト愛がある人はかなり力を発揮できるポジションでもあると言うことですかね。
Matz：細かい点ですが、プロダクトへの愛といった部分は後天的にも持てるとは思います。ただし、「他人から与えられることはない」という点で、自分がこのプロダクトを愛すると決めるかどうかだと思います。
業務命令として、プロダクトを愛せといわれても難しいじゃないすか？（笑）
多田：私も生まれた時からCOCOAR, LESSARを愛していたわけではないので（笑）
渋谷：なるほど。他人からではなく、自発的に自分が扱うプロダクトのことを愛せるようになるかどうかということですね。
後半まとめ
渋谷：いかがでしたでしょうか？
PdMにしてもCMにしても、何をプロダクトと定義するかの差であり、そこに進め方や育て方の違いはあるものの、根底にある「プロダクトを愛せるか？」はとても大切なマインドになると思いますし、それがプロダクトに対する誠意なのではないかと感じました。
技術やスキルも大事ですが、何よりも自分がどんな未来を実現したいかを描くことが大事なのだと思います。
採用に関して
クラウドサーカスでは、プロダクトマネージャーのポジションも募集しております。カジュアル面談を積極的に実施しており、個別でお話ししてみたいな！という方はぜひこちらからカジュアル面談のお申し込みをお願いします。
この記事が気に入ったらサポートをしてみませんか？