PMだけが役割の境界線を越えてもプロダクトは作れない　プロダクト開発の肝は「全員でやっていく」文化形成

三竹氏の自己紹介

三竹弘司氏：では、今回はビットキーの三竹が、「越境するプロダクト開発」についてLTを始めていきたいなと思います。よろしくお願いします。

アジェンダを簡単に説明します。最初にビットキーを紹介がてら、「プロダクト開発をこんなふうにしているよ」というところを、フローや役割分担、あとは越境などを説明しつつ、各自、各ロールへのエピソードをメンバー各位で共有していきたいなと思っています。

最初に、私とビットキーの紹介を簡単にしたいなと思います。私は三竹弘司と申します。ビットキーでプロダクトマネージャーをやっています。

経歴を簡単にいうと、新卒でSIerに入って、エンジニアとしてキャリアスタートして、システム開発をやっていました。その後は、アドテクのプロダクト開発や、オフショア拠点を作るところを経て、スタートアップでプロダクトマネージャーをやっているというのが私のキャリアのサマリーになります。

（スライドを示して）写真にあるとおり、僕はランニングとDeNAベイスターズが趣味です。

株式会社ビットキーについて

簡単にビットキーの説明です。ビジョンだけを説明すると、僕らは「安全で便利で気持ちよく『つなげる』」と「Connect Everything」を目標に会社をやっていて、プロダクトを作っているということを覚えて帰ってもらえるとうれしいです。

（スライドを示して）事業は2つやっていて、「homehub」「workhub」です。

今回登壇するのはworkhub（での話）です。「働き方に、自由とパワーを」というところで、オフィスワーカー向けにサービスを提供していることを頭の片隅に入れておいてくれるといいかなと思っています。

プロダクトもけっこう多くやっていて、ソフトウェア、ハードウェア含めて、数多くのサービスを提供しています。そういった企業だと思ってもらえればなと思っています。

ビットキーにおけるプロダクトの開発のフロー

まずはビットキーのプロダクトの開発のフローや役割分担を少し紹介していきたいなと思っています。

全体像です。フローとしてはみなさんもやっていると思いますが、ディスカバリーと発見のフェーズ、デリバリー、送り出していくフェーズで分かれていきます。

（スライドを示して）ディスカバリーのほうは、ロードマップの検討がメインかなと思います。細々したことはいろいろあるのですが、「何を作っていくの？」というところを、プロダクトマネージャーが主導で検討しています。

「優先順位をどうつけるか？」が肝かなと思っているし、Bizや開発、プロダクトマネージャー自身も、「ビジョンの実現に向けてどうしていくの？」というところを喧々囂々とディスカッションしているフェーズかなと思っています。なので、プロダクトマネージャーが主体的にヒアリングをして課題を見つけ、どうしていくかを考えていくことがディスカバリーになります。

（スライドを示して）翻ってデリバリーですね。ここは「何をどのように作っていくのか？」というフェーズなので、作り手、開発者やデザイナーが主体になってやっていきます。（他のセッションで）出てくる竹内（Manami Takeuchi氏）や瀬戸（瀬戸康大氏）を含むデザイナーとエンジニアが、主体的にどのように作っていくのか？　を動かしているフェーズになります。

プロダクトマネージャーの役割は、仕様やリリースの責任はもちろん負いつつ、スプリントのフォローをしていくといったロールを担っているとイメージしてもらえればなと思っています。

ちなみに弊社はハードウェアもあるので、ハードウェアのフローもあります。（スライドを示して）ここはチラ見せぐらいですね。僕もがっつり入っているわけではないので、インサイトやデザインやディベロップフェーズというフェーズがあるという紹介になります。

ビットキーにおける役割分担

役割分担はかっちり決まっているわけではないのですが、「事業戦略」や「Vision/Mission」「why」「what」「how」という5つの柱があります。

（スライドを示して）このような役割分担をイメージして対応しています。もちろんフェーズや要因によるところで差分はあるとはいえ、こういったイメージを持っています。

プロダクトマネージャーは、事業戦略との整合性を踏まえて、why、what、「誰を、どんな状態にしていくのか？」に責任を持ちます。UXD（User Experience Design）、デザイナーは、whyを踏まえてユーザーへの価値提供に責任を持ち、エンジニアは「何を、どう作るか？」に責任を持つという役割分担で開発を進めています。

「役割が決まればうまく回る」わけではない

（スライドを示して）今回は「越境することがプロダクト開発の肝」というところでLTをしていますが、先ほど言った役割が決まればうまく回るかというと、こんな問題がいろいろ出てきますよね。

