- 認定スクラムマスター研修を受講した際のメモをまとめたものです。あまり他人向けではないかもしれません。
- もう何年も前のなぐり書きを下書きに放置していたので内容が陳腐化しているかもしれませんがご容赦ください。
1日目
客観的に証明された検証
なぜ? その目的は? を常に問うことを忘れない。
プロダクトのつくり手として、たぶん大丈夫 だと勝手に思い込む/主張する。
それが問題だ、と指摘されない限り、問題にはならない。
- 「障害だ」と指摘されない限り、それは障害ではない。
- 「バグだ」と指摘されない限り、バグは顕在化しない。
- 「今まで大丈夫だったから」
- それって本当? 検証できる?
「これでいいや」「このくらいでいいや」
- プロダクト開発を前進させるためにこう考えがち。
- 前進していると思いたいから自分にこう言い聞かせる。
- 本当に課題ならばそれを取り上げて、解決を働きかける必要がある。
プロジェクト内に埋もれた「課題」を見つけ出し、チームを救う役割を担う。
- 思い込みではなく戦略的にアプローチして、プロダクト開発を前進させる。
- 「人」にフォーカスして働きかける。
集団心理と組織論
本当の課題にアプローチするには、集団心理と組織論が不可欠の要素。協働のためにはぜひ考慮すべき。
- 課題の解決策はスクラムは導き出さない。「人」が導き出す。
- 「人」の集まりであるチームが一致団結して総合力を発揮するためにはどうしたらよいか、ということを常に考える必要がある。
- そのためには組織論の考え方やスキルが必要になってくる。
- ただし組織論だけを持ち出して、それを適用したからといってチームはまったくよくならない。
- その考え方やプラクティスがチームにどう影響してどのような効果を生み出すのか、ということは、集団心理の側面まで踏み込んで考える必要がある。
- 人は機械ではないから、何かを適用したからといって思惑通りに動くと思ったら大間違い。
- 気の持ちようや心の動きにまで踏み込んでいく必要がある。
Team-Based Organization
自ら行動して前進することを容認する。
例えば戦場で命の危機に直面したとき、わざわざ司令部の上官に判断を仰いでいては死んでしまう。現場がその都度判断をする。
- リーダーシップはあっても、特定のリーダーはいない。
- 状況に応じて先導役が変わる。
スクラムは Team-Based Organization を今のところベストプラクティスであると考えているので、これを採用しているが、今後さらによいプラクティスが新たに登場したら、この考え方を見直して簡単に乗り換えるだろう。
ヒエラルキーの上にいる人々が使い物になるか?
- マーケットに価値を提供する人々 = 現場の人たちが自由に動き回れる状態を作る必要があるのではないか?
- ヒエラルキーの上にいる人々は、ビジョンや方針は作るものの、それに対するアプローチのしかたまで逐一指示する必要はなく、現場が自分たちで考えてどう進むかを考えるべき。
参考: ピーターの法則
- 組織は無能で構成される。
- あるレイヤーで有能だった人材が上のレイヤーに上がると別のスキルセットを求められるが、それを体系的に学ぶことができない。
- 結果的に各レイヤーは無能が集まる。
- 組織内でその人が本領発揮するのはどのポジションなのかを評価する方法はない。
- 一般的に片道切符で、レイヤー間を移動することがないから。
チームのあるべきスタンスと思考性
スタンス
- 自分たちで考えてリスクを許容する。
- リスクを許容した上でどれだけベネフィットを取れるか。
- そのためにチームはどう考え、何を選択するか。
姿勢によるリスクの捉え方の違い
| 受け身 | 攻めの姿勢 |
|---|---|
| 拒絶、なんでだよ、お仕着せ | 許容、考慮、選択 |
思考性
- マーケット (ゴール) に向かうこと。
- そのためにチームはどんな手法 (How) を採択するか、自分たちで決める。
- リーンキャンバス、MVP、カンバン、etc...
- 課題解決の手法やプロセス
依頼側の中途半端な How の混じった依頼
何かを依頼されたときに混じってくる、「このやり方でやってください」とかいうもの。やりたいことが満たせればよいのだから、手法まで指定される筋合いはなく、本来は不要なはず。
-
Whatだけ教えてほしい。-
Howはチームが考える。 - それにあたってのリスクも考慮する。
-
What の中に How が混じっていると、やり方を選べないのでリスクを自分たちで許容できなくなる。非常に危険。
これらをきちんと分割するのがスクラムマスターの役目。
- 何がしたいの?
- 依頼のエッセンスを抽出する。
- ゴールは何?
- どうやるの? はチームが考えること。
- やったときのリスクは? もチームが考えること。
スクラムマスターの存在によってプロジェクトはどうなるか
- 細かな問題があっても、炎上はしない。
- プロジェクトがなんとなく、そつなく終わっている状態になる。
スクラムはどんなフレームワークか
「人」にフォーカスしたフレームワーク
- スクラムはあくまでもフレームワークに過ぎない。
- 実際にそれをやるかどうかは「人」のがんばり次第。
- 人の行動を規定するのではなく、自発的に期待以上のアウトプットを出すことを狙ったフレームワーク。
現状を計測するフレームワーク
- 課題を解決するものではない。
- 課題解決するのはあくまでもチームがやる。
- 解決に導くために全力でチームをサポートするのがスクラムマスターの役目。
-
現状がダメなこと が明確になる。
- 適用したからといって現状がよくなることはない。
誰にでもできる
スクラムのフレームワークに従って進めることに特別なスキルはいらない。
- 有能なエンジニアでも、靴紐が結べないぐらいの無能でもできる。
- Sprint1 が終わった段階で、チームのポテンシャルは把握できる。
- Done できるか否か、これに尽きる。
2日目
事象の捉え方
- 人が変われば、同じ事象を異なる観点で捉えがち。
- 絶対異なるはず。
- 多様であることを容認する。
- 個々の事象について、チームがどう捉えるのかを都度考える。
- 事象の捉え方をどうするか、チームが合意すること。
- チームの総和で事象を捉える。
最も厄介な「サイレンサー」
Silencer: チームの中で何も意思表示をしない人。これが最も厄介で、反対してくれる方がよっぽどマシ。
改善案
ダメな点だけでなく、改善案が出てくるとベター。
チームが自律的になっている証拠。
実績 (経験) 主義
実績や経験があれば、リスクを理解/受容した上でどうするか、自分たちで決めることができる。
ものさしの必要性
ありとあらゆることに「ものさし」が必要。
あらゆる事柄を「計測」して、その結果から次の一手を打つ。
- ひとつひとつのイベントにかかる時間を正しく計測する。
- 細かなことでもどのぐらいかかったか、を実績として記録していく。
- ex. スプリントプランニングで1つの機能について進め方を計画するときにどのぐらい時間がかかるか。
- ex. ふりかえりの各アクション (データを出す、議論するものを決める、改善アクションを導き出す、など) にどのぐらい時間がかかるか。
これが「スクラムマスターはストップウォッチが必携」とも言われる所以。
計測によりチームのポテンシャルがわかるようになり、例えば各イベントや会議はどのぐらいの時間をセッティングしておけばいいか、といったことが経験に裏打ちされて正確にわかる。
スクラムで最も重要とされる三本柱
| Inspect: 検証 | Adapt: 適応 | Transparency: 透明性 |
|---|---|---|
| 確認、計測、検証、未来予測。 | Inspect の結果をもとに選択する。現状維持 (keep going) を受け入れることもある。 | 常に使える情報がただ1つで、複数に存在しないこと。それが新鮮/最新であること。誤認されないこと。 |
Transparency が担保されていれば、次の行動を誘発するトリガーとして作用させられる。
逆に担保されていなければ、未来の予測もできないし、問題のあぶり出しもできない。
役割 (Scrum Roles)
役割の一覧
| 名前 | 役割 |
|---|---|
| プロダクトオーナー (Product Owner) | スクラムチームの ROI を最大化する = スクラムチームのコストを減らし、次にマーケット (チーム) がもたらすリターンを増やす。 |
| チーム (Team) | スプリントプランニングで約束したことを実現する。チームの生産性を具体的な何かで向上させる。生産量ではない ことに注意。 |
| スクラムマスター (Scrum Master) | スクラムをプロダクトオーナーやチームに最大限活用する。もし適さない (効果が最大限発揮されない) 場合には他の方法論へ導く。 |
補足
プロダクトオーナー
チーム内の共通言語を作り、コストをゼロにする。
- 言葉の意味をうまくコントロールすること (七色の言葉) が求められる。
- コミュニケーションコストを減らす。チームから質問されない。
- ただしこれは単なる「中間生成物」に過ぎない。
- プロダクトをすぐ作れる。認識のズレが起こらない。見通しが立てやすい。
スクラムマスター
- プロジェクトで「スクラムをやる」と言ったからといっても、ずっとそれが続くわけではない。プロジェクトの過程で変わることもある。
- スクラムが効果を発揮しないとわかったら、ウォーターフォールでもなんでもためらいなく採用する。
- 既存のプロジェクトマネージャーとはやることが異なる。
- 既存のプロジェクトマネージャーがやることは、プロダクトオーナーとチームがほとんどやる。
- スクラムマスターはそれを手伝う。
ロール間で何かしら摩擦が起こるように設計されている
- 敢えてそのようになっている。
- 例: プロダクトオーナーとチームとで、やりたいこととできることの意見が合わない、など。
3日目
(この分け方見直したほうがよさそう)
セレモニー
スクラムで1スプリント内に行われるイベントのこと。
スプリントプランニング
目的: スプリントの ROI を明確にする。
- スプリントプランニングを通して、スプリントでやることが完全に明確になる。
- 不明確なものは上がってこない。
- ここを徹底的にやらなければ、スプリントのベロシティは上がらない。
- スプリントの途中で「これはどうやるんだっけ?」「これは調整済みじゃないんだっけ?」は致命的。
- 「スプリント」というぐらいだから、文字通り「駆け抜け」られるくらいにタスクが明確になっていなければならない。
- スプリンターが途中で考え事をするか? 何も考えずに一気に走りきるはず。
- プランニングの最中にちょっとした開発をやっちゃってもいい。
- ちょっとした修正ならプランニングの最中にした方がいい。
- スプリントプランニングで見積もる内容は、0.5h か 1h のどちらかで終わるぐらいに細かく分割する。
- 内容を満たすまでキチンとやる。
- 他のセレモニーと違い、これだけは時間よりも 内容を優先 する。
プロダクトバックログリファインメント
目的: 中期の見通しを立てる、もしくは再計画する。
- この調子で終わるかどうか? 何か見直したほうがよいことはあるか?
- プロダクトバックログアイテム以外のあらゆるものをインプット情報とする。
- 時間が経ったら終了する。
スプリントレビュー
目的: スプリントプランニングでコミットしたことをレビューする。
- 機械的にできるはず。
- スプリントプランニングで細かく計画しているから。
- 優先順位の高いものは先にできているので、スプリント中にチェックできているはずだから、スプリントレビューでレビューするものは少なくなっているはず。
- 時間が経ったら終了する。
目的その2: プロダクトをより良くするための議論 (もっとこうした方がよさそう)
- ステークホルダーによる確認と、次スプリント以降の意思を出す場。
スプリントレトロスペクティブ
目的: 生産性を上げるための、TakeAction を1つ以上決めてコミットする。過去の TakeAction をチェックする。
- スプリント中に何をやったか、ふりかえりの素材集めはスクラムマスターの責任。
- 古い記憶は覚えていられない。
- どうすれば記録を最新/完全にしておけるか、を常に考える。
- 出てきた内容を並べたら最近のしかない、と偏らないようにする努力が必要。
- 前回の TakeAction をチェックする。
- チームがやると決めたアクションなので、できていなかったら叱責してよいレベル。
- そのアクションが皆になじんだら外す。
- 時間が経ったら終了する。
デイリースクラム
目的: チームが学習したことを共有する。
- 解決はここでしない。
- 3 Questions (昨日やったことは? / 今日やることは? / 何か問題点は?) はあくまでも目安。
- 「何か問題点は?」はスクラムマスターが最も聞くべきこと。
- 「特に問題点はありません」は危険信号。
- 仮にこれがあったら、スプリントプランニングがマズイ可能性がある。