コーディングエージェントの普及によって、ソフトウェア開発の現場は「AIを入れるかどうか」を議論するフェーズを通り過ぎました。
問いはすでに、AIがある前提で組織をどう設計するかに移っています。

ところが金融業界の開発組織にとって、この移行はそう単純ではありません。
お客さまの大事なお金を預かる以上、品質も安全性も統制も落とせない。そのうえで内製開発の組織は急速に拡大し、エンジニアの評価も、経営との対話も、システムの統制も、同時に整えなければならない状況にあります。

本イベントに登壇した3社が語ったのは、「開発現場で起きていることを、外から見える形にし、個人の努力を組織の能力へ変えていくための仕組みづくり」でした。評価という「人」の仕組み、計測という「プロセス」の仕組み、統制と量産という「基盤」の仕組み。切り口は異なりますが、3社はいずれも、属人的な頑張りに依存しない構造をどう設計するかという同じ問いに向き合っています。

ご登壇いただいたのは、株式会社横浜銀行の嵯峨野憲作氏、株式会社セブン銀行の紙中加代子氏、株式会社みずほフィナンシャルグループの齋藤悠士氏の3名です。

3社が扱ったレイヤーは、それぞれ「人」「プロセス」「基盤」と綺麗に分かれています。
本レポートでは、単なるセッション要約ではなく「開発組織の課題解決ストーリー」として、3社の視点の違いが見える形で整理してお届けします。

イベント概要

• イベント名：金融業界の開発組織がAI時代に整えるべき「3つの仕組み」
• 主催：ファインディ株式会社（Findy Team+）
• 形式：オンライン配信（Zoomウェビナー）
• 開催日時：2026年7月14日（火）12:00〜13:40
• テーマ：評価・計測・AI活用の各仕組みを軸に、金融機関の開発組織が生産性と品質を両立するための実践知を共有
• イベントページ：https://jp.findy-team.io/events/finance-devorg-260714/
• 登壇者
  • 嵯峨野 憲作 氏
    • 株式会社横浜銀行／ITソリューション部 プロダクトエンジニアリンググループ リーダー
  • 紙中 加代子 氏
    • 株式会社セブン銀行／金融ソリューション部 部長
  • 齋藤 悠士 氏
    • 株式会社みずほフィナンシャルグループ／デジタル戦略部 テクノロジー第二チーム 次長

セッション①｜横浜銀行：エンジニアでない上司が、エンジニアを正しく評価するために

課題・背景

嵯峨野氏のキャリアは、SIer子会社 → フリーランス → ベンチャー → 機械メーカー → 横浜銀行という経歴をたどってきました。機械メーカーで内製開発に取り組んでいた時期からスクラムマスターとして活動するようになり、2023年に横浜銀行へ入行。現在は内製開発の組織づくりとエンジニアリングマネージャーを担当しています。

横浜銀行の内製開発の歩みは、そのまま今回の課題の背景になっています。

• 2019年：横浜銀行の内製化が開始。ただし当初はパートナーエンジニア主体で、外部から来たエンジニアがコードを書いていた
• 2023年：嵯峨野氏が入行
• 2024年：銀行員主体の開発チームが始動。銀行員エンジニア4名からのスタート
• 現在：銀行員エンジニア12名／3チーム体制
• 来年度：18名体制を目指す

問題は、この拡大に伴ってマネジメントの複雑さが人数以上のスピードで増していくことでした。しかも横浜銀行の場合、もともとコードを書くエンジニアがいない組織の中にエンジニア組織を作っているため、管理者・評価者がエンジニアではない行員の上司という構造になっています。

嵯峨野氏はスパン・オブ・コントロールという概念を挙げました。一人が把握できるメンバーは5〜8人、最大でも10人と言われますが、現在すでにその人数を超えており、管理限界を迎えている状態です。
さらに人数が増えるほど、行内の規定作り、開発体験向上の取り組み、対外活動、他部署からの相談と、組織の作業そのものが多様化していきます。

感覚に頼った運営では、なぜ限界を迎えるのか

では感覚で評価すればよいかというと、そこには3つの壁があります。

• 成長している部分を把握できない
  • そもそも一人一人の活動を把握できていない状態で、「この人はここが成長した」とは言い切れません
• エンジニアの「実績」をどう測るか分からない
  • 「何かたくさんコードを書いていたっぽい」「バグが出ていないから品質活動を頑張っていたのかな」では、適切な評価になりません
• 案件リリースは外部要因で変動し、評価軸にしづらい
  • そもそもエンジニア一人だけの実績ではありませんし、ビジネス部門の都合でプロジェクトが延期・中止されれば、エンジニアの実績が「何もしなかった」ことにされかねません

嵯峨野氏はこれらの根っこを一つに束ねます。評価と改善の定量的根拠が不足している、という一点です。

「銀行エンジニアの評価」という固有の難しさ

この構造は、横浜銀行の人事制度と衝突します。同行の評価制度では、半期ごとに定量的な業績目標が必要です。営業職なら融資の実行額や預金の獲得額、事務職なら処理件数やミスの上限。いずれも定量化しやすい指標です。

しかしエンジニアにとっては、事情が異なります。

• 案件リリースは外部要因で変動し、目標にしづらい
• 技術的貢献（レビュー、設計改善、基盤整備）は定量化が困難

「そもそも目標を立てるときに担当する案件が決まっていない場合もありますし、その中で担当するタスクも決まっていないようなことが多々ありますので、定量的な目標を書くのが難しいということがよくあります」（嵯峨野氏）

定量的な目標にできない部分が多く残れば、各メンバーの頑張りが正当に評価されない事態も十分あり得ます。そうなれば開発者の幸福度は下がる一方です。

だから「仕組み」が必要になる、というのが嵯峨野氏の出発点でした。掲げられた条件は3つです。

• 活動を見える形にする
• 外部要因に左右されない評価軸を持つ
• 評価者にも被評価者にも指標が見える状態にする

評価と改善の関係──数字は改善の道具であって、評価の点数ではない

ここで嵯峨野氏は、評価の目的を給与査定から引き離します。

「測定できないものは改善できない（If you can’t measure it, you can’t improve it.）」

スライドで示されたのは、評価（何が良くて何が悪いかを知る）と改善（何を変えるべきかを決める）が双方向の矢印で結ばれた図でした。そこに添えられた注意点は、このセッション全体でもっとも重要な設計思想です。

• 評価はゴールではなく、改善のためのインプット
• 改善につながらない評価は、チームのやる気を奪うだけ
• 数字は改善の道具。評価の点数にしない

「測定して評価するだけだと、数字だけを追い求めてしまうということが起こりがちですので、その点は注意が必要かと思います。
計測した数字は、あくまでここを深掘りして話そうという会話のきっかけに使うべきであり、直接人事評価につなげる点数ではないということを、評価する側とされる側の双方できちんと合意形成をしてから、こういった仕組み作りに取り掛かる必要があることは強くお伝えしたいと思います」（嵯峨野氏）

大切なのは、ツールを入れる前に、指標の使い方を合意しておくことです。
このセッションで最も再現性が高い設計は、実は3つの仕組みそのものではなく、その前段に置かれたこの一手かもしれません。

取り組み内容：3つの仕組み

仕組み①：指標の可視化（Findy Team+）

横浜銀行は、エンジニア活動の可視化ツールとしてFindy Team+を導入しました。狙いは「被評価者にも評価者にも『見える』状態をつくっていく」ことです。

