「内製開発ラボ」立ち上げの目的。内製開発が直面する「不確実性」とは何か

─スピードと正確性の両方が求められる金融領域において、「内製開発ラボ」を立ち上げた背景と目的を教えてください。

染谷：目的は明快で、開発における「不確実性」を減らし、変化に対応する力を育むことです。現場のニーズに素早く応える必要がある一方で、金融領域の開発では品質や安定性の基準を下げることはできません。だからこそ、エンジニアが増えていく局面では、個々の頑張りだけでは開発スピードや品質の統一性に限界が来ます。やり方の違いが増え、判断が遅れ、品質のばらつきが生じ、結果として再作業が増える。こうした「不確実性」が積み上がると、組織としての開発速度は落ちてしまいます。

─ここでいう「不確実性」は、どのような状態を指しますか？

染谷：典型的な例としては、同じような開発であってもチームごとに進め方が異なり、開発期間の見積もりや求められる品質の基準が見えにくいことが挙げられます。アーキテクチャの設計や実装が属人化してソースコードやノウハウの再活用が進まず、過去の知見が次の開発にいかされないケースもあります。また、運用設計が不十分なまま開発が進み、後になって障害や性能面の問題が顕在化し、開発計画そのものが崩れてしまう。私たちは、こうした状態を「不確実性」と捉えています。

「内製開発ラボ」は、その「不確実性」を抑えるために、開発プロセスの標準化を行い、体制が拡大しても、安定した開発のスピードと品質を維持するためのチームです。

「型化」による開発スピードの向上と再現性の追求

─開発プロセスの標準化について、まずアジャイル開発の「型化」に取り組むと聞きました。具体的にはどのような取り組みでしょうか？

染谷：私たちは開発の軸として、2週間程度の短いサイクルで設計・開発・検証・運用を繰り返す「スクラム」という手法を採用しています。

「スクラム」での開発イメージ

前提として、私たちが「型化」したいのはスクラムという手法そのものではなく、設計・開発・検証・運用にわたる「開発プロセス全体」です。スクラムを中核に据えつつ、自社に最適な各工程の標準ルールを整えることで、組織としての開発の進め方を揃えています。

スクラムは本来、変化に強いフレームワークですが、自由度が高い分、組織が大きくなるほどチームごとの差も広がりやすくなります。「型化」の目的は現場の自由度を奪うことではありません。チームごとの裁量は残しつつ、横展開に必要な共通部分を「型」として揃えることです。共通部分が揃っていないと、開発の知見を横展開しにくくなり、人が増えたときに開発体制を拡大できません。だから、スクラムを中核に据えつつ、設計から運用までのプロセスを再現可能にするための「型」を整えています。「内製開発ラボ」がこの土台を築くことで、AIプロダクト開発の「不確実性」を排除し、開発スピードと品質を両立させていくことが狙いです。

─「型」とは、どこまで決めるイメージですか？

染谷：各工程やイベントで何を扱い、どういった成果物を残し、どのような基準で完了と判断するか。その指針を定めることです。例えば、バックログの粒度や受け入れ条件が曖昧だと、スプリントの終盤になって「結局、何が完了したのか」が見えにくくなります。設計・検証・運用の観点があとから入ると、「何をもって完了とするか」の定義にばらつきが生じ、再作業が増えやすくなります。「型化」とは、こうした不透明になりやすいポイントをあらかじめ共通の判断基準やルールに落とし込み、意思決定を速くすることだと考えています。

─開発プロセスの標準化に加えて、AI活用に関するプレイブックも策定されたと伺っています。

染谷：「内製開発ラボ」では全エンジニアにAIツールを提供していますが、使い方の前提が揃っていないと品質がばらつき、かえって「不確実性」を生んでしまいます。この「不確実性」を生まないために、AI活用に関するプレイブックとして「みずほゴールデンパス」を策定しました。これを通じて「どの工程で、何にAIを使い、何を守るのか」を明確に定めています。具体的には、インフラ環境のコード管理ルールやセキュリティ基準、アプリケーションのひな形（テンプレート）等を「型」としてあらかじめ用意し、AI活用が属人化することなく力を発揮できる土台を作っています。

