三菱UFJフィナンシャルG、業務部門がリリース後に抱く「本当はこうしたかった」をどう解消？：内製化でシステム部門との新たな役割分担

要件通りにシステムが完成しても、実際にシステムを使う側の業務部門では「もう少しこうしたかった」という部分が残ることもある。三菱UFJフィナンシャル・グループ（MUFG）の融資企画部 BHC法対応企画室は、ローコード開発基盤を活用し、自らシステム開発に携わる内製化に挑んだ。

[雨輝ITラボ（リーフレイン）, 編集：遠藤文康，＠IT]

　構築したシステムが当初の要件を満たしていても、実際に使う業務部門にとっては「もう少しこうしたかった」「思っていたものと違う」と感じる部分が残ることもある。こうした業務部門と開発側の認識のずれを埋め、システムを継続的に改善していくには、どうすればよいのか。

　三菱UFJフィナンシャル・グループ（MUFG）で米国の金融規制への対応を担う融資企画部 BHC法対応企画室は、システムを「使う側」にとどまらず、自ら開発にも携わる道を選んだ。2026年9月3日に開催された「OutSystems World Tour Japan 2026」では、同室から3人が登壇し、ローコード開発を活用した内製化の取り組みや、開発部門・外部パートナーとの協働の進め方を紹介した。

「使う」から「作る」へ――業務部門が開発に関わる新たな形

　同室は、米国の金融規制への対応を担っており、もともとシステム開発の専門組織ではない。開発経験がほとんどなかった担当者たちは、どのように開発に関与し、自らシステムを作るまでになったのか。開発を担うIT部門や外部パートナーは、業務部門とどのように役割を分担し、内製化を支援したのか。

　MUFGの融資企画部 BHC法対応企画室は、米国の金融規制であるBHC法（米国銀行持株会社法）への対応を担っている。主な業務は、MUFGが世界中で行う出資の状況を監視し、必要に応じて関係部署に助言・指導することだ。

　同室の山本晃祥氏（次長）は、金融規制対応業務の特性として、判断の正確性と、規制変更への迅速な対応を両立させる必要があることを挙げる。システム化に当たっては、業務の専門性が高く、業務が細分化しやすいことに加え、大量のデータを収集することや、当局への説明に備えて証跡を残す必要もあることなどを考慮しなければならない。

業務の特性から生じるシステム化の課題（提供：MUFG）

　従来同室では、年次報告や出資情報の確認・検証などグローバルな規制に対応するために、「Microsoft Access」や「Microsoft Excel」を使って管理していた。数万規模の事業法人やファンドの出資データを手作業や目視で管理していたが、金融規制や報告要件の変更にも迅速に対応し、継続的な業務改善を支援できる仕組みが求められていた。

　こうした課題に対応するため、同室ではシステムの内製化を見据え、OutSystemsのローコード開発基盤を導入した。グループ各社の出資情報を取り込み、計算・判定から報告書の作成までを担うシステムを構築。手作業の削減に加え、規制や業務の変化に合わせて継続的に改善できる仕組みを目指したという。

まずは「開発者にどう伝えればいいか」を学ぶ

　同室の森川克真氏（調査役）は、従来のシステム開発における課題として、業務部門の要望が開発側に十分伝わらないことや、システムの内部構造がブラックボックス化し、修正が難しくなることなどを挙げる。

　そうした課題に対して同室が取ったのが、短い設計・開発サイクルを繰り返し、業務部門が実際に動くシステムを確認しながら仕様を改善していくアプローチだ。

開発時の重点課題と対応方法（提供：MUFG）

　ただし、業務部門の担当者にはシステム開発の経験がほとんどなかった。そこで、まずはPMO（プロジェクトマネジメントオフィス）として開発に参加し、進捗（しんちょく）・品質管理やベンダーとの調整などを担当。要件定義にも関わりながら、開発者に要望をどう伝えればよいかを学んでいったという。

