はじめに
スクラムやスクラムマスターの考え方は、開発を進めたり、チームをまとめていく上で効果的だと考えています。
今回はスクラムのスクラムマスターについて学ぶ中で、今後の開発に役立ちそうな知識や考え方を書いていきたいと思います。
「勉強するもの」「スクラム関連」以外はスクラム開発以外にも当てはめて考えられるように、できるだけスクラムの用語を使っていません。
行動
- 現在の活動を分析することが重要
- 分析した結果、どのような問題があるか、改善はどうするかを考える
- 分析するときに、問題をブレークダウンする
- 質問を通じて理解を深めることで、相互理解も深まる
- 活動を分析する時に、どのように評価するかが重要（活動と評価基準はセット）
- 話を聞く時はリアクションを取ること
- 相手に多く話してもらうこと
- 何が正しくて、何が間違っているかは変わっていくので、考え方を常にアップデートする
- 失敗時に相談してもらうような関係を常日頃作るように心がける
- チームメンバーの行動を強制するのではなく、行動を促す環境を作る
- 自然と実行するような環境やルールを作る
- ルールはあくまで目的のためであり、ルールは臨機応変に変更する
- フィードバックをするときは、相手と自分で同じ基準を持ち、それに基づいて話す
- 基準を上回ったら、次の基準を設ける
- 基準を下回ったら、改善点、改善する行動を明確に伝える
- 改善する行動をいつするかは相手が決める（相手の権利と責任）
- 机上の空論・理屈では組織は動かないので、事実・成果を示して組織を変えるようにする
考え方
- 期間が短いことで見直せる回数が多くなる
- どれだけ自分たちの間違いを見直して確認できるか
- 初めて行うことを短期間にすると、抵抗が生まれるので、結果・期待値を緩める
- 習慣としてやっていく必要がある
- プランは複数考える
- 問題が発生する可能性や、急な休みなどリスクをすべて考える
- 状況によってはトレードオフをしないといけない
- 組織内で他のステークホルダーと調整をしないといけないので、開発チームの特性などについて詳細に理解しておく
- チーム自体で意思決定してもらうためにはどうすればいいかを考える
- チーム自体に行動の責任がある場合は最後まで実行してもらう
- 行動の権利と責任は共存させなければいけない
- 行動を決める基準は論理的でないといけない
- 定量的に判断可能な基準を作る
- 基準に合うかどうかの方程式を作り、方程式をみんなに理解してもらって判断に使用してもらう
- 方程式があれば、より適切な判断をすることができる（計画を立てやすくなる）
- 行動の基準となるもの
- 行動の順序としてそれ以外ありえないかどうか
- 今行動しないと機会を逃すかどうか
- その行動が価値を向上させるかどうか
- 目的を達成するために曖昧な基準では意味がなく、論理的な判断基準でないといけない
問題の解決
- 問題を分割したり、解決する時に、それに関する知識の解像度が低いとうまくいかない
- とりあえず進めることは、見落としを生むので良くない
- 問題解決の時は話し合う
- アプローチを考えるきっかけにする
計画・進め方
- 計画を進めながら分析することが重要
- 計画を進める中で、何が関連してくるのか見極める
- 計画の段階でゴールを必ず決めて実行すること
- どれが有効性が高いか
- 思い込みにより見落とす可能性があるので、分析する必要がある
- 解かなければいけない論点になっているかを常に考える
- チームの課題について直接解消するのではなく、サポートして自分たちで解決してもらう
- 様々な状況を考慮して、複数の計画を立てる必要がある
- 緊急の不具合対応、メンバーの体調不良、仕様変更などそれぞれを想定してすべてに対して計画を立てる
- 計画していない事態が起きたら、次回以降それらを考慮して計画を立てる
- 計画力を向上させることが重要
- 初めは計画に時間がかかるが、しっかり計画して実行する
- 計画を判断基準として、実行（活動）を計測・分析する
スコープ
- 時間の中で、過去から現在、未来までについて見て、未来のために改善を行わないといけない
- 未来で同じ失敗を繰り返さないためにどうするかを考えて現在を行動する（現在の改善だけを見ない）
- 未来地点での良いチームを作ることに価値がある
- サポートして良くする対象はチームであり、組織を変えることを目的にしない（チームを良くするために組織を良くする）
勉強するもの
- 学問としての組織はどのようになっているか
- 人の意思決定のためのプロセスはどのようになっているか
- スクラムガイドは開発者用にできているので、スクラムマスターについては別に勉強する必要がある
- 考え方を学ぶ
- 学ぶことで内容や話す順番がより良いものになる
- 話す中で相手と考えている内容が同じになるように、分析して、内容を変更する
- 理屈を考えるスキルを伸ばすことが重要
- 習得するものの考え方を理解しておけば、理解しやすいので習得する時間も短くなる
スクラム関連
- スクラムマスターはサーヴァントリーダーであり、直接指摘することはない
- 聞かれたらコーチングを使用して、自己解決するようにサポートする
- ワーキングアグリーメント（ルールや約束を明文化したもの）
- 目的とルールをセットで決める、罰則のためにあるのではない
- 人によって見解が変わらないようにするため
- 守らなかったら損をすることを対象とする
- 1つのスプリントは1週間で行う（現在の主流）
- 1つのタスク（スプリントアイテム）は10分単位で考える
- 短時間のタスクにすることで、どこで問題が発生しているか検知する
- 検証・適応・透明性の3つが常に担保されている状態を作る
- 守られていれば、現状を把握することができる
- いつでも検証できるように基準を方程式で計算できるようにする
- プロダクトバックログは、過去の状態になったら正しくないので常にアップデートする
- プロダクトオーナー（PO）は自分の部署から出して、スクラムマスター（SM）は自分の組織から出す
- ゴールを理解して、外部と調整できる人をPOにする
- 組織のチームの活動を改善しようとするのは、自組織の人だけなので自組織の人をSMにする（外部の人はチームの成長を促進するメリットがない）
- スクラムガイドはあくまでガイドなので、自分たちに合ったものにカスタムして良い（自分たちのスクラムガイドを作るのもいい）
- システムが1つ、プロダクトバックログが1つ、POが1人でも、プロダクトは複数ある（マーケットが違う）場合がある
- 複数の機能で1つのシステムになっていても複数POがいることは良くない（意思決定の速度が落ちる）
- スクラムではDone（やるべきことが明確）を積み上げて、Undone（不確定な要素がある）を減らすようにする
- プロダクトバックログはDoneItem → プロダクトバックログアイテムで行う
- Undoneが増えることで不確定要素が増え、問題の原因になる可能性がある
- 中間生成物の運用コストも考慮して、あまり作らない
- 問題を解決するために動かないので、他との調整で忙しくなることはない