みなさんも同じような境遇に遭うこともあるかと思いますが、「作ってみたけど、どうなんだろう？」という課題は、いろいろと出てくるのが当たり前ですよね。

なので、役割を定義したからといってうまくいくわけではないです。この定義が強くなれば強くなるほど「お見合い」は絶対増えるし、境界線が色濃くなってしまうとボールは落ちてしまうものかなと思っています。

なので、この役割というのは、やはり越境していかないとうまくいかないかなというのが、僕らの開発チームが思い描いているものです。

プロダクトマネージャーだけが越境してもプロダクトは作れない

「プロダクトマネージャーにとって、越境とは？」を少し考えてみたのですが、プロダクトマネージャーはプロダクトの成長を実現することに責任を持つ人です。

事業やGTM（Go to Market）を、BizDevやCSのみにしてはいけないと思っているし、開発もがっつり入っていくと思うし、落ちるボールは拾って、足りないロールは見いだす人たちかなと。自分自身もそう思っているし、そうやって動いているのかなと思います。

では、プロダクトマネージャーだけが越境でプロダクトを作れるかと言われるとそんなことはなくて、ボトルネックになっているし、そもそも1人でできることは高が知れています。

なので、役割は越えていかないといけないかなと思っていて。先ほどの表を見ると、境目を各自が越境していくことが必要かなと感じているところです。

なので、例えばエンジニアが目指す状態として、背景の理解はもっともっと踏み込んでいくべきだし、「なんで今これをやるのか？」というところは、実装工数を踏まえての最適解を出したり。どうやって作るかというところは、もっともっと自分の領域を広げて、開発者の意思決定もどんどん入れていくべきだし、どう作るかも領域を広げていくといったスタンスで臨んでいくのがいいのかなと思っているところです。

越境を本セッションのテーマにした背景

ちなみに今回、越境をテーマにした背景は、プロダクト開発の現場で実践していることも1つあるのですが、弊社としてバリューを定義しているというところもあります。

（スライドを示して）「Hand in Hand」がバリューとして定義されているのですが、主体性を持ちながらチームを思いやり、カバーやムードメイクをすることを定義をしていて、これこそまさに越境といえます。

プロダクトマネージャーだけではなくて、開発メンバー全員で取り組むことが、事を前に進めるために必要かなというところです。この越境体験、Hand in Handを意識しているポイントを各ポジションから発表していくと、ビットキーがどういう会社なのかを発信できるかなと思ったのがきっかけになります。

前段が少し長くなりましたが、私なりのプロダクトマネージャーとしての越境エピソードを説明していきます。

（スライドを示して）今回のエピソードは、事業戦略やGo To Marketという、どちらかというとビジネス側、プロダクトマネージャーが越境しているエピソードを2点ほど紹介していこうかなと思っています。

「背景・ゴールを自ら言語化する」「ディベロッパーの納得感を醸成し続ける」

僕なりにプロダクト開発で意識しているポイントは3点あります。大きく背景・ゴールを理解した上で、プロダクト開発ができる場を作るところが肝かなと思っていて、それを実現するために3つ意識しているポイントがあります。

これも当たり前の話かもしれませんが、背景・ゴールを自ら言語化していかなきゃいけないかなと思っています。ディベロッパーの納得感を醸成し続けることが必要で、あとは信じて任せることです。この3点を共有していきたいなと思います。

（スライドを示して）まずは上の2点をまとめて説明します。顧客のビジネスモデルの把握と提供価値の定義を作っていくというところを説明します。

例えば、私たちはオフィス向けやコワーキング事業向けにサービスを提供しています。そのサービスを提供している先のコワーキング事業者のビジネスモデルを理解していく取り組みが必要かなと思っています。

（スライドを示して）整理すると、ここに書いてあるとおり、当たり前ですが、知ってもらって、利用してもらって、定期的に利用してもらって、ファンになってもらって、もっともっと長く継続してもらうことです。当たり前のようなことですが、ここがビジネスモデルとしてあるかなと思います。

フェーズをざっくり分けるとするのであれば、前半はユーザーの獲得、俗にいうリードの獲得です。コワーキングを知ってもらって、実際に体験してもらわないといけないというところですね。

この後は収益化のフェーズになるかなと思っていて、より定期的に利用を開始して、ファンになってもらって、もっともっと利用してもらうという、大きく2つのフェーズがあるかなと思っています。

なにかしらの機能開発や追加がターゲットであれば、リード獲得を実現することが目的になります。

これを実現するためには、プロダクトのユーザ体験として（求められるものは）、すぐに申し込めること。操作がより簡易で、アクションは極力少なくすることが必要です。

