ハクソク

世界を動かす技術を、日本語で。

スペースシャトル「コロンビア」事故とパワーポイントへの過剰依存 (2019)

270日前原文(mcdreeamiemusings.com)

概要

  • Columbia号事故 は、PowerPointの誤った使い方が悲劇に繋がった事例
  • NASA とBoeing間のコミュニケーション不全が事故要因
  • スライド設計の問題 が重要な警告を埋没させた
  • PowerPoint依存 が組織の意思決定に悪影響
  • 効果的なプレゼンの重要性を示す警鐘

Columbia号事故とPowerPointの悲劇

  • 2003年1月16日、 NASAミッションSTS-107 でColumbia号が打ち上げ
  • 乗組員7名による 微小重力下での科学実験 が目的
  • 打ち上げ82秒後、 外部燃料タンクの断熱材(SOFI)が剥離 し、左翼の耐熱タイルに衝突
  • 地上からは 損傷の程度が不明、過去にも類似事例あり
  • 断熱材が衝突したタイルは 大気圏再突入時の高熱から機体を守る重要部位

NASAの対応と意思決定

  • 宇宙遊泳による目視点検、 救出ミッション、 通常再突入 の3案を検討
  • Boeingのエンジニアが 28枚のPowerPointスライド で説明
  • 重要なポイント：実験データは 衝突した断熱材より600倍小さいもの が前提
  • NASAは「 致命的損傷の可能性は低い」と判断し、通常通り再突入を決定

事故発生とその後

  • 2003年2月1日、 大気圏再突入時に通信途絶、機体分解、全員死亡
  • 原因は 断熱材によるタイル損傷→翼の過熱→機体崩壊
  • シャトル計画は2年間停止、徹底調査が行われた

PowerPointスライドの問題点

  • タイトルが誤解を招く内容 で、リスクを過小評価させる
  • 箇条書きの階層・フォントサイズの乱用 で重要情報が埋没
  • 100語以上の過剰なテキスト、専門用語や曖昧な表現が多用
  • 最重要情報 （試験条件を大幅に超える衝突）の記載が 最下部の小文字 で目立たない
  • NASAマネージャーは「 下部・小さい文字は重要性が低い」と誤認

組織文化とPowerPoint依存の弊害

  • NASA調査報告書：「 PowerPointによる簡易ブリーフィング依存が技術的伝達を阻害」
  • Yale大学Edward Tufte教授の分析：「 PowerPointは重要な情報を埋没させ、思考を阻害」
  • Amazon CEO Jeff Bezosも PowerPoint禁止 を社内で実施
  • 読み上げ型スライド は教育でも学習でもないという指摘

効果的なプレゼンのために

  • メッセージの明確化 が最優先
  • 例：「 foam strike more than 600 times bigger than test data.」のような一文で十分
  • テキストの羅列は危険、情報の本質を伝える工夫が必要
  • 過ちを繰り返さないため、 Columbia号事故を教訓 とする重要性

まとめと教訓

  • Death by PowerPoint は比喩ではなく現実
  • プレゼンでは 伝えたい本質 を見失わない工夫が不可欠
  • Columbia号の悲劇 を忘れず、プレゼンや教育の在り方を常に見直す必要

Hackerたちの意見

この記事は（明確に示されているように）、チャレンジャー事故（1986年）やコロンビア事故（2003年）についてタフテが書いたことに大きく依存しています。彼はコロンビアの件について、『パワーポイントの認知スタイル』の第2版でより詳しく書いています。記事内の彼のウェブサイトへのリンクは今は壊れているので、彼のサイトの「コメント」セクションに含まれている数ページのキャプチャに興味がある人もいるかもしれません[0]。また、彼がこの件について「コメント」セクションに再投稿した記事も見てみてください[1]。 [0]: https://www.edwardtufte.com/notebook/new-edition-of-the-cogn... [1]: https://www.edwardtufte.com/notebook/the-columbia-evidence/

└

もしまだ読んでいなければ、ファインマンのチャレンジャー事故報告書への追記を読むことを強くお勧めします：https://www.nasa.gov/history/rogersrep/v2appf.htm 「安全係数3」という言葉は、私の人生の毎日と共に生き続けるでしょう。

└

