利用者800万人のシステムが抱える3つの構造課題
実はフィンテック企業──丸井グループをそう形容しても、もはや違和感はない。丸井の店舗としての印象が強い同グループだが、現在は自社発行の「エポスカード」を軸としたフィンテック事業が収益の大半を占めており、小売と金融を掛け合わせた独自のビジネスモデルで成長を続けている。
その丸井グループが、2024年10月に新たな一手として立ち上げたのがテックカンパニー「マルイユナイト」だ。マルイユナイトは、顧客起点のデジタル体験を支えるアジャイルなプロダクト開発を加速させ、グループ全体に波及させていくことを目的に設立された。背景には、事業の中核であるフィンテック領域の拡大において、開発効率の伸び悩みが経営上の大きな懸念事項となっていたことがある。こうした課題に対処すべく、丸井グループは新会社を通じた構造的な変革に踏み出した。
なぜ開発効率が上がらないのか。マルイユナイトのCTO、巣籠悠輔氏は3つの要因を挙げる。
1つ目は、システムのレガシー化だ。2025年6月期時点で800万人の会員を抱えるエポスカードの基盤システムは、2006年のリリース以降、実に20年も更新されてこなかった。「フロントエンドとバックエンドの分離もなく、開発体制が並列で組みにくい。RESTにも対応していない。設計思想自体はしっかりしていたが、テスト性などが低く、検証に膨大な時間を費やしている状況だった」（巣籠氏）
2つ目は、システムと組織の肥大化だ。これまで機能やサービスを追加するとき、事業ドメインやアプリケーション単位で部署を設置して運用を担当してきた。こうした体制は、サービス規模が小さかった当初は問題なかっただろう。しかし、会員数が増え、時代やニーズに合わせて機能を増やす中で、担当部署も増加。さらに、システムの全容を把握して統括する担当者が不在だったため、新たに機能を追加、修正したいとき、システムの影響箇所をすぐに洗い出すことができず、複数の関係部署との調整や検証で必要以上のコミュニケーションコストや工数がかかっていた。
3つ目は、ベンダー依存の体制だ。丸井グループではこれまで社内エンジニアがおらず、要件定義こそ社内で行うものの、開発はベンダーに外注するのが通例だった。さらに部署ごとに発注していたため、コードベースの統一性もなく、「コードを見たら、似たような処理が何度も出てきたり、ドメインごとに設計思想がバラバラだったり。全体最適の視点がない状態だった」と巣籠氏は振り返る。
現状を打破するための内製組織構築とAI駆動開発
こうした現状を打破すべく、巣籠氏がまず着手したのは「体制の変革」だった。同氏は、体制を変えるのに12年、システム刷新にはさらに7年を要したとされるみずほ銀行の勘定系システム刷新を引き合いに出し、これほどの大組織になると、意思決定の構造や働き方を変えるだけでも膨大な時間と労力が必要になると考えた。よりスピード感のある変革を目指す巣籠氏は、できるところから一つずつ変えていく方針を選んだ。
取り組んだのは、内製組織の構築と、AI駆動開発の推進だ。
まず内製組織については、将来的に開発運用の70～80%を内製化することを目標に、その第一歩としてコードレビュー体制の整備に着手した。「エンジニアもようやく5人になったが、リソースとしてはまだまだ少ない」と巣籠氏。そんな少人数でも技術的な意思決定に介在し、アプリケーションの品質を担保できるよう、体制作りを進めている。
それと並行して着手したのが、内製開発に必要な環境の整備だ。ここでの課題は、社内の申請プロセスは依然として複雑で、開発用ツールや生成AIサービスの導入にも時間がかかっていたことだ。少人数体制で効率よく開発を進めるには、新しいテクノロジーをいかにスムーズに取り入れられるかがカギになる。そこで巣籠氏が掲げたのが「AI駆動開発の推進」だった。
「AI駆動開発」は、開発効率を高めるだけでなく、先進的な取り組みとして社内外へのブランディング効果も期待できる。そんなメッセージを繰り返し訴えた結果、その言葉は経営層に届き、丸井グループの経営計画のキーワードのひとつとして正式に盛り込まれることとなった。その成果もあって、ツール導入申請のプロセスも一気に簡略化され、今ではClaude Codeをはじめとした生成AIツールも活用できている。
比較的セキュリティ要件の厳しくない小売系システムの開発では、すでにAI駆動開発が本格的に進む。「他のIT企業とそん色ない環境で開発できるようになってきた」と巣籠氏は胸を張る。
組織構造ではなく、システムの構造に合わせる
現状打破に向けたもうひとつの取り組みが、システムの刷新だ。
従来のシステムはJ2EEベースのモノリシックな構造で、クライアント層からアプリケーション層、プレゼンテーション層、ビジネスロジック層、データベースまで、すべてがオンプレミス環境の同一インスタンス上に載っている。ごく一部の改修であっても、全体を見直さなければならない状態で、開発や運用においてとても非効率な環境だった。
そこで採用したのが、段階的に既存システムを置き換えていく「ストラングラーパターン」だ。まずは静的ページが中心のWebクライアント層を切り出し、AWSのS3への移行を進めている。また、それと並行してノーコードツール「Studio」の導入も行った。これにより、エンジニアではないメンバーも、Webサイトの構築や公開、運用が可能になった。「数少ないエンジニアに、すべての開発業務を任せていては負担が大きすぎる」エンジニアの人数がボトルネックにならないように、現実的な打ち手を選んだ。
本命は、当然ながらアプリケーション層の刷新だ。ここでは、開発頻度が高く、かつ事業インパクトの大きいドメインから優先的に着手している。現在は、プレゼンテーション層の分離や、頻繁に機能追加が行われる領域の切り出しが進行中だ。
将来的には、ドメイン単位で組織を編成し、各ドメイン内で完結する機能開発を担う「フィーチャーチーム」を設置する考えもある。これにより、これまで組織構造に引きずられていた開発体制を、システムの構造に合わせた柔軟なものへと再構成していく。
「アーキテクチャを含めてシステムを刷新することで、技術の視点から組織そのものを変えていける。技術改革を足がかりに、組織のあり方そのものを見直すという、非常に貴重な経験をさせてもらえている」と巣籠氏は語る。
開発効率を高めたいという思いは、多くの企業に共通するものだ。ただし、それを実現するためには、体制だけ、あるいはシステムだけを変えれば済む話ではない。マルイユナイトの取り組みから見えてくるのは、どちらか一方の変化がもう一方の変化を促し、互いに作用しながらサイクルとして動いていくことの重要性である。
今回の事例は、あくまでもひとつのケースにすぎないが、同じように現場で課題に向き合っている人たちにとって、何かしらのアイディアやヒントの種になればと巣籠氏は締めくくった。
株式会社マルイユナイトでは、一緒に働くエンジニアの積極的な採用活動を行っています！
マルイユナイトは2024年9月に始動した、丸井グループのテックカンパニーです。
「好き」という感情とデジタルの力で、新しい顧客体験を共創しています。
本記事でご興味を持たれた方、よろしければカジュアルにお話ししませんか。
こちらからお気軽にエントリーください。
