さらなる顧客拡大のために、いまや企業のDX推進は必須といえます。しかし、顧客の利便性を重視するあまり、セキュリティーが脆弱なサービスを提供してしまっては、かえって顧客の信頼を失いかねません。本記事では、特定非営利活動法人失敗学会理事の佐伯徹氏の著書『DX失敗学　なぜ成果を生まないのか』より、セブン＆アイ・ホールディングスのDX失敗原因について紐解いていきます。

顧客拡大を狙ってセキュリティレベルを下げて失敗

～事例から【他山の石】としていただきたいこと～

企業戦略のために顧客拡大を狙うのは民間企業では当たり前のことである。しかし、顧客の使い勝手を優先して大事なセキュリティーに目をつぶってしまった結果、顧客の信頼を失ってしまった。

セブン＆アイ・ホールディングス「7pay（セブンペイ）」

DX戦略

電子決済としては後発であるが、「かんたん」「便利」「おトク」を3大コンセプトとして、登録から支払い・チャージ・ポイントなどにおいて、ユーザーが簡単で使いやすくお得になるサービスとして打ち出された。

7payとは？

7payはセブン＆アイ・ホールディングス（以下セブン＆アイ）が2019年7月1日に始めたスマートフォンによるバーコード決済のサービス。2万店舗を超えるセブン-イレブン店舗で利用できるようにした。

既存のセブン-イレブンアプリに支払い機能を付加したもので、アプリトップ画面からわずか2タップで利用登録できるという簡単さを売りにした。当初の予定では、2019年10月以降に外部加盟店での利用も始め、2020年からはセブン＆アイグループ各社のアプリとの連携を図っていく予定だったが約3ヵ月でサービス終了となった。

＜サービス開始時点での7payのメリット＞

・スマートフォンをツールとした、セブン&アイ独自のバーコード決済サービスである。

・セブン-イレブンアプリから最短2タップの画面遷移で簡単に登録できる。

・店頭レジ、セブン銀行ATM、各種クレジットカードなどからチャージが可能である。

・使用方法として、レジでお会計の際に「支払いバーコード」画面を提示し、バーコードを読み取るだけ。

・7payによる支払いでnanacoポイントもためることができる。

失敗事象

不正アクセスによって第三者によって支払われてしまう事案が多数生じた。

被害状況

808人／38,615,473円（2019年7月31日17：00時点）

不正アクセスの手口

セブン＆アイが情報セキュリティーの会社と連携した「セキュリティ対策プロジェクト」の調査によると「攻撃者がどこかで不正に入手したID・パスワードのリストを用い、7payの利用者になりすましつつ、不正アクセスを試みる、いわゆる『リスト型アカウントハッキング』である可能性が高い」（セブン＆アイのプレスリリースより）とされた。

2019年8月1日現時点では、「外部ID連携・パスワードリマインダー、有人チャットによるパスワードリセットなどの機能が、不正アクセスの直接の原因となった事例は見つかっておらず、内部からの流出についても、実査も含め、確認調査を行ったが、明確な流出の痕跡は確認できない」との結果が取りまとめられた。

本事案発生の原因

犯行を防ぐことができなかった理由として3つの要因と対応策が挙げられた。

①7payに関わるシステム上の認証レベル

「複数端末からのログインに対する対策」や「二要素認証などの追加認証の検討」が十分でなく、結果『リスト型アカウントハッキング』に対する防御力を弱めることとなった。

②7payの開発体制

7payのシステムの開発には、グループ各社が参加していたが、システム全体の最適化を十分に検証できていなかった点が今回の事案を引き起こした原因の可能性がある。

③7payにおけるシステムリスク管理体制

7payにおける、リスク管理上、相互検証、相互牽制の仕組みが十分に機能していなかった可能性がある。

経緯

結論

以下の3点の理由から、2019年9月30日をもって7payのサービスを廃止した。

①7payについて、チャージを含めて全てのサービスを再開するに足る抜本的な対応を完了するには相応の期間が必要である。

②その間、サービスを継続するとすれば「利用（支払）のみ」、という不完全な形となる。

