マルチドライブアーキテクチャ: 複数の駆動力でプロダクトを前進させる

アーキテクチャConference 2025の発表資料です

Transcript

1. マルチドライブアーキテクチャ： 複数の駆動⼒でプロダクトを前進させる 株式会社ログラス 鈴⽊ 健⼀  CTO室 ⼩林 達  プロダクト基盤部 アーキテクチャ Conference 2025
2. ⾃⼰紹介 鈴⽊ 健⼀ （Kenichi Suzuki） X: @_knih 新卒でNTTデータに入社。ミッションクリティカルシステム・大規模 基幹システムのアーキテクチャ設計や統括業務に従事した後、よ り堅牢な開発を求めて、プログラム言語理論（型システム、関数型 等）を研究。
 その後、Visionalにてサイバーセキュリティ事業の立ち上げからプ ロダクト開発をけん引した。ContractS株式会社にて開発部長、プ ロダクト部長、技術戦略室長、VP of Developmentを歴任。2023年 ログラスへ入社。 アーキテクチャConference 2024
3. 複数の異なる変化速度を 同時に扱うアーキテクチャをどう設計するか？
4. 本⽇のお品書き 前半 • 速度差が摩擦を⽣むという問題 • マルチドライブアーキテクチャ 後半 • 事例1：リアーキテクチャ • 事例2：共通基盤 まとめ 前半は 概念 に徹します 後半で 事例 をお話します
5. 板挟みになっていませんか？
6. 板挟みになっていませんか？ よくある板挟み ちゃんと設計しないと！ もっと速く、市場の変化に 追いつきたい、顧客ニーズを 満たしたい！ 正しいけど同時には満たせない AIに対応して！
7. 板挟みになっていませんか？ よくある板挟み 板挟み状態 短期 （速く進めたい） 中期 （整えたい） ⻑期 （未来へ備えたい）
8. 板挟みになっていませんか？ 事業変化によってアーキテクチャが限界になるリスク 異なる要求を同時に扱う必要性に迫られた 短期戦略 中期戦略 ⻑期構想 共通基盤等の標準化の要求 競争優位の核をつくる戦略的昇華 既存アーキテクチャが 限界になるリスク 既存プロダクトの価値強化
9. 正体は異なる時間軸
10. 異なる時間軸を扱う マルチドライブアーキテクチャ
11. それぞれ異なる時間軸で動いている
12. 異なる時間軸を扱うマルチドライブアーキテクチャ 異なる時間のスケール 関⼼事によって時間のスケールが異なる ⋯ ⋯ 短期 中期 ⻑期 （2〜5年） （3ヶ⽉〜2年） （数週〜3カ⽉）
13. 異なる時間軸を扱うマルチドライブアーキテクチャ Anthonyの経営管理の3階層 異なる時間軸で動く3階層 戦略計画 （Strategic） 管理統制 （Management） 業務統制 （Operation） Anthony, R. N. (1965). Planning and Control Systems: A Framework for Analysis. Harvard Business School Press. Anthonyの3階層 ⻑期 （数年） 中期 （四半期〜年） 短期 （⽇〜週〜⽉） 時間軸 関心事 競争優位の構築 組織の⽅向性 効率的な資源配分 戦略の実⾏保証 ⽇常業務の効率化 タスクの遂⾏
14. 異なる時間軸を扱うマルチドライブアーキテクチャ 経営理論の3階層と、3つの駆動 戦略計画 （Strategic） 管理統制 （Management） 業務統制 （Operation） 共通基盤等の標準化の要求 競争優位の核をつくる 戦略的昇華 既存プロダクトの価値強化 変化による要求 （関心事の違い） アンソニーの 3階層 異なる時間軸はどこ から来るのか
15. 異なる時間軸を扱うマルチドライブアーキテクチャ 経営理論の3階層と、3つの駆動 ビジョン駆動 （V; Vision） イネーブルメント駆動 （E; Enablement） オポチュニティ駆動 （O; Opportunity） 戦略計画 （Strategic） 管理統制 （Management） 業務統制 （Operation） プロダクトの羅針盤 競争優位の源泉 開発効率の向上・強化 ビジネス最前線の 機会対応 長期 中期 短期 アンソニーの 3階層 対応する駆動力 各階層を駆動する力 の源泉は？
16. 異なる時間軸を扱うマルチドライブアーキテクチャ 経営理論の3階層と、3つの駆動 ビジョン駆動 （V; Vision） イネーブルメント駆動 （E; Enablement） オポチュニティ駆動 （O; Opportunity） 戦略計画 （Strategic） 管理統制 （Management） 業務統制 （Operation） プロダクトの羅針盤 競争優位の源泉 開発効率の向上・強化 ビジネス最前線の 機会対応 長期 中期 短期 共通基盤等の標準化の要求 競争優位の核をつくる 戦略的昇華 既存プロダクトの価値強化 変化による要求 （関心事の違い） アンソニーの 3階層 対応する駆動力 異なる時間軸と関⼼事を、互いに阻害せず並列に動かすため、 駆動⼒で分離する
17. multi-drive ひとつの対象やシステムが、複数の独⽴した駆動源や原動⼒によって 同時に動かされている状態。 あるいは、複数のドライバーが独⽴して動くしくみ。
18. 異なる時間軸を扱うマルチドライブアーキテクチャ マルチドライブ、3つの駆動 ビジョン駆動 （V; Vision） イネーブルメント駆動 （E; Enablement） オポチュニティ駆動 （O; Opportunity） 未来への道筋をつくる つくる力を強くする いまの価値を生む 長期 中期 短期
19. 異なる時間軸を扱うマルチドライブアーキテクチャ オポチュニティ駆動（顧客‧市場に向き合うアジリティ） 顧客や市場からの機会（Opportunity）に直接対応し、新しい価値を素早く創造・検証 ・提供する駆動力 MVP Growth 新規アプリA 新規アプリB 既存アプリA 既存アプリB ・・・ ・・・ 不確実性 価値の最大化 不確実性の 解像度が変化する オポチュニティ駆動に投資すると、不確実性を解像し、ポテンシャルを価値に変換できる
20. 異なる時間軸を扱うマルチドライブアーキテクチャ イネーブルメント駆動（アジリティを⽀える開発効率） 開発効率を担保し、安定性を確保する駆動⼒ スピードの持続 開発効率の最⼤化 基盤の⼀貫性 認証基盤 権限制御 Agentic RAG ⋯ プロダクト横断でなくてはならないケイパビリティを提供する イネーブルメント駆動に投資すると、オポチュニティ駆動領域の価値創出が速く‧安全になる
21. 異なる時間軸を扱うマルチドライブアーキテクチャ ビジョン駆動（アジリティのベクトルを定める羅針盤） ⻑期的な戦略やビジョンを具現化し、プロダクト全体の⽅向性をつくる駆動⼒ ビジョン駆動に投資すると、将来的に取れる市場⾯積そのものが広がる 成⻑領域の開拓 ⻑期の⽅向性と筋道の構築 持続的な競争優位性の構築 どこへ⾏くか （どの領域で勝つ か） なぜそこへ⾏くか （勝つ理由） 何を前提とするか （勝てる条件） 何に投資するか （勝つために必要な 武器は何か） 何を捨てるか （勝つために戦わな い領域はどこか）
22. 異なる駆動をつなぐ テンションとクラッチ
23. 異なる駆動をつなぐ 遅い変化と速い変化の衝突 二項対立は負債を生み、成長の足かせになる テンション（歪み） 市場ニーズ、価値検証 遅い変化 速い変化 遅い変化を優先した場合： （スピードを犠牲にしがち） 機会損失という事業的負債が⽣まれる 速い変化を優先した場合： （品質を犠牲にしがち） 技術的負債が⽣まれる 安定性、品質保証
24. 異なる駆動をつなぐ テンションとは 異なる時間軸を持つ関⼼事が、混在あるいは不適切に接続されていることで⽣じる 歪みや摩擦のこと テンションは⼀種のサイン 速度差があり、境界の設計が必要だというアラート テンションは、後述するクラッチで吸収していく テンション （歪み） 中期（あるいは⻑期） の時間軸 短期の時間軸 優先順位は？？ 技術的負債はいつ 解消する？
25. 異なる駆動をつなぐ 異なる時間軸を調整するクラッチ 駆動間のテンションを吸収する境界を設ける 速度差はテンションを⽣む ならば吸収する仕組み（＝クラッチ）が必要 中期（あるいは⻑期） の時間軸 短期の時間軸 テンションを 吸収するクラッチ
26. 異なる駆動をつなぐ 参考）クラッチのイメージ エンジン エンジン クラッチによって速度差を吸収する
27. 異なる駆動をつなぐ クラッチの具体、２種類のクラッチ 技術的クラッチの他に、組織的クラッチも効果的 技術的クラッチ 組織的クラッチ • 共有ライブラリ • API • ⾮同期化 • フィーチャーフラグ • イベント駆動 • マイクロサービス etc. • ロードマップ同期 • 責務の境界付け • 優先順位のプロセス • 設計レビュー • 技術的負債の返済ルール • フィードバックループの設計 etc.
28. 共有ライブラリ フィーチャーフラグ API (REST, gRPC) ⾮同期化(キューイング) イベント駆動 マイクロサービス コスト（ρ） 効果（η） クラッチ（分離）のトレードオフ 効果が⾼いほど 導⼊‧運⽤コストも⾼くなる
29. 異なる駆動をつなぐ テンションの変換モデル 削減効果 分離コスト T: テンション ⋯ 組織の速度差が原因で生じる摩擦を定量化したもの η: 変換効率 ⋯ テンションをどれだけ削減できるか ρ: 内部抵抗 ⋯ クラッチの導入やメンテに掛かるコストや複雑性 例：マイクロサービスは変換効率が高いが、内部抵抗も高い 改善前テンション 純改善後テンション コスト 改善前 改善後 クラッチの削減効果と追加コストを意識する
30. クラッチ導入の損益分岐点 テンションが⾼い場合は マイクロサービスのほうが有利 テンションが低い場合は 軽量な境界のほうが有利 テンションが低いのに 重厚な境界を設けると逆効果
31. 体制とアーキテクチャのイメージ
32. 体制とアーキテクチャのイメージ マルチドライブとチームトポロジー コンプリケイテッド・サブシ ステムチーム プラットフォームチーム ストリームアラインドチーム イネイ ブリン グチー ム ファシリ テーション X -as-a-Service X -as-a-Service ビジョン 駆動領域 オポチュニティ 駆動領域 イネーブルメント 駆動領域 異なる時間軸を扱う概念がチームトポロジーとの⼤きな差 ？
33. オポチュニティ イネーブルメント ビジョン 共通基盤 体制とアーキテクチャのイメージ アーキテクチャイメージ ドメイン基盤 データ基盤 App1 App2 … AppN AI エージェント 関⼼事と変化速度で駆動領域を分ける コンテキスト 基盤 エージェント 基盤
34. 前半のまとめ：マルチドライブアーキテクチャの3原則 原則1：分離の原則（Separation） 異なる時間軸を混ぜない  短期‧中期‧⻑期の関⼼事を不⽤意に混ぜると、速度差による「テンション （歪み）」が⽣まれ、双⽅の良さを殺してしまう。まずは時間軸で切り分ける 原則2：駆動の原則（Drive） 3つのエンジンを持つ  ビジョン(V)、イネーブルメント(E)、オポチュニティ(O)。役割の異なる3つの駆動 ⼒を定義し、それぞれを最適な速度で⾃律的に回す 原則3：接続の原則（Connection） クラッチでつなぐ  速度差を吸収する「クラッチ（境界）」を設け、コストと効果の損益分岐点を⾒極め て適切に接続する
35. マルチドライブアーキテクチャ 事例紹介 x2
36. 事例紹介の前に ⼩林 達（Satoshi Kobayashi） 略歴 ディーバ (2004 〜 2014) 連結会計製品の導⼊‧開発 ビズリーチ (2014 〜 2024) HRMOS採⽤‧評価の⽴ち上げ（開発部⻑） ログラス (2024 〜) リアーキテクチャ、共通基盤（EM） 好きなモデル Composer 1 趣味 娘とキャンプ、カメラ、⽇本酒
37. 事例 1/2: 基幹製品のリアーキテクチャ
38. 事例 1/2: 基幹製品のリアーキテクチャ 事例 1: 基幹製品のリアーキテクチャ ログラスは、昨年末よりリアーキテクチャリ ングに⼤きな投資をしています。 リアーキテクチャの結果、データ分析基盤が 誕⽣しました（記事参考）。 最⼩のリスクで最⼤のインパクトをどう実現 しようとしてきたか、マルチドライブアーキ テクチャの視点で振り返ってみます。 https://note.com/loglass_post/n/n04d559e729c5
39. 事例 1/2: 基幹製品のリアーキテクチャ モノリシックなアーキテクチャの限界が⾒え始めた • 創業より6年、モノリスが中⼼ • DDD、クリーンアーキテクチャの徹底により内部品質は保たれていた • それでも（それが故に顕在化が遅くなった可能性もあり）、 コードベースが⼤きくなるにつれ認知負荷が限界へ • 短期的な施策の波に押され、⻑期的な施策が打てなく なりつつあった モノリス 

