Russ Olsen氏がGOTO Berlin 2015カンファレンスで“To the Moon”と題した基調講演を行い， 宇宙計画とソフトウェア開発の類似点について論じた。
InfoQはOlsen氏にインタビューして，期限に間に合わせるためにすべてを同時に実行する方法の問題点，失敗や成功から学ぶということ，ソフトウェア開発において些細なことがいかに命取りになるか，複雑な作業において各詳細に集中して対処するにはどうすればよいか，といった話を聞いた。
InfoQ: 今回の講演は大半が最初の月面着陸の話題でしたが，このような構成にしたのはなぜでしょう？
Olsen: “すべてが変わる”というフレーズがよく使われるのは，よくご存知だと思いますが，実際に何かが変わったという話を聞くことはめったにありません。ましてや，すべてが変わったなど聞いたこともありません。ですが，あの日曜日の午後に人類が月面に着陸したことで，少なくとも私にとっては，すべてが変わりました。突然，私の人生の進むべき方向が，大人になった時にやりたいことが分かったのです。それは私だけではありませんでした。その日を境に人生が変わったという，たくさんの人たちに会ったのです。私は長い間，不幸にしてその場に居合わせなかった人たちに，私の経験を理解してもらおうと努力してきました。それがうまくいった唯一の方法が，その強烈な瞬間瞬間を，私と一緒に追体験してもらうことだったのです。そこで今回の講演，という訳です。
InfoQ: 宇宙計画では，期限に間に合わせるために，すべてを同時に行うという方法を取りました。同じことがソフトウェア開発でも見られるということでしょうか？この方法に効果はあるのですか？
Olsen: ApolloプロジェクトにおけるNASAの状況は，不可能に近いプロジェクトを考えられない期間で完了しなければならない，というものでした。タイムラインは，“ステップ１の上にステップ２を配置する”ようなプロセスを論理的に許していません。そのため，彼らが最終的に採用したのは，必要なことのリストを作ってそれを全部同時に実行し，最後に組み上げるという単純な方法でした。これは恐ろしく不効率な方法です – 組み合わせた時に正しく動作しないコンポーネントがあるのは目に見えていますし，同じ問題が他でも起きていることが分からないので，同じ対策を何度も行うことになるからです。全体的な設計変更を行えば，作業の手戻りも膨大になります。
Apolloプロジェクトの異常さを最も顕著に表しているのは，母船の背面に搭載された巨大なエンジンです。このロケットエンジンはもともと，母船が月面から離れる時のために設計されたものでした。ところが，プロジェクト全体のデザインが固まっていく中で，母船とは別に，専用の着陸船が用意されることになったのです。そのため，最終的に母船は月に着陸しない – つまり離陸する必要もない – ことになりました。結果として母船には，巨大なロケットエンジンは必要なくなったのですが，すでにそのように設計されていたため，そのまま残しておく方が簡単だったのです。
残念なことに，このような“先に全部作っておいて，後で統合する”というテクニックを使用しているソフトウェア開発を目にすることが非常に多いのです。それはどうやら，私だけではないようです – 講演では，この開発システムを”時代を越えた素晴らしいアイデア”だ，と冗談で言うのですが，皆さん –– 特に開発者 –– はいつも笑ってくれます。なぜこのような方法をとるのでしょう？その理由はNASAの人たちと同じ –– 異常な目標と非常識な開発期間にあります。こう言い換えてみましょう – ソフトウェアプロジェクトを管理していて，不可能な目標と非常識な期限を決めたとしても，そうですね，チームにもよりますが，それをやってのけることがあるかも知れません。たいていは無理ですが，あり得ないこともないでしょう。ですが，成功か失敗かに関係なく，不可能な目標と非常識な期限は，無駄な労力やチームの燃え尽き感，不完全な設計など，さまざまな形で代償となって現れるのです。
InfoQ: 宇宙計画の間違いからどのような事を学べばよいのか，いくつか例をあげて頂けますか？ソフトウェア開発でも同じようなことができるのでしょうか？
Olsen: 航空宇宙技術に対する印象として一般的なのは，顕在的と潜在的の両面での，失敗に対する執拗かつ系統的な研究です。旅客機や宇宙船では，その一部に問題があった場合のための，体系的な質問セットが用意されています。“なぜ失敗したのか？” だけではありません。“どうしてもっと早く分からなかったのか？”，あるいは“他の機体ではどの程度起きているのか？”，“この問題は，より一般的な問題のひとつの例なのか？”という質問も当然あります。さらに，障害とまでは言えないようなもの – 航空宇宙技術のエンジニアたちは例外にも，すなわちダメージには直結しなくても，通常起きてはならないものにも，常に注意を払っています。彼らは障害に対して非常に注意深く，データ駆動かつ統計的なアプローチを取ることが多いのです。
最近はそれほどでもありませんが，ソフトウェア開発者は従来，障害を，“天からボルトが落ちてきた(random Bolts from heaven)”ように扱っていました – 多分，ログサービスが落ちたんだろう，問題を修正して，そのことは忘れよう。もっと悪ければ，ソフトウェア障害をあたかも開発者の道徳的欠陥の証拠のように扱うこともあります – “どうやったら，こんなことが起こせるんだ?!!”と言うのは，ソフトウェア障害に対する反応として理解はできますが，生産的ではありません。異常な動作を無視する傾向もあります – 壊れていなければ修正するな，というように。たまに異常が起きる以外，システムは故障していないのですが，そのシステムは必死にあなたの気を引こうとしている，いまにも倒れそうなのを告げようとしているのです。
ソフトウェアシステムは多数の部品で構成された複雑な機械である，と見ることができます。そうであるならば，システムに関する実際のデータ –– 障害や“奇妙な”問題も含みます –– を収集し，そのデータに基づいたシステム理解の構築を考えなくてはならないのは自明なことです。
InfoQ: 成功していること，うまくいっていることからは，どのように学べばよいのでしょう？あなた自身の見解と，それがソフトウェア業界で十分に行われているかを教えてください。
Olsen: 私がソフトウェア業界で何度も目にした問題は，成功したプロジェクトから学んだことを，あまりにも一般化しているという点です。プロジェクトは明確な目標，熱意を持ったユーザ，確かな技術，柔軟な思考，優れたドキュメントを持って開始されます。そこでよく口にされるのが，“プロジェクトはうまくいった，設計資料もよくできている！”，あるいは，“私たちは毎日１時間，ユーザとミーティングしている。そこであがった要件はすべて実現した”，“要件はすべて理解した”，といったこと，まさに魔法の弾丸ですね！問題なのは，複雑なソフトウェアシステムには，正しく実現しなければならない機能が数百万もあることです。成功したのならそれは素晴らしい，その成功の根本要因をぜひ特定してください。ただし注意して欲しいのは，要因(causes)は複数形である，ということです。
InfoQ: 宇宙では些細なことが命取りになる，という話をされていましたが，ソフトウェア開発でもそうなのでしょうか？
Olsen: ソフトウェア開発で重要なのは，全体の構造が適切であることです。システムとして全体設計の正しさが不可欠なのは当然ですが，いくら設計がよくても，実装が貧弱であっては大して役に立ちませんまたは実装がいくら優秀でも，バグがたくさんあるようなシステムでは，誰も喜んでくれないでしょう。多くのソフトウェアシステムが，“マイナー”なバグでその価値を損ねているのは間違いありません。
InfoQ: 複雑な作業を行う上で，重要な事は何でしょう？具体的な問題には，どのように対処すればよいのでしょうか？
Olsen: 講演の中で理解してもらいたかったのは，月ロケットや，おそらくは中規模の企業システムのように複雑なものを構築する場合，失敗は避けられないということです。もう一度言います – 失敗はあります。ソフトウェア開発者は，さまざまな問題解決を試みて日々を過ごしています。彼らは夜や週末にも，問題を正しく処理するための方法を探しているのです。しかしながら，過去半世紀にわたるプログラミングの歴史から私たちが学んだのは，不良率を下げることはできても，ゼロにするのは不可能だということです。ですから私たちは，障害が発生することを前提として，その障害に対処可能なように私たちのシステムを，組織を，私たち自身を構築する必要があるのです。この機能，このサービス，このシステムを，現実的に可能な限り信頼できるものにするために，できる限りの努力をするというのが正しい姿勢です。その上で，問題が発生した場合に何をすべきか，ということに取り組んでください。米国の宇宙計画からの有名なことばに，“失敗という選択肢はない(Failure is not an option)”というものがありますが，失敗が確実なものである大規模ソフトウェアシステムの開発に関しては，それは正しくありません。問題はただひとつ，あなたとあなたのシステムが，失敗に対する準備ができているかどうかなのです。
InfoQは，12月3日と4日に開催されるGOTO Berlinカンファレンスの状況をお伝えする予定だ。まだご覧でないならば，氏が３月にQCon Londonで行った以前のバージョンの講演を見ることができる。