AIの進化やビジネスニーズの加速により、アプリ開発の現場に求められるスピードと柔軟性が年々高まり続けている。PoCや仮説検証の実施、MVP（*1）の作成をどれだけ早く回せるかが、開発競争力を左右する時代だ。

しかし、思うようにスピードを上げられずに苦心している開発現場も多い。「検証用の環境を用意するだけで、部署横断の申請や数週間の待機を強いられる」といったケースに身に覚えがある、もしくは耳が痛いと感じるエンジニアもいるのではないだろうか。

三菱UFJ銀行のIT戦略を支える三菱UFJインフォメーションテクノロジー（以下、MUIT）も、かつては同じ壁に直面していた。

「このままでは、競合との開発競争に敗れてしまう」

そんな危機感を覚えたMUITが挑んだのが、組織横断での「開発基盤の早期提供プロジェクト」だ。

従来の申請フローや基盤構築のあり方を根本から見直し、技術面・組織面の双方にメスを入れていったというこのプロジェクトで、MUITの開発現場はどう変わったのか。

プロジェクトを推進した堀内さん、荒木さん、金子さんの三名に、その全貌と舞台裏を聞いた。

三菱UFJインフォメーションテクノロジー株式会社
ITコントロールサービス部
堀内 幸之介さん

2011年入社。連携基盤システムの開発・保守を一貫して担当。2024年よりITコントロールサービス部を兼務し、基盤早期提供プロジェクトの推進を担当

三菱UFJインフォメーションテクノロジー株式会社
ネットワーク・クラウドサービス部
荒木勇登さん

2014年入社。入社以来、共通基盤の開発・保守を担当。2024年より行内のコンテナ基盤担当として基盤早期提供プロジェクトに参画

三菱UFJインフォメーションテクノロジー株式会社
業務基盤第一部
金子 隼也さん

2014年入社。入社以来、市場系システムの基盤開発・保守案件を担当。2024年より業務基盤本部の担当メンバーとして基盤早期提供プロジェクトに参画

基盤構築に2か月……“申請のスタンプラリー”を終わらせたかった

ーー検証環境の基盤構築には、複数の部署をまたいだ申請が必要だったと伺いました。当時の状況を詳しく教えてください。

堀内：当時は、ネットワーク、OS、ミドルウエアなど、レイヤーごとに担当部署が分かれており、検証環境を利用するには複数部署をはしごして申請を行う、いわばスタンプラリー的なフローが必要でした。その結果、基盤が整うまでに2〜3か月かかることも珍しくなかったんです。

次第にエンジニアの間で「今の基盤提供のやり方は、本当に最適なのか？」という声が上がるようになり、基盤有識者による改善活動が始まりました。この取り組みが、2024年の3月より正規のプロジェクト化し、以来、私もプロジェクト推進として携わっています。

まずは、基盤提供に至るまでの全工程を可視化することから始め、どこにボトルネックがあるのかを明らかにしていきました。

ーー何が課題だったのでしょうか？

堀内：煩雑な申請フロー、様々な個別要件に応えるための人手を多く介する構築プロセスの両面が、根本的な課題でした。そのため、あらかじめ決められた構成パターンをテンプレート化し、申請から構築までのプロセスを標準化・簡素化することを目指したんです。

この方針を実現するにあたり、既存のプラットフォーム担当組織とは別に、レイヤー横断で動ける専任のプロジェクトチームを新たに立ち上げました。ネットワーク・OS・ミドルウエアなどの各部署が個別に自動化を進めたとしても、部署をまたぐ煩雑な申請がいるといった根本的なボトルネックは解消できませんから。

チームが立ち上がってからは、プロジェクトメンバー内で「われわれがやっているのはPlatform Engineeringである」という旗印を明確に掲げました。開発工程の単なる一部自動化ではなく、プロセスも含めて刷新していくんだという共通認識をチーム全体で持つためです。

技術と組織の両軸を改革し、プロセス全体を自動化する

ーー基盤構築の自動化の設計は、どのような流れで進めていきましたか？

