スクラムプロジェクト準備(公開用) No.31

No.31

すくすくスクラム
セントラルソフト株式会社事業推進部課長

スプリントぜろ！

クリエイティブな仕事したい人？

2

自己紹介

•楽器メーカーで開発業務５年
•陶磁器の卸父の会社を継ぐ 2年
•鉄道関係の研究開発 2年
•シンセサイザーオペレータ１年
•ネットワーク保守業務１年
•現職ただいま15年目ぐらい
3

やってきたもの（開発）

やってきたもの（開発）
• 電子楽器の開発
• ドラムマシン、エフェクター、カラオケアンプ
• 鉄道関連
• デジタルATS、リニアモーターカー運行システム
• フレームワークの開発
• IOCコンテナをベースとしたJavaとVBをシームレスにつなくコン
ポーネントフレームワーク
• 業務アプリ
• 大規模基幹業務開発、標準化、方式設計
• 大規模基幹業務向けEJBフレームワークの開発
• 物流系、薬局関連、製造業関係
• 音響制御系
• サラウンドミキサー装置 →愛地球博NHKパビリオンで上映

現在
• 教育プランニング、受託開発

• スクラム導入支援、コーチング技術を使ったトレーニング

• すくすく・スクラムスタッフ

• NLP認定プラクティショナー

• 認定スクラムマスター、プロダクトオーナー

• 要求開発アライアンスコアメンバー

• DCFA認定ドラムサークルファシリテーター
MOTO$$ Beat$of$Success

• BOSサポートメンバー(トレーニングビート)
Beat$of$Success
T.G.P.%
http://www.bos1.org

• Cloudera Hadoop認定デベロッパー

• BCB認定ファシリテーター

トロントAgile 2008（ドラムサークル） EM ZERO Vol.2

XP祭り 2009 (リズムと朝会)
XP祭り 2008
Thanks
チームの皆へ
送り出してくれた人達へ
（リズムとファシリテーター育成）今日聞いてくれた人達へ

(撮影KKD)
要求開発アライアンス DevLove
TFPモデリングスペキュレーション 2007年人とのつながりの奇跡に感謝(2008 LT)
要求開発マスター認定制度への提案 2008年すくすく・スクラム
スクラム基礎＋朝会ワークショップ
スクラムと要求開発 2011/05
オブラブ自己組織化ワークショップ
ドラムサークルとプロジェクトファシリテーション(2007/06LT) ウォーターフォールとアジャイル
短期に低価格で持ち家建設を行うためのパターンランゲージ(2009/01 LT) リズムと朝会（名古屋）
スクラム入門、ドラムサークルチームビルディングセッション(2010/07) スクラム入門、朝会ワーク（大阪）
マイクロソフト TechEdDay 振り返りの基礎はこれだ
スクラム導入どたばた事例 2010/08 振り返りってなんだ（岡山）
マイクロソフト AgileDay4 モチベーションマネジメント入門
自己組織化のためのNLPをつかったコミュニケーションワーク
スクラム道ファシリテーション入門だ！
スプリント０探求ワークショップ(2011/02) 心理学を使ったスクラムチームのコミュニケーションパターン分析ワーク
スクラムギャザリング東京ショップ（XP祭り2011）
スクラムの心ワークショップ(2011/10)
タスクカンバンはこれだ！(2011/10)
同再演 2011/12

現在

心理学手法を使ったアジャイル導入プログラムを
鋭意開発中！

【アジャイル導入プログラムの開発メンバー】(五十音順)

• 牛尾剛さん (シンプルアーキテクト代表)
• 梅本和比己さん (株式会社チーム医療代表取締役、 NLPトレー
ナ)
• 大久保透さん (株式会社チーム医療 NLPトレーナー)
• 林栄一さん (セントラルソフト株式会社)
• 本橋正成さん (合同会社カルチャーワークス)
• 吉羽龍太郎さん (株式会社ICI)

自我状態 ∼自己の行動を理解する∼

周囲に厳しく／厳格／責任感／けじめ
／偏見／圧力Ｃ
Ｐ
P 親の自我
周囲に優しく／保護的／思いやり／配慮／ＮＰ
心づかい

冷静／客観的／合理的計画的／役割的Ａ A 大人の自我

