【DotDev 2026 参加レポート Vol.4】POS UI extensions — デジタルのチェックアウトを越えて、店頭のUXから学んだこと

フロントエンドデベロッパーのRossellaです。Shopify DotDev 2026 参加レポートの第4弾をお届けします。DotDev 2026で、私が必ず聴こうと決めていたセッションの一つが、「POS UI extensionsはいかにしてマーチャント体験を良くするか」をテーマにしたファイヤーサイドチャットでした。登壇したのは、Easyteam CEOで2026年のBuild Award受賞者でもあるHarel Ishay、ShopifyでRetail Product Partnershipsを担当するBrian Edwards、そしてShopifyのテクニカルコンサルタントSergio Vazquez Malvaezの3人です。

FlagshipにとってPOSは初めての領域ではありません。クライアント固有のニーズや、地域ならではのワークフローに合わせたカスタムのPOS extensionsを、すでに構築してきました。

それでも、こうしたセッションに参加して、POSソフトウェアの背後にある大きな考え方についての議論に触れることには、計り知れない価値があります。巨大なユーザーベースに向けて公開アプリを作っている登壇者と、まったく異なるクライアント要件を抱えるエージェンシーのエンジニアの双方から話を聞くことで、私たち自身のソリューションへの向き合い方が豊かになります。加えて、米国・カナダ・英国の市場はネイティブPOSの普及という点で格段に成熟しているため、そこで得た国際的な視点をチームに持ち帰ることは、私たちのオムニチャネル戦略を直接強くしてくれます。

私は技術的な解説を聞くつもりで席に着きました。しかし持ち帰ったのは、店頭のために作るということについての、考え方の転換でした。以下は、私がたどり着いた場所です。

0.5秒の間（ま）

セッションのあとも心に残ったイメージは、ごく小さなものでした。お客様がカードをタップした直後の、0.5秒。オンラインなら、誰も見ていないスピナーです。店頭では、カウンターを挟んで向かい合う人と人が、同じ0.5秒を沈黙の中で待っています。

それが少し長引けば、もはやローディング状態ではありません。二人の人間の間の、気まずい間になります。

チェックアウトの速さを、人と画面の間ではなく、人と人の間で起きるものとして考えたことは、それまでありませんでした。

この視点が、残りのパネルを見るときのレンズになりました。

私たちは実際、誰のために作っているのか

トークは小売スタッフの離職率の話から始まりました。登壇者が共有した数字では、年間およそ75%にのぼるそうです。

フロントエンドエンジニアとして、オンラインの機能を作るとき、私は長年積み上げられてきたECのロジックを頼りにしています。カートのフローに何が必要か、標準的なチェックアウトはどう感じられるべきか、初めての顧客とリピーターがストアフロントに何を期待するか。ユーザーは予測可能なメンタルモデルを持って画面に向かいます。

店頭では、そうしたエンジニアリング上の前提が消えます。今日そのインターフェースを扱うレジ担当者は、初出勤の日かもしれないし、3か月後にはいないかもしれません。独自の癖に慣れるための助走期間はなく、長く使い込むことで得られる恩恵もありません。

カスタムのPOS extensionsを設計するとき、私たちは、複雑なツールを徐々に使いこなしていくパワーユーザーのために作っているのではありません。即座に身体で覚えられることのために設計しています。状態の変化は少なく、行動の道筋は一本で、先週の設定を誰かが覚えていることには一切頼らない。標準的なストアフロント開発とは、まったく異なる技術的な要件です。

1タップのコストは、ここでは意味が違う

オンラインの仕事から来た私が、いちばん見落としやすかった部分です。ウェブサイトでのクリックは、ユーザーにほんの一瞬のコストを、人目のない場所で負わせます。レジでのタップにかかる時間も、同じ一瞬です。ただ、それはお客様の目の前で費やされる。その違いが、意味を変えます。不要なタップが3回あることは、店頭では些細なUXの摩擦ではありません。レジ担当者が誰かを待たせなければならない瞬間が、3回あるということです。

セッションを終えて考えたのは、チェックアウトフローの中のすべてのタップを、マーチャントが二重に支払うものとして扱うべきだ、ということでした。一度はそれにかかる時間として。もう一度は、誰かを待たせることがどう感じられるかとして。

設定画面ではなく、一つのワークフローを

どんな店にも合うように、十分に設定可能なものを作る。それは開発者の初期設定ともいえる本能です。登壇者たちは、そこに異を唱えました。小売のワークフローは、オンラインのチェックアウトのように一つの形へ収束しません。ブティックと、美術館のギフトショップと、ホームセンターは、同じやり方で売り場を回してはいません。

良いextensionは結局、一人のマーチャントの実際の日課に沿った形になります。誰にもぴったりとは合わない選択肢のメニューではなく。

この課題は、世界の市場を比べるとさらに鮮明になります。米国やカナダ、英国では、POSのワークフローはネイティブのカードリーダーと、滑らかなタップ決済の恩恵を受けています。しかし香港や韓国といったAPACの店頭に立てば、スタッフはまったく別の現地の現実と向き合っています。地域で支配的なデジタルウォレットから、レジ担当者に端末の行き来を強いる外部の決済ターミナルまで。手作業のステップが一つ増えるごとに、従業員のシフトに摩擦が加わります。カスタムのPOS UI extensionsは、見た目を整えるだけのUIの手直しではありません。複雑でローカライズされた決済の経路を、レジ担当者の主たるワークフローに直接つなぎ込み、不要な運用上の摩擦から守るための、アーキテクチャ上の橋渡しです。

売上の瞬間だけでなく、シフト全体のために設計すること。勤怠の記録、コミッション、返品など、スタッフが取引と取引の間に実際にやっていることすべてが含まれます。開発者はまた、プラットフォームの制約を「解決する」のではなく「その前提で設計する」つもりで臨むべきです。たとえば、一つの販売に対する複数スタッフ間でのコミッション分割は、現時点ではネイティブにサポートされていないため、意図的なUI設計が必要になります。

A/Bテストはない。店がある。

私の検証についての考え方を最も変えたのが、ここです。デジタルの開発では、検証とはたいてい、実験とダッシュボードを意味します。セッションで強調されたのは、POSを深く手がける開発者が、テストし、バグを見つけ、次に何を作るかを決める方法でした。自分のソフトウェアを使っている店に行って立ち、レジを回している人たちに聞くのです。

自分の席に戻る前に、実行可能なフィードバックのバックログができあがっています。

最後に

POSのために作ることの最も難しい部分が、技術ではなく人と人の関係にあるとは思っていませんでした。今週働き始めたかもしれないユーザー、お客様の目の前で支払われるタップ、そしてダッシュボードで測るのではなく現地で見なければならないワークフロー。結局は、そこに帰着します。

DotDevのような交流は、カスタムのPOS extensionsを作ることが、技術的な能力を広げるだけではなく、考え方を絶えず研ぎ続けることでもあると、改めて教えてくれます。エンタープライズクライアントの特定のユースケースを解くときも、成熟した海外市場の知見を取り込むときも、私たちが物理的な小売のためにエンジニアリングするやり方を決めているのは、こうした人間側の制約なのです。