GOリリース直後の危機を乗り越え、僕たちは強くなった。PdM×エンジニア対談

2020年4月、前身となるJapanTaxiが、DeNAのMOV/DRIVE CHART事業と統合。Mobility Technologies（以下、MoT）に社名変更し新たなスタートを切りました。そして、2020年9月、新たにタクシーアプリ「GO」をリリース。2021年10月には500万ダウンロードを突破しました。

かつては競合関係にあった2社が手を組み、新たに取り組んだアプリ開発。その成功の裏には、知られざるハードシングスがありました。プロダクトマネジメント部部長の脇水誠とアプリ開発グループマネージャーの日浅貴啓が振り返ります。

GOリリース直後のチームに訪れたピンチ

ーまず、もともとライバル関係にあったような2社が統合したことで、現場の各メンバー間に戸惑いは生まれなかったんですか？

プロダクトマネジメント部部長 脇水誠

脇水：
GOを担当するプロダクト開発組織として40名規模の大所帯になったので、プロジェクトを進めていく中で最初は難航すると思っていましたが、戸惑いややりづらさは想定よりなかったと感じていました。2020年9月に「GO」をリリースするという大きな目標があったことは大きいと思います。必然的に目線が合っていった感覚がありました。

日浅：
問題は、9月以降です。リリース後は、コロナ禍でリモートワークだったことも相まって、コミュニケーションが噛み合わず、心理的安全性が担保しづらい状況が続きました。なんといっても、もともとはライバル関係にあった2社です。そもそも組織風土が違うし、大きな目標をクリアしたことで目線がバラバラになってしまった感覚がありました。

ー具体的にはどういう状態だったのでしょうか？

脇水：
当時のGOを担当するプロダクト開発組織の内訳は、一つのチームの中にPdMが6名、エンジニアがiOS、Android、サーバー含めて約15名。さらにPjMやデザイナー、テスト担当も含めると合計で40名を超える規模になっていました。

その規模でデイリースクラムを実施していましたが、そうなると必然的に発言者はPdM・PjM・エンジニアリングマネージャーに限定され、メンバー全員が発言する機会もなくプロジェクトの進捗管理のみで時間を要するように。各個人が抱えている課題にはスポットが当たらないため、今振り返るとその課題が徐々に蓄積していき組織の課題として表面化していくのは時間の問題という状態だったと思います。

個人的には事業統合時点ではあった「チームでプロダクトを作っている」という感覚が、時間の経過と狭い範囲での限定的なコミュニケーションが継続していたことによって薄れていく状態になってしまったと感じていました。

アプリ開発グループマネージャー 日浅貴啓

日浅：
更には、その限定的なコミュニーケーションが、各プロジェクトのコミュニケーションコストにも繋がっていることがわかりました。

当時は、プロジェクトに対して各職能（PdM、デザイナー、エンジニア、QA）から人員をアサインしていました。

しかし、毎回顔ぶれが違うため、まずは、為人（ひととなり）を知るところから始めたり、コミュニケーションの取り方を考えたり、約束事を決めたりするところから始めなければいけませんでした。

また、Slackで連絡する際にメンションが漏れてしまって重要な情報が一部のメンバーに伝わっていなかったこともありましたし、コミュニケーションを通じて、きちんとお互いの担当領域のすり合わせができていないと、「別のエンジニアはここまでやってくれたのに」とギャップが生まれてしまうこともありました。

そのコストってものすごくもったいないですよね。それだけの時間があるなら、どうやったらGOを良くできるかにもっと力を注ぐことができるのに。

LeSSの“ゆるめの強制感”が、チームを救った

ーどのように解決していったのでしょうか？

脇水：
具体的には、大規模スクラムのフレームワーク「LeSS(Large Scale Scrum)」の導入です。LeSSとは、スクラムの目的、原理原則、要素を大規模開発で行うためのフレームワークで、プロダクトバックログは1つの統合したものを用い、このプロダクトバックログを基に各チームがスクラムで開発を進めるという手法になります。

ーどういったことを実践したのでしょうか？

脇水：
PdM、デザイナー、QA、エンジニアで構成される、新機能を開発するチーム2つと改善するチーム1つの3チームを組成しました。メンバーはそれぞれ10名前後。チームごとのデイリースクラムではメンバー全員の発言が可能になりました。

加えて各個人が日々の業務で何をしているのかが明確に把握できるようになり、課題の共有や、リリースした案件についてクイックにその効果を共有するなどコミュニケーションが活性化するようになったことで様々なメリットが生まれました。

