スクラム 再入門

横道 稔 RightSegment

浅岡 陽子 GameTailor

井辺 拓男 Smalgo

茅野 祥子 Dynalyst

田中 正巳 TAO

中村 州一朗 GameTailor

二藤部 恵理 Amebaリワード

本間 貴真 CAMP

2015-03-19株式会社サイバーエージェント

アドテクスタジオ「リーン/アジャイル開発プロセス ゼミ」

「リーン/アジャイル開発ゼミ」とは？

「リーン/アジャイル開発」ゼミとは

● サイバーエージェント アドテクスタジオ内制度

● 「スキルアップゼミは、参加自由の勉強会とは異なり、大学

のゼミと同様に少数メンバーにて研究を行います。研究の

成果を事業に活かすことを目的とします。」

「リーン/アジャイル開発」ゼミとは

● リーンソフトウェア開発、スクラム、XP、カンバン、リーンス

タートアップなどのアジャイル手法の原理、原則、本質を学

び、現場に活かす（形式知の習得）

● 各現場の開発プロセスパタンの作成などを通じて、暗黙知

の形式知化（共有化）に寄与する

SECI モデルでいうこのへんをまずやろうとしている。

「アジャイル開発」とは？

アジャイル宣言とその経緯

● 2001年に、軽量ソフトウェア開発手法との分野において名

声のある17人がスキーリゾートに会し、彼らがそれぞれ別

個に提唱していた開発手法の重要な部分を統合することに

ついて議論した （Wikipedia より）

● 結果、まとまらなかった。

● しかし、それぞれが推進していた開発手法に

共通する価値観を見出した。

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践

あるいは実践を手助けをする活動を通じて、

よりよい開発方法を見つけだそうとしている。

この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを

認めながらも、私たちは右記のことがらにより価値をおく。

つまり、アジャイルは手法ではなく価値観

Don't DO Agile, BE Agile!

近年におけるアジャイル開発（１）

● 「リーン・スタートアップ」の誕生。○ リーン/アジャイルを奔流とし、よりビジネスにフォーカス

● アジャイル開発のスケール○ Scrum of Scrums○ Spotify での事例（Scaling Agile @ Spotify）○ リーン開発の現場（スウェーデン国家警察機関）

● エンタープライズアジャイルの本格化○ Disciplined Agile Delivery (DAD)○ Scaled Agile Framework（SAFe）

近年におけるアジャイル開発（２）

● キャズムを超えた？

● ワードとしての陳腐化している？

● 手段としてとらえた結果、多くの失敗が生まれている？

　今、スクラムを改めて考えてみるときかも

Scrum 再入門

注意（スライド公開において）

● 当スライドでは、発表時にスクラムを全くしらない方への短時間での説明を勘案した結果、各訳語をスクラムガイドと合わせておりません。スクラムガイドをすでにお読みの方は、以下に読み替えてください。

○ スプリント計画 → スプリントプランニング○ スプリント振り返り → スプリントレトロスペクティブ○ 出荷可能な製品 → インクリメント

1. スクラムオーバービュー

2. ロール：スクラムマスター

3. ロール：プロダクトオーナー

4. ロール：開発チーム

▼

▼

▼

Harald Walker https://www.flickr.com/photos/sonicwalker/446331388/

スクラムの３つの原則

スクラムオーバービュー

３つの原則

● 検査○ チームがゴールに向け正しく進捗しているか検査し、検知する○ 成果の妨げにならないように検査の時間には制限を設ける

● 適応○ 検査の結果、プロセスや構成に調整が必要な場合、早急に対応を行う

○ 5つのイベント内で対応を行う

● 透明性○ 結果責任を持つ者に対して全て見える化されている

ex. 　　　　　　プロセスを指す用語が、関係者全員で共有されてる

　　開発チームと PO で「完了の定義」を共有している

　　開発チーム内で他のメンバーの作業が見えるようになっている