堀内：プロセス全体のアーキテクチャ設計は専任チームが中心となって進めており、具体的にはGitLab CI/CDによるパイプラインを採用しました。複数の担当部門が関わる処理を疎結合かつスムーズに連携できる構成が実現できるので、これがベストな選択でした。

基盤構築にはさまざまな部署が携わっているのは先ほどお伝えしたとおりですが、GitLab CI/CDを用いることで、各チームが自分たちの処理（ジョブ）を独立したリポジトリで管理しつつ、全体としては一本のCIパイプラインに統合することが可能になります。この構造により、各チームが自律的に運用しながらも、プロジェクト全体では一貫した自動化フローを実現することを目指しました。

また、エンジニアが普段から行っている操作の延長で、違和感なく基盤構築の申請を行えるようにするうえでも、GitLab CI/CDの採用は効果的でした。

今回のプロジェクトでは、YAML形式のファイルで基盤利用の申請を出すモデルを採用しています。YAMLは、CI/CDの設定やインフラの定義などで広く使われている、人間にも読みやすい記述形式で、GitLabのCI/CD機能とも親和性が高い。YAMLで定義された内容をもとにパイプラインを実行できるため、開発者にとって自然な操作フローのまま申請から自動処理へとつなげることができるんです。

ーー荒木さんは、インフラ基盤の構築・運用を主に担当されたそうですが、CI/CDパイプラインはどのような構成になっていますか？

荒木：開発者がGitLabにYAMLファイルを登録すると、その内容が自動的にパイプラインへ引き渡されます。その後、ROSA（*2）やAWSに必要な形式に変換され、該当部門のGitLabリポジトリに渡される流れです。そこからGitLab CIのパイプラインが起動し、自動で構築が始まります。

ROSAクラスタの構築においては、構成情報を自動生成するために構成管理ツールの「Ansible」を使用しています。生成された設定データを「Kubernetes」に読み込ませることで、必要なリソースや環境を自動で立ち上げられる仕組みです。AWSも同様に、テンプレートとパラメーターを使った標準化と自動化を進めています。

さらに、2024年度からはROSAのマルチクラスタ提供も本格的に開始しました。「1システム＝1クラスタ」の構成に転換し、管理部分を軽くした新方式である「ROSA with Hosted Control Plane」（*3）を導入。一つのクラスタに多くのシステムを詰め込むことによる運用負荷や制約が軽減され、システムごとに独立して管理・運用が可能になりました。

これにより、新しいシステムと古いシステムを切り替えながら段階的に更新するBlue/Greenデプロイや、既存の環境を一度壊してから再構築するスクラップ＆ビルド型の柔軟な更新方式も実現できるようになっています。

ーーアプリチームに提供される検証環境基盤は、どのようにセットアップを？

金子：その領域は、私たち業務基盤本部のメンバーが中心に担当しました。

アプリケーションチームに提供される基盤は、GitLab CI/CDパイプラインを通じて自動化された構成スクリプトが実行され、必要な環境が順番に整備されるようになっています。

パイプラインが起動すると、まず最初に全システム共通のOS設定をAnsibleで自動実行します。これらは「共通ロール」として標準化しているため、再利用性が高く、保守性にも優れています。

その後に、プロジェクトごとに異なるミドルウエアの構成処理が走ります。こちらは導入要否や設定内容がシステムによって異なるので、「個別ロール」として柔軟に適用できるようにしています。「共通処理」と「個別処理」を明確に分けることで、標準化とカスタマイズのバランスを取るようにしました。

さらに最近では、インフラの構成テストを自動化する「Serverspec」というRubyベースのツールも導入し、構築された環境が設計通りになっているかをコードベースで検証する取り組みも進めています。

ーー技術と組織の両面から整備を進めたことで、比較的スムーズに自動化が進んだように感じますが、実際はいかがでしたか？

荒木：そう見えるかもしれませんが、金融系システムならではの厳しい制約に対応するのは簡単ではありませんでした。

