ジョエルテストをやってみました。と言っても，やったのはかなり前なんですが・・・。

1. バージョン管理システムを使っているか？

Subversionを使っています。とおーい昔はCVSだったような。

2. １オペレーションでビルドを行えるか？

面倒な作業はしたくないので，1オペレーションでビルドできます。

3. 毎日ビルドを行っているか？

行なっています。みんな知らない間にドックフード（ドックフードの出典はどこだったけ？）を食べています。

4. バグトラッキングシステムを持っているか？

古くはBugzilla、その後はMantis、今ではTracを使っています。

5. 新しいコードを書くまえにバグを修正しているか？

これは微妙なところです。return 25;なんてしていませんが，なるべく修正するようにしています。新しい機能を追加する前に，以前のコードがメンテナンス不能だとしたら、なるべく分かりやすく書き換えています。

6. 更新可能なスケジュール表を持っているか？

まあ，あるかな。

7. 仕様書を持っているか？

あるかないかで言えば，ありますが，不十分です。会社の弱いところかもしれません。とくにユーザストーリが少ないです。個人的には画面構成とかは気にしないのですが，ユーザがどう使うかと言う部分はもう少しどうにかする必要があるかもしれません。

8. プログラマは静かな労働環境にあるか？

静かです。会社に新しく加わった人は静かすぎると怖がっています。まあ，僕が一日のうちで純粋に開発しているのは3時間か4時間ぐらいですが。

9. 買える範囲で一番良い開発ツールを使っているか？

手に入る範囲では使っています。Emacsを強行に使い続けている人もいます。ほとんどがEclipseです。

10. テスト担当者はいるか？

残念ながら，専任の人は今はいなくなってしまいました。そのかわり，持ち回り制になっています。

11. プログラマを採用するときにコードを書かせるか？

これは，会社ができて，半年ぐらいしてからずっとそうしています。以前はCでしたが、今はJavaです。でも最近はJavaプログラマの募集でもCのテストをした方がいいかなと思っています。まあ，スタックとかメモリとか意識できる人が少ないせいかもしれません。

12. 「廊下でユーザビリティテスト」を行っているか？

僕はテストと言うか、見せびらかしたいので結果的にそうなっていますが，社内的にやってほしいと思います。と言うか，やろうとしています。

前回からとっても間がありましたが，社員紹介です。
アリエルと言う会社のバイトの人たちはレベルが極めて高いです。と言うか、高過ぎです。アリエルに18歳ハッカー君が入社したのは去年の事です。今では悲しい事に19歳になってしまいました。そのハッカー君の師匠が4月からアリエルでバイトをしています。ハッカー君の師匠のハッカー君はハッカー君より1歳年下です。

さて，バイトのハッカー君は，社員ハッカー君と同じようにきわめて優秀です。同じ製品を外注した場合に比べて、10分の1のコストで，10分の1の時間で同じかそれ以上の品質のものを作ってくれます。社内でTracに移行するときに，僕が時間がなくてできなかった移行ツールの手直しをしてくれたのも彼です。残念な事は，彼はPythonよりRubyが好きらしい事です。まあ，好き嫌いはどうしようもないです。

ハッカーたちは社交的でないとか，人付き合いが悪いと思われがちですが，実際のところ、そんな事はないです。普通(?)の人に比べたら多少そうかもしれませんが・・・。

10代のハッカーがどれくらい日本にいるか知りませんが，アリエルの少ない社員，バイト君たちの中だけで考えると，将来はそんなに暗いものじゃないのかもしれません。

運用環境でテストしないで欲しい。でも、テストをするためだけに運用環境の設定を変更しないでほしい。

たんなる愚痴でした。

昨日のお話を別の視点（別の人から）から聞いたお話です。

チームAに所属する子羊Lさんは、ドキュメントが不十分な事に常日頃から不満を持っていました。調べればすぐに見つかるようにドキュメントを整備しておくべきだと，いつも言っています。開発が遅れる原因はドキュメントがないせいだと主張しています。

子羊Lさん「ドキュメントがなさすぎます。この機能Kのドキュメントを作ってください」
子羊Lさんの直属のリーダーNさんはドキュメントを書いて、チーム全体にアナウンスしました。

子羊Lさん「コーディングスタイルのドキュメントを見つけられません。なんとかしてください」
Nさんは、ドキュメントが見つけやすいようにシステムを整備しました。

子羊Lさん「この前追加された機能についてのドキュメントがないので，その機能の使い方がわかりません」
Nさんは、その機能の使い方を書いて，全員にアナウンスしました。