導入に至った経緯には、内製組織らしい判断があります。当初はメンバーが自前でGitLabのAPIを叩き、Four Keysと呼ばれる指標を計測できるようにしていました。しかし、計測した数値を評価しやすくするためにUIを作り込むのがそれなりの手間になることが見えてきます。人数が少ない中でそこに時間をかけるのは違うという判断から、ツール導入へ切り替えました。

改善につなげる観点で特に有効だと考えているのが、サイクルタイムの分解です。コーディングからレビュー開始まで何時間、レビューからマージまで何時間。これによって「レビュー待ちが長い」といった課題が、感覚ではなく数字で語れるようになりました。

そして、この仕組みを一言でまとめたスライドのメッセージがこちらです。

「見られている」ではなく「見える化で自分の成長に気づける」

仕組み②：SPACEフレームワークの導入

SPACEは、マイクロソフトの研究チームが提唱した、開発者の生産性を単一指標で測ることの危険性を示したフレームワークです。5つの観点で組織の生産性を多面的に評価します。

横浜銀行がこれに出会ったのは偶然でした。開発チームのスクラムマスターの一人がFindy Team+のサーベイ機能に気づいて試し、そこから嵯峨野氏に共有されたのが最初だといいます。

なぜ5つの観点が必要なのか。嵯峨野氏は活動量を例に説明します。

「プルリクエストを必要以上に小さな単位に分解しているだけかもしれませんし、大きな設計をじっくり考えている人は活動量が少なく見えたりもします」（嵯峨野氏）

そしてもう一つ、このフレームワークの運用で強調されたのが「定量＋定性の組み合わせが鍵」という点です。

• 定量：Findy Team+（サイクルタイム／PR活動量／レビュー時間）
• 定性：チームサーベイ／1on1／振り返り

満足度については、評価とは少し別の位置づけです。満足度が低ければいずれエンジニアは離れていく。アンケートから改善ポイントが見えることもあれば、その人が長く働いてくれるかの目安にもなります。変化を見逃さないための装置として捉えられています。

仕組み③：評価と改善の接続

3つ目は、数字を「査定」ではなく「改善のインプット」に変えていく運用です。嵯峨野氏はここが本丸だと語ります。

「1つ目と2つ目の仕組みは、ツールを入れてフレームワークを知って、やり方を決めるだけなら1ヶ月とか、そういった期間でもできるかもしれません。でも、それを日常業務に組み込んで自然に回る状態にするのが本当のチャレンジかなと考えています」（嵯峨野氏）

運用サイクルは、計測 → 振り返り → アクション設定 → 実行 → 計測（繰り返し）。これはスクラムのレトロスペクティブで使われるKPTのサイクルと同じ構造で、横浜銀行の内製開発組織ではすでに文化として定着しています。

注目すべきは、これを「仕組み」として成立させるための具体的な仕掛けです。

既存のスクラムイベントと1on1、そして目標設定という「すでにある場」に指標を差し込む。新しい会議体を作らないからこそ、忘れられずに回り続けるという設計です。

指標は見るだけでは意味がない。改善アクションに変換して初めて価値が出る

成果・学び

嵯峨野氏はBefore／Afterのスライドで、正直な現在地を示しました。

ただし、Beforeの記述にはひとつ補足が入りました。

「実際は今、幸運なことに我々の組織は非常に優秀なメンバーに恵まれていまして、メンバーの感覚もすごく優れているので、改善活動などはすごく十分にできているという印象を私は受けております。ですが、その印象も私の感覚的なものなので、なかなか裏付けを持って語れない。上司へ『ここがすごいんです』ということをしっかりと語れないような状態になっています」（嵯峨野氏）

問題はチームの実力ではなく、その実力を外に説明する手段がないことにある、という指摘です。そして、まだ実際のAfterを報告できる段階ではないと率直に前置きしたうえで、こう締めくくりました。

仕組みを整えた今、チームのポテンシャルが引き出されると確信している

1〜2年後、「仕組みがある組織」と「ない組織」で何が変わるのか

嵯峨野氏は、聴衆に問いを投げます。もし今、人事評価をしている人が異動になったら、評価基準は維持されるでしょうか。誰が来ても人事評価はブレないでしょうか。

「成功体験を別の人やチームに展開ができないということも多いかと思います。評価と改善のサイクルを作ってナレッジとして蓄積する仕組みを作らないと、その場限りの改善になってしまってすごくもったいないと考えています」（嵯峨野氏）

期待している効果として挙げられたのは、評価の納得感／離職抑制／振り返りアクション実行率の向上の3点です。そしてスライドはこう結ばれていました。

仕組みは「今の課題」だけでなく「未来の拡大」に備える投資

明日から始められる最初の一歩

セッションの締めくくりに置かれたのは、極めて小さな提案でした。

「明日から、チームの何か一つだけでも計測してみてください。サイクルタイムでも、レビューの待ち時間でも、プルリクエストの数でも何でも構いません。
計測するだけでチームの会話が変わると思います。『あれ、ここずいぶん時間かかってるね』とか『これ先月より改善してるね』とか。そういった会話が始まった瞬間が改善の一歩かなと考えます」（嵯峨野氏）

そして最終スライドには、セッション全体を貫くメッセージが置かれていました。

「評価は査定で終わらせない。改善のインプットとして機能させる仕組みをつくれば、チームは自ら伸びる。」

「正直、全てがうまくいくかどうかはまだ分かりません。でも、一つだけ確信していることがあります。仕組みがなければ、人が増えるにつれて問題が大きくなっていくだろうということです」（嵯峨野氏）

このセッションから得られる示唆

• 可視化ツールを入れる前に、指標の使い方を合意する
  • 「これは人事評価の点数ではなく、会話のきっかけである」という宣言がないまま数字を出すと、数字を追う行動が生まれます。順序を逆にした瞬間に、仕組みは副作用装置に変わります。
• 評価が難しいのは、エンジニア側の問題ではなく制度側の問題でもあります
  • 「半期ごとに定量的な業績目標」という制度と、「レビュー・設計改善・基盤整備は定量化が困難」という実態のあいだにあるギャップは、評価される側だけで抱え込むテーマではありません。
• 単一指標で判断しない
  • PR数が多いのは価値を出しているからかもしれず、PRを細かく割っているだけかもしれません。SPACEのような多面的な枠組みと、定量＋定性の併用が誤った評価を防ぎます。
• 新しい会議体を作らず、既存の場に指標を差し込む
  • スプリント振り返り、1on1、目標設定。すでに定期実行されている場に載せるからこそ、忘れられずに回り続けます。
• 仕組みは、人が変わっても残る資産になります
  • 評価者の異動でブレる評価基準は、そのままエンジニアの定着率に跳ね返ります。
• 最初の一歩は、驚くほど小さくて構いません
  • 一つの指標を測り始めるだけで、チームの会話の質が変わります。

Q&Aから：現場のリアルな問いに答える

Q. 評価する側とされる側での目線合わせが大事とのことですが、具体的にはどのようにメンバーを巻き込んで会話されましたか。

エンジニアメンバーとは心理的安全性が高く、普段から率直に会話・相談しているといいます。加えて巻き込んだのが、一次評価をする直属の上司でした。

「特に今の我々の上司はエンジニアじゃない畑から来て我々を見てくれている人なんですが、すごく理解力がありまして、『こういった課題があるので、こういうふうにやっていこうと思っている』というところをすごく素直に聞き入れてくれて、一緒に考えてくれる」（嵯峨野氏）

