Fast CompanyでNASAの宇宙船のロケットを
発射するプログラムを開発しているロッキード・マーティンという会社の記事が書いてありました。
結構面白かった記事でしたので、英語が読めない方に紹介したいと思います。
もしも、宇宙船のコードにバグがあったら、一瞬で「4千億円」が爆発するのです。
ですから、この会社の宇宙船のコードは「バグフリー」にならなければなりません。
最初のコードレビューのとき、420,000行のコードの中に発生していたバグは、たった17個しかありませんでした。
そんな量で17個しかありませんでした！ものすごいでしょ？
ちなみに、普通社内用ソフトの同じコード量があるソフトになったら、バグは5000個もあります。
しかも、その会社のライフワークバランスは非常に優れています。
宇宙船の開発者のワーキングタイムは9時から5時で、残業は年に数回、しかもコーダーの半分は女性です。
デッドラインに余裕を持って間にあわせることができるし、予算が超えることもありません。
病気になれば、もちろんきちんと休むことができます。
それらを備えた上で、作成されたソフトは「バグフリー」なのです。
いったいどのふうにこのいいコードが書けますか？
しかしながら、この宇宙船のコードを書く人が超人なわけではありません。
彼れはただ、社内で定められた非常にシンプルなルールを守っているだけです。
彼らに設けられたルールは全部で4つ。
1. 設計書を完成させていない状態で、開発を始めることはできません。
宇宙船の設計書はおよそ4000ページにのぼります。
設計書が完成すればデザインを一通り書き、あとはひたすら開発を進めていきます。
宇宙船の開発者マンソンさんは言いました。
「我々は開発にお金をあんまりかけません」
「普通の会社はすぐにアプリを開発し始めます。ですから彼らのコードの8割は保守時に書かれていますね。結構お金をかかりますね。それに比べ、我々は確かに設計書を通常よりも長い期間推敲しますが、プログラムを書くのはたった一回だけです」
2. テストに重きを置きます。
宇宙船開発のチームは「開発チーム」と「テストチーム」の大きく2つに分かれます。
開発者は必ずテストチームにバグを見つけられたくない。
テストチームはバグを必ず見つけ出したい。
しかし、もしもバグを見つけたとしても、怒鳴り挙げることはないし、土下座をすることもない。
そのフレンドリーな競争のおかげで、ユニットテスト前に、85％のエラーを発見することができます。
そして、９９.９％のエラーがNASAのレビュー前に見つけ出されているのです。
これこそ、「バグフリー」の真髄と言えるでしょう。
3. コードにおける追加や変更は、資料やデータベースにすべて反映されます。
そのため、コードレビューの際に、すぐにそのコードの「なぜ」がわかるようになっています。
結果的に、バスファクターは非常に大きな数字となりますね。
誰であっても資料を読めば開発を進めることができますし、データベース上にすべてのエラーが記載されていますから、
開発中のどんなエラーもすぐに原因を判明させることができます。
4. もしもエラーを見つけたら、「なぜ」を5回唱えましょう。
・本当のバグはどこに隠れている？
・なぜこのエラーは出てしまった？
・どのプロセスで間違えてしまった？
・バグの本質は一体何だった？
・この間違いが二度と起きないようにするにはどうしたら良い？
本当の問題が見つけたら、バグフィックスだけでなく、バグが起きた原因の原因まで追求するのです。
いいコードの書き方のまとめ
- ちゃんと設計した後、開発する。
- 開発の経緯をすべて資料にまとめる。
- 作ったものをきちんとテストする。
- 問題があれば、その原因を突き止める。
- 開発についてログを記録しています。問題があったとき、よかったとき、すべてを纏めています。
この4つのルールは決してハードルの高いものではありません。
例えば、自動車業界はすでにそれを実践しています。
だって、自動車に5000個の問題があったら、誰も乗りたがらないでしょう？
では、自分のソフトにも、バグフリーに頑張りましょう！