顧客通知、オークションへの参加、落札後の決済、サービス運用は一つの利用体験です。キダルト収集品のライブコマースB社で開発・クラウド・顧客メッセージング・決済を一緒に構築し、リリース後はQAと運用へつなぎました。
オークション型ライブコマースを作るとき、放送画面だけが完成してもサービスは始められません。顧客は放送が開かれることを知る必要があり、参加した取引は決済へつながらなければなりません。運用チームは、その過程で何が起きたのかを確認できなければなりません。
B社はキダルト収集品を扱うライブコマースを新たに準備していました。開発の成果物とともに、サービスを載せる環境、顧客へ出す通知、資金が通る経路が同じリリース日程の中で必要でした。
IXCが担った仕事は、それぞれのソリューションを設置することで終わりませんでした。異なる機能が顧客にとって一つのサービスとして動くようにつなぐことでした。
四つの作業には、一つのリリース日程がありました
開発、インフラ、メッセージング、決済をそれぞれきちんと構築することも重要です。しかし個別の作業が完了したという事実が、利用の流れ全体の完成を意味するわけではありません。
顧客通知に必要な機能がまだアプリにないこともあれば、決済結果を受け取ってもサービスが次の状態に進まないこともあります。こうした接点は、各部分を別々に見るときより、全体の流れを一緒に見るときに現れます。
B社では、クラウド環境とデプロイ経路を開発日程に合わせて準備し、メッセージング連携と決済構築を同じ日程の中で進めました。環境の切り替えには、戻す条件も整理しました。
この方法の意味は、担当会社の数を減らしたことだけにあるのではありません。変更に必要な条件と前後関係を、一つの日程の中で扱うことにあります。
顧客通知は設置ではなく、運用の出発点まで作りました
顧客メッセージングは、SDK連携とチャネル設定、基本キャンペーンの構成を一緒に進めました。放送と顧客の接点を作り、運用担当者がその後キャンペーンを広げていける出発点を用意したのです。
通知機能は、メッセージを送れるという事実だけでは完成しません。どんな状況で誰に連絡し、顧客がメッセージを受け取ったあとどこへ移動するのかまで、運用の文脈が必要です。
ただし、システム連携とキャンペーンの成果は区別しなければなりません。チャネルをつないだからといって、顧客がより多く戻ってくると断定することはできません。顧客の反応を見ながらメッセージの対象と内容を調整する仕事は、運用の中で続きます。
このプロジェクトの構築範囲は、その運用が始められるよう基本構造を整えることにありました。
決済の成功より先に、決済の状態を定めました
決済では、承認と取消、部分返金の状態を定義したうえで連携しました。同じ要求の重複処理を減らすための一意な識別基準と再試行ルールを用意し、テスト環境で失敗経路も確認しました。
決済の例外を考えてみると、状態の定義がなぜ必要かが見えてきます。要求を送ったあと応答を受け取れなかったとき、サービスは成功と失敗のどちらとして処理すべきでしょうか。無条件に再要求したり、注文を失敗と表示したりするだけでは十分ではありません。
同じ要求を繰り返しても取引が二重に反映されない性質を冪等性と呼びます。名前より重要なのは、顧客が意図した一回の取引が、システムでもその取引として追跡されるかどうかです。
決済連携では、決済画面を開けるかだけでなく、想定どおりに応答しない状況でサービスがどんな状態を残すのかも併せて見る必要があります。
ポイントも別々の数字として残しませんでした
B社にはポイントのチャージ・管理機能も追加しました。決済とポイントという二種類の取引を、つながった記録として管理する構成でした。
ポイント残高は画面に表示される数字ですが、運用ではその数字がなぜそうなったのかを説明できなければなりません。チャージした履歴と使った履歴を分けて理解して初めて、顧客からの問い合わせにも対応できます。
今回の構築では、決済とポイント取引のつながりを扱いました。取引が発生したときに互いにどの記録を参照すべきかを整理し、購入の過程とポイント管理がかけ離れた機能として残らないようにしました。
取引機能が増えるほど、ボタンの種類より取引記録のつながりを先に考えるべきだということを示しています。
リリース後も検証と運用が続きました
サービスはリリース後に運用段階へ移り、クラウド運用とリリースQAを続けました。構築を終えたあとの変更も、同じサービスの文脈で扱う方式です。
ライブコマースでは、一部分の修正が別の部分の利用の流れと出会います。したがって機能ごとの完了だけでなく、変更後も顧客体験がつながっているかを確認する必要があります。
このプロジェクトが示すのは、多様な技術を使ったという事実より、その関係を一緒に扱った方法です。顧客接点を作るメッセージング、取引を処理する決済、サービスを載せるクラウド、変更を確認するQAが、一つの運用対象としてつながりました。
放送を見られるサービスから、顧客を案内し、取引をつなぎ、改善し続けられるサービスまで。B社の構築範囲は、その流れ全体にありました。