競合同士だった2つのプロダクトを1つに統合する話(前編)
はじめに
こんにちは、株式会社MobilityTechnologiesで乗務員向けアプリのPdM(プロダクトマネージャー)をしている華井と申します。
2020年4月1日に会社統合をしまして、もとは競合同士だった「JapanTaxi」アプリと「MOV」アプリが統合して9月に「GO」アプリが誕生しました。
GOなどのタクシーを呼べるタクシーアプリには、お客様のお迎え先や目印・希望サービス(ex.希望乗車時刻があるなど)など各種情報を連携し目的地までのナビなどを行うなど、注文を引き受け運行をサポートするための対となるタクシー乗務員向けのアプリが存在しています。
toC向けのタクシーアプリは「GO」に統合しましたが、乗務員向けのアプリはJapanTaxi用の乗務員アプリと、MOV用の乗務員アプリの２つが引き続き存在しております。
そのままの状態ですと、GOアプリに何か改修・新規機能を追加した際に、JapanTaxi用の乗務員アプリと、MOV用の乗務員アプリの両方に都度手を入れる必要性が出てきてしまい、二重開発になってしまいます。
そのため、二重開発の無駄をなくすことで、その分より便利な新機能や使い勝手の向上に時間を使えるよう、開発効率の最適化と中長期的にみたときの事業としての収益性向上を目的に、2つある乗務員向けアプリを統合することになりました。
今回はその乗務員向けアプリの統合についてお話できればと思います。
※乗務員向けアプリがどのようなものかは以下記事を参照ください。
プロダクト統合プロジェクトを取り巻く環境と進め方
①前提：当時の環境について
会社統合をしたのは4月、そこから乗務員向けアプリの統合プロジェクトに関する会話が始まりだしたのが6月頃からになります。
当時はざっくり以下のような状況でした。
1：コロナ感染者が出始め、1番初回の外出自粛タイミング直後😨
冒頭に述べたように2020年4月に会社統合をしまして、社員も倍(250名くらい→500名くらい)になりましたが、なんと4月7日に第1回目の緊急事態宣言！まだお互い人もプロダクトも全然知れていないのに、タイミングの悪いことに、いきなり外出自粛でリモートでの"顔合わせになってしまいました。。
もちろん、1番初回の外出自粛でしたのでリモートワーク自体にも慣れていなければ、お店が軒並み営業停止になってしまっていたりと生活スタイルの急変に伴うストレスも重なり、かなりストレスフルな環境でした。
2：組織の統合も絶賛進行中で、まだまだ2つの組織が混在しているような状態
会社統合しました！といっても、4月に入って統合日を迎えてからようやく実際に社員同士での関わりやコミュニケーションができるようになり、同時並行で組織構造の再編も進められはじめた状況下だったので、プロジェクトが動き始めた6月頃はまだまだ2つの組織がお互いのプロダクトや人について情報交換しながら一緒に方針を探ってく、そんなようなステータスでした。
細かいところでいうと、追っている指標の言い回しや定義さえも異なりますし、互いのプロダクトも乗務員向けというtoBプロダクトなのもあり、まず市場に出回っている双方のプロダクト挙動・機能をみることが叶っていなかったので、本当に第一歩としてお互いの常用している用語の理解とプロダクトを触り合うところから、の開始でした。
②統合版アプリの大方針決めについて
そんな中で、乗務員向けアプリを統合していくにあたり、どんな機能をつくるか、どんな体験にしていくか、以前のもっと前段の部分で決めておかねばならないことが、大きく3点ありました。
1：新規でアプリを作るか？どちらか既存のアプリに寄せるか？
2：いつまでにどこまでをスコープとするか？
3：開発はアジャイルで進めるか？ウォータフォールで進めるか？
1：新規でアプリを作るか？どちらか既存のアプリに寄せるか？
プロダクトの統合自体の目的が、開発効率の最適化と中長期的にみたときの事業としての収益性向上でしたので、エンジニアマネージャーを中心に今ある2つのプロダクトのうち片方に機能追加をし1つに寄せていくのか、それとも第3の新アプリを作り出し、今ある2つのアプリを新アプリに移行させるのかを検討していきました。
結果的には、可能な限り他プロダクトへの影響を抑えつつも今後の改善がしやすいように、システム同士の親和性があるものは既存アプリを流用し、でもUIなどは見直して新しくするといった形で、"極力影響範囲を広げすぎずに今後の開発の効率化を叶える"ことに重きをおき、新規アプリだけど使えるところは流用する、という形に着地しました。
2：いつまでにどこまでをスコープとするか？
二重開発にはなってしまうものの、そのままの状態を維持していてもご利用いただいている事業者や乗務員にもそれだけでは何か負担をかけるものでもなく、ただただ現状維持となりますので、当初は明確なおしりが存在しているわけではない状態でした。
ただ、プロジェクト進行開始に伴い連携している外部システムの提供会社様と新アプリに関する契約条件をすり合わせる中で、一定の期間までにここのラインまでシェアを広げてほしい、というオーダーが出てきたので、そのラインまでシェアを広げるにあたって、現行機能×対応ハードウェアの組み合わの中でいくつか実装プランのパターンを作り、どこまでをスコープとしたプランが現実的かを吟味し、仮のおしりとスコープを設けました。
3：開発をアジャイルで進めるか？ウォータフォールで進めるか？
よくアジャイルか、ウォータフォールか、という派閥にも近いような二者択一の話がされることが多いですが、個人的にはどの開発手法を用いるかは、あくまでも手段であって目的ではないので、手法のお作法を忠実になぞっていくことにこだわらず、プロジェクトのゴールとを照らし合わせた上で、双方のいいとこ取りをし、仕組みを取り入れていくべきだと考えています。
今回は結論から言うと、チームで話し合い、全体の大枠スケジュール・進行管理はウォータフォール的に進めつつ、見積もりや日々の開発進捗確認はアジャイル的に進める、というハイブリッド型で進めていきました。
(結果としてどうだったか、は後編で触れようと思います。)
今回このような選択になった理由ですが、統合直後で互いのプロダクトやシステム理解もまだ不完全な中、長期スパンでのプロジェクトになることは必須だったので、何らか途中で仕様や計画が変動した際にも臨機応変に対応をしやすくしたり手戻りを少なくしたいため、アジャイル型で進めたい、という声がチームからまずあがりました。
いっぽうで、プロダクトの性質上、乗務員向けアプリは各事業者のほうで乗務員に使い方などを教育し、実際の現場で使っていただく、というフローになるため、数ヶ月前には事業者に対してどういうプロダクトになるのか、どういう機能感・使い勝手なのか、という部分を周知・説明をし、スケジュールに一定の合意を得ておく必要性があります。
◇タクシー事業者と数か月前からスケジュールを合意しておく必要がある
・サービス導入前に、乗務員へのトレーニングやフォローが必要なため
・新アプリに切り替わることで一時的に事業者の追っているKPI数値に影響がでうるため
・事業者によっては特殊な外部システムと連携しており、そちらへの連携も含めて問題がないか実車両でテストするなど、事前に綿密なすり合わせが必要なケースもあるため
アジャイル開発のうちスクラムの形式では「スプリント内に完了しなかったものは、次のスプリントで対応を行う」ことが一般的ですが、直前でリリースが1週間2週間ずれるという場合はステークホルダーとの調整が難航したり、タクシー事業者からの信頼を失ったり、余計な手間をかけさせてしまったりと、許容されないことが多々あります。
今回は新アプリに切り替わることになるので、普段以上に前もっての調整が大事になってきます。そのため、一定期間前からはもうおしりがずらせないものとして、プロジェクト全体の進行管理はウォーターフォール的に行いたく、前述のハイブリッド型に落ち着きました。
③大方針はきまっての着手フェーズに行ったこと
大方針が決まってから実際に開発着手にあたり、ざっくりチームで以下のようなことを行っています。
■目線合わせ
・インセプションデッキの作成
・業務フロー、ユースケースの洗い出し
・双方プロダクトの機能一覧化、差分洗い出し
■要件決め
・PRD(プロダクト要求仕様書）の作成
・設計に関する個別議論の整理
・連携外部システムの仕様確認、要望上げ
■デザイン
・デザイナーによるインタラクションフローの作成
・デザイン作成
■プロダクトに関する社内の合意形成
・経営層、営業やカスタマーサポートなど関連部門との読み合わせ(PRD、デザインフロー)
・実機で、動くものを実際に触りながら確認いただく場の用意
・社内向けFAQの用意
■実装
・一定周期での進捗確認と、できたもの共有会(スプリントレビュー)
・要件では未定義だった詳細仕様の方針決め
・管理画面やユーザーアプリなど他プロダクトとの連携や対応依頼
■対外基準チェック
・法務でのクリアランスチェック
・交通安全に配慮できているかの安全レビュー
■品質確認
・品質管理部門によるテスト項目作成とテスト実施
・乗務員にプロダクトのプロトタイプを触っていただく
・机上だけでなく実車両に取りつけての走行テスト
・不具合のトリアージ(優先度判断)
■リリース前準備
・事業者、乗務員へのマニュアルや周知準備
・リリース後のアプリの展開マイルストーンを検討しておく
・KPIなどチームで見れる分析レポートの準備
■リリース後準備
・利用者からのお問い合わせ発生時の体制、運用決め
・新規導入や拡大が行われる際の体制、運用決め
・アプリの入ったタブレット端末側が故障したときの運用決め
続く後編にて、特に開発・実装に関わる部分を中心にいくつかピックアップして取り組んだことの具体を紹介できたらと考えています。
後編の概要紹介と企画宣伝
以上、前編としまして競合同士だった2つのプロダクトを1つに統合するために、どういう状況下でどのようにして大方針を決めていったのかをお話させていただきました。
続く後編としましては、以下のような内容を予定しています。
月内には出したいな、と思いつつ記事を書くことに慣れていないので、白目を向きながらがんばります。。生暖かい目で見守ってください。。
(ちょっと変わっちゃったらごめんなさい)
前編の続きとして以下を予定しています。
③、着手フェーズに行ったことの具体をいくつかピックアップしてご紹介
④、プロダクト統合のつらみと反省
⑤、現在とこれからについて
そして最後に宣伝です…！
Mobility Technologiesでは、現在"ウラ凸"としてMobility Technologiesのウラ側へ、カジュアル面談で突撃しよう！という企画を実施中です。
もし移動・モビリティの分野や、PdMとしての業務に興味を持たれましたら、こちらからお気軽にお声がけください＾＾
最後までお読みいただき、ありがとうございました。
この記事が気に入ったらサポートをしてみませんか？