【内製開発Summit 2025】100年の歴史を誇る地銀『横浜銀行』の内製化ジャーニー

横浜銀行が内製開発を始めたきっかけ

以前はベンダーに丸投げだった

横浜銀行の嵯峨野と申します。私は国内SIerの系列会社、フリーランス、ベンチャー企業を経て、2023年に横浜銀行に入行しました。現在は内製開発チームにて、スクラムマスター兼組織づくりを担当しております。

会社についてもご紹介させてください。横浜銀行は創立100年を超える地方銀行です。従業員は4000人弱で、地方銀行の中では規模が大きい方だと思います。本日お話しさせていただくトピックはこちらです。



最初に、横浜銀行が内製開発を始めるに至った経緯や、その歩みをお話しします。横浜銀行には、大小合わせて300以上のシステムがあるのですが、2018年まではそれらすべての開発を外部委託していました。俗に言う、丸投げ開発です。

現在でも、ほぼすべてのシステムがこのスタイルで開発されており、銀行側が企画をして発注し、完成したものを受け入れてテストする、そういった流れです。場合によっては、企画や要求定義の段階から外部に参加していただくこともあり、システム開発の多くをベンダーやSIerに頼っています。

この開発スタイルは、ベンダーが完成責任を負ってくれますし、銀行員がコア業務に集中できるというメリットがあります。しかし、一定の開発期間が必要ですし、開発コストが嵩みがちです。また開発ノウハウが社内に蓄積されないため、過去の経験を生かせずブラックボックス化してしまうデメリットもあります。システムが増えるにつれて、どんどん複雑になってしまうという課題もありました。

内製開発のきっかけは、タブレットアプリ

丸投げ開発をしていた横浜銀行が、内製開発に挑戦するきっかけになったのは、店舗で使用するタブレットアプリ「AGENT」です。「AGENT」は、窓口を通して手続きする必要があった口座開設や氏名・住所の変更などを、お客様自身で対応できるようにすることを目的に開発されたものでした。

開発は大手SIerに依頼し、既存パッケージを流用することで短期間でMVPをリリースすることができたそうです。この時点で私はまだ入社していなかったのですが、当時の状況を知る社員からは「素早くユーザーに価値を届ける、といった点では良いプロジェクトだった」と聞いています。

ただ、横浜銀行の経営陣としては、追加機能の開発や保守運用でコストが嵩んでいる状態を課題に感じていたようです。そこに追い討ちをかけるように、金融系の記事を扱っているメディアにて「AGENT」を取り上げながら、横浜銀行のシステム開発に対するコスト意識に苦言を呈する記事が公開されてしまいました。

この記事を目にして危機感を募らせた横浜銀行は、内製開発に挑戦することを決意しました。内製開発のターゲットとして選ばれたのは、記事でも取り上げられた「AGENT」です。

他の地方銀行でもアジャイルによる内製開発に取り組む事例がでてきていたこともあり、横浜銀行でも追加機能をスクラム開発することを目指し、2019年より内製開発に向けた取り組みが始まりました。

外部委託主体のチーム体制からスタート

内製開発に向けて最初に取り組んだのは、体制づくりです。



当時の横浜銀行にはアプリ開発を生業としているエンジニアはいなかったため、SES契約で来ていただいた外部委託のメンバーが主体の体制をとりました。プロダクトオーナーについては、それまでにもシステムの要求定義などを担当していた銀行員が担当することになりました。

SES契約のメンバーは横浜銀行との付き合いが長いベンダーの方で、行内の文化や業務には詳しいものの、開発経験が豊富なわけではなく、アジャイル開発にもあまり慣れていなかったそうです。そのため、初期段階では外部からアジャイルコーチを招いたり、初期開発を依頼した大手SIerにサポートをお願いしたりしていたと聞いています。

内製開発を始めるまでの歩みとは

観察を通して見えてきた三つの課題

最初は外部委託主体のチーム体制で順調に進んでいたのですが、3～4年ほど経ってから、問題が出てくるようになりました。要は、負の遺産が蓄積されて影響を及ぼし始めたのです。

私が横浜銀行に入行したのは、ちょうどそんな時でした。入行してすぐに内製開発プロジェクトに参画することになったのですが、本番障害が発生していたため「このタイミングで入るのは厳しいな」と思ったのを覚えています。