ＮＣ
感情的／明るい／直感的／行動的／自由
天真爛漫
LP
CC
C 子供の自我
RC
感情的／暗い／内省的／従順／消極的
感情的／反抗的／破壊的／衝動的

9
BCBトレーナー大久保氏の資料より一部抜粋

ユーザープロダクトオーナースクラムマスターチーム

ファシリテートファシリテート
お願い自己組織・振り返り
ヒアリング

要求デモ A
バックログ
ヒアリング
励まし・巻き込み
自己組織・振り返り

連帯
信頼連帯連帯

まだまだ、たくさん線
を引くことができます。
10

ニューロロジカルレベル

スピリチャリティー

アイデンティティ―
価値観

信念

能力

行動

環境

すくすく・スクラム
2009年４月から東京で始まった。
月に１回、関連講演者やスタッフがリード
４ヶ月に１回振り返り月
参加費無料
すくすくスクラム瀬戸内 2010年2月開始
すくすくスクラム大阪 2010年６月開始
２０回の勉強会を実施
スクラムアライアンス登録ユーザーグループ

12

すくすく・スクラムイベント実績
すくすくスクラム2009年
– 4月23日第１回クリエイティブ朝会林栄一(東京都)
– 5月28日第2回スクラム基礎、開発者兼経営者
林栄一氏、エマーソンミルズ氏(東京都)
– 6月25日第3回自己組織化ワーク林栄一(東京都)
– 7月23日第4回カンバンゲーム安井力氏(東京都)
– 9月16日第５回壁はスクラムで乗り越えろ
榎本氏(東京都)
– 10月21日第６回デザイナー気分でAgileUX
加納氏(東京都)
– 11月25日第7回チームとは何だ？！
エマーソンミルズ氏(東京都)
– 12月19日 "TDD" Boot Camp "ＴＤＤ" をつかめ！
Lasse Koskela氏、和田卓人氏(東京都)
• XP祭り
– 9月19日 Let's クリエイティブ朝会ワークショップ
林栄一氏 (東京都)
13

– 1月25日第８回１人１人がリーダーだ！今村氏(東京都)
– 2月4日第9回 IN広島Catch The Scrum エマーソンミルズ氏(広島県)
– 2月7日第10回 in 名古屋朝会を極めろ林栄一氏(愛知県)
– 2月25日第11回ユーザーストーリーはこう書け！角征典氏(東京都)
– 3月24日第12回 PFとは何だ?! PFを体感しよう! 松本潤二氏(東京都)
– 4月25日第13回 IN大阪スクラムを体感しよう第一弾江端一将氏(大阪府)
– 5月27日第14回スクラムの落とし穴はどこだ？！西村氏、安井氏(東京都)
– 5月29日第15回 IN大阪第２弾スクラムを体感しよう江端一将氏(大阪府)
– 6月21日第16回これが、ユーザ行動モデリングだ！本徹也氏(東京都)
– 7月28日第17回ふりかえりの基礎はコレだ！林栄一(東京都)
– 9月29日第18回私がみたAgile2010はコレだ!? 細澤あゆみ氏(東京都)
– 10月25 日第19回 Scrum &kanban 江端一将氏
– 11月29日第20回事例から探求する改善への一歩豊田氏

• オブジェクト倶楽部夏イベント
– 7月16日スクラムワークショップ今村哲也、川口恭伸、林栄一

14

– 1月28日第21回ほいほいモチベーションアップ！林栄一(東京都)
– 2月18日∼19日デベロッパーサミットブース出展
– 2月21日第22回ここから始めるImpediment探求 zuisener氏(東京都)
– 5月27日第23回ゲームで学ぶスクラムの概要海江田氏(東京都)
– 6月25日勉強会カンファレンスブース出典、パネル出演
– 第２４回ファシリテーション入門だ！（林栄一）
– 第２５回プロダクトオーナー探求（ユッカ氏）
– 第２６回みんなで朝会をより良くしよう！(スタッフ一同)
– 第２７回タスクカンバンはこれだ！ (スタッフ一同)
– 第２８回振り返り探求（スタッフ有志）
– 第２９回プロジェクト逆計画ゲーム（安井力氏）
– 第３０回 Head First インセプションデッキ（西村直人氏）

15

