初めに
皆さんこんにちは。
フロントエンドエンジニアとして頑張っている人です。
私事ですが、現在の会社を退職しペライチという会社にjoinさせてもらうことになりました。
今月からjoinしているのですが、有給消化中のため業務委託として参加し、
7月1日から正式に正社員として参画させてもらうことになっています。
本題
ペライチではアジャイル開発でスクラムを行っております。
前職では経験のなかった開発手法でしたので、ビビって事前にこの本を読みました。
そもそも筆者は、前職の開発手法が何に当てはまるのかわからない。笑
ちょうど読み終わったのでアウトプットとして、自分なりにまとめ投稿しようと思います。
購入前の注意事項
非常にわかりやすかったので、アジャイル開発手法のスクラムを学びたい方はぜひ手にとっていただきたいです。
ただ、他の開発手法（かんばんやXPなど）を学びたい場合はおすすめできません。
あくまでも本のタイトルにもあるように、アジャイル開発のスクラムについて一点突破で書かれた本になります。
そもそもアジャイル開発って？
本書ではこのように記述されています。
- 関係者は目的の達成のためにお互いに協力し合いながら進める
- 一度にまとめてではなく少しづつ作り、早い段階から実際に動作するものを届け続けて評価を繰り返す
- 利用者の反応や関係者からのフィードバックを継続的に得ながら、作っている物自体や計画を調整する
このような進め方をアジャイル開発と呼ぶ。
つまり、アジャイル開発とはなにか単一の開発手法を指すものではなく、似たような開発手法に共通した価値観と行動規範に名前がついたものであると言えます。
より具体的な開発手法として、今回のスクラムやかんばん、エクストリーム・プログラミング(XP)があるということです。
従来の開発と何が違うのか
従来の開発手法では、あらかじめすべての要求を集め、全てを作るためにはどれくらいの期間とコスト、人数が必要なのかを見積もります。
その点アジャイル開発では、まずはじめに期間と人数を決めその範囲の中で大事な要求から順番にプロダクトを作る。
重要なものを先に作り、成果を最大化していく手法です。
パレートの法則と考え方が似てますね。
スクラムって？
スクラムは前述の通り、アジャイル開発手法の1つ。
スクラムの特徴としては以下。
- 要求を価値やリスクや必要性を基準にして並べ替えて、その順にプロダクトを作ることで成果を最大化します
- スクラムでは固定の短い時間に区切って作業を進めます。固定の時間のことを
タイムボックスと呼びます- 現在の状況や問題点を常に明らかにします。これを
透明性と呼びます- 定期的に進捗状況や作っているプロダクトで期待されているせいかを得られるのか、仕事の進め方に問題がないかどうかを確認します。これを
検査と呼びます- やり方に問題が合ったり、もっとうまくできる方法があったりすれば、やり方そのものを変えます。これを
適応と呼びます
ここらへんは本を読み進めていけば理解していきます。
スクラムでは上記のような特殊な呼び方が多く、最初は透明性ってなんだ？タイムボックスってなんだ？ってなりますが、本書の特徴である一部漫画形式で書かれている箇所が補ってくれます。
なので安心して読み進めましょう。
個人的に重要なのは、上記内容以外の5つのイベントと3つのロールと3つの成果物のルールセットです。
スクラムでは最低限のフレームワークがあるだけなので、ルールセットをうまく利用して取り組む必要があります。
スクラムのルールについては、こちらに最新版があるので参考にするといいかもしれないです。
次に上記で出てきたイベント、ロール、成果物をまとめてみる。
5つのイベント
| イベント | 概要 |
|---|---|
| スプリント | - 最長1ヶ月までの同じ期間に区切って繰り返す。(短くて1週間、長くて4週間) - 1つの区切りをスプリントと呼ぶ - スプリントは、他のイベントのコンテナ(入れ物)となる - 期間の長さが変わってはいけない |
| スプリントプランニング | - スプリント計画会議とも呼ぶ - スプリントで開発をするためには計画が必要なので、スプリントの冒頭で実施する - プロダクトバックログの項目で話し合う ○ プロダクトオーナーは何をほしいか ○ 開発チームはどれくらいできそうか ○ 開発チームはどうやって実現するか - 検討した内容を踏まえて今回のスプリントの目標を簡潔にまとめておく、これを スプリントゴールと呼ぶ |
| デイリースクラム | - ゴールの達成に向けて進んでいるか毎日検査する - 15分間のタイムボックスで行い、延長はしない - 進め方には特に決まりはないが、以下の3項目で進めることが多い ○ スプリントゴールの達成のために、自分が昨日やったことは何か？ ○ スプリントゴールの達成のために、自分が今日やることは何か？ ○ スプリントゴールの達成するうえで、障害となるものがあるか？ |
| スプリントレビュー | - 開発チームのスプリントでの成果物(完成したもの)を関係者にでもする ○ 事前に完成したもの、完成してないものを区別しておくと良い - フィードバックを得て、プロダクトバックログを見直す - 全体の残作業や進捗をトラッキングする - 今後の予定や見通しを共有する - プロダクトオーナーが主催 - ステークホルダーに参加してもらう - スプリントレビューの時間は、1ヶ月のスプリントであれば4時間、2週間の場合は2時間が望ましい |
| スプリントレトロスペクティブ | - もっとうまく仕事を進められるようにカイゼンを繰り返す - バグを治すではなく、バグが生まれるプロセスを治す - 人、関係、プロセス、ツールなどの観点で今回のスプリントを検査する - うまくいったこと、今後の改善点を整理する - 今後のアクションプランを作る - 一度にたくさんのことを変更しようとしない |
3つのロール
| ロール名 | 担当領域 | 役割 |
|---|---|---|
| プロダクトオーナー 通称 PO |
プロダクトのWhatを担当 | - プロダクトの価値を最大化する - プロダクトの責任者(結果責任)で、プロダクトに1人必ず必要 - プロダクトバックログの管理者 - プロダクトバックログ項目の並び順の最終決定権限を持つ - プロダクトバックログ項目が完成しているかどうかを確認 - 開発チームに相談できるが干渉はできない - ステークホルダーとの協業 |
| 開発チーム | プロダクトのHowを担当 | - ものを作る - 3人〜9人が適切な規模 - 全員揃えばプロダクトを作る能力が揃う - 肩書やサブチームはなし |
| スクラムマスター | プロセスを円滑に回し、 プロダクトをうまく作れるようにする |
- 妨害の排除 - 支援と奉仕(サーバントリーダーシップ) - 教育、ファシリテーター、コーチ、推進役 - マネージャーや管理職ではない - タスクのアサインも進捗管理もしない |
3つの成果物
| 成果物 | 概要 |
|---|---|
| プロダクトバックログ | - 実現したいことをリストにして並べ替える ○ 優先度ではない - 常にメンテナンスして最新に保つ ○ 項目が追加されたり、削除されたりする ○ 順番は定期的に見直す - 上位の項目は見積もりを済ませておく(定期的に見積もり直す) - 責任者はプロダクトオーナー(PO) |
| スプリントバックログ | - 選択したプロダクトバックログ項目と実行計画 - プロダクトバックログを具体的な作業に分割する - 後から増えることもある - 1タスクは1日以内で終わるサイズ |
| インクリメント | - スプリント単位で評価可能なインクリメントを作ることが求められる- インクリメントとはこれまでのスプリントでの成果と今スプリントで完成したプロダクトバックログ項目を合わせたものを指す - リリースするかどうかに関係なく動作して検査可能でなければいけない - プロダクトオーナーと開発チームが「完成」の指す内容について共通の基準を保つ必要があり、これを 完成の定義と呼ぶ |
全体図
上記のテーブルを踏まえての全体図でいい感じのが合ったので添付します。
本書を読み終えての感想
正直本で読んでみただけだと、半分わかるかどうかでした。
なれない用語ばかりなのでどれがどうだっけ？って何度もなりました。
ただ、本書は実際の開発に置き換えてマンガ形式に教えてくれます。
スクラムの全体像を把握するにはとてもいい本でした。
1度だけ読み終えてもわからないことが多いので、スクラムをする上でわからないことがあればまた読み直すスタイルでいこうと思います。
今回はこれで以上です。
ありがとうございました。