tech-trend-watch

長期的なテクノロジー動向の監視

データソース

ソース	頻度	URL	測定対象
State of JS	年次（秋）	https://stateofjs.com	JS ライブラリ、フレームワーク、ツール — 使用状況と満足度
State of CSS	年次（秋）	https://stateofcss.com	CSS ツール、フレームワーク、機能 — 使用状況と満足度
Thoughtworks Tech Radar	四半期ごと	https://www.thoughtworks.com/radar	幅広いテクノロジー（言語、プラットフォーム、ツール、手法） — リングの割り当て

レビューを始める前に、それぞれの最新の版を取得してください。State of JS/CSS では、公開 JSON API も提供されています。

https://assets.devographics.com/surveys/js<YYYY>/en-US/results.json
https://assets.devographics.com/surveys/css<YYYY>/en-US/results.json

Step 1 — 現在のスタックを棚卸しする

package.json にある主要な依存関係をすべて列挙します。

jq -r '(.dependencies // {}) + (.devDependencies // {}) | keys[]' package.json | sort

対象は、フレームワーク、バンドラー、テストランナー、型チェッカー、リンター、CSS ツール、状態管理、ルーティング、データ取得、アニメーションです。低レベルのユーティリティとポリフィルはレビュー対象から除外します。

Step 2 — State of JS/CSS との対応付け

現在のスタックにある各テクノロジーを、State of JS/CSS の結果から探します。

満足度 × 使用状況マトリクス

                  Low usage        High usage
                ┌────────────────┬────────────────┐
High            │   EMERGING     │    STABLE      │
satisfaction    │  (consider     │  (keep, likely │
                │   adopting)    │   healthy)     │
                ├────────────────┼────────────────┤
