planning-cadence

計画サイクルの最適化

構造化された階層的な計画の定例行事を通じて、長期的な戦略と短期的な実行を連携させます。

Lenny's Podcast と Newsletter に登場した13人のゲストや投稿から得られた知見を活用し、ユーザーの計画サイクル最適化を支援します。

支援方法

1. サイクルの監査 - 現在の計画頻度が、会社の規模や市場の変動性に合っているかを評価します。
2. 詳細度の設計 - どの期間について詳細なプロジェクト情報が必要か、どの期間は高レベルの戦略テーマにとどめるべきかを判断します。
3. フレームワークの選択 - 組織でトップダウンとボトムアップのどちらの意見を重視するかに基づいて、W型、M型、またはローリング型のサイクルを選びます。
4. 定例行事の改善 - 四半期目標と、指標を動かすために必要な直近の行動との隔たりを埋めるため、週次のチェックポイントを導入します。

基本原則

定例行事より戦略を優先

Shreyas Doshi Live：「興味深いことに、本物のプロダクト戦略があったからこそ、という発見がありました。よくある形だけのものではなく、全員との合意が取れた本物のプロダクト戦略です。それがあったおかげで、Stripeのこの主要プロダクトの計画には、たった3日しかかかりませんでした。」

効率的な計画は、官僚的な定例行事をこなすことではなく、事前に関係者の合意を得た本物のプロダクト戦略から生まれます。

締め切りより毎週の勢いを重視

Christina Wodtke：「『目標に近づくために、今週何をしていますか？』と聞くでしょう。その質問に答えられるなら、OKRの仕組みはすべて手放してもかまいません。ただ、『戦略目標や長期目標に近づくために、今週何をしていますか？』と尋ねるだけで、それがまさに本質なのです……」

遠い締め切りではなく、今週必要な具体的な行動に焦点を移し、現在のタスクが戦略目標に向かうものになるようにします。

ばらつきを減らすために標準化

Eeke de Milliano：「プロセスとは、定義上、ばらつきを減らすものです。組織内のばらつきが大きすぎると懸念するからこそ、プロセスを導入します。人々に一定の基準を満たしてほしいのです。その代償はもちろん、基準を下げて人々を平均まで引き上げる一方で、ほかの人々も平均まで引き下げてしまうことです。」

許容できない基準のばらつきを減らすことに的を絞ってプロセスを導入し、高い成果を上げる人々に不要な摩擦が生じないようにします。

厳格なタイムボックスを設ける

Jason Fried：「私たちは、常に2人でプロダクトを作ります。Basecampでも、HEYでも、あるいは何であれ、私たちが作るものの各機能に取り組むのは2人です。プログラマー1人とデザイナー1人で、取り組んでいる機能を完成させるまでの期間は最長6週間です。」

開発サイクルを最長6週間に制限し、小規模で自律的なチームを活用することで、肥大化を防ぎ、組織の勢いを維持できます。

ローリングサイクルの柔軟性

Paige Costello：「以前は主に年単位で計画していました。今は6か月ごとに、ローリング方式で12か月先まで計画します。直近の半年は確度が高く、その次の半年は確度が低くなりますが、12か月分の計画を6か月ごとに行うことで、事業の見通しが立ちやすくなり、Go-to-Marketとプロダクトの計画をより適切に連携できるようになります。」

ローリング方式の計画サイクルに移行することで、長期的な連携を維持しながら、新しい情報に柔軟に対応できます。

階層的な計画の詳細度

「How Notion builds product」より：「とはいえ、私たちは大まかに半年ごとに計画を立てますが、2つの四半期では詳細度を変えています。たとえば今年の初めには、Q1についてはロードマップの優先順位を付けながら、すべてのプロジェクトを詳細に挙げるようにし、Q2については、取り組む予定のことを高レベルの箇条書きで示すようにしました。」

直近の四半期については具体的なプロジェクトを詳細に計画し、その次の四半期については柔軟性を保てるよう、高レベルの箇条書きにとどめます。

Big Boulder アラインメント