ここでは収益化は目指していません。仮に「事前決済ができない」となったとしても、そこはあまり重要ではないことになります。

そういった意思決定が容易にできるかなと思います。現地対応でもいいし……。もちろん事前決済できたほうがいいですが、そこのプライオリティは低いですね。そういったところが定義できるかなと思っています。

これを「顧客やビジネス側に聞いた」と言っていたのでは、ちょっと弱いかなと思っています。ここをプロダクトマネージャーが自ら定義して、開発者に伝え続ける。開発者が納得感を持って背景を理解した上で開発ができる環境を提供していくことが必要だと思っています。

もう1つのエピソードは、法規制と対応方針の決め込みです。法規制など、みなさんも経験があると思うのですが、弊社が対応していくものとしては、スペースの提供ですかね。

コワーキングやレンタルスペースと利用者をマッチングするプラットフォームを提供しているので、自ずと利用者の個人情報を事業者に提供します。

これは俗にいう個人情報の第三者提供になるのですが、この課題を解決する時に、「個人情報って何だろう？」「第三者って何？」など、いろいろと解釈が必要になる部分が出てくるかなと思います。

よくあるのは、プロダクトマネージャーがBizや法務に、（前提情報なしで）「ちょっと確認させてもらっていいですか？」というスタンスで臨んでいくことで、これも1つの手としてありかなと思うのですが、これだと時間がかかって効率が悪いです。

法律もあるのですが、プロダクトとしてどうあるべきかの定義をなかなか作りづらいかなと思います。

（スライドを示して）ここはもっともっと越境して、「個人情報は、これです」「合意方法は、これです」と。事業者は申し込み直後から管理画面で参照できるので、「このスクショでサービス提供していきます」と（プロダクト側で主体的に前提を整理したうえで、「法的要件をカバーしきれているのかを確認してもらいたい」というぐらいにイニシアチブをもって）コミュニケーションしていきます。

より一歩踏み込んで課題解決に向かうスタンスが、プロダクトマネージャーには必要かなと思っているところです。なので、プロダクトマネージャー自ら定義して、ステークホルダに伝え続けるスタンスが必要だと考えています。

「信じて任せる」

最後に、「信じて任せる」ですね。どちらかというと、ここはUXDやエンジニアの人たちの領域を広げてもらいたいものです。

「どのような体験であるべきか？」とか、「どう作っていくか？」ということは任せていくスタンスで僕は取り組んでいます。

背景は3つあります。意思決定こそが成長の糧ということで、「自分が意思決定者だったら」という体験をすることで、成長は促せるかなと思います。

もちろん、「なにか言語が書ける」とかそういう（直接的な成長の）ことではないですが、物事を前に進めるための意思決定をして、その賞賛や、ある意味批判を受けることでの成長は、必ずあるかなと思っていて。（だから）意思決定していってもらいたいなという思いがあります。

あとは、これも耳が痛い話ですが、プロダクトマネージャーの判断が常に正しいことはないというところが実感値としてあります。作りながら動かしてみた後に気づくことは多いし、作り手が動くものからフィードバックをもらったところは、優先していくべきかなという考えを持っています。

とはいえ丸投げにはしないで、一緒に考えていくスタンスは必要です。プロダクトマネージャーが楽になることが目的ではなく、最後の責任は持ちます。一緒になって考えていくという指針を持って任せていくことをスタンスとして持っています。

越境していくことの文化形成は必要である

簡単にまとめます。伝えたいこととして、プロダクトの開発のフローや役割の定義は、もちろん必要かなと思います。スタイルを統一していかないと、組織が組織として動くことは難しいかなと思います。

「私のプロダクトマネージャーの定義では」というところは、もちろんそれはリスペクトして尊重していくのですが、組織としてどうあるべきかは定義し続けるというところが必要かなと思っています。

2点目がオーバーラップですね。越境していくことの文化形成は必要です。「自分の仕事だけやっておけばOK」という空気は作らず、相互に助け合う精神は大切だし、これはプロダクトマネージャーだけではなく、全員やっていくという文化形成をし続けないとだめかなと思っています。

最後にプロダクトマネージャーとしての視点ですが、背景・ゴールを理解した上でのプロダクト開発の場が作れることですね。

開発メンバーに背景を理解してもらうことがスタートラインかなと僕は考えています。「ほかの人が言ったんだから」ではなく、自ら定義して、ステークホルダに伝え続けることが大事かなと思っています。

あとは「どのような体験であるべきか？」と「どう作っていくか？」っていうところは思いきって任せて、みんなで作っていく文化を作っていくことが大切かなと思っています。

簡単ですが以上になります。ご清聴ありがとうございました。