この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
事業開発部の大矢です。
先日、認定スクラムマスター研修を受講しました。
そこで私が学んだことを記します。
この記事は、研修の中で聞き取った内容をベースとしています。
研修での理解を促進するために、あえて大げさで極端な表現を用いている部分もあるかもしれません。
また研修の内容を個人的に解釈して書いている部分もあります。
一般的な言葉の定義と異なる部分もあるかもしれません。
以降読まれる際は、これらの点について、ご了承ください。
また以下の内容を当ブログに掲載することについて、事前に研修を開催しているOdd-e Japan様に相談し、了承をいただいております。
認定スクラムマスター研修の概要
- 認定スクラムマスター研修
- 2018/02/28 - 03/02
- 講師：江端 一将
スクラムとは
プロジェクトの状況を把握するためのフレームワークです。
「状況把握」の要素
- 透明性 (Transparency)
- 正しい情報が1箇所に集められており次の行動が誘発され続けている状態
- 検証 (Inspect)
- ゴールと現状の差分を把握し続けている状態
- 適応 (Adapt)
- ゴールと現状との差分を埋めるために活動し続ける状態
役割 (Role)
スクラムには、以下の役割があります。
- プロダクトオーナー
- チーム
- スクラムマスター
この3つを合わせて、「スクラムチーム」と呼びます。
プロダクトオーナー (Product Owner / PO)
戦略 (what) を作る人です。
スクラムチームの投資収益率 (ROI) を最大化することに責任があります。
プロダクトオーナーは、スクラムチームに1人です。
- ゴール、戦略、戦術
- why: ゴール。目的。
- what: 戦略。そのために何をするか。
- how: 戦術。手段。
プロダクトオーナーは顧客側？
違います。プロダクトオーナーはチーム側の組織（会社）の人が担当します。
プロダクトオーナーが見ている ROI は、スクラムチームの ROI です。（顧客の ROI ではない）
チーム (Team)
製品を作る人たちです。
チームは、スクラムの活動を通じて「自律的なチーム」に成長します。
チームは製品開発の生産性（ ≠ 生産量）を向上します。
1チームは7±2人で構成します。
大規模なスクラムチームは、複数の「チーム (Team)」で構成します。
ある程度長く同じメンバーでチームを構成することが望ましいです。
プロジェクトが終わったとき、チームを解散してバラバラにするのではなく、チーム単位で次の仕事に当たらせると効率的です。
チームを壊す簡単な方法は、人を追加することです。
「プロジェクトマネージャー」の仕事
スクラムには「プロジェクトマネージャー」という役割は登場しません。
では従来の「プロジェクトマネージャー」の仕事は、スクラムでは誰が担うのでしょうか？
→プロダクトオーナーとチームです。
スクラムマスター (Scrum Master / SM)
スクラムマスターは、チームの状況を把握し、適宜支援します。またチームを外部の干渉から守ります。
スクラムマスターは、チームをゴール達成へ導きます。ゴールは必須で、効率的にゴールに達することを考えます。
スクラムマスターは、チーム毎に1人です。（複数チームの兼任は困難）
チームビルディング
スクラムマスターは、チーム立ち上げから3ヶ月程度で「自律的なチーム」を作ることを期待されます。
スクラムを使わない判断も
スクラムマスターは、スクラムを使うか否かを判断し、使う場合、最大限スクラムを活用します。
しかし使わない方が適切と判断した場合は、チームを他の方法論へ導くこともあります。
スクラムマスターの5つのスキル
- ティーチング
- ファシリテーティング
- メンタリング
- コーチング
- シチュエーショナリング
スクラムマスターの仕事のイメージ
- Office Linebacker (動画)
- コミカルな動画で、スクラムマスターの仕事のイメージを掴むことができます。
スクラムの Celemony
スクラムの Celemony には、以下のものがあります。
- Sprint Planning
- Daily Scrum
- Product Backlog Refinement （本記事では記載無し）
- Sprint Review （本記事では記載無し）
- Sprint Retrospective （本記事では記載無し）
Sprint Planning
Sprint の長さ
sprint の長さは1週間から 1ヶ月です。一度決めたら固定します。
動画：ゲーム開発チームの Sprint Plannning
- Sprint Planning の例として、とあるゲーム開発チームの Sprint Plannning の様子を鑑賞。
- 広い部屋にスクラムチーム全員が集合する。（一部はリモート拠点から TV 会議での参加）
- まずプロダクトオーナーからスクラムチーム全員に対し、マーケット課題を説明。
- チームが Product Backlog を取って、自分たちの Sprint Backlog にする。
- Backlog の内容を理解するため、チーム内外問わず必要な人とコミュニケーションする。
- 設計までは、Sprint Planning で完了させてしまう。
- Backlog ごとに、「受け入れ基準 (Acceptance Criteria)」を作る。
- 必要なコミュニケーションは Sprint Planning で済ませてしまう、という考え。翌日以降は、個別にモクモクと作業する。
- この例では、Sprint Planning に丸1日かけている。（スプリント期間は1週間）
このチームは、 Sprint Plannning を重要視し、 十分時間をかけて、決めるべきことをこの場ですべて決めているようです。具体例を見ることで、 Sprint Plannning の理解が深まりました。
割り込み作業
Sprint Planning を終えた後、sprint 期間中は、プロダクトオーナー等による作業追加はできません。
Daily Scrum
毎日チーム全員で行うミーティングです。
以下の3つの質問を確認します。（テキストより転記）
- (1) 前のデイリースクラムから何を完了したのか。
- (2) 次のデイリースクラムまでに何を完了させようと考えているのか。
- (3) 現在、止まっていることや障害になっていることは何か。
これで状況を把握できますか？
もしメンバーからうまく状況を聞き出せていないと感じたら、自ら進んで話してもらえるよう、やり方を工夫するのも良いでしょう。テンプレートに縛られることはありません。
Product Backlog
Product Backlog Item（要求）のリストです。
受け入れ基準 (Acceptance Criteria)
Product Backlog Item には、受け入れ基準 (Acceptance Criteria)を明記します。
Product Backlog の管理はPOがやる？
Product Backlog の管理は、プロダクトオーナーがやらなければならない、というわけではありません。チームがやってもよいです。
プロダクトオーナーは「 ROI を最大化する」ことに責任を負っているので、それができていればよいです。（そして忙しいことが多い）
Product Backlog Itemは、プロダクトオーナーが書くわけではありません。実施する人であるチームに任せるべきです。（伝言ゲームも減る）
プロダクトオーナーからは、ビジネスの状況（何を優先してほしいか、など）を説明してもらいます。
後はチームが判断して、Backlogを処理していきます。
| 要素 | 担当 |
|---|---|
| マーケット課題 | プロダクトオーナー |
| マーケット課題を解決、改善、軽減するアイデア = Product Backlog Item | Team |
品質
品質には、「製品品質」と「技術品質」があります。
製品品質
- 「ペットボトルのお茶」であれば、味、量、パッケージデザイン、など。
- 相手が価値を認めるもの。
- スクラムでは、Product Backlog と Acceptance Criteria（受け入れ基準）で表現されます。
技術品質
- 「ペットボトルのお茶」であれば、健康を害さないこと、容器の耐久性、など。
- サービス提供者が担保するべきこと。（相手が「できていて当たり前」と思うこと）
- スクラムでは、Done で定義します。
完了の定義 (Definition of Done)
スクラムでは、プロダクトごとに「完了(Done)」を定義します。
Undone
例えば「完了(Done)」を以下のように定義したとして、
- ドキュメンテーション
- 仕様書、ユーザーマニュアル
- デベロップメント
- テスティング
- 単体テスト、結合テスト、システムテスト
- デプロイメント
「ログイン機能を作りました。終わりました。」と開発者が報告したときに、実際には、
- 単体テスト、結合テストは終わっているが、システムテストは行っていない。
- ユーザーマニュアルのログイン機能に関する部分は書いていない。
という状態だった場合、
- ログイン機能のシステムテスト
- ユーザーマニュアルのログイン機能部分
は、「Undone」として、 Product Backlog に残ります。
Undone として残した作業は、早めに消化しておくことが望ましいです。
例えば、次のスプリントで、製品品質の Backlog Item を減らして、Undone の消化に充てる、など。そうするとプロダクトオーナーは嫌がるかもしれませんが、説得しましょう。
Undone を先送りし続けるとプロジェクト炎上の可能性が高まります。
リリーススプリント
リリースするための残作業を行うためのスプリントです。
Undoneとして残した作業があれば、ここで消化します。
他にも、後でまとめて実施しようとしていた作業（性能テスト、等）を行います。
リリーススプリントは、無い方が望ましいです。（通常のスプリントで消化しておくことが望ましい）
受け入れテスト駆動開発 (ATDD)
受け入れテスト駆動開発 (ATDD) という手法があります。
Sprint Planningで受け入れテストを作り、それを完了条件として実装を進めると、プロダクトオーナーとチームの認識のズレが無くなります。
参考文献
最後に
この研修を受講して、スクラムの概念について、書籍等で理解していた段階よりもより深いところで理解できた気がします。
この記事では、私がそう感じたところを中心に、まとめてみました。
どなたかの参考になれば幸いです。
またこの研修はとても素晴らしく、刺激的な内容になっていますので、ご興味を持たれた方は、ぜひ受講してみてください。（人気のようなので予約はお早めに）
75
