『Code Craft』16、17章
読書メモ。
ひきつづき、『Code Craft ~エクセレントなコードを書くための実践的技法~』を読み中。少し前に、次の2つの章を読んだ。
- 第16章 コードモンキー
- 第17章 チームの力
しばらく仕事でミーティング続きだったので、章を飛ばしてこのあたりを先に読んだ。第16章も第17章も、章末にアクションシートがついている。
第16章 コードモンキー
プログラマーをさまざまなタイプに分類している。あるあると思ったり、耳が痛かったりしつつ、気楽に読める。
最後に、「良いプログラマーはPRAT（Politician，Relational，Artistic，Technical genius）であり、THICK（Team Player，Honest and humble，Improving constantly，Considerate，Keen）である」という話がでてくる。
自分に足りないものを改めて考えさせられる。
第17章 チームの力
期待以上に面白かった。ヒト系・チーム系の話が好きな人は、第17章だけでもこの本を読む価値があるかも。
17.2 チーム編成
編成とコードの構造（p.389）の項より。
チームに合わせてコードを作成するのではなく、作成するコードに合わせてチームを編成する。
最近まったく逆のケースを見聞きしているところなので、この部分にはっとさせられた。「コードに合わせたチーム編成」が、まだピンとこない。具体的にどんなものなんだろう。
17.4 チームを襲う病魔
第16章でプログラマーをタイプ分けしたように、第17章ではチームをタイプ分けしている。各タイプについて、方向転換の方法と成功戦略が、処方箋のように書かれている。
うちのチームは、民主主義型とレミング型の弱点をあわせもってるな、などと思いながら読む。新人研修をサポートしていて見かけたのは、グランドキャニオン型（=スキルや経験がメンバー間で二極化していて、上級プログラマーが下級プログラマーをともすれば見下すチーム）だなぁ、とか。
たとえば、グランドキャニオンなチームなら、こんな対策が書かれている（p.400）。すぐに試せそう。
- 同じ派閥で固まらないように、座席の配置を変える
- 上級プログラマーは、魅力的なプログラミング作業を独り占めしない
また、レミングスなうちのチームでは、「近視眼的なその場しのぎ」を避け、あとでコードを修正できるとは決して思わずに作業するべきだとわかる（p.403）。技術的負債という単語はどこにも出てこないけれど、そういう話が書かれている。
17.6 チームのワークの基本原則
コードの共同所有から、プログラマーの燃え尽き回避の話まで。
この本で述べられている燃え尽き回避策は、岡島さんの『ソフトウェア開発を成功させるチームビルディング 5人のチームを上手に導く現場リーダーの技術』に書かれていた、仕事のレベル、種類、量を変えていくという話に通じるところがある。
17.7 チームの一生
チームの誕生から、成長、終焉まで。
チームワークについて、必要とあらば作業習慣を刷新することを恐れるな、という話がある（p.415）。身につまされると同時に、元気がでてくる。
また、チームの終焉（p.415）の項より。
開発の最初の段階から、終着点を明確に見据えておかなくてはなりません。
先日書いたように、プロジェクトに宙ぶらりんな期間をつくってしまった身としては、これを読んで反省している。「プロジェクトの完了に際しての計画を立てておくこと」は、今後の課題だなぁ。