「ものを作るだけがエンジニアの仕事じゃないよね」という認識を上司が共有してくれていることが、組織づくりや規定整備といった活動を「必要な作業」として認めてもらえる土台になっているといいます。

Q. 実際にメンバーの目標・評価としては、どんな数字を置いているのですか。

ここで返ってきたのは、率直な現在地でした。トライアル導入と目標設定のタイミングが重なってしまい、今期はテックブログの本数、プロジェクト内のレビュー数の割合、テストの担当割合といった指標を「無理やり定量的な感じで置いた」といいます。

「ちょっと、やっぱりしっくりこない感じがずっとしていまして。今計測を始めたFindy Team+を、来期の業績目標を立てる時にうまく使えるといいなというところにチャレンジしているところになります」（嵯峨野氏）

Q. AIを活用できていること自体は、評価に入れるべきでしょうか。

嵯峨野氏は「これはあります」と即答します。生成AIをうまく使うことで、Findy Team+で見えている数字がすでに大きく変わっており、リードタイムは約4倍のスピード感になっているといいます。

「エンジニア側から『生成AIをこういうふうに活用していることで、これだけの効率向上につながっている』とアピールして、評価者の方にはぜひそういったところを評価してほしいなと考えています」（嵯峨野氏）

Q. AIでプルリクエストは量産できるようになり、評価が難しくなったと思います。このあたりはどうしていますか。

「やっぱりたくさん作っているというのは、それだけ価値を作り出しているということにつながっていますので、本当に単純にここは評価にそのまま直結するようなところになるんじゃないかなと考えています」（嵯峨野氏）

Q. 現時点で定量やROIはどのようなことが見えてきているか、可能な範囲で教えてください。

リードタイム、コミットからレビューに着手できるまでの時間、レビューにかかった時間といった指標が定量的に見えるようになっているとのこと。生成AIを使っていなかった頃と比べて指標値が劇的に良くなっており、そこをROIの説明につなげて上司や経営層にアピールできればと考えているといいます。

Q. SPACE指標を実際の人事評価に落とす際の重み付けや最終判断の仕方を教えてください。

来期の評価で直属の上司と相談しながら決めていく段階だといいます。案件の内容によって重視すべき点は変わり、メンバーがアピールしたい部分もそれぞれ違う。柔軟に評価できるやり方を模索中で、「ズバッとした回答はできない」と率直に語りました。

Q. ここで言う内製開発とは、どういったプロダクトを対象としたお話でしょうか。

横浜銀行が提供するモバイルアプリと、そこから呼ばれる周辺のWebサービス、そして行内向けのシステム。アジャイル開発に適した案件、自分たちの価値を最大限出せる案件を選んでいくために、「どういったものがそれに当たるのか」を整理している段階だといいます。

セッション②｜セブン銀行：計測は管理のためではなく、変化への適応速度を上げるため

課題・背景

セブン銀行の紙中氏のセッションは、「完成で止めず、『最適化』で育てる」という一枚から始まりました。

「アジャイル開発は完成で止めず、最適化で育てていくものだと感じておりますけれども、これは開発のプロセスの中だけじゃなくて、チームのあり方とか組織の運営にも当てはまる考え方かなと思っています」（紙中氏）

スライドに示されたのは、シンプルな4段の流れです。

• 変化が速い
• 仮説を置いて動く
• 結果を早く知る
• 素早く軌道修正する

お客さまのニーズも事業環境も変わり続け、金融サービスにおいてもアプリやデジタルチャネルへの期待、セキュリティ要求、スピードとコストへの目線がすべて変化しています。その中で、金融機関としての品質や安全性を軽視することはできません。だからこそ、不確実を受け入れ、変化を前提にした開発プロセスには計測が必要である──というのが出発点です。

ここから、計測の位置づけが定義し直されます。計測は管理や評価のためではなく、「変化への適応速度を上げるための仕組み」である、と。

10年でここまで来た、セブン銀行の内製開発

セブン銀行の内製開発は、10年をかけて段階的に領域を広げてきました。

完全外注・計画駆動からスタートし、規模を拡大しながら難易度を上げてきた。この歩みの先に必要になったのが、個人個人の頑張りを組織としての改善力に変える仕組みでした。

計測・改善の仕組みで実現したい3つのこと

内製開発を進めていると、経営やビジネス部門から「もっと早くできないのか」「なぜこれだけコストがかかるのか」「内製でやる価値は何なのか」という問いが出てきます。紙中氏はこれを「当然の問い」と受け止めたうえで、こう続けます。

「一方で開発サイドからすると、品質を保つための活動、技術的負債への対応とか障害対応ですとか、外から見えにくい努力がたくさんあります。このギャップを感覚とか定性評価だけで埋めるのはなかなか難しいので、同じ事実を見ながら会話できる共通言語が必要になります」（紙中氏）

CI/CDを整える、エラーを減らす、属人化を解消する。いずれもプロダクトの価値を支える大事な仕事ですが、成果としては見えにくい仕事でもあります。計測によって自分たちの改善活動が生んだ変化が見えると、チームは成長を実感しやすくなり、エンジニアのモチベーション向上とプロダクトへのオーナーシップ醸成につながる、という整理です。

「生産性」をコスト削減の文脈だけで語らない

このセッションで最も重要な定義の置き直しが、ここで行われます。スライドには、こう明記されていました。

生産性 ＝ 限られた開発リソースを、顧客価値・事業価値へつなげる力

「企業として開発コストとか投資対効果を厳しく見るということは当然必要なんですけれども、生産性を単なるコスト削減の文脈だけで語ってしまうと、内製開発の本来の価値を見失ってしまうかなと思っています。（中略）手戻りとか不要な調整といった見えない負荷を減らして、エンジニアの努力がより価値に届く状態を作るということが真の狙いかなと理解して、仕組みづくりを実践していきたいと考えております」（紙中氏）

現在地：何が見えていなかったのか

左側の指標はスプリント単位の振り返りには役立ち、一定期間でどれだけ作業が完了できたか、計画に対して進捗はどうだったかという観点での改善にはつながっていました。しかし右側の項目は、チームごとの感覚や個別の振り返りでは課題として上がることがあっても、組織全体としては見える状態になっていませんでした。結果として、改善が個人やチームごとの独自の取り組みにとどまりやすく、組織としての改善知見を蓄積しづらい構造になっていた、という自己分析です。

そしてスライドには、もう一つ重要な図が置かれていました。

エンジニアの努力 → 開発プロセス → プロダクト品質 → 顧客体験 → 事業価値
この流れのどこで詰まっているかを可視化したい

「エンジニアは新しい機能を作るだけではなくて、改善もありますし、問い合わせ対応もありますし、リリースの調整とか、非常に多くの仕事を日々行っていますけれども、そういった努力がどのように顧客体験とか事業価値につながっているのか。ここの繋がりが見えにくいと、努力がなかなか正しく伝わらないなと思っていまして」（紙中氏）

取り組み内容

開発プロセスの計測：Azure DevOps環境にFindy Team+を導入

セブン銀行はAzure DevOps環境でFindy Team+を一部チームに導入し、見えていない詰まりの可視化から着手しました。3ステップで整理された取り組み内容は、そのまま他社が真似できる粒度になっています。

対話の入口として、Four Keys／DORAの定量指標を参考に利用しているといいます。

「まだ分析しながらやっている最中ですので、見えた数値だけですぐに原因が決められるというわけでもないんですけれども、これまで感覚的に漂っていた課題感の可視化にはつながってきているように見えますし、そのポイントを捉えた対話を始めるとか、施策を考えるとか、そういうのが入り口、質の良いきっかけとしてはとても有効なんじゃないかなという期待があります」（紙中氏）

