- 宇宙船の設計およびエンジニアリングプロジェクトに適用される40の実践的原則をまとめたスライド
- 数値に基づく分析、反復的設計、フォールトトレラント設計を中核原則として強調
- スケジュールは一方向にしか進まず、初期見積もりは常に過小評価されるという現実的な警告を含む
- 宇宙工学を超えて、ソフトウェア・システム・スタートアップ設計全般にそのまま適用可能
- 工学的判断で繰り返し発生する誤りを防ぐための実践的チェックリスト
法則 1 — 数値で証明される工学
- "Engineering is done with numbers. Analysis without numbers is only an opinion."
- 工学は数値で行うものであり、数値のない分析は単なる意見にすぎない
- 工学者が数学の学習に多くの時間を費やす理由
- 工学的な成功は定量化可能でなければならない
- "私のシステムのほうが速い" → どれほど速いのか?
- "私のシステムのほうが安い" → コストはいくらか?
- "私のシステムのほうが単純だ" → 単純さをどう測定するのか?
法則 2 — フォールトトレラント設計
- "To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong."
- 宇宙船を完璧に設計するには無限の努力が必要なので、一部に問題があっても動作するよう設計すべきである
- 100%の信頼性を要求するシステム設計は禁止
- 失敗事例: Deep Water Horizon、福島
- 航空機制御システムにおける**3重ロジックチェック（3 way logic checking）**方式の例
法則 3 — 反復的な設計プロセス
- "Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time."
- 設計は反復的なプロセスであり、必要な反復回数は現在までに行った回数より常に1回多い
- 良い設計は決して完成しない
法則 4 — 失望への対処
- "Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment."
- 最善の設計努力が最終設計では無駄になることは避けられない。失望と付き合うことを学ぶべきだ
- Bhargavaの法則: 研究プロジェクト10件のうち、産業の実務に適用されるのは1件だけ
- 最高の商業的成功が最高の技術設計とは限らない
- 例: Nokia N95 vs 初代 iPhone
法則 5（Millerの法則） — 3点で曲線は決まる
- "Three points determine a curve."
- データセットからは常にパターンを見つけてしまう
- そのパターンが測定ノイズではなく、実際の研究対象の現象によるものか確認が必要
- 学界や大学院生は特にこのルールを無視しがち
法則 6（Marの法則） — データ過学習への警戒
- "Everything is linear if plotted log-log with a fat magic marker."
- log-logグラフを太いマジックで描けば、何でも線形に見える
- Biggの法則: "数学的ツールに惚れ込むな。ツールは愛を返してくれない"
- データの過学習（over-fit）禁止
法則 7 — リーダーシップとチーム編成
- "At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it."
- 設計プロジェクトの開始時には、チームリーダーになりたがる人物ほど、その適性が低い可能性が高い
- Dilbertの漫画は、実際のエンジニアリング企業での経験をやや誇張したものに基づいている
- リーダーシップの一部は生まれつきだが、かなりの部分は学ばなければならない
- 管理者が「基本を尊重する（respect the basics）」ことができない場合がある
法則 8 — 最適点は中間にある
- "In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point."
- 自然界では最適点はほとんどの場合どこか中間にあり、極端な点が最適だという主張は疑うべきである
- 標準的な例: 最適電力伝送（Optimal power transfer）
- 実習例: 最適センサー抵抗（optimal sensor resistance）
法則 9 — 情報不足は言い訳にならない
- "Not having all the information you need is never a satisfactory excuse for not starting the analysis."
- 必要な情報がすべてそろっていないことは、分析を始めないための十分な言い訳にはならない
- より完全な分析のために、どの値が必要なのか把握しなければならない
法則 10 — 推定と当て推量
- "When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along."
- 疑わしいときは推定し、緊急時には推測せよ。ただし、実際の数値が得られたら必ず戻って後始末をしなければならない
- エンジニアとして訓練されているのであって、占い師ではない
- この仕事では素早い思考よりも質の高い思考のほうが重要
法則 11 — 最初からやり直す
- "Sometimes, the fastest way to get to the end is to throw everything out and start over."
- ときには、最後にたどり着く最も速い方法が、すべてを捨てて最初からやり直すことになる
- いつそうすべきかを学ぶには時間がかかる
- 多くの業界で、そうすべきだったのにそうしなかった事例が多い
- ロシアの有人偵察宇宙ステーション Almaz: 優れた技術設計だったが、打ち上げ後にコンピュータ制御の偵察衛星によって時代遅れになった
- 初期の「自動車」たち
法則 12 — 唯一の正解はない
- "There is never a single right solution. There are always multiple wrong ones, though."
- オープンマインドを保つ
- 工学は宗教ではない
- 技術的背教（Technical apostasy） は完全に許容される
- 例: 機械式自動計算
- 第二次世界大戦では主流の方式だった
- デジタルハードウェアがこの分野を支配するまでには1960年代までかかった
法則 13 — 要件ベース設計
- "Design is based on requirements. There's no justification for designing something one bit 'better' than the requirements dictate."
- 設計は要件に基づくものであり、要件が求める以上に少しでも「良く」設計する正当な理由はない
- 顧客は不要な機能に対して費用を払うことを嫌う
- アプリケーションに必要な信頼性を見極め、その信頼性水準に合わせて設計しなければならない
法則 14（Edisonの法則） — 「より良い」は「良い」の敵
- "『より良い』は『十分に良い』の敵である。"
- 実際には Voltaireの引用
- システムが 十分に良い(good enough) 状態に到達したとき、それを認識しなければならない
- 完璧さは無限の資源を要求するため、システムはいくらでもさらに良くできてしまう
- 法則13を参照
法則15（Sheaの法則） — インターフェースが核心
- "The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up."
- 設計を改善する能力は主としてインターフェースで生まれ、同時にそこは台無しにする主要な場所でもある
- 1つのシステムを本当に深く理解しているエンジニアや技術者は多い
- 複数の異なるシステムを本当に深く理解している人はまれ
- 例: 複雑なハードウェアとソフトウェアの相互作用を持つシステムでは、たいていインターフェースで問題が発生する
法則16 — 過去の分析を盲信しない
- "The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours."
- 類似の分析を行った先人たちが、時代を超えた叡智に直接つながっていたわけではない。したがって、彼らの分析を自分の分析より信じる理由はなく、とりわけ彼らの分析を自分のものとして提示する理由はない
法則17 — 出版物の正確性
- "The fact that an analysis appears in print has no relationship to the likelihood of its being correct."
- ある分析が印刷物に載っているという事実は、それが正しい可能性とは無関係である
- 1970年代の有名な見解:
- 「1200 baudがおそらく電話モデムが到達できる最大速度だろう」
- "Coding is dead" という発言で知られる
- Trellis coded modulationにより、1990年代までにこの速度は 50kbps まで引き上げられた
法則18 — 過去の経験の両面性
- "Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though."
- 過去の経験は現実的な検証を与えるのに非常に有用だが、現実を重視しすぎると、本来価値のある設計を駄目にしてしまうこともある
法則19 — 謙虚さの重要性
- "The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up."
- 自分がその分野の他の誰よりもはるかに賢い可能性はきわめて低い。もし分析の結果、終端速度が光速の2倍になるなら、ワープドライブを発明したのかもしれないが、単に計算を間違えた可能性のほうがずっと高い
法則20 — プレゼンテーションの重要性
- "A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."
- 悪い設計でもプレゼンテーションが良ければいずれ失敗し、良い設計でもプレゼンテーションが悪ければ即座に失敗する
- 例: Avro C102 — 世界で2番目の商用ジェット旅客機（差は13日）
法則21 — 教育の本質
- "Half of everything you hear in a classroom is crap. Education is figuring out which half is which."
- 教室で聞くことの半分は役に立たない。教育とは、どちらの半分がそれなのかを見極めることだ
- 教授たちが意図的に時間の50%を無駄にしようとしているわけではない
- 急速に変化し進化する分野で、どの技術が必要になるかを推測しているのである
- 例: 量子コンピューティング
- 今後20年間エンジニアとして働くうえで必須の知識になるかもしれないし、2030年代までは学術的関心にすぎないかもしれない
法則22 — 文書化の重要性
- "When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a program.)"
- 疑わしいときは文書化せよ。（文書化の要求は、プログラム終了直後に最大に達する。）
- 問題を解決できないなら、無知を隠してはならない
- 問題の原因を文書化する
- 他の誰かがその問題の解決法を見つけられるかもしれない
法則23 — スケジュールという虚構
- "The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it."
- 作成したスケジュールは、顧客がそれを守れなかったとしてあなたを解雇する時まで、完全なフィクションのように見えるだろう
法則24 — 作業分解構造
- "It's called a 'Work Breakdown Structure' because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it."
- これが『Work Breakdown Structure（作業分解構造）』と呼ばれるのは、何らかのStructureを与えないかぎり、残作業があなた自身がBreakdownするまで増え続けるからだ
法則25（Bowdenの法則） — テスト失敗後の分析
- "Following a testing failure, it's always possible to refine the analysis to show that you had negative margins all along."
- テストに失敗した後なら、分析を精緻化して、最初から余裕度がマイナスだったことを示すのはいつでも可能である
- 例: カナダ交通事故調査安全委員会 および 連邦航空局(FAA) の事故報告書
- 一部の失敗は 想像力の欠如 によって起こる（Frank Bormanの意訳）
- エンジニアはミスを犯すことは許されるが、ミスを隠すことは許されない
法則26（Montemerloの法則） — ばかなことをするな
- "Don't do nuthin' dumb."
- 工学の実務では 驚くほど守るのが難しいルール
- 基本を忘れないこと
- 自分の中で優先順位を明確にしておくこと
法則27（Varsiの法則） — スケジュールは一方向にしか動かない
- "Schedules only move in one direction."
- 問題や困難に備えた 余裕を残しておくこと
- 自分のせいではなくても、他の人が 必要な製品を遅れて納品することがある
- 常に自分とチームのために スケジュール上の余裕 を残しておくこと
法則28（Rangerの法則） — 無料の打ち上げはない
- "There ain't no such thing as a free launch."
法則29（von Tiesenhausenのプログラム管理の法則） — コストと時間の見積もり
- "To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right."
- 最終的なプログラム要件を正確に見積もりたければ、初期の時間見積もりに πを掛け、コスト見積もりの小数点を 右に1桁ずらす
法則30（von Tiesenhausenのエンジニアリング設計法則）— アーティストコンセプトの影響
- "If you want to have a maximum effect on the design of a new engineering system, learn to draw. Engineers always wind up designing the vehicle to look like the initial artist's concept."
- 新しいエンジニアリングシステムの設計に最大限の影響を与えたいなら、絵を描くことを学ぶべきだ。エンジニアは結局、最初のアーティストコンセプトのように見えるよう乗り物を設計することになる
法則31（Moの進化的開発法則）— 技術の根本的限界
- "You can't get to the moon by climbing successively taller trees."
- 技術やアプローチの 根本的な限界を理解することが有用
法則32（Atkinのデモ法則）— マーフィーの法則
- "When the hardware is working perfectly, the really important visitors don't show up."
- ハードウェアが完璧に動作しているときに限って、本当に重要な来訪者は現れない
法則33（Pattonのプログラム計画法則）— 実行の重要性
- "A good plan violently executed now is better than a perfect plan next week."
- 今すぐ断固として実行される良い計画は、来週の完璧な計画より優れている
- 産業界での誤り: 「完璧な」技術を待つこと
法則34（Rooseveltの課題計画法則）— 現実的な実行
- "Do what you can, where you are, with what you have."
- SF作家でもない限り、存在しない技術のために設計するのは無意味
法則35（de Saint-Exupéryの設計法則）— 完璧な設計
- "A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."
- 設計者は、もはや付け加えるものが何もないときではなく、もはや取り除くものが何もないときに完璧に到達したと知る
法則36 — 優雅さ、効率性、有効性
- "Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective."
- 平凡なエンジニアでも優雅なものは設計できる。良いエンジニアは効率的なシステムを設計し、偉大なエンジニアは有効なシステムを設計する
- 優雅な設計（Elegant design）: 標準的な都市上水道システム
- 効率的な設計（Efficient design）: ニューヨークの上水道システム
- 有効な設計（Effective design）: 北米・南米先住民文明の灌漑システム（一部は1000年以上稼働中）
法則37（Henshawの法則）— 責任の明確な線引き
- "One key to success in a mission is establishing clear lines of blame."
- 自分の行動と決定に 責任を負うべき
- 責任を取ることを拒むエンジニア（あるいは他の誰であれ）は 信用してはならない
法則38 — 能力が要求を主導する
- "Capabilities drive requirements, regardless of what the systems engineering textbooks say."
- システムエンジニアリングの教科書に何と書いてあろうと、能力が要求を主導する
- 重要なのは、どのような 新しい能力が開発されつつあるか を認識すること:
- 1950年代: トランジスタ
- 1960年代: 集積回路
- 1970年代: マイクロプロセッサ
- 1980年代: 家庭用コンピュータ
- 1990年代: インターネット
- 2000年代: 無線／モバイルコンピューティング
法則39 — 新しい打ち上げ機の開発禁止
- 新しい有人宇宙プログラムを低コストかつ予定通りに維持するための3つの鍵:
- 新しい打ち上げ機を作らない
- 新しい打ち上げ機を作らない
- 何があっても新しい打ち上げ機を開発すると決めないこと
- 完全に新しい製品が、既存製品の進化形より常に優れていると信じる 誘惑を避けるべき
法則40 — 宇宙は容赦しない
- "Space is a completely unforgiving environment. If you screw up the engineering, somebody dies (and there's no partial credit because most of the analysis was right...)"
- 宇宙はまったく容赦のない環境であり、エンジニアリングをしくじれば誰かが死ぬ（分析の大半が正しかったからといって部分点はない……）
- 大規模なエンジニアリング制御災害:
- 福島、チェルノブイリ
- De Havilland Comet（商用旅客機の窓の角が丸い理由）
- Eastern Airline Flight 401（自動操縦装置が民間航空機をエバーグレーズへ導いた）
- Therac-25（カナダの放射線治療装置）
- Richard Feynmanの意訳: "自然は欺けない（Nature cannot be fooled）"
1件のコメント
Hacker Newsのコメント
1990年代にTrellis coded modulationで50キロボーまで上げたという話は、やや違う
電話線の帯域幅とSNR特性から計算したShannon容量は約30kb/s程度で、V.34モデムはこの限界に近い33.6kb/sまで到達していた
しかし80年代以降、電話網は「ラストマイル」を除いてすでにデジタル化されていた
ISP側のモデムがデジタル音声を直接出力すれば理論上64kb/sまで可能だったが、実際にはFCCの電力制限により約53kb/s程度だった
当時私はモデム変調の研究チームで働いていたが、アナログ的な発想に慣れていたエンジニアたちがデジタルチャネルの可能性に気づくまでにはかなり時間がかかった
その後、彼らはケーブルモデムへ移り、再びアナログの世界へ戻っていった
依然として自宅までの区間がアナログなら、Shannon-Nyquist限界に縛られるのではないか？
もしISPモデムと家庭用モデムの間がフィルタのない銅線なら、単にUARTで数Mbps送信することも可能ではないのか？
この部分をもう少し明確に説明してほしい
Trellisコーディングを含むさまざまなエンコーディング・圧縮技術のおかげで、今でもUS Roboticsの56kモデムを購入できる
Law 20は、今どきのスタートアップの現実を正確に表している
「良いデザインが悪いプレゼンテーションに出会うと即座に潰れる」という言葉の通り、表現力の重要性は絶対的だ
うまく説明できることは、理解している証拠でもある
「5歳児に説明できないなら、自分でも理解していない」という言葉を思い出す
「最大の商業的成功が最良の技術設計とは限らない」という話について
Nokia N95と初代iPhoneの比較は適切ではない。代わりに私はCanyon’s Law of Design Optimizationを提案したい。顧客が求める指標と開発者が最適化する指標は異なり、顧客が間違っていると説得しようとしてはならない、という意味だ
初代iPhoneは形態とインターフェースは素晴らしかったが、機能は不足していた。3G、GPS、サードパーティ製アプリ、カメラのどれも弱かった
iPhone 3Gが出てからようやく本当の商業的成功を収めた
最後のスライドが抜けている
「上記のすべての助言を無視して、正しいことをせよ」という文言が核心だ
相反する助言の中でバランスを取ることこそが本当のエンジニアリングであり、技術的にも社会的にも最も難しい目標だ
「以前の分析は絶対的真理ではなく、自分自身の判断を信じるべきだ」という内容だ
このPDFは新しく見えるが、Akin’s Laws of Spacecraft Design自体は2003年から存在していた
Web Archiveのリンクでも確認できる
最初の法則を見るだけでも、なぜソフトウェア「エンジニアリング」を本当のエンジニアリングと呼びにくいのかが分かる
私は長い間、von Tiesenhausenの法則を引用してきた
「エンジニアは結局、最初のアーティストのコンセプトどおりに設計する」という言葉だが、Webプロジェクトでもまったく同じだと感じた
最初の文書を作った人、あるいは会議でメモを残した人が製品の方向性を決めてしまうことが多い。
「アジャイル」だとしても、実際には経路依存的だ
MITで2003年に宇宙船設計のキャップストーン授業を受けたが、このリストは見たことがない
当時のプロジェクトは衛星中心で、Akinの哲学が暗黙のうちに染み込んでいたのだと思う
宇宙工学は保守的な設計文化が強く、発展の速度が遅く、Elon Musk以前は変化がさらに緩やかだった
特に「宇宙は容赦のない環境であり、エンジニアリングの失敗は即、命の喪失だ」という文句が印象に残った
2003年のColumbia事故の時期とも重なる
おそらくLaw 31（既存技術の限界を理解せよ）がLaw 11（すべてを捨ててやり直せ）を引き起こし、Law 16（以前の分析を盲信するな）がそれを支えたのだろう
私は保守が不要で交換しやすいシステムを好む
ソフトウェア技術はいずれ消えるのだから、ハードウェアのようにいつでも交換できる構造であるべきだ
「完全に新しい製品が、常に既存製品の進化版より優れていると信じる誘惑を避けよ」という助言がとりわけ心に響いた