「アジャイル開発とスクラム」をよんだ
December 29, 2013
@hsbtさんから頂戴した本書、大変よかったです。
ありがとうございます！
 | 翔泳社 発売日 : 2013-01-18 |
実は、１年前ぐらいにアジャイルサムライを読んけどそんなにしっくりこなかった。
本書は
- アジャイル開発とは何か、スクラムとは何か
- アジャイル開発とスクラムを実践する
- アジャイル開発とスクラムを考える
という三部構成で、第一部でアジャイルとスクラムについてのわかりやすい解説があり、
第二部で実際に導入した事例の紹介と中の人の体験談を学び、
最後に歴史と、もう少し踏み込んだ話になっていて、大変わかりやすい内容だった。
前職では、３人でサーバサイドのインフラ部分の作業を分担していて、
他の部署の人たちがアジャイル開発を実践しているのを遠くで眺めていたレベルだった。
３人で特定の作業を行うだけであればとくにそういうことも必要なかったし
自主的に仕事を見つけては共有していたので問題はそんなになかった。
コミュニケーションも隣りの席にいてもなるべくIRCを利用し、
コミュニケーションのログに残すようにしていたので、
コミュニケーションロスはそんなになかった。疑問があったらすぐ相談していたのも
多分よかったのだと思う。
一方、現在は組織自体もできてそんなに時間が経っていない、
スタートアップなので組織うんぬんよりも、アプリケーションの新機能に
業務時間を費やしてきたパターンという印象だ。
自分が入社して１ヶ月ぐらい経つが、他の人が何をやっているのかわかっていない。
１週間の進捗確認はあるが、おおよそ１時間で誰が何をやっているのかの詳細をつかむことは
相当難しいと思う。そしてスタートアップ関係なしで
そういう組織は多いんじゃないかと思っている。
では、そのように誰が何をやっているのかいまいち共有されていない組織すべてが
本書を参考に全面的にアジャイルを導入すべく
コミュニケーションを取っていくかと考えるとそれは違うと思う。
自分の状況に当てはめると、スクラムマスターと
プロダクトオーナーを置いて、スプリントを決めてガッツリと組織立てて行うことは
あまりにも変化が大きすぎるからそのコストだけでも大変だ。というのが第一の理由で、
第二の理由は、そのようなことに時間を割いている余裕がないことである。
後者の理由については、スタートアップだから。という理由で御座なりにしていくと
後々大変なことになるのは経験上目に見えているので
> プロダクトと組織が大きくなる一方、
> プロダクトと組織を構成する仕組みや運用が脆弱なまま進んでいく危険
早めのうちに対応しておくべきだ。その点で、本書に掲載されているいくつかの施策は
試すに値するものがあると感じた。(自分で感じてもみんなが感じなければあんまり意味ない。)
なにはともあれ、各個人が自分の与えられた作業を遂行するのではなく
全員が集まって、課題に対してワイワイしながら
- 課題に対する作業
- 自発的に誰が何をやるのか
- 誰が何の作業でどう困っているのか
- どういう進捗なのか
- 課題はなにか。
- 失敗はあったか
- 失敗をどう克服したら良いのか
などなど、各個人やグループで完結するのではなく、チーム全員で共有し
邁進していくことが最高なんだ。という当たり前のことを改めて学べたので、
相談しながらどうしていくかみんなで考えたい。
考えたい。というか、みんなでどうやって進めていくのがいいのか
話し合ってやってみるところからが本当のスタートだと思う。
その上で2014年、本書は最高の課題図書になる。
ホワイトボード使ってかんばんやってみるのがいいのかな。
あわせてよみたい
 | 技術評論社 発売日 : 2013-12-21 |