新年あけましておめでとうございます。
2012年1回目の勉強会は1月10日(火)に行われた、達人プログラマー読書会@札幌でした。
「チーム」という最近ずっと興味を持っていることについてまったりと語らいました。
第8章 達人のプロジェクト
この章では、達人プログラマがプロジェクトに入ったら、どうなるか、どうすべきか、という事が書いてあります。
達人が集まるプロジェクトチーム、最強だなあと思います。
また、チームとして集まる事で、達人だけではなく達人「なりかけ」の人の力もたくさん引き出していけそうな（引き出させてもらえそうな）。
「成功とは見る人が判断するもの、プロジェクトの場合見る人はスポンサー、だから、スポンサーの大きな期待に応える事が大事」
心に留めて読み進めていきます。
41. 達人チーム
達人の技法が集団としてのチームにどう適用できるのか。
よくも悪くも染まりやすい自分としてはうなずく事がたくさんありました。
- 品質を気にかけないチームに配属されると、どんなに優秀な開発者でも面倒な問題を修正する情熱を維持しづらく感じる
- プロジェクト開発における環境全体の温度に気をつける、ということは難しい
- チームも組織の一員であり、他の世界と情報交換しあわないといけない
- しっかりと準備されたパフォーマンスがチーム全体を心地よくする
この辺りのチームのあり方、気持ちの持ち方、モチベーションについて、ずっと誰かに引っ張ってもらってきた（幸いにも良い形のチームである事が多かった）ところです。
これからは、自分がこのようなチームを作り上げていく力の一つになりたいと思う。
また
- 機能によってチームを分ける事で二重化を減らす
- プロジェクトの諸活動（分析、設計、コーディング、テスト）を別のものとして独立させることは問題を発散させてしまう事につながる
- 実際のユーザーから2〜3階層離れたプログラマーは、自分たちのコードが実際に使用される際のコンテキストについて、あまり注意を払わないようになる
この辺りはまさに「大規模開発をやっている職業プログラマ」時代に思い当たるところがたくさんありました。
コードのコンテキストについての意識は常に持っていたい。
42. どこでも自動化
今、業務で「Maven」を使用している事もあり、自動化の重要性、便利さ（そして使いこなすまでにはちょっと苦労する事）などを感じていたところでした。
「プロジェクトの整合性と再現性を保証」するためには、なるべく手動の手続きは入れない方がよい。
ただ、細かい部分の自動化にどこまで時間を使うか、は判断を迷う時が結構あります。
（最近だと、Excelにコピーしてデータ量順にソートして終わりにするか、ソート用のプログラムを作るか、など）
自分は細かい部分（自分だけの作業）だと、手動でゴリゴリやりがちなので
「コンピューターの方がうまくやってのけるような繰り返しや俗っぽいことはすべてコンピューターに任せてしまう」
ようにしていきたいと思います。
そして、労力をかけずにそうできるようになりたい。
次回で達人プログラマ読書会は終了（予定）です。
約半年間、あっという間だったなぁ。
最終回もきちんと出席したいです。