先日、The Vergeの記事を読んで、少し背筋が伸びる思いをしました。ゲームプラットフォームのGOGが、6月5日に配信したゲーム「The End of the Sun」のニュースレターに、ナチスSSを連想させる記号を含めてしまったという件です。
GOGはスラブ神話をベースにしたゲームの販促として、スラブルーンをメールに使いました。そのなかの「Sowilō（ソウィロ）」というルーン文字は、本来「太陽」を意味するものです。ところが一部のモバイル端末で、このルーンが「ϟ」という記号に化けて表示された。さらに2つ並べたことで、ナチスの親衛隊シンボルと見まがう表記になってしまいました。
GOGが原因として挙げたのは、ドイツのQAチームとのコミュニケーション不足、フォントの描画の不一致、そして銀行休日による人員不足という複数の要因でした。実はドイツ向けには事前に気づいて配信しなかったのに、他地域にはそのまま送ってしまったと。開発会社自身も「なぜGOGがあのシンボルをニュースレターに使ったのか、私たちも本当に驚いた」とコメントしています。
この話を読みながら、自分の部署のことを思い浮かべていました。私が担当する営業DX推進部には25名のメンバーがいます。昨年から社内向けの自動配信ツールを導入して、顧客向けの資料送付や案内メールを半自動化してきました。
「QAチームが確認した」という言葉、うちのプロセスでもよく出てきます。でも今回のGOGの件を見ると、「確認した」の中身が問題だとわかります。誰が、どの端末で、どの言語設定で確認したのか。特にフォント描画の話は、Windowsで見るのとスマートフォンで見るのとでは結果が違う、という話で、これは製造業の品質保証と同じ構造です。検査環境が本番環境と違えば、不良品は検査をすり抜けます。
昨年の4月に、うちでも似た経験をしました。新しい顧客向け案内メールをテンプレート化して展開した際、特定のメーラーで表組みが崩れて、金額の列が読み取れない状態で届いていたことが発覚したのです。気づいたのは取引先の担当者からの電話でした。確認は済んでいた、でも確認していた環境は社内の標準PCだけだった。反省として、確認項目のチェックリストと確認環境の条件を文書化しました。あのときの経験があったから、今回のGOGの記事は人ごととは思えなかったのです。
私の仕事のひとつに、ツールやシステムのベンダー選定があります。経営陣への稟議では、投資対効果を数字で示すことが当然求められます。ただ最近は、リスクコストの説明も避けて通れなくなってきました。
今回のGOGの件で言えば、
この3点が問われています。ベンダーを評価するときも、機能や価格だけでなく、「何かあったときにどう動くか」を確認する必要があります。実際、私が社内でセキュリティ要件の審査を通すとき、情報セキュリティ部門から必ず聞かれるのが「インシデント対応手順書はありますか」という質問です。それを用意できないベンダーは、稟議の土台にも乗りません。
GOGが「人員不足」を原因のひとつとして挙げたことも、気になりました。銀行休日で担当者が少なかったというのは、裏を返せば、特定の人に依存したプロセスだったということです。属人化のリスクとして、これも投資対効果の議論に織り込むべき視点だと改めて感じました。
メール一通の誤りが国際的なニュースになる時代に、「確認は取った」という言葉がどれだけの重みを持つか、自分の部署のプロセスを今一度点検してみようと思います。
GOGはスラブ神話をベースにしたゲームの販促として、スラブルーンをメールに使いました。そのなかの「Sowilō（ソウィロ）」というルーン文字は、本来「太陽」を意味するものです。ところが一部のモバイル端末で、このルーンが「ϟ」という記号に化けて表示された。さらに2つ並べたことで、ナチスの親衛隊シンボルと見まがう表記になってしまいました。
GOGが原因として挙げたのは、ドイツのQAチームとのコミュニケーション不足、フォントの描画の不一致、そして銀行休日による人員不足という複数の要因でした。実はドイツ向けには事前に気づいて配信しなかったのに、他地域にはそのまま送ってしまったと。開発会社自身も「なぜGOGがあのシンボルをニュースレターに使ったのか、私たちも本当に驚いた」とコメントしています。
「確認済み」が通じない理由を考えた
この話を読みながら、自分の部署のことを思い浮かべていました。私が担当する営業DX推進部には25名のメンバーがいます。昨年から社内向けの自動配信ツールを導入して、顧客向けの資料送付や案内メールを半自動化してきました。
「QAチームが確認した」という言葉、うちのプロセスでもよく出てきます。でも今回のGOGの件を見ると、「確認した」の中身が問題だとわかります。誰が、どの端末で、どの言語設定で確認したのか。特にフォント描画の話は、Windowsで見るのとスマートフォンで見るのとでは結果が違う、という話で、これは製造業の品質保証と同じ構造です。検査環境が本番環境と違えば、不良品は検査をすり抜けます。
昨年の4月に、うちでも似た経験をしました。新しい顧客向け案内メールをテンプレート化して展開した際、特定のメーラーで表組みが崩れて、金額の列が読み取れない状態で届いていたことが発覚したのです。気づいたのは取引先の担当者からの電話でした。確認は済んでいた、でも確認していた環境は社内の標準PCだけだった。反省として、確認項目のチェックリストと確認環境の条件を文書化しました。あのときの経験があったから、今回のGOGの記事は人ごととは思えなかったのです。
リスクの棚卸しをベンダー評価に使う
私の仕事のひとつに、ツールやシステムのベンダー選定があります。経営陣への稟議では、投資対効果を数字で示すことが当然求められます。ただ最近は、リスクコストの説明も避けて通れなくなってきました。
今回のGOGの件で言えば、
- 配信前の多環境確認プロセスが設計されていたか
- ローカライゼーション対応の体制が整っていたか
- インシデント発生時の対応フローが機能したか
この3点が問われています。ベンダーを評価するときも、機能や価格だけでなく、「何かあったときにどう動くか」を確認する必要があります。実際、私が社内でセキュリティ要件の審査を通すとき、情報セキュリティ部門から必ず聞かれるのが「インシデント対応手順書はありますか」という質問です。それを用意できないベンダーは、稟議の土台にも乗りません。
GOGが「人員不足」を原因のひとつとして挙げたことも、気になりました。銀行休日で担当者が少なかったというのは、裏を返せば、特定の人に依存したプロセスだったということです。属人化のリスクとして、これも投資対効果の議論に織り込むべき視点だと改めて感じました。
メール一通の誤りが国際的なニュースになる時代に、「確認は取った」という言葉がどれだけの重みを持つか、自分の部署のプロセスを今一度点検してみようと思います。