平均的な合意がプロジェクトを壊すとき、標準偏差で組織を見る

平均が「成功」を隠している

チームの全員が「順調です」と答えているのに、なぜプロジェクトは突然止まるのでしょうか。

多くの場合、問題は能力不足でも、努力不足でもありません。チームの平均的な理解が、実際のばらつきを隠しているのです。

たとえば、プロダクトの目的について五人に尋ねたとします。四人が「既存顧客の継続率を上げるため」と答え、一人が「新規市場を開拓するため」と答えた。平均的に見れば、五人はかなり同じ方向を向いているように見えます。しかし、その一人が営業責任者や経営陣なら、数週間後に優先順位をめぐる衝突が起きる可能性は高いでしょう。

統計における平均は、データの中心を示します。しかし、中心だけではデータの形は分かりません。平均が同じ二つの集団でも、一方は値が密集し、もう一方は大きく散らばっているかもしれない。そこで必要になるのが、平均からの離れ具合を測る分散と標準偏差です。

この考え方は、数値データに限りません。組織の合意にも標準偏差があると考えると、プロダクト開発における多くの見落としが説明できます。

合意とは、全員が同じ言葉を使うことではない。全員の理解が、どれほど離れているかを把握することである。

プロダクトマネージャーの仕事は、単に機能の仕様を決めることではありません。中核の開発チームだけでなく、営業、マーケティング、カスタマーサクセス、法務、経営、サポートなど、製品に接続する人々との間にある理解の差を扱うことです。つまり、プロダクトマネジメントは、組織内のばらつきを発見し、意味のある方向へ縮める仕事でもあります。

沈黙は、標準偏差がゼロという意味ではない

会議で反対意見が出ないと、私たちはしばしば合意が成立したと考えます。しかし、沈黙は合意ではありません。発言するコストが高い、質問しても歓迎されない、そもそも自分の理解が間違っているかもしれない、と参加者が感じているだけかもしれないからです。

ここで、簡単な「理解の分布」を作ってみましょう。新機能の目的について、関係者に次の三つの質問をします。

1. この機能は、誰のどんな問題を解決するのか
2. 成功したと判断する指標は何か
3. 今回あえて解決しない問題は何か

回答を集めたら、正解を一つ決めて採点する必要はありません。むしろ、回答がどこで一致し、どこで分かれているかを見ます。

営業は「大口顧客への提案材料」と答え、サポートは「問い合わせ件数の削減」と答え、開発は「技術的負債の解消」と答え、経営は「新しい収益源」と答えるかもしれません。これらはすべて合理的な見方です。問題は、誰かが間違っていることではなく、同じ機能に複数の仕事を背負わせていることです。

統計でいえば、平均を計算する前に、分布の形を見る必要があります。組織でも同じです。「みんな理解していますか」と聞いて全員がうなずくより、各人の解釈を短い文章で書いてもらうほうが、はるかに有益です。言葉にした瞬間、見えなかったばらつきが現れます。

分散は、平均との差を二乗して平均したものです。負の差と正の差をそのまま足すと相殺され、必ずゼロになってしまいます。だから差を二乗する。組織の対話にも、これに似た工夫が必要です。

「目的に賛成ですか」と尋ねると、賛成と反対が相殺され、表面上は問題が消えます。代わりに、「この目的を十点満点でどの程度明確に理解していますか」「自分の理解と他者の理解はどの程度一致していると思いますか」と尋ねる。これなら、賛否ではなく認識の広がりを観察できます。

標準偏差が大きい場所には、摩擦が生まれる

身長の平均値だけを見ても、集団内の個人差は分かりません。平均身長が同じでも、ほとんどの人が平均付近にいる集団と、非常に高い人と低い人に分かれている集団では、必要な対応が異なります。標準偏差は、平均値が隠している個人差を見えるようにします。

