Hacker News で良記事を見つけたので、勢いで訳してみました。(精読したわけではない大雑把な意訳なのはご勘弁)
ジョエルテストをご存知の方もそうで無い方も、日頃を振り返る意味でご一読いただければ幸い。
ちなみに、太字は個人的な"ツボ"ですのであしからず。
ジョエルテストをご存知の方もそうで無い方も、日頃を振り返る意味でご一読いただければ幸い。
ちなみに、太字は個人的な"ツボ"ですのであしからず。
/* ここから */
この記事はソフトウェア開発者よりは、開発者のマネージャー・上司に向けたものである。
今のあなたにとっては恐らくご存知のように、ソフトウェア開発者（又は、プログラマー）をマネージするというのは簡単な仕事ではない。彼らは、あなたが当然と考えている「決まりごと」に則ることを嫌う。
今のあなたにとっては恐らくご存知のように、ソフトウェア開発者（又は、プログラマー）をマネージするというのは簡単な仕事ではない。彼らは、あなたが当然と考えている「決まりごと」に則ることを嫌う。
なぜか?
なぜ、彼らは厄介で御し難いのか?
なぜ、黙って座り、コードを書いているのが難しいのか??
ソフトウェアマネージャー向け「ジョエルテスト」
私は、かのスポルスキー氏の器・経験には遠く及ばないので、これを「ジョエルテスト」と呼ぶのはいかがなものかと思う。だが、このテストの目的は、オリジナルのジョエルテストと同じだ。全ての質問は YES or NO（いいえ、しかし○○の場合は...ということはナシで) で答えなくてはならない。テストが終わったら、「YES」と答えた数だけ1ポイントになると思ってほしい。
1. 勤務時間はガチガチでは無いか？
工場でも運営しているのなら、毎日9時～5時の勤務を強制するのは良い方法だ。しかしプログラマーは、5時ぴったりで問題について考えることをやめたり、しかかっているタスクを止めたりすることはできない。朝9時ぴったりに仕事を始められない点でも、同じようなことが言える。彼らの思考は常にフル回転で、1日24時間、直面している問題に大してよりよい解決方法を考え続けている。そして、出版業界の人たちと同じように、"行き詰まる"ことがある。私は時々、丸1日にわたって何も手につかない状態になり、それはずるずると翌日にも引きずられる。私が最も良く活動できる時間は、夕方ではあるけれど、仕事時間内ではない。まず第一に、私は毎朝とても長いルーチン作業を行っていて、その日の最初の数時間、集中とは無縁の状態になる。これは事実で...寝起きの朝7時に重要なことをやったりしない。しかし、仕事中の午後2時過ぎにそんなこと(大事なことをする、しない)を気にしたりはしない。私の頭はよりすっきりしていて、より少ないミスで、何を作るのも問題解決をするのも速やかにできる。
何も私は、開発者がやる気になったらつでも仕事場に入れるようにしておくべきだ、なんて言うわけではない。単に、開発者が夜遅くまで仕事を続けたいと思ったら、休みの日でもなんでも報酬付きでやらせてやったほうが良いと言いたいだけだ。彼らは、好きでもなければそういう風には働かないし、思考が充実している時に、それが失われないうちに、タイプしておきたいと思っている。このやり方を促すのは重要なことだ。
テレワーキングも、プログラマーが時間を管理するにあたって良い方法だ。仕事がはかどらない時、私はスーパーマーケットに行き、普段仕事が終わった後に買う食べ物を買いに行ってみるものだ。これは、何かしら一仕事終える6時まで、また仕事を続けられるということを意味する。もちろん、皆が皆こんなフリーダムなやり方をやれるわけではないけれど、ほとんどは大丈夫なんじゃないかな..
2. 単体テストに十分な時間を与えているか？
次のいずれかを選びなさい:
・デプロイの前に、8時間ほど余計に単体テストを行う
・デプロイの後にバグを直すのに12時間ほど使い、その間あなたの顧客はイケてないウェブサイトについて愚痴を垂らし、おまけに追加対応にかかった費用を誰から取ろうか不毛な努力を続ける
単体テストはバグ数を減らすのに大きく貢献するし、それは、他の工程－コンパイル/実装、デプロイ、ドキュメント記述などといった－と同様に開発サイクルの一部だ。もちろん、納期は常にまとわり付くものであるが、納期のせいで品質確保の時間に影響が出るべきではない。
品質を犠牲にすることで時間を節約できるという考えに陥らないことだ。そんなことは無いんだから..
3. 設計に十分な時間を与えているか？
プロジェクトが開始された後、設計は必要で、且つ速やかに行われなければならない。設計に余計な時間をかければ、得られるものは少なくなる。うん、理解できる。誰だって、恐らく、理解できる。しかし、作り始める前に、何を作るかを考えることが重要だ。たいてい、少しの仕様も無いために、何がどうなっているのかよく知らないままに、プロジェクトを始めなければならなかった。単に、ぼんやりとしたアイデアと、いくつかのスクリーンショット、又はワイヤーフレームがあるだけ。想像してみてほしい－あなたは「家」を建てる必要がある。しかし、それが小さいアパートなのか、それとも摩天楼なのか、知りもしないときた・・・さぁ、あなたのタスクはコンクリートの基礎を作るところからだ。これ、できる？
数時間か又は数日か、プロジェクトのことを考え、最大2～3時間程度の小さなタスク群に分割する作業は、少なくとも2つのことを成し遂げる。
1つ目は、プロジェクトに関する良質なディスカッションをすることで、コンピュータに向かってメールを打つ前だというのに、多くのボトルネックを見つけ出すことができる。
2つ目は、かなり正確な(時間)見積もり計画を得ることができる。
あなたは、どのタスクがリスクになるか、どのタスクがそうでないかがわかっているので、プロジェクト計画はもっと容易になるはずだ...
4. プログラマーが必要としているツールを与えているか？
これは、開発者全員にZendStudioのライセンスを付与しろとか、“ultimate PHP IDE Deluxe enterprise edition limited 2011″(訳注*1：とにかく、開発環境の何かすごいやつ)の最新版をコピーしろとか言っているわけでは、決してない。これは、プログラマー(彼、又は彼女ら)が使いたいものを使えているかということだ。例えば、あなたは(プロダクトの)中央コードレポジトリとしてSVNを使っている(バージョン管理システムを使ってない、なんてことは無いよねぇ?)。GIT/GIT2SVNを使ってSVNにコミットしたいプログラマーはどうだろうか。実質的に、(管理者である)あなたからしたら、それは一緒かもしれない。が、プログラマーたちは電車の中だろうが飛行機だろうが他のどこだろうが、中央リポジトリにアクセスできない場所でも仕事はできる。そして、中央リポジトリに無意味な中間チェックインをすることなく、他の開発者とコードを共有することが簡単になる。
最終的な結果があなたの望むものであるなら、プログラマーが自身の時間をより簡易に、効率的に使えるツールを与えてあげるというのがポイントだ。この例はもちろん、数ある中の1つに過ぎない。もしプログラマーがツールを使うなら(お金がかかったとしても)、黙って許してあげることだ..プログラマーなら、何を使うのが一番効率的か知っているものだ..
5. プログラマー自身に、開発環境を選ばせているか？
誰もが使用する開発環境を持つことで一番大きなことは恐らく、ライセンスコストが割引になるということだろう。私は、他に理由が考えつかないくらいだ。
第一に、1つの開発環境を強制するということは、他の開発環境を使っている開発者にそれを禁止するということだ。そう、私は1週間 Zend Studio で働いている時、Zend Studio で自由自在に作業できるとも。しかし、私は日々の仕事のために、PHPStormや、あるいはvimなんかも使いたいのだ。私は、ノートパッドやtextmateで巨大なコード片をいじったって、少しも気に止めたりはしない。私が思うに、大部分のマネージャーは「あぁ、2週間もあったら、それを使えるようになるよ」なんて考えるだろう。まぁ、大体合っている。でも、最掲しておく：多くのプログラマーは、あなたの会社外で、何かしらプログラミングをしている。オープンソースやら、趣味やら、なんやかんやで。それらの活動は、好みの開発環境で行われる。多分、私のVIM環境のほうが、Zend Studio を使っている他のどのユーザよりも最適化されていてより速いだろう。もし、IDEのほうがいいやと思ったら、それを使うよ。
もちろん、若手プログラマーに特定の開発環境を進めるなと言っているわけではない。彼らが経験不足なのであれば、何らかの開発環境を使っている貴社の多くの人がその疑問に答えることができて、環境も整えているものの使い方を学ぶというのは、最良の方法だ。
でも、より経験豊かなプログラマーにとっては、「強制」は彼らを追い出す最良の方法だ..
6. あなたと、そして周りの人は、「ゾーン」を尊重しているか？
以前働いていた会社には暗黙のルールがあったものだ。もしヘッドセットを付けていたら、火事でも起きない限り邪魔をしてはいけない。「ゾーン」は精神的に極めて集中することで、110%のパフォーマンスを発揮できる時間帯だ。ゾーンに入るのは困難で、そこから抜け出すのは極めて簡単だ。ゾーンに入ってすぐ、誰かが私のところに寄ってきて「in_array()ってin_array( $haystack, $needle ) だっけ、in_array( $needle, $haystack ) だっけ？(*1)」とでも聞けば、一瞬で私はゾーンから抜けるだろう。そもそも、聞いてきたやつ自身がそうする必要があるように、私も答えなんて知らないから php.net で検索しないといけない。だから、わずか10秒の割り込みが意味するところは、もし(戻ることが)可能だったとしても、ゾーンに戻るまでに数時間を要するということだ。
今の仕事では、ゾーンは尊重されざるべきものだ。もちろん、誰かがゾーンにあるかどうかを伝えるのは難しい。私たちも、マネージャーも、読心術の使い手ではないけれど、ちょっと目を向ければ極めて簡単に見分けることはできるだろう...
すぐ返事が欲しいようなメールを送らないこと。送りつけたところまでまっすぐ歩いて行って「今送ったメールなんだけど・・・」なんて聞くのはひどいパターンだ。あなたが思っている以上に、生産性はぶち壊しになっている。ほとんどのプログラマー（私ではないけど）はあなたに怒鳴りたいのをこらえているだろうけど、その時の恨みと言ったらないだろう。本当に。
7. プログラマーは輪の中にいるか？
これは「設計」の話といくぶん似通っている。プログラマーは、プロジェクトの何がどうなっているか知っていて、大きな取引が終わる前に意見を求められているか？
実録：ある時、我々は作っているサイトが国家キャンペーンの一部だとわかった時には、ウェブサイトの最終版を本番環境にデプロイしていた。もちろん、この些細なことは開発チームには知る由も無かった。我々がデプロイを行ったサーバは、すでに他の沢山のサイトが稼働しているシングルサーバーの共有ホスト環境だった。もしプログラマーか、システム管理者がもっと早く輪の中に入っていれば、サイトの開始前に問題点を察知できていただろう。公共の電波におけるCMと同じことで、誰もアクセスできないサーバなど欲しくない(訳注：だから、デプロイ自体を疑問に思う人はいなかったんでしょう。輪の中の人にとっては)。あなたは悪者扱いされるでしょうし、あなたはプログラマーを避難するでしょう。まぁ公平に見て、問題なのはおおよそアナタだけどね。
プログラマーは、ものの可否はさておき、またどれだけ時間がかかるかに寄らず、もっとまともな見積もりができるものだ。あなたが確実にデリバリーできると確信を持たない限りは、顧客に何も約束してはいけない。
8. 打ち合わせ時間を最小にしているか？
打ち合わせは、プログラマーをゾーンから引っ張り出すスバラシイ方法だ。そもそも、ほっとんどの打ち合わせは、プログラマーにとって面白くない。大部分のプログラマーは、打ち合わせを興味の無いものとして分類する傾向にある。設計に関するディスカッション、顧客絡みのトラブル、プログラマーが幾度と無く防御すべき・・・機能に関する要望又は取り下げ事項。10中8,9、プログラマーは負ける運命にあるので、これはイライラの元になるし、打ち合わせが終わる頃には頭は空っぽになっているので、ゾーンは遙か彼方にいってしまっている。日中に打ち合わせを予定せず（いくつか例外はあるが）、プログラマーにはまとまって使える時間を与え、ゾーンに入って仕事をしてもらうことだ。
9. 十分な気晴らしを与えているか？
最初に働いた会社では、廊下の中央に大きなソファーがあったものだ。そりゃー素晴らしかった..あなたはくつろげるし、仮眠もできるし、誰も邪魔なんてしなかった。我々は廊下を歩き周り、実際何もしてないかのように（本当は違うけども）屋外ですばらしい仕事をしてみたりしたものだ。思考は断片的になり、徐々に明らかになり、考えがまとまり、雑多な中で過ごしていた時間の後により大きな視点で物事を見ることができる。私は1日につき2～3回このような時間が必要で、ほとんどの場合ものの数分で、時間としては十分だ。プログラマーからタイピング音が聞こえていないからと言って、何もしてないなどと考えないことだ。Wiiを、fussball set(訳注:フットボールゲームみたいなもの)ならもっといいかも、あるいは両方とも買ってやって。あるいはダーツボード。あるいは、プログラマーの頭をリラックスできるようなもの。あなたがプログラマーたちからちょっと離れたところに位置どって、ゾーンにいる人を邪魔してないかも、確認すること。
10. オープンソースコミュニティに貢献しているか？
この質問は、もしもあなたが100%クローズドなソースでソフトウェア開発をしているならあてはまらない。この場合、あなたはそんなソフトウェアを買い、誰にも何も借りていないということだ。しかし、私の推測では、100%クローズドなソースではない。Linuxを使ったサーバ群がある？Firefoxや、Thunderbirdは使っている？それらは公開されていて、何の料金も無しに使うことができる。あなたが何かを無償で得るなら、「ありがとう」と言う事だけが、礼儀正しいと呼べる唯一のことだと思う。プログラマーに、時々オープンソースプロジェクトに取り組ませてやってほしい。Zend Framework や PHP のバグ修正、github上のオープンソースプロジェクトでの活動、あるいは社内向けデプロイツールとして作ったものをオープンソースとして世界に向けて公開し、誰かにコード改善を手伝ってもらうとか。
第一に、それはあなたがオープンソースコミュニティに対してできる最大限の感謝だ。
第二に、会社として多大な尊敬の念を得る。
第三に、プログラマーは他者のコードを読み、そこから学習し、大きなプロジェクトで活動することがどういうことかを経験し、彼らの血となり肉となり、あなたとそして会社のためになる。
そして最後に、より良いプログラマーをあなたの会社に惹きつけることになる..これは、大きな取引ではないか？
11. プログラマーにリサーチさせているか？
マネージャーは、R&D部門が開発部門というだけでなく、リサーチ部門であることを失念する傾向にある。あなたがフレームワークを使って、プログラマーは（恐らく、それより優秀な）フレームワークを探させないとしたら、どうだろうか？
あなたに知識が無いばかりにその技術を実装できないばかりか、会社の周りの誰もがそれを見るためにただの5分も使えないがために、その可能性を確認することすらできないとしたら、どうだろうか？
リサーチは重要だ。プログラマーは、会社が開発しているプロダクト全般に関わるような知識を得るでしょう。
12. プログラマーに発表させたり、カンファレンスに参加させているか？
カンファレンスに出席することほど、プログラマーに新技術・開発に対しての知見を与えられるものは無い。それはそんなに高価なわけでもなく、開発部隊をまるまる1週間送り込むようなものでもない。しかし、開発者には自身が興味があるものをピックアップして参加させてほしい。これらのカンファレンスで、日々の業務とは異なる様々な話を聞けるだろうし、他の開発者と交流することで新しいアイデアや知見を持ち帰らせてほしい。終わったら簡単なまとめを提出させて、カンファレンスに関することを話してもらうといい。それは（良い）プログラマーをあなたの会社に引き止める素晴らしい方法であると同時に、多くの有益なフィードバックが得られるだろう。
採点
0-4 ポイント )
あーぁ。チャンスさえあれば、開発者はすぐにでもいなくなるだろうね。何ら期待はしないことだ、あなたは何も与えてないんだから。
4-7 ポイント )
少なくとも、プログラマーにいくらかの余裕は与えているようだ。しかし、あなたが必要としているうちの一部の開発者か、又はあなたと争わず、一切合切を当たり前だと思う人を雇っていない？
7-10 ポイント )
正しいやり方だ。いくつかの誤りを正せば、あらゆるプログラマーはあなたと働くことを望むだろう。あなたは、一端の良きマネージャーになりつつある。
11ポイント )
12ポイント )
注意：このテストは真剣に受け取りすぎないように。・・・一方では、そう受け取ってほしいけどもね。
/* ここまで */
参考
*1 : 原文著者はZend Certified な方のようなので、PHPerな例えですね。
0 件のコメント:
コメントを投稿