注目すべきは、可視化がもたらす変化の性質です。制度を変える必要がありません。

「レビューがたまりやすい対象を意識できると、その優先順位を少し変えることができますし、待ち時間が発生している箇所などをチームで話すという、大きな制度変更を要さなくてもチームが自分たちで行動を変え始められるという意味では、非常に重要な一歩になるんじゃないかなと思っています」（紙中氏）

顧客体験に踏み込む計測：狭義の生産性向上から、価値そのものの向上へ

開発プロセスの計測は、待ち時間・手戻り・属人化を減らすという意味で生産性向上に寄与します。しかし紙中氏はこれを「狭義の生産性向上」と位置づけ、その先を目指すと語ります。

「内製開発が発揮すべき価値は、単に安く作るということだけではないので、もう一段、価値創出に資する生産性向上というものを目指していく必要があるかなと思っています」（紙中氏）

アプリ画面の表示が遅い、エラーが起きている、特定の操作で離脱が多い。これらは単なるシステム障害や性能問題ではなく、顧客体験そのものに関わる問題である、という捉え直しです。

そこで直近、オブザーバビリティツール（New Relic）を導入しました。これによって、

• エラーを件数だけで見るのではなく、どの処理でどのような条件で起きているのかが具体的に分かる
• 性能を、システム内部の処理時間ではなくユーザーにとっての体感品質として捉えられる
• 離脱についても理由を具体的に特定し、新しいアプローチでの対策を考えられる

「言われたものを作る」から、「主体的にお客さま体験上の課題を見つけて、プロダクトオーナーやビジネス部門と一緒に改善していく」へ。その動きが活性化する仕組みに育てていきたい、というのが狙いです。

計測対象をつなげて、内製開発の価値を可視化する

セブン銀行の設計思想が最もよく表れているのが、この4層の連結です。

この連結によって何が可能になるのか。紙中氏は具体例を挙げます。レビュー待ちの短縮を工夫すると、改善施策のリリースが早まり、結果として利用率にポジティブな影響を与えられた。あるいは、アプリの性能問題によって離脱が増えると事業KPIにも影響する。

「そういう事業観点で開発チームが課題の重要度とか問題点を認識することができると、単なる性能改善ではなくて、顧客体験とか事業価値に直結する改善テーマとして取り組むことができるんじゃないかなと思っています」（紙中氏）

そして開発活動の層には、AI時代ならではの狙いが加わっています。

「生成AIの活用でリードタイムとかデプロイ頻度が改善したように見えても、実はレビュー負荷が増えているといった歪みが出てきていると昨今言われていますけれども、こういった歪みが出てきている状態に早く気づくという効果も狙っていきたいなと思っています」（紙中氏）

KPIも仮説であり、見直されるべきもの

もう一つ、このセッションの特徴的な視点が「KPIも検証対象である」という前提です。スライドでは、中央に「KPI設定も仮説」と置き、その周囲に4つのズレが配置されていました。

紙中氏は、KPIを見直すこと自体が運用に取り込まれていなかったために後手に回ってしまったという過去の課題も率直に挙げました。開発チームがリードタイム短縮を頑張っても、ビジネス側からはそれがどの顧客価値に効いているのか分からない。逆に、ビジネス側が見ている利用率や収益が、開発からするとどの技術的課題や体験上の課題に影響しているのか分からない。

ズレに早く気づけることが変化への適応力になる

成果・学び：改善サイクルが自走する状態とは

最後のスライドで示されたのは、5つの要素が循環する図でした。

計測 → 気づき → 対話 → 改善行動 → 価値の確認 →（計測へ戻る）
チームが自律的に行動を変え続けている

この状態が生む効果として挙げられたのが、次の3つです。

• 見えない負荷が見える
• 改善努力が見える
• 顧客価値へのつながりを実感できる

実現条件として紙中氏が挙げたのは2つ。一つは、データが自動的に集まる仕掛けです。

「手作業で集計する負荷が高すぎると、そこに不満が溜まってしまって継続が続かないとか、効果も限定的という形になるので、ダッシュボードなどでいつでも確認できるという状態を作ることも一つ大事な取り組みかなと思います」（紙中氏）

もう一つは、改善行動をチームの中に閉じないことです。プロダクトオーナー、ビジネス部門、場合によっては経営とも対話できること。こうした動きが自然に生まれる状態こそが、改善サイクルの自走だという整理です。

このセッションから得られる示唆

• 計測の目的を「管理」から「適応速度」へ置き換える
  • 結果の良し悪しを判定する装置ではなく、ズレに気づいて次の行動を早くするための装置として設計すると、現場の受け止め方が変わります。
• 生産性を「安く作る力」で定義しない
  • 「限られた開発リソースを、顧客価値・事業価値へつなげる力」と定義し直した瞬間、手戻りや不要な調整といった見えない負荷が、削減すべき対象として視界に入ってきます。
• 可視化の効果は、制度変更を待たずに現れます
  • レビューの集中が見えるだけで、チームはレビュー優先順位の見直し、放置PRの確認タイミング設定、ペアレビューといった小さな改善を自分たちで始めます。
• 速度指標の隣に、必ず歪みの指標を並べる
  • リードタイムやデプロイ頻度の改善の裏でレビュー負荷が増えていないか。AI活用が進む組織ほど、この対の設計が効きます。
• KPIを固定の正解として扱わない
  • KPIの見直しを運用に組み込んでいないと、環境変化のたびに後手に回ります。
• 開発から事業価値までを1本につなげて初めて、開発の努力は伝わります
  • 4層のどこかが切れていると、「頑張っている」は最後まで感覚論のまま終わります。

Q&Aから

Q. 「これは価値がありそうだ」「これは価値が低そうだ」といった意思決定や優先順位付けはどのようにしていますか。当社では企画サイドが持ってきたものをとりあえず作るという状態に陥りがちです。

紙中氏は「案件単位では近しいところがある」と正直に認めたうえで、介入するポイントを示しました。

「その実現の仕方も、真の狙いとして──それは画面デザインかもしれないですし、機能の配置の仕方かもしれないんですけれども──それを実現する仕方について、どんどん口出しをしていくとか、提案していくとか、その場合のお金のかけ方の優先順位みたいなところには入り込んでやっていくといったことはしていたりはしますね」（紙中氏）

企画は企画サイドが持ちつつ、設計には積極的に入っていく。分断を埋める現実的な入り口です。

Q. AIの影響でレビュー放置やレビュー集中がより顕著になっています。セブン銀行様でも同様でしょうか。

内製開発においてはAIをコーディングの補助ツールとして使っている段階で、AI駆動開発は「今年中になんとか1つのプロダクトでうまくいかせて、来年拡大させたい」というフェーズ。そのため顕著な現象はまだ観測していないものの、情報を集めて何が起こり得るかを事前に取り込んでいきたいといいます。

AIとは無関係のレビュー集中への対策としては、Findy Team+で集中が見えることを起点に、「どういうものだったら他の人ができるのか」という分散と、レビュー内容の明確化を少しずつ進めているとのことでした。

Q. 共通言語としてうまく使えている指標はありますか。

汎用的な答えはまだ見つけられていないと前置きしたうえで、2つの実感が語られました。

「ビジネスと一緒にROIを見ていこうという、その取り組み自体を一緒にやっていくといったところは、開発からの景色を変える取り組みの一つになっているかなというふうに思いますし」（紙中氏）

