はじめに
四半期ロードマップを作るとき、こういうことが起きていないだろうか。技術的負債の優先順位が特定のシニアエンジニアの感覚に依存している。「これは重要な投資だ」と経営層に説明しようとするが、定量的な根拠が薄い。承認されたロードマップが実際の開発と乖離して形骸化する。
Claude Codeを「コードを書くツール」だと思っていると、ロードマップ策定での活用は思いつかない。実際に使ってみて効いたのは、コードベースからのボトムアップ分析、優先順位フレームワークの適用、経営層向け説明文書の生成の3点だった。
3軸のアプローチ：技術戦略立案をどう変えるか
軸1：コードベースからのボトムアップ分析
「なんとなく古い」という印象論ではなく、変更コストと影響範囲に基づいた候補リストをClaude Codeに出させる。
現在のコードベースを分析して、技術的負債の集中している領域を特定してください。
依存関係の複雑さ、テストカバレッジの低さ、変更頻度と障害率の相関を含め、
次四半期のロードマップ候補をリストアップしてください。
コードベース全体を読み込んだClaude Codeが、感覚論ではなく証拠ベースで候補を洗い出す。「どこから手をつければいいか」の判断を個人の経験則から解放できる。なお技術的負債のビジネス言語への翻訳については、別記事「Claude Code × 技術的負債」で詳しく扱っている。
軸2：優先順位付けフレームワークの自動適用
mcpmarket.comで提供されているRoadmap Management skillを使うと、RICE・MoSCoW・Now-Next-Laterなどのフレームワークを自動適用できる。
RICEスコアはReach（影響ユーザー数）×Impact（影響度）×Confidence（確信度）÷Effort（工数）で計算される。Claude Codeに各施策の要素を入力させてスコアリングテーブルを生成させることで、「これは優先度が高い気がする」という直感をデータに変換できる。
GitHub: deanpetersのProduct-Manager-Skillsは47以上のPMスキルを提供しており、Geoffrey Moore・Jeff Patton・Teresa Torresらの手法を参照した戦略立案支援も可能だ。
軸3：経営層向け説明文書の生成
技術ロードマップを経営層が承認しやすい形式に変換することもClaude Codeの強みだ。
この技術ロードマップを経営層に説明するための資料を作成してください。
各施策の投資対効果（ROI）・実施しない場合のリスク・四半期ごとのマイルストーンを含めてください。
「なぜ今この投資が必要か」を事業言語で語れる文書が生成される。技術者の頭の中にある判断を、意思決定者に伝わる形に変換するコストが大幅に下がる。
計画と実行の分離：ロードマップを「書面」として扱う
Claude CodeにはPlan Modeという計画専用モードがあるが（詳細は別記事）、ロードマップ策定においても同じ原則が重要だ。分析・計画フェーズと実装フェーズを明確に切り分ける。
1. `plan.md`を先行作成：技術的調査結果・候補施策・リスクを記載
2. ステークホルダーレビュー：Claude Codeが生成した分析を人間がレビュー・修正
3. 承認後に実装フェーズへ移行
ロードマップ文書を「承認前は変更可能な草稿」として扱い、承認後に実装指示へ変換する流れを整備することで、ロードマップと実際の開発の乖離を防げる。
プロトタイプ駆動：「3ヶ月後に」ではなく「今日の午後に」
技術ロードマップの落とし穴のひとつは、「書類だけで終わる」ことだ。経営層への説明で何が一番効くかというと、「今日の午後に動くものを見せる」だった。
Claude Codeを使ったプロトタイプ駆動開発では、検討中の技術施策について数時間で動くものを生成し、実際の動作を見せながら投資判断を促す。「3ヶ月後に出来上がったものを見せる」から「今日の午後に動くものを見せて意思決定する」スタイルへの転換だ。
6段階ゲート審査：承認プロセスを構造化する
複数チームを持つ組織では、ロードマップ承認が非構造的になりがちだ。ゲートレビュー方式のフレームワークとして、以下の6段階構造が有効だ。
| ゲート | フェーズ | Claude Codeの役割 |
|---|---|---|
| Gate 0 | 技術実現可能性の評価 | 技術スタックとの整合性チェック |
| Gate 1 | スコープ定義 | 要件の明確化・境界線の設定 |
| Gate 2 | リスク評価 | 依存関係・セキュリティリスクの洗い出し |
| Gate 3 | 工数見積もり | コード量・複雑性からの見積もり支援 |
| Gate 4 | ステークホルダー承認 | 経営層向け説明文書の生成 |
| Gate 5 | 最終リリース承認 | チェックリスト・ドキュメント整備 |
各ゲートで「通過条件」を定義し、CLAUDE.mdに記載しておくことで、チーム全体で一貫したプロセスを維持できる。
参考：Claude Codeの開発速度
Anthropicは社内でもClaude Codeを活用しており、1エンジニアあたり1日10〜30件のPRを処理する体制を実現しているという報告がある（参考値）。また2026年初頭時点で、Claude Codeは全世界のGitHubコミットの相当部分に関与しているとされる。benenewton.comの「Claude Code is More Than a Dev Assistant—It's My Project Manager」では、技術的優先順位の整理から経営層との調整までを担わせる実践が紹介されている。
限界を把握した上で使う
Claude Codeは現在のコードベースを読めるが、将来のビジネス状況は予測できない。市場変化・採用計画・資金状況は人間が補完する必要がある。生成される工数見積もりは参考値として扱い、エンジニアによる検証が必須だ。「なぜこの技術を選んだか」という歴史的経緯はClaude Codeには伝わらないため、ADRやCLAUDE.mdで補完する（この点については別記事「Claude Code × ADR」で詳しく扱っている）。
AIの出力はあくまで叩き台で、最終的な意思決定は人間がする——これを崩さなければ、ロードマップ策定でのClaude Code活用はかなり使えると感じている。
まとめ
今週から始める3ステップを提案する。
ステップ1（30分）：Claude Codeに「このリポジトリで最も変更コストが高い領域はどこか。次四半期で対処すべき技術的課題を5つリストアップして」と依頼する。感覚論とは異なる根拠ベースの候補リストを体験できる。
ステップ2（1〜2時間）：候補施策をリストアップし、Claude CodeにRICEスコアを試算させる。上位3施策をロードマップの核心に据える。
ステップ3（30分）：技術ロードマップの内容をClaude Codeに渡し「経営層向け・ビジネス言語で」という制約で説明文書を生成する。次回の経営会議で使ってみる。
コメント