「金融界のサグラダ・ファミリア」、みずほのシステムに続発したトラブルでは、「4件のシステム障害に関連性は見いだせていない」と述べられています。
システム開発業界にいる方ならなんとなく感じているのではないかと思いますが、システムトラブルは「出るときに出る」もの。しばらく出ずに「無事故無災害」が続く期間もあれば、ひとたび出だすと芋づる式に発生するものだと、経験から言えそうに思いませんか。システム障害あるある(そういえば昔は「マーフィーの法則」と言われていましたね)、もしかすると他の業界でも似たようなことはあるのかもしれません。
このあるあると、「相互に関連性はない」とが、どうもうまく腹落ち*1しないのはなぜなのでしょう。について考えてみました。
時限爆弾
続発したシステム障害は、それぞれ別のサブシステムで発生して、設計者や開発者も異れば、場合によってはプログラム言語も異なっていて、どうにも因果関係はなさそう。外部環境の変化もなく、まるで雨後の筍、時限爆弾のように次々と表に出てくる… そうして悪夢のような時間が過ぎていくと、こんどは「出尽くした感」というこれまた不思議な感覚に襲われ、雨宿りしていた動物たちが草陰から顔を出すようにそろそろとSEたちが動き始める・・そんな感覚はありませんか。
お互い共通点がなさそうなのに、「気をつけるべし」との訓示を受けて、「気を引き締めて」バラバラと散っていく。そうして次へのカウントダウンが静かに始まる・・・こういうイメージです。よね。
つまりはそういうことではないかと思うのです。
関連性はよくわからないものの、一つひとつの障害には確たる(と思われる)原因があり、対処方法が定められる。「再発防止策」として、マネジメントの強化、チェックリストの追加、作業の自動化、などが採られ、「一層気を引き締める」というエイエイオーが叫ばれ、かつその時点から徐々に効果が薄れていく。時限爆弾的に。
習慣が惰性となり、ルールの目的が曖昧になって亜流が生まれ、締めた気は緩み、対策の「賞味期限」がどんどん近づいてくる。そうして同じ歴史を繰り返すことになる。実態としてはこんなところではないでしょうか。
根拠はなし
根拠も理論も理屈もありません。
ただ、そう思えてならないような繰り返しを見ていると、やはり法則性はあるのでは、と感じてきませんか。賞味期限が切れる前に、人も組織も役員も変わります。社長も変わっていきます。なので、社長が頭を下げても、別の社長が頭をあげる頃には同じことが発生しているような予感がするのです。
どうにかならないのか
別の記事で「『ルールの見直し』をルール化する」点をポイントとして書きましたが、賞味期限をより伸ばすには、そうした「見直しをルール化する」のが一つの解決策かもしれません。プロジェクト終了や障害発生から一定期間、だと拘束力が弱いので、期初・月初など確実に定期的に訪れるタイミングで、賞味期限を延長するためのイベントを設けることがヒントになるかもしれないと考えた夜でした。