目次
はじめに
話題になっている7payの話を、ソフトウェアテストの知見（ソフトウェアテストの7原則）を使って、反面教師として次に活かせる形にして書いてみます。
ただし、「これを知れば事前に防げる！」と主張したいのではなく、（エンジニアも経営層も）意識して臨まないといけないという意味も込めて書きます。
この記事の元ネタ
教訓の元にした7pay会見の記事はこちら
ソフトウェアテストの7原則の説明はこちら（昨年に改定された版を引用しています）
【リンク】ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J02
教訓1:「脆弱性はなかった」という発言
セブン＆アイの清水健執行役員は「あらゆるサービスについて、事前にセキュリティ審査をやっている。7payもきちんと確認したが、脆弱性（ぜいじゃくせい）はなかった」と繰り返し強調した。
この部分から活かせる教訓は2つ。
ソフトウェアテストの7原則の1.テストは欠陥があることは示せるが、欠陥がないことは示せない
テストによって導き出せるのは、欠陥があることのみです。悪魔の証明ってやつですね。
上記の発言が「（セキュリティ審査の中では）脆弱性がなかった」という報告であれば良いです（結果としては良くないけど）。
ただし、「セキュリティ審査はやった。だから脆弱性はない」という主張であれば、明確に「テストは『欠陥があること』しか示せない」という原則を理解していないことが分かります。
ソフトウェアテストの7原則の7.「バグゼロ」の落とし穴
「バグがない＝素晴らしいとは限らない」ということです。
特に今回のように、「セキュリティ審査では1件も問題が出なかった」という報告は（特に経営陣は）安心材料になったのかもしれないです。
ただし、そこには落とし穴があり得るという理解が必要です。
教訓2:仕様・設計の段階での指摘
そもそも「明らかに問題がありそうな仕様・設計」について、現場担当者レベルで誰も気付かなかったのかという疑問は残る。
この部分から活かせる教訓はこれ。
ソフトウェアテストの7原則の3.早期テストで時間とコストを節約
テストに関しては初期部分から入ることが重要です。
今回の場合は仕様策定や設計段階で気づくべき内容を、リリース後まで放置していたためにこれだけ大ごとになってしまっています。
仕様レビューの段階で「これってどうなの？」という話し合いがあれば、きっと小1時間で修正できたでしょう。*1
（「現場は修正したかったが、政治的なことがあって…」とかは邪推できますが、一旦その話は置いときます）
教訓3:決済系のサービスに対するテスト
今回の大規模な不正アクセス被害で多くの利用者の信頼を失ったのも事実だろう。「スマートフォン決済全体の信頼を損なう出来事ではないか」と指摘されると、小林社長は「（今回の件は）残念な事象。スマートフォン決済は安心、安全、便利と思ってもらえるよう、早急に立て直したい」と答えた。
この部分から活かせる教訓はこれ。
ソフトウェアテストの7原則の6.テストは状況次第
全ての製品・サービスにおいて同じテストを当てはめれば良いのではなく、状況によって変わっていきます。
生命を扱う製品・機能と、使いやすさを追求するだけの製品・機能では、テストの工数や方法なども変わっていきます。
今回の場合は決済というお金を扱う部分が含まれているにも関わらず、テストがきちんと行われていなかったように思われます。
セブンイレブンの場合、2007年に「お取り寄せ便」というサービスを開始しています。（現在のサービス名は「セブンミール」）
しかし当時のクレジットカード決済はそこまで使われていたとは思いにくく*2、お金を取り扱っているという意識は少なかった（商品をお届けするためのサービスという位置づけだった）のではないでしょうか？
そういう状況であれば、乗っ取りが発生しても各ユーザーに甚大な被害は起きなかった可能性が高いです。（いや、個人情報とかがあれば、それはそれで問題だけど）
決済というお金を扱う部分も含めていることで、もっとその部分に関して重点的に考えるべきではなかったかと思います。*3
おわりに
今回は7payの会見を元に、ソフトウェアテストの7原則に当てはめて書いてみました。
とはいえ今回の記事は、こうやって事象が起きた後ならば、いくらでも書ける内容であることは確かです。
「はじめに」でも書きましたが、あくまでも今回の事象を教訓に自分の製品でもあてはめて考えてみたいです。
そして、実際に開発・テストをするのは現場とはいえ、経営層も含めてソフトウェアテストの7原則を意識すべきだと思います。
【リンク】ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J02
