ハクソク

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

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

2025年8月29日原文(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における技術的コミュニケーションの問題の一例と見なしています。」

Hacker Newsで議論の続きを見る