SCRUM 開発手法メモ

目次

• 0. 基本的な考え方
• 1. Events（イベント，ミーティングや会議など）
• 2. Rolls（ロール，役割）
  • 2.1. Product Owner（プロダクトオーナー）
  • 2.2. Developers（開発チーム）
  • 2.3. Scrum Master（スクラム マスター）
• 3. Artifacts（作成物）
• A. 実践的ノウハウ
  • A.1. 見積もり
  • A.2. チームの処理能力（velocity）

0. 基本的な考え方

• 事前にすべてを正確に予測し，計画することはできない．

この前提にたち，下表の右欄のような考え方で開発を進める．

誤解を恐れずいえばこんな感じ（エライ人に見つかったら怒られそうだけど ^_^;）

• カンで「5人 × 3か月で！」と決めてしまう
• やりたいことを順位付けしたリストの上から順にできるとこまでやる

さらに

• だらっと作業しないために固定の短い期間「タイムボックス」という考え方を重視する（わざわざ「ボックス」といっているのは「伸びたり・縮んだりしないよ」という意味）．
  • 「できないから延長」などはしない．3か月と決めたら必ず3か月．
  • さらに2週間の「スプリント」に区切って｛計画 → 設計 → 実装 → テスト｝を繰り返す．この2週間も伸ばしたり縮めたりしない．
• できないから人を増やすなども（基本的に）しない．
• できなかったことは Product Backlog に積み残して終わりにする（ってエライ人に見つかったら怒られそう ^_^;）

以下に SCRUM の3つの基本概念を説明する．

• Events（イベント）
• Rolls（ロール，役割）
• Artifacts（作成物）

1. Events

1.1. スプリント（Sprint）

SCRUM手法はとにかく「短く区切って繰り返す」のが特徴．その基本単位がスプリント．

• 1回2週間固定の開発サイクルのことを「スプリント」と呼ぶ．
  • 3か月 = 12週間を 6スプリント に分割．
    • 現実には最後数週間に「リリース スプリント」という最終事務作業をやる特殊な期間を設定する場合もあるけど，基本は2週間固定のスプリントを繰り返す．
  • 備考　1スプリントの長さは1週間としたり，もっと長く4週間にしたりする場合もあるが，伸び縮みさせてはいけない．一度「n週間」と決めたら常にn週間を使い続ける（以下は2週間で説明します）．
• 2週間のように短く固定するのはリズムによる集中を生み出すため．
• 短く区切ることで進捗把握・リスク対応を容易にする．
• 2週間の中でプロダクトバックログ項目を完成させるためのすべての作業｛計画 → 設計 → 開発 → テスト｝をやる．
• 作業が残っていてもスプリントは終了．
  • 延長戦はなし．完了できなかった項目は単位「失敗」としてバックログにもどす（次のスプリントバックログに送る）．
  • 「あとちょっと」とかを期間延長で処理しないのはチームの処理能力（velocity）を正しく把握するため．
• 備考　特例としてプロダクトオーナーだけは要求の変更などにより今のスプリントが意味をなさなくなった場合に打ち切りができる．

1.2. スプリントの中の4つのイベント

1回のスプリントの中には下記の4つのイベントがある．

2. Rolls（役割）

Scrum Team 内には下記3種類の役割（Rolls）の人がいる． Scrum Team 外の関係者のことを Stakeholders（ステークホルダー，利害関係者）と呼ぶ．

• Scrum Team
  • Product Owner
  • Developers
  • Scrum Master

2.1. Product Owner（プロダクトオーナー）

• プロダクトの価値を最大化するため何を作るか（What）を管理する．
• Product Backlog の管理責任者．
  • Product Backlog の作成は開発チームと協力する場合もあるが最終責任はプロダクトオーナー．
  • 各項目の並び順の最終決定権者．
  • おおよそのリリース計画を決める．
  • 各項目が完成しているかどうかを確認する．
  • Product Backlog のメンテナンスを継続的に実施する．
• 1プロダクトにつき1名のみ（not 合議制）．
• プロダクトの最終責任者はプロダクトオーナー．なので，プロダクトオーナーが決めたことを勝手に覆してはいけない．
• 開発チームに相談はできるが干渉してはいけない．
• ステークホルダーと協業．
• 予算を管理する．

2.2. Developers（開発チーム）

• 実際に開発する人たち．
• 組織は完全フラット．役職・肩書（上下関係）はもちろん固定した役割もなし．
  • サブチーム（マシンの手配だけをやってる人とか）は作らない．全員同じ作業をする（機能横断的チーム）．
• 3〜9人
  • 10人以上はコミュニケーションコストが大きすぎる．
  • 2人以下はスプリントで意味のある大きさのものが作れない．
• Sprint Backlog を作成・管理．
  • チーム内で作業の進め方を決める（自己組織化）．進め方について外部からの干渉を受けない．

2.3. Scrum Master（スクラム マスター）

• SCRUM手法の理解の促進・実践指導をする苦労人（アツいハートをもってる人しかできなさそう ^_^;）
  • プロダクトオーナーや開発チームだけではなく，ステークホルダーからの干渉（妨害・割り込み）なども指導・排除する．
