フレームワーク活用ガイドひとことで言うと#
組織が利用する技術（言語・フレームワーク・ツール・プラットフォーム）を Adopt / Trial / Assess / Hold の4段階で分類し、技術選定の意思決定を可視化・標準化する手法。
押さえておきたい用語#
- Adopt（採用）
- 組織として本番環境での使用を推奨する技術のこと。新規プロジェクトではデフォルトで選択される。
- Trial（試用）
- 限定的なプロジェクトで実績を積んでいる段階の技術を指す。成功すればAdoptに昇格する。
- Assess（評価）
- 調査・検証の価値があると判断された注目すべき技術である。PoC（概念実証）で適用可能性を検証する段階。
- Hold（保留）
- 新規採用を停止した技術のこと。既存利用は許容するが、新しいプロジェクトでは選択しない。
- Blip（ブリップ）
- レーダー上の個々の技術項目を指す。各ブリップにはリング（4段階）と象限（カテゴリ）が割り当てられる。
テックレーダーの全体像#
こんな悩みに効く#
- チームごとに異なる技術を採用し、スタック断片化が進んでいる
- 新しい技術を導入したいが、判断基準がなく属人的に決まる
- レガシー技術の非推奨化が進まず、保守コストが膨らんでいる
基本の使い方#
具体例#
エンジニア70名のEC企業。フロントエンドにReact、Vue、Angular、jQueryが混在し、チーム間の人材移動のたびにキャッチアップに 2〜3週間 かかっていた。共通コンポーネントの再利用もできず、同等の機能を各フレームワークで 3重に実装 している状態だった。
テックレーダーを導入し、ReactをAdopt、VueをTrial、AngularとjQueryをHoldに分類。新規プロジェクトはReact一択とし、既存のjQueryコードは改修時にReactへ段階移行するルールを設けた。
1年後、フロントエンドの 85% がReactに統一され、チーム間異動のキャッチアップは 3日 に短縮。共通コンポーネントライブラリが 120個 整備され、UI開発速度が 40% 向上した。
エンジニア300名の金融系SIer。案件ごとにAWS・Azure・GCPが混在し、インフラチームの対応コストが年間 1.2億円 に膨張していた。また、セキュリティ審査が案件ごとに必要で、新規案件の立ち上げに 6週間 かかっていた。
Platforms象限でAWSをAdopt、AzureをTrial（特定業界案件限定）、GCPをHoldに分類。Adopt技術については事前審査済みのテンプレートを用意し、セキュリティ審査を省略可能にした。
新規案件の立ち上げが 6週間 → 2週間 に短縮され、インフラチームの対応コストは年間 7,200万円 に削減された。
エンジニア18名のヘルスケアスタートアップ。CTOが独断で技術選定を行っており、「なぜこの技術を使うのか」がチームに共有されていなかった。CTOの退職リスクも懸念されていた。
全エンジニアでテックレーダーを作成。Adopt 12技術、Trial 5技術、Assess 8技術、Hold 6技術 を分類し、各技術に「なぜこのリングか」の理由を併記。四半期のテックリード会議でリング変更を議論する文化を定着させた。
技術選定が属人化から脱却し、新メンバーが「なぜこの技術スタックなのか」を 30分 で理解できるようになった。
やりがちな失敗パターン#
- レーダーを作って終わり — 四半期更新を怠ると、レーダーと実態が乖離して誰も参照しなくなる。更新サイクルをカレンダーに入れる
- Hold技術の移行計画がない — Holdに分類しただけでは既存コードは消えない。移行のタイムラインと担当を明記する
- 全員の合意を取ろうとして決まらない — 全会一致は不要。テックリード会議で判定し、異論はTrial期間で検証する
- リングの判定基準が曖昧 — 「なんとなくAdopt」では説得力がない。本番実績・社内知見・エコシステム成熟度・セキュリティの4軸で評価する
まとめ#
テックレーダーは、組織の技術スタックをAdopt・Trial・Assess・Holdの4段階で分類し、技術選定の意思決定を可視化するツール。ThoughtWorksが2010年に提唱し、技術のポートフォリオ管理として広く普及している。四半期ごとの定期更新と変更理由の記録により、属人的な技術選定から組織的な意思決定プロセスへの転換を実現する。