スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-/Mitch Lacey

すでにテスト駆動開発(TDD)と並んで常識というレベルにまで普及したスクラム。少なくとも、思想的には普及しましたよね。

どのぐらい実践されているのかとか、どのぐらい成功裏にプロジェクトが完了しているのかとかは良くわかりませんけど、2018年にシステム開発のプロジェクトをしようとするならば、まず、スクラムが開発手法として選択肢に上がらないことはないでしょう。

とはいえ、です。私がスクラムマスターの研修を受けて思ったことは、「スクラムがきちんと出来るメンバーがそろったならば、スクラムじゃなくたってプロジェクトは上手くいくだろう」ということでした。それまでの開発手法は前提として、それなりの能力を持った開発者やリーダーが定められたプロセスをきちんと実行できるならば、プロジェクトはうまく進むのだとしていました。そのため、プロジェクトにトラブルが生じたら「何が出来ていないのか」ということがチェックされました。

で、よくよく考えてみるとそのプロセスというのは、「ちゃんとやる」ことがすごく難しいものでした。例えば、「要件はすべて明確にされる必要がある」とか「リスクは網羅的に把握されなくてはならない」とか。で、トラブったら「漏れてた」「網羅性に問題があった」と言われるわけですが、いや、「すべて」とか「網羅」とか、普通に無理でしょう。無理だったわけですよ、後から言うのは何とでも出来るけども。

それがスクラムになると、「プロジェクトを進める上で障害が必ずあります。チームはそれをみんなで解決しなくてはいけません」「チームには必ず改善すべき点があります。毎スプリント何かを改善していくことによりチームは向上します」となる。「○○をしろ」ではなく「ゴールを達成するために何をするのか考えて、ベストのことをやれ」になる。抽象度が一つ上がっていて、そのレベルでどう行動するのかのルールが決められたフレームワークがスクラムなので求められていることは難しいわけ。だから、開発者にとって魅力的なんだけども。

そんなスクラムなので、「こういう場合はどうしたらいいの？」というケースはけっこうあると思います。もちろん、スクラム自体はそれに答えてくれないケースも多いんだけど、そのようなケーススタディについていろいろ書いてあるのが、この本です。物語仕立てのケーススタディを読むのがけっこう楽しい。

こんなケースについて、ヒントが得られます。

• プロジェクトを進めるのに必要なスキルを持つメンバーが集められなかった
• まだ何も始めてないのにいつ出来るか報告しろと言われた
• チームでいちばんのリーダーと、いちばん仕様を把握している人と、最も優秀なプログラマが同一人物なので、３つのロールを兼ねた
• TDDや継続的デリバリーやペアプログラミングはスクラムのプラクティスではないのでやらない
• 毎日デイリースクラムに遅刻する奴がいて、メンバーがキレた
• ４週間のスプリントでスプリントバックログを消化しきれないので、５週間に伸ばしたい
• チームの状態が悪く仕事が終わらないから、レトロスペクティヴをパスしたい
• チームのスタープレイヤーが異動になった。それも、今日。
• オフショア先の開発者をチームに入れろと言われた
• プロジェクトをはじめたいが、プロダクトバックログが数百あって、スプリント1でどれをやればいいか決められない

まあ、あるあるっすなー。

というわけで、スクラムをやり始めたら直面するであろうあるあるについていろいろと検討している本です。具体的な手法や、思考のツールも満載ですし、ケーススタディを通じて「スクラムっぽい考え方」を理解できるというのも良い。語り口も軽やかで読みやすいです。良書ですねー。