Better is the enemy of good

＜よりよく＞することは、＜よい＞ことの敵である
　　　　-- フォン・ブラウン

これはV2ロケットの開発者にしてアポロ計画の立案者であったフォン・ブラウン氏の言葉である。

クリステンセン的に読めば、「持続的イノベーション」から「破壊的イノベーション」は生まれないということだろうか。

東大宇宙航空研を長年率いてこられた斎藤成文氏の著書（初の国産人工衛星「おおすみ」打ち上げまでのトラブルシューティングの物語である）では、この言葉を次のように評している。

サブシステムの担当者が自分の受け持ちの部分をよりよくしようとするが、そうするとシステムの全体としての信頼性はバランスを失して悪くなる

これはソフトウェアにもあてはまるし、まさにエンジニアリングの本質を言い表している。特に息の長いシステムソフトウェアはアプリケーションのニーズやハードウェアの進化に合わせて、リバランスする必要があり、エンジニアの飯のタネはなくならないと思う。もちろん時代の流れにキャッチアップしていくためにも、日々勉強は欠かせないが。

似たような話として、インタネットのEnd-to-end原則について書かれた長健二郎氏の文章から引用。

TCPはパケット損失率が1%程度までなら、ほとんど性能低下なしにエラー修復ができるので、リンク層におけるエラー低減はパケット損失率1%程度を達成すればよい。ところが、往々にして無線技術者はオーバーエンジニアリングしてしまい、リンク層とTCPのエラー修復機能が不整合を起こして、全体の性能が低下する事態を招く。つまり、個別の技術を独立に最適化するのではなく、バランスを考えた設計が求められるのである。

OS失敗学の題材として、バランスの問題を取り上げるのも一つのアプローチだな。

また、Joel Spolskyの「Best Software Writing」では、Mary Poppendieckの「チームへの報奨」を取り上げている。知識労働者のパフォーマンス測定がいつも反生産的だという議論を行っているが、ソフトウェア開発における部分最適化の弊害について次のように書いている（P.154）。

鎖の一部だけ最適化しようとするとき、必然的に全体のパフォーマンスは部分最適なものとなる。部分最適化の最もわかりやすい例は、ソフトウェア開発が、サポートや保守と分断される場合だ。開発者がもっぱらスケジュールに間に合わせることで報いられるなら、彼らは自動化されたテストスイートを書いたり、インストーラを作ったりせず、脆弱なコードを書くようになる。そのシステムのサポートや保守には、開発で節約したのよりずっと多くのコストがかかるだろう。

蛇足になるが、この本を知ったのは「科学書乱読術」という書評集？がきっかけだった。この本からトラブルシューティングネタをもう一冊紹介すると、「だれがタコマを墜としたのか」は未読なので読んでみたい。これはタコマ橋というアメリカの吊り橋の崩落事故を日本人である著者が現地取材を通して調査するというドキュメンタリである。この事故から得られる教訓を勝手に解釈すると、業界の偉い人が言っているから正しいと盲目的になるのではなく、技術の本質を捉えることが重要ということかな。現実的にそれを通すのは難しいかもしれないけど、自分の作るソフトウェアに関してはそうありたいな。この事故に関しては「失敗学のすすめ」でも取り上げられていた。