悲しきブラックボックス

IT稼業から足を洗って10数年が経ちました。

それでもトラブルシューターの悲しい性(さが)ともうしますか、
システムダウン系のニュースが流れると、
つい目が行ってしまうんですよ。

そう、またやっちまいましたね、みずほさん。

１年で６回目ともなると、
さすがの執行部も重苦しい空気に包まれているでしょう。

そしてみずほさんや関係IT企業だけではなく、
長い社歴を持つ他企業の情シスも、
多かれ少なかれ同じ不安を抱えていると思います。

なぜなら明日はわが身の話だから。

みんなこの原因が分かっているんですよ。
そしてその大筋は自社にも十分当てはまると。

その不安の元とは『ブラックボックス』。

長い社歴と前置きしたのは、そこに大きな意味があるからです。
とりわけＩＴではなく、
ＯＡという略語を知っている情シスメンバーがいるような古い組織では、
ブラックボックスの脅威は相当なものになっているはず。

すなわち、
自社で稼働しているシステムの不明部分がそれだけ大きく深い、
ってことなのですから。

で、なぜ大人の組織でこんなことが起こっているのか？
答えはシンプル。

まず、紙とペンの文化からＯＡ化の御旗のもと、
黒船よろしく電算機が会社にやってきました。
そのときはまだ分り易い。
箪笥のように巨大な電算機は聖櫃よろしく電算機室に鎮座し、
そこに入れるのは技術者という限られた神官のみでしたから。

ところがまもなくイントラネット上にクラサバシステムが構築され、
社員ひとりにパソコン１台の時代が到来します。
この辺から今日のブラックボックスに至る悪夢が始まったのですよ。

たとえば最初にシステムＡがあったとしましょう。
そこに別のシステムＢが連結されます。
そして次はシステムＣが、さらにシステムＤが繋げられ、
こうして20年もすると社内システムは、
Ａ+Ｂ+Ｃ+Ｄ+Ｅ+Ｆ+Ｇ+・・・
様々なシステムが合体したキメラのようになってしまうのです。
こうなるともはや全体が分かる人は誰もいません。

同じベンダーがすべてのシステムを担当していたなら、
社内の窓口も情シス一本に絞られていたなら、
ここまでひどくならなかったでしょう。

ところが実際はシステムＡはＡ社が、システムＢはＢ社が作っており、
基本的に両社は相手のシステムがよくわかりません。
もちろんひとつのプロジェクトを、
複数のベンダーが分担するのは普通の話ですが、
別の時期に行われた別のプロジェクトのシステムは、
同業者といえどもまさしくブラックボックスなんですよ。

さらに社内でも各部門が勝手にベンダーと話をはじめ、
作ったシステムを既存のシステムとこっそり繋げてしまう。
IPアドレスだって勝手に割り振っちゃう。
力の弱い情シスは指をくわえてただ見ているだけ・・・

こうして悪夢は膨らみ続ける。

みずほ銀行は2002年に第一勧業銀行、富士銀行、
日本興業銀行の分割、合併によって生まれました。
ということは、そこで各行のシステムの統合が行われたとみていい。
これだけでも特大のブラックボックスが生まれる条件を、
十分満たしているでしょう？

ITシステムの黎明期ならともかく、
今のシステムはゼロから開発されるケースなんてまずありません。
先行するシステムを改修するか連結して巨大化するのです。
金融業界で今も古参のCOBOL使いが仕事をしている理由は、
この辺にあるんですよ。

そんなこんなで現場の現実を知る同業者にしてみれば、
みずほさんの事故は起こべくして起こったことであり、
反対に、起こってないところは「よく無事だな・・・」
なんですね。

ではどうしたら、この惨事を未然に防ぐことができるのか？

答えはプログラムならコメント、システムには仕様書など、
第３者が見てわかるレベルのドキュメントを残すこと。

これしかありません。

そんなのジョーシキ、みんなが知っている。
なのになぜできないのか？

理由はふたつ。
お客さんがドキュメント制作費用を渋るから。
(実際けっこうするんですよ)
そしてベンダー側にドキュメントを作る時間がないから。
たいてい少人数で納期ぎりぎりの仕事をやっているので、
ドキュメントはおろかマニュアルすら作るのが厳しい。

こうした悪しき、
いや、悲しき伝統がまだ続いているんだろうなぁ・・・

だから僕は、ＩＴからくりをあまり信用しないんですよ。

えーじ