⛰️

ウェルスナビのSREチームの歩みとこれから

に公開

はじめに

システム基盤チームのマネージャーの和田です。
本記事では、SREが所属するシステム基盤チームのこれまでの歩みと、取り組みについて説明します。サービスをより良くするために日々工夫を重ねている皆さまに、本記事が少しでもヒントや励みになれば幸いです。

ウェルスナビについて

当社は「働く世代に豊かさを」というミッションのもと、1兆4,000億円超*1の資産をお預かりするWealthNaviを提供しています。今後は、三菱UFJ銀行と共にデジタルバンクを立ち上げ、保険や年金、住宅ローンなど多様な金融サービスを提供する『総合アドバイザリー・プラットフォーム(MAP)』 を実装し、中立的な立場から、個々人のお金の悩みを解決することを目指します。

チームのこれまでの歩み

システム基盤チームの歩み
システム基盤チームの歩み

私たちのチームのSRE成熟度段階(SREをはじめよう16章より)は「火消し」(トラブル対応に追われる状態)から「門番」(SREが信頼性のゲートキーパーとなる段階)を経て、現在は「パートナー」(開発チームと協働して組織全体で信頼性文化を醸成する段階)への移行を目指しています。

0→1フェーズ(2015年〜)

ウェルスナビ創業間もないこの時期は、専任SREがいない体制で運用を開始しました。
少人数でスピードを重視した構成であり、自動化や高度な運用体制はまだ整っていませんでした。そのため、各メンバーが幅広い業務を担当していました。

1→10フェーズ(2018年〜)

プロダクトの急成長に伴いインフラの課題が増加し、日々のトラブル対応を行いながら基盤のモダナイズを進める必要がありました。
この時期、SREは2名(2018年)から4名(2021年11月)へ、開発者は約25名から約45名へと増員され、安定運用に向けた取り組みが本格化しました。
EC2からAuroraへの移行、Datadogの導入、コンテナ化を実施し、プロダクション環境と開発環境を大幅に改善したことで、開発組織のアジリティが向上しました。

10→100フェーズ(2024年〜)

現在進行中のこのフェーズでは、開発組織が急速に拡大し、プロダクト数も爆発的に増加しています。10→100フェーズと表現していますが、デジタルバンクや新規プロダクトという0→1の立ち上げが連続する状況でもあります。
2024年にはSREが8名、開発者が約80名まで増え、2025年には開発者が100名を超えました。
このタイミングで、プロダクト数・ユーザー数・開発者数が10倍規模になることを見据えた基盤作りに本格的に着手しました。詳細は後述します。

開発組織との関係性について

開発組織との関係性について、チームの取り組みを説明する前にご紹介します。
システム基盤チームは横断的な組織として機能し、プロジェクトベースで協力しています。

各チームとの関わり方(2025年時点)
各チームとの関わり方(一部省略)

スポットの問い合わせは、専用Slackチャンネルに投稿された相談に、emojiリアクション をつけることでNotionにチケットが作成され、担当者が自動で割り当たる仕組みで運用しています。

チームの取り組み

私たちが目指しているのは、 「各チームがSRE、DBRE、FinOpsなどのエンジニアリング手法を効果的に活用できるよう支援し、顧客への価値提供を最大化する」 ことです。各分野の状態目標は次の通りです。

各分野の状態目標
各分野の状態目標

続いて、各分野における具体的な取り組みについて説明します。

Site Reliability Engineeringの取り組み

開発組織全体でSREを実践するためには、組織全体が 「運用の価値」 を理解することが不可欠です。その好例として、Amazon社が提唱する「You build it, you run it」という考え方があります。

従来のモデルでは開発と運用には壁があり、開発したソフトウェアを運用側に投げ渡してその後は関係ないという考えでした。しかし、Amazon では違います。構築した者が運用するのです。
これによって、開発者は自分のソフトウェアの日常的な運用に触れられます。また、開発者は日々、顧客と接することになります。顧客からのフィードバックのループが、サービスの品質向上には欠かせないのです
Amazon社が提唱する「You build it, you run it」 の説明抜粋

