システムトラブル38年史
私も有料購読している日経xTECHにかなりためになる記事が掲載されています。
IT黎明（れいめい）期の1980年代からまだ記憶に新しい2010年代まで、全1176件の「動かないコンピュータ」を振り返る。年代ごとの主な事例からその時代ごとの特徴を再点検してみた。
私がIT業界に入った1990年代半ばは「まだこの業界は若い。就労者の平均年齢も若いし、どんどん変わっていく成長期だ」と言われたものでした。2019年の今に立つと、ずいぶんこの業界もいろいろなことを経験し成熟したと思います。いろんな世代が参加していますし、「これは絶対にやっていはいけない」という原則のようなものも業界に浸透していると思います。昔はそんな原則がなかったので、今は考えられないような設計や構築を行い当然のように失敗したりデスマーチ化したものでした。別にデスマーチやブラック体質が大好きだったわけではなく、そうなるべくしてなったという感じでした。今はいろんな知恵が発達して失敗しないようになったのだと思います。
今、語り継ぐべきとき
1980年を起点とするともう40年が経ち、そうなると当時大卒（22～23歳）の人も引退の時期が見えてきます。もちろん70まではたらけ！の時代ですからロスタイムはまだまだ先なのですが、それでももう業界的には「血の入れ替え」の時期となってきたと思います。
そうなると、「戦争を知らない世代が増えてきた」ではないですが、過去伝説となったようなシステムトラブルを実際に経験した人がどんどん業界からいなくなっていきます。ところが、現在IT業界をスマート／ホワイトにしてくれているこれらの原則論は、確実に過去学んだことから作られています。これらは理由があってそうなっているのですがだんだんと原則だけが残っていき、なぜそうなっているんだっけ？という空洞化が起こるのも実は時間の問題だと思います。本当に痛い思いをした人たちが、今マネジメント層にいるからこそ「絶対ここはこういう設計にしなさい」と指導でき今のIT業界の成功があるはずです。その層がいなくなるときに考えなければいけないのは、過去の事実をもう一度見える化し、その対策がなんであるかを一対一で再度捉えなおすことだと思います。
まだ回復していない千葉の台風によるデータセンターへの影響であったり、先日の電源系統の異常を端に発するAWSの障害などは、より仮想化され抽象化されたITインフラに対する警告ではないかとも思います。1980年ごろにITが重要な社会インフラとなり物理層への対策が強化されている状況を踏まえ、現在の2019年にも再度、物理層へフォーカスしシステムトラブルを防ぐことを念頭に置くべきだと思います。クラウド全盛の時代にあっても・・です。
ここ最近において、より業務自身をデジタル化すべきという論調において、業務もデジタルもわかっているユーザー側の人材がいない、ということが問題になりがちです。当然の話で、ベンダー側に業務まで丸投げするわけにはいかないからです。一方で、ベンダーお仕着せの仕様を業務側が受け入れることは日本においてはご法度とされてきました。業務が絶対でベンダーがカスタマイズするのが当然だと。この文化が真っ向から否定されているのが現状の流れで、ノンカスタマイズでできるだけ入れて業務自体をデジタル化するというのが主流です。これについていけないユーザー側が「要件がまとめられない」となってしまいシステム開発が失敗していくのが現在のトレンドだと思います。
全体の流れは大きく変わっていき、その属性に合わせたトラブルは頻発するようになるのはわかるのですが、そちらに気を取られていくと、結局は「昔起こったけれども、もう風化してしまい誰も気にしなくなったこと」が再度牙をむき出すということは間違いないと思います。ですから、再度この記事のように全体を俯瞰的にまとめ、再度思い出していくことは大事だと思います。そして、過去であればあるほど今のうちに詳細化すべきではないか、と思うのです。
失敗学こそ重要
IT分野のメディア記事は基本的に成功事例ばかりです。このソフトウェア、このソリューション、このベンダー、この開発手法。成功した事例をプレゼンテーションにまとめ発表することでブランド価値を向上させるというモチベーションで彩られています。しかし、これらの成功は幾多の失敗の上に成り立っているということを忘れてはいけませんし、その失敗は先人たちが残した遺産です。だんだんとそれらを実際に体験した人たちがいなくなり、雰囲気で原則を守るようになりがちです。それは戦争体験と似たものがあります。私が子供の時に大人が語った戦争体験は、それはも悲惨でリアリティーがあってトラウマになるような迫力でしたが、今や原則だけが残っている感があります。
成功のためには、失敗学こそ大事、ということを主張しておきたいです。
