「エッセンシャルスクラム」を読みました
だいぶぶりの読書感想ブログ。ノルマ的にこなしていかんと、なかなか進まないなあ。いつも言ってる気がするけど。
ということで、これも今更ながらの名著です。実際には、スクラムガイド2017での変更点の紹介 | Ryuzee.comやスクラムで削除された5つのトピック | Ryuzee.comのように、スクラムガイドも細かく更新されています。が、本質的なところはそう変わってないはずなので、ちゃんと読んでおくべきだと判断しました。
エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)
- 作者: Kenneth Rubin,岡澤裕二,角征典,高木正弘,和智右桂
- 出版社/メーカー: 翔泳社
- 発売日: 2014/07/08
- メディア: 大型本
- この商品を含むブログ (7件) を見る
第1章 イントロダクション
クネビンフレームワーク。開発プロセスの提案をすることもときどき出てきた立場として、アジャイルプロセスを適用するかどうかの最初の指針になるもので、盲目的にアジャイルでいくんだーとなる前に考えていいところ。まあ、最近のソフトウェア開発は、大体は複雑な領域に相当するので、それをうまくやっていくためのアジャイルな開発プロセスがマッチするというのはそうなんでしょうけど。
ちなみに、クネビンフレームワークを改めて調べ直して、カオスな領域での適切なふるまいを勘違いしてたことに気づきました。カオスな領域だと、まずはカオスを脱出するために、強力なリーダーシップのもとにコマンド＆コントロールで進めるべきみたいですね。例として挙げられてたのは、9.11 のテロ事件とか。確かに、テロ真っ最中のときに悠長に検査・適応してから進もうってのは苦しい。
と考えると、ソフトウェア開発でカオスな状況って、よっぽどのことですね。本の中では、自分たちのサービスのバグによって不利益をこうむった顧客から、今まさに巨額な訴訟を受けよう最中というのが挙げられてました。
第3章 アジャイルの原則
ここではやっぱり「3.5 仕掛中の作業（WIP）」ですよね。
- 作業は経済的に妥当なサイズにまとめよ
- 在庫を認識し、適切な流れで管理せよ
- 作業者の手待ちではなく、作業の手待ちに着目せよ
- 遅延コストを考慮せよ
この辺は、カンバンの原則にもまんま通じるところがあると思ってます。詳しくは、以前発表した資料を。
第5章 要件とユーザーストーリー
ここは目新しい項目はなかったのだけど、今まで学んできたことを再度確認した章。そうだよね〜とか、あーこれはどうだったっけ？って調べながら、読み進めていきました。キーワード的にはこの辺。
- ユーザーストーリー・エピック・テーマ
- INVEST
- 非機能要件
- 学習のためのストーリー（スパイク）
- ユーザーストーリーマッピング
第7章 見積もりとベロシティ
すでに本書の時点で、ストーリーのサイズ見積もりをしない話がでてました*1。
スクラムを実践している人たちの中には、PBIのサイズ見積もりを必須ではないと考えている人もいる。経験上、成熟したスクラムチームなら、すべてのPBIを同程度のサイズにまとめられると知っているからだ。彼らは、同程度の小さいサイズにまとめられたPBIを前にして見積もりをするのは、時間のムダだと考えている。そんなことをしなくても、単にPBIの和を数えれば、それで十分だというわけだ。
ケースバイケースとは思いつつも、↓の理由から作者はPBIを見積もりたい派で、自分も同じだなー。少なくとも今は。
- 第5章で説明したとおり、すべてのPBIが同時に同じサイズになるわけではない。たとえすべてのPBIのサイズを小さめに揃えることを目指していても、バックログの中には大きめのPBIがいくつか残る。
- チームのメンバーがPBIのサイズを同程度にまとめられるようになるには、それなりに時間がかかる。
- 同じサイズにすることが目的になってしまい、不自然なところでストーリーを分割せざるを得なくなるかもしれない。
- いちばん大切なことだが、見積もりの最大の目的は、話し合う家庭でいろいろな気付きが得られるということだ。何かに対して数字を付けてくれと頼んだりするだけでは、健全な議論が生まれない。意見の相違は見えなくなるだろうし、思い込みがあったとしても表には出てこなくなる。見積もりをやめてしまうのなら、健全な議論をうながすための何らかの手を他に探す必要がある。
この辺も思い出したので、参考がてらはっておこう。
第8章 技術的負債
今自分の中でホットな話題ｗ どういうものかはある程度感覚としてあるので、主にどういう風に解決していくべきか？という視点で読んでました。その中であがったのが、以下の2節。
- 技術的負債の可視化
- 技術的負債の返済
技術的負債の可視化
可視化については、ビジネスレベル / 技術者レベルでの可視化があるとのこと。ビジネスレベルではベロシティへの影響を与えるかどうかで考えるのが分かりやすそう。ベロシティが半分になれば、倍の作業コストなり遅延コストがかかるよねという感じで。
技術者レベルでの可視化については、障害管理システム / プロダクトバックログで障害を扱う / 技術的負債バックログの3つがあげられてました。それぞれ、負債の量が少ない順という感じかな。負債がすくなければ、不具合と同じレベルで障害管理システムに突っ込んでおくぐらいでいいし、もうちょい大きいものならばPBIとしてプロダクトバックログにつっこむ。負債が多い場合は、それ専用のバックログを用いて、かつそれをちゃんとスプリントプランニングで考える必要がある（けど、管理だけして忘れがち。。。）
技術的負債の返済
返済の手法で気になったのは、以下の3つかな。
- ボーイスカウトルールに従う（負債を見つけたらその場で返済する）
- 技術的負債の返済はインクリメンタルに
- 技術的負債を返済しながら顧客に価値をもたらす作業も行う
ボーイスカウトルールは好きなんだけど、無制限にその場で返済し続けるわけにもいかないですよね。一定の割合に収めるというのが大事そう。
残り2つは、一括返済じゃなくて徐々に返済していこうという話。一括は考えやすいんだけど、それは問題を先送りにして楽な方に逃げてたつけなのかもですね。ご利用は計画的に。
「技術的負債返済スプリント」だとか「リファクタリングスプリント」などといった言葉がチーム内で出てきたら、危険信号だ。（中略）私に言わせればそれは大量の負債を一気に支払うということだ。実際のところ、そんなコメントが出てくるというのは、技術的負債がそんなにふくれあがるまで負債の削減など気にしていなかった証に他ならない。
↑の「技術的負債バックログ」と合わせた手法も紹介されてました。こういうのもよさそう。
第9章 プロダクトオーナー
だんだん疲れてきたのでｗ、後から参考にできるように、ここでは最低限の表だけで。
| 開発の種類 | プロダクトオーナーの候補 |
|---|---|
| 社内開発 | そのソリューションによって恩恵を受けるビジネスエリアの代表や顧客 |
| 商用開発 | 実際の顧客やユーザーの組織内プロキシ（プロダクトマネージャー、プロダクトマーケッター、プロジェクトマネージャーなど） |
| 外部委託開発 | そのソリューションに支払い、恩恵を受ける会社の代表や顧客 |
| コンポーネントチーム | 技術的なバックログの優先順位をうまく受けられる技術者 |
最後のコンポーネントチームだけは、ちょっと疑問に思った。コンポーネントチームを作るのは、悪手だと思ってるので。コンポーネントチームはそれ単体ではユーザーに価値を出さないし、コンポーネントを利用するフィーチャーチームからすると外部のコンポーネントチームに依存するので、クロスファンクショナルにならなさそう。
というのを、第12章の「12.2 フィーチャーチームかコンポーネントチームか」に書いてあった。
第10章 スクラムマスター
「1日の様子」が面白かった。スクラムマスターのやることとして、下記のようなアクティビティがある。
- インペディメントの除去
- コミュニケーション
- チェンジエージェント
- プロダクトオーナーの支援
- チームのコーチ
- スクラムのアクティビティ
スプリントの最初と最後はスクラムのアクティビティ（スプリントプランニングやレビューなど）が占めるのはそのとおりだけど、それ以外の日は5割ぐらいインペディメントの除去に費やされてた。まあそうだよね。
第11章 開発チーム
ここでは、開発チームの特性かな。「よりいいチームになるために、どこを頑張っていけばいいと思う？」みたいな問いかけのときに、こういうのを思い返してもよさそう。
- 自己組織化
- 機能横断的な多様性と十分な能力
- T型スキル
- 銃士の姿勢
- 広帯域のコミュニケーション
- 透明なコミュニケーション
- 適切な規模
- 集中とコミットメント
- 持続可能なペースで仕事する
- 長寿
第12章 スクラムチームの構成
「12.3 複数チーム間での調整」で、スクラムオブスクラム・リリーストレインという2つの手法が紹介されてましたが、後者の方に興味をひかれました。ちょいちょい見たことはあったのですが、SAFeでも定義されてたんですね。SAFeはほとんど知らないのですが、いつかちゃんと見ておきたい。今の自分の立ち位置だと直接関わることはほぼなさそうですが。
第13章 マネージャー
マネージャーの責務として、一番根幹だと思うものを一つだけ取り上げておこう。
境界を定める
- マネージャーが、プロダクトやプロジェクト（砂場）を定める
- マネージャーが、チームの構成を決める（誰をどの砂場で遊ばせるかを決める）
- チームは、それぞれの砂場の中で自己管理する
第15章 さまざまなレベルでのプランニング
プランニングのレベル。スクラムで主に意識するのは、リリース・スプリント・デイリーぐらいまでだろうけど、プロダクトやポートフォリオ*2もあるよと共通言語を持っていると、話が早いだろうなとは思った。例えば、いまのうちの会社に照らし合わせると、ポートフォリオプランニングはあれで、プロダクトプランニングはロードマップ含めたあの辺かなという感じ。
| レベル | 範囲 | 誰が作るか | 何を対象にするか | 成果物 |
|---|---|---|---|---|
| ポートフォリオ | おそらく年単位 | ステークホルダーとプロダクトオーナー | プロダクトのポートフォリオの管理 | ポートフォリオバックログ、そして仕掛中のプロダクト群 |
| プロダクト | 数ヶ月単位か、あるいはもっと長期 | プロダクトオーナー、ステークホルダー | ビジョン、そしてプロダクトの成長 | プロダクトのビジョン、ロードマップ、そして概要レベルのフィーチャー群 |
| リリース | 3ヶ月から9ヶ月程度 | スクラムチーム全体、ステークホルダー | 顧客に届ける価値と全体的な品質について、スコープやスケジュールそして予算などの制約の範囲で継続的にバランスを取る | リリースプラン |
| スプリント | イテレーションごと（1週間から1ヶ月） | スクラムチーム全体 | 次のスプリントでどのフィーチャーを出荷するか | スプリントゴール、そしてスプリントバックログ |
| デイリー | 毎日 | スクラムマスター、開発チーム | コミットしたフィーチャーをいかに完成させるか | 進捗確認、そしてその日の作業をうまく進めていくための調整 |
第16章 ポートフォリオプランニング
この章からは、やっぱ遅延コストかな。よさげな概念だとは思うんだけど、まだ理解しきれていない。次かその次に感想ブログあげる予定のリーンエンタープライズでも出てきてるので、そっちも合わせて考えてみよう。
なお、ポートフォリオレベルでのプランニングとは言ってるけど、別にポートフォリオに限らずプロダクトレベルやリリースレベル以下でも十分に適用できる内容も多かったです。上記の遅延コストもそうですし、小さなリリースとか、WIPの制限、作業者の手待ちじゃなくて作業の手待ちとかとか。
第23章 未来へ
「23.4 スクラムを使って、進むべき道を探し出せ」がよかった。スクラムを広げる際、まずは少数のチームから始めて次に組織全体に広げていくことになったお話。全体に広げるときにやるべきことをバックログとして管理して、3週間のスプリントで見直しながら取り組んでいったというお話。開発じゃなくても物事を進めるときのフレームワークとしてスクラム（のエッセンス）を使うのもよさそうです。
最後に小ネタですが、高校の合唱コンクールでキロロの「未来へ」をピアノ伴奏しました。男の人がピアノ弾くと、映えるのでオススメです♪
スクラム自体というより、スクラムをうまくやるための周辺の考え方やツールなどが役に立ちました。スクラムのルール自体は、スクラムガイドで分かるしね。
ちなみに、ブログ書くときは再度読み直すのでこれも2周目なのですが、今回はいつにもまして以前読んだことをまったく覚えていない。。。まあ、だからこそ改めて読み直す意義があるのでしょうが。
