Back in Stock管理UIの実装ポイント

通知の仕組みは、管理画面がないと運用できない

配信の仕組みをどれだけ丁寧に作っても、その状況を見る画面がなければ運用は回りません。「通知が届かない」という問い合わせが来たとき、どこで止まっているのかを調べる手段がなく、エンジニアにログの確認を依頼して返事を待つことになるからです。1件ごとにこれをやっていると、問い合わせ対応そのものが回らなくなります。

この記事では、再入荷通知の管理画面に何を持たせるかを整理します。画面のコンポーネントはまだ作っていないので、実装した結果の紹介ではなく、着手前の要件の整理として読んでください。管理画面は「エンジニアが使う開発者向けの画面」ではなく、運用チームが毎日開く道具として設計します。

見るための画面と、動かすための画面を分ける

一枚に詰め込むと誤操作が起きる

異常に気づくための画面と、実際に送り直しを実行する画面を同じ場所に置くと、確認のつもりで開いたときに操作ボタンを押してしまう事故が起きます。特に通知が大量に詰まっているような場面では、慌てて操作しがちです。

そこで、全体の状況を見る画面と、対象を絞って操作する画面を分けます。前者は「いま何が起きているか」だけを表示し、後者は絞り込んだうえで実行する。日常の作業で迷わない導線をつくることが、この画面の品質をいちばん左右します。

詳しく調べる画面は時系列で追えるように

1件の通知を開いたとき、対象の商品、いまの状態、何が原因で失敗したか、これまでに何回送り直したか。この4つが時間の順に並んでいると、状況を把握するのに説明が要りません。

運用担当が知りたいのは、多くの場合「なぜ失敗したか」より先に「次に何をすれば直るか」です。原因と、そのとき取るべき操作をセットで表示する。開発向けの生の記録は、折りたたんで下に置いておけば、読みやすさと調べやすさのどちらも保てます。

上の2つが「調べるための画面」、下の2つが「変えるための画面と、その記録」という分け方です。役割を混ぜないことで、確認中の誤操作を減らせます。

送り直しで事故を起こさないための作り

何件に送られるのかを先に見せる

送り直しは便利な機能ですが、条件の指定を間違えたまま一括で実行すると、大量の重複通知が飛びます。一度送ってしまうと取り消せないので、実行前に止める仕組みが必要です。

具体的には、実行する前に対象が何件あるかを表示する、確認の画面を1段挟む、一度に実行できる件数に上限を設ける。この3つで、ほとんどの操作ミスは止まります。忙しいときほど焦って押してしまうので、「押しにくくする」ことを仕様として先に決めておくのが効きます。

設定を変えたとき、いつから効くのかを書く

送信の間隔や1日の上限といった設定は、変更すると配信の結果に直接影響します。ところが画面に数値の入力欄だけが並んでいると、変更した内容がすぐ反映されるのか、次回の配信から効くのかが分かりません。

設定画面には、反映のタイミングと適用される範囲を明記します。あわせて、変更前と変更後の値を並べて確認できるようにしておく。設定の変更が中身の見えない操作になっていると、何かあったときに原因を特定できないので、意図と結果を後から追える形にしておきます。

個人情報の見え方を、役割ごとに分ける

標準は伏せ字、必要なときだけ全体を表示

管理画面は通知の宛先を扱うので、ユーザーの連絡先が並びます。ここを何の制限もなく全部表示する作りにすると、画面を開いただけで個人情報を見ている状態になります。標準では一部を伏せて表示し、全体を見られるのは限られた役割の人だけ、という形にします。

障害の対応中は焦っているので、画面共有や画面の撮影で情報が外に出やすい場面でもあります。運用のルールで気をつけるだけでなく、画面側で表示できる情報を絞っておく。仕組みで防いでおくほうが、実務では確実です。

普段は伏せ字、必要なときだけ全体を見る。そして見たこと自体も記録に残す、という切り分けです。

役割を3つに分け、操作の記録を残す

権限は3つに分けておくと扱いやすくなります。見るだけの人、送り直しや一時停止まで行う人、設定やメール文面まで変更できる人。全員に全部の権限を渡さないだけで、誤操作の範囲はかなり狭まります。

そのうえで、誰がいつ何を変更したかを記録として残します。誤操作や想定外の操作に気づけるようになり、何が起きたのかを説明できるようになる。管理画面は機能を足すより先に、この統制の部分を整えておくほうが安全です。ここが弱いまま運用の規模が広がると、後から立て直すのが大変になります。

成果の数字は、動かしてから足していく

いま出せない数字は書かない

通知の仕組み自体をまだ作っていないので、通知経由の売上や、通知から購入に至った割合といった実績の数字は存在しません。管理画面の設計としても、これらを「現在の成績」として置く前提にはしていません。将来観測したい項目の候補、という位置づけです。

作る前に成果を断定しないでおくと、読む側にも運用チームにも誤解が生まれません。実装が進んだ段階で、実際に取れた数字を追記していく形にしておきます。

追いかける順番を決めておく

計測を始めるときは、まず配信そのものの数字から入るのが安全です。送れた件数と失敗した件数、そして失敗の理由の内訳。ここが安定してから、通知を開いた人、そこから商品ページへ進んだ人、購入した人、という順に広げていきます。

一度にすべてを計測しようとすると、数字が取れているのか、取れているが正しくないのかの区別がつかなくなります。ひとつずつ確かめながら広げるほうが、最終的に信頼できる数字になります。この順番を決めておくこと自体が、管理画面の作る順番にもなります。

まとめ

管理画面は見た目を整えるための画面ではなく、運用の安全を支える土台です。見る画面と動かす画面を分ける、送り直しに歯止めをつける、個人情報の見え方を役割で分ける、操作の記録を残す、そして今は出せない数字を無理に置かない。この5つを決めておけば、実装フェーズに入ってからも品質を落とさずに進められます。