# ソシオテクニカル負債 Navigation: [[index]] | [[concepts/_index]] ## 定義 ソシオテクニカル負債(sociotechnical debt)とは、組織の社会的構造(文化・チーム・プロセス)と技術システム(ソフトウェア・インフラ)の間の不整合が生む隠れた累積コストである。Damian A. Tamburri と Elisabetta Di Nitto が2015年のWICSA論文「When Software Architecture Leads to Social Debt」で提示した概念を出典とする。技術的負債と同じく、目先の簡便な解決策を選ぶことで後により多くの作業を生む点は共通するが、技術的負債がツールやコードの変更で解消できるのに対し、ソシオテクニカル負債は人の行動変容を要するため、より解消が難しい。すべてを完済する必要はないが、組織の最重要目標を脅かす負債は対処が必須になる(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]])。 『Observability Engineering』第2版第23章は、CTO[[Darragh Curran]]の公開書簡として、この負債を放置した組織がAI時代に直面する3種類の具体的なパターンを挙げる: 1. **開発者が本番でなくテストの世界に生きている**: developer intentが検証される前に忘れ去られ、production feedbackがopsチームだけの経路(アラート・エスカレーション・サポートチケット)に閉じている状態。 2. **テレメトリがプロダクトでなくインフラとして扱われている**: 開発者が所有し意図的に計装する「プロダクト能力」ではなく、opsが保守しコスト最適化の対象とする「ボルトオン」として扱われている状態。 3. **開発者向けツールがプロダクトとして設計されてこなかった**: 発見(discovery)や認知負荷への配慮なしに蓄積したツール群。プラットフォームエンジニアリングの導入自体もプロジェクト化・単純改名という2つの失敗パターンに陥りがちで、負債が名前を変えて存続する。 ## 横断的知見 - **DORAの2025年調査は「AIは組織の卓越性を新たに作らず、既存の行動を増幅する」と述べ、これはソシオテクニカル負債の定義そのものと直接接続する**: [[DORA]]の年次調査は、AIが強いフィードバックループと規律ある実践を持つ組織では優位性を、遅延シグナルと運用のヒロイズムに頼る組織では混沌を、それぞれ増幅すると報告する。ソシオテクニカル負債の中心的主張(「今日、迅速かつ自信を持って動くことを妨げる負債は、AIの速度でも同じ制約になる」)は、DORAが定量的に観測した「増幅」という現象のメカニズムを組織論的に説明するものと読める。DORAの計測フレームワーク(デプロイ頻度・リードタイム・変更失敗率・MTTR)は負債の症状を数値化する手段、ソシオテクニカル負債の概念はその根本原因を名指す枠組みという役割分担で補完し合う。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]], [[DORA]]) - **プラットフォームエンジニアリングの「単純改名」失敗パターンは、mizzy(2026)がDevOpsからPlatform Engineeringへの系譜として整理した「認知負荷の再配分」構造と同じ現象を、失敗事例として裏側から照らす**: [[プラットフォームエンジニアリング]]の既存知見は、DevOpsが開発者側に寄せた運用の認知負荷をプラットフォームチームが引き受け直す動きとしてPlatform Engineeringを位置づけていた。第23章はこの引き受け直しが実際には起きず、「既存のDevOps/インフラチームを改称しただけ」で運用モデルも開発者志向も変わらないケースが最も一般的な失敗パターンだと指摘する。理念上の系譜(認知負荷の再配分)と実装上の失敗(改名だけで中身が変わらない)が、同じPlatform Engineeringという現象の異なる断面を映し出している。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]], [[プラットフォームエンジニアリング]]) - **技術的負債(コード・システムレベル)とソシオテクニカル負債(組織・人の行動レベル)は解消の難度が異なる階層構造をなす**: [[@2014__SE4ML2014__Machine Learning - The High-Interest Credit Card of Technical Debt]]が扱う[[技術的負債]]は、リファクタリング・静的解析ツール・テストといった技術的介入で(困難ではあるが)解消しうる対象として描かれる。一方本概念は「ツールやコードの変更で解消できる技術的負債」とは異なり「人の行動変容」を要するためより解消が難しいと明示的に対比される。両ソースを並べると、技術的負債の枠組みが「システムに何を実装するか」の問題であるのに対し、ソシオテクニカル負債の枠組みは「その実装をチームがどう扱うか」の問題であり、前者の解消(例: データ依存性の自動アノテーションツール導入)が後者を自動的には解消しない、という補完関係が見える。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]], [[@2014__SE4ML2014__Machine Learning - The High-Interest Credit Card of Technical Debt]]) - **コンウェイの法則は、ソシオテクニカル負債が「なぜ人の行動変容を要するのか」に構造的な根拠を与える**: 本概念は、ソシオテクニカル負債が技術的負債と異なり「人の行動変容」を要するためより解消が難しいと述べるが、なぜ組織構造の変更が技術システムの変更と同程度に困難なのかまでは論じない。『SREの探求』31章の[[コンウェイの法則]]の議論は、システムを設計する組織のコミュニケーション構造がそのままシステム構造に反映されると述べ、相互運用に失敗する2つのソフトウェアコンポーネントの裏には必ずうまくやり取りしていない2つのチームがあると指摘する。この視点に立つと、ソシオテクニカル負債(社会構造と技術システムの不整合)はコンウェイの法則が予測する定常状態そのものであり、技術的な修正だけでは負債が解消しない理由は、組織のコミュニケーション構造という上流の原因を変えない限り技術構造がそこへ回帰し続けるためだと説明できる。31章が示す実践的な診断法(組織図とシステムフロー図を並べて乖離を確認する)は、ソシオテクニカル負債の所在を可視化する具体的な手段としても読める。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]], [[@2021__OReillyJapan__SREの探求 - Chapter 31 複雑なシステムのためのエレジー]] §31.1) ## 未解決の問い - ソシオテクニカル負債の定量化は可能か。技術的負債にはコード複雑度・テストカバレッジのような代理指標があるが、本章が挙げる負債は定性的な組織診断に依存しているように見える。 - Tamburri and Di Nitto (2015) の原論文における社会的負債(social debt)の定義と、本章のsociotechnical debtの定義の異同はどの程度あるか。原論文の詳細な参照が必要。 - ソシオテクニカル負債の解消順序(どの負債から着手すべきか)を決めるフレームワークは、[[組織の信頼性マインドセット]]のようなフェーズモデルと組み合わせられるか。 - AIエージェントが開発ライフサイクルの大半を圧縮する中で、「オブザーバビリティだけが生き残る品質ゲート」という本章の主張は、他のソースでどこまで裏付けられるか。 ## 関連 - 概念: [[プラットフォームエンジニアリング]] / [[DORA]] / [[フィードバック駆動開発]] / [[SRE組織変革]] / [[技術的負債]] / [[コンウェイの法則]] - 実体: [[Darragh Curran]] / [[Intercom]] / [[Fin]] - ソース: [[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]] / [[@2021__OReillyJapan__SREの探求 - Chapter 31 複雑なシステムのためのエレジー]] ## 出典 - [[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]] — Damian A. Tamburri and Elisabetta Di Nitto, "When Software Architecture Leads to Social Debt", WICSA 2015 を引用してsociotechnical debtを定義 - [[@2021__OReillyJapan__SREの探求 - Chapter 31 複雑なシステムのためのエレジー]] — Mikey Dickerson, 「複雑なシステムのためのエレジー」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 31章, §31.1