技術的負債から考える、AI時代のエンジニアリング投資 — ビズリーチの技術的負債と向き合った経験から、変更し続けられるソフトウェアを考える/ technical-debt-con2026

2026年9月16日開催「技術的負債に向き合うConference 2026」の登壇資料です。

▼関連資料
リアーキテクティングのその先へ 〜品質と開発生産性の壁を越えるプラットフォーム戦略〜
https://speakerdeck.com/visional_engineering_and_design/architecture-con2025

ビズリーチにおけるリアーキテクティング実践事例
https://speakerdeck.com/visional_engineering_and_design/jjug-ccc-2025-spring

プロダクト全体で取り組むSREing イシューから始める信頼性・生産性向上の実践
https://speakerdeck.com/visional_engineering_and_design/sre-next-2024

ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う
https://speakerdeck.com/visional_engineering_and_design/jjug-ccc-2022-fall

AI駆動開発が変える、大規模開発の前提 ーHuman in the Loop から Human on the Loop へ
https://speakerdeck.com/visional_engineering_and_design/aie2026

検索ランキングの比較のためにInterleavingの導入と評価をした際の工夫
https://engineering.visional.inc/blog/615/implement-interleaving-for-search-evaluation/

HR領域の検索が直面する課題 - 双方向マッチングの難しさと技術的挑戦
https://engineering.visional.inc/blog/660/bizreach-search-core-group/

-----
Visionalのエンジニアリングに関する最新情報はX、ブログで発信しています！📣

▼Visional Engineering Blog
https://engineering.visional.inc/blog/

▼VISIONAL ENGINEERING / X
https://twitter.com/VISIONAL_ENG

Transcript