そういうことが長い間続き，ドキュメントは徐々に充実していきました。ある日，
Nさん「この前アップしたXの機能のドキュメント読んだ？」
子羊Lさん「まだ読んでいません」
Nさん「それじゃ、今実装している機能はXXの機能を使うけど，そのドキュメント読んだ？」
子羊Lさん「まだ読んでいません」
Nさん「１週間前にLさんが作った機能のドキュメント書いた？」
子羊Lさん「まだ書いていません」

子羊さんたちは，ドキュメントがない事に不満を持っていてましたが，ドキュメントが作られても読まず，また自分たちで書こうともしませんでした。子羊さんたちにとっては、必要な環境は降ってくるもので，自分たちで作るものじゃないのです。

いろいろなものを文書化するのは悪い事ではありません。文書化というのに抵抗があるならシステム化でもいいです。整然としていたチームも，人が増えればカオスは増えます。これはどうしようもない事で，カオスが大きくなるにつれて，それをもとに戻そうと文書化やシステム化が行なわれます。

今回Aチームは人がドンドン増えてきました。当初は１０人のチームだったのに，いつの間にか１００人のチームです。このプロジェクトのリーダのFさんは、カオスの増大に危機感を募らせ始めました。このままいくと，プロジェクトは迷走すると思い始めました。まずは，開発プロセスを見直しから始めました。
「まず，ここに機能説明書を書いてくれ！」
子羊たちは従いました。
「最後にリリースノートを書くのが大変なので，バグの各担当者はバグ修正したらリリースノートにその項目を追加してくれ」
子羊たちは従いました。
「デザインは大切なので、デザインができたらフィードバックのミーティングを開いてくれ」
子羊たちは，プロジェクトの終わりになってデザインができたので，フィードバックのミーティングを開きました。でも，フィードバックをもらっても、フィードバックをいれる時間はもうありません。
「機能説明だけでは不十分なので，機能説明の説明会を各機能ごと開いてくれ」
子羊たちは、何がたりないかわからないまま、説明会は無視しました。
「テストを始める前にテスト仕様書が機能仕様書とは別に必要だ。テスト仕様書がないとテストが始められないじゃないか。」
子羊たちは，せっせとテスト仕様書を書きました。テスターは開発者が作ったテスト仕様書をもとにテストしました。でも，開発者が作ったテスト仕様書は，すでに開発者がテストしたものなので，バグはほとんど見つかりません。
おー、なんと素晴らしいのでしょう。バグが少ないソフトウェアが出来上がった。

で、開発者は一体どこに何を書けばよくって、いつミーティングすればいいのでしょ？再び混沌が訪れそうになったので，チームリーダーのFさんは開発プロセスをマニュアルにしました。マニュアルにしただけでは開発者は無視しちゃうので，説明会も開きました。そうして，一人の子羊が一つの機能を実装するのに必要なプロセスが１００個になりました。プロセスが増えても，子羊たちは自分たちが何をやっているかわからず，何が必要とされているかも分からないままでした。

ちなみに，これは僕の働いている会社の話じゃないです。そもそも１００人もいないし。

C++に比べればJavaは格段に簡単です。面倒な多重継承もありません。書き方が多少冗長になりますが，魔法はありません。
さて，次のコード。

  List<String> list = new ArrayList<String>();

これは，多分，名前から大体わかるかもしれません。でも，次のコード。

  Collection<String> list = new ArrayList<String>();

これを魔法のように感じるプログラマもいるらしいです。
さて，Collectionをimplementした独自のMyList<T>クラスを作ってくださいとお願いすると，途方にくれるプログラマもいます。
Cのポインタと同じく(ポインタほどじゃないにしても)Javaのinterfaceも難しいのかもしれません。
Listクラスにどんなメソッドがあるか覚えるより（と言うか、補完してくれるので覚えていない人も多いかも。僕も覚えていない），もうちょっと基本的な概念がわかっていないとなー。

先日アナウンスしたPython Workshop the Edge 2007と言うイベントで「Pythonコード添削道場」と言うのがあって、それでPythonのコードを募集しています。
まだ、数は少ないですが、まじめな解答からネタとしか思えないもの(僕だったりする）までいろいろあります。こういう問題を考えるのはとても面白いです。

僕の働いているアリエルという会社は変な会社で、こういう問題の場合は、普通の答えかたはしようとしません。仕事で書くコードは普通のコード(誰がよんでもわかるようなロジック）ですが、仕事をちょっとはなれたところでは発想力という、変な解答をする方が柔軟性がでてよいというか、単なる天邪鬼と言うか・・・。
なので、スピードは無視してどこかのWeb Serviceに問い合わせて結果を返すとか、遺伝的アルゴリズムを無理矢理使うとどうなるかとか、Q&Aと連動させた人力解答とか、ばかみたいなことが真剣に議論されています。

そんな変なやつらとは別に、普通に書いちゃったら自分のコードは偉い(?)人たちにどう見られているのか、っていうのは気になるし、勉強になるかもしれません。しかも、匿名で投稿してもよいらしいので他の人と一緒に自分の書いたコードをそしらぬ顔で「こうした方がいいのに」と講釈をたれることもできます。

さて、Pythonに限らず、あなたならどれくらいスマートに、もしくは、どれくらい馬鹿げて答えられるでしょう?

僕は顧客先に行くのが嫌いです。これは，エンジニアだから人付き合いが悪いとか，そういう理由ではないです。僕が客先に行くのは主に二つあります。一つが営業段階でエンジニアが説明したり質問に答えたりするものです。これは、コンサル的な事までやれればそれなりに面白いのですが，それ以前の話が多いので単純につまらないだけです。
もう一つが，客先でトラブルが発生して場合です。僕が客先のトラブルを見に行くのはかなり状況が切羽詰まった場合なんですが，その緊張感が嫌なのかもしれません。エンジニアが直接出向いていって状況が改善しない場合は，返金とかいろいろなものがちらついて来ます。そこまで行かなくても，エンジニアが直接現場を見ると言うのは最後の手段で，エンジニアが問題を解決できなければ，手の施しようがありません。気持ち的には，再挑戦（２回目）はなくって，一発ですべてを解決しなければなりません（あくまで気持ちの問題で，問題によっては多少長引くこともあります）。エンジニアのプライドなのかもしれません。あとは，僕が解決できなければ，社内のだれも解決できないと言う自負のせいかもしれません。めったに頭をさげない開発部長でも，ぼくが解決できなければ謝りにいかなければなりません。幸い，今のところ，そんなことはないですが。

さて，トラブルではないですが，僕以外にも客先にいってインストール作業やらを行なう人がいます。通常は割とジュニアなエンジニアが行ないます。逼迫感などは比べようもありませんが，２回目は許されないというような気持ちがなかなか持ってもらえません。今回ダメなら次回挑戦，と言うような気持ちが垣間見えます。事前の準備や下調べが少ないんです。ダメなものはダメなんですが，何もしないでダメなのと、下調べや最大限の努力をしてダメなのでは違います。つまりは，WebSphereに対する愚痴なのですが。

去年に引き続き今年もまた，Python Workshop the Edge 2007なるものが６月３０日に東大の駒場であります。去年のセミナーだけと違って，今年は１時間のセミナー数個と30分のセミナー数個，PCを触りながら実際のコードを書いたり読んだりするものが６個と，他にもいくつかあります。それが一日中続きます。
MicrosoftはアメリカからIronPython(.netで動くPython)の開発者を連れてきて，お話ししてくれます（ほぼ確定の予定）。それからエマーソンミルズさんと言う人もおはなしするそうです。外人が二人！それからPerlのひらただいじさんと言う人がPythonのお話をするそうです。その他諸々。

よくわかりませんが，凄いらしいです。僕のセッションは？スレッドは体に良くないと言うものです。

CやC++などを使ってきた人はライブラリとかAPIとかのレイヤー構造を意識する人が多いかもしれません。アプリケーションのモジュール構造のようなものを階層構造の図にしているものをよく見かけますが，その層構造の事です。

小規模なプロジェクトだと，そういう階層構造を意識する事は少ないですが，ある程度規模が大きくなると，レイヤーに分けて管理します。階層構造の図は単なる概念的なものではなく，ソースコードの依存関係を表したものです。

以前，ある人と話していたところ，生粋のJavaのプログラマはレイヤーの概念が少ないと言っていました。低レベルなレイヤーがより上位のレイヤーのAPIを平気で使うと言っていました。僕は純血主義者ではないので，必要であればそういう構造も仕方ないと思っていますが，これが複雑になっていくと，依存関係が人間の管理できる範囲をこえることになるのでよろしくないです。（ちなみに，データベースは究極のグローバル変数でどこからでも参照できて，更新もできるので危険です。）そうした危険性を認識した上であえてレイヤーを超えてアクセスする事は、まあ，他に手段がないなら仕方ない事です。

ここまでが前置きで，開発も人が増えると個人の能力もバラバラで，とりあえず動けばよいと言うことだけで，レイヤーを無視していろんなコードが入ってきます。なぜ，ここにこのコードがあるかと聞けば，クラスを作らなくてもよいからだと言う答えがどうどうと返ってきます。レイヤーのことを指摘しても，わかってもらえません。だって，動くんだもん。そんなことを繰り返していると，コードに完璧さを求める人だと思われてしまいます。つまりは，階層構造の図は単なる概念図で意味がないものだということです。うーん、どうしたものなんでしょう。

多分，「Javaのインターフェース」ということで続きがあるかも。