Try! ジョエル・テスト
Joel on Softwareで有名なジョエル・テスト。
Joel on Software - ジョエル・テスト
http://japanese.joelonsoftware.com/Articles/TheJoelTest.html
- ソース管理システムを使っているか？
- １オペレーションでビルドを行えるか？
- 毎日ビルドを行うか？
- 障害票データベースを持っているか？
- 新しいコードを書くまえにバグを修正するか？
- 更新可能なスケジュール表を持っているか？
- 仕様書を持っているか？
- プログラマは静かな労働環境にあるか？
- 買える範囲で一番良い開発ツールを使っているか？
- テスト担当者はいるか？
- プログラマを採用するときにコードを書かせるか？
- 「廊下での使い勝手テスト」を行っているか？
ジョエル発案の簡単に開発組織の質をチェックできるテストで、Yes/Noで回答して10点以下ならその組織は問題があるという話。もちろん、これが全てじゃないけれど－たとえば6番とか（これは顧客の性質に寄るところも多いだろうから）、10番とか（チームメンバーが10名に満たない場合にテスト専任はコスト面で厳しいだろう。Joelの理屈はわかるが上を説得できませぬ）－愚直に達成していこうと思っている。
ところで、驚いたのは
いいアジャイルと悪いアジャイル
http://www.aoky.net/articles/steve_yegge/good_agile_bad_agile.htm
の記事。
Googleでは
- ガントチャートや、日/タスク/担当者が書かれたスプレッドシートや、そのほか何であれ、目に見えるプロジェクト管理を示すものは見たことがない。
らしい。衝撃だ。その理由はつまり、
作っているソフトウェアについて前もってアナウンスする習慣があるなら、一般の人々はそれがいつ頃になるのかを知りたいと思い、それは日付ということにな る。私の考えでは、これがGoogleが前もってアナウンスをしないことが多い理由なのだ。いい料理を手早く作ることはできず、赤ちゃんを手早く産むこと はできず、そしてソフトウェア開発を手早くやることはできないということを彼らは知っているのだ。
これらの3つの例外が日程によって駆動されているのでないなら、何が彼らを駆動しているのか? ある部分では、それは創造への欲求であり、何かを作りたいという欲求だ。すぐれたエンジニアがみんな持っているものだ。
(中略）
違うのは、Googleは物事にどれくらいかかるか分っていると主張するほどばかでも傲慢でもないということだ。
ということらしい。うん、確かに、自分と自然の摂理に嘘をつかない生き方を考えればこうなるね。
未来は予測できないということは賢い子は幼稚園児ぐらいから自覚する自明の定理なわけだけども、これを諦念とともに受け入れて適応すべきか、戦いをいどむべきか。どちらが大人な態度なんだろうか。
「スケジュール？そんなもんいらねーよ。俺を駆動するのは俺自身のモチベーションだけだ！」
なーんて言い出したら、ご飯が食べれなくなっちゃう人がいっぱい出てくるからなかなか大声ではいえないわね。
非難轟々でしょうなぁ、きっと。
マネジメントって本質的に、上手くできない、稼動する気のない人達、その件に興味のない人達をなんとかその気にさせるってことだと思うので、そんな人がいないなら、または充分に少ないなら、その組織ではマネジメントっていらないんだろうな。どこかでマイナス面を解消するためのコストが解消によって得られるコストを上まるポイントがあり、ここを越えてまで管理するのはナンセンスだろう。だから、やる気のある人を雇うのはマネジメントコストを抑えられるのでお得って話になる。逆に言えば、「いい人材さえいえば！！」という渇望は、マネジメントの敗北ともいえる。
ただ、ここのロジックの穴は、人のステータスを静的にとらえてるってところで、人のやる気だの能力だのは変化するので、やる気のない人というのが定常的にあるというのも実は危うい発想なんだよな。正確にはやる気のある時もない時もあるし、環境にも多分にそれは影響されるってことで、その辺りに実はマネジメントの骨法があるような気がする。マネジメントはだから、何かを作れば（仕組、ガイドライン、懲罰、報償、etc・・・）それで終わりというものではなくて、家事のように、毎日し続ける、終わりのないメンテナンスタスクの総称なんだろう。だから、マネジメントがいらなくなることはない。家事がいらなくならないように。でも、同時に家事はできれば最小化できれば、楽だよね。