数ページの抜粋 フルレポート（2003年版、低解像度）はResearchGateで入手可能だよ。著者自身がアップロードした合法的なコピーみたい。確かに面白い読み物だね。 https://www.researchgate.net/publication/208575160_The_Cogni...

父はロッキード・マーチン側でコロンビア事故後のフライト再開の一環として、外部タンクからフォームのPALランプを取り除く redesign effort を担当していました。当時、彼はそのデザインからランプを取り除くことを以前に調査していた時から会社に残っている最後の人でした。彼は、もともとはこのプロジェクトを隅で一人でやっていたのが、NASAがフライト再開にはランプを取り除く必要があると認識した時に、突然数百万ドルの資金が得られ、風洞テストのために飛び回ることになったと話してくれました。彼の名前はこの件に関する歴史の中で出てきたことがないと思います—ロッキードの方針で、従業員が論文で公にクレジットされることを許可していなかったからですが—でも、彼はその時の内部賞を家のデスクに飾っています（今は引退しています）。私はいつも彼を誇りに思っています。

└

うん、彼を誇りに思ってるよ。私たちを星に戻す手助けをしてくれてありがとう。

└

ありがとうと言われない品質保証の仕事が、あっという間に重要になるのが面白いよね。もちろん皮肉で言ってるけど。みんなに言いたいのは、華やかな仕事じゃなくて重要な仕事をしなさいってこと。そうすれば、よく眠れるし、実際に意味のある存在になれるかもしれないよ。

└

彼が君のことを誇りに思っているって知ってるといいな。

面白い記事だったけど、解決策はあまり提供されていなかったね。新しいAPIを教えるテックトークをいくつか見たけど、スライドは大体左側に箇条書き、右側にコードか画像があった。見ながら「これって最悪のスタイルじゃないの？」と思ったけど、「でも、これより良いやり方が思いつかないな」とも思った。APIだから、例が必要だし、何に集中すべきか、例や画像が何を示しているのかを説明する必要がある。言葉なしで画像だけの素晴らしいトークもたくさん見てきたけど、それはそのトークのタイプに合っていたからね。APIのトークは箇条書きなしの方が良いとは思えないな。参考になるものがあれば、リンクを教えてほしい。

└

タフテは、聴衆が読める本物の文書を準備するべきだと具体的な提言をしていて、会議中にそれを前に置いておくべきだと言っていました。これをあなたのAPIの例にどうやってうまく翻訳するかは分からないけど。

当時の議論はこちら：https://news.ycombinator.com/item?id=19668161 記事のスライドが、当時公に利用できなかったフォントのカリブリを使っているのは驚きでした。元の議論では、記事のスライドは元のものの再現であることが確認されています：> 記事のスライドは同じテキストですが、元のものの再現です（カリブリフォントは2007年までPowerPointには含まれていませんでした）。 > 元のスライドは、記事にリンクされている完全な報告書で見ることができます：> https://www.edwardtufte.com

これがパワーポイントとどう関係があるのか分からない。明確なコミュニケーションがなかっただけで、メディアはそれに全く関係ない。チョークボードに書いていてもコミュニケーションが失敗することはあるし、その場合チョークボードを責めるべきなの？

└

メディアが、読者が意思決定をするために必要な技術情報を密に伝えるのに適していないからです。他の類似のメディア、例えばチョークボードは特に取り上げられていませんでしたが、問題がパワーポイントに特定されていたからです。そして、似たような問題を抱えるメディアの選択ではなく、スライド対ペーパーの問題でした。記事から、> 「委員会は、技術的な文書の代わりにパワーポイントのブリーフィングスライドが常用されていることを、NASAにおける技術的コミュニケーションの問題の一例と見なしています。」

└

そうそう、「私たちのテストは関係ない」ってポイントを軽く流す選択は意図的だったよ。もし論文に載ってたら、テストの大きなグラフがあって、x軸を他の段落で言及されてる実際のスケールと比較するために自分で作業しなきゃいけない。最初から「警告：テストした600倍小さい粒子でも翼を傷つける可能性がある」って言ってたわけじゃなくて、マイクロソフトが勝手にランダムなことを上に載せたわけじゃない。どんな媒体でもできる、ちょっと情けないコミュニケーションだよ。彼らが言うべきポイントは、難解でも技術的でもなく、子供でも理解できるくらいシンプルなんだ。

