うるう年のソフトウェア障害
今年は閏年だった訳ですが、私の知る限り、各所で閏年関連のソフトウェア障害が報告されています。ざっと、こんなところでしょうか*1。
- NTT 東西、4th MEDIA 用の STB Picture Mate 300 で障害
- NTT 東西、公衆電話の保守サービス系で障害
- 豊川市など、住民記録システム、印鑑登録システムで障害
- サッカーくじ toto、販売システムがうるう年を考慮せず障害
- シグマ、一眼レフのファームウェア障害
重大な不具合に至らなかったり、報道されないような事象がたくさんあるでしょうから、氷山の一角と思われます。
多くの巨大システム工学（建築学、機械工学）では、大きなシステムは複数のモジュールで構成され、モジュールは小さな部品で構成され、という成熟した方法論がありますが、ソフトウェアの世界では未だに末端の担当者が基本的な部品であるカレンダー（暦法計算）まで自前で実装しているかのようです。ソフトウェアの詳細設計を未だに「製造」とか「作りこみ」とか呼んでいる管理者もあり、大学や専門学校を出たばかりの新人が簡単な研修を経ただけで、前線の設計者として現場に送り込まれています。携帯電話端末のソフトウェアは 1000人規模のソフトウェア設計者で構成されているという話を聞き、半分はこの数字を自慢しているような響きすら感じられることもあります。
多くのソフトウェア技術者が、いずれも少量しか出荷されないような類似したソフトウェア部品を一から繰り返し設計させられ、スキルを身につける時間が得られていないのではないでしょうか。ソフトウェアの生産量をコード行数で測る文化から抜け出せず、プログラムコードばかりが増えるために、設計レビューがほとんど不可能になっているのではないでしょうか。末端の技術を理解できずに右から左へと設計成果物を承認する管理者や、管理業務と設計業務の双方に関わり、始終過労となる管理者が溢れているのではないでしょうか。
日経○○などを見ると、モデル設計から半自動的にソフトウェアコードが生成されるような話が出てきます。確かに、日本のソフトウェア設計現場に、方法論や系統立った設計手法が確立されていない現状は問題だとは思いますが、同時に、モデリングさえできれば、あとは単純行程でソフトウェアが生成できるという話を真面目に信じる人が出てくるのではないかと不安になることもあります。建築の分野で、顧客の要望を入力すれば建築図面が自動的に出てくることがあり得ないように、モデリング言語で記述されたシステムから「現実」のプログラムコードが自動生成される技術は世の中にできていません*2。ソフトウェアの詳細設計は知的作業であり、スキルのない技術者がパソコンのマウスをポンポンとクリックして出てくるものではありません。世の中で、モデリングがうまく適用できていると言われる事例も、陰ではスキルのある上級ソフトウェア技術者が、知恵を絞って現実のプロジェクトに適用しているのだと思います。プロジェクト X ではありませんが、泥臭い話というのは、あまり表には出てこないものです。
何を当たり前のことを書いているんだあ、と言われそうですが、私は新聞各紙で今年の閏年問題を見るにつけ、ソフトウェアの世界は、少なくとも 2000年問題の頃*3からほとんど変わっていないんだなあ、と痛感せざるを得ませんでした。
