変更し続けられるシステムをどう保つか — AI時代のSSoTという設計原則

by かわうそ

Embed

Start on current slide

Slide 1

Slide 1 text

変更し続けられるシステムをどう保つか — AI時代のSSoTという設計原則 Dress Code株式会社 / Product & Technology かわうそ（河村勇樹）

Slide 2

Slide 2 text

自己紹介業務プロダクト開発 / アーキテクチャ / 共通基盤組織設計 / 採用 / 技術広報技術アーキテクチャを考えるのが好き Event Sourcing New SQL かわうそ @_syoryu89 趣味お酒 / ゴルフ / 競馬 / カワウソ鑑賞 Dress Code Inc. Product & Technology ／ Tech Lead © Dress Code Inc. 2

Slide 3

Slide 3 text

今日は以下の流れで話を進めます 1 AIにより生成が速くなった直し続けるとレガシーが加速するかもしれない 2 修正より作り直すコストが下がった「直す」から「壊して作り直せるように」へ 3 作り直すには事実が必要＝SSoT 守るべきは“成果物”ではなく“事実” 4 事実の残し方の実例 Core DB ／ Event Sourcing・CQRS / 開発プロセス 5 まとめ速度と持続性を両立 © Dress Code Inc. 3

Slide 4

Slide 4 text

01 AI時代に「変更し続けられる構造」をどう保つか実装は速くなった。だが、変更し続けられることは、むしろ難しくなっている。 © Dress Code Inc. 4

Slide 5

Slide 5 text

皆さんのチームでは 1年前の設計判断を、今も正確に追いかけられますか？ AIが数秒で数千行を生成し、人が手を入れた先のコードを、半年後も自信を持って変更できますか？ © Dress Code Inc. 5

Slide 6

Slide 6 text

AIは「レガシー化」を加速させる可能性がある実装速度 ↑ 変更頻度 ↑ 複雑性 ↑ エントロピー ↑↑ AIが生成を担う手を入れる回数が増える構造が絡み合う＝レガシー化の加速 Mutable Code Accumulates Entropy — インクリメンタルな編集が意図を曖昧にし、レガシーを生む。 Immutable Infrastructure, Immutable Code © Dress Code Inc. 6

Slide 7

Slide 7 text

インクリメンタルな変更が”レガシー”を生む ● 今までのソフトウェア開発の基本戦術は「既存コードの修正」 ● インクリメンタルな変更は意図を地層のように積み重ねる ● 局所最適な修正が蓄積し、整合性が壊れ、エントロピー（複雑さ）が増大 AI時代には破壊性（Destroyability）と回復性（Recoverability）が必要だと思った話 © Dress Code Inc. 7

Slide 8

Slide 8 text

昔から言われていたことでもある「割れ窓理論」建物の割れた窓を放置すると次々に荒廃が進むように、コードベースの小さな劣化を放置すると、それが連鎖的にシステム全体の品質を蝕んでいくという考え方インクリメンタルな変更は、まさにこの「割れ窓」を積み重ねるリスクを表している達人プログラマー © Dress Code Inc. 8

Slide 9

Slide 9 text

AIは凄まじい速度で生成を行う ● AIは数秒で数千行のコードを生成する ● それを人間やAIがインクリメンタルに編集し始めると理解不可能なアーティファクトが生成される ● 脆いレガシーを作り出しているのかもしれない © Dress Code Inc. 9

Slide 10

Slide 10 text

「速度」と「持続性」のトレードオフ速度速く作れる ⇄ 犠牲になりやすい持続性変更し続けられるそして、これは規模が大きいほど深刻になる。 © Dress Code Inc. 10

Slide 11

Slide 11 text

02 直し続けるから壊して作り直すへ守る対象を、コードという”成果物”から、事実という”源泉”へ。 © Dress Code Inc. 11

Slide 12

Slide 12 text

AI時代のパラダイムシフトこれまで AI時代／逆転修正コスト＜再構築コスト修正コスト＞再構築コスト作り直すのは高くつく。だから、既存コー改修するより、仕様から再生成した方が速ドを大事に直し続けてきた。く・正確なケースが現れ始めた。 © Dress Code Inc. 12

Slide 13

Slide 13 text