　設計・開発段階では、機能を小さな単位に分けて開発と改善を繰り返した。その中で重視したのが、開発担当者と業務部門の間に立ち、双方の認識のずれを埋めることだった。具体的には、開発担当者が作成した設計や機能を自ら確認し、内容を理解した上で業務担当者に説明した。一方、業務担当者からの要望はそのまま開発担当者に伝えるのではなく、背景にあるニーズを整理し、画面イメージやデータモデルなども用いながら具体的に伝えるようにしたという。

　約1年にわたるプロジェクトを経て、業務部門としては開発者にシステムを作ってもらうだけの立場から、自らも開発に携わるようになり、「内製化の礎を築けた大きな一歩だった」と森川氏は振り返る。

「もう少しこうしたかった」をどう解消するか

　業務部門による内製化をさらに進める背景について、同室の田中玲香氏（エキスパート）は、従来のシステム開発で感じていた課題を挙げる。

　同室は、金融規制や業務フローに通じた業務部門の強みを生かして要件定義や基礎設計を担い、開発担当者に伝えてきた。プロジェクトは順調に進み、当初の要件を満たしてリリースした。それでも「もう少しこうしたかった」という思いは残る。田中氏は、開発プロセスで起き得ることとして3つの状況を挙げた。

• 優先順位の関係で、本当はやりたかった機能がスコープ外になる
• 出来上がった画面は要件通りでも「これが本当に欲しかった機能なのか」と疑問を抱く
• 要件定義から完成までの間に、業務やそれを取り巻く環境が変わる

リリース後にも「もう少しこうしたかった」が残る（提供：MUFG）

　こうした状況に対し、業務を知る自分たちが自ら形にすることで、業務の理想と実装のギャップを縮め、変化への対応力を高めたい。これが内製化を目指した出発点だと田中氏は語る。

「ペアプログラミング×実案件」――作りたいものを自分で作る

　進め方は「ペアプログラミング×実案件」だ（下図）。1つ目のポイントは、座学ではなく開発しながら学ぶこと。本開発の最中に、ビジネスパートナーとのペアプログラミングで1つの画面を実装した。分からないことはその場で確認しながら自分で手を動かした。苦戦はしたものの「やってみたら面白かったというのが率直な感想」と田中氏は振り返る。

　2つ目のポイントは、実際の業務案件を題材にすることだ。当初のシステム開発では、実装したい機能があっても、優先順位の関係で開発対象から外さざるを得ないものがあった。田中氏は、そうした機能の一つを自ら開発することにした。選んだのは、他部署がデータ検証に使用していたExcelのクロス集計表をシステムに取り込む機能だ。田中氏は「本当に欲しいものを自分が作るので、学ぶ側も本気になる」と振り返る。

　田中氏は、内製化とは全てを業務部門だけで開発することではないと強調する。重要なのは、業務部門と開発の専門家が、それぞれの強みを生かして協働することだ。

　業務部門が主導するのは「何を、なぜ作るのか」という部分だ。金融規制に基づく判断の根拠や例外への対応を考え、業務フローや必要なデータが適切かどうかを見極めながら、日々の改善を進める。一方、システム部門や外部パートナーには「どう実現するか」という観点から、システムの設計や実装、品質の確保など、専門性が求められる領域を支援してもらう。

　こうした役割分担を通じて目指すのは、単に業務部門がシステムを開発できるようになることではない。業務や規制の変化に対応しながら、業務とデータの信頼性を維持・向上できるシステムへと進化させていくことだという。

---

　MUFGの内製化の取り組みは、業務部門が開発を全て引き受けることを意味しない。業務部門が「何を、なぜ作るのか」を主導し、開発部門や外部パートナーが「どう実現するか」を技術面から支える。業務部門がシステムの仕組みを理解し、自ら改善にも関わる一方、開発の専門家は設計や実装、品質の確保を支援する。こうした役割分担が、業務や環境の変化に対応しながらシステムを継続的に改善していくための鍵になりそうだ。