とはいえ、なんとか対応しないといけません。考えた末に、なぜこのような事態になっているのか、プロジェクトの具体的な問題を理解するために、開発風景を観察するところから始めることにしました。そして、観察を通して三つのことに気がつきました。



一つ目は「抜けきらない請負契約の関係」です。3～4年もスクラム開発をやっていたにも関わらず、スクラムのマインドセットが定着しておらず、仕様を伝えたあとは開発エンジニアに任せっきりの状態でした。また、仕様やシステムについて、提供する価値や目的の共有もされていませんでした。銀行業務にありがちな“暗黙のルール”などに関する情報が開発エンジニアに共有されていなかったため、受け入れテストや本番リリースの後に障害が発見されるといった状況が見受けられました。

二つ目は「育たない当事者意識」です。コミュニケーションが不足していたからか、開発チームに当事者意識がないような印象を受けました。自分たちが作っているプロダクトの価値や目的を把握できていなかったため、モチベーションにつながらなかったのだろうと考えています。例えば、共通部分に修正が必要な時、通常であれば既存部分に影響がないか調査しますよね。しかし、調査をせず既存部分に影響がないように自分のところだけ動くようにしている、なんてケースもありました。

そのほか、確認作業を嫌って、使わなくなった処理をそのまま残しているケースもありました。そういったことが積み重なり、機能追加やリファクタリングが極めて難しいソースコードになってしまい、不具合や考慮漏れにつながっていたのです。通常のスクラムであれば、仕様に対して開発者から「もっとこうした方がいい」などの提案がされることがあると思うのですが、そういったこともありませんでした。

三つ目は「蓄積されない開発ノウハウ」です。観察をしている間にも、キーマンと呼ばれるエンジニアが離脱してしまうことがありました。その都度、キーマンに属人化していた知識やノウハウが喪失されてしまうため、チームとしてもリセットされてしまうといった状況が続いていました。外部から来ていただいているベンダーのエンジニアさんの場合、正社員よりも退職のリスクが高くなってしまう傾向があるように思います。

課題対応に向けて、動き出した

先ほど発見した三つの課題について、どうやって対応したのかについてもお話しします。



一つ目の「抜けきらない請負契約の関係」については、銀行員の意識を改善するため、プロダクトオーナーに時間を取ってもらい、スクラム勉強会を開催しました。プロダクトオーナーは、プロジェクト開始時にアジャイルコーチから基本的なレクチャーを受けたようなのですが、あまり理解ができていなかったようで。そもそも、基礎知識がない状態で話を聞いても、話を理解するのは難しいですよね。

それに、請負契約での体制しか知らないのに、急にスクラム開発をしようとなっても「どうすれば良いかわからない」となるのは当たり前だと思います。本来なら、プロダクトオーナーの経験不足をサポートするのがスクラムマスターの役割だと思うのですが、そこができていませんでした。この勉強会は、ある程度の経験を積んで、チームの課題が見えてきたタイミングで開催できたため、プロダクトオーナーも内容が理解しやすかったのではないかと思っています。

二つ目の「育たない当事者意識」については、希薄になっていたコミュニケーションを改善するために、関係者全員が参加できるチャットツールを構築しました。それまではコミュニケーションの手段がメールか電話のみで、メールの見逃しやCCの入れ忘れ、言った言わない問題など、ミスコミュニケーションが生じていました。チャットツールを導入してからは、ミスコミュニケーションが減り、関係者全員が情報にアクセスできるようになりました。開発メンバーとプロダクトオーナーのコミュニケーションも増えて、開発者の当事者意識を向上できたように思います。

三つ目の「蓄積されない開発ノウハウ」について、当時はADR（Architectural Decision Records）のようなものがなく、ミーティングの議事録さえ残っていない状況でした。ドキュメントを作ったとしても「最新版がどこにあるのかわからない」「先祖返りしてしまった」などの問題が多発していました。そこで、社内wikiのようなプロジェクト用の情報共有ツールを導入し、すべての情報を一元管理できるようにしました。ただ新しいツールを導入しても、使い方がわからないと使用してもらえない可能性もあります。そのため、導入してからしばらくは私自身がスクラムイベントやミーティングに参加して議事録を書いたり、ツールの使い方の勉強会を開いたりするなど、工夫していました。

その甲斐もあってか、徐々に情報が蓄積されて情報の見える化が進み、認識のズレや対応漏れも目に見えて減りました。また当時はベンターが1社のみだったのですが、技術的にもマインド的にも良い見本・刺激になることを願って、別のベンダーにも参画してもらいました。