組織の活動でも、同じことが起きます。全体の売上が目標を達成していても、顧客満足度のばらつきが大きければ、特定の顧客群が深刻な不満を抱えている可能性があります。平均の納期が守られていても、案件ごとの納期のばらつきが大きければ、営業は約束をしにくくなり、顧客は予測できなくなります。

プロダクトの指標を見るときも、平均値だけに依存すると危険です。たとえば、新機能を使ったユーザーの平均作業時間が二十パーセント短縮されたとします。素晴らしい結果に見えますが、実際には初心者の作業時間が大幅に減る一方、熟練者の一部では操作が複雑になっているかもしれません。平均の改善が、少数の重要顧客の悪化を覆い隠している可能性があります。

同じ視点を関係者との連携に適用すると、次のような「組織の標準偏差」を観察できます。

• 目的の理解のばらつき
• 成功指標の優先順位のばらつき
• 問題の深刻さに対する認識のばらつき
• 意思決定の権限についての理解のばらつき
• いつまでに何をするかという期待のばらつき

このうち特に危険なのは、成功指標のばらつきです。営業が契約数、サポートが問い合わせ削減、開発がリリース、経営が利益率を見ているなら、各部門が熱心に働くほど衝突が増えることがあります。努力が足りないのではなく、最適化している対象が違うからです。

この状態で「もっとコミュニケーションしましょう」と言っても、改善は限定的です。必要なのは会話の量ではなく、ばらつきの所在を特定することです。どの認識が一致していて、どの認識が大きく離れているのか。どの差は健全な専門性の違いで、どの差は意思決定を妨げる危険な不一致なのか。測るべきなのは会議時間ではなく、誤解が発生する確率と、その誤解が生むコストです。

明確化は、合意を強制することではない

ここで重要な区別があります。標準偏差を小さくすることは、全員を同じ考えにすることではありません。

営業と開発が異なる視点を持つのは自然です。顧客との接点が違い、扱う情報も異なるからです。視点の違いそのものは、製品を強くします。問題は、違いが可視化されず、同じ言葉の背後に隠れていることです。

「顧客価値を高める」という表現を例に考えてみましょう。営業にとっては提案時に顧客が感じる魅力かもしれません。サポートにとっては、導入後に困らず使えることかもしれません。開発にとっては、安定性や応答速度かもしれない。全員が同じ標語に賛成していても、行動に移す段階では別の方向へ進みます。

明確化とは、この違いを消すことではありません。抽象語を具体的な選択へ変換することです。

「顧客価値を高める」を、次のような文章に変えてみます。

「今四半期は、初回設定で離脱する中小企業の割合を減らす。そのために、設定画面の簡略化を優先し、高度な分析機能の追加は後回しにする。成功は初回設定完了率と、設定に要する時間で判断する」

この文章には、対象顧客、問題、優先順位、非優先事項、指標が含まれています。合意を作るときに重要なのは、賛成を集めることではありません。異なる専門性が、同じ判断を再現できる程度まで条件を明らかにすることです。

そのために、ビジネスモデルキャンバス、チーム憲章、OKR、仮説一覧などの道具が役に立ちます。ただし、道具は権威ではありません。完成した文書を作って承認を待つためではなく、思考のずれを早く露出させるために使います。

たとえば一枚の仮説カードに、「誰が」「どんな状況で」「何に困っていて」「何が変われば成功か」を書く。関係者に同じカードを別々に埋めてもらう。回答が一致しない箇所が、そのまま次に話すべき論点になります。議論を始める前に、議論の地図が得られるのです。

「許可を求めない」は、無謀に進むことではない

実務では、明確化の必要性が分かっていても、「正式な承認を得てから始めよう」と考えがちです。しかし、承認を待つほど、曖昧さは組織内に蓄積します。誰も全体像を整理しないまま、各部門がそれぞれの解釈で動き始めるからです。

小さなキャンバスを作る。関係者に三つの質問を送る。会議の最後に決定事項と未決事項を一枚にまとめる。これらは大げさな変革ではありません。多くの場合、誰かの許可がなくても始められます。