スクラムの３つのフレーム

スクラムオーバービュー

３つのフレーム

1. 役割（３つのロール）

2. ５つのイベント

3. ４つの成果物

▼

▼

スクラムオーバービュー

３つのフレーム

1. 役割（３つのロール）

2. ５つのイベント

3. ４つの成果物

▼

▼

スクラムオーバービュー

3つのロール

スクラムオーバービュー

３つのフレーム

2. ５つのイベント

1．役割（３つのロール）

3. ４つの成果物

▼

▼

スクラムオーバービュー

5つのイベント

スクラムオーバービュー

5つのイベント ①

● スプリント計画スプリントのゴールを設定する

プロダクトバックログからスプリントバックログを作成

１つのスプリントは２〜４週間

スクラムオーバービュー

5つのイベント ②

● デイリースクラム　　開発チーム全員で、スプリントゴールに対する進捗を確認するMTG　　朝会

　　昨日の作業、今日の予定、現在の障害の共有

スクラムオーバービュー

5つのイベント ③

● スプリントレビュースプリントの成果物のレビューを行う

プロダクトの今後についてディスカッションする

ステークホルダーも参加が可能

スクラムオーバービュー

5つのイベント ④

● スプリント振り返りKPTスプリントレビューが終って、次のスプリント計画が始まる前に行う

スクラムオーバービュー

5つのイベント ⑤

● プロダクト・バックログ・リファインメントプロダクトバックログの内容や優先度をブラッシュアップする

スプリント期間の５〜１５％プロダクトオーナと開発チームでアップデート

スクラムオーバービュー

３つのフレーム

３. ４つの成果物

2. ５つのイベント

1. 役割（３つのロール）

▼

▼

スクラムオーバービュー

４つの成果物

● 出荷可能な製品○ スプリントごとに作られる

● プロダクトバックログ○ 今後開発する機能を、優先順位付きで管理する○ 誰でも参照、追加が出来る（優先順位変更はPOのみ）○ プロダクトの状況が把握できるもの

● スプリントバックログ○ プロダクトバックログから1スプリント分を細分化させたもの

● インペディメントリスト （障害リスト）○ チームの障害になっているもののリスト

認定スクラムマスター研修（2015/03/05,06 アドテクスタジオ プライベート研修 by Jim Coplien）

より

スクラムオーバービュー

ムリ、ムラ、ムダ

ムリムラムダ は 減らすもの。誰でも減らしたい

例えば

● 誰も読まないドキュメントの作成はしない● ユニットテストはいつでも必ず必要？？● 使い辛いツールは使わない● コードに必要以上にコメント（ドキュメント）は書かない

など

改善を繰り返すことで

ムリムラムダを見つけたらすぐに対応するという

意識が大切

スクラムオーバービュー

場

場、雰囲気、環境 を大切にする ex 開発メンバーがより働き易いチームを作る

良い開発環境を作る

すごしやすい社内を作る

美味しいコーヒーを用意する。。。

ベロシティ（生産性の指標）には

成果に直接関わること以外も含める（勉強会、休暇などなど）

チームのモチベーションは

チームのパフォーマンスに影響する

スクラムオーバービュー

スプリント中止の儀

メンバーそれぞれ、外部要因で自分のコミットを台無しにされたらフラストレーションは溜まるもの。。。。。

儀式の内容

1. チームメンバー全員で集まる2. 円を作り、中心に足を向けて仰向けに寝転がる3. 合図によって、全員で叫んで感情を発散させる

　　（ex. せっかく頑張ったのに、納期に間に合わせたのに。。。などなど）

4. へとへとになるまでやって、疲れたら、立ち上がる5. 気分をすっきりさせて、他の作業に移る

開発メンバーのモチベーションを大切にするこの手法から伝わることは

開発メンバーをリソースとは考えないという点です

スクラムオーバービュー

守・破・離の精神元々武道の考え方です。実際にスクラムに当てはめた場合は