当社の「新プロダクトづくりの大原則」はこの考え方と多くの共通点があり、SREを実践する素地が既に整っています。実際、開発チーム自身がオンコール対応を担当している点がその好例です。

新プロダクトづくりの大原則
新プロダクトづくりの大原則

しかし、これを組織文化として定着させ続けるには、継続的な啓発活動が重要です。その一環として、当チームは新卒研修で「You build it, you run it」の考え方と当社の行動基準との関連性について解説しています。さらに、人事エンジニアリングエンゲージメントチームと協力し、オンコール手当の拡充検討など、現場と会社両面からの文化醸成に挑んでいます。

SREの実践例としては、最近「パフォーマンス確認会」を立ち上げました。これはSREと各開発チームのリーダーが知見を持ち寄り、ユーザー数増加やリリースが信頼性に与える影響について認識を揃え、改善の意思決定を行う場です。エラーバジェットなどの手法については、提供価値と投資対効果のバランス調整が必要になったプロダクトから導入する方針としています。

Platform Engineeringの取り組み

フィードバックループをまわして顧客へ届ける価値を最大化するという共通目的ができたら、次に考えるべきは少人数チームの認知負荷軽減です。
Netflixの記事にもある通り、少人数のチームでループを回すためにはその作業を支えるためのツールが重要になります。

Netflix社ブログより: 驚くべきツールをもってループをまわす開発者の図
Netflix社ブログより: 驚くべきツールをもってループをまわす開発者の図

当チームでは2024年にEKSをマルチテナントモデルで導入し、これを開発を支えるプラットフォームとして発展させてきました。

また、社内の開発者向けポータルにてツールのロードマップを公開し、開発者からのフィードバックをもとに優先順位を決定して対応を進めています。
開発者ポータルで公開している開発・運用基盤ロードマップ
開発者ポータルで公開している開発・運用基盤ロードマップ

実装したツールについては、開発者向け勉強会で発表を行い、その勉強会を軸として実装サイクルをコントロールしています。詳細は、0からはじめるプラットフォーム普及活動 をご確認ください。

Database Reliability Engineeringの取り組み

当社の主力事業であるWealthNaviのデータベースは、顧客数とデータ量の増加によりスケーラビリティの課題に直面しています。複数のアプリケーションが共同利用する構成のため、顧客視点のモニタリングだけでは問題への対応が後手に回る可能性があります。

そのため、データベースのリスクに対して、対応策の優先度や対応期限を可視化し、組織全体で共有できる判断基準を確立することを目指しています。負荷の可視化にはDatadog Database Monitoringを導入し、開発者自身がすぐに調査をはじめられる環境を整えています。

最近では、新卒メンバーが開発効率や品質向上に大きく貢献しています。具体的には、バッチ処理のパフォーマンステスト向けに、任意日時のマスク済みDBクラスタを作成できるツールをGoで実装し、さらにk6を使用して負荷テストコードも実装してくれました。

断面のマスク済みのDBクラスタを作成する仕組み
断面のマスク済みのDBクラスタを作成する仕組み

この機能はすでに開発者に提供している仕組みの中に統合され、Notion経由で利用できるようになっています。仕組みの詳細については過去の記事をご確認ください。
https://zenn.dev/wn_engineering/articles/9e5b6ee94e6b39

FinOpsの取り組み

FinOpsは単なる「コスト削減」ではなく、コストに対する意識を持ち、投資対効果を最大化するための意思決定を支援する文化と実践だと考えています。

