20年超レガシー「バイトル」をAI駆動で再設計！事業成長を実現するリアーキ戦略

20年以上続く求人サービス「バイトル」。この巨大モノリスと日々向き合い、私たちは事業成長を続けながら大規模リアーキテクチャに挑んでいます。「働く人や企業」の課題を技術で解決する社会的意義を胸に、AIネイティブを前提とした開発体制とアーキテクチャ刷新を実現。既存システムと共存しつつ、複雑な技術負債の解消、ドメイン再設計、マイクロサービス移行の意思決定──。持続可能性とスケーラビリティを両立させるこの戦略と、変革を推進した組織のリアルを共有します。

Transcript

1. 20年超レガシー「バイトル」をAI駆動で再設計！ 事業成⻑を実現するリアーキ戦略 ディップ株式会社 執⾏役員CTO ⻑島 圭⼀朗 2025年11⽉20⽇
2. ⻑島 圭⼀朗 Keiichiro Nagashima ディップ株式会社 執⾏役員CTO 2024年よりディップに参画 アドテク‧EC‧ソーシャルゲーム ‧IoT‧SaaSなど様々なサービス の企画開発を経験 現在はレガシーシステムとの格 闘、そしてAIネイティブな組織づ くりに奮闘中
3. Copyright © DIP Corporation, All rights reserved. 本⽇お話しすること 40分で伝える、巨⼤レガシー再⽣の「⽣々しい」プロセス 我々が直⾯した「技術的迷宮」というピンチ アーキテクチャ選定における「泥臭い議論」のプロセス AI駆動開発（AI-DLC）の「光と影」 最も困難だった「組織変⾰」のリアル
4. AIネイティブな組織づくり 04 組織：変⾰を推進した体制 Agenda なぜ変える必要があったのか 01 導⼊：直⾯した現実と、共感 3つの重要な意思決定 02 戦略：アーキテクチャの意思決定 AI-DLCによる開発⾰命 03 戦術：AI駆動開発のリアル 05 まとめ
5. ディップ株式会社 2000年：  インターネットの家庭普及率が18%の時代   求⼈広告業界初の「ポータルサイト」が誕⽣ 2010年：  スマホ普及率が4%でガラケー全盛期の時代  動画で仕事を探せる機能をバイトルに実装  2019年：  ユーザーの働く課題を解決するために、  AI‧RPAを活⽤したDXサービスを開始 2024年：  ⽇本初のAIと対話型バイト探しサービス  『dipAI』を時代に先⽴ってリリース
6. × “誰もが働く喜びと幸せを感じられる社会” Labor force solution company VISION Human work force solution ユーザーファーストな独⾃機能を搭載した、 求⼈情報‧⼈材紹介サービスの提供を通じて、 ユーザーの就業課題を解決しています。 ⼈材サービス事業 Digital labor force solution バイトコミュニケーションアプリ『バイトルトーク』や、 機能を絞ったシンプルなSaaS型の『コボット』を通じて、 職場環境やコミュニケーション課題を解決しています。 DX事業
7. Copyright © DIP Corporation, All rights reserved. 採⽤、定着、ブランディングまで 労働課題のトータルソリューションを実現
8. 第1章 導⼊：直⾯した現実と、共感 なぜ変える必要があったのか？
9. Copyright © DIP Corporation, All rights reserved. 「技術的負債」？ いいえ、 「技術的迷宮」でした 20年の蓄積が⽣んだ、誰も全貌を知らない巨⼤システム
10. Copyright © DIP Corporation, All rights reserved. 事業は成⻑、しかしシステムは限界へ 2000年代初頭から稼働する、モノリシックなアーキテクチャ ⻑年の機能追加により、コードベースは極度に複雑化‧肥⼤化 事業戦略のスピードにシステムの変更速度が追いつかない状態 20年超の歴史を持つ巨⼤レガシーシステム
11. Copyright © DIP Corporation, All rights reserved. システムが抱えていた3つの構造的負債 成⻑の代償としての「技術的迷宮」 壊れやすいシステム 影響範囲を完全には⾒ 通 せないまま、デプロ イボタンを押す重圧 迷宮探索のコスト コードを 書 く 時 間 よ り、迷宮のような依存 関係を「調査」する時 間が圧倒的 組織のサイロ化 ビジネスと開 発が「異 なる⾔語」で話し、全 体最適より部分最適が 優先される
12. Copyright © DIP Corporation, All rights reserved. 1つの 修 正 がどこに 影 響するか、誰も全体像 を把握できていない テストコードが 不 ⾜ し、デグレを 恐 れて 「 触 れない」コードが 増加 特定の古参メンバーし か 触 れない「ブラック ボックス領域」が多数 存在 現場から聞こえてきた「悲鳴」 開発チームが直⾯していた「苦しさ」の具体例 密結合の恐怖 テストの形骸化 属⼈化の極み
13. Copyright © DIP Corporation, All rights reserved. 3 事業戦略とアーキテクチャの「ズレ」 「単品売り切り」から「セットメニュー」への構造転換 管理⽅法： 各プロダクトが独⽴した「単品」管理 顧客体験： バラバラのID‧管理画⾯ 管理⽅法： 統合基盤による「パッケージ」管理 顧客体験： 単⼀のID‧統合ダッシュボード 現状 (クロスセル構造) ⽬指す形(アップセル構造)
14. Copyright © DIP Corporation, All rights reserved. ⼩⼿先の改善（リファクタリング）では、もはや追いつかない 事業の未来を⽀えるためには、抜本的な再設計（リアーキテクチャ） が必要不可⽋ しかし、ただ作り直すだけでは、10年後に同じ迷宮が⽣まれるだけ 我々は「3つの⼤きな意思決定」を⾏った このままでは事業成⻑を⽀えられない 我々に残された道は「再設計」のみ
15. Copyright © DIP Corporation, All rights reserved. 「事業成⻑」と「持続可能性」を両⽴させるため 私たちが下した3つの意思決定を共有します 戦略 Architecture 戦術 AI-Process 組織 Team 事業の「ズレ」を直 すためのドメイン再 設計と技術選定 AIを前提とした新し い開発プロセス 「AI-DLC」の導⼊ 変⾰を推進する「AI ネイティブ」な体制 と役割の再定義 我々が⽬指した3つの変⾰
16. 第2章 戦略：アーキテクチャの意思決定 3つの重要な意思決定
17. Copyright © DIP Corporation, All rights reserved. 奇をてらった技術は使わない ただし⽬先の負債解消だけでは、数年後に再びレガシー化する 「事業のズレ」を解消し、営業‧開発‧運⽤の効率を最⼤化する AIによる開発⽀援を「前提」としたアーキテクチャを採⽤する 全体設計思想：事業成⻑とAIネイティブの両⽴ 単なる負債解消ではなく、戦い続けられるシステム を⽬指す
18. Copyright © DIP Corporation, All rights reserved. 構造の転換：技術駆動からドメイン駆動へ コードの構造を「ビジネスの形」に合わせる MVC/Layered：技術的役割でフォル ダを分割（Controller, Model...） 機能凝集：ビジネスの⽂脈が分散 し、機能変更の影響が⾒えにくい モノリシックな思考：全てが繋がり 合い、変更が全体に波及する Bounded Context：ビジネス領域ご とに境界を定義（求⼈, 応募...） ドメイン凝集：関連するロジックを ⼀箇所に集め、変更を局所化 モジュラーな思考：境界内は密結合 でも、境界外とは疎結合に保つ Before: 技術駆動 After: ドメイン駆動
19. Copyright © DIP Corporation, All rights reserved. OpenAPI + REST を正式採⽤ BFF (Backend for Frontend) の原則廃⽌ SDKの⾃⽣成 RESTへの統⼀とBFFの原則廃⽌ Web / Mobile / AIチームが疎結合に開発できる体制へ
20. Copyright © DIP Corporation, All rights reserved. KMP (Kotlin Multiplatform) の導⼊ デザインシステムの構築とコンポーネント統⼀ UIとロジックの共通化 Web/Mobile間での分断を防ぎ、⼀貫した体験と開発効率を実現
21. Copyright © DIP Corporation, All rights reserved. 当初は、Webとモバイルアプリの差異を吸収するため、BFFの導⼊を検討 しかし、開発‧保守コストの増加、レイテンシへの懸念が浮上 「フロントエンドの要求を待つ 必要があり、開発が律速するのでは？」 「BFF⾃体の保守コスト が、メリットを上回るのではないか？」 論点1：BFFは本当に必要か？ 「BFFいらない説」の台頭
22. Copyright © DIP Corporation, All rights reserved. フロントエンドごとに最適化された APIを提供できる バックエンドのドメインロジックを 隠蔽できる Web/Mobileの要求差異を吸収できる 開発‧保守コストが単純に増加する あ BFFの開発がボトルネックになる可能 性 アーキテクチャが複雑化し、ドキュ メント管理が煩雑になる BFF導⼊のメリット vs デメリット 当時の議論ログから抜粋 メリット（期待） デメリット（懸念）
23. Copyright © DIP Corporation, All rights reserved. 原則廃⽌ ただし以下の条件で限定導⼊可: - 認可処理の変換 (例: トークン切り 替え) - Web/MobileでIF分離が必須な場合 アーキテクチャのシンプル化 開発‧保守コストの削減 APIの独⽴性‧再利⽤性の担保 BFF導⼊のメリット vs デメリット BFF⽅針 採⽤理由 開発ガイドラインへの明記
24. Copyright © DIP Corporation, All rights reserved. 案A（APIシステムで集約） 汎⽤APIが画⾯都合を知りすぎ、「神API化」する恐れ（責務違反） 案B（アプリで直叩き） 通信回数増⼤、ロジック分散、認証トークン管理の複雑化 気づき 「純粋なデータ（CRUD）」と「画⾯⽤オーケストレーション」の間の空⽩ しかし、現場から「待った」がかかった ビジネス要求の問題と、ドメインAPIシステムの純潔性
25. Copyright © DIP Corporation, All rights reserved. 激論：CTO vs 現場エンジニア BFFは「DRY（重複排除）」よりも「Decoupling（疎結合）」 BFFの共有を⽬指しては？ ⼯数削減‧効率化 「⾞輪の再発明」は避けたい Web/アプリでライフサイクルが違う 無理な共有は「密結合」のリスク UIが異なるならBFFも分けるべき CTOの提案 (効率重視) 現場の反論 (独⽴性重視)
26. Copyright © DIP Corporation, All rights reserved. 着地：BFF 2.0（現代的な再定義） 「ロジック」は持たせず、集約と認証に徹する 複数サービスからの 応答を束ねる 認証を⼀⼿に引き受け るGateway。 裏側のAPIをセキュア に保つ アプリチームは Ktorを採⽤。 ⾔語統⼀でコンテキス トスイッチを排除 集約 認証 変換
27. Copyright © DIP Corporation, All rights reserved. BFF不採⽤を前提とし、API設計の議論がスタート フロントエンドからは「⾃由にデータ取得できるGraphQL」を推す声 バックエンドからは「更新時のテストや管理の複雑性」への懸念 論点2：API設計 (GraphQL vs REST) 銀の弾丸か、新たな複雑性か
28. Copyright © DIP Corporation, All rights reserved. 学習コスト ▲ ⾼い (メンバーの負担⼤) ◎ 低い (全員が知っている) 複雑性 ▲⾼い (N+1、キャッシュ設計が難解） ◎ シンプル (HTTPの原則通り) ⾃動⽣成 △ クライアント側のみ ◎ サーバー/クライアント双⽅向 結論 柔軟だが、今の我々には Too Much 「堅実」かつ「最速」の選択 GraphQL vs REST 徹底⽐較 我々のユースケースにおける評価 GraphQL REST (OpenAPI)
29. Copyright © DIP Corporation, All rights reserved. API定義を「OpenAPI」で厳密に⾏うことを決定 OpenAPIスキーマから、サーバーサイドのコード と クライア ントSDK を⾃動⽣成 TypeSpecの導⼊も検討、スキーマ定義の体験向上も追求 APIはインテグレーションテストに注⼒すべきという合意形成 結論：OpenAPI + RESTを採⽤ スキーマ駆動開発による堅牢性の確保
30. Copyright © DIP Corporation, All rights reserved. レガシーシステムでは、認証基盤は完全に内製（秘伝のタレ 状態） セキュリティリスク と 保守コスト が極めて⾼い状態だった 再設計にあたり、マネージドサービスの活⽤を検討 最有⼒候補：AWS Cognito 論点3：認証基盤 内製開発 vs マネージドサービス (Cognito)
31. Copyright © DIP Corporation, All rights reserved. 認証‧認可の責務をAWSにオフロー ド。MFAやSAML連携も容易 ⾞輪の再発明（認証機能の内製）を 避け、コアビジネスにリソースを 集中 Cognito採⽤の決め⼿ インフラ議論のログより セキュリティとスケーラビリティ 開発リソースの集中
32. Copyright © DIP Corporation, All rights reserved. コンテナ基盤：Amazon ECS (Fargate) を採⽤ 認証基盤：AWS Cognito API：OpenAPI (REST) で定義 CI/CD：GitHub Actions, CodeDeploy データベース：Amazon Aurora (スケールアウト対策を議論) （参考）インフラ全体のアーキテクチャ Fargate, Cognito, OpenAPI (REST) を採⽤した構成 マネージドサービス と サーバーレス を推進し、運⽤負荷 を最⼩化する戦略
33. Copyright © DIP Corporation, All rights reserved. 新規開発領域で Nxを導⼊ モジュール間の依 存を制御し、スパ ゲッティ化を防⽌ モジュール単位で 独⽴ビルド‧デプ ロイ可能な体制を 構築 巨⼤モノリスと共 存しながら、秩序 だった移⾏を実現 モノレポによる「秩序ある」リアーキ 既存システムと共存しつつ、安全に移⾏を進める モノレポ採⽤ 依存関係の可視化 CI/CDの分離 安全な移⾏
34. Copyright © DIP Corporation, All rights reserved. 単なる負債解消ではない。5、10年後を⾒据え、設計思想そのものを変えた 「AIツールを前提に設計 →実装→テストの全工程を支援する」 ユニットテストカバレッジ常時80%以上を維持 AI活⽤を組み込んだ開発フロー ドキュメント⾃動更新の仕組み テストの全⼯程を⽀援 「AIが前提」のアーキテクチャ 開発ガイドラインのゴールに「AIネイティブ」を明記
35. 第3 章 戦術：AI駆動開発プロセスのリアル AI-DLCによる開発革命
36. Copyright © DIP Corporation, All rights reserved. 全員の悩み：「AI、どう使えばいい？」 AI活⽤は「悩みの宝庫」 Q. AIを導⼊したいが、そもそも使えていない A. 私たちも最初はそうでした Q. 育成コストやROI（投資対効果）が⾒えない A. 「どこで」使うかが重要です Q. AIの品質をどう測ればいいか分からない A. 私たちの解は「AI-DLC」でした
37. Copyright © DIP Corporation, All rights reserved. STEP 1 抽象的な要求 STEP 2 AIがユーザーストーリー⽣成 STEP 3 AIが受⼊基準を策定 STEP 4 AIがタスク分解 AI-DLC (AI-Driven Development Life Cycle) 単なるCopilot導⼊ではない。「上流⼯程」からAIを組み込む
38. Copyright © DIP Corporation, All rights reserved. 要求をヒアリング ユーザーストーリーを⼿動作成 受⼊基準（AC）を定義 タスクに分解 抽象的な要求をAIに⼊⼒ AIがユーザーストーリーを⾃動⽣成 AIが受⼊基準を⾃動⽣成 AIがタスク分解まで⽀援 事例：AIによる要件定義の効果 従来のプロセス AI-DLCのプロセス 従来のプロセスとの⽐較
39. Copyright © DIP Corporation, All rights reserved. 事例：AIによる要件定義の効果 従来のプロセス AI-DLCのプロセス 従来のプロセスとの⽐較 数⽇〜数週間 ⼿動でヒアリング、作成、分解 数時間 AIが⾃動⽣成、⼈間はレビュー
40. Copyright © DIP Corporation, All rights reserved. 実際のプロンプトの⼀部 + Claude 4.5 Sonnet
41. Copyright © DIP Corporation, All rights reserved. 要件定義の時間が劇的に短縮され、開発チームは 「価値ある実装」に集中できるようになった。 開発体験が「10倍」⾼速化した。。。
42. Copyright © DIP Corporation, All rights reserved. 成功体験 (光) だけで終わらないのが、 レガシーシステム変⾰のリアル AI-DLCを全社的な取り組みにスケールさせようとした時、 我々は「3つの⼤きな壁」に直⾯した しかし、現実は⽢くなかった AI-DLC導⼊の「影」の部分
43. Copyright © DIP Corporation, All rights reserved. AI活⽤の前に⽴ちはだかる「3つの壁」 AI-DLCの理想と現実 ドメイン知識の壁 DDDの学習コスト レビューのボトルネック化
44. Copyright © DIP Corporation, All rights reserved. AIは⼀般的な知識は豊富だが、20年モノの複雑な独⾃ドメイ ン は知らない AI-DLCを試⾏した現場からは「ドメインが絡むとAIのパ フォーマンスが著しく悪化する」という悲鳴（メンバーの声 より） AIにどうやって効率よくドメイン知識をインプットするかが 課題となった 壁1：ドメイン知識の壁 「AIが既存の複雑なドメインを理解できない」
45. Copyright © DIP Corporation, All rights reserved. Q. 既存の複雑なコードやドメイン知識を、どう効率よくAIに インプットすればいい？ A. 当時は有効な⼿段がなく、⼿動でのプロンプト調整や、 Unit of Work作成時に都度参照させるしか⼿がなかった 現場のリアルな疑問 (AI-DLCアンケートより) ドメイン知識のインプットに関する悩み
46. Copyright © DIP Corporation, All rights reserved. AIに正しく指⽰を出すためには、⼈間が「ビジネスの本質 （ドメイン）」を理解し、整理する必要がある そのための⼿法として「ドメイン駆動設計（DDD）」の導⼊ を決定 しかし、DDD⾃体の学習コストが⾮常に⾼く、「DDDの導⼊ ⾃体が苦⾏」となってしまった 壁2：DDDの学習コスト 「AIに“何を”作らせるかを定義できない」
47. Copyright © DIP Corporation, All rights reserved. AIはユーザーストーリーやタスクを⾼速で⼤量に⽣成する しかし、そのアウトプットの妥当性を判断し、意思決定する のは、結局「⼈間」 「開始スコープが⼤きすぎて⼈間が把握しきれず、レビュー がボトルネックになった」 壁3：レビューのボトルネック化 「AIの⽣成速度に、⼈間のレビューが追いつかない」
48. Copyright © DIP Corporation, All rights reserved. AIは速度を上げるが、変⾰の「痛み」や「泥臭いプロ セス」を無くしてくれるわけではない。 AIは「銀の弾丸」ではなかった
49. Copyright © DIP Corporation, All rights reserved. ⼈間：指導レビュー役 AIの⽣成物をレビュー し、意思決定する AI：アナリスト役 要件定義‧タスク分 解 AI：アーキテクト役 設計‧コード⽣成 （フック）マルチエージェントへの我々の解釈 AI-DLCは「開発プロセスにおけるマルチエージェント」的アプローチ
50. 第4 章 組織：変革を推進した体制 AIネイティブな組織づくり
51. Copyright © DIP Corporation, All rights reserved. 最⾼のアーキテクチャ と 最先端のAIプロセス を導⼊しても、 それを使う「組織」が変わらなければ意味がない レガシーシステムの改修と、AIを活⽤した新規開発をどう両 ⽴させるか？ 我々は、組織構造そのものにAIを組み込むことを決断した AIネイティブな組織変⾰ 技術とプロセスを「使いこなす」ための組織
52. Copyright © DIP Corporation, All rights reserved. AI-DLCプロセスの標準化 全社的なAIナレッジ共有 PO 開発者複数名 AI-Enablement担当 デザイナー/SRE アーキテクチャ変⾰は「組織変⾰」である 各開発チームに「AI推進者」を配置 中央AI推進室 各開発チーム (A, B, C...)
53. Copyright © DIP Corporation, All rights reserved. AI-DLCの導⼊は、開発者の役割そのものを変えた 単純なコーディング作業（How）はAIが担う割合が増加 開発者の役割は、「何を作るべきか」（ドメイン定義）や 「AIの⽣成物をレビュー‧指導する」こと（意思決定）へ シフト 開発者の役割はどう変わったか？ 「コーダー」から「AIのレビュアー/指導者」へ
54. Copyright © DIP Corporation, All rights reserved. 要件を理解し、コードに翻訳する ボイラープレートコードを書く ドキュメントを探し、読む AIに正しい指⽰(プロンプト)を出す AIの⽣成物をレビューし、最適性を 判断する ビジネス価値を最⼤化する「意思 決定」に注⼒する 役割の再定義：開発者の「価値」の変化 AI-DLCを経て、私たちの仕事は「書く」から「決める」へ Before：コードを書く⼈ After：AIを指導‧レビューする⼈
55. Copyright © DIP Corporation, All rights reserved. もちろん、この変⾰は簡単ではありません 現場では、⽇々「泥臭い」試⾏錯誤が繰り返されています これは、あるチームの振り返り（Keep/Problem/Try）の様⼦ です 現場の「泥臭い」試⾏錯誤 組織変⾰は⼀⽇にして成らず
56. Copyright © DIP Corporation, All rights reserved. AI-DLCによるタス ク化が定着してき た レビュー負荷が特 定の⼈に集中 ドメイン知識の暗 黙知が多い レビュー担当の ローテーション ドメインの図解を 優先的に進める あるチームのKPT (Keep/Problem/Try) Keep Problem Try
57. Copyright © DIP Corporation, All rights reserved. ドメイン知識の暗黙知を解消するため、我々は「すべての議 論をAIの知識に変える」仕組みを構築しました 会議の議事録、Slackの議論、設計ドキュメント（ADR）... これら全てをAIが検索‧回答できるナレッジベースに格納 議論を「知識」に変える仕組み ドキュメントは「⼈が探す」ものから「AIが使う」ものへ
58. Copyright © DIP Corporation, All rights reserved. フロー情報のストック化 「過去の議論」が「即戦⼒の知識」へ これまで ➡ 議論と結論が分断され、「なぜその決定に⾄った か」という背景情報が失われていた。 NotebookLM導⼊後 ➡ 議論ログや作成した図を「そのまま⾷ わせる」だけで、AIが⽂脈を理解したナレッジベース化。 ドキュメント作成のコストをかけずに、組織の「記憶の解像 度」を劇的に向上させた。 ※Google Workspace Enterprise版を利用し、入力データは学習に利用されない設定で運用 ※個人情報・機密情報はマスキング処理済み
59. Copyright © DIP Corporation, All rights reserved. 劇的ビフォーアフター：仕様確認の⾰命 「未来の⾃分」を救うためのアーカイブ 仕様確認に数⽇：担当者を探し出 し、記憶を頼りにヒアリング 「なぜ？」が迷宮⼊り：「3年前の決 定だから誰も知らない」 ドキュメントが形骸化：更新が追い つかず、誰も読まないWiki AIへの質問で30秒：チャットで聞け ば、即座に議論の経緯を回答 背景まで完全回答：「あの時の懸念 点は何か」までAIが解説 ⽣データ活⽤：SlackログやFigmaを 放り込むだけ。作成コストゼロ Before（これまで） After (NotebookLM導⼊)
60. Copyright © DIP Corporation, All rights reserved. 会議開催 Geminiで⽂ 字起こし PDF化 Notebook LMへ格納 DesignDoc/ ADR作成 GitHub / Notion管理 完了‧合意 Notebook LMへ格納 AIによる「知識型ADR」の実現 すべての意思決定を「AIが検索‧回答できる知識」に変える
61. Copyright © DIP Corporation, All rights reserved. 「なぜこの技術を選んだ？」 「この変更の背景は？」 これらの質問に、AIがチャットで即座に回答する ドキュメントは「⼈が探す」ものから「AIが使う」ものへ 「なぜ？」にAIが答える開発⽂化 「あの仕様どうなった？」を探す時間をゼロにする
62. Copyright © DIP Corporation, All rights reserved. BFF廃⽌、OpenAPI採⽤、Cognito採⽤… 「泥臭い議論」のプロセスを経て、我々は「開発ガイドライ ン」を策定しました なぜこの技術を選ぶのか を明⽂化し、組織全体の⽬線を合わ せる 開発ガイドライン策定までの道のり 議論の「結果」を「ルール」として明⽂化
63. まとめ 第5 章
64. Copyright © DIP Corporation, All rights reserved. 戦略（Architecture） 事業の「ズレ」を直すため、DDDとOpenAPIで再設計。議論のプロセスを重視 戦術（AI-DLC） 「光と影」を直視し、ドメイン知識とレビューの課題に向き合う 組織（Team） 開発者の役割を再定義し、議論を「知識」に変える⽂化を醸成 20年超のレガシーは「AI駆動」で再設計できる 私たちが下した「3つの意思決定」
65. Copyright © DIP Corporation, All rights reserved. 我々が「技術的迷宮」と呼んだレガシーシステム しかし、そこに蓄積された 20年分のドメイン知識 や 議論の ログ は、⾒⽅を変えれば「AIにとって最⾼の教師データ」 レガシー資産は、もはや「負債」ではなく、未来のAIネイ ティブなシステムを⽣み出すための「資産」です レガシー資産は「負債」->「AIの教師データ」へ 20年の歴史は、未来への「資産」に変わる
66. Copyright © DIP Corporation, All rights reserved. 多くのエンジニアが「レガシーだから挑戦できない」と思っ ているかもしれません しかし、逆です レガシー × AI ほど、エンジニアとして⾯⽩く、インパクトの ⼤きい挑戦ができるフィールドはありません レガシーは、AIで挑戦できるフィールドだ
67. Copyright © DIP Corporation, All rights reserved. この変⾰を完遂するには、仲間が⾜りません 我々は戦略（AI-DLC）と武器（開発ガイドライン）を⼿に⼊ れましたが、対象となる「技術的迷宮」は広⼤です 「AIに任せること」と「⼈間が泥臭く解決すること」のバラ ンスを⾒極めるエンジニアが、今もっとも必要とされていま す 完成された組織ではありません。だからこそ、技術で組織を 変えるこの「過渡期」を⼀番楽しめます
68. Copyright © DIP Corporation, All rights reserved. dip テックブログ 
 挑戦の軌跡を発信しています ブースでもお待ちしています！ お気軽にお立ち寄りください