tech-radar

テクノロジーレーダー

エンジニアリングチーム向けに、包括的なテクノロジーレーダー文書を作成します。このレーダーでは、チームのスタックに含まれる重要なテクノロジーについて、何を標準として採用し、何を試し、何を評価し、何の使用を積極的に止めるべきかを、チームで共有できる明確な方針として示します。ThoughtWorks Tech Radar の形式に従い、4 つの象限（テクニック、ツール、プラットフォーム、言語とフレームワーク）それぞれに 4 つのリング（採用、試行、評価、保留）を設けます。各テクノロジー項目（「ブリップ」）には、リングの割り当て、1 段落の根拠、日付を記載します。何が、なぜ移動したのかを示す変更履歴と、レーダーを最新の状態に保つためにチームが実施できるメンテナンスプロセスも含めます。

必須入力

まだ提供されていない場合は、以下を尋ねてください。

• チーム名または会社名 — 文書のヘッダー用
• 現在の技術スタック — チームが現在使用している重要なテクノロジー、ツール、言語、プラットフォームをすべて列挙してください
• 積極的に評価中のテクノロジー — チームが現在試している、または検討しているツールやフレームワーク
• 非推奨にする、または移行するテクノロジー — チームが使用をやめたいもの、または積極的に移行中のもの
• 戦略的なテクノロジーへの賭け — 会社が意図的に注力しているテクノロジー（例：「Kubernetes に全面的に取り組む」や「イベント駆動型アーキテクチャへ移行する」）
• チームの背景情報 — チームの規模、製品領域、制約（規制、コンプライアンス、ベンダーロックインへの懸念など）

テクノロジーについて言及があり、リングの割り当てがない場合は、根拠となる入力を使って適切なリングを判断してください。2 つのリングのどちらにするか判断できない場合は、尋ねてください。

出力形式

---

テクノロジーレーダー：[チーム名／会社名]

版：［年月］ 管理者：［チーム名／アーキテクチャギルド／CTO オフィス］ **レビュー頻度：**年 2 回（6 か月ごと） 次回レビュー：［年月＋6 か月］

---

このレーダーの読み方

このレーダーは、［チーム名／会社名］が使用、評価、廃止するテクノロジーについて、現時点でどのように考えているかを示します。テクノロジーの選定に一貫性を持たせ、新しいエンジニアのオンボーディングを行い、スタックについて体系的に話し合うために活用してください。

象限は、テクノロジーの種類を分類します。

象限	含まれるもの
テクニック	手法、パターン、プラクティス（例：トランクベース開発、イベントソーシング）
ツール	開発およびデリバリープロセスで使用するソフトウェアツール（例：リンター、CI システム、可観測性プラットフォーム）
プラットフォーム	インフラストラクチャとホスティング環境（例：AWS、Kubernetes、Snowflake）
言語とフレームワーク	プログラミング言語とアプリケーションフレームワーク（例：Go、React、FastAPI）

リングは、推奨事項を表します。

リング	意味	対応方法
採用	業界で実績があり、当チームでも良好に機能しています。標準的な選択肢です	新しい作業ではデフォルトで使用してください。特別な理由は不要です
試行	取り組む価値があります。限定的な本番環境で試験運用しています	アーキテクチャの監督のもと、範囲を限定して使用し、得られた知見を共有してください
評価	調査する価値があります。本番環境ではまだ使用していません	試験実装、プロトタイプ作成、または調査を行ってください。レビューなしに本番環境では使用しないでください
保留	このテクノロジーを使った新しい作業を始めないでください	既存の取り決めを完了させ、使用を拡大せず、移行を計画してください

---

象限 1：テクニック

採用

テクノロジー	開始時期	備考
[技法名。例：トランクベース開発]	[月 年]	[採用した理由と、置き換えたものを説明する一文]
[技法名]	[月 年]	[理由を説明する一文]
[技法名]	[月 年]	[理由を説明する一文]

[技法名] — 採用 [理由を説明する段落。この技法がどのような問題を解決するのか、チームの状況に適している理由、適用する前にチームが把握しておくべきことを説明してください。社内での経験も記載してください。例：「2024年に8つのサービス全体に導入したところ、マージコンフリクトが40％減少しました。」]

[採用リングの技法ごとに繰り返します。]

試行

