結論：大手SIerでも止まる。発注側は「進捗の可視化」と「中止条件」を最初に握る
日立製作所が、伊予銀行に約60億円、滋賀銀行に約80億円、合計140億円の和解金を支払い、両行の次世代勘定系システムの開発が中止されました（出典：日本経済新聞「伊予銀行、日立製作所から和解金60億円」2026年6月29日／日経xTECH、2024年12月・2026年6月）。発注先は国内有数のシステムインテグレーターであり、対象は銀行の中核中の中核である勘定系です。それでもプロジェクトは完成に至りませんでした。
この出来事が発注経営層・情報システム部門・PMOに突きつける論点は明快です。ベンダーの規模や実績は、プロジェクト完遂を保証しないということ。そして、開発が遅延の末に「中止」へ転がるか、「軌道修正」で着地するかを左右するのは、発注側が要件定義・進捗の可視化・契約上の中止条件をどこまで自分の手で握っているか、という点です。本記事では公表情報から読み取れる範囲で経緯を整理し、発注側が中止リスクを抑えるために実務で何を握るべきかを分解します。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
何が起きたのか：2行が相次いで勘定系開発を中止
両行はいずれも、日立が地方銀行向けに提供するオープン勘定系パッケージ「OpenStage」を用いた次世代システムの構築を進めていましたが、開発の遅延を理由に中止に至りました。報道とIR開示から確認できる事実を時系列で整理します。
| 項目 | 滋賀銀行 | 伊予銀行（いよぎんHD） |
|---|---|---|
| 採用・基本合意の公表 | 2020年9月（OpenStage活用を発表） | 2023年10月（基本合意を発表） |
| 当初の稼働予定 | 2024年1月（その後2度延期） | 2028年稼働を計画 |
| 中止の公表 | 2024年12月20日 | 2025年2月 |
| 和解金 | 80億円 | 60億円 |
| 特別利益の計上 | 2024年10〜12月期に「受取和解金」 | 2026年3月期決算で「受取和解金」 |
| 中止後の対応 | 約61億円でメインフレームを更改し現行を継続（2027年1月予定） | 基幹系高度化の計画を変更 |
（出典：日経xTECH「滋賀銀行が次世代勘定系システムの構築を中止、日立が和解金80億円を支払い」2024年12月、同「日立が伊予銀行に和解金60億円」2026年6月／日本経済新聞、2026年6月29日。各行の稼働予定・計上時期はIR開示および報道による）
滋賀銀行は中止の理由について「想定を上回るハードルの高さと銀行システムの安定的な提供という観点からサービスインの時期を延伸してきたが、早期の完成が見通せない」と説明しています（出典：日経xTECH、2024年12月。同行コメントの引用）。伊予銀行については、日立のシステム提供が想定よりも時間を要し、当初見込んでいた2028年の稼働が難しくなったことが中止の背景として報じられています（報道による）。
注目すべきは、和解金が発注側（銀行）に支払われている点です。つまり会計上、銀行側に特別利益が立つ構図であり、この金額の流れ自体が、開発遅延の責任分担をめぐる交渉の結果を示唆します。ただし、和解の詳細な前提や責任割合は当事者間の合意事項であり公表されていないため、ここでは金額と中止という結果のみを事実として扱います。
独自分析：規模ではなく「不確実性の握り方」で結果が分かれる
ここからは、公表された経緯から論理的に導ける範囲での読み解きです（断定ではなく、発注実務への示唆として提示します）。
第一に、両案件はいずれも基本合意から中止までに複数年を要し、稼働予定が繰り返し後ろ倒しになった末の中止でした。これは、プロジェクトが突然破綻したのではなく、延期の連鎖が一定期間続いた後に「早期完成が見通せない」という判断へ至ったことを意味します。延期が重なる局面こそ、発注側が進捗の実態を独立して把握できているか、続行と中止を判断する基準を持っているかが問われる場面です。
第二に、対象がパッケージ（OpenStage）を用いた構築であった点です。パッケージ活用は本来、開発期間とリスクを圧縮する手段ですが、勘定系のように各行固有の業務・商品・規制対応が深く入り込む領域では、パッケージと自行要件のギャップ（フィット&ギャップ）が想定を超えて膨らむと、かえって難易度と工数が跳ね上がり得ます。「パッケージだから安全」という前提は、要件の固め方しだいで崩れることを示す事例と読めます。
第三に、滋賀銀行が中止後に約61億円を投じて現行メインフレームを更改し、現行システムを継続利用する方針を採った点です。これは、刷新が止まっても銀行業務は止められないという制約を示します。発注側にとって、刷新計画には常に「止まったときの退避シナリオ（現行延命・代替計画）」が必要であり、それを欠いたまま新システムへ一本足で賭けることのリスクを浮き彫りにします。
総じて、この2件が示すのは「ベンダーが大手だから安心」ではなく、不確実性を発注側がどう握るかが結果を分ける、という構造です。これは金融の勘定系に限らず、数十億円規模の基幹システム刷新やレガシー刷新に共通する論点です。
発注側が中止リスクを抑えるために握るべきこと（チェックリスト）
公表事例から導ける実務上の論点を、発注経営層・情シス・PMOが着手段階で確認すべき項目として整理します。
- 要件定義の主導権：自行の業務・商品・規制要件を、ベンダー任せにせず発注側が文書として確定・凍結できているか。フィット&ギャップの範囲と追加開発量を着手前に見積もれているか。
- 進捗の独立可視化：ベンダー報告を鵜呑みにせず、第三者または社内PMOがマイルストーンの達成度を独立して検証できる体制があるか。
- 段階リリース（分割）：全面一括カットオーバーではなく、機能・チャネル単位で段階的に切り替え、各段階で価値を確認できる計画か。
- 中止・撤退の条件：何が起きたら続行を見直すか（遅延幅・コスト超過・品質指標）の判定基準と、責任分担・精算条件を契約に明記しているか。
- 退避シナリオ：刷新が止まった場合に現行システムをどう延命・更改するか、その費用と期間を事前に試算しているか。
- 意思決定の頻度と権限：延期判断を現場任せにせず、経営層が定期的に続行可否を判断する場（ゲート）を設けているか。
このチェックリストは網羅的なものではなく、本事例から読み取れる優先論点に絞ったものです。各組織の規制要件・既存資産に応じて補完してください。
自社への翻訳：金融に限らない「数十億円級刷新」の備え
勘定系は極端な事例に見えますが、ERPや基幹業務システム、生産・物流の中核システムなど、数十億円規模の刷新では同じ構造のリスクが繰り返し現れます。発注側が要件を固めきれないまま着手し、ベンダーの進捗報告に依存し、止まったときの退避策を持たない――この3点が重なると、規模の大小を問わずプロジェクトは中止リスクにさらされます。
実務では、まず着手前の要件定義に発注側のリソースを厚く配分することが起点になります。要件が曖昧なまま見積もりと契約に進むと、後工程での手戻りと追加コストが膨らみ、遅延の連鎖に入りやすくなります。要件定義から進捗管理までを発注側の視点で設計し直したい場合は、DX・システム開発の発注ガバナンス支援で、要件確定・スコープ管理・中止条件を含む発注設計を整理できます。
また、現行のメインフレームや基幹システムを抱えたまま刷新の可否を見極めたい場合は、レガシー刷新の要件定義で、現行延命と刷新のシナリオを並行して評価する進め方が有効です。刷新そのものに踏み切る前に、構想の妥当性と実装難易度を客観評価したいときは、AI・システム導入の可否アセスメントで着手前の判断材料を揃えられます。
進捗の独立検証や、止まりかけたプロジェクトの立て直しのように、計画書だけでなく成果が出るところまで伴走が必要な場面では、成果まで伴走するFDE+のように発注側に張り付いて要件・進捗・意思決定を支える体制が、中止リスクの抑制に寄与します。
いつGXOに相談すべきか
次のような状況にある発注側組織は、着手前または遅延の初期段階での相談を検討する価値があります。
- 数十億円規模の基幹・勘定系・ERP刷新を計画しており、要件定義の主導権を発注側で握りたい
- ベンダーからの進捗報告に不安があり、独立した進捗検証の仕組みを持ちたい
- 既存のプロジェクトで延期が繰り返されており、続行か中止かの判断基準を整理したい
- 現行システムの延命と刷新のどちらを採るべきか、シナリオを並行評価したい
GXOは、要件定義・進捗管理・発注ガバナンスの設計から、成果が出るところまでの伴走まで対応します。中止という最悪のシナリオを避けるための主導権を、発注側に取り戻すところから始められます。まずはシステム刷新の要件定義相談から、自社の計画のどこに中止リスクが潜んでいるかを点検してください。
FAQ
Q. 和解金140億円は誰から誰に支払われたのですか。 A. 日立製作所から、伊予銀行に約60億円、滋賀銀行に約80億円が支払われ、合計で140億円です。会計上は受け取った銀行側に特別利益として計上されています（出典：日本経済新聞、2026年6月29日／日経xTECH、2024年12月・2026年6月）。
Q. 開発が中止された理由は何ですか。 A. 両行とも、日立のシステム提供が想定より時間を要し、稼働時期の見通しが立たなくなったことが背景とされています。滋賀銀行は「想定を上回るハードルの高さ」「早期の完成が見通せない」と説明しています（出典：日経xTECH、2024年12月。詳細な責任分担は当事者間の合意事項で非公表）。
Q. 大手ベンダーに発注すればプロジェクトの完遂は安全ではないのですか。 A. 本事例は、ベンダーの規模や実績がプロジェクト完遂を保証しないことを示しています。要件定義・進捗の独立可視化・中止条件・退避シナリオを発注側が握ることが、規模を問わず重要になります。
Q. これは金融機関だけの問題ですか。 A. いいえ。ERPや基幹業務システムなど数十億円規模の刷新では、同じ構造のリスクが分野を問わず現れます。発注側の要件確定とガバナンス設計が結果を左右します。