必要なのは「銀行員が主体の開発体制」

地道な活動を通して、少しずつ現場でのスクラム開発の理解が進み、良い流れに乗ることができたように思います。改善のマインドセットが、少しずつ普及してきているのかなと。

そして、私個人としては、改善活動を続けながら「そもそも、横浜銀行にとっての内製開発って何だろう？」と、内製開発の将来像についても検討を続けていました。考えた結果、辿り着いたのがこちらです。



これを長期的に安定して達成していくためには、内製開発を外部ベンダーに依存するのではなく「銀行員が主体の開発体制」が必要だという結論に達しました。具体的に言うと、銀行業務や銀行システムに関する知識を持っていて銀行員と対等に話ができる、圧倒的な当事者意識を持っている銀行員エンジニア。そういったメンバーで構成された開発チームが必要だと考えました。

ただ、そんなチームは短期間ですぐに作れるわけではありません。千里の道も一歩からということで、非常に果てしなく長い道のりに思える「横浜銀行の内製化ジャーニー」が始まりました。

内製開発に向けて組織づくりがスタート

エンジニアが集まらず、最初は苦戦…

2023年より、銀行員主体の内製開発組織づくりがスタートしました。銀行員主体の内製開発をするために必要なのは、先ほどお話ししたような、銀行員エンジニアです。仲間を集めるため、求人サイトや転職エージェントを活用したり、求人イベントに参加したりと色々と努力していたのですが、なかなかエンジニアの目に留まらないという現実がありました。

そのため少し時間がかかってしまいましたが、横浜銀行の取り組みに共感してくれるエンジニアが入行してくれて、なんとか5名のチームをつくることができました。とはいえ、5名揃ったからといって、新しいプロダクト開発をすぐに始めることはできません。将来的に内製開発ができるように、下準備として「銀行内の整備」と「開発チームづくり」を並行して進めることにしました。

下準備その①「銀行内の整備」

新しいことを始める時には、新しい部署をつくるのが一番良い方法だと思います。ただ、横浜銀行では新しいポジションをつくるのが簡単なことではなく、またチーム人数が5名という少人数であることから新しい部署をつくることはできませんでした。

そこで現在、開発チームは「ICT推進部」という部署に所属しています。こちらはシステム開発やインフラ基盤の運用管理を担っている部署で、基本的にはプロジェクトマネジメントを行っているメンバーで構成されています。内製開発をするとなったら、プロジェクトマネジメントに従事している人はステークホルダーになりますよね。ステークホルダーと近い距離で仕事ができるという点では、とても適した所属先なのではないかと考えています。

この活動の一環として、評価制度や内製開発するシステムを選ぶ基準などを決める必要もあったのですが、ここについては後半のパートでお話しします。話を戻して、銀行内の制度が整いつつある現在は、開発チームを大きくしていくための準備活動にも力を入れ始めています。

そこで、まず必要だと感じたのは、プレゼンスの向上です。先ほど、なかなか応募が来なかったとお話ししましたよね。そういった点を改善するべく、内製開発Summitのようなイベントに積極的に参加するようにしています。そのほか、テックブログにも挑戦する予定です。エンジニアに向けて情報を発信することで、エンジニア同士のつながりを広げて、仲間を増やしていきたいなと考えています。

それと並行して、入行していただいた後の準備も進めています。金融業界からの転職はレアケースですし、必然的に他業種からの転職が多くなるはず。そのため、業務知識や銀行内の文化・ノウハウをまとめたものを作成して、中途採用の方が働きやすい環境・職場づくりを目指しています。

下準備その②「開発チームづくり」

現在の開発チームは、若手が多く30歳前後のメンバーを中心に構成されており、100%自分たちの力だけで内製開発を進められる状態ではありません。当面は全面的なサポートが必要であるため、パートナー企業に協力してもらうことにしました。

「個別のシステム開発をサポートするのではなく、横浜銀行に内製およびアジャイルの文化を浸透させるというゴールに向かって伴走してくれる企業がいい」。そう考えて、アジャイル界隈で有名な永和システムマネジメントさんに伴走パートナーをお願いすることにしました。

現在は、アジャイルコーチやテックリードなど、スクラム開発における重要なポジションをお任せしているほか、内製開発を成功させるための作戦会議などにも参加していただいています。



この二つの下準備を経て、2024年7月から、銀行員エンジニアを中心とした内製開発がスタートしました。最初は小規模なサービスから挑戦していて、同時にDevOps環境や次回以降の案件でも利用できるような基盤の構築も進めました。

内製開発スタート後の新たな課題？その対応策とは

エンジニアの評価

次に、銀行員エンジニア主体の内製開発が始まった後に発生した課題と、その対応についてお話します。内製開発を始めるにあたって、一番難しい領域は「社内文化を変えること」ではないでしょうか。そのなかで、最初に課題として浮かんだのがエンジニアの評価です。

開発チームが所属しているICT推進部では「スキルの評価」「業績目標、行動目標の達成評価」という二つの評価軸があります。前者については、レベルごとにチェック項目をつくり、各メンバーのスキルをチェックシート形式で評価しています。そのスタイルに合わせる形で、エンジニア向けのスキルの評価項目を自分たちでつくることになりました。



ただ、実際につくってはみたものの、チェック項目に対する品揃えや難易度が公平なのかどうかを評価できる人材がいないという壁にぶつかってしまいました。こちらについては、机上で検討しても答えが出せるものではないため、運用しながら見直すという形で進めています。

「業績目標、行動目標の達成評価」については、年度ごとに個人で設定するもので、達成したかどうかをクリティカルに評価されてしまう部分でもあるため、無難な目標にしがちという課題がありました。これを改善するには、新たな指標が必要です。例えば、チャレンジングな目標を立てて、100%達成できなかったとしても、達成できた度合いによって評価をする形にできれば挑戦しやすくなるはず。今後はOKRなどのフレームワークを導入して、挑戦しやすい土壌を作りたいと考えています。またスクラム開発を取り入れているため、チームとして成長できているかどうかを評価するために、Four Keys などの導入も予定しています。

案件と予算

次に、開発対象の案件と予算についてお話しします。



現時点で、アジャイル開発や内製開発についてビジネス部門の人たちに正しく理解していただいている状態ではない、というのが実情です。そのため、ビジネス部門の人たちに「どういった案件を内製開発すると良いのか」をわかりやすく説明するために、クネビンフレームワークなどを活用しています。また開発要領やガイドラインを策定し、それをドキュメントにまとめました。ドキュメントを作成する際は、アジャイル開発を専門にされている有名な方に協力いただいてドキュメントの内容に説得力を持たせる、といった工夫もしています。

また横浜銀行のシステム開発の予算は、具体的な効果をもとに算出して計算されています。業務効率化を目的としたシステムを例にすると「このシステムを使うことで、窓口の行員の作業が一日あたり◯分、銀行全体で年間で◯分の工数を削減できます。その結果◯円も経費を削減できます。削減できる経費をシステム開発に投入しましょう」といった具合です。

この予算の取り方は、内製開発との相性があまり良くありません。基本的にプロジェクトの開発期間内しか予算がつかないため、外部から招いている方を含めたチームでは、体制を維持するのが難しくなってしまいます。また特定のシステム開発に対する予算しかない場合、DevOps環境の整備や開発者が挑戦したいことが実現できないという問題もありました。

現在はパイロットプロジェクトとして柔軟に対応してもらっているのですが、将来的にはスタートアップへの投資モデルのような予算の取り方を導入しないと、できることが限られてしまいます。そのため、そういった予算枠が取れるように、さまざまな部署と調整し、働きかけを続けています。

セキュリティやリスク

続いては、セキュリティやリスクについての課題と工夫です。




金融業界は個人情報を取り扱っているため、セキュリティ意識が非常に高く、リスクについても敏感です。安全側に倒した規定やルールが多く、SaaSの導入も慎重に検討しなくてはいけません。

内製開発をするにあたって、DevOps環境の構築をはじめとして、開発生産性を高めるためのツールを導入することが多いと思います。しかし、銀行で新しいサービスやSaaSを利用する場合は、事業会社側にものすごい数のアンケートに対応してもらう必要があります。また実施検査として、銀行側のスタッフがサービスプロバイダーの拠点に行って、きちんとした対策が取られているか視察をするといったこともしています。

このように、新しいサービスを導入するハードルが非常に高いため、いくつかのサービスでは自分たちでサーバーを構築して運用しています。そうすることで、自分たちで必要なセキュリティ対策を決めることが可能ですし、運用も自由になります。構築や運用の手間はかかりますが、それ以上にメリットがあるものはSelf Managedのサービスとして運用しています。例えば、Gitサーバーやソース管理のリポジトリ、チャットツールなどはそのような形で運用しています。今後はドローイングツールやAWSの構成図を書くツールについても、Self Managedのサービスとして運用する予定です。

事務手続きとステークホルダー {#事務手続きとステークホルダー}

会社員である以上は仕方ない部分もあるのですが、事務手続きがとても多いです。今後は、事務をサポートしてくれる人員を導入して、エンジニアが開発に集中できる環境を整えていきたいと考えています。




あとは、分業化が進んでいるため、調整先が多すぎるという悩みもあります。会社としては各分野の担当者の知見が深くなるメリットがありますが、開発者側はちょっとした変更でも皆さんに合意を求める必要があるため非常に時間がかかってしまいます。今後は、スクラムイベントに各ステークホルダーを呼んで、その場でいろいろ決定できるようにしていきたいと考えています。

システム環境やチームについても課題

銀行には「勘定系」と呼ばれる巨大なシステムがあり、テストの自動化が難しいという課題もありました。こちらについては、勘定系システムを操作するためのAPIのレイヤーに汎用的なAPIをつくり、モックによるE2Eテストの自動化をしていきたいと考えています。



チームについては、先ほどもお話ししたように若手中心でスクラム開発の経験者が少なかったため、萎縮してしまっているところがありました。そこで、あだ名呼びの徹底や毎朝のアイスブレイクを取り入れました。小さな工夫ですが、メンバー間のコミュニケーションが目に見えて良くなったので、良かったなと思っています。

あとはペアプロやモブプロも導入しており、非常に経験豊富なテックリードのもとで、スキルを磨いてもらっています。最終的には、銀行エンジニアが独り立ちできる状態を目指しています。



プロジェクトに関する課題もありました。具体的に何があったのかというと、大幅な開発範囲の拡大です。一番最初の開発案件であるため、最初はフロントエンドだけを開発しようと考えていたのですが、気がついたらバックエンドも開発しなくてはいけなくなっていました。スコープが拡大した時点で、開発計画やリリース計画を見直さなかったため、プロジェクト中盤では「本当に終わるのかな…？」とみんなが不安になる状態でした。

現在は、要件もしくはユーザーストーリー自体を見直して細かい機能を少しずつ削ることで、なんとかリリースに間に合いそうなところまでこぎつけています。「なんとかなるだろう」という気持ちでスコープの変更をしてはいけない、という非常に良い学びになりました。

新しい挑戦ができる環境を整えていく

これまでのまとめです。

横浜銀行では「リリースまでが長い」「開発コストの増加」「開発ノウハウの喪失」といった悩みがあり、その解決を目指して内製化に取り組み始めました。「時間をかけずに、コストをかけずに、自分たちの必要なものを作る」を長期的に達成するために、今後は次のようなステップで進めていくつもりです。



まずは実績、土壌づくりとして、いくつかの案件をこなしていくことで、内製開発のメリットを示していきます。その後はチームを株分けして、PoCや短期・長期的なプロジェクトなど、複数の案件がきても同時に回していけるチーム体制を構築します。そんなチームができたからといって闇雲に開発すると、その後の運用保守の部分でつまづいてしまうかもしれません。そのため、どういった領域でどういったシステムを内製開発の対象にするのか、標準化したいと考えています。

そして、それをドキュメントにまとめて、ビジネス部門と認識を共有する。相互理解ができたら次のステップとして、成功パターンを確立していきます。成功する案件や進め方に関するテンプレートパターンがあれば、ビジネス部門も判断しやすくなりますし、開発側にも余裕が出てくるはずです。それにより、新しい挑戦がしやすい環境ができると考えています。

最後に、少しだけ採用のお話もさせてください。横浜銀行では内製開発の仲間を絶賛募集しています。カジュアル面談も実施していますので、お気軽にご連絡いただければと思います！

本日はご静聴ありがとうございました。

▼参考ページ
・内製化取り組みのご紹介
https://www.talent-book.jp/boy/stories/55208

・株式会社横浜銀行人財部 採用担当
問い合わせメール：career_saiyo_yokohama@hamagin.co.j

アーカイブ動画はこちら

https://findy-tools.io/events/7ac096c18ee037bb4478