見出し画像

pmconf2023登壇 | 事業のターニングポイントに向けて、開発ロードマップの"策定"と"達成"のためにPMがやったこと

こんにちは。
Luupという会社でユーザー向けアプリのプロダクトマネージャーをがんばっています。Genyaです。
(※ この記事はLuup Advent Calendar 2023の3日目です)

2023/11/29、プロダクトマネージャーカンファレンス2023の公募セッションに採択され、登壇してきました。

pmconfはずっと視聴者として参加してきましたが、話す側としても一度ぐらいは出てみたいなと思っていたので、とても嬉しい一日となりました。

会場入口。久しぶりのオフライン参加でした。

当日お話しした内容と感想について、このnoteで一部解説しながらまとめておきたいと思います。

登壇内容

話したテーマは『事業のターニングポイントに向けて、開発ロードマップの策定と達成のためにPMがやったこと』です。

2023年7月1日に改正道路交通法が施行され、取り組む事業ドメインのルールが策定されるというターニングポイントをLuupは迎えました。

そんな中でPMとしてロードマップをつくるにあたって考えたことや、達成に向けて実際に行ったことを発表しました。

登壇資料

当日の資料はSpeaker Deckにupしています。
以下に詳細を記載します。(※とても長くなってしまったので、目次からご興味のある部分をご覧ください)


前提

LUUPは、”街じゅうを「駅前化」するインフラをつくる”というミッションのもと電動マイクロモビリティのシェアリングサービスを運営しています。
"ポート"と呼んでいるモビリティを借りる場所・返す場所を、街じゅうの至るところに展開することによって、人の移動の選択肢を増やすことを目指しています。

モビリティとしては、電動キックボード・電動アシスト自転車の2種類を提供しており、電動キックボードについては、政府の実証実験に参加することでこれまでサービス提供してきていました。

そんな中、今年の7月1日に、”改正道路交通法”が施行されました。
電動キックボードをはじめとする、電動マイクロモビリティ専用の交通ルールが初めて定められることとなりました。
この改正によって、一時的な実証実験の枠組みではなく、決まった法律のもとで電動キックボードのシェアリングサービスを運営できるようになりました。

事業者としては定められた新しい法律を遵守する形で、事業を運営する必要があり、プロダクトやオペレーションのアップデートが必要になります。

改正内容自体は2022年の4月には公表されていたものの、施行日の2023年7月1日は2023年1月下旬に初めて発表されることとなり、我々に与えられたタイムリミットは半年弱でした。

また、法律には明記されないような事業者が守るべきガイドラインや、保安基準などが別に存在していて、それらを含めたMustな要件のすべてがわかっていない状態でした。

つまり、場合によっては施行日である7/1から継続的に電動キックボードをユーザーに提供できるのか、あるいは一時的にサービスを中断しなければならないのか、不明な状態でプロジェクトが進行することとなりました。

そういったピンチな状態ではありましたが、とはいえ改正法の施行は大きな機会でもありました。
実証実験時と比較して、(1)利便性が向上し、(2)手に取れる利用者層も広がります。(3)ルールや罰則も電動マイクロモビリティの実態に合ったものが決まり、分かりやすいものとなりました。

7月1日からも継続的にサービス提供ができるかという不確定な状況ではあるものの、サービスの理解浸透・利用拡大の大きなチャンスにするために、施行日に集中する動きへ 全社的にシフトすることとなりました。

ゴールの考え方

半年弱の期間の中でまず最初に考えたことは、法律を遵守するためのいくつかの開発案件は期日までに必達しなければならないということです。
不確実性をはらんだ進行の中でも、遅延は許されないということを強く意識していました。

一方で、法律が変わるということ、それに対して興味関心を持ってもらえる可能性があるということは、事業運営上 やはり2度とはやってこないイベントです。
振り返ったときに「これがターニングポイントであった」というものにするべき大きな機会だなと考えていました。

状況は変化する可能性はありつつも、7月1日を起点として、そこから事業がさらに伸びていくというのが作りたい成果です。
そのためにはプロダクト開発で出来ることが何があるかを考えるべきで、いま見えている情報の中で、最善手を計画することが必要であると考えを改めました。

設定したゴール

7月1日から利用のスタートダッシュを切れる状態に仕上げること。そして、事前期から利用者の皆さんへのワクワク感を醸成することをゴールとしました。

成功イメージを逆算したときに、7/1から初めて興味を持ってもらうのではなく、すぐ試したくなるような期待値をしっかりつくっていくことが大事だと思いました。
そして何より、当日には安心・安全に利用いただくことが重要で、交通ルールなども変わる部分があるので、事前にルールの変化を正しく理解してもらいたいと考えていました。
LUUPはどこかに移動したいそのときや、次の用事の前に使われるサービスなので、ゆっくり知識をインプットできないことがストレスやプレッシャーになってしまうシチュエーションが起こるのはなるだけ避けたいと考えていたので、早め早めに情報を提供していきたいとも考えていました。