ー結果はどうでしたか？

脇水：
効果は出ました。月次でチームごとにアンケートをとっているのですが、心理的安全性に関する項目への回答が改善されています。

日浅：
チーム結成当初、今の自分達とのギャップを把握するために、各チームごとにグループワークを実施しました。

その中の1つに「良いチームとは」というお題があったのですが、そこを深掘りしていく中で、今の自分たちには心理的安全性が担保できていないということに気付くことができました。そして、チームのバロメーターを自分達で確認するために、独自に月次アンケートをとって計測するようになりました。

アンケートの取り方もチームごとにユニークで、あるチームはNPSで計測したり、あるチームはGoogle re:Workの心理的安全性を測定するための7つの質問をチームに尋ねたりしています。

また、個人的に大きな成果だと感じたことは、LeSSのフレームワークの中にある「オーバーオール・レトロスペクティブ」です。これは、プロダクト開発に携わる主要なメンバーで組織やプロセスを振り返る場なのですが、ひと月通して、課題の洗い出し、対策のアイディアの発散からアクションプランへの落とし込みを行なっています。これを月毎に回していくことで、自分たちの開発プロセスをどんどん改善できている実感があります。

脇水：
同時に、一人ひとりの顔やパーソナリティーが見えるようになったことが大きいですね。チームごとに週次で実施しているレトロスペクティブを通じてコミュニケーションが増えたことで、個人が抱えている課題にもスポットライトが当たるようになり、その課題を解決するためのTryとしてチームで何ができるのかを考えるようになったことで以前より一体感が生まれたように感じています。雑談の機会も増え、人柄を知れるようになったこともチームの心理的安全性の向上に寄与していると思っています。

ーLeSSがうまくハマった要因はなんだと思いますか？

脇水：
「まずはやってみよう」というメンバーが多かったことは大きいですね。導入直後はミーティングの時間が以前より増えているという懸念もありましたが、今まで以上にコミュニケーションが密になり、メンバーの心理的安全性の向上が見えるようになったことでその懸念はなくなりました。

以前は振り返りを予定していても、プロジェクトが忙しいとスキップや欠席しがちになっていたことで課題が埋もれたままになっていましたが、LeSS導入後のレトロスペクティブでは「今週はスキップしましょう」とはならなかった。フレームワークによる“ゆるめの強制感”がいい方向にワークしたのではないでしょうか。

日浅：
そのとおりですね。スクラム自体が組織論や集団心理学に基づいた手法だと理解しているメンバーが多いので、「このミーティングは必要ないんじゃないですか？」といった声は生まれなかったですね。そういう意味で、メンバーに受け入れられやすい手法だったと思います。

スクラムも、カッチリやるのではなく、まずは心理的安全性を担保するための場をしっかり用意するためにLeSSを導入し、それに伴って、チームごとにスクラムのイベントを実施したという流れになっています。

そのため、実はスクラムマスターという役割も置いておらず、ストーリーポイントやバーンダウンチャートでチームのベロシティを把握するということもやっていません。先ほども脇水が言ったとおり、そのような”ゆるさ”が今回上手くいった要素の1つだと思います。

ハードシングスを乗り越えたチームを、成長の足がかりに

ーある意味のハードシングスを乗り越えたわけですが、今後はどのような組織にしていきたいと思いますか？

日浅：
今回、10名前後のチーム内に、PdM、デザイナー、エンジニア、QAメンバーがいる構成にすることで、チーム単体で判断し機能をリリースできるように権限を委譲することができました。今後も任せられるところはどんどん権限委譲していきたいので、メンバーには成長の足がかりにしてもらいたいと思っています。

また、現在は、チームとして心理的安全性を担保できるようになったので、次はチームのベロシティーを測定し、安定化させることに焦点を当てていきたいと考えています。

エンジニアに関しては、技術ラインかマネジメントラインか、技術ラインの中でもスペシャリストかジェネラリストかなど様々なキャリアパスがあると思います。弊社では、希望があれば別のプロダクトにジョインすることも可能なので、自分が思い描いているキャリアパスに向かって、どんどん活用していっていただきたいです。僕のグループでも2021年5月にリリースしたフードデリバリーアプリ「GO Dine」の開発にジョインしたメンバーもいますし、サーバーサイドに移ったメンバーもいます。一般的なエンジニアのキャリアパスに加えて、スキルアップできる環境が整っていると思いますよ。

