プロダクトの機能追加における2つのアンチパターン　「数値悪化」「関連プロダクトに対する要求漏れ」への対策

アンチパターン「不確実性の高い機能のリリースで数値が悪化」

向井毅男氏（以下、向井）：というところでパネルテーマ③。ここが今日一番楽しくお話ししたかったポイントかなと思って。このようにMVPを定義しながら成長してきた各プロダクト、サービスの中でも、失敗とかいろいろあったと思うので、ぜひそのあたりを両社から共有してほしいな思います。

今回、両社から3つずつアンチパターンというかたちで失敗談を共有してもらおうと思っているので、さっそくカウシェさんの1個目から共有、説明をお願いします。

近藤優輝氏（以下、近藤）：ではまず、カウシェの1個目のアンチパターンについて紹介します。

不確実性が高い機能をMVPで出した際に、数値が悪化したことがありました。オンボーディングというパネルにちょっとテコ入れをして、通常ECにはないような、プロフィール登録みたいな機能を導入する施策がありました。

そこで導入する際に、「まとめて情報を取っちゃったらいいよね」という。分散していろいろなところで情報を取るよりは、まとめて登録する際に取ったほうがいいという考えから、ソーシャルのサインアップ、GoogleのサインアップとかAppleのサインアップとかあると思いますが、あれを画面として1枚挟むことをついでの追加としてやった結果、ファネルがちょっと悪化した問題がありました。

（スライドを示して）これが具体のイメージです。ウォークスルーを3枚経て、その後にサインアップの画面があって、その後にプロフィール登録みたいなのがあるようなオンボーディングのフローです。その中の「サインアップする」のところで、スキップの導線をテキストリンクで用意していたんですが、それを見てもこの画面で拒否反応を示されて離脱しちゃうみたいなケースがあって。離脱が発生して、数値が非常に悪くなった事例です。

対応策として選んだ「プレモーテム」という手法

近藤：これに対してカウシェとして取り組んだ対策としては、プレモーテムという手法で取り組みました。あらかじめ起こり得る失敗と、その可能性を事前に予測するリスクマネジメントがあるのですが、まずリリースする前に「そういう失敗ってあり得るよね」みたいなものを洗い出しておいて、それを要件定義段階で盛り込んでおく手法です。

その失敗の可能性のケースみたいなものを盛り込んでおいて、失敗が発生した時に、即座に変更して改善することができるようになる感じです。

具体的にどういうことをやったかでいうと、今回の事例はある程度プレモーテムによって予見していたところがあって、パネルを増やすことで数値悪化するかもしれないというケースをあらかじめ想定しておきました。

対策としては、オンボーディングのフローでユーザーの状態を疎結合に管理するとか、ドメインを疎結合に保つとか。そういったような設計をすることで、途中のファネルを取り除いたとしても、仕様として成り立つような設計・実装を1個行いました。

ケース②として、これは実際には発生しませんでしたが、ECでプロフィールみたいなものを登録してもらおうとした時に、そこでまた拒否反応が起こるんじゃないかなと想定していて。

通常ないSNSの要素が入ってくることで悪化するんじゃないかというところで、今は必須のプロパティにしていますが、ニックネームみたいな任意のオプショナルな値にしても、全体の仕様とかUXとかが成り立つように設計・開発をしました。

向井：ありがとうございます。これ、あれですね。MVPの定義で触れた不確実性に対するアプローチとしてプレモーテムという手法を使ってやられたというところで、非常に新鮮なアプローチだなと聞いていて思いました。

現状の「GO」の機能に至るまでの背景

向井：仕様策定プロセスでいろいろ工夫することが多いと思いますが、逆にこの部分においてのMoT側での失敗とかアンチパターンはどのようなことがありますか？

脇水誠氏（以下、脇水）：そうですね。まず、タクシーアプリ「GO」の話ですが、ローンチしてから2年経過していて、プロダクトが成長していろいろな要求や機能が追加されている背景がまずあります。

（スライドを示して）一番左に「2020年9月」と書いていますが、こちらはアプリ統合、ローンチしたタイミングになっていて。この時、体験として一番重要視していたところが、タクシーを今すぐ呼べること。すぐ呼んでタクシーにすぐ乗れるというところを提供価値として一番考えていて、そこにフォーカスして機能を提供していました。

真ん中、2020年11月ですね。このあたりから複雑度がけっこう増してきていて。いわゆるAIを使っていろいろなサービスを作っていきましょうという背景があって、AIを活用して予約機能を提供しています。

これは何かというと、今すぐ呼ぶのではなく、例えば「明日の朝8時に乗りたい」とか、そういった時間を指定して呼べる機能を提供しています。これにはAIを活用し需給予測を用いて実現しています。

その右に「多様なニーズにフィット」と書いてありますが、いわゆる、ユーザーさんが自分の乗りたい車両を選んで乗れる機能提供をしています。例えば「車椅子車両を指定して呼びたい」とか、「ちょっと大きめの車を選んで呼びたい」とか、そういったユーザーさんのいろいろなニーズがあるので、そこに対して応える機能を提供しています。

その下にある数字ですが、これは案件ごとの要求仕様書、PRDにあった要求数をピックアップして書いています。こんな感じで、だんだん機能ごとに要求が増えてきて、それが積み重なって今のサービスとして提供している背景がまずあります。

