年の瀬に Joel Test で自己評価 - 職業プログラマの休日出勤

Joel Test（ジョエル・テスト）とは、もう12年も前のものではありますが、ソフトウェア開発チームの良し悪しを測定するための、良くできたテストです。12個の質問に Yes / No で回答していき、 Yes の数が点数となります。
もちろん得点は高いほど良く、12点は「完璧」、11点は我慢できる範囲内、10点以下は深刻な問題を抱えたソフトウェア開発チームだ、という評価になります。
原文はこちら　⇒ The Joel Test: 12 Steps to Better Code - Joel on Software
日本語訳が必要な方は、探せばすぐに見つかるでしょう。きっと。

なぜ今 Joel Test をやってみようと思ったのかと言うと、2週間くらい前に見かけた豪州のソフトウェア開発会社の求人広告の中に「ウチは12点満点でっせ。どや」というのがあったためです。
そう、開発者としては、12点を取れる環境というのはとても魅力的に映ります。
テストが作られたのが12年前ということもあり、結果をそのまま鵜呑みにする訳にもいきませんが、反省と来年以降の活動のために、大いに参考にしたいと思っています。

評価対象チームと、それぞれの背景

現在従事しているチームだけだと面白くないので、僕が過去に日本で所属していたチームも評価します。

チームA：プロジェクト参加人員150名規模の大規模（？）プロジェクトです。僕はここで4人から8人の開発者を率いて開発にあたっていました。予算規模は不明ですが、相当な資金が投入されたはずです。
チームB：中規模（？）な情報システムを永年にわたって改修／拡張していくプロジェクトです。いわゆる受託開発です。参加人数は少ない時で4人。僕は主に新機能開発を担当していました。
チームC：こちらも情報システムを永年にわたって改修／拡張していくプロジェクトです。規模は小さく、参加人数は2人から3人。僕は現在ここで従事しています。受託開発ではなく、システムの内製をやっていることになります。

問１：Do you use source control?

ソースコードのバージョン管理をしているかい？　という質問です。
こういう仕組みが無いと、チーム内の他の誰が何をしたか、きちんと把握できないでしょ？という話ですね。

チームAでは当然のごとくやっていました。当時はGitは普及しておらず、Subversionを利用していました。結果○。
チームBでは、使用している開発ツールがバージョン管理ツールのいずれとも相性が悪く、残念ながら使用することができませんでした。結果×。
チームCでは、当初は使用しておらず、ソースコードのコメントに「○年○月○日　修正ここから　by○○」というのが残されている状態でした。僕はこの惨状を見て、バージョン管理の導入を急ぎました。チームが小規模であり分散もしていないことから、GitではなくSubversionを導入しました。結果×⇒○。

問２：Can you make a build in one step?

たった１つの操作でビルドできるかい？　という質問です。
開発対象がスクリプト言語系のWebアプリなどの場合はビルドという概念はありませんので、ソースツリーを一発で出力できるかどうかを評価しましょう。

チームAではSubversionからソースを出力してビルドするまでを全てこなすAntのスクリプトが用意されており、もちろん○です。このチームでは構成管理を専門に引き受けるチームが存在し、頻繁なビルドと頻繁なテストを進めても十分に耐えられる体制でした。
チームBでは、このような仕組みを導入することが非常に難しかったです。やはり、バージョン管理ツールを導入できないというのは大きな痛手です。結果×。
チームCでは、当初はこのような仕組みは全く存在しませんでしたが、必要な処理を全て bash のシェルスクリプトで準備しました。結果×⇒○。

問３：Do you make daily builds?

毎日ビルドしているかい？　という質問です。
毎日ビルドすることは、間違いに素早く気付くことができるため、開発チームには非常に大きな効果をもたらします。

チームAでは、確かに毎日ビルドしていました。日々大きな修正が入るため毎日ビルドせざるを得なかった、というのが正しい表現でしょうか（笑）。結果○。
チームBでは、これもできていませんでした。問１が×だったら、ここまで尾を引きますね。結果×。
チームCでは、残念ながら毎日ビルドしていません。シェルスクリプトを１つ流すだけなのに（泣）。やっていない理由は、チーム内で同じ部分を修正することが発生し得ないから、です。今後、チームが拡大していくようであれば、毎日ビルドすることを当然検討しなければなりません。結果×。