ただし、「許可を求めない」は、独断で決めることを意味しません。より正確には、承認を待つ前に、可逆的で低コストな観測を始めるということです。

この原則を、二つの軸で考えると実践しやすくなります。

第一の軸は、行動のコストです。会議の議題を変える、質問票を配る、仮説を一枚に整理する、といった行動は低コストです。大規模な開発投資や組織再編は高コストです。

第二の軸は、行動の可逆性です。メモを作り直すことは容易に戻せます。一度市場に大規模投入した機能や、顧客との契約変更は戻しにくい。

低コストで可逆的な行動なら、許可を待つより試す価値が高い。そこで得たデータをもとに、必要な承認を求めればよいのです。これは勇気の問題というより、不確実性を減らす順序の設計です。

実務で使える「組織の標準偏差」診断

明日から使える方法として、プロジェクトの節目ごとに「理解の分布」を確認する短い診断を行います。対象は中核チームだけでなく、製品に影響を与える周辺の関係者です。

まず、全員に同じ五つの問いへ個別に答えてもらいます。

1. 私たちが今解決しようとしている顧客の問題は何か
2. 最も重要な顧客は誰か
3. 成功を示す一つの指標は何か
4. 今回は何をしないのか
5. 自分の仕事に最も影響する決定は何か

次に、回答を並べます。平均的な答えを作るのではなく、差を分類します。

第一の分類は、表現の差です。言葉は違うが意味は同じなのか。これは用語の整理で解消できます。

第二の分類は、前提の差です。顧客像や問題認識が違うのか。これは顧客データや観察によって検証します。

第三の分類は、優先順位の差です。何を先にするかが違うのか。これは選択と非選択を明示する必要があります。

第四の分類は、権限の差です。誰が決められるのかについて認識が違うのか。これはチーム憲章や意思決定ルールに落とし込みます。

この分類を行うと、「コミュニケーション不足」という曖昧な問題が、扱える問題に変わります。必要なのが用語集なのか、顧客調査なのか、優先順位の決定なのか、権限の整理なのかが見えてくるからです。

Key Takeaways

• 平均的な合意を信じすぎない。 関係者に同じ質問を個別に投げ、回答のばらつきを見る。
• 目的、指標、非優先事項を一緒に定義する。 何をするかだけでなく、何をしないかを明記する。
• 沈黙を合意と解釈しない。 会議でうなずくことより、各人の理解を文章で確認する。
• 差を消すのではなく、差の種類を分類する。 表現、前提、優先順位、権限のどこに問題があるかを特定する。
• 小さく、可逆的な観測を許可なく始める。 承認を待つ前に、質問票、仮説カード、決定ログで不確実性を減らす。

成功とは、ばらつきをなくすことではない

優れたチームは、全員が同じ意見を持つチームではありません。営業は市場の変化を察知し、開発は技術的な制約を見抜き、サポートは顧客のつまずきを知り、経営は資源配分を考える。それぞれの視点には、固有の情報が含まれています。

目指すべきなのは、視点の標準偏差をゼロにすることではありません。違いを保ったまま、重要な判断については分布の幅を管理できる状態です。

平均だけを見れば、チームは順調に見えるかもしれません。しかし、散らばりを見れば、どこに誤解が潜み、どこで摩擦が起き、誰の声が平均から押し出されているかが分かります。

プロダクトマネージャーの本当の仕事は、全員を一つの答えに押し込むことではありません。異なる答えを集め、その違いが顧客価値を高めるものなのか、単なる誤解なのかを判別することです。

次に「みんな分かっています」と言いそうになったら、問いを変えてみてください。

「平均的には分かっているか」ではなく、「誰の理解が、どの方向に、どれくらい離れているか」。

その問いを立てた瞬間、合意は印象ではなく、観察できる対象になります。そして、曖昧な組織を動かす最初の一歩は、たいてい壮大な計画ではなく、隠れていたばらつきを一枚の紙に現すことなのです。