● 守○ まずは形式に沿ったスクラムを実践してみる○ ただやるのではなく、それぞれのロール、フレーム、イベントがなぜ必要なのかを

理解することが大切である

● 破○ 守で形式に沿った事が出来る様になったら、応用してみる○ 現状に納得出来なければ常に変化させ、試してみる

● 離○ 破を繰り返すと、自分チームに合った新しいスクラムの形が見えてくる○ 自分たちの新しいスクラムを作る○ 作るためにはメンバーにそれなりの経験を求められる

守の状態に固執してしまいがちですが、スクラムとは手段ではないので改善して変化させていくことが自然であり大切である。

スクラムのそもそもの発端は

「成功率が低く、管理者はいつも不機嫌で、開発者は常にプレッシャーにさらされ、顧客は不満足である」

という問題を解消するためにできたものであり

最終形態（ベストな状況）というものはありません

常に検査と適応を繰り返し

関わる人々を含めた環境（場）を

改善、進化をし続けることが大切です

2. ロール：スクラムマスター

3. ロール：プロダクトオーナー

4. ロール：開発チーム

▼

▼

▼

1. スクラムオーバービュー

スクラムマスター

1. 役割・責務

2. 他のロールとの関わり方

▼

▼

3. イベントとの関わり方

『役割』と『責務』

● チーム全員が共通認識を持てるよう必

要に応じて、よく話す。

● 中立性と客観性を発揮し、チームが問

題解決出来るよう導く

● チームの成長を手助けする

● 仕事の妨げとなる障害物を取り除く

スクラムマスター

スクラムマスター

1. 役割・責務

2. 他のロールとの関わり方

▼

▼

3. イベントとの関わり方

プロダクトオーナーとの関係

● プロダクトオーナーにサポート出来ること

○ プロダクトオーナーはROIに責任がある。

○ プロダクトオーナーの責任に対して、スクラムマスターは

ROIを最適化するプロセスが上手く回るようにす

る責任がある。

スクラムマスター

● プロダクトオーナーに確認すべきことの例

○ プロダクトバックログは整理されてますか？

○ 仕様や要件は明確に発信出来てますか？

○ スクラムチームに不満は抱いていないですか？

　※これらは例にすぎませんが、スクラムを進めていくことでチームも成長していくの

で、チームの成長度によって、スクラムマスターからプロダクトオーナーに確認すべき

ことは変わっていきます。

スクラムマスター

開発チームとの関係

● 開発チームへサポート出来ること

○ 開発チーム出荷可能な製品として開発する責任

がある。

○ スクラムマスターは開発チームの障害を排除する責

任がある。

スクラムマスター

● 開発チームに確認すべきことの例

○ 効率的に協働してますか？

○ 責任を持って開発してますか？

○ 当事者意識を持って問題解決してますか？

○ チームメンバーは疲れていないですか？

○ 何かショックを受け効率落ちていないですか？

○ 外部から何か横槍を入れられていないですか？

○ プロダクトオーナーに不満を抱いていませんか？

スクラムマスター

スクラムマスター

1. 役割・責務

2. 他のロールとの関わり方

▼

▼

3. イベントとの関わり方

５つのイベント

● スプリント計画

● デイリースクラム

● スプリントレビュー

● スプリント振り返り

● プロダクトバックログリファインメント

スクラムマスター

● スプリント計画

● イベント概要

○ プロダクトバックログから次のスプリントの目標と機能を

決め、タスク化していく作業

● スクラムマスターの関わり方

○ スプリント計画が実施されることを確認する。

○ プロダクトオーナーと開発チームの会話と作業の場であ

ることに重きを置く。

○ 客観的なベロシティ値でスプリントの開発項目が、

選ばれているか確認する。

スクラムマスター

● デイリースクラム

● イベント概要

○ 開発メンバー同士で各自の状況を共有する

