ストーリー
田
田中VPoE
標準を「生き物」として維持するための進化サイクル、メトリクス、非推奨化プロセスを学んだ。最後にこれらを統合して、TaskFlow社の進化サイクルを設計してもらう
あなた
具体的に何を設計するんですか？
あ
田
田中VPoE
3つだ。年間の進化サイクルカレンダー、メトリクスダッシュボードの設計、そしてVue.js 2の非推奨化計画だ。TaskFlow社が実際に使える運用設計をしてくれ
ミッション概要
| 項目 | 内容 |
|---|---|
| 演習タイトル | 進化サイクル設計 |
| 想定時間 | 60分 |
| 成果物 | 進化サイクルカレンダー + メトリクスダッシュボード設計 + 非推奨化計画 |
| 対象組織 | TaskFlow株式会社 |
Mission 1: 年間進化サイクルカレンダーを設計する
要件
TaskFlow社の技術標準の年間進化サイクルを設計してください。
- 四半期ごとのレビューアジェンダ（参加者、議題、成果物）
- 月次・週次の定期活動
- 年間の主要マイルストーン
解答例
年間カレンダー
| 月 | 活動 | 責任者 |
|---|---|---|
| 1月 | Q4振り返り + Q1計画、テクノロジーレーダー更新 | 技術標準委員会 |
| 2月 | メトリクスレビュー、フィードバック分析 | 事務局 |
| 3月 | 標準改定RFC議論 | 全エンジニア |
| 4月 | Q1振り返り + Q2計画、テクノロジーレーダー更新 | 技術標準委員会 |
| 5月 | エンジニア満足度アンケート実施 | 事務局 |
| 6月 | 半期レポート（経営層報告） | VPoE |
| 7月 | Q2振り返り + Q3計画、テクノロジーレーダー更新 | 技術標準委員会 |
| 8月 | 年間ADRレトロスペクティブ | 技術標準委員会 |
| 9月 | 標準バージョンアップ（メジャー/マイナー） | 事務局 |
| 10月 | Q3振り返り + Q4計画、テクノロジーレーダー更新 | 技術標準委員会 |
| 11月 | エンジニア満足度アンケート（2回目） | 事務局 |
| 12月 | 年間レポート、次年度計画 | VPoE |
週次・月次活動
| 頻度 | 活動 |
|---|---|
| 週次 | テックトーク（隔週）、メトリクスモニタリング |
| 月次 | コードレビュー勉強会、RFCレビュー会 |
Mission 2: メトリクスダッシュボードを設計する
要件
TaskFlow社の技術標準メトリクスダッシュボードを設計してください。
- トップレベル指標（経営層が見るサマリー）
- 詳細指標（技術標準委員会が見る運用指標）
- 各指標のデータソースと測定方法
解答例
トップレベル指標
| 指標 | 現在値 | 目標値 | 傾向 |
|---|---|---|---|
| 標準準拠率 | 78% | 90% | 改善中 |
| DORA成熟度 | Low | Medium | 改善中 |
| エンジニア満足度 | 3.6/5.0 | 4.0/5.0 | 横ばい |
| 本番障害件数（月平均） | 4.2件 | 2.0件以下 | 改善中 |
詳細指標
| カテゴリ | 指標 | データソース |
|---|---|---|
| 準拠率 | 品質ゲート通過率 | GitHub Actions |
| 準拠率 | Hold技術使用サービス数 | テクノロジーレーダー管理ツール |
| 開発効率 | デプロイ頻度 | GitHub Actions |
| 開発効率 | PR マージまでの時間 | GitHub API |
| 品質 | テストカバレッジ平均 | Codecov / CI レポート |
| 品質 | Critical CVE数 | Trivy / Snyk |
| DX | RFC提出件数 | RFC リポジトリ |
| DX | オンボーディング完了日数 | 人事システム + Gitログ |
Mission 3: Vue.js 2の非推奨化計画を策定する
前提
TaskFlow社のAdmin画面（管理ツール）がVue.js 2で構築されています。Vue.js 2はサポート終了しており、Reactへの移行を計画しています。
| 項目 | 現状 |
|---|---|
| 対象サービス | Admin画面（管理ツール） |
| コード規模 | 約30,000行 |
| 使用チーム | Webフロントチーム（25名のうち5名がAdmin担当） |
| ユーザー | 社内の管理者約50名 |
| 重要度 | 中（社内ツールだが業務に不可欠） |
要件
- 非推奨化通知ドキュメント
- 移行タイムライン（フェーズ分け）
- 移行アプローチの選定と理由
解答例
移行アプローチ: Strangler Fig
理由: Admin画面は稼働中のため一気に移行するのはリスクが高い。画面単位でReactに段階的に移行する。
タイムライン
| フェーズ | 期間 | 内容 |
|---|---|---|
| 告知 | Month 0 | 非推奨通知、移行ガイド公開 |
| Phase 1 | Month 1-3 | 共通基盤（ルーティング、認証）のReact化。新規画面はReactで開発 |
| Phase 2 | Month 4-6 | 主要画面（ダッシュボード、ユーザー管理）のReact移行 |
| Phase 3 | Month 7-9 | 残りの画面のReact移行 |
| 最終警告 | Month 10 | 未移行画面の最終確認 |
| 廃止 | Month 12 | Vue.js 2コードの完全削除 |
リソース
- 専任: 2名（フルタイム）
- Admin担当: 5名（通常業務と並行、20%の工数を移行に充当）
- 推定工数: 約8人月
達成度チェック
| 観点 | 達成基準 |
|---|---|
| カレンダーの網羅性 | 四半期レビュー、月次活動、年間マイルストーンが含まれている |
| メトリクスの妥当性 | 4カテゴリ（準拠率、効率、品質、DX）をカバーしている |
| データソース | 各指標のデータ取得方法が明確 |
| 非推奨化の責任 | 移行先、移行支援、十分な期間が提示されている |
| 段階的アプローチ | 一度にすべてを変えない段階的な計画 |
推定所要時間: 60分