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つの手としてありかなと思うのですが、これだと時間がかかって効率が悪いです。

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

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

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