PdMによるブログリレー@MoT「RSGT2022登壇の話」
株式会社Mobility Technologies（以下、MoT）の脇水と申します。
MoTのプロダクトマネージャーとして、「どうする? GOする！」のCMや広告でもおなじみのタクシーが呼べるアプリ「GO」を担当しています。
MoTでは「GO」をはじめとした様々なプロダクトがあり、各プロダクトを担当するプロダクトマネージャー（以下、PdM）が十数名いるのですが、弊社PdMの業務内容や担当プロダクトをもっと知ってほしいという思いからブログリレーを開始します！
初回は私、脇水の方から先週実施されたRegional Scrum Gathering Tokyo 2022（以下、RSGT2022）にて、「どうする？GOする！LeSS導入する！？」というタイトルで登壇する機会をいただきましたので、登壇のスライドとともに、参加いただけなかった方にも内容をお伝えできるようにと記事にしました。
自己紹介
まず初めに私、脇水 誠（わきみず まこと）の自己紹介を簡単にさせてください。
職歴としてはSIerでプログラマー・SEとしてキャリアをスタートしました。その後はto C向けのサービスに携わりたく2007年から楽天で働き、楽天トラベルの事業の中でエンジニア兼プロデューサー、PdMを経験しました。
2019年からはテクノロジー × モビリティ産業の組み合わせに高い将来性を感じ、成長産業に身を置きたいという思いからDeNAのオートモーティブ事業部に移籍、2020年4月からのJapanTaxi株式会社との事業統合に伴い株式会社Mobility Technologiesで働くことになり、現在はPdMの所属組織であるプロダクトマネジメント部の部長として、PdMの業務に加えてチームビルディングや採用などを担当しています。
RSGT2022 - 登壇のWhy/What
MoTは事業統合という形で2つの組織が1つになり、様々なプロダクトを世に届け進化させ続けています。タクシーアプリについては、統合前は競合であった「JapanTaxi」アプリと「MOV」アプリのそれぞれの強みを活かす形で、「GO」アプリを統合からわずか5ヶ月でリリースし、ダウンロード数No.1*の実績を誇るまで成長してきました。
*App Annie調べ：タクシー配車アプリにおける日本国内ダウンロード数(iOS/Google Play合算値）調査期間：2020年10月1日～2021年9月30日
今回の登壇はその「GO」リリースの成功談を伝えたい！のではなく・・・ 統合と進化の過程で発生した様々な組織課題とその課題解決におけるアプローチについて、DeNA出身のPdMとJapanTaxi出身のエンジニアリングマネージャーという異なるバックボーンを持つ2人の視点から現場のリアルを伝えることを目的としました。自社の組織における課題解決に役立つ何かしらのヒントを持ち帰っていただければ幸いです。
統合後の最初の事業ミッションは5ヶ月で「GO」を市場に届ける！
DeNAで「MOV」を担当していた私にとって、事業統合前の「JapanTaxi」アプリは「MOV」よりも歴史が長く機能も多く対応エリアも広かったため、「Japan Taxi」アプリを超える機能や良い体験を作りたいという意識があったのと同時に、「Japan Taxi」アプリが既に持っている権利を侵害しないように機能を作らなければならないという観点もあって、常に意識をしているプロダクトでした。
2020年の2月にJapanTaxi株式会社との事業統合が発表された時は、私がいたDeNA社内の関係者の間で驚き・不安・混乱・期待など様々な複雑な感情が入り混じっていたのは事実です。私個人としては、DeNAから所属が変わる不安よりは、今よりも多くのユーザーに使ってもらえるプロダクトを作れるチャンスが広がるという観点で、楽しみの方が上回っていた状態でした。
事業統合後の「GO」プロダクトチーム体制
2020年4月にMoTが誕生し、さぁお互いの強みを活かして心機一転新しいプロダクトを世に出すためにがんばるぞ！と思っていたところ、予期せぬ自体が発生します。事実上の出社禁止、フルリモートワークへの環境移行です。
リアルでの対面ができず、ひととなりをほとんど把握できないまま事業統合と同時にリモートワークになったMoTですが、組織としても統合が行われ、ユーザー向けアプリを担当していた「JapanTaxi」アプリと「MOV」の2つのチームが合体し、「GO」を開発するための1つのチームになり、PdM・PjM・デザイナー・品質管理（QA）・iOSエンジニア・Androidエンジニア・Backendエンジニアを合わせると40名を超える規模のプロダクトチームになりました。
ちなみに「GO」のサービスでは、「エンドユーザー」「タクシー乗務員」「タクシー事業者」の3つのユーザーに向けてそれぞれ別のプロダクトを提供しています。今回お話しする範囲としては、 私が所属するタクシーアプリ「GO」を担当するエンドユーザー向けのチーム組織の話になります。
なぜ2020年9月に「GO」のアプリのリリースを目指したのか？という点については、事業を早く軌道に乗せるという観点は当然強いものの、少しでも早く「GO」を市場に届けることで「JapanTaxi」アプリと「MOV」を超える良い体験をユーザーに提供したい、もっと便利にタクシーを利用してもらいたい、またタクシー乗務員さん・事業者さんに対しても、コロナ禍で人々が街から消えてしまった逆風の中でも密にならない移動手段ということでアプリでタクシーを呼ぶニーズが増えてきた状況があったため、「GO」を通じて今まで以上に効率的な配車を成立させることで営業面でのサポートをしたい、といったような様々な理由がありました。
結論としては、多くの課題や困難があったものの、ターゲットとしていた2020年9月に「GO」をリリースすることができました。
統合からわずか5ヶ月でリリースできたことには様々な理由がありますが、職種・立場・出身の会社などに関係なくOne Teamとして、「GO」に関わる全てのメンバーが強いオーナーシップをもって、プロダクトを「自分ごと」として捉え、熱量高く業務に当たっていたことが大きかったと思っています。
GOのリリースという大きなマイルストーンを達成したプロダクトチームですが、2020年の夏頃から「GO」ならではのAIを活用した「AI予約」や「優先パス」といった大型の新機能を並行して開発していました。タクシー業界最大の繁忙期である12月までに市場に届けることを目標にプロジェクトを進めており、こちらも様々な困難があったものの11月中旬という時期にリリースすることができました。
急成長・急加速する企業とプロダクトで生じた課題と歪み
「GO」がリリースされ、大型の新機能を追加し、マーケ施策を踏んで認知が進みマーケットにフィットしていくプロダクトに成長してきた一方で、このあたりから徐々にプロダクトチーム内の状態が変わってきていました。GOリリース時と比べてチームの一体感が薄れてきているという状態です。
当時は40名超という大きな一つの「GO」プロダクトチームとしてデイリースクラムなどのイベントを行っていましたが、人数が多いこともあり、発言するメンバーも限定的になり、段々とプロジェクトの進捗管理のみがメインになってしまい、各個人が抱える課題にまではとてもスポットが当たらない状況でした。
2020年11月以降の「GO」プロダクトチームは、プロジェクトとしては予定通り進行できていたものの、個人の課題がチームの潜在的な課題として蓄積していった時期だったと振り返っています。
そして2021年になり、潜在化していたチームの課題が徐々に顕在化するようになってきました。「自分ごと」として捉えていたはずのプロダクトに対して距離を感じてしまうメンバーが現れたり、チームに対して発言ができないメンバーがいたり、節目を迎えた「JapanTaxi」アプリと「MOV」を支えてきたキーパーソンの数名が退職するという事態が起きたり・・・
オーナーシップが強いメンバーが内製でプロダクトを作るという組織の強みが以前より活かせなくなってきていました。
組織課題解決に向けて、40名超の「GO」プロダクトチームを3つに分割
そのような組織課題の解決に向けて、40名でOne Teamの組織を3チームに分割しました。2チームが新規案件の開発、1チームがグロース（改善）の案件を担当します。各チーム毎に要求定義・開発・デザイン・テスト・リリースまでの1サイクルが回せる組織です。
1チーム10名前後という組織になったことで、まずはシンプルにコミュニケーションが活性化しました。雑談も増えました。結果として各メンバーのひととなりがわかるようになり、デイリースクラムなどのイベントを通じて全メンバーの個人に毎日スポットライトがあたるようになりました。
チーム形成時には以下の質問についてチーム毎で考えるワークショップをmiroを使って開催しました。GOに限定しない形で各個人の理想を書き出したことで、今のチームが置かれている理想と現実とのギャップが把握できました。
良いプロダクトの条件とは？
良いチームの条件とは？
GOを強いプロダクトにするにはどう改善すればよいか？
さらに、各チームでOKRを設定するようにしました。チームのOKRについては各メンバーの評価とは直接連動しておらず、「チームとしてこうなりたい」という目標を作成し、チーム内の全メンバーが同じ目線で高い目標を追ってチームとして成果を上げる組織になることを目的としています（なおMoTでは全社・部門・個人でOKRを採用しており、個人のOKRについては評価に紐づく形になっています）。
私が所属するチームのKRの一つ目は「チームメンバー全員の心理的安全性が高い状態であること」という内容でした。つまりこれはチーム発足前は心理的安全性が高くなかったという状態を表しているとも言えます。
心理的安全性が向上
3チームの体制になったことで、心理的安全性が向上しました。3チームの体制になる前の2021年5月と比較すると11月には+15.6ポイント増加しています（このポイントの数字そのものにはあまり意味はありません）。
成果として、チーム単位での活動によって課題感やひととなりが把握できるようになり、各個人にスポットライトがあたるようになったことが大きかったと考えています。なお登壇中にDiscordで「アンケートでどのような質問をしているのか気になります」という投稿をいただいていたので、参考までに私が所属するチームで以前とったアンケートの内容を記載しました。これはエドモンドソン教授が提唱している心理的安全性を測定する7つの質問を引用しています。
チームの中でミスをすると、たいてい非難される
チームのメンバーは、課題や難しい問題を指摘し合える
チームのメンバーは、自分と異なるということを理由に他者を拒絶することがある
チームに対してリスクのある行動をしても安全である
チームの他のメンバーに助けを求めることは難しい
チームメンバーは誰も、自分の仕事を意図的におとしめるような行動をしない
チームメンバーと仕事をするとき、自分のスキルと才能が尊重され、活かされていると感じる
▼上記質問に対して、5段階で回答し集計します
強くそう思う
そう思う
どちらでもない
そう思わない
強くそう思わない
複数チームにしたことによる課題
もちろん3チームの体制に分割したことで全ての組織課題が解決するとはいきません。細かく組織を分割すればするほど各組織内のコミュニケーションは活性化しますが、一方で組織外の活動が見えにくくなります。心理的安全性は高まったものの「GO」プロダクトチームとしてのアウトプットのパワーが以前よりも下がってしまっては本末転倒になってしまいます。
LeSSの導入
そこでタクシーアプリ「GO」のプロダクトチームでは、LeSSのフレームワークを採用することにしました。
RSGTに参加の皆さんはこの辺りはとても詳しいので詳細な説明は割愛しますが、LeSSとは、スクラムの目的、原理原則、要素を大規模開発で行うためのフレームワークで、プロダクトバックログは1つの統合したものを用い、このプロダクトバックログを基に各チームがスクラムで開発を進めるという手法になります。
LeSSでは1つの統合したプロダクトバックログを基に開発を進めます。週に1回のプロダクトバックログリファインメントを通じて、PBI（プロダクトバックログアイテム）の優先順位を確認したり、PdMが各アイテムのWhy,Whatを伝えることで、複数のチーム体制でも同じ目標に向かって開発を進めていくことができます。かつ「他のチームが何を開発しているのかよくわからない」という状態を避けることができます。
レトロスペクティブ（ふりかえり）のイベントは各チーム毎で週一回実施することに加え、チーム毎に代表者を募りチーム横断で行う、オーバーオールレトロスペクティブを実施しています。チームの活動で発見した課題を基に組織を横断した課題を抽出し議論を行い、改善に向けたアクションプランに落とし込みます。
【PdM視点】LeSS導入の効果
PdMの私の視点から見たLess導入の効果としては、エンジニアをはじめとしたチームメンバーにクイックに相談できる仕組みがあることが大きいです。チーム毎のデイリースクラムでは15分でメンバー全員が主に「昨日やったこと」「今日やることを」を順に共有していきますが、その中でちょっとした課題や確認したいことがあり15分の枠で収まるのであれば話して解決してしまいますし、15分で足りない場合は別の場をセットして相談するという頭出しができるので、以前より早期に課題が解決ができるようになりました。
PdMが突き詰めて考えた案件毎のWhy,Whatをプロダクトチーム内に浸透させやすいという効果も生まれました。その結果としてPdMからエンジニアに「案件の開発を依頼する」のではなく「一緒に良いモノを作る」という内製開発の本来の強みを、プロダクトチーム全体としての人数が増えている状況下においても最大限に活かせる組織になってきたと感じています。
また、LeSSのイベントを通じて適切なコミュニケーションを、決まった枠組みの中で適量に行えるようになったことでリズムが作れるようになり、以前と比べてコミュニケーションのオーバーヘッドが小さくなり、コミュニケーションのコストが下がりました。「コトに向かって走れ。」というMoTのビジョンがあるのですが、余計な調整毎に時間を割くことが減り、以前よりPdMの本業に集中できるようになりビジョンを体現できるようになってきました。
最後に
「GO」プロダクトチーム発足時の体制から「GO」のリリース、組織課題発生とその改善の取り組みをLeSSの導入を含めて紹介させていたきました。もちろん全ての組織課題が解決されているわけではありませんし、さらに自己組織化したチームになるために、今回のRGST2022での登壇や他のセッションに参加して得たスクラムの知識を活用するなど、今後も様々なトライをしていきたいと考えています。
（本当に最後に）
今回、私としては数年ぶりのオフラインの場での登壇ということで、オンラインとは違う程よい緊張感とともに登壇を楽しむことができました。登壇者も参加者も全員マスクをしているという今までとは違う状況下ではありましたが、久しぶりに同じ志を持っている人々が一箇所に集まって同じ時間を過ごすという体験ができてよかったなと思いました。引き続きスクラムの最新情報をウォッチしていきながら、また私や弊社MoTのメンバーからRSGTで登壇ができればと思っています！
登壇資料はこちらにアップしています
関連記事
事業統合 〜 GOリリース 〜 LeSS導入に至ったストーリーを掲載しています
PdMによるブログリレー@MoT
「タクシー乗務員」「タクシー事業者」向けプロダクトの全体像について記事にしています