参考資料

• 文献
• 「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
• 記事
• 「振り返りカタログ」https://qiita.com/viva_tweet_x/items/f4db2c923d474f67fe0f
• 「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
• 書籍
• アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント (翔泳社)

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)

スクラムが解決したかったこと

• 今回は「アジャイルソフトウェア開発宣言」の中にある 「アジャイル宣言の背後にある原則」から課題背景を読み取って、したいこと・解決したかったこととして説明してみます。

• 引用
• 「アジャイルソフトウェア開発宣言」https://agilemanifesto.org/iso/ja/manifesto.html (参照 2024-3-22)
• 「アジャイル宣言の背後にある原則」 https://agilemanifesto.org/iso/ja/principles.html (参照 2024-3-22)

2.スクラムフレームワークについて知ろう

スクラムのサイクル

スクラム3つの役割

開発者(DEV・Developers)

プロダクトオーナー(PO)

スクラムマスター(SM)

おまけ: ステークホルダー

• 役割
• プロダクトへの要望を伝える
• インクリメント(成果物)の評価を伝える

スクラム3つの制作物

プロダクトバックログ

• 役割
• プロダクトに必要な機能や改善の一覧
• 責任者
• プロダクトオーナー

スプリントバックログ

• 役割
• インクリメント(成果物)を届けるために必要なタスクの一覧
• 責任者
• 開発者

インクリメント(成果物)

• 役割
• リリース可能な機能や改善
• 責任者
• 開発者

スクラム5つのイベント

スプリント

• 全てのスクラムイベントを統合した総称です。
• 1スプリントの期間は、事前に決められた同じ期間で繰り返し行います。

スプリントプランニング

• 必要なもの(input)
• 最新化されているプロダクトバックログ
• 開発者がスプリント内で達成できると想定される生産量(ベロシティ)の情報
• 成果物(output)
• スプリントレビューで確認・検証可能なインクリメント(制作物)を決める(スプリントゴール)
• スプリントゴールを達成するための計画を立てる
• 実施タイミング
• スプリントの最初
• やること
• 優先順位の高いプロダクトバックログアイテムから、スプリントレビューで確認・検証可能なインクリメント(制作物)を決める
• スプリントバックログアイテムを作成する
• (必要であれば)スプリントバックログアイテムの見積もりをする
• しないこと・してはいけないこと
• プロダクトバックログアイテムについて、不確実な点・不明点をプロダクトオーナーに質問をしない
• スプリントレビューでインクリメント(制作物)がないゴール設定をする
• 品質を下げる前提のゴールを設定する
• チームの能力を超えたスプリントバックログアイテムを作成する
• 参加者
• 開発者
• プロダクトオーナー
• スクラムマスター

デイリースクラム

• 必要なもの(input)
• スプリントプランニングで決定したスプリントゴール
• 最新状態になっているスプリントバックログ
• 成果物(output)
• スプリントゴール達成可能か確認・検証する
• スプリントゴール達成において障害となる課題の解決策を決める
• 実施タイミング
• 毎日、同じ時間・場所
• やること
• スプリントゴール達成可能か確認・検証する
• スプリントゴール達成に障害となる課題を共有し、解決策を決める場を設定する
• しないこと・してはいけないこと
• 実施タイミングを守らない
• 形式的な質問で、無機質な進捗報告をしない
• 障害となる課題をチームに共有しない、一人で判断・解決しようとする、後回しにする
• スプリントゴール達成不可能だと判断した場合に、プロダクトオーナー・スクラムマスターに相談しない
• 参加者
• 開発者
• (出来るだけ)プロダクトオーナー
• スクラムマスター

スプリントレビュー

• 必要なもの(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)

• 実施タイミング
• スプリントの最後
• やること
• チームメンバーそれぞれがスプリントを振り返る
• 振り返りの内容をチームで共有する
• このスプリントでのまとめを行う
• レトロスペクティブで出てきた改善することを、プロダクトオーナーへ相談の上、プロダクトバックログに追加する
• しないこと・してはいけないこと
• チームメンバーそれぞれが思っていることを吐き出さない
• 現状のままで良いと思わない
• 以降のスプリントで改善するべきことを決めない
• 参加者
• 開発者
• プロダクトオーナー
• スクラムマスター

補足: (プロダクトバックログ)リファインメント

• 必要なもの(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
• 小さな軌道修正を繰り返して、目的地に達する。
• きゅーちゃん
• 変化に柔軟に対応するための手法のひとつ。
• すー
• 現状どうあるべきかではなく、未来がどうありたいかを実現するプロセス。

謝辞

レビューをして頂いた皆さん

このコンテンツはレビューしてくれた皆さんの集合知です。

意見が違うこともありましたが建設的な議論を重ね、より良い表現にするために尽力頂きました。

私だけではここまで良いものを作ることは出来ませんでした。重ねて感謝申し上げます。

「先輩たちが考えるスクラムとは？を一言でまとめる」を記載頂いた皆さん

これはコンテンツ作成中の思いつきだったのですが、とても良いコンテンツになったと思います。

それぞれの想いが簡潔に言葉になっていることで、これからスクラムを学習していく人への支えとなり、指標となると思います。

このコンテンツを作成する機会を頂けたこと

この機会によって私の足りなかった知識、より深い理解ができました。

コンテンツを作り上げる過程でたくさんの方に助けて頂きました。

この助けて頂けるコミュニティがなによりの価値だと再認識できました。

著作権について

• 引用した画像・動画・文章、その他全てのコンテンツの著作権は各制作者に帰属します。

このコンテンツを利用する場合

• 自由にご利用ください。
• 利用したことによる損害などは一切責任を負いません。