technology-radar

テクノロジーレーダー

テクノロジーに関する意思決定、アーキテクチャのガバナンス、エンジニアリングの有効性の測定、技術的負債の管理、イノベーションパイプラインの運用を行うための CTO の方法論です。これらのフレームワークは、短期的なデリバリー速度と長期的なプラットフォームの健全性のバランスを CTO が取るのに役立ちます。

使用しないケース

• エンタープライズケイパビリティマップ、オペレーティングモデルの設計、現状／目標状態のロードマップについては、enterprise-architecture に振り分けてください。このスキルはテクノロジーポートフォリオの方針とガバナンスの仕組みに焦点を当てています。システムレベルの目標設計には、software-architecture を使用してください。
• 重大な意思決定の永続的な記録については adr-authoring に振り分けてください。このスキルは、ガバナンスの進め方を選び、その決定を標準やレーダーのフィードバックに結び付けるために使用します。
• システム設計とコード変更については関連するエンジニアリングスキルに、セキュリティ要件と脅威モデリングについては secure-software-engineering に、稼働中の運用や SLO に関する作業については site-reliability-engineering に振り分けてください。

ドメインモデル

ドメイン	対象範囲	成果物
テクノロジーレーダー	Adopt／Trial／Assess／Hold の各象限、ツール選定基準、廃止ポリシー	テクノロジーレーダー文書
内製か購入か	TCO 分析、意思決定マトリクス、ベンダー評価、統合コスト	内製か購入かの推奨
アーキテクチャガバナンス	自動化されたポリシー、連合型の意思決定、アドバイスプロセス、集中レビュー、標準、例外、フィードバック	ガバナンス意思決定記録、標準、例外、レーダー更新
エンジニアリングメトリクス	DORA（デプロイ頻度、リードタイム、MTTR、変更失敗率）、SPACE、DevEx	エンジニアリングダッシュボード、健全性レポート
技術的負債	利息の算出、修正の優先順位付け、元本の見積もり	技術的負債台帳
イノベーションパイプライン	将来動向の調査、POC の基準、本番環境への準備状況を確認するゲート	イノベーションファネル、POC レポート

読み込むタイミング

次のような作業を行う場合に、このスキルを読み込んでください。

• 新しいテクノロジーやツールの導入を評価する
• TCO 分析を伴う内製か購入かの判断を行う
• アーキテクチャガバナンスプロセスを設計または監査する
• エンジニアリングメトリクスのダッシュボード（DORA、SPACE）を設定する
• 技術的負債の修正を定量化し、優先順位を付ける
• POC から本番環境へのゲートを設けてイノベーションパイプラインを運用する
• レガシーテクノロジーを非推奨にする、または廃止する
• 自動化されたポリシー、連合型の意思決定、アドバイスプロセス、集中レビューを選択または監査する

ガバナンスのワークフロー

アーキテクチャまたはテクノロジーガバナンスに関する作業では、references/architecture-governance.md を読み、次の手順に従ってください。

1. 意思決定、意図する成果、影響を受けるシステムとチーム、利用可能な根拠、意思決定の責任者を明確にします。
2. 可逆性、適用範囲、リスク、影響範囲、規制上の影響、チーム間への影響を評価します。不確実性を根拠のないスコアに置き換えず、そのまま記録してください。
3. 信頼できる範囲で下振れリスクを抑えられる、最も軽量なガバナンス方式を選択します。自動化されたポリシー、連合型の意思決定、アドバイスプロセス、集中レビューから選んでください。根拠から、当初の想定より意思決定の可逆性が低い、適用範囲が広い、リスクが高い、または規制が厳しいと分かった場合は、上位の審査に回します。
4. 意思決定記録、実装時の確認事項、例外申請の経路、再検討の契機となるシグナルを定めます。
5. 実装と運用から得られた根拠を、意思決定、標準、例外、レーダーの方針に反映します。フィードバックは、遡及的に責任を問うためではなく、学ぶ機会として扱ってください。

参照ファイル

参照資料	読み込むタイミング	ファイル
Technology Radar	テクノロジーやツールを評価し、導入、試行、評価、保留に分類する必要がある場合	references/technology-radar.md
Build vs Buy	TCO 分析と判断基準に基づいて、内製と購入の選択肢を比較する場合	references/build-vs-buy.md
Architecture Governance	適切なガバナンスモード、標準、例外、エスカレーション、フィードバックを選択または監査する場合	references/architecture-governance.md
Engineering Metrics	DORA、SPACE、または DevEx フレームワークを用いて、エンジニアリングの有効性を測定する場合	references/engineering-metrics.md

設計原則

1. テクノロジーは手段であり、目的ではありません。 テクノロジーに関するあらゆる判断は、ビジネス成果に結び付いている必要があります。「新しいから」は導入の理由にはなりません。「X をより速く／安全に／低コストで解決できるから」が理由になります。
2. レーダーは常に更新されるドキュメントです。 テクノロジー・レーダーは、エビデンス、戦略、リスク、または使用状況に重大な変化があったときに更新する必要があります。ポートフォリオに合った更新周期を設定し、重要な導入、保留、昇格、または廃止の判断があった場合は、カレンダー上の時期を待たずに更新を行います。
3. 内製か購入かの判断は、コストだけではありません。 総所有コストには、保守、採用、トレーニング、統合、移行、機会費用が含まれます。今日の内製コストが安くても、3 年間でははるかに高くつく可能性があります。
4. エンジニアリング指標は、人ではなくシステムを測定します。 DORA 指標は、組織のデリバリー能力を測定します。SPACE は、開発者の満足度を測定します。どちらも個人の人事評価に使うものではありません。
5. 技術的負債には元本と利息があります。 元本は、適切に修正するためのコストです。利息は、速度を継続的に低下させる負担です。利息と元本の比率が最も高い負債を優先してください。
6. 本番運用への準備ゲートは、危機を防ぐためにあります。 迅速化を理由に省略したゲートは、その後のインシデント対応時間という形で必ず代償を払うことになります。
7. ガバナンスは、判断の影響に応じて適用する必要があります。 局所的で取り消し可能な判断は現場に委ねます。取り消し不能な判断、規制対象の判断、影響範囲の大きい判断、または複数チームに実質的な影響を与える判断には、より強い連携または権限が必要です。

移植性

このスキルは、特定のホストに依存しないように設計されています。ここに記載されている参照資料、テンプレート、スクリプトは、エージェントが通常使用する方法で読み込んでください。特定のプロファイルシステム、タスクオーケストレーター、メモリーサービス、または応答引き継ぎ形式を前提にしないでください。