スクラム入門
この記事はスクラム開発について学ぶために読んだ SCRUM BOOT CAMP の読書メモと感想です。
本について
- SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発
- 西村 直人, 永瀬 美穂, 吉羽 龍太郎 (著)
- https://amzn.asia/d/1fo7IBF
ソフトウェアを作る上で本当に重要なことは何か？
- できあがったソフトウェアを実際に活用することで顧客や利用者の課題を解決したり、お金を稼いだりする、つまり成果を上げること。
- ソフトウェアを作ること自体は目的ではなく、成果を上げるための手段。
- したがって、何のために作るのかを明らかにし、現在作っているものが本当に成果を実現できているのかを小まめに確認しながら進めていくことが必要。
アジャイル開発とは？
- 特徴
- 一度にまとめてではなく少しずつ作り、早い段階から実際に動作するものを届け続けて評価を繰り返す。
- 関係者は目的の達成のためにお互いに協力しながら進める。
- 利用者の反応や関係者のフィードバックを継続的に得ながら、作っているもの自体や計画を調整する。
- アジャイル開発とは何か単一の開発手法を指すものではなく、似たような開発手法に共通した価値観と行動原則に名前がついたものであり、それを体現する様々な手法があるということ。
- スクラム
- エクストリーム・プログラミング(XP)
- カンバン
- さまざまなアジャイル開発手法に共通するのは「事前にすべてを正確に予測し、計画することはできない」ということを前提にしている点。
スクラムとは？
- スクラムは前述の通りアジャイル開発手法の1つ。
- 1990年代にジェフ・サザーランド氏とケン・シュエイバー氏によって作られた。
- 小さな開発サイクル(スプリント)を繰り返しながら、継続的にソフトウェアを改善し、価値を提供していく。
- 特徴
- 要求を価値やリスクや必要性を基準にして並べ替えて、その順にプロダクトを作ることで成果を最大化する。
- スクラムでは固定の短い時間に区切って作業を進める。固定の時間のことを「タイムボックス」と呼ぶ。
- 現在の状況や問題点を常に明らかにする。これを「透明性」と呼ぶ。
- 定期的に進捗状況や、作っているプロダクトで期待されている成果を得られるのか、仕事の進め方に問題がないかどうかを確認する。これを「検査」と呼ぶ。
- やり方に問題があったり、もっとうまくできる方法があったりすれば、やり方そのものを変える。これを「適応」と呼ぶ。
- メリット
- 仕様変更に対応しやすい、柔軟な開発ができる
- 毎回の振り返りで継続的な改善が可能
- 日々のコミュニケーションが活発なためチームの一体感が強まる
- スクラムはわかっていることよりもわからないことが多いような複雑な問題を扱うのに適している。
ロール
ロールは、スクラムチームの中で誰が責任を持って取り組んでいくかをわかりやすくするための目印。肩書きや役職とは全く別のものとして考える。
プロダクトオーナー
- プロダクトの責任者で、プロダクトに1人必ず必要。
- プロダクトの価値を最大化する。
- プロダクトのビジョンを明らかにし、周りと共有する。
- ステークホルダーとプロダクトバックログの内容を確認したり、作る順番や実現時期を相談する。
- そのためにプロダクトバックログの内容を最新の状態に更新する。
- プロダクトオーナーが決めたことを他人が勝手に覆してはいけない。プロダクトオーナー自身が決めることで、結果に対して責任を持てるようになる。
開発チーム
- モノを作る。
- 3人〜9人が適切な規模。
- 要求の分析、設計、コードを書く、ドキュメントを書くといったプロダクトを作るために必要なすべての作業ができなければいけない。
- 特定のことしか行わない専門のサブチームは作らない。
- メンバーごとにできることは違ったりするが、なるべく個人が複数のことをできるようになることが望まれる。
- これを機能横断的なチームと呼ぶ。
- 特定の肩書きや役割はない。
- 仕事は開発チームのメンバーの合意のもとに進み、外部から指示されることはない。
- 開発チーム全体で責任を持ち主体的に進めることによって、チームの能力を継続的に向上させていく。
- これを自己組織化と呼ぶ。
スクラムマスター
- スクラムがうまく回るようにチームを支える。
- 支援と奉仕(サーバントリーダーシップ)。
- 教育、ファシリテーター、コーチ、推進役。
- スクラムの外部からの妨害や割り込みからプロダクトオーナーや開発チームを守る。
- マネージャーや管理者ではない。タスクのアサインも進捗管理もしない。
- チームがスクラムに慣れていない段階では、やり方を教えるような先生役やトレーナーとして振る舞うことが多くなる。
- 慣れてきたら、プロダクトオーナーや開発チームの求めに応じて作業を助けたり、よりうまく仕事を進めるための活動にシフトしていく。
イベント
スプリント
- スクラムでは最長1ヶ月までの固定の期間に区切って、繰り返し開発を行う。
- この固定の期間のことをスプリントと呼ぶ。
- 固定の期間に区切って開発を繰り返すことで、チームにリズムができて集中できるようになり、ゴールに対する進捗が把握しやすくなる。
- スプリントは、他のイベントのコンテナ(入れ物)となる。
- 途中で期間の長さが変わってはいけない。
スプリントプランニング
- スプリントで何をつくるのか、どのように作るのか計画する。
- プロダクトオーナーが今回のスプリントで達成したい目的を明らかにする。
- プロダクトバックログの上位の項目から、目的を達成するための項目を選択する。
- 計画は開発チームの過去の実績(ベロシティ)と、今回のスプリントで作業に使える時間(キャパシティ)などを踏まえて決定する。
- またバックログ上位の項目について、項目の中身を具体的にする、項目の疑問点を解決する、項目の作業量を見積もるといった、スプリントプランニング開始前に事前準備を行う活動をリファインメントと呼ぶ。
- 検討した内容を踏まえて今回のスプリントの目標を簡潔にまとめたものをスプリントゴールと呼ぶ。
デイリースクラム
- このまま進めてスプリントゴールが達成できるかどうかを、毎日、同じ時間、同じ場所に開発チームのメンバーが集まって精査する。
- 開発チームの人数に関係なく15分間のタイムボックスで行い、延長はしない。
- 進め方に特に決まりはないが、以下の3つの定型の質問に答える形で進めることが多い。
- スプリントゴールの達成のために、自分が昨日やったことは何か？
- スプリントゴールの達成のために、自分が今日やることは何か？
- スプリントゴールを達成するうえで、障害となるものがあるか？
- デイリースクラムは問題解決の場ではない。メンバーが問題を報告した場合は、デイリースクラム後に改めて、必要な人を集めた別の会議を設定するなどして、15分のタイムボックスを守るようにする。
スプリントレビュー
- 開発チームのスプリントでの成果物(完成したもの)を関係者にデモする。
- 実際に動作する環境を見ながら確認できるようにする。
- プロダクトオーナーが主催。
- ステークホルダーに参加してもらう。
- 現状の進捗を踏まえて、リリース日や完了日を予測する。
スプリントレトロスペクティヴ
- 直近のスプリントで問題がなかったか、もっと成果を出すためにできることがないか検査を行う。
- 問題そのものを直すのではなく、問題が生まれるプロセスを直す。
- 今後のアクションプランを作る。
- 一度にたくさんのことを変更しようとしない。
作成物
プロダクトバックログ
- 機能や要望などプロダクトに必要なものを抽出し、順番に並べたリスト。
- その項目が実現されたときに得られる価値やリスク、必要性などを考慮して、実現したい順番に並べる。
- 一度作って並べ替えたら完成ではなく、絶えず要求が変わったり追加されるため、常にメンテナンスして最新に保つ。
- 上位の項目については直近のスプリントで開発できるように、作業量の見積もりを済ませておく。
- 項目を作成したり、作業量の見積もりに必要な情報が足りないのであれば、まずは情報を集めるところから始める。
- ただし今後の見通しを立てるために、必要以上に時間を費やさない。実際にスプリントを始めて1~2週間経てば、事前の見通しが本当に正しかったかすぐにわかる。
- 大切なのは致命的なことを見落とさないようにすること。スクラムチームがプロダクトバックログについて理解が十分だと思えること。
スプリントバックログ
- プロダクトバックログから選択した項目と、具体的な作業を洗い出した、スプリントの作業計画。
- スプリント期間中も自由に作業を追加したり削除したりできる。
- 注意しなければいけないのは、開発チームはプランニングで合意した内容を完成させることに全力を尽くす必要はあるものの、すべて完成することを約束しているわけではないということ。
- 約束してしまうと、見積もりが外れていたり難易度が高かったり、不測の事態が発生した場合に、チームが長時間残業したり、必要な作業を省いてしまうかもしれない。
インクリメント
- これまでのスプリントと今回のスプリントで完成した動作する成果物のこと。
- リリースするかどうかに関係なく動作して検査可能でなければいけない。
- 「完成」の指す内容については、スプリントでどこまでやるかチームで共通の基準を持つ必要がある。これを完成の定義と呼ぶ。
- 完成の定義の一例
- コードレビュー
- ユニットテスト
- 結合テスト
- ドキュメント
- セキュリティ
1スプリントの活動例
以下は1スプリントを2週間とした時の活動例。
1週目
月曜日
- スプリントプランニング (スプリントゴールの設定、バックログアイテムの選定)
- 開発着手 (タスク分解、環境準備、実装開始)
火曜日 ～ 金曜日
- デイリースクラム (進捗確認、課題共有、障害除去)
- 実装 & コードレビュー
- 必要に応じてペアプログラミングや設計ディスカッション
2週目
月曜日 ～ 水曜日
- デイリースクラム
- 実装の最終調整
- テスト & バグ修正
- ドキュメント更新 (必要に応じて)
木曜日
- スプリントレビュー準備 (デモ環境の構築、発表資料の整理)
- 最終テスト & バグ修正
金曜日
- スプリントレビュー (成果物のデモ、ステークホルダーからのフィードバック)
- スプリントレトロスペクティブ (改善点の振り返り、次回スプリントへの改善策を策定)
- プロダクトバックログの整理 (次スプリントの計画に向けた準備)
この流れを繰り返すことで、継続的に開発と改善を進めることができる。
まとめ
私は普段スクラム開発を行っていますが、この本を読んで、スクラムの理論を言語化し再確認することができました。
今の企業に勤める前は少人数の受託制作会社に勤めていたのですが、その時はスクラムを導入しておらず、案件によってはウォーターフォールのように進めることもありました。
その時と比較すると、定期的に確かな進捗を確認でき、問題が起きた時も手戻りが少なく済むため、スクラムの導入は非常に有効だと感じています。
ある程度の枠組みが定められたイベントを通じて、建設的なコミュニケーションを行えることや、それによって開発のモチベーションが上がることも大きなメリットです。
それらを踏まえてデメリットもあげるとすれば以下になります。
-
メンバーに一定のコミュニケーションスキルが求められる
スクラム開発では頻繁にミーティングや状況共有を行うため、一定のコミュニケーションスキルがないと取り残されてしまうように思います。
一人でもくもくと開発したい方や、発言が苦手な方は馴染めないこともあるかもしれません。どの業種でも一般的なスキルかもしれませんが、スクラムは求められる水準が少し高いように思います。 -
導入コストが高い
困った時に方向性を示せるメンバーがいないとスクラムがうまく機能しないように思います。
その役割がスクラムマスターだと思いますが、スクラムマスター自身も初めてだった場合、正しく機能するまで一定のトレーニング期間が必要そうです。
また事業部の方達や、受託開発の場合クライアントの方達にも一定理解してもらう必要がありそうで、導入初期は大変な印象です。
このように向かないケースがあると思いつつ、やはり導入するメリットは大きいと感じます。
可能であれば、まずはお試しでスクラムを導入してみて、その効果を実感できたら本格的に導入するといいかもしれません。
本書はこれからスクラム開発を進めていく中でのつまずきどころや、その解決策を示してくれています。
導入のガイドラインとして、またスクラムの理論を学ぶための入門書として非常におすすめなので、興味のある方はぜひ読んでみてください。
Discussion