• すべてがうまくまわるように支援と奉仕を続ける，まさに Servant Leadership そのものなSCRUM手法における真のリーダー的存在． 役割は多岐にわたるので詳しくはSCRUM GUIDEを見て．
• 管理職ではない．
  • タスクのアサインや進捗管理はしない．
• スクラムマスターとプロダクトオーナーは兼任禁止．
  • 開発者の近くにいてスクラムマスターと とにかくモノをよくしたいプロダクトオーナーは基本的に利益相反の関係にあるため．
  • 従来型の開発手法では，いわゆるリーダー格の人が両方を兼ねたような感じの役割でバランスをとったりしてることが多いと思うけど，SCRUMでは分離することが求められている．

3. Artifacts（作成物）

• Product Backlog
  • 実現したいこと（What）が書きだしてあるリスト．バックログというのは例えばお店で注文が入ったけどまだ発送してないものみたいな意味．
• Sprint Backlog
  • Product Backlogの各項目を実装・実施可能なレベル（How）に分解して各スプリント用につくったバックログ．
• Increment
  • 簡単にいうとプロダクトのこと．++iみたいに日々成長しているので増分（インクリメント）と呼んでいる．

A. 実践的ノウハウ

A.1. 見積もり

• 見積もりは当たらないもの・推測にすぎないと割り切って，正確さを求めず短時間で「大雑把な大きさの把握」程度で済ませる．
  • 時間をかけて精度を上げてもハズレると精度を上げるために投入した時間がムダになる．
  • ハズレる前提で短いサイクルでやりなおすのがキモ．
• 見積もりは具体的な作業を見通せる「タスク」単位で行う．
• 「相対見積もり」とする．
  • 作業量・たいへんさが把握できている標準的な作業を 3 ポイントと設定する．
    • 単位は「ポイント」としておく．
    • 「人時」みたいな物理的に測定可能な単位をさけて精度に対するこだわりを払拭するため．
    • 標準は，すべてのタスクを並べて比較したときに 10 倍くらいの範囲に収まるものにしておく（できるだけコンパクトにまとまる中央値あたりのものにしておく）．「100倍大変そう」みたいな大きな数値のものがでてくると大変さが想像できなくなってくるため．
  • それよりたいへんそうなら 5 や 8，簡単そうなら 2 や 1 を設定する．
  • 数値は 1, 2, 3, 5, 8, 13, 21, ... のフィボナッチ数列から選ぶとよい（経験則でしかないけど）．
    • フィボナッチ数から選ぶとよい理由のひとつは「わからないことに対して適当なバッファーを積む」のと似た効果があるからだと考えられる． 標準タスク（3）よりたいへんと思ったとき，次の数は5なんだけど「2倍はたいへんそう」と思ったら2倍より 33% 大きい 8 を設定しておくことになる．この 33% がバッファーとして作用する． 「8じゃ済まない」と思ったら次は 13 になり，わからないレベルが大きくなるほどバッファーも大きく積まれる仕組みになっている．

A.2. チームの処理能力（velocity）

• 1スプリントでのチームの処理能力を velocity（ベロシティー）と呼ぶ．
• 上位「ポイント」で見積もったタスクのうち，1スプリント内でできたものの合計がチームの velocity になる．
  • 「できたもの」のみの合計．
  • 「もうちょっとで完成だったのに…」みたいなタスクであっても切り捨て．完成度にあわせて割り引いて参入とかはしてはいけない．
• velocity がわかれば（何回かスプリントを回して安定してくれば）あと何スプリントでどこまでできるかが，ある程度の明瞭さで見えるようになってくる．
• 1スプリントを2週間に固定する（あと少しで終わりそうな作業を延長して終わらせたりしない）のは，この velocity を安定させるためでもある．

Links

• SCRUM GUIDES
  • スクラムガイド 日本語版 PDF, 2020/11.
• Manifesto for Agile Software Development（アジャイルソフトウェア開発宣言, 2001）
  • プロセスやツールよりも個人と対話を
  • 包括的なドキュメントよりも動くソフトウェアを
  • 契約交渉よりも顧客との協調を
  • 計画に従うことよりも変化への対応を

推薦書籍

SCRUM BOOT CAMP THE BOOK 【増補改訂版】，翔泳社 2020． 簡潔かつ実践的な内容にまとまっていて短時間で要点が把握でき（1日あれば十分），すぐにSCRUM開発を試しはじめられるようになると思います． 実は本家 SCRUM GUIDE も わずか18ページしかなく簡単に読めるのですけど実践につなげられるかというとかなり疑問．この本のように，ほどよく実践への応用と現実的な妥協点を示してくれるガイドが必要だと思います． この本は276ページありますが，本家 SCRUM GUIDE が扱ってる範囲に近い基礎編は21ページにまとまっていて，残りは実際にSCRUMをはじめるとハマりそうな問題の対処方法を扱った実践編になっています． 従来的な開発方法とSCRUMの違いを素早く知りたいというような方であれば基礎編21ページだけ読むのもいいですし，実際に試行錯誤してみたいという人はトピックごとに実践編を追加で読むというような方法でも活用できると思います．