これはスクラム研修用の事前学習コンテンツです。
スクラム研修ではワークショップを通じた体験学習を重視しているため、このコンテンツでは全てを説明することはせず、必要な要素を厳選して作成しました。
もっと詳しくを知りたい人は、下記参考資料をご覧ください。
参考資料
文献
「scrum guide 2020 JP」 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
「アジャイルソフトウェア開発宣言」https://agilemanifesto.org/iso/ja/manifesto.html
「アジャイル宣言の背後にある原則」 https://agilemanifesto.org/iso/ja/principles.html
記事
「MVP - not "bike to car"」https://www.linkedin.com/pulse/mvp-bike-car-fred-voorhorst/
「リーンのMVP(Minimum Viable Product)の車とスケボーの例えを改めて解釈する」https://note.com/rhayahi/n/n317d54f8ca48
1.スクラムについて知ろう
スクラムとは
scrum guide 2020によるとスクラムは下記のように定義されている
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。
スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。
スクラムのルールは詳細な指⽰を提供するものではなく、実践者の関係性や相互作⽤をガイドするものである。
引用: Ken Schwaber & Jeff Sutherland著, スクラムガイド，2020年，p.4．https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf (参照 2024-3-22)
スクラムは全てを解決する銀の弾丸ではありません。
スクラムは「理解は容易、習得は困難」と言われます。
手段の1つでしかなく、スクラムフレームワークを遵守していれば良いというものでもありません。
スクラムは変化に適応できるチームであり続けるための学習の習慣化フレームワークです。
スクラムが解決したかったこと
今回は「アジャイルソフトウェア開発宣言」の中にある 「アジャイル宣言の背後にある原則」から課題背景を読み取って、したいこと・解決したかったこととして説明してみます。
2001年に、17名の著名なエンジニアがソフトウェア開発について今後どのようにあるべきかについて議論した結果を「アジャイルソフトウェア開発宣言」として公表しました。
スクラムとは、この「アジャイルソフトウェア開発宣言」という概念の基となった実際の開発手法の一つとなります。
引用
2.スクラムフレームワークについて知ろう
スクラムのサイクル
スクラムフレームワーク
スクラム3つの役割
開発者(DEV・Developers)
役割
スプリントバックログを計画・作成し、それを完遂する
開発者の改善を行う
やること
スプリントプランニングを行い、必要なタスクをスプリントバックログに反映する(スプリントゴール)
スプリントバックログを常に最新状態であることを担保する
プロダクトバックログアイテムについて、プロダクトオーナーまたはステークホルダーへ質問をする
プロダクトの品質を担保する
スプリントを完遂する
チームの出来ることを増やす
しないこと・してはいけないこと
プロダクトバックログの優先順位を決める
スプリントゴールの変更
スプリントゴールの未達成
スプリントレビューで評価できるインクリメント(成果物)がない
参考動画
開発者とはエンジニアもデザイナーもプロダクトを作る人たちを指します。
機能横断型(クロスファンクショナル)チームになるように改善していく必要があります。
上司という概念はないので、チームに不足している能力は増員する・教育するなども、開発者が責任を持ちます。
メンバーの入れ替えはない方が良いですが、時には入れ替えも視野に入れて、より良いチームを作る責任があります。
プロダクトオーナー(PO)
役割
プロダクトへ情熱と責任を持つ
プロダクトの価値を最大化する
「何をするか・しないか」を決める
スプリントを中止する権限を持つ
やること
ステークホルダーとのコミュニケーションを通じて、プロダクトに関する要求やフィードバックを収集する
プロダクトのビジョンや戦略を策定し、プロダクトバックログに反映する
プロダクトバックログを常に最新状態であることを担保する
プロダクトバックログアイテムについて、ステークホルダー・開発者へ丁寧な説明をする
しないこと・してはいけないこと
開発者のマネージメント
スプリントバックログのハンドリング
開発者から上がってくる改善要望を軽んじる・後回しにする
参考動画
プロダクトオーナーの責務は他のメンバーに委任することもできます。但し、責任はプロダクトオーナーのままです。
プロダクトのビジョンは必須です。なければ必ず作りましょう。
プロダクトのビジョンがなければ、目指すべきゴールが定まらず、ステークホルダーの声ばかり反映することになります。
スクラムマスター(SM)
役割
スクラムプロセスの遵守
スプリント達成に障害となることへの対処
プロダクト価値・チーム状態の可視化
やること
スクラムの導入・実践・理解・遵守の支援
スクラムイベントの計画と実行の支援
スクラムチームの⾃⼰管理を促進支援
問題解決と障害除去の支援
開発者・プロダクトオーナー・ステークホルダーの連携支援
しないこと・してはいけないこと
何かを決定する
プロジェクトの予算管理
開発者のマネージメント
(プロダクト・スプリント)バックログの作成・整理・更新・完了
参考動画
以下の注意点を守ることが重要です。
開発者とプロダクトオーナーの信頼を獲得しコミュニケーションを円滑にすること
問題解決能力を持ち、チームに適切なアドバイスを提供すること
スクラムの基本的なルールや原則を守ること
スクラムイベントの運営において、円滑な進行を支援すること
継続的にプロセスの改善提案を行うこと
スクラムに関する深い知識を継続して学習し続けること
おまけ: ステークホルダー
役割
プロダクトへの要望を伝える
インクリメント(成果物)の評価を伝える
チームやプロダクトに影響を与える出資者や利害関係者を指します。
主に株主・債権者・取引先・決済者などが該当します。
スクラム3つの制作物
プロダクトバックログ
役割
プロダクトに必要な機能や改善の一覧
責任者
プロダクトオーナー
プロダクトバックログは、全てのステークホルダーからの要求を収集し、それぞれの項目を優先順位で並べます。
その優先順位は、ビジネス価値、顧客への影響、リスクなど、さまざまな要素に基づいて決定されます。
スプリントバックログ
役割
インクリメント(成果物)を届けるために必要なタスクの一覧
責任者
開発者
スプリントバックログは、リアルタイムで更新されていきます。
進捗状況がすぐにわかるくらいのタスク粒度が望ましいです。
インクリメント(成果物)
役割
リリース可能な機能や改善
責任者
開発者
インクリメント(成果物)は、複数作成される場合もあります。
リリース可能(完成)の定義は、チームによって異なります。
スクラム5つのイベント
スプリント
全てのスクラムイベントを統合した総称です。
1スプリントの期間は、事前に決められた同じ期間で繰り返し行います。
大事なこと
スプリントゴールの達成を危険にさらすような変更はしない。
品質を低下させない。
プロダクトバックログを必要に応じてリファインメントする。
スプリントの期間は長くても1ヶ月以内にする。
引用: Ken Schwaber & Jeff Sutherland著, スクラムガイド，2020年，p.8-9．https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf (参照 2024-3-22)
スプリントプランニング
必要なもの(input)
最新化されているプロダクトバックログ
開発者がスプリント内で達成できると想定される生産量(ベロシティ)の情報
成果物(output)
スプリントレビューで確認・検証可能なインクリメント(制作物)を決める(スプリントゴール)
スプリントゴールを達成するための計画を立てる
実施タイミング
スプリントの最初
やること
優先順位の高いプロダクトバックログアイテムから、スプリントレビューで確認・検証可能なインクリメント(制作物)を決める
スプリントバックログアイテムを作成する
(必要であれば)スプリントバックログアイテムの見積もりをする
しないこと・してはいけないこと
プロダクトバックログアイテムについて、不確実な点・不明点をプロダクトオーナーに質問をしない
スプリントレビューでインクリメント(制作物)がないゴール設定をする
品質を下げる前提のゴールを設定する
チームの能力を超えたスプリントバックログアイテムを作成する
参加者
開発者
プロダクトオーナー
スクラムマスター
スプリント内でどれくらい完了できるかを選択するのは難しいかもしれない。
しかしながら、開発者が過去の⾃分たちのパフォーマンス、今回のキャパシティ、および完成の定義の理解を深めていけば、スプリントの予測に⾃信が持てるようになる。
引用: Ken Schwaber & Jeff Sutherland著, スクラムガイド，2020年，p.10．https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf (参照 2024-3-22)
デイリースクラム
必要なもの(input)
スプリントプランニングで決定したスプリントゴール
最新状態になっているスプリントバックログ
成果物(output)
スプリントゴール達成可能か確認・検証する
スプリントゴール達成において障害となる課題の解決策を決める
実施タイミング
毎日、同じ時間・場所
やること
スプリントゴール達成可能か確認・検証する
スプリントゴール達成に障害となる課題を共有し、解決策を決める場を設定する
しないこと・してはいけないこと
実施タイミングを守らない
形式的な質問で、無機質な進捗報告をしない
障害となる課題をチームに共有しない、一人で判断・解決しようとする、後回しにする
スプリントゴール達成不可能だと判断した場合に、プロダクトオーナー・スクラムマスターに相談しない
参加者
開発者
(出来るだけ)プロダクトオーナー
スクラムマスター
デイリースクラムは、コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進する。その結果、他の会議を不要にする。
引用: Ken Schwaber & Jeff Sutherland著, スクラムガイド，2020年，p.10．https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf (参照 2024-3-22)
スプリントレビュー
必要なもの(input)
確認・検証可能なインクリメント(制作物)
成果物(output)
ステークホルダーからインクリメント(制作物)に対するフィードバック
実施タイミング
スプリントの終盤
やること
スプリントゴールが達成されたことをみんなで喜ぶ
インクリメント(制作物)をステークホルダーが実際に動かしてみる
次にやるべきことをステークホルダー含めて話合う
インクリメント(制作物)とフィードバックを受けて、プロダクトバックログの調整
しないこと・してはいけないこと
ステークホルダーが参加しない
インクリメント(制作物)をプレゼンテーションするだけの場にしない
ゴール達成を喜ばない
参加者
ステークホルダー
プロダクトオーナー
開発者
スクラムマスター
スプリントレビューは「祝いの場」とも表現されますので、過剰なくらい喜びを表現するようにしましょう。
インクリメント(制作物)を動かしフィードバックするのは、プロダクトオーナーである場合もあります。
スプリントレトロスペクティブ
必要なもの(input)
スプリント期間内の出来事
チームメンバーそれぞれの振り返り
成果物(output)
チームの品質と効果を高める方法を計画する
引用: Ken Schwaber & Jeff Sutherland著, スクラムガイド，2020年，p.12. https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf (参照 2024-3-22)
実施タイミング
スプリントの最後
やること
チームメンバーそれぞれがスプリントを振り返る
振り返りの内容をチームで共有する
このスプリントでのまとめを行う
レトロスペクティブで出てきた改善することを、プロダクトオーナーへ相談の上、プロダクトバックログに追加する
しないこと・してはいけないこと
チームメンバーそれぞれが思っていることを吐き出さない
現状のままで良いと思わない
以降のスプリントで改善するべきことを決めない
参加者
開発者
プロダクトオーナー
スクラムマスター
振り返りの手段は多種多様です。その時そのチームにあった振り返りフォーマットを選択するようにしましょう。
参考: ふりかえりを更に拡張する「ふりかえりカタログ（コミュニティ版）」https://qiita.com/viva_tweet_x/items/f4db2c923d474f67fe0f (参照 2024-3-22)
補足: (プロダクトバックログ)リファインメント
必要なもの(input)
市場動向・状況
ステークホルダー・開発者からの要望・意見
スプリントレトロスペクティブでの改善案
スプリント状況
成果物(output)
プロダクトバックログを最新状態にする
実施タイミング
スプリントレトロスペクティブ直後
随時またはスプリントプランニング中
やること
プロダクトバックログアイテムを作成し、開発者がスプリントを実行できる情報を記載・準備する
プロダクトバックログの優先順位を決める
しないこと・してはいけないこと
プロダクトバックログアイテム達成に必要な「どのように実現するか」を記載する
参加者
プロダクトオーナー
(必要に応じて)ステークホルダー、開発者
スクラムマスター
スプリントが始まる前もしくは、スプリントプランニング前に完了している必要があります。
完了している前提で、スプリントプランニング中にチームと相談の上、変更する場合もあります。
スプリント中でも必要に応じて更新をします。
スプリントレトロスペクティブとセットで行うのを推奨します。
3.おまけコンテンツ
おまけ1: システム開発の難しさを表現した動画
これは車を走らせながらタイヤを交換している動画です。
昨今のビジネスも同様で、常にビジネスを前進させながら都度状況に合わせて改善・メンテナンスを続けなければなりません。
私たちはこのような状況であることを再認識して、変化に対応し続ける必要があります。
そのため、スクラムというフレームワークが重要になってきます。
おまけ2: プロダクトを成長させていく上でどのように進めていくのが良いかのアイデア
引用: 「MVP - not "bike to car"」https://www.linkedin.com/pulse/mvp-bike-car-fred-voorhorst/
この画像は「MVP(Minimum Viable Product) = 実用最小限の製品」の実現方法ついて、問題提起とその解決方法のアイデアを説明している画像です。
スクラムを運用しているチームではよく「PMF(Product Market Fit)」や「MVP(Minimum Viable Product) 」という単語が出てくることが多いです。
参考
「リーンのMVP(Minimum Viable Product)の車とスケボーの例えを改めて解釈する」https://note.com/rhayahi/n/n317d54f8ca48 (参照 2024-3-22)
おまけ3: 実店舗でプロトタイプ開発をする動画
これは実店舗でプロトタイピングをしていく動画です。
利用者にフィードバックをもらいながらプロダクトを改善をしていく、理想とも言えるプロダクト開発を行っています。
おまけ4: 先輩たちが考えるスクラムとは？を一言でまとめる
@Katsutaro Eimaeda
勇者ヒンメルの行動をフリーレンがなぞっていくプロセス。
Tomy
正解なんてどこにも落ちてないからチームで作れ。
@Hiroki Naito
チームビルディングの兵法書。振り返りを通じて結束を高める戦術。
いさぴょん
チームワークが全て！独りではできないことも、チームではできるようになることを知ることが大事で、Ghost Shellみたいなチームが理想で、違う感性を受け入れましょう。
しずかちゃん
みんなでだんだん良くする。
@Yuhi Otsuka
一生うまくいかないので、フレームワークをヒントにチームの課題に向き合い、悩みながら根気よく改善し続けること。
@Kei Nakamura
ゲームみたいなものです。楽しみましょう。
@Daisuke Tsukahara
一人はみんなのために、みんなは一つの目的のために。（One for all All for one）
@Hajime Nakagawa
みんながこぞって同じハウツーをありがたがってる状況はぼくはあまり好きじゃないです。
@Takuma Miura
レトロスペクティブがキモ！！
@Koji Sugimoto
当たり前のことを当たり前にやるだけの指針。特別なことは何もないです。
masafumi
永遠に遊べるシミュレーションゲームです。
@Wonjae Kim
「いい感じで」を明瞭にするプロセス。
はにわ
自分のチームに一番合うフローを考えるためのフレームワーク。
@Masahiro Akiyama
小さな軌道修正を繰り返して、目的地に達する。
きゅーちゃん
変化に柔軟に対応するための手法のひとつ。
すー
現状どうあるべきかではなく、未来がどうありたいかを実現するプロセス。
謝辞
レビューをして頂いた皆さん
このコンテンツはレビューしてくれた皆さんの集合知です。
意見が違うこともありましたが建設的な議論を重ね、より良い表現にするために尽力頂きました。
私だけではここまで良いものを作ることは出来ませんでした。重ねて感謝申し上げます。
「先輩たちが考えるスクラムとは？を一言でまとめる」を記載頂いた皆さん
これはコンテンツ作成中の思いつきだったのですが、とても良いコンテンツになったと思います。
それぞれの想いが簡潔に言葉になっていることで、これからスクラムを学習していく人への支えとなり、指標となると思います。
このコンテンツを作成する機会を頂けたこと
この機会によって私の足りなかった知識、より深い理解ができました。
コンテンツを作り上げる過程でたくさんの方に助けて頂きました。
この助けて頂けるコミュニティがなによりの価値だと再認識できました。
著作権について
引用した画像・動画・文章、その他全てのコンテンツの著作権は各制作者に帰属します。
このコンテンツを利用する場合
自由にご利用ください。
利用したことによる損害などは一切責任を負いません。