もう一つが、リソースの弾力性の可視化です。

「エンジニアの方がどれぐらい弾力的にプロダクトにリソースされているかみたいなところを見せていくというのも割と、外注ではなかなか固定化されているところが、内製だとこれぐらい柔軟に動けるんだなといったところを見ることができたといったところの反応も良かった」（紙中氏）

ROIについては、コストサイドとトップラインの両方を同時に考え、リターンの計画精度を上げていくことが重要だといいます。

Q. 計測から改善のサイクルは、どのような期間で実施されていますか。

何を測るかによるとしたうえで、一番小さい開発現場では2週間スプリントの中で回しているとのこと。ダッシュボードを毎日経営と一緒に見るところまでは仕組みとして育てきれていないものの、それができれば違うタームでの改善サイクルも見つけられるだろう、と展望が語られました。「2週間に一度ずつくらい、ここを改善しようねという会話が少しずつ生まれてきている」段階だといいます。

セッション③｜みずほフィナンシャルグループ：AIを入れただけでは、金融の開発は速くならない

課題・背景

3人目の登壇者、みずほフィナンシャルグループ（以下、みずほFG）の齋藤氏は、冒頭で自らのセッションの位置づけを明確にしました。

「先ほどまでのお二方の話がヒューマン的な仕組みだとしたら、我々が今回お話しするのは少しシステマチックな仕組みについてお話しさせていただきたいなと思っております」（齋藤氏）

齋藤氏は銀行業務とシステム開発の両方を経験してきた人物です。2012年より国内金融機関にて融資審査・途上管理、現金輸送ロジスティクス、ATM出店計画策定等に従事。2017年より国内ネット系銀行で預金プロダクト担当として事業計画策定やターゲティング分析を手がけ、事務企画担当として当局対応、次世代システム更改の要件定義、銀行アプリのUI/UX改善などを経て、内製アジャイル開発チームの開発リーダーとして法人口座開設オンライン化プロジェクトを完遂。2023年9月より現職で、内製アジャイル開発組織の運営およびAIエージェント基盤構築、みずほLLM構築に係る開発責任者を務めています。

組織構造も特徴的です。みずほフィナンシャルグループでは、グループCDTOの下にDX機能を集約し、グループ会社も含めて一体でDXを推進する体制を取っています。齋藤氏が所属するデジタル戦略部は「CoE＋プロジェクト推進」を担い、企画チーム、プロジェクト推進第一〜第三チーム、テクノロジー第一・第二チーム、業務チームで構成されます。ビジネスサイドとテックサイドが同じ部に同居している点が、後述する「内製開発ラボ」の前提になっています。

本題：「（金融では）AIを入れただけでは開発は速くならない」

スライドいっぱいに、こう書かれていました。

（金融では）AIを入れただけでは開発は速くならない
なぜなら・・・

「昨今、いろんなネット上とかでも『とにかくAIコーディングだ』『Claude Codeだ』『Codexだ』『Devinだ』みたいな、とにかくコーディングにすべてのAIのケイパビリティを突っ込んで、あっという間に早くなりましたみたいな話をしているんですけれど、ある面ではそれは正しいと思います。ただ、金融という面ではそれだけでは済まないというのが我々の今持っている結論かなと思っています」（齋藤氏）

その答えが、次のスライドで示されます。コーディングだけAIにやらせても、人間に起因する課題が山積しているから。齋藤氏が挙げた3つの課題と、それぞれで実際に起きることは次の通りです。

これらに対するみずほFGの取り組みは、共通化・統制・再利用・安全な高速化という4つのキーワードで整理されています。目指すのは一言、「事故を防ぎながら、開発を速くする」ことです。

課題①：アプリごとの統制実装が、開発を重くする

業務ごとに開発が進むほど、金融ならではのセキュリティ／ガバナンスを毎回作る負荷が増えていきます。スライドでは、実際のプロダクト3つを並べて構造が示されました。

それぞれ気をつけるべきポイントは違いますが、共通するものもある。にもかかわらず個別に実装すると、統制の設計・審査・実装・テストがユースケースごとに重複することになります。

「それを一つ一つ金融の統制を作ってしまうと、一回一回テストも必要ですし、また審査というものも必要になってくるというところなので、これらを一緒くたにしたもの、共通の統制基盤というものを作りました」（齋藤氏）

仕組み1：AIエージェント統合開発プラットフォーム「みずほWiz Base」

解は明快です。統制を共通機能として開発基盤側に組み込む。個別対応から、共通基盤での統制へ。

「みずほWiz Base」はAWSをベースとしたAIエージェント統合開発プラットフォームで、生成AIアプリケーション／AIエージェントの開発時に各共通機能を利用できます。提供機能は6領域に整理されています。

Phase1は2025年12月に完成し、NW共通・開発管理の一部・運用共通が先行して稼働しています。ここに、この取り組みの進め方のポイントがあります。

「網羅的に、今後できるものも含めて結構網羅的に構想を練って、それでできるところから着手していったというのがポイントになっております。やはり一番重要な面としては、下のクラウドインフラ、ネットワーク共通とか運用管理の共通とか、こういったものが全ての土台になってきたりしますので、ここら辺から作っていった」（齋藤氏）

実際のアーキテクチャでは、共通部品・Gateway・開発基盤によってAIエージェントを素早く組み上げられるアジリティを確保しつつ、認証認可・監視・LLMOps・Firewallを基盤側に組み込み、金融機関に求められるセキュリティ／ガバナンスを担保する構造になっています。ガバナンス、LLMOps、LLM Firewall、AIセキュリティ診断といった機能が「AIセキュリティ／AIガバナンス共通管理機能」として一段にまとめられている点が象徴的です。

構想は網羅的に、実装は土台から順に。全体像を描かずに個別対応を積み上げても統制基盤にはならず、かといって全部を一度に作ることもできません。その中間を通す実務的な進め方です。

課題②：統制は担保できても、現場ごとの個別開発では量産できない

ベースラインの統制をかけた後、次の壁が現れます。要件・AIリテラシー・アーキテクチャが揃わないまま現場ごとに作ると、都度ゼロから立ち上げる負荷が増えるという問題です。

みずほRM Studio、めんきくん、スライド生成。それぞれが専任チームを個別に編成し、要件定義・基盤構築・運用改善を都度繰り返す。立ち上げ・基盤構築・運用がチームごとに重複し、量産できない状態です。

「我々が今作っているのはAIエージェントです。AIエージェントは人間の動きの代替みたいな感じで、かなり初期に早く作り込んで、それを改善して回していくことが必要であったりとか、複数のエージェントが協働するとなったときに、一つ一つのエージェントにそんなに時間をかけるわけにもいかない。共通の型があるので、毎回同じようなことをやっていてもしょうがないよね、というのが課題感としてありました」（齋藤氏）

仕組み2：エージェント量産工場「エージェントファクトリー」

解決の方向は、ヒトとモノを一体でそろえて量産することでした。「ノーコード」＋「コード開発」でエージェントを量産し、管理／運用するためのプラットフォームが「エージェントファクトリー」です。

構造は3層で整理されています。

そして、これら全体を貫く統制として策定されているのがAIOA（エージェント開発における全社ルール策定）です。アーキテクチャ標準と開発・管理ガイドラインという2つの統制文書からなり、社員であれエンジニアであれ、基本的にこれを守りながら開発する形を取っています。

