東証の派生売買システム障害の原因判明

　この事件でいろいろ考えさせられたのですが、課題はすぐに思いつくだけでもこれだけ。

1. 設計の問題
   　今回はメモリの確保量が足りなかったというのが直接原因ですが、確保したメモリを１銘柄当りの上限を超えたときに他の銘柄分で未使用のものを利用するのと言うのは資源の有効活用という意味では有りですが、それが禁止事項なのか設計上有り得ない事象であればせめてアラートを出すくらいの処置をすべきですね。もしかしたらコーディング担当レベルでは実装済みだったかもしれませんがテスト担当者が見れないログレベルのアラートの場合も多いですけどね。
2. テストの問題
   　テストで発見できなかったとありますが記事の内容を見る限りテストを行ってません。テストと名づけた手順を指定した時間で実施した事実があるだけでテストになっていない。テスト計画が杜撰だったという事ですがそうさせたのは誰かこの部分は十分に責任を問うべきです。業務や取引のシステムだから障害が起きても直接死亡事故に発展しないだけですがそれにしても危機感無さすぎです。負荷テストは想定される規模以上の状態に耐えうるかとテストするもので普段の利用頻度以下でしかテストしてないのは論外。このシステムの規模なら同時問い合わせは最大約18万件ぐらい想定した方が良い(5台のシステムが停止して残り1台で全銘柄の同時処理を行うのを想定)。勿論その場合はまともな処理ができない筈なのでフェイルセーフの能力試験になってしまいますが。
3. 現場管理の問題
   　テスト計画が杜撰だったのがテスト設計内容に問題があったのなら優秀なテスト設計者を呼ぶ必要があるし、要求仕様がいい加減(100件処理できれば良いよって口頭で言ってるレベル)でテスト設計に影響していればレビューをもっと徹底(形式や建前の徹底は意味が無い)すべきだし、スケジュールや予算の問題でテスト自身削られたのならマネジャーをクビにした方がいい。それこそ誰も死ななかったから刑務所行きじゃなくて良かったなってフォローされる程度。

ソフトウェアの業界は理論上は経験の積み重ねと技術の共有によって同じ労働でも多くの仕事が出来るようになっていくのですが、現実は歴史から学んでない、新興産業のクセに他業界から何も学習しようとしない、独占と縦割りとつまらない社内競争でノウハウの共有が出来ない、お偉いさんは競争相手ばかり意識して現場の実態を知らない、管理職はYesManの無能揃いで現場を敗戦前の軍需工場レベルの低品質劣悪環境にしてしまう。ここまで酷くはないだろうと思われる方もいると思いますが一定の割合でそういう会社は存在するし、ゲーム業界やブラックIT企業をモデルにネタ本が定期的に出てきますね。