3-12 Scrum – アジャイル開発手法

参考図書

• Scrum Guide 。2020年更新（配信時の情報）。
• Scrum Boot Camp 。漫画で実践例を交えて描かれており分かりやすかったです。

アジャイル開発とは

• 詳細は前回のエピソードで。
• アジャイル開発 Agile software development：これは価値観！
  • Waterfallなど計画に重きを置く開発手法（重量ソフトウェア開発手法）に対抗
  • Agile Manifesto
    • プロセスやツールよりも個人と対話を
    • 包括的なドキュメントよりも動くソフトウェアを
    • 契約交渉よりも顧客との協調を
    • 計画に従うことよりも変化への対応を
  • Agile software development principles：12の原則
• 前提：事前に全てを正確に予測し、計画することはできない <=> predictive でなく adaptive
  ※ただし計画を放棄するわけではなく、大まかなリリース計画などは必要。
• 方法（参考：Agile Software Development (Wikipedia) ）
  • Incremental：少しずつ作る、計画、設計、実装、テストを行って実際に動作するものを一歩ずつ作る
  • Iterative：反復する = 計画、設計、実装、テストの一連を反復する
  • Evolutionary：デモを通じてstakeholderからfeedbackをもらい、計画を見直す
• 効果：リスク低減、変化するニーズへの素早い対応、早い市場投入

具体的にどうやってアジャイル開発をすすめればよいのでしょうか？この一つがScrumです。

Scrumとは

• アジャイル開発の手法の一つ。Scrum Guide: https://scrumguides.org/ 。2020年更新（配信時の情報）。
• 参考図書：Scrum Boot Camp 。漫画で実践例を交えて描かれており分かりやすかったです。
• 経験主義に基づくScrumの3本柱
  • 透明性：何をやるか、何をやるべきかをチームで共有し、明文化する
  • 検査：透明性が確保されたうえで、成果物が正しく動作するか、またチームの活動が目的に沿って正しく行われているか、をチェック
  • 適応：feedbackに応じて計画を変更する

Scrumの構成要素 – 3つのロール

Product Owner：プロダクトのWhatを担当

• 一人！合議制ではない！
• 具体的な役割は以下です：
  • プロダクトのvisionを明示し、他メンバと共有する。
  • リリース計画をあらかじめ決めておく。
  • 予算管理をする。
  • Stakeholdersと調整する
  • （成果物である）プロダクトバックログを確認し優先度を変更する
  • プロダクトに対して説明責任 accountability を持つ。

Development Team：プロダクトのHowを担当

• 3人～9人が適切。Amazonのチーミングルールであるピザ2枚ルールと近い。
• 全員でプロダクトを作るスキルがそろう：cross-functional
• 肩書、サブチームはなし

Scrum Master：スクラムのプロセス円滑化を担当

• チームのラーニングカーブ、生産効率を上げる役割。
• サーバントリーダー (2017) => true leader (2020)
• 具体的な役割は以下：
  • チームメンバの教育、コーチング。
  • イベントのファシリテート。
  • 他ステークホルダとの相談を促すなど。
• 注意：Scrum Masterはマネージャーや管理者ではない！タスクのアサイン、進捗管理をしない。
  • では誰がタスクをアサインするの？という疑問がわくかと思います。これはDevelopment teamのメンバで決めることになります。バックログを確認し、自発的にタスクを担当することを進言します。問題を発見したら自発的に全員に働きかけ、各人がタスクを自発的に分担する、自己組織化された self-organized チームが形成されるよう、Scrum Masterはメンバを教育、コーチングしていく必要があります。
• Product OwnerとDevelopment teamの調整役も重要。

Scrumの構成要素 – 5つのイベント

Sprint

• 1週間～1ヶ月の定まった期間。プロダクトに応じて定めればよい。
• この間に計画、設計、開発、テストをすべて実行。
• 例えば要件が分からずヒアリングが必要な場合は、1週間などと短い期間を設定し何度もイテレーションを回すScrumを組むのが一つの方策。

Sprint Planning