問４：Do you have a bug database?

バグのデータベースを使用しているかい？　という質問です。
脳内バグデータベースは上手く行かないよ、と作者様も言っておられます。我々にももちろん無理です。

チームAでは、これ専用の商用製品を導入していました。開発中にこのデータベースが破損するという大事件が発生しましたが、翌日にはバックアップから復旧していました。結果○。
チームBでは、バグのデータベース（Webアプリ）を内製してしまいました。というのも、商用だったりOSSのバグデータベースは利用者として技術者を想定しているものがほとんどですが、このチームでは一般のシステム利用者にもバグ報告をしてもらう文化があったためです。よりシステムの実態に合わせた入力項目を設けていました。結果○。
チームCでは、Excelという形ではありますが、作者様が原文で挙げられている要素も全て網羅しており、確かにバグデータベースとして稼働しています。チームの人数が4人以上になったらもう無理なので、早くRedmine等に移行したいところです。結果○。

問５：Do you fix bugs before writing new code?

新機能を追加する前に既知のバグを修正しているかい？　という質問です。
既知のバグも放置すればするほど対応にコストがかかるようになっていっちゃうよ？　という理屈ですね。

チームAでは、いわゆるウォーターフォール式のプロジェクトであり、新機能の追加という場面はそれほど発生しなかったことから、バグを先に修正するという行動を取れていました。結果○。
チームBでは、バグの内容に応じて、先に修正するのか新機能を優先するのかの判断が下されていっており、これで上手く運営できていました。規模がこれから少しでも大きくなればこの運用は無理だなー、という印象は確かにあります。結果×。
チームCでもチームBと同様の状態です。小規模だからこそ助かっています。結果×。

問６：Do you have an up-to-date schedule?

最新のスケジュールは存在するかい？　という質問です。
原文には「It will be done when it's done!」という迷言が提示されていますが…

チームAでは、さすが大規模プロジェクト（？）、製品よりも最新スケジュールのメンテナンスを優先する程の勢いでした。皮肉にも、結果○。
チームBでは、ここは上手く回っていたように思います。結果○。
チームCでは、残念ながら「It will be done when it's done!」な状態です。結果×。

問７：Do you have a spec?

仕様書はあるかい？　という質問です。

チームAでは、かなり詳細な仕様書を作ってから開発するスタイルでした。その詳細さは職業PGにわかるFizzBuzz - 日々常々に匹敵するほどでした（泣）。「日本語ってのはプログラミング言語じゃないんだよ」と日々叫んでおりました。結果○。
チームBでは、提案資料とプログラムだけしか存在しない状態でした。「どんな仕様になっているのか？」の問いには、プログラムから仕様書を起こして提出するという状態でした。結果×。
チームCではチームBと同じく、提案資料とプログラムだけが存在する状態です。僕は（頻繁に変更の入るシステムにおいては）仕様書を作りたがらないので、システムの画面から仕様が読み取れるように仕組みを整えていっています。そこでもまかないきれない部分はソースコードのコメントが仕様書、になります。でもまだ十分ではないので、結果×。

問８：Do programmers have quiet working conditions?

プログラマは静かな場所で作業できているかい？　という質問です。

これに関してはチームAからC、全てにおいて×です。
いずれのチームにおいても、顧客や同僚などからの電話がよく鳴り響きます。
これはどのチームもパッケージ製品の開発ではなく、利用者と折衝しながら勧めるシステム開発であったため、仕方のないことでもあります。
日本で「システム開発」を担っているプログラマならば、ほぼ×の環境に居るのではないでしょうか。

問９：Do you use the best tools money can buy?

最良のツールを取り揃えているかい？　という質問です。