すくすくスクラム大阪 2010 年
6 月 16 日第１回 ∼スクラム基礎理論∼ 林栄一 (大阪府)

すくすくスクラム瀬戸内 2010 年
2 月 5 日第１回ソフトウェア開発の３つの嘘
江端一将氏、今村氏、林栄一、
エマーソンミルズ氏
4 月 24 日第２回身体でおぼえるスクラム
エマーソンミルズ氏
12月25日第3回振り返りワークショップ(年末振り返り特別版)
林栄一
すくすくスクラム瀬戸内 2011 年
4月15日 Agile Japan 2011 岡山サテライト安井力氏他
すくすくスクラム仙台 2011 年
ファシリテーション超入門 7/27 江端氏
みんなで朝会をより良くしよう！ 10/7

16

勉強会？
みんなが集う場所

お互いを知りあう

知識を共有

心得

全員が価値を得られるようお互いをサポート

新しい知見やアイディアを創りだすこと

参加者が現場に帰って行動する勇気を得ること

グループワーク
ココに
模造紙書く

参加の目的

他のメンバーの人
は、共感できることが
あったらその横に★印
を書いてください

事前準備どうやって現場
でやっている?

・業務運用管理，利用部門支援，システム運用，運用管理，システム保守の方法を確認。
ステム運用・保守 OM ・トラブル・Q/A対応，ネットワーク，ハードウェア，ソフトウェア，アプリケーショ
の変更管理を実施し，改善計画を立案。
富士通のSDEM
運用・
保守
企画プロセス開発プロセスプロセス
工程情報化システムシステムユーザインタシステムプログラムプログラプログラ結合システム運用システム
構想立案企画方式設計フェース設計構造設計構造設計ミングムテストテストテストテスト運用・
保守
カテゴリＶＰＳＰＳＡＵＩＳＳＰＳＰＧＰＴＩ
ＴＳＴＯＴＯＭ

企業企業

業務
業務業務利用者による妥当性確認業務

設計者による検証
業務システムシステム

システム
・
・開発者による検証
・プロセスプロセス

分解の過程プログラム統合の過程
（設計）（
テスト）
モジュール

図-2 品質保証のV字モデル
Fig.2-V model for quality assurance.

表-1 工程の定義
情報化構想立案 VP ・情報化戦略を策定し，実行の優先順位を決め，中長期計画を策定。
企画
システム企画 SP ・業務システムの現状分析と要件定義を行い，投資効果を評価し，開発の意思決定。
・システム化に対する要件を確認し，業務分析によりシステム化の範囲を確定。
システム方式設計 SA ・システム方式設計と実現性の検討を行い，プロジェクト開発計画を立案し，プロジェクト運営の
ための管理方法を準備。
・業務システム仕様（プロセス機能，データ構造，画面，帳票）を設計。
設ユーザ UI ・システム方式設計の詳細化，および運用・移行方法を設計。
計インタフェース設計
・全体テスト計画を立案。
・プロセスをプログラムに分割し，システムの内部構造を確定し,共通プログラムを設計。
システム構造設計 SS ・運用管理システム，セキュリティシステム，移行ツールを設計。
・システムテスト計画，運用テスト計画を立案。
プログラム構造設計 PS ・プログラムの構造を決め，ロジックを定義。
開
発製プログラミング PG ・プログラム構造設計に従ってプログラムを作成し，動作を確認。
造
プログラムテスト PT ・プログラムテスト仕様に従ってテストを実施し，品質を検証。
・プログラムを結合して，プロセス単位のテストを実施し，品質を検証。
結合テスト IT ・外部システムとのインタフェースを含むすべてのプロセス間のインタフェーステストを実施。
・必要に応じて結合レベルや処理形態例（オン/バッチ）でIT工程を分割。
テ・実機上で業務システム機能をテスト。
スシステムテスト ST
ト・性能，信頼性，運用性，セキュリティなど，システム全体の検証を実施。
・実機，実環境，本番データで，利用者による仮運用を実施。
運用テスト OT ・業務システム機能，性能，信頼性，運用性，セキュリティなどの妥当性を確認。
・本稼働への移行の意思決定を行い，業務を移行。
・業務運用管理，利用部門支援，システム運用，運用管理，システム保守の方法を確認。
運用・
システム運用・保守 OM ・トラブル・Q/A対応，ネットワーク，ハードウェア，ソフトウェア，アプリケーション使用など
保守
の変更管理を実施し，改善計画を立案。

