――とある金曜日の夜。
東京・京橋の会場は、オンラインの視聴者とともに、静かな、しかし確かな熱気に包まれていました。
そのイベントの名は「Zero.Lab Open Day 2026」。
普段、デジタルバンク「みんなの銀行」のシステム開発を担うゼロバンク・デザインファクトリー（※1 以下、ZDF）のエンジニア陣が、業務時間内に役職関係なく自らの知見を共有し、刺激し合う社内登壇会「Zero.Lab（ゼロラボ）」（※2）。
このZero.Labの特別編として、私たちが直面した「過去最大級の挑戦」とその乗り越え方を社外の皆さまに向けてありのままに語る、オープンな場が設けられました。この記事では、その熱気あふれる様子を1本のレポートに凝縮してお届けします。
※1 ゼロバンク・デザインファクトリーは、みんなの銀行のシステム開発を担う兄弟会社です。組織こそ分かれていますが、私たちはワンチームで「みんなに価値あるつながりを。」というミッションの実現を目指しています。
※2 Zero.Labは、2022年から続く、社内エンジニア向けの登壇会。開発を担うZDFのエンジニアたちが、普段から組織の垣根を越えて知見を共有し、互いに刺激し合う文化として根付いています。今回の「Zero.Lab Open Day」は、その特別編として、社外の方々にもご参加いただけるリアルセミナー形式で開催されました。
潜在ユーザー規模10倍超。「絶対に落とせない」戦いの幕開け
▲写真：みんなの銀行／ゼロバンク・デザインファクトリー 宮本昌明CIO
私たちみんなの銀行にとって、2025年は大きな転換点となりました。国内有数のユーザー規模を誇る外部プラットフォームとの、戦略的なBaaS（Banking as a Service）提携。これにより、そのパートナー企業のアプリを通じて、みんなの銀行の機能が提供されることになったのです。
しかし、エンジニアチームに突きつけられたミッションは、極めてチャレンジングなものでした。
宮本CIO「パートナー企業は数千万人規模のユーザーを抱えています。我々はその規模のアクセスに備える必要がありました。これは、当時のシステムから見れば、一気に10倍超のトラフィックを捌き切る能力を要求されることを意味していました。」
CIO（最高情報責任者）の宮本さんは、当時の緊張感をそう振り返ります。
もし、サービス開始と同時にアクセスが集中し、システムがダウンしてしまえば、お客さまの信頼を損なうだけでなく、パートナー企業にも多大な影響を与えてしまう。まさに「絶対にシステムを落とすな」という至上命題。
この巨大なプレッシャーに対し、バックエンド、フロントエンド、QA、インフラ、4つの領域のエンジニアたちは、いかにして立ち向かったのでしょうか。それぞれの「壁」と「突破口」を、登壇順に見ていきましょう。
1. バックエンド：鉄壁のAPIセキュリティと合理的な総力戦
▲写真：Application Development Headquarters Engineering Division2 BaaS開発Group 志村 直紀さん
最初に登壇したのは、BaaS API開発を担ったバックエンドエンジニアの志村さん。彼が語ったのは、「安全」と「スピード」を両立させるための、二つの知られざる奮闘でした。
「診断ツールが動かない……」高セキュリティであるがゆえの課題と突破口
銀行のAPIである以上、セキュリティは絶対に妥協できません。
しかし、その認証・認可方式を極めて強固にした結果、思わぬ事態が発生します。外部の専門会社による「脆弱性診断」で、通常の診断ツールではAPIを叩けないという壁にぶつかったのです。
志村さん「これでは、システムの“健康診断”ができない……。」
このままではプロジェクトは進まない。ここで彼らが取った解決策は、意外なものでした。
志村さん「診断会社がテストデータを安全に投入し、正しく検査を実施できるように、診断専用のツールを自社開発したのです。」
これは、セキュリティレベルを下げて検査を迂回させたのではありません。むしろその逆で、システムの堅牢性を保ったまま、第三者による厳格なチェックを可能にするためのプロフェッショナルな「工夫」でした。この自作ツールと、リクエストコマンド集を整備したことで、無事に診断を完了させることができたのです。
ツールの限界を超えろ！目的達成のための「物理的」負荷テスト
次なる壁は、性能を測る「負荷テスト」で現れました。数千万ユーザーのアクセスを想定した負荷をかけようにも、テストツールの性能が限界に達し、ローカルPC1台では目標とする負荷をかけられません。
志村さん「どうする？ このままでは、想定トラフィックに耐えられるかの検証ができない……。」
クラウド上で大きな負荷をかけるテスト用環境を組む時間もない中、チームが下した決断は、極めてシンプルかつパワフルなものでした。
志村さん「多端末からの同時アクセスという、より現実に即したシナリオを検証するため、チーム全員のPCを会議室に持ち寄って、一斉に負荷をかける。デジタルの課題解決ですが、目的達成のためにはこうした物理的なアプローチも厭わない。これも一つの合理的な判断でした。」
クラウド環境内のみでのシミュレーションだけではなく、多端末からのアクセスという、より現実に近い挙動を確認するために、あえて物理デバイスを用いた最終確認も徹底する。
この「念には念を入れる品質へのこだわり」が、大規模トラフィックの信頼性を担保する礎となったのです。
2. フロントエンド：「ゼロからの構築」を支えた“対話”の力
▲写真：Application Development Headquarters Engineering Division3 原田 一大さん
続いて登壇したフロントエンドエンジニアの原田さんが挑んだのは、アプリを介さずにブラウザだけで金融体験を完結させる「ウェブ金融空間」の構築でした。
「想像以上にタフな状況でした」――ゼロベース開発と大量のバグ
これまでのモバイルアプリの資産が使えない、私たちにとっては全く新しいウェブ開発。福岡と東京に拠点が分かれ、フルリモートで進むプロジェクトは、当初から困難の連続でした。
原田さん「フレームワークは？ ディレクトリ構成は？ 状態管理は？ CI/CDは？ 決めることが山積みで、正直『想像以上にタフな状況』の一言でした。でも、せっかくゼロから作るなら、数年間は保守しやすい『綺麗な土台』を作りたい。その想いは譲れませんでした。」
土台を固め、いざ開発が進み始めたテストフェーズ。今度は「直しても直しても湧き出るバグ」という次なる壁が立ちはだかります。
原田さん「文言が違う、レイアウトが崩れる、エラーメッセージすら表示されない……。いつ終わるか分からない不安がありました。」
解決の鍵は「デザインドキュメント」。コードを書く前に合意形成を
この二つの大きな壁を突破した原動力。それは、最新のツールではなく、極めて地道な「コミュニケーションの徹底」でした。
原田さん「拠点が離れているので、すべてのやり取りをSlackやConfluenceに形として残すことを徹底しました。特に効果的だったのが、『デザインドキュメント』の導入です」
これは、コードを書き始める前に、「なぜこの修正をするのか」「どう実装するのか」「完了条件は何か」をドキュメント化し、関係者と合意形成する手法です。
原田さん「実装後に『思っていたのと違う』という手戻りをなくし、レビュアーの負担も劇的に減らせました。結局、コミュニケーションが大事という当たり前の結論ですが、それを徹底し、文化として根付かせたことが、巨大なユーザー規模を迎え入れる『ウェブ金融空間』を支える真の力になったのです」
3. QA：銀行の“重厚な”テストを24時間稼働させるハイブリッド戦略
▲写真：System Design Division Project Management Group 小林 亜美さん
3人目は、QA（品質保証）エンジニアの小林さん。彼女は「銀行のテストはタフで当たり前」という定説に、テクノロジーと戦略で挑みました。
ボトルネックは「BST」。手動テストの限界
お客さまの資産を守るために実際の業務の流れに沿って行う「BST（業務シナリオテスト）」は、銀行システムの品質を支える最後の砦です。しかし、その多くが手動で行われ、準備負担や手戻りリスクから、開発全体のボトルネックになっていました。
小林さん「この重い課題を、どうにかして効率化できないか……。」
小林さんが武器として選んだのは、AIテスト自動化ツールでした。
「100%自動化」は目指さない。逆転の発想が生んだ時間創出効果
しかし、外部システム連携や物理デバイスの操作など、銀行業務のテストには自動化が困難な制約も多く存在します。すべてを自動化しようとすれば、逆にコストが膨らんでしまう。
そこで小林さんが導き出した答えは、「手動と自動のハイブリッド運用」でした。
小林さん「完全自動化は目指さない。制約がある部分は人間が担当し、繰り返し発生する共通手順や、深夜・休日のテストを自動化ツールに任せる。これが最も現実的でした。」
この戦略の最大の強みは、「1日24時間をフル活用できる」点にあります。
日中は人間が複雑な判断を要するテストに集中し、エンジニアが眠っている夜間や休日に、AIテスト自動化ツールが単純なテストを回し続ける。これにより、カレンダー上のテスト期間を劇的に短縮することに成功しました。
小林さん「今回の取り組みは、まだ“一合目”。自動化は導入して終わりではありません。今後は誰でも使えるように標準化を進め、さらなる効率化を進めて山頂を目指します。」
銀行システムの品質を守りながら、いかに開発～テストのスピードを上げていくか。QAチームの挑戦は、まだ始まったばかりです。
4. インフラ：「クラウドの常識」を超えて。「絶対に落とさない」ためのプロフェッショナルな決断
▲写真：Infrastructure Development Headquarters Architecture Division2 櫻井 拓海さん
最後に登壇したインフラエンジニアの櫻井さんは、このプロジェクト最大の課題、「潜在ユーザー数10倍超」という巨大なトラフィックをどうさばき切るか、その心臓部を担いました。
急激なアクセス増にどう備えるか？「リスクがあるなら、コストよりも安定性を優先する」
「絶対にシステムを落とすな」。CIOからの至上命題を受け、櫻井さんは3つの懸念を洗い出しました。
1．GKE(※)のスケールアウト速度：負荷に応じて処理能力を自動で増減させる「オートスケール」は、稼働までに数分のタイムラグがある。急激なアクセス増加には間に合わないのでは？
2．DBの性能：データベースは想定される高負荷に耐えられるのか？
3．クラウドのクォータ抵触：Google Cloud側で設定されたリソースの上限に達してしまうのではないか？
※GKE：Google Kubernetes Engineの略。Google Cloudが提供する、コンテナを自動的に管理するサービス。
最初の壁、GKEのスケール速度問題。櫻井さんの提案は、コスト効率を重視するクラウドの常識をある意味で覆すものでした。
櫻井さん「『オートスケールが間に合わないリスクがあるなら、コストよりも安定性を優先し、最初から最大構成で臨む』。それが、私たちが下した最も合理的な判断でした。」
これは「先行スケール」と呼ばれる手法。コストはかかりますが、「絶対に落とさない」という信頼性を最優先した、プロフェッショナルな経営判断でもありました。
最後は「地道な試算」がモノをいう
DBのコネクション数上限や、クラウドのCPU総数といったクォータの壁に対しては、魔法のような解決策はありません。
櫻井さん「GKEにデプロイされている全てのワークロードを洗い出し、CPUやメモリの使用量をスプレッドシートで緻密に計算しました。その結果をもとに、Googleへ事前に上限緩和を申請する。結局、インフラの安定稼働は、こうした泥臭いとも言える作業の積み重ねによって支えられているのです。」
クラウドを使えば何でも自動で解決されると思われがちですが、大規模トラフィックを支える鍵は、最新技術の知見と、それを使いこなすための地道な準備と計算、そして「安定性を死守する」という強い意志でした。
なぜ、みんなの銀行は「挑戦」を楽しめるのか？
4人のエンジニアが語った、それぞれの挑戦。
技術的な面白さはもちろんですが、何より印象的だったのは、全員が「大変だった」と語りながらもその表情がとても誇らしげで、楽しそうだったことです。
なぜ彼らは、これほどの巨大な壁を楽しみ、乗り越えることができたのか。
その答えは、このイベントの母体である「Zero.Lab」という文化そのものにありました。
「Zero.Lab」は、月に一度、業務時間内に開催される社内登壇会です。この取組みの目的と、2023年以降は年に1回、社外に公開している理由について、宮本CIOはこう語ります。
宮本CIO「元々Zero.Labは、純粋に社内エンジニアのための文化として始めました。目的は大きく3つです。
一つ目は、チームや領域の垣根を越えて知見を共有し、互いのコミュニケーションを活性化させること。
二つ目は、資料作成や登壇を通じて、プレゼンテーション能力といったソフトスキルを磨き、登壇者自身の価値を高めること。
そして三つ目が、仲間の挑戦に触れることで自己研鑽への刺激を受け、組織全体で高め合う風土を醸成すること。
エンジニアがもっと気軽に表舞台に立ち、自分の仕事をアピールできる。そんな機会が、個人の市場価値を高め、組織の力になると信じています。」
そして今回、この熱気あふれる文化を社外の方にも体感してもらうべく、「Zero.Lab Open Day 2026」が開催されました。
宮本CIO「私たちの挑戦やカルチャーをありのままに見ていただくことで、まずはゼロバンク・デザインファクトリーという会社のことをもっと知っていただきたい。そして、この記事を読んでくださっているあなたのような、未来の仲間と出会うきっかけにしたい。今回のイベントには、そんな採用への想いも込められています。」
この文化を象徴するのが、新作ステッカーのキャラクター。凛々しい表情のキャラクターの頭の上には、一見すると「バグ」にも見える、王冠のようなアイコンが乗っています。これは、挑戦の過程で生まれる困難さえも、成長の糧として乗り越えていく、私たちのカルチャーを象徴しています。
宮本CIO「バグや失敗さえも自分たちの一部として受け入れ、それを乗り越えて成長していく。そんな想いを込めて、デザインもできるフロントエンドエンジニアと一緒に作りました。銀行という堅いイメージを超えて、エンジニアが失敗を恐れずに発言できる心理的安全性を、こうした遊び心で作りたかったのです。」
個々の技術力はもちろんのこと、「自分の知見を惜しみなく共有し、仲間の挑戦をリスペクトする」。Zero.Labで培われたこの文化こそが、今回の巨大プロジェクトを成功に導いた最大のエンジンだったのです。
おわりに
巨大な挑戦の裏側で、エンジニアたちは何を考え、どう乗り越えたのか。「Zero.Lab Open Day 2026」のレポートでは、その一端として、「銀行」という枠組みを超え、モダンな技術と地道な努力、そして遊び心を持って課題に立ち向かう彼らの姿をお届けしました。
みんなの銀行、そしてゼロバンク・デザインファクトリーは、これからも「挑戦」を楽しみ、それを乗り越えることで、新たな価値を創造していきます。今回のレポートで紹介した、困難なプロジェクトを成功に導いたエンジニアリング文化やその裏側にあるストーリーから、読者の皆様が何か一つでも得られるものがあれば、大変嬉しく思います。
※この記事は、みんなの銀行公式ブログ「note」からの転載です。
最新情報やサービス詳細は、みんなの銀行公式サイトをご確認ください。
公式サイト：https://www.minna-no-ginko.com/
