スクラム実践入門
チーム開発本の読書感想、第２弾「スクラム実践入門 」
「スクラムってなんぞや」という疑問があって手に取った本（１年ぐらい前に買って本棚に眠ってた）スクラム開発の具体的な手法が詳細に述べられているのと、実際にスクラムを導入した企業の経験談が載っている。
スクラムとは、Team Geekでの主張でもあったように、ソフトウェア開発をチームスポーツとして捉え、チームメンバーがラグビーの”スクラム”のようにタッグを組んでプロダクトを開発・提供していこうぜ、という考え方に基づいたアジャイル開発手法のことで、詳細はこのブログでは述べないが、属人性の廃止、チームのゴール/現況/課題の共有、開発プロセスの継続的な改善などの目的で、近年のチーム開発で採用されている。
３つのロール（役割）
スクラムを実践するにあたって、３つのロール（役割）がある
スクラムマスター？
スクラムは”習うのは簡単だが、実践は難しい”と言われていて、確かに具体的な方法を読んでみてこれは結構めんどいなー、と感じることも多かったが、僕が一番現実的に難しい（というよりもイメージが湧かなかった）のでは？と感じたところは、スクラムチーム専任のスクラムマスターとなる人をアサインすることだと思った。スクラムマスターは、開発には直接関わらず、スクラムをきちんと回すためだけに存在する人だが、僕の過去の開発経験に照らしあわせてみても、スクラムマスターに相当するような役割を持った人、またはそれに近しい人も存在しない（スクラムしたことないから当然といえばそうなのだけど。。）ということもあって、スクラムマスター像がうまくイメージできなかった。
たしかに、スクラムの「スプリント計画」 → 「レビュー」 → 「振り返り」 のスプリントをきちんと運用するために、スクラムマスターのような仕切る人が必要（その方が絶対メンバーが楽）だと思うが、スクラムマスターみたいな仕事は、スクラム知識・経験があって、なおかつ、ある程度開発経験もないと難しいし、そんな人はそうそう居ないんじゃないかな、と思った。
プランニングポーカー
本書で紹介されていたスクラム流見積り手法。
僕は見積りというものが苦手であります（この世に俺は見積り大好き！みたいな人がいるのだろうか）ソフトウェア開発で正確な見積りは難しいし（というか不可能）、頑張って見積りを作って出したら出したで、いろいろ大人の事情があったりで、何かと消耗させられる見積り作業だが、プランニングポーカーは、そんな見積り者の消耗を軽減させるための見積り手法であると思う。通常１人で行う見積もりを、複数人でゲーム感覚（まるでポーカーで遊んでるかのように）で見積もりを行うことにより、見積り作業自体の属人性を減らし、チームの結束力を高めることも期待できる。また、見積りの計算方法が時間見積もり（何人日）ではなく相対見積りであることも特徴的だと思う。
ただ、本書で実際にプランニングポーカーを実践した企業の経験談によると、他メンバーに見積もりの根拠となる説明をしなければいけないため結構時間が取られてしまい、案外１人で見積もりするより大変であると、あったのでやっぱり見積りは難しいなー、という結論なのかもしれない。
ソフトウェア開発は難しい
冒頭で著者が「ソフトウェア開発は難しい」と述べており（これに同意しない奴は、こんな本読まない） 誰がなんといおうがソフトウェア開発は困難極まりない作業なわけで、そんな複雑な問題に立ち向かうべくして スクラムのようなキメ細かい戦法をとるわけであって、そんな時に大事なのは
今俺らは”スクラム”をやってんねんでー！
チームでソフトウェア開発に取り組んでるんやでー！
という、文字通りラグビーのスクラムのような結束意識なんではないか。と思った。
