ホームズのWeb担がアプリ担になって1年 Webとアプリの違いと学び。
私はこれまでLIFULL HOME'SのWeb担として、マークアップエンジニア→ディレクター→プロジェクトマネージャー→プロダクトマネージャーといったキャリアを積み、サービス開発に従事してきました。昨年から長らくいたWebを離れ、LIFULL HOME'Sのアプリ担当となり、約1年が経ちました。
特に転職や異動等で、新しい環境でプロダクトマネージャーになった方の参考になったらいいなと思いながら、この1年で学んだことやWebとアプリの違いについて書き連ねてみました。
新しい環境でまずやった5つのこと
プロダクトマネジメントをおこなうには、書籍「プロダクトマネジメントのすべて」で書かれてるプロダクトのCore・Why・What・Howの4階層の理解（作成）が必要です。そのために、私はまずこの5つのことをこの順番で意識しておこないました。
Whatの理解：KGI・KPIは何か？KGI・KPIツリーを理解する
プロダクトのCoreであるビジョンや事業戦略は異動前からある程度の理解があったので、私はここからスタートしました。
KGIは売上などのケースが多く、プロダクトの指標とちょっと離れているので、日々のサービス開発の中ではそれほど意識する必要はないと思っています。ただ、その売上がどう成り立っているのかの理解は超大事で、KGIの解像度が浅いと戦略や戦術に関わるのは難しいです。
KPIは、プロダクトやチームの状態や戦略によりけりのものです。何を設定していて、どれくらいのサイクルで、どうウォッチしているのか、過去はどういったものを設定していたかなどをヒアリングしました。KPIが長らく見直されていない、KGIと連動していない、チームの活動と連動していないといった場合は見直しをする必要があります。
Howの理解①：チームのコミュニケーション、意思決定ライン、ご近所さんを理解する
いわゆる定例MTG、プロジェクトの進行管理、施策等の意思決定、ステークホルダーは誰か？レポートラインはあるのか？
チームの活動の中で、どういった会話がどの頻度でどのメンバーでされているのかをまず理解すると、チームの性質やルーティンが見えてきます。それらを知ることで、チームの課題やキーとなる人、自分の役割や立ち回り方が見えてきます。
私はまず、チームのMTGにひと通り参加し、小さな施策のリリースを経験させてもらいました。これは、書籍「プロダクトマネージャーのしごと」で紹介されているプロダクトマネージャーのCOREのコミュニケーション、組織化、実行力につながります。
Howの理解②：ワーキングアグリーメントでメンバーを理解する
一緒に働くメンバーの価値観を理解するために、ワーキングアグリーメントを実施したのがとても良かったです。ワーキングアグリーメントは、お互いの仕事に対する理想の状態や価値観を共有して、その上でチームとしてストレス少なく生産的に働くことができるルールを作って明文化するものです。
直接のマネージャーでもないと、なかなか聞きにくい内容もありますが、メンバー同士で理解を深めることが大切です。
チームのルールが整えば、チームの実行力が高まり、定期的なふりかえりのネタにも活用できます。
Whatの理解：ユーザーの入口から出口までのファネルを理解する
ユーザーがどのようにプロダクトを知り、どこで接点を持ち、どこで離脱しているのかをまず理解すると、まずどこに注力すればよいのかの目星がつきます。
基本的な数字を理解することで、施策の予測が立てやすくなり、データ分析時のミスも発見にも繋がります。また、障害発生時の初動対応も迅速に行えます。まずは、これらの数字を把握しました。
Whyの理解：ユーザー体験を理解する
ここは、戦略や数字を理解してからやるべきか、前提知識なしにやるか悩ましいですが、まずはシナリオを立ててプロダクトを使ってみるのが大事だと思います。初見での気付きや、つまずきからの発見は大きいです。開発に関わってからだと、慣れによる思い込みや愛着がどうしても邪魔になります。
あとは、過去のユーザーインタビューやユーザーテスト、ユーザーからの声などをインプットし、ユーザー体験を理解しました。
LIFULLではUXリサーチを担う専門部門があり、ユーザーから学び、ユーザーの声をプロダクトに活かす文化が醸成されています。
Web担当からアプリ担当になって知った、Webとアプリの違い
ここからは、Web担当からアプリ担当になって知った、Webとアプリの違いについて書いていきたいと思います。
リリースサイクル、リリース方法が違う
アプリの場合は、更新のたびに新バージョンをストアに提出し、ストアの審査プロセスを経て公開となるのが基本です。また更新も、ユーザーにアップデート版をインストールしてもらう必要があります（ここは自動更新のユーザーがほとんど）。
そのため、Webのようにリリースを高頻度におこなったり、部分的な変更をおこなってリリースはできません。
リリースサイクルはどうしても長くなりますし、プラットフォーマーに依存するところが大きいのでリリース計画やリリース後のパフォーマンスチェックなど慎重におこなうべきところがあります。
ユーザーの利用モチベーションが違う
アプリの場合は、ユーザーはストアからアプリをダウンロードし、インストールする必要があります。この段階で、ユーザーはある程度利用することを前提としているため、利用モチベーションが高い傾向にあります。そのため、各種機能の利用率はWebと比較して非常に高い傾向があります。はじめて数字を見たときは、何か間違いがあるのではと何度か見直しました。
ユーザーのモチベーションが高いため、プロダクト側で体験設計をコントロールしやすい部分が大きいです。
ただ、Webでランディングページが重要であるように、アプリでもインストール初日の初回体験が非常に重要です。まず初日に、プロダクトのコアな体験を提供することに注力しました。
ユーザーの継続率が違う
アプリの場合は、アプリアイコンがホーム画面にあるためワンタップでアクセス可能です。これはWebとの大きな違いで、ユーザーインタビューでも毎回ブラウザで検索してアクセスするのが面倒なのでアプリをインストールするという方が多くいます。
また、定期的にアプリを利用してもらう仕掛けや仕組みとしてプッシュ通知や、アプリ内メッセージなどで直接的なコミュニケーションを取ることができるので、継続率も良い傾向があります。
これらの特徴からWebとは全く違うアプローチが必要だなぁと思いました、ほんとに学びの1年でした。
🙄Web担がアプリ担になって、苦労した（している）こと
プラットフォームの理解が必要
iOS・Androidともにプラットフォーマーの規制や変更に左右されることが多いです（というか、基本必須対応）。そのため、両社のガイドラインの理解や取り組みを常に追う必要があります。リリースサイクルが長い
リリースサイクルが長いゆえ、段階的なリリースやちょっとした修正はやりにくいです。 リリースごとの申請、テストなどもWebよりもやることは多いです。アプリ内ですべて体験設計する必要がある
Webと違いロングテールワードやコンテンツでユーザーを獲得することはできません。そのため、アプリ内での体験設計（UIデザイン、パーソナライズ）が超重要になります。
🥰Web担がアプリ担になって、良かったこと
リリースサイクルがほぼ固定
リリースサイクルがほぼ固定なので、サイクルに合わせた仮説検証と計画をたてる必要があります。不自由さはあるんですが、固定なので慣れるとチーム全体で仕事のサイクルを揃えることができ、働き方のコントロールがしやすいなと感じました。ユーザーの利用モチベーションが高い
ユーザーの利用モチベーションが高いので数字変化がわかりやすく、コントロールしやすい！個人的には仮説検証はWebよりもアプリの方がやりやすく感じています。 特にデータが見れる人はとても楽しいと思います。数字だけでなく、ストアレビュー等でユーザーから直接フィードバックがもらえるのもうれしいです（※つらいときもある）。アプリ内での体験設計がすべてである
アプリ内での体験設計（UIデザイン、パーソナライズ）がすべてです。プッシュ通知やアプリ内メッセージなどWebではできない（やりにくい）アプローチが可能です。 制約もありますが、Webよりも機能利用の流れを作りやすいです。 例えば、起動時に案内を出したり、ボトムメニューにボタンを配置するなどで狙ったユーザーの利用を促すことができます。
👋おしまい
ということで、Web担がアプリ担になると…Webとは全く違うプロダクト開発ができます！！
アプリ領域で勉強すること、新たにチャレンジすることがまだまだ多いですが、Web担で得た知見も活用できる、とても刺激的な世界です。
また、LIFULL HOME'Sアプリが750万ダウンロード突破しました。ぜひ、LIFULL HOME'Sアプリもご利用いただければ幸いです。これからもよろしくお願いいたします。