ドキュメント

TIDE_v2.md

# TIDE Framework v2.0 **Technical Investment Decision Engine** 技術投資意思決定エンジン --- ## 0. What's New in v2.0 | 進化点 | v1.0 | v2.0 | | ---------------- | ------------------------------- | -------------------------------------------------------------- | | **構造** | 4層（CTOS） | 4層（TIDE一致） | | **トリガー分類** | Surface/Structural/Foundational | **3S Model**: Signal/Structure/Substance | | **設計原則** | 3原則 | **4原則**（技術的謙虚さ追加） | | **研究データ** | なし | 定量的根拠を統合 | | **失敗構造** | なし | **5つの失敗パターン**を類型化 | | **事例** | なし | 成功・失敗事例を収録 | | **スコアカード** | 100点 | 100点（AI時代の評価軸を強化） | | **運用モード** | ガイドラインのみ | **SIA統合**: 成果物テンプレート固定 + エスカレーション・ゲート | --- ## 1. 概要 ### 1.1 目的 TIDEは、システムリライト・技術刷新の意思決定における**構造的な判断歪み**を防ぎ、質の高い意思決定を組織的に実現するためのエンジンである。 ### 1.2 解決する問題 | 問題 | 症状 | TIDEの対応 | | -------------------- | -------------------------------------- | -------------------------------- | | **表層と本質の混同** | 「採用できない」を理由にリライトを決定 | **Insight**でトリガーを3Sに分類 | | **選択肢の狭窄** | Big Bangか現状維持の二択 | **Design**で5選択肢を強制検討 | | **政治的歪み** | 反対意見が封殺される | **Evaluate**で判断保護メカニズム | | **時代錯誤** | AI時代にAI以前の判断基準を適用 | **全層**にAI時代の再評価を統合 | ### 1.3 設計思想 **潮流（TIDE）の比喩**: - 技術変化は潮のように押し寄せる - 波に乗るか、待つか、逆らうかは**文脈次第** - 正解は一つではない。**判断の質**を高めることが目的 **4つの原則**: | # | 原則 | 内容 | | --- | ---------------- | -------------------------------------------------------------- | | 1 | **強制的多様性** | 選択肢を意図的に拡張する | | 2 | **構造的検証** | 判断プロセス自体に検証を埋め込む | | 3 | **政治的保護** | 反対意見が表出する構造を作る | | 4 | **技術的謙虚さ** | 技術選定は仮説であり確定ではない。AI進化により前提は変わりうる | ### 1.4 想定ユーザー - CTO / 技術責任者 - 技術委員会 / アーキテクチャレビューボード - 経営層（技術投資判断時） - コンサルタント / アドバイザー - VC / PE（技術デューデリジェンス時） ### 1.5 使い方 | あなたの状況 | 運用モード | 所要時間 | | -------------------- | ------------------ | --------- | | 小規模変更、緊急 | 簡易モード（§6.1） | 30分 | | 中規模以上、通常判断 | 標準モード（§6.2） | 半日〜1日 | | 大規模、不可逆的判断 | 詳細モード（§6.3） | 1週間〜 | --- ## 2. TIDE 4層構造 v2.0では、フレームワーク名 **TIDE** の4文字が4層と完全一致する。 ``` ┌─────────────────────────────────────────────────────────┐ │ T Terrain（地形を読む） │ │ 「今、私たちはどこにいるのか？」 │ │ 組織フェーズ・競争環境・負債速度・チーム状態・リソース │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ I Insight（本質を見抜く） │ │ 「なぜリライトしたいのか？本当の理由は？」 │ │ 3S分析: Signal → Structure → Substance │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ D Design（選択肢を設計する） │ │ 「他にどんな選択肢があるか？」 │ │ 5選択肢の強制検討・評価マトリクス │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ E Evaluate（判断を守る） │ │ 「この判断は歪んでいないか？」 │ │ 撤退基準・外部検証・スコアカード・再評価サイクル │ └─────────────────────────────────────────────────────────┘ ``` --- ## T: Terrain（地形を読む） **目的**: 判断の前提条件を明確にする。同じトリガーでも、文脈によって最適解は異なる。 ### T.1 組織フェーズ | フェーズ | 特徴 | 技術判断への影響 | | ------------------ | -------------------------- | -------------------------------------------- | | **スタートアップ** | 速度最優先、リソース制約大 | 「動くもの優先」が合理的。技術負債は後回し可 | | **成長期** | スケール課題、採用拡大 | 技術負債の影響が顕在化。段階的対応が現実的 | | **成熟期** | 安定運用、効率化 | リライトの機会費用が大きい。慎重判断が必要 | | **転換期** | ピボット、M&A、事業再編 | ビジネスモデル変化に伴う技術変革は合理的 | **問い**: 私たちは今、どのフェーズにいるか？ ### T.2 競争環境 | 状況 | 判断への影響 | | ------------------ | ------------------------------------------------ | | **時間圧力が高い** | 「待つコスト」が大きい。速度重視の判断が合理的 | | **時間圧力が低い** | 「待つ価値」が高い。AI進化を織り込んだ判断が可能 | **問い**: 競合に先行されるリスクはどの程度か？ ### T.3 技術負債の増大速度 | パターン | 特徴 | 対応 | | ------------------ | -------------------------- | ---------------- | | **線形増大** | 毎月一定のメンテコスト増加 | 計画的対応が可能 | | **指数関数的増大** | 加速度的にコスト増加 | 早期対応が合理的 | | **安定** | 負債はあるが増大していない | 急ぐ理由は薄い | **問い**: 技術負債は今後どう増大するか？ ### T.4 チーム状態 | 指標 | 警戒サイン | | ---------- | ------------------------------------------ | | **離職率** | レガシー担当からの離職が増加 | | **士気** | 「このコードでは成長できない」という声 | | **採用** | 「この技術スタックでは人が来ない」という声 | **注意**: 採用・士気は「トリガー」ではなく「文脈」として扱う。AI時代には「この技術でないと人が来ない」は弱い論拠になりつつある。 ### T.5 リソース可用性 | リソース | 確認事項 | | -------- | ------------------------------------------ | | **人員** | リライトに専念できるチームを確保できるか？ | | **予算** | 失敗した場合のバッファはあるか？ | | **時間** | 他のプロジェクトを止めずに実行できるか？ | --- ## I: Insight（本質を見抜く） **目的**: 「なぜリライトしたいのか」の本当の理由を特定する。表層的な理由を本質的な理由と誤認することを防ぐ。 ### I.1 3Sトリガーモデル v2.0では、3層トリガーを**3S**（Signal / Structure / Substance）として再定義する。 ``` ┌─────────────────────────────────────────────────────────┐ │ Signal（信号） │ │ ─────────────────────────────────────────────────────── │ │ 「見える」症状。AI時代に解決策が根本的に変わった領域。 │ │ │ │ ・コードが読めない / 理解できない │ │ ・ドキュメントがない │ │ ・テストがない │ │ ・この言語/フレームワークでは採用できない │ │ │ │ → AI支援で解決可能性が高い。リライトの根拠としては弱い。 │ │ → これだけでBig Bangを選択してはならない。 │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ Structure（構造） │ │ ─────────────────────────────────────────────────────── │ │ アーキテクチャレベルの問題。段階的対応の可能性を検討。 │ │ │ │ ・アーキテクチャが機能追加を阻害している │ │ ・性能限界に達している │ │ ・スケーラビリティの壁がある │ │ ・セキュリティ要件を満たせない │ │ │ │ → Strangler Fig等の段階的対応で解決可能か検討必須。 │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ Substance（本質） │ │ ─────────────────────────────────────────────────────── │ │ ビジネス/ドメインレベルの根本変化。 │ │ リライトが合理的根拠を持ちうる唯一の層。 │ │ │ │ ・ビジネスモデルが根本的に変化した │ │ ・ドメインモデル自体が陳腐化した │ │ ・規制要件が根本的に変化した │ │ ・M&A / 事業統合で技術統一が必要 │ │ │ │ → 段階的対応では解決困難。Big Bangの合理的根拠たりうる。 │ └─────────────────────────────────────────────────────────┘ ``` ### I.2 判定フロー ``` Q: なぜリライトしたいのか？ │ ▼ ┌───────────────────┐ │ 理由を列挙する │ └───────┬───────────┘ │ ▼ ┌───────────────────────────────────────────┐ │ 各理由を3Sに分類する │ │ │ │ □ コードが読めない → Signal │ │ □ 採用できない → Signal │ │ □ アーキテクチャ限界 → Structure │ │ □ ビジネスモデル変化 → Substance │ └───────────────────────────────────────────┘ │ ▼ ┌───────────────────────────────────────────┐ │ Substanceトリガーはあるか？ │ │ │ │ YES → リライトの合理的根拠あり → Dへ │ │ NO → Signal/Structureのみ │ │ → 代替手段を優先検討 → Dへ │ └───────────────────────────────────────────┘ ``` ### I.3 AI時代のSignal再評価 | 従来の理由 | AI時代の再評価 | 根拠 | | ------------------------ | -------------------------------- | --------------------------------------------------------------------- | | コードが読めない | AI支援で解読可能 | 大規模コードベースの依存関係マッピングが数時間で可能に | | ドキュメントがない | AI支援で生成可能 | 既存コードからの自動ドキュメント化が実用段階 | | テストがない | AI支援で生成可能 | AIによるテスト生成で特性テスト（characterization test）の自動化が進行 | | この言語では採用できない | AI時代に言語依存の採用優位は減少 | Coding Agentがどの言語でも補助できるため | **重要**: Signal層のみでリライトを決定することは、AI時代には合理性が低下している。 ### I.4 失敗の5構造（認識すべきパターン）リライトが失敗する構造的パターンを事前に認識し、回避する。 | # | 名称 | 現象 | 対策 | | --- | ------------------------- | ---------------------------------------------------------- | ------------------------------------------------------ | | 1 | **Second System Effect** | 制約から解放され、過剰設計に走る。「今度こそ完璧に」の心理 | 現システムの「成功している部分」を明示的に保存する設計 | | 2 | **Moving Target** | リライト中もビジネスは動き、要件が変化し続ける | 機能凍結期間の設定、またはStrangler Figの採用 | | 3 | **Knowledge Evaporation** | 「なぜそう実装されたか」の暗黙知が蒸発する | リライト前にAI支援で知識を言語化・文書化 | | 4 | **Integration Collapse** | 個別モジュールは動くが、最終統合時に全てが同時に壊れる | 段階的移行、カナリアリリース、ロールバック設計 | | 5 | **Political Capture** | 技術選定が派閥争いや個人の趣味の道具になる | 外部CTOレビュー、判断根拠の文書化 | ### I.5 「隠れた動機」チェック表層的なトリガーの裏に、以下の**言語化されにくい動機**が隠れていないか？ - 新CTO / 技術責任者の「自分の色を出したい」欲求 - エンジニアの退屈 / チャレンジ欲求 - 「レガシー」というレッテルの政治的利用 - 投資家 / 株主への「イノベーション」アピール - 競合への焦り（Shiny Object Syndrome） **診断法**: 「もしこのリライトが失敗した場合、誰が最も困るか？」を問う。困る人がいなければ、動機は本質的ではない可能性がある。 --- ## D: Design（選択肢を設計する） **目的**: Big Bangか現状維持の二択に陥ることを防ぐ。強制的に5つの選択肢を検討する。 ### D.1 5つの選択肢（全て検討必須） ``` 低リスク ←─────────────────────────────────→ 高リスク低コスト高コスト ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ │ │ │ │ │ │ │ │ │ │ ① │ │ ② │ │ ③ │ │ ④ │ │ ⑤ │ │ 静観 │ │ AI │ │ 漸進 │ │ 部分 │ │ 全面 │ │ │ │ 治療 │ │ 移行 │ │ 刷新 │ │ 刷新 │ │ │ │ │ │ │ │ │ │ │ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ Observe Augment Migrate Isolate Replace ``` | # | 選択肢 | 概要 | 適用条件 | | --- | ----------------------- | ----------------------------------------------------------------------- | --------------------------------------- | | ① | **Observe（静観）** | 現状維持。「何もしないコスト」を定量化して判断 | Substanceトリガーなし、負債安定 | | ② | **Augment（AI治療）** | AI支援でコード理解・テスト生成・ドキュメント化。延命ではなく治療 | Signalトリガーのみ、時間的余裕あり | | ③ | **Migrate（漸進移行）** | Strangler Figパターン。新機能は新システムで構築し、旧を段階的に絞め出す | Structureトリガー、リスク分散が必要 | | ④ | **Isolate（部分刷新）** | ボトルネック箇所のみ切り出して刷新。他は維持 | 問題が特定領域に集中 | | ⑤ | **Replace（全面刷新）** | Big Bang Rewrite。全てを作り直す | Substanceトリガー明確、リソース確保済み | ### D.2 各選択肢の詳細 #### ① Observe（静観） **「何もしない」は消極的選択ではなく、意図的な判断である。** 以下を定量化して「何もしないコスト」を明示する： - **現状維持コスト**: 今後12ヶ月のメンテナンスコスト予測 - **機会損失**: 新機能開発の遅延による逸失利益 - **リスク増大**: 技術負債の増大による将来コスト - **チームへの影響**: 離職リスク、士気低下の影響 #### ② Augment（AI治療） **AI時代に新たに出現した選択肢。** Signal層の問題はAI支援で治療可能。具体的アプローチ： 1. AI支援で依存関係マップを生成（数時間） 2. AI支援でテストを追加（数日〜数週間） 3. AI支援でドキュメントを生成（数日） 4. AI支援で段階的リファクタリングを実行（継続的） #### ③ Migrate（漸進移行） **Strangler Figパターンによる段階的置換。** ``` 旧システム ┌─────────────────┐ │ 機能A │ 機能B │ 機能C │ └───┬───┴───┬───┴───┬───┘ │ │ │ ┌───▼───┬───▼───┬───▼───┐ │ Proxy │ Proxy │ Proxy │ ← ルーティング層 └───┬───┴───┬───┴───┬───┘ │ │ │ ┌───▼───┐ │ │ │ 新A │ │ │ ← 徐々に置換 └───────┘ │ │ ┌───▼───┐ │ │ 新B │ │ └───────┘ │ ┌───▼───┐ │ 新C │ └───────┘ ``` **研究データ**: モノリス内で正式なインターフェース契約を確立した組織の73%が移行に成功。無制限のモジュール間アクセスを許可した場合は34%。Strangler Figを実装した組織は、Big Bangを試みた組織と比較して移行中の本番インシデントが67%少なかった。 #### ④ Isolate（部分刷新） **問題が集中する特定モジュールのみを切り出して刷新する。** 適用条件： - ボトルネックが特定領域に集中している - 他モジュールとの結合が疎（または疎にできる） - 6-18ヶ月で対象モジュールが刷新可能 #### ⑤ Replace（全面刷新） **全てを作り直す。最終手段。** 全面刷新が正当化される条件（**全てを満たす必要がある**）： - [ ] ドメインモデル自体が根本的に変化した（Substanceトリガー確認済み） - [ ] 漸進的アプローチを検討し、不可能と結論した（③④を検討済み） - [ ] ビジネスが2-3年の移行期間を許容できる - [ ] リソース（人員・予算・時間）が確保されている - [ ] 外部専門家（CTO経験者）のレビューを受けた - [ ] 撤退基準が事前に設定されている **警告**: リライトを推奨する声の多くは、リライト対象の詳細を知らない人から来る。3万フィートの視点から「簡単だ」と主張するのは容易だ。システムを書いた人で、すべてのユースケースやエッジケースをサポートするのにどれだけの時間がかかったかを知っていれば、それが簡単ではないことがわかる。 ### D.3 評価マトリクス | 選択肢 | 時間 | コスト | リスク | 可逆性 | 総合 | | --------- | ---- | ------ | ------ | ------ | ---- | | ① Observe | | | | | | | ② Augment | | | | | | | ③ Migrate | | | | | | | ④ Isolate | | | | | | | ⑤ Replace | | | | | | 評価: ◎=優 ○=良 △=可 ×=不可 ### D.4 選択の原則 **原則1**: ①から順に検討する（左から右へ） - まずObserve/Augmentで対応可能か検討 - 不可能な場合のみ、右へ移動 **原則2**: ⑤は「他に選択肢がない」場合のみ - Substanceトリガーが確認された場合 - ①〜④が技術的に不可能な場合 **原則3**: 選択の根拠を明文化する - 「なぜ②ではなく③か」を説明できなければ、判断が曖昧 --- ## E: Evaluate（判断を守る） **目的**: 判断プロセス自体の歪みを防ぐ。政治的圧力、認知バイアス、自己欺瞞から判断を保護する。 ### E.1 事前設定（判断確定前に決める） | 項目 | 内容 | タイミング | | ------------------ | --------------------------------- | -------------- | | **撤退基準** | 何が起きたら中止 / 方針変更するか | 判断確定**前** | | **外部検証者** | 誰が客観評価するか | 判断確定**前** | | **再評価サイクル** | いつ判断を見直すか | 判断確定**前** | **重要**: これらは判断**後**ではなく**前**に設定する。判断後に設定すると「都合の良い基準」になる。 ### E.2 撤退基準テンプレート ``` 1. 時間基準 - [ ] マイルストーンXが日付Yまでに未達成 → 再評価 - [ ] 進捗率がZ%を下回った → 方針変更を検討 2. コスト基準 - [ ] 予算超過がX%を超えた → 再評価 - [ ] 追加予算申請がY回を超えた → 中止検討 3. 品質基準 - [ ] 重大バグがX件を超えた → 方針変更 - [ ] 性能目標未達がY項目以上 → 再評価 4. チーム基準 - [ ] キーパーソン離脱時 → 即座に再評価 - [ ] チーム士気低下の兆候 → 方針検討 ``` ### E.3 外部検証プロトコル **外部検証者の要件**: - 意思決定に利害関係がない - 技術的な判断能力がある（CTO経験者推奨） - 率直なフィードバックができる **投資**: 全体予算の5-10%を外部検証に充てる。この投資を惜しむことは、残り90%の成否を賭けに変える。 **検証者への提供資料**: 1. T-I-Dの分析結果 2. スコアカード結果 3. 提案する選択肢と根拠 **検証者への問い**: 1. この分析で見落としている点は？ 2. この選択肢以外にありうるものは？ 3. この判断の最大リスクは何か？ ### E.4 政治的保護メカニズム | メカニズム | 目的 | 実施方法 | | -------------------- | ------------------------ | ---------------------------------- | | **匿名意見収集** | 反対意見の表出を促進 | 無記名アンケート、匿名フォーム | | **48時間ルール** | 即断による判断歪みを防止 | 最終判断から48時間のクーリングオフ | | **意思決定ログ** | 事後検証を可能に | 判断根拠、反対意見、採用理由を記録 | | **Devil's Advocate** | 意図的に反対意見を生成 | 特定メンバーに反対役を割り当て | ### E.5 再評価サイクル | 頻度 | 内容 | 参加者 | | ---------- | ---------------------------------------------------- | ----------------- | | **月次** | 進捗確認、撤退基準との照合 | 開発チーム | | **四半期** | 選択肢の再評価、AI進化状況の確認、競争環境の変化確認 | PM + ビジネス | | **半期** | 判断全体の妥当性再検証、前提条件の変化確認 | 経営 + 外部検証者 | --- ## 3. 診断スコアカード ### 3.1 スコアカード本体 ``` ┌────────────────────────────────────────────────────────┐ │ TIDE Diagnostic Scorecard v2.0 │ │ 技術投資意思決定診断スコアカード │ ├────────────────────────────────────────────────────────┤ │ │ │ 診断日: ____年__月__日 │ │ 対象システム: _______________________ │ │ 診断者: _______________________ │ │ │ ├────────────────────────────────────────────────────────┤ │ │ │ ■ Section T: Terrain Score（地形） /25点 │ │ ────────────────────────────────────────────── │ │ │ │ T1. 組織フェーズを特定したか？ │ │ □ 未特定(0) □ 曖昧(2) □ 明確(5) ___/5 │ │ │ │ T2. 競争環境・時間圧力を評価したか？ │ │ □ 未評価(0) □ 定性的(2) □ 定量的(5) ___/5 │ │ │ │ T3. 技術負債の増大パターンを分析したか？ │ │ □ 未分析(0) □ 感覚的(2) □ データあり(5) ___/5 │ │ │ │ T4. チーム状態を把握したか？ │ │ □ 未把握(0) □ 一部(2) □ 網羅的(5) ___/5 │ │ │ │ T5. リソース可用性を確認したか？ │ │ □ 未確認(0) □ 概算(2) □ 詳細(5) ___/5 │ │ │ │ Section T 合計: ___/25 │ │ │ ├────────────────────────────────────────────────────────┤ │ │ │ ■ Section I: Insight Score（本質） /25点 │ │ ────────────────────────────────────────────── │ │ │ │ I1. トリガーを3S（Signal/Structure/Substance）に │ │ 分類したか？ │ │ □ 未分類(0) □ 一部(3) □ 全て(7) ___/7 │ │ │ │ I2. Signal層のAI代替可能性を検討したか？ │ │ □ 未検討(0) □ 一部(3) □ 全て(6) ___/6 │ │ │ │ I3. Substanceトリガーの有無を判定したか？ │ │ □ 未判定(0) □ 曖昧(4) □ 明確(7) ___/7 │ │ │ │ I4. 失敗の5構造を認識し、対策を検討したか？ │ │ □ 未認識(0) □ 一部(2) □ 全て(5) ___/5 │ │ │ │ Section I 合計: ___/25 │ │ │ ├────────────────────────────────────────────────────────┤ │ │ │ ■ Section D: Design Score（設計） /25点 │ │ ────────────────────────────────────────────── │ │ │ │ D1. 5つの選択肢を全て検討したか？ │ │ □ 2つ以下(0) □ 3-4つ(4) □ 5つ全て(8) ___/8 │ │ │ │ D2. 「Observe」のコストを定量化したか？ │ │ □ 未定量化(0) □ 概算(3) □ 詳細(6) ___/6 │ │ │ │ D3. 各選択肢を4軸（時間/コスト/リスク/可逆性）で │ │ 評価したか？ │ │ □ 未評価(0) □ 一部(3) □ 全て(6) ___/6 │ │ │ │ D4. 選択肢間の比較を可視化したか？ │ │ □ 未可視化(0) □ 表のみ(2) □ 詳細(5) ___/5 │ │ │ │ Section D 合計: ___/25 │ │ │ ├────────────────────────────────────────────────────────┤ │ │ │ ■ Section E: Evaluate Score（評価） /25点 │ │ ────────────────────────────────────────────── │ │ │ │ E1. 撤退基準を事前に設定したか？ │ │ □ 未設定(0) □ 曖昧(3) □ 具体的(7) ___/7 │ │ │ │ E2. 外部検証者を設定したか？ │ │ □ 未設定(0) □ 内部のみ(3) □ 外部あり(7) ___/7 │ │ │ │ E3. 反対意見を収集したか？ │ │ □ 未収集(0) □ 形式的(2) □ 実質的(6) ___/6 │ │ │ │ E4. 再評価サイクルを設定したか？ │ │ □ 未設定(0) □ 曖昧(2) □ 具体的(5) ___/5 │ │ │ │ Section E 合計: ___/25 │ │ │ ├────────────────────────────────────────────────────────┤ │ │ │ ■ 総合 │ │ │ │ Section T（Terrain）: ___/25 │ │ Section I（Insight）: ___/25 │ │ Section D（Design）: ___/25 │ │ Section E（Evaluate）: ___/25 │ │ ───────────────────────────────── │ │ 総合スコア: ___/100 │ │ │ ├────────────────────────────────────────────────────────┤ │ │ │ ■ 判定基準 │ │ │ │ 80-100: 判断の質が高い。実行検討に進んでよい。 │ │ 60-79: 追加検証を推奨。盲点がある可能性。 │ │ 40-59: 判断プロセス不十分。再検討が必要。 │ │ 0-39: 判断の根拠が不足。最初からやり直し。 │ │ │ │ ■ セクション別注意 │ │ │ │ T < 15: 前提条件の把握が不足 │ │ I < 15: 本質の見極めが不十分 │ │ D < 15: 選択肢の検討が狭い │ │ E < 15: 判断保護が弱い（政治に流されるリスク） │ │ │ └────────────────────────────────────────────────────────┘ ``` ### 3.2 スコア解釈ガイド | 総合スコア | 解釈 | 推奨アクション | | ---------- | -------------------- | -------------------------------------- | | **80-100** | 判断の質が高い | 実行に移してよい。再評価サイクルを守る | | **60-79** | 概ね良好だが盲点あり | 低スコアのセクションを重点的に再検討 | | **40-59** | 判断プロセスに問題 | 各セクションを一から見直す | | **0-39** | 根拠不足 | 判断を中止し、Terrainから再開 | --- ## 4. 事例 ### 4.1 失敗事例: イテレーション失敗によるフルリライト **背景**: ダッシュボードページの改善プロジェクト。初回描画に4秒かかるページの刷新。 **TIDE診断（事後）**: | 層 | スコア推定 | 問題 | |----|-----------|------| | T | 10/25 | リソース可用性の確認が不十分 | | I | 8/25 | CEO要望を未検証のまま本質トリガーと認定 | | D | 5/25 | イテレーティブな選択肢を検討したが途中で放棄 | | E | 3/25 | 撤退基準なし、ロールバック計画なし | | **計** | **26/100** | **判断根拠不足** | **何が起きたか**: より少ない、より大きなステップで機能をより早く出すことを選択。結果的に最も重要な機能の提供がイテレーティブなアプローチよりも遅くなった。パフォーマンスの悪さを理由にカットした機能が、一部の顧客にとって重要だったことが事後に判明。 **教訓**: パフォーマンス最適化を行う前に、顧客が元のページをどのように使っていたかを理解するための調査が必要だった。 ### 4.2 成功事例: Strangler Figによる小売クーポンシステム移行 **背景**: 大規模小売業者のレガシークーポンシステムのモダナイゼーション。 **TIDE診断（事後）**: | 層 | スコア推定 | 良かった点 | |----|-----------|-----------| | T | 20/25 | 組織フェーズと競争環境を正確に把握 | | I | 18/25 | Structureトリガーを明確に特定 | | D | 22/25 | Migrate（③）を選択、段階的移行計画を策定 | | E | 18/25 | モジュール単位の完了条件を設定 | | **計** | **78/100** | **概ね良好** | **成功要因**: 明確なモジュール境界の特定、段階的な移行とテスト、新旧システムの並行稼働。 ### 4.3 パターン認識成功したリビルドと失敗したリビルドの決定的な差： **成功パターン**: 進捗が速い。トンネルの終わりに光がすぐに見える。本番環境で動くものが早期に出る。ステークホルダーが安心する。 **失敗パターン**: 進捗が遅い。過剰設計や複雑すぎるアプローチを選んでいる。本番に出るまでの時間が長く、不確実性が蓄積する。 --- ## 5. 診断プロンプト ### 5.1 初期診断プロンプト ``` あなたはTIDE Framework v2.0（Technical Investment Decision Engine）の診断アシスタントです。以下の4層分析を支援してください。【T: Terrain（地形）】 - 組織のフェーズは？（スタートアップ/成長/成熟/転換） - 競争環境における時間圧力は？ - 技術負債の増大パターンは？（線形/指数関数的/安定） - チームの状態は？（離職率、士気、採用状況） - リソース可用性は？（人員、予算、時間）【I: Insight（本質）】 - なぜリライト/刷新を検討しているか？ - その理由は3Sのどれか？（Signal/Structure/Substance） - Signal理由はAIで代替可能か？ - Substanceトリガーは存在するか？ - 失敗の5構造のうち、該当するリスクは？【D: Design（設計）】 - 5つの選択肢（Observe/Augment/Migrate/Isolate/Replace）を全て検討したか？ - 「Observe」のコストは？ - 各選択肢のトレードオフは？【E: Evaluate（評価）】 - 撤退基準は設定されているか？ - 外部検証者は誰か？ - 反対意見は収集されたか？各質問に対する回答を受けて、スコアカードの推定スコアと改善すべきポイントを提示してください。 ``` ### 5.2 トリガー深掘りプロンプト ``` 以下の「リライトしたい理由」をTIDE Frameworkの3Sモデルで分析してください。【入力する理由】（ここにリライトしたい理由を記載）【分析観点】 1. この理由はSignal/Structure/Substanceのどれに分類されるか？ 2. Signalの場合、AI支援で解決可能か？具体的にどのように？ 3. Structureの場合、Migrate（③）やIsolate（④）で対応可能か？ 4. Substanceの場合、具体的に何が根本的に変化したか？ 5. 失敗の5構造のうち、該当するリスクは？【出力形式】 - 分類: [Signal / Structure / Substance] - 根拠: [分類の理由] - AI代替可能性: [高/中/低] - 失敗リスク: [5構造のうち該当するもの] - 推奨選択肢: [① ② ③ ④ ⑤ のいずれか] - 推奨アクション: [具体的な次のステップ] ``` ### 5.3 選択肢拡張プロンプト ``` 以下の状況に対して、TIDE Frameworkの5つの選択肢をそれぞれ具体化してください。【状況】（ここに状況を記載）【5つの選択肢を具体化】 ① Observe（静観） - 12ヶ月後の予測コスト: - メリット/デメリット: ② Augment（AI治療） - 具体的なAI活用方法: - 必要期間: - メリット/デメリット: ③ Migrate（漸進移行） - 移行ステップ: - 必要期間: - メリット/デメリット: ④ Isolate（部分刷新） - 対象範囲: - 必要期間: - メリット/デメリット: ⑤ Replace（全面刷新） - 必要リソース: - 必要期間: - メリット/デメリット: 【評価マトリクス】各選択肢を「時間」「コスト」「リスク」「可逆性」で評価し、推奨順位を提示してください。 ``` --- ## 6. 運用モード（SIA適用） ### 6.0 設計思想: 課金事故を構造的に不可能にする従来の運用モード設計は「ガイドライン」（SIA Layer 3）のみに依存していた。「30分で終わらせましょう」は、「制限速度を守りましょう」と同じ — 守れるかは意志次第。 v2.0では、SIA（Structural Impossibility Architecture）の思想を適用し、 **モードの逸脱を「構造的に不可能」にする**。 ``` ┌─────────────────────────────────────────────────────────┐ │ Layer 0: 型（成果物テンプレートが固定） │ │ → モードに存在しないセクションは「書く場所がない」 │ │ → スコープ超過が構造的に不可能 │ │ │ │ Layer 1: ゲート（エスカレーション条件が明示） │ │ → 簡易→標準→詳細の移行に明示的な判断と再合意が必要 │ │ → 「気づいたら詳細モードになっていた」が不可能 │ │ │ │ Layer 2: デリバリー検証（成果物 = モード） │ │ → 成果物がモードのテンプレートと一致しなければ納品不可 │ │ → 過剰/過少な成果物を納品することが不可能 │ │ │ │ Layer 3: ガイドライン（時間目安） │ │ → 「30分」「半日」「1週間」は目安として残る │ │ → ただし制御はLayer 0-2が担う │ │ │ │ Layer 4: 創造的自由（モード内の柔軟性） │ │ → Layer 0-2の枠内で、分析の深さや表現は自由 │ └─────────────────────────────────────────────────────────┘ ``` ### 6.1 簡易モード **適用条件**: 小規模変更、影響範囲が限定的、緊急性が高い **SIA Layer 0（型）— 成果物テンプレート**: ``` ┌────────────────────────────────────────────────────────┐ │ TIDE Quick Scan │ │ モード: 簡易 │ ├────────────────────────────────────────────────────────┤ │ │ │ 対象: _______________________ │ │ 日付: ____年__月__日 │ │ │ │ ■ 3S分類 │ │ リライト理由: ________________________ │ │ 分類: □ Signal □ Structure □ Substance │ │ 根拠: ________________________ │ │ │ │ ■ Signal層のAI代替可能性 │ │ □ 高（AI支援で解決可能） │ │ □ 中（部分的に解決可能） │ │ □ 低（AI支援では困難） │ │ │ │ ■ 判定 │ │ □ Substance なし → ①Observe or ②Augment を推奨 │ │ □ Substance あり → 標準モードへエスカレーション │ │ │ │ ■ Section I スコア: ___/25 │ │ 15点未満 → 標準モードへエスカレーション │ │ │ │ ■ 推奨アクション（1つだけ記載） │ │ ________________________ │ │ │ └────────────────────────────────────────────────────────┘ ``` **テンプレートに存在しないもの** = このモードでは実施しない: - ✗ Terrain分析（T） - ✗ 5選択肢の全検討（D） - ✗ 外部検証（E） - ✗ 撤退基準の設計 **SIA Layer 1（ゲート）— エスカレーション条件**: 以下のいずれかに該当した場合、簡易モードを**中止**し標準モードへ移行する。この移行には**スコープと見積もりの再合意**が必須。 ``` エスカレーション・トリガー: □ Substanceトリガーが検出された □ Section I スコアが15点未満 □ 複数チームに影響することが判明した □ 「もう少し深掘りしたい」と感じた ← これ自体がシグナル ``` **SIA Layer 2（デリバリー検証）**: - 成果物はQuick Scanテンプレート**1枚のみ** - 1枚を超える成果物 → それは簡易モードではない --- ### 6.2 標準モード **適用条件**: 中規模以上の変更、複数チームに影響、通常の意思決定 **SIA Layer 0（型）— 成果物テンプレート**: ``` ┌────────────────────────────────────────────────────────┐ │ TIDE Standard Analysis │ │ モード: 標準 │ ├────────────────────────────────────────────────────────┤ │ │ │ 対象: _______________________ │ │ 日付: ____年__月__日 │ │ │ │ ■ T: Terrain │ │ 組織フェーズ: □ スタートアップ □ 成長 □ 成熟 □ 転換 │ │ 時間圧力: □ 高 □ 中 □ 低 │ │ 技術負債パターン: □ 線形 □ 指数関数的 □ 安定 │ │ チーム健全性: ________________________ │ │ リソース可用性: ________________________ │ │ │ │ ■ I: Insight │ │ 3S分類: [Signal / Structure / Substance] │ │ 根拠: ________________________ │ │ AI代替可能性: □ 高 □ 中 □ 低 │ │ 失敗リスク: [5構造のうち該当するもの] │ │ │ │ ■ D: Design │ │ 5選択肢評価: │ │ ① Observe [時間: /コスト: /リスク: /可逆性: ] │ │ ② Augment [時間: /コスト: /リスク: /可逆性: ] │ │ ③ Migrate [時間: /コスト: /リスク: /可逆性: ] │ │ ④ Isolate [時間: /コスト: /リスク: /可逆性: ] │ │ ⑤ Replace [時間: /コスト: /リスク: /可逆性: ] │ │ 推奨: [選択肢番号] 根拠: ________________________ │ │ │ │ ■ E: Evaluate │ │ 検証者: □ 内部レビュー（標準モードでは内部可） │ │ 撤退基準: ________________________ │ │ 再評価サイクル: ________________________ │ │ │ │ ■ スコアカード │ │ T:___/25 I:___/25 D:___/25 E:___/25 計:___/100 │ │ │ │ ■ 判定 │ │ □ 60点以上 → 推奨選択肢で実行 │ │ □ 60点未満 → 再検討（低スコアセクションを重点的に） │ │ □ 40点未満 → 詳細モードへエスカレーション │ │ │ └────────────────────────────────────────────────────────┘ ``` **テンプレートに存在しないもの** = このモードでは実施しない: - ✗ T-I-D-Eの複数回反復 - ✗ 外部CTO/アドバイザーの検証（内部レビューで可） - ✗ 経営層への報告プロセス - ✗ 48時間ルール **SIA Layer 1（ゲート）— エスカレーション条件**: ``` エスカレーション・トリガー: □ スコアが40点未満 □ Replace（⑤）が推奨選択肢になった □ 全社的影響が判明した □ 不可逆的判断であることが判明した □ 反復分析が必要と判断した ``` **SIA Layer 2（デリバリー検証）**: - 成果物はStandard Analysisテンプレート**1式のみ** - 外部検証報告書が含まれている → それは標準モードではない --- ### 6.3 詳細モード **適用条件**: 大規模変更、全社的影響、不可逆的判断 **SIA Layer 0（型）— 成果物テンプレート**: ``` ┌────────────────────────────────────────────────────────┐ │ TIDE Deep Analysis │ │ モード: 詳細 │ ├────────────────────────────────────────────────────────┤ │ │ │ 対象: _______________________ │ │ 期間: ____年__月__日〜 ____年__月__日 │ │ 分析チーム: _______________________ │ │ │ │ ■ Part 1: T-I-D-E 分析（複数回反復） │ │ 第1回分析: [日付] [結果サマリー] │ │ 第2回分析: [日付] [結果サマリー] │ │ 第N回分析: [日付] [結果サマリー] │ │ 反復による発見: ________________________ │ │ │ │ ■ Part 2: 外部検証報告（必須） │ │ 検証者: ________________________（CTO経験者） │ │ 検証日: ____年__月__日 │ │ 検証所見: ________________________ │ │ 見落とし指摘: ________________________ │ │ 推奨事項: ________________________ │ │ │ │ ■ Part 3: スコアカード（最終版） │ │ T:___/25 I:___/25 D:___/25 E:___/25 計:___/100 │ │ │ │ ■ Part 4: 経営報告 │ │ 推奨選択肢: [番号] │ │ 投資規模: [金額] │ │ 期間: [月数] │ │ リスク: ________________________ │ │ 撤退基準: ________________________ │ │ │ │ ■ Part 5: 48時間ルール │ │ 最終判断日: ____年__月__日 │ │ 48時間後確認: ____年__月__日 │ │ 判断変更: □ なし □ あり（内容: ____________） │ │ │ │ ■ 判定 │ │ □ 80点以上 → 実行承認 │ │ □ 80点未満 → 追加検証（不足セクションを特定） │ │ │ └────────────────────────────────────────────────────────┘ ``` **テンプレートに存在するもの（全て必須）**: - ✓ 複数回の反復分析 - ✓ 外部CTO/アドバイザーの検証報告 - ✓ 経営層向け報告 - ✓ 48時間ルールの記録 **SIA Layer 2（デリバリー検証）**: - Part 1-5の**全てが記入済み**でなければ納品不可 - 外部検証報告（Part 2）が空欄 → 詳細モードの成果物として不成立 --- ### 6.4 モード間エスカレーション・プロトコル **SIA Layer 1の核心**: モード間の移行は「自然に起きる」のではなく「明示的に判断する」。 ``` 簡易 ──→ 標準 ──→ 詳細 ↑ ↑ │ │ エスカレーション・ゲート（以下が全て必要） 1. エスカレーション理由の明文化 2. スコープ変更の合意 3. 見積もり（時間・コスト）の再提示 4. クライアント / 意思決定者の承認 ``` **構造的に不可能にしていること**: - 「気づいたら標準モードの深さだった」→ テンプレートが違うので気づかないことが不可能 - 「簡易モードの料金で詳細モードの成果物が出た」→ テンプレート不一致で納品不可 - 「エスカレーションせず追加作業をした」→ 追加セクションの記入場所がテンプレートに存在しない ### 6.5 SIA × TIDE 設計原則まとめ | SIA層 | TIDE運用での実装 | 防ぐ事故 | | ------------------------- | ---------------------------------- | ------------------ | | **Layer 0: 型** | 各モードの成果物テンプレート固定 | スコープ超過 | | **Layer 1: ゲート** | エスカレーション条件 + 再合意必須 | 暗黙のモード移行 | | **Layer 2: 検証** | 成果物 = テンプレート一致 | 過剰/過少納品 | | **Layer 3: ガイドライン** | 時間目安（30分/半日/1週間） | 参考情報として残す | | **Layer 4: 自由** | テンプレート内での分析の深さ・表現 | 制約しない | --- ## 7. 付録 ### 7.1 危険信号チェック（簡易版）以下のいずれかに該当する場合、**立ち止まって再検討**が必要： ``` □ 「10年支えるシステム」の根拠が「採用しやすい技術」 □ 人材エージェントの「紹介できません」が決定打 □ 「モダンな技術スタック」が目的語になっている □ 反対意見が政治的に封殺されている □ 「今決めないと手遅れ」という焦り □ 具体的な「技術負債」を列挙できない □ 新CTO就任直後の提案 □ 競合がやっているから ``` ### 7.2 用語定義 | 用語 | 定義 | | ------------------------- | ----------------------------------------------------------------- | | **Signal** | 3Sモデルの第1層。コード可読性、ドキュメント不足など「見える」症状 | | **Structure** | 3Sモデルの第2層。アーキテクチャ、性能などシステム構造の問題 | | **Substance** | 3Sモデルの第3層。ビジネスモデル、ドメインモデルの根本変化 | | **Strangler Fig Pattern** | 既存システムを段階的に新システムに置き換えるパターン | | **Second System Effect** | 第二システムで過剰設計に陥る傾向 | | **Moving Target** | リライト中もビジネス要件が変化し続ける問題 | | **Knowledge Evaporation** | 「なぜそう実装されたか」の暗黙知が失われる現象 | | **Political Capture** | 技術選定が政治争いに捕獲される現象 | ### 7.3 関連フレームワーク | フレームワーク | TIDEとの関係 | | --------------------------------------- | ---------------------------------------------- | | **ADR (Architecture Decision Records)** | 意思決定ログの記録形式として活用可能 | | **DORA Metrics** | Terrain層でのチーム状態の定量評価に活用可能 | | **Technical Debt Quadrant** | Insight層での負債分類に活用可能 | | **Wardley Mapping** | Terrain層での競争環境の可視化に活用可能 | | **Domain-Driven Design** | Migrate（③）選択時のサービス分割設計に活用可能 | ### 7.4 参考文献 1. Martin Fowler, "StranglerFigApplication" (2004) 2. Joel Spolsky, "Things You Should Never Do, Part I" (2000) 3. Fred Brooks, "The Mythical Man-Month" — Second System Effect 4. AWS Prescriptive Guidance, "Strangler fig pattern" 5. Microsoft Azure Architecture Center, "Strangler Fig Pattern" 6. Thoughtworks, "Embracing the Strangler Fig pattern for legacy modernization" ### 7.5 更新履歴 | バージョン | 日付 | 変更内容 | | ---------- | ------- | ------------------------------------------------------- | | v1.0 | 2025-02 | 初版リリース | | v2.0 | 2026-02 | TIDE一致化、3Sモデル、失敗5構造、事例、研究データ統合 | | v2.1 | 2026-02 | SIA統合: 運用モードに構造的不可能性アーキテクチャを適用 | ### 7.6 設計思想メモこのフレームワークは以下の洞察に基づいている： 1. **表層を本質と誤認する** — 人間は「見える問題」を過大評価し、「見えない問題」を過小評価する 2. **判断の政治的歪み** — 組織では「正しい判断」より「通りやすい判断」が選ばれやすい 3. **AI時代の前提変化** — 従来の「リライトすべき理由」の多くがAI支援で解決可能になりつつある 4. **技術選定は仮説である** — どの技術も永続しない。「10年支える」と確信した技術が3年で陳腐化する可能性を常に織り込むこれらの洞察は、技術が変わっても意思決定の構造的問題として残り続ける。フレームワークの「形式」は更新が必要だが、「視座」は持続する価値を持つ。 --- ## 8. ライセンス本フレームワークはオープンに利用可能です。商用利用、改変、再配布を許可します。出典の明記を推奨しますが、必須ではありません。 --- **TIDE Framework v2.0** Technical Investment Decision Engine 技術投資意思決定エンジン