裏でやっていたJoel SpolskyのJoel on Softwearを
今更ながら初めて読みました。開発に関わるすべての
人が読んだほうがいいと思いました。
そもそもhttp://www.joelonsoftware.com/
の日々の
雑感から面白そうなものだけを載せているということで
45の独立したトピックになっていて興味のあるところ
だけ読んでもよし、という作りになっています。
翻訳も読みやすいです。翻訳書の独特の言い回しが
かなりあるけど趣旨がわからなくなるほどにはなって
いないからでしょう（中にはそうでない箇所も散見されましたが）。
開発現場を如何にマネージメントするか。
そういう意外とどこにも出ていない命題にJoel
なりの解答を記しており、比近な例を用いて説明して
くれている本です。
PMBOKもMBA学問もここまでは親切でないです。
まずは”ジョエルテスト”なる12の質問にて自分の現場
を見直すこととあります。
【ジョエル・テスト】
http://japanese.joelonsoftware.com/Articles/TheJoelTest.html
１．ソース管理システムを使っているか？
２．１オペレーションでビルドを行えるか？
３．毎日ビルドを行うか？
４．障害票データベースを持っているか？
５．新しいコードを書くまえにバグを修正するか？
６．更新可能なスケジュール表を持っているか？
７．仕様書を持っているか？
８．プログラマは静かな労働環境にあるか？
９．買える範囲で一番良い開発ツールを使っているか？
１０．テスト担当者はいるか？
１１．プログラマを採用するときにコードを書かせるか？
１２．「廊下での使い勝手テスト」を行っているか？
当社の環境では適合度は７０％ぐらいです。２．とか３．
のようなものはJavaやC++のようなビルドを必要とする言語で
なければ関係ないので除いてますけど･･･。
こういった環境整備から初めて体制を整えたら、
次は開発にまつわる諸々の問題があるでしょう。
それらにも明快に答えてたりします。
・アジャイル思想の”弊害”に振り回されず仕様書を作成せよ
・顧客は自分で何が欲しいのはわかっていないもの
・スクラッチビルドでシステムを書き換えるのはやめておけ
・ビジネスで核となる機能はアウトソースしないで自前で作る
・底辺のエンジニアにも成し遂げられることはある
といった珠玉の金言に酔うこともあるでしょう。
また、戦略に対する考え方とか上位思想に関しても言及して
あってこの辺も参考に（鵜呑みは×）なります。
元々MSのExcel開発チームだったJoelは様々な経験を通して
得た知見をブログという形で提供しており、ボランティアの
力もあって日本語にも翻訳されています。
面白いなあと思ったのは、非技術者のプログラムマネージャー
に対する考え方が付録に出ていて、その人たちの
コミュニケーションスキルはコテコテのエンジニアには
ないものだろうと若干皮肉まじりに教えてくれています。
私の経験ではエンジニア（特にプログラマ）は他人の仕事
やプロダクトにケチをつけることにより溜飲を下げ、
如何に自分がそれに対して何かソリューションを提供して
いるかをアピールするタイプの人が多い気がします。
そうでない人には釈迦に説法ですが、建設的な意見を出しつつ
他人を認めることによって共に新たな価値を産み出していこう
という人と仕事をしたいと思うわけです。技術力は重要だけど
そんなに問題じゃない。だって陳腐化するものだし（本当に
重要なポイントを押さえていれば関係ないけど）。
聖書にある
「汝の敵を愛し、汝らを責むる者のために祈れ」
はあらゆる人に有効な言葉かも、ですね。
ということで経験則から学ぶプログラムマネージャ（プロジェクト
マネージャでないこともポイント）論を読みたい人は是非！
オススメです。
それにしてもJoelさん会いたかったな。
人が読んだほうがいいと思いました。
そもそもhttp://
雑感から面白そうなものだけを載せているということで
45の独立したトピックになっていて興味のあるところ
だけ読んでもよし、という作りになっています。
翻訳も読みやすいです。翻訳書の独特の言い回しが
かなりあるけど趣旨がわからなくなるほどにはなって
いないからでしょう（中にはそうでない箇所も散見されましたが）。
開発現場を如何にマネージメントするか。
そういう意外とどこにも出ていない命題にJoel
なりの解答を記しており、比近な例を用いて説明して
くれている本です。
PMBOKもMBA学問もここまでは親切でないです。
まずは”ジョエルテスト”なる12の質問にて自分の現場
を見直すこととあります。
【ジョエル・テスト】
http://
１．ソース管理システムを使っているか？
２．１オペレーションでビルドを行えるか？
３．毎日ビルドを行うか？
４．障害票データベースを持っているか？
５．新しいコードを書くまえにバグを修正するか？
６．更新可能なスケジュール表を持っているか？
７．仕様書を持っているか？
８．プログラマは静かな労働環境にあるか？
９．買える範囲で一番良い開発ツールを使っているか？
１０．テスト担当者はいるか？
１１．プログラマを採用するときにコードを書かせるか？
１２．「廊下での使い勝手テスト」を行っているか？
当社の環境では適合度は７０％ぐらいです。２．とか３．
のようなものはJavaやC++のようなビルドを必要とする言語で
なければ関係ないので除いてますけど･･･。
こういった環境整備から初めて体制を整えたら、
次は開発にまつわる諸々の問題があるでしょう。
それらにも明快に答えてたりします。
・アジャイル思想の”弊害”に振り回されず仕様書を作成せよ
・顧客は自分で何が欲しいのはわかっていないもの
・スクラッチビルドでシステムを書き換えるのはやめておけ
・ビジネスで核となる機能はアウトソースしないで自前で作る
・底辺のエンジニアにも成し遂げられることはある
といった珠玉の金言に酔うこともあるでしょう。
また、戦略に対する考え方とか上位思想に関しても言及して
あってこの辺も参考に（鵜呑みは×）なります。
元々MSのExcel開発チームだったJoelは様々な経験を通して
得た知見をブログという形で提供しており、ボランティアの
力もあって日本語にも翻訳されています。
面白いなあと思ったのは、非技術者のプログラムマネージャー
に対する考え方が付録に出ていて、その人たちの
コミュニケーションスキルはコテコテのエンジニアには
ないものだろうと若干皮肉まじりに教えてくれています。
私の経験ではエンジニア（特にプログラマ）は他人の仕事
やプロダクトにケチをつけることにより溜飲を下げ、
如何に自分がそれに対して何かソリューションを提供して
いるかをアピールするタイプの人が多い気がします。
そうでない人には釈迦に説法ですが、建設的な意見を出しつつ
他人を認めることによって共に新たな価値を産み出していこう
という人と仕事をしたいと思うわけです。技術力は重要だけど
そんなに問題じゃない。だって陳腐化するものだし（本当に
重要なポイントを押さえていれば関係ないけど）。
聖書にある
「汝の敵を愛し、汝らを責むる者のために祈れ」
はあらゆる人に有効な言葉かも、ですね。
ということで経験則から学ぶプログラムマネージャ（プロジェクト
マネージャでないこともポイント）論を読みたい人は是非！
オススメです。
それにしてもJoelさん会いたかったな。