「アジャイル開発とスクラム」をよんだ

@hsbtさんから頂戴した本書、大変よかったです。
ありがとうございます!

実は、1年前ぐらいにアジャイルサムライを読んけどそんなにしっくりこなかった。
本書は

という三部構成で、第一部でアジャイルスクラムについてのわかりやすい解説があり、
第二部で実際に導入した事例の紹介と中の人の体験談を学び、
最後に歴史と、もう少し踏み込んだ話になっていて、大変わかりやすい内容だった。

前職では、3人でサーバサイドのインフラ部分の作業を分担していて、
他の部署の人たちがアジャイル開発を実践しているのを遠くで眺めていたレベルだった。

3人で特定の作業を行うだけであればとくにそういうことも必要なかったし
自主的に仕事を見つけては共有していたので問題はそんなになかった。
コミュニケーションも隣りの席にいてもなるべくIRCを利用し、
コミュニケーションのログに残すようにしていたので、
コミュニケーションロスはそんなになかった。疑問があったらすぐ相談していたのも
多分よかったのだと思う。

一方、現在は組織自体もできてそんなに時間が経っていない、
スタートアップなので組織うんぬんよりも、アプリケーションの新機能に
業務時間を費やしてきたパターンという印象だ。

自分が入社して1ヶ月ぐらい経つが、他の人が何をやっているのかわかっていない。
1週間の進捗確認はあるが、おおよそ1時間で誰が何をやっているのかの詳細をつかむことは
相当難しいと思う。そしてスタートアップ関係なしで
そういう組織は多いんじゃないかと思っている。

では、そのように誰が何をやっているのかいまいち共有されていない組織すべてが
本書を参考に全面的にアジャイルを導入すべく
コミュニケーションを取っていくかと考えるとそれは違うと思う。

自分の状況に当てはめると、スクラムマスターと
プロダクトオーナーを置いて、スプリントを決めてガッツリと組織立てて行うことは
あまりにも変化が大きすぎるからそのコストだけでも大変だ。というのが第一の理由で、
第二の理由は、そのようなことに時間を割いている余裕がないことである。

後者の理由については、スタートアップだから。という理由で御座なりにしていくと
後々大変なことになるのは経験上目に見えているので

プロダクトと組織が大きくなる一方、
プロダクトと組織を構成する仕組みや運用が脆弱なまま進んでいく危険

早めのうちに対応しておくべきだ。その点で、本書に掲載されているいくつかの施策は
試すに値するものがあると感じた。(自分で感じてもみんなが感じなければあんまり意味ない。)

なにはともあれ、各個人が自分の与えられた作業を遂行するのではなく
全員が集まって、課題に対してワイワイしながら

  • 課題に対する作業
  • 自発的に誰が何をやるのか
  • 誰が何の作業でどう困っているのか
  • どういう進捗なのか
  • 課題はなにか。
  • 失敗はあったか
  • 失敗をどう克服したら良いのか

などなど、各個人やグループで完結するのではなく、チーム全員で共有し
邁進していくことが最高なんだ。という当たり前のことを改めて学べたので、
相談しながらどうしていくかみんなで考えたい。

考えたい。というか、みんなでどうやって進めていくのがいいのか
話し合ってやってみるところからが本当のスタートだと思う。
その上で2014年、本書は最高の課題図書になる。

ホワイトボード使ってかんばんやってみるのがいいのかな。

あわせてよみたい