LESSON 15分

ストーリー

田
田中VPoE
標準の進化には「追加」だけでなく「削除」も含まれる。古くなった標準や技術を適切に非推奨化し、廃止するプロセスが必要だ
あなた
「この技術はもう使わないでください」と言うだけではダメですか？
あ
田
田中VPoE
それだけでは不十分だ。移行先を明示し、移行期間を設け、移行を支援し、完全に廃止するまでを管理する。これが「責任ある非推奨化」だ

非推奨化のライフサイクル

非推奨化のライフサイクル:

1. 非推奨の告知（Deprecation Notice）
   ├── 対象技術/標準の明示
   ├── 非推奨の理由
   ├── 移行先の提示
   └── 廃止予定日の告知

2. 移行期間（Migration Period）
   ├── 移行ガイドの提供
   ├── 移行支援チームのアサイン
   ├── 進捗のモニタリング
   └── 期間: 最低6ヶ月（規模に応じて延長）

3. 最終警告（Final Warning）
   ├── 廃止1ヶ月前の最終通知
   ├── 未移行チームへの個別フォロー
   └── 例外申請の最終期限

4. 廃止（End of Life）
   ├── CI/CDでのブロック開始
   ├── テクノロジーレーダーから除外
   └── ドキュメントのアーカイブ

非推奨化の判断基準

基準内容例
セキュリティリスクサポート終了による脆弱性の放置Python 3.9のEOL
保守コスト維持にかかるコストが利益を上回るレガシーフレームワークの保守
エコシステムの衰退コミュニティの縮小、更新の停滞Angular.jsの衰退
より良い代替の登場明らかに優れた後継技術があるExpress → NestJS/Hono
組織戦略との不一致言語ポートフォリオの見直し4言語→2言語への統一

非推奨化通知テンプレート

# 非推奨化通知: [対象技術/標準]

## 基本情報

| 項目 | 内容 |
|------|------|
| 対象 | [非推奨となる技術/標準] |
| 非推奨開始日 | YYYY-MM-DD |
| 廃止予定日 | YYYY-MM-DD |
| 移行先 | [推奨される代替技術/標準] |
| 関連ADR | ADR-XXXX |

## 非推奨の理由

[なぜこの技術/標準を非推奨とするか]

## 影響範囲

[影響を受けるサービス、チーム]

## 移行ガイド

[移行の手順、参照すべきドキュメント]

## タイムライン

| 日付 | イベント |
|------|---------|
| YYYY-MM-DD | 非推奨の告知 |
| YYYY-MM-DD | 移行ガイドの公開 |
| YYYY-MM-DD | 最終警告 |
| YYYY-MM-DD | 廃止（CI/CDブロック開始） |

## 問い合わせ先

[移行支援チームの連絡先]

廃止時の注意点

注意点説明
十分な移行期間最低6ヶ月。大規模な場合は12ヶ月以上
移行先の成熟度移行先が十分に安定していることを確認
強制力の段階化Warning → Soft Block → Hard Block と段階的に強制
例外の余地期限までに移行できない場合の例外プロセスを用意
アーカイブの保持非推奨技術のドキュメントは削除せずアーカイブ

「技術の廃止は”終わり”ではなく”進化”だ。古い枝を剪定することで、新しい枝が育つ。ただし剪定には責任が伴う」 — 田中VPoE

まとめ

ポイント内容
ライフサイクル告知→移行期間→最終警告→廃止
判断基準セキュリティリスク、保守コスト、エコシステム衰退、代替の登場
責任移行先の明示、移行支援、十分な移行期間の確保
段階化Warning→Soft Block→Hard Blockの段階的な強制

チェックリスト

  • 非推奨化のライフサイクルを理解した
  • 非推奨化の判断基準を理解した
  • 非推奨化通知テンプレートの構成を理解した
  • 廃止時の注意点を理解した

次のステップへ

次は演習「進化サイクルを設計しよう」に進みます。Step 5で学んだ進化サイクル、メトリクス、非推奨化プロセスを統合した実践演習です。

推定読了時間: 15分