TL;DR
- Technology Radar は技術選定を「Adopt（採用）/ Trial（試用）/ Assess（観察）/ Hold（保留）」の4象限で運用する仕組みで、属人的な意思決定を組織の判断ログに置き換える。
- 自社版の作り方は5ステップ。スコープ定義 → 候補収集 → 判定セッション → 公開 → 更新サイクル。判定の核は「証拠の強さ × 影響範囲」の2軸マトリクス。
- 月次30分の会議テンプレで運用に乗せる。Radar は「横断方針」、ADR は「個別決定」と層を分けると、二重運用にならない。
はじめに
こんにちは、みねです。
「この技術、来期から使いませんか」が会議で出るたびに議論が振り出しに戻る。採用したはずのライブラリが半年後には誰も使っていない。逆に、明らかに保守不能なまま塩漬けになっている技術が「停止」の合意を取れずに残り続ける。CTO・EM・アーキテクトとして組織を動かしていると、こうした技術選定の不可逆な決定が場当たりで積み上がる現実に直面します。
この記事のゴール:
ThoughtWorks 由来の Technology Radar を自社運用に乗せる手順を、4象限の判定ルールと月次30分の会議テンプレで具体化する。
この記事がカバーしないこと:
- ThoughtWorks 公式 Radar の各 Blip の中身解説（→ 公式 を参照）
- 個別技術の比較レビュー（→ microservices-failure-patterns など個別記事）
- ADR（Architecture Decision Record）テンプレートの詳細
1. Technology Radar とは何か
Technology Radar は、ThoughtWorks が 2010 年から発行している半年に一度の技術トレンドマップで、技術を点（Blip）として配置し、4 つの Ring で採用判断を可視化します（ThoughtWorks Technology Radar 公式）[公式値]。
用語を3つだけ整理します（公式 FAQ 準拠）[公式値]。
| 用語 | 意味 |
|---|---|
| Blip | 評価対象の個別技術（例: gRPC、Kubernetes、Rust） |
| Quadrant | 技術カテゴリ（Techniques / Tools / Platforms / Languages & Frameworks の 4 種）[公式値] |
| Ring | 採用推奨度の 4 段階（Adopt / Trial / Assess / Hold）[公式値] |
補足: Quadrant=カテゴリ軸、Ring=採用推奨度軸。
なぜ自社版が必要か
公式 Radar は世界全体のトレンドであり、特定の業界・組織規模・人員構成を前提にしていません。たとえば「Adopt: Rust」と書かれていても、Rust 経験者が3人しかいない100人規模の SaaS 企業にとっては Trial が現実的です。判定は文脈依存であり、自社の現実に合わせた Radar を作らないと、参考情報のまま終わります。
組織として技術選定が場当たりになると、microservices への安易な分割や、検証不足の OSS 採用が跡を残します。具体的な失敗パターンは microservices-failure-patterns にまとめてあります。
2. 4象限（Ring）の判定ルール
Radar の核は、Blip をどの Ring に置くかという判定です。判定基準を「気合」「経験」に頼ると属人化するので、2軸の判定マトリクスに落とします。
判定マトリクス
縦軸を 証拠の強さ（社内・社外での本番運用実績）、横軸を 影響範囲（採用したときに他チームに波及するか）として、4象限を割り当てます。
| 証拠 \ 影響範囲 | 限定的 | 広範 |
|---|---|---|
| 強い（複数本番事例） | Trial → Adopt 候補 | Adopt |
| 弱い（PoC 段階） | Assess | Trial（撤退基準必須） |
| 否定的（事故・運用不能） | Hold | Hold |
なお「弱い × 広範」で Trial に置く場合、広範影響の Trial は限定導入（1チーム/1サービス）を必須とします。証拠が薄いまま全社展開すると影響範囲が一気に広がるため、撤退コストを抑えるための安全弁として、最初は対象を絞って運用してください。
各 Ring の運用定義
ThoughtWorks 公式の Ring 定義は 「Adopt = 我々が強く推奨」「Trial = 価値があり追求すべき」「Assess = 知る価値あり」「Hold = 慎重に進める」 で、本番採用 vs 観察を区別する 4 段階です（公式 Radar FAQ）[公式値]。自社運用では、本記事のように 撤退基準・移行計画 まで添えると組織の意思決定ログとして機能します。
- Adopt: 組織標準として推奨。新規プロジェクトでは原則これを使う。逸脱には ADR が必要
- Trial: 限定スコープで本番運用する価値あり。撤退基準を必ず添える（例: 3か月で SLA 99.9% 未達なら Hold へ）
- Assess: 観察対象。PoC・社内勉強会の対象だが、本番投入は時期尚早
- Hold: 新規採用を止める。既存の運用も移行ロードマップを引く
判定の独立性
判定は提案者と別人が担う、というルールが効きます。1人 Radar は「提案＝採用」と等価で、Radar の機能（独立した判定の場）を失います。AI コーディングツールのように評価が割れる技術ほど、独立した判定の場が必要です。AI コーディング系の Trial 判定例は ai-coding-security-design のセキュリティ4層モデルを基準にすると、判定軸が明確になります。
3. 自社版の作り方 5ステップ
導入は5段階で進めます。順番を守ると、最初のサイクルで運用が止まりません。
graph LR
S1[1. スコープ定義] --> S2[2. 候補収集]
S2 --> S3[3. 判定セッション]
S3 --> S4[4. 公開]
S4 --> S5[5. 更新サイクル]
S5 -.差分.-> S2
ステップ1: スコープ定義
Quadrant を自社用にカスタマイズします。ThoughtWorks の4 Quadrant をそのまま使うか、業界特性に応じて差し替えます。SaaS なら「データ基盤」「観測（Observability）」を独立 Quadrant にする例があります。
スコープ定義で決めるもの:
- Quadrant 数とカテゴリ名
- Ring の運用定義（前章のテンプレで十分）
- Radar オーナー（後述）と判定参加者の範囲
ステップ2: 候補収集
Blip を集めます。集め方は3経路で並列化します。
| 経路 | 提案者 | 例 |
|---|---|---|
| ボトムアップ | 全エンジニア | 「このライブラリを試したい」 |
| プロジェクト発 | 各チーム TL | 「採用したので Adopt 化したい」 |
| 外部観察 | Radar オーナー | 公式 Radar、カンファレンス |
提案テンプレは1枚 Pull Request で完結させます。タイトル・Quadrant・推定 Ring・根拠（証拠の強さ）・影響範囲・撤退基準（Trial 候補のみ）。リポジトリ構造は ai-legible-repository-design のテンプレ思想と同じく、判定者が読みやすい形に固定します。
ステップ3: 判定セッション
次章の月次30分テンプレで実施します。
ステップ4: 公開
判定結果を3チャネルで配信します。
- Markdown ファイル（Git 管理、履歴で差分が追える）
- 内部 wiki（検索性のため）
- Slack 通知（差分のみ告知、全文転記しない）
OSS の Build Your Own Radar を使うと SVG が自動生成されます。手書きの可視化に時間を使う必要はありません。
ステップ5: 更新サイクル
月次は差分レビュー、四半期は全体改訂。月次の判定を四半期の発行に貯める運用にすると、毎月の負荷が軽くなります。
4. 月次30分の会議運用テンプレ
会議が30分で終わらないと続きません。アジェンダを固定します。
0:00-0:05 前回からの差分朗読（追加 Blip と移動候補）
0:05-0:20 各 Blip の判定ディスカッション（1件 ≤3 分）
0:20-0:25 Hold 移動候補の確認
0:25-0:30 次月までの宿題と署名
役割
- ファシリテーター: 時間管理、議論の打ち切り判断
- スクライブ: 判定結果の Markdown 反映、ADR との突き合わせ
- Radar オーナー: 議題優先度、判定停滞時の最終裁定
3役は別人が担います。役割を兼ねると、独立した判定の場が成立しません。
終了条件
会議の終了条件は「全 Blip の Ring が確定」もしくは「次回継続フラグが付いている」のどちらかです。未決を持ち越さないことより、未決を可視化することを優先します。
1件3分で結論を出すための質問
各 Blip の判定で、ファシリテーターは3問だけ聞きます。
- 本番運用の証拠は何件あるか
- 採用した場合の影響範囲は限定的か広範か
- Trial にする場合、撤退基準は何か
3問で答えられないなら、その Blip は Assess に置きます。情報不足は Assess、否定的事実があれば Hold、ポジティブな事実が揃えば Trial か Adopt です。
5. Radar と ADR の二層運用
Radar と ADR（Architecture Decision Record）は責務が違います。混同すると二重運用になり、片方が形骸化します。
| 軸 | Radar | ADR |
|---|---|---|
| 粒度 | 横断方針（言語・フレームワーク・ツール全体） | 個別決定（このサービスでは X を採用） |
| 更新頻度 | 月次差分・四半期改訂 | 決定の都度 |
| 責任 | Radar オーナー / CTO 室 | 各チームのテックリード |
| 参照方向 | ADR は Radar の Ring を引用 | Radar は ADR を集計しない |
参照方向の固定
Radar → ADR の片方向参照に固定します。ADR の本文に「Radar 上は Trial だが、本サービスは制約条件 Y のため Adopt として採用する」と書けば、逸脱の根拠が残ります。逆方向（Radar が ADR を集計する）を許すと、ADR の数で Ring が動く Radar になり、判定の独立性が失われます。
コード規約との連携
リポジトリ単位のコード規約・lint・CI ルールは、Adopt 判定された技術に紐づけて固定します。エージェントが読みやすいリポジトリ設計の観点は ai-agent-legible-repo-design を参照してください。Adopt の Blip ほど「規約が言語化されている」状態に持っていきます。
二層が機能している兆候
- 新規プロジェクトの ADR で Radar の Ring が引用されている
- Hold 入りした技術の段階的廃止 ADR が出ている
- Radar の差分が Slack 1スレッドで完結し、ADR は別チャンネルで議論されている
6. アンチパターンと回避策
実運用で観測される失敗パターンを4つに整理します。
| アンチパターン | 症状 | 回避策 |
|---|---|---|
| 流行追い Radar | Adopt が新語ばかりで実績の裏付けが無い | 証拠の強さの定義を「本番3か月以上」など定量化 |
| 棚卸し疲れ | 候補が多すぎて30分で終わらない | Quadrant 単位で会議を分割し並列化 |
| Hold が空 | 「停止」を明文化できず減点法として機能しない | 四半期に1件は Hold 候補を必ず議題化 |
| 1人 Radar | 提案者＝判定者で承認の独立性が無い | 提案者は判定セッションで投票権を持たない |
流行追い Radar の見分け方
直近6か月の Adopt 追加に対し、社内本番運用の証拠を伴うものの比率を計測します。例: 50%（経験則） を切ったら、そのチームの Radar は流行追いに振れている可能性が高い、というラインです。社内の蓄積データから導いた数値ではなく、目安として置く境界線である点に注意してください。新技術の Adopt が悪いのではなく、証拠なしの Adopt が悪いという基準で評価します。
棚卸し疲れの初期兆候
会議1件あたりの平均判定時間が3分を超え始めたら、Quadrant 分割の検討タイミングです。Tools と Languages-Frameworks を別会議に分割した場合、片方の会議が短時間（例: Blip 10件以下なら20分前後）で終わることが多くなります。
Hold を埋める難しさ
「使うのを止めよう」は、現役のサービスを担当しているチームには反発されます。だからこそ、Radar オーナーが個別チームの撤退コストではなく、組織全体のリスクを基準にHold を切り出す責任を持ちます。Hold は Radar の信頼性を生む層であり、ここが空のままだと Radar は機能しません。
7. まとめ
Technology Radar の自社版は、4象限の判定ルールと月次30分の会議テンプレで、十分に運用に乗ります。
- 証拠 × 影響範囲のマトリクスで Ring を決める（属人化を避ける）
- 月次30分・3役分担で会議を固定する（持続性を担保する）
- Radar と ADR を片方向参照で連携させる（二重運用を避ける）
- Hold を必ず埋める（減点法を機能させる）
最初の一手は、3 Blip だけ載せた Radar v0 を作って30分の会議を1回回すことです。完璧な Quadrant 設計より、最初のサイクルを完走する方が大事です。
技術選定の判断基準そのものを設計したい場合は、補完記事 tech-decision-criteria も併読してください。会議テンプレを実際の組織に合わせてカスタマイズしたい・第0回のファシリテーションを依頼したい場合は、X（@mine_take） までご連絡ください。
FAQ
Q1. Technology Radar は何人から始められる？
エンジニア5〜10人規模からでも開始できます。重要なのは人数ではなく、提案者と判定者を分離できるかです。1人で兼ねると判定の独立性が失われるため、最低でも提案・判定・スクライブの3役を別人で立てられる体制を目安にしてください。
Q2. ADR との違いは？
Radar は横断方針（言語・フレームワーク・ツール全体の Ring）、ADR は個別決定（このサービスでは X を採用する）を扱います。参照方向は Radar → ADR の片方向に固定し、ADR から Radar の Ring を引用する運用にすると二重管理を避けられます。
Q3. 四半期更新が重い場合は？
月次差分レビュー＋四半期全体改訂の2層に分解してください。月次は Blip の追加・移動だけを30分で扱い、四半期に一度それを束ねて公開する運用にすると、毎月の負荷が会議1本分まで下がります。
Q4. Hold の運用が形骸化したら？
四半期に1件は Hold 候補を必ず議題化するルールを置きます。Hold が空のままだと Radar は「採用したい技術リスト」に縮退し、減点法として機能しません。Radar オーナーが個別チームの撤退コストではなく組織全体のリスクを基準に Hold を切り出す責任を負ってください。
Q5. 公式 ThoughtWorks Radar をそのまま使ってはダメ？
参考情報としては有用ですが、自社運用には向きません。判定は文脈依存（人員構成・業界・既存資産）であり、公式 Radar の Adopt が自社では Trial 相当になるケースが多いためです。自社の現実に合わせて Ring を再判定する場が Radar の本質です。
8. References
- ThoughtWorks Technology Radar 公式: https://www.thoughtworks.com/radar
- Build Your Own Radar（OSS ツール）: https://www.thoughtworks.com/radar/byor
- 関連: microservices-failure-patterns / ai-coding-security-design / ai-legible-repository-design / ai-agent-legible-repo-design / tech-decision-criteria
