「アジャイルソフトウェア開発スクラム」を読みました。

薄い本ですが、中盤が思いの他読み辛くて、思ったより時間がかかりました。はっきり言うと、中盤は内容も薄いです。言いたいことは2章分ぐらいしかないのに、本にするために無理矢理、章を書き足した印象です。読む価値があるのは3章「スクラムのプラクティス」と9章「スクラムの価値」の2章です。

スクラムで(scrum)一番有名(?)な「ニワトリとブタ」の話は好きです。話を知らない人はWebで調べてみてください。

アリエル社内では、様々なプロジェクトで、様々な開発プロセスを試行しています。この本を手にしたきっかけは、最近の社内の開発プロセスはスクラムっぽくなってきたのでは?、と思ったからです。本書の第1章で、「使用する方法にかかわらず、最も生産的にソフトウェアを納入しようと考えれば、誰でも結局はスクラムにとても似たことを始めるだろう」とあります。アリエルが現在たどりついた開発プロセスとスクラムには、共通点もあれば相違点もあります。

スクラムでは、プロダクトバックログと呼ばれる優先順位付きのタスクリストを用意します。このプラクティスは目新しいものではありません。と言うより、このようなタスクリストの無いソフトウェア開発の方が珍しいはずです。アリエルでは、昔から、単一のBTS(Bug Tracking System)でバグリストとウィシュリストを管理しています。ただし、プラクティス「3.2.1. プロダクトオーナーがプロダクトバックログを1人で制御する」の実現は容易ではありません。

スプリントと呼ばれる1ヵ月の開発期間を区切ります。プロダクトバックログから1ヵ月分の作業をスプリントバックログとして切り出します。このように、期間を切って、その期間の作業を切り出すプラクティス自体は普通です。ソフトウェア開発に期間的な区切りがあるのは普通で(イテレーションと呼んだり、あるいは単にリリースの都合で区切られるかもしれません)、その期間でどれだけの作業をする予定か、最初に計画するのは当然だからです。この時、曖昧さを許すか否かは意見が分かれるかもしれません。ぼくは、完全な見積りができるとは思っていないので、幅を持たせた計画を支持します。

開発期間のイテレーション1ヵ月が適当かどうかは意見が分かれます。ぼく自身、確固とした信念があったわけではありませんが、現時点では、1ヵ月という単位は妥当だと考えています。

スクラムの開発チームの規模は、「3.3.2 チームの規模」から引用すると、「チームの規模は5人から9人でなければならない」「8人以上のチームは適切に機能しない」とあることから、5人から7人を適切と見なしているようです。個人的にもこのチーム規模を支持します。

スクラムで最も特徴的なのは、スクラムチームを決めて、スプリントバックログを決定した後は、スプリント期間中の1ヵ月はスクラムチームに介入するな、と主張する点です。以下に、「3.6.2 口出し無用、おせっかい無用、裏取り引き無用」から引用します。

チームは、30日のスプリントの間自由である。チームは目標にコミットし、目標を満たすようにプロダクトに機能を追加する責任を負っている。チームは、自分たちが優れていると思うことを行う権限も持っている。チーム外の人は、スプリント中にチームが行っている作業の範囲や性格を変えてはいけない。スプリントに機能や技術を追加してはいけない。チームにスプリントでどう行えばよいかを教えてはいけない。

かなり大胆です。実際、これを管理者の賭け、と呼んでいます。また、多くの管理者は30日以上介入を我慢することができないので、スプリント期間は30日になっている、ともあります。

上の引用だけを読むと、開発者の独断で機能が決まりそうに見えます。そうではありません。スプリントを始める前にスプリントの目標とバックログは開発者以外も含めた合意で決めます。スプリント終了後にはスプリントレビューで成果を非開発者と共有します。軌道修正が必要なら、次のスプリントに反映します。

極言すると、スクラムにおける管理者の仕事は、スクラムマスターを中心したスクラムチームを外部の雑音からいかに守るか、だけです。ぼく自身、この開発スタイルは好みですが、現実にはまったくできていません。ブタ(身を削る開発者)に対する、ニワトリ(身を削らない人)の介入を30日間阻止することは絶望的に難しい話だからです。