STORES レジ のVOC駆動開発
はじめに
これは hey Advent Calendar 13日目の記事です。
こんにちは、 STORES レジ のiOSアプリを開発をしているたまねぎです。
カバー写真は私の手です。手タレデビューしました。
今年の6月、私達のチームは新規プロダクトである「 STORES レジ 」をリリースしました。
本記事ではこのアプリのリリース後、現在までどういった形で改善を行なってきたかを振り返る内容になっています。
ユーザーの声をベースにした機能開発・改善、不具合対応など、リリースから半年ほどの出来事を紹介します。
※ 本記事では STORES レジ に関する技術的な話についてはしていません。
そちらについては、今年開催されたiOSDC2021にてお話しする機会を頂いたので、もし良ければアーカイブも見ていただけると嬉しいです。
STORES レジ とは
まず最初に、 STORES レジ とはどういったアプリなのかを簡単に紹介させていただきます。
STORES レジ は、「商品のお会計や管理」など、実店舗でのお商売に必要な機能を一通り提供しているiPadアプリで、ネットショップとの連携が強力であるといった特徴があります。
小売店や飲食店などで、お会計時に店員さんがiPad端末を操作しているのを見たことがあるかもしれませんが、その時に利用されているのが STORES レジ のようなPOSレジサービスです。
もしプロダクトの詳細について興味を持って頂ければ、是非サービスサイトの方もご覧ください。
VOCとは
それでは、記事のタイトルにしているVOCについて説明します。
VOCとはVoice of Customerの略で、つまりユーザーの声のことを指しています。
STORES レジ の開発は常にユーザーの声を重要視して機能開発や改善を続けてきました。そのため、本記事上でのみ勝手にVOC駆動開発と開発スタイルを名付けています。
また、POSレジアプリにとっての「ユーザー」とは、お買い物をする人ではなく「店舗を運営する人」です。このことから、我々のチームではユーザーのことを店舗オーナーであることから「オーナーさん」と呼んでいます。
VOC改善フロー
STORES レジ での開発の流れを大まかに説明します。
まず、チームを跨いだ大きな動きとしては下図のようなフローがあり、VOC定例と呼ばれるMTGにてオーナーさんの声を異なる職種間で共有しています。
私が属しているモバイルエンジニアチームの動きとしては、まず週一で開催されるVOC定例にて「オーナーヒアリング」「カスタマーサポートへのお問い合わせ」などの共有を受け、様々な課題をキャッチアップします。
その後、PMによってピックアップされたIssueに対してデザイナーやエンジニアも加わって詳細を詰め、2週間を1スプリントとして毎スプリントアプリのリリースを行なっています。
本記事ではその中から4つ改善事例をピックアップしてみたので、これをきっかけに STORES レジ アプリの改善の動きが少しでも伝わると幸いです。
(※本文中に記載しているオーナーさんの声は、そのまま載せているのではなく要約した内容のみを記載しています)
VOC改善事例①:カテゴリ別アイテム選択画面の改善
まず1つ目は、「カテゴリ別アイテム選択画面」の改善です。
この画面は、登録アイテムをカテゴリごとに分けて表示し、そこから商品選択ができる機能を備えています。
こちらについては、下記のような問い合わせが寄せられました。
この件について調査したところ、表示が遅くなる現象はアイテム登録件数が多いアカウントでのみ発生することがわかりました。
普段メンバーが使うテストアカウントには、大量のアイテム登録はされていないので、VOCの仕組みがあったおかけで気づくことが出来た形になります。
大量アイテム登録アカウントを用いたパフォーマンステストはリリース前にも行っていたのですが、ここはメイン導線ではないという認識があったためか、見落としがありました。これはリリース直後に分かった件なので、イメージしている使い方と実際の使われ方が異なることを改めて認識する良い機会となりました。
VOC改善事例②:在庫切れ表示機能
次は「商品在庫」に関してです。
STORES レジ には、商品情報を STORES のネットショップと連携できる強力な機能が備わっています。
例えば「ネットショップ」と「実店舗」両方を運営しているオーナーさんの場合、その両方で販売している商品をそれぞれ別で管理するのは大変です。「オンラインでアイテムが売れる→実店舗のアイテムの在庫を修正する」といった手作業が必要になるかもしれません。
STORES レジ ではそのような作業は必要なく、1つの商品データを共通で管理できます。これにより、ネットショップで商品が売れると自動で共通の在庫データを減らすということが実現可能になります。
しかし、リリース直後のレジアプリには「ネットショップ販売で共通在庫が減った結果、レジ側で在庫切れになったことが気付きづらい」という使いづらさが残っていました。
下記がオーナーさんから寄せられたお問い合わせです。
変更前のホーム画面の表示は下記のようになっており、各アイテムが在庫切れしているかを認識できません。
この状態から改善検討が始まり、最終的には下記のように「在庫切れ状態がホーム画面上で視覚的にわかる」UIに変更されることになりました。
この問題はリリース当初からある程度認識はしていたのですが、実際のオーナーさんの声を聞くことでより課題の解像度が上がり、実現すべき状態を明確にできました。
VOC改善事例③:プリンター不具合関連
次は不具合の修正対応についてです。
STORES レジ などのPOSレジアプリは、外部ハードウェアとの連携が豊富な点も大きな特徴の1つです。
ハードウェア連携の対応はとても難しいもので、リリース前に十分なテストはしたものの、実際に店舗利用が開始すると様々な不具合が報告されるようになりました。
また、ハードウェア関連の不具合は、検証端末が会社にあるという点でリモートワークが中心の働き方と相性がとても悪く、「問い合わせ→迅速に出社→再現確認→修正→リリース」という流れが突如発生する点も対応が難しい要因の1つでした。
これらの不具合は、環境や利用方法に依存していることにより問題が再現しづらいこともありました。そのため、修正対応をした未リリースアプリを直接オーナーさんに(TestFlightの外部テスター機能で)配信して、個別で修正確認を行なってもらったこともあります。
こういった地道な対応を続けた結果、直近ではプリンター関連のお問い合わせが大幅に少なくなり、リリース後半年をかけて着実に安定化していっています。これはチームとしてオーナーさんと密接なコミュニケーションを取ってきたからこそ実現できたことです。
VOC改善事例④:バーコードリーダー精度改善
最後はバーコードリーダー機能に関する話です。
STORES レジ では、商品登録時にJANコードを設定できます。これにより、対応バーコードを「iPadのカメラ」もしくは「専用のバーコードリーダー」で読み取ることで、直接商品をカートへ投入できるようになります。
この機能について、あるタイミングで「iPadカメラでバーコードの認識がされない」という報告を受けました。
手元の環境では再現できず、オーナーさんの環境を伺ったところ、多数のバーコードを隣接した状態で読み取りをしていることがわかりました。
隣接したバーコードに対する読み取り操作は、そもそもの使い方として認識精度を下げる要因となり得ます。
そのため、これはプロダクトの問題ではなく使い方の問題であると割り切り、利用方法を変更するご案内をするだけという選択肢もありました。
しかし、ここではVOCの経験を元にして「オーナーさんの使い方に合わせる」にはどうすればいいのかと、オーナーさん目線になって考えてみることにしました。
結果「iPadカメラでの認識領域を特定範囲に狭める」という改善対応を思いつき、実際に修正版を利用してもらったところ、明らかに認識精度が上がったという嬉しいフィードバックを頂くことができました。
このように「オーナーさんにこちらが想定する使い方を強制させない」「オーナーさんの環境に合わせてプロダクト側を改善する」という考え方ができたのは、普段からVOCベースの開発を行なってきたからこそ自然にできたことだと思います。
これから
以上が、リリース後半年間で行なってきたVOC改善事例の一部の紹介でした。
直近では、何度もオーナーさんヒアリングを行いブラッシュアップした「ホーム画面を自由にカスタマイズできる機能(通称カスタムパネル)」をリリースしたりなど、 STORES レジ は日々進化を続けています。
とはいえ、このプロダクトはリリース後まだ半年のプロダクトです。足りない機能の拡充や独自の価値創造など、今後もやるべき事は沢山あります。
それにあたり、オーナーさんと同じ方向を向いて一緒にサービスを成長させていくには、このVOC改善フローは欠かす事が出来ません。
2022年以降もSTORES レジはさらなる進化をしていきますが、「オーナーさん目線」であることを忘れずに、今後も技術の力で貢献していければと思っています。
以上、hey Advent Calendar 13日目を @_chocoyama がお届けしました。
最後に、STORES レジはユーザーの声を聞きながら開発できる環境です。新しい仲間も絶賛募集中なので、興味がある方は採用ページもぜひご覧ください。
この記事が気に入ったらサポートをしてみませんか?