チーム - みる会図書館


検索対象: ソフトウェア開発者採用ガイド : 優れた技術者の集まる会社にする方法
56件見つかりました。

1. ソフトウェア開発者採用ガイド : 優れた技術者の集まる会社にする方法

第 6 章採用面接ゲリラガイド そして面接の終わりには、その候補者について 鋭い決断をする準備ができていなければならない。 その決断には 2 種類の結論しかない。採用か、不採 用かだ。それ以外の答えというのはあり得ない。 「採用してもいいけど、私のチーム以外に」とは決 して言わないこと。これは無礼であり、候補者が あなたと働けるほど頭が良くはないが、しかし向 こうのチームの負け大たちとならやっていけるだ ろうと言っているようなものだ。「採用してもいい けど、私のチーム以外に」と言いたくなったら、 ただそれを機械的に「不採用」に変換すればいい。 候補者があなたの抱えている特定のタスクは見事 ーーなせるが、他のチームではあまりうまくいか ないだろうという場合、不採用だ。ソフトウェア の世界では、物事は非常に早く非常に頻繁に変わ るので、あなたが投げ込むどんなプログラミング タスクでもうまくこなせるような人が必要なのだ。 何かの具合で SQL についてはすこぶる優れている が、その他のトピックとなると何も学べないよう なイディオ・サヴァンを見つけたという場合も不 採用だ。そうしないと短期的な痛みの解決と引き替 えに、ずっと長く続く痛みを抱え込むことになる。 「いいかもしれないけど、わからない」とは決し て言わないこと。もしわからないなら、それは不 採用を意味する。これはあなたが考えるよりすっ と簡単なことなのだ。わからないって ? じゃあノ ーと言えばいい ! 境界線上だという場合も、不採 093

2. ソフトウェア開発者採用ガイド : 優れた技術者の集まる会社にする方法

074 ソフトウェア開発者採用ガイド な多様性をもたらし得る。アセンプラの経験のあ る電子工学工ンジニアは、 Lisp ハッカーのチーム に有用な多様性をもたらし得る。工ストニアの大 学を最近出たばかりの人は、中西部出身の経験豊 かなマネジメントコンサルタントのチームに有用 ーでの理屈は、チー な多様性をもたらし得る。こ ムに多様性が多いほど、チームの誰かが何かの経 験をバックグラウンドに持っていて、チームが異 なった解法を見出せる可能性が高くなるというこ とだ。 情熱 強調しておきたいのは、これらの指標 を持っていること、選んでいること、英語ができ ること、頭が良いこと、選ばれていること、本格 は、採 的であること、多様性をもたらすこと 用の基準ではない、ということだ。採用の基準に するには弱すぎる。このテストで点数が低いが非 常に優れている人や、へばなプログラマだが高い 点数になる人はたくさんいる。ジョ工ルがアイビ ーリーグ出しか雇わないとか、 GPA フェチだとか このリストが採用不採用を決め 文句を言う前に るためのものではないということを理解してもら いたい。大きな履歴書の山を並べ直すための客観 的で公正な方法というだけのことであり、それに よってうまくいく見込みの最も高い候補者が最初 に面接されるようにし、そのあと彼らを採用すべ きかの判断をするのだ。

3. ソフトウェア開発者採用ガイド : 優れた技術者の集まる会社にする方法

第 4 章履歴書の順序付け のテクノロジーよりも難しく、そのテクノロジー をうまく使えたなら、雇うべき人であることの強 い証拠になるということだ。だから履歴書を順序 付ける目的においては、難しいテクノロジーは上 のほうへ上がる傾向があり、一方で、たとえば Microsoft Word を使う能力があると主張するのは、 底のほうへ沈むことになる。 多様性をもたらすこと 含みの多い「多様性」という言葉を使って国際 的な大きなフレーム戦争を引き起こす前に、私が こで意味していることを少し注意して定義して おきたい。私は既存のチームとは十分に違ったバ ックグラウンドを持つ人々を特に求めているのだ。 彼らは新しいアイデアと新しい考え方をチームに もたらし、自分自身の声のこだまを聞いているよ うなグループ思考に疑問を引き起こしてくれる。 私が異なるバックグラウンドと言うときに意味し ているのは、文化的、社会的、それに職業的なも のも含んでいる。工ンタープライズソフトウェア で多くの経験を積んでいる人は、インターネット プログラマのチームに有用な多様性をもたらし得 る。貧しく育った人は、アンドーヴァー訳注 05 出身 のお坊ちゃんばかりのスタートアップ企業に有用 な多様性をもたらし得る。家庭に籠っていたママ が職場に復帰すれば、新卒ばかりのチームに有用 訳注 05 Phillips Academy Andover : マサチューセッツ州にある名門私立高校。 073

4. ソフトウェア開発者採用ガイド : 優れた技術者の集まる会社にする方法

