けっこうな大騒ぎになった7Payがサービス終了するらしい。
https://www.7andi.com/library/dbps_data/_template_/_res/news/2019/20190801_01.pdf
正直に言うと、バーコードやQRの決済サービスは乱立していてよく分からない。キャッシュレスを施策として推し進めたいなら、交通系ICかクレカでええやんと思っている。でも観光客とかの利便性を考えると必要なのだろうか？(インバウンドの「大口顧客」たる中国では盛んらしい)
今回語りたいのはキャッシュレス決済の話ではなく、7payにかかわるシステム開発の話だ。もちろん数多のエンジニアの方々が気の利いた記事を書いているだろうから、技術的な解説論説はそちらに任せるとして、個人的な感想・憶測を書いてみたい。
どうしてこうなった、という点
今回の7payについては、記事を拾い読みする限り2つのまずいことがあったと思っている。
- パスワードリセットの不備(アカウント乗っ取りに悪用される危険)
- セキュリティに気を使うべき領域なのに、2段階認証がなかった
どちらも設計の初期段階で拾えるはずのミスであったように見える。というか今動いている類似の決済システムの作りを真似すればだいたい埋められた類の穴であるような気もする*1。「なんで気づけなかったんだろうか？」というのが率直な疑問として浮かんでくる。
進捗は進捗しない
ところが、以下の記事を読むと感想が変わってしまう。こりゃあダメだ。しょうがない、と諦観さえする。
以下は引用。
7payの仕様がなかなか固まらず、リリースの比較的直前まで開発現場が混乱していた、という指摘だ。
本来は3月中に、7payの動作確認を行う｢システムテスト｣が実施される予定だったが、実際にテストが開始されたのは、4月末のゴールデンウィーク直前だった。 テスト期間として当初は1カ月半〜2カ月ほどの余裕があったはずが、ゴールデンウィーク直前から開始したため、テスト期間は実質1カ月を切る状態だった可能性がある。
どうやら仕様が固まらず、おそらく設計・開発段階で「そういえばさ、ここどうすんの？」「ここの部分ちゃんと決まってないと作れないんだけど？」といった障壁が発生し、手戻りが発生したものと類推される。
これがシステム開発の嫌らしいところで、「どんなものを作るか」がふわっとしたまま工程を進めてしまうと、こういった疑問が噴出して作業を進められなくなってしまい、例えばプログラムのソースをゴリゴリ書く段階から設計の中身を書き出す段階まで戻る羽目になってしまう(残念ながら、こういった事態は往々にしてある)。もしあなたがとある企業のシステム担当者で、開発ベンダーに向かって「とりあえずそれっぽいもの作ってよ」と曖昧な要求をしようものなら、あなたはSEたちが正気を失うか、あるいはバールのようなものを握って襲いかかってくることを覚悟せねばならない*2。
更にタチの悪いことに、ここの疑問点に対ししっかりと仕様を定め、仕様に対する認識をベンダーと顧客(システム発注側/ここではセブン&アイの中の人か)間で一致させないと、いわゆる「思ってたんと違ぁう！」ブツができあがってしまう。最悪の場合、顧客側の偉い人が「そもそもこんなものを作る契約をした覚えはないんだけど！？」と激おこで、ベンダーが自腹を切って作り直しをしたりなんてこともある。この場合、SEたちはしめやかに爆発四散する。ナムアミダブツ！
いずれにしても、こういった手戻りの発生は開発スケジュールを圧迫する。しかも、スケジュールの遅延は得てして納期の延長という結論を導くことはない。「お客さんにはいついつにリリースするって言っちゃったから。納期はずらせませんので、まぁがんばってください」という、ベンダー営業か、険しい顔をしたプロジェクトマネージャーの言葉があるだけだ。そこから先にあるのは、労働の強化、ヘルプ人員と生じた有象無象のSEたちの投入*3、それに伴うコミュニケーションコストの増大、大量のエナジードリンクの空き缶、削れていく精神である。この場合も、SEたちはしめやかに爆発四散する。ナムアミダブツ！
まして下記のような記事に書かれる事情からすると、おそらくスケジュール遅延からくる納期の遅延という可能性が出た時点で、顧客担当からはヤクザスラング混じりの罵詈雑言が飛んできたのではと想像してしまう。SEの端くれとして言わせてもらうならば、経営側の都合など知ったことではないんだが。
よりよいものを作るだって？面白いこと言うぜHAHAHAHAHA
開発スケジュールの圧迫と労働の強化で、SEたちにはどんな変化が起こるか。これは半分実体験も交えているが、まず「より良いものを作ろう」「ユーザビリティを意識しよう」といった、就職面接で高い評価を得られるであろう崇高な考えは一切合切抜け落ちる。とにかく、山のように積まれたタスクを感情的にも理性的にもならずにただ消化していくことが求められる。というか、そういうマインドに追い詰められる。
そんな状況の中で「パスワード変更のロジックで抜け道あるんじゃないですか？」「そもそも二段階認証にしなくてもいいんですか？」といった疑問が生じたとしても、どうだろうか。
「あー、それは障害だね。じゃあ君が直してください。」
そう、ミスを報告すると自分の仕事が増えてしまう。自分でテストをして、バグがあったら障害票を書いて、その障害を自分で直してまたテストする、という経験がある自分からすると、「気づいても黙っておくか」という心情になってしまうのは理解できる。もちろん平時からすると「そういった判断はすべきでない」という常識的な発想もできるし、もちろん頭では理解しているのだが、殊に炎上してしまったプロジェクトにおいては正常な判断力は期待できるところではない。憔悴している(あるいはうつ状態にあるかもしれない)人間なら、「早くこの苦しみから逃れたい」という発想になってしまうのではないだろうか。
爆発四散しないために、しよう
セブンペイの失敗に対しては、以下3つの原因があったのでは、と個人的に邪推している。
- 初期段階の設計で仕様、セキュリティ要件を明確に定めず、手戻りが出た
- 手戻りがスケジュールを圧迫し、労働が強化された(炎上 your life time)
- 激務にあたった戦士たちが、正常な判断力を保てなくなった
上記の問題は、別にキャッシュレス決済サービスのシステムにとどまらない。IT開発全般に渦巻いている問題でもあるし、多くのSEが胃を痛めたり、心療内科に通ったりする事態とも深く関わっていると思う。
ここでいうミソは「初期段階の設計」にあると考えている。ここに関係してくる人員はユーザー側のシステム担当、プロジェクトマネージャーなどのマネジメントの要素が強い一部に限られている。昨今言われている「働き方改革」にあたっては、このマネジメント(ここでは、何を目指すか、どういうふうに目指すかに関する取り決めのこと、なのかな？)をきちんとすることで、その末端の一般SE兄貴たちも救われることになるんじゃないかなぁ。
セブン&アイという大企業がキャッシュレス決済の覇権レースから脱落したことで、日本にこの手の決済が流行るか？という問いに対しては大きな疑問符がつくことになった。今後もこの手の案件からはなるべく全速力で逃げつつ、SEの兄貴達が健康的に働き、十分な量の休日をもらい、安全に憩った暮らしができることを望んでいる。
この記事は仕事のある日に書くと気分が滅入るので、盆休み中に書きました。