エージェント開発基盤の構成要素は多岐にわたります。ローコード基盤（Dify）、エージェント向け短期記憶／長期記憶（AgentCore Memory）、エージェントオーケストレーション（マルチエージェントツールキット）、CI/CD（GitHub Enterprise）、AI Evaluation／AIデータ基盤（Databricks）、ソリューションカタログ＆マルチテナントデプロイ（Enterprise Hub）、セキュリティ診断（SAST、LLM脆弱性診断）、Observability（New Relic／Datadog）、共通LLMゲートウェイ／LLM通信監視／LLMガードレール、ダッシュボード（CloudWatch）、MCPゲートウェイ／A2Aゲートウェイ、エージェントMCP／ツールホスティング（AgentCore Runtime）。

加えて、共通テンプレートとして汎用Agent・Agentワークフロー・特定業務向けエージェント・オーケストレーターのサンプルコード、Evaluation／メモリ・記憶管理／ユーザーFB収集／監査ログ／CI・CD／Runtimeの各IaCテンプレートが提供され、開発・運用支援としてAIアーキテクチャーレビュー、Agentコードレビュー、開発ガイド、運用ガイド（監視・運用管理、コスト管理）が揃えられています。

AIエージェント階層モデル：「何でもエージェント」を避けるための設計

「AIエージェントって、そのまんま置いておくと、何でもAIエージェントって呼べるっちゃ呼べますので、そうじゃなくて、やっぱり人間の業務の代替であるからには、人間の業務というものはおそらくこういった形に分解できるのであろうということで、階層モデルというものを作っています」（齋藤氏）

AIエージェントを階層に分解して標準化し、コンポーネントとして設計することで、用途横断で再利用できるため、量産・全社展開が可能になります。さらに開発・運用の効率化と全体像の把握を目的に、CUG／業務グループ単位で階層別の「エージェントマップ」を整備しているといいます。

期待される効果：開発期間を最大70%短縮

エージェントごとに開発者がゼロから実装していた状態から、標準テンプレートを活用してビジネスロジックの開発に専念できる状態へ。この転換によって期待される効果として、スライドには4点が挙げられていました。

• スピード：開発期間を最大70%短縮
• 品質：設計・テスト・評価の標準化
• セキュリティ／ガバナンス：ポリシー一貫適用・監査性
• 継続的量産・改善

課題③：基盤を整えても、ビジネスとテックで要件がかみ合わない

3つ目の課題は、極めて人間的なものです。立場も評価軸も異なるまま要件を詰めると、仕様が固まらず開発に入れません。

結果として要件がかみ合わず、手戻り・仕様変更で開発が停滞する。齋藤氏は、AI開発ならではの期待値のズレも指摘します。

「『AIは何でもできるんだ』みたいなのとか、もしくはエンジニア目線で言ったら『AIを制御しづらい』というふうに思ったりするかもしれない。こういった両者のコンフリクトみたいなのは当然に起こってきます。現実に結構起こったりもしています」（齋藤氏）

仕組み3：ビジネスニーズとAI駆動を連動させる「内製開発ラボ」

対立から、一体の内製開発体制へ。ビジネスと技術を同じチームで回すという解決策が「内製開発ラボ」です。

体制はこう組まれています。ビジネスニーズ起点のPO・案件組成チームがPoCを企画し、技術起点のDevチーム・R&Dチームと連携して開発依頼を出す。それを受けるのが内製開発ラボです。

• エンジニア約60名が所属し、15のスクラムチームに編成（1チームあたり約3〜4名）
• 各チームがAIプロダクトを継続的に開発・改善し、合計50プロダクトを開発・提供
• スプリントプランニング → デイリースクラム → 開発・実装 → レビュー → ふりかえり という短いサイクルで学習し、継続的に価値を提供

技術スタックもモダンです。フロントエンドはReact／Next.js、バックエンドはFastAPI、AIエージェントフレームワークはAWS Strands AgentsやOpenAI Agents SDK、データ・インフラはAWS／Amazon Bedrock／Aurora RDS／S3・Data Lake／CloudWatch。開発生産性と品質を最大化する取り組みとして、CI/CD、テスト自動化、コード品質（静的解析・レビュー）、観測性、ナレッジ共有、ユーザー中心の設計が並びます。

さらに齋藤氏は、資料には載っていない工夫として、オフィスの設計にも触れました。

「オフィスを最近移転してきまして、大手町にあるんですけれども、そこでエンジニアとビジネスサイドがすごく近くなるようなオフィスの設計みたいなのを行っていまして、気軽に話をお互いできるような、そんな仕組みとかも整えているような感じになります」（齋藤氏）

デジタル戦略部の7職種：企画・推進・実装・統制が一体になる

この体制を成立させているのが、職種の網羅性です。企画・推進・実装・統制が一体となり、生成AI／AIエージェントを「PoC→本番→継続改善」まで内製で実施しています。

目指しているのは、従業員35,000名超の現場に展開されるプロダクトを、金融要件（安全性・監査性・権限管理等）を満たしながら作り込み、使われ続ける状態まで育てることです。

成果・学び：3つの仕組みから生まれたプロダクト群

齋藤氏は、スライドを1枚めくってこう問いかけました。「本当にうまくいってるの？」。そして次のスライドのタイトルが、率直な答えになっていました。「（課題もあるが、がんばってます）〈みずほ〉のAIアプリケーション事例」。

内製開発したハーネスにより、ガバナンスに準拠しつつ、アジリティ高くPoC・本番環境のアプリケーションを開発しているといいます。業務プロセスをE2Eで捉え、AI前提でのプロセスの再設計として開発されたものばかりです。

このうち4つが、詳細とともに紹介されました。

① 営業支援AI「みずほRM Studio」

法人営業担当者（RM＝リレーションシップマネジメント）向けに、インサイト創出・提案資料作成・面談後のレビューを一体化したAIアプリケーションです。ニュース、リサーチレポート、業界／市場インテリジェンスといった外部データと、CRM・顧客の財務データ・社内ナレッジベースといった内部データを統合し、顧客理解 → 仮説の構築 → ソリューション設計 → 提案作成という営業プロセスを支援します。

数字が明快です。

• 事前準備時間：約50%短縮
• 顧客との対話時間：約3倍に増加
• FY26で約3,500名の法人RMへ展開予定

準備時間が半減し、その分が顧客との対話時間に3倍となって返ってくる。AI活用の効果を「時間の削減」ではなく「時間の再配分」として示している点が示唆的です。

②リテール顧客向け対話型AIアシスタント「あおまるバンク」

お客さまのリクエストを適切な専門エージェントに振り分け、迅速かつ一貫性のあるサポートを提供するマルチエージェントアシスタントです。2026年9月より提供開始予定で、4つのエージェントが役割を分担します。

これにより問い合わせを迅速に解決し、電話や店舗来店の必要性が減少することを目指しています。前述のAIエージェント階層モデルが、実際のプロダクトとしてどう具現化されるかを示す好例と言えます。

③ 面談記録・議事録作成支援「めんきくん」

生成AIを使い、オンライン／対面ミーティングの面談記録ドラフトを作成するiOS/Webアプリケーションです。iPhone／iPadアプリから音声データを自動アップロードし、Amazon Transcribeでテキスト化・話者分離・辞書変換を行い、Amazon Bedrockで指定テンプレートに変換して面談記録のドラフトを出力します。サーバーレス構成です。

出力されるのは、会議の概要、主要議題と内容、決定事項、残課題、重要な指摘事項、Next Action。プロンプトの変更で出力内容を柔軟に変更できます。

