Team Dev - Scrum

スクラム開発について

Transcript

1. チーム開発講座 アジャイル ~ スクラム講座 ~
2. 講師紹介 榛葉 章隆 - Aktiaka Shinba - 株式会社オルターブース所属 a-shinba @shinbaz
3. 2日間を通じた全体のゴール ❏ ソフトウェア開発におけるトレンドを理解！ ❏ 「アジャイル開発」「スクラム」手法を理解し、チーム開発をブースト！ ❏ AI開発プラットフォームGitHubを使いこなせるようになる！ 皆さまのエンジニア市場価値向上！ を目指して...
4. 本日のゴール ❏ ソフトウェア開発の世界的な状況を知る ❏ DevOps概要を知る ❏ アジャイル、スクラムについて学ぶ ❏ スクラムWorkshopを実施！ ❏ GitHub と ソフトウェア開発の関連性 ❏ GitHub のサービス理念を知る ❏ GitHub の機能を学ぶ ❏ GitHub Copilotを利用し、AI駆動開発を 知る スクラム開発 GitHub
5. 2日目のゴール ❏ GitHubを利用し、アプリケーションを開発する ❏ 成果発表！ GitHub
6. ソフトウェア開発にお けるトレンドを理解す る ソフトウェア開発業界はいま、ど のようなトレンドがあるのでしょう か。 実は「ソフトウェア開発」にはいく つかの手法があり、時代にあった 手法に則った開発能力が求めら れるようになってきています。
7. 世の中はソフトウェア開発に よって支えられている 世の中は年々、各種アプリケーションによるITへの置き換えが起 こっており、それを支えるIT技術が経済成長のための重要なファク ターです。 ハードウェアの進展と同時に、ソフトウェア開発手法もまた大きな進 化を遂げています。
8. 世界のビジネス情勢 (2024) 順位 企業名 時価総額（億ドル） ソフトウェア関連性 1 Apple 35,452.09 ◦（モバイルOSやエコシステム全体の統合） 2 Microsoft 30,855.49 ◦（OS、クラウドサービス、業務支援ソフト） 3 NVIDIA 29,405.14 ◦（AI・GPU関連ソフトウェアの提供） 4 Alphabet (Google) 25,000.00 ◦（検索エンジン、クラウド、広告プラットフォーム） 5 Amazon.com 23,000.00 ◦（クラウド基盤やEC運営ソリューション） 6 Saudi Aramco 22,000.00 × 7 Meta Platforms 18,000.00 ◦（ソーシャルメディア、デジタル広告） 8 Tesla 15,000.00 ◦（車両制御、AI活用の自動運転技術） 9 Broadcom 12,000.00 ◦（通信やネットワーク関連ソフトウェア） 10 Berkshire Hathaway 10,000.00 ×
9. ビジネスライフサイクルの短命化 ソフトウェアが世界のビジネスを牽引する様になり、ビジネスのライフサイクルは 短命化しました。 次から次へと新たなサービス、機能が誕生し、市場やユーザーはすっかり慣れきっています。 2010年頃まで日本ではmixiというSNSが主流でしたが、翌年には facebook、旧Twitterなどが台頭し て、mixiをたった数年で衰退させました。 Skypeという通話ツールは世界中のデファクトスタンダードな通話ツールでしたが、 Teams, Zoom, Discordといった新たな強力なサービスによって次第にシェアを奪われていきました。 アプリケーションやサービスは、 速やかなリリース・進化・対応が求められ、継続的改善が必須となった
10. DevOpsという文化が誕生した
11. ソフトウェア開発手法 ウォーターフォール • 従来の開発手法 • アプリケーションの設計、テスト、リ リース計画を最初に行い、遂行する • 仕様が決まっているもの、作りたいも のがはっきりしているもの、金融系な どでよく使われる スクラム開発（アジャイル） • 継続的改善を前提としたアジャイル 開発の中の一つの手法 • アプリケーション設計などは行うが、 小さくはじめ、小さく前進してゆく • Webサービスや、アプリケーションで よく使われる • 誤解されやすいが、開発速度をあげ たり、単価を下げる目的はない
12. ウォーターフォールとアジャイルの比較
13. 開発手法の意思決定
14. 開発手法の意思決定 ソフトウェア開発には不向き
15. 込み入った領域 • 専門家が分析や調査を行うことで、解を導き出せる問題 • 解が複数存在することもある • 状況を「把握」し、課題やアプローチを「分析」し、専門的に対応する • ウォーターフォール開発の得意分野 例 • 会社規模に合わせた会計パッケージを導入する • 必要なテーブル情報をもったデータベースを構築する
16. 複雑な領域 • 流動的で予測不可能、適切な解がない • 専門家を持ってしても、因果関係を明らかにすることは困難 • 仮説検証や、実証実験などを繰り返しながら、適切な対応は後になってからわかる • アジャイル開発の得意分野 例 • ユーザー便利な機能を持ったWebアプリケーション
17. アジャイル開発 さっそく、アジャイル開発のメリットを みていきましょう。
18. ウォーターフォールとアジャイルの比較
19. ソフトウェアの開発計画 機能A 機能B 機能C 企画 設計 実装 テスト ウォーターフォール開発 すべての物事を順序立てて、上流から下流にかけて開発し、リリースを目 指す。下流で問題が起こると、上流へ逆流する必要があり、修正が困難 な場合がある。 アジャイル開発 機能をコンパクトにリリースしながら 理想形を目指す。理想形そのものが 変わることもあるが、柔軟な計画変 更に対応可能な場合が多い。 機能A 企画 設計 実装 テスト 機能B 企画 設計 実装 テスト 機能C 企画 設計 実装 テスト
20. リスク比較
21. スクラム開発手法 アジャイル開発の中でも、「スクラ ム」は多くの組織で選ばれていま す。
22. スクラム開発とは？ • プロダクト開発フレームワーク ◦ 複雑な課題をより小さな断片に分解し、 ◦ チームがより頻繁に、継続的に価値を提供できるようにする • 特徴 ◦ 機能要求を洗い出し、優先度を流動的に並び替えながら、プロダクトの完成を目指す ◦ 透明性を重視し、状況や問題点が、誰から観ても明らかな状態を目指す ◦ チームビルディングに力を入れており、チーム全体の力を成熟させていく動きもある • よくある勘違い ◦ 工数短縮、効率化、低予算化などは、スクラム開発の目的ではありません ◦ スクラム開発手法が最も優れている、わけではありません
23. スクラムガイド（公式ルールブック） スクラムガイド (2020) • ガイドに忠実に開発することをスクラム開発と呼 びます • スクラムガイド規定を変更、削除することはスク ラム開発とは呼ばれません。それらは「スクラム バット（Scrum, but)」とよばれ、非推奨とされてい ます。
24. スクラム開発の構成要素 3本柱 5つの 価値基準 11の 主要要素 理想形 マインドセット 運用要素
25. スクラム三本柱 透明性 • プロセスや作業を可視化すること • 透明性があることによって検査が可能になる • 興味を持っている人全員に可視化され、理解できるようにされている状態 • 透明性が低い作成物は価値を低下させ、リスクを高める意思決定につながる可能性がある 検査 • 問題を早期に検知するため、スクラムの作成物やゴールは頻繁に検査される必要がある • そのために5つのイベントが提供されている • 検査によって適応が可能になる。適応のない検査は意味がないとされている 適応 • プロセスやプロダクトに異常が生じた場合に、それらの修正や改善を行うこと • スクラムチームは、検査によって得られた情報をもとにできるだけ早く対応し、 逸脱を最小限に抑え、適切な方向に素早く修正する＝適応することが期待される
26. 5つの価値基準 確約(Commitment) • スクラムチームは、ゴールを達成し、お互いにサポートすることを確約する 集中(Focus) • スクラムチームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する 公開(Openness) • スクラムチームとステークホルダーは、作業や課題を公開する 尊敬(Respect) • スクラムチームのメンバーは、お互いに能力のある独立した個人として尊敬し、 一緒に働く人たちからも同じように尊敬される 勇気(Courage) • スクラムチームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持つ
27. 11の主要要素 3つの役割 3つの作成物 5つのイベント スプリント スプリントプランニング デイリースクラム スプリントレビュー スプリントレトロスペクティブ プロダクトオーナー 開発者 スクラムマスター プロダクトバックログ スプリントバックログ インクリメント
28. プロダクトゴール プロダクトの将来の理想的な状態を示すもの • チームの長期的なターゲット、目標となる • 言語化することで、常に透明性を保ち、チーム全員が意識可能な状態を保つ • ゴールを達成できたかは、評価できる必要がある 番外編 月間100万PVを達成し、市場を盛り上げる ペットウェルネスの認知度を上げるための ウェブサイトを立ち上げる 社内全体で使えるワークフロー自動化プラット フォームを構築する 月間アクティブユーザー10万人を達成する
29. プロダクトバックログ (PB) プロダクトゴールを達成するために必要な項目の一覧 • プロダクトバックログに登録されているアイテムを「プロダ クトバックログアイテム (PBI)」と呼ぶ • 実現したい項目順に並べる。この順序は直近の計画だけ 立てればよく、順序は定期的にお手入れする • 可視性を担保するため、PBIは、縦一列に並べる • PBの責任は、「プロダクトオーナー」が持つ • PBIの作業規模（工数）は、直近の計画だけ立てれば良 い。また、工数を見積もるのは開発者。 • PBIは、タスクリストではない。 • PBIの粒度は、可能な限り分解すること ◦ NG：商品を購入できる ◦ OK：商品を一覧表示する、配送日数を表示する ◦ 分解しすぎて、PBI同士を依存させないこと プロダクトバックログ 1番目に実現したい 2番目に実現したい 3番目に実現したい 4番目に実現したい 5番目に実現したい PBは定期的にお手入れするので、すべ ての順番を決めきる必要はない 99番目に実現したい 100番目に実現したい ・・・ 3つの作成物
30. プロダクトオーナー (PO) ユーザーの声を代弁する、 PBの責任者！ • ユーザーがどのような機能や修正をほしがっているか、チーム に代弁する（発注者の代弁ではない） • PBに対して最終責任を持つ ◦ ただし、POが許可する場合、開発者がPBの順序の並び 替え、追加、更新を行うことができる ◦ その際も、最終責任者はPOである • 開発者との関わり ◦ PBの相談や更新委任はできるが、開発手法や見積もりな どの干渉はできない • スクラムマスターとの関わり ◦ チーム形成において、スクラムをより浸透させたいときに 連携する。 優れたPOは、ユーザーと同じ情熱を持っている！ 3つの役割
31. 開発者 プロダクトの開発計画からリリース、継続開発まで担当！ • 基本的にチームで動き、すべてのチームメンバーが揃えば、プ ロダクトを作る能力が揃う ◦ デザインチーム、設計チームという特定のことしか行わな いサブチームは作らない • 開発とは、コーディングだけではなく、デザイン、設計、ドキュメン ト作成なども含まれる • 「モノを作るだけ」ではなく、PBの確認や、チームビルディングな どにも積極的に参加する。 • 経験値の違う開発者がいるのは当然だが、「チームとしての開 発力」を高める努力をする。 専門家として、お互いに責任を持つ 3つの役割
32. スクラムマスター スクラムを周知させ、実施することに責任を持つ！ • チームがスクラムを正しく実施することに責任を持つ • スクラムマスターはチーム全員を多方面からサポートする ◦ 妨害の排除 ◦ 教育、ファシリテーター、コーチ、推進役など • よくある勘違い ◦ プロジェクトマネージャーや、管理者ではない ◦ PB整理や、タスクへのアサインなどは行わない ◦ ただし、スクラムとして成り立っていない箇所があればそれ らを促すことはアリ スクラムをこれから取り入れるチームにとっては、その中心 チームがスクラムに慣れてくると、徐々に仕事がなくなっていく 3つの役割
33. スプリント スクラム開発をするうえで起こるすべてのイベントの入れ物 • スクラムでの開発をはじめたら、常にスプリントの中にいることになる • スプリントは、1ヶ月以内で決まった長さで区切られたタイムスパンで、それを繰り返すことでプロ ダクトゴールを目指す ◦ スプリントは1週間、2週間、3週間、4週間で区切る事が多い イベント スプリントプランニング デイリースクラム スプリントレビュー スプリントレトロスペクティブ
34. スプリントプランニング スプリント内で最初に行うイベント • PBの上から、スプリントで実装する内容を計画する • 作業工数の見積もりを行う • スプリントプランニングのアウトプットとして、作成物として のスプリントバックログ ができあがる • スプリントバックログに登録されている項目を、スプリント バックログアイテム と呼ぶ • 一つのPBIが、2つのスプリントにまたがるような計画はし ない。もし、計画段階でそのようなことが起こりそうであれ ば、PBIを分解し、小さな単位にする • タスク化する場合は、開発者視点や技術単位のタスクでは なく、実際の動作・タスクを完了したらどうなるかを起票す る。 ◦ NG例：API設計、画面デザイン、画面実装 ◦ OK例：お届け日数を計算できるようにする スプリントバックログ 1番目に実現したい 2番目に実現したい 3番目に実現したい 4番目に実現したい 5番目に実現したい 3つの作成物 イベント 「このスプリントを終えとプロダクトがど うなっているか？」というスプリントゴー ルを言語化する
35. デイリースクラム 毎日行う、スプリントゴールに対する進捗報告の場 • 言語化されたスプリントゴールに対する進捗を報告、スプリントバックログの調整の相談を行う 場 • 上記以外の内容、特に「問題解決のための MTG」としてはいけない。 ◦ 問題解決については、「問題が起こったときにコミュニケーションを図るべき」であり、わざ わざ次回のデイリースクラムを待つ必要はない • スプリントプランニングにて、「1日1タスク完了」というタスク化がされていれば、全員が何かしら 進んでいる状態となる。 • 基本的に、毎日同じ時間、同じ場所で行う • ファシリテーターは誰でも良い 3つの作成物 イベント
36. インクリメント スプリントを通じてできあがった、具体的な作成物 • これまでのスプリントの成果 + 今回のスプリントでできあがった、具体的な作成物 • 計画書や、デザイン、画像、図などではなく、実際に画面上で動く状態のもの • すべてのインクリメントは連携して機能する必要がある • 完成の定義を満たす必要がある ◦ 完成の定義とは、例えば単体テスト実施済みであったり、動作確認済であること、など 3つの作成物
37. スプリントレビュー 開発中のプロダクトをデモしたり実際に動かしてもらい、フィードバックを得る • インクリメントを、ステークホルダー（依頼主）にレビューしてもらうイベント • インクリメント＝完成しているものなので、こちらも図や計画ではなく、実際に動くものを用意す る。 • 開発者はスプリントレビューにプロフェッショナルとして望み、そのスプリントでどのようにユー ザーのニーズを満たす機能を実装したか、プレゼンすること ◦ テックカンファレンスではないので、技術に関する詳細は基本的に不要 ◦ うまくいかなかった理由や、反省を述べる場ではない。それらは相手を不安にするだけで ある • フィードバックを得て、PBのお手入れを計画する 3つの作成物 イベント
38. スプリントレトロスペクティブ スクラムチームが、そのスプリントをどう過ごしたか振り返る • スプリントの進行について、より良い方法がないか、方法を検査し適応する • チームのパフォーマンスを上げるために、最も効果がありそうな施策を明らかにする • 「反省会」ではない！良かったところに注目しよう。 • 言い出しづらいことがいえる環境が理想 • 議論が激しくなる可能性がある。スクラムマスターの出番。 3つの作成物 イベント
39. プロダクトバックログリファインメント PBのお手入れ • 開発状況や、スプリントレビューのフィードバックを反映させる • 実施頻度に決まりはなく、チームで決めて良い 3つの作成物 イベント
40. 11の主要要素 3つの役割 3つの作成物 5つのイベント スプリント スプリントプランニング デイリースクラム スプリントレビュー スプリントレトロスペクティブ プロダクトオーナー 開発者 スクラムマスター プロダクトバックログ スプリントバックログ インクリメント
41. Q&A
42. ワークショップ！ テーマ：本日学んだスクラム開発手法 を、スクラム開発を知らない「同級生」「同僚」 「両親」に紹介、理解してもらう！ ルール： ・1枚のスライドに、極力文字を使わず表現する ・スクラムに関するイラストを検索しない ・スクラムガイドは OK！ ・20分事前準備、スプリント 20分 スプリントを何度か回します。 スプリントレビューも行いますので、プレゼン準備も必要です。 役割を決める ①プロダクトゴール ②プロダクトバックログ ③スプリントプランニング （バックログ） ④開発 ⑤スプリントレビュー発表15:00!! ⑥スプリントレトロスペクティブ
43. ワークショップ！ テーマ：本日学んだスクラム開発手法 を、スクラム開発を知らない「同級生」「同僚」 「両親」に紹介、理解してもらう！ ルール： ・1枚のスライドに、極力文字を使わず表現する ・スクラムに関するイラストを検索しない ・スクラムガイドは OK！ ・20分事前準備、スプリント 20分 スプリントを何度か回します。 スプリントレビューも行いますので、プレゼン準備も必要です。 レトロスペクティブ15:20まで！
44. ワークショップ！ テーマ：本日学んだスクラム開発手法 を、スクラム開発を知らない「同級生」「同僚」 「両親」に紹介、理解してもらう！ ルール： ・1枚のスライドに、極力文字を使わず表現する ・スクラムに関するイラストを検索しない ・スクラムガイドは OK！ ①プロダクトバックログリファインメント （お手入れ） ②スプリントプランニング （バックログ） ③開発 ④スプリントレビュー発表17:05!! ⑤スプリントレトロスペクティブ
45. ワークショップ！ テーマ：本日学んだスクラム開発手法 を、スクラム開発を知らない「同級生」「同僚」 「両親」に紹介、理解してもらう！ ルール： ・1枚のスライドに、極力文字を使わず表現する ・スクラムに関するイラストを検索しない ・スクラムガイドは OK！ ・20分事前準備、スプリント 20分 スプリントを何度か回します。 スプリントレビューも行いますので、プレゼン準備も必要です。 レトロスペクティブ17:18まで！
47. Q. バグが発生したらどうするの？ • スプリント内で発生したバグは修正するほか選択肢はありません。
 • バグがある（顕在化されている）状態でリリース可能であったとしても、できる限り取り除くべきです。 スプリント内のバグは「バグ」というよりも、「チームは開発を完了していない」というステータス で す。
 • もしも同一スプリント内で取り除くことができないのであれば、それは開発者の実施した予測（見積 もり）か、スプリントプランニングに誤りがあったことになるので、レトロスペクティブで振り返り、スク ラムの進め方を適応させる必要があります。
 • スプリント外（1つ以上前のスプリント）で発生したバグ 
 • そのバグを取り除かないとスプリントゴールを達成できない場合は、取り除く作業が入ります。 
 • それが残ったままでもスプリントゴールを達成できるのであれば、次スプリント移行で修正します。 PBIとしてのバグ修正は、機能要求と同じように扱われるべきです。
48. アンケートにご協力ください