時間枠の捉え方

そういったゴール設定から、与えられた時間枠に対して「どこに何を置くべきか」「いつなにを達成したいか」という意思を持つことができました。

期日を守ることを第一に考えると、後ろから順番に並べていくことだけに終始しますが、ゴールイメージをもつことによって、与えられた時間枠の"全体"を俯瞰して、適切なタイミングで配置し、成果を最大化するためのマッピングを考えることができたと思います。

半年弱の期間は「それなりに猶予があり、どうにかなる長い期間」という捉え方もできるかと思いますが、"いつまでには何を出したい"という見通しを立てることで、最初期の企画・設計時点から健全な焦燥感をもつことができました。
また、各部署への連携や事前のユーザーリサーチを行うことなど、ロードマップ作成のプロセスでは焦点の当たりづらいアクションも、自然に生まれることとなりました。

ロードマップ達成のために意識したこと

後半では、策定したロードマップを達成するためにPMとして(あるいは開発チーム全体として)やったことの実例をお話ししました。

開発遅延や工数の肥大化を防ぐためには、チーム運営上のリスクを取らず、教科書的なTipsや基礎的なプラクティスをいかに徹底できるかということが重要です。

今回の取り組みでは「進捗が大きく遅れないようにやったこと」と「小さな遅れが積み重ならないようにやったこと」の2つアクションを行いました。

大きく遅れないようにやったこと

1.既存のロードマップをすべて捨てる

前半部分で紹介したロードマップを作る前に、進行途中のロードマップを一度白紙にする意思決定をしました。
ロードマップを立てた当初の状況からは 全く違う戦局になっており、従来の考え方・やりたかったことに固執するメリットがほとんどないと考えたからです。

全社戦略にしっかりアラインできるような余白を最大限につくりたいと思っていたことと、なにかが起きたときに耐えられる最低期間としてのバッファを最初に取ることを意識してのアクションです。

2.可能な最大範囲の共通認識を最速で取る

「どんなアップデートや新規開発があるのか」「既存のアプリフローにどういった差分がうまれるのか」。これらを想像がつく最大限の範囲で可視化して、チームみんなで共通認識を取ることを早いタイミングで行いました。

これにより、PMが見えていないタスクがたくさん出てきたことと、「ここは大体決まってる・ここは全然決まってない」というような共通認識をとることができました。注意しなければならないポイントのアンテナを皆で持つことができ、あとから大きな遅延につながるような問題が露見するような事態を事前に予防できたと考えています。

3.有事だからこそ、慣れている開発スタイルを貫く

開発ワークフローにチャレンジがあると、足元から崩れていくおそれがあるので、慣れている開発スタイルにできるだけ近づけることを考えていました。
Luupのアプリ開発は2週間スプリントで進行していたことから、半年間の活動を細かいチケットに分解し、7月までの期間(10個ほどのスプリント)に並べていくことで、平常運転化することを試みました。

これによって、「どういう順序や速度で」「誰がなにを完了させていくのか」が早くから想像できる状態になったことに加えて、「ひとつひとつをいつもどおりにこなしていけば達成できる、無茶な計画ではない」という算段がついたことが精神的にも非常に大きかったと考えています。

余裕があるわけではなかったので、いつもの開発スタイルをより一層強固なものにして、盤石な進行にしていきたいという改善意識が芽生えたことも副次的な効果だったと感じています。

小さな遅れが積み重ならないようにやったこと

1. PM間の持ち場・裁量を明確にわける

続いて、小さな遅れが積み重ならないためにやったことを5つ紹介します。

まず最初に、PM間の持ち場や裁量を明確にわけました。
責任範囲・決定権を明確にすることで、確認や合意のプロセスによってテンポを悪くすることや、責任範囲を曖昧にすることを避けるためです。

2.キメの問題はすぐキメる

キメる必要のあるものが何か出てきた時には すぐに決めきることで、「決まったこと」と「まだ決められないこと」の2つの分類に早く着地させ、よどみなく開発を進行することができます。
中途半端なステータスのものがスタックすると、企画・デザイン・開発の手を止めることがあるため、キメるアクションは基礎的なプラクティスではありますが、優先的にやっていくことがPMとしての大事な役割だと思っています。

3."ついでに"と"欲張り"の線引をシビアに見る

いろいろなアップデートを行っていく中で、「ついでに修正したい」という誘惑に駆られることも多いです。本当に「ついで」で出来るものなのかは冷静に判断することが求められます。
一見簡単にできそうなことも、デザインや開発においては「意外と面倒」ということもありますので、都度会話をしつつ ”やれるといいな”という欲張りは切り捨て、要求をシャープにしていきました。

一方で、シビアに切り捨てすぎると「表立った改善が何もない」という期間が長く続いてしまうので、本当に一緒にやれてしまう改修はうまく取り入れられるように、良い塩梅の線引を意識しながら進行していました。

