PdMによるブログリレー@MoT「GOアプリ新規開発のフローとPdMの役割」
この記事は、株式会社Mobility Technologiesのプロダクトマネジメントチームが企画している「プロダクトマネージャーブログリレー2022」の記事です。
はじめに
はじめまして。株式会社Mobility Technologies（以下、MoT）でプロダクトマネージャー（PdM）を担当しているTannyです。現在、No.1※タクシーアプリ『GO』と、その法人向けサービス 『GO BUSINESS』を担当しています。
※ App Annie調べ｜タクシー配車関連アプリにおける日本国内ダウンロード数(iOS/Google Play合算値) 調査期間：2021年1月1日~2021年12月31日
MoTでPdMを担当し始めてから半年が経過し、今ではPdMとしての仕事の進め方もおおよそ分かってきました。しかし私はこれまで、PdMという職種が明確に存在しない職場で開発をしてきたので、開発プロセスにおいてPdMがどういう役割を果たしているのかよくわかっていませんでした。
そこで今回は、これまで経験を振り返り、MoTでのGOアプリの新規開発フローを整理し、その中でのPdMの役割をご紹介したいと思います。MoTではどのように新規開発をしていて、その中でPdMがどんな業務をしているか、イメージしていただければ幸いです。
ここでは、GOアプリが起点となる新規開発案件の、一般的な開発フローをご紹介します。実際の開発業務の全てを網羅しているわけではないので、ご了承ください。
今回は、MoTでのアプリ開発フローを以下の8ステップに分け、順にご紹介していきます。
STEP1｜WhyとWhatを考える
STEP2｜PRDを書く・デザインを検討する
STEP3｜PRDをレビューする
STEP4｜見積もる・スケジュール化する
STEP5｜開発する
STEP6｜テストする
STEP7｜リリースする
STEP8｜振り返る
STEP1｜WhyとWhatを考える
GOの事業では、プロダクト責任者・事業責任者・開発責任者がプロダクト開発の大きな方向性やロードマップを議論して決めています。予定した時期が来たら、ロードマップ上の開発案件がPdMに割り振られることになります。
GOアプリでは、基本的には1つの案件に対して1人のPdMがアサインされます。ここでPdMは、その案件が成功すること（事前に定めた目標やKPIを達成すること等）を担うこととなります。
最初に考えること
案件にアサインされたらまず、その案件の「Why（なぜやるのか）」と「What（何をやるのか）」を整理します。ロードマップに書かれている時点である程度整理されていますが、ロードマップは半年〜1年以上前に決められている場合も多いです。そのため、今の状況を踏まえてPdM自身がもう一度WhyとWhatを考え直し、腹落ちさせるようにしています。ここで自分が納得できるまで考え尽くせていないと、後に関係者を巻き込んで開発を進めるときに、案件の重要性・必要性をうまく説明できなくなってしまいます。
最初に考える項目
■ Why（なぜやるのか）
→どんな課題を解決したいのか、何を目標とするのか
■ What（何をやるのか）
→課題をどのように解決しようとしているのか
■ ターゲットユーザー
→どんな属性のユーザーをターゲットとしているのか
■ なぜ「今」やるのか
→他の案件を差し置いても、今やる理由は何か
ここではWhatとWhyの他にも、ターゲットユーザーを整理することを忘れないようにしています。GOのユーザーは様々な属性があるので、「ヘビーユーザー」「初回利用ユーザー」「首都圏のユーザー」「全てのユーザー」など、どのユーザーを対象としているのかを整理します。
なぜ「今」やるのか
さらに、なぜ「今」やるのかということも整理します。GOでは自分が担当している案件の他にも、ユーザーからの改善要望や、運用の改善、他プロダクトの案件などなど。。。GOでは色々な案件が実装を待っている状態となっています。ロードマップに置かれていると、それを順番に実施することに疑問を持たなくなりがちですが、なぜ自分の案件を今やるべきなのかということをしっかり説明できるようにしています。
STEP2｜PRDを書く・デザインを検討する
WhyとWhatを自分の中で納得できるまで整理できたら、「PRD（プロダクト要求定義書）」の作成に取り掛かります。
MoTでは、PdMがPRDをしっかり書くことを重視しています。GOはユーザー向けアプリの他にも、乗務員向けアプリ、事業者向けアプリなどのプロダクトで構成されており、アプリの変更が他プロダクトにも影響を与えることが多々あります。
そのため、PRDの形でやりたいことをドキュメントに起こし、この組織図に書かれている関係者のフィードバックをもらうことが重要になります。
PRDに書くこと
PRDには主に、「その案件で実装したい仕様」を記載していきます。スマホアプリの仕様を記載するほか、CSチーム向けの問い合わせ対応ツールや、設定変更用の管理者向けツールなど、周辺プロダクトの仕様も記載するため、GOのプロダクト全体の理解も必要です。
その他、先ほど整理したWhy, Whatなど、案件に関する情報を追記しますが、詳細は割愛します🙇♂️ 。内容としては他社で使われているものと大きく変わらないと思います。PRDに記載する内容については以下の記事が参考になるので、引用させていただきます。
並行してデザインを検討する
PRDをおおよそ書き終わった段階で、デザインチームに内容を共有し、Figmaでラフデザインの作成を進めてもらいます。Miroなどを使って自分でワイヤーフレームを描くこともありますが、実際のアプリのデザイン制約に基づいてデザインしてもらうことで、動作をより具体的にイメージすることができます。また、最初のPRDでは欠けていた機能や、アプリでは実装が難しいUIなども顕在化するため、完成度・実現度の高いPRDにすることができます。
先ほどのPdM組織図にも記載されていましたが、PdMとデザイナーは同じ組織に属しています。そのため、検討段階でも気軽に相談しやすい環境になっています。早い段階で、プロの目線でデザインを検討してもらえるため、UI・UXを意識した仕様検討が可能となっています。
STEP3｜PRDをレビューする
PRDを一通り書きおわり、説明可能な状態になったら、関係者でPRDレビューを行います。レビューの意見を反映し、PRDをブラッシュアップします。
主なレビュー先と確認観点
■ ステークホルダー（事業責任者など）
→ ロードマップに書かれていた時の想定とズレがないか。
■ アプリ開発チーム
→ 実装上の懸念点がないか。より効率的な仕様は考えられないか。
■ QA（品管）チーム
→ 特殊な操作（アプリ強制終了など）をした時の仕様が検討できているか。アプリの他の機能に影響を与えないか。
■ データ分析チーム
→ KPIの策定や、ダッシュボード化の依頼。
■ ヘルプデスクチーム
→ 問い合わせ対応の方法は検討できているか。
■ 乗務員向けアプリのPdM
→ 追加した情報を、乗務員が理解できる形でアプリに表示できるか。
■ 事業者向けシステムのPdM
→ 料金体系や支払い方法を変更する場合、表示・訂正などを実施できるか。
このように、レビュー先が多くて大変な作業ですが、色々な目線からの意見を集約することで、PRDの完成度を高めることができます。また、GOアプリのPdM目線では気づけなかった見落としも発見できるので、実装中の出戻りも最小限にできます。
レビューの際に注意することは、最初にWhyとWhatをしっかりと伝えることです。ここで認識を合わせておくことで、プロダクトの完成後の状態を共通認識として持っておくことができます。
STEP4｜見積もる・スケジュール化する
PRDレビューと修正が完了したら、関係プロダクトの工数見積もりを行い、スケジュール化します。
これまで紹介してきたように、GOのサービスはさまざまなプロダクトで構成されています。そのため、GOアプリが起点の開発であっても、Backendや他のプロダクトとの足並みを揃えて開発を進める必要があります。
MoTでは、複数のプロダクトの見積もりをまとめ、スケジュールが合うように要員アサインの調整などを実施する役割を、プロジェクトマネージャー（PjM）が担っています。もしPdMだけでこの作業を実施すると、自分の担当外の案件の開発状況も常に考慮する必要が出てくるため、「担当案件を成功に導く」というPdMの役割に集中できなくなってしまいます。PdMとPjMの業務が分担されていることで、PRDの要求事項をスムーズに開発していくことができるのです。
また、PRDには要求事項ごとの優先度を記載しておきます。もし予定していた期間内で全ての要求を実装できない場合、この優先度に基づき、どこまで実装するかをPjMと相談することになります。
STEP5｜開発する
スケジュール化が完了したら、各プロダクトの開発がスタートします。私はGOアプリの開発状況を主に見ていくことになります。
GOアプリの開発体制
GOアプリでは「Large-Scale Scrum（Less）」という開発体制を取っていて、3つのアプリ開発チームが並行して開発を行なっています。このうち1つのチームに案件をアサインし、開発がスタートします。
なお、この開発体制の詳細や、これに至った経緯については、ブログリレーの別記事で紹介していますので、こちらをぜひご覧ください。
スクラム開発
ここからは、一般的なスクラム開発の流れがスタートします。開発は少人数のチームで行うため、実装上の課題点や変更したい点があれば、デイリースクラム（朝会）などでサクッと相談して解決できます。ここでのPdMの役割は、案件のWhyとWhatに基づいて、課題に対してどう対応すべきかをメンバーと議論することです。
このフェーズでは他のプロダクトも並行して開発が進んでいます。しかし開発状況によっては、当初のスケジュール通りに進まないことも当然あります。その進行状況はPjMが把握しており、必要に応じてスケジュール調整などを行います。これにより、各PdMは自分の担当プロダクトに集中して開発を進めることができます。
STEP6｜テストする
各プロダクトの開発（単体テストまで）が完了したら、結合テスト工程に進みます。ここまで紹介してきたように、GOは複数プロダクトの組み合わせで構成されているため、結合テストが特に重要な工程です。
バグバッシュ
アプリ開発チームでは、「バグバッシュ」というイベントを取り入れています。バグバッシュとは、QAチームにテストに出す前に、開発チームでプロダクトを触って不具合を出そうという会です。みんなで一気に触ってみることで、OS間の挙動の違いや、デザインの違いのような、開発中に見落としがちな軽微なバグを発見できます。
ちなみに、バグの発見件数が多かった人は「バグ王👑」として表彰されるので、みんな競い合いながら楽しく実施できます。「バグが検出される」というと、これまでネガティブなイメージがあったのですが、みんなで成果物を触りながら楽しく品質を高めていく、前向きなイベントだと感じています。
バグバッシュについてはアプリ開発のメンバーがTechブログにまとめていますので、ぜひご覧ください。
結合テスト
バグバッシュが完了したら、PdMが一通りのテストを再度実施し、品管チームでのテストに進みます。配車システムに関するテストの場合、スマホアプリの動作だけでなく、タクシーを配車依頼し、乗務員アプリで受け付け、事業者アプリで結果を確認する、という一連の流れが必要となり、各プロダクトの仕様にも精通している必要があります。そのため、MoTではPdM組織内にQAチームを設けており、テスト環境の構築・実施や、テストノウハウの蓄積・向上を担っています。
テストの中で不具合が検出された場合、Jiraでチケットが発行され、基本的には開発メンバーが改修を行います。しかし不具合内容によっては、「そもそもこの仕様はどうするのが正しかった？」と迷うこともあります。その場合にはPdMも参加して、改修の方向性を議論します。
実車テスト
検証環境でのテストが完了したら、最後は本番環境でのテストを行います。このテストは最後の関門となるので、基本的にはPdMが実施します。本番環境のテストでは、タクシーに実際に乗車して確認します。本番環境用の机上配車のツールもありますが、やはり実際のユーザーが使う環境で確認するのが一番です。物理的に移動するテストは、モビリティサービス特有の面白さだと思います。
STEP7｜リリースする
テストが完了したらいよいよリリースです！が、リリース前にはいくつか準備するべきことがあります。
リリースに向けた準備
新機能はリリースするだけではなく、ユーザーに実際に使ってもらって初めて価値を発揮します。そのために、PdMはセールスチームや渉外チームと連携し、以下のような準備を行なっています。
新機能の価値をユーザーに届けるための準備
■ ユーザーに認知してもらうための施策
→ マーケティング施策やプレスリリース作成のための、新機能の情報の提供
■ ユーザーに機能詳細を理解してもらうための施策
→ユーザー向けマニュアルやFAQなどの素案作成、レビュー
■ 問い合わせ対応の準備
→ヘルプデスクチームと、問い合わせ時の対応方法について整理
ここに挙げた準備事項は一例ですが、ユーザーとプロダクトとの接点となる部分にはPdMが必ず関わることになります。「PdMだから何でもやる」のではなく、「プロダクトの価値を最大化することは何でもやる」という意識で活動しています。
本番リリース
ここまでの準備が全て完了したら、いよいよリリースです！アプリの更新後にタクシーに乗車して新機能を確認したら、リリース作業は完了です🎉
案件によってはプレスリリースを出したり、CM放送にアナウンスを追加したりと広報活動もスタートし、多くのユーザーの目に触れていくこととなります。
STEP8｜振り返る
PdMの業務は本番リリースが終わりではありません。プロダクトの価値を最大化できているか、最後まで見届ける必要があります。
プロダクトの成果の振り返り
リリース後は、データ分析チームに用意してもらったダッシュボードでKPIを確認します。PRDレビュー段階からデータ分析チームに参加してもらっているため、リリース直後からKPIを確認できるようになっています。
KPIが想定通りであればそれを継続できるように、そうでない場合は別の打ち手を検討できるように、セールス担当チームなどと一緒に、プロダクトを見守っていくことになります。
ちなみに、これらのKPIはSlackでの通知や月次の報告会を通じて、GOの関係者全員が把握できるようになっています。一緒に開発してきたメンバーと、狙い通りの効果が出ていることを共有できるのは、PdMを担当していて一番やりがいを感じます！
開発チームとの振り返り
案件の効果の振り返りだけでなく、開発フロー自体の振り返りも、もちろん実施します。リリース後のなるべく早い段階で、開発チームメンバーでKPT（Keep, Problem, Try）をベースとした振り返りを実施します。今後も開発すべき案件はたくさんあるので、開発フローを常にアップデートし続けています！
おわりに
私がMoTに来てPdMを担当する以前は、「ウォーターフォール・外注開発」を中心としてシステム開発を行っていました。それが「アジャイル・内製開発」という真逆のフローに代わり、最初は違いに戸惑うことも多かったです。
何度かサイクルを回してきて、基本的な流れも分かってきたので、この機会に現状の開発フローを整理して振り返ってみました。今後はより良いプロダクトの開発に向けて、フローの改善案を提案・実践していければと思っています！
現在、Mobility Technologiesではプロダクトマネージャーとして一緒に働く仲間を募集中です。
Missionは移動で人を幸せにすること。現代の移動革命を我々と一緒に実現しませんか？
Mobility Technologiesではカジュアル面談も実施中です。こちらから気軽にお申し込みください。
この記事が気に入ったらサポートをしてみませんか？