└

媒体がメッセージだよね。

└

チョークボードの話だけど、次にプレゼンをする時は、チョークボードを持ってきて、リアルタイムでスライドをやってみて。視覚的なショー、聴覚的なオーバーロード、そしてその行為の新しさが、普通の「眠くなるパワーポイント」よりもずっとインパクトがあるんだよね。ホワイトボードは…まあまあ…パワーポイントよりはマシだけど、チョークボードほどは伝わらないと思う。音のせいかな。

└

メディアがメッセージだよね。パワーポイントが使われるのは、観客があまり努力しなくて済むから。みんなリラックスして、まるでソファに座ってるポテトみたいにぼーっとしちゃう。パワーポイントはやめて、技術報告書をマネージャーに投げつけちゃえ。文句を言ったり、読まない奴は無能だから、その場でクビにすればいい。

└

この特定のタイプのコミュニケーションの失敗は、黒板に書いているときにはずっと難しいと思う。スライド全体を書くのを想像してみて、永遠にかかりそうだよね。本当に黒板でその情報を提示しなきゃならないなら、「テストデータを確認した結果：タイルに大きな損傷が出る可能性がある」「翼に当たったフォームはテストよりもずっと大きかった」みたいなことを書く可能性が高いと思う。もちろん、どんなメディアでも誤解は生じるけど、著者の言いたいこと（私も同意するけど）は、特定のメディアは特定のタイプの誤解を生じやすいってことだよね。

これはPowerPointの失敗じゃないよ。俺はNASAで働いてるけど、今でもよく使ってるし、どんな媒体を使ってもコミュニケーションエラーは多いってことは誰にでも言える。問題は、現場のエンジニアとマネージャーが技術情報を解釈する方法の違いなんだ。記事でも触れられてるけど、著者は箇条書きやPowerPointに焦点を当ててて、技術論文で似たような事実を書き直しても何も変わらないと思ってる。俺の同僚もこれにいつも引っかかってる（幸いにも、俺の仕事が直接誰かの命に関わるような立場じゃないから助かってるけど）。最近、同僚がミッションパラメータについてマネージャーに決定を助けたことで賞をもらったけど、彼は選ばれたパラメータの値が気に入らなくて混乱してた。彼の問題は、多くのエンジニアと同じように、彼が導き出した結論に至るまでの技術的背景を提供することが結論を提示するのと同じくらい効果的だと思っていることなんだ。実際にはそうじゃない。マネージャーに聞いてもらいたいなら、同僚に本当に理解してもらいたいなら、シンプルすぎる、物議を醸す、根拠が薄いと思われるようなことを最初に言わなきゃいけない。そして、質問されるときに分析を明らかにすればいい。これを何度も見てきて、これは性格の問題かもしれないと思い始めてる。エンジニア同士で「Xは絶対にうまくいかない」って噂話してる。マネージャーとの会議では「XはYやZよりもわずかに効果が低いという30の異なる分析」を提示する代わりに、「Xはバカで、やるべきじゃない」ってスライドを出せばいいのに。幸運なことに、俺はあまり良いエンジニアじゃないから、乗っかってるときは大体マネージャー語にうまく翻訳できるんだ。

└

最近、「学者たちは情報に対する自信の度合いを示すために修飾語を使う」っていう素晴らしい議論を読んでたんだけど、ハッカーニュースみたいな場所でも似たような傾向が見られるよね。でも、「不確か」な言葉を使うのは、こういう文化の外にいる人には説得力がないみたい。もちろん、権力のダイナミクスもあるし。

└

それにしても、PowerPointを印刷して静かな部屋でじっくり読むのはかなり難しいし、あまりないよね。俺は書かれたものを読むときはいつもそうしてるけど。

└

「もし自分の意見を聞いてもらいたいなら…本当に理解してもらいたいなら…あまりにも単純すぎる、物議を醸す、根拠が薄いことを最初に言わなきゃいけない。そして人々が質問してくるときに、自分の分析を明らかにできるんだ。」 その前提には疑問があるな。冗談だよ、面白いからそれをどう活かすか考えてみるよ。ブログにも応用できるかな？もちろん、発言した後にコメント欄で「根拠を示さないなんておかしい」と思われるのが怖いよね。フォーラムの種類によるのかもしれないけど。