直近では、開発者向けに開発環境のクラウドコストに関する勉強会を実施しました。この勉強会では、各チームの開発環境におけるクラウドリソースの使用状況を可視化し、コストの発生箇所と改善機会を具体的に共有しました。また、「コストを下げる」ことだけでなく、「必要な投資によって開発スピードや品質を向上させる」ことも重要な価値である、という観点についても意見を交わしました。

あわせて、Datadogにコストダッシュボードを作成し、週次でコストの緩やかな増加傾向を監視しています。あらかじめ定めたしきい値を超える増加が見られた場合は、その要因を開発チームなどに確認した上でプロダクトごとにNotion DBへ記録し、ナレッジとして蓄積しています。今後は、このデータをもとにAIを活用してコスト傾向を分析し、プロダクトごとのコスト最適化戦略の立案に活かしていく予定です。

AWSコストダッシュボード
AWSコストダッシュボード(緩やかな増加傾向を監視)

今後も、各チームが自律的にクラウドコストと向き合えるよう、ダッシュボードの整備や定期的なコストレビューの開催など、SREとして仕組みづくりを継続していく予定です。

AIOpsの取り組み

同じグループのAI推進チームと協力し、AIアシスタントプラットフォームの基盤構築とフィードバックを行っています。グループの特性を活かしてAIの最新機能に早期にアクセスし、システム運用の効率化と品質向上に向けたアイデアを積極的に探求しています。

AIアシスタントプラットフォーム
AIアシスタントプラットフォームの構成図

また、GitHubのPRレビュー自動化、オンボーディング用Slack Bot開発、GitHub Copilot Agent ModeやNotion AIの活用推進にも取り組んでいます。
本取り組みはAIに興味があるリーダーや、新卒をはじめとした若手メンバーで結成されており、日々(私が知らない)新しいツールが誕生しています。今回の記事を書くにあたり、彼らに推しツールを教えてもらったので以下にそのスクショを貼ります。

Slackのスレッド内の会話をもとにタスクを切ってくれるBot
Slackのスレッド内の会話をもとにタスクを切ってくれるBot

DBパフォーマンスレポート作成をしてくれるBot
DBパフォーマンスレポート作成をしてくれるBot

サブシステム開発の取り組み

当チームではイベント・メール処理サブシステムを運用しており、Goを使用してクリーンアーキテクチャで開発を進めています。

イベント駆動基盤とメール送信基盤
イベント駆動基盤とメール送信基盤

このサブシステムは、マルチプロダクト化される前に構築された基盤であり、現在は主力事業のWealthNaviでのみ利用可能な状態です。そのため、特定プロダクトへの依存を段階的に解消していく必要があります。今後、より幅広い活用を促進するためには、管理コンソールの実装やスケーラビリティの向上が必要不可欠です。

マネジメントの取り組み

ピープルマネジメントの取り組み

システム基盤グループはメンバー・組織マネジメントに力を入れています。
例えば、グループ長が中心となって、カッツの技能習得モデルとリーダーシップ・パイプラインの考え方を基に、次のグレードに必要なスキルとマインドセットの転換を独自に可視化し、メンバーがキャリアの方向性を理解できるよう支援しています。

役割・期待値の変化を可視化した図
役割・期待値の変化を可視化した図

テクノロジーマネジメントの取り組み

また、プロフェッショナル職を目指すメンバーが主導して、チームの経験と個々のメンバーの興味を調査しています。この調査結果をもとに組織の縦と横の技術スケール戦略を策定し、採用計画やプロジェクトのアサインメントに活用しています。

チームの経験と興味から算出した伸びしろ(大きいほど伸びしろがある)
チームの経験と興味から算出した伸びしろ(大きいほど伸びしろがある)

さらに、リーダーシップパイプラインの定義とメンバーのスキル・興味をNotionで一元管理し、AIミーティングノートで記録したキャリア面談の議事録と組み合わせることにより、メンバー一人ひとりに合わせた最適なキャリア支援の仕組みを構築しています。

プロダクトマネジメントの取り組み

