ソフトウェア技術者のためのバグ百科事典（20）みずほ銀行は人ごとではない!? システム刷新のバグ：山浦恒央の“くみこみ”な話（141）（1/4 ページ）

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第20回は、「IT業界のサグラダファミリア」と呼ばれたみずほ銀行の事例に代表されるシステム刷新のバグを紹介します。

[山浦恒央 東海大学 大学院 組込み技術研究科 非常勤講師（工学博士），MONOist]

※本記事はアフィリエイトプログラムによる収益を得ています

1．はじめに

　バグ百科事典では、筆者が気になったバグを紹介し、読者の皆さまに「バグの早期発見」と「バグの未然防止」に役立てていただくものです。

　本シリーズも第20回目となりました。今回は、筆者が経験した小規模なシステム移行で発生したバグを紹介します。

⇒連載「山浦恒央の“くみこみ”な話」バックナンバー

2．レガシーシステムとのお付き合い

※写真はイメージです

　近年におけるソフトウェア業界の課題の一つが、レガシーシステムへの対応です。レガシーシステムとは、長期運用により、保守性が低下したソフトウェアのことを言います。企業の担当者は、これまでの運用実績、費用の観点から、このまま保守するか、刷新するか悩んでいるようです。

　システム刷新業務で最も注目を集めた企業が、みずほ銀行です。みずほ銀行では、過去のトラブルの経験を踏まえ、システム刷新に膨大な工数を投入しました^※1）。刷新業務は想像以上に難航し、世間からは「IT業界のサグラダファミリア」との批判も受けたようです。それでも、2019年に新システムの稼働に成功しました。

※1）参考文献［1］によると、開発規模は35万人月だったそうです。コスト見積もりでは、1人月を米国では1万米ドル、日本では100万円と計算することが多いようです。これを適用すると、少なくともみずほ銀行は3500億円もの巨額を投資したことになります。

　ちなみに、これまでで人類最大とされるソフトウェア開発は、IBMが1963年から1966年にかけて開発したOS/360の構築といわれています。OS/360は、仮想記憶を採用したメインフレーム用の本格的なOSです。この開発は人類が初めて経験する超巨大ソフトウェア開発プロジェクトで、全5000人年、ピーク時には1000人以上が従事しました。当時はソフトウェア工学という言葉さえなかった時代で、このプロジェクトはもちろん大混乱します。OS/360は、ビジネス的には大成功し、IBMの繁栄の礎を築きましたが、プロジェクト的には大失敗となりました。

　この時の大混乱、大失敗を書いたのがフレデリック・ブルックスの筆になる永遠の名著「人月の神話」です。OS/360のプロジェクトマネジャーだったブルックスが書いた内容は、50年以上たった今でも、ソフトウェア開発プロジェクトで普通に発生しています。OS/360が5000人年ということは6万人月で、みずほ銀行のシステム刷新に投入した人月は、その6倍。しかも、OS/360は新規開発ですが、みずほ銀行は他人のプログラムに手を入れる保守で、難度は新規開発より格段に高くなります。

　OS/360が4年で6万人月、みずほ銀行は19年で35万人月であることを考えると、みずほ銀行のシステム刷新が「IT業界のサグラダファミリア」と言われたのはもっともながら、新システムが稼働にこぎ着けたのは快挙であり、「OS/360を越える大規模プロジェクトはあり得ない」という“神話の崩壊”だと思います。世界的な難事業であった青函トンネルの工事には26年と5384億円もかかりました。みずほ銀行のシステム刷新は、それに匹敵する難事業です。

3．システム刷新業務の特徴

　システム刷新は、新規開発と異なる苦労があります。筆者が感じるシステム刷新の課題は以下です。

3.1 今までのやり方を変えたくない

　場合にもよりますが、顧客はシステムが変わっても、業務プロセスを大きく変更する気はありません。そのため、「レガシーと手順が異なる」「レガシーでは○○という機能があったのに、新システムにはない」との厳しいクレームを受ける場合があります。全てのベースはレガシー基準なのです。

3.2 思っている以上に大変

　刷新業務は、新規開発とは異なり、既存の設計資産があります。その上で、システム刷新時に細心の注意を払わねばならないのが、見積もりです。例えば、「顧客側で刷新時の仕様が固まっていない」「データの移行作業に想定以上に工数がかかる」などが原因で、予算額が当初よりも大幅に膨らむ可能性があります。