大型システムの障害

NTTのIP電話、ANAの予約・発券システムの障害などが相次いだ。 その原因について、朝日新聞の2007年6月1日朝刊の科学面に興味深い記事があった。 国立情報学研究所の本位田(ほんいでん)真一教授によるコメントである。

装置の更新やシステム増強の際に障害が発生するのは、「改造を加えたり、めったに使わない機能が働いたりしたときに、想定外のトラブルが起こる」からだという。

確かに、システム移行の際、よく利用される機能、動作しないととても困る機能についてのテストは入念に行うが、滅多に使わない(と判断した)機能についてはテストを省略することがある。 何しろたくさんの機能があり過ぎて、個々の担当者ではシステムの全容を把握できないのだ。

障害が起こって初めて、「そんなプログラムがあったのか」と気付く場合がある。 しかも、そのプログラムが実際の業務には使われていないことすらある。 プログラムを開発した担当者も、開発を依頼したユーザー部署の担当者も、ともに異動(あるいは退職)してしまっていたり、ユーザー部署そのものが消滅してしまっていたりすることがあるからだ。

キッチリ仕様書が書かれていて、引継ぎをキチンとすれば、そんな障害は起こらないだろう、と思っちゃう人は、開発現場を知らない人である。 本位田教授のコメントから引用しておこう。

システムが設計図通りに作られていないことも多い。最初はきちんとした設計図があっても、着手後の開発で新機能がどんどん追加されるため、引き継がれるべき設計図に変更が反映されないためだ。 10階建てのビルを造り始めてから15階建てに変えることは、建築の世界ではありえないが、システム作りではまかり通っている。

10階建ての予定だったのに、途中で15階建てにしたいと言い出すのは、ユーザー部署である。 システム開発者が、その要望に沿おうと努力した結果、潜在的に危険なシステムが出来上がってしまうのだ。 要望に沿おうと努力するのは、人間関係やら人事考課やら受注関係やらイロイロあるからだけどね。

そんな無茶な要望に従わなければいいじゃん、と言う人自身が、そういう要望を出す人だったりする。 「情報システム部門はすぐにできないと言う」とか「四の五の言って、なかなか対応してくれない」とか「こうすれば便利なのに、危険だとか言って嫌がる」とか思ってませんか?*1

さて、システム開発者の問題としては、「納期に間に合わせるために」とか「どうせこのシステムを使うのは1年限りだろう」とか「開発後の運用は他者(社)だし」とか考えて、「とりあえず動く」システムを作ってしまうことがある点を指摘しておこう。

いやホント、ユーザー部署の担当者の細かい要望に応えて木目細かな対応のできるシステムを作ったのに、半年後に担当者が異動になったら、後任にこんなふうに言われてしまうことすらあるのだ*2

「何この使いにくいシステム。こんな処理、Excelでできるから要らないよ」

なかなか、数年間運用し続けることを想定したシステム開発など、やっていられない。

それにまぁ、あれだけ大騒ぎになった「西暦2000年問題」だって、1980年代の開発者が、「よもやこのシステムをこのまま10年も20年も使うまい」と思った*3から起こったわけだ。

人間も、その人間が作ったシステムも、「想定外」のことには対応できないのである。


*1 ……ってコレ、ワシの個人的不満ではないからね。
*2 ありがちな話として挙げただけで、フィクションである。
*3 西暦の下2桁だけを扱うようにすれば、メモリやディスクの容量を節約できるからそう思ったわけだ。当時はコンピュータは高価だったのである。2000年以降も使うことを考えていないシステムの場合、「年」の値が「00」なら「1900年」だと判断して間違った計算結果を返してしまう。ましてや、「年」として「80」〜「99」しか入らないことを想定したシステムの場合、「00」が入ると(「該当なし」とか「無効」とか「異常」という意味で「00」を使うようにプログラムしてあったりすると)誤動作するかも知れない。……というのが「西暦2000年問題」だった。まぁ、みんなの努力の甲斐あって、大事故やライフラインの途絶が起こらずに済んで良かったけどね。

FrontPage   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2007-06-03 (日) 11:36:35 (3850d)