「みずほゴールデンパス」イメージ

さらに、これらの「型」は配布して終わりにせず、現場で得られた知見を取り込みながら常にアップデートする循環を回しています。最新の「型」を提供し続けることで、ゼロから悩む箇所を減らし、開発の再現性を高めているのです。

速く作り続ける組織へ。「内製開発ラボ」がめざす未来

─将来的にAIプロダクト開発をより加速させるためには、組織全体で多数のAIプロダクトの状況を「横断的に可視化」することも重要になると思います。この可視化の取り組みについては、現時点ではどこまで進んでいるのでしょうか？

染谷：まさに立ち上げの段階です。いきなり完成形の指標を作るというより、まずは各工程のリードタイムやチケットの滞留状況といった開発状況に加え、何が実現できたのかを「測れる状態」に持っていくことを優先しています。現場の負担を増やさず、すでに存在する情報を活用しながら、まずは無理のない範囲で可視化を始めている段階です。

─なぜ、最初から指標を作り切らないのですか？

染谷：AIプロダクトの開発指標は、作った瞬間から正しく機能するわけではありません。現場の実態とずれていれば、改善につながらないどころか、誤った行動を促す可能性もあります。また、指標の運用のために入力作業が増えてしまっては本末転倒です。そのため、まずは現場の開発体制に無理な負荷をかけずに測る。測ってみて、改善に有効な解決策か、現場が納得できるかを見ながら育てていくほうが、結果的に強い指標になります。

─最終的には、指標をどのように活用していくことをイメージしていますか？

染谷：将来的には、AIプロダクト開発において、ボトルネックを特定して改善を回すために使いたいです。要件の滞留なのか、レビュー待ちなのか、テストでの再作業が多いのか。そうしたボトルネックを素早く見つけて、開発プロセスの「型」と、それを支えるテンプレートやルールを改善し、AIプロダクトの価値の向上につなげる。その循環が機能し始めると、整備した仕組みが実際の運用改善につながっていきます。

─最後に、「内製開発ラボ」を通じて実現したい状態を教えてください。

染谷：一言でいうと、「速く作る」ではなく、「速く作り続ける」ことです。エンジニアが増えると、通常は品質や開発の進め方にばらつきも増えます。そこで、開発プロセスの「型」を作って展開し、「みずほゴールデンパス」でAI活用の迷いを減らし、計測の仕組みも無理のない形で育てていく。これらがつながることで、「不確実性」は発生しづらくなり、組織全体の開発スピードと柔軟性も高まっていきます。

そして、この開発体制の安定は、社内の業務改善を通じて結果的に〈みずほ〉のお客さまにとっても大きな価値につながります。新しい機能や業務改善の仕組みがスピーディに整うことで、私たちはより多くのリソースを、お客さま一人ひとりと向き合う時間や本質的な課題解決に充てられるようになるからです。「内製開発ラボ」は、そのための土台です。

私たちは今後もこの土台づくりを加速させ、組織の開発力をさらに引き上げていきます。これから新しく参画するエンジニアにとっても、金融という大規模かつ変化の大きい領域で、「内製開発」の土台そのものを設計し、開発生産性向上に貢献できる場は多くありません。単にAIプロダクトを作るのではなく、組織全体の開発のやり方を変えていく。そうした挑戦に興味があるエンジニアにとって、〈みずほ〉は魅力のあるフィールドだと考えています。

内製開発ラボメンバー 左から小見山 勝、張 セイヨウ、小野 雄二、染谷 謙太郎

PROFILE

みずほフィナンシャルグループ
デジタル戦略部 テクノロジー第二チーム

染谷 謙太郎

2025年にキャリア採用でみずほフィナンシャルグループに入社。1社目は大手通信会社にて法人向けのインフラからバックエンドまでのプロダクト開発に従事。2社目にてエンタープライズ向けのソリューションアーキテクトのビジネス課題解決に従事したのち、現職。〈みずほ〉でAIを活用したアプリケーションのプラットフォーム開発を行う等、社内DXを推進。

※所属、肩書きは取材当時のものです。
※「WeWork」にて撮影

文・写真/みずほDX編集部