• 一人当たり月間削減効果：4時間以上
• 議事録作成時間削減率：70%以上を実現

「いろんな議事録作成AIみたいなのが最近出てきてはいるんですけれども、〈みずほ〉の議事録に適した出力になるようプロンプトチューニングしているので、割と手直しせずに使えるというのが特徴になっています」（齋藤氏）

④ スライド生成支援「みずほスライドジェネレーター」

作成したいスライド内容を自然言語で指示すると、AIが構成を検討し、社内様式を反映したスライドを数分で自動生成します。大量のドキュメントや複雑なデータも、理解しやすい図表にAIが自動で変換。サーバレス構成アプリケーションで、Amazon Bedrock・Claude 4.5を利用しています。

• スライド作成にかかる時間を最大70%削減

そして注目すべきは、プロダクト同士の連結です。

「先ほどあった面談記録のAIで出てきた議事録をこのスライドジェネレーターに入れると、会議議事録があっという間にパワポでできますというのが、かなり社員の中で受けているような感じになります」（齋藤氏）

標準化された基盤の上でプロダクトを量産すると、プロダクト同士がつながって新しい価値が生まれます。エージェントファクトリーの効果が最も分かりやすく表れた事例です。

このセッションから得られる示唆

• 統制は、アプリごとに実装すると開発を重くします
  • 設計・審査・実装・テストがユースケースごとに重複するコストは想像以上に大きく、共通基盤に先出しすることで、統制はアジリティの敵ではなく前提条件に変わります。
• 構想は網羅的に、実装は土台から
  • 全体像を描かずに個別対応を積み上げても基盤にはならず、一度に全部を作ることもできません。Phase分割で土台から着手する進め方が現実解です。
• 「何でもAIエージェント」を避けるために、階層で構造化する
  • 人間の業務が分解できるなら、エージェントも分解できます。LV0〜LV3という抽象化が、用途横断の再利用と量産・全社展開の前提になります。
• AI活用の効果は「削減」ではなく「再配分」で語ると伝わります
  • RM Studioの「事前準備時間を約50%短縮し、顧客との対話時間を約3倍に」という示し方は、コスト削減の文脈を超えて事業価値に接続しています。
• ビジネスとテックの分断は、所属と座席で解けるかもしれません
  • 7職種が同じ部に集まり、同じスクラムチームを組み、近い座席で働く。どんなプロセス改善よりも直接的な設計です。
• 標準化された基盤の上では、プロダクト同士が連結して新しい価値を生みます
  • めんきくんの議事録をみずほスライドジェネレーターに流し込む。個別開発では生まれにくい効果です。

Q&Aから

Q. みずほWiz Baseのような共通基盤を導入する際、現場が使わないことを防ぐために、どのような仕組みやルールを設けているのでしょうか。

齋藤氏は「これは我々がかなり気にしたところ」と応じました。

「結論としては、AI開発をするといったものについては、Wiz Base上で開発しましょうよ、というか、しないとほぼダメだよねみたいな空気感とルール感を醸成することによって、ある種の強制性ですね。強制的に使うみたいなものを、完全に明文化するわけではないんですけれども、そういったルールを設けているような感じになります」（齋藤氏）

共通基盤は「作る」より「使われる」が難しい。完全な明文化ではない「空気感とルール感」という表現は、大企業で基盤を普及させた経験のある読者ほど頷ける実感でしょう。

作ったエージェントを使ってもらう工夫としては、社内の広報チームによるプロモートに加え、プロダクトオーナー起点の展開が挙げられました。プロダクトオーナーが「使いたい」というニーズをもとにAIエージェントを作ってもらうため、そのプロダクトオーナーが自部署の人に使ってもらい、そこから横展開していきます。プロダクトオーナーが展開まで責任を持つケースが非常に多いといいます。

Q. トークンのコストを抑える取り組みを実施しているようであれば教えてください。

「トークンコストは今、非常に問題になっていますので、いろんな手段を使っていますというところなんですけど、ポイントは、いかに品質を落とさずにコストを抑制するかということです」（齋藤氏）

具体的には、コンパクション（圧縮）の標準機構をオンにすること。そして、新しいモデルの情報をいち早くキャッチしてPoCのプロダクトに投入し、実際に効果を見る。ダメだったら元に戻し、うまくいったら続ける。この活動を繰り返してコストを抑制しているといいます。全プロダクトではなく、いくつかのプロダクトでこうした取り組みが走っている段階とのことでした。

Q. AI駆動開発について、各工程どの程度自動化されているでしょうか。

このセッションで最もインパクトのある回答が返ってきました。

「将来的には、ちょっと過激かもしれないですけど、すべての工程をAIによる自動化をしたいと思っています。今は少なくともコーディングと単体テスト、これは完全に自動化をされていて、少し挑戦的に『手でコードをなるべく書かないでください』というようなことをエンジニアたちにはお伝えをしています」（齋藤氏）

そして次の展開についても明確です。

「ここからプルリクエストのレビューだとか設計だとかというところにどんどん染み出していきたい。そのためには、やはりハーネスが重要なので、ハーネスの整備・開発というものを同時に進めているような感じになります」（齋藤氏）

3社の視点が交わった論点

3セッションと各Q&Aを並べると、アプローチの違いと、それでも一致している点がくっきりと見えてきます。

論点1：AIは、何を増幅させたのか

3社とも、AIによって「速くなった」ことは認めています。横浜銀行ではリードタイムが約4倍のスピード感に。みずほFGではコーディングと単体テストが完全自動化され、エージェント量産では開発期間を最大70%短縮する見込みが示されました。

しかし、その裏側への注目が共通しています。

速くなったこと自体は、もはや成果の証明になりません。速度指標の隣に何を置くかが、3社に共通する設計課題として浮かび上がりました。

論点2：測ることは、誰のためか

ここに3社の立場の違いが最もよく表れます。

• 横浜銀行は、測ることをエンジニア自身のために置きました。「監視」ではなく「自己成長の道具」であり、計測値は人事評価の点数ではなく会話のきっかけである、という位置づけです
• セブン銀行は、測ることを経営・ビジネスとの対話のために置きました。外から見えにくい努力と、経営からの当然の問いのギャップを埋める共通言語をつくる、という設計です
• みずほFGは、測ることを統制とコスト制御のために置きました。監視・LLMOps・コスト管理を基盤側に組み込み、あらかじめエンジニアや社員に渡す仕組みにしています

立場は違いますが、3社とも「測って裁く」のではなく「測って動かす」という点では一致しています。

論点3：ビジネスとテックの分断を、どう埋めるか

この論点への3社の答えは、それぞれ異なる打ち手でありながら、方向は同じです。

• セブン銀行：企画は企画サイドが持つとしても、設計には積極的に入り込む。画面デザイン、機能の配置、お金のかけ方の優先順位まで提案する
• みずほFG：同じ部署、同じスクラムチーム、近い座席に置く。すべての職種が全員そろった内製開発ラボ
• 横浜銀行：評価する側の上司を巻き込んで一緒に考える。「ものを作るだけがエンジニアの仕事じゃないよね」という認識の共有

会議体を増やすのではなく、関与のポイントそのものを前に倒すか、物理的な距離を縮めるか。3社ともそこに手を打っています。

共通して見えたこと

3社が示したのは、開発プロセスの改善だけでは成果に到達しないという認識でした。

評価制度の設計、経営との共通言語、システムの統制、職種の配置、オフィスのレイアウト。3社が実際に手を入れているのは、いずれもアジャイル開発のプラクティスそのものではなく、その外側にある構造です。この一点で、規模も事業も異なる3社が一致していました。

