あなたの会社は何点ですか？
もしあなたの会社がシステム開発会社であったならチェックしてみるのもよいかもしれない。
チェックポイントは以下のとおり。
1)ソース管理システムを使っているか？
2)１オペレーションでビルドを行えるか？
3)毎日ビルドを行うか？
4)障害票データベースを持っているか？
5)新しいコードを書くまえにバグを修正するか？
6)更新可能なスケジュール表を持っているか？
7)仕様書を持っているか？
8)プログラマは静かな労働環境にあるか？
9)買える範囲で一番良い開発ツールを使っているか？
10)テスト担当者はいるか？
11)プログラマを採用するときにコードを書かせるか？
12)「廊下での使い勝手テスト」を行っているか？
自分はこのジョエルテストを著者の本を読んで知って以来、
常駐先の企業やプロジェクト単位で（もちろん自社も含めて）
採点してみたりする。意外な問題点が浮き彫りになり興味深いのだ。
各項目の解説
ちょっと自分の解釈で解説してみる。
1)ソース管理システムを使っているか？
→SubversionとかCVSのことです。
2)１オペレーションでビルドを行えるか？
→コンパイルが必要な言語だと当然だよね。
WEB系のスクリプト言語だと該当なし。
3)毎日ビルドを行うか？
→2)と同じ理屈。日々手が入るようなプログラムだと
必要かな。
WEB系のスクリプト言語だと該当なし。
4)障害票データベースを持っているか？
→バグトラッキングシステムのことだね。
障害票の管理と検索ができるしろものならよい。
チェックポイントの中で一番重要かな。
5)新しいコードを書くまえにバグを修正するか？
→もとからのバグか新規追加のバグか切り分けがつかないとか
覚えているうちに直せってことかな。
6)更新可能なスケジュール表を持っているか？
→最初に引いたスケジュールが実態と合わなくなったら
リスケをするべきということか。
遅れた原因がはっきりしていれば、賛成だね。
7)仕様書を持っているか？
→プログラマはえてしてドキュメントを書きたがらない修正がある。
コードを書いていた方が楽しいので。
でも後々のメンテナンスを考えると必須だよね。
8)プログラマは静かな労働環境にあるか？
→営業さんの怒号やひっきりなしにかかってくる電話。
また実験室からの落下試験の音とか（これは自分の体験ねｗ）
このようなところでは生産性は悪くなるのは必定だ。
9)買える範囲で一番良い開発ツールを使っているか？
→予算の範囲内で、効率をアップするツールは必須だ。
無理に高いツールは買う必要はないけど、
メモ帳で開発するのは無理があるよね。
10)テスト担当者はいるか？
→基本的にプログラムを作った人間がテストすると
動物的カンで危ない箇所を避けてしまう。
またシステムは想定外の動作も考慮しないといけないので
他人にやってもらう方がよい。
11)プログラマを採用するときにコードを書かせるか？
→そこまでする必要があるかとは思うが、
例えば、社員を雇うのであれば、長く付き合う訳で
どんなコードを書くのか事前に知っておくのは
あとで精神的なショックを受けるより、意味がある。
12)「廊下での使い勝手テスト」を行っているか？
→これが一番よく分からないチェックポイントだけど、
自分の解釈ではソースレビューのことかな。
採点すると「あの世界的な企業のプロジェクトが、この点数かよ」みたいなことがよくあるｗ
読んでない人は是非。
コメント