私たちのチームが担う領域(開発・運用基盤、可観測性、デリバリーパイプライン、インシデント管理など)は、他チームに再利用され、信頼され、継続的に改善されるべき「サービス」です。そのためには以下が求められます。

  • 顧客(=開発チームや顧客、CSなど)を明確に意識する
  • ユースケースやニーズを把握する
  • 機能や使いやすさ、信頼性、ドキュメントの整備といったプロダクト的な品質管理
  • 提供価値と投資対効果のバランスを考える

つまり、チームのアウトプットを「プロダクトとして扱う」視点が重要になります。
まずは開発者ポータルやサービスカタログを立ち上げ、勉強会などで継続的な接点を持つところからはじめています。詳細は前述したPlatform Engineeringの取り組みをご確認ください。

フィンテックSREは大変?

これまでの取り組みにおける主な障壁は「金融ならではのルール」です。この障壁を乗り越えるには、ルールの原理原則を深く理解し、現代のテクノロジーでどのように要件を満たせるのかを監査で説明できる必要があります。

幸いなことに、同グループの情報・システム統制チームと密に連携できる環境があります。例えば、私たちの方でまだ詳細を固めていない段階でも、法規制や社内規定を調べ上げたうえで方針を示してくれるなど、非常に心強い支援を受けており、不安なく進められています。

それ以外は一般的なSRE業務と変わりません。顧客(エンドユーザー・開発者・ビジネスサイド)の状況や提供価値を理解し、プロダクトがなぜ上手く動いているのかを常に考える姿勢さえあれば、金融業界の経験がなくても十分に活躍できる環境です。現に私たちのチームは金融業界出身以外のメンバーの比率が高いです。

システム基盤チームのプロフィール(2025年5月時点)
システム基盤チームのプロフィール(2025年5月時点)

ここからは個人的な考えの話になりますが、私のこれまでの経験から、SREには絶対的な正解は存在しないと学びました。そのため、金融機関として、また現在の会社のフェーズに応じて、どのような取り組みが必要か探求することを楽しめる人にSRE適性があると考えています。
https://zenn.dev/waday/articles/8d1c0bc82c5582

まとめ

SREが所属するシステム基盤チームは、プロダクト数・ユーザー数・開発者数が10倍になることを見据えた基盤強化に取り組んでいます。これを実現するためには、SRE、Platform Engineering、DBRE、FinOps、AIOps、DevSecOpsなど、多岐にわたる分野での成熟度向上が必要不可欠です。

本記事ではそれぞれの取り組みを概念的に説明しましたが、技術的な詳細については、今後メンバーから順次発信していく予定ですので、ご期待ください。

SREを募集しています

これからの超拡大フェーズを乗り越えるためには、新たな仲間の力が必要です。

https://hrmos.co/pages/wealthnavi/jobs/100009906

当社のSREとして働く魅力は次の通りです。

  • 働く世代が長期で利用する社会的意義のあるプロダクト運営に携われる
  • 新規プロダクトの立ち上げや大規模なシステムの運用を経験できる
  • 特定プロダクトに深く関わるSRE、横断的なSRE、DBRE、開発者向けプラットフォーム開発など、様々な役割を行き来できる
  • 同グループにAI、セキュリティ、統制などの専門家チームが存在するため、強力な支援を得ながら業務に取り組める
  • 日本最大規模のデジタルバンクを立ち上げ など組織の拡大が続いており、手を挙げればチャンスを掴みやすい環境
  • 新技術や新ツール導入に積極的な文化
  • メンバー発案のAWS新機能キャッチアップ会などボトムアップな取り組みが活発

金融未経験やバックエンドエンジニアなど他職種からのチャレンジも大歓迎です。
気になる点があればカジュアル面談などで気軽に聞いてください。
https://hrmos.co/pages/wealthnavi/jobs/100000002

*1: 2025年1月23日時点

WealthNavi Engineering Blog

Discussion