ジョエルテスト

ソフトウェア開発チームの質を3分で評価するテストがある。
ジョエルテストと言われるものだ。

ジョエル・テスト

質問は12問あり、Yes又はNoで答える。
質問内容も至ってシンプルだ。

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

だが、その評価はとても厳しい。

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

他の会社のジョエルテストは下記に書かれている。
はてなは12点満点、アプレッソは10点だそうだ。

はてなのジョエルテスト

アプレッソのジョエルテスト判定結果

プログラムの書けない手配師の会社の多くは、仕様書は書けても、その仕様書はソース管理でバージョン付けする管理はしていないだろう。

プログラミング技術が低いソフト会社の多くは、ソース管理していても、ワンクリックビルドやデイリービルドできる開発環境はないだろう。

デスマーチに陥っている会社の多くは、お客から苦情や非難の電話やメールが開発チームに溢れて、マネージャだけでなくプログラマも電話対応や無駄なミーティングに時間を浪費して、労働環境は最悪だろう。

日本の大手SIerの殆どは、ソース管理やビルドツールは持っていても、BTSでバグ報告を一貫して管理していないから、いつまで経ってもバグが収束せずに納期がズルズルと遅れているだろう。
また、プログラマの採用時にコードを書かせていないから、プログラマの品質がまちまちでプロジェクト管理が大変だろう。

ジョエルテストのチェック項目を振り返ってみよう。

2-1.XPプラクティスの一つであるコードの共同所有。
Subversion、CVSでソースだけでなく仕様書、ビルドスクリプト、ライブラリもバージョン管理しているか？

2-2.ソースをCIしたら、手作業で何度も間違えながらビルドするのではなく、ワンクリックでビルドできているか？
Windowsアプリのように複数のDLLから成るアプリケーションの場合、ビルドモジュールの依存関係まで考慮するから、ビルドは時間も手間もかかりやすい。

2-3.XPプラクティスの一つである常時統合、つまりデイリービルド。
特に大規模プロジェクトで複数チームがソースをコミットする場合、デイリービルドできていなければ、ソースのデグレが多発するだろう。

2-4.BTSでバグ管理できているか？
最近なら、プロジェクト管理機能を持つRedmineやTracを使うのが普通だろう。
RedmineなどのBTSによって「プロジェクトの見える化」がすごく簡単になる。

2-5.新規機能よりもバグ修正を優先しているか？
Redmineのロードマップでバージョン計画を作ると、チケットを優先順位付けせざるを得ない。
その時の基準がこれに当たる。
最近のオープンソースの開発でよく見られる2系統のバージョン管理戦略では、新規機能のブランチと保守ブランチを使い分けるのが普通だろう。

2-6.リアルタイムに保守されたスケジュールを持っているか？
昔なら、各メンバーにプロジェクトリーダーが逐一確認して、MS Projectでガントチャートを時間をかけて保守せざるを得なかった。
最近なら、Redmineのロードマップや、バーンダウンチャート、バグ収束曲線で簡単にスケジュールを作れるだろう。
まさに「プロジェクトの見える化」。

2-7.最近なら仕様書は、テストソースが相当することが多いだろう。
あるいは、Testlinkのように、シナリオベースのテストケースをBTSのようにWebで管理するシステムを使っているだろう。

2-8.プログラマは、割り込みタスクや雑音に惑わされず、集中できる環境にいるか？
プログラミングもできて環境構築もできるユーティリティプレーヤーほど、割り込みタスクが多くて、生産性が低い時が多い。
プロジェクトリーダーの仕事の一つは、プログラマが集中してプログラムを書ける環境を作ることだと思う。

2-9.Eclipseでコード補完する時に、イライラするぐらい遅いマシンを使っていないか？
デイリービルドできるマシンを用意しているか？
プログラマはマルチディスプレイで仕事しているか？

2-10.バグ修正フローでは、バグ修正する開発者とバグ報告を起票して検証するテスト担当者のペアで行う。
駄目なプロジェクトは、プログラマが設計、実装、テストまで全部やっている。
2人以上の目を通らないソースは、必ず漏れがある。

2-11.ソフトウェア開発チームの生産性は、プログラマの生産性にほぼ完全に依存している。
優秀なプログラマを採用するために、書いたコードで確認しているか？

2-12.「アプレッソのジョエルテスト判定結果」でも書かれているが、ユーザビリティは特に最近のWebシステムでは重要だ。
Ajax、Flex/Air、Silverlightなど、手のかゆい機能を実装する技術が最近は溢れている。
この時に、ペルソナシナリオ法を使うという考えは参考になる。

お客からの問い合わせを何度も受けてくると、そのインシデントの傾向、変更要求の傾向が見えてくるものだ。
その傾向から、顧客のキャラクターをペルソナシナリオ法で分析すれば、仮想的なキャラクター像が出来上がるだろう。
そのペルソナがシステムをどのように使うだろうか？という観点で設計や開発すれば、かなり良いシステムが作れるだろうと思う。

PMBOK/CMMI/ITILなどの重量級の開発プロセスやマネジメントのフレームワークを導入するぐらいなら、ジョエルテストをクリアできるようにチームの環境を整える方が早く問題を解決できるだろう。