「JapanTaxi」アプリ開発体制の変遷（2019 Winter）

はじめに

「いま、全国タクシーチームで開発者として働くということ (2018 Spring)」 から1年半が経ち、その間に「JapanTaxi」アプリの開発体制にも変化がありました。

今回は当時の体制を「全国タクシーチーム期」と捉え、以降の開発体制の変遷をお伝えします。

「JapanTaxi」アプリチーム移行期（2018年9月〜）

体制や役割を微調整しながら形を模索

開発メンバーが増えたこともあり、体制や役割を微調整しながら形を模索していた時期。

グループ全体のプロジェクトを取りまとめる役割として「プロジェクトマネージャー」、注文系/決済系プロジェクトをまとめる役割として「プロジェクト担当」を定義。

私はサーバサイドエンジニアの傍ら、注文系プロジェクト担当として注文に関わる機能開発や施策の取りまとめ役を務めていました。

2018年8月末にアプリ名が「全国タクシー」から「JapanTaxi」アプリになったことで「JapanTaxi」アプリ開発チームと呼ばれるようになりましたが名前が長いため、JapanTaxi App Teamの頭文字からJAT（じゃっと）の略称を使い始めたのはこのタイミングです。

移行期に感じていた課題

当時、体制やメンテナなどの役割定義があることで動きやすさはあったもののいくつかの課題を感じていました。

• 機能開発や改修依頼の案件がさまざまな部署から来て乱立
• 案件の優先順位がつけづらい
• 一人案件が多く、一部メンバーに負荷が集中
• やったら終わり案件の存在

体制イメージ

主な役割

• プロジェクトマネージャー（全プロジェクトの統括）
• 注文系/決済系プロジェクト担当（複数プロジェクトの統括）
• プロジェクトメンテナ（プロジェクトの運営）
• ユニットメンテナ（ユニットの運営）

施策管理

• Github Projects

「JapanTaxi」アプリチーム期（2018年12月〜）

複数プロジェクトでの開発

当時、全社的に複数の「プロジェクト」という形で複数の開発を進めることが多く、それに対して事業側メンバーや開発メンバーがアサインされる形でした。

大きな機能開発をおこなうプロジェクトの場合はそれ自体がミッションとなっていましたが、注文系の一部プロジェクトではそれぞれミッションを定義してチームの目標数値の調査や施策を検討し、実施後の数値を確認しながら次の施策や改善をおこなう形をとっています。

他部署からの依頼については新たに始まっていた全社での小〜中規模施策の取りまとめの場を活用したり、プロジェクト内の施策案として集約したりすることで、移行期の課題は徐々に解消されていきました。

目的と目標数値を追うことによる変化

目的を共有して複数人で一緒に案件を進めて数字を追う文化ができ、施策リリース後のPDCAを回せるようになったことで、メンバーから施策実施後に「数字が上がって楽しかった、よかった」との声も。

一方で、プロジェクト自体は引き続き複数ありそれぞれ兼務メンバーが多くなっていたため、プロジェクト単位で見るとスピードが出ない課題も浮き彫りとなりました。

業務管理ツールに課題を感じていたのもこの頃で、連続性のある施策実行やマイルストーンを置いて目標に向かって動くにあたり、一部プロジェクトでClickup / asana での運用を開始しています。

体制イメージ

（移行期と変わらず）

主な役割

• プロジェクトマネージャー（全プロジェクトの統括）
• 注文系/決済系プロジェクト担当（複数プロジェクトの統括）
• プロジェクトメンテナ（プロジェクトの運営）
• ユニットメンテナ（ユニットの運営）

施策管理

• Github Projects
• 一部でClickup、asana

Passengersグループ期 その1（2019年5月〜）

グループへの再編

タクシー配車に関わる開発部門が整理され、大きく乗客向け・乗務員向け・タクシー会社向けの組織構造となるにあたり「JapanTaxi」アプリ開発チーム＋αが乗客向けを担うPassengersグループとして再編され、私はグループマネージャーを務めることになりました。

