お客様係と一緒に取り組んだ、不正注文対策プロジェクトのプロセスを振り返ります
こんにちは。クラシコムでエンジニアをやっている矢田です。少し前の話になりますが今回は「北欧、暮らしの道具店」に対する不正注文の対策を行なった話をしたいと思います。
ECサイトへの攻撃にも様々な種類があると思います。例えば、不正アクセスやサイトの脆弱性を狙った攻撃、DDoS攻撃などが考えられます。今回対策した「不正注文」というのは「不正なユーザー」が「不正なクレジットカード」を利用し「実際に商品を注文」することを対象にしています。
この不正注文で、なにが困るかというと、
不正なクレジットカードを利用しているため元々のクレジットカード利用者が想定していない請求がされてしまう
不正注文と気づかず発送してしまったあとにクレジットカード会社からキャンセルが入ってしまい損失が出てしまう
といった、お客様や当店を利用されたことがない方、もちろん弊社にも影響がでてしまうことです。
一般的に不正注文による被害は増加しており、各社で様々な対応を取られていると思います。
クレジットマスターと呼ばれる攻撃もよくみられる手口で、クレジットカード番号が漏洩していなくても不正利用の被害にあうこともあります。
IPAの情報セキュリティ10大脅威の第4位にもクレジットカードの不正利用が入っており、ECサイトでは必ずなにかしらの対策が必要とされています。
弊社では以前からこの不正注文を防ぐために、お客様係のスタッフが受注システムを使ってほとんど手動だったり目視だったりで作業を行っていました。しかし、不正注文の確認に多くの時間を取られてしまい、他の業務を行う時間が逼迫することが問題になりました。
そこで、システム側からのアプローチでなんとか不正注文を確認する作業を減らせないか、お客様係とテクノロジーG共同のプロジェクトとして、不正注文対策を行うことになりました。
進め方はまず、お客様係からどのような不正注文を確認する作業にどれくらいの時間がかかっているかをヒアリングしました。次に、どういった表示や機能があれば良いかをリストアップしてもらいました。そこからテクノロジーGの方で実装可能か、また他に良い方法がないかを検討し、お客様係と意見を交換しました。最終的に、対策方法を一覧にし各開発項目に「開発工数」と「インパクト」を決めました。
「開発工数」と「インパクト」の定義は次のようにしました。
開発工数: テクノロジーGの開発にかかる時間。1,2,3のいずれかの数字で各数字のおおまかな決め方は以下にしました。
1: 1週間未満
2: 1~2週間
3: 3週間~
インパクト: お客様係の業務にどれくらいがどれくらい軽減されるかの指標。1があまり軽減されなくて3が多く軽減される。
この「開発工数」が一番小さく、「インパクト」が一番大きい順に優先順位をつけました。
RICEという優先順位付けを参考にしています。
開発は、1機能につきエンジニアが1人つく形で、エンジニア3人体制で行いました。各機能の詳細はそれぞれのエンジニアがお客様係のスタッフと相談して実装を進めました。各機能を詰めていくために都度ミーティングをしつつ、週1の頻度で定例を実施し進捗の確認やリリースした機能の振り返りをしました。
おおよそリリースして1週間ほどお客様係のスタッフに利用してもらってから機能のフィードバックをもらって効果測定を行いました。
定例で「実装→利用→フィードバック」を行うことで短い期間で機能の改善と効果測定を行うことができ、さらに別のチームであるお客様係とテクノロジーGとの間でよりコミュニケーションを取りやすくすることができました。
今までやっていたプロジェクトではプロジェクトが終わった後に振り返りを行うことが多かったのですが、機能をリリースしてすぐフィードバックをもらうことで記憶が新しいうちに集中して改善することができました。業務軽減の効果測定は数値として見えづらいですが、業務時間を比較することで対策の効果が分かりやすかったです。
機能にもよりますが、お客様係のスタッフの体感で業務負荷が半分 ~ 4分の1程度になったというフィードバックもありました。
これまでは他チームから新しい機能開発だったりシステムの修正だったりの依頼をいただいて、開発そのものはテクノロジーG内の話し合いで行うことがほとんどでしたが、今回お客様係のスタッフと一緒にプロジェクトを進めることで、細かい仕様を詰められたりテクノロジーGだけでは気付けないような箇所を取り入れることができたりしました。
リモートワークで働いていると他のチームの業務が見えづらくなりますが、週に1回の頻度でミーティングをやってみると、具体的な業務の進め方や、システムの使い方が見えてきて他チームの利用するシステムを今後開発・改善していく上で「ここが使いにくそうだな」「こんなところが意外と使われているのか」という発見がありとても勉強になりました。
今回行った対策について、詳細の内容は書けませんが、不正注文として確認する必要がある注文を絞ったり確認作業がしやすいような情報表示の工夫を行っています。「不正注文」というのは様々な種類があるため「これが不正である」と確定して見つけることが難しいので、受注システムで不正注文のみを表示するのではなく、最終的にスタッフが目視で判断するための手助けをするような改善を行いました。
もしブログを読まれた方で現場の業務改善を行う際に他チームとの進め方でこういった方法でやっているよ！といったものがありましたらぜひ教えてください。
今回は不正注文対策としてお客様係のスタッフと一緒にシステム改修からフィードバックまでを行いました。プロジェクトの進め方として社内で運用しているシステム改修改善に向いていそうだったので、別のチームが利用しているシステムでも要望を受けて修正するだけでなく改修方針の決定からフィードバックまで一緒に進められると、よりクラシコムとしてやりたいことが実現できるシステムになるのではと思っています。
クラシコムでは社内の課題を技術的に解決したり「北欧、暮らしの道具店」を支えるシステムを一緒に改善したりできるエンジニアを募集しています。少しでも興味がありましたら気軽にお話しできればと思っています。是非お声がけください！
