「SCRUM BOOT CAMP THE BOOK」を読んだ感想
読んだ。
「基礎編」でスクラムの全体像を説明したあと、「実践編」では漫画でお話が進む。主人公の「ボク」くんがスクラムいいな〜ってぼやいてたら部長にスクラムマスターに任命されて奮闘する感じのストーリーになってる。キャラ設定もだいぶ細かくて面白かった。バッチくんが「バッチ得意です!!!!」と宣言したときは感動ものだった。
個人的には、当初スクラムに対して「ルールがっちり決められて堅苦しい進め方をするやつ」みたいなイメージがあったのだけど、これを読んでだいぶ希望が持てた1。特に現在の自分は実際の仕事でけっこうな失敗2をしたばかりなので、興味深く読めた。
この本に書かれていることを実践するのは面倒だし、やることが増えるように感じる。まずチームをスクラムにするというところから大変だ。
しかし、雑に見積もってえいやで始めて、完璧なソフトウェアが出来上がったりしないことはすでに経験した。
プログラムを書くときに、デザインパターンを利用すれば、「これはDecoratorです」みたいなことが言える。多少のぶれはあっても、自分の新しいアイデアを採用するよりは、認識は揃いやすくなる。それと同じように、スクラムも、チームの中で共通認識として持てることが強いのかなと思った。「どれくらいタスクを消化できるかわからない」となったら、まずベロシティを測るべきだし、「この仕様は誰に聞けばいいのかわからない」となったら、それはプロダクトオーナーに聞くべきだし、「なんかビルド遅いから直したいけどいつやればいいかわからない」となったら、プロダクトバックログに追加して優先度を上げる相談をすればいい。
スクラムのようなものがないとどうなるか?どれくらいタスクをこなせるかもわからず無理なスケジュールを提示してしまうかもしれないし、細かい仕様は開発側でよしなにやってくれということになるかもしれないし、ビルドの改善は残業してやるしかないかもしれない。その問題が、問題と認識されることすらないまま、誰かの頑張りでどうにかするしかないかもしれない。ある瞬間はそれでもいいのかもしれないけど、チームの中でその認識がずれていると、不満が募って、チームのメンバーが退職してしまうかもしれない。
スクラムは銀の弾丸どころか、実践が難しくて面倒で堅苦しいものかもしれないけど、複数の人間が共通認識を持つには同じ言葉を使って何度も何度も話し合うことが必要で、スクラムがそのフレームワークなんじゃないかと、そんなことを考えた3。
-
実際はこの本読む前に id:hiroyuki-hanai さんによる研修も受けさせてもらっていて、それも理解の助けになった。↩
-
幸いリリースはなんとかできたけど、スケジュールは破綻してしまっていた↩
-
そんなことはこの本のどこにも書いていないけど↩