なんで突っかかるんだろう。俺。

同業者の端くれとして、あんまりよその障害ネタなんて拾いたくないんだが、これには反応したい。
三菱東京UFJ銀の一部障害、直接の原因は文字コードの設定誤り
自分は起きてしまったことは仕方ないと考えている。起きちゃいけないとは思うけれど、作業されてる方々には健康に注意してこの修羅場をなんとかして乗り越えてほしいと思う。
さて、記事で気になるのはこういう部分

　不具合の直接の原因は分かったが、根本的な原因について2つの疑問が残る。1つは、文字コードを変更する計画がどうしてセブン銀に伝わっていなかったのか。もう1つは、なぜ事前のテストで文字コードの不一致を発見できなかったのかだ。

どうして伝わっていなかったか。
伝わったことを「確認した」人が居なかったからなんだろうなぁ、と、思った。
言わなくてもわかるよね、ってこっちが思ってる内容は言われるまで（相手が）気づかないなんて、そこかしこで起きてるじゃない。
（起きちゃいけないんだけどね。でも、自分の感じた点はこの記者とは違う。）
こういう相手に当たり前だと思っていることをイチイチくどくどと、言って、こんなの書かなくてもいいじゃん、と思えるような内容だって文書に残して
決めておくのが大変なんだよ。当然、相手は嫌がる。なんで「そんな当たり前の話をするのに時間をかけるのですか」って言ってくる。
相手に恨まれ、いやがれても時間を拘束して、会話して当たり前だという部分を共通認識にしてゆく。文書に残す。それが結合部分のアルファにしてオメガだ。
ソースを書くとか、書いた通りにソースが動いたかとか、そういう難しさとはまた別の世界だ。
逆に、ソースに乗ってしまった部分っていうのは、試験は比較的簡単なんだよな。
プログラマーなり、SEなりが、「自分の思う正しい」動きになるようにする作業だから。
でも、本質は「プログラマーの思う正しい」じゃない「相手の思う正しい」で動作するかどうかだ。
そのとき「相手は何を以て正しいと見なすのか」という判断基準を事前にネゴってないとわからない（これがさっき言った共通認識の文書だ）

　切り替え作業に先駆け、三菱東京UFJ銀は100万件以上のテストを消化している。社外との接続テストも、100以上に及ぶすべての相手先との間で実施した。仮にコード変更の伝達漏れがあったとしても、条件に合うパターンをテストしていれば、そこで不具合が見つかったはずだ。

これについてはもっと違和感を感じる（これを書いた記者にね、現場で試験やってる人にじゃない）
１００万件以上やったから大丈夫なの？違うだろ。
そんな数字の大小なんて試験の網羅性と全く関係ないよ。数字を出しちゃダメだよ。
１００万件やったとしても「まだつぶし切れていないバグがどこかにある」という意識を持って望まないとな。でも、この場合はそれとも違うと感じている。


それが「条件に合うパターンをテストしていれば、そこで不具合が見つかったはずだ」に感じる違和感だ。
それは結果論だ。今だから「どうやるのが正しいのか」が言える。
こういう仕事は事前想定が全てなのだから起きてから言ったんじゃ遅い。
事前に「相手はカタカナでもひらがなでも、漢字仮名まじり文でも大丈夫」というバイアスがかかった状態で、正しい試験ができるのだろうか。
最終的に正しいテストは「カタカナ以外は送ってはいけない」らしいのだが、
試験工程での認識は「カタカナ以外でも、ひらがなでも漢字でも送信されなければならない」とか判断しそうだ。
（優秀なプログラマーほど、カタカナ以外のパターンでも大丈夫なパターンを作ってしまうような気がする）
それは、１００万件やったから大丈夫、という話とは違うだろう。
関係者じゃないので真相はわからないし、想像で勝手に語っているのだから言いたい放題なんだが、これは試験で拾えるようなエラーだったのだろうか？
試験項目書には「送信電文にはカタカナのみの文字コードが入り、それ以外は含まれていないこと」と書いてあったのだろうか？
（こうなるのが正しいと認識できた人なんてプロジェクト内に居なかったんじゃないの？）
「何を以て試験結果を正しいと見なすか」、の根拠っていうのは思ったよりも上流に深い根があることが多い。
で、この記事ではそれを歪曲して伝えようとしているような気がしてならない。
問題が起きたのが内部処理だと、テストしたのになんで？と言うのもアリだと思うが、システム間の結合部分でお互いの勘違いが原因の今回の場合、テスト工程にバグの責任を負わせるのはいかがなものか。
と、思った次第。