ソフトウェアトラブル・システム障害について考える

なんか、硬いネタばっかりですね。
別に本質的にそういう人間という訳じゃないんですけど、勉強中なものですから．．．

今年もソフトウェアトラブル・システム障害に関する話題が豊富だった様です。
ITProで特集してました。
http://itpro.nikkeibp.co.jp/99/trouble/index.html
- 2008年11月4日　JCBのカード関連サービス障害
- 2008年9月14日　全日本空輸（ANA）の空港システム障害
- 2008年7月22日　東証の新派生売買システム障害
- 2008年5月19日　住友信託銀行のシステム障害
- 2008年5月12日　三菱UFJ銀行のシステム統合に伴うトラブル
- 2008年2月25日　信金中央金庫のシステム障害

ここに挙がってくるようなシステムは、それでもお金かけてテストしていると思いますよね。　でも、どんなにお金をかけてもソフトウェアトラブル・システム障害を防ぐことが出来ないことは、マイクロソフトが年間70億ドルの開発予算を掛けてもバグがなくならないWindowsが物語っていると思います。　僕のNote PCは大体週に2回くらいブルースクリーンを見るかな？　何時間もかけて書いた書類が吹っ飛んだりすれば、それは頭にも来るでしょうけれど、幸いにしてそういう経験はあまり無いので、コーヒーブレイクをとれという神のお告げだと思うことにしています。

東京証券取引所のJCOM問題は恐らくソフトウェアトラブルを考える際の最も優れた教材なのかも知れません。　こちらのJCOM問題が実際にどのようにして起こったのかを纏めた情報システム学会の資料です。
http://issj.nuis.jp/renkan.pdf
（去年の技術士二次試験の問題は、ここからの引用だったんですね。）
証券関係のシステムをやっている人がどう捕らえるかは分かりませんが、よくここまで不幸が重なったものだな．．．というのと、このケースを想定したテストが書けなかったということにどれだけの過失があるのだろうか？この問題を100%防ぐアプローチが存在するのか？と、言うのが率直な感想です。　Windowsなんか、利用シナリオを考えていたらキリがないから、マイクロソフトの場合、Microsoft Solution Frameworkに書かれている手法（つまりバグはあるという前提で、統計的に管理する手法、あるいはプロジェクト管理面に関する議論）とかで品質の向上を狙っているのでしょうかね？　それが正しければ、バグがあるという前提のOS上で動いている情報システムにバグフリーを要求すること自体がナンセンスな気もしてしまうわけですが．．．　だからWindowsを使わないんだ！！と、突っ込まれそうですが、本質的にはソフトウェアが複雑になりすぎて統計的手法に頼らざるを得なくなっている、あるいはTQCのようなプロジェクト管理的に品質向上を狙うアプローチにしかなり得ないということだと思います。　簡単な言い方をすると前者はベータテストみたいな形でシナリオフリーでユーザーに使ってもらうか、パイロットプロジェクトを行って、そこで品質を作り上げていくということでしょうし、後者に関しては、こういったソフトウェアトラブルの原因を追究し、どうすれば防げたのか？という問いに対して、本質的に「関係者間のコミュニケーションの改善」という答えに行き着いてしまうということです。　そう考えると、「Programming First Development」や「Test Driven Development」ってソフトウェアの品質向上にどれだけ寄与するのか．．．

僕は以前、プラントエンジニアリング会社に勤めていたのですが、そこであるシステム構築の計画の際に、部長に「検証はどのようにやるのか」と、聞かれ、答えに窮してしまった経験があります。　システムエンジニアとして何年か経験した今でも、検証プロセスに対してその時からそう成長した感じはしませんが、自分自身がシステムエンジニアとして品質に対するマインドが特段低いとは考えていません。　ハッキリ言ってしまえば、情報システム開発はプラントエンジニアリングほど成熟しておらず、品質管理もプラントエンジニアリングに見習うべきところが多いということです。（もちろん、情報システム開発が進んでいる部分も多々ありますが．．．）　そういった他業種のベストプラクティスの流用に関しては、自動車業界を引き合いにだすことが多いと思いますが、受注産業である点やプロジェクト管理の手法（PMPなんか、元は建設業界の方が盛んでした）など様々な面から情報システム開発はプラントエンジニアリングに似ています。

例えとして、システム開発におけるプログラマとプラント建設における溶接工を比較してみます。　溶接はプラント建設において品質を作りこむための一つの大きな要素ですが、基本的には全ての溶接箇所にたいして、溶接手順やその溶接手順で十分な品質が出たことの証明（WPS/PQRと呼ばれる）が存在します。　この証明（=PQR）はプラントエンジニアリング会社の溶接技術者が確認するのではなく、第三者機関が確認します。　そして、それぞれの溶接手順（WPS）はどの溶接工でも施工して良いわけではなく、それぞれのWPSに対して認定された溶接工のみが施工を許されています。　が、一方システム開発ではどんなことをやっているというのでしょう？　何の認定もないプログラマに実装（=施工）のかなりの部分の裁量が与えられてしまっているのではないでしょうか？

この問題を考え始めたきっかけは、技術士口頭試験で以前題材となったということからなのですが、考えていくと、ちょっと極端に深く広くなっていき、キリが無いので、この辺で止めることにします。　午後はもっと楽しいことを考えることにしよう．．．