technical-roadmaps

技術ロードマップ

プロダクトリーダー 1 名のフレームワークと知見を活用して、効果的な技術ロードマップを作成できるようユーザーを支援します。

支援の方法

ユーザーから技術ロードマップについて相談された場合：

1. 背景を把握する - 現在の技術状況、チームの規模、ビジネス上の制約について尋ねます
2. 文書化する - 文書化されていない戦略は、問題を特定して調整することができません
3. Rumelt のフレームワークを適用する - 診断（問題は何か）、基本方針（意思決定の原則）、行動（何をするか）の構成にします
4. 堅実な戦略を優先する - 既存のツールで十分な場合に、新しいツールを導入したくなる気持ちを抑えられるよう支援します

基本原則

文書化する

Will Larson：「戦略の第一のルールは、書き留めれば改善できるということです。文書化されていないと、この PM の能力が低いのか、それとも誤解した戦略を適用しようとしているのか、判断が難しくなります。」文書化された戦略は、批評して改善するための基準になります。

堅実な戦略が功を奏すことは多い

Will Larson：「よくある、とても効果的でありながら退屈な戦略の一つは、今あるツールだけを使うことです。エンジニアは新しいプログラミング言語、新しいデータベース、新しいクラウドプロバイダーを導入したがります。ほぼすべての企業にとって非常に有効な戦略は、すでにある標準セットだけを使うことです。」技術的な目新しさではなく、ビジネス価値のある問題にエンジニアリングの力を集中させます。

Rumelt のフレームワークを使う

Richard Rumelt のフレームワークを使って技術戦略を構成します。診断（中核となる課題は何か）、基本方針（意思決定を導く原則は何か）、行動（具体的に何をするか）です。

標準セットを作る

承認済みのツール、言語、プラットフォームのリストを定義します。これにより、技術の乱立を抑え、チームがインフラの再構築ではなく、中核となるプロダクトの課題解決に集中できるようになります。

ユーザーを支援するための質問

• 「この技術戦略は、誰でも参照できる場所に文書化されていますか？」
• 「解決しようとしている中核的な技術課題（診断）は何ですか？」
• 「技術的な意思決定を導く原則（基本方針）は何ですか？」
• 「新しいツールを追加するのは必要だからですか、それとも興味があるからですか？」
• 「承認済みの技術からなる『標準セット』はどのようなものですか？」
• 「この技術ロードマップは、ビジネス上の成果とどのように結びついていますか？」

指摘すべきよくある間違い

• 戦略が文書化されていない - 誰かの頭の中にしかない戦略は、問題を特定して調整することができません
• ツールの乱立 - 既存のツールで対応できるのに新しい技術を導入すると、保守の負担が増えます
• ビジネス価値とのつながりがない - プロダクトやビジネスの成果に結びつかない技術ロードマップには、正当性がありません
• 診断ばかりで行動がない - 優れた戦略には、問題の分析だけでなく、具体的な行動が必要です
• 基本方針がない - 原則がなければ、技術的な意思決定のたびにゼロから議論することになります

詳細

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

関連スキル

• 技術的負債の管理
• プラットフォーム戦略
• エンジニアリング文化
• ロードマップの優先順位付け