三菱UFJ銀行におけるエンタープライズAI駆動開発のリアル 〜内製開発の具体手順デモ〜
尾根田 倫太郎さん(三菱UFJインフォメーションテクノロジー株式会社)
https://speakerdeck.com/muit/enterprise-ai-driven-development-at-mufg-bank-the-real-story
- AI駆動開発
- AIコーディングエージェントを前提とした開発
- スキルが高い人ほど生産性が上がっていく
- 三菱UFJ銀行におけるAI駆動開発
- 2024末頃から調査開始
- 2025/5にAI駆動開発ガイド
- 2025/6から案件で適用開始
- 融資審査システム(Java -> React)
- 財務諸表を作成する分析システム(PL/1 -> Java)
- FigmaからUIコンポーネントの生成
- 会計パッケージ移行
- 2025/10AI駆動開発研修
- AI駆動開発ガイド
- 80点の出力を期待する
- 残りの20点を人がうめる
- AIは補助で人がチェックする
- 80点の出力を期待する
- エンタープライズ開発
- 対象システムが数十万〜数百万行
- 開発人数が数十人〜数百人
- ドキュメントはエクセル方眼紙
- エクセルは標準フォーマットなのでxml化できてAIに渡せる
- インターネット接続ができない環境
- 接続先を差し替えられるAIを使ってる
- cline
- ClaudeCode
- 裏はBedrockで
- ジュニアエンジニアをどう育成するか
- よくわからないけど動いてますは許されない
- 生産性を犠牲にするわけにもいかない
内製開発の"共通言語"としてのFigma ─ AI時代のプロダクトづくり
谷 拓樹さん(Figma Japan株式会社)
- アイデア -> 視覚化 -> 構築 -> リリース
- デジタルプロダクトにおけるこれらをFigmaがカバーしてる
- 内製開発が変えること
- 工程や部門間の分断を解消する
- 合意形成のスピードが上がり検証と開発が高速化
- 生成AIによる高速化
- 速さが分断を高速化させる
- 探索があらゆる場所でおこなわれサイロを生み出す
- スピードの裏にある手戻りのコスト
- FigJamと生成AI
- ChatGPT連携ができる
- FigJam上で編集可能なダイアグラムを作ってくれたり
- Claudeでも
- FigmaMake
- テキストからUIのコード生成
- 既存のデザインをコンテキストとして持った上で
- 非デザイナー(PdMなど)がプロトタイプまで作ってといった使い方も
- 成果物をFigmaに持っていってブラッシュアップしていける
- npmパッケージのデザインシステムを与えることもできる
- MCPでnotionつないだりもできる
- デザインからコードへ
- DevMode
- デザインから開発へのハンドオフ
- 人から人への前提だった
- Figma MCP Server
- 既存コードの文脈を踏まえた上でのコード生成
- 視覚に関するコンテキストを補完
- Code Connect
- デザインとUIコンポーネントの実装を紐づける
- DevMode
- Claude Code to Figma
- ブラウザのレンダリング結果をFigmaのデザインに変換できる
- コードからデザインに
- 画面上の特定の要素を選んでFigmaに持っていくこともできる
- デザインの検討をするのに実装を先にやって議論をFigmaでやる
AI 駆動開発ライフサイクル(AI-DLC):ソフトウェアエンジニアリングの再構築とAWS の内製化支援
金森 政雄さん(アマゾン ウェブ サービス ジャパン合同会社)
- 従来の開発手法
- ウォーターフォールやアジャイル
- これらは人と人が協調するための仕組みだった
- 段階的な改善ではなくパラダイムシフトはどうすれば起こせるか
- AI Managed
- AIが自律的に構築/保守することを目指す
- 人間が介入しない
- よほど単純なシナリオでないと上手くいかない
- AI-Assisted Development
- 従来の開発プロセスのままでAIが得意なところを置き換える
- 部分的な高速化はする
- AIに仕事をさせるための人のマニュアルタスクが増えてしまう
- AI Managed
- １人でのバイブコーディングははかどる
- 組織のなかでAIコーディングすることとのギャップ
- AI-DLC
- AI Development Lifecycle
- AIは計画やタスク分解やアーキテクチャ提案などの開発プロセスを実行
- 開発者は検証や意思決定や最終的な責任を持つ
- Inception - Construction - Operation
- 各段階が次の段階のためにコンテキストを構築する
- AIと人間がレビューしてコンテキストを作らせる
- プラン - レビュー - 実行 - レビュー
- 組織やチームがコミュニケーションをとってアクティブに開発できることを目指している
- AIがチーム間のダイナミックなコラボレーションを促進させる
- モブワークを前提とした考え方
- 職種をまたいだモブワークで即座の意思決定
- 次世代アジャイル
- アイデア創出 - 理論的基盤- 概念実証 - 顧客検証
- 素早い実験から学びを最大化
- それを実現するための文化や風土が必要
- チームが分割されえると学びが切断されてしまう
- 学ぶための機能横断的な小さなチーム
- End to Endで見れる必要がある
- その実現は内製の方がいい
東京ガス「myTOKYOGAS」内製化の3年：プロダクトオーナーとエンジニアが語るリアル
迫田 賀章さん(東京ガス株式会社)
荒井 亮汰さん(東京ガス株式会社)
福田 美桜さん(東京ガス株式会社)
- myTOKYOGASの開発体制
- ビジネス/エンジニア/デザイナーが同じ組織に
- スクラムで2週間スプリント
- 内製開発を始めて
- 2週間単位で要件決めて開発をしていく
- 保守もしていく
- 単に作業者が内部の人になっただけになってないか
- 要求通りに早くよりも顧客価値の高速な検証
- 開発プロセスの改善
- 仕様検討段階からエンジニアも入っていく
- 必要十分にとどめて要件を広げすぎない
- 内製エンジニアとして重視してること
- プロダクトエンジニアとしての事業価値創出
- ドメイン知識や歴史の理解
- 内製化領域
- まずはフロントエンドから
- バックエンドや基幹システムは他のグループ会社で
- BFFにドメイン層を設けたら汎用的なものになってしまった
- マイクロサービスとして徐々に切り出しへ
- それに伴ってバックエンドも内製化
- 高トラフィックなためDB設計など必要
- いわゆるNewSQLサービスのTiDBを採用
- プラットフォームチーム
- エンジニアチームが価値を最大限発揮できるように
- マイクロサービスのプラットフォーム
- EKSからECSに移行
- 運用してみると管理対象が多くバージョンアップ作業が大変
- 運用コストが高すぎるのでECSに移行
- リリース作業をエンジニアチーム単独で実行できる環境の整備
- 組織がスケールしていった時にプラットフォームチームがどこまでやるかの線引を考え直さないといけない
なぜLIXILは内製化を選んだのか？10年間の挑戦と内製化戦略
原田 篤さん(株式会社LIXIL)
- LIXILのDigital部門
- 研究 -> 開発 -> 製造 -> 販売
- 800以上のシステム
- 150以上のスクラムチーム
- 5社が合併して出来た会社
- なぜ内製化の流れがあるのか
- ビジネスの急激な変化
- 競争優位性の厳選がソフトウェアへ
- コア機能と補助機能
- 自社で作るべき領域と外部から調達する領域の区別
- 内製化のモデル
- 何を作るか
- どこまで内製で作るか
- 誰がどうやって作るか
- 採用と技術スタック
- goよりもJavaの方が採用市場で人が多いとか
- 5社の合併によるシステム統合
- パッケージ製品に寄せる方向で刷新しようとした
- 業務をシステムに寄せて変えないといけない
- コンサル会社手動で要件定義しブラックボックス化
- 外注だと業務を変えることのオーナーシップが不在
- 将来性を考慮できてない
- ベンダー依存/意思決定が遅い/ビジネスニーズへの追従困難
- 顧客認証基盤
- IDaaSの設計運用
- 10年前の見積もりシステムの基幹刷新
- 合併での失敗作のシステムの刷新
- 内製開発のtips
- コントロールできるようにできるだけミニマムに
- 最低でも1人はエンジニアリングリーダーが必要
- Job型で採用異動できる体制
- AIの恩恵がビジネスに直結する
「使いにくい」も「運用疲れ」も卒業する。UIデザイナーとエンジニアが創る持続可能な内製開発
東影 勇太さん(NRIネットコム株式会社)
大林 優斗さん(NRIネットコム株式会社)
https://speakerdeck.com/nrinetcom/shi-inikui-mo-yun-yong-pi-re-mozu-ye-suru-uidezainatoenziniagachuang-ruchi-sok-ke-neng-nanei-zhi-kai-fa
- 内製開発におけるUIデザイン
- 機能は満たしているのに使いにくい
- 仕様=画面になりがち
- 開発集弁で変更要望で手戻り
- 伴走型のデザイン
- デザインを納品ではなくデザイナーが参加するスタイル
- 見た目を整える以前に情報の整理が必要
- デザインのAI活用
- 飛躍的に向上している
- Figmaをマスターとする場合
- FigmaMakeで画面作成
- htmlもできあがる
- おかしなところをFigmaDesignで手直ししコードを再生成
- コードをマスターとする場合
- デザインシステムをClaudeCode二読み込み自然言語で画面生成
- 生成されたコードを手直し
迷わず行けよ。行けば分かるさ。内製化の道。～三井住友海上、内製化との格闘の記録～
山戸 伸一郎さん(三井住友海上火災保険株式会社)
- アジャイル推進組織をビジネス部門の中に設置
- スクラムチームを構築
- アジャイルCoE
- 開発エンジニアは一部パートナー
- アジャイルコーチを外部から
- アジャイルに対する組織の視線
- 失敗すると次につながらずアジャイルの流れがなくなってしまう
- 動くものをはやく出して成果を見せないと
- DevOps環境の壁
- ネットワークにつながらない環境
- SaaSを使うことでパートナー会社からもアクセス可能
- GitLab SaaSを採用した
- PoCやってその後本格展開
- ビルド/デプロイのハードルが下がった
- PoC -> MSの案件に展開 -> MS/AD前者に展開
- インフラ構築のボトルネック
- 従来はインフラ部門に依頼してやってもらってた
- その部門もパートナーに依頼してやってもらう
- 2-3ヶ月
- グループ全体でIT構造最適化の流れ
- クラウド基盤強化
- 自分たちでインフラを作れる状況に
- 従来はインフラ部門に依頼してやってもらってた
- アジャイル体制の課題
- 開発がパートナーに依存
- 開発領域の担当が分かれて縦割り
- チームが自己完結できていない
- 内製化へ
- テックリードの採用へ
- 1人目が大事
- 少人数の内製からスタート
- インフラの完全内製化
- 構築期間2倍短縮
- 圧倒的なコスト削減
- アプリは60%くらい内製
- テックリードの採用へ
SIerが語る内製開発のすすめ──今こそビジネスの主導権を取り戻せ！
添田 直之さん(富士通株式会社)
- 内製化が難しい？
- 内製開発の対象があってないのかも
- 誰にどんな価値を提供するのかの意思決定の内製化が必要
- ビジネスの成功
- 顧客価値と事業価値の両立
- 日本企業は事業価値が優先されがち
- アジャイル実践事例
- ビジネス
- ビジネスサイドからPOを選出
- 社内受託ではなくアウトカムを追求
- 組織
- 自律的なチーム
- マネジメントが口を出しすぎない
- ビジネス
- 生成AIに対する捉え方
- 日本は便利ツールのいきをでない
- 海外はゲームチェンジャーとして扱ってる
- 目指す姿
- 従来はITベンダー依存
- これからはビジネス部門がイニシアチブ
- そのために
- ビジネス部門の積極的なデジタル適用
- アジャイル型のプロダクトエンジニア
- 事前計画型のプロジェクトマネジメントではなく
- 内製化範囲を定義してケイパビリティを強化する
- ビジネス部門からプロダクトオーナー
- IT部門からアーキテクチャリード
- 富士通の事例
- 従来は人月のプロジェクト型のビジネス
- これからはプロダクト型で共創するビジネス
住友生命「Vitality」に学ぶ内製化・内製開発で実現する顧客価値と事業×システム創造
岸 和良さん(住友生命保険相互会社)
- 住友生命のデジタル&データ本部
- DXマインドセット研修
- 顧客価値についての連載
- 書籍出版
- なぜ内製化がいいのか
- 試して公開して改善して修正するサウクルが早いから
- スキル・ノウハウが組織に残る
- 新しい技術を試しやすい
- コア人材を調達する課題が少ない
- コストコントロールがしやすい
- 顧客の声を理解し価値を作りやすい
- 伝統企業は顧客価値が低いことが多い
- ユーザから遠い
- 真の要件提示者がいない
- 要件通りに正確に作ることが義務付けられる
- ユーザに聞かずに部長や役員に聞く
- サイロ化した組織と心
- ユーザ視点が消えて組織に無難なシステム
- コンサルに提案してもらっても稟議を回す間に無難になる
- ユーザを楽しませる知識やスキルがない
- 楽しいUXや使い続けたくなるUXを知らない
- ユーザから遠い
- 体制や取り組み
- 社長直轄の3つのCoE
- デジタル人材育成
- 生成AI研修を内製で
- 生成AIコンテスト
- ビジネスモデルと顧客価値
- 4つのビジネスモデル
- デジタル集客系、マッチング、マーケットプレイス
- デジタル商材系
- リアルビジネス+デジタル
- リアルビジネス
- 顧客価値重視のアプローチ
- パーソナライズ指向
- 最小コスト最大ベネフィット指向
- レコメンド指向(他人の意見)
- 価値 = ベネフィット / コスト
- 4つのビジネスモデル
