出典: ITmedia
今回のテーマは、商品やサービス開発です。プロダクトマネジメントについて見ていきます。
✓ この記事でわかること
- ｢日産レンタカー公式アプリ｣ の開発ストーリー
- 開発課題は納期と品質の両立
- 問われる ｢Must have｣ と ｢Nice to have｣ の見極め
- プロダクトマネージャーの役割
おもしろいと思ったアプリの開発事例をご紹介します。そこから学べることとして、プロダクト開発で大事なこととプロダクトマネージャーの役割を解説しています。
よかったら最後までぜひ読んでみてください。
｢日産レンタカー公式アプリ｣ の開発
こちらの記事がおもしろかったです。
｢DX を進めた意識はなかった｣ 日産レンタカーが、すごいアプリを作れたワケ｜ITmedia
プロダクト開発で参考になる記事でした。
2021年4月から提供している「日産レンタカー公式アプリ」の開発ストーリーが、担当者へのインタビューから紹介されています。
出典: ITmedia
レンタカー利用手続きの面倒さ
皆さんは、レンタカーを利用したことはあるでしょうか？
レンタカーの利用では、店頭で免許証の提示や書類の記入といった手続きがあります。これは今思い返すと面倒な手間なんですよね。日産レンタカー公式アプリでは、これらの事務手続きをアプリ内で完結できます。
予約から返却までの手続きをアプリで行え、他には、事前に登録した免許証やスマホアプリをクルマの鍵代わりにできたり、店員の付き添い不要で完全非対面での直接乗車ができる ｢セルフライドゴー｣ 機能も搭載しています。
納期と品質の両立
開発の裏話で興味深かったのは、｢納期 (開発スピード) ｣ と ｢品質｣ のいわばトレードオフをどう両立するかでした。
以下は、記事からの引用です。
岡本: 構想からリリースまでは3年ほど費やしていますが、実際の開発期間は8カ月ほどでしたよね。最初、ご無理を言って ｢8カ月後のリリースを目指したい｣ と伝えたら、｢成功確率は2割です｣ というお話をいただいて (笑) 。
ただ、当時もお話ししましたが、一発で良いアプリができるとは思っておらず、短期改善を繰り返していこうと考えていました。
小林: 僕も同じ考えで、自動車などの命に関わる商品は 100% の品質が必要ですが、ソフトウェアは 70% 、80% でもリリースして、フィードバックを受けながら改善することが大事です。｢ソフトウェアに一生、完成形はない｣ という前提が大切ですよね。
岡本: 成功しているソフトウェアの多くはその手法で作られていますからね。ただ誤解してはいけないのは、どんなにリリースが遅れても絶対落としてはいけない機能があることです。その見極めを企業側ができるか。
ここを間違えれば、この時代に使われるアプリにはなりません。今は価値がないと判断されたアプリはすぐにアンインストールされますから。私もよく自分のスマホで削除するので、実体験として分かっています (笑) 。
小林: ユーザーにとって不可欠な機能なのか、それとも納期優先で実装を先送りしてもよい機能なのか、正しく区別することですよね。その見極めを行うにも、最初の顧客体験を突き詰めることが生きてくると思います。
Must have と Nice to have の見極め
ここから掘り下げていきたいのが、｢どんなにリリースが遅れても、絶対落としてはいけない機能がある。その見極めをできるか｣ についてです。
これは特に、プロダクト開発の初期段階では大事なことです。
アプリなどのソフトウェア開発では、物理的なモノの製品とは違い、原材料の制約がないために機能の追加は増やしがちになります。開発初期フェーズでは必ずしも必要でない機能が実装されてしまうことがあります。
そうではなく、つまり ｢あれもこれも｣ ではなく、重要なのは ｢あれかこれか｣ です。足し算よりも引き算の考え方をすることです。
この時に問われるのが、絶対に必要な ｢Must have｣ なのか、それともあればいいレベル (後からの開発で良い) という ｢Nice to have｣ かの見極めです。
納期を優先するなら、Nice to have は覚悟を持って捨てます。開発要件として残しておき、後から再度 Must have か Nice to have なのかを判断します。
プロダクトマネージャーの役割
では最後に、今回の話から学べることとして ｢プロダクトマネージャー｣ の役割を掘り下げてみましょう。
ここまで見てきた ｢日産レンタカー公式アプリ｣ の開発の事例と、Must have と Nice to have の見極めの話から、開発を主導するプロダクトマネージャーの役割が見えてきます。
次の3つです。
✓ プロダクトマネージャーの役割
- 想定ユーザーの理解と市場性の把握
- 開発するプロダクトの定義づけ、開発要件への落とし込み
- 社内外のステークホルダーとの開発プロダクトの共有
順番に補足しますね。
想定ユーザーの理解と市場性の把握
プロダクトの存在意義は、想定ユーザーに使ってもらい、価値を提供することです。
そのためにはプロダクトマネージャーはユーザーを誰よりも理解し、困りごとや悩み、不満、そこから発生する隠れたニーズを掘り下げます。
ユーザーや競合プロダクトからも市場性を把握することが求められます。
開発するプロダクトの定義づけ、開発要件への落とし込み
ユーザーと市場性の理解から、開発し自分たちの提供するプロダクトを定義します。
存在意義から落とし込んだ開発要件を決めます。この時に記事の前半で見た Must have と Nice to have の見極めが重要になります。
社内外のステークホルダーとの開発プロダクトの共有
社内では、関係各部署との情報共有、認識合わせや期待値の調整をします。プロダクトマネージャーが社内でのハブの役割を果たします。
社外とは、特に想定ユーザーに開発中のプロダクトを紹介し、見せたり実際に使ってもらいます。ユーザーから ｢お金を払ってでも欲しい｣ と言ってもらえるプロダクトかを検証します。
また利用シーンやユーザーからのフィードバックから、次の開発へのヒントを得るのもプロダクトマネージャーの役割です。
まとめ
今回は、日産レンタカー公式アプリの開発事例から、プロダクト開発で大事なことやプロダクトマネージャーの役割を見てきました
最後にまとめです。
Must have と Nice to have の見極め
- プロダクト開発の特に初期段階では、どんなにリリースが遅れても絶対落としてはいけない機能があり、その見極めをできるかが問われる
- 絶対に必要な ｢Must have｣ なのか、あればいいレベル (後からの開発で良い) という ｢Nice to have｣ かの見極めが大事
- 納期を優先するなら、Nice to have は覚悟を持って捨てる。開発要件として残しておき、再度 Must have か Nice to have かを判断する
プロダクトマネージャーの役割
- 想定ユーザーの理解 (不満や隠れニーズの掘り下げ) と、市場性の把握
- 開発するプロダクトの定義づけ、開発要件への落とし込み
- 社内外のステークホルダーとの開発プロダクトの共有。関係各部署との情報共有･認識合わせ。想定ユーザーにプロダクトを紹介し使ってもらい、｢お金を払ってでも欲しいか｣ を検証する
ニュースレターのご紹介
マーケティングのニュースレターを配信しています。
気になる商品や新サービスのヒット理由がわかり、マーケティングや戦略を学べるレターです。
マーケティングのことがおもしろいと思えて、今日から活かせる学びを毎週お届けします。
レターの文字数はこのブログの 2 ~ 3 倍くらいで、その分だけ深く掘り下げています。ブログの内容をいいなと思っていただいた方には、レターもきっとおもしろく読めると思います (過去のレターもこちらから見られます) 。
こちらから無料の購読登録をしていただくと、マーケティングレターが週1回で届きます。もし違うなと感じたらすぐ解約いただいて OK です。ぜひレターも登録して読んでみてください！