● スクラムマスターの関わり方

○ 必要以上の議論は止めてあげる

○ 何か難しい問題が共有された場合、デイリースクラムで

は解決せず、別の時間に解決するよう促す

スクラムマスター

● スプリント振り返り

● イベント概要

○ 働き方、プロセス改善に関するブレインストーミング&改善アクションの取り決めを行う

● スクラムマスターの関わり方　

○ 課題の着眼点へのアドバイスや、アクションの妥当

性の確認をする。

○ 障害はインペディメントリストに追加する。

スクラムマスター

4. ロール：開発チーム

▼

▼

▼

1. スクラムオーバービュー

3. ロール：プロダクトオーナー

2. ロール：スクラマスター

プロダクトオーナー

想定する聴衆

もちろんプロダクトオーナー

スクラムマスター・チームの方も

➢ プロダクトオーナーをサポートするために

➢ プロダクトオーナーの役割を理解

プロダクトオーナー

Overview1. 役割・責務

2. 管理する成果物

3. スキル

4. 各ロールとの関わり方

5. 参加するイベント

▼

▼

▼

▼

認定スクラムプロダクトオーナー研修フィードバック

リーン・キャンバス

プロダクトオーナー

1. 役割・責務

2. 管理する成果物

3. スキル

4. 各ロールとの関わり方

5. 参加するイベント

▼

▼

▼

▼

プロダクトオーナー

1.『役割』と『責務』

ROI（投資対効果）の最大化チームに何かを作ってもらう＝投資

2. 管理する成果物

プロダクトバックログプロダクト・バックログ＝Whatのリスト

スプリント・バックログ＝Howのリスト

PO: 2/5

プロダクトオーナー 1.『役割』と『責務』　②

やらなきゃならないこと

● プロダクトの機能とフィーチャーを定義し、

リリースの内容と日付を決める（『期日』・『予算』・『スコープ』）

● プロダクトの収益性と投資効果の責任者（ ROIの最大化）

● 市場価値をもとに機能の優先順位を決める

● スプリントごとにフィチャー定義や優先順位を変える権利がある

● 作業結果を許可または却下する

PO: 2/5

プロダクトオーナー 1.『役割』と『責務』　③

やらなきゃならないこと

PO: 2/5

プロダクトの旗振り役がたったひとり！

プロダクトオーナー

1. 役割・責務

2. 管理する成果物

3. スキル

4. 各ロールとの関わり方

5. 参加するイベント

▼

▼

▼

▼

プロダクトオーナー

3. 『スキル』　①

ビジネススキルの全てを持つ人あるサイトによるとこんな感じの人らしい・・・

PO: 3/5

1. 技術を活用すること技術を理解し、活用の可能性を調べられる力

プロダクトオーナー

3. 『スキル』　②

PO: 3/5

2. 本当に大事なものだけに集中すること

影響力のある社内の人間や客先の声高な要求に屈しない力

プロダクトオーナー

3. 『スキル』　③

PO: 3/5

プロダクトオーナー

3. 『スキル』　④

その他 いっぱい。

3. 時間管理

自分のプロジェクトにとって本当に重要な仕事に集中する時間を作り出す力

4. コミュニケーション能力

簡潔明瞭な文章を書ける。権威ではなく説得によって人を動かす力

5. ビジネススキル

開発チームと社内のその他の人たちとの間の橋渡し役として、財務部門、マーケティング部門、営業部門、

経営陣とともに、それぞれの分野の専門用語や考え方を使いながら仕事できる力

PO: 3/5

プロダクトオーナー

3. 『スキル』　⑤

そんな人いねーよこのような資質やスキルを持っている人を探し出して、トレーニング、日常的に気軽に助言を受けるためのメンタープログラム、正式な従業員開発プログラムなどを使って、育てることだ

　⇒そっかそっかぁ。。って、だからその資質ある人どこにいるんだよ！

それゆえにスクラムの弱点になりがち