40. 事例 1/2: 基幹製品のリアーキテクチャ 対処療法にとどまり、製品の進化が減速 抜本的な対応の必要性 複雑化した業務に対応した 処理の再構成 複数のケースに対応しやすい 柔軟さを持ったモデルの実現 疎結合‧⾼凝集のモジュール構造      対処療法 ⾮同期化、処理の分割実⾏      データ‧処理が 類似した固有の実装      テストコード追加、 プロセスの⾒直し タイムアウト多発 障害の 増加傾向 新たな ユースケース
41. 事例 1/2: 基幹製品のリアーキテクチャ すべての駆動が未分化の状態だった、と⾔える オポチュニティ、イネーブリング、ビジョンの駆動が絡まった未分化の状態 • 開発計画は、短期開発‧⻑期開発の速度差「テンション」を意識できていない • モノリスは、速度差を吸収するための「クラッチ」機構を意識できていない なにより、まず「明確な境界」を引くことが必要だった
42. • 専任チームを構成。社歴の⻑いエース級数⼈のPdM、デザイナー、エン ジニア。社歴が⻑い ≒ 歴史‧痛みを深く共有（課題感が強い） • 荒いスケジュールはあるが、短期的な売上を追わないのはもちろんこ と、⻑期の売上計画にも織り込まない形でスタート • ログラスの企業規模では、⼤きな投資 • 振り返ると、まさに ビジョン駆動 の萌芽であった 事例 1/2: 基幹製品のリアーキテクチャ 完全に独⽴したプロジェクト組成という意思決定 ⻑期的な競争優位性の獲得にフォーカスした プロジェクトを組成
43. 事例 1/2: 基幹製品のリアーキテクチャ 既存開発と距離をおき、接続が不明瞭な状態でのテンションの衝突を避ける すぐに開発しない ビジョン駆動 の分離の徹底 FigJamの絵 調査、要件化、モデリングの徹底 • 徹底的な先⾏プロダクトの調査 • 顧客要望の深堀り。たとえば、既存製品が カバーできていない巨⼤なExcelユースケー スの分析、要求への昇華（右図） • 並⾏して技術検証とPoCの繰り返し
44. 事例 1/2: 基幹製品のリアーキテクチャ テンションが⾼まり、ビッグバンの懸念へ 半年以上の試⾏錯誤の末、リアーキテクチャの形は明確になった。しかし、「最⾼ のものをじっくり作って乗り換えてもらう」時間軸は⻑い。現実との乖離‧世の中 においていかれるリスクが、 ビジョン駆動 における懸念としてあがってきた 駆動差を低減し、ビッグバンリリースを避けたい 理想の形は⾒えつつあった 既存製品との⼤きすぎるテンション
45. 事例 1/2: 基幹製品のリアーキテクチャ クラッチの「効果」と「コスト」のトレードオフ観点 しかし、⼤きく異なる駆動を接続する ≒ クラッチを⾼度にしすぎることは、ト レードオフを超え、効果の頭打ち、場合によっては減少の可能性も懸念された
46. 事例 1/2: 基幹製品のリアーキテクチャ 現実に「適合」できるのか、検証を繰り返した 既存製品を置換または接続できるのか。「適合設計」と呼ぶ、クラッチの形成期 を経ることになった。同時に理想にフィードバックを得る機会ともなった。 理想は現実から乖離していないか？ 理想が現実に耐えうるのか？ 適合設計 ≒ クラッチ形成期 ビジョン駆動 オポチュニティ駆動 理想 リアーキテクチャ 現実 既存製品 Feedback Verfication
47.                事例 1/2: 基幹製品のリアーキテクチャ 部分的なリプレース、という現実解に舵を切った      既存の改修 性能や品質の改善幅に疑問符      部分リプレース 現実界なのでは？      完全リプレース 乗り換えられない懸念 旧製品 新製品 旧製品 新製品 旧 to 新製品 効果★★☆ コスト★★☆ 効果★☆☆ コスト★☆☆ 効果★★☆ コスト★★★ 採⽤
48. 事例 1/2: 基幹製品のリアーキテクチャ 複数ドライブを並⾛させるアーキテクチャへ 性格の異なるシステム間を接続し、単⼀プロダクトを形成。リーアキテクチャは、 現在進⾏形でプロダクション環境への段階的デプロイを進めている ビジョン駆動 オポチュニティ駆動 新アーキテクチャ 既存プロダクト 短期ユースケース RDB データ同期 Outbox トランザクショナル 業務DB的（OLTP） Stream Aligned Source of Truth 個別業務重視 分析DB的（OLAP） ⻑期ロードマップ 汎⽤化重視 Complicated SubSystem スケーラブル ⾮RDB クラッチ
49. 事例 1/2: 基幹製品のリアーキテクチャ • リアーキテクチャに ビジョン駆動 で取り組んできた。 • 完全に独⽴したチームで『⻑く使う』ために『正しく作る』ことを⽬標 • ビッグバンリリースの懸念、コストに対して成果が頭打ちする懸念 • 早期にクラッチを形成する⽅向に舵を切り、新旧をスムーズにつなげる • 結果的に、オポチュニティ駆動 の開発を維持しつつ、ビジョン駆動 の成果を 編み込んでいく現実解に着地しつつある 事例1のまとめ
50. 事例 2/2: 全社横断の共通基盤
51. 事例 2/2: 全社横断の共通基盤 事例 2: 全社横断の共通基盤 昨年末から少しずつ動き出し、今秋より本格化 した共通基盤構築（記事参照）。 マルチドライブアーキテクチャで広いスコープ をどう捉え、どうマネージしていこうとしてい るか、現在地をお伝えします。 https://note.com/loglass_post/n/nba2b49ea7da5
52. 事例 2/2: 全社横断の共通基盤 複数の⼤きな変化が、同時に起こりつつある 既存製品中⼼ リアーキテクチャ 既存製品 + 新規製品 マルチプロダクト 製品 + 組織 + 個⼈ AI ⻑期視点で⼼臓部の再構成 モノリス分割‧認知負荷低減 Loglass AI Agents構想 AIネイティブカンパニーへ 経営管理、⼈員計画、 同時多発的に多数の⽴ち上げ ⼀貫性のある進化のための「共通基盤」の機運 昨今、ログラスの製品を取り巻く状況‧環境が、⼤きく変わってきた。
53. それぞれで向かう⽅向性と「時間軸」が異なり、整合を取ることが極めて難しい 既存製品中⼼ 既存製品 + 新規製品 製品 + 組織 + 個⼈ ⻑期視点で⼼臓部の再構成 モノリス分割‧認知負荷低減 Loglass AI Agents構想 AIネイティブカンパニーへ 経営管理、⼈員計画、 2027年までに20プロダクト リアーキテクチャ マルチプロダクト AI ⼀貫性のある進化のための「共通基盤」の機運 事例 2/2: 全社横断の共通基盤 複数の⼤きな変化が、同時に起こりつつある ⻑期視点での 抜本的な変化が⽬的 製品ごとに 要件‧技術‧進度に「差」 刻々、世の状況が変わり ⽅向を定めにくい
54. 変化を許容しつつ、無秩序にプロダクトが広がることは避けなければいけない 既存製品中⼼ 既存製品 + 新規製品 製品 + 組織 + 個⼈ ⻑期視点で⼼臓部の再構成 モノリス分割‧認知負荷低減 Loglass AI Agents構想 AIネイティブカンパニーへ 経営管理、⼈員計画、 2027年までに20プロダクト リアーキテクチャ マルチプロダクト AI ⼀貫性のある進化のための「共通基盤」の機運 事例 2/2: 全社横断の共通基盤 複数の⼤きな変化が、同時に起こりつつある 素早い要求変化への適応 秩序だった製品進化 V S
55. 事例 2/2: 全社横断の共通基盤 進度の速い部分をまずイネーブルさせる • 共通ユーザー管理に取り組む • データモデル、データの独⽴性、 アプリケーションテンプレートを 同時に提供 • ⼀部メンバーの兼務でスタート 経営管理 新製品A 新製品B 新製品C 共通ユーザー 管理 イネーブルメント駆動 で初速をつける
56. 事例 2/2: 全社横断の共通基盤 イネーブルメント駆動 で初速をつける ビジョンを語るではなく、進度の速い部分をまずイネーブルさせることに集中。 • 摩擦を減らして⾃由度を獲得 ‐ 初期は、プロセスの摩擦‧認知負荷が⾼く、ビジョンを語っても実⾏できない ‐ イネーブリングは、摩擦を減らして⾃由度を増やす⾏為 • 全体の最適解への準備 ‐ イネーブリングは、多くの場合「今の状況での個別最適を⾼める」活動 ‐ イネーブリング施策が回ると「これでできそう」という⾃⼰効⼒感が⽣まれる ‐ 「もっと⼤きな⽬的のためにどこを変えるべきか」を考える素地ができた
57. 事例 2/2: 全社横断の共通基盤 あるべき姿、 ビジョン駆動 へのギアチェンジ 現在は、統合ロードマップの策定が徐々に進み、駆動を切り替えようとしている 「この基盤を使って、どんな世界を実 現したいか？」という問いに答える、 意味‧⽬的の付与。 イネーブリングによって「どこへ⾏っ てもおかしくない状態」の獲得し、 イネーブルメント駆動 ビジョン駆動
58. 事例 2/2: 全社横断の共通基盤 駆動の移⾏ ≒トポロジーの変遷 駆動の移⾏をトポロジーの変遷になぞらえて捉えている イネーブルメント駆動 ビジョン駆動 「偶有的複雑性と戦うためのアーキテクチャとチームトポロジー」(2024)より
59. 事例 x2 のまとめ
60. 事例まとめ: リアーキテクチャと共通基盤 異なる駆動と、境界、遷移をマネージする 現実を、マルチドライブアーキテクチャのフレームワークで捉え直し、複数の異なる 駆動と、その時間軸での遷移で⽴体的に捉え、マネージしていく意義 • リアーキテクチャは、 ビジョン駆動 で開始し、 オポチュニティ駆動 と接続する • 共通基盤は、 イネーブルメント駆動 で開始し、 ビジョン駆動 に遷移する マルチドライブアーキテクチャが、 複雑で動的な現実に地図を与える フレームワークになる
61. まとめ
62. まとめ まとめ：ご清聴いただきありがとうございます！ テンションを恐れず、適切なクラッチを設計しましょう • 速度差（時間軸）を⾒極め、適切に分離する ‐ 時間軸のズレを混ぜるのではなく、駆動⼒を分離 ‐ ただし、分離にはコストが伴うため、速度差に⾒合うだけの効果があるか（損益分岐点）を常 に⾒極める • アーキテクチャを動的に捉る ‐ フェーズによって主役となる駆動（V‧E‧O）は変わってくる ‐ 変化に合わせて柔軟に境界を引き直す • テンション（歪み‧摩擦）を進化の合図にする ‐ 現場の摩擦は新たなクラッチが必要になったというアラート 。 ‐ テンションを再設計のトリガーに変える
63. よりリアルなお話は ぜひログラスのブースで！ 書籍販売ブースの 近くです
65. Appendix
66. Appendix テンションは駆動間の速度差に⽐例する 安定性優先 スピード優先 テンションは駆動間の速度差に⽐例する T_i,j : 駆動i、駆動j 間のテンション v_i : 駆動iにおける変化速度(velocity) 速度差が⼤きいほど、クラッチ（緩和する仕組み）が必要 テンション