130 ソフトウェア開発者採用ガイド このトピックについては以前『 Joelon Software 』・ 03 という本に書いた。ソフトウェア開発チームが良 いプログラムを書くためにできることをまとめた 本で、その原則はほとんどあらゆるハイテクチー ムに適用可能だと思う。その本の核にあるコンセ プトは「ジョ工ルテスト」で、これは開発チームが 行うべきだと私の考える重要な 12 項目だ。ジョ工 ルテストのコピーをこの本の付録につけておいた。 マネジメント法 チームであれ会社であれ軍隊であれ国であれ、 何かを率いようとするときに直面する主たる問題 は、みんなを同じ方向に進ませなくちゃいけない ということだ。これは実際には「他の人を思った とおりに動かす」ということを体裁良く言ってい るにすぎない。 こんなふうに考えてみるといい。あなたのチーム の人数が 1 人より多いなら、そこには異なる意志を 持った異なる人間がいることになる。彼らはあな たが望んでいるのとは違ったことを望んでいる。 あなたがスタートアップ企業の創業者であるなら、 大金をさっさと稼いで引退し、その後の 20 年くら ☆ 03 JO 引 Spolsky, "Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove Of lnterest to Software Developers, Designers, and Managers, and toThose WhO, Whether by GOOd Fortune 0 「Ⅲ Luck, Work with Them in Some Capacity" ( Berkeley, CA: Apress, 2004 ) / 青木靖訳「 Jo on Software] ( オーム社、 2005 年 )

5. ソフトウェア開発者採用ガイド : 優れた技術者の集まる会社にする方法

1 2 6 ソフトウェア開発者採用ガイド 会社を救っていたかもしれないアイデアを推し 進めていた開発者が解雇されるのを見たことがあ る。彼が本来の仕事を十分にしていなかったため だ。また、チームのみんなが楽しく、陽気で生産 的に仕事できるように一人で奮闘していた人間が ひどい評価を受けているのを見たこともある。そ こで使われていたメトリクスに違った種類の貢献 を評価する方法がなかったためだ。 メトリクスで測定できないことがそんなに悪い こととも思わないなら、それが申し分のない楽し く生産的なチームを壊しさえすることを指摘して 確かに自分の役割を果たせない開発者も いる 知識労働者に対してはメトリクスが単に機能し ないにしても、開発者の中にはすごい開発者と、 まともな開発者と、お粗末な開発者がいるという のも確かだ。興味深いことに、みんな誰がどれに 当たるのかをわかっている。単に測定できないだ けなのだ。 あなたはチームメンバーが次の 3 つのどれに当た るかを把握する必要がある。 1 . 優れた開発者

6. ソフトウェア開発者採用ガイド : 優れた技術者の集まる会社にする方法

第 7 章最適でないチームを直す その根拠は、もし動かなければ、敵はこちらが 全滅するまで、 1 人すっ狙い撃ちすることができる からだ。こちらから攻撃を仕掛けるなら、何人か は地雷を踏んで死ぬことになるだろうが、しかし それはより大きな益のためにしなければならない ことなのだ。 問題は、理性的な兵士はそのような状況で突撃 しようとはしないことだ。個々の兵士にはズルを することに対するものすごく大きなインセンティ プがある。自分はその場にじっとしていて、他の もっとマッチョな兵士たちに突撃させておくのだ。 これは一種の「囚人のジレンマ」だ。 生きるか死ぬかという状況において、軍隊は号 令ひとつで兵士が自殺的な命令にでも従うことを 必要とする。兵士というのは、ソフトウェア会社 なんかではまったく必要とならないくらい従順で あるようプログラムされている必要があるのだ。 言い換えると、軍隊が指揮統制を使うのは、そ れが 18 歳の若者に地雷原の中を突撃させるための 唯一の方法だからであって、あらゆる状況で最善 のマネジメント法だからではない。 特にそれがソフトウェア開発チームであって、 優れた開発者はどこでも好きなところで働けると いう場合には、兵隊ごっこをさせられるのはまっ たく辟易することであり、チームには誰も残らな くなるだろう。 1 3 /

7. ソフトウェア開発者採用ガイド : 優れた技術者の集まる会社にする方法

第 7 章最適でないチームを直す 2. 改善すべき点のある開発者 3. 望みのない開発者 能さもまた評価されないことを意味するからだ。 いることに苛立ちを感じている。それはつまり有 いる。そしてマネージャが無能な人間を放置して ッグしたり書き直したりすることに飽き飽きして 優れた開発者はまともに動かないコードをデバ 0 しなければならないことにうんざりしているもの 優れた開発者は同僚のお粗末な仕事の尻拭いを しかしそれとは逆の効果があることも多い。 のを懸念するためだ。 れるのは、それによってチームのモラルが下がる マネージャが働きの悪い者を取り除くことを恐 ラルを損なわない 働きの悪い者を解雇するのは必すしもモ それについてよく調べること。 たなら ( みんなポプは去るべきだと思っている ) 、 リのどれに当てはまるか聞いてみる。傾向が見え を約東した上で他のメンバーがこの 3 つのカテゴ を聞くことだ。メンバーの一人ひとりに、匿名性 やるための一番手つ取り早い方法は、同僚の評価 チームの新しいマネージャになった人がこれを 1 2 7