犠牲的アーキテクチャ（Sacriﬁcial Architecture）今つくっているものが、数年後には破棄される—— その事実を“今”受け入れ、リプレースが容易になるよう、はじめから設計に織り込む。廃棄は「失敗」ではない各時点では「正しい」品質を捨てるのではない多くの人には失敗の象徴に映る。だ前のが間違っていたのではない。鍵はモジュール性。境界が適切なが今の最善が数年後に捨てられるのその時点では、それで十分だった。ら、捨てる単位を局所に絞れる。は珍しくない。 Martin Fowler氏の語る”犠牲的アーキテクチャ” © Dress Code Inc. 13

Slide 14

Slide 14 text

「壊して作り直せる」を支える2つの性質破壊性 Destroyability 回復性 Recoverability 壊した影響をその範囲内に閉じ込め仕様と契約が守られていれば、 AI られる度合い。がゼロから再生成しても機能する × ※「破壊力が大きい」ことではない性質。回復できるのは「事実」が残っているから破壊性 × 回復性＝壊して作り直せる © Dress Code Inc. 14

Slide 15

Slide 15 text

破壊性 - 壊しても、影響をその範囲に閉じ込められる「破壊性が高い」＝破壊力が大きい、ではない。影響を局所に閉じ込められる度合いが高いこと。消すと、連鎖して壊れる消えても、他は動き続けるあるモジュールを削除すると、依存する他のそのモジュールだけが消え、他は何事もなくモジュールも連鎖的に倒れる。怖くて壊せな動く。だから安心して壊せる。い。破壊性低い破壊性高い AI以前からあるが、AIで「壊して再生する」コストが激減し、現実的な選択肢になった。 © Dress Code Inc. 15

Slide 16

Slide 16 text

回復性 - 壊した部分を差し替えて、機能を再び実現できる破壊性が「安全に壊せる」なら、回復性は「壊した後に確実に再生できる」。仕様が明確契約（IF）が中身は、AIがゼロから再生成しても動く守られる何を満たすべきかがインターフェースが仕様と契約＝”事実”さえ守られていれば、実装そのも定義されている。保たれている。のは作り直してよい ── これが回復性が高い状態。破壊性だけ高くても、回復性だけ高くても、再生できなければ意味がない。壊すと波及するなら怖くて壊せない。両方揃って、はじめて成立 © Dress Code Inc. 16

Slide 17

Slide 17 text

ここまでの結論成果物を“守る”のではなく、事実を“残す”。「事実」さえ残っていれば、AIが壊して作り直せる。 AIは、「生成」は得意だが、「事実」は作れない。 © Dress Code Inc. 17

Slide 18

Slide 18 text

「コードを守るな」＝品質軽視、ではない ✕ よくある誤読 ○ 本当の意味品質を軽視し、技術的負債を放守る対象の優先順位を”成果物”から置してよい、という意味だ。 ”源泉（事実）”へ移す。その「事実」を残す具体的な形が Single Source of Truth（SSoT） © Dress Code Inc. 18

Slide 19

Slide 19 text

「壊して作り直せる」形にするのがアーキテクチャ破壊性も回復性も、すでに見たとおり事実があってこそ。その事実を活かす器がアーキテクチャ。主役支え事実（SSoT）アーキテクチャ何を残すか。事実を「壊して戻せる形」にする器。以降は、事実をどう残すかを軸に。アーキテクチャはその支えとして扱う。 © Dress Code Inc. 19

Slide 20

Slide 20 text

03 事実を、SSoTとして残す何を「これ1つだけが真実」と決めて、すべての参照元をそこに向けるか。 © Dress Code Inc. 20

Slide 21

Slide 21 text

SSoT とは、どういう状態か Single Source of Truth（SSoT） - 「信頼できる唯一の情報源」あるデータについて「これ1つだけが真実」と決めて管理し、すべての参照元が、その1つを見る。参照元アプリ A アプリ B 唯一の真実 Single Source of Truth レポート C © Dress Code Inc. 21

Slide 22

Slide 22 text

残すべきは「源泉」だけ。導出物は、そこから作り直せる。いまの状態も、コードも、構成図も、ぜんぶ事実から導かれた結果。源泉さえ守れば、壊して作り直せる。源泉導出起きた事実・決めた事実そのもの。事実から導かれた結果。これだけを守る。失っても作り直せる。事実不変永続再生成結果可変揮発使い捨てできる © Dress Code Inc. 22

Slide 23

Slide 23 text

