Evidence-Basedだけでは意思決定はできない

「それ、データはあるの？」

会議でこの一言が出ると、場が静かになります。誰も反論できないからです。データに基づいて決める。これほど正しく聞こえる原則もありません。

私もデータは重要だと思っています。勘と声の大きさで決まっていた時代に戻りたいとは、まったく思わない。計測できるものを計測せずに議論するのは、単に怠慢です。この記事は、データを軽んじる話ではありません。

そのうえで、ずっと引っかかっていることがあります。データだけでは、最後の一歩が決まらないのです。

データは過去しか語らない

当たり前のことですが、意外と忘れられています。どんなに精緻なダッシュボードも、映しているのは過去です。先月のベロシティ、直近のバグ発生率、去年の類似案件の工数。すべて、すでに起きたことの記録です。

精緻に作り込まれたダッシュボードほど、未来まで見通せる気がしてくるので厄介です。あれはフロントガラスではなく、バックミラーなのだと思っています。

そして意思決定は、これから起きることについて行うものです。ここに埋めようのない溝があります。

過去が未来をよく予測してくれる領域も、もちろんあります。同じ製造ラインで同じ部品を作り続けるなら、先月の不良率は来月の良い手がかりになる。繰り返しの度合いが高いほど、データは強くなります。問題は、プロジェクトがその逆に位置していることです。

プロジェクトは「一度きり」が前提にある

プロジェクトという営みは、そもそも繰り返さないものとして定義されています。毎回、メンバーが違う。顧客が違う。技術スタックが違う。前提となる市場も違う。同じチームで同じような案件をやっているつもりでも、二年前とは組織の空気すら変わっています。

つまりプロジェクトは、データが一番効きにくい条件で行われる意思決定の連続です。

不確実性が大きいというのは、データが足りないという意味ではありません。データを増やしても縮まらない部分が残る、という意味です。

進捗は健全なのに、芯を食っていない

こういうことがありました。

メンバー一人ひとりの進捗は、きれいに出ていました。誰も遅れていないし、報告に嘘もない。数字の上では健全そのものです。それなのに、これが何になるのか、という感覚がずっと消えませんでした。

見えてきたのは、それぞれが進めている施策が全体としてどんな効果をもたらすのか、誰も説明できないという状態でした。各自が目の前の課題に部分最適で対応している。本来なら、もっと高次のアーキテクチャを決めて合意を取ってから進めるべき議論があったのに、それを避けて、手前の問題解決に拘泥するスタイルになっていたのです。

厄介なのは、進捗というデータがこの状態を一切検知しないことです。むしろ逆で、部分最適に徹しているチームほど進捗は良く出ます。目の前の課題は分解しやすく、片付けやすいからです。

結局、目標を定義し直しました。ただ、これは私一人では無理でした。より高いレイヤーの判断ができる人にサポートに入ってもらって、ようやく立て直せた。自分の手に負えないと認めるところから始まったわけです。

見える化は、それ自体が人を動かしてしまう

もう一つ、データの厄介さを思い知った経験があります。

会社の数字を見える化したときのことです。売上や受注に関する指標を、誰でも見える場所に置きました。判断の材料を増やすつもりでした。

ところが、指標を置くという行為そのものが、人を動かしてしまったのです。

経営層が数字について現場部門に聞く。この指標はどうなっているのか、と。単に状況を知りたいだけの質問です。しかし聞かれた側は、それを「この数字を改善せよ」という指示として受け取ります。以降、その数字を上げること、あるいはその数字である理由を説明することのほうが、優先順位の上に来てしまう。

最終的な利益にどう効くのかという一番大事な問いは、いつのまにか現場の視界から消えていました。

見える化は、背景をよく共有しながらやらないと暴走します。数字は中立な鏡のようでいて、置かれた瞬間から人の行動を変える力を持ってしまう。ここは対処しました。現場との会話を増やして、説明可能で妥当な指標に整理し直したのです。

背景から切り離された数字が危ういのは、リアルタイムの指標に限りません。組織に残る過去の実績も同じです。

正直に言うと、私は組織の過去実績をあまり信用していません。自分自身の実績なら、適用できる範囲を見極めたうえである程度は参考にします。どういう条件で出た数字か、自分は知っているからです。でも組織の実績は、誰がどんな前提で出したのかが抜け落ちた状態で残ります。数字だけが独り歩きして、参照するときには「前回はこうだった」という一行になっている。

溝を埋めるのは、仮説と経験と対話

二つの話を並べて気づくのは、どちらも最後は人と話すことで解決していることです。片方は高いレイヤーの人に入ってもらい、もう片方は現場との会話を増やした。データの問題を、データで解いてはいないのです。

データで届かない部分を埋めるものは、三つあると思っています。

一つは仮説です。過去の延長で語れないなら、「今回はこうなるのではないか」と筋を立てるしかありません。仮説は当てずっぽうとは違います。検証できる形にして、早めに間違いが分かるようにしておくもので、むしろデータの使い方の一種です。

もう一つは経験です。言語化されていないけれど確実に蓄積されている何か。進捗が健全なのに芯を食っていないと感じたあの感覚も、たぶんこれです。ただし経験は思い込みと見分けがつきにくいので、扱いには注意がいります。

そして対話です。個人的には、これが一番効くと思っています。データにも自分の経験にも表れていないものを拾えるのは、結局のところ人と話しているときです。顧客の言いよどみ、開発メンバーの歯切れの悪さ。数字の外側にある情報は、たいてい会話の中に落ちています。

PMはEvidenceとJudgementの両方を扱う

こう考えると、PMの仕事はEvidence（証拠）とJudgement（判断）の二階建てなのだと思います。

証拠を集めるところまでは、技術と手続きの話です。訓練すればできるし、他人と共有もできる。一方で判断は、証拠が尽きたところから先の仕事です。誰かに代わってもらえないし、外れたときの責任も引き受けることになります。

厄介なのは、この二つが混同されやすいことです。データを揃えれば判断が自動的に出てくるかのように振る舞ってしまう。あるいは逆に、「経験上こうだから」で証拠集めをサボってしまう。どちらも、二階建てのうち一階だけで住もうとしている状態です。

白状すると、私は後者に転びやすいタイプです。もう少しデータを集めてから決めよう、というのが待てない。だからこの記事は、自分への戒めでもあります。判断を急ぐ人間ほど、証拠の側を意識的に踏まないと、ただの勘で決める人になってしまう。

Evidence-Basedは出発点であって、終着点ではありません。データを尽くしたうえで、なお残る不確実性を引き受けて決める。その引き受けの部分こそが、PMという仕事の本体なのだと思っています。