Technical Roadmaps

1人のプロダクトリーダーからのフレームワークと知見を活用して、ユーザーが効果的なテクニカルロードマップを作成するのを支援します。

How to Help

ユーザーがテクニカルロードマップについてのヘルプを求めてきた場合：

1. コンテキストを理解する - 現在のテクニカル状態、チームサイズ、ビジネス上の制約について質問する
2. ドキュメント化を確認する - 戦略が文書化されていないと、デバッグやアラインメントができない
3. Rumelt フレームワークを適用する - 診断（何が問題か）、ガイディングポリシー（判断の原則）、アクション（何をするか）として構造化する
4. 地味な戦略を優先する - 既存のツールで十分な場合に新しいツールを導入したい衝動に抵抗するのを支援する

Core Principles

Write it down

Will Larson: "戦略の第一法則は、書き下ろせば改善できるということです。書き下ろされていないと、このPMが単に優秀でないのか、それとも誤解した戦略を適用しようとしているのか判断するのは困難です。" 文書化された戦略は、批判と改善の対象となるベースラインを提供します。

Boring strategies often win

Will Larson: "本当に優れているが非常に退屈な一般的な戦略は、今日持っているツールだけを使うというものです。エンジニアは新しいプログラミング言語、新しいデータベース、新しいクラウドプロバイダーを導入したいと思っています。ほぼすべての企業にとって本当に優れた戦略は、既に持っている標準的なキットを使うことです。" エンジニアリングのエネルギーをテクニカルな新規性ではなく、ビジネス価値のある問題に向けることに焦点を当てます。

Use the Rumelt framework

Richard Rumelt のフレームワークを使用してテクニカル戦略を構造化します：診断（中核的なチャレンジは何か）、ガイディングポリシー（どのような原則が判断を導くか）、アクション（何をするか）。

Create a standard kit

承認されたツール、言語、プラットフォームのリストを定義します。これはテクニカルな拡散を制限し、インフラストラクチャを再発明するのではなく、チームが中核的なプロダクト問題の解決に焦点を当てることを可能にします。

Questions to Help Users

• "このテクニカル戦略は、誰もが参照できるどこかに文書化されていますか？"
• "解決しようとしている中核的なテクニカルチャレンジは何ですか（診断）？"
• "あなたのテクニカル判断を導く原則は何ですか（ガイディングポリシー）？"
• "必要だから新しいツールを追加していますか、それとも興味深いからですか？"
• "承認されたテクノロジーの『標準的なキット』はどのような構成ですか？"
• "このテクニカルロードマップはビジネス成果とどのようにつながっていますか？"

Common Mistakes to Flag

• Unwritten strategy - 誰かの頭の中にしか存在しない戦略はデバッグできず、アラインメントもできません
• Tool proliferation - 既存のもので対応できるのに新しいテクノロジーを導入すると、メンテナンス負担が増加します
• No connection to business value - プロダクトやビジネスの成果に結びつかないテクニカルロードマップは正当性がありません
• All diagnosis, no action - 優れた戦略には、問題の分析だけでなく具体的なアクションが必要です
• Missing guiding policies - 原則なしでは、すべてのテクニカル判断が一からの議論になります

Deep Dive

1人のゲストからのすべての2つの知見については、references/guest-insights.md を参照してください

Related Skills

• Managing Tech Debt
• Platform Strategy
• Engineering Culture
• Prioritizing Roadmap