リモートでも歩みを止めない！プロダクト開発工程別のデータ活用実践例
こんにちは。「Airレジ ハンディ」のプロダクトマネージャー（以降、PM）をしている植田です。
「Airレジ ハンディ」のプロダクト立ち上げをした3年半前（2017年5月）から、PMとして遅めの青春を楽しませてもらっています。
「Airレジ ハンディ」のプロダクトチームは、プロトタイピングが大好きなチームです。
特に、不確実性の高いエンハンスや新しい価値を発見するためのプロトタイピングを行う際には、”本番プロダクト×オズの魔法使いプロトタイピング”と呼べるような手法を好んで使います。
詳細は、川崎の記事（「Airレジ ハンディ」セルフオーダーの立ち上げ初期の「ブレない価値の軸」の作り方）を見ていただけるとイメージ掴めると思います。
そして、「中小企業向け&店内の業務支援ツール」というプロダクト特性上の事情もあり、観察やヒアリングなどの定性調査に加えて、プロダクト内の操作ログなどの定量データもプロダクトデザインの意思決定に多く活用しています。
この記事では、どのようにデータをプロダクトデザインの意思決定に活かしているかが伝わるように、エンハンス案件の実例を開発プロセス（工程）に沿って紹介します。
特に今回は、コロナ禍で客先に滞在することが難しくなり、プロトタイピングや観察によるリサーチがやりづらくなったと感じている人が多そうなので、プロトタイピング工程も含めてほぼリモートで実施した最近の案件を実例として扱うこととします。
観察やヒアリングの精度を高めたい
プロトタイピングの質を上げたい
要件定義時にどこまで実装すべきか迷う
リリース後の振り返り学習が難しい・大変
という課題感がある方には参考になるかもしれません。
また、中小企業向け・業務支援ツールといった特徴のあるプロダクトを扱っている方には共感いただける内容かと思います。
今回紹介する事例：テイクアウト対応
案件について触れる前に、前提として「Airレジ ハンディ」というプロダクトについて説明が少し必要なので補足します。
「Airレジ ハンディ」は、飲食店の注文・調理・配膳をカンタンにするオーダーエントリーシステムです。
そして、我々は、以下のような想い（ミッション・ビジョン）でプロダクトを作っています。
顧客は、飲食店の中でも居酒屋のような、イートインのフルサービスレストラン（FSR）の業態のお店がメインとなっています。
つまり、コロナの影響を大きく受けている業界にプロダクトを提供しているということになるのですが、今回紹介する案件は、まさにその状況を象徴する『テイクアウト対応』です。
テイクアウト対応
コロナ禍で新たにテイクアウトを始めた飲食店は、テイクアウト注文を非効率な方法（紙のメモなど）で対応しなくてはならない状況にある。
そのことで増えた現場負荷・料理提供遅れの発生といった問題を、「Airレジ ハンディ」のエンハンスで解決しようとする案件。
ここからは、開発プロセスの工程ごとに詳細に言及していくことになるため、とっても長くなります。
なので、先に全体像を画にしておきたいと思います。
01 異常検知 コロナで「熱狂ファネル」悪化に気付く
業務インフラ的な存在である「Airレジ ハンディ」は、利用を突然辞めることが出来ない性質もあるため、チャーン（解約）を予期することが難しいです。そもそもチャーン自体も理由は閉店などがほとんどです。
そのため、 SaaSの最重要指標であるチャーン率の改善のための打ち手の検討は少し難しいです。（他のどのプロダクトもそうだとは思いますが、、、）
「Airレジ ハンディ」では、チャーンの先行指標として、顧客がプロダクトに不満がある状態から熱狂するまでのどの状態にあるかを判定する「熱狂ファネル」というものを定義してモニタリングしています。
コロナで緊急事態宣言が発令された4月以降、モニタリングレポートはこんな状態になっていました。（諸事情でざっくりの表現に編集してますがご了承ください）
5月以降、営業再開する飲食店が増えている中で、「注文会計差額あり伝票 多」というファネルが3月と同じ水準に戻っていない点をPMとしては警告信号として捉えていました。
02 問題の可視化 テイクアウトを始めた店で「ハンディ伝票割合」が低下していることを実感
前項でも触れた通り、緊急事態宣言が解除され、休業から営業再開する店舗が増えてきた中でもファネルは元どおりにはなっていませんでした。
これは、コロナ以前では満足してもらえていたが、今は何かが変わって不満がある状態である、ということを意味します。
肌感でも顧客との対話でも認識していましたが、「テイクアウト注文を非効率な方法（紙のメモなど）で対応しなくてはならなくなっているのではないか？」という仮説は明白かつ有力でした。
そこで、その仮説が本当か、どの程度の話か把握するため、以下のような可視化をしました。
チャートはデフォルメしていますが、赤がテイクアウトの注文の場合に「Airレジ ハンディ」をうまく使えてない店舗の割合を示しています。
これを見ると、個別に把握していたこの問題が顧客全体の中でも広く起きていそうだということが分かると思います。
この段階で、PMとしてはプロダクトバックログアイテムの評価基準であるRICE（Reach/Impact/Confidence/Effort）のReach（効果の適用範囲）についておおよその検討を付けている感じです。
当時、他の案件も動かしていましたが、このReachを見て、テイクアウト対応案件の優先度を最高にしてタスクフォース化しています。
03 N=1にたどり着く 協力店舗の獲得
次に我々が行ったことは、「N=1にたどり着く」ためのアクションでした。「Airレジ ハンディ」には、”新機能先行モニター店舗”というスキームがあります。
＜新機能先行利用モニター店舗とは＞
データ共有およびプロトタイプ検証などのプロダクト開発に協力してくださっている店舗様のこと。
・AppStore公開前の最新バージョンをTestFlightで先行配信。
・数週間業務利用し、使用感や課題がないかをプロダクトチームに直接フィードバック。
※ハイファイ・プロトタイプとして検証用のアプリを提供し、実運用に乗せて検証することもある。
幸い、普段から協力関係にある店舗が、「テイクアウトを始めたが問題が起きている」という状態だったため、正式に”新機能先行利用モニター店舗”としてご参画いただきました。
N=1にたどり着く方法は様々あると思いますが、データを見れば「この顧客に、この問題が存在する可能性は高いのかどうか」はある程度分かると考えています。
もちろん、偶然の出会いから気づきを得ることもありますが、無駄なヒアリングを重ねて貴重なUXリソースを浪費したくない、とPMとしては考えているので、「ヒアリング対象の選定をデータから精度高く抽出する」ということを出来るように日頃からSQLを作って蓄積しています。
04 ヒアリング仮説の設定 「受け取り予定時刻」が管理出来ないから？
N=1の顧客を獲得した後は、ヒアリング準備に取り掛かります。
「Airレジ ハンディ」は、アルバイト/社員、ホール/キッチンなど様々な人が操作するため、ヒアリングしようにも本人に自覚がないこともあれば全体を把握している人がいないことも当たり前にあります。
そのため、ヒアリングの質を高めるために、以下のようなことを極力事前にやるようにしています。
＜ヒアリング前にやっておくと良いこと＞
①ヒアリング対象の店舗と同じ設定をデモ用のアカウントに再現
②繁忙時間帯の注文データを見ながらトレース
③自分がお店だったらプロダクトに持つ不満・改善要望をリストアップ
今回の案件であれば、税率8%の商品が含まれる伝票の注文に対する操作の履歴を特にチェックしました。
補足：消費税の軽減税率制度により、税率8%＝店外飲食（テイクアウトorデリバリー）と推測できます。
そして、いくつか具体的にヒアリング時のヒントになる事実を掴めました。
＜今回得られたヒントの例＞
⑴通常のカウンター用の席を選択してテイクアウトの注文を打っている。
→ホール：イートインのお客様もいた場合、案内できなくて困るのでは？
→キッチン：イートインのお客様もいた場合、テイクアウトかどうかわかりにくいのでは？
⑵注文入力時に「受け取り予定時刻」らしきメモを入力して送信している。
→キッチンが複数ポジションあるので、同じ受取予定時刻を複数の注文商品に入力せねばならず、面倒くさいと感じているのでは？
→入力している「注文メモ」は、注文送信時にしか編集できないので、後から時間が分かったり変わったりした場合に困るのでは？
ただ、この『データベースや操作ログから、どんな風に業務を行っていたか調べる』というのを必要な時にパッとやれるようにするのは、簡単なようで実は大変な準備が必要です。
というのも、システムのデータベースは正規化されているので大量のテーブルを結合しなくてはなりませんし、必要な情報がデータベースにある訳ではなくアプリの操作ログやサーバーのログとしてしか残していないケースもあります。
上記のような形式や単位、保存場所の異なるデータを統合するためには、データを1箇所に集めた上で統合するためのSQLなどを書かなくてはなりません。実際に「Airレジ ハンディ」には何種類かのデータマート生成SQLを用意していますが、さっき試しに長そうなSQLファイルを開いて行数をカウントしたところ、500行くらいありました。
この話については、「ユーザーの利用体験を可視化できるデータマートを作る」のような記事がもう一つ書けそうなテーマなので、今回はこれ以上の詳細は割愛します。
05 ヒアリング実施 問題と原因仕様が分かったぞ
ヒアリングの内容は詳細割愛しますが、WEB会議システムを用いてヒアリングを実施したところ、今の「Airレジ ハンディ」でテイクアウト注文をうまく管理できていないことで起きている問題とその原因仕様が明らかになりました。
ちなみにですが、問題と原因仕様が明らかになった時に、PMとして意識的にやっていることがあります。
＜問題と原因仕様の仮説が見えてきた時にやっていること＞
「N=1の問題をデータパターンとして定義
→同じデータパターンの他の顧客を抽出
→N=2〜10の店舗のデータの海にDive
これをやると、この問題の大きさ（深さだけでなく、広さ）の解像度が上がるだけでなく、N=1で理解したことのうち”何が個別事情で、何が共通項なのか”も言語化できたりします。
（ので、個人的にはおすすめ）
さらにちなみにですが、ヒアリング後の解釈をまとめている際には、以下のようなつまづきが「あるあるだよなぁ」とも感じています。
あれ？この時、たしかに『●●してる』って言ってたけど、どの画面でやってるかって聞けてたっけ？
やっべ、、、それによって解釈変わるんだよなー。
1段階抽象化すると、「ヒアリングで5W1Hを確認し損ねた」というだけのことだと片付けることも出来ますが、完璧にヒアリングを実施することが難しいのも事実です。
こういう時には、実際の利用データと照らし合わせながら、「ヒアリングを実施する/ヒアリング結果を解釈する」ということをしています。
さらに言うと、事前にデータを見ておくことが出来れば、ヒアリング中に利用データとユーザーの発言の間で整合しない部分に気付いて確かめることも可能になるため、UXデザイナーにはヒアリングの前にデータを見ておいてもらうことをリクエストしています。
06 プロトタイピング設計 システム実装して検証すべき論点は「既存の入力導線を変える必要があるか？」だ
「Build-Measure-Learn」という言葉がありますね。
私もこの考え方自体は好きですし、いつも意識していますが、「Airレジ ハンディ」は業務支援ツールなので少し慎重になる必要があります。
もし、本番アプリに下手なものをBuildしてしまった場合には、全国の飲食店の業務を止めてしまうかもしれませんし、仕様をコロコロ変えること自体が顧客にとっては苦痛です。
そのため、新しいインタラクションを採用する場合やシステムで管理する情報の概念が広がる場合などは、不確実性とリスクの高い案件として捉え、捨てる前提のハイ・ファイプロトタイプでの運用を実施します。
（実は、この捨てる前提のプロトタイプ開発によって一度Buildする工程を踏めるため、開発観点でもいいことがたくさんあります。）
今回の例でも、前項のヒアリングの結果「受け取り予定時刻」を管理する必要があることは明らかになったのですが、いくつか検証しておかないと要件として確定できない要素がありました。
実際には細かい点も含めて検証論点は何点かあったのですが、最も大きな論点は以下でした。
＜前提＞
⑴「Airレジ ハンディ」の業務データは以下３つのレイヤに分類される。
┗ 伝票情報（お客様の組単位の情報 ex.4名..）
┗ 注文情報（注文送信単位の情報 ex.注文時刻..）
┗ 注文商品情報（商品単位の情報 ex.だし巻き卵 2点..）
⑵「受け取り予定時刻」は、以下の性質を持つ。
・組単位で決まる（≒伝票情報である）
・注文入力時には決まっていない（変わることもある）
⑶注文入力UIでは、伝票情報の編集操作を許していない。
⑷会計済の伝票情報の編集ができる画面は存在しない。
⑸テイクアウトは、注文した流れでそのまま会計してしまうケースがある。（＝先会計）
＜論点＞
既存の入力導線を大きく変える必要があるのか、それとも今の入力導線のままでも十分問題解決に資するのか。
＜検証ポイント＞
先会計のケースでも受け取り予定時刻を入力できるのか。
先会計で受け取り予定時刻を編集できないと困るケースの発生頻度は高いのか。
上述の論点に答えを出すため、
「入力導線は大きく変えず、素直に伝票情報を編集できる画面に”受け取り予定時刻”を追加」した、（捨てるつもりの）TestFlightアプリを開発し、新機能先行利用モニター店舗にリリースすることにしました。
07 プロトタイピング実施 入力導線を大きく変えなくても良さそうだ
TestFlightアプリを数週間業務利用いただき、我々はデータを見て以下のような点を日々チェックしていました。
①先会計のケース、後会計のケースそれぞれどれくらい発生しているのか
②それぞれのケースで追加した「受け取り予定時刻」は入力できているか
③「受け取り予定時刻」の入力はどのタイミングで行なっているか
本番アプリに少し修正を入れただけのTestFlightアプリなので、実装工数はそこまで大きくかけずに済みますし、ログは本番と同等に残ります。
そのため、お店に張り付かずに長期間のプロトタイピング（検証）が可能になります。
毎日6時間近く多くのユーザーに操作され続ける業務支援ツールなので、今回のように発生頻度も含めて検証したいケースが多く、ペーパープロトでは検証が不可能なため、こういった検証スタイルがメインになっているのだと理解しています。
こういった検証スタイルを定常的にリリーススケジュールに組み込むためには、エンジニアも含めたチームプレーが重要になるのですが、それはそれで話が長くなるので、今回は割愛します。（案件を思い出しながらこういう記事を書くとすぐ脱線しそうになりますね 笑）
数週間経った後、データでおおよその解釈は加えつつ、最終的に答えあわせのような形でユーザーにヒアリングを行いました。
無事、最大の論点であった、”既存の入力導線を大きく変える必要があるのか” については、”大きく変える必要はない” と結論づけることができました。
08 要求/要件定義 開発チームへの要件インプットが15分で終了 "TestFlight版との差分はここです”
我々は、要件インプット会という打ち合わせの場で開発チームに要求事項と大枠のデザインを伝えているのですが、こういったプロトタイピング工程を噛ませた案件だと、開発チームも既に一度作っていたりもするので理解度がむしろエンジニアの方が高かったりします。
この案件はたしか、検証結果と学びについての共有とTestFlight版との差分についてUX担当が言及したのですが、それでも15分くらいで話すことがなくなってしまい、変な空気が流れて笑って解散したのが印象的でした。
ちなみにですが、要件インプット会ではPMとしてデザインしてもらった画面を見て「何か貢献できないか」と考えるのですが、以下のような観点でコメントしたりもします。
09 振り返り学習設計 「問題解決度」も「学習論点」もDBのデータで評価できるね
前項まででは、「プロトタイピング工程でデータから学習できることがあります」的なことを書いてきましたが、実際には本番リリースが学習のスタート地点ですよね。
プロダクトチームでは、要件インプットするためのドキュメントをフォーマット化しているのですが、「リリース後にデータから何を振り返り評価し、学習するのか」もテンプレートに入っています。
参考になるかもしれないので、無邪気に画像を貼ってみることにします。
無邪気に貼ってみたものの、上の画像は「細かいな・・・これは見てられんぞ」と思ったので、このフォーマットを作ることを決めた朝、私が通勤中にSlackに書いた独り言の方も貼っておきます。
毎回、要件定義段階でこの検証設計をするのはしんどいのですが、これをサボるとかなり高い確率で、「振り返りするのに必要なログデータが特定できない」という悲しい事態を引き起こします。
今回のテイクアウト案件の場合は、新たにアプリのログを吐くようにしたりしなくても良さそうでした。
10 設計・実装・リリース 現在開発中です
この案件、実はこのnote記事とほぼ同じタイミングでリリースされます。
なので、この工程についてはまだ書けることがありません。
何か見落としがあってリリース後に叫んでる可能性もあり得ますが、、まぁ、そういった学習がプロダクト開発の楽しさだと思うので、むしろ楽しみにしています。
まとめ
今回、テイクアウト対応という案件を通じて、「Airレジ ハンディ」のプロダクトチームがどのようにデータを活用しているかを紹介しました。
かなり文量があって、上に戻るのも辛いので全体図を再掲します。
ここまで読まれた方にとって、1つでも参考になれば幸いです。
ToBの業務支援SaaSプロダクトの良い点は、
①プロダクトの利用が大量で、顧客の日々発生する問題解決（業務）に直結していること
②その問題解決の過程も含めて、データとして顧客とプロダクト提供者の間で共有蓄積されること
③継続的な関係維持の動機付けがプロダクト提供者にもあるので、長期的な視点で顧客の成長に繋がるような問題発見を志向でき、必要な打ち手は段階的に出していくことも可能であること
④そして、上述した点が多数の顧客に同時並行で行うことができること
だと思んですよね。
顧客は、「お店の中で何が起きているのか」「何が必要なのか」を、プロダクトを利用したデータを共有するという形で教えてくれていて、むしろ『それくらい汲んでくれよ』と言われているような気すらしているんですよね。
顧客がシステム開発会社にRFPを作成して伝える時代はもう終わっていて、
データから学習し、プロダクトの改善を通じて顧客の問題解決を進める。
そのことで顧客と我々プロダクト提供者の双方が成長していく。
もう、そういう時代だよね、と感じています。
コロナの影響で、顧客と直接顔を合わせて話をしたり、視覚的に得られる情報を得にくくなっている側面はたしかにあります。
しかし、SaaSプロダクトは毎日顧客との接点になっており、データという形で多くのことを伝えてくれます。（「Airレジ ハンディ」なら、毎日6時間以上ほぼ絶え間なくサーバーとユーザーが対話しています。）
こんな状況だからこそ、逆にデータに耳を傾ける力をチームで強化する機会だと捉え、プロダクト開発プロセスも改善していこうと感じる日々です。