3つのレイヤーごとの「事実」と「導出」源泉＝守る（事実・不変・永続）データコードアーキテクチャイベント ── 誰が・いつ・何をしたか EmploymentSigned → DeviceAssigned → InvoiceIssued → … 仕様 ── どう振る舞うべきか（SDD）入力・出力・業務ルール・受け入れ条件意思決定 ── なぜそう作ったか（ADR）導出＝捨ててよい（再生成できる）現在の残高・在籍状態生成されたコードそのもの現状のモジュール構成図選んだ／捨てた選択肢・その時の前提とトレードオフ 3つとも「壊して作り直す」の難易度は違う。今日は、データ層を中心にお話します。 © Dress Code Inc. 23

Slide 24

Slide 24 text

データ層の思想状態は揮発的、イベントが永続的な事実。現在の状態（Read Model）は、残された事実から、いつでも作り直せる。 © Dress Code Inc. 24

Slide 25

Slide 25 text

04 Dress Code での実現コンパウンドプロダクト × 大規模、という制約下で、原則をどう具体化したか。 © Dress Code Inc. 25

Slide 26

Slide 26 text

会社・プロダクト紹介 © Dress Code Inc. 26

Slide 27

Slide 27 text

Dress Code 会社概要 Company Name / 会社名 Dress Code 株式会社 CEO / 代表取締役江尻祐樹 Date of establishment / 設立年月 2024年9月 Location / 所在地東京都中央区築地2-1-4 銀座PREX East 8F Member / メンバー数 47名 Pre Seed&Seed Round 正式創業：2025年4月 Number of companies Number of countries 14.1億円 250+社 5カ国資金調達を実施が利用中で事業を展開 © Dress Code Inc. 27

Slide 28

Slide 28 text

挑戦する事業ドメイン/マーケット Dress Code が挑戦するのは、グローバル（まずアジア）のWorkforce Management領域全体 Workforce Management領域 Asia to Global 採用管理労務管理人事/ 配置育成/ 定着福利厚生 × 【Entry】入社/入場【Retire】退職/退場ライフサイクル ITツール /備品拠点/ 環境セキュリティ /ガバナンスプロジェクト外部人材活用 © Dress Code Inc. 28

Slide 29

Slide 29 text

デジタル化に伴う社会課題 -「摩擦問題」 SaaS/ツール乱立に伴い、システムの分断・業務のサイロ化が進む採用関連データ分断契約関連データ分断労務関連データ勤怠関連データ ❌ ❌ ❌ 分断分断 SaaS関連データ分断デバイス関連データ ❌ ❌ 採用管理システム契約管理システム労務管理システム勤怠管理システム SaaS管理システムデバイス管理台帳採用部門法務部門労務部門人事部門情報システム部門総務部門各業務担当者ツールの乱立で、使いこなせない/慣れるのまでに時間がかかるツール/部門間のアナログ連携が大変担当間/部門間の摩擦が増大している経営/管理部全体最適なSaaSを選定することが困難データが散在していて利用/活用できない連携/メンテのためのコスト(時間・お金)が膨大 © Dress Code Inc. 29

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Platform Capabilities プロダクトにおけるデータベース・ミドルウェア含めた”共通基盤” コンパウンドプロダクトにおける価値を提供するための”エンジン” 初期段階から共通基盤に投資をしてプロダクトの横展開を実現 © Dress Code Inc. 32

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Dress Code における SSoT：Core DB 全てのビジネスアプリケーションから共通して利用されるデータ。「信頼できる唯一の情報源」として、組織内のすべてのデータが1つの場所で管理・更新されるように設計されたシステムの根幹。 © Dress Code Inc. 34

Slide 35

Slide 35 text

Dress Code における SSoT：Core DB 全てのビジネスアプリケーションから共通して利用されるデータ。「信頼できる唯一の情報源」として、組織内のすべてのデータが1つの場所で管理・更新されるように設計されたシステムの根幹。 © Dress Code Inc. 35

Slide 36

Slide 36 text

各プロダクトで分散・重複管理させない従業員のデータをSSoTに管理する仕組み © Dress Code Inc. 36

Slide 37

Slide 37 text

AI時代における「作る」と「働く」「事実を残す（SSoT）」という原則が、AIの2つの側面に同時に効く。これまで話してきた顔これから話すもう一つの顔 AIが「作る」 AIが「働く」事実があれば、壊して作り直せる事実がブレなければ、AIに業務を任せられる（破壊性 × 回復性）守るべき事実＝仕様・意思決定・イベント＋（業務自動化）守るべき事実＝業務の記録（誰が・いつ・何を） Core DB は、この両方に応える。開発生産性とは別の、もう一つの側面を次に話します。 © Dress Code Inc. 37

Slide 38

Slide 38 text

