「新しい技術を採用すべきか、チーム全体でどう判断すればいいか」と悩んだことはないだろうか。
Tech Radar（テックレーダー）は、組織が利用する技術・ツール・プラットフォーム・言語を4つのリング（Adopt・Trial・Assess・Hold）に分類し、技術選定の方向性を可視化したフレームワークだ。ThoughtWorksが広めたことで世界標準となっており、グローバルなエンジニアリング組織では英語でのテックレーダー設計書の作成が求められる。
この記事では、英語テックレーダー設計書の4つの必須セクションと日英テンプレートを解説する。コピペで使えるWord形式のテンプレートもダウンロードできる。
技術選定の意思決定を英語で体系化し、組織全体で合意できるようになる、実践的な内容だ。
英語テックレーダー設計書とは？4つのリングの意味を整理する
テックレーダー設計書（Tech Radar Design Document）は、組織の技術ポートフォリオを評価・分類し、各技術の採用方針と選定基準を文書化したものだ。
テックレーダーの4つのリング（Blip Status）の定義は以下のとおりだ。
| リング | 英語表記 | 意味 | 行動指針 |
|---|---|---|---|
| Adopt | Adopt | 本番採用を推奨する技術 | 積極的に新プロジェクトで使用する |
| Trial | Trial | 本番での試用を推奨する技術 | パイロットプロジェクトで検証する |
| Assess | Assess | 調査・評価を推奨する技術 | PoC・学習を通じて理解を深める |
| Hold | Hold | 採用を一時停止・廃止推奨の技術 | 新規採用を避け、段階的に移行する |
テックレーダーが扱う4つのカテゴリ（Quadrant）も整理しておく。
| カテゴリ | 英語表記 | 例 |
|---|---|---|
| 言語・フレームワーク | Languages & Frameworks | TypeScript, Go, React, FastAPI |
| ツール | Tools | GitHub Actions, Terraform, Datadog |
| プラットフォーム | Platforms | AWS, Kubernetes, Snowflake |
| 技術・手法 | Techniques | Platform Engineering, MLOps, DDD |
テックレーダー設計書が必要な場面は以下のとおりだ。
| 場面 | 例 |
|---|---|
| 技術選定の標準化 | 複数チームの技術スタック統一方針の策定 |
| 新技術採用の意思決定 | 新フレームワーク・ツールの組織的評価 |
| 技術的負債の解消 | レガシー技術の廃止・移行計画 |
| エンジニア採用・育成 | 習得すべき技術の明示 |
| CTO・経営層報告 | 技術投資方針の可視化 |
英語テックレーダー設計書の4つの必須セクション
英語テックレーダー設計書は4つのセクションで構成する。
1. Radar Scope & Governance（スコープとガバナンス）
テックレーダーの対象範囲と、誰がどのように評価・更新するかを定義するセクションだ。ガバナンスが曖昧だと、テックレーダーはすぐに形骸化する。
スコープの定義例：
| 項目 | 内容 |
|---|---|
| 対象組織 | エンジニアリング部門全体（〇〇事業部を含む） |
| 対象期間 | 2027年上半期（1月〜6月） |
| 更新頻度 | 四半期に1回（1月・4月・7月・10月） |
| 次回レビュー日 | 2027年3月31日 |
| フレームワーク | ThoughtWorks Tech Radar形式 |
ガバナンス体制の例：
| 役割 | 担当 | 責任 |
|---|---|---|
| Tech Radar Lead | CTO / Principal Engineer | 全体統括・最終承認 |
| Quadrant Owner | 各領域のSenior Engineer（4名） | 担当カテゴリの評価・提案 |
| Contributor | 全エンジニア | 技術の推薦・フィードバック |
| Reviewer | Architecture Review Board | 評価基準の一貫性確認 |
評価プロセス：
| ステップ | 内容 | 期間 |
|---|---|---|
| 1. Nomination | エンジニアが技術を推薦・提案 | 随時 |
| 2. Assessment | Quadrant Ownerが評価・スコアリング | レビュー前4週間 |
| 3. Review | ARBがレビュー・議論 | レビュー前2週間 |
| 4. Approval | Tech Radar Leadが承認 | レビュー前1週間 |
| 5. Publication | 全社に公開・周知 | レビュー日 |
英語例文：
- “The Tech Radar is updated quarterly and covers all engineering teams across the organization.”
- “Each quadrant is owned by a Senior Engineer who is responsible for maintaining the blip status.”
- “Any engineer can nominate a technology for assessment by submitting a proposal to the Quadrant Owner.”
- “Blip status changes require approval from the Architecture Review Board.”
2. Blip Registry（技術評価一覧）
各技術の評価結果・ステータス・評価理由を一覧化するセクションだ。これがテックレーダーの中核となる。
Languages & Frameworks（言語・フレームワーク）：
| 技術 | ステータス | 変更 | 評価理由 |
|---|---|---|---|
| TypeScript | Adopt | ↑（Trialから昇格） | 型安全性・開発者体験・エコシステムの成熟 |
| Go | Adopt | → | マイクロサービス・CLIツール開発の標準 |
| React | Adopt | → | フロントエンド開発の組織標準 |
| FastAPI | Trial | NEW | Python APIの生産性向上・型定義の明示 |
| Next.js | Trial | → | SSR・SSGが必要なプロジェクトでの評価継続 |
| Ruby on Rails | Hold | ↓（Adoptから降格） | 新規採用を停止し段階的にPython/GoへIgration |
Tools（ツール）：
| 技術 | ステータス | 変更 | 評価理由 |
|---|---|---|---|
| GitHub Actions | Adopt | → | CI/CDパイプラインの組織標準 |
| Terraform | Adopt | → | IaCの組織標準・エコシステム充実 |
| Datadog | Adopt | → | オブザーバビリティの組織標準 |
| OpenTelemetry | Trial | ↑ | ベンダー非依存のトレーシング標準として評価 |
| Pulumi | Assess | NEW | TypeScriptでIaCを記述できる点を評価中 |
| Jenkins | Hold | → | GitHub Actionsへの移行を推奨 |
Platforms（プラットフォーム）：
| 技術 | ステータス | 変更 | 評価理由 |
|---|---|---|---|
| AWS | Adopt | → | クラウド基盤の組織標準 |
| Kubernetes | Adopt | → | コンテナオーケストレーションの標準 |
| Backstage | Trial | ↑ | Internal Developer Portalとして組織展開評価中 |
| Snowflake | Trial | → | データプラットフォームとして評価継続 |
| Wasm（WebAssembly） | Assess | NEW | ブラウザ・エッジ実行環境として調査中 |
| Heroku | Hold | ↓ | コスト・カスタマイズ性の観点からAWSへ移行 |
Techniques（技術・手法）：
| 技術 | ステータス | 変更 | 評価理由 |
|---|---|---|---|
| Platform Engineering | Adopt | ↑ | 開発者体験向上の組織標準アプローチ |
| MLOps | Trial | → | ML基盤の標準化に向けて評価継続 |
| FinOps | Trial | ↑ | クラウドコスト最適化の実践として展開 |
| Chaos Engineering | Assess | NEW | 障害耐性検証の手法として調査中 |
| Micro-frontends | Hold | → | 複雑性コストが高く、現時点では推奨しない |
英語例文：
- “TypeScript has been promoted from Trial to Adopt based on strong developer experience and ecosystem maturity.”
- “Ruby on Rails is moved to Hold. Teams currently using it should plan migration to Go or Python over the next 18 months.”
- “OpenTelemetry is in Trial as we evaluate it as our vendor-neutral observability standard.”
- “We assess WebAssembly for edge computing use cases and will report findings in the next radar cycle.”
3. Evaluation Criteria（評価基準）
テックレーダーのリングを決定するための評価軸と採点基準を定義するセクションだ。評価基準を明示することで、技術選定の一貫性と透明性が担保される。
評価軸（Evaluation Dimensions）：
| 評価軸 | 重み | 説明 |
|---|---|---|
| Technical Maturity | 25% | 技術の成熟度・安定性・後方互換性 |
| Community & Ecosystem | 20% | コミュニティの活発さ・ドキュメント・ライブラリ |
| Developer Experience | 20% | 学習コスト・開発生産性・ツールサポート |
| Operational Fitness | 20% | 運用しやすさ・可観測性・スケーラビリティ |
| Strategic Alignment | 15% | 組織の技術戦略・ロードマップとの整合性 |
リング判定基準（スコアリング例）：
| 総合スコア | 判定リング |
|---|---|
| 80点以上 | Adopt |
| 60〜79点 | Trial |
| 40〜59点 | Assess |
| 39点以下 / 廃止推奨 | Hold |
評価シートの例（FastAPI）：
| 評価軸 | スコア（/20） | コメント |
|---|---|---|
| Technical Maturity | 16 | Python標準の型ヒントを活用した成熟したフレームワーク |
| Community & Ecosystem | 17 | 急速に成長するコミュニティ・豊富なドキュメント |
| Developer Experience | 18 | 自動ドキュメント生成・型定義による開発生産性が高い |
| Operational Fitness | 15 | ASGI対応・非同期処理・Dockerとの相性が良好 |
| Strategic Alignment | 14 | Python/MLチームとのスタック統合に有効 |
| 合計 | 80 | → Adopt判定 |
英語例文：
- “Each technology is evaluated across five dimensions, each scored on a 20-point scale.”
- “A total score of 80 or above qualifies a technology for Adopt status.”
- “The Strategic Alignment dimension assesses how well the technology supports our long-term architecture roadmap.”
- “Evaluation scores are reviewed and validated by the Architecture Review Board before publication.”
4. Migration & Sunset Plan（移行と廃止計画）
Hold判定の技術について、廃止スケジュールと移行先を明示するセクションだ。廃止計画が伴わないHold判定は実行されないまま形骸化する。
廃止・移行計画の例：
| 技術（Hold） | 移行先 | 移行期限 | 担当 | 移行支援 |
|---|---|---|---|---|
| Jenkins | GitHub Actions | 2027年Q2 | Platform Team | 移行ガイド・ペアワーク |
| Ruby on Rails | Go / Python | 2028年Q4 | 各サービスチーム | ハンズオン研修 |
| Heroku | AWS ECS | 2027年Q1 | Cloud Team | IaCテンプレート提供 |
| Micro-frontends | モノリシックフロント | 採用停止 | – | – |
廃止フェーズの定義：
| フェーズ | 内容 | 期間 |
|---|---|---|
| Announcement | 廃止決定・移行先・スケジュールの周知 | 廃止の6ヶ月前 |
| Migration Support | 移行ガイド・ハンズオン・ペアワーク提供 | 廃止の3〜6ヶ月前 |
| New Adoption Freeze | 対象技術を新規プロジェクトに採用禁止 | 廃止の3ヶ月前 |
| Sunset | 既存プロジェクトの移行完了・サポート終了 | 廃止日 |
技術トレーニング・学習支援：
| 技術（Trial/Assess） | 学習リソース | 支援内容 |
|---|---|---|
| FastAPI | 公式ドキュメント・内部Wiki | ハンズオンセッション月1回 |
| OpenTelemetry | CNCF公式ドキュメント | SREチームによる導入支援 |
| Backstage | Spotify公式ドキュメント | Platform Teamによる設定支援 |
| Chaos Engineering | CNCF Chaos Engineering | 四半期ごとのGamedayの開催 |
英語例文：
- “Jenkins will be sunset by Q2 2027. All teams are expected to migrate to GitHub Actions by that date.”
- “The Platform Team will provide migration guides and pair programming support for teams transitioning from Jenkins.”
- “New projects must not adopt Jenkins as of Q4 2026, when the New Adoption Freeze takes effect.”
- “Quarterly Gamedays will be conducted to build team familiarity with Chaos Engineering practices.”
テンプレートをダウンロード（Word）
日本語版・英語版をWordファイルで用意した。
ダウンロードしてそのまま使えるフォーマットだ。
日本語版テンプレート（コピペOK）
【英語テックレーダー設計書】
組織名：
作成日：
作成者：
対象期間：
更新頻度：
次回レビュー日：
■ 1. スコープとガバナンス
役割 | 担当 | 責任
----|------|----
Tech Radar Lead | |
Quadrant Owner（4名） | |
Reviewer | |
評価プロセス：
1. Nomination：
2. Assessment：
3. Review：
4. Approval：
5. Publication：
■ 2. 技術評価一覧
【Languages & Frameworks】
技術 | ステータス | 変更 | 評価理由
----|---------|------|--------
| | |
【Tools】
技術 | ステータス | 変更 | 評価理由
----|---------|------|--------
| | |
【Platforms】
技術 | ステータス | 変更 | 評価理由
----|---------|------|--------
| | |
【Techniques】
技術 | ステータス | 変更 | 評価理由
----|---------|------|--------
| | |
■ 3. 評価基準
評価軸 | 重み | 説明
------|------|----
Technical Maturity | 25% |
Community & Ecosystem | 20% |
Developer Experience | 20% |
Operational Fitness | 20% |
Strategic Alignment | 15% |
リング判定基準：
・Adopt：80点以上
・Trial：60〜79点
・Assess：40〜59点
・Hold：39点以下
■ 4. 移行と廃止計画
技術（Hold） | 移行先 | 移行期限 | 担当 | 移行支援
----------|--------|---------|------|--------
| | | |英語版テンプレート（コピペOK）
[Tech Radar Design Document]
Organization:
Date:
Author:
Target Period:
Update Frequency:
Next Review Date:
■ 1. Radar Scope & Governance
Role | Owner | Responsibility
-----|-------|---------------
Tech Radar Lead | |
Quadrant Owners (×4) | |
Reviewer | |
Evaluation Process:
1. Nomination:
2. Assessment:
3. Review:
4. Approval:
5. Publication:
■ 2. Blip Registry
[Languages & Frameworks]
Technology | Status | Change | Rationale
----------|--------|--------|----------
| | |
[Tools]
Technology | Status | Change | Rationale
----------|--------|--------|----------
| | |
[Platforms]
Technology | Status | Change | Rationale
----------|--------|--------|----------
| | |
[Techniques]
Technology | Status | Change | Rationale
----------|--------|--------|----------
| | |
■ 3. Evaluation Criteria
Dimension | Weight | Description
----------|--------|------------
Technical Maturity | 25% |
Community & Ecosystem | 20% |
Developer Experience | 20% |
Operational Fitness | 20% |
Strategic Alignment | 15% |
Ring Thresholds:
• Adopt: 80+ points
• Trial: 60–79 points
• Assess: 40–59 points
• Hold: Below 40 points
■ 4. Migration & Sunset Plan
Technology (Hold) | Migration Target | Deadline | Owner | Support
-----------------|-----------------|---------|-------|-------
| | | |英語テックレーダー設計書で使えるフレーズ20選
ステータス変更を説明するフレーズ
| 日本語 | 英語 |
|---|---|
| 〜をTrialからAdoptに昇格します | ~ has been promoted from Trial to Adopt |
| 〜をHoldに移動します | ~ is moved to Hold |
| 新規採用を停止します | New adoption of ~ is no longer recommended |
| 段階的に〜へ移行します | Teams should plan migration to ~ over the next ~ months |
評価理由を説明するフレーズ
| 日本語 | 英語 |
|---|---|
| エコシステムの成熟と開発者体験の向上を評価しました | We evaluated ~ for its ecosystem maturity and developer experience |
| ベンダー非依存の標準として評価中です | We assess ~ as our vendor-neutral standard |
| 複雑性コストが高く現時点では推奨しません | The complexity cost is high; we do not recommend ~ at this time |
| 次のレーダーサイクルで調査結果を報告します | We will report findings in the next radar cycle |
廃止・移行計画のフレーズ
| 日本語 | 英語 |
|---|---|
| 〜年Q〜までにすべてのチームが移行する必要があります | All teams are expected to migrate by Q~, ~ |
| 移行ガイドとペアワークを提供します | We will provide migration guides and pair programming support |
| 〜から新規採用禁止となります | New projects must not adopt ~ as of ~ |
| 廃止の6ヶ月前に周知します | Teams will be notified 6 months before the sunset date |
ガバナンス・プロセスのフレーズ
| 日本語 | 英語 |
|---|---|
| テックレーダーは四半期ごとに更新されます | The Tech Radar is updated quarterly |
| 誰でも技術の推薦を提出できます | Any engineer can nominate a technology for assessment |
| ステータス変更はARBの承認が必要です | Blip status changes require ARB approval |
| 全社に公開・周知します | The updated radar is published and communicated to all engineering teams |
インナーソースで採用する技術の選定基準を可視化したい場合は、英語インナーソース計画書の書き方と組み合わせることで、技術決定とコード共有の方針を一体的に整備できる。
テックレーダーで技術選定の方針を定めたうえで、英語プラットフォームエンジニアリング議論術を活用することで、ゴールデンパスや標準化の推進をグローバルチームに英語で伝えられる。
まとめ：英語テックレーダー設計書は4つのセクションで完成する
英語テックレーダー設計書のポイントをまとめる。
- Radar Scope & Governance：対象範囲・更新頻度・ガバナンス体制を定義し、継続的な運用基盤を整える
- Blip Registry：4カテゴリの技術をAdopt/Trial/Assess/Holdに分類し、評価理由を記録する
- Evaluation Criteria：5つの評価軸とスコアリング基準で技術選定の一貫性と透明性を担保する
- Migration & Sunset Plan：Hold技術の廃止スケジュールと移行先を明示し、計画の実行を担保する
テックレーダーが機能するかどうかは、「誰がどう更新するか」のガバナンス設計で決まる。四半期ごとのレビューサイクルとQuadrant Ownerの責任を明確にすることで、技術選定の意思決定を継続的に組織に根付かせることができる。
テックレーダーで整理した技術方針は、エンジニアリングKPIと連動させることでビジネスへのインパクトを可視化できる。
英語エンジニアリングKPI設計書の書き方と合わせて活用することで、技術投資の効果を定量的に経営層へ報告できる。
テックレーダーで採用する技術はDX推進計画との整合が重要だ。
英語DX推進計画書の書き方も合わせて整備することで、技術選定とデジタル変革の方向性が揃う。
コメント