└

企業がエンジニアにデモをさせるとき、実際のエンジニアが出てくるから、最悪のセールストークになるのが好きなんだよね。彼らは自社製品の問題点を痛いほど詳しく教えてくれる。プレゼンはひどいけど、こういう瞬間は本当に貴重だよね。別のセールスマンがありえない約束をするより、ずっと価値がある。エンジニアの仕事は製品の問題を見つけて理解することだから、顧客と話すときにはどうしても問題点が目立っちゃうんだよね。うまくいってる部分は、彼らにとっては重要じゃない。

└

パワーポイントは実際には悪くないけど、どんなメディアでも悪いコミュニケーションは起こるよね。NASAでも今でもpptx使ってるし！問題はマネージャーと専門家のコミュニケーションの違いだよね。技術的な文書の問題もあって、長くて退屈だったり、ワードやエクセル、PDFに比べて…（次のスライドお願いします）マネージャーと専門家の違い - 文脈 vs 結論 - 魅力的なストーリーを語る - でも最初に結末を教えちゃう - 性格の違い - 動機やインセンティブ、マインドセット（次のスライド）災害から学ぶ - メディアがメッセージとメッセンジャーを導く - 責任を押し付ける道具 - 二者択一？ - プレゼンテーションの補助具 vs 分散型技術アーティファクト（次のスライド）質問は？

└

そうだね、これについては肝心なところを隠してる。これのフォームは私たちのテストの100倍も大きいから、手動で確認しなきゃいけないね。

└

わかるなぁ。その投稿のパワーポイントを見たら、思わず cringe しちゃった。まるで自分が書いたみたいな、未完成の考えがあちこちに散らばってるやつだったから。

└

問題は、特にエンジニアじゃない人たちが、いつも過剰に売り込んだり、約束しすぎたりしてることだと思う。リスクや問題、欠点について正直に話すと、プロジェクトや製品が悪く見えちゃうからね。Xを実現する最も現実的な方法は、「Xは素晴らしい選択肢で、リスクは管理可能だし、比較的早くできる」って言うことだよね。そしたら、予想外に時間がかかったり、いくつかの予期しないトレードオフが必要になったりするけど。

└

これはパワーポイントの失敗じゃない。 同意するし、同じことを言おうと思ってた。メッセージは特定の聴衆のために作られるべきだよね。非技術系のマネージャーに、あのスライドみたいな技術的詳細がたくさん入ったメールを送るときは、概念的なメッセージと詳細な内容を分けることが多い。「要約：システムのパフォーマンスは稼働には十分ではない。いくつかの解決策を検討中。詳細（興味がある人向け）：システムxは...blah blah blah...」

発射された弾丸よりも9倍速く落ちるって？ いや、それは物理学的におかしいよ。フォームは、切り離されたときにシャトルと同じ速度で動いてて、シャトルにぶつかる前に加速（減速）する時間が短かったんだ。

└

ありがとう。スペースシャトルの速度がコロンビアの翼に泡がぶつかったときの速度として引用されるのを何度も見てきたけど、それがすごくイライラするんだよね。

エドワード・タフテがその災害の調査に関わってたと思う。彼はPowerPointを伝説的に嫌ってるんだ。 https://www.edwardtufte.com/product/the-cognitive-style-of-p...

└

この記事で言及されていて、リンクもあるよ。

ピーター・ノーヴィグのゲティスバーグ演説のパワーポイントは、パワーポイントが物事を悪化させる良い例だよ。 https://norvig.com/Gettysburg/

一部の人がDoDに衛星を使って被害を確認するよう頼んだけど、リンダ・ハムはそのリクエストを断ったんだ。「その画像リクエストは、リンダ・ハムがその出所を調査した後、NASAのミッション管理チームの議長である彼女によってすぐに取り消された。彼女はフライトディレクターのフィル・エンゲラウフやミッション管理チームのメンバーと相談したが、コロンビアの画像が必要だとは言わなかった。ハムはデブリ評価チームとは相談せず、公式なルートを通っていないという理由で画像リクエストをキャンセルした。」