なぜ、SSoTな仕組みが必要か？ Core DB は「業務の事実を SSoT として残す仕組み」の一つ。動機は開発生産性ではなく、「AIが働く」時代の必然にある。業務自動化の土台 AIが安全に読み書きできるプロダクト横断で一致する業務をAIに任せるほど、判断の拠り唯一の真実が定まっていれば、AIのコンパウンドの全プロダクトが、同所になるブレない事実が要る。読み書きが食い違いを生まない。じ事実を見て動ける。だから Dress Code は、最下層に唯一の事実（SSoT）を置く。 © Dress Code Inc. 38

Slide 39

Slide 39 text

Slide 40

Slide 40 text

イベントだけでなく、コマンドも残す一般的に残すもの Dress Code は、さらにイベントコマンド「何が起きたか」という結果。「何をしようとしたか」という指示・意図まで残す。結果に加えて意図が残るから、再構築の判断材料が増える。 © Dress Code Inc. 40

Slide 41

Slide 41 text

Core DB は設計思想。実現方法はデータ特性で変える「事実を残す」原則は共通。どう残すかは、ドメインとデータの性質に合わせて最適化する。 S3 / Glue DynamoDB アクセス系データ従業員データデータ量が多く、ノイズも多い。月末・月初にトランザクションが急増。安価に大量蓄積し、後からまとめて分析する形が合スパイクに耐える書き込み特性が要る。う。同じ思想でも、データストアの選択はドメインごとに違う——テンプレの一律適用ではない。 © Dress Code Inc. 41

Slide 42

Slide 42 text

壊して作り直せるのは、事実を残しているから状態（Read Model）は使い捨てていい。スキーマが陳腐化したら、躊躇なく壊せる。 Read Model を破壊蓄積イベントは残る新しい状態を再生成事実は不変に積まれているイベントから作り直す陳腐化した状態は捨ててよい（使い捨て）スキーマを壊しても、事実から状態を作り直せる。これが破壊性 × 回復性の、データ層での姿。 © Dress Code Inc. 42

Slide 43

Slide 43 text

実例：事実（Event）から、複数の Read Model を導く PeopleEvent という唯一の事実から、性質の違う状態を何度でも投影できる。 READ MODEL ① EVENT STORE ── 源泉（SSoT）影響を受けない最新状態ビュー（Current State） PeopleEvent 最新の契約・在籍状態を “名詞” として保持。全プロダクトが参照。誰が・いつ・何をしたか。追記のみで蓄積。 EmploymentSigned 雇用契約の締結 READ MODEL ② AddressChanged 現住所の変更 DependentAdded 扶養家族の追加 OrganizationChanged 所属組織の変更事実不変 Projection 使い捨て ── 破棄 → 再投影検索用インデックス（Search Index）検索特化の非正規化ドキュメント。要件が変われば、壊して再投影。 READ MODEL ③ ⋮ グループ会社横断ビュー（Cross-Tenant）永続ホールディングス管理向け。既にある事実に、投影を足すだけ。事実が残っているから、壊して再投影も、未来の要件への追加投影も自由にできる。 © Dress Code Inc. 43

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

開発プロセスに織り込むコード層の事実＝仕様、アーキ層の事実＝意思決定。この2つは ADR → SDD → 実装という一連の流れで、上流の事実がそのまま実装の根拠になる。 01 03 02 ADR を作成 SDD で仕様を作成仕様を元に実装 Any Decision Record Spec Driven Development Implementation 「なぜ」その判断をしたかを残す（次 ADR を元に、仕様を SSoT として記 SDD の仕様から、コードを生成・実ページで事例）。述する。装する。土台のアーキテクチャモジュラーモノリス DDD Clean Architecture 無秩序な実装にはならず、アーキテクチャに則った実装になる。 © Dress Code Inc. 46

Slide 47

Slide 47 text

意思決定を事実として残す ── ADR Architecture → Any へ。領域も大小も問わず、「なぜ」を全部残す。 Notionにとにかく全部残す考え方の転換 Architecture Decision Record Any Decision Record 週次で共有・FBし文化にする “全部（Any）残せばええねん” 「なぜそうなったか」が追えるデータ層でイベントを残すのと同じ原則を、アーキテクチャ層では”意思決定を残す”として体現している。 © Dress Code Inc. 47

Slide 48

Slide 48 text

仕様を事実として残す ── SDD（Spec-Driven Development）仕様＝「どう振る舞うべきか」という事実。実装は、そこから導出する。一般的な SDD（仕様駆動開発） Dress Code は、こう運用仕様の「残し方」に3段階ある「事実を残す」ための3つの選択 Spec-anchored を選択 Lv.1 Spec-ﬁrst 1 仕様を起点に実装する。仕様は作って終わり。 toB SaaS は仕様を保持し続けること自体に価値がある。 Lv.2 Spec-anchored 2 タスク完了後も仕様を残し、保守・改善に活用する。 Proposal → Specs → Design → Tasks を確定し、実装だけAIが生成。 Lv.3 Spec-as-source 3 仕様＝ソース。原則、人間はコードを触らない。 changes を時系列で蓄積。仕様の変遷も意思決定も、一つの置き場に。各ステップで人間がレビュー ADR と同じストックへ仕様を「作って終わり」にせず、残して育てる ── コード（成果物）よりも事実を守る。 © Dress Code Inc. 48

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

「壊して作り直せる」は、万能ではない ES/CQRS は運用・学習コストが高い全システムに適用すべきではない。データ移行・整合性・ダウンタイムの制約は現実に残る。どこから始めるか変更頻度が高く、事実を残す価値が大きい中核領域から。「SSoTを残す」 ≠ 「全部をESにする」残すべき事実を見極めることが本質。手段の全面採用が目的ではない。 © Dress Code Inc. 51

Slide 52

Slide 52 text

冒頭の問いに、答えられるようになる冒頭の問い ① 答え 1年前の設計判断を、今も正確に追 ADR で意思決定を事実として全部残す。いかけられますか？「なぜ」は、Notion AI に聞けば返ってくる。答え ── 問いの前提を、ひっくり返す冒頭の問い ② AIが書いたコードを、半年後も自信を持って変更できますか？そもそも変更し続けない。壊して作り直す。 SDD の仕様が残っていれば、AI が再生成できる。 © Dress Code Inc. 52

Slide 53

Slide 53 text

Slide 54

Slide 54 text

なぜ、「事実」を残すのかコードも状態も構成図も、すべて導出物。源泉である事実だけは、失えば二度と作れない。 1 2 3 AIは、事実を作れない事実があれば、作り直せる AIが「働く」拠り所になる「何が起きたか」「なぜ決めたか」は、失うと生成では復元できない。仕様・意思決定・イベントが残っていれば、導出物はAIがゼロから再生成できる。業務をAIに任せるほど、判断の土台になるブレない唯一の事実が要る。不可逆 ── 唯一守るべきもの破壊性 × 回復性 ── 壊して作り直せる業務自動化 ── SSoTが土台だから、守る対象を成果物から事実へ。 © Dress Code Inc. 54

Slide 55

Slide 55 text

守る対象を成果物から事実へ残す源泉（事実）捨てる導出物 Dress Code の仕組みデータイベント＋コマンド状態 / Read Model Core DB（ES / CQRS）コード仕様生成されたコード SDD（Spec-Driven Development）アーキ意思決定現状の構成図 ADR（Any Decision Record）レイヤー源泉を残し、導出物は壊して作り直す。これが、速度と持続性を両立させる AI 時代の設計原則。 © Dress Code Inc. 55

Slide 56

Slide 56 text

守る対象を成果物から事実へ冒頭のコールバック今日から手を付けられること事実を残せば、破壊性 × 回復性が手に入る 1 既存設計の「事実が残っている部分／ AIは事実を作れない。事実を SSoT として残すことで速く・長く作り続けられる。重要な設計判断を ADR として残し始める 2 失われている部分」を棚卸しする © Dress Code Inc. 56

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Dress Code Advent Calendar 2026/07 開催中!! Dress Codeのユニークな PdMやエンジニア達がブログを執筆中です!! 2026年 7月夏バテ予防に刺激を感じてください!! Comin g soon… Comin g soon… Comin g soon… Comin g soon… © Dress Code Inc. 58

Slide 59

Slide 59 text

カンファレンス＆イベントにも登壇中！！ 7/22~23開催 AI DevEx Conference 2026 22日10時50分〜 RoomC プロダクトエンジニアの河村が登壇！ 7/24~25開催大吉祥寺.pm 25日14時10分〜プロダクトエンジニアの櫻井が登壇！ 8/1開催【非公式】きのこカンファレンス 2026 in 関西 14時50分〜プロダクトエンジニアの山口が登壇！ 8/25開催 ProductZine Day 2026 14時40分〜プロダクトマネージャー／プロダクトデザイナーの馬場が登壇！ © Dress Code Inc.