1. 技術的負債に向き合うConference 2026 技術的負債から考える、 AI時代のエンジニアリング投資 ビズリーチの技術的負債と向き合った経験から考える、変更し続けられるソフトウェアのつくり方 株式会社ビズリーチ（Visionalグループ） 菊池信太郎
2. 自己紹介 Shintaro Kikuchi 菊池 信太郎 株式会社ビズリーチ プロダクト本部 プラットフォーム統括部 統括部長 SIerを経て、ビズリーチには2018年から在籍 ビズリーチでやってきたこと ヘッドハンター向けプロダクト、採用企業向けプロダクトの開発 組織横断のプロジェクトリード、プラットフォーム開発 プロセス改善、ナレッジマネジメント、リアーキテクティングの推進など 最近は5歳の子どもと一緒にポケモンコンテンツを大量に浴びています。 2
3. ビズリーチの紹介 即戦力人材と企業をつなぐ転職サイト「ビズリーチ」 ⼈材検索・スカウト 求⼈掲載 求職者 会員ユーザー 職務経歴書を登録 返信・応募 スカウトを受信 ⼈材検索・スカウト 求⼈掲載 返信・応募 直接採⽤企業 ⼈事・採⽤担当 ヘッドハンター ⼈材紹介会社 3
4. プロダクトを変え続ける力に投資する AI時代、技術的負債とどう向き合うのか？何に投資すべきなのか？ 技術的負債は、なぜ返しにくくなるのか？ すでにある構造的負債を、どう解いていくか？ AIが正しい方向へ、安全に、速く変更するには、何が必要か？ 変更の効果をどう確かめ、次の改善につなげるか？ 4
5. プロダクトを変え続ける力に投資する プロダクトを変更し、顧客へ届け、結果から学ぶ 期待と結果を比べ、判断の前提を確かめ、次の変更へ戻す。 追加の調査や調整が増えると、結果を得るまでの時間も延びる。 変更に伴う追加負担 事業仮説 変更を届ける 結果を観察 次の判断 観察から学 、次の仮説を試す 5
6. プロダクトを変え続ける力に投資する 事業を理解し、プロダクトを変え続ける力に投資する 6
7. プロダクトを変え続ける力に投資する 技術的負債と向き合ってきた経験から、AI時代の投資を考える 1 技術的負債は、なぜ返しにくくなるのか 2 責務を見直して合意し、構造を段階的に変える 3 AIが正しい方向へ、安全に、速く変更できる環境に投資する 4 変更の効果を確かめ、次の改善と投資を決める 7
8. 技術的負債は、なぜ返しにくくなるのか 8
9. 技術的負債は、なぜ返しにくくなるのか ビズリーチのプロダクト構成 社内向け プロ クト 求職者向け CSプロ クト ヘッドハンター向け CSプロ クト 採用企業向け CSプロ クト お客様向け プロ クト 求職者向け プロ クト ヘッドハンター向け プロ クト 採用企業向け プロ クト 業務支援 プロ クト バッチ処理 共有DB 9
10. 技術的負債は、なぜ返しにくくなるのか 当初は、全体を1つのプロダクトと捉えていた 認識に沿ったモノレポ・共有DB 求職者向け・採用企業向け・ヘッドハンター向けを、合わせて1つのプロダクトと捉えていた。 モノレポ・共有DBは、その捉え方に沿った自然な構成だった。 少人数では大きな支障がなかった 開発者が少ない当時は、開発チームは分かれておらず、 全員が全てのコードを理解していたので、 DBと密結合していても大きな支障はなかった。 10
11. 技術的負債は、なぜ返しにくくなるのか 事業は成長を続け、プロダクトも組織も大きくなった 初期には大きな支障がなかった構造も、変更する機能や関わるチームが増えると、影響の調査や調整が 必要になった。 出典：JJUG CCC 2022 p.15（ビジョナル株式会社 2022年10月の説明資料より） 11
12. 技術的負債は、なぜ返しにくくなるのか 短期戦略を重視した結果、変更容易性が失われ、開発生産性が低下 事業成長のために、技術的負債を認識しながらも、短期施策を優先する必要があった。 改善の経緯：JJUG CCC 2022／2025、SRE NEXT 2024、アーキテクチャカンファレンス2025 12
13. 技術的負債は、なぜ返しにくくなるのか 追加作業と依存が積み重なり、構造を直しにくくなる 13
14. 技術的負債は、なぜ返しにくくなるのか 過去数年の取り組みで、各プロダクト内の変更容易性は取り戻しつつある 積み重ねた改善 CI/CD テスト・QA ドメインモデリング・設計改善 リリースプロセス改善 リアーキテクティング 検索などのマイクロサービス化 それでも、まだ複数の領域にまたがる内部依存は残っている。 改善の経緯：JJUG CCC 2022／2025、SRE NEXT 2024、アーキテクチャカンファレンス2025 14
15. 技術的負債は、なぜ返しにくくなるのか 組織内の判断は速くなっても、システムの結合は残った 逆コンウェイで、組織を価値提供の単位に分けた結果、組織内に閉じる判断は速くなった。 レジュメ・求人・メッセージなどの変更は、求職者向けと企業向けの組織をまたいでしまう。 社内向け プロ クト 求職者向け CSプロ クト ヘッドハンター向け CSプロ クト 採用企業向け CSプロ クト お客様向け プロ クト 求職者向け プロ クト ヘッドハンター向け プロ クト 採用企業向け プロ クト 業務支援 プロ クト バッチ処理 破線：組織の境界 共有DB common・共有DBは横断して残る 15
16. 技術的負債は、なぜ返しにくくなるのか 例：求職者側の処理が、採用企業側の「対応済み」を判断 当初は、進捗を求職者と採用企業の共有モデルとして捉えていた。 学習に伴い、お客様に見える機能は変更したが、データモデルはそのまま残った。 求職者向けプロ クト 共有DB 採用企業向けプロ クト メッセージ本文・スレッド メッセージ保存処理 求職者側の メッセージ ックス 参照 呼び出す 「対応済み」の判定 採用企業側の業務判断 破線枠：共有DB 採用企業側の メッセージ ックス メッセージ画面・ 対応状況の表示 採用企業側の対応状態 （対応済みフラ ） 濃い箱：送信側で実行される、受信側の業務判断 実線矢印：書き込み・参照 16
17. 技術的負債は、なぜ返しにくくなるのか 問題は、分かっていなかったことだけではない。 分かったことを、構造へ反映することが難しかった。 17
18. 技術的負債は、なぜ返しにくくなるのか 負債が生まれることと、長期化することは違う 01 02 03 発生 増幅 固定化 不確実な中で判断する 依存や例外が積み重なる 複数の責任領域にまたがる 設計の前提が変わる 変更の影響が広がる 一つのチームでは 返済を決められない 返済する意思決定そのもの 難しくなる。 18
19. 技術的負債は、なぜ返しにくくなるのか 変更がチームをまたぐと、返済の判断にも合意が必要になる レジュメ・求人・メッセージの横断変更では、次の仕事が必要だった。 必要だったこと 進めるうえでの難しさ 各プロダクトのPO・EMへ説明・調査依頼 一つの組織では影響と仕様を確かめきれない ロードマップを合意 各プロダクトの優先順位をそろえる必要がある 移行先の責務を整理 どこが何を判断するか、責務設計に合意する必要がある 19
20. 技術的負債は、なぜ返しにくくなるのか 一緒に変える必要がある部分がチームをまたぐと、調整の負担が増える 結合の「距離」には、組織も含まれる 同じチームで変更できる場合と、異なるチームで変更をそろえる場 合では、必要な調整の労力が変わる。 今回の経験との接点 組織内の判断は速くなったが、一緒に変更する必要のある部分は組 織をまたいで残った。 Vlad Khononov 著／島田浩二 訳 『ソフトウェア設計の結合バランス』 インプレス、2025年 第8章 pp.152–153（要約） 各チームが自分たちで変更できる範囲を広げるために、責務と依存関係を見直す。 20
21. 責務を見直して合意し、構造を段階的に変える 21
22. 責務を見直して合意し、構造を段階的に変える 今の業務理解から、誰が何を担うかを言語化する 業務を捉える 誰にどんな価値を届け、どんな判断やルールが必要か 責務を分ける それぞれが何を判断し、どの情報を持ち、更新するか 関係を定める 責務間で何をやり取りし、各チームがどこまで決めるか 22
23. 責務を見直して合意し、構造を段階的に変える RFCに判断材料をまとめ、組織横断で合意する ビズリーチでは、組織横断のアーキテクチャ変更を審議するため、アーキテクチャ委員会を組成した。 判断材料を書く RFCに背景、責務、選択肢、影響範囲をまとめる。 組織横断で検討する 関係者が非同期でレビューし、委員会が判断案をまとめる。 合意と実行をつなぐ 判断理由と条件を記録し、事業PO会の承認・実施計画へつなぐ。 検討中の案と合意した方針を区別し、判断の根拠を後から参照できるようにする。 23
24. 責務を見直して合意し、構造を段階的に変える 横断的な変更には、責任と移行の時間も確保する 横断変更は、事業PO会で相談し、ロードマップを合意してきた。 計画へ含めるもの 決めること 判断主体 責務の所有者と、API・イベントの仕様変更の合意先 優先順位 事業PO会で相談し、各プロダクトの計画とそろえる 利用側の工数 切り替え・検証・旧経路撤去までを計画に含める 合意した変更を進めるために、利用側の移行時間も計画に含める。 事業PO会：事業長、プロダクト本部長、各プロダクトPOを含む、プロダクトのロードマップに関する意思決定を行う会議体。 24
25. 責務を見直して合意し、構造を段階的に変える 責務に応じて分け、API・イベントでつなぐ 従来の構造 求職者向けプロ クト 合意した責務設計 共有DB 採用企業向けプロ クト 求職者向けプロ クト メッセージ本文・スレッド メッセージ保存処理 マッチン 要求 「対応済み」の判定 採用企業側の業務判断 採用企業側の メッセージ ックス メッセージの保持 本文・スレッド・添付・記録 採用企業向けプロ クト 要求 送信・返信の要求 求職者側の メッセージ ックス 送信・返信の要求 メッセージの伝送 送信受付・送信可否 ロック適用 参照 呼び出す プラットフォーム メッセージ画面・ 対応状況の表示 採用企業側の対応状態 （対応済みフラ ） 求職者側の受信箱・既読 （画面・業務状態） 通知 伝送結果の記録 通知イベントの仕様 通知 採用企業側の受信箱 「対応済み」・進捗 各業務固有の状態は持たない 破線枠：共有DB 濃い箱：送信側で実行される、受信側の業務判断 実線矢印：書き込み・参照 25
26. 責務を見直して合意し、構造を段階的に変える 既存の仕組みを動かしながら、新しい構造へ段階的に移す ストラングラーパターン：既存の仕組みを動かしながら、段階的に置き換える。 1 新しい機能を用意する 既存の仕組みと併存できる形でつくる。 2 呼び出しを少しずつ切り替える 動作を確かめながら、新しい機能へ移す。 3 不要になった旧経路を外す 利用がなくなった処理を撤去する。 参照：Sam Newman『モノリスからマイクロサービスへ』第3章（オライリー・ジャパン、2020） 26
27. 責務を見直して合意し、構造を段階的に変える 最初から完璧な設計はない。理解が進んだときに変えられることが大事 負債の比喩 DDDの洞察 未成熟なコードでも、 顧客に届ける価値はある。 ただし、書き直して返済しなければ、 利息が積み重なる。 ドメインへの理解が深まったら、 その洞察をモデルの リファクタリングに反映する。 Ward Cunningham（1992）｜要約 Eric Evans（2015）｜要約 The WyCash Portfolio Management System Domain-Driven Design Reference, p.8 Refactoring Toward Deeper Insight ビズリーチで技術的負債と向き合って学んだこと 事業が変わる以上、責務の境界と実際の業務とのズレは避けられない。 短期施策を優先する判断は残るが、ズレを発見し、理解を構造へ反映する仕事を先送りしない。 出典：Cunningham（1992）／Evans（2015） 上段は各資料の要約 27
28. AIが正しい方向へ、安全に、速く変更できる環境に投資する 28
29. AIが正しい方向へ、安全に、速く変更できる環境に投資する これまでのエンジニアリング投資を、AIも使える変更能力へつなぐ 事業理解・責務設計 何を変え、何を守るか。その意味と判断理由を明らかにする。 テスト・実行基盤 ルールを確かめ、許可された範囲で変更を試せるようにする。 SRE・可観測性 ログや指標から変更の影響を捉え、修正と次の判断へ返す。 これらを一連の開発の流れとしてつなぎ、変更し続ける力にする。 29
30. AIが正しい方向へ、安全に、速く変更できる環境に投資する 人間が境界を見いだし、ドメインモデルとして意味を与える 顧客・業務に向き合う 同じ言葉が何を意味し、どんな判断が必要なのかを捉える。 境界とモデルを形づくる 事業をどう変えたいかを踏まえ、何を一緒に扱い、何を別々に変えるかを考える。 AIが探究を助ける 現行挙動を調べ、境界の候補を比べ、モデルの矛盾を指摘する。 現行挙動・合意した設計・未決定事項を、判断理由とともに残す。 30
31. AIが正しい方向へ、安全に、速く変更できる環境に投資する 責務の境界を、変更と検証の単位にする 業務の内側 他の責務との接点 公開する範囲 その領域の業務ルールを、内部 で変更・検証できるようにす る。 API・イベントの仕様を明確に し、連携への影響を確かめる。 内部のデータ構造をそのまま公 開せず、連携に必要な情報と振 る舞いを定める。 変更に必要な理解の範囲と、影響を確かめる範囲を絞る。 参照：Khononov『ソフトウェア設計の結合バランス』pp.128–129、154–155（要約） 31
32. AIが正しい方向へ、安全に、速く変更できる環境に投資する 事例：候補者検索をAPIで分離し、ランキングを継続的に改善する 候補者検索をAPIで分離した結果、ランキングを独立して変更できるようになった。 新旧ランキングを利用者の行動から比較・評価する仕組みを整え、改善を重ねている。 求職者向けプロダクト 候補者情報 職務経歴など 候補者検索API 候補者情報 ランキング 誰を、どの順序で 提⽰するか 採⽤企業向けプロダクト 検索条件 候補者を検索する 検索結果を⾒る 検索結果 スカウトを送る AI時代への展開 境界づけられたコンテキストを、改善を速く繰り返せる単位にする。 その業務の文脈をAIへ伝え、変更・検証・修正の一連の仕事に活用していく。 出典：Visional Engineering Blog「検索ランキングの比較のためにInterleavingの導入と評価をした際の工夫」（2024） 32
33. AIが正しい方向へ、安全に、速く変更できる環境に投資する 守るべきルールを、違反を検知できる形にする 業務ルール・連携仕様 ドメインのテストと、API・イベントの契約テストで確かめる。 依存の方向 禁止した依存の追加を、静的解析や構造テストで検知する。 操作できる範囲 実行権限と隔離環境で、変更できる対象や操作を制限する。 人間が意味づけたルールを、実行時に使える検証と制御へつなぐ。 33
34. AIが正しい方向へ、安全に、速く変更できる環境に投資する 環境の準備から検証・修正までを、一続きに実行できるようにする 実行や結果の受け渡しを毎回人が担うと、AIの検証・修正も人待ちになる。 1 2 3 4 5 環境を立ち上げる データを用意する 処理を動かす 結果を取得する 直して再実行する 依存先を含めて、 手元で同じ構成 業務上の代表ケース と境界ケース 変更前後を、同じ入力 で実行できる 差分を機械的に 比較でき、ログ 修正から再検証まで を、短く繰り返せる を再現できる を揃えられる 参照：OpenAI（2026）Harness engineering: leveraging Codex in an agent-first world や指標を読める 34
35. AIが正しい方向へ、安全に、速く変更できる環境に投資する 情報・ツール・実行結果をつなぎ、AIの仕事を支えるのがハーネスである 接続するもの コード 責務を整理したRFC 判断理由 未決定事項 データの所有 API・イベントの仕様 利用側の依存 隔離環境 再現データ 合意した検証条件 実行ログ 失敗ケース 採用判断の経路 AIと進める仕事 既存処理を調べる 変更案をつくる 変更案を試す 結果から見直す 次の判断へ 返すもの 現在の処理と 目指す責務の対応 未合意を決定扱いしない 何を移し、 何を各業務へ残すか 維持できた挙動 意図した差分 意図しない差分 実装修正で済むか API・イベントの変更箇所 業務ルールや連携仕様の 見直しが必要か 見直しの結果を、調査・設計へ戻す 35
36. AIが正しい方向へ、安全に、速く変更できる環境に投資する 移行の完了を待たず、調査と検証からAIを活用する 既存の構造のまま始められる投資 責務・移行と並行して進める投資 現行挙動の調査と、その説明の整備 データの所有と、API・イベントの仕様設計 隔離環境と再現データでの検証 利用側の移行と、旧経路の撤去 判断理由と未決定事項の記録 API・イベントの契約テストと観測の更新 AIで調査やテスト整備の負担を下げ、これまで費用が見合わず先送りした改善を見直す。 36
37. 変更の効果を確かめ、次の改善と投資を決める 37
38. 変更の効果を確かめ、次の改善と投資を決める 検証結果から実装を直し、事業の変化や得られた知見から前提を見直す 内側：合意した条件で実装を直す 外側：意味・境界・評価を見直す 業務モ 合意した理解 ル・API／イベント仕様・検証条件 前提として使う 変更を実行 検証 結果 合意した条件を満たさない：実装を直す 条件そのものに 矛盾・不足がある 事業の変化 新しい証拠 根拠を確かめ、理解を見直す 意味・境界・評価を更新 見直した理解で、業務モ ル・API／イベント仕様・検証条件を更新する 38
39. 変更の効果を確かめ、次の改善と投資を決める 実装・AIの仕事・事業への効果を分けて確かめる 確かめる対象 確かめること 実装 合意した業務ルール・API／イベントの仕様を満たしたか AIの仕事 根拠と権限に沿って進め、必要な判断を人へ返したか 事業への効果 目的に照らして役立ったか。費用や副作用はどうか 判断時点の期待と結果を比べ、根拠・適用条件・未確定な点を残す。 参照：Anthropic（2026）Demystifying evals for AI agents ／ Microsoft（2023）How to Evaluate LLMs 39
40. 変更の効果を確かめ、次の改善と投資を決める 実装を変える権限と、正解を変える権限を分ける 意味とモデルを見直す 人間が顧客や業務を捉え直す。AIは調査・比較・見直し案で助ける。 変更する条件を決める 責任を持つ人・チームが、業務ルールや仕様の採否と委任範囲を決める。 実装と検証へ反映する AIも合意内容に沿って更新する。矛盾や不足があれば、人に判断を求める。 人間の仕事は、最後の承認だけではない。 40
41. 変更の効果を確かめ、次の改善と投資を決める 次の変更を支える投資を、日々の開発と横断計画に組み込む 通常の変更に含める 判断理由・検証条件・再実行手段を残し、次の変更でも使えるようにする。 横断計画で確保する 複数の利用側に及ぶ責務再設計・移行・旧経路の撤去を進める。 当面維持する領域も選ぶ 繰り返す負担とリスク、移行・維持費、今後の変更必要性を比べる。 意味・仕様・評価・実行と観測の基盤は、AIモデルの更新後も引き継ぐ。 41
42. 変更の効果を確かめ、次の改善と投資を決める 成果は、プロダクトの次の変更をどう進められるかで見る 今回の変更は終わったか 次回の追加作業は減ったか 機能が動く。合意した条件を満たす。 見るもの 品質 意図しない差分、障害、手戻り 反復する調査・操作 同種の変更で繰り返す説明や手作業 所要時間と総費用 判断待ちを含め、変更の完了までにかかる時間と維持費 次の判断への反映 矛盾・不足や検証結果を、次の判断に使えたか 42
43. 変更の効果を確かめ、次の改善と投資を決める 今日の価値を届けながら、明日も変え続けられるプロダクトに投資する 経験からの学び 事業づくりの速度を優先し、負債を引き受けることはある。 しかし、理解を構造へ反映する仕事を先送りしない。 人間が担う仕事 事業を理解し、境界を見いだし、ドメインモデルとして意味を与える。 AI時代の投資 AIが正しい方向へ、安全に、速く変更できる環境をつくる。 プロダクトを変え、顧客へ届け、結果から学ぶ。そのループを速め、事業の成長につなげる。 43
44. APPENDIX APPENDIX 44
45. APPENDIX：因果ループ図 技術的負債と、変更し続ける⼒の因果関係 01 発⽣ 学習で判明した 意味・責務の違い 短期の価値を優先した 設計上の妥協 設計が満たすべき条件の変化 新たな理解が設計へ未反映 + + 現在の変更に合わない 設計・境界の残存 追加負担を⽣む構造的不適合 ­ + 02 増幅 + + 1回の変更で⽣じる 余分な調査・調整・検証 不要な変更波及・⼿戻りを含む 現在の変更を 妨げる場合 03 固定化 + + 依存の切り離し・移⾏に 必要な作業量 仕様・設計意図を 理解し直す難しさ R3a 技術的固定化 R3b 認知的固定化 元本相当：解消のための費⽤ + ­ 構造修正の完了速度 依存解消・移⾏・旧経路の撤去まで + + ­ + R2 改善が余⼒を⽣む + ­ ­ 改善へ配分できる余⼒ 実⾏・検証へ再投資 依存が責任境界を またいで残る場合 返済に必要な 横断調整の負担 + 費⽤・便益・判断権限の 組織間での分散 他組織の計画・優先順位に依存 ­ AIによる 個別対応の省⼒化 ⾃⼰完結できる 実⾏・検証能⼒ 返済へ配分 暗黙仕様・知識の集中 責務・権限と変更範囲が整合 R1 利払いが改善余⼒を削る 再設計を⾒送った 継ぎ⾜し・迂回への依存 + 領域内の判断・ 並⾏実⾏能⼒ + + ­ 期間中の追加作業量 〈利払い〉 ­ R4 継ぎ⾜しが次の変更を重くする 古い構造に積み上がる 依存・例外 ­ + 横断依存が 残る場合 構造が追従しない場合 + 組織拡⼤に伴う 分業・権限移譲 対象領域の 期間中の変更回数 事業・利⽤規模の変化 + 合意・移⾏の待ち時間 R3c 組織・経済的固定化 AIによる返済作業の⽀援 調査・実装・検証・移⾏の作業 + 費⽤を負担する側と便益を得る側が異なる + 観測と事業上の判断 観測された損失に基づく 修正の優先度 DDD・ドメイン理解 意味・責務・設計意図を明確にする → 理解の難しさ／境界のずれ Platform Engineering 環境・デプロイ・連携をセルフサービス化 → ⽇々の追加作業を減らす QA・E2E・API・イベントの契約テスト 必要な振る舞いと変更の安全性を検証 → 実⾏・検証能⼒を⾼める SRE・可観測性 損失の観測・標準判断・検知・復旧 → 優先度の判断／反復負担の軽減 責任・権限・優先順位・⼯数 費⽤と便益を横断で捉え、移⾏を揃える → 合意・移⾏待ち／修正の完了速度 利払いと元本は分ける 期間中の利払い ≈ 変更回数 × 1回の追加負担 元本に相当するもの ＝ 解消に要する費⽤ 上の式は負担を分解する概念式（実測値ではない） 図の前提 複数システムの変更や、必要な協調そのものを 負債とはしない。対象は余分な負担を⽣む構造。 組織拡⼤そのものが負債を⽣むわけではない。 残る技術依存が、組織間の依存になる場合を描く。 余⼒・理解・作業量・合意・移⾏の制約は同時に働く。 AIによる作業⽀援だけでは、合意や撤去は完了しない。 すべての負債がこの順序で悪化するわけではない。 変更が少なければ、維持を選ぶ判断もあり得る。 ⽮印とループの読み⽅ 便益・返済費⽤・リスクで判断 + B1 損失を捉え、合意して返済 投資が変える変数 関係組織で合意・確保した 移⾏⼯数 ＋／­：他の条件が同じときの影響⽅向 R：⾃⼰強化 B：打ち消し //：効果の遅れ 破線：配分・合意などの条件付きの関係 線の交差は接続を表さない 図全体は提⽰⽂とこれまでの議論を整理した因果仮説。 実線も実証済みの関係を意味しない。 提供側・利⽤側の双⽅ 45
46. APPENDIX：参考文献 主題 文献・資料 技術的負債の原点 Ward Cunningham, The WyCash Portfolio Management System（1992） 理解とプログラムの乖離 Wardの説明（2009）の翻訳・解説、t-wada（2020） 洞察に向かうモデルの更新 Eric Evans, Domain-Driven Design（2004） 結合と変更の調整 Vlad Khononov 著、島田浩二 訳『ソフトウェア設計の結合バランス』（インプレス、2025） モデルの境界 Martin Fowler, Bounded Context（2014） ハーネスエンジニアリング OpenAI, Harness engineering: leveraging Codex in an agent-first world（2026） 運用と信頼性 Beyer et al., Site Reliability Engineering（2016） AI支援開発 DORA, State of AI-assisted Software Development 2025 46
47. APPENDIX：過去登壇 JJUG CCC 2022 ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う JJUG CCC 2025 ビズリーチにおけるリアーキテクティング実践事例 アーキテクチャカンファレンス 2025 リアーキテクティングのその先へ SRE NEXT 2024 プロダクト全体で取り組むSREing―イシューから始める信頼性／生産性向上の実践 47
48. APPENDIX：Visional Engineering Blog Visional Engineering Blog 検索ランキングの比較のためにInterleavingの導入と評価をした際の工夫 2024年9月26日 HR領域の検索が直面する課題 — 双方向マッチングの難しさと技術的挑戦 2025年12月12日 48