テクノロジー	開始時期	備考
[技法名]	[月 年]	[何をどこでテストしているのかを説明する一文]

[技法名] — 試行 [1段落で説明してください。何を試行していますか？どのチームやサービスで実施していますか？どのような仮説を検証していますか？採用または保留に移行する判断基準は何ですか？]

評価

テクノロジー	開始時期	備考
[技法名]	[月 年]	[関心を持っている理由を説明する一文]

[技法名] — 評価 [1段落で説明してください。なぜ関心を持っているのですか？試行に移行するには何を確認する必要がありますか？評価の担当者は誰ですか？]

保留

テクノロジー	開始時期	備考
[技法名]	[月 年]	[中止する理由と、置き換えるものを説明する一文]

[技法名] — 保留 [1段落で説明してください。なぜ保留にするのですか？移行の道筋はどのようなものですか？現在も使用しているチームが目指す最終状態は何ですか？]

---

第2象限：ツール

採用

テクノロジー	開始時期	備考
[ツール名。例：GitHub Actions]	[月 年]	[理由を説明する一文]
[ツール名]	[月 年]	[理由を説明する一文]

[ツール名] — 採用 [理由を説明する段落。これを標準ツールとしているのはなぜですか？チームの状況において、どのような点に優れていますか？チームが従うべき設定や使用パターンはありますか？]

[採用リングのツールごとに繰り返します。]

試行

テクノロジー	開始時期	備考
[ツール名]	[月 年]	[テストしている内容を説明する一文]

[ツール名] — 試行 [理由と試行範囲を1段落で説明してください。]

評価

テクノロジー	開始時期	備考
[ツール名]	[月 年]	[評価している理由を説明する一文]

[ツール名] — 評価 [関心を持つきっかけ、評価担当者、スケジュールを1段落で説明してください。]

保留

テクノロジー	開始時期	備考
[ツール名]	[月 年]	[置き換えるものを説明する一文]

[ツール名] — 保留 [非推奨とする理由と移行の道筋を1段落で説明してください。]

---

第3象限：プラットフォーム

採用

テクノロジー	開始時期	備考
[プラットフォーム名。例：AWS EKS]	[月 年]	[理由を説明する一文]
[プラットフォーム名]	[月 年]	[理由を説明する一文]

[プラットフォーム名] — 採用 [1段落で説明してください。このプラットフォームは何を提供しますか？使用範囲の境界はどこですか？チームが従うべき社内のゴールデンパス設定はありますか？]

[採用リングのプラットフォームごとに繰り返します。]

試行

テクノロジー	開始時期	備考
[プラットフォーム名]	[月 年]	[試行範囲を説明する一文]

[プラットフォーム名] — 試行 理由と試行の境界を1段落で説明してください。]

評価

テクノロジー	開始時期	備考
[プラットフォーム名]	[月 年]	[調査している理由を説明する一文]

[プラットフォーム名] — 評価 評価計画を1段落で説明してください。]

保留

テクノロジー	開始時期	備考
[プラットフォーム名]	[月 年]	[移行先とスケジュールを説明する一文]

[プラットフォーム名] — 保留 保留の判断に至ったきっかけ、移行先、スケジュールを1段落で説明してください。]

---

第4象限：言語とフレームワーク

採用

テクノロジー	開始時期	備考
[言語／フレームワーク、例：Go]	[月 年]	[理由を述べる一文]
[言語／フレームワーク]	[月 年]	[理由を述べる一文]

[言語／フレームワーク] — 採用 [1段落。この言語またはフレームワークは何に使用しますか？チームにはどの程度の習熟度を期待しますか？標準的な選択肢として併用するフレームワークやライブラリはありますか？]

[採用リングにある各言語またはフレームワークについて繰り返します。]

トライアル

テクノロジー	開始時期	備考
[言語／フレームワーク]	[月 年]	[範囲を限定したユースケースを示す一文]

[言語／フレームワーク] — トライアル [理由を述べる1段落。]

評価

テクノロジー	開始時期	備考
[言語／フレームワーク]	[月 年]	[関心を持ったきっかけを示す一文]

[言語／フレームワーク] — 評価 [評価計画を述べる1段落。]

保留

テクノロジー	開始時期	備考
[言語／フレームワーク]	[月 年]	[理由と移行先を示す一文]

