2025.7.18_Developers Summit 2025 Summer

Transcript

1. 企業規模から考える技術戦略 創業ベンチャーCTO が丸井グループに転身して、何と闘ったか 巣籠 悠輔 Yusuke Sugomori
2. 巣籠 悠輔 Yusuke Sugomori @yusugomori
3. https://prtimes.jp/main/html/rd/p/000003581.000003860.html PR TIMES 記事より
4. 丸井グループは、エポスカードのシステムを抱えるフィンテック企業 フィンテック 小売 フィンテック x 小売 の組み合わせで事業を行っている
5. 事業を拡大していくうえで... システムの開発効率が上がらないことが問題視されている 特にフィンテック事業は収益の大半を占めるため、経営上のインパクトが大きい
6. DX 推進の一環として、開発効率を上げるための組織として マルイユナイトが発足 🚀 そこで... 昨年10 月発足から半年経った4 月より、CTO ポジションの策定 → 技術視点から組織を牽引することに
7. そのために... そもそも、なぜ開発効率が上がらないのか？ についてブレークダウンを行う → 大企業にありがちな３つの要因そのまま当てはまる
8. なぜ開発効率が上がらないのか？の３つの要因 システムのレガシー化 システム・組織の巨大化 ベンダー依存の開発体制
9. なぜ開発効率が上がらないのか？の３つの原因 システムのレガシー化 システム・組織の巨大化 ベンダー依存の開発体制
10. フレームワークが20 年以上刷新されておらず、 モダンなアーキテクチャへの対応が全くできていない😇 REST や gRPC にも対応しておらず、非効率的な形式の 実装が強いられている状態 テスト性も低く、テスト・検証に莫大な時間がかかっている 規模の大きいシステムだがフロントエンド・バックエンドの 分離もできておらず、開発体制が並列に組みづらい
11. なぜ開発効率が上がらないのか？の３つの原因 システムのレガシー化 システム・組織の巨大化 ベンダー依存の開発体制
12. 新機能の拡充に伴いシステム・組織も拡大し、 事業ドメインごと・アプリケーションレイヤーごとに部署ができている状態 新機能の開発の都度、複数部署が関係してくるために調整コス トが高くなってしまっている モノレポなアプリケーションのため、ビルド・デプロイにも多大 な時間がかかる システムの全容を把握できている人がおらず、システムの結合 度合いが分からないために、検証時間が莫大に
13. なぜ開発効率が上がらないのか？の３つの要因 システムのレガシー化 システム・組織の巨大化 ベンダー依存の開発体制
14. 丸井グループにはもともとエンジニアがおらず、 要件定義以降の開発はすべてベンダーに任せている状態 部署ごとに発注→ 納品ベースの開発のため、システム全体の最適 化がされず、同じようなコードが複数に散見してしまう さらに、事業ドメインごと・アプリケーションレイヤーごとに 異なるベンダーに発注しているため、調整コストが高い （まさしくコンウェイの法則そのもの）
15. 課題は大企業にありがちなことそのものだが... それに対してどうアクションを取るか？については、シンプルに２つしかない 体制を変える システムを変える
16. ちなみに、 みずほ銀行の勘定系システムの刷新・統合プロ ジェクトでは、 体制を変えるのに12 年 システムを変えるのに7 年 かかっている... システムはともかく、体制を変えることの 難しさがよく分かる  日経コンピュータ みずほ銀行システム統合、苦闘の19 年史
17. 体制を変える システムを変える そこで... 目先できることから目標をセット 内製エンジニア組織をつくる（開発環境づくり・採用） ストラングラーパターンで徐々にシステムを切り出し
18. 体制を変える システムを変える そこで... 目先できることから目標をセット 内製エンジニア組織をつくる（開発環境づくり・採用） ストラングラーパターンで徐々にシステムを切り出し
19. 目指す姿は、開発・運用が７〜８割は内製化できている状態だが... 当然ながらエンジニアはまだ全然いない 第一歩として、コードレビュー体制を構築 少ない人数でも技術的な意思決定に介在できるようにし、ア プリケーションの質を担保していく💪 ここから、内製メンバーの拡大とともに徐々に自分たちで開発 できるところを増やしていっている
20. 内製メンバーによる開発を進めるうえで、開発環境が整っていなかったことも 大きな課題だった これまで社内にエンジニアがいなかったことから、「当たり前の」開 発環境が存在しなかった 開発用のアプリケーション・サービスはすべて申請をしないと使えない🤢 生成AI も当然ながら使えない（一方で、社内独自ツールはある）
21. 内製開発の体制が整うには採用にかかるリードタイムが長いので、 少人数で効率よく開発できる環境が必須 「AI 駆動開発」を突き進める 「AI 駆動開発」のキーワードをとにかく連呼し、経営層に刷り込み 開発効率アップの文脈と、大企業の中でいち早くAI 駆動開発に取り組 むことで、ブランディングに繋がるという文脈 IT 企業やスタートアップでは当たり前の環境を、いち早く作る！
22. 「AI 駆動開発」が経営上のキーワードになることによって、 アプリケーション利用に申請が必要 生成AI が使えない もともとの２つの問題 ⬇️ を同時にクリア... ！ 申請が完全に不要になったわけではないが、生成AI ツールの導入は申請プ ロセスが簡易に 第一歩として Cursor を導入し、そこから CLI などに繋げている
23. 特にフィンテックよりもセキュリティ要件が厳しくない小売システムの開発 では、AI 駆動開発全開で、モダンな環境で開発を実践中👏 MCP サーバ・ツール開発や、Obsidian x Cursor を用いたドメイン モデリングなど、実験的な取り組みも順次（乞うご期待！）
24. 体制を変えるためのアクションまとめ： 内製エンジニア組織をつくることを目標に、まずは コードレビュー体制の構築 AI 駆動開発の推進 → 少ない人数でも、効率よくアプリケーションの質を保つ取り組み
25. 体制を変える システムを変える そこで... 目先できることから目標をセット 内製エンジニア組織をつくる（開発環境づくり・採用） ストラングラーパターンで徐々にシステムを切り出し
26. 巨大なレガシーシステムを刷新していくために、ストラングラーパターン で段階的移行 ＝ 現システムから切り出せる部分を徐々に新システムに移行していく
27. どこから切り出していくか？についてはアーキテクチャ次第ではあるが、 アプリケーションのレイヤーごと or ドメインごとで考えることが多い クライアント層 プレゼンテーション層 （WEB サーバ） ビジネスロジック層 データアクセス層 （アプリケーションサーバ） ドメイン（・サービス）A ドメイン（・サービス）B ...
28. もともとクライアント層まで含む全レイヤーがオンプレの同じインスタン ス内に存在していたので、いち早くクライアント層のファイルはクラウド へと移行（途中） クライアント層 プレゼンテーション層 （WEB サーバ） ビジネスロジック層 データアクセス層 （アプリケーションサーバ） ドメイン（・サービス）A ドメイン（・サービス）B ... クラウドへ 移行中
29. 移行に伴い、デザイン作業が伴う運用が発生するコンテンツに関しては、 ノーコードツール STUDIO を導入し、エンジニアでないメンバーで内製 運用ができる体制を構築 エンジニアの人数がボトルネックにならないように デザインにおいても可能な限りコンポーネント化しておくなど、内製を しやすくなるように進行
30. 本命であるアプリケーション側は、開発頻度の高い（＝事業インパクトの 大きい）箇所を優先して刷新するために、プレゼンテーション層および、 一部のドメインの切り出しに着手 クライアント層 プレゼンテーション層 （WEB サーバ） ビジネスロジック層 データアクセス層 （アプリケーションサーバ） ドメイン（・サービス）B ... ドメイン（・サービス）A
31. ドメインの切り出しによって、組織構造もドメイン単位（feature 単位）に することも見据える 組織構造を反映した開発体制・システム構造になっている現状に対し、 システム構造をベースに体制を変えていく、いわば「後追い逆コンウェイ」 コンウェイか逆コンウェイかは本質ではなく、 とにかく開発効率が上がるように体制を組んでいくことが大事 ※ アーキテクチャ含めた刷新は、技術目線で組織改革までを考えることが できる貴重な機会
32. システムを変えるためのアクションまとめ： ストラングラーパターンによる段階的刷新 エンジニア人数不足を補うノーコードツールでの内製化 （STUDIO ） → システムを変えることで、体制も変えることを見据える
33. 体制を変える システムを変える まとめ： 開発効率を上げるための目標の振り返り 内製エンジニア組織をつくる（開発環境づくり・採用） ストラングラーパターンで徐々にシステムを切り出し
34. 体制を変える システムを変える まとめ： アクションの振り返り コードレビュー体制の構築 AI 駆動開発の推進 ストラングラーパターンによる段階的刷新 エンジニア人数不足を補うノーコードツールでの内製化
35. 体制 システム 開発効率をあげるために、体制を変える・システムを変えることが必要 片方の変化がもう片方の変化も促し、変化のサイクルが生まれるように （する必要がある）
36. エンジニアの人数が少なくても取れるアクションはあるが、 人数が多ければ、当然ながら打ち手は増やせる... 大企業でのAI 駆動開発、システム刷新などご興味ある方はぜひ🙏🙏
37. Thank you!