セルフレジに学ぶ、誰のためのUXなのかという問い

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp

これまで組織やマネジメントの話を書くことが多かったのですが、以前から少し気になっていたことがあります。

年末年始の休みに買い物をしている際、やはりそのことが気になったので、今回はそれについて書いてみようと思います。それはセルフレジについてです。

目次

「セルフレジのUIは、なぜあんなに不自由なのか？」

初めてセルフレジを使ったとき、そう感じたことがある方は多いと思います。操作の順番は決められていて、戻ることはできず、選択肢も少ない。

WEBサービスやアプリに慣れているほど、この不自由さは違和感として強く残ります。しかし、この違和感こそが、toB SaaSのUI/UXを考える上で極めて重要なヒントになるのではと思っています。

私は現在、ラクスというSaaS 企業で、プロダクトマネージャーとプロダクトデザイナーが所属するプロダクト部のマネージャーを務めています。日々の業務の中で繰り返し立ち返る問いがあります。 それは、「良いUI/UXとは誰にとってのものなのか」という問いです。

プロダクト開発の現場では、UI/UXという言葉がしばしば「使いやすさ」「分かりやすさ」「シンプルさ」と同義で語られます。しかし、toB SaaSにおいてそれだけを追い求めると、運用が破綻する、問い合わせが増える、結果として顧客価値を下げてしまう──そんな経験をした方も多いのではないでしょうか。

今回、セルフレジやファーストフードのセルフオーダーといったリアルのUI/UXを整理して、私は「これはそのまま toB SaaS に当てはまる構造だ」と強く感じました。本記事では、セルフレジUI/UXの具体例を交えながら、リアルUIとWEB UIの違いがどこから生まれ、なぜ toB SaaS のUI設計にとって重要なのかを整理していきます。

リアルUIとWEB UIは、そもそも戦っている場所が違う

セルフレジやセルフオーダー端末に触れると、WEBやSaaSとは明らかに違う設計思想を感じます。この違いは、UIデザインのトレンドやデザイナーの好みではありません。UIが置かれている環境と、背負っている責任構造の違いから必然的に生まれています。

利用者の「状態」の違い

リアルUI（セルフレジ・飲食店端末）の利用者は、次のような状態に置かれています。

• 立ったまま操作している
• 後ろに行列ができている
• 周囲が騒がしく、集中しづらい
• 初見利用者が多い
• 操作ミスが即トラブルにつながる

一方、WEBやSaaSのUIはどうでしょうか。

• 座って操作できる
• 基本的に一人で使う
• 自分のペースで進められる
• 戻る・やり直しが可能
• 学習しながら使う前提

この違いが、設計思想を真逆の方向へ引っ張ります。

リアルUIは「考えさせない・迷わせない」ことが最優先であり、WEB UIは「ある程度の自由や探索」を許容します。ここを混同すると、UIは破綻します。

コンビニのセルフレジUIに見る「運用者優先」の設計

セブンイレブン  セルフレジ ローソン  セルフレジ ファミリーマート  セルフレジ

コンビニのセルフレジには、実は複数のUIパターンが存在します。

• レジ袋選択 → 商品スキャン → ポイント → 決済
• 決済方法選択 → レジ袋 → 商品スキャン → 完了

一見すると「なぜこんな順番なのか分かりにくい」と感じる方も多いでしょう。しかし、これらはすべて運用上の事故を防ぐための設計のように思います。

例えば、

• レジ袋を最後に聞くと、袋代金の取り忘れが発生する
• 決済直前に袋選択を挟むと、操作ミスが起きやすい
• ポイント提示を忘れると、店員呼び出しが発生する

セルフレジでは、一人の迷いが行列全体を止めるという前提があります。そのため、UIは「直感的であること」よりも「事故が起きないこと」を優先します。これは決してユーザー軽視ではありません。店舗全体のUXを守るための設計だと思います。

ファーストフードのセルフオーダーUIが示す別の最適解

一方、ファーストフードのセルフオーダー端末では、ほぼ例外なく次のような流れが採用されています。

1. 商品選択
2. セット・サイズ・カスタマイズ
3. 注文内容確認
4. 決済

ここで重要なのは、決済が必ず最後に来るという点です。なぜなら、飲食においては「何を食べるか決めるプロセス」そのものが体験価値だからです。

マクドナルドのセルフオーダーを思い浮かべてください。画面には大きな写真、セット提案、期間限定商品が並びます。これはUXのためだけでなく、客単価を最大化するための設計でもあります。しかし同時に、

• カスタマイズは段階的にしかできない
• 戻り操作は最小限
• 注文確定後の変更は難しい

といった制約も多く存在します。ここでも、運用者視点（厨房・提供フロー）が強く効いているように思います。

なぜリアルUIでは「運用者視点」が強くなるのか

セルフレジやセルフオーダーは、UXツールであると同時に業務装置です。1人の操作ミスは、

• 行列停止
• 店員の割り込み対応
• 提供遅延
• クレーム

といった形で即座に表面化します。そのためリアルUIでは、

• 操作順序の固定
• 選択肢の制限
• 確認ダイアログの多用

が「正義」になるのでは推測しています。WEBの世界で嫌われがちなこれらの設計は、リアルでは現場を守るための合理です。

この構造は、そのまま toB SaaS に当てはまる

ここで話を toB SaaS に戻します。toB SaaS もまた、

• 日々オペレーションを行う利用者
• 全体を管理する管理者・組織

という二重構造のユーザーを持っています。

toB SaaSでよく見る失敗

• 「利用者にとって分かりやすいUI」を優先しすぎる
• 設定の自由度を上げすぎる
• 業務フローを柔軟にしすぎる

