https://news.goo.ne.jp/article/jbpress/business/jbpress-66788.html?page=2

勘定系システムの統合には、大きく2つのパターンがある。

　一つは全く新しい情報システムを構築して、各行が既存システムから移行する。

　もう一つは、どこか一行の既存のシステムに他社が移行する。後者は片寄せ統合という。

　合併期においては、優劣の開いたシステム間で統合が図られることが多かったために、原則的に先進的なシステムか、規模の大きいシステムに片寄せされる片寄せ統合が多く行われた。

　三菱UFJ銀行の場合は、旧三菱銀行のベンダーであった日本IBMのシステムに片寄せされた。

　三井住友銀行の場合は、旧三井銀行のベンダーであったNECのシステムに片寄せされた。

　さて、みずほFGであるが、旧みずほ銀行の勘定系システムのベンダーは富士通であった。

　ところが、全く新しい勘定系システム「MINORI（みのり）」のシステム構築は、旧みずほ銀行の2002年および2011年にも大規模なシステム障害を受けて開始したこともあり、富士通、日立製作所、日本IBM、NTTデータ（プロジェクト・マネジメント・オフィスの支援を担当）の4つのベンダーが新システム構築に参加した。

　以上まとめると、みずほFGは、富士通、日立製作所、日本IBM、NTTデータのマルチベンダー体制（注）でシステム開発を推進した。

　他方、三菱UFJ銀行および三井住友銀行は、それぞれ、日本IBMおよびNECのシングルベンダー体制でシステム開発を推進した。

　各銀行のシステムベンダーである富士通、日立製作所、日本IBMおよびNECは、いずれも日本を代表するシステムインテグレーターであり開発能力に遜色はない。

　よって、筆者は、みずほ銀行の採用したマルチベンダー体制が、システム障害発生に何らかの影響を及ぼしているのではないかと考えた。

　一般に、システム構築の手法には、マルチベンダー体制とシングルベンダー体制の2通りがあるが、各々にメリットとデメリットがある（メリットとデメリットについては後述する）。

　しかし、大規模コンピューターシステムの開発にはベンダーの数が増えれば、それだけ調整事項が増え、設計にミスが出やすくなる。

　また、参加する人が増えれば増えるほど、信頼できない人がまぎれ込む可能性が大きくなり、業務の忙しさにかまけて必要なチェックを手抜きするかもしれない。

　マルチベンダー体制の最大の問題点は責任の所在が曖昧になることである。これはシステム開発時にもシステム運用後のシステム障害対処時にも当てはまることである。

　銀行のシステムに詳しい京都情報大学院大学の甲斐良隆教授は、「開発に複数企業が関わるとバックアップ機能のテストが難しくなる。一般論だが、責任の所在も曖昧になってトラブルが起きやすい」と指摘する(出典：読売2020.8.25)。

　上記のようにマルチベンダー体制には問題があるが、やりようによっては、すなわち、十分な時間と資金と人材を大量に投入し、経営トップの卓越したリーダーシップがあれば、マルチベンダー体制でも完璧なシステムを構築することができることを付言しておく。

　本稿は、みずほFGのシステム障害に関する報道においてあまり注目されていないマルチベンダー体制の問題点に焦点を当てている。

　以下、初めに大規模なシステム障害の経緯について述べ、次に、シングルベンダー体制とマルチベンダー体制のメリットとデメリットについて述べる。

（注）ベンダーは、元々販売業者、販売供給元を意味する言葉である。ただし、IT業界では、システムの企画、設計、開発、運用、保守までの業務を受託する企業は、ITベンダー、システムベンダー、またはシステムインテグレーターと呼ばれる。

「マルチベンダー体制」とは、複数のITベンダーが協同一致して開発プロジェクトを推進することをいう。他方「シングルベンダー体制」とは、単一のITベンダーが開発プロジェクトを推進することをいう。