最近だと去年iOSからサーバーサイドに移ったメンバーが「Go」という言語のGo Conferenceで登壇していました。マネージャーとしてリソースのやりくりは大変でしたが、新たな環境で結果を出しているメンバーの顔を見たら、やはり嬉しかったですね。

脇水：
PdMもやり甲斐があると思います。「PdMの役割はよくWhyとWhatを突き詰めて考えること」と言われますが、大切なのはプロダクトを通じてどんなユーザー課題を解決したいのか、どんな価値を提供したいのかをとことん考えることにあります。そういった軸がしっかりあるが故に同じ志を持った仲間ができ、チームとして成果を生み出すことができるようになり、結果としてプロダクト・個人・組織・事業の成長に繋がっていきます。

自分なりにベストだと考えた要求仕様をチームやビジネスサイドにレビューしてもらう際、時にはタフなフィードバックも受けますが真摯にそれを受け止め、ブラッシュアップしていくわけです。プロダクト・個人・組織・事業全てが伸びているMoTの環境だからこそ、必然的に高いレベルの成果を求められますが、だからこそ成長できると実感しています。

PdMという職種の知名度自体は近年すごく上がった反面、まだまだ専門性の高い人は少ないですが、MoTであればロールモデルとして活躍できる可能性があります。

MoTではキャリアもバックグラウンドもさまざまなPdMが集まっていてそれぞれの強みを活かして業務にあたっているので、日々の業務を通じて成長できる体制が整っていると実感しています。

MoTで活躍するPdMとエンジニアの条件

ーそれぞれ、MoTで活躍するための要件を教えてください。

脇水：
大きく分けて、3つあります。1つ目は粘り強く成果を出すまでやり遂げる力です。プロダクトの成功に責任を持つのがPdMです。リリースして「やった！」と喜んでいるうちはまだまだだし、リリース後にユーザーの課題を解決できているか追い続けられなければなりません。

2つ目は、周囲を巻き込む力です。例えば規模の大きい案件を進めていくと日々様々な課題に直面します。当然自分1人で解決できることには限界があるため、周囲の協力を得ていく必要があります。そういった時に課題の背景や経緯を周囲に的確に説明し、解決した後のGoalを共有することで一緒に課題に立ち向かってくれる仲間を作るための巻き込み力がとても重要になります。

3つ目は、段取り力です。常にユーザーにとってベストな要求を考えるのがPdMの重要な役割ですが、世の中の状況や市場の動きなどを適切に捉えたうえで「この要求は今はあえて実装しない」という判断も非常に重要になります。

日浅：
エンジニアの場合、職能によって若干異なりますが、やはり自分のサービスが好きであることは重要ですね。好きならサービスを良くすることも苦にならないし、スキルの伸び率も変わってくるので。

ー最後にMoTへの入社を検討している方にひと言お願いします。

脇水：
個人的に、モビリティ産業の未来に大きな期待を寄せています。今後10年で間違いなく新しいテクノロジーと供に進化を遂げる成長産業だからこそ、自分たちの取り組みが社会課題解決に貢献した、新しい仕組みの社会実装に貢献したという実感が得られるのではないかと思っています。テクノロジーの力でこれからのモビリティの未来をカタチにしていく志がある方はぜひ仲間になっていただきたいです。

また一方で、現時点でモビリティ産業に大きな興味がなくても、PdMとしてもっと成長したい、今後はPdMとして新しいキャリアを築いていきたい、というキャリア志向を軸にしている方も大歓迎です。PdMとして成長して行きたいという方、まずはカジュアル面談でも歓迎ですのでぜひお話ししましょう。

日浅：
エンジニアとして一番念頭に置いているのは、技術品質へのこだわりです。一般的に、製品品質の中に、技術品質が内在すると思われがちなのですが、プロダクトが今後実現できる世界感の上限は、技術品質の上限によって決まってくると考えています。そう考えると、実は技術品質の中に製品品質が内在しているという解釈の方がしっくりくるのです。

つまり、GOが今後エクスパンドするかどうかは、技術品質にかかってくるということです。この技術品質を上げるためには、個人の技術スキルはもちろんのこと、チーム品質の点も重要になってきます。集団で開発している以上、心理学的視点からも、1 + 1は決して2にはなりません。この1 + 1をどのように2に近づけるか、そこが今重要だと感じているからこそ、僕はチームにこだわっています。自分のスキルを最大限発揮できるチームで働きたいエンジニアの方、ぜひお待ちしております。