通勤時間のみで少しずつ読み始めてようやく一通り読み終えることができた。アジャイルといえることはこれまでやったことがないし、チーム開発といえるものもここしばらく行っていない人が思ったこと。
本書を読むとチームで一丸となって開発していくことが大事であることが伝わってくる。誰が実際に担当するかは分からない、つまり誰が担当になってもいいようにする。
開発担当は A さんだからといった感じで割り振ると、その人はその担当に関してはスペシャリストにはなるだろう。だけど A さんはプロジェクトで得た業務知識をチームに還元できるだろうか。プロジェクトで得た技術的知識を還元できるだろうか。トラブルが発生したときにその人以外で解決できるだろうか。みんなで助け合っていき、一緒に学んでいくことが大事なのではないかと思う。特定の人に任せて最速でできなくたっていいじゃない。これは請負で出向しているとなかなかできないことだったりすると思う。ノウハウを take できることを期待するのでなく give (というとなんだか偉そうだけど)して share していける環境がいい。これは今の職場で学んでいることでもある。これを一人で行うのでなく、周りも意識できないといけない。でも高望みしすぎてもいけない。
やり方のひとつの案として開発時はボードにタスクをぺたぺたと貼り付けて今日は僕これやります。前回楽しい仕事もらったので、今回はこれでいいですよ。この作業つまらないから誰々とやります。みたいな感じで自分だけでなくチームとしてモチベーションをあげていければ面白い気がする。ペアプログラミングなどは手法であって、こういった考えの延長線上にたまたまあるんだろうなあ。だから強要すべきものでもない。やってみてダメならダメな理由を考えて別のやり方をすればいい。
それから考え方としてただただしさんが言っていたように正直になること。自分も甘えた人間なので、ときにずるして多めの見積もりを言ってしまうこともある。お客さんに接する人なんかはもっと大変そう。
実際にやったことないから今はこんな漠然とした考えにしかまとまらないけど、そんなことを考えさせてくれた本。量も多く理解できていないので、しばらく経ってから読む機会をつくりたい。