運用・
保守

要求開発(OPENTHOLOGY) 要求の４象限

戦略オペレーション

ビジネス
ビジネス
ビジネス戦略
オペレーション
表(価値) 裏(実現)
表(価値)

裏(実現)

システムシステム要求システム設計

表(価値) 裏(実現)

開発プロセスオーバービュー
要求開発(OPENTHOLOGY)
広義の要求開発（要求定義）狭義の要求定義

ＢＤＡ

経営分析要求開発広義のシステム開発
ビジョン、ミッションの
確立
問題点分析準備立案デザイン移行
ビジネスゴール設定
狭義のシステム開発
ビジネスユースケース
システム開発
システム化範囲の導出
財務的解決やマーケ業務フロー（As-Is、To-Be) 方向付け　推敲　　　　　構築　　　　　　移行
ティング的解決で終わロードマップ作成
業務レベルの概念モデル
る課題もあるシステムユースケースの
抽出と個別プロジェクト
へのブレークダウン第１　プロジェクト
方向付け　推敲　　　　　構築　　　　　　移行
ビジネス戦略の見
える化、プロジェク
トスコープとリソー業務要求の獲得
スを確定しゴールとプロセスの見え第２　プロジェクト
を明確化。る化、ITの基本要方向付け　推敲　　　　　構築　　　　　　移行
求の獲得。
狭義のプロジェクト
第３　プロジェクト

広義のプロジェクト

要求開発(OPENTHOLOGY)
モデルの役割(Ver1.0)
観点のビジネス課題ビジネス・オペレーションシステム要求システム設計
流れ

業務プロセスからIT要求へ

プロセスモデルサービスモデル
・業務フロー・システムユース
　ケース
戦略モデルサービスモデル
アーキテクチャモデル
・BSC戦略
・ビジネス
　マップ　・ERD/DB設計
　ユースケース
・IT貢献度
　マップ情報モデル　・アーキテクチャモデル
・プロジェクト
　ゴール記述書 TFP分割手法　・SOAモデル
　・Thing図
　・Function図
　・Place図
ビジネス概念からITアーキテクチャへ

要求開発
フェーズ準備立案デザインシフトシステム開発フェーズ

模造紙
参加の目的

ココに
書く

うまく行かなかったPJ

事前準備どうしておけば
よかった?

ココに
模造紙書く

参加の目的どんな準備しておけばよかっ
た？

プロジェクト準備？

スプリント０とは
リリースバーンダウン

100

75

50

25

0
SP0 SP1 SP2 SP3 SP4

http://www.infoq.com/jp/articles/skills-for-scrum-agile-teams

コーディングを開始し、チームの
作業を統合するために、スプリン
ト０では、開発者に必要な環境構
築に関することはどんな小さなこ
とでもすべて文書化する必要があ
ります。

http://www.infoq.com/jp/news/2008/09/sprint_zero

スプリント０の是非


DanubeのシニアコーチであるDan Rawsthorne氏は
チームを始動させる方法として使っている。

1.プロダクトバックログで項目をいくつか選ぶ。
2.品質を満たすコードの記述を可能にする最低限の環境
を提供する。
3.いかに小さくとも、実コードを記述する。

ただし、できるだけ期間を短く。一週間を推奨。


Mark Woyna氏は、スパイクとしてスプリント０を使用する。

以下を計画に関するスプリント０の成果とする。

1.予測付きのすべての優先度づけされたストーリー

2.ストーリーをスプリントに割り当てるリリース計画

3.高水準アプリケーションアーキテクチャ

機能が実装、変更しやすい方法を選択可能なはず


「スプリント０は、最初のスプリントに
先立って発生する計画を説明するとき
に、誤使用されるフレーズとなった」

Ken Schawber氏
@kawaguti 作


「スプリント０などない！」

Jim Coplien氏

ジェフサザーランドのＣＳＰＯ（研修）での準
備完了の条件
• ステークホルダが明確
• ステークホルダの目標が明確
• ビジネス状況が把握できている
• 成功の基準が明確
Discovery ﬂow