8. ソフトウェア開発者採用ガイド : 優れた技術者の集まる会社にする方法

索引 1 75 面白いプロジェクトの重要性 . .. 057 ~ 058 会社の理想主義的側面を見つける . .. 060 ~ 062 基本的な原理 .. 契約を結ぶ . 間違った判断のコスト .. 採用・不採用の決断のガイドライン . .. 093 ~ 095 . 136 ~ 1 37 .. 1 32 ~ 1 37 .. 1 36 ~ 138 .. 006 ~ 007 .. 007 ~ 008 .. 036 ~ 039 .. 1 01 ~ 1 03 .. 160 ~ 1 61 094 095 a Civilized Workplace and Surviving One That lsnlt" サットン、ロバートヨ著 "The NO Asshole Rule: Building サンタテレサ研究所 ( 旧 M) . 指揮統制マネジメント法 軍隊で使用される理由 軍隊におけるマネジメントが基本 . ハイテクチームにおける難点 . 『七人の侍』黒澤明監督の映画 . 実験結果 最初の集計 . トップ 25 % の学生の集計 .. 資本を役立つソフトウェアに変える . 社員による紹介の良い面と悪い面 .. 自由回答式の質問 . 仕様 . ジョ工丿レテスト スコアの解釈 . ソフトウェア開発チームがすべきこと .. 1 50 . 1 30 . 053 044 1 1 6 001 ソフトウェア開発チームのクオリティの評価 ... 149 ~ 150 ジョーンズ、ケイバー著 "HOW Office Space Affects Programming Productivity 044

9. ソフトウェア開発者採用ガイド : 優れた技術者の集まる会社にする方法

ソフトウェア開発者採用ガイド 154 ビルドを壊すというのはそれほど悪い ( しかもよ くある ) ことなので、ディリービルドしてビルドが 壊れているのに気付かれずにいることがないよう にしよう。大きなチームでビルドの失敗が即座に 修正されるようにする良い方法は、毎日午後に たとえば昼休みにディリービルドすることだ。み んな昼食に行く前にありったけのチェックインを する。戻ってきたときにはビルドは終わっている。 うまくいっていれば、万歳 ! みんな最新版のソー スをチェックアウトして仕事を続けられる。ビル ドが失敗していたら、原因になった人が修正に当 たるが、他の人はビルド前の壊れていないバージ ョンのソースを使って作業を続けられる。 Excel チームでは、ビルドを壊した人は罰として、 他の誰かがまたビルドを壊すまでの間ヒルドのお 守りをしなくちゃいけないというルールがあった。 これはビルドを壊さないようにするための良いイ ンセンテイプになったし、ビルドプロセスを全員 に持ち回りさせてその仕組みを学べるようにする 良い方法だった。 4. バグデータベースはある ? たとえ何と言おうと、プログラムを開発してい て ( 1 人のチームであったとしても ) 、すべての既知 のバグをリストアップした組織立ったデータベー

10. ソフトウェア開発者採用ガイド : 優れた技術者の集まる会社にする方法

付録ジョ工ルテスト ポイントというところで運営されており、彼らは 切実に助けを必要としている。それというのも、 Microsoft のような会社は常に 12 ポイントで運営さ れているものだからだ。 ーーに挙げたのが成功か失敗かを分 もちろん ける要因のすべてというわけじゃない。実際のと ころ、製品がもとより誰も欲しがらないようなも のだったなら、開発しているのが偉大なソフトウ ェア開発チームだからといって、みんな欲しくな こういったことを るわけじゃない。そしてまた、 何一つとしてやっていない「早撃ちガンマン」た ちのチームが目を見張るような素晴らしいソフト ウェアを作って世界を変えるということだって考 えられる。しかし他のすべての条件が同じなら、 12 項目をちゃんとやることで、堅実に製品をリリ ースできる統制のとれたチームができるだろう。 1. ソース管理してる ? 私は商用のソース管理パッケージを使ったこと もあるし、フリーソフトの CVS を使ったこともあ るけれど、言わせてもらえるなら、 CVS は素晴ら しい、 02 。もしソース管理システムを使っていない なら、プログラマたちを一緒に働かせようとして *02 このアーティクルを書いた後、 Subve 「 sion が現れて CVS を時代遅れにした。 Subversion は CVS よりさらによくできている。 151