※2024年3月14日に開催したオンラインイベント「プロデザ BY RECRUIT VOL.17　　3つの不確実性と向き合った 『じゃらんnet』公式アプリの高速リニューアル事例を大公開」から内容の一部を抜粋・編集しています。

プロダクトの変革を阻む3つの「不確実性」

橋本：『じゃらんnet』公式アプリのプロダクトマネージャーを担当しています、リクルート プロダクトデザイン室の橋本悠と申します。

本題に入る前に、プロダクトマネージャー（以下、PdM）のみなさんはこんな悩みを抱えていませんでしょうか？

「プロダクトを大きく変革したいけれど、なかなか踏み出せない」

この悩みですが、具体的には以下の三つに分解できると思っています。

（1）検証したい仮説が多くて、どこから手をつけよう……
→「スコープが不確実」という悩み

（2）目の前にマストの対応案件がたくさんあって、変革の部分に開発工数が割けるのか、どれくらい時間がかかるのか……
→「デリバリーの不確実性」に関する悩み

（3）ABテストなどの検証結果が出るまで本番反映が確定できない……
→「成果が不確実」という悩み

これら三つの「不確実性」は、まさに私がこのプロジェクトで直面した悩みでした。
今回は、大きい変革を成し遂げようとするときに、切っても切り離せない不確実性というものをテーマに「不確実性が大きいプロダクトのリニューアルをスピーディーに実現するための3つのナレッジ」という形で、私の経験をシェアできればと思います。

はじめに、プロジェクトにおける「不確実性」について、もう少し掘り下げてみます。

不確実性の概念を図で表してみました。このグラフのように、一般的にプロジェクトが進行するにつれて徐々に「不確実」だったものが「確実」になっていき、不確実性が減少していくプロセスをたどると思います。

最初に挙げた３つの不確実性を時系列でプロットすると、最初に「スコープの不確実性」、続いて「デリバリーの不確実性」、最後に「成果の不確実性」という順で課題になることが多いんじゃないかなと思います。そこで、今回もこの時系列でナレッジをご紹介していきます。

高速リニューアルを実現し、売上への貢献も達成

橋本：本題のナレッジに行く前に、今回の事例の紹介と成果を共有いたします。

今回の事例は『じゃらんnet』公式アプリのリニューアルプロジェクトです。『じゃらんnet』は口コミ数、宿泊施設参画数で国内最大級ということもあって、多くのユーザーさんにご利用いただいています。そのため、プロダクトをリニューアルすることによって影響を受ける関係者も少なくありません。

そんな、『じゃらんnet』アプリをリニューアルした成果がこちらです。

今回はTOP画面をリニューアルし、UXの改善を行いました。その結果、ABテストに勝利し、売上への貢献を達成することができました。
また、こだわったのがスピードで、当初に想定していた工期から3分の1も時間を短縮することができました。

後ほど、このナレッジについては詳しく紹介できればと思いますが、そもそも、どうしてリニューアルに取り組んだのか？　背景についても少しご紹介します。

そこには、プロダクトが掲げている「理想と現実のギャップ」がありました。

私が『じゃらんnet』アプリのPdMとして社内異動してきた当初、こんなビジョンが掲げられていました。

「『じゃらんnet』を宿泊予約サービスから旅行情報サービスに進化させていきたい」

つまり、従来は宿の予約に特化していた『じゃらんnet』の提供価値を、旅行全体に広げていきたいというビジョンです。

上記スライドの右側にある価値のピラミッドでいうと、最上位の「これまでにないプラスαの魅力品質を提供していきたい」というビジョンが掲げられていたわけです。

ただ、当時のプロダクトを見るとそのプラスαの魅力品質の前に、解決すべき課題がありました。たとえば、アプリを起動して最初にバッと目に入ってくるTOP画面には22もの機能が並列に並んでいて、メインのがどこか分かりにくい状態でした。
つまり、このピラミッド上でいくと、魅力品質の土台になる「使いやすさ」や「便利さ」といった、いわゆる一元品質に課題があるという状況でした。

そこで、今回のプロジェクトでは理想とする魅力品質に向けて、「まずは一元品質の改善を早期に達成しよう」というところをゴールに掲げて発足しました。ここまでがプロジェクトの背景になります。

「スコープの不確実性」を突破〜最優先課題にスコープを絞り、一気に改善〜

橋本：ここからが本題です。変革のプロセスで最初に直面した不確実性が「スコープの不確実性」でした。どんなプロジェクトでも、まずはこのスコープを決めることでその後の開発や検証のやり方が変わってくるため、最初に直面する不確実性がスコープではないかと思います。

今回のリニューアルプロジェクトにおけるスコープの不確実性は、端的にいうと「どの機能を、どのフェーズで検証していくか」という不確実性になります。悩ましいのが、機能ごとの効果検証を細かく実施していくと、それだけ検証のフェーズ数が増えて実現までのスピードが落ちていく、というトレードオフの関係にあるところかなと思います。

通常は、やはり機能ごとに細かく検証を繰り返して登っていくやり方が一般的ですが、それをやると例えば1サイクルに9ヶ月かかり、4つの機能全てでその山を登っていくと平気で2〜3年はかかってしまうというように、実現までのスピードに大きな課題があったんです。今回のプロジェクトは、この「時間の短縮」も非常に重要なポイントでした。

そこで取り組んだのは、「本当に最優先で取り組むべき検証のスコープに絞る」ことでした。そのために2つのステップを踏んでいて、1つ目が「課題の仮説」の絞り込み。2つ目が「打ち手の仮説」の絞り込みです。

まず、1つ目の「課題の仮説」の絞り込みです。ここでは最初に定量データの洗い出しを徹底的にやりました。TOP画面の全ての機能ごとに利用率、予約への貢献というところを定量で調べていきました。その結果、「宿の検索パネルへの導線」という部分が、最も売上貢献度が高いことを特定しました。ただ、TOP画面からこの検索パネルに行くためにはワンタップが必要で、「主導線にすぐにアクセスできない使いにくさ」という課題が見つかりました。そこで、まずはそれを改善しようというふうに、課題の仮説を絞り込みました。

2つ目のステップは「検証すべき打ち手の仮説」の絞り込みです。ここでは過去の知見を頼ることにしました。過去にプロダクトデザイン室が行った100件以上のABテストの記録を見返し、振り返り資料も読んで、確度の高そうな打ち手について学んでいきました。

そうやって打ち手の仮説を抽出したあとは、デザイナーに協力を仰いで様々なパターンのワイヤーフレームを作ってもらい、この打ち手を具体化していきました。

この2つのステップを経て、具体的に絞り込んだスコープがこちらです。

メイン動線である宿を「日付と目的地から検索できる検索パネル」。これをトップ画面に配置する。この一点にスコープを絞って、一気にリニューアルすることに決めました。

1つ目のナレッジのまとめです。「スコープの不確実性」に直面したときに、今回は最優先の検証にスコープを絞り、一気に改善するという打ち手を取りました。

多くのプロジェクトでは「何を検証するか？」という絞り込みに頭を悩ませることがあると思います。実際、私自身もこれでいいのかと、すごく不安を感じていました。そんなときは、データや過去の事例など客観的なファクトを「自分が納得できるまで集め切る」ことで、優先課題にスコープを絞るという意識決定ができるのではないかと思います。

「デリバリーの不確実性」を突破〜攻めと守りの二刀流体制で挑む〜

橋本：続いて、2つ目の不確実性です。スコープの不確実性を乗り越えて、次に直面することが多いのが「デリバリーの不確実性」ではないかと思います。

今回の事例でいうと、デリバリーの不確実性は、既存体制で「"守り"のマスト案件」に工数が取られて、「"攻め"のリニューアル案件」が遅延するリスクがあるという不確実性でした。

守りの案件とは、たとえばAndroidやiOSの保守の対応であったり、社内のアプリチーム以外から依頼されるマスト対応であったりします。リニューアル案件を進めている途中であっても、そうした依頼がどんどん舞い込んでくることが予想されるわけです。つまり、既存体制のままで進めると、攻めのリニューアル案件の遅延リスクが生まれてしまいます。

そこで選んだ打ち手が、開発体制を「守りの既存保守」と「攻めのリニューアル」の2つに分けることでした。こうしてリニューアル専門の体制として切り出すことで、守りの案件が入ってきても並行稼働しやすくなり、攻めのリニューアル案件の遅延リスクを極限まで下げる仕立てとしました。

この「攻めの体制」を構築するにあたって重要なポイントだったのが、「エンジニアチームとの、組織を超えた協業」です。「リニューアルの早期実現」は、我々PdMのWillでしたが、そこに「技術的負債を解消したい」というエンジニアのWillが重なった結果が、この組織を超えた協業につながりました。

具体的な解決策を紹介すると、新体制では「Flutter」というiOS、Androidを一つのコードで実装できるフレームワークを採用して画面を刷新することにしました。こうすることで、長年蓄積した「既存の技術的負債を解消する」というエンジニアのWillと「早期にリニューアルを達成したい」というPdMのWillを同時に達成することができる仕立てにしました。

こうして、スコープの絞り込みと新体制の構築によって、当初想定していた期間から1年以上も工期を短縮することができました。

2つ目のナレッジポイントのまとめです。デリバリーの不確実性に直面したとき、今回は「攻めと守りの二刀流体制で挑む」という打開策をとりました。もちろん、組織体制の変更はPdMだけでは実現しません。今回は、開発組織と一緒に「最速で実現しよう」という目標を共有し、プロダクトの責任者に認めてもらえたことが適切な組織体制を築けた大きなポイントだったと思います。

「成果の不確実性」を突破〜積み上げた意義と仮説により実現可能性を高める合意形成〜

そして、最後に直面するのは、検証のタイミングでの「成果の不確実性」です。
今回の事例における成果の不確実性は、端的に言うと「ABテストの結果が出るまで本番反映が確定できない」というものでした。

今回のように大きな投資を伴うリニューアルプロジェクトの場合、本番反映ができないと、それだけ失う投資のコストも大きくなります。そのため、非常に重いリスク、不確実性になるかなと思います。

そこで、短期的なリターンだけでは語れない「プロジェクトの意義」を持つことで、成果の不確実性を乗り越えられないかと考えました。つまり、これまでお伝えしてきたような、積み上げてきた「意義と仮説」を決裁者に相談できる会議に持ち込み、共通認識を形成していくことを目指しました。

具体的には、「このプロジェクトに最優先で取り組む意義」、「できる限り、客観的な事実を積み上げて仮説を作っていること」、そして、「プロダクト組織一丸で、最速で実現するための体制を構築している」といったことを決裁者に共有し、認識を合わせていきました。

その結果、最終的には決裁者であるプロダクト責任者とも合意ができ、「売上の毀損がなければ本番反映していこう」という合意形成ができました。その際、責任者からも、「できるだけ早く変化を」「スピード感にこだわっていこう」という言葉をもらい、プロジェクトの強い後押しになりました。

3つ目のナレッジのポイントです。「成果の不確実性」に直面したときに、より大きい変革を伴うプロジェクトほど確実な成果が求められるという難しさがあるかなと思います。

そこで、今回のプロジェクトでは、積み上げた意義と仮説を決裁者と共有して目線を合わせてきました。結果、短期的な成果の不確実性の中でも実現可能性が高い条件で本番反映の合意を獲得することができました。

以上が、今回シェアしたかった3つのナレッジポイントです。最後に、振り返りとまとめです。

改めて、今回の成果の再掲です。最終的には、ABテストの結果でも勝利して、短期的な売上貢献も証明することができました。そして、もう一つこだわった「スピード」については、当初の工期を3分の1に短縮することができました。

本日は「不確実性」をキーワードに、プロダクトのリニューアルをスピーディーに実現するというナレッジを紹介しました。

今日、このイベントには様々な分野のプロダクトに向き合っている方が参加されているかと思います。どんなプロダクトであっても、不確実性と向き合って、それを乗り越えていくプロセスは欠かせません。今回の事例が少しでも、プロダクト変革に向き合う皆さんの参考になれば幸いです。

質疑応答

Q.ABテストはどのように実施されましたか？
橋本：基本的なABテストのやり方を、今回のリニューアルでも踏襲しています。現状の画面と検証したい画面を同時期に走らせて、コンバージョンレート、売上貢献を比較していくというものです。やり方は一般的ですが、そのなかでも特にこだわったのは「どのパターンを検証するか」という点。今回、本番反映したのは1パターンですが、どうしてもここは検証したいというパターンを数種類用意して、それを比較・検討できるようにしていました。

ただ、パターンを増やすほど検証期間が長くなってしまいますので、そこは過去の施策におけるABテストの結果も見ながら、検証しなくてもいいものは排除しています。どうしてもここは見なければいけないというところ、今回でいえば22の機能のなかでメインで検証する機能を一つ立てつつ、続いて、他ので優先度が高いものをどこに配置しようかというあたりが、実際に検証したかったところになります。

Q.攻めと守りの体制を分けるのは予算が膨らみ社内での合意をとるのが大変そうだなという印象ですが、その点はいかがでしたか？

橋本：前提として、開発組織としても「この案件を実施していくことで得られるものがある」という確信を持ってもらえたことが、合意形成の上で非常に大きかったと思います。特に、リニューアルによってこれまで溜まっていた既存の負債を解消できるというところは、開発としても長年やりたかったことでした。それが開発組織として予算を投下する意義になったかなと思います。

加えて、「攻め」の人員を完全にアドオンしたというよりは、もともとの人数配置の中での転換などもあったので、その辺りを含めて必要最低限のスモールなチームでやっていこうと決めていました。そこも、合意が得られたポイントだったと思います。

Q.A/Bテストで統計的に有意な結果が出ないこともあるかと思います。そのような場合は、どのようにして次に活かしていますでしょうか？

橋本：もちろん、望ましい結果が出ないことは多々あります。ただ、有意な結果が出なかったということも、それはそれで一つの学びです。また、最終の結果指標が出るまでに細かい中間指標のデータが溜まっていて、そこから読み解けることは多いです。たとえば「この機能は思ったより利用されている」「このA/Bパターンでいうと、こちらのほうが改善傾向にある」など、振り返りの時にこれらをふまえ「仮説に対してどうだったか？」という視点で考えるようにしています。

ちなみに、プロダクトデザイン室にはABテストをはじめとする施策の結果と振り返りをメンバーが投稿する、ナレッジ共有のシステムがあります。他チームの振り返りも自由に閲覧することができて、すごく勉強になりますね。そもそもの仮説の立て方や、予想と違った時の対応の仕方といった考え方は、先人たちの事例から学んだ部分も大きいです。

お知らせ｜プロデザ室は仲間を募集しています

プロダクトデザイン室の募集情報は〈こちら〉のサイトからご確認いただけます。ぜひご一読ください☆
https://blog.recruit-productdesign.jp/

お願い｜できればX(旧twitter)もフォローをお願いします

プロダクトデザイン室の公式X（旧twitter）ではイベントの見どころやオリジナルコンテンツを更新しています。ぜひフォローしてください。
https://twitter.com/Recruit_PD_PR