『達人プログラマー』第8章のMorning Bee

先月から実施していた『達人プログラマー』のMorning Bee（早朝読書会）が終わりました。全5回でした。りょーさん＆こんぴろさん、どうもありがとうございました。

振り返ろうと思ったんだけど、アレ・・・第1回のことしか日記に書いてない・・・

ラストなので、雑感ですがメモしておきます。今日は第8章でした。

第8章

チーム分割

職務権限ではなく、機能でチームを分割しよう、という話。

今年1月のJaSSTで、テスト工程だけをオフショアに出すことについて議論されていたけれど、これに起因する失敗は本当によく起きる…らしい、というような話を聞かせてもらいました。チームに機能をまるごと任せた方が、取り組む側のモチベーションが上がるし、責任を持つようになるし、（適切に分割されていれば）作業もしやすいし、上手くいくよね、という結論です。なお、ここでいう機能とは、ユースケースという意味の機能ではありません。

ただ、じゃあ、分業しやすいアーキテクチャとはそもそもどんなものなのかとか、実際にどこで分割すると効率が良いのかとかは、まだ自分にはよく分からないカンジです。

自動化

自動化といえば、機械にできることは機械に任せて、人間様はもっと創造性が必要な仕事をすべし、というオフェンシブな文脈でよく語られます。けれど、手作業でやると間違えたり忘れたりするから自動化しよう、というディフェンシブな観点の意見も（時と場合によっては前者以上に）説得力があるよねと思いました。両方重要。

テスト

たとえばパフォーマンステストのように自動実行ができないテストは、スケジュールに組み込んで、リソースを細かく割り当てておくこと、とありました。テスト計画の時点でそういったことをチェックするのは、無意味ではないようです（というよりも、それしかやりようがない）。

テストのテスト

テストが正しいかどうかを検証する方法については、結局よく分かりませんでした。設計のためのテストの妥当性は、レッドバーが出るテストを一旦書いてみることで、十分なのかもしれません。

でも、品質保証のためのテストを検証するには、なんらかの手法に基づいてテストケースの作成、テストデータの抽出をした後、その方法も含めてレビューする以外、方法はないのかな・・・？

コードと署名

これかな…と思ったり。

• コードに署名するということ - 虎塚

それってコードの共同所有の原則に反するんじゃ？と最初思ったけど、そうではなく、要は、心意気とか仕事に対するスタンスとかの話みたいでした。

参考資料

本書の参考文献ではなく、お二人と話していて教えていただいた資料のメモです。

• アジャイル開発者の習慣－acts_as_agile：連載｜gihyo.jp … 技術評論社
  • ソースコードのコメントにはWhyを書くべし、という話が出てくるそうです
• DRYがテーマの号のWEB+DB PRESS（WEB+DB PRESS Vol.49かな？）
  • ドキュメントのDRYに関して、達人による記事があるそうです
• 『闘うプログラマー』
  • 締め切りに厳しい鬼のようなビルドエンジニアが出てくるそうです

ちなみに、JaSST'10 Tokyoのクロージングパネルは、まとめ記事とかないようです・・・残念。

というわけで、ありがとうございました

同じIT系ながら全く違う仕事、経験の人で集まって読書会ができて、面白かったし、勉強になりました。

達人プログラマー―システム開発の職人から名匠への道

こんなおっかない表紙の本、一人じゃ読めなかったと思いマス。ありがとうございました。