アジャイルとスクラム開発を手っ取り早く理解する
職場での現状のスケジュール・タスク管理方法に課題感を感じて、スクラム開発を取り入れられないかと思い、著名な本を読み漁ってみた。 手にとったのは以下の３冊（『スクラムガイド』は無料 PDF）で、上から順に読んだ。 絵が多くイメージしやすい『SCRUM BOOT CAMP THE BOOK』から読み始めたことで、あとの２冊もすんなり理解できて結果的に良い順序だったと思う。
- 作者: 西村直人,永瀬美穂,吉羽龍太郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/02/13
- メディア: 単行本（ソフトカバー）
- 購入: 5人 クリック: 13回
- この商品を含むブログ (33件) を見る
- 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未
- 出版社/メーカー: オーム社
- 発売日: 2011/07/16
- メディア: 単行本（ソフトカバー）
- 購入: 42人 クリック: 1,991回
- この商品を含むブログ (257件) を見る
実践していくために重要になると感じたポイントをまとめてみた。
アジャイルとスクラムの関係
アジャイル開発の１手法として、具体的な作業、会議、成果物を定めたものがスクラム。 他にもエクストリーム・プログラミング、リーン、カンバンなどがあり、また独自の手法で取り組んでもよい。
では、アジャイルとはそもそも何だろう？ アジャイルソフトウェア開発宣言 と アジャイルソフトウェア開発の12の原則 を読もう。
原則後戻りしないウォーターフォールに比べ、目的達成のための道筋は柔軟に対応するのがアジャイルとざっくり理解。 アジャイルのプロジェクト成功率はウォーターフォールより３倍高いという研究結果も出ている。 *1
今や旧態依然の大企業やSES企業でなければ、アジャイル手法は部分的にでもたいてい取り入れられているのでは。
スクラム手法
スクラムチームと、スクラムの進め方（スプリント）をざっくりイメージし、それがアジャイル原則にどう従っているのか対応づけて整理してみる。
なお、★ は作成物、■ はスクラムイベント（会議体）、● はロールを示している。
スクラムチーム
よし、スクラムを始めるぞ！となったらまずはロールと、プロダクトバックログから整えるとよさそう。
★ プロダクトバックログ
プロダクトへの要求をリストにして、優先順位で並び替えたもの。 ToDo リストのこと。エクストリーム・プログラミングでは「マスターストーリーリスト」とか「ユーザーストーリー」と呼ぶ。
● プロダクトオーナー
プロダクトバックログの管理者で、並び順を最終決定する権限を持つ役割（ロール）。プロダクトの結果責任を持つ。 プロダクトに必ず１人。プロダクトができたらレビューをもらう「顧客」となる。
● 開発チーム
プロダクトを作るために必要なすべての作業をするロール。スクラムでは３〜９人としている。 分析や UX デザイン、設計、コーディング、インフラ、テストなどを明確な役割なく、機能横断的なメンバーで構成し、上下関係は無し。 開発チームはチーム全体で責任を持って作業を進める自己組織化されたチームとして動く。
● スクラムマスター
プロダクトバックログの要求を実現するプロダクトを作っていくために、後述するスプリントやデイリースクラムなどの、プロダクトオーナーや開発チームの活動を支えるロール。 スクラムやアジャイル開発をまわりの社員、ステークホルダーに理解・実施してもらう組織的な動きも求められる。
● その他の人たち
営業や上司など。現実的には期日やコストなどの都合で介入されることも多そう。 スクラムチームのロールではないが、プロダクトバックログの追記は許可される。 経験上スクラムチーム外だけど時に口を挟みたい人はいるもので、決して蚊帳の外ではないんだということは誤解されないようにするべきだと感じて記載した。
スプリント：プロダクト開発の進め方
固定の期間（スプリント）を区切って、繰り返し開発を行うのがスクラムでのプロダクト開発の進め方となる。 アジャイル宣言ではこのサイクルは２-３週から２-３ヶ月とされているが、スクラムでは１週間から最長１ヶ月とされている。
★ スプリントプランニング（スプリント計画ミーティング）
各スプリントの頭で、プロダクトオーナー・開発チーム・スクラムマスターは、何を作るのか？（What）と、どのように作るのか？（How）を計画する。 プロダクトバックログの上から順に今回の開発対象とする項目を検討し、過去のスプリングの実績（ベロシティ）から開発できる量に収まるように選択する（スプリントゴールを決める）。 選択したものは、開発チームがプロダクトバックログを具体的なタスクに分割し、必要なすべての作業を洗い出し、見積もる。
★ スプリントバックログ
スプリントプランニングで決めた、今回のスプリントで行うタスクの一覧をスプリントバックログとしてまとめる。
★ デイリースクラム
開発チームで毎日15分、集まって以下のことを報告する
- 私が今日やったこと
- 私が明日やること
- 困っていること
★ インクリメント（リリース判断可能なプロダクト）
スクラムでは、スプリント単位でリリース判断可能なプロダクトを作る。 いつでもリリースできる品質を満たしたプロダクトを作るには、実装してコードレビューやテスト、ドキュメント、セキュリティ、パフォーマンス検証など済ませておく必要がある。
■ スプリントレビュー
スクラムチームとプロダクトオーナーが招待した重要なステークホルダーが参加し、インクリメントをレビューする。 開発チームは動作するプロダクトをデモして、プロダクトバックログの項目通りであれば完了にし、依頼したものと異なればプロダクトバックログに戻す。 プロダクトオーナーはプロダクトバックログの現状を説明し、チームで次に何をすべきか議論する。
インセプションデッキ
スクラム手法を学ぶと、思ったよりシンプルで、実践して上手く回る未来が描ける気がする。 でも、スクラム手法に取り組んでいないチームは「よしスクラムやるぞ」とトップダウンでヨーイドンしない限りハードルも高そうだと思ってしまった。
そんな時に、『アジャイルサムライ−達人開発者への道−』第３章「みんなをバスに乗せる」はとても参考になった。
プロジェクトに対する期待をマネジメントするためのすぐれたツール「インセプションデッキ」が紹介されている。 プロジェクトメンバーが同じ方向を向くように、まずはインセプションデッキの10の設問に答え、それを出発点にしよう、というもの。
インセプションデッキの 10 の設問
- 我われはなぜここにいるのか(Why1)
- エレベーターピッチを作る(Why2)
- パッケージデザインを作る(Why3)
- やらないことリストを作る(Why4)
- 「ご近所さん」を探せ(Why5)
- 解決案を描く(How1)
- 夜も眠れなくなるような問題は何だろう(How2)
- 期間を見極める(How3)
- 何を諦めるのかをはっきりさせる(How4)
- 何がどれだけ必要なのか(How5)
おわりに
書籍からのインプットはひとまずこの程度に、まずはプロジェクトのインセプションデッキ・プロダクトバックログの整理などできる所から取り組んでいこうと思う。
保守フェーズのプロダクトと新規プロダクトが混在していてプロダクトオーナーが複数いる、スクラムマスター有資格者や経験者がいない、すでに分業が進んでしまっている（メンバーの機能横断性が低い）など、本格的にスクラムに取り組むのは難しそうな状況もチームによっていろいろあると想像するが、まずは本を片手に部分的な導入からはじめ、もし進展や新たな気付きや学びが生まれればまたブログに投稿したい。
