altitude-horizon-framework について
PMからプロダクトDirectorへの移行を支援するリファレンスフレームワークです。視野の広さと時間軸で課題を診断し、戦略をチームの優先事項に落とし込む方法を示します。
主な機能
- 01役割移行を捉える二軸モデル
- 02四つの移行領域
- 03Directorに多い失敗の診断
- 04六段階のコンテキスト展開
- 05PMと新任Director向けの指針
活用シーン
- 01PMからDirectorへの移行で課題を特定
- 02曖昧な会社戦略をチームの責任に翻訳
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ deanpeters/ product-manager-skills --skill altitude-horizon-frameworkインストール後、Claude Code で/altitude-horizon-frameworkを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
template.mdexamples/sample-industrial.mdsample.md詳細
目的
Director レベルの思考と PM の思考を区別する、2 つの軸からなるメンタルモデルを定義します。高度(どれだけ広い範囲を俯瞰するか)と時間軸(どれだけ先まで見通すか)です。これを使って、役割の移行で実際に何が変わるのかを理解し、どの移行ゾーンが摩擦を生んでいるのかを診断し、組織の方向性が曖昧または存在しない場合に、カスケード型コンテキストマップを適用します。
これは、職位の上下関係を示すものではありません。自分の役割に適した高度で業務を行う PM は、優れた仕事をしています。PM の高度で業務を行う Director は、本来の職務を果たせていません。
入力
必須の入力はありません — 最初から最後まで読めるリファレンスフレームワークです。 あると役立つ情報: 現在の状況(役割、移行に伴って感じている摩擦、検討中の意思決定)。それがあれば、フレームワークを直接適用して、どの移行ゾーンにいるのかを診断できます。
スキル名の後に続くテキスト、貼り付けられたコンテキストのダンプ、追記された ARGUMENTS: 行など、呼び出し時に渡された情報は、すでに回答済みの内容として扱います。それを活用し、該当する内容については質問し直さないでください。
何も入力せずに始めても大丈夫です。 メンタルモデルとして読み、ガイド付きのコーチングには director-readiness-advisor を併用してください。
呼び出し例: Apply the altitude-horizon framework to my situation: senior PM, just inherited two more teams, drowning in delivery detail.
主な概念
2 つの軸
高度 — 範囲
- PM の高度: 現場に近い視点です。顧客の課題、個々の機能、スプリントの優先順位、特定のチームの力学を扱います。
- Director の高度: 高い視点です。製品ポートフォリオ、部門横断のシステム、組織の力学、予算配分、市場での位置付けを扱います。
- この変化は、顧客への共感を失うことではありません。1 つのテーブルだけでなく、レストラン全体を見渡すために視点を引き上げることです。
時間軸 — 時間
- PM の時間軸: 日、週、スプリントです。長くても四半期までです。
- Director の時間軸: 四半期を起点とします。年間計画サイクル、複数年の戦略、市場の変化を扱います。
- Director は、製品エコシステムが 1 年後にどうあるべきかを計画し、そこから逆算して取り組みます。
ウェイターとレストラン運営者
役割の変化を表す、最も的確なたとえです。
| 観点 | PM(ウェイター) | Director(レストラン運営者) |
|---|---|---|
| 焦点 | 個々の食事客の体験 | 人員配置、利益率、メニュー、仕入先を含むシステム全体 |
| 権限 | 決定権を持たずに影響を与える | ポートフォリオの意思決定、予算、リソース配分 |
| 成功の指標 | 7 番テーブルの客が満足している | レストランの収益性、一貫性、拡張性が保たれている |
| 顧客との関係 | 直接的で、日々の、親密な関係 | 集約された傾向、購買者ペルソナ、市場コホート |
| 失敗のパターン | 7 番テーブルのニーズを無視する | 7 番テーブルのレモンにこだわりすぎる |
ウェイターは、個々の食事客の体験を的確に伝えることに長けています。運営者も食事客を無視しているわけではありません。異なる問いを立てているのです。「食材にお金をかけすぎていないか」「75 ページのメニューで客を困惑させていないか」「夕食時の混雑に備えて、もう 1 人サーバーを増やす必要はないか」。どちらの問いが絶対的に重要というわけではありません。それぞれ異なる役割に適した問いです。
4つの移行領域
PM から Director への移行には、4つの領域を越える必要があります。ほとんどの人は、他の領域よりも1つか2つの領域で苦労します。どの領域が最も大きな変化につながるポイントなのかを見極めることが重要です。
領域1 — 思考の高度
- やめること:個々の顧客の問題を直接解決する
- 始めること:さまざまな種類の問題を解決するシステムやチームを設計する
領域2 — ペルソナの転換
- やめること:個々のユーザーペルソナや日々の顧客との接点にこだわる
- 始めること:購買者のペルソナ、市場のコホート、組織内のステークホルダー、経営層の力学を考える
領域3 — ヒーロー症候群からの回復
- やめること:窮地を救い、称賛を受ける人でいる
- 始めること:チームの成功に満足感を得る。あなたのプロダクトはロードマップではなく、チームメンバーです
領域4 — 方向性の創出
- やめること:動き出す前に上層部から明確な指示が出るのを待つ
- 始めること:インプットが不完全でも、会社の戦略をチームが明確に理解できるように、文脈を段階的に伝える
よくある失敗パターン
ヒーロー症候群 どのような状態か:自ら問題解決に乗り出す。実務に深く関わり続ける。個人の成果を周囲に知ってもらいたがる。 なぜ起きるのか:PM は人の役に立ち、迅速に対応するよう訓練されています。Director になると称賛される機会が減るため、以前の報酬サイクルに戻ってしまいます。 代償:シニア IC として過剰に機能する一方で、Director として十分な成果を出せなくなります。チームの成長を妨げてしまいます。
プロセスへの拒否反応 どのような状態か:共通の仕組みに抵抗する。実績のある PM に、それぞれ独自の進め方で仕事をさせる。 なぜ起きるのか:PM は本質的に官僚主義を嫌います。Director になりたての頃は、寛容に任せることが「素晴らしいリーダーシップ」や「チームへの信頼」に思えることがあります。 代償:マーケティング、財務、経営陣のステークホルダーが、ばらばらの成果物をまとめられなくなります。共通のプロセスがなければ、チームは「部屋の中でガラスを割りまわるサル」になってしまいます。
人に好かれようとするリーダーシップ どのような状態か:チームに好かれたいと思う。厳しいフィードバックを避ける。関係を保つために、ステークホルダーの要望に応じる。 なぜ起きるのか:優れた PM になるために役立った傾聴力、共感力、対応力が、組織規模では足かせになります。 代償:「好かれること」と「効果を上げること」を混同します。尊敬は、優しさではなく、明確さと厳しい決断によって築かれます。
即効性を求める罠 どのような状態か:リーダーシップの本を読み、資格を集め、「昇進するには何をすればよいのか」と尋ねる。 なぜ起きるのか:PM は最適化を得意としています。必要な経験を近道で得ようとします。 代償:Director としての準備には、実体験に基づく苦労話と、経験を通じて培った謙虚さが必要です。用語を使いこなせるようになるまで学ぶことはできますが、役割を担う準備が整うわけではありません。
白黒思考 どのような状態か:「これは明らかな決断に思える」「なぜ両方に資金を出せないのか」「なぜここでは何でも政治的なのか」と考える。 なぜ起きるのか:PM は、因果関係が明確で、より整理された問題領域で仕事をします。Director の意思決定には、相反する制約、限られた情報、組織内の力学が関わります。 代償:確信が持てないまま急いで決断すると、後々混乱を招きます。グレーゾーンがあるのはリーダーシップの失敗ではなく、実際の地形そのものです。
カスケード型コンテキストマップ
組織の方針が曖昧、または存在しない場合、ディレクターは待ちません。上から下へとカスケードします。
6つのステップ:
- トップレベルの戦略に耳を傾ける — QBR、会社からのメッセージ、経営陣からのコミュニケーション
- 経営陣が示した重要な優先事項を抽出する — 20個の箇条書きではなく、3~5個のテーマを特定します
- 第2層をマッピングする:「事業部門として、これらの目標をどのように達成するのか?」
- 第3層をマッピングする:「製品ポートフォリオとして、それをどのように実現するのか?」
- 第4層をマッピングする:「第3層での成功につながる、チーム固有の責任は何か?」
- カスケードをチームに伝える — 何をすべきかだけでなく、それが上位の目標とどう結び付くかも伝えます
**解決できること:**チームが「荒野をさまよう」状態、つまり、コンテキストがチーム向けに翻訳されていないために、戦略につながらない仕事をリリースしてしまう状況です。
**中核となる原則:**上層からの方針が不完全でも、ディレクターの仕事は、その不足を下層に向けて埋めることです。完璧に明確になるまで待つのは PM の習慣です。不完全でも役立つ明確さを生み出すのが、ディレクターのスキルです。
適用
PM としてこのフレームワークを使う(移行前)
- 自分が最も苦手とする移行ゾーンを特定します。今すぐ行動に移すためではなく、何を観察すべきかを知るためです
- マネージャーとの1対1でゾーン4を練習します。「自分の仕事はビジネス戦略とどうつながっていますか?自分が見落としている組織的なコンテキストは何ですか?」
- 今のうちにヒーロー症候群の傾向に注意します。他の人がコーチングを受けて解決できる問題に、自分から飛び込んで解決していませんか?
- まだ PM の役割にいる間は、ディレクターの視点に過度に注力しないでください。現在の担当範囲に全力で取り組みましょう。ディレクターの視座が必要になるのは、その状況が求めるときです
昇進したばかりのディレクターとしてこのフレームワークを使う
- **最初の30日:**新しい「視座と時間軸」のマップを作成します。新しいステークホルダーは誰ですか?この組織における四半期から年単位の計画期間とは、実際にはどのようなものですか?
- **最初の60日:**自分のヒーロー症候群の引き金を特定します。コーチングする代わりに、直接介入したくなるのはどんなときですか?
- **最初の90日:**初めてのカスケード型コンテキストマップを作成します。会社の戦略が明確でなくても、最善の解釈をまとめてチームと共有します
- **継続的に:**摩擦が生じたら、どの移行ゾーンにあるのかを明示します。処方より先に診断を行います
カスケード型コンテキストマップの作成
組織の戦略が自分たちの仕事にどう関わるのか、チームが把握できていないときに使用します。
## Context Cascade
**Company Priority:** [What leadership said — in their words]
**Business Unit Translation:** [How your BU contributes to that priority]
**Product Portfolio Translation:** [How your products contribute to that]
**Team Accountabilities:** [What each team owns specifically]
**Why this matters:** [The so-what for your team — what changes, what stays the same]
10ページより1ページのほうが優れています。目標は網羅性ではなく、明確さです。
例
完成したカスケード型コンテキストマップとアンチパターンの対比を含む、詳しいシナリオについては examples/sample.md を参照してください。
良い例:ディレクターが曖昧な会社の優先事項から明確さを生み出す
**状況:**CEO が QBR で「エンタープライズ分野への注力をさらに強化します」と発表します。3人の PM がディレクターに「それはロードマップにとってどういう意味ですか?」と尋ねます。
PM の対応(誤った視座):「スプリントのバックログにエンタープライズ向け機能を追加しましょう。」
**ディレクターの対応(適切な視座):**カスケード型コンテキストマップを作成します。次のように翻訳します。「エンタープライズとは、より大きな案件規模、より長い営業サイクル、そしてより多くの統合要件を意味します。ポートフォリオでは、製品Aが管理者向けコントロールを、製品BがAPIドキュメントを、製品Cがセキュリティ認証を担当します。第3四半期の計画で変わることと変わらないことは、以下のとおりです。」
**効果がある理由:**ディレクターは、さらなる明確さが得られるまで待ちませんでした。得られた情報をもとに、自ら明確さを生み出しました。
悪い例: ヒーロー症候群の実例
状況: チームのある PM が、難しいステークホルダーとの関係に苦戦しています。
ディレクターの対応(誤り): 「私が直接そのステークホルダーと話そう。私が何とかするよ」
ディレクターの対応(正しい): 「これまで何を試したか聞かせて。どこでうまくいかなくなったのか、そして次は何を変えてやるのかを一緒に考えよう」
なぜ重要か: 最初の対応は問題を解決しますが、依存を生みます。2 つ目の対応は PM を成長させます。 rescue を繰り返すディレクターは、自分がいなければ機能しないチームを作ってしまいます。
良い例: ウェイターからオペレーターへの転換
状況: 優秀な PM が、「自分のステークホルダーはこの形式を好むから」という理由で、チームの他のメンバーとは異なる形式で要件を文書化することに固執しています。
ディレクターの対応(誤り): 「それでいいよ、彼女はうちで一番の PM だから。彼女のチームでうまくいっているなら、そのままにしておこう」
ディレクターの対応(正しい): 「Joe は個人としては素晴らしい成果を出している。でもマーケティングが 3 人の PM の仕事を横断して統合しようとすると、それができない。共有されたプロセスは官僚主義ではない。それはシステムを外部の全員にとって理解可能にするものだ」
なぜ重要か: ハイパフォーマーの例外を守ることは、目に見えない調整コストを生みます。レストランオペレーターの仕事はシステムであり、スターのウェイターではありません。
よくある落とし穴
落とし穴 1: 高度の見せかけ
症状: スプリントレベルの意思決定をしながら、戦略の言葉(「ポートフォリオ」「エコシステム」「長期ビジョン」)を使う
結果: ディレクターのように聞こえても、PM のように機能してしまいます。チームは誰が実際に決定し、どのレベルで決定しているのか混乱します。
修正: 詳細に関与しているなら、それを認めましょう。関与していないなら、完全に委任しましょう。シグナルを送らずに高度のレベルを混ぜると、チームの信頼を損なう曖昧さを生みます。
落とし穴 2: 一度きりのコンテキストカスケード
症状: 年次計画でカスケーディングコンテキストマップを一度実行し、その後二度と見直さない
結果: チームは第 1 四半期に整合しますが、戦略の進化とともにずれていきます。第 3 四半期には、チームの仕事は現在の優先事項から切り離されています。
修正: 主要な転換点 — 四半期計画、重要な役員の変更、ピボット、組織再編 — でカスケードを見直しましょう。
落とし穴 3: 優しさとリーダーシップの混同
症状: チームを難しい決断から守る、自分が抱えている制約を過剰に説明する、フィードバックを意味のないほど和らげる
結果: チームは正確なコンテキストなしで活動し、現実が警告なしに訪れたときに信頼が損なわれます。
修正: 難しい決断の背後にある「なぜ」について透明になりましょう。すべてを共有する必要はありません — ただし、共有するものは正直で実行可能であるべきです。
落とし穴 4: PM としての早すぎるディレクター思考
症状: PM の年月をポートフォリオ戦略、組織力学、そして「自分の給与等级を超えた思考」を心配して過ごす
結果: 現在の役割に十分に貢献できません。ディレクターのように考える PM は、実際の役割が要求する顧客レベルのシグナルを見落としがちです。
修正: 現在の役割に全力で取り組みましょう。転換はやがてディレクター思考を要求します — 準備ができるのは、PM の仕事をしっかりやったからであり、ディレクターの役割を早まって練習したからではありません。
参考資料
関連スキル
skills/director-readiness-advisor/SKILL.md— このフレームワークを使用して、あなたの特定の移行状況を診断しコーチングするインタラクティブアドバイザー
ソース資料
- The Product Porch、エピソード 42: From Product Manager to Director: How to Make the Shift (Part 1) — Todd Blaquiere、Ryan Cantwell、Joe Ghali(2026 年 1 月)
外部フレームワーク
- Marty Cagan『Empowered』— プロダクトリーダーシップにおける組織力学と役割の明確さ
- Julie Zhuo『The Making of a Manager』— IC からマネージャーへの移行と実践的な体験談
- Michael Watkins『The First 90 Days』— リーダーシップ移行への構造化されたアプローチ