# 🔧 Adoption Architecture Framework (AAF) v1.0 ## 技術的価値を持続的な組織価値へ変換する設計体系 **Version 1.0** **Created: 2025-12-25** --- ## § 0. Executive Summary ### 本質 ``` 【定義】 Adoption Architecture（採用設計）とは： 技術的価値を社会的価値に変換し 組織の既存システムに不可分に統合させ 持続的な価値ループを生み出す設計行為 ``` ### これは何ではないか ``` ❌ 機能を増やすこと ❌ マーケティングで売り込むこと ❌ 導入時のオンボーディングだけ ❌ カスタマーサクセスの運用改善 ``` ### これは何か ``` ⭕ 「使われ続ける状態」を設計すること ⭕ 採用障壁を構造的に除去すること ⭕ 組織への統合を事前設計すること ⭕ 持続的な価値循環を埋め込むこと ``` ### 背景にある洞察 ``` 【AI時代の真実】 作ることは簡単になった 動かすこと（使われ続ける状態）は簡単にならない 【プロダクトが死ぬ理由】 機能が足りないからではない 組織に「埋め込まれなかった」から 【勝敗を分けるもの】 機能の数 → ✗ 採用設計の質 → ◎ ``` --- ## § 1. 根本軸の定義 ### 軸1：技術的完成度 ⟷ 社会的統合度 ``` 技術的完成度 社会的統合度 （Technical Completeness） （Social Integration） ←───────────────────────────────→ 【左端：技術的完成度】 ・機能が揃っている ・バグがない ・性能が良い ・「良いプロダクト」の従来定義 【右端：社会的統合度】 ・組織に埋め込まれている ・業務フローの一部になっている ・責任・権限が明確 ・「なくてはならない存在」になっている ``` ### 軸2：一時的採用 ⟷ 持続的定着 ``` 一時的採用 持続的定着 （Temporary Adoption） （Sustainable Retention） ←───────────────────────────────→ 【下端：一時的採用】 ・導入直後だけ使われる ・担当者が変わると消える ・流行りで入れたが定着しない 【上端：持続的定着】 ・ずっと使われ続ける ・担当者が変わっても継続 ・組織のインフラになっている ``` --- ## § 2. 4象限マップ ``` 持続的定着 │ 専門家の道具 │ インフラ化 ┌────────────┼────────────┐ │高機能だが │組織の一部に│ │限定利用 │なっている │ │ │ │ 技術的 │ │ │ 社会的 完成度 ─┼────────────┼────────────┼─ 統合度 │ │ │ │作って終わり│一時的に │ │使われない │盛り上がる │ └────────────┼────────────┘ 機能の墓場 │ 流行り物 │ 一時的採用 【各象限の特徴】 機能の墓場（左下）： 技術的には完成しているが、誰も使わない 「良いものを作れば売れる」幻想の末路 流行り物（右下）： 導入時は盛り上がるが定着しない 合意なき導入、表面的なオンボーディング 専門家の道具（左上）： 特定の人には必須だが、組織全体には広がらない 技術者向けツールに多いパターン インフラ化（右上）： 組織の一部として不可欠な存在 AAFが目指す到達点 ``` --- ## § 3. AAFの3層構造 ``` ┌──────────────────────────────────────────────────────┐ │ Layer 3: Value Loop（価値循環） │ │ 使うほど価値が増える構造を設計する │ │ → 持続的定着の「エンジン」 │ └──────────────────────────────────────────────────────┘ ↑ ┌──────────────────────────────────────────────────────┐ │ Layer 2: Integration（統合設計） │ │ 既存システム・文化への埋め込みを設計する │ │ → 社会的統合度を高める │ └──────────────────────────────────────────────────────┘ ↑ ┌──────────────────────────────────────────────────────┐ │ Layer 1: Friction Removal（摩擦除去） │ │ 採用障壁を特定し解消する │ │ → 採用の「入口」を開く │ └──────────────────────────────────────────────────────┘ ``` ### 3層の関係 ``` 【積み上げ構造】 Layer 1なしにLayer 2は機能しない Layer 2なしにLayer 3は機能しない 【優先順位】 まずLayer 1で入口を開く 次にLayer 2で埋め込む 最後にLayer 3で循環させる 【よくある失敗】 Layer 3だけ考える（機能を増やす） Layer 1を軽視する（「良いものは売れる」幻想） Layer 2を忘れる（導入で終わり） ``` --- ## § 4. Layer 1: Friction Removal（摩擦除去） ### 定義 ``` 採用を阻む5つの摩擦を特定し、設計段階で除去する ``` ### 5つの摩擦タイプ ``` ┌─────────────────────────────────────────────────────┐ │ ① 認知摩擦（Cognitive Friction） │ │ 「何これ？わからない」「学習コストが高い」 │ │ │ │ 症状： │ │ ・最初の5分で離脱 │ │ ・「難しそう」で敬遠 │ │ ・機能があるのに使われない │ │ │ │ 処方： │ │ ・即座に価値を体感させる（Time to Value短縮） │ │ ・段階的開示（最初は最小限） │ │ ・既存メンタルモデルへの接続 │ └─────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────┐ │ ② 政治摩擦（Political Friction） │ │ 「誰が責任取る？」「誰が決める？」 │ │ │ │ 症状： │ │ ・稟議が通らない │ │ ・情シスに止められる │ │ ・「上が決めないと動けない」 │ │ │ │ 処方： │ │ ・責任分界点の明確化 │ │ ・決裁者向け説明資料の整備 │ │ ・セキュリティ・コンプライアンス対応の可視化 │ └─────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────┐ │ ③ 運用摩擦（Operational Friction） │ │ 「面倒」「続かない」「手間が増える」 │ │ │ │ 症状： │ │ ・1ヶ月後に使われなくなる │ │ ・入力が放置される │ │ ・「前のやり方に戻る」 │ │ │ │ 処方： │ │ ・既存ワークフローへの最小侵襲 │ │ ・入力の自動化・簡素化 │ │ ・即時フィードバック（やった意味を感じさせる） │ └─────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────┐ │ ④ 経済摩擦（Economic Friction） │ │ 「高い」「ROIが見えない」「予算がない」 │ │ │ │ 症状： │ │ ・価格で比較される │ │ ・「効果が出たら継続」で止まる │ │ ・予算削減で真っ先に切られる │ │ │ │ 処方： │ │ ・価値の定量化（時間削減、エラー減少など） │ │ ・段階的な価格設計（始めやすく、拡大しやすく） │ │ ・コスト中心ではなく投資対効果の語り方 │ └─────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────┐ │ ⑤ 技術摩擦（Technical Friction） │ │ 「既存と繋がらない」「環境が違う」 │ │ │ │ 症状： │ │ ・インテグレーションで頓挫 │ │ ・「うちの環境では動かない」 │ │ ・データ移行で挫折 │ │ │ │ 処方： │ │ ・主要システムとの連携を標準装備 │ │ ・段階的導入パス（全か無かではなく） │ │ ・既存データの活用設計 │ └─────────────────────────────────────────────────────┘ ``` ### Layer 1 チェックリスト ``` □ 5つの摩擦すべてを洗い出したか □ 最大の摩擦はどれか特定したか □ 各摩擦に対する処方を設計したか □ 処方が機能として実装されているか □ 処方の効果を測定する手段があるか ``` --- ## § 5. Layer 2: Integration（統合設計） ### 定義 ``` プロダクトを組織の既存システム・文化に不可分に埋め込む設計 ``` ### 4つの統合次元 ``` ┌─────────────────────────────────────────────────────┐ │ ① Process統合（業務フローへの統合） │ │ │ │ 目標： │ │ 「使う」ではなく「業務の一部」にする │ │ │ │ 設計要素： │ │ ・既存業務フローのどこに入るか │ │ ・前後のプロセスとの接続点 │ │ ・例外処理の設計（使わない場合どうするか） │ │ │ │ 成功指標： │ │ 「これなしで業務が回らない」状態 │ └─────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────┐ │ ② System統合（既存ITへの統合） │ │ │ │ 目標： │ │ 「別のツール」ではなく「システムの一部」にする │ │ │ │ 設計要素： │ │ ・API/連携の設計 │ │ ・データフローの設計 │ │ ・認証・権限の統合（SSO等） │ │ │ │ 成功指標： │ │ 「シームレスに繋がっている」状態 │ └─────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────┐ │ ③ Culture統合（組織文化への統合） │ │ │ │ 目標： │ │ 「導入されたツール」ではなく「うちのやり方」に │ │ │ │ 設計要素： │ │ ・組織の価値観との整合 │ │ ・既存の習慣・儀式への接続 │ │ ・チャンピオン（推進者）の設計 │ │ │ │ 成功指標： │ │ 「新人に当然のように教えられる」状態 │ └─────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────┐ │ ④ Governance統合（責任・権限への統合） │ │ │ │ 目標： │ │ 「誰かが管理」ではなく「制度の一部」にする │ │ │ │ 設計要素： │ │ ・責任者の明確化 │ │ ・権限設計（誰が何をできるか） │ │ ・監査・コンプライアンス対応 │ │ ・障害時の責任分界 │ │ │ │ 成功指標： │ │ 「組織図・規程に組み込まれている」状態 │ └─────────────────────────────────────────────────────┘ ``` ### Layer 2 チェックリスト ``` □ 4つの統合次元すべてを設計したか □ 最も弱い統合次元はどれか特定したか □ 統合を阻む要因を洗い出したか □ 統合を促進する施策を設計したか □ 統合度を測定する手段があるか ``` --- ## § 6. Layer 3: Value Loop（価値循環） ### 定義 ``` 使うほど価値が増え、使い続ける理由が強化される循環構造 ``` ### 3つの価値ループ ``` ┌─────────────────────────────────────────────────────┐ │ ① Data Loop（データループ） │ │ │ │ 構造： │ │ 使う → データが溜まる → 価値が増える → もっと使う│ │ │ │ 設計要素： │ │ ・使用データの蓄積設計 │ │ ・蓄積データからの価値創出（分析、提案等） │ │ ・データの可視化（ユーザーに価値を実感させる） │ │ │ │ 例： │ │ ・履歴から学習するレコメンド │ │ ・使用パターンからの最適化提案 │ │ ・組織全体の傾向分析 │ └─────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────┐ │ ② Learning Loop（学習ループ） │ │ │ │ 構造： │ │ 使う → 上手くなる → 成果が出る → もっと使う │ │ │ │ 設計要素： │ │ ・習熟度の可視化 │ │ ・段階的な機能開放 │ │ ・成功体験の設計（小さな勝利） │ │ │ │ 例： │ │ ・スキルバッジ、レベルアップ │ │ ・「先週より20%速くなりました」 │ │ ・ベストプラクティスの自動提案 │ └─────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────┐ │ ③ Network Loop（ネットワークループ） │ │ │ │ 構造： │ │ 使う人が増える → 価値が増える → もっと人が増える │ │ │ │ 設計要素： │ │ ・コラボレーション機能 │ │ ・共有・招待の設計 │ │ ・組織内での可視性 │ │ │ │ 例： │ │ ・チームで使うと価値が倍増 │ │ ・共有テンプレート、ナレッジベース │ │ ・「○○さんも使っています」 │ └─────────────────────────────────────────────────────┘ ``` ### Layer 3 チェックリスト ``` □ 3つのループのうち、どれを主軸にするか決めたか □ ループが回る仕組みを設計したか □ ユーザーがループを実感できる設計になっているか □ ループの回転速度を測定する手段があるか □ ループが止まる条件を特定し、対策を設計したか ``` --- ## § 7. 3層の統合：採用設計キャンバス ``` ┌──────────────────────────────────────────────────────────────┐ │ Adoption Architecture Canvas │ ├──────────────────────────────────────────────────────────────┤ │ │ │ 【Layer 3: Value Loop】 │ │ ┌─────────────┬─────────────┬─────────────┐ │ │ │ Data Loop │Learning Loop│Network Loop │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └─────────────┴─────────────┴─────────────┘ │ │ ↑ │ │ 【Layer 2: Integration】 │ │ ┌──────────┬──────────┬──────────┬──────────┐ │ │ │ Process │ System │ Culture │Governance│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └──────────┴──────────┴──────────┴──────────┘ │ │ ↑ │ │ 【Layer 1: Friction Removal】 │ │ ┌────────┬────────┬────────┬────────┬────────┐ │ │ │認知 │政治 │運用 │経済 │技術 │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └────────┴────────┴────────┴────────┴────────┘ │ │ │ └──────────────────────────────────────────────────────────────┘ ``` --- ## § 8. 実践ガイド ### 8.1 診断：現状の採用設計を評価する ``` 【Layer 1 診断】 Q1: 5つの摩擦のうち、最大のものは何か？ Q2: その摩擦に対する処方は機能しているか？ Q3: 採用率・離脱率のデータはあるか？ 【Layer 2 診断】 Q4: 4つの統合のうち、最も弱いのはどれか？ Q5: 「なくてはならない」と言われているか？ Q6: 担当者が変わっても継続しているか？ 【Layer 3 診断】 Q7: どのループが回っているか？ Q8: 使用量は増加傾向か？ Q9: ユーザーから「もっと使いたい」と言われるか？ ``` ### 8.2 設計：新規プロダクトの採用設計 ``` 【Step 1】摩擦マップの作成（Layer 1） ・想定ユーザーごとに5つの摩擦を洗い出す ・優先順位をつける ・処方を設計する 【Step 2】統合計画の作成（Layer 2） ・4つの統合次元ごとに現状と目標を定義 ・統合を阻む要因を特定 ・統合を促進する施策を設計 【Step 3】ループ設計（Layer 3） ・主軸となるループを選択 ・ループが回る仕組みを設計 ・ループの測定方法を定義 【Step 4】キャンバスの完成 ・3層を統合してキャンバスに記入 ・弱点・盲点を特定 ・優先施策を決定 ``` ### 8.3 改善：既存プロダクトの採用設計改善 ``` 【Step 1】診断 ・Layer 1-3の診断を実施 ・最も弱い層を特定 【Step 2】ボトルネック特定 ・弱い層の中で、最大の問題を特定 ・根本原因を分析 【Step 3】処方設計 ・ボトルネックに対する処方を設計 ・実装計画を立てる 【Step 4】効果測定 ・処方の効果を測定 ・次のボトルネックへ移行 ``` --- ## § 9. 適用例：IDE/開発者ツール ### 9.1 開発者ツール特有の摩擦 ``` 【Layer 1：開発者ツールの5つの摩擦】 ① 認知摩擦（特に強い） ・開発者は新しいツールに懐疑的 ・「既存のやり方で十分」という抵抗 ・学習コストへの敏感さ 処方： ・5分で価値を体感させるデモ ・既存ワークフローへの最小侵襲 ・漸進的な機能開放 ② 政治摩擦 ・セキュリティチームの懸念（コードが外部に出る？） ・ライセンス・コンプライアンス ・「全員が同じツールを使うべき」vs「個人の自由」 処方： ・オンプレミス/プライベートクラウド対応 ・SOC2、ISO27001等の認証 ・チーム導入と個人導入の両パス ③ 運用摩擦 ・既存のIDE/エディタとの共存 ・設定の引き継ぎ・同期 ・チーム間での設定統一 処方： ・既存ツールへのプラグイン提供 ・設定のエクスポート/インポート ・チーム設定の一元管理 ④ 経済摩擦 ・「無料ツールで十分」という意識 ・ROIの説明が難しい（生産性は測りにくい） ・個人 vs チーム vs 全社の価格設計 処方： ・無料tier（個人利用） ・時間削減の定量化ダッシュボード ・段階的な価格設計 ⑤ 技術摩擦 ・言語・フレームワークのカバレッジ ・既存CI/CDとの統合 ・社内独自ツールとの連携 処方： ・主要言語・フレームワークの網羅 ・CI/CDプラグイン ・API/拡張性の提供 ``` ### 9.2 開発者ツールの統合設計 ``` 【Layer 2：開発者ツールの4つの統合】 ① Process統合 ・コーディング → レビュー → デプロイのどこに入るか ・ペアプログラミング/モブプログラミングとの関係 ・ドキュメント作成との統合 ② System統合 ・Git/GitHub/GitLabとの統合 ・CI/CD（Jenkins, GitHub Actions等）との統合 ・Slack/Teams等のコミュニケーションツール連携 ③ Culture統合 ・「AIに頼るのはズルい」という意識への対応 ・シニア開発者の抵抗への対応 ・チーム内でのベストプラクティス共有 ④ Governance統合 ・コード品質基準への組み込み ・セキュリティレビュープロセスへの組み込み ・オンボーディングプロセスへの組み込み ``` ### 9.3 開発者ツールの価値ループ ``` 【Layer 3：開発者ツールの3つのループ】 ① Data Loop ・使用履歴からの学習（個人の好み、プロジェクトの文脈） ・チームのコードパターンの学習 ・「使うほど賢くなる」体験 ② Learning Loop ・開発者自身のスキル向上可視化 ・「今週、AIと協働で○○行のコードを書きました」 ・新しい言語・フレームワークの学習支援 ③ Network Loop（最重要） ・チームで共有するとコンテキストが蓄積 ・チーム内でのベストプラクティス自動共有 ・「チームメンバーが使っているから使う」効果 ``` ### 9.4 IDE向けAAFキャンバス例 ``` ┌──────────────────────────────────────────────────────────────┐ │ IDE Adoption Architecture Canvas │ ├──────────────────────────────────────────────────────────────┤ │ │ │ 【Layer 3: Value Loop】 │ │ ┌─────────────┬─────────────┬─────────────┐ │ │ │ Data Loop │Learning Loop│Network Loop │ │ │ │使うほど賢く │スキル向上 │チームで使う │ │ │ │なる │の可視化 │ほど価値増大 │ │ │ └─────────────┴─────────────┴─────────────┘ │ │ ↑ │ │ 【Layer 2: Integration】 │ │ ┌──────────┬──────────┬──────────┬──────────┐ │ │ │ Process │ System │ Culture │Governance│ │ │ │開発→ │Git/CI/CD │AI協働の │品質基準 │ │ │ │レビュー │統合 │正当化 │への組込 │ │ │ └──────────┴──────────┴──────────┴──────────┘ │ │ ↑ │ │ 【Layer 1: Friction Removal】 │ │ ┌────────┬────────┬────────┬────────┬────────┐ │ │ │認知 │政治 │運用 │経済 │技術 │ │ │ │5分で │ｾｷｭﾘﾃｨ │既存 │無料tier│言語 │ │ │ │価値体感│認証 │ﾌﾛｰ維持 │+ROI可視│ｶﾊﾞﾚｼﾞ │ │ │ └────────┴────────┴────────┴────────┴────────┘ │ │ │ └──────────────────────────────────────────────────────────────┘ ``` --- ## § 10. フレームワークの限界と発展 ### 限界 ``` 【AAFが適用できる領域】 ・B2B SaaS、エンタープライズツール ・社内ツールの導入 ・開発者向けツール ・組織変革を伴うサービス 【AAFが適用しにくい領域】 ・B2Cのコンシューマー向けアプリ（組織統合が不要） ・単発利用のツール（持続的定着が目標でない） ・完全に個人向けのサービス ``` ### 発展の方向 ``` ① 深化 ・各Layer/次元の詳細方法論 ・業界別の適用ガイド ・測定指標（KPI）の体系化 ② 拡張 ・B2Cへの適用変形 ・オープンソースプロジェクトへの適用 ・社内変革プロジェクトへの適用 ③ ツール化 ・診断ツール ・キャンバステンプレート ・チェックリスト集 ``` --- ## § 11. 関連フレームワーク ``` 【AAFの位置づけ】 ITF v2.1（思考の体系） └ 「どう問うか」を規定 USM（体系化の方法） └ 「どう構造化するか」を規定 CEM（協働の方法） └ 「どう共に考えるか」を規定 AAF（採用設計の方法）← NEW └ 「どう使われ続ける状態を作るか」を規定 【ITFとの対応】 AAF Layer 1 → Q4 Validation（摩擦の検証） AAF Layer 2 → Q6 Integration（組織への統合） AAF Layer 3 → Q6 Integration（価値ループ＝持続的仕組み） 【3Drivenとの対応】 VisionDriven → Layer 3（価値ループで実現する未来） IssueDriven → Layer 1（ユーザーの摩擦・痛み） TechnologyDriven → Layer 2（統合の技術的実装） ``` --- ## 付録A：用語集 | 用語 | 定義 | | :-------------------- | :------------------------------------------------- | | Adoption Architecture | 技術的価値を持続的な組織価値へ変換する設計体系 | | Friction | 採用を阻む障壁・抵抗 | | Integration | プロダクトを組織の既存システム・文化に埋め込むこと | | Value Loop | 使うほど価値が増える循環構造 | | インフラ化 | 組織にとって不可欠な存在になること | | Data Loop | 使用データの蓄積により価値が増すループ | | Learning Loop | 習熟により成果が上がるループ | | Network Loop | 利用者増加により価値が上がるループ | --- ## 付録B：クイックリファレンス ``` 【3層構造】 Layer 3: Value Loop（価値循環）→ 持続的定着のエンジン Layer 2: Integration（統合設計）→ 社会的統合度を高める Layer 1: Friction Removal（摩擦除去）→ 採用の入口を開く 【Layer 1：5つの摩擦】 ① 認知摩擦：わからない、難しい ② 政治摩擦：責任、権限、セキュリティ ③ 運用摩擦：面倒、続かない ④ 経済摩擦：高い、ROI不明 ⑤ 技術摩擦：繋がらない、動かない 【Layer 2：4つの統合】 ① Process：業務フローへの統合 ② System：既存ITへの統合 ③ Culture：組織文化への統合 ④ Governance：責任・権限への統合 【Layer 3：3つのループ】 ① Data Loop：使うほどデータが溜まる ② Learning Loop：使うほど上手くなる ③ Network Loop：使う人が増えるほど価値が上がる ``` --- ## 付録C：参考文献・思想的背景 ``` 本フレームワークは以下から着想を得ている： Geoffrey Moore - Crossing the Chasm（キャズム理論） - 技術採用ライフサイクル Clayton Christensen - Jobs to be Done - 顧客が「雇う」仕事 Everett Rogers - Diffusion of Innovations（イノベーション普及理論） Andrew Chen - The Cold Start Problem - ネットワーク効果の設計 Nir Eyal - Hooked（フック・モデル） - 習慣形成の設計 原典テキスト - 「合意の設計」に関するTwitter/X投稿 - IT人材向けの実践的洞察 ``` --- **Document Information** ```yaml Title: Adoption Architecture Framework (AAF) Subtitle: 技術的価値を持続的な組織価値へ変換する設計体系 Version: 1.0 Created: 2025-12-25 Status: Active & Evolving 構成: §0: Executive Summary §1-2: 根本軸と4象限 §3: 3層構造の概要 §4-6: 各Layerの詳細 §7: 統合キャンバス §8: 実践ガイド §9: IDE適用例 §10: 限界と発展 §11: 関連フレームワーク 付録: 用語集、クイックリファレンス、参考文献 関連文書: - ITF_v2_1.md - USM_v1.md - CEM_v1.md - Framework_Integration_Map.md ``` --- _技術的価値を社会的価値に変換し_ _組織に不可分に統合させ_ _持続的な価値ループを生み出す_ _これがAdoption Architecture Frameworkである_ 🔧