結果として、

• 管理画面が複雑化
• 設定ミスが多発
• 問い合わせが増加
• 運用ルールが守られない

これは、セルフレジにWEB的UI思想を持ち込んだ時と同じ失敗構造ではと思っています。

セルフレジUIと toB SaaS UI の対応関係

ここで重要なのは、制限＝悪ではないということです。制限は、運用を守るためのUXです。

セルフレジのUI/UXを観察して得た最大の学びは、UXとは「画面を触る個人」だけのものではないという事実です。

toB SaaSにおけるUXは、

• その画面を触る人
• そのデータを管理する人
• その業務を回す組織

全体最適として成立して初めて良いUXになります。

UIを改善するとき、「もっと分かりやすく」「もっと自由に」と言いたくなったら、ぜひセルフレジを思い出してほしいと思います。その不自由さには、必ず理由があります。

プロダクトチームとして、この話をどう使うか

ここまでセルフレジのUI/UXを題材に、リアルUIとWEB UI、そしてtoB SaaSの共通構造を整理してきました。最後に、プロダクト組織の責任者という立場から、この話をどう使ってほしいかをまとめます。

• UXは「画面単体の使いやすさ」ではなく、「業務が止まらないこと」まで含めて考える
• 制限はUXの敵ではない。むしろ運用を守るためのUXであることが多い
• 利用者視点と運用者視点のどちらを優先しているのかを、常に言語化する

これらは、UIレビューや仕様議論の場で、必ず立ち返るべき問いなのかなと思いました。

AIが入ることで、ネットのUI/UXはどう変わるのか

最後に、ネットのUI/UXにおいてAIが入ることで何が変わるのかについて触れておきたいと思います。これは、セルフレジや toB SaaS の話とも深くつながるテーマです。

これまでのWEB UI/UXは、「人が画面を操作する」ことを前提に設計されてきました。ボタンを押し、入力欄に文字を入れ、選択肢の中から選ぶ。そのためUIは、

• どの順番で操作させるか
• どこまで自由を与えるか
• どこで制限をかけるか

を画面上で細かく設計する必要がありました。しかしAI、とりわけ生成AIや対話型UIが入ることで、この前提が少しずつ崩れ始めています。

UIから「操作」を減らし、UXを「対話」に移す

AIが入ることで、ユーザーは必ずしも画面構造を理解する必要がなくなります。「こうしたい」「これをやってほしい」と自然言語で伝えれば、AIが裏側の操作や設定を肩代わりしてくれるからです。

これは、WEB UIを

• 画面中心のUX
• 手順中心のUX

から、

• 意図中心のUX
• 結果中心のUX

へと変えていきます。

それでも消えない「運用者視点」

ただし、ここで重要なのは、AIが入っても運用者視点は消えないという点です。むしろ、AIが自由度を一気に引き上げるからこそ、

• 何をAIに任せてよいのか
• どこは人やルールで縛るのか
• AIの判断をどう制御するのか

という設計が、これまで以上に重要になります。これは、セルフレジで「自由を削ることで現場を守ってきた」構造と非常によく似ています。AIはWEB UIを一気に自由にしますが、その裏側では運用を守るための強いガードレールが必要になります。

toB SaaSにおけるAI時代のUI/UX

toB SaaSにおいては、AIによって

• 設定画面が不要になる
• 操作フローが短縮される
• 専門知識がなくても使える

といった変化が起きていくでしょう。一方で、

• 誤った設定をAIが自動でしてしまう
• 誰がどこまで責任を持つのか分からなくなる
• 組織ルールが崩れる

といった新しいリスクも生まれます。だからこそ、これからの toB SaaS のUI/UXでは、

• AIに任せる自由
• 人が守る制約

を意識的に分離して設計する必要があります。

AI時代だからこそ、セルフレジの学びは生きる

AIはUIを消し去る存在ではありません。むしろ、UI/UX設計の難易度を一段階引き上げます。自由度が増えるほど、運用を守る設計が重要になる。この構造は、セルフレジやセルフオーダーがすでに私たちに示してくれています。AI時代のUI/UXを考えるときこそ、

• 誰のUXを守るのか
• どこまでをUXの責任範囲とするのか

を問い続ける必要があります。

セルフレジ → toB SaaS → AI時代のUI/UX

これらは別々の話ではなく、同じ構造の延長線上にあると、私は考えています。

おわりに

リアルのUI/UXは不自由です。しかしその不自由さは、現場を守り、業務を成立させるための合理です。セルフレジやセルフオーダーを観察すると、

• なぜ手順が固定されているのか
• なぜ自由度が低いのか

が腹落ちします。そしてそれは、そのまま toB SaaS のUI/UXにも通じます。UXを語るとき、「誰のUXか」「どこまでをUXの範囲とするか」を誤ると、プロダクトは壊れます。画面を触る人だけを見て設計すると、現場や組織が苦しみます。

セルフレジは、toB SaaSを作る私たちにとって、現場視点と組織視点を同時に学べる、非常に優れた教材です。もし今後、UI/UXの議論で迷ったときは、ぜひ近くのコンビニやファーストフード店に立ち寄ってみてください。その不自由なUIの中に、プロダクト設計の本質が詰まっています。

この記事を読んで、やラクスのプロダクト部に興味を持ってくださった デザイナー／PdM の方 は、ぜひカジュアル面談からご応募ください。

※プロダクトマネージャーのカジュアル面談は、基本的に私（稲垣）が担当します！

●採用情報 デザイナー career-recruit.rakus.co.jp

  └ デザインマネージャー career-recruit.rakus.co.jp ／アシスタントマネージャー career-recruit.rakus.co.jp