イベント全体のまとめ

3社が語った内容を、改めて一文ずつ振り返ります。
株式会社横浜銀行の嵯峨野憲作氏は、エンジニアでない上司がエンジニアを評価するという構造的な難しさに、評価と改善をつなぐ仕組みで挑む取り組みを語りました。
続く株式会社セブン銀行の紙中加代子氏は、計測を「管理のため」ではなく「変化への適応速度を上げるための仕組み」として位置づけ直し、開発活動から事業価値までを1本につなげる設計を提示しました。
そして株式会社みずほフィナンシャルグループの齋藤悠士氏は、「（金融では）AIを入れただけでは開発は速くならない」と言い切り、統制基盤・エージェント量産・組織体制という3つのシステマチックな仕組みを公開しました。

共通課題

「AI活用は進んでいるのに、開発組織の課題が解けない」という現象の背後には、共通した構造があります。

• 開発の内側が、外から見えない
  • 横浜銀行は非エンジニアの評価者に、セブン銀行は経営・ビジネス部門に、みずほFGはビジネスサイドに対して、開発の実態が観測可能な形になっていない
• 個人技が組織知にならない
  • 「成功体験を別の人やチームに展開できない」（横浜銀行）／「改善が個人・チームごとの独自の取り組みにとどまる」（セブン銀行）／「毎回いちから車輪の再発明」（みずほFG）
• 内製組織が拡大フェーズにあり、拡大に耐える土台がない
  • 横浜銀行は4名→12名→18名、セブン銀行は完全外注から10年かけて拡大期へ、みずほFGは内製開発ラボにエンジニア約60名・15スクラムチーム・50プロダクト
• 金融特有の制約を落とさずに速度を上げる必要がある
  • 品質・安全性・統制は交渉の余地がなく、他業界のプラクティスをそのまま持ち込めない
• AIが「速くなった」ように見せる裏で、歪みが生まれる
  • レビュー負荷の増加、レビュー集中、活動量指標の意味の変質、トークンコスト、プロンプトインジェクション

各社のアプローチの違い

横浜銀行が「納得を作る」アプローチ、セブン銀行が「つながりを見せる」アプローチであるのに対し、みずほFGは「型を作る」アプローチだと言えます。
そして3社は対立せず、補完関係にあります。型がなければ量産できず、つながりが見えなければ何を作るべきか決められず、納得がなければ人が残らないからです。

成功要因

• 測る目的を「評価」ではなく「対話と改善」に置いている
• 新しい会議体を作らず、既存の場（スプリント振り返り・1on1・目標設定）に仕組みを差し込んでいる
• 仕組みを人に依存させず、引き継げる形にしている
• ビジネス・経営と同じテーブルに載る言語を作ろうとしている
• 拡大する前に土台を作り、それを「未来の拡大に備える投資」として位置づけている
• 「まだ途中である」ことを率直に開示し、期待値を操作していない

今後重要になるテーマ

読者へのメッセージ

このイベントで語られたことの多くは、目新しい技術の話ではありませんでした。「エンジニアの活動は測れているか」「その努力は事業価値までつながっているか」「統制は開発を重くしていないか」──いずれも、良い開発組織が向き合ってきたテーマです。ただ、AI時代においては、それらの整備状況が成果の差として増幅されて表れるようになりました。

だからこそ、明日から着手できることがあります。何か一つの指標を測り始める。速度指標の隣に手戻り率を並べてみる。統制の実装がプロジェクトごとに重複していないか棚卸ししてみる。ビジネス側の担当者と同じ会議ではなく、同じチームに入れないか検討してみる。

3社の登壇者が揃って「まだ途中です」「答えを持っていません」「課題もありますが、がんばっています」と率直に語ったことは、印象的でした。完成形を持っている組織は、まだありません。だからこそ、走りながら整えていくしかないのです。

この記事の要点

1. AI導入は前提になりました。問われているのは、その外側の仕組みです。
   • みずほFGの齋藤氏は「（金融では）AIを入れただけでは開発は速くならない」と言い切り、その理由を「コーディングだけAIにやらせても、人間に起因する課題が山積しているから」と説明しています。目指すのは「事故を防ぎながら、開発を速くする」ことです。
2. エンジニアでない上司がエンジニアを評価するという構造は、金融・非IT大企業に固有かつ切実な課題です。
   • 横浜銀行では半期ごとに定量的な業績目標が必要ですが、案件リリースは外部要因で変動し、レビュー・設計改善・基盤整備といった技術的貢献は定量化が困難です。
3. 数字は改善の道具であり、評価の点数ではありません。
   • 「改善につながらない評価は、チームのやる気を奪うだけ」。この合意形成を先に置かないと、数字だけを追う行動が生まれます。横浜銀行が掲げたのは「『見られている』ではなく『見える化で自分の成長に気づける』」という位置づけでした。
4. 新しい会議体を作らず、既存の場に指標を差し込みます。
   • スプリント振り返り・1on1・目標設定という定期実行される場に載せるからこそ、属人化せず、忘れられずに回り続けます。
5. 生産性を「安く作る力」で定義しないことも大切です。
   • セブン銀行は「限られた開発リソースを、顧客価値・事業価値へつなげる力」と定義し直し、手戻りや不要な調整という見えない負荷を削減対象に据えました。
6. 可視化の効果は、制度変更を待たずに現れます。
   • セブン銀行はAzure DevOps環境にFindy Team+を導入し、PRレビューの集中や放置作業が見えたことで、レビュー優先順位の見直し・放置PRの確認タイミング作成・ペアレビューという小さな改善がチーム発で始まりました。
7. KPIそのものが仮説です。
   • 計測は計画と実績のズレだけでなく、チームの認識と実態のズレ、開発活動と顧客価値のズレ、事業KPIと現場実態のズレに気づくための装置。ズレに早く気づけることが変化への適応力になります。
8. 統制は共通基盤に先出しすると、アジリティの前提条件に変わります。
   • アプリごとに実装すれば設計・審査・実装・テストが重複します。みずほFGはAWSベースの「みずほWiz Base」（Phase1は2025年12月）に集約し、構想は網羅的に、実装は土台から進めました。
9. AIエージェントは階層で構造化すると量産できます。
   • LV0オーケストレーター／LV1業務ドメイン統括／LV2業務エキスパート／LV3サブタスクモジュールに分解して標準化することで用途横断の再利用が可能になり、標準テンプレートによって開発期間を最大70%短縮する効果が見込まれています。
10. AI活用の効果は「削減」ではなく「再配分」で語ると伝わります。
    • 〈みずほ〉の営業支援AI「RM Studio」は事前準備時間を約50%短縮し、顧客との対話時間を約3倍に増やしました。FY26で約3,500名の法人RMへ展開予定です。
11. ビジネスとテックの分断は、所属と座席で解けるかもしれません。
    • みずほFGの内製開発ラボはエンジニア約60名・15スクラムチームで50プロダクトを開発し、7職種が同じ部に所属しています。コーディングと単体テストはすでに完全自動化され、次はレビューと設計へ。そのためのハーネス整備が進行中です。

次回イベントのご案内

Findy Team+では、開発資本・AI駆動開発・開発組織マネジメントをテーマにしたイベントを継続的に開催しています。
最新の開催情報は下記からご確認ください。

• イベント一覧：https://jp.findy-team.io/events/
• Findy Team+ サービス紹介資料：https://jp.findy-team.io/download/service-document/