第36章

間違いを認めるくらいならリリースする

取り戻せない支出が、次の判断を誤らせる

やめるべきだとわかっていた。それでも続けた。ロードマップに書いてあったから、というだけではない。チームがすでにあまりにも多くの時間を注ぎ込み、信頼できないものを出すより、打ち切るほうがつらく感じられたからだ。

それが、サンクコストの罠だ。時間も労力も、もう戻らない。それでも、次の判断に影を落とす。今、何が理にかなうかを問う代わりに、過去に費やしたものが少しでも無駄ではなかったと感じられる方法を、チームは探し始める。

なぜ、捨てるべき仕事を守り続けるのか

サンクコストとは、取り戻せないお金、時間、労力だ。正しい判断では、それを考慮しないはずだ。Hal ArkesとCatherine Blumer は、人がそれをいかにできないかを示した。一度何かをつぎ込むと、証拠がやめるべきだと示していても、続けたい気持ちに引っ張られる。彼らは、それを「いったん投資すると、その取り組みを続けようとする傾向」（英語からの翻訳）と呼んだ。

Richard Thaler の研究は、理由を理解する助けになる。損失は痛い。何か月も機能に費やしたなら、打ち切ることは、その損失を正式に認めるように感じる。世に出せば、まだ何かを救えるかもしれないと感じる。理屈は通っていない。それでも、引き寄せられる力は本物だ。

計画は、もうなくなっているかもしれない。締め切りも変わったかもしれない。それでもチームは、すでにそこにある代償を直視するのがつらくて、悪いものを生かし続ける。

ロードマップの圧力との違いは、そこだ。もう誰も、その機能を求めていなくてもいい。チーム自身が、努力を損失として認めることに耐えられないから、仕事が生き残る。過去が、会議室に居座り続ける。

Microsoftは、それでもKinを出した

2010年、Microsoftは、若いユーザー向けの2機種の携帯電話、Kin を発売した。プラットフォームの開発には、約2年と約10億ドルを費やしていた。そして世に出したプロダクトは、48日しか続かなかった。

Kinがここで参考になるのは、失敗したことだけではない。発売前に、警告があったことだ。2012年、Wired は、社内のユーザビリティテストの映像を公開した。参加者は基本的な操作で行き詰まり、いら立つ、わかりにくいと評していた。問題は、微妙なものではなかった。それでもMicrosoftは発売した。

プロダクトでのサンクコストは、そんな形で現れる。何年もの仕事。莫大な支出。すでにつくりすぎたもの。その時点で打ち切ることは、損失をはっきり認めることを意味したはずだ。

チームがそこまで来ると、ほとんどどんな継ぎはぎも魅力的に聞こえ始める。もう1スプリント。もう一度の修正。うまくいかない部分を包む、もう一層の説明。根本の問題を解決するからではない。最初の投資は実らなかったと、誰かが言わなければならない瞬間を、先延ばしにできるからだ。

プロダクトチームでは、どう現れるか

このパターンの有名な例が、Concorde だ。飛行機は並外れた技術の成果だったが、プロジェクトが終わるずっと前から、経済的には見合わなくなっていた。それでも各国政府は支援を続けた。理由の一つは、すでにあまりにも多くを費やし、中止することが、損失をそのまま認めるように感じられたことだった。

Kinは、プロダクトチームが下す判断にもっと近い。チームはすでにつくっていた。テストの結果は悪かった。人は基本的な操作で行き詰まった。プロダクトのわかりにくさは、見落としにくいものだった。

そこで誰かが、代わりに手直しできるかもしれないと言う。ラベルを足す。案内を足す。もう一度磨く。問題が解決するからではない。問題のある版を出すより、捨てるほうがつらいからだ。何か月も作業したあと、大きなデモのあと、社内で発売日を発表したあとに、チームがそうするのを、私は見てきた。すでに払った代償を誰も認めたくないから、機能が生き残る。

ここでの問いは、それだ。「約束したか」は忘れよう。「ロードマップに載っているか」も忘れよう。代わりに問う。すでに費やしたもののために、まだこの仕事を守っているのか。私はその理屈が、一貫性、ブランド、勢い、チームの士気への配慮として語られるのを聞いてきた。

ここでチームは、同じ判断を、聞こえのよい言葉で飾り始める。機能は完成間近だと言う。ユーザーは覚えてくれると言う。公開すれば、もっと学べると言う。公開して学べることもある。だが、チームはすでに十分知っていて、追加の学びは、損切りを拒むための口実でしかないこともある。

それでも出す前に、何を問うか

一つ問おう。これまでの経緯が何もない状態で、今日これが自分の机に届いたら、世に出すだろうか。

この問いは、脳が持ち込み続けるものを取り除く。費やした時間。デモ。ストレス。日程へのしわ寄せ。まだ間違ったものなら、そのどれもユーザーの役には立たない。

ここで Kahneman が役に立つのは、同じ修正を繰り返し促すからだ。閉じ込められた物語の外へ出て、もっと冷静な場所から判断を見る。過去の支出は現実にある。それでも、決定権はない。

私はこの問いが好きだ。一瞬でも、経緯を部屋の外へ押し出せるからだ。今日、初めて見たら却下するものを、過去の何か月かが強くしてくれるわけではない。打ち切りにくくするだけだ。たいてい、その瞬間にようやく、場にいる人は3か月前の姿ではなく、今の機能を、そのまま見られるようになる。

それは、マネジメントの問題であって、ユーザーの問題ではない。ユーザーに渡してはいけない。