切屑堂 kirikuzudo
ブログ： 2023/01/15 雑訳：AIAA講演資料『System Engineering: A Traditional Discipline in a Non-Traditional Organization』(SpaceX 2012年)
雑訳：AIAA講演資料『System Engineering: A Traditional Discipline in a Non-Traditional Organization』(SpaceX 2012年)
『System Engineering: A Traditional Discipline in a Non-Traditional Organization』というAIAAで2012年に公開されたSpaceXの講演資料があります。
Googleで検索するとAIAAからは消えていて、いまは怪しげなサーバにコピーされたPDFが残されてるぐらいです。
直訳すると「非伝統的な組織における伝統的な規律」ですが、中身はなかなか含蓄に富むといいますか、「こういう組織と殴り合ってこの先生きのこるのは無理では？」という気持ちにさせてくれる資料です。
2012年といえばまだFalcon9がデモフライトをしてる頃で、いまみたいなFalcon9無双がはじまる前の時期ですが、こういうのがじわじわと効いて現状があるんだな、ということで、
雑な要約と意訳と所感をさらしていこうかと思います。
元資料が非公開なので、図はところどころ抜粋する程度にしています。
＜大事だと思うところの要約＞
時間ない人向けです。ざっくりです。
１．SpaceX には全体で1,750人の従業員がいる
日本の宇宙産業におけるロケット関連産業の従事者数は2010年で1500人以下。
https://www8.cao.go.jp/space/comittee/dai6/siryou8-2.pdf
つまり「日本のロケット関連産業従事者数とほぼ同等な従業員がひとつの組織にいる」
２．人間は Integration における潜在的な問題を予測するのが苦手
Systems Engineering は Integration における問題を事前に予測して解決しようとしてるけど、歴史を見ると人間は Integration における潜在的な問題を予測するのが苦手ですね。
３．システム志向の組織文化と責任の哲学が大事
システム志向の組織文化と責任の哲学が大事でこれを置き換えるエンジニアリングプロセスなんてない。フラットで大規模な組織をまわすためにはこれが重要。部門にはシステムレベルの要求を割り振ってシステム志向を維持する。
４．物理システムでのテスト駆動開発
「heavy up front systems engineering」と「rapid prototyping」のバランスをとる。バランスは
・「organizational agility」（組織の俊敏さ）
・「cost of iteration」（イテレーションのコスト）
・「ability to trade lower level requirements」（低レベル要求のトレード力）
に依存している。
低コストで設計製造テストのサイクルをまわして経験を通して学習することができる。
・「we can design-build-test at low cost」
・「we can afford to learn through experience」
テストできるシステムを設計して、実際に飛ぶものをテストする。
・「Design a testable system and test what you fly!」
５．下位の要求は設計段階で常に交換・最適化が可能
伝統的なシステム開発のＶ字モデルみたいに要求分解はしない。トップレベル要求を満たす、最適なシステムパフォーマンスを実現するための主要な設計パラメータを特定し調整するようになっている。
伝統的なシステム開発のＶ字モデルみたいに要求の境界がないので、主要設計パラメータのトレードオフの速度を上げられるし、内製比率が高いので製造工程まで含めた最適化を行える。
内製比率が高くフラットな組織なので、要求の境界を発生させてしまうサプライチェーンがほとんどない。
＜全体を通しての所感＞
2023年ではもうテック組織の運営という点で、知識上では常識になっちゃってる内容ばかりなわけですが、なかなかこれを大規模で複雑な物理システムを扱う組織に適用するのは難しく、それゆえに15年以上前からこれを適用して運営できているというのは驚きです。
そして、その結果として現在のFalcon9無双状態があるのだな、と思うと、やはりうまくいくのにも理由があるのだなあ、という気持ちになります。
［以下、全体の要約］
＜Page.2 会社概要＞
原本では「Corporate Overview」ってなってます。
いろいろと箇条書きになっていますが、気になる点を挙げてみましょう。
「・Founded with the singular goal of providing highly reliable space transporation」
信頼性の高い宇宙輸送の提供を唯一の目標で設立された組織です、と1行目でうたっています。
「・Tech-style Organization - Flat and Fast」
2行目ではこんなことが書かれていますが、これについてはPage.7のところで触れたいと思います。
「・1,750 employees and growing」
3行目では、1,750人の従業員がいて更に増えているよ、と言っています。
少し古い資料ですが、日本の宇宙産業におけるロケット関連産業の従事者数は2010年で1500人を超えていません。
https://www8.cao.go.jp/space/comittee/dai6/siryou8-2.pdf
ここ10年で大幅に増えたという話も聞かないので、2000人を超えてないと考えていいでしょう。
つまり「日本のロケット関連産業従事者数とほぼ同等な従業員がひとつの組織にいる」という、なかなかすごい状況です。
さらにこれは2012年の状態なので、Falcon9無双が確定してStarShipをなんやかんやしてる2022年では1.5～2.0倍程度になっているのではないかと思います。
＜Page.6 前提＞
Page.3～5はFalconシリーズの今後のロードマップみたいな感じなんで飛ばします。
原本のPage.6は前提の話をしていますね。
「Systems Engineering は 確立された discipline で」
「Integration における問題を事前に予測して解決することで」
「大規模で複雑なシステム開発への投資を抑制する」
「しかしながら歴史は示している」
「人間が Integration における潜在的な問題を予測するのが苦手なことを」
「特に新しいシステムを開発するときには」
という感じになるでしょうか。
※前振りというか「お前ら Systems Engineering 使いこなせてないんじゃないの？」という煽りにも見えます。うーん。
＜Page.7 核となる思想＞
Central Philosophy ってやつですね。
ここも箇条書きになっています。
1行目と2行目に書かれている中で注目したいのが、「systems oriented culture」と「philosophy of responsibility」という表現です。これに付随して、「no engineering process in existence can replace this」という表現があります。
システム志向の組織文化と責任の哲学が大事でこれを置き換えるエンジニアリングプロセスなんてないんだ、という表明です。
そして、おそらく Page.2 でスルーした、
「・Tech-style Organization - Flat and Fast」
の Flat and Fast を実現しているのが、この部分なのでしょう。
※「システムとしては人間を信用していないが、システムを作り上げようとする人間の責任(だけ)は信用している」というのがこの部分から伝わってくる気がします。
この1行目と2行目は抽象的ですが、組織文化や組織の価値観という Business School で扱う題材をきちんと意識しているんだな、というのがよくわかります。
3行目からはちょっと踏み込んだ話になっています。
まず「heavy up front systems engineering」と「rapid prototyping」のバランスをどうとったらシステム開発のリスクを低減できるんだろうね、という文があり、続けて、バランスを決める要素(「tipping point heavily dependent on」)として、
「organizational agility」（組織の俊敏さ）
「cost of iteration」（イテレーションのコスト）
「ability to trade lower level requirements」（低レベル要求のトレード力）
が挙げられています。
続いて4行目。
「consuming schedule attempting to anticipate all possible system interactions」（考えられるすべてのシステムの相互作用を予測しようとしてスケジュールを消費する）というなかなか響くセンテンスが出てきます。
そして、
「we can design-build-test at low cost」
「we can afford to learn through experience」
という表現が出てきます。
さらに5行目と6行目。
「Design a testable system and test what you fly!」
「Test rigorously and at multiple levels of integration」
3～6行目をまとめると、テスト駆動開発をリアルワールド（しかもクソデカ複雑系であるロケット！）に適用してやろうぜ、という感じですね。正気か？
しかし、それで成果が出ているわけですから、正解ではあるんですよね。
※このあたりについては組織の成り立ちとして Elon Muskという大資本家がいるという前提は無視できません。本邦の基幹ロケットは官のお金で動いており、ご説明ピラミッド・単年度会計・多重組織という縛りがある以上、適用はまず無理でしょう。ISTとSpaceOneに期待ですね。
※「we can design-build-test at low cost」という点についても、試験自体に失敗できない縛りがある本邦ではとてもじゃないけど「low cost」は無理なお話です。
※「Design a testable system」という点ですが、このあたりは設計と試験が別部門で上下流工程になっている弊害みたいなのがあると思います。ここは本邦でも改善可能なところですし、なんとかならんかなあ、なんて思ってます。
＜Page.8～9 Iterative Design の例＞
Iterative Design の例として、Engine Controller と Marlin Engine が出てます。おそらく講演では具体的な話があったんじゃないかと思いますが、資料にこれらのPageには文が一切ないのでわかりません。
ただ、Engine Controller の Previous Design がよくあるアルミ削り出しのボックスにたくさん(12個くらい)コネクタが生えた形状なのに対して、Current Design が基板1枚が収まるフラットなアルミ削り出しケースで、コネクタも2個だけになっています。
ケースの加工時間でいくと5倍ぐらい差があるんじゃないでしょうか。コネクタ取付も考えると10倍近い工数差がありそうに見えました。
※そういえば Rocket Lab の Rutherford Engine の Engine Controller もこういうフラット形状でしたね。しかも D-Subコネクタでしたし。（リンク先画像の黄色のやつ）
https://spacenews.com/rocket-lab-unveils-battery-powered-3d-printed-rocket-engine/
＜Page.10 スパイラル開発における継続的な設計資産の継承＞
「Maintain continuous design heritage in development with within rapid spiral methodology」というタイトルのページです。
Design -> Build -> Certify -> Flight Test という４象限で開発がスパイラル状に拡大していく図が載っていますが、特に文はありません。
＜Page.11 詳細＞
箇条書きページです。
1行目は
「システムレベルのタスクを部門毎に分配してシステム志向に集中できるようにする」
2行目は
「社内全体を通した integrators のネットワークによるフォローアップする」
3行目は
「ユーザー要求はすべて tracked and verified されてるけど、より下位の要求は設計段階で常に交換・最適化が可能になっている」
4行目は
「discussion と integration のための伝統的な討論会や委員会はinformation system tools で置き換えている、social networking の考え方に近いものを使っている」
「Focus on TOOLS NOT RULES」
5行目は
「Test rigorously and often」
という感じです。
flat な組織でも departments はある、ということですね。それを integrators という役割の人(？)がネットワーク状にやりとりしてフォローアップしている、というような感じでしょうか。タスクの分割がシステムレベルのものになると、確かに最終システム全体に意識を向けやすいのはありますね。
※おそらく本邦の組織でも実務レベルでのネットワークによるフォローアップみたいなのはあるんでしょうけど、公式ではないので弱いんですよね。
※要素と工程でマトリクス状に部門が分割されている本邦では部門間の調整や勝った負けたというシステム全体からすると不毛な話が多く出てくるの、マジでつらいです。
要求の話は次の Page.12 に絡むので、そちらで。
※ルールではなくツールに注目しようぜ、というのはまったくそのとおりで、人間というのは環境の奴隷ですからね。（ツール自体が広義のルールではあるんですが）
そして、「Test rigorously」というのがここでも繰り替えされています。
＜Page.12 下位の要求は設計段階で常に交換・最適化が可能＞
前ページの3行目の解説みたいなページです。
「Traditional Vee」と「SpaceX」という形で対比した図が示されています。
この「Traditional Vee」はよく出てくるシステム開発のＶ字モデルの図ですね。トップレベル要求から要求分解してボトムでコンポーネント開発してそれをインテグレーションしていくというよく見る図です。
これに対して「SpaceX」ですが、要求分解側は
「Identify Key Design Parameters」
「Adjust Key Design Parameters For Optimum System Performance to meet Top Level Requirements」
（トップレベル要求を満たす、最適なシステムパフォーマンスを実現するための主要な設計パラメータを特定し調整する）
という表現をしています。また、インテグレーション側では Verification を行うのはトップレベル要求に対してのみで、下位では
「Qualify units to predicted/measured environments」
（予測/測定環境に対するユニットの認定）
という表現をしています。
これだけだとよくわかりませんが、ページの下に次の一文があります。
「possible to trade key design parameters between subsystems to optimize results because designers not separated by contract-subcontract bounds」
つまり、要求の境界がないので最適なシステムパフォーマンスを実現するための主要な設計パラメータのトレードオフを進められるということですね。
これは Page.6 の
「しかしながら歴史は示している」
「人間が Integration における潜在的な問題を予測するのが苦手なことを」
という前提に対する回答ではないでしょうか。潜在的な問題が出ても要求が分解されている以上、分解された枠内で解決しないといけません。そしてそれが不可能な場合は、Ｖ字モデルのはじめからやり直しになります。
＜Page.13 主要設計パラメータのトレードオフ速度向上＞
ではどうやって「designers not separated by contract-subcontract bounds」するのかというページです。
ここでも Traditional と SpaceX の対比になっていますが、面白いのがSpaceX側の表記が「If SpaceX performed traditional decomposition」となっている点です。
図はサプライチェーンのピラミッドなわけですが、SpaceX は decomposition してないのでサプライチェーンのピラミッドなんてないので、「もし decomposition したらこんな感じ」ということなんですね。
あとはページの下に
「70％ of rocket dry mass is built in house at SpaceX from raw materials」
とあります。ガチ内製ですね。内製してるんで製造技術もトレードオフのパラメータになってきたりしますし、ここもけっこう効いてるポイントな気がします。
※Verificationしないとサプライチェーン間を跨げないですし、そうなるとどうしてもsubconstract側は慎重になりますからね。
※ここでも組織の成り立ちとして Elon Muskという大資本家がいるという前提は無視できません。人件費を気にする株主にしばられて半分以上が技術派遣で構成されたジャパニーズトラディショナルビッグテックカンパニーでガチガチの内製型組織なんていまさら作れるんかいな？
＜Page.14 システム相互作用を予測しようとせず、経験を通じて学習する＞
ここも Traditional と SpaceX の対比ですね。
Traditional側は「Plan -> Design -> Build -> Test」という単一のサイクルで製品化しようとしています。そして、単一サイクルでやろうとするので、投資を抑制するために「Mandates Heavy Systems Engineering」されている、と表現されています。
それに対して SpaceX側は「design-build-test」によって設計とその結果を伝える、と表現されています。
あとはページの下に
「Documentation and process becomes more formal as systems move into later cycles Final qualification, first flight and production」
（最終認定、初飛行、および生産に移行するにつれてプロセスは正式化され文書化される）
と書かれています。
＜Page.15 飛ぶものをテストする＞
「Test Like You Fly, Test What You Fly」というタイトルのページです。
「Integrated testing tools are a key investment and provide points where integration is assessed and ensured using a ―Test Like You Fly? approach」
という文がはじめに来ています。テストツール（テスト環境）は重要な投資項目で、可能な限りFlight環境に近い状態でテストしていくよ、という感じでしょうか。
そして、その下に
「・Ironbirds at Hawthorne - hardware-software integration」
「・McGregor engine test - engine and avionics integration in real dynamics environment」
「・McGregor stage test firing - tanks, plumbing, avionics and propulsion integration in real dynamics environment」
「・Launch site Hadrware in the Loop Simulations - hardware-software integration with all system components」
「・Launch Site Wet Dress Testing and Static Fire - hardware-software integration with all system components in real dynamics environment」
とテスト環境に関して箇条書きにされています。このあたりはわりと伝統的なテストをきっちりやっているという感じですね。テストにも種類があるようで、次ページに詳細があります。
＜Page.16 柔軟なテスト階層＞
「Flexible test hierarchy increases formality as product matures」というタイトルのページです。
箇条書きでテストの種類が書かれています。
・Development Tests 開発テスト
「Development Tests used to determine hardware capability in excess of requirements and to find weaknesses (running at extended temperatures, ultimate strength tests)」
要求以上の負荷をかけて weakness を見つけていくというやつだそうです。
・Qualification Tests 認定テスト
「Qualification tests demonstrate hardware performance limits (worst case flight conditions plus required factor of safety or margins). Qualification tests are performed every design/environment combination」
こっちは性能限界を確認するテストですね。
・Acceptance Tests 受入テスト
「Acceptance Tests verify workmanship and functionality. All hardware acceptance tested」
製造上の問題がないか、機能を確認するテストですね。
・Hardware in the Loop
「Hardware in the Loop shows hardware-software integration. Run for every
hardware-software change」
HILsですね。every hardware-software change に対して実施されるというのはなかなかすごいです。
そして、このページと次のページに下記のテスト項目と写真が載っています。
・M1C Merlin Engine Foreign Object Ingestion Demonstration Test
（インペラにWedged nutが突き刺さっている写真）
・Thermal qualification of F9 separation system
・Development Test - Composite Overwrap Pressure Vessel Ultimate
・Thermal qualification test of Dragon Claw - connection between Dragon and Trunk
・F9 First Stage Qualification Tank at McGregor, TX
・Second Stage Acceptance Test Flight 3 - McGregor, TX
・Dragon Trunk - Falcon 9 Second Stage Separation Qualification Test
・Draco(Dragon Thruster) Acceptance Testing
・Merlin Nozzle Carbon Coating Development Test
・Dragon Eye Dragon Rendezvous Thermal Sensor Shuttle Development Flight Test
・Space Station End To End Communications Testing
＜Page.18 テストプロセス at SpaceX＞
どどん、と一枚絵です。これは載せた方がはやいですね。
＜Page.19 まとめ＞
まとめページです。
「・It is difficult to build a creative high performance engineering culture」
（クリエイティブで高パフォーマンスなエンジニアリング文化を構築するのは難しい）
「・It is really easy to ruin the creativity and performance by too much organization, rules and process」
（組織、ルール、プロセスが多すぎると創造性とパフォーマンスが簡単に失われます）
「・SpaceX is achieving a good balance of creativity and systems engineering for agility and affordability」
（機敏さと手頃な価格のためにSpaceXは創造性とシステムエンジニアリングのバランスを取っています）
あと、開発コストと開発期間の表がページの下に載っています。
・Falcon 1 Development => 3years,4months and $90M
・Falcon 9 Development => 4years,7months and $300M
・Dragon Spacecraft => 4years,3months and $300M
・Falcon 9 Integration Hangar => 12months and $1.25M
・Hypergolic Test Facility => 12months and $2M
・Falcon1 Launch Pad => 6months and $10M
このページのまとめはざっくりしすぎていてあまり面白みはないですが、開発期間の短さだけはやはり際立ちますね。
＜Page.11 詳細＞
箇条書きページです。
1行目は
「システムレベルのタスクを部門毎に分配してシステム志向に集中できるようにする」
2行目は
「社内全体を通した integrators のネットワークによるフォローアップする」
3行目は
「ユーザー要求はすべて tracked and verified されてるけど、より下位の要求は設計段階で常に交換・最適化が可能になっている」
4行目は
「discussion と integration のための伝統的な討論会や委員会はinformation system tools で置き換えている、social networking の考え方に近いものを使っている」
「Focus on TOOLS NOT RULES」
5行目は
「Test rigorously and often」
という感じです。
flat な組織でも departments はある、ということですね。それを integrators という役割の人(？)がネットワーク状にやりとりしてフォローアップしている、というような感じでしょうか。タスクの分割がシステムレベルのものになると、確かに最終システム全体に意識を向けやすいのはありますね。
※おそらく本邦の組織でも実務レベルでのネットワークによるフォローアップみたいなのはあるんでしょうけど、公式ではないので弱いんですよね。
※要素と工程でマトリクス状に部門が分割されている本邦では部門間の調整や勝った負けたというシステム全体からすると不毛な話が多く出てくるの、マジでつらいです。
要求の話は次の Page.12 に絡むので、そちらで。
※ルールではなくツールに注目しようぜ、というのはまったくそのとおりで、人間というのは環境の奴隷ですからね。（ツール自体が広義のルールではあるんですが）
そして、「Test rigorously」というのがここでも繰り替えされています。
＜Page.12 下位の要求は設計段階で常に交換・最適化が可能＞
前ページの3行目の解説みたいなページです。
「Traditional Vee」と「SpaceX」という形で対比した図が示されています。
この「Traditional Vee」はよく出てくるシステム開発のＶ字モデルの図ですね。トップレベル要求から要求分解してボトムでコンポーネント開発してそれをインテグレーションしていくというよく見る図です。
これに対して「SpaceX」ですが、要求分解側は
「Identify Key Design Parameters」
「Adjust Key Design Parameters For Optimum System Performance to meet Top Level Requirements」
（トップレベル要求を満たす、最適なシステムパフォーマンスを実現するための主要な設計パラメータを特定し調整する）
という表現をしています。また、インテグレーション側では Verification を行うのはトップレベル要求に対してのみで、下位では
「Qualify units to predicted/measured environments」
（予測/測定環境に対するユニットの認定）
という表現をしています。
これだけだとよくわかりませんが、ページの下に次の一文があります。
「possible to trade key design parameters between subsystems to optimize results because designers not separated by contract-subcontract bounds」
つまり、要求の境界がないので最適なシステムパフォーマンスを実現するための主要な設計パラメータのトレードオフを進められるということですね。
これは Page.6 の
「しかしながら歴史は示している」
「人間が Integration における潜在的な問題を予測するのが苦手なことを」
という前提に対する回答ではないでしょうか。潜在的な問題が出ても要求が分解されている以上、分解された枠内で解決しないといけません。そしてそれが不可能な場合は、Ｖ字モデルのはじめからやり直しになります。
＜Page.13 主要設計パラメータのトレードオフ速度向上＞
ではどうやって「designers not separated by contract-subcontract bounds」するのかというページです。
ここでも Traditional と SpaceX の対比になっていますが、面白いのがSpaceX側の表記が「If SpaceX performed traditional decomposition」となっている点です。
図はサプライチェーンのピラミッドなわけですが、SpaceX は decomposition してないのでサプライチェーンのピラミッドなんてないので、「もし decomposition したらこんな感じ」ということなんですね。
あとはページの下に
「70％ of rocket dry mass is built in house at SpaceX from raw materials」
とあります。ガチ内製ですね。内製してるんで製造技術もトレードオフのパラメータになってきたりしますし、ここもけっこう効いてるポイントな気がします。
※Verificationしないとサプライチェーン間を跨げないですし、そうなるとどうしてもsubconstract側は慎重になりますからね。
※ここでも組織の成り立ちとして Elon Muskという大資本家がいるという前提は無視できません。人件費を気にする株主にしばられて半分以上が技術派遣で構成されたジャパニーズトラディショナルビッグテックカンパニーでガチガチの内製型組織なんていまさら作れるんかいな？
＜Page.14 システム相互作用を予測しようとせず、経験を通じて学習する＞
ここも Traditional と SpaceX の対比ですね。
Traditional側は「Plan -> Design -> Build -> Test」という単一のサイクルで製品化しようとしています。そして、単一サイクルでやろうとするので、投資を抑制するために「Mandates Heavy Systems Engineering」されている、と表現されています。
それに対して SpaceX側は「design-build-test」によって設計とその結果を伝える、と表現されています。
あとはページの下に
「Documentation and process becomes more formal as systems move into later cycles Final qualification, first flight and production」
（最終認定、初飛行、および生産に移行するにつれてプロセスは正式化され文書化される）
と書かれています。
＜Page.15 飛ぶものをテストする＞
「Test Like You Fly, Test What You Fly」というタイトルのページです。
「Integrated testing tools are a key investment and provide points where integration is assessed and ensured using a ―Test Like You Fly? approach」
という文がはじめに来ています。テストツール（テスト環境）は重要な投資項目で、可能な限りFlight環境に近い状態でテストしていくよ、という感じでしょうか。
そして、その下に
「・Ironbirds at Hawthorne - hardware-software integration」
「・McGregor engine test - engine and avionics integration in real dynamics environment」
「・McGregor stage test firing - tanks, plumbing, avionics and propulsion integration in real dynamics environment」
「・Launch site Hadrware in the Loop Simulations - hardware-software integration with all system components」
「・Launch Site Wet Dress Testing and Static Fire - hardware-software integration with all system components in real dynamics environment」
とテスト環境に関して箇条書きにされています。このあたりはわりと伝統的なテストをきっちりやっているという感じですね。テストにも種類があるようで、次ページに詳細があります。
＜Page.16 柔軟なテスト階層＞
「Flexible test hierarchy increases formality as product matures」というタイトルのページです。
箇条書きでテストの種類が書かれています。
・Development Tests 開発テスト
「Development Tests used to determine hardware capability in excess of requirements and to find weaknesses (running at extended temperatures, ultimate strength tests)」
要求以上の負荷をかけて weakness を見つけていくというやつだそうです。
・Qualification Tests 認定テスト
「Qualification tests demonstrate hardware performance limits (worst case flight conditions plus required factor of safety or margins). Qualification tests are performed every design/environment combination」
こっちは性能限界を確認するテストですね。
・Acceptance Tests 受入テスト
「Acceptance Tests verify workmanship and functionality. All hardware acceptance tested」
製造上の問題がないか、機能を確認するテストですね。
・Hardware in the Loop
「Hardware in the Loop shows hardware-software integration. Run for every
hardware-software change」
HILsですね。every hardware-software change に対して実施されるというのはなかなかすごいです。
そして、このページと次のページに下記のテスト項目と写真が載っています。
・M1C Merlin Engine Foreign Object Ingestion Demonstration Test
（インペラにWedged nutが突き刺さっている写真）
・Thermal qualification of F9 separation system
・Development Test - Composite Overwrap Pressure Vessel Ultimate
・Thermal qualification test of Dragon Claw - connection between Dragon and Trunk
・F9 First Stage Qualification Tank at McGregor, TX
・Second Stage Acceptance Test Flight 3 - McGregor, TX
・Dragon Trunk - Falcon 9 Second Stage Separation Qualification Test
・Draco(Dragon Thruster) Acceptance Testing
・Merlin Nozzle Carbon Coating Development Test
・Dragon Eye Dragon Rendezvous Thermal Sensor Shuttle Development Flight Test
・Space Station End To End Communications Testing
＜Page.18 テストプロセス at SpaceX＞
どどん、と一枚絵です。これは載せた方がはやいですね。
＜Page.19 まとめ＞
まとめページです。
「・It is difficult to build a creative high performance engineering culture」
（クリエイティブで高パフォーマンスなエンジニアリング文化を構築するのは難しい）
「・It is really easy to ruin the creativity and performance by too much organization, rules and process」
（組織、ルール、プロセスが多すぎると創造性とパフォーマンスが簡単に失われます）
「・SpaceX is achieving a good balance of creativity and systems engineering for agility and affordability」
（機敏さと手頃な価格のためにSpaceXは創造性とシステムエンジニアリングのバランスを取っています）
あと、開発コストと開発期間の表がページの下に載っています。
・Falcon 1 Development => 3years,4months and $90M
・Falcon 9 Development => 4years,7months and $300M
・Dragon Spacecraft => 4years,3months and $300M
・Falcon 9 Integration Hangar => 12months and $1.25M
・Hypergolic Test Facility => 12months and $2M
・Falcon1 Launch Pad => 6months and $10M
このページのまとめはざっくりしすぎていてあまり面白みはないですが、開発期間の短さだけはやはり際立ちますね。
