2006年02月26日
アプレッソのジョエルテスト判定結果
今週末は熱海の温泉に行ってきた。
行き帰りの新幹線で読んだJoel on Software
は衝撃的に良かった。
この本はソフトウェア開発に携わるすべての人が読むべき本だと真剣に思う。
中でも第三章に書かれているジョエルテストが面白かったので、
これをアプレッソに当てはめて判定してみることにした。
現在のアプレッソでは、12のテストのうち、10項目が当てはまっている。
該当する項目が2から3の会社が圧倒的に多いということなので、
判定結果としてはかなり良い方だと思う。
しかし、今は導入した後でその効果を知っているから全面的に賛成できるのだが、導入する前は、
「今のままで特に大きな問題があるわけでもないし、
新しい方法を導入することにはリスクも伴う。
このままでも良いのではないか。」
という理由で導入を躊躇したものも多かった。
これらはどの項目についても、マネージャーがどんなに反対したとしても
導入を推進していくべきだ。
判定結果は次の通り。
1. ソース管理してる？
判定結果: ○
DataSpider の開発を始めたばかりの頃、具体的には2000年末から2001年の夏頃までは、ソースコードの管理は共有ディスクに日付ごとにバックアップフォルダを作成するごく初歩的な管理しか行っていなかった。
共有ディスクのバックアップはきちんととっていたので、この方法でもディスククラッシュによるソースの紛失は避けることができたが、ソース規模の拡大につれ、2001年の夏頃から後述の bugzilla と同時に CVS を導入した。
CVS を導入するときにも、ファイルベースのバックアップで事足りるのではないかという議論もあったが、今ではちょっとしたプロジェクトであっても、CVS なしで開発を行うということはちょっと考えられない。
ファイルベースの単純なバックアップと比べて、CVS を導入した方が良い理由は次の通りだ。
・チーム開発の際の変更箇所の明確化
他のエンジニアの変更した箇所がどこなのかがはっきりとわかる。これによって、実はその箇所をそういう風に変更してしまってはまずい、という点について、すぐに伝えて修正してもらうことができる。特に自分が担当しているモジュールや依存関係の大きいモジュールに変更がかかっていた場合、どこをどう変えたのだろうとすぐに確認できて良い。
・エンバグしたときに何が原因なのかがはっきりとわかる
新バージョンのリリースやパッチのリリースの際にはソースツリーに対してタグを振ることになるが、パッチを適用したところ問題が発生した、というような時に、パッチ以前のバージョンとパッチのソースとを比較して、その差分を見るだけでバグの原因となっている変更箇所が即座にわかることが多い。
・修正の多重化を避けることができる
過去にリリースしたバージョンでバグ修正やエンハンスメント対応を行う際、過去のバージョンと開発中の最新バージョンとの両方に同じ修正を加えるのは効率が悪い。バージョンのリリースごとにブランチを切り、過去のバージョンへのバグ修正の際には最新のバージョンに対してこまめにマージしていけば、修正作業の多重化を避けることができる。
2. ワンステップでビルドできる？
判定結果: ○
makefile には ant を使用しており、タスクとして主に次のようなものを用意している。
・release
CVS から所定のフォルダにソースコードのチェックアウトを行い、
ソースコードをコンパイルし、
難読化を行い、
各モジュールのユニットテストを実行し、
テスト結果のレポートを出力し、
インストーラーを作成するタスク。
要するにワンステップでビルドに関係するすべてのタスクを実行する。
・compile
現在のフォルダ以下の全モジュールをコンパイルする。
・unittest
現在のフォルダ以下の全モジュールのユニットテストを実行し、レポートを出力する。
・obfuscate
現在のフォルダ以下の全モジュールの難読化を行う。
等々。特に release によるミスの減少効果は絶大で、
間違って最新版とは若干異なるバージョンのソースを使ってインストーラーを作ってしまった、
というようなミスが非常に起こりにくくなっている。
特にパッケージ製品を開発する場合には、
ワンステップでビルドできるようにしておくことは効率の面でとても重要だ。
Joel on Software ではこのプロセスの自動化のために Wise から InstallShield に切り替えたとのことだが、アプレッソで使用している InstallAnywhere でもこの手の自動化は問題なく実現できる。
3. デイリービルドしてる？
判定結果: ○
毎晩夜遅くに(というか明け方に)、スケジューラによってデイリービルドが自動的に行われている。朝出社したときには前の晩までにコミットされたソースが反映された最新版のインストーラーが作成されている。
アプレッソでデイリービルドを導入したのは割と最近で、2005年になってから、開発中の機能を社内の SE にいち早く実際に触ってもらい、すばやいフィードバックをもらうために、ということで導入した。
2番目の項目のワンステップでのビルドが実現できていればこの項目の実現は簡単で、スケジューラの設定と十分なディスクスペースさえあれば実現できる。
重要なのは変更や修正がきかない状況になる前に事前にそれらを察知することで、社内のすばやいフィードバックだけではなく、開発チーム内での仕様的なバグの早期の指摘などにもつながるため、この項目についても導入の効果は大きい。
4. バグデータベースはある？
判定結果: ○
バグデータベースとしては bugzilla を使用している。
bugzilla も CVS と同じタイミングで比較的早期に導入した。
導入後にはいくつかの工夫もしていて、例えば重要度は bugzilla 標準の blocker、critical、major、normal などをそのまま利用してているが、プライオリティについては
・P1: 次のリリースまでに対応する。
・P2: 次のリリースまでにできれば対応する。
・P3: 基本的には次々回のリリース以降対応する。
という意味づけを行っている。
bugzilla は開発だけでなく営業・SE もアクセスできるようになっているので、
案件での優先度が高い場合などには P3 になっていたものが、
「○○の案件で至急必要なので P1 でお願いします」
というコメントとともに営業サイドからプライオリティの変更がかかることもある。
バグ管理システムはコミュニケーションツールとしても有用だ。
5. 新しいコードを書く前にバグを直している？
判定結果: ○
どこの会社でもこの項目は当てはまっているかどうか判断に迷うところがあると思うが、少なくともこの本で例に出ているようなプロジェクトのように、return 12; と高さの指定が固定になっているコードが放置されたり、重要な問題があるのに放置して機能追加に邁進したりすることはないので○とした。
スピーディに新機能を追加していくようなフェーズでは、どうしても「ここは後でちゃんとリファクタリングしてきれいにしたい」というところが残ってしまう。
「ソースコードをきれいにしたい」というのは天井知らずで、エンジニアがすっきりするまでどこまでもどこまでも進めていくことができてゴールがない。
問題のあるソースコードを放置して新機能を追加していく開発チームも怖いが、リファクタリングばかりしていてやたらとバッファを長く取っているチームも怖い。
新しいものがでてくることで、古いものがそっくりいらなくなってリファクタリングする必要自体がなくなるソースだってある。
バグとしてレポートされているものであれば目につきやすいしすぐ修正されるけれど、リファクタリングはバグが見つかっていなくてもやらなければいけないケースがあり、それをどこでどの程度やっていくかという判断はかなり難しい。
6. アップデートされているスケジュールがある？
判定結果: ○
この項目の冒頭に出てくる「いつ出来上がるかって？そりゃ、出来上がったときさ！」という台詞にはなかなか耳が痛い。
風のプログラマを目指す私は、ソフトウェアを開発する速度についてはそれなりに自信があるものの、「工期は？」と聞かれて、ピピピッと見通しが立つと「一瞬。」と答えてしまうような危うさもある。
ソフトウェア開発においては、即座にサッと作ってしまうようなスピード感が重要であることもさることながら、きちんと組み立てられたスケジュールがあることで得られる社内外の安心感もとても大切なものだ。
そして、スケジュールを資料として作成することもそれはそれでリスクとしてあって、間違って古い資料が人の目につくところにおいてあろうものなら、ミスコミュニケーションの傾向と対策の資料分散型のミスコミュニケーションが頻発してしまう危険性もある。
だから最新のスケジュールは常に一箇所に管理され、更新があったらそのただ一つの資料が必ずアップデートされなければならない。
アプレッソではこの課題に対処するために、ちょうど昨年の後半辺りから、「スケジュール・バイブル」という考え方を導入した。
これは単に、他のどこに何と書いてあろうが、この資料が常に最新であり正しいです、という意識を共有しましょうということで、現在ちょうど必要な資料を整備して行っているところである。
準備中の箇所もあるという意味では、本当は△かもしれない。
7. 仕様書はある？
判定結果: ○
アプレッソでは社内情報共有に Wiki を使っているのだが、Wiki に「仕様書 / ○○」というエントリがあって、開発の前にここに仕様を書いてから開発を進めることになっている。
この本に書いてある通り、つくってから修正するのには膨大な時間がかかるけれど、つくる前に仕様書を修正するのはそれと比べてずっと短い時間で修正を行うことができる。
ツールの機能の概要や画面構成などのユーザに直接関係する箇所については仕様書をつくるようにし、クラス設計などの詳細設計に近いところでの仕様書については、チーム開発の際に複数の人が利用するインターフェースを事前に決める以外は、基本的に個々のエンジニアに任せることにしている。
はてなの伊藤さんが書いているように、優秀なプログラマのほとんどは詳細設計を行う代わりに直接プログラムを書いてしまう。
だから仕様書を書こう、といっても、どのレベルでの仕様書を書くべきなのか、開発チームの特性に合わせてよく考えて対応していかなければならないと思う。
8. プログラマは静かな環境で作業している？
判定結果: ×
この項目は、アプレッソが始まったばかりの最初の1年くらいは○だった。
当初は「図書館のように静かな開発部屋にしよう」という目標を掲げたり、開発のための部屋を営業・SEの部屋と分けたりしていたのだけれど、
「すぐ聞けることなら聞いてしまったほうが良い」
「営業と開発とで垣根をつくってしまうのは良くない」
等の理由で、あえてプログラマは静かな環境で作業をしないようにしている。
2番目の理由は、垣根を取り払ったことでよい影響もたくさんあったので、
これはこれで今のままでよいのではないかと思っている。
ただ、開発の中でのコミュニケーションですぐ聞いてしまったほうが、というのは、Joel が言うとおり間違えているのかもしれない。
この点については考えなくては。
9. 手に入る最高のツールを使っている？
判定結果: ○
アプレッソには火のプログラマーを地で行っているHさんという人がいて、この点について彼がチームに貢献してくれている部分はとても大きい。
特に開発環境の eclipse については、
「バージョン XX のβ5が出ました。
かなり生産性が上がっているので、みんな便利だと感じると思います。
チーム全体でのアップデートを検討したいです。」
というような提案がポンポンでてきて、開発チームの環境の改善が進んでいる。
ただし、
「なるほど。そのβ5の安定度はどの程度ですか？」
「かなり安定していると思います。」
「期間的にはどの程度使いました？」
「昨日からです。」
などという笑い話みたいなこともあったりする。
(ちなみにこの話は実際に1週間ほど前にあった話である)
10. テスタはいる？
判定結果: ×
この項目で書かれていることは、テストを専門としている職種を設けているかということだが、これはアプレッソでは現在できておらず、プログラマーがテストを行っている。
この点については現在強く課題として認識しており、この本で指摘されていることは至極もっともだと思う。
ちょうど今、このテーマについて検討しているところなのでとても良い参考になった。
11. 採用面接のときにコードを書かせている？
判定結果: ○
はい。書かせています。
これはアプレッソ設立当初からずっとポリシーにしてきたことで、
プログラマーとして応募してくる人には、プログラマーとしての勘や知恵や最低限の概念理解ができているかどうかを確認するために、ソースコードを書く課題をその場で提示して、ホワイトボードかプロジェクターに接続したPCでコードを書いてもらっている。
コードを書いてもらうと、華々しい履歴書では絶対にごまかせないプログラマーとしての能力がすぐに明らかになるので、この方法は、もし導入していないのであればすぐにでも導入したほうが良いと思う。
ちなみにうちでよく出す質問の例としては次のような感じで、この例では一見普通に動作するのだけれど、後で発見しにくいバグの原因となってしまうようなコードを書かない人かどうか、というのがチェックの内容となっている。
質問: このコードが NG な理由は？
public void readFile(String filePath) throws Exceptoin {
InputStream in = new BufferedInputStream(new FileInputStream(filePath));
// do something
in.close();
}
答え: do something 内で例外発生時に close されないから次のようにしないと NG
public void readFile(String filePath) throws Exceptoin {
InputStream in = null;
try {
in = new BufferedInputStream(new FileInputStream(filePath));
// do something
} finally {
if (in != null)
in.close();
}
}
12. ユーザビリティテストはしている？
判定結果: ○
ここはかなり力を入れている点で、私はこれからはエンタープライズソフトウェアであってもその手触りの良さがどの程度のものかということでマーケットでの勝敗が分かれてくると考えている。
なので、2003年からペルソナ／シナリオ法という、ユーザにより感情移入しながらソフトウェアを設計していくためのを導入し、実際に昨年10月にリリースされた DataSpider Servista という製品はすべてこのペルソナ／シナリオ法を使って開発した。
アプレッソのジョエルテストの判定結果は以上の通りである。
このところWoW こと World of Warcraft にはまりにはまって私生活のほとんどの時間をそちらにつぎ込んでしまい、ブログをほとんど書いていなかったこともあり、ずいぶんと長いエントリになってしまった。
Joel on Software はジョエルテスト以外の章も実に読み応えがあり頷ける部分の多い本なので、まだ読んでいない方はこの機会にぜひ。
行き帰りの新幹線で読んだJoel on Software
は衝撃的に良かった。この本はソフトウェア開発に携わるすべての人が読むべき本だと真剣に思う。
中でも第三章に書かれているジョエルテストが面白かったので、
これをアプレッソに当てはめて判定してみることにした。
現在のアプレッソでは、12のテストのうち、10項目が当てはまっている。
該当する項目が2から3の会社が圧倒的に多いということなので、
判定結果としてはかなり良い方だと思う。
しかし、今は導入した後でその効果を知っているから全面的に賛成できるのだが、導入する前は、
「今のままで特に大きな問題があるわけでもないし、
新しい方法を導入することにはリスクも伴う。
このままでも良いのではないか。」
という理由で導入を躊躇したものも多かった。
これらはどの項目についても、マネージャーがどんなに反対したとしても
導入を推進していくべきだ。
判定結果は次の通り。
1. ソース管理してる？
判定結果: ○
DataSpider の開発を始めたばかりの頃、具体的には2000年末から2001年の夏頃までは、ソースコードの管理は共有ディスクに日付ごとにバックアップフォルダを作成するごく初歩的な管理しか行っていなかった。
共有ディスクのバックアップはきちんととっていたので、この方法でもディスククラッシュによるソースの紛失は避けることができたが、ソース規模の拡大につれ、2001年の夏頃から後述の bugzilla と同時に CVS を導入した。
CVS を導入するときにも、ファイルベースのバックアップで事足りるのではないかという議論もあったが、今ではちょっとしたプロジェクトであっても、CVS なしで開発を行うということはちょっと考えられない。
ファイルベースの単純なバックアップと比べて、CVS を導入した方が良い理由は次の通りだ。
・チーム開発の際の変更箇所の明確化
他のエンジニアの変更した箇所がどこなのかがはっきりとわかる。これによって、実はその箇所をそういう風に変更してしまってはまずい、という点について、すぐに伝えて修正してもらうことができる。特に自分が担当しているモジュールや依存関係の大きいモジュールに変更がかかっていた場合、どこをどう変えたのだろうとすぐに確認できて良い。
・エンバグしたときに何が原因なのかがはっきりとわかる
新バージョンのリリースやパッチのリリースの際にはソースツリーに対してタグを振ることになるが、パッチを適用したところ問題が発生した、というような時に、パッチ以前のバージョンとパッチのソースとを比較して、その差分を見るだけでバグの原因となっている変更箇所が即座にわかることが多い。
・修正の多重化を避けることができる
過去にリリースしたバージョンでバグ修正やエンハンスメント対応を行う際、過去のバージョンと開発中の最新バージョンとの両方に同じ修正を加えるのは効率が悪い。バージョンのリリースごとにブランチを切り、過去のバージョンへのバグ修正の際には最新のバージョンに対してこまめにマージしていけば、修正作業の多重化を避けることができる。
2. ワンステップでビルドできる？
判定結果: ○
makefile には ant を使用しており、タスクとして主に次のようなものを用意している。
・release
CVS から所定のフォルダにソースコードのチェックアウトを行い、
ソースコードをコンパイルし、
難読化を行い、
各モジュールのユニットテストを実行し、
テスト結果のレポートを出力し、
インストーラーを作成するタスク。
要するにワンステップでビルドに関係するすべてのタスクを実行する。
・compile
現在のフォルダ以下の全モジュールをコンパイルする。
・unittest
現在のフォルダ以下の全モジュールのユニットテストを実行し、レポートを出力する。
・obfuscate
現在のフォルダ以下の全モジュールの難読化を行う。
等々。特に release によるミスの減少効果は絶大で、
間違って最新版とは若干異なるバージョンのソースを使ってインストーラーを作ってしまった、
というようなミスが非常に起こりにくくなっている。
特にパッケージ製品を開発する場合には、
ワンステップでビルドできるようにしておくことは効率の面でとても重要だ。
Joel on Software ではこのプロセスの自動化のために Wise から InstallShield に切り替えたとのことだが、アプレッソで使用している InstallAnywhere でもこの手の自動化は問題なく実現できる。
3. デイリービルドしてる？
判定結果: ○
毎晩夜遅くに(というか明け方に)、スケジューラによってデイリービルドが自動的に行われている。朝出社したときには前の晩までにコミットされたソースが反映された最新版のインストーラーが作成されている。
アプレッソでデイリービルドを導入したのは割と最近で、2005年になってから、開発中の機能を社内の SE にいち早く実際に触ってもらい、すばやいフィードバックをもらうために、ということで導入した。
2番目の項目のワンステップでのビルドが実現できていればこの項目の実現は簡単で、スケジューラの設定と十分なディスクスペースさえあれば実現できる。
重要なのは変更や修正がきかない状況になる前に事前にそれらを察知することで、社内のすばやいフィードバックだけではなく、開発チーム内での仕様的なバグの早期の指摘などにもつながるため、この項目についても導入の効果は大きい。
4. バグデータベースはある？
判定結果: ○
バグデータベースとしては bugzilla を使用している。
bugzilla も CVS と同じタイミングで比較的早期に導入した。
導入後にはいくつかの工夫もしていて、例えば重要度は bugzilla 標準の blocker、critical、major、normal などをそのまま利用してているが、プライオリティについては
・P1: 次のリリースまでに対応する。
・P2: 次のリリースまでにできれば対応する。
・P3: 基本的には次々回のリリース以降対応する。
という意味づけを行っている。
bugzilla は開発だけでなく営業・SE もアクセスできるようになっているので、
案件での優先度が高い場合などには P3 になっていたものが、
「○○の案件で至急必要なので P1 でお願いします」
というコメントとともに営業サイドからプライオリティの変更がかかることもある。
バグ管理システムはコミュニケーションツールとしても有用だ。
5. 新しいコードを書く前にバグを直している？
判定結果: ○
どこの会社でもこの項目は当てはまっているかどうか判断に迷うところがあると思うが、少なくともこの本で例に出ているようなプロジェクトのように、return 12; と高さの指定が固定になっているコードが放置されたり、重要な問題があるのに放置して機能追加に邁進したりすることはないので○とした。
スピーディに新機能を追加していくようなフェーズでは、どうしても「ここは後でちゃんとリファクタリングしてきれいにしたい」というところが残ってしまう。
「ソースコードをきれいにしたい」というのは天井知らずで、エンジニアがすっきりするまでどこまでもどこまでも進めていくことができてゴールがない。
問題のあるソースコードを放置して新機能を追加していく開発チームも怖いが、リファクタリングばかりしていてやたらとバッファを長く取っているチームも怖い。
新しいものがでてくることで、古いものがそっくりいらなくなってリファクタリングする必要自体がなくなるソースだってある。
バグとしてレポートされているものであれば目につきやすいしすぐ修正されるけれど、リファクタリングはバグが見つかっていなくてもやらなければいけないケースがあり、それをどこでどの程度やっていくかという判断はかなり難しい。
6. アップデートされているスケジュールがある？
判定結果: ○
この項目の冒頭に出てくる「いつ出来上がるかって？そりゃ、出来上がったときさ！」という台詞にはなかなか耳が痛い。
風のプログラマを目指す私は、ソフトウェアを開発する速度についてはそれなりに自信があるものの、「工期は？」と聞かれて、ピピピッと見通しが立つと「一瞬。」と答えてしまうような危うさもある。
ソフトウェア開発においては、即座にサッと作ってしまうようなスピード感が重要であることもさることながら、きちんと組み立てられたスケジュールがあることで得られる社内外の安心感もとても大切なものだ。
そして、スケジュールを資料として作成することもそれはそれでリスクとしてあって、間違って古い資料が人の目につくところにおいてあろうものなら、ミスコミュニケーションの傾向と対策の資料分散型のミスコミュニケーションが頻発してしまう危険性もある。
だから最新のスケジュールは常に一箇所に管理され、更新があったらそのただ一つの資料が必ずアップデートされなければならない。
アプレッソではこの課題に対処するために、ちょうど昨年の後半辺りから、「スケジュール・バイブル」という考え方を導入した。
これは単に、他のどこに何と書いてあろうが、この資料が常に最新であり正しいです、という意識を共有しましょうということで、現在ちょうど必要な資料を整備して行っているところである。
準備中の箇所もあるという意味では、本当は△かもしれない。
7. 仕様書はある？
判定結果: ○
アプレッソでは社内情報共有に Wiki を使っているのだが、Wiki に「仕様書 / ○○」というエントリがあって、開発の前にここに仕様を書いてから開発を進めることになっている。
この本に書いてある通り、つくってから修正するのには膨大な時間がかかるけれど、つくる前に仕様書を修正するのはそれと比べてずっと短い時間で修正を行うことができる。
ツールの機能の概要や画面構成などのユーザに直接関係する箇所については仕様書をつくるようにし、クラス設計などの詳細設計に近いところでの仕様書については、チーム開発の際に複数の人が利用するインターフェースを事前に決める以外は、基本的に個々のエンジニアに任せることにしている。
はてなの伊藤さんが書いているように、優秀なプログラマのほとんどは詳細設計を行う代わりに直接プログラムを書いてしまう。
だから仕様書を書こう、といっても、どのレベルでの仕様書を書くべきなのか、開発チームの特性に合わせてよく考えて対応していかなければならないと思う。
8. プログラマは静かな環境で作業している？
判定結果: ×
この項目は、アプレッソが始まったばかりの最初の1年くらいは○だった。
当初は「図書館のように静かな開発部屋にしよう」という目標を掲げたり、開発のための部屋を営業・SEの部屋と分けたりしていたのだけれど、
「すぐ聞けることなら聞いてしまったほうが良い」
「営業と開発とで垣根をつくってしまうのは良くない」
等の理由で、あえてプログラマは静かな環境で作業をしないようにしている。
2番目の理由は、垣根を取り払ったことでよい影響もたくさんあったので、
これはこれで今のままでよいのではないかと思っている。
ただ、開発の中でのコミュニケーションですぐ聞いてしまったほうが、というのは、Joel が言うとおり間違えているのかもしれない。
この点については考えなくては。
9. 手に入る最高のツールを使っている？
判定結果: ○
アプレッソには火のプログラマーを地で行っているHさんという人がいて、この点について彼がチームに貢献してくれている部分はとても大きい。
特に開発環境の eclipse については、
「バージョン XX のβ5が出ました。
かなり生産性が上がっているので、みんな便利だと感じると思います。
チーム全体でのアップデートを検討したいです。」
というような提案がポンポンでてきて、開発チームの環境の改善が進んでいる。
ただし、
「なるほど。そのβ5の安定度はどの程度ですか？」
「かなり安定していると思います。」
「期間的にはどの程度使いました？」
「昨日からです。」
などという笑い話みたいなこともあったりする。
(ちなみにこの話は実際に1週間ほど前にあった話である)
10. テスタはいる？
判定結果: ×
この項目で書かれていることは、テストを専門としている職種を設けているかということだが、これはアプレッソでは現在できておらず、プログラマーがテストを行っている。
この点については現在強く課題として認識しており、この本で指摘されていることは至極もっともだと思う。
ちょうど今、このテーマについて検討しているところなのでとても良い参考になった。
11. 採用面接のときにコードを書かせている？
判定結果: ○
はい。書かせています。
これはアプレッソ設立当初からずっとポリシーにしてきたことで、
プログラマーとして応募してくる人には、プログラマーとしての勘や知恵や最低限の概念理解ができているかどうかを確認するために、ソースコードを書く課題をその場で提示して、ホワイトボードかプロジェクターに接続したPCでコードを書いてもらっている。
コードを書いてもらうと、華々しい履歴書では絶対にごまかせないプログラマーとしての能力がすぐに明らかになるので、この方法は、もし導入していないのであればすぐにでも導入したほうが良いと思う。
ちなみにうちでよく出す質問の例としては次のような感じで、この例では一見普通に動作するのだけれど、後で発見しにくいバグの原因となってしまうようなコードを書かない人かどうか、というのがチェックの内容となっている。
質問: このコードが NG な理由は？
public void readFile(String filePath) throws Exceptoin {
InputStream in = new BufferedInputStream(new FileInputStream(filePath));
// do something
in.close();
}
答え: do something 内で例外発生時に close されないから次のようにしないと NG
public void readFile(String filePath) throws Exceptoin {
InputStream in = null;
try {
in = new BufferedInputStream(new FileInputStream(filePath));
// do something
} finally {
if (in != null)
in.close();
}
}
12. ユーザビリティテストはしている？
判定結果: ○
ここはかなり力を入れている点で、私はこれからはエンタープライズソフトウェアであってもその手触りの良さがどの程度のものかということでマーケットでの勝敗が分かれてくると考えている。
なので、2003年からペルソナ／シナリオ法という、ユーザにより感情移入しながらソフトウェアを設計していくためのを導入し、実際に昨年10月にリリースされた DataSpider Servista という製品はすべてこのペルソナ／シナリオ法を使って開発した。
アプレッソのジョエルテストの判定結果は以上の通りである。
このところWoW こと World of Warcraft にはまりにはまって私生活のほとんどの時間をそちらにつぎ込んでしまい、ブログをほとんど書いていなかったこともあり、ずいぶんと長いエントリになってしまった。
Joel on Software
はジョエルテスト以外の章も実に読み応えがあり頷ける部分の多い本なので、まだ読んでいない方はこの機会にぜひ。
トラックバックURL
この記事へのコメント
1. Posted by Kazutoshi Ono 2006年03月29日 10:00
> 10. テスタはいる？
> 判定結果: ×
QA チームを新設した、該当項目が 10 → 11 になりました
> 判定結果: ×
QA チームを新設した、該当項目が 10 → 11 になりました