• (1)Product Ownerが欲しいもの、(2)Development Teamができること、(3)Development Teamが実現する方法、の3つを定める。
• それぞれを共有し「透明性」を高めるため、以下を設定する：
  • (1)：「スプリントゴール」「プロダクトバックログ」「完成」
    • 「スプリントゴール」：
    • 「プロダクトバックログ」：達成したいことを優先度付けする。
    • 「完成」：例えば演算性能やパフォーマンス、テストなど。
  • (2)(3)：「スプリントバックログ」
    • スプリントバックログの各項目は、1日以内に終わる粒度に分割する。
    • すべて完了することをProduct Ownerに約束はしていない！作業達成量を正しく見積ることができるよう、無理をしない。
• 1ヶ月のSprintで8時間、Sprintが短ければより短くする。

Daily Scrum

• 毎日決まった時刻に15分ほど行う。
• 参加者は基本的にDevelopment team。Product Ownerは出席しなくてよい。
• 「検査」の一つであり、ゴール達成のために、昨日やったこと、今日やること、業務を進めるための障害の3点を話す。

Sprint Review

• Sprintの末に行う。
• StakeholdersにSprintで作成できた成果物（＝インクリメント）を見せてfeedbackを得る。

Sprint Retrospective

• Sprint Review後に行う。
• Sprintの活動に対する「検査」：改善点

Scrumの構成要素 – 3つの成果物

• プロダクトバックログ：製品のWhatを決めるものであり、Product Ownerがその優先度を管理する。
• スプリントバックログ：製品を作るHowを決めるものであり、Development Teamがその内容と優先度を管理する。
• インクリメント：動作するソフトであり、Sprint Reviewでfeedbackを得るために必要。設計段階であれば図面やパラパラ漫画でもよく、アイデアを伝えてfeedbackを得られるものであればなんでもよい。

Key Point

• Incremental（少しずつ作る）、iterative（一通り回して動作可能とする）、evolutionary（feedbackをもらって再計画する）の3つがちゃんと設計されているか？
• 1週間～1ヶ月のSprintでvelocityを測定できているか？時間を経るごとに、作業量の予測精度があげられているか？
• 注意：velocityは作業量であり、進捗ではない！進捗は目標があることを前提としているが、ScrumではSprint Reviewを経て目標が変更されうるため適切ではない。本来やりたいはずのことは、ある目標を設定した時にこのチームがどの程度のことをどの程度の期間でできるか、という見積もりができることであり、作業量を見積ることが重要。

役割は兼ねちゃダメなのか？

Product OwnerとScrum Master / Development Teamを兼ねてよい？

• これはアンチパターン！強く非推奨！
• Product Ownerは顧客視点で機能リリースを早くやりたいが、Scrum MasterとDevelopment Teamは開発可能なスケジュールを守りたいため、目的がぶつかる。役割を兼ねた人はバランスが取れなくなってしまう。
• 開発体制に問題意識を持っている人ほど、Product OwnerとScrum Masterを兼任せざるを得ない状況に追い込まれそうだが、それは絶対に避けたい。事業部門、上司などを説得して適任な人をまきこもう。

Scrum Master と Development Teamを兼ねてよい？

• 否定はされていないが、推奨ではない。
• Scrum Masterは2～3のScrumまでなら担当可能とされており、役割毎に横断的とする方が良い。

マサトの経験

• 過去にScrumをやったときはProduct Ownerを担当。ただし一人ではなくチームの一員として参加。スクラムガイドに記載があるやり方は「型」であり、現場ごとにアレンジしてよいと思う。
• 例えばDXの文脈で、ソリューションを内製するプロジェクトでScrumを用いる場合、Product Ownerは顧客目線を持ったビジネス/事業ユニットの人、Development teamはIT部門の人（outsourcing先の人を含んでよい）、という役割になると思う。プロジェクトの置かれた状況に応じて柔軟に変更しよう。
• 経験を通して知れて良かったことは、Product Ownerがちゃんと決めることがScrumを進める上でとても重要。そのためには何となくで会議に参加しないことが重要。
• Product OwnerがWhat、Whyを決め、開発チームと共有することで、良いアイデアが沢山出てくる。またfeedbackを通じて柔軟に変えていける仕組みを使って、いい方向に変えていくのがよい。