Joel on Software

Joel on Software   このページは"ジョエル・オン・ソフトウェア

 

※新しい翻訳はJoel on Software Translation Projectにあります。

その他の "Joel on Software" の記事(日本語)

その他の "Joel on Software" の記事(英語)

著者へのメール(英文のみ)

 

下っ端でも何かを成し遂げる方法


Joel Spolsky ジョエル・スポルスキ
翻訳: Yasushi Aoki 青木靖
2001/12/25

このサイトではソフトウェアマネジメントを扱っている。しかしあなたは経営命令で組織を変える力を持ってないかもしれない。あなたが階級組織の最下層にいる下っ端のプログラマなら、人々にスケジュールやバグデータベースを作るように命令することができないのは明らかだ。そしてあなたがマネージャであったとしても、開発者を管理するのは牧猫するようなもので、違いはそんなに楽しくないことだとわかるだろう。「こうしろ」と言うだけではそうはならないのだ。

ジョエルテストで低いスコアしか取れない組織であなたが働いているのなら、それはいら立たしいことだろう。あなたのコードがいかに良くとも、あなたの同僚がああもまずいコードを書き、あなたは自分がそのプロジェクトに関係付けられていることが恥ずかしく感じられる。あるいはマネジメントがどんなプログラムを作るかについてまずい決定をし、あなたは子供向け退職プランゲームのAS/400バージョンのデバッグをして才能を無駄にすることを余儀なくされるかもしれない。

あなたには単に会社をやめるという選択もある。しかしおそらくは、あなたがそこにとどまる理由が何かあるのだろう。ストックオプションがまだ与えられていないのか、あなたの小さな町には他にもっとましな働き場所がないのか、あるいはあなたのボスがあなたの愛する人を人質に取っているのかもしれない。いずれの場合でも、まずいチームとやっていくのは腹立たしいことだろう。しかしあなたのチームを下から改善する戦略というのがあるのだ。そのいくつかをお教えしよう。

戦略 1 実行あるのみ

一人の人間がそれをするだけでプロジェクトをずっと改善できることがたくさんある。デイリービルドするサーバがないって? 作ればいい。あなた自身のマシンを使い、夜間にビルドを作って結果をメールで通知するジョブをスケジュールする。ビルドするのにあまりに多くのステップが必要だって? makefileを書けばいい。誰もユーザビリティテストをやっていないって? あなた自身のホールウェイ・ユーザビリティテストを、郵便室の連中相手に紙切れかVBプロトでやってみればいい。

戦略 2 バイラルマーケティングの力を活用する

ジョエルテストの戦略の多くは、非協力的なチームの中にいる一人の人間にも実行可能だ。そのうちのいくつかは、うまく機能すればチームのほかの人たちにも広まるだろう。

たとえば、あなたのチームの誰もバグデータベースを使おうとしなかったとする。そんなことは気にしないことだ。あなた自身のバグトラッキングをただ続けていればいい。あなた自身のコードに見つかったバグを入力する。他の誰かが修正すべきバグを見つけたときは、そのバグをバグデータベースを使って彼らに割り当てる。あなたが良いバグトラッキングソフトウェアを持っているのなら、それは彼らにメールで通知するだろう。彼らがバグを直さないならメールを送り続けることができる。いつかは彼らもバグトラッキングの価値を理解し、それを使い始めるだろう。品質保証チームがバグをバグトラッキングシステムに入力してくれないのなら、他のチャンネルからのバグレポートを単に拒絶すればいい。3000回目にあなたが「ねえ、聞いて。そいつを直したいんだけど忘れそうだ。バグをこのシステムに入れておいてくれない?」と言ったとき、彼らはデータベースを使い始めるだろう。

チームの誰もソース管理を使いたがらない? 必要ならあなた自身のCVSリポジトリをあなたのハードディスクに作ればいい。たとえ協力がなかったとしても、他の人のコードとは独立に、あなたのコードをチェックインすることはできる。そして彼らがソース管理で解決可能な問題にぶち当たったとき(だれかが誤ってrm *~のかわりにrm * ~とタイプしたときなど)、彼らはあなたの助けを求めるだろう。そしてやがては彼らも、彼ら自身のチェックアウトを持てるのだということを認識するだろう。

戦略 3 優れた人間を作り出す

チームがスケジュールを立てようとしない? あるいは仕様書を書こうとしない? あなた自身のを作りなさい。あなたがしようとしている作業について、最小限の仕様書とスケジュールを書くために1日か2日使ったところで、誰も文句は言わないだろう。

チームに優秀な人間を入れる。採用と面接に関わり、良い候補者をチームに補充する。

改善し、できるようになりたいと思う人々を見つけ、彼らをあなたの味方につけるのだ。ひどいチームであっても、ただすばらしいコードを書いた経験がないだけで頭はいい人間を見つけられる可能性はある。彼らを助けてやること。彼らが学べるようにしてやること。彼らがチェックインしたコードを読むこと。彼らが何かばかげたことをしている場合に、彼らのチェックインがいかにばかげているか説明するうぬぼれたメールを送らないこと。それは彼らを怒らせて防御的にさせるだけだ。かわりに、そのチェックインで引き起こされるバグを何食わぬ顔で報告し、彼らに何がそれを引き起こしたのか見つけさせるのだ。バグを自分で見つけたときに、彼らはずっとよく教訓を覚えるものだ。

