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

# 概要
AIにより実装速度が上がる一方、システムは複雑化し変更頻度も加速しています。問われるのは「変更し続けられる構造」をどう保つかです。Dress Codeでは、修正コストが再構築コストを上回る今、仕様・意思決定・イベントといった事実をSSoT（Single Source of Truth）として残し、「壊して作り直せる」という思想のもと設計しています。全データの唯一の情報源となるCore DBやEvent Sourcingの実践を通じ、変更容易性と開発生産性をどう両立しているかをご紹介します。

# プロフィール
河村 勇樹 / Dress Code株式会社 / Product & Technology テックリード / かわうそ（@_syoryu89）

2019年に新卒で大手事業会社に入社し、航空気象サービスの開発に携わる。2021年にレバレジーズ株式会社に中途入社。レバテックCTO室のテックリードとして「レバテック」の開発・組織を牽引。レバテックのリアーキテクトやTiDBの導入を推進。2024年11月にDress Code株式会社に中途入社。アーキテクチャを中心にフルスタックに開発。ドメイン駆動設計やEvent Sourcing・CQRSを推進。採用や技術広報・組織設計にも携わる。趣味はお酒とゴルフとカワウソ鑑賞。

Transcript

1. 変更し続けられるシステムをどう保つか — AI時代のSSoTという設計原則 Dress Code株式会社 / Product & Technology かわうそ（河村 勇樹）
2. 自己紹介 業務 プロダクト開発 / アーキテクチャ / 共通基盤 組織設計 / 採用 / 技術広報 技術 アーキテクチャを考えるのが好き Event Sourcing New SQL かわうそ @_syoryu89 趣味 お酒 / ゴルフ / 競馬 / カワウソ鑑賞 Dress Code Inc. Product & Technology ／ Tech Lead © Dress Code Inc. 2
3. 今日は以下の流れで話を進めます 1 AIにより生成が速くなった 直し続けるとレガシーが加速するかもしれない 2 修正より作り直すコストが下がった 「直す」から「壊して作り直せるように」へ 3 作り直すには事実が必要＝SSoT 守るべきは“成果物”ではなく“事実” 4 事実の残し方の実例 Core DB ／ Event Sourcing・CQRS / 開発プロセス 5 まとめ 速度と持続性を両立 © Dress Code Inc. 3
4. 01 AI時代に「変更し続けられる 構造」 をどう保つか 実装は速くなった。だが、変更し続けられることは、むしろ難しくなっている。 © Dress Code Inc. 4
5. 皆さんのチームでは 1年前の設計判断を、今も正確に追いかけられますか？ AIが数秒で数千行を生成し、人が手を入れた先のコードを、 半年後も自信を持って変更できますか？ © Dress Code Inc. 5
6. AIは「レガシー化」を加速させる可能性がある 実装速度 ↑ 変更頻度 ↑ 複雑性 ↑ エントロピー ↑↑ AIが生成を担う 手を入れる回数が増える 構造が絡み合う ＝ レガシー化の加速 Mutable Code Accumulates Entropy — インクリメンタルな編集が意図を曖昧にし、レガシーを生む。 Immutable Infrastructure, Immutable Code © Dress Code Inc. 6
7. インクリメンタルな変更が”レガシー”を生む • 今までのソフトウェア開発の基本戦術は 「既存コードの修正」 • インクリメンタルな変更は意図を地層のよ うに積み重ねる • 局所最適な修正が蓄積し、整合性が壊れ、 エントロピー（複雑さ）が増大 AI時代には破壊性（Destroyability）と回復性（Recoverability）が 必要だと思った話 © Dress Code Inc. 7
8. 昔から言われていたことでもある 「割れ窓理論」 建物の割れた窓を放置すると次々に荒廃が進むよ うに、コードベースの小さな劣化を放置すると、 それが連鎖的にシステム全体の品質を蝕んでいく という考え方 インクリメンタルな変更は、まさにこの「割れ 窓」を積み重ねるリスクを表している 達人プログラマー © Dress Code Inc. 8
9. AIは凄まじい速度で生成を行う • AIは数秒で数千行のコードを生成する • それを人間やAIがインクリメンタルに編 集し始めると理解不可能なアーティファ クトが生成される • 脆いレガシーを作り出しているのかもし れない © Dress Code Inc. 9
10. 「速度」と「持続性」のトレードオフ 速度 速く作れる ⇄ 犠牲になりやすい 持続性 変更し続けられる そして、これは規模が大きいほど深刻になる。 © Dress Code Inc. 10
11. 02 直し続けるから壊して作り直すへ 守る対象を、コードという”成果物”から、事実という”源泉”へ。 © Dress Code Inc. 11
12. AI時代のパラダイムシフト これまで AI時代 ／ 逆転 修正コスト ＜ 再構築コスト 修正コスト ＞ 再構築コスト 作り直すのは高くつく。だから、既存コー 改修するより、仕様から再生成 した方が速 ドを大事に直し続けてきた。 く・正確なケースが現れ始めた。 © Dress Code Inc. 12
13. 犠牲的アーキテクチャ（Sacrificial Architecture） 今つくっているものが、数年後には破棄される—— その事実を“今”受け入れ 、 リプレースが容易になるよう、はじめから設計に織り込む。 廃棄は「失敗」ではない 各時点では「正しい」 品質を捨てるのではない 多くの人には失敗の象徴に映る。だ 前のが間違っていたのではない。 鍵はモジュール性 。境界が適切な が今の最善が数年後に捨てられるの その時点では、それで十分だった 。 ら、捨てる単位を局所に絞れる。 は 珍しくない。 Martin Fowler氏の語る”犠牲的アーキテクチャ” © Dress Code Inc. 13
14. 「壊して作り直せる」を支える2つの性質 破壊性 Destroyability 回復性 Recoverability 壊した影響をその範囲内に閉じ込め 仕様と契約が守られていれば、 AI られる度合い。 がゼロから再生成しても機能する × ※「破壊力が大きい」ことではない 性質。 回復できるのは「事実」が残っているから 破壊性 × 回復性 ＝ 壊して作り直せる © Dress Code Inc. 14
15. 破壊性 - 壊しても、影響をその範囲に閉じ込められる 「破壊性が高い」＝破壊力が大きい、ではない。影響を局所に閉じ込められる度合いが高いこと。 消すと、連鎖して壊れる 消えても、他は動き続ける あるモジュールを削除すると、依存する他の そのモジュールだけが消え、他は何事もなく モジュールも 連鎖的に倒れる 。怖くて壊せな 動く 。だから安心して壊せる。 い。 破壊性 低い 破壊性 高い AI以前からあるが、AIで「壊して再生する」コストが激減し、現実的な選択肢になった。 © Dress Code Inc. 15
16. 回復性 - 壊した部分を差し替えて、機能を再び実現できる 破壊性が「安全に壊せる」なら、回復性は「壊した後に確実に再生できる」。 仕様が明確 契約（IF）が 中身は、AIがゼロから再生成しても動く 守られる 何を満たすべきかが インターフェースが 仕様と契約＝”事実”さえ守られていれば、実装そのも 定義されている。 保たれている。 のは作り直してよい ── これが 回復性が高い状態。 破壊性だけ高くても、 回復性だけ高くても、 再生できなければ意味がない 。 壊すと波及するなら怖くて壊せない 。 両方揃って、はじめて成立 © Dress Code Inc. 16
17. ここまでの結論 成果物を“守る”のではなく、事実を“残す”。 「事実」さえ残っていれば、AIが壊して作り直せる。 AIは、「生成」は得意だが、「事実」は作れない。 © Dress Code Inc. 17
18. 「コードを守るな」＝ 品質軽視、ではない ✕ よくある誤読 ◦ 本当の意味 品質を軽視し、技術的負債を放 守る対象の優先順位 を”成果物”から 置してよい、という意味だ。 ”源泉（事実）”へ移す。 その「事実」を残す具体的な形が Single Source of Truth（SSoT） © Dress Code Inc. 18
19. 「壊して作り直せる」形にするのがアーキテクチャ 破壊性も回復性も、すでに見たとおり事実があってこそ。その事実を活かす器がアーキテクチャ。 主役 支え 事実（SSoT） アーキテクチャ 何を残すか。 事実を「壊して戻せる形」にする器。 以降は、事実をどう残すかを軸に。アーキテクチャはその支えとして扱う。 © Dress Code Inc. 19
20. 03 事実を、SSoTとして残す 何を「これ1つだけが真実」と決めて、すべての参照元をそこに向けるか。 © Dress Code Inc. 20
21. SSoT とは、どういう状態か Single Source of Truth（SSoT） - 「信頼できる唯一の情報源」 あるデータについて「これ1つだけが真実 」と決めて管理し、 すべての参照元が、その1つを見る。 参照元 アプリ A アプリ B 唯一の真実 Single Source of Truth レポート C © Dress Code Inc. 21
22. 残すべきは「源泉」だけ。導出物は、そこから作り直せる。 いまの状態も、コードも、構成図も、ぜんぶ事実から導かれた結果。源泉さえ守れば、壊して作り直せる。 源泉 導出 起きた事実・決めた事実そのもの。 事実から導かれた結果。 これだけを守る。 失っても作り直せる。 事実 不変 永続 再生成 結果 可変 揮発 使い捨て できる © Dress Code Inc. 22
23. 3つのレイヤーごとの「事実」と「導出」 源泉 ＝ 守る（事実・不変・永続） データ コード アーキテクチャ イベント ── 誰が・いつ・何をしたか EmploymentSigned → DeviceAssigned → InvoiceIssued → … 仕様 ── どう振る舞うべきか（SDD） 入力・出力・業務ルール・受け入れ条件 意思決定 ── なぜそう作ったか（ADR） 導出 ＝ 捨ててよい（再生成できる） 現在の残高・在籍状態 生成されたコードそのもの 現状のモジュール構成図 選んだ／捨てた選択肢・その時の前提とトレードオフ 3つとも「壊して作り直す」の難易度は違う。今日は、データ層を中心にお話します。 © Dress Code Inc. 23
24. データ層の思想 状態は揮発的、 イベントが永続的な事実。 現在の状態（Read Model）は、残された事実から、いつでも作り直せる。 © Dress Code Inc. 24
25. 04 Dress Code での実現 コンパウンドプロダクト × 大規模、という制約下で、原則をどう具体化したか。 © Dress Code Inc. 25
26. 会社・プロダクト紹介 © Dress Code Inc. 26
27. 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
28. 挑戦する事業ドメイン/マーケット Dress Code が挑戦するのは、グローバル（まずアジア）のWorkforce Management領域全体 Workforce Management領域 Asia to Global 採用 管理 労務 管理 人事/ 配置 育成/ 定着 福利 厚生 × 【Entry】 入社/入場 【Retire】 退職/退場 ライフサイクル ITツール /備品 拠点/ 環境 セキュ リティ /ガバナ ンス プロ ジェ クト 外部 人材 活用 © Dress Code Inc. 28
29. デジタル化に伴う社会課題 -「摩擦問題」 SaaS/ツール乱立に伴い、システムの分断・業務のサイロ化が進む 採用関連データ 分断 契約関連データ 分断 労務関連データ 勤怠関連データ ❌ ❌ ❌ 分断 分断 SaaS関連データ 分断 デバイス関連データ ❌ ❌ 採用管理 システム 契約管理 システム 労務管理 システム 勤怠管理 システム SaaS管理 システム デバイス 管理台帳 採用 部門 法務 部門 労務 部門 人事 部門 情報 システム 部門 総務 部門 各業務担当者 ツールの乱立で、使いこなせない/慣れるのまでに時間がかかる ツール/部門間のアナログ連携が大変 担当間/部門間の摩擦が増大している 経営/管理部全体 最適なSaaSを選定することが困難 データが散在していて利用/活用できない 連携/メンテのためのコスト(時間・お金)が膨大 © Dress Code Inc. 29
30. © Dress Code Inc. 30
31. © Dress Code Inc. 31
32. Platform Capabilities プロダクトにおけるデータベース・ミドルウェア含めた”共通基盤” コンパウンドプロダクトにおける価値を提供するための”エンジン” 初期段階から共通基盤に投資をしてプロダクトの横展開を実現 © Dress Code Inc. 32
33. © Dress Code Inc. 33
34. Dress Code における SSoT：Core DB 全てのビジネスアプリケーションから共通して利用されるデータ。 「信頼できる唯一の情報源」として、組織内のすべてのデータが1つの場 所で管理・更新されるように設計されたシステムの根幹。 © Dress Code Inc. 34
35. Dress Code における SSoT：Core DB 全てのビジネスアプリケーションから共通して利用されるデータ。 「信頼できる唯一の情報源」として、組織内のすべてのデータが1つの場 所で管理・更新されるように設計されたシステムの根幹。 © Dress Code Inc. 35
36. 各プロダクトで 分散・重複管理させない 従業員のデータをSSoTに 管理する仕組み © Dress Code Inc. 36
37. AI時代における「作る」と「働く」 「事実を残す（SSoT）」という原則が、AIの2つの側面に同時に効く。 これまで話してきた顔 これから話すもう一つの顔 AIが「作る」 AIが「働く」 事実があれば、壊して作り直せる 事実がブレなければ、AIに業務を任せられる （破壊性 × 回復性） 守るべき事実 ＝ 仕様・意思決定・イベント ＋ （業務自動化） 守るべき事実 ＝ 業務の記録（誰が・いつ・何を） Core DB は、この両方に応える。開発生産性とは別の、もう一つの側面を次に話します。 © Dress Code Inc. 37
38. なぜ、SSoTな仕組みが必要か？ Core DB は「業務の事実を SSoT として残す仕組み」の一つ。動機は開発生産性ではなく、「AIが働く」時代の必然にある。 業務自動化の土台 AIが安全に読み書きできる プロダクト横断で一致する 業務をAIに任せるほど、判断の拠り 唯一の真実が定まっていれば、AIの コンパウンドの全プロダクトが、同 所になる ブレない事実 が要る。 読み書きが 食い違いを生まない。 じ事実 を見て動ける。 だから Dress Code は、最下層に唯一の事実（SSoT）を置く。 © Dress Code Inc. 38
40. イベントだけでなく、コマンドも残す 一般的に残すもの Dress Code は、さらに イベント コマンド 「何が起きたか」という結果。 「何をしようとしたか」という指示・意図ま で残す。 結果に加えて意図が残るから、再構築の判断材料が増える。 © Dress Code Inc. 40
41. Core DB は設計思想。実現方法はデータ特性で変える 「事実を残す」原則は共通。どう残すかは、ドメインとデータの性質に合わせて最適化する。 S3 / Glue DynamoDB アクセス系データ 従業員データ データ量が多く、ノイズも多い 。 月末・月初にトランザクションが急増 。 安価に大量蓄積し、後からまとめて分析する形が合 スパイクに耐える書き込み特性が要る。 う。 同じ思想でも、データストアの選択はドメインごとに違う——テンプレの一律適用ではない。 © Dress Code Inc. 41
42. 壊して作り直せるのは、事実を残しているから 状態（Read Model）は使い捨てていい。スキーマが陳腐化したら、躊躇なく壊せる。 Read Model を破壊 蓄積イベントは残る 新しい状態を再生成 事実は不変に積まれている イベントから作り直す 陳腐化した状態は捨ててよい （使い捨て） スキーマを壊しても、事実から状態を作り直せる。これが 破壊性 × 回復性 の、データ層での姿。 © Dress Code Inc. 42
43. 実例：事実（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
44. 04 +α ADR + 仕様を残す開発プロセス ADR → SDD → 実装 という一連の流れで、上流の事実がそのまま実装の根拠となる © Dress Code Inc. 44
45. 3つのレイヤーごとの「事実」と「導出」 源泉 ＝ 守る（事実・不変・永続） データ コード アーキテクチャ イベント ── 誰が・いつ・何をしたか EmploymentSigned → DeviceAssigned → InvoiceIssued → … 仕様 ── どう振る舞うべきか（SDD） 入力・出力・業務ルール・受け入れ条件 意思決定 ── なぜそう作ったか（ADR） 導出 ＝ 捨ててよい（再生成できる） 現在の残高・在籍状態 生成されたコードそのもの 現状のモジュール構成図 選んだ／捨てた選択肢・その時の前提とトレードオフ © Dress Code Inc. 45
46. 開発プロセスに織り込む コード層の事実＝仕様、アーキ層の事実＝意思決定。 この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
47. 意思決定を事実として残す ── ADR Architecture → Any へ。領域も大小も問わず、「なぜ」を全部残す。 Notionにとにかく全部残す 考え方の転換 Architecture Decision Record Any Decision Record 週次で共有・FBし文化にする “全部（Any）残せばええねん” 「なぜそうなったか」が追える データ層でイベントを残すのと同じ原則を、アーキテクチャ層では”意思決定を残す”として体現している。 © Dress Code Inc. 47
48. 仕様を事実として残す ── SDD（Spec-Driven Development） 仕様 ＝ 「どう振る舞うべきか」という事実。実装は、そこから導出する。 一般的な SDD（仕様駆動開発） Dress Code は、こう運用 仕様の「残し方」に3段階ある 「事実を残す」ための3つの選択 Spec-anchored を選択 Lv.1 Spec-first 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
49. ドキュメントはAIの味方！スタートアップのアジャイルを加速するADR © Dress Code Inc. 49
50. グローバルなコンパウンド戦略を支えるモジュラーモノリスとドメイン駆動設計 © Dress Code Inc. 50
51. 「壊して作り直せる」は、万能ではない ES/CQRS は運用・学習コストが高い 全システムに適用すべきではない。データ移行・整合性・ダウンタイムの制約は現実に残る。 どこから始めるか 変更頻度が高く、事実を残す価値が大きい中核領域から。 「SSoTを残す」 ≠ 「全部をESにする」 残すべき事実を見極めることが本質。手段の全面採用が目的ではない。 © Dress Code Inc. 51
52. 冒頭の問いに、答えられるようになる 冒頭の問い ① 答え 1年前の設計判断を、今も正確に追 ADR で意思決定を事実として全部残す。 いかけられますか？ 「なぜ」は、Notion AI に聞けば返ってくる。 答え ── 問いの前提を、ひっくり返す 冒頭の問い ② AIが書いたコードを、半年後も自 信を持って変更できますか？ そもそも変更し続けない。 壊して作り直す。 SDD の仕様が残っていれば、AI が再生成できる。 © Dress Code Inc. 52
53. 05 まとめ コードを守るのではなく、事実を残す。 © Dress Code Inc. 53
54. なぜ、「事実」を残すのか コードも状態も構成図も、すべて導出物。源泉である事実だけは、失えば二度と作れない。 1 2 3 AIは、事実を作れない 事実があれば、作り直せる AIが「働く」拠り所になる 「何が起きたか」「なぜ決めた か」は、失うと生成では復元でき ない。 仕様・意思決定・イベントが残っ ていれば、導出物はAIがゼロから 再生成できる。 業務をAIに任せるほど、判断の土 台になるブレない唯一の事実が要 る。 不可逆 ── 唯一守るべきもの 破壊性 × 回復性 ── 壊して作り直せる 業務自動化 ── SSoTが土台 だから、守る対象を 成果物 から 事実 へ。 © Dress Code Inc. 54
55. 守る対象を 成果物 から 事実 へ 残す源泉（事実） 捨てる導出物 Dress Code の仕組み データ イベント ＋ コマンド 状態 / Read Model Core DB（ES / CQRS） コード 仕様 生成されたコード SDD（Spec-Driven Development） アーキ 意思決定 現状の構成図 ADR（Any Decision Record） レイヤー 源泉を残し、導出物は壊して作り直す。これが、速度と持続性を両立させる AI 時代の設計原則。 © Dress Code Inc. 55
56. 守る対象を 成果物 から 事実 へ 冒頭のコールバック 今日から手を付けられること 事実を残せば、破壊性 × 回復性 が手に入る 1 既存設計の「事実が残っている部分 ／ AIは事実を作れない。 事実を SSoT として残すこと で速く・長く作り続けられる。 重要な設計判断を ADR として残し始める 2 失われている部分」を棚卸しする © Dress Code Inc. 56
57. 06 宣伝 © Dress Code Inc. 57
58. 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
59. カンファレンス＆イベントにも登壇中！！ 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.
60. コンパウンドSaaSに挑戦する仲間を募集しています！ © Dress Code Inc. 60
61. ご清聴ありがとうございました！！！ ブースや懇親会でもお話ししましょう！ © Dress Code Inc. 61