Low             │   AVOID        │    LEGACY      │
satisfaction    │  (don't start) │  (plan exit)   │
                └────────────────┴────────────────┘

しきい値（State of JS の調査）：高 ≥ 70％、低 ≤ 55％。55～70％の値は境界領域です。年次推移を確認して判断してください。

STABLE（使用状況が高い + 満足度が高い）：対応は不要です。健全なエコシステムです。

EMERGING（使用状況が低い + 満足度が高い）：採用を検討します。成熟度、エコシステムの充実度、現在の選択肢からの移行コストを確認してください。

LEGACY（使用状況が高い + 満足度が低い）：移行を計画します。使用状況が高いということは、惰性だけが使い続けている理由です。移行先として選ばれているテクノロジーを確認してください。

AVOID（使用状況が低い + 満足度が低い）：新規プロジェクトでの採用は避けてください。すでに使用している場合は、削除を計画します。

追加のシグナル

• 年次推移：満足度は上昇していますか、それとも低下していますか？STABLE で推移が低下している場合、早期の LEGACY シグナルです。
• 継続率と関心度：継続率が高く（ユーザーが使い続けている）、関心度も高い（未使用者が使いたがっている）場合は、有望な選択肢です。
• 「再び使いたくない」の急増：最も強い LEGACY シグナルです。

Step 3 — Technology Radar との対応付け

各項目について Thoughtworks Tech Radar を確認します。リングは次のとおりです。

リング	意味	対応
ADOPT	実績があり、リスクが低く、幅広い利用が推奨される	デフォルトの選択肢として使用する
TRIAL	取り組む価値があり、特定のケースで実績がある	実際のプロジェクトで試し、経験を積む
ASSESS	有望で、影響を調査する価値がある	スパイク／PoC のみ。本番では使用しない
HOLD	注意して進める。新規採用は開始しない	新規プロジェクトでは使用しない。すでに使用している場合は終了を計画する

項目がレーダーに掲載されている場合は、リングと初回掲載日を記録します。2 年以上 HOLD のまま変化がない項目は、積極的な削除の候補です。

レーダーに掲載されていない項目が、必ずしも悪いとは限りません。レーダーはエンタープライズやコンサルティングの課題に偏っており、新興の JS エコシステムツールの動向を 1～2 年遅れて反映するためです。

Step 4 — 相互参照して優先順位を付ける

シグナルを組み合わせ、4 段階の対応優先度を設定します。

優先度	State of JS のシグナル	Tech Radar のシグナル	対応
P0 — 今すぐ移行	LEGACY	HOLD	今回のスプリントで移行 PR を作成する
P1 — 移行を計画	LEGACY または低下傾向	ASSESS または HOLD	次の四半期に予定する
P2 — 監視	継続率が低下	レーダーに掲載なし	次の年次サイクルで監視する
P3 — 対応不要	STABLE	ADOPT または TRIAL	現状を維持する

新たに EMERGING となったテクノロジーには、現在のツールが P0/P1 でない限り移行しないでください。強いられない限り、切り替えコストがわずかな改善効果を上回ります。

Step 5 — 移行候補を評価する

P0/P1 の各項目について、次を見積もります。

1. 移行工数：使用箇所を grep で数え、必要な時間を見積もる
2. 移行先の候補：State of JS の「movers」は何に移行しましたか？
3. 併用期間：移行中に旧バージョンと新バージョンを並行して実行できますか？
4. リスク：ランタイムに影響するか（高リスク）、それともビルドツールのみか（低リスク）？

評価テンプレートの例：

### jest → vitest

- Current usage: 47 test files (grep -r "from 'jest'" src/)
- State of JS signal: LEGACY (satisfaction dropped from 85% → 61% 2021→2024)
- Tech Radar: HOLD (Vol.30)
- Target: vitest (STABLE, Tech Radar ADOPT Vol.31)
- Effort: ~4h (config migration + minor API diffs, @testing-library compatible)
- Coexistence: no (different config, but can migrate per-file)
- Risk: build tooling only → low
- Recommendation: migrate in one PR

Step 6 — 出力

次の内容を含むレビュー文書を作成します。

## Tech Watch — <YYYY-QN>

### Data source versions
- State of JS: <year>
- State of CSS: <year>
- Tech Radar: Vol.<N> (<date>)

### Stack health summary
| Technology | Category | Signal | Priority | Notes |
|---|---|---|---|---|
| vitest | test runner | STABLE / ADOPT | P3 | — |
| tailwindcss | CSS | STABLE / ADOPT | P3 | v4 migration due |
| jest | test runner | LEGACY / HOLD | P0 | migrate to vitest |
| ... | | | | |

### P0 — Migrate now
- [ ] <package>: <brief rationale> → <target>

### P1 — Plan migration (next quarter)
- [ ] <package>: <brief rationale>

### P2 — Watch (next annual cycle)
- <package>: <signal to monitor>

### Newly emerged (consider adopting)
- <technology>: EMERGING, TRIAL — evaluate for <use case>

実施頻度

• 年次：State of JS/CSS のリリースに合わせて、全体レビューを実施します（通常は11月～1月）。
• 四半期ごと：Tech Radar の新しい版を確認し、既存のスタック項目に変更がないかを確認します。
• 随時（新規採用）：既存の候補がない新しいライブラリの追加を検討する場合は、ステップ3（Radar のみ）を実施します。
• 随時（置き換えの判断）：現行ツールと候補ツールの両方について、ステップ2～5を実施します。ステップ1のスタック一覧とステップ6の全体出力ドキュメントは省略し、代わりに単一の移行評価を作成します。「X から Y に切り替えるべきか？」「Y を追加するか、X を使い続けるか？」のように、既存の候補がある場合はこの方法を使います。

範囲

• このスキルの対象は戦略的な判断であり、実装ではありません。更新を実行する場合は、dep-lib-review を使用してください。
• Tech Radar だけを使わないでください。JS エコシステムの動向への反映が遅れるため、必ず State of JS/CSS と照らし合わせてください。
• 「誰もが X に移行している」は、移行の十分な理由にはなりません。移行コストと、現行ツールで実際に生じている問題を評価してください。

関連項目

• dep-lib-review — 実際の更新を実行します（パッチ／マイナー／メジャー単位でまとめて適用）
• frontend-review-deps — CVE のトリアージと傾向監視スクリプトを用いた、運用上の依存関係監査