その次ですが、先ほど山田さんからお話もあったように、これはまさにGOの特徴なんですが。ひとえにGOといっても、エンドユーザー向けのタクシーアプリGOとか、エンドユーザー向けのアプリで配車依頼をかけてタクシー乗務員さんがそれを受け取って、実際にお客さんの元に向かうといった、そういったナビゲーションのシステムがあったり。

（スライドを示して）あと一番右のタクシー事業者向けのシステムについては、いわゆる営業成績を管理したり、経理系のシステムがあったり、そういったすべてのソリューションをソフトウェアで提供しています。

一方で、タクシーの社内にあるデバイスと私たちが作っているデバイスを組み合わせて、ハードウェアの観点でもサービスを作っています。（スライドの）下に「BLE Logger」と書いてあるのは、タクシーには空車とか迎車とか（を表示するため）の「スーパーサイン」という既存のデバイスがあるのですが、そことタクシー乗務員向けのプロダクトを連携してサービスを作ったり。

あとは決済機ですね。SuicaとかPASMO、そういったいわゆる決済をするためのデバイスを作っていたり。（スライドの）右下にある後部座席タブレットについては、最近、後席にタブレットが乗っていて、そこに広告が流れたり、そこで決済できるシステムがあるのですが、そういったものも提供しています。

このハードとソフトが組み合わさって、1個のGOというサービスを作っているというところが背景としてあります。

アンチパターン「関連するプロダクトに対しての要求が漏れる」

脇水：まず1点目（のアンチパターン）を紹介したいなと思います。MVPって、一般的に必要最低限かつユーザーの体験を担保するというところで、ミニマムで提供して定義していこうという話があると思います。それはもちろん意識してMVPを定義しているんですが、先ほどお伝えしたように、たくさんの機能が増えてきて、関連するプロダクトが多いところがあって。要求がMinimumすぎてしまう課題が生まれてきています。

つまり、新しい案件のMVPは定義できていますが、もともとあった機能とか、関連するプロダクトに対しての要求が漏れていて。そういったところが課題としてあがっていました。

考慮不足ってどうしても昔の案件に関連していて、いろいろな観点でそこを定義しないと、新しい機能の提供ができないところにつながってきちゃうんですけど。どうしても途中から考慮不足に目がたくさんいってしまって、「この案件のMVPって何だっけ？」という最低限守るべき質のところの認識が、だんだん関係者でずれてしまっていることが過去に起きていました。

いったん1番目までやります。2番目、3番目は次に紹介したいなと思っています。向井さんに1回戻します。あれ、ミュートかな？

近藤：向井さん、ミュートかも。

原田七穂氏（以下、原田）：ミュートかも。

向井：ごめんなさい。やらかしましたね、すみません。

（一同笑）

向井：このタイミング、ちょうどいいので。質問とか感想とか、ぜひコメントを書いてもらえるとうれしいなと思います。

要求漏れに対するカウシェの3つの対策

向井：じゃあ、戻ります。仕様を決める上で、考慮漏れは絶対起きる事例かなと思っていたりするんですけれど、カウシェさん側でも、考慮漏れが起きてしまったようなユースケースがあったと聞いているんですが、そのあたりはどうですか？

近藤：そうですね。考慮漏れというところでいうと、カウシェの場合、MVPで作った機能が想定外の運用によってパフォーマンス劣化したような事例がありました。

これはどういったことかというと、タイムセールという機能を提供しました。タイムセールは時間が決まっていて、「24時間以内でお得な商品が買える」みたいな機能です。そういったものをMVPで最小工数で提供することをやっていて。

セール商品なので、多くても数十件ぐらいの商品データかなと想定して、ページネーションとかをせずに、レスポンス一括でデータを返却することをやっていました。

運用していくうちに、気づかぬうちに商品データを数百件扱うような運用に変わっていて。レイテンシーが大きくなって、パフォーマンス劣化しちゃうみたいな。運用の考慮漏れというような事例が、カウシェの場合ではありました。

これ自体は先ほどのプレモーテムみたいな、事前に想定することをちょっとできていなかったんですけれど。「事後の対策としてこういったことを考えています」みたいなところを紹介できればと思います。

短期的なところと長期的なところがあるかなと考えていて。短期的なところでいうと、MVPがどういうもので、どういう仕様で、どういう使われ方をするのか。どこまで許容できるのかみたいなところを、ほかの部署とか、実際運用するところと共有しないといけないというのがあって。

プロダクトの進捗共有の場を同期的にするというのを、毎週1時間設けるようにしています。施策の内容とか仕様とかを詳細に共有する場みたいなものを設定するようにしました。

2つ目が運用レビューというところで、「運用としてこういうことを新しくやりたい」みたいなことが出てきた時に、プロダクトメンバーがそれをレビューしていくことをやっています。

最後に恒久的な対応でいうと、システムを制御するのが一番いいよねというところがあって。MVPとの兼ね合いでどれぐらい工数をかけるかという問題はありますが、システムで制御するようにして、想定外の運用がされないようにするみたいな。

先ほど（の例）だとページネーションしたり、現行では一定件数以上は登録できないようにするとか、そういったアプローチがあると思います。対策としてそういったことをやっていっている感じです。

向井：ありがとうございます。開発チームの中に閉じてしまうと（気付けない）、今紹介してもらったチーム間での考慮漏れみたいなことを、体制を構築していくことによって防ごうとする努力をしたということで、非常に勉強になるなと思いました。

（次回に続く）