JATに代わる新たな略称として採用したのが、旅客用語でPassengerを表すPAX（ぱっくす）です。

社内にデータサイエンティストが増えてチームの分析に入ってもらえるようになったり、ディレクター職（施策の立案や調整をおこなう役割）ができたのはこのタイミングでした。

プロジェクト兼任制からチーム専任制へ

JAT → PAXになるにあたり見るべきプロダクトや範囲が増えていたことやプロジェクト兼任制のスピードが出ない課題から、チーム専任制をとることに。

アプリの機能開発は2チームに分け、プランニングやふりかえり、バックログ＆カンバンでのスプリント管理などをおこなうスクラムベースの開発体制をスタートさせています。

全社的に大きな開発は引き続き「プロジェクト」として立ち上がっていましたが、メンバー1人ずつではなくチーム自体をアサインする形に。各メンバーがチーム専任となることで、チーム内での開発プロセス改善が進み開発スピードもあげられるようになったのと、細かな案件も個人ではなくチーム担当とすることでフォローや相談などがしやすい状況がつくれていたように感じています。

一方でWHY/WHATよりもHOWによった計画が多いことで軌道修正がしにくかったり、「JapanTaxi」アプリの機能開発を担う2チーム間のバックログが別管理で同一課題を同じ場所で管理できないなどの弊害が見えてきました。

体制イメージ

主な役割

• グループマネージャー（全チームの統括）
• ディレクター（施策の立案・他部署調整）
• チームリーダー（チームの運営）
• ユニットリーダー（ユニットの運営）

施策管理

• asana

Passengersグループ期 その2（2019年12月〜）

1バックログ2チーム

全社的な組織見直しなどで、これまで複数人のディレクターがPAXに関わっていたところから1ディレクターがグループ専任になるなどの変化がありました。

デザイナーも同様に1デザイナーがグループ専任となり、プロダクトデザイナーという呼び名になっています。

そこで、PAX専任のディレクターをプロダクトマネージャーと定義し、アプリの機能開発をおこなう2チームについてはLeSS（大規模スクラム）をベースに進め始めました。

細かな案件も含めてバックログを1つにすることで、状況に応じて最適な進め方をとれるようにしていきたいと考えています。

グループ内ではアプリのバックエンドの品質向上やグループ内基盤を開発を担当するチームも存在しており、そちらはサーバサイドエンジニア主体のチームとして動いています。

ユニットリーダーからテックリードへ

ユニットリーダーについては今回からテックリードという呼び方に変更し、よりサーバサイド/iOS/Androidの技術判断をおこなう役割を明確化して、グループ全体の課題解決にも技術観点で入ってもらえるようにしました。

前期の課題を踏まえてミッションの定義に重きをおいて、「JapanTaxi」アプリチーム期の注文系プロジェクトのように目標を共有してチームが自立的に考えて動ける状態をいかにつくっていくかがテーマです。

体制イメージ

主な役割

• グループマネージャー（グループの統括）
• プロダクトマネージャー（施策のWHY・WHAT整理）
• チームリーダー（チームの運営、施策のHOW整理）
• ユニットごとのテックリード（ユニットの技術判断）

施策管理

• asana

まとめ

まだまだ課題はありますが、この1年弱で以前に比べてチームで考えチームで学ぶ機会が増え、開発プロセス段階的にが良くなってきていることを実感しています。

アプリQAやユーザーサポート、データ分析などグループ外との協力体制も以前に比べ強くなり組織力が底上げされていることも大きいです。

引き続き試行錯誤とふりかえりを繰り返しながらそのタイミングに最適な開発体制で、よりよい「JapanTaxi」アプリやJapanTaxi BUSINESSを始めとするプロダクト群を進化させていきたいと思います。

変化し続ける「JapanTaxi」アプリの開発現場に少しでも興味を持った方は、Wantedlyや採用ページを覗いてみてください！

Mobility Technologies では共に日本のモビリティを進化させていくエンジニアを募集しています。話を聞いてみたいという方は、是非 募集ページ からご相談ください！