タクシーアプリ『GO』- プロダクト開発のプロセス改善

これはMobility Technologies Advent Calendar 2021の25日目の記事です。

こんにちは、『GO』のユーザーアプリ開発のエンジニアマネージャーの日浅です。

『GO』のプロダクト開発では、Large Scale Scrum（以下 LeSS）を採用しています。

本ブログでは、どのような課題に対して、LeSSを採用するに至ったかを書き留めました。

また、より詳細な内容は、Regional Scrum Gathering Tokyo 2022 『どうする？GOする！LeSS導入する！？』で現場感も含めてお伝えできればと考えているので、是非ご参加の方はご視聴ください。

背景

統合時の状況

2020年4月に、JapanTaxi株式会社と株式会社ディー・エヌ・エーのタクシーアプリ『MOV』などが事業統合し、株式会社Mobility Technologies（以下MoT）がスタートいたしました。

『JapanTaxi』アプリや『MOV』アプリを統合する開発を無事やりきり、2020年9月にタクシーアプリ『GO』をリリースしました。

その後も、「AI予約」や「優先パス」など数多くの機能をリリースしてきました。

エンジニア目線での当時のプロダクト開発

2020年9月までは、『GO』をリリースするということで、全員共通の目標に向かってプロダクト開発ができている実感がありました。

しかしながら、コロナ禍でリモートワークだったこともあり、9月以降は各職能（PdM、PjM、デザイナー、エンジニア、QC）間でコミュニケーションが噛み合わない場面が増えてきました。

そもそも組織風土が違う2社がコロナ禍の最中に一緒になり、大きな目標をクリアしたことで、目線がバラバラになってしまった感覚がありました。

また、技術的負債を解消する動きも、iOSは別で技術的負債を解消するチームを作り、そこでリファクタリングを実施していましたが、それ以外のメンバーは、プロジェクトとプロジェクトの合間を縫いながら、有志が対応しているような状況でした。

『GO』ユーザーアプリ プロダクト開発の改革

組織の改革

当時の開発体制

当時は、下図のように、プロジェクトが発足するタイミングで、都度、各職能（PdM、デザイナー、QC、エンジニア）から人をアサインしていました。

更に、『GO』のプロダクトは、ユーザーアプリだけはなく、乗務員アプリやタクシー会社が利用する管理ツールなど、複数のプロダクトの足並みを合わせる必要があるため、当時のPjMが細かなリソース管理やスケジュール管理、神がかり的な調整力により、数多くのプロジェクトを達成していました。

転機

ところが、2021年5月に転機がやってきます。

当時、数多くのプロジェクトが控えている中、神がかり的な調整を行なっていたキーパーソンが卒業することになりました。

引き継ぎの際に、彼がやっていたことを整理した結果、実に多くのことをハブとなってやってくださっていることがわかりました。

ただ、このまま他の誰かが引き継いだとしても、リソース的にもかなり厳しいことは明白でした。

そこで、当時感じていた組織の課題感と共に、適切に権限委譲するために、PdM、PjM、デザイナー、QCを巻き込みながら、意思を持って組織を変えることを検討していきました。

組織に対する課題感

その議論の中で、大きく3つの問題が見えてきました。

• コミュニケーションパスが多いため、コミュニケーションコストが高い。
• プロジェクト発足時にそれぞれの職能からアサインする人を決めるため、一緒に仕事をする人が毎回異なり、チームが洗練されにくい。
• プロジェクト発足時にそれぞれの職能からアサインする人を決めるため、プロジェクトチーム内部で共感し合える味方が少なく、心理的安全性が担保されにくい。

これらは、会社がコロナ禍の最中に統合し、社員の人数が約2倍に増え、全体で約400人超の組織になったことにより、組織の構造化が進んだからこその成長痛なのだと思います。

職能横断のバーチャルチームの結成

これらの課題を解決するために、下図の職能横断のチームを結成することにしました。

つまり、各職能（PdM、デザイナー、QC、iOSエンジニア、Androidエンジニア）がいる固定のチームになります。

そして基本的にプロジェクトは個人にアサインするのではなく、チームにアサインする方式へと変更しました。

※ Backendエンジニアはユーザーアプリ向けのリソースとして分かれているわけではないため、別枠として記載しています。

次に、それぞれの課題に対して、どのようなメリットがあったのかを述べていきます。

コミュニケーションコストが高い問題へのアプローチ

バーチャルチームの結成前だと、エンジニアへの依頼は、どうしても依頼元と仲の良い人であったり、特定の人に負荷が偏ってしまったり、エンジニアがやっていることをPdMが知らないという状況が出てきていました。

バーチャルチームの結成後だと、チームを固定化することで、依頼先のI/Fを固定化できるため、基本的にはチームのPdMが受けるルールとし、PdMがチームの状況を見ながら適切なタイミングで相談をすることで、エンジニアの負荷の軽減することができました。

チームが洗練されにくい問題へのアプローチ

バーチャルチームの結成前だと、毎回プロジェクトにアサインされたタイミングで、まずは、メンバーの為人を知るところから始めたり、コミュニケーションの取り方を考えたり、約束事を決めたりするところから始まるため、どうしてもチームとして成長することが難しい環境になっていました。

