「図面」から「法則」へ 〜メタ視点で読み解く現代のソフトウェアアーキテクチャ〜

Transcript

1. 「図⾯」から「法則」へ メタ視点で読み解くソフトウェアアーキテクチャ 【6社共催】スケールするサービスにおけるアーキテクチャの⼯夫‧苦労を語る会 2025年12⽉17⽇ 株式会社ログラス プロダクト基盤部 エンジニアリングマネージャー ⼩林 達 1
2. ⾃⼰紹介 ⼩林 達（Satoshi Kobayashi） 2 略歴 ディーバ (2004 〜 2014) 連結会計製品の導⼊‧開発 ビズリーチ (2014 〜 2024) HRMOS採⽤‧評価の⽴ち上げ（開発部⻑） ログラス (2024 〜) リアーキテクチャ、共通基盤（EM） 使うモデル Composer 1 、Opus 4.5、Gemini 3.0 Pro 趣味 娘とキャンプ、カメラ、⽇本酒
3. ここ数ヶ⽉、これまで、、 3
4. これまで、、、 「データ分析基盤」を作っています！という記事を出し、 https://note.com/loglass_post/n/n04d559e729c5 4
5. これまで、、、 「共通基盤」を⽴ち上げます！という記事も出しました https://note.com/loglass_post/n/nba2b49ea7da5 5
6. これまで、、、 「マルチドライブアーキテクチャ」で交通整理してきました https://speakerdeck.com/knih/multi-drive-architecture 6
7. これまで、、、 マルチプロダクトの第⼀弾「Loglass AI IR」が正式リリース！ 7 https://www.loglass.jp/ai-ir
8. とあるように、 基盤の拡充に⼒を⼊れていますが、 具体的な技術⾯は、 後⽇あらためて発信していく予定です。 m(_ _)m 8
9. 本⽇は、少し抽象的な話です。 9
10. 提起 10 アーキテクチャ Conference の「マルチドライブアーキテクチャ」のスライドですが、 実際、⾬後のたけのこのように幾つものプロジェクトが同時進⾏しています。
11. もしかして、 「変化し続ける」ことが あらたな「常態」なのではないか？ 11
12. 「変化」を前提としたときに、 アーキテクチャはどうなるのか？ 12
13. そもそも、 「私のアーキテクチャに関する認識が 古いのではないか？」 （典型的な、私のアーキテクチャのイメージは「図」です） 13
14. 少し過去を振り返って、 その後に現代のアーキテクチャの形について まとめてみます。 14
15. 時代背景 15 私たちが前提としてきた「変化の速度」と「変化の単位」が、 この⼗数年で劇的に、そして不可逆的に変わってしまっていそうです。 アーキテクチャの「何が『制約」で、何が『正解』とされていたか」という 価値観の変遷として、3つの時代を振り返ってみます。 アーキテクチャを設計するとは 、⼀体どういうことだったか
16. 16 時代背景① オンプレミス時代：「予測可能性」という信仰 物理的な制約が、開発のスピードを規定していた時代 ‧サーバー調達は数週間〜数ヶ⽉。 ‧最⼤の美徳は「予測可能性」。変更は莫⼤な コストとリスクを伴う。 ‧アーキテクチャは「城塞」の設計図。堅牢で、 揺るぎない。 ‧Big Design Up Front が経済合理的だった
17. 17 時代背景② クラウド時代：「可処分性」の獲得 「とりあえず作って、ダメなら作り直す」アジャイルなアプローチが インフラ層まで浸透。アーキテクチャはより流動的に ‧固有の名前をつけ、⼿塩にかけて育てる ‧不調になれば、原因を特定して修理する ‧唯⼀無⼆の存在として、⻑く維持する ‧番号で管理し、全体を⼀律に扱う ‧不調になれば、修理せず新品と⼊れ替え ‧個体に執着せず、システム全体を守る The History of Pets vs Cattle and How to Use the Analogy Properly 「ペットvs家畜」をアレンジ 盆栽 農業
18. 18 時代背景③ ⽣成AI時代：「⾮連続な再構築」へのシフト 「リファクタリング」より「リライト」が速い世界 ‧「仕様から実装へ」の変換コストが極限まで低下 ‧変化のサイクル：「数年」→「数⽇‧数時間」 ‧「仕様駆動開発」という名の現代版‧超⾼速 ウォーターフォール。やり直しコストはほぼゼロ
19. もはや、静的な「図⾯」は描けない。 （私のアーキテクチャのイメージは「図」 、、、） 19
20. 20 もはや、静的な「図⾯」は描けない アーキテクチャを再定義する 静的な「図⾯」から動的な「反応」へ 変化の防波堤として機能 する構成図。衝撃の伝わ り⽅を決定づける ストラクチャ (Structure) ルール (Rules) アーキテクチャ 変化の作法。システム を健全に保ち続けるた めのしくみ
21. これからのアーキテクチャに求められる 3 つの性質 （ここ数年のアーキテクチャに関する技術書や理論からの導き） 21
22. 22 これからのアーキテクチャに求められる 3 つの性質 可観測性（Observability）：システムの振る舞いを透視する • 静的な図⾯が正しくても、動いているシステムがどう 振る舞っているかが⾒えなければ、変化に対応できな い。 • 従来の「死活監視」が"⽣きているが"を知るものに対 し、可観測性は“なぜ”そう振る舞うかを理解する能 ⼒。 • ログ、メトリクス、分散トレーシングをアーキテク チャの第⼀級市⺠として組み込むことで、変化への反 応速度を決定づける「⽬」を⼿に⼊れる
23. 23 これからのアーキテクチャに求められる 3 つの性質 適応度関数（Fitness Functions）：「健全性」をコードで守り続ける 「変更に強い」といった定性的な⽬標を、定量的な指標で計測し、客観的に評価し続ける必要がある。 適応度関数は、アーキテクチャ上の⽬標（可⽤性、性能、依存関係など）をコード化し、⾃動的に評価する 仕組み。ルールを破る変更があればCIが失敗し、即座にフィードバックが得られる。「数値」を頼りにアー キテクチャを継続的に進化させる。
24. 24 これからのアーキテクチャに求められる 3 つの性質 可処分性（Disposability）：「⾮連続な再構築」を前提とする • 「古くなったコードをいかに低コストで捨て、書き直 させるか」が重要になる。鍵となるのが「可処分性」 • 必ずしもマイクロサービスである必要はなく、「モ ジュラーモノリス」のように内部境界が明確であれば よい • 他へ影響を与えずに切り離せる（Detachable）設計が 求められる
25. 「メタ‧アーキテクチャ」という視点への昇華 （アーキテクチャのアーキテクチャ） 25
26. 26 アーキテクティングは「個別の技術選定や構成の決定」から、 「アーキテクチャの変化そのものを管理する仕組みの構築」へとシフトしている 「メタ‧アーキテクチャ」という視点への昇華 システムの振る舞いを透視する 変化の良し悪しを⾃動判定する いつでも構造を書き直せる Disposability Observability Fitness Functions 適応度関数
27. 27 「メタ‧アーキテクチャ」という視点への昇華 「形」ではなく「流れ」をデザインする Design the "flow", not the "form" 静⽌画としての「ストラクチャ」に美しさは求められていない。 重要なのは、動画として⾒たときの「ルール（振る舞い）」の滑らかさ。 アーキテクティングは、チームの中に⾶び込み⽇々の開発の「流れ」そのものを整えることへ
28. 28 詳細は Zenn にて https://zenn.dev/loglass/articles/a31edf89fc5456
29. 29 本⽇のまとめ • 「変化し続ける」あらたな「常態」をどう捉えるか • 時代背景：不変から流動への不可逆なシフト ‐ オンプレミス時代：「予測可能性」 ‐ クラウド時代：「可処分性」 ‐ ⽣成 AI 時代：「⾮連続な再構築」 • 「アーキテクチャ = ストラクチャ + ルール」で再定義 • 「メタ‧アーキテクチャ」という視点への昇華 ‐ 1. Sense: 可観測性（Observability） ‐ 2. Judge: 健全性（Fitness Functions） ‐ 3. Act: 可処分性（Disposability） • 「形」よりも「流れ」をデザインする