チームAでは、予算が潤沢だったためか、かなりの投資がなされていました。１ライセンス数百万円するようなツールを僕のチームのためだけに用意してくれたこともありました。もちろん、その効果は絶大でした。結果○。
チームBでは、開発ツールとしては○ですが、ビルの空調が上手く動作しておらず二酸化炭素濃度が高かったり、ビルのトイレの稼働率が異常に高かったりしたため、設備投資は十分に為されていなかったと判定できます。物理的な環境という面では劣悪でした。結果×。
チームCでは予算が無く（泣）、工夫とOSSの駆使でどうにか回している状態です。結果×。

問１０：Do you have testers?

専任のテスト担当者は居るかい？　という質問です。
時給100ドルのプログラマにテストさせるよりも、時給30ドルのテスターにテストさせた方が金銭的にも効率的でしょ？という話も原文には掲載されています。確かにそうですね。

チームAでは、居ました。こういうポジションには新人が割り当てられることが多いのですが、熟練したテスターも居ました。僕のチームもテストを担当していた時期もあります。結果○。
チームBでは、居ませんでした。これはやはり小規模だからでしょうか。結果×。
チームCでは、やはり居ません。結果×。

問１１：Do new candidates write code during their interview?

新人を雇うとき、面接の時にコードを書かせているかい？　という質問です。
コードを書かせると、あれこれ質問するよりも率直に能力が見えてきますからね。

日本の情報システム開発のほとんどは、業務請け負いと派遣で成り立っており、特に後者が多いです。チームAやチームBも例外ではありません。新しいメンバーをチームに加えることは、新しい派遣人員を呼ぶことを意味します。派遣を雇うときは「事前面接」は法律で禁止されているので、この問いに対しては結果×となります。
もちろん直接雇用であれば問題無い訳ですけどね。

チームCでは直接雇用なので（しかも日本ではないので）コードを書かせることも自由なのですが、やっていません。僕が新人さんと面談する時は代わりに情報セキュリティの質問を多く投げ掛けています。「○○という攻撃に対して、どのように防御しますか？」と問います。知識がある人はすんなりと回答しますし、知識が無くても情報技術の基礎を知っていて思考力があれば回答できますので、これで人を振り分けています。でも最近はコード書かせた方が良いような気もしています。結果×。

問１２：Do you do hallway usability testing?

ユーザビリティのテストをしているかい？　という質問です。

チームAでは、実際のユーザがテストに参画するのは本番導入と試験運用のときでだけでした。開発者によるユーザビリティ観点のテストは、予算が削られてしまったのでしょうか、一切実施しないことになっていました。プログラマの中ではユーザビリティの低さに耐えかねて、勝手に仕様を変更してしまうことも時々見受けられましたが。結果×。
チームBでは、システムの開発中から積極的にユーザが試用するという文化が根付いており（これはバグ・データベースの話にも通づるところがあります）、多くの意見が寄せられていました。開発会社の上長もユーザビリティを気にする人材が多く、結果○。
チームCでは、UIデザインを担当している者が居り、その人物によるテストはほぼユーザビリティのテストになります。結果○。

評価結果

	チームA	チームB	チームC(当初)	チームC(現在)
問１	○	×	×	○
問２	○	×	×	○
問３	○	×	×	×
問４	○	○	○	○
問５	○	×	×	×
問６	○	○	×	×
問７	○	×	×	×
問８	×	×	×	×
問９	○	×	×	×
問１０	○	×	×	×
問１１	×	×	×	×
問１２	×	○	○	○
合計	9点	3点	2点	4点

感想

チームAの得点が高いのは、やはり予算の都合が大きいと感じます。でも、それでも9点なのですね。
チームBはバージョン管理さえ導入できる環境にあれば、一気に得点を３つほど追加できるのですが、これは悔しいところです。
チームCは、僕が着任してから伸ばすことができたのは2点だけでした。次は問6と問7に○が付けられるようにしたいと思います。
12点満点を取るのは、やはり相当な労力と、経営陣の理解が必要です。例えば技術者の努力だけでは問9は○にはなりませんからね。冒頭に掲げた求人広告を出した企業は、かなり良い環境なんだろうなと思います。