「Snowflake のプロダクト開発手法」より：「私たちは計画にかなりの時間をかけており、四半期ごとと年次の計画サイクルに沿って、頻繁に計画を立てています。計画の場が6週間以上ないと、メールが機能していないのではないかと冗談を言うこともあります。」

会社全体で足並みをそろえるため、個々のチームの計画がすべて結び付く、少数の大局的な会社の優先事項を定めます。

テンプレートとフレームワーク

• Snowflake の Big Boulders 計画フレームワーク（「Snowflake のプロダクト開発手法」） - 経営陣が毎年6～10個の「大きな岩」を特定し、各プロダクト領域がそれらに結び付けた6ページの年次計画を作成する、全社的なアラインメントのフレームワーク。
• W フレームワーク（「優れた計画プロセスの秘訣 — Airbnb と Eventbrite から学ぶ教訓」） - 年次または四半期計画において、経営陣とチーム間の意見のやり取りを構成する4段階の計画フレームワーク。「W」の形をした r
• 四半期計画の「M」フレームワーク（「Gong のプロダクト開発手法」） - 通常、新たなトップダウンの指針がない場合にプロダクトポッドからボトムアップで始める、「M」の文字の形をした簡略版の四半期計画プロセス。
• 可変粒度による半年ごとの計画（「Notion のプロダクト開発手法」） - 会社全体では半年分を計画しつつ、四半期ごとに詳細度を変える計画アプローチ。
• 週次目標75％（「Perplexity のプロダクト開発手法」） - 各チームメンバーが最優先事項を特定し、週末までにその75％を完了することを目指す、軽量な週次計画のルーティン。期待値を re
• 会社の成長段階に応じた計画サイクルの変化（「Ramp のプロダクト開発手法」） - 会社がプロダクトマーケットフィット以前から複数プロダクトのポートフォリオへと成長するにつれて、計画期間をどのように変化させるか。
• Snowflake の年次プロダクト計画（6ページ文書）（「Snowflake のプロダクト開発手法」） - 各プロダクト領域が、会社レベルの Big Boulders と足並みをそろえるために作成する年次計画文書の構成。
• 確信度の段階を設けたローリング6か月ロードマップ（Varun Parmar） - 時間の経過とともに確信度を下げることで、エンタープライズ顧客への可視性のニーズとチームの機動性のバランスを取るロードマッププロセス。
• 複数の高度で行う計画サイクル（「Figma のプロダクト開発手法」） - Figma の3段階の計画構造：年次の会社の優先事項、半年ごとのチームロードマップ、四半期ごとの調整。

詳細を含む全リストについては、references/artifacts.md を参照してください。

ユーザーの役に立つ質問

• 「現在、チームではどの期間を対象に計画を立てており、その計画をどのくらいの頻度で見直していますか？」
• 「正式な計画プロセスを始める前に、チームが足並みをそろえるための戦略文書はありますか？」
• 「大局的な年次の重点施策と、詳細な四半期のタスクをどのように区別していますか？」
• 「計画プロセスのどの段階で、シニアリーダーと個々のチームが意見を出しますか？」
• 「標準化された計画のルーティンにより動きが遅くなると感じる可能性のある、高い成果を上げるチームにはどう対応していますか？」
• 「新しい市場情報やプロダクトのパフォーマンスデータに基づいて、ロードマップをどのくらいの頻度で調整していますか？」

よくある間違いとして指摘すべきこと

• 戦略のない計画 - 明確で事前に合意された戦略的方針がなければ、ルーティンは形骸化した官僚的な作業になります。
• 固定された年次ロードマップ - 年間計画に厳密に従うと、年の途中で見つかった新たなデータや市場の変化にチームが対応できなくなります。
• 一律の詳細度 - 次の四半期を現在の四半期と同じ詳細度で計画しようとすると、確度の低いタスクに労力を浪費することになります。
• 過度な標準化 - 創造性の高いチームや成果を上げているチームに厳格なプロセスを強いると、生産性が阻害され、組織内の摩擦を招くことがあります。

詳細

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

関連スキル

• ロードマップの優先順位付け
• OKR の目標設定
• 重大な意思決定
• トレードオフの評価