また、初めて一緒に仕事をする人に対しては、どうしても心理的な壁を感じてしまうケースもあると思います。

バーチャルチームの結成後だと、常に同じ人と仕事をするため、デイリースタンドアップやレトロスペクティブなどの活動を通じて、メンバーの状況や感性などを知ることができるため、プロジェクトをリリースするごとに、1つ前のプロジェクトよりも確実に洗練されたチームになることができます。

心理的安全性が担保されない問題へのアプローチ

前述した内容に近い形にはなりますが、バーチャルチームの結成前だと、どうしても胸襟を開いて接するための壁があるため、心理的安全性が担保されにくい状況になってしまっていました。

バーチャルチームの結成後だと、その壁は単純接触回数や時間経過と共に小さくなっていくので、心理的安全性の担保に繋がりやすいのです。

その他のメリット

もちろん上記に挙げた以外にも、数え切れないほどのメリットがあるのですが、全ては書ききれないため、一部だけ抜粋して掲載します。

• チームを10人前後に抑えたことによって、誰も発言しないということが無くなり、コミュニケーションが活発化した。
• チーム単体で仕様策定からリリースまでの責任を負うことができ、適切な権限委譲ができた。
• エンジニアがコミュニケーションに頭を悩ませることが少なくなったため、自分の開発に集中することができるようになった。
• しっかり自分たちがリリースした機能の数字を追うことができるようになった。

開発プロセスの改革

LeSS（Large Scale Scrum）の導入

バーチャルチームを構成することで、非常に多くのメリットを享受することができるようになったのですが、仕様策定からリリースまでの責任を負うことができる最小単位のバーチャルチームを作る上で、2つほど問題が生じました。

1つ目は、チームに仕様策定からリリースまでの責任を移譲することにより、全体のプロダクトバックログの優先順位を調整する必要が出てきた点です。

特に、今回、新規案件チームを2チーム、プロダクト改善チームを1チーム、計3チームを作ったのですが、それぞれ独自に考えて動き出すことができるため、複数あるプロジェクトやその他のタスクをどのような優先順位でやるか調整する必要があります。

2つ目は、チーム自体の改善はチームにお任せすることができるが、チームを超えたプロセス改善はチーム単体ではできないため、別途プロセス改善のパイプラインを用意する必要が出てきた点です。

これら2つの課題を考えたときに、組織論や集団心理学をベースとしているLeSSを選択しました。

ただ、『GO』に関連するプロダクトは、ユーザーアプリだけでなく、乗務員アプリや、管理ツール、基盤系などもあるため、それらのプロダクトとの整合性を合わせるため、PjM管轄で別の会議体を用意する方向で進めることにしました。

プロダクトバックログリファインメント

1つ目の課題を解決するために、LeSSのイベントであるプロダクトバックログリファインメントで、主に以下のことを実施しています。

• プロダクトバックログの状況の確認
• 各プロジェクトの着手順番を決定
• 見積もりを実施するチームの決定

これらを実施することによって、プロダクトバックログアイテム（PBI）を着手可能な状態に持っていっています。

オーバーオールレトロスペクティブ

2つ目の課題を解決するために、LeSSのイベントであるオーバーオールレトロスペクティブで、主に以下のことを実施しています。

• チームで上がった課題を、全体の課題として認識し、対策を考える
• 職能横断しないと解決できないような、プロダクト開発プロセスに対する課題を認識し、対策を考える
• ユーザーアプリだけでは解決できないような組織的な課題を認識し、対策やアプローチを考える

特に、オーバーオールレトロスペクティブでは、１ヶ月を通して、課題の洗い出し、対策のアイディアの発散、実施するアクションへの落とし込みをし、これを１ヶ月サイクルで回しています。

また、深堀りが必要なアイディアに関しては、更にメンバーを絞ってワーキンググループを組成し、別で議論をする仕組みを整えています。

これらを実施することによって、自己組織化された集団の形成ができていると感じています。

これからやりたいこと

今のやり方に変えて半年しか経っていませんが、集団として成長できている実感があります。

今後、エンジニアとしてやりたいことは、しっかりと技術的負債を解消していくチームを発足させ、技術品質の面から持続可能なプロダクトにしていきたいですし、新規案件チームやプロダクト改善チームに関しては、今以上に事業の思いや状況を知るために、PMMの役割を担う方をチームに巻き込んでいきたいですし、まだまだやりたいことは絶えません。

これからも、皆、一丸となってもっと良いプロダクト開発の集団を目指していきましょう！

謝辞

自分たちの組織を良くしたい、プロセス改善をするパイプラインをしっかり作りたいと考えたとき、相談にのっていただき、どうすれば今より良くなるか、議論に参加してくださった、PdM、PjM、デザイナー、QC、エンジニアの皆さん、卒業されるまで、現状がどうであるとか、こういう点は注意した方が良いとアドバイスをくださった方々、本当にありがとうございました。

We're Hiring!

興味のある方は 採用ページ も見ていただけると嬉しいです。

Twitter @mot_techtalk のフォローもよろしくお願いします！