Product Owner

“Re
+ Vision

Discovery Sessions Product Backlog items
~3 days to 3 weeks created Product Backlog
Prioritised and “ready”
Who
the

• 実装戦略ができている
Brings in the Who, why, what
Cross-functional
Team Wha
Estimated by the team Product Owner

`````````````````` 1
2
3 Wha

E S
4

UR
AT
5

FE
You
6
7

Release plan created 8

esti

• ＰＢＬの粒度が適切
9
10
11
12 min
Product
Backlog 93
Q1 Q2 Q3
93

発見の流れ

• ＰＢＬは価値最大、リスク最小で優先づけ
プロダクトオーナー
+ ビジョン

発見セッション
3日間以下∼3週間
プロダクトバックログ項目
の作成完了
プロダクトバックログの優
先度付け完了と準備完了
準
利害
状況
クロスファンクショナルだれが, なぜ, なにを

どう
チームに引き渡す

チームによる見積もりプロダクトオーナー

`````````````````` 1
2 実装
3

E S
4

UR
プロ

AT
5

• ＰＢＬ＝プロダクトバックログ

FE
6

価値
7
リリースプランの作成完了 8
9

いま
10
11
12

プロダクト
バックログ 94
第1四半期第2四半期第3四半期
94

xUNIT TEST Patterns の著者Gerard Meszaros氏
From Concept to Product Backlog

What Do You Need to Get Started
Concept Backlog

Story
User Tests

??? Stories

Iteration
Budget
1 Plan

Tech
Staffing

Business
Staffing

MuchAdo2010 Tutorial 20 Copyright 2008-2010 Gerard Meszaros

From Concept to Product Backlog

What We Needed to Get Started
Concept Backlog
Product Product Project
Envisioning Planning Execution
Risks
Release Story
Major Plan
User Tests
Features
Benefits Stories
Product Iteration
Design Budget
1 Plan
Effort Cost
Product Estimate Estimate Tech
Arch.
Staffing
Skills Business
Test
List Staffing
Strategy

An incomplete set; you may need other things too!
MuchAdo2010 Tutorial 21 Copyright 2008-2010 Gerard Meszaros

Beyond
Sprint
Prioritize possible outcomes, not output
Zero
Product Goals ?51-2"@,//*A,0*B6'")0,7;<4"
(Name desired =15<,6'0C"4,")/*-":21/'"
outcomes) )0,D'<45

