筆者は約30年にわたってメインフレームのシステムをオープン系ハードウエアに移行する作業に携わってきた。過去にはメーカー系のSIerなど複数のITベンダーを渡り歩いた。この間、どうしようもない「塩漬けシステム」を数多く見聞きしてきた。なぜそのようなシステムが出来てしまうのか。実例を基に分析する。

 今、現役で稼働しているメインフレームシステムは、歴史的な2つの転換点をくぐり抜けてきたシステムだ。1つは「2000年問題」である。2000年問題に対応するため、多くの企業で既存の業務システムに改修が必要になった。これを機にメインフレームをオープン化するブームが起きた。もう1つは「2007年問題」だ。このときも、メインフレームをよく知る団塊世代の技術者が引退する前にオープン化を進めようという動きがあった。

 これらの節目をくぐり抜けて、現在も使用されているメインフレームには、移行できなかった理由がある。根底にあるのはシステムの「属人化」だ。その上に「独自業務」「独自技術」「抵抗勢力」という3つの直接的な理由が存在する。

塩漬けシステムが生まれる要因
塩漬けシステムが生まれる要因
[画像のクリックで拡大表示]

属人化で移行できず

 そもそもシステムが「属人化」する経緯はこうだ。メインフレームでは、オンライン、バッチ、アプリケーション、インフラなど領域ごとに担当者が分かれていることが一般的だった。作業領域ごとに細分化された状態で、数十年間にわたってシステムを運用してきた。その間、多くの企業で保守費用の削減や体制の縮小、初期メンバーの退職などが相次いだ。結果として、「××については○○さんしか分かりません」といった、属人化した状態になった。このことがメインフレームの移行を妨げている。

 一例を挙げよう。属人化が理由でメインフレームの撤廃プロジェクトが頓挫した、ある自治体の事例だ。

 プロジェクトの計画と予算化をまとめたのは前任の部長だった。その部長はメインフレーム撤廃までの筋道をつけた段階で定年になり、後任の部長が移行作業を受け持った。

 旧システムの運用は属人化しており、後任の部長にメインフレームの作業経験はなかった。このため業務的にも技術的にも旧システムの処理が理解できていなかった。いざ、移行プロジェクトを開始したものの、勝手がわからない。その結果、前任者の見積もっていた以上の作業が発生してしまった。当然ながらプロジェクトは長期化。前任者が確保していた予算とスケジュールを大幅に超えてしまい、プロジェクトは中止に追い込まれた。