③顧客の不安を完全に拭うのは難しく、7payのサービススキームを保ったままサービス提供を継続することは困難である。

失敗の真の原因を考察

ここまで公開された報告内容を使い、直接的ではない真因を考察していきたい。本来であれば、「ITプロジェクト版失敗原因マンダラ図」はグループ作業を推奨しているが、個人でも作業が可能であるため、本記事では筆者の知見・知識でステップ1～5を行ってみる。

読者は本記事を読み終えたあと、自分ならどう考えるかをぜひ実践していただきたい。それでは失敗の原因をリストアップしていく。

ステップ1：「ITプロジェクト版失敗原因マンダラ図」から全ての失敗原因を抽出する

「ITプロジェクト版失敗原因マンダラ図」の使用方法として、時計の8時の位置に置く＜個人＞に関する原因から、時計回りに＜プロジェクト＞＜組織＞＜未知＞まで順に原因を考えていくが、できれば作業は個人の知識だけに頼らないように、グループ（複数人）で進めるのが望ましい。

1人でも作成可能だが、プロジェクトに参画した複数のキーパーソンで議論したほうが、より客観的かつ網羅的に原因を究明できる可能性が高いことが過去の検証で実証されている。まず、＜個人＞に関する責任の第一階層の中で、【無知】の「知識不足」、「経験不足」「引き継ぎ」の3つの失敗原因から、原因を想像してみる。

ステップ2：抽出した失敗原因を集約する

ステップ2としてグループ作業の場合は一人ひとりが作業したものを1つの表にまとめていく。今回は、例として4名がグループ作業を行ったイメージ図を記載している。筆者の作業結果をAさんの列に記入した。失敗学会の思想として、原因の究明が大切であり、「誰が原因か」といった、特定の個人の名前は必要ないため、ABCDなどの符号で個人が特定できないように配慮する。集約したイメージ図は下記のようになる。

ステップ3：失敗原因を整理する

集約した＜グループ作業＞の場合の一覧表は個人の知識・経験に依存しているものであるため、メンバー間でなぜ原因であると考えたのかを議論する。さらに、議論の終盤でいいので、選定されなかった原因項目について、選定されなかった原因をメンバーで討議しておいてもらいたい。さらに、次のステップにむけて、連関図で配置する場合の時間軸を記載していくと次の作業がスムーズになる。

ステップ4：真の失敗原因を特定する

ステップ3で討議した内容から具体的に事象がどこで発生したものかを並べ、連関図を作成していく。線で結ぶ際は、記載された事象から関係性を表していくと関係性の深いものは線が多く交わっていくことがよく分かる。

「推測」をできるだけ排除した「事実」だけを集め、失敗を判断する

失敗学会※では「三現主義」を唱えている。三現主義とは「現地に出向き、現物にさわり、現人（人間）に会う」ことである。専門職なら誰でも頭の中に持っている「暗黙知」を分かりやすく表出し、皆と共有するためである。

※失敗学会：筆者が理事を務める特定非営利活動法人「失敗学会」は、広く社会一般に対して失敗原因の解明および防止に関する事業を行い、社会一般に寄与することを目的とする。

そのため、ステップ1で選定しなかったもの、少数の意見を拾うことが重要と考えている。今回は筆者一人で原因を考えているため、「三現主義」を実施できないが、外国を含む遠方で起こった事故なども「三現主義」の実施は難しい。

そこで、筆者を含む失敗学会としては「事実」を1つのメディアから取り入れるのではなく、多くのメディアや新聞情報などから「推測」をできるだけ排除した「事実」だけを集め判断することに用いている。今回もできるだけ多くのメディアや新聞情報などから、「事実」を集め、当事者の気持ちで考えるのではなく、客観的に俯瞰してみた結果を伝えることとする。

筆者が考える今回の問題点

それでは、セブン＆アイが考える7payの問題点と筆者が考えた問題点を比べてみよう。セブン＆アイが考える3点は以下のものである。

①7payに関わるシステム上の認証レベル