4.不確実性の低い案件こそ なる早で終わらせる

不確実性の"高い"案件のリスクを早期に小さくしていくことはもちろん意識するところですが、不確実性の低い案件にも油断しないことが重要だと考えていました。
期日が決まったプロジェクトは時間がどんどんなくなっていくので、時間あたりのスループットを高めることが、進捗をつくる上で非常に重要になってきます。
確実にこなせるものは余裕を持たずになる早で終わらせてしまうことで、不確実性の高い案件にフォーカスできる環境を長く維持することができたと考えています。

5. 他部署コミュニケーションはシナリオを明確にする

部署間では役割が違ったり、お互いの情報のすべてが見えているわけではないので、すれ違いにより進行のブロッカーが生まれることはあるあるかと思います。
他の部署と連携して動く際の工夫のひとつとして、シナリオを明確にしたコミュニケーションすることが予防策として考えられます。

たとえば、他部署に何か決めてほしいというような場合には「X日までは待てるが、X日をすぎると影響が大きい」「Xだけはキメてほしいが、Xはあとからでも問題ない」など、作りたい進行シナリオや、"これだったら許容できる"というシナリオを明確にすることがポイントです。
お互いがお互いの要件を外さないような情報を共有することで、連携すべき箇所でしっかりと役割を果たせる状態がつくりやすくなると思います。

まとめ

結果として、メンバーみんなの頑張りのおかげで、日々の開発は最後までテンポ良く進行することができ、すべての案件が7月1日までにリリースされました。

しかしながら、ロードマップに関しては想定外はやはり発生するもので、最初のロードマップ通りの進行にはなりませんでした。
時間を突き詰めた進行をしましたが、最終的に残ったバッファは小さいものでした。予防策が足りずに何かが大きくずれていれば、ギリギリの進行になっていた可能性が高かったんじゃないかと思います。

私自身の学びとしては、「基本を徹底すること」の重要性を改めて感じたことが一番大きかったです。
今回の登壇でお話した内容も学びの"基本の基"である振り返りによって、あとから自覚したものも一部含まれています。

登壇後にいただいた質問やコメント

登壇セッション終了後には「Ask the speaker」というコーナーがあり、Discordをつうじて視聴者が登壇者に対して質問や感想を直接投げかけられる時間がありました。その場で回答した内容について紹介します。

Q1. 対応したチームは何チームあったか?  1チームなのか複数チーム横断でやっていたのか

A:アプリ開発の体制はPM・Design・iOS・Android・Backend・QAのチームが主体。進行上は他部署(ex: マーケや広報)との横断的な連携はもちろんあり、連携のフロントにはPMが立つことが多い。

Q2. 体験設計がすごくシームレスだった。横断チームだとしたらどのようにすり合わせをしたのか?

A:アプリ上の体験設計はPMとデザイナーに裁量を委譲してもらえている。アプリ全体をスコープとした上で、どこにどのようなアップデートをかけるのかという全体像を俯瞰した上で半年の開発計画を立てることができた。
そのため、体験を構成する各パーツやフロー間でのすり合わせは不要で、すべてを一体にして、各部署とは議論を進めることができた。

Q3. 既存のロードマップはいつ捨てたのか?

A:捨てることを決めること自体は施行日が決まったと知ってすぐ。
ただ、最初期段階はやることが明確に詰まってはないので、現行のロードマップで既に着手しているものを進行することや、軽微な不具合の修正対応などその時にやれることをした。

その他 コメント

イベント終了後の懇親会などで声をかけてくださった方には「いまの事業の状況と照らし合わせて参考になった」「期日が決められてしまっていて、めちゃくちゃ苦労が想像できました」などのコメントをいただきました。

ありがたいことに、X(Twitter)でも感想をポストしてくださっている方がいました。

おまけ:カンファレンスに参加してみての感想

当日は、うちの頼もしいデザイナーがこの日を見据えて用意してくれたオリジナルウェアを着て挑みました。LUUPロゴを見て声をかけてくれる人もいたので嬉しかったです。

LUUPロゴが入ったカッコいい一張羅。背中にもイケてるプリントがあるけどリュックを背負っていると見えないことに気づいたので次からはカバンも考えます。
toCサービスのPMと話したいと言ってたら、懇親会ではたくさんのtoCな人が現れてくれました。みんないつもどこにいるんだろう。

登壇された方も、聞く側で参加された方も、PM間の情報交換や勉強会の機会などを模索されていて、みんな悩んでいるんだなぁということを肌で感じることができました。
昔仕事でお世話になった人や、友達の友達みたいな人にも出会うことができたので、リアルの場に出ていくのも悪くない(むしろ良いな)と思いました。

pmconf運営の皆さまありがとうございました。そして登壇スライドを作っている最中にはチームの皆の頑張りにも改めて感謝の気持ちが湧き上がりました。

来年もなにかしらで参加します!


この記事が参加している募集

PMの仕事

この記事が気に入ったらサポートをしてみませんか?