User
Constituencies
Targetpeople that will to maximize
(The
solution
outcome, business output
not
use some solution to
meet
goals)
!"#$%&'()
:21/')0,7;<4='512-9<,>
DE*+,-F*<>9,02
Activities &
481+'0G""D'(E*+,-
Tasks !"#$$%"&'(")*+,-."*//"012345"0'5'06'7."8889:21/')0,7;<4='512-9<,> H

(performed by users
using software)
!"#$$%"&'(")*+,-."*//"012345"0'5'06'7."8889:21/')0,7;<4='512-9<,> ?@

!"#$$%"&'(")*+,-."*//"012345"0'5'06'7."8889:21/')0,7;<4='512-9<,> ??

インセプションデッキ

ワークショップ形式でチームとユーザーと一緒に作る

意識付け、動機づけ、チームビルディングができる

隠れた意図を引き出すコミュニケーションツール

コンセプトの共有

方向性を明確にする

プロジェクト憲章(PMBOK)

・顧客やステークホルダからの要求事項
・プロジェクトの目的
・プロジェクトの成果物
・スケジュールの概要
・予算の概要
・主要ステークホルダの関与とその影響
・プロジェクトを遂行する上での前提条件・制約条件

それぞれの位置

目的いつ？誰

インセプション PJ全体像、方向性チームの開発がユーザー、チー
デッキを明確にするスタートする前ム、PO,SM

プロジェクト憲目的を明確にし認 PJが正式開始す
営業、PL
章可してもらうる前

要求を見える化しシステム化プラユーザー、コン
要求開発
開発するンを作るまでサル

アジャイルがうまくいく
のは？

スイートスポット
7 - 15 人 1 か所に所在
専任
社会-技術的システム → 人間とシステムが密に相互
作用するシステム
安定したソフトウェアアーキテクチャ
安全性への要求が低から中
上の人たちとの友好的な環境
新規開発

フィリップ・クルーシュテン博士の「アジャイルは単に廃れつつある流行語なのか ? 」セミナー 2009/12/12

アーキテクチャジャンプ

酷いときは言語がかわったり、実装方針やコン
ポーネント分け方の方針が変わったり、フレームワークが変
わったり


利点

欠点

システムが進化する
規模大きくなってもシンプルさを
利点維持できる
最適なアーキテクチャを探索

欠点

システムが進化する
規模大きくなってもシンプルさを
利点維持できる
最適なアーキテクチャを探索

作り直しのリスク
欠点
一時的に価値を提供できなくなる


許せるレベル、ゆるせないレベルがあるのではないか？

許せる規模、時期、その判断基準は？

ジャンプ発生がなるべくリスクにならないようにベース
アーキテクチャや実装戦略を設計できるか？

シンプルデザインとリファクタリ
• リファクタリングによって機能密度が上
がるアーキテクチャ・ジャンプ
LOC = コード行数
FD = 機能密度
= (functionality/LOC)
FD = 1行あたりの機能量

リファクタリングが
有効に作用している

LOC
時間，機能
2001/3/22 ©2001, Kenji HIRANABE 51

リファクタリングと勇気
• アーキテクチャ・ジャンプには勇気が必
要

局所解コンテキスト

アーキテクチャ・
リファクタリング
ジャンプ
原子のエネルギーエネルギー
準位のようにギャップがある。
一つ上のレベルに行くにはリファクタリングコストがかかる。

2001/3/22 ©2001, Kenji HIRANABE 52

林がSP0として決めたこと

アーキテクチャジャンプのリスクを最小にする
環境の準備を完了する
基本的なトレーニングを完了する
ビジネス価値を提供しないスプリント
大まかにプラクティスを選択しプロセスを設計する
プロジェクトをとりまく状況を、アプリレベルとプロ
ジェクトそのものレベルでモデル化し見えるようにする

メタプロジェクト体制を定義

メタプロジェクト定義

プロジェクト自体の要求分析ツリー

SP0は順番の依存高


スプリント０



スプリント０スプリント1..*


PJ振り返り
スプリント０スプリント1..* ゴール評価


プロジェクトの要求をとりまく状況をモデル化
全員が直感的に把握出来る状態に

プロジェクトの課題を課題分析ツリーで分析

課題解決案リスク

時間割カンバン

ワーク
ショップや勉強会を１日
３コマの時間割で管理

コンテクスト
規模計画ゲーム

深刻度スプリント期間
実リリース頻度
変化率ＤＯＤ
システムの寿命選択バックログ

ビジネスモデル調整ＣＩ
ドキュメントどこまで
アーキテクチャの安定度適合品質
統率訓練デイリースクラム
ロール設計
組織の理解
ＴＤＤ
チームの経験度ペアプロ

オフィス環境見える化モノ

フィリップ・クルーシュテン博士の「アジャイルは単に廃れつつある流行語なのか ? 」セミナー 2009/12/12 から加筆

観点
アーキテクチャジャンプのリスク

ＤＯＤをいつどうやって決めるか

プロセスや役割をどう決めるか

環境やツールの選定や準備

ビジネス価値を提供しないスプリントの是非

チームビルディング

目的、コンセプトの共有

要求の正当性

準備に１ヶ月もら
えるとしたら？

観点
チームビルディング
トレーニング
アーキテクチャ
プラクティス
プロセス
開発環境
等、、、

ココに
模造紙書く

参加の目的どんな準備しておけばよかっ
た？

準備に１ヶ月もらえるとした
プロジェクト準備？
ら？

結論的ななにか

どんなに良くできた手法も、誤用可能。

悪意的に見ればどんな手法も悪く解釈す
ることが可能。

コンテクストに合わせて、うまく使おう

スクラムプロジェクト準備(公開用) No.31

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie スクラムプロジェクト準備(公開用) No.31

Ähnlich wie スクラムプロジェクト準備(公開用) No.31 (20)

Mehr von Sukusuku Scrum

Mehr von Sukusuku Scrum (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

スクラムプロジェクト準備(公開用) No.31

Hinweis der Redaktion