PO: 3/5

プロダクトオーナー

3. 『スキル』　⑥

じゃあどうするの？

⇒育成する

⇒POチームを設ける（その場合も最終決定者は明確にする)

⇒ステークホルダーにサポートしてもらう

PO: 3/5

プロダクトオーナー

1. 役割・責務

2. 管理する成果物

3. スキル

4. 各ロールとの関わり方

5. 参加するイベント

▼

▼

▼

▼

プロダクトオーナー

4.『各ロールとの関わり方』　①

すべきでないこと

● プロジェクトマネージャとしてふるまう

● チームのやる気を削ぐ

● なにを、いつまでに終わらせなければはらな

い、と指示する

PO: 4/5

プロダクトオーナー　すべきでないこと３つの理由

4.『各ロールとの関わり方』　②

その壱. プロダクトオーナーはマネージャじゃない

リーダーでなくてはならない !⇒ リーダーはみんながついていく。

　マネージャは管理者

PO: 4/5

プロダクトオーナー　すべきでないこと３つの理由

4.『各ロールとの関わり方』　③

その弐. チームは制約条件

チームにマイナスなことはしない！

じゃあ言いたいことあったらどうするの？

⇒ 言いたいことはまずＳＭに言え！！

⇒ 例えチームがヘッポコでポンコツだとしても

　そのチームへの投資で最大の効果を得る

PO: 4/5

プロダクトオーナー　すべきでないこと３つの理由

4.『各ロールとの関わり方』　④

その参. 信頼こそすべて！

信頼しなきゃ信頼されない。信頼関係が築けない！

PO: 4/5

プロダクトオーナー

4.『各ロールとの関わり方』　⑤

すべきこと

● ビジョンを明確化する

● 最新のビジネス価値をデリバリーする（マクロな視点）

● チームの価値を引き出す（投資に対する効果）

● スプリントを緊急に停止する

PO: 4/5

プロダクトオーナー

1. 役割・責務

2. 管理する成果物

3. スキル

4. 各ロールとの関わり方

5. 参加するイベント

▼

▼

▼

▼

プロダクトオーナー

5.『参加するイベント』

1. スプリント計画

2. スプリントレビュー

3. スプリント振り返り

4. プロダクトバックログ リファインメント

5. デイリースクラム

※関係がよければ全て出席していい

PO: 5/5

▼

▼

1. スクラムオーバービュー

2. ロール：スクラマスター

▼

4. ロール：開発チーム

3. ロール：プロダクトオーナー

1. 開発チームとは

2. 完了の定義

3. 良い開発チーム

4. チームワーク

5. 各イベントへの関わり方

▼

▼

▼

▼

開発チームとは

その『役割』と『責務』とは？

・プロダクトバックログを、　出荷可能な製品として実装することに責任を持つ

・毎日の「検査」と「適応」で、　ゴールの達成とプロセスの成長を行う

1. 開発チームとは

2. 完了の定義

3. 良い開発チーム

4. チームワーク

5. 各イベントへの関わり方

▼

▼

▼

▼

完了の定義とは？

● スプリントバックログの各作業について、どこまで作業をしたら「完了」とするかを決める

● 開発チームが主体で決め、POと合意する

（例）

「各作業について、スプリント内で必ずユニットテストとコードレビューはやろう」

↓完了の定義は「ユニットテストとコードレビューが完了していること」になる。

完了の定義

Done List● 成果物を「リリース」するために必要な作業を

リストアップする● その中から「各スプリント内でどこまでやるか」、

を抜き出したものが「完了の定義」

（Done Listの例）

● コードレビュー● 単体テスト● 結合テスト● パフォーマンステスト● ステージングにデプロイ

開発チーム「コードレビューと単体テストはスプリント内で必ずやろう」

“完了の定義”に含める項目

完了の定義

Undone Work● 完了の定義に入らなかったDone Listの残作業● 通常のスプリントとは別に、

