発売後けっこうすぐに買ってはいたのだけど、少し目を通してそのままにしていたのを2週間ぐらい前から少しずつ読み直して、けっこうみっちり最後まで読んでみた。
スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)
- 作者: 貝瀬岳志,原田勝信,和島史典,栗林健太郎,柴田博志,家永英治
- 出版社/メーカー: 技術評論社
- 発売日: 2015/03/18
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (4件) を見る
ひと言で感想を言うと、本としてよく出来ていて、道具のようにひき続き使っていけそう、という感じ。
「本としてよく出来ている」というのはどういうことかと言うと、たとえば構成がシンプルでよい。
第1章 ソフトウェア開発の困難にスクラムで立ち向かう
第2章 スクラムチーム
第3章 スクラムイベント
第4章 スクラムの作成物
第5章 スクラムを支えるプラクティス
第6章 GMOペパボの事例 ── どのように導入したか
第7章 mixiの事例 ── 導入失敗からの立てなおし
第8章 DeNAの事例 ── 大規模開発，業務委託への適用
第9章 スクラム導入時によくある問題と解決策
第10章 スクラムチームでよくある問題と解決策
第11章 スクラムイベントでよくある問題と解決策
第12章 スクラムの作成物によくある問題と解決策
（ http://gihyo.jp/book/2015/978-4-7741-7236-1#toc から章題のみ抜粋）
概説的な第1章を除くと、複数の章が一連のパターンを持つひとかたまりのブロックのように構成されていて、それが各章内でも同様に（入れ子のように）繰り返されていく。
たとえば上記の12章は、大きく第2章〜5章でひとかたまり。第6章〜8章が同じくひとかたまりの2周めで、第9章から12章が3周め、というふうに分けられる。
一度このパターンが体に馴染むとあとはそのリズムに乗って読んでいくだけというか、「次はこんな感じの話が来るだろう」と予測しながら読んでいけるので本質的な差分に集中しやすく、とくに後半は楽しく読めた。
「とくに後半は〜」と書いたが、それは本の後半という意味ではなく、読書体験の後半である。
というのも、ぼくの場合は第1章から順番に読んだのではなく、まず第5章、その次に2章を読んで、そこから3、4……と終盤に向けて読み進め、最後に第1章を読んだから。
なぜそんな変則的な順番で読んだのかと言うと、第1章は抽象的・俯瞰的な話であり、しかし読み手の自分としては何よりもまず具体的な話、つまりこれを導入したチームではどんなことをやるのか、それによってチーム開発を襲うどんな問題にどう対処できるのか、みたいな「結局、スクラムってなんなん？！」ということを知りたかったので、最初に我慢して抽象的な説明を読んでいるとすぐに飽きてしまいそう、という懸念があった。
それでパラパラとめくった中でもとりわけ「具体的に何をやるのか」について書いてありそうな第5章から読んだのだけど、これは半分正しく半分失敗で、何しろスクラムというのは「スプリントレトロスペクティブ」とか「プロダクトバックログ」とかいった専門的な用語を多用する方法論で、しかし第5章では「もうそういう説明は今までの章で存分にしたよね」という前提で、そういう用語の再説明などはしないので、いきなり途中から読んでもそうした用語が出てくるたびに「ぐぬぬ……意味わからん……日本語で喋れや……」みたいになってしまってつらかった。（これは読者が悪い）
と同時にしかし、これも冒頭に書いた「本としてよく出来ている」の一面なのだけど、同書は巻末の索引が非常によく出来ていて、そのような不良読者であっても、ちょっとつまづいた用語に出会うたび、索引をちょっと引いて、その初出で説明されている部分をちらっと読めば大抵「はあ、そういうことね」と、おぼろげであれ把握できる。
もちろん実際にその章や前後をみっちり読まないことには、深く理解することはできないわけだが、少しでも早く「ようするにどんなことをやるの？！」を知りたかった自分にとってはとりあえずそんな感じで充分だった。
索引を多用しながら第5章を読み終えて、さあ次はどれがいいかな、と考えたとき、先に挙げた目的からすると、
これを導入したチームではどんなことをやるのか、それによってチーム開発を襲うどんな問題にどう対処できるのか
第6章以降の導入事例に進めばよいところなのだけど、第5章の「前提にしてる用語がわからん問題」を身をもって体験した後ではあまりそういう冒険的な気持ちにもなれず、素直に最初から読み進めようということで、具体的な説明の最初となる第2章から順に読むことにした。
ちなみに、これも「本のつくり」で感心した部分なのだけど、同書では巻頭に各章の執筆分担がけっこう細かく明記されていてよかった。
共著の本だと時々、どの章を誰が書いているのか明示されていないことがあるのだけど、実際には複数人がドロドロ溶け合いながら執筆しているわけではなく、仮に編集段階で溶けているとしても中心的な担当者というのはいるはずで、ぼくの興味としては「どこの誰が責任をもってこれを書いたのか」を非常に知りたいので、どのページを読んでいても「なるほど、あの人がこういうことを考えた＆書いたのか」と想像しながら読むことができてよかった。
＊
スクラムとは何か？ という、スクラムの詳しい内容については第2章から第5章までの4章でだいたい説明される。
第2章は「チーム内の役割分担」について。
第3章は「スクラムで何をやるのか」について。
第4章は「スクラムで何を作るのか」について。
そして第5章は、その過程で用いられる様々な技というか方法を具体的に紹介している。
これらをロールプレイング・ゲーム風*1に言い換えると、
第2章は「キャラクターの職業」を紹介するような章なので、「戦士・魔法使い・僧侶」がいるよ、みたいな感じ。
第3章は、それらのキャラクターを使って何をやるのか。という意味では、「たたかう・まほうをかける・にげる」があるよ、みたいな感じか。
第4章は旅の目的を示すようなものなので、「レベルを上げる・コインをためる・敵を倒す」とか。
そして第5章はその道中で使用する技や道具の博覧会。魔法の種類（ギラ・ベホマ・パルプンテ）とか、武器や道具（薬草・鋼のつるぎ）にはこんなのがあるよ、みたいな感じ。
これらを最初の方にも書いたとおり、一定のテンプレートというか書法にそってぐるぐる反復するように説明していくので、読んでいて小気味よい。
そしてしみじみ思ったのだけど、いきなり第5章を読んだときに感じた「専門用語、多すぎだろ！」という感覚は徐々に薄れ、いやこれ、どっちかというとかなり極限までシンプル化されてるかも？ みたいな感じになってくる。
たとえば第2章で紹介されるロール（各役割）なんて基本3種類だけである。
それは第3章も4章も同じで、どうもこのスクラムというのは、必要以上に選択肢を増やさないよう意識して作られているのではないかと感じられる。
原理・原則を最小限にすることによって、なるべく多様な現象に適応できるようにしている、といったところだろうか。
＊
第6章から8章までの導入事例では、とくにDeNAのそれが面白いと感じた。
第9章から第11章までの「問題と対策」的なブロックでは第11章がとくに面白かった。あるあるの連続。
ぼくの仕事はソフトウェア開発ではなく、おもにCDブックの制作を編集者およびチームリーダー的な立場でやっているのだけど、それでも「うわー、これなあ……」みたいな「よくわかる！あるよねえ〜それ……」みたいに思えるエピソードが多く、その共感でき具合が楽しかった。
やっぱり人間同士、やっぱりコミュニケーション、難しいし面白い。だいたい似たようなところでつまづいて、それぞれそれなりの解決策なり、解決できなさなりがある。
いろんな人がいろんなことを考えていろんなものを作っているから、ひと筋縄ではいかない。そしてそういうのって、業種や場所が違ってもやっぱり似たり寄ったりなんだなあ、とじんわり実感した。
＊
さてそのように、「具体的に何をやるのか」をざっくり把握した上でようやく第1章に戻り、ひとまず全体を読み終えて思ったのは、これだけバラエティにとんだ、かつ豊富な情報を詰め込んでいるにもかかわらず、本自体は非常にコンパクトというか、ページ数も少なくてそれがすごい、とまた本のつくりに関する感想になってしまう。
ページ数が少ない＝軽いので、持ち運びもラクだし、一家に一台ならぬチームに1冊、いやチームメンバー1人につき1冊、共通の参考書として配ってもいいんじゃないかと思うほどのポータビリティ＆内容の過不足のなさである。
また、ぼくのチームでスクラムを導入する予定は今のところないけれど、部分的に取り入れられる部分は少なくないと感じた。
たとえばぼくはプロジェクトの開始から完了に至るまでのタスクの洗い出しや、それぞれにかかる時間の見積りなどをけっこう細かく設定しているので、「バーンダウンチャート」なんて案外取り入れやすいかもしれない。
最後に、本書を読んでぼくが得た一番大きなものは何かと考えてみると、以前はこうした「スクラム」とか「アジャイル」みたいなものに対して、ある種の胡散臭さというか、「造語ばかり使いおって……」みたいな不信感・偏見を抱いていたのだけど、それが一気に払拭されたということではないか、と思っている。
実際にはこのスクラムでは、上記のように、そういった専門的な概念は必要最小限に絞られていて、もしそれでも残った専門用語を別の汎用的な一般名詞などに置き換えてしまったら、無用な誤解や混乱を招いてしまう可能性が出てくる。
スクラムはメンバー間のコミュニケーションを最適化するための取り組みでもあるから、使う言葉も最大限誤解の余地がないものでなければならず、その点からもある程度特殊な用語が必要とされるということについては理解できたと感じる。
一方で、ではそうしたスクラムに対するストレスというか、偏見みたいなものがなぜ発生してしまうのか？ という点が新たな興味の対象にもなりつつあるのだが、これについてはまた機会をあらためて考えてみたい。
