第31章

リリースされるのは上司の好み

権威バイアスが、いつもデザインの判断に優先する

上司が「うーん」と言った。それで、仕事の方向が変わった。ユーザーに嫌われたからでも、テストで失敗したからでもない。立場の上の人が疑問を示し、ほかの全員が、その疑問を証拠のように扱い始めたからだ。

そうなったら、もう仕事そのものを評価してはいない。

肩書きが、意見の重さを変える

Stanley Milgram は、権威があると受け止められることが、どれほど強い力を持つかを示した。Yaleでの研究は、デザインレビューよりはるかに極端なものだ。だから、その研究が支えられる範囲を超えて話を広げたくはない。それでも、ある参加者の一言は重要だ。「彼らは、とても自信を持って答えていました。もし迷っていたなら、私は行動を変えていたでしょう」（英語からの翻訳）。真剣に受け止めるべきなのは、そこだ。権威ある人の自信は、ほかの人が何をしようとするかを変える。

プロダクトチームは、この動きをよく知っている。上の立場の人が、確信が持てないと言う。あるいは、ある方向性が大好きだと言う。正式なことは何も起きない。誰も命令されない。それでも、場は変わる。下からの疑問は、重みを失い始める。上からの自信は、証拠のように聞こえ始める。

Amy Edmondson は、チームのなかで、対人関係上のリスクを安心して取れないときに何が起きるかを研究した。学習につながる行動が減る。場を気まずくするかもしれないことを、言わなくなる。ここで重要なのは、権威バイアスには、大げさな意味での恐怖はいらないということだ。反対意見を言う代償が高く感じられるだけの上下関係があればいい。

その代償は小さくても、害を及ぼす。罰を受けるわけではないかもしれない。ただ、面倒な人、遅い人、戦略的に考えられない人、方向性を共有できない人と思われるだけかもしれない。多くの会社では、それで十分だ。失職を恐れる必要はない。会議をいつもややこしくする人になることを、心配するだけでいい。

AmazonがBezosのためにつくったもの

2014年、AmazonはFire Phoneを発売した。Fast Companyの報道は、Bezosの頭からそのまま出てきたようなプロダクトだったと描写した。立ち上げチームのあるリーダーは、「Jeffが手塩にかけたもの」（英語からの翻訳）と呼んだ。別の関係者は、「私たちは顧客のために携帯電話をつくっていたのではありません。Jeffのためにつくっていたのです」（英語からの翻訳）と述べた。この一言で、問題がすぐに見えてくる。

問題を最もよく表す機能が、Dynamic Perspectiveだった。前面の4台のカメラで動く、3Dの視差効果だ。その報道によると、Bezosは象徴となる機能を求め、Lab126の内部で実際の用途を見つけるのに苦労していても、チームをその方向へ押した。

携帯電話は2014年7月に発売された。Amazonはその後、1億7000万ドルの評価損を計上した。生産は2015年8月に止まった。

強い創業者が一人いると、必ずプロダクトがだめになるわけではない。言いたいのはそこではない。もっと小さく、役に立つ指摘だ。頂点の一人が十分な重みを持つと、組織のほかの部分が、その人の確信に応えるために動き始める。

そうなると、仕事は見慣れた形でゆがむ。チームは、最も核心を突く証拠を持ち込まなくなる。そうした証拠は、摩擦を生むからだ。代わりに、無難な証拠を持ってくる。もっと耳当たりのよい証拠。すでに上から承認された方向性を裏づける証拠。社外で説得力を持つずっと前に、社内では足並みのそろったプロダクトに見え始める。

なぜ、バイアスだと感じないのか

罠なのは、起きている最中には、もっともに感じられることだ。

上司はおそらく、こちらの知らないことを知っている。見ていない数字を見ている。要件書に書かれなかった制約も知っている。立場の上の人が、単に正しいこともある。だから、権威の影響は、内側からは見つけにくい。よい意見と愚かな意見のどちらかを選んでいるのではない。意味のある手がかりと、地位の力を見分けようとしている。

Solomon Asch の研究がここで役立つのは、周辺の部分だ。人は、社会的な圧力で判断を曲げる。この場合、その圧力には発生源がある。上の誰かが空気を決め、ほかの全員が合わせ始める。

だから、この章はリーダーシップへの反対ではない。強いリーダーシップが、悪い仕事を救うこともある。問題は、権威が証明と取り違えられ、場にいる人が、人物と理屈を分けなくなることだ。その二つが一体になった途端、批評は急速に静かになる。

上司が意見を出したとき、何を聞くか

一つ、率直に聞こう。「そう考える理由は何ですか」。

挑戦するためでも、見せ場をつくるためでもない。理由を見えるようにするために聞く。ユーザーの証拠、市場の状況、実際の制約に根ざした答えなら、いい。これで、理由を扱える。答えは曖昧なままなのに、それでも場が動くなら、別のことがわかった。仕事をしていたのは、肩書きだったのだ。

それでも、上司が正しい可能性はある。だが、証拠や明確な手がかりなしに受け入れるべきではない。私なら、早めに聞く。その発言を受けて、周りが動き始める前に。変更が始まったら、その意見はすでにプロセスを動かしている。

多くのチームが世に出すのは、最も強い根拠のある案ではない。上司が気に入ったあとで、よりよく聞こえるようになった案だ。