North Star指標の設計と運用

前提 — North Star指標が機能するための条件

North Star指標は、プロダクトが顧客に届けている価値を表しつつ、事業の成果を先行して予測する指標として選びます。売上や契約数のような遅行指標ではなく、そこに至る前の利用行動を捉える点が特徴です。

この指標が機能するには、プロダクトの提供価値がある程度言語化されていることが前提になります。価値がまだ定まっていない探索段階のプロダクトでは、指標を固定するより仮説検証を優先したほうが実務上は妥当なことが多いです。プロダクトの段階ごとに追うべき指標が変わる点はプロダクトライフサイクルと各段階の意思決定でも扱っていますので、自社がどの段階にあるかをまず確認してください。

手順 — North Star指標を選び、入力指標に分解する4つのステップ

1. 提供価値を一文で定義する

「このプロダクトは顧客の何を可能にしているか」を一文で書きます。抽象的な言葉ではなく、顧客が実際に行う行動で表現するのがコツです。

2. 候補指標を洗い出し、条件で絞り込む

候補は複数出して構いませんが、最終的には「顧客の価値実現を反映しているか」「先行指標として機能するか」「チームの施策で動かせるか」「測定・可視化が継続的に可能か」の4条件で絞り込みます。いずれか一つでも満たさない指標は、North Starではなく補助指標として扱ったほうが安全です。

3. North Star指標を入力指標に分解する

選んだ指標を、チームが実際に動かせる複数の入力指標に分解します。分解の粒度が粗いままだと、指標は下がった・上がったという結果しか分からず、次の施策につながりません。

4. ダッシュボード化しレビューの頻度を決める

入力指標まで含めてダッシュボードにまとめ、週次または隔週で確認する場を作ります。経営会議だけで見る数字にとどめてしまうと、現場の意思決定に反映されません。

適用例 — SaaSプロダクトでのNorth Star設計

以下は説明のための例であり、実際の数値やプロダクト名ではありません。あるプロジェクト管理SaaSで、North Star指標を「週次でアクティブなプロジェクト数」と定めたとします。

North Star指標 = 週次アクティブプロジェクト数

入力指標への分解（例）
  有効化ユーザー数（初回のプロジェクト作成まで到達した新規ユーザー）
  × 週次継続率（前週に利用したユーザーのうち当週も利用した割合）
  × ユーザーあたりの平均プロジェクト数

この分解によって、North Star指標が下がったときに「新規の有効化が減っているのか」「既存ユーザーの継続が落ちているのか」「一人あたりの利用が薄まっているのか」を切り分けられるようになります。単純な会員登録者数のような指標は、登録しただけで価値を得ていないユーザーを含んでしまうため、この用途には向きません。

確認 — North Star指標は万能ではない

単一の指標にプロダクト全体の健全性を語らせるのは危険だという指摘は少なくありません。一方で、North Star指標だけを追うと、指標を上げるためにユーザーの実質的な利便性を損なう施策が採用されるおそれがあります。例えば通知の頻度を増やせば短期的な利用回数は上がりますが、解約率が悪化することがあります。この歪みを防ぐには、North Star指標と対になる守り（ガードレール）指標をあわせて設定し、片方だけが動いた場合に警戒する運用が実務的です。

つまずきやすい点

登録者数や訪問数のようなバニティメトリクスをそのままNorth Starに採用してしまうケースが最も多い失敗です。これらは経営会議での見栄えは良くても、顧客が実際に価値を得ているかを示しません。指標を上げるためだけの施策、いわゆるゲーミングも典型的な罠です。四半期ごとにNorth Star指標そのものを変えてしまう運用も見られますが、これでは過去との比較ができなくなり、指標としての意味を失います。指標がチーム全体の共通言語になっておらず、経営層だけが見る数字にとどまっているケースも珍しくありません。

次の一歩

North Star指標が決まったら、入力指標のうちどれが現在最も伸びしろがあるかをコホート単位で確認すると、次に着手すべき施策が見えてきます。指標の読み方についてはコホート分析とリテンションの読み方で扱っていますので、あわせて確認してください。プロダクトの段階が変わればNorth Star指標も見直しの対象になる点は、プロダクトライフサイクルと各段階の意思決定で改めて整理しています。