9/2にロシアの宇宙船ソユーズが500回目の打ち上げを行いました。
(http://www.afpbb.com/articles/photo-slide/3059216?pno=1#/0 (c)AFP/KIRILL KUDRYAVTSEV)
このソユーズですが、1967年初飛行以来ずっと現役で、改良はあるものの50年も前に設計されて確立された技術が使われていることになります。
一方、アメリカのスペースシャトルは、コストが高騰したアポロ計画を受けて、再利用可能な宇宙船として1981年に初飛行しますが、二度の死亡事故と運用コストの問題で2011年に計画は終了してしまいます。
ソユーズとスペースシャトル、単純にソユーズがよくてスペースシャトルが悪いというような図式では比較することは出来ませんが、ソフトウェアの開発、保守という点で教訓とするべきことが多数あります。
私なりに考え方をまとめてみました。
目次
ソユーズとスペースシャトルの比較
まずはソユーズとスペースシャトルの比較について。
ソユーズ
3人乗りのロシアの宇宙船です。
(https://en.wikipedia.org/wiki/Soyuz_(spacecraft))
使い捨てで毎回新しい機体を作り直しています。
1967年初飛行と基本設計は古いものの、いまだに現役で唯一のISSへの有人輸送が可能な宇宙船です。
過去発生した死亡事故には以下のものがあります。
1967年、ソユーズ1号は、パラシュートが開かなかったために、飛行士が地面に激突し最初の死亡事故が起こりました。
1971年、ソユーズ11号では、バルブの欠陥で機内の空気が漏れてしまったために、3名の飛行士が全員窒息死しました。
これらの問題は初期の段階で改良がなされ、現在問題は解決しています。
ソユーズに使われている技術は「枯れた」技術であるものの、現在も現役であり、既に40年以上も死亡事故を起こしておらず、信頼性は極めて高いと言えます。
スペースシャトル
再利用可能にすることで、運用コストを下げることを目標に開発されたアメリカの7人乗りの宇宙船です。
コロンビア、チャレンジャー、ディスカバリー、アトランティス、エンデバーの5機のオービタが生産されました。
(https://en.wikipedia.org/wiki/Space_Shuttle)
スペースシャトルは、1981年初飛行で、2011年に135回の飛行で計画は終了しました。
1986年チャレンジャー号と2003年コロンビア号の2度の死亡事故と運用費の高騰によって、当初の計画通りにはいかなかったと言えるでしょう。
ソユーズとスペースシャトルの比較
単純に比較することは意味をなさないですが、いくつかのポイントに絞って比較してみます。
コスト
ソユーズの打ち上げ費用はせいぜい50億円前後です。
作り直しなので、機体はすべて新品です。
従って維持費とかはかからないです。
一方、スペースシャトルの打ち上げ費用は約1,200億円です。
また、スペースシャトル1機の値段は、エンデバー号を製造した時の費用で約2,160億円でした。
使い捨て技術の方が有利と言えるでしょう。
安全性 信頼性
安全性、信頼性の面ではソユーズがスペースシャトルを上回ります。
打ち上げ時に、ソユーズでは先端にある緊急脱出用ロケットを使って脱出することが可能です。
一方、スペースシャトルでは、脱出する方法がありません。
打ち上げ時に爆発事故を起こしたチャレンジャー号ですが、ソユーズでは脱出可能だったわけです。
また、帰還時の高温に耐える方法として、スペースシャトルでは耐熱タイルを使うのに対して、ソユーズではアブレータという断熱材を使います。
アブレータは溶けることで熱を逃がすので、帰還するまで持てばよいのです。
一方、耐熱タイルは、繰り返し使えることを目的とするものの、帰還後に毎回ひとつひとつ点検が必要なため、コストが増大する原因となりました。
コロンビア号は、打ち上げ時の耐熱タイルの破損が原因で帰還時に空中分解しましたが、耐熱タイル問題はスペースシャトル計画の失敗の最大の原因の一つと言えるでしょう。
重いものを持ち運ぶ
スペースシャトルは20トンもの大荷物を打ち上げられるという、ソユーズには太刀打ちできないメリットがあります。
ソユーズでは決して出来ないこの技術は、かなり評価できるものです。
ISSの建設には大いに役立ったことでしょう。
ソフトウェア開発とソユーズ
ソフトウェア開発において、ソユーズのスペースシャトルに対するメリットは、大いに学ぶべきことがあります。
最も大事な教訓は再利用に関する考え方です。
コードは腐らない、古いコード、使われているコードはよくテストされている、ゆえに信頼がおけます。
この辺りの考え方は、以下にも記載しています。
新たなソフトウェアを開発する際に、まず、似たようなことをやっているプロジェクトはないかと調べてみるのはよいことです。
この辺りの考え方も、車輪の再発明のところで説明した通りです。
Windowsの変遷
ところで、Windows OSの発売年は、Windows XP以降、次のようになっています。
2001年 Windows XP
2006年 Windows Vista
2009年 Windows 7
2012年 Windows 8
2013年 Windows 8.1
2015年 Windows 10
マイクロソフトのような大企業でも失敗は数多くあるようで、スティーブバルマー自ら「Windows Vistaは失敗だった」と述べています。
つい最近リリースされたWindows 10については、そろそろ評価が出るのでしょうか。
私は、Windows 10からWindows 8.1に戻したのですが。
ちなみに、私の中での順位は次の通りです。
Windows XP > Windows 7 > Windows 8.1 = Windows 8 > Windows 10 > Windows Vista
ログインユーザーをAdministrator権限にすると、すべてのプロセスが管理者権限で実行されるために、セキュリティが甘いと言われたWindows XPですが、後発のWindows Vistaよりは、軽くてはるかに扱いやすかったです。
セキュリティを強化し、UAC(User Account Control)やAeroと呼ばれる派手なユーザーインターフェースの採用など、エンドユーザーの使い勝手のよさや軽さを犠牲にしたWindows Vistaは、多くのユーザーに受け入れられませんでした。
私もWindows Vistaを使ってみて、起動があれほど遅いのは耐えられなかったです。。
Windows XPのダメだったところを、自分の好みで機能をドンドン追加して良くしようとした技術者の失敗と言えるでしょう。
この辺りは、アポロ計画からスペースシャトル計画への変遷にも似ています。
基本的に前より重いもの、ユーザーインターフェース上無理があるものは、受け入れられにくいと思います。
VCS バージョン管理ツールの変遷
バージョン管理システムについて詳しくは以下をご覧ください。
私が主に使っていたバージョン管理ツールは以下のようになっています。
～2003年までVisual Source Safe
2003年から2009年 CVS(Concurrent Versions System)
2009年から2013年 Subversion
2013年から Git
この中で、私の中の順位は次の通りです。
CVS > Subversion = Git >= Visual Source Safe
CVS(Concurrent Versions System)は、1990年に初版リリースですが2000年代前半までは、多くのオープンソース開発プロジェクトで使われていました。
CVSは、データベースを持っておらず、ファイル単位で差分を管理しており、差分が分かりやすく、サーバー移行などに対して管理がしやすかったです。
ViewVCのようなWebベースでビジュアルなユーザーインターフェースもあって、軽くて使いやすかったのも特徴です。
一方、Subversionは、多くのコマンドがCVS互換でCVSから移行がしやすくなっており、また、CVSの悪い点、たとえば、ファイル名の変更ができない、ファイルの移動が出来ない、などの欠点が改良されていました。
ただ、Subversionの致命的な点は、CVSよりも重かった点です。
私の場合、ある程度大きなリポジトリを扱っている場合、チェックアウトするのにCVSよりはるかに時間のかかるSubversionは、使いたくなかったです。
Gitは、CVSやSubversionを嫌いだったLinuxの制作者Linus Torvaldsにって作られたもので、分散型の管理が特徴的です。
ただ、実際の所、分散型で管理する必要のあるような、巨大なオープンソースプロジェクトならいざ知らず、社内で数十人程度開発されるシステムには、必ずしもGitが向いているわけではないと思います。
Gitには、CVSでViewVCを使って出来たような、リビジョンごとに、ファイル単位で差分を
GUIで見るような要望に見合うツールはないようです。
CVSは、2006年以降、更新が行われていな様な「枯れた」システムですが、軽くて、今もWindowsベースの開発なら十分かと思います。
流行というだけで、SubversionやGitを使うのは、必ずしも得策ではないと思います。
まとめ
いかがでしょうか。
枯れた技術って使えると思いませんか。
以下の「枯れた技術の水平思考」とは横井軍平氏の言葉です。
ゲーム＆ウオッチは、5年早く出そうと思ったら10万円の機械になっていた。
量産効果でどんどん安くなって、3800円になった。それでヒットしたわけです。これを、私は"枯れた技術の水平思考"と呼んでいます。
技術者というのは自分の技術をひけらかしたいものだから、最先端技術を使うということを夢に描いてしまい、売れない商品、高い商品ができてしまう。
値段が下がるまで、待つ。つまり、その技術が枯れるのを待つ。枯れた技術を水平に考えていく。
垂直に考えたら、電卓、電卓のまま終わってしまう。そこを水平に考えたら何ができるか。
そういう利用方法を考えれば、いろいろアイディアというものが出てくるのではないか。
ソフトウェアの生産性、保守を語る上で、「枯れた技術」は大事な要素の一つだと思います。
最後まで読んでいただきありがとうござました。
この記事が気に入っていただけたらシェアしてくれると嬉しいです。
コメント