ソフトウェア開発現場の質を素早く測る「ジョエル・テスト」

User Interface Design for Programmersの著者であるJoel Spolskyという研究者(現在はFog Creek Softwareという会社のCEO)のコラムを読んでいたら(日本語版もあります)、ジョエル・テストという興味深いリストを見つけました。


どうやらSEMAというソフトウェア開発プロセスの健全度を測定する手法があるらしいのですが、それがあまりに複雑で試すのが面倒だということで、ジョエル氏は「いいかげんだが3分で終えられるテストを考えてみた」そうです:)


以下、日本語版より引用。


ジョエル・テスト

  1. ソース管理システムを使っているか?
  2. 1オペレーションでビルドを行えるか?
  3. 毎日ビルドを行うか?
  4. 障害票データベースを持っているか?
  5. 新しいコードを書くまえにバグを修正するか?
  6. 更新可能なスケジュール表を持っているか?
  7. 仕様書を持っているか?
  8. プログラマは静かな労働環境にあるか?
  9. 買える範囲で一番良い開発ツールを使っているか?
  10. テスト担当者はいるか?
  11. プログラマを採用するときにコードを書かせるか?
  12. 「廊下での使い勝手テスト」を行っているか?

補足しておくと、障害票データベースとは発見したすべてのバグを記録するデータベース、「廊下での使い勝手テスト」というのは、「廊下を通る隣人を捕まえて、自分が書いたばかりのコードを使ってみてもらうこと」だそうです。5人にやってもらえば、コードの中にある使い勝手の問題点を95%は知ることが出来るだろう、とのこと。

そして、その採点は以下の通り。

12点は完璧で、11点は許せる範囲だ。だが、10点以下だったら君は本当に深刻な問題を抱えていることになる。実際のところ、大半のソフトウェア開発組織は2点か3点の状態で仕事をしている。そして、彼らは本当に助けを必要としている。なぜなら、マイクロソフトのような会社は常に12点の状態でいるのだから。

そして、ジョエル・テストの使い方はこんな感じ。


ジョエル・テストの4つの使い方

  1. 君のソフトウェア組織についてテストして私にランクを教えてくれれば、言いふらしてあげる
  2. 君がソフトウェア開発チームのマネージャならば、君のチームが出来る限りよい状態にあるかどうかを確認するチェックリストとして使える。12点になったら、君はプログラマ達に自由にやらせておき、営業担当者がプログラマを邪魔することを阻止することに集中できる。
  3. 君がプログラミングの仕事を受けようかどうか決めるところだったら、未来の雇用者にこのリストでその会社が何点かを聞いてみることだ。点が低すぎたら、君がそういったことを正す権限を持てることを確認することだ。それができなければ、君は不満が溜まり、生産的に仕事ができないだろう。
  4. 君が投資家で、プログラミングチームの価値について正しい判断を下す必要があるか、君のソフトウェア会社が他社と統合することを検討中ならば、このテストによってすぐに大雑把な判断ができるだろう。

ソフトウェア屋さんが、現在の職場やこれからの職場の能力を測る上で(そして悲劇に遭わないようにするために)、きっと役に立つテストと思います:)