ツール散乱 ─ single source of truth が崩壊する組織と、テーマ単位の集約設計

• 想定読者： Notion・Confluence・Slack・Drive・GitHub wiki が散在する組織の IT・知識マネジメント・組織変革担当
• 前提知識： 「組織のコンテキスト供給能力を整える実装ガイド」12パターン G の概要
• 所要時間： 通読 約13分／要点把握 約4分

概要

Notion・Confluence・Slack・Google Drive・GitHub wiki・Quip——大企業の典型的な knowledge スタックでは、これらに同じテーマの文書が散在する。検索しても見つからず、結局「あの人に聞く」に戻る。

本記事は、姉妹記事「組織のコンテキスト供給能力を整える実装ガイド」12パターン G を独立記事として深掘りする。ツール統合より 「テーマ単位の single source of truth」 設計を中心に、新規ツール導入時の deprecation 義務、横断検索の整備を扱う。

症状：ツール散乱の現実

典型的な症状：

• 同じプロジェクトの情報が Notion・Confluence・Slack・Drive に分散
• 「最新版はどこ？」が常に問題になる
• 横断検索しても、上位に古い情報や別バージョンが並ぶ
• 「Wiki に書いた」「Slack で共有した」「メールで送った」が同じ情報の3バージョン
• 部門ごとに採用ツールが違い、横断的なやり取りで摩擦
• 退職時に「あのドキュメントは○○部の Notion にある」「いや Drive のはず」が頻発
• AI に渡すコンテキストの所在が不明（C パターンと接続）

これらは大企業ほど深刻だ。Productiv の SaaS Management Index¹ や Okta の “Businesses at Work” レポート² によれば、企業平均の SaaS 数は数百を超える組織も珍しくない。Panopto の調査³ では、81% の従業員が必要情報を得られず frustration を経験している。

メカニズム：誰の管轄でもなく増える

ツールは部門・時代・買収・リーダー個人の好みで増える。統合の意思決定が誰の管轄でもなく 放置される：

• 部門ごとに最適化：エンジニアリングは GitHub・Notion、営業は Salesforce・Confluence、HR は別のシステム
• 時代の流れ：5年前のツールが残り、新しいツールも追加される
• 買収：被買収企業のツールが統合されないまま並走
• リーダー個人の好み：新任 CTO が好みのツールを導入、前任のツールも残る

統合する意思決定をする人が組織内にいない。「全社ツール統一」を打ち出すと部門の自律性と衝突し、現場から反発が出る。だから誰も決めない。

「全社統一ツール」が解にならない理由

直感的には「全社で統一すれば解決」だが、これは大抵失敗する：

• 部門ごとの専用ニーズが満たされず非効率
• 移行コストが膨大（数千人月）
• 移行中に旧ツールも残るため、結局並走
• 統一しても「フォルダ・ページ構造」がバラバラで検索性は改善しない
• 統一したのに「あのページどこ？」は変わらない

横断検索ツールも完全な解にならない

Glean / Notion AI / Slack 内検索などの横断検索ツールは助けになるが、完全な解ではない：

• 埋もれた情報は検索でも上位に出ない
• 古い情報と新しい情報の区別がつきにくい
• 部門ごとのアクセス権限で検索結果がバラつく
• AI による要約は、複数ソース間の矛盾を解決できない

横断検索は 補完 であって 本体 ではない。

対処の方向

1. テーマ単位の single source of truth

ツール統合ではなく テーマ単位 で single source of truth を決める：

テーマ	Single source
コードに関する判断（ADR等）	GitHub（リポジトリ内）
戦略・経営方針	Notion / Confluence のいずれか1つ
人事制度・規程	Confluence / 専用 HR システム
顧客情報	Salesforce
営業契約	Drive / 契約管理システム
インシデント対応	PagerDuty + GitHub

各テーマで「ここに書いてあれば公式」「これ以外は参考情報」と明確化する。ツールではなくテーマで分割する のが鍵だ。

2. 新規ツール導入時の deprecation 義務化

新規ツール導入のルール：1つ入れるなら1つ捨てる。

• 新ツール導入の意思決定プロセスに「このツールが入ると何が deprecated になるか」を必須項目に
• deprecated になるツールの移行プランと期限を提示
• 既存データの移行責任を明確化
• deprecation 後の旧ツール read-only 化期間を設定

これは組織の「ツール採用ペース」を強制的に減速させる。だが SaaS sprawl の暴走を防ぐ唯一の構造的対処だ。

3. 横断検索の整備（補完として）

テーマ単位の集約と並行して、横断検索ツールを整備：

• Glean / Notion AI / Slite / 専用 enterprise search
• 検索結果に「ソースのテーマ」「最終更新日」を表示
• 古い情報と新しい情報を区別する UI
• AI 要約には「ソース複数で矛盾あり」のアラート

横断検索は補完ツールで、テーマ集約の代替ではない。

4. 「先週情報を探して見つからなかった件」を継続的に拾う

1on1 で 「先週情報を探して見つからなかった件はあった？」 を継続的に拾う：

• 月次で集計、テーマ別に分類
• 同じテーマで複数件発生したら集約レビューを実施
• 検索性改善の優先順位付けに使う

これは ground truth だ。組織のメンバーが実際に困ったケースを記録することで、検索性の本当のボトルネックが見える。

5. ツール変更履歴と移行ガイドの文書化

deprecated になったツールも、その存在・役割・代替先を記録する：

• 「2024年に Quip → Notion 移行」「旧 Quip ページの URL → 新 Notion URL 対応表」
• 退職者が知っているツールから新人が情報を引き継げる経路
• 過去の決定（ADR）が deprecated ツールに残っている場合の参照方法

これは組織の ツール考古学 で、長期運用に必須だ。

アンチパターン

パターン	何が起きるか	対処
全社ツール統一を打ち出す	移行コストと部門反発で頓挫	テーマ単位の集約
新規ツールを deprecation なしで追加	SaaS sprawl が累積	1入れたら1捨てる
横断検索ツールに依存	補完が本体扱いされる	テーマ集約と併用
ツール変更履歴を残さない	過去のドキュメントが探せなくなる	移行ガイドの文書化
部門の自律性を理由に統合議論を避ける	全社視点が消える	「テーマ単位」なら部門自律と両立

まとめ

• ツール散乱は誰の管轄でもなく増えるため、統合の意思決定が放置される
• 「全社統一ツール」「横断検索ツール」は完全な解にならない
• 対処：テーマ単位の single source of truth／新規導入時の deprecation 義務／横断検索は補完／1on1 で検索失敗を拾う／ツール変更履歴の文書化
• ツールではなくテーマで分割する設計が鍵

関連記事

• 組織のコンテキスト供給能力を整える実装ガイド ─ 直視から、修復へ - 本記事の親記事
• ドキュメンテーション・シアター - 検索性とドキュメント生死
• 「AI が文脈を察してくれる」という誤信 - AI に渡すソースの所在
• ADR / Pitch / キックオフメモの実装ガイド - 検索可能性の設計

参考資料

1. Productiv Q2 2024 SaaS Management Index Report - Productiv (2024). 企業平均の SaaS 数とトレンド。【信頼性: 中〜高】 ↩︎

2. Businesses at Work 2024 - Okta (2024). エンタープライズ SaaS 採用動向。【信頼性: 中〜高】 ↩︎

3. Inefficient Knowledge Sharing Costs Large Businesses $47 Million Per Year - Panopto + YouGov (2018-07). 81%が必要情報を得られず frustration。【信頼性: 中〜高】 ↩︎