スクラム開発を実践するための大切な考え方とよく使われるプラクティス / Important way of thinking and recommended practice for scrum development

Transcript

1. スクラム開発を実践するための 大切な考え方と よく使われるプラクティス kurama pommel
2. アジャイル開発のおさらい
3. アジャイル開発のおさらい • しばしば「ウォーターフォール開発」と比較される開発手法 • 「プロジェクトの完遂」を目的としたウォーターフォール開発に対して、「 プロダクトにおけるユーザー 価値の最大化」を目的としているのがアジャイル開発 • そのため、両者はしばしば比較されるが、実は目的が全く異なる別のもの • 「プロジェクトの完遂」という視点だとベルトコンベア式が最も効率が良いため、ウォーターフォール 開発が向いていた • しかし、昨今においてはユーザー側に選択の幅が広がったことから、価値あるものが取捨選択され るようになったため、「完遂したから利益が出る」とは言えなくなってしまった • そこで、ユーザー価値の最大化に着目したアジャイル開発が注目されるようになってきている
4. アジャイル開発のおさらい • アジャイルとは、常に改善している状態 、より良いものを作っている状態 のことを呼ぶ • アジャイル開発において重要なことは ◦ 「ユーザーが本当に求めているもの 」を ◦ 「数週間から数ヶ月という短い期間 」で ◦ 「繰り返し継続的に届ける 」ことにある • 近年では「アジャイル」な考え方は IT 業界特有のものではなく、「アジャイルな経営」といったビジネ スレイヤでの活用や、リサーチナースのような医療看護の分野でも活用されている • 今回はスクラムの話を中心とするため、アジャイル開発の歴史やより具体的な内容については、「ア ジャイルソフトウェア開発宣言」やアジャイル開発に関する書籍に委ねることとする ◦ https://agilemanifesto.org/iso/ja/manifesto.html
5. スクラムについてざっくり紹介
6. スクラムについてざっくり紹介 • まずは教科書から ◦ スクラムの内容については スクラムガイド にすべて記載されている • ざっくりと本文抜粋 * スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織 が 価値を生み出すための軽量級フレームワークである。 * スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から生 ま れ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。 * スクラムでは、予測可能性を最適化してリスクを制御するために、イテレーティブ（反復的） でイ ンクリメンタル（漸進的）なアプローチを採用している。
7. スクラムについてざっくり紹介 • アジャイル開発を実践するための最も有名なフレームワーク ◦ 必要最低限の枠組みだけが定められていて、「習得は易く、実践は難い」なんて言われたりす る • アジャイルに開発を進めるために、スクラムは 経験主義 に基づいている • 三本柱 と呼ばれる基礎がアジャイルとしてのスクラムを支えている 透明性 検査を可能にするためにプロセスやタスクの「価値」や「内容」、現在の 「状態」などを明確にすべきという考え 検査 適応を可能にするために現在の状況を頻繁に検査すべきという考え 適応 検査によって見つかった良いものは継続し、改めるべき面は改善すべき という考え
8. スクラムについてざっくり紹介 • アジャイルである状態をより高め、アジャイル開発を成功させるための 5 つの価値基準を定義して いる ◦ 確約 ◦ 集中 ◦ 公開 ◦ 尊敬 ◦ 勇気 • スクラムは「経験主義」に基づき、「三本柱」の土台の上で「 5 つの価値基準」を強化していく ことでア ジャイル開発を成功させようとしている • これを実現するための少人数（ 6 ± 3 人）の「機能横断型（職能横断型） 」で「自己管理型」の組織を 「スクラムチーム」と呼ぶ ◦ スクラムチームには 3 つのロールが存在する ◦ スクラムチームは三本柱の実現のための 3 つの成果物を確約する ◦ スクラムチームは 5 つのイベントを繰り返すことで目的を果たそうとする
9. スクラムについてざっくり紹介 プランニング スプリントバッ クログ デイリー スクラム スクラム マスター プロダクト バックログ インクリメント スプリント レビュー プロダクト オーナー レトロスペクティブ 開発チーム スプリント 継続的に改善、改良を繰り返し、 成長させていくプロセス
10. スクラムを実践する上で 大切な考え方
11. スクラムを実践する上で大切な考え方 • 守破離を意識する • 「ユーザーが本当に求めているもの」を探求し、 100% じゃなくてもいいから小さく 確実に届ける • マネージャーというポジションはない、ただし マネジメントという仕事は必要 • 変化に柔軟に、でも変化をすべて受け入れるということではない • 時間は見積もるものではなく導出されるもの 、見積もる対象は「大きさ」と「価値」 • 明確な「ペルソナ」や「 feature / 特徴」を議論の軸におく • 結局、「ユーザーが喜んで」いて「チームの心理的安全性が確保されて」いて「お金が生まれて」いく ように「改善を続けて」いるのであれば良い
12. スクラムを実践する上で大切な考え方 • 「守破離」とは ◦ まずは決まりや教えを守ってやってみる ◦ それができるようになったら決まりや教えを破って自分なりにアレンジしてみる ◦ 最後は決まりや教えを離れてオリジナルにやってみる • スクラムに適用するのであれば ◦ まずは、最小限の枠組みだけ定められている「スクラムガイド」に 則って進めて みて、スクラ ムの考えを身につける ◦ スクラムの考えが身についた上で自分たちのチームに合っていない部分の 改善を行い 、合 いそうなプラクティスを取り入れてみる ◦ 最終的には 自分たちなりのプラクティスを生み出してみる • 守破離を実践しないことで陥りがちなのが「なんちゃってスクラム」だったり、「なんちゃってアジャイ ル」だったりする ◦ 結果としてうまくいかず、「スクラムはだめだ」という判断になってしまう 守破離を意識する
13. スクラムを実践する上で大切な考え方 • 「ユーザーが言っているもの」「プロダクトオーナーが言っているもの」を そのまま実現すれば「本当 に求めているもの」になるとは限らない • 例 • むしろ 100% を目指すよりも重要なことは タイムボックスを守り、確実に届ける こと 「ユーザーが本当に求めているもの」を探求し、 100% じゃなくてもいいから小さく確実に届ける * ユーザーから「歩いて通勤するのが大変なので、車を作って欲しい」という要望があったとして、車作りから始めてしまうと、そ のユーザーは車が実際に出来上がるまでは歩いて通勤を続けないといけない状態が続いてしまう * この場合のユーザーの目的は「車を手に入れること」ではなくて、「歩いて通勤するのが大変という問題を解決すること」にあ る * 「スケボー -> キックボード -> 自転車 -> バイク -> 車」というように徐々にアップグレードするように、 100% じゃなくてもいい ので「今直面している問題を少なからず解決できる手段」を確実に届けることが大切 * もしかしたら 自転車を届けたタイミングでユーザーは満足するかも しれない、その場合 結果としてオーバースペックなものを 作らなくて済む
14. スクラムを実践する上で大切な考え方 • スクラムには 開発者（開発チーム）、プロダクトオーナー、スクラムマスター の 3 ロールしかないた め、従来の「マネージャー」と呼ばれるようなポジションは存在しない ◦ そもそも 従来のマネージャーはプロジェクトに対しての責任を持つため、全く異なる性質の業 務を掛け持ちしていた ▪ 事業やプロダクト、予算などの「ビジネス面のマネジメント」 ▪ チームやリソース、開発スケジュールなどといった「組織面のマネジメント」 ◦ スクラムでは それらを的確に分散している • スクラムチームは自己管理型なので、誰かが管理（マネジメント）するのではなく、自分たちで管理す る、例えば下記のような 管理をチーム全体で行う ◦ ユーザーの声をもとにしたプロダクトの価値やプロダクトの品質を管理する ◦ チーム内のリソースを管理して、不足しているものがあれば打診する ◦ 「誰かのタスク」ではなく「チームのタスク」としてタスクやスケジュールを管理する • 普段から「私は」ではなく 「私たちは」を主語として扱うように意識する と、自己管理が馴染みやすい マネージャーというポジションはない、ただしマネジメントという仕事は必要
15. スクラムを実践する上で大切な考え方 • スクラムに限らず、アジャイル開発を導入するとなったとき、しばしば誤解されがちなのが「仕様を決 めない開発手法」であるということと、「仕様変更がいくらでもできる開発手法」であるということ • まず、スクラムにおいて重要なことは スプリント期間中はスプリントゴールに向かって集中して走り 続けられるようにする こと • 作るものの仕様とそのスプリントのスプリントゴールは開発者・プロダクトオーナー間においてスプリ ントプランニングで確約しているため、 仕様は決めるしスプリント期間中の仕様変更やタスク追加は 原則認めない • これは「スプリントの期間をどのくらいにするか」の判断基準にも使える、例えば「プロダクトオーナー が仕様変更を我慢できる期間」とかで決めるといいかもしれない • 突然の大きな市場の動向の変更や、天変地異などによりスプリントを続ける意味がないと判断した 場合は、プロダクトオーナーにのみ許された 最終奥義「スプリント・ストップ」 を使う 変化に柔軟に、でも変化をすべて受け入れるということではない
16. スクラムを実践する上で大切な考え方 • 従来型の開発においては、作業者が行う見積もりは、「工数」と呼ばれる作業にかかる「時間」の見 積もりのみであることが多かった ◦ この見積もりの問題点は以下 ▪ 作業時間を見積もるというのは「自分だったらどのくらいかかるか」や「なんとなくこの作 業だとこれくらいだろう」というように、属人的になりやすかったり透明性を排除して行わ れることが多い ▪ そもそも自分以外の誰かがやると決めたことだとモチベーションが上がりにくい • スクラムでは 開発者が、タスクに対しての「大きさの見積もり」と「バリュー（価値の）見積もり」を行う ◦ 「タスクの大きさ」という観点で見積もるため、「自分だったらどれくらいか」という主観を排除し て客観的に見積もることができる ◦ バリュー見積もり とはユーザー価値を見積もるということ、自分たちで「価値のあるもの」であ ると納得して作業できるためモチベーションが上がりやすい • 見積もった大きさをもとに 過去に経験した近い大きさのタスクを参照することで、結果的に「時間」は 導出される 時間は見積もるものではなく導出されるもの、見積もる対象は「大きさ」と「価値」
17. スクラムを実践する上で大切な考え方 • 「どんなユーザーをターゲットとしているのか」「このプロダクトの一番の特徴はなにか」「他の類似し たプロダクトと差別化された部分はなにか」、こういったものを開発開始時に明確に決めておき、 仕 様を決めるときや価値の見積もりのとき、チーム内で意見がぶつかったときなどの軸とする ◦ 「アジャイルサムライ」で紹介されている インセプションデッキ の中の エレベータピッチ のよう なもので良い • 「良い」という評価は往々にして個人の主観が絡みがち、そこで客観的な軸があることでチームが目 指していく先が見失われなくなる • もちろん ペルソナや feature もユーザーのニーズに合わせて成長させていく 、基本的にプロダクト オーナーマターで手を加えるが、透明性が失われてはならない 明確な「ペルソナ」や「 feature / 特徴」を議論の軸におく
18. スクラムを実践する上で大切な考え方 結局 ユーザーが喜んで いて チームの心理的安全性が確保されて いて お金が生まれて いくように 改善を続けて いるのであれば 良い
19. スクラムでよく使われる プラクティス
20. スクラムでよく使われるプラクティス • ユーザーストーリー と スパイク を用いたプロダクトバックログアイテムの作成 • 相対見積もり による精度の高い見積もりと プランニングポーカー • スプリントプランニングの準備 プロダクトバックログ・リファインメント • KPT / YWT と 障害リスト を利用したふりかえり • カンバン と パーキングロット 、 バーンダウン（アップ）チャート • スプリント・ゼロ で走り出しの準備を
21. スクラムでよく使われるプラクティス • プロダクトバックログに積むバックログアイテムの作り方として、 ユーザーストーリー という手法が使 える • ユーザーストーリーとは <使用者> が、 <目的> のために、 <何> ができる のフォーマットで記載され た機能要望 ◦ 例） ▪ 忙しく時間の取れないユーザーが、簡単な操作で他のユーザーとマッチングするため に、スワイプで次々に「気になる」「気にならない」の振り分けができる ▪ サーバの負荷試験を担当するエンジニアが、他の影響を受けない環境で試験を実施す るために、独立した環境で試験を行える • ユーザーストーリーは「話を広げる種」のようなものなので、 具体的な仕様については議論可能な 余地を残しておく と良い • スパイク とは簡単にいうと調査タスク ◦ タイムボックスを切ってその間を 調査検証 に使い、その結果を持って実施の有無や再度スパ イクを行うか否かを判断する ユーザーストーリーとスパイクを用いたプロダクトバックログアイテムの作成
22. スクラムでよく使われるプラクティス • 見積もり方としておすすめなのが 相対見積もり • 従来の見積もり方で多いのは「どれくらいの時間がかかるか」「どれくらい売れそうか」といった 絶対 見積もり であったが、それに対して「 A と B を比較してどちらのほうが複雑そうか」「 A と B を比較し てどちらのほうが価値がありそうか」のように 比較して見積もるのが相対見積もり • 人間にとって、例えば「ここから東京タワーまでは何キロか」のような問いに答えるのは難しいが、 「ここから東京タワーと富士山だとどちらのほうが遠いか」のような問いに答えるのは易い ◦ このときその殆どが「なんとなく」な基準になるが、その なんとなくは 経験に基づくものであり、 あたっていることが多い ため絶対見積もりと比較して精度が上がる ◦ この得意な見積もり方を用いて過去のタスクと比較することで タスクの見積もりがしやすくな る • 相対見積もりを行うためのツールとして プランニングポーカー が使われることが多い 相対見積もりによる精度の高い見積もりとプランニングポーカー
23. スクラムでよく使われるプラクティス • スクラムガイドではプランニングの中で出てくる リファインメント 、「スクラムには 19 の要素がある」 という説もあるが、そのなかにも含まれている重要なセレモニーのひとつ • リファインメントでやるべきことは ◦ バックログアイテムの内容を詰める ▪ スプリントバックログに載せられる状態（ READY ）まで詰めておくとスプリントプランニ ングのときに集中しやすくなる ◦ 大きなバックログアイテムの分割 ◦ バックログアイテムの並び替え • 個人的に スプリントをうまく回すための要となっている と思っているのがリファインメント、プランニン グとリファインメントで２つは分けて考えたほうが良いかもしれない • 丁寧すぎるかもしれないが、慣れるまではスプリント期間中に２つ先のスプリントくらいまでのバック ログアイテムをリファインメントできていると安心して進められる スプリントプランニングの準備 プロダクトバックログ・リファインメント
24. • KPT は keep( 続けること ) / problem( 抱えている問題 ) / try( チャレンジすること ) の頭文字で、ふ りかえりに使われる手法 ◦ KPT はときにチーム内の心理的安全性に影響を与えることがあるとして、最近は日本発祥の YWT ( やったこと、わかったこと、次やること ) が使われ始めている • 障害リスト は機能障害のリストのことではなく、 プロダクト開発を妨害しているもの・改善すべきもの 全般のリスト ◦ 例えば 換気が弱くオフィスの空気が常に汚れている 、 マシンスペックが足らずビルドに 10 分もかかってしまう などもそう ◦ レトロスペクティブの場ではこれらをどのように改善していくかについても話し合う • スクラムマスターは、チームがレトロスペクティブやデイリースクラムなどを使ってこれらの問題の解 決に努められるように支援する スクラムでよく使われるプラクティス KPT / YWT と障害リストを利用したふりかえり
25. • スプリント期間中はスクラムボードとして カンバン が用いられることが多い • カンバンのステータスとして一般的に用意されるものが「 TODO 」「 DOING / WIP 」「 DONE 」で、 加えて「 READY 」「 Q.A. 」などもよく用意される • 加えておすすめしたいのが PARKING LOT ◦ parking lot とは「保留」のこと ◦ スプリント期間中に見つかった問題や緊急度の低いバグ、優先度の低いタスクなどを parking lot においておく ◦ スプリント期間中に余裕ができれば対応しても良いが、もし余裕がなかったとしても レトロスペ クティブでリファインメント対象にするか対応しない（タスク自体を削除する）かを必ず決める ◦ この運用により「先延ばし」を一時的なものに抑えることができる • デイリースクラムでカンバンと合わせてスプリントの進捗を確認するのに用いられるのが バーンダ ウン（アップ）チャート ◦ 「理想線」「予定線」「実績線」の三本線からパッと見で進捗がわかる スクラムでよく使われるプラクティス カンバンとパーキングロット、バーンダウン（アップ）チャート
26. • 初回のスプリントを始める前に行っておくべきスプリント ◦ フルスクラッチの状態からいきなりスプリントを回し始めても、開発環境も整っていないので、 初回のスプリントでいきなりインクリメントを作り上げるのは現実的ではない ◦ そのため、 最低限必要なものはスプリント・ゼロで揃えておく（整えておく）必要がある • スプリント・ゼロで揃えておく（整えておく）べきものの例 ◦ スクラムの導入に前向きなスクラムチームのメンバー ◦ プロダクトのペルソナと feature ◦ ユーザーストーリーマッピング ◦ ステークホルダー含めたスクラムの勉強会 ◦ チャットツールや wiki などのコミュニケーション基盤 ◦ 言語やフレームワーク、ライブラリなどの技術選定 ◦ 開発環境や検証環境などのインフラ構築 ◦ git repository の作成、 TDD を行える基盤構築、 CI/CD の設定 ◦ その他、 1 スプリント目のインクリメントで「リリース判断可能」といえるものが作れる準備 スクラムでよく使われるプラクティス スプリント・ゼロで走り出しの準備を
27. さいごに
28. • スクラムは「経験主義」に基づき、「三本柱」の土台の上で「 5 つの価値基準」を強化していくことでア ジャイル開発を成功させようとしている • スクラムを実践する際に大切な考え方は、ユーザーにとって価値あるものをスクラムチームの責任 で継続的に探求し、実現し、届け続けていくことで利益をうみだそうという考え • なんちゃってスクラムで失敗しないためには、守破離ですすめていくと良い、先人の知恵に感謝 • プラクティスを取り入れる際に大事なことは、自分たちのチームに合ったものをチームの責任で取捨 選択していくこと さいごに
29. 本スライドでご紹介させていただいた内容 が、 少しでもスクラム導入の助けになれていた ら幸いです 楽しいスクラムライフを
30. 参考文献
31. • 書籍 ◦ アジャイルサムライ 達人開発者への道 ◦ SCRUMMASTER THE BOOK ◦ スクラム実践入門 成果を生み出すアジャイルな開発プロセス ◦ アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理 ◦ アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法 • WEB サイト ◦ スクラムガイド（ 2020 年 11 月版） ◦ アジャイルソフトウェア開発宣言 ◦ ryuzee さんのブログ ▪ twitter: @ryuzee • 画像 ◦ いらすとや 参考文献