「複数端末からのログインに対する対策」や「二要素認証などの追加認証の検討」が十分でなく、結果『リスト型アカウントハッキング』に対する防御力を弱めることとなった。

②7payの開発体制

7payのシステムの開発には、グループ各社が参加していたが、システム全体の最適化を十分に検証できていなかった点が今回の事案を引き起こした原因の可能性がある。

③7payにおけるシステムリスク管理体制

7payにおける、リスク管理上、相互検証、相互牽制の仕組みが十分に機能していなかった可能性がある。

そして、筆者が問題としたのは、下記の3点である。

①「かんたん」「便利」のコンセプトを重視するあまり、結果的にセキュリティーレベルをさげてしまうことへの危機感がなかった。

②アプリケーションのシステムコード（プログラム）が全世界に流出した可能性が予見された時点で、セキュリティーに問題が発生していることへの想像力を働かせることができなかった。

③生産・販売の業界と金融業界の常識は違っていて当たり前という前提にたち、不足している知識、経験を外部に依存するだけでなく、自分たちで調査することで外部委託会社を牽制するためのプロジェクト体制が構築できなかった。

上記を読者の方が読まれて両方を読まれた感想はいかがだろうか。大抵の報告書は結果を導きだす導線が描かれることはないため、なぜ、そのような結論となったのか、読者も首をかしげることもあるのではないか、今回、筆者が「ITプロジェクト版失敗原因マンダラ図」を使って、結論を導き出す導線を可視化したことで、セブン＆アイと同じ答えとなっている部分も理由が腑に落ちるのではないだろうか。

ステップ5：再発防止策を検討し蓄積・活用する

上述で真因となる事象が発見されれば、各社が今まで蓄積されている対応策を使用することともでき、また、新たな事象であれば、筆者が想定した対応策を参考にしていただきたい。筆者が考える対応策は次の5点。

①人材確保

電子決済アプリケーションであることから、サービス業界のセキュリティーレベルだけでなく、金融業界のセキュリティーレベルを理解した人材を確保し、アプリケーションに必要なセキュリティー水準を確保する。「かんたん」「便利」なサービスレベルの開発を行うに当たってのリスクコンティンジェンシープランを作成し、経営者は第三者による評価を確認しながら、定点チェックをおこない最大限のリスク低減を図る。

②セキュリティー教育

開発メンバーだけでなく、システムに関わる全てのメンバーがセキュリティーの重要性について定期的に教育を受け、セキュリティー意識を高める。今回のケースはシステムコード（プログラム）が漏れた可能性が予見された時点で、運用開始はできない予測のもと経営者と問題点を協議のうえ、システムコード（プログラム）を再設計する。

③情報開示

システムコード（プログラム）が流出した可能性がある場合、悪意者がどのような行動をとるか想像する。対処例として、漏れた事象を公開し対応策（処置）を行うことを発信することで、悪意者がシステムコード（プログラム）を入手しても利用できないと思い込ませる。また、万一の不正に備え、プログラム言語を変更するなどアクションプランを作り最悪の事態を想定した対応を行う。

④情報発信

強制リセット行為は「伝家の宝刀」を抜いたと考えられるが、リセットを行うことでどこまで影響を及ぼすか想像する。対処例として、コールセンターに問い合わせが殺到することを考慮して大幅に人員を増やすだけでなく、時間を最大限に延長し丁寧に対応する。

また、既存店舗の影響が避けられないため、店舗入り口で特設コーナーを設置し対応している姿をメディアに公開し、お客様を大切に思っている姿を明確に宣伝することで、失った信頼を再構築する。

まとめ

今回、本件の報告書で発表されたものと「ITプロジェクト版失敗原因マンダラ図」から考える真因への対応は違っていることが分かる。報告内容は、該当プロジェクトの事象だけに沿ったものである。失敗全体が記載されている「ITプロジェクト版失敗原因マンダラ図」を使うことで、本来見えなければならない事が関係者の知識に関係なく見えてくる点が違うことをお伝えしておきたい。

佐伯 徹

特定非営利活動法人失敗学会

理事