リリーススプリントを別途実施してリリースする

（Done Listの例）

● コードレビュー● 単体テスト● 結合テスト● パフォーマンステスト● ステージングにデプロイ

開発チーム「結合テスト以降は、リリーススプリントで対応しよう」

“Undone Work”

完了の定義

完了の拡張

そもそも、リリーススプリントはムダ！

もし「完了の定義」にDone Listの項目がすべて含まれていれば、

各スプリント毎に成果物をデリバリー出来るはず。

例えば、今は完了の定義の項目は下記のように２つだが、、、

Done List● コードレビュー● 単体テスト● 結合テスト● パフォーマンステスト● ステージングにデプロイ

完了の定義

チームの成長とともに、「完了の定義」を拡張していく

Done List● コードレビュー● 単体テスト● 結合テスト● パフォーマンステスト● ステージングにデプロイ

完了の定義

完了の拡張

完了の拡張！！

「完了の定義」の項目が１つ増えた。

● 自動化などによって「完了の定義」の項目を増やしていく● チームの成長につれて増やしていく● 最終的にはスプリント内でいつでもリリース！

○ リリーススプリントが必要無くなる⇒ムダが減る

1. 開発チームとは

2. 完了の定義

3. 良い開発チーム

4. チームワーク

5. 各イベントへの関わり方

▼

▼

▼

▼

● 自己組織化されている○ チームの問題はチーム自身が解決する

● クロスファンクショナルである○ チーム全員がチームのすべての個人を助ける○ 開発チームは多様性を持つ

● 長期安定○ 長期間にわたって安定したベロシティを目指す○ チームがお互いに信頼を育み、良いチームになる

良い開発チーム

1. 開発チームとは

2. 完了の定義

3. 良い開発チーム

4. チームワーク

5. 各イベントへの関わり方

▼

▼

▼

▼

チームワーク

「群がる」すなわち、チームワーク

○ クロストレーニングを強制することで、

チームは共同作業の方法を学ぶ

“1度にバーンダウンさせる

バックログアイテムは1つだけ！”

チームワーク

● 分散・並列作業ではなく、チームで「群がって」問題を解決していく

● 人と人の重なり合い ”SASHIMI” by James O. Coplien

Albert Lynn

1. 開発チームとは

2. 完了の定義

3. 良い開発チーム

4. チームワーク

5. 各イベントへの関わり方

▼

▼

▼

▼

各イベントへの関わり方

「ロール：開発チーム」が主体になるものを抜粋してご紹介

イベントへの関わり方

スプリント計画

● スプリントバックログ作成○ 開発チームが見積もりを実施する

見積もり手法「プランニングポーカー」● 見積の違いを見える化する

○ メンバーそれぞれが認識している仕様に、齟齬がないか確認できる

● 合意を促進する

● 全員が見積もりに参加できる

Joel Bez

イベントへの関わり方

デイリースクラム

開発チームが主体となって実施する

⇒「スクラムマスターへの報告」ではない！

● 透明性○ 問題が共有される

○ 『That's information!!』James O. Coplien⇒「問題を共有してくれてありがとう！！」

● 明らかになった問題をチームで解決する

○ チームがチームを助ける

⇒「群がる」「SASHIMI 」「検査・適応」

イベントへの関わり方

スプリント振り返り

スクラムマスターが主催

⇒「検査・適応」していくのは開発チーム自身

● プロセスを振り返る● 開発チーム自身が改善策を特定する

○ 検査、適応

「ロール：開発チーム」まとめ

大事そうなキーワードをいくつか抜粋して「まとめ」とします。

● 出荷可能な製品○ 完了の定義

● チームワーク○ 群がる、“SASHIMI”

● 検査・適応● 透明性

○ “That's Information!”

アドテクスタジオでは一緒にスクラムなチームになるエンジニアを募集しています

http://adtech.cyberagent.io/