「重要な操作（特権操作）には、複数部門の承認が必須」
「AWS上でのアクセスや設定は、すべて精査してから許可」
「基盤を提供した後も、開発者はEC2やELB（クラウドのサーバーやロードバランサー）すら直接操作できない」

こうした厳格なセキュリティーポリシーがあるため、自動化を進めても、スピードを出すのが難しい場面が多くありました。そこで、解決策として設けたのが「サンドボックス環境」です。

これは本番環境とは分けられた「お試し環境」で、開発者自身が自由に操作できる空間です。セキュリティーの基本ルールは守りつつ、試行錯誤できる余地を与えることで、「すぐに動かして試したい」という現場ニーズにも応えることができました。

「最短5営業日」でPoC着手やMVP立ち上げを実現

ーー今回のプロジェクトで得られた成果を教えてください。

堀内：最も大きな成果は、PoCやMVP立ち上げまでのリードタイムが劇的に短縮されたことです。これまでは、基盤が提供されるまでに約2か月かかっていましたが、サンドボックス環境の導入により、最短5営業日で検証に着手できるようになりました。

これまでは基盤側の都合でアプリ側の開発スケジュールが引っ張られるケースも多かったのですが、現在は開発チームの初動に合わせて柔軟に基盤を提供できる体制が整いつつあります。この変化は、開発者のモチベーションや設計の柔軟性にも良い影響を与えており、チーム全体のアジリティー向上にもつながっています。

ーー難しさもあったかと思いますが、一方で得られた気付きや学びも多かったのではないでしょうか？

金子：はい。今回のプロジェクトを通して、自動化に対する意識が大きく変わりました。

実は一部の構築作業には、以前からAnsibleを用いた自動化が取り入れられていたのですが、手作業に頼る部分も多く残っていたんです。

しかし今回のプロジェクトで、自動化によってミスや工数を大きく減らせることを身をもって実感し、「まずは自動化を前提に考える」マインドに自然と切り替わっていきました。

また、Infrastructure as Code（コードによるインフラ構築）を実践することで、従来のサーバー構築と異なり、アプリケーション開発に近い感覚や技術が求められるようになりました。構成や検証をコードベースで管理できるようになったことで、自分自身の技術領域も広がり、エンジニアとしての成長を実感しています。

荒木：MUIT全体に影響を及ぼすような選定を担うプレッシャーの中で、常にバランスを意識しながら設計判断を下す力が鍛えられました。

特にコンテナ周りのエコシステムは、技術の進化スピードがとても速いです。どの製品や構成を「標準」とするか判断する際には、単なる機能性だけではなく、「本当に多くのチームが必要とするものか？」「複数のシステムに展開できる汎用性があるか？」といった視点が欠かせません。

中でもROSAクラスタの標準化では、システムごとの構成やニーズを深く理解しながら、リードタイムや認知負荷の削減につながる最適な形を模索する過程で、自分の視野が広がっていくのを実感しました。

ーー今後、この取り組みをどのように発展させていきたいと考えていますか？

堀内：基盤構築の時間は短縮できましたが、現場のニーズはまだまだあります。とりわけ「開発者がセルフで基盤を立ち上げ、アプリのデプロイやテストまで一気通貫で進められるようにしたい」といった声は、アプリ開発のスピードと柔軟性をより向上させる上で見過ごせない課題です。

そのため現在は、開発者自身が必要なタイミングでテスト用の環境を作り、使い、破棄するところまで行える「セルフサービス型」の検証基盤を目指しています。

とはいえ、現時点では提供できる構成パターンが限られており、運用やセキュリティー、統計情報の収集といった管理系の機能も、まだ十分には整っていません。また、構成処理やリソース管理の仕組みについては、コストや工数の関係で着手できていない部分が多く残っているのが現状です。

今はまだ、CI/CDをベースとした「標準的な自動化の型」が見え始めてきた段階にすぎません。今後は、提供できる機能の幅を少しずつ広げ、より多くのシステムをこの仕組みに乗せていくことで、本当の意味で「必要なときにすぐ使える基盤」を実現したいです。

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