第7章

締め切りは思考を鈍らせる

最も困るタイミングで、プレッシャーが思考を狭める仕組み

プレッシャーの中でリリースしたことがあるなら、あの感覚はわかるだろう。締め切りは動かせない。クライアントは待っている。そんな最悪のタイミングで、誰かが問題を指摘する。何かがおかしい。誰も対応していなかった例外的なケースがある。選択肢は二つ。延期して、その影響を引き受けるか。リリースして、後で対処するか。こういう場面では、十分に考えたからではなく、カレンダーの日付が代わりに決めてしまったからリリースすることがよくある。ストレスが変えるのは、そこだ。いちばん早く楽になれる選択が、よい判断のように感じられ始める。

ストレスは視野を狭める

Robert Yerkes と John Dodson が1908年に学習とストレスの実験を行ったとき、気になることがわかった。ある程度のプレッシャーは成績を上げる。だが、一定の点を超えると、プレッシャーを増やすほど悪くなる。少なすぎれば何も進まない。多すぎれば思考が機能しなくなる。役立つ範囲は、その中間にあった。適度なストレスは助けになる。極度のストレスは、単に役立たなくなるのではない。仕事を悪くする。

脅威を感じると、体内にコルチゾールが大量に分泌され、思考は目の前の最も差し迫った問題に絞られる。身体的な脅威なら、それは役に立つ。だが、脅威が締め切りの場合は、あまり役に立たない。選択肢を比較するのをやめ、その感覚を消してくれそうな最初の行動に飛びつく。もう幅広く考えてはいない。居心地の悪さを止めようとしている。

デザインの仕事には、広い思考が必要だ。複数の選択肢を残し、例外的なケースを考え、自分の前提を疑う。ストレスは、そのすべてを縮める。複雑な判断を、リリースするか、しないかという単純な二択に変えてしまう。細かな違いが見えなくなり、問題に気づけたはずの判断力も失われる。急いでいるチームは、急にみんなの口調が確信に満ちてくると、思考が狭まったことを、考えが明確になったことと取り違える場合がある。

Barry Staw は、集団の中でこれがどう現れるかを示した。1981年の研究によると、脅威を感じたチームは、意思決定を上層部に集め、情報の共有を減らし、以前うまくいった方法に戻る。試すことをやめる。誰も、進行を遅らせる人にはなりたくない。問題に最も近いエンジニアが黙り込む。プレッシャーの中で懸念を口にすることは、事態を悪くするように感じられるからだ。いちばん必要な瞬間に、いちばんよく知っている人が、いちばん話さなくなることがある。後になって、ずっと不安だったと言う。

NASA は準備が整っていないと知っていた

1986年1月27日の夜、Morton Thiokol のエンジニアたちは、Challenger の打ち上げを止めようと3時間にわたって訴えた。翌朝の予想気温は−6°C（20°F）。ロケットブースターの接合部を密閉するゴム製のOリングは、12°C（53°F）未満では試験されていなかった。寒さでゴムは硬くなる。硬くなったOリングでは、十分に密閉できないかもしれない。高温のガスが漏れれば、燃料タンクを焼き破る。Oリングの専門家 Roger Boisjoly は、気温に問題があり、飛ばすべきではないと NASA に伝えた。

NASA は強く反発した。Lawrence Mulloy は、12°C（53°F）未満では打ち上げられないと、どこに書いてあるのかと尋ねた。George Hardy は、その勧告に衝撃を受けたと述べた。プレッシャーはすさまじかった。Challenger はすでに5回延期されていた。打ち上げは、大統領の一般教書演説とも結びついていた。Morton Thiokol は NASA と8億ドルの契約を結んでおり、遅延には1000万ドルの違約金があった。エンジニアたちはデータを示した。NASA が求めたのは、失敗するかもしれないという懸念ではなく、失敗するという証明だった。Boisjoly にはデータと懸念はあったが、失敗するという確証はなかった。

Morton Thiokol の上級副社長 Jerry Mason は、チームを別の場所に集め、技術担当副社長の Bob Lund に、エンジニアとしてではなく経営者として考えるよう伝えた。Lund は勧告を変えた。エンジニアたちの判断は退けられ、打ち上げは承認された。

Lund は後に Rogers Commission で証言した。

私たちは、まだ準備ができていないことを彼らに証明しなければなりませんでした。それで、うまくいかないと証明する方法を何とか探そう、という考え方に陥ってしまったのです。
— Robert Lund（英語からの翻訳）

ルールが逆転していた。エンジニアたちは、打ち上げが安全であることを証明しようとしていたのではない。すでに打ち上げを決めた人たちに、危険であることを証明しようとしていた。Challenger は翌朝、気温2°C（36°F）の中で打ち上げられた。73秒後、乗員7人全員が命を落とした。

見覚えがあるはずだ

もっと小さな形で、同じことがプロダクトの仕事でも日常的に起きている。明日から実装するから、ユーザビリティテストを省く。どうせ直す時間がないから、アクセシビリティの確認を飛ばす。開発者の懸念を聞いても、対応すればデモを延期することになるので、話題を変える。懸念が消えたわけではない。誰か別の人のスプリントに移っただけだ。

プレッシャーは、こうした判断を実際よりも妥当に感じさせる。ストレスで注意がゴールだけに絞られ、それ以外のことは気を散らすものに感じられる。懸念は、面倒なものになる。会議室でみんながうなずく中、一人が黙り込み、会議が終わった後で Slack が不安の声で埋まる。私はそんな場面を見てきた。たいてい、真剣に受け止めるべき警告はそういうものだ。だが、その頃には会議は次へ進んでいる。だから問題が残る。

警告が無視されそうになったら

ここで役立つのは、最悪のタイミングで投げかける、一つの質問だ。「これを確かめるには、何が必要か」。

「延期すべきか」ではない。「これは本当に問題なのか」でもない。そうした問いは、楽な答えを正当化する議論につながる。「確かめるには何が必要か」なら、具体的だ。懸念を見積もりに変えられる。テストに1時間。調査に1日。リリース前に収まるほど小さいこともある。リスクは現実のもので、もっと難しい話し合いが必要だとわかることもある。どちらにしても、タイミングが悪いという理由で埋もれさせず、その懸念をきちんと検討する機会をつくれた。リスクが消えたふりをするより、ずっとよいプレッシャーの使い方だ。

Challenger のエンジニアたちは、情報を持っていた。何がわかっているのかを把握していた。NASA の誰も、その懸念を確かめるには何が必要かと聞かなかった。締め切りのせいで、その問い自体が不可能に感じられた。実際には、警告より打ち上げのほうが現実味を持つようになっていたから、不可能なものとして扱われたのだ。