アジャイルを導入したものの、プロセスをなぞるだけで成果が出ない。気付けば「アジャイルをやること」自体が目的になり、形骸化してしまう。こうした悩みを抱えている開発組織は少なくない。

アジャイルが文化として根付き、長期にわたって機能し続ける組織と、そうでない組織の違いはどこにあるのか。その答えのヒントが、三菱UFJインフォメーションテクノロジー株式会社（以下、MUIT）のリテールチャネル部の歩みにある。

同部では2018年頃から現在に至るまで、銀行の諸届手続きをスマホアプリで提供する『かんたん手続アプリ』、BtoBtoC型サービス『＆BANK』、銀行・信託・MUITの三者共創による新規ビジネスなど、さまざまなプロジェクトでアジャイル開発を実践してきた。

ウォーターフォールが前提の厳格な開発手続き、外部パートナーとの協業、大規模かつ組織横断のプロジェクト……。決してアジャイル導入に適した環境とはいえない中で、なぜ同部の取り組みは形骸化せず、文化として育ってきたのか。

アジャイル導入を牽引してきた上田純昭さん、久保埜 恵さん、三木崇史さんの三名に話を聞いた。

三菱UFJインフォメーションテクノロジー株式会社
リテールチャネル部　※2025年12月取材時点
上田純昭さん

2005年入社。法人向けチャネルシステム、ダイレクトバンキングの開発を手掛けた後、18年より『かんたん手続アプリ』を担当し、銀行の非対面チャネルを支えるシステムの保守・開発に携わる。リテールチャネル部におけるアジャイル開発の初期フェーズを経験し、同部のアジャイル文化の土台づくりに関わってきた

三菱UFJインフォメーションテクノロジー株式会社
リテールチャネル部　※2025年12月取材時点
久保埜 恵さん

2004年入社。証券決済システムの内製開発を担当し、2児の出産・育休を経て、口座開設アプリの開発に従事。現在は、外部のパートナー企業と協業し、新たな顧客サービスを提供する『& BANK』アプリの開発プロジェクトにて、チームを支えるスクラムマスターを担当。アジャイルを前提とした高速な改善サイクルやAWSコンテナを活用したクラウドネイティブな開発を推進中。MUFG/MUITでワンチームとなったアジャイル開発の実践を担っている

三菱UFJインフォメーションテクノロジー株式会社
リテールチャネル部　※2025年12月取材時点
三木崇史さん

2005年入社。旧UFJ銀行と旧東京三菱銀行の合併に伴う行内振込システムの新規構築、電子記録債権システム新規構築、電手システム統合案件などの内製開発を担当。営業店システム更改案件のリーダーを経て、『& BANK』アプリ開発のマネジャーを務める。現在は、銀行・信託・MUITが連携する大規模な取り組みの中で、SAFe（Scaled Agile Framework）を用いた組織横断アジャイルの推進に関わる

既存ルールへの歩み寄りが、アジャイルへの信頼を生む

ーーリテールチャネル部におけるアジャイル導入は、「諸届手続き」のアプリ化から始まったと伺っています。当初、どのような課題があったのでしょうか？

上田：2018年当時、銀行の諸届手続きは、住所や電話番号変更など一部を除いて窓口や電話で行う必要がありました。特にキャッシュカードの再発行は受付件数が非常に多く、お客さまにとっては来店や電話で時間を取られる不便さがあり、1件あたり30分程度かかる窓口対応に追われていました。

この状況を改善できれば、単なる業務効率化にとどまらず、銀行全体としてより戦略的な業務に人的リソースを投入できます。そこで、これまで非対面では行えなかった諸届手続きをWeb上で行える『かんたん手続アプリ』の開発が立ち上がりました。

スマホアプリによる諸届手続きはターゲットとなる顧客層が広く、リリース後にどれだけ利用されるか、どのような機能が求められるかを予測しづらい。最初から完璧な仕様を決めて作るよりも、反応を見ながら機能を拡張していく必要があると考え、アジャイルの導入を決めました。

ーー当時の銀行システム開発は、ウォーターフォールがスタンダードですよね。アジャイル導入は、一筋縄ではいかなかったのでは？

上田：仰るとおりで、開発に着手するには、事前に「施策内容（要件）が確定していること」と「費用の見積もりが完了していること」が必須条件になります。

本来であれば、アジャイルを導入するタイミングでルールを変えるのが理想です。ただ、開発スケジュールやリリースの問題などから、既存のウォーターフォールベースの手続きを遵守せざるを得ませんでした。そのため「既存のルールを遵守したうえで、運用の工夫でアジャイルを成立させる」方針を取りました。

具体的には、稟議上はウォーターフォールに近い粒度で見積もりを作ってチームの人数と期間を確定させたうえで、開発過程での要件変化を考慮したバッファ期間を設けています。

バックログの優先度に応じて無制限に変更できるわけではありませんが、決められた予算と期間の枠内であれば、最大限柔軟に開発のスコープ調整を行えます。

ーーでは、ウォーターフォールで開発されているメインフレームとの連携はどうでしょうか。スピード感のギャップが出てくるかと思いますが……。

上田：前提として、大規模なホスト側（勘定系システム）のスケジュールは簡単には動かせません。そのため、アジャイルの理屈を押し付けない配慮を徹底しています。アジャイルは仕様変更に強いのが特徴ですが、設計完了後の見直しといった「ホスト側で手戻りになるような仕様変更は原則NG」としました。

また、スクラムは2週間を1スプリントとして回していますが、ホスト側の仕様確認には一定の期間が必要です。そこでスプリント内の回答を急かすのではなく、時間がかかりそうな場合はそのストーリーを次のスプリントに回すなど、アジャイル側がスケジュールを柔軟に調整しています。

一方で、ホスト側の担当者に私たちの進め方を理解してもらうため、プランニングやレビュー、時にはデイリースクラムにも参加してもらいました。アジャイルの「柔軟さ」を「無秩序」と誤解されないように、こちら側の計画や優先度の考え方を共有し、互いに気持ちよく進められるルール作りに注力しています。

「対面の熱量」が、仕様変更のストレスを減らす

ーー『かんたん手続アプリ』の開発以降、その他のプロジェクトでもアジャイル開発が広がっていったのでしょうか。

久保埜：はい。私が担当しているBaaS事業の『＆BANK』というサービス開発プロジェクトがその一つです。

これは簡単に言うと、銀行が直接お客さまにサービスを提供するのではなく、事業者を通じてBtoBtoCの形で金融機能を届けるプロダクトです。あくまでもMUITは決済処理システムといった「金融サービス」を提供する裏方であり、実際にお客さまと接点を持つのはパートナー企業になります。

実は『＆BANK』の開発当初、銀行内には「要件が決まっているならウォーターフォールでいいのでは」という声もありました。

しかし、開発期間は約1年半。変化の早いBtoBtoC市場において、1年半後のローンチ時に市場がどうなっているか、誰も保証できません。そこでチーム内で議論を重ね、「スコープを固定すること自体がリスクではないか」という結論に至りました。

アジャイルを採用したのは、単にスピードを上げるためではありません。ローンチはゴールではなくスタートラインで、そこからプロダクトを育てていくという意識をチーム全体で共有するためでした。

ーー外部企業との協業となると、また勝手が違うと思います。『かんたん手続アプリ』とは違った難しさがあったのでは？

久保埜：そうですね。特に新サービス開発の場合は正解が分からないので、突発的な仕様変更は日常茶飯事です。ですがその際、チャットツール上のチケット管理だけで済ませていると、「なぜコロコロ変わるんだ」「前の仕様で合意したはずだ」と現場に不満が溜まっていってしまいます。

そのため私たちのチームでは、プロダクトオーナーとエンジニアが対面で要件の議論ができるよう、週2～3回は同じ拠点で業務を進め、対面コミュニケーションを欠かさずに行いました。

メールやチャットでは「要件変更」というテキスト情報しか届きませんが、膝を突き合わせて話をすれば、なぜプロダクトオーナーがその決断をしたのかという背景や熱量が分かります。するとエンジニア側からも「それなら、ゼロから作り直すよりこの機能を流用した方が早いですよ」と、建設的な提案ができるようになります。

単なる発注者と受注者ではなくビジネスを成功させるワンチームになるためには、この泥臭いプロセスが不可欠でした。

ーー諸届手続きラインで培った「歩み寄り」の精神が、BaaS事業でも受け継がれているのですね。

久保埜：私はスクラムマスターとしてチームを手助けする立場にいるのですが、「プロジェクト・ファースト」よりも「人・ファースト」の意識で仕事を進めています。

具体的には、若手メンバーに対して「指示を待つのではなく、チームに良い影響を与えるために今自分がどう動くべきか」を問い続けました。 失敗してもいいから、自律的に動くことを称賛する。そうすることで、メンバー自身がサービスのファンになり、「もっとこうしたい」という提案が自然と出てくるようになるのです。

こうした自律性が育って初めて、突発的な仕様変更にも強い、本当の意味でのアジャイルチームになれるのだと思います。プロジェクトは終わるとそこで途切れてしまいますが、アジャイルチームは終わることなく「ワンチーム」となって進化し続けていけると感じますね。

アジャイルに迷った時は「ビジネスのゴール」に立ち返る

ーーとはいえ、プロジェクトの規模が拡大していくと「密な対話」や「個人の頑張り」だけでは立ち行かなくなるのでは？

三木：仰るとおり、規模の拡大はアジャイルにとっては「壁」になります。実際、私たちのチームが現在進めている新規ビジネスは、銀行・信託・MUITと三菱UFJフィナンシャル・グループの各社が共創する非常に複雑なプロジェクトです。ここまでプレイヤーが増えると、単一チームやリーダー個人の力だけでは限界があります。

従来は、銀行や信託銀行の方でビジネスの企画が固まり、要件定義の終盤になってから「これをシステム化してください」とMUITに依頼が来るのが一般的でした。

しかし銀行システムは非常に複雑なので、システム観点で確認すると「この構想は実現できない」「ここは大幅な見直しが必要だ」というポイントが見つかることが少なくありません。その結果、企画の練り直しに半年から1年近くかかってしまうケースもありました。

この「ビジネス構想」と「システム実現性」の間で生じるタイムラグを解消し、ビジネスアジリティーを向上させるためには、企画立案段階からMUITが参画する必要があります。

ーー所属企業や立場が異なるもの同士となると、議論が難しそうです。どうやって実現したのですか？

三木：従来の会議体や承認フローではスピードが追いつかないため、「SAFe（Scaled Agile Framework）」という大規模アジャイルの仕組みを試験的に導入しています。

具体的には、各組織の決裁権限者や意思決定者を集めて、一つのART（アジャイルリリーストレインチーム）と呼ばれるバーチャルチームを組成しました。ここでは3カ月のサイクルで、ARTのビジネスオーナーが膨大な数のアイデアを評価し、即座に意思決定を行っていきます。

ビジネスの検討の場にエンジニアも同席していますから、「今のシステムならこう実現できる」「それは難しいが代替案がある」と、その場で実現性を判断できます。これにより、従来であれば調査・調整に後1年はかかっていたであろうグランドデザインを、短期間かつ実現性の高い状態で策定できたのです。

もちろん、最初は価値観の違いに戸惑うこともありました。だからこそ、信頼関係構築のため、全員が同一拠点に集まってのワークショップを複数回実施し、互いの組織文化や価値観を認め合い、同じゴール意識を持てるような土壌作りに注力しました。

ーーここでも、『かんたん手続アプリ』や『＆BANK』で培った経験が活かされているわけですね。

三木：個人的にアジャイルの成果とは、ビジネスの成功とアジャイル開発としての成功体験の両方が伴って、初めて実感できるものだと思います。アジャイルを行う目的は、あくまでビジネスを成功させるために継続的にプロダクトを育てていくことです。

しかし、システムが肥大化したり関係者が増えたりすると、どうしても「ウォーターフォールに合わせたアジャイル」にならざるを得ない場面も出てきます。そうなると、メンバーは「何のためにアジャイルをしているのか？」と迷子になってしまうときがありますよね。

成果が出ずに悩んでいる時は、原点に立ち返ることをお勧めします。アジャイルという手法そのものではなく、「実現したかったビジネスのゴールは何だったのか」と。自ずと、チームが進むべき方向が見えてくるはずです。

【Check】三菱UFJインフォメーションテクノロジーの中途採用情報はこちらから it.mufg.jp

撮影／赤松洋太　取材・文／今中康達（編集部）