[言語／フレームワーク] — 保留 [非推奨とする理由、既存システムに関する義務、および廃止までのスケジュールを述べる1段落。]

---

決定の記録

この記録には、レーダーの初版以降に行われたすべてのリング移動を記録します。テクノロジーの選択がどのように変化してきたかを把握するために利用してください。

テクノロジー	分野	以前のリング	新しいリング	版	理由
[名前]	[分野]	—	採用	[月 年]	初回配置 — [理由を述べる一文]
[名前]	[分野]	評価	トライアル	[月 年]	[移動のきっかけ — 証拠、チームからのフィードバック、本番環境での試行結果]
[名前]	[分野]	トライアル	採用	[月 年]	[採用理由 — 利用結果、チームの満足度、実証された規模]
[名前]	[分野]	採用	保留	[月 年]	[保留に移動した理由 — より優れた代替手段、セキュリティ上の懸念、コスト、ベンダーの問題]
[名前]	[分野]	—	保留	[月 年]	初回配置 — [理由]のため、直接保留に追加

---

レーダーのメンテナンスプロセス

寄稿者

• アーキテクチャレビューチーム／CTOオフィス — 最終的なリング配置を決定
• すべてのエンジニア — [チャンネルまたはフォーム]から候補を提出
• テックリード — 候補をトリアージし、レビュー会議に向けた提案を準備

更新頻度

作業	頻度	担当者
新しい候補の受付	継続 — すべてのエンジニアが[チャンネル]から提出可能	誰でも
候補のトリアージ	毎月	テックリード
レーダー全体のレビュー会議	6か月ごと	アーキテクチャグループ
レーダーの公開更新	6か月ごと	[担当者名または役割]

候補の提出方法

1. [Slackチャンネル／フォームのURL]に、テクノロジー名、分野、提案するリング、理由を述べる1段落を添えて提出します。
2. テックリードが2週間以内にレビューし、次回のレビュー会議に予定するか、追加情報を求めます。
3. レビュー会議でアーキテクチャグループが議論し、投票します。単純過半数で決定し、同数の場合は追加の証拠が得られるまで保留とします。
4. 承認された候補は、会議から1週間以内にレーダー文書と決定の記録に追加されます。

リング変更の基準

採用に移す条件	トライアルに移す条件	評価に移す条件	保留に移す条件
複数の本番システムで実績がある。チーム全体が十分なトレーニングを受けている。明確な運用手順書がある	少なくとも1つの本番ユースケースが稼働している。アーキテクチャ上の監督体制がある。得られた知見が文書化されている	具体的なユースケースが特定されている。スパイクが完了または進行中である。少なくとも2人のエンジニアが関心を示している	より優れた代替手段がある。既知のセキュリティ／コンプライアンス上のリスクがある。戦略的な方針が変更された。許容できないほど保守の負担が大きい

---

このレーダーに関する質問：[Slackチャンネル] | 候補の提出：[URLまたはチャンネル]

---

品質チェック

• すべてのブリップに、表の行への記載だけでなく、理由を説明する段落が記載されている
• すべてのブリップについて、少なくとも最初に配置した日付が意思決定の記録に記載されている
• Hold リングの項目には、単に「使用をやめる」とするのではなく、具体的な移行方法または移行先のテクノロジーが記載されている
• リングの定義があり、各リングの意味と、それに対してエンジニアが取るべき対応の両方が含まれている
• メンテナンスプロセスに、提案の受付窓口、レビュー頻度、決定者、リング変更の基準が含まれている
• 入力で「戦略的な賭け」と特定されたテクノロジーは、実証済みであれば Adopt に、導入中であれば Trial に配置されている
• 非推奨と特定されたテクノロジーは、置き換え先に言及した理由を添えて Hold に配置されている

アンチパターン

• チームの規模で実証済みであるという根拠なしに、テクノロジーを Adopt に配置しないでください。期待だけに基づく配置は、エンジニアを誤解させます
• 理由を説明する段落なしにブリップを追加しないでください。背景のない表の行は役に立ちません
• 具体的な移行方法または移行先のテクノロジーを指定せずに、Hold の項目を作成しないでください
• メンテナンスプロセスを省略しないでください。更新プロセスのないレーダーは、2 四半期以内に古くなります
• リングの定義を省略しないでください。エンジニアには、各リングの意味だけでなく、それに対して何をすべきかを知る必要があります