戦略 4 間抜けを無力化する

最高のチームにも間抜けが1人や2人はいるものだ。チームにできの悪いプログラマがいるのがいら立たしく思われるのは、彼らのまずいコードがあなたのすばらしいコードを壊すとき、あるいは優れたプログラマができの悪いプログラマの後始末に時間を取られるときだ。

下っ端としてのあなたのゴールはダメージの最小化、別名封じ込めだ。ある時点でこれらの天才の一人は、2週間かけて信じ難いほどまずく決して機能しないコード片を書く。あなたは15分使ってそれをスクラッチから書き直す誘惑に駆られるだろうが、その誘惑には抵抗すること。あなたはこの間抜けを数ヵ月間無力化する機会を手に入れたのだ。ただ彼らのコードに対するバグを報告し続ければいい。あなたがもはやバグを見つけられなくなるまでの数ヶ月間、彼らにはせっせとその作業を続ける以外に選択肢がない。その数ヵ月の間、彼らが他の場所にダメージを与えることはない。

戦略 5 邪魔を避ける

幸福な仕事環境はみな似ているものだ(プライベートオフィス、静かな環境、優れたツール、邪魔の少なさ、さらに少ない大きな会議)。不幸な仕事環境が不幸なのはそれぞれの理由による。

悪い知らせは、仕事環境の変更はどんな会社でもほとんど不可能だと言うことだ。長期リースであるために、CEOでさえそれについては何もできないかもしれない。それがプライベートオフィスを持てるソフトウェア開発者がこうも少ない理由だ。これは少なくとも2つの仕方であなたの会社を損なう。第1にそれは、 (他の条件が同じなら)より快適な条件を用意してくれる企業を好む、最高の開発者の採用を難しくする。第2に、邪魔の程度によっては開発者はゾーン(訳注: 没頭した生産的な状態)の中に居続けることができず、生産性は著しく低下し得る。

そのような環境を逃れる方法を探すこと。たくさんのテーブルがあるが一日の大半は空いている(そして誰もあなたを見つけない)、会社のカフェテリアにラップトップを持って行く。会議室を丸一日予約し、そこでコードを書く。そしてチェックイン攻勢によって、部屋に一人でいるときにあなたがいかに多くの仕事をしたか明らかにする。この次に危機が訪れ、あなたのマネージャが明日までにこれをやるには何が必要かと聞くときに、あなたは何と言えばよいかわかるだろう。彼らはあなたのために、その日一日オフィスを確保するだろう。そしてすぐに、その生産性を一年中維持するためにはどうしたらよいか、彼らは考えるようになるだろう。

仕事に遅く出てきて遅く帰る。会社の他の人たちが帰った後の時間は最も生産的であり得る。あるいは、あなたがいつも遅く出て来る開発者たちのチームにいるのであれば、午前9時に仕事を始める。他の人が出てきてあなたの邪魔をし始めるまでの2時間の間に、その日の残りよりも多くの仕事ができるだろう。

emialやIMクライアントを上げっぱなしにしないこと。望むなら一時間おきにemailをチェックするのはいいが、上げっぱなしにはしないこと

戦略 6 かけがえのないものになる

あなたが本当に優れた貢献者なのでないなら、これらの戦略のどれも機能しない。あなたが良いコードを、しかもたくさん書くのでないなら、あなたはコードを書いているべき時に、ただバグデータベースを怒っていじり回しているばかりだろう。あなたのキャリアにとって、何も達成しないでプロセスばかりにこだわっているという評判を受けることほど致命的なことはない。

私が新しい会社で下っ端のプログラマとして新しい仕事を始めたとき、私はその会社がジョエルテストで 2点くらいのところで運営されていることを知り、それを改善することに決めた。しかし私は良い第一印象を与えることが重要なこともわかっていた。それで私は期待されていた通りに、毎日はじめの7時間はコードを書くのに使った。開発チームの他の人からあなたが良く見えるようにするのに、怒濤のごときチェックインほど効果的なものはない。しかし私は家に帰る前のもう一時間を、プロセスの改善のために使った。私はその時間を使って、私たちの製品のデバッグを困難にしていた問題を修正した。私はデイリービルドとバグデータベースを構築した。私は開発を困難にしていた積年の頭痛の種を取り除いた。私はその日にする仕事のための仕様書を書いた。私は開発マシンをスクラッチから構成するためのステップ バイステップの解説ドキュメントを書いた。私はドキュメント化されていなかった重要な内輪の言語を詳細にドキュメント化した。ゆっくりとプロセスは改善されていった。私(と私が管理するようになってからの私のチーム)以外の誰もスケジュールや仕様書を書いてはいなかったが、それ以外についてはジョエルテストで 10点になった。

あなたは管理する立場にいなくとも、ものごとを改善することはできる。しかしあなたはシーザーの妻である必要がある: 疑惑を招いてはならない。そうでなければあなたは敵を作るだけだろう



この記事の原文(英語)は Getting Things Done When You're Only A Grunt です。 

ジョエル・スポルスキは、ニューヨーク市の小さなソフトウェア会社  Fog Creek Software の設立者です。イェール大学を卒業後、マイクロソフト社、Viacom社、 Juno社でプログラマとして働きました。


このページは著者の個人的な意見を掲載したものです。
All contents Copyright ©1999-2005  by Joel Spolsky. All Rights Reserved.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky