三井住友カードとデータ・AIチャプターの挑戦

折島：本日は「ゼロから始めるボトムアップ内製化」をテーマに、私たちが数年かけて取り組んできた、強い開発組織をつくるための環境と文化の醸成の仕方についてお話しします。

私は2024年に入社し、現在は全社のデータ利活用とビジネスデータを取り扱うデータ・AIチャプターで、クラウドデータ基盤のチームのシニアマネージャーを務めています。入社以来、データ基盤の全社最適化とモダン化をエンジニアの視点でリードしてきました。三井住友カードは、主要商品であるクレジットカードに加えて銀行との一体商品「Olive」も提供しており、キャッシュレスのインフラを支える企業からテックカンパニーへの変革を加速させています。

私の所属するデータ・AIチャプターは、マーケティング本部に存在し、データ基盤・AI活用・内製開発の3つを軸にビジネスへの価値提供を行っています。社内のデータ基盤とその利活用を担当すると同時に、加盟店向けの総合データサービスも外部向けに提供しています。扱っている決済データは日次で1億円超という規模になり、この膨大で熱量のあるデータをどう料理していくかが私たちの仕事です。

なぜ内製化を進めるのか

今回お話しする内製化についてですが、まずなぜ私たちが内製化を進めているかについてお話しします。
事業会社において内製化の潮流があります。昨今では事業会社でも、ITシステムの開発はビジネスのアジリティを左右する要素だという、考え方のパラダイムシフトが起こったと考えています。つまり、外部依存を減らすことで自分たちで速度とコストを制御しないといけない、そういう力を取り戻す必要があるという考え方にシフトしてきました。これが私たちが内製化を進めるべきと考える根拠の一つです。

私たちのチームが使うデータ基盤を内製化すべき根拠は、4点にまとめられます。1つ目は「翻訳の限界」です。事業会社としてベンダーに強く依存してきた従来の仕組みでも、社員のみが取り扱えるビジネスデータが存在し、これに関するドメイン知識は社員が保持してその運用を担保していくしかありませんでした。2つ目の「ブラックボックスの排除」につながりますが、データのトラブルへの対応は社員が一貫して行うべきで、ブラックボックスは排除されるべきだと考えています。3つ目は「スピードの壁」です。分析ニーズの変化に追従できるスピードは、内製でなければ出せないという認識が共通のものとなりました。4つ目は「守りの要（ガバナンス）」で、セキュリティとガバナンスを外付けではなく開発プロセスの中に組み込むためには、内製が必要だと考えています。

内製だからこそ実現できる品質も見落とすべきではありません。内製エンジニアはユーザーとの近さ、裁量、そして責任を実感でき、現場のエンジニアがビジネスの価値を直接感じられる環境が、モチベーションの原動力になると考えています。

ゼロベースからの挑戦

ではここから、具体的にどのような技術基盤と開発環境を整えたのか、そして道具を揃えるだけでなくいかに文化を変えてきたか、その実践についてお話しします。
チームのミッションは、Snowflakeを利用したデータ開発基盤・データ分析基盤の構築と運用でしたが、実質的に3本のわらじを履いて活動することになりました。1つ目が本来の担当であるデータ基盤、2つ目がアプリとインフラの構築です。社内で当時唯一の内製クラウドインフラチームとして、データ利活用に関わる部門内のアプリケーション開発チームに対してインフラを提供する責務を負いました。3つ目が開発環境の整備で、GitHubのリポジトリやGitHub ActionsによるCI/CDを、部門内外のチームに提供しています。

始動、つまりゼロベースで始めるところでは、ベンダーにビジネス案件ごとにシステム開発を発注するという、事業会社によくある従来のやり方ではないやり方を始めるにあたり、まずそれをやってよいという承認を得る必要がありました。その次に、手の届く範囲でチームを組成していく必要があり、具体的には若手社員と一人一人面談してエンジニアへの転職意欲がある人をピックアップし、集まったメンバーとキックオフを行い、プロジェクト憲章とインセプションデッキを整備して、スクラム開発をやるという方向性をチームとして持っていきました。

次が、決裁の壁と環境を戦略的に使わなければならないという点です。内製開発をやるべきだと私たちが明確に考えていても、それが理解されているとは限りません。「クラウドにする理由がない、オンプレの環境があるからそれでやればいい」というのが、当時の決裁権限者の考えでした。結局一番大事なのは、利用開始できなければ何も始まらないということです。AWSを例に挙げると、自社アカウントで契約して利用することはできない状況になったため、グループ企業がAWSの基盤構築サービスを提供しているところを見つけ、これを利用することにしました。セキュリティと低レイヤーの管理をお任せしてIAMユーザーを払い出してもらうような形になりますが、始められなければ仕方ない、一手妥協して進めていくというスタンスのほうが結局大事だと感じています。

人の育成とハイブリッドチームへの発展

若手社員を選抜してチームを組成した後、その育成には3点の工夫がありました。1つ目は、メンバーに成長してもらうための時間と労力です。「テックデー」と呼んで、平日1日の午後を丸々ブロックし、週4時間のハンズオンを行いました。Linuxから始まり、Git、AWS、Terraform、DBTという必要な技術スタックを、私が講師になって叩き込んでいきました。

2つ目は、時間対比の教育効果を最大化することです。教材作成に時間をかけすぎない、集合研修で一人一人教えずに済ませるといった工夫で、負担をなるべく下げて続けられるようにしました。3つ目が恒常的な学習環境で、教育を始めてから3ヶ月ほど経った頃には業務を割り当てていき、どういう仕事ができるかを一人一人見ていきます。向いていないメンバーが出ていくことも全く気にせず進め、最初5名で始めたところ、入れ替わりを経つつ延べ15人ほどがこの教育に参加しています。

この教育プログラムでは、学ぶことと業務だけでなく、アウトプットにも注力する形をとっています。自社のテックブログ（tech.smbc-card.com）への記事執筆や、外部勉強会での登壇もこなしてもらっています。

かなりハードにいろいろなことを要求しているぶん、成果を出してくれたメンバーにはインセンティブを提供したいという思いがあり、海外カンファレンスに行っていいという仕掛けも用意しています。先月あったSnowflake Summitのサンフランシスコでの様子にも、メンバーが参加してくれました。

とはいえ、社員を高度な業務領域で通用するレベルまで育成するのには時間がかかります。その限界をどう工夫していくかが、もう一つのポイントです。
何をどう作るべきか決定して自分で実装できるリードエンジニアはどうしても必要で、これは私が担いました。ただその人が一人いてもだめで、社員のチームメンバーの技術レベルを向上させ実装できるようにサポートするシニアメンバーが何名かいないと、ジュニアも育ちません。そこで、クラウドベンダーからメンバーに参画してもらい、定着した社員メンバー5名とベンダーメンバー5名でワンチームの体制を作りました。
所属の垣根なく、GitHubやSlackでフラットに連携して業務を進めてもらっています。

組織の壁を越え、失敗から学んだチームビルディング

組織的な壁の突破としては、ルールの活用と追い風という2つの観点があります。社内にはもともと開発者というロールが存在せず、調達した開発用マシンは管理者権限がなく、全ポートが塞がれている代物でした。そうした設定を管理している側はその必要性も知らないため、粘り強い交渉をしていく必要がありました。参画いただいているベンダーとのやり方についても、当社の場合はオフィスに常駐してくれる人でなければ外部ベンダーを受け入れ不可能という仕掛けになっていましたが、社内で粘り強く交渉し、当社初の完全リモートベンダー協業事例として実現しました。

最後の「追い風」については、私たちのチームは完全にボトムアップでやってきましたが、やがてトップダウンで内製開発をやりなさいという動きが発生しました。そうして組成されたチームは、私たちと使えるリソースや置かれた環境がだいぶ違いますが、そこで反発したり腐ったりするのは賢明ではないと考え、それも追い風として、リソースを一緒に使えないかという方向で進めています。

失敗についても触れます。チームビルディングにおいて、成果がありすぎてメンバーにストレスのかかるチームになってしまったという事例があります。

これに対しては、心理的安全性を確保すること、そしてメンバーにはスキルだけでなくエンジニアとしてのマインドセットを育んでもらうことに取り組みました。問題解決に対してプロアクティブに自分ごととして取り組めるかどうかは、エンジニアとして大事な考え方だと思っていて、そこをスキルと同じくらい重視しています。

組織・人・ミッションという3つの軸を同時に並行して回すことで、内製化を推進してきました。現状は、最初の立ち上げ期から開発体制の確立、組織としての壁の突破を経たフェーズ3にあり、今はフェーズ4として、さらに高度な運用や他部署へのナレッジ展開、全社戦略的なハブへの成長を目指しています。

現在地と、これからの挑戦

成果と課題については、生産性が目に見えて向上しました。GitHubやFindy Team+のスコアで可視化しており、一定期間で明らかに高まりました。
ただ、問題点もいくつもあります。全社スケールへの拡大や、レガシーのプロセスへの統合が現在の課題です。加えて、プロダクトの持つAI機能の全面的な利用についても、金融の会社ではAI機能の利用にかなり重厚な承認プロセスが必要で、これを今まさに突破しようとしています。Snowflakeのようなプロダクトが持つAI機能は頻繁にアップデートされるため、審査プロセスの中で「この機能をこう使う」と定義して承認を進めている間に新しい機能が出て、想定する使い方が変わってしまうということが非常に多く、もっと大きくこの仕組み自体を変えていきたいと考えています。

全社戦略との融合については、当社にはトップダウンのシステム開発、いわゆる内製化という動きがすでにあります。この動きは大きく、私たちのチームが中途採用のエンジニア採用のページで様々な職種の募集を行っていることにもつながっています。この大きな動きと連動し、一部のユニットとしてだけでなく、全社戦略とエンジニアリングが高度に統合した姿、全社戦略的なハブになることを目指しています。

金融の会社、事業会社、そして大きな会社という、かなり大変な前提があるなかでもそれを可能にする方法を学んできたつもりです。そこから得た3つの実践知を共有します。
1つ目は「完璧な環境を待たずに始動」することです。必要なアイテムが揃うことを期待せずに始め、何かしらを成し遂げてスモールウィンをすること、その成果を喧伝して存在価値を社内で理解してもらうことが、とても大事でした。2つ目は「ルールと戦わず味方につける」ことです。かなり固い社風がある中で、一旦ルールと戦い始めてしまうと戦いが終わらず、本来やりたいことができなくなってしまいます。そうではなく組織内で協調性を保ちつつ、アンテナを立てて利用できる追い風がないか、それを逃さない姿勢が非常に有益でした。3つ目は「成果よりも安全性を先に」です。内製組織をつくろうというリーダーには成果が見えていても、ついてきてくれる人には全然ピンとこない、見えていないという状況は当たり前のことです。したがってリーダーが自らエンジニアリングの品質を担保しつつ、メンバーには心理的安全性を提供して現場の信頼をつくり上げていくことが大事だと思います。

この3つが、ボトムアップで大きな組織に内製を実現する鍵だと考えています。金融の未来を皆さんの手でつくっていく一助になれば幸いです。
ご清聴ありがとうございました。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画はこちら

※動画の視聴にはFindyへのログインが必要です。