Osaka-No001-01-suc3rum-20100616

大阪すくすく・スクラム
第１回ワークショップ
セントラルソフト株式会社公開用資料

事業推進部林栄一
すくすく・スクラムスタッフ
名付け親

2010年6月22日火曜日

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


自己紹介


自己紹介
楽器メーカーで開発業務 4年半ほど

陶磁器の卸父の会社を継ぐ 2年ぐらい

JR関係の研究開発 2年ぐらい

シンセサイザーオペレータ１年ほど

ネットワーク保守業務１年ほど

現職ただいま12年目


やってきたもの（開発）


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

現在
セントラルソフト株式会社事業推進部課長
★ワンポイント・ストレスケア！（ミニセミナー５分）
ストレスと疲労の違いって？ストレスの発散法？などストレスケアの方法や

すくすく・スクラムスタッフ（月１で勉強会）
ドラムサークル α プラス
理学などを知って、仕事や生活をエンジョイしましょう。心の専門家の秘伝
目からうろこの実践ポイントを伝授します！シリーズ化決定！

参加者が輪になってパーカッションのアンサンブルを即興的に作り上げます。打楽器などの経験は全く必要ありません。誰でも安心し
て楽しめるようにファシリテーターがガイドいたします。一体感を感じながら共に楽しみ、打ち解けることができます。そして心の扉を開

DCFA認定ドラムサークルファシリテーター
き、コミュニケーションを促進していくことに喜びを感じます。
●こんな人集まれ！
運動不足の方、ストレスがた
ご案内まっている方、音楽が好きな
方、仕事で嫌なことがあった方

NLP認定プラクティショナー
リング効果、仲間づくりによ
≪新宿≫ る一体感、孤独感の解消、リ
ラックス効果、運動不足解消、
●日時：２０１０年１月３１日日曜日抗うつ対策、肩こり軽減・改善
などの効果が期待できます。
１６：１５開場１６：３０スタート１８：００終了

認定スクラムマスター ●場所：スタジオノード新宿店5F 東京都新宿区西新宿7-16-7
http://www.studio-node.com/
西武新宿線西武新宿:220m 都営大江戸線新宿西口:380m JR 総武線大久保:480m

●定員：２５名様限定！※定員になり次第締め切らせていただきます。申込順（基本、メールにてお申し込みください）

要求開発アライアンスコアメンバー
●参加費 : ３，０００円/人２回目以降参加者２，５００円/人 ※当日集金

♪ストレスケア・ドラムサークルのファシリテーター紹介♪・・・その② 申込・お問い合わせ

尾崎 !"#"$$元章 %&'($)*$+,--&..

BOSサポートメンバー(トレーニングビート)
ファシリテーター
トレーニング・ビートメイントレーナー
%&'($)*$+,--&..
!"#"$"%ドラムスクール主宰。多くのドラマーを育てるとともに、ド
ラムサークルの普及にも努め、神奈川の地域誌にも紹介される。現 &''()**+++",-./"-01
在までに小中学校・相模原市大田区・目黒区・世田谷美術館・神奈
川県立藤野芸術の家等のイベントでもドラムサークルを行う。【基本はメールにてお申込くださ

教育とか開発とかスクラムとか、スクラム導入コーチ
info@bos1.org
TEL：０３‐３５１６‐８４１
〒103-0022 東京都中央区日本橋
1-6-13 井上第二ビル6Ｆ

とかもろもろやってます。

トロントAGILE 2008 EM ZERO VOL.2

XP祭り 2008 XP祭り 2009
Thanks
チームの皆へ
送り出してくれた人達へ
今日聞いてくれた人達へ

(撮影KKD)

要求開発アライアンス DEVLOVE 2008
TFPモデリングスペキュレーション 2007年人とのつながりの奇跡に感謝(LT)
要求開発マスター認定制度への提案 2008年

オブラブすくすく・スクラム
スクラム基礎＋朝会ワークショップ
ドラムサークルとプロジェクトファシリテーション(2007/06LT)
自己組織化ワークショップ
短期に低価格で持ち家建設を行うためのパターンランゲージ
ウォーターフォールとアジャイル
(2009/01 LT)


もくじ

なぜ？すくすくスクラム

スクラム基礎理論

朝会ワークショップ


EM ZERO VOL2


EM ZERO VOL2
新しい手法を試し、検証し、適用する姿勢
はとても大切ですが、それを一発で解決す
る「銀の弾丸」と思うのは望ましくありま
せん。
いつでも一番大切なのは、今目の前にいる
チームメンバーと何をするのかということ
だと思うのです。

特定のやりかたが
どんな場合でも
うまくいくとは
かぎりません。

自分の頭で考えよう！


同じプロジェクトは
一生に１回だけ
何をどう使うか！
どうやって
適応させるか！

そのためには、
なぜそうなのかを
「理解」
することが重要。

それが！

すくすく
スクラム

ツールとスキル

2009 XP祭り LT資料より林栄一

ツール？

スパナ


ねじまわし


方法論


指向


駆動開発


工学


How To


すべて広義の
ツールの一種


どんなに良い道具でも
体で理解しないと
得られない領域がある。
おな
じくらい
大事

ツールスキル技


だから！

グループワーク１
プロジェクトの課題、悩み
模造紙
プロジェクトの課題、悩み
ココに書く


第１部スクラム基礎


スクラム

スクラムとは
 アジャイルプロセスの一つ
 日本の製造業の製品開発手法をソフトウエア開発に応用した方
法論
 竹内弘高・野中郁次郎 The New New Product
Development Game 1988
 Jeﬀ Sutherland と Ken Schwaber がOOPSLA 1995 に
て発表

 プロジェクトをチームで進めるためのシンプルなマネジメント
フレームワーク

 ビジネスの変化、今ある状況に対応する


http://www.versionone.com/pdf/2009_State_of_Agile_Development_Survey_Results.pdf
VersionOne2009 資料


スクラムの基礎となる
価値


価値
•自己組織化、自発的決定


価値
•予測型実測駆動


価値
•そのときどきの状況にあわせて計画し
つづける


価値
•そのときどきの状況にあわせて計画し
つづける
•問題の原因はプロセスや技術ではなく人
間に依存する


スクラムの３つの柱


•透明性


•透明性
•プロセスを見える化


•透明性
•一定していて明確な完了の定義


•透明性
•検査


•透明性
•検査
•頻繁に検査


•透明性
•検査
•頻繁に検査
•うけいれ難い変化をすぐに検知


•透明性
•検査
•頻繁に検査
•適応


•透明性
•検査
•頻繁に検査
•適応
•プロセスをすぐに調整

スクラムの
プロセス概要
実測駆動管理ー今ある正直な状況から次！
ROIからみた優先順位で小出しリリース
振り返りと調整、改善の繰り返し
２∼４週間ごとの納品
管理しない管理、自発性、チーム主体
チームの責任と権限

スクラムのプロセス


皿に取っスクラムの流れを大まかに示すと図1 いつでも納品可能な状態を維持する
理がない
、つい和
スクラムのプロセス
■図1 スクラムの流れ
のお皿を
※認定スクラムマスター
のテキストを元に筆者が
作成。デイリー
手法を適スクラム
（24時間ごと）
います。
しい手法
紹介され
スプリント
スプリントバックログ
のお皿に（4週間）
スプリントの
ようとし終わりに
新しい機能を
。デモ
選択された
ラクティプロダクトバックログ

カスタマ
。いわゆ
です。ほ
同じ難しプロダクト
バックログ
を組むこ
しかない
対処して

EM ZERO Vol.2 より引用

スクラムのロール

ユーザープロダクト
オーナー

スクラム
開発チーム
マスター


スクラムのロール

• スクラムマスター
スクラム推進のキーパーソン
• プロダクトオーナー
成果物の責任者
• スクラムチーム
開発を行う主役


スクラムマスター
 プロジェクト管理者ではい
− チームによる自己管理
− 内部調整
− 他の人や他のチームとの調整
 権限無い⇒チームが決める
 指示型⇒促進型
 組織変革の主役


プロダクトオーナー

•スプリントごとに機能と優先順位を変える権限
を持つ

•完成イメージと方向性を把握している
•プロダクトの収益性に関する（ROI)責任者
•リリースの内容と日付を決める


ミーティングフロー
スプリントプランニング

デイリースクラム
（朝会）

スプリントレビュー

スプリントレトロスペクティブ
（反省会）


プロダクトバックログ
高いバックログ項目

バックログ項目

優
先
順
位バックログ項目



低い
...

高いバックログ項目


優
先
順



プロダクト低い
オーナーが決
める ...

スプリントプラ
高いバックログ項目ンニングミーティン
グで、チームが項目
ごとの「規模」を見
優積もって、そのスプ
先リントの範囲を決め
バックログ項目る
順



プロダクト低い
オーナーが決
める ...

スプリントプラ
高いバックログ項目ンニングミーティン
グで、チームが項目
ごとの「規模」を見
優積もって、そのスプ
先リントの範囲を決め
バックログ項目る
順

アジャイルよく使わ
バックログ項目れる見積もり手法：
バックログ項目・相対規模見積もり
プロダクト低い・プランニングポーカー
オーナーが決
める ... ・理想時間見積もり



「スクラム入門」川口泰伸より引用


• 機能、問題点の一覧表

• プロダクトオーナーが優先順位を決める

• だれでも追加できる

• 常時更新され、目に入るところに提示

• ビジネスプランまたは事業方向性をもとに
作られる










...

タスク
タスク
タスク

バックログ項目タスク


タスク

... タスク


TODO DOING DONE

タスク

タスク

タスク

タスク

タスク

タスク

タスク

タスク

タスク

タスク


kkd さんの資料より

プロダクトバック
ログ項目

タスク
その時点の残


バーンダウンチャート
スプリントバーンダウン

3 4

バーンダウンチャート毎日その時点の残（※規模）を
合計してプロットする。
スプリントバーンダウン全体の割合の変化ではなくて、
その時点時点の残工数を見る点
が実測駆動。
タスクの残ではなくタスクの完
了でプロット
完了の定義重要。

3 4

バーンダウンチャート毎日その時点の残（※規模）を
合計してプロットする。
スプリントバーンダウン全体の割合の変化ではなくて、
その時点時点の残工数を見る点
が実測駆動。
タスクの残ではなくタスクの完
了でプロット
完了の定義重要。

※規模
・規模を抽象化した「ポイン
ト」の合計をプロットする。
具象時間、工数でプロットしな
い方がよい。
3 4

デイリースクラム（朝会）
毎日の１５分だけの状況報告ミーティング

• 同じ場所、同じ時間
• ３つの質問
‒ 前回からなにをしたか
‒ 次回まで何をするか
‒ 課題になっていること



•ユーザーにスプリントで作ったものをデモする
• 開発者とユーザーが直接話しをする


スプリント
レトロスペクティブ

• スプリントが終わる度によりよいプロセスへ
• スクラムマスターがファシリテートする
• 良い点と改良できる点を洗い出す


ミーティングフロー
スプリントプランニング

デイリースクラム
（朝会）
TODO DOING DONE


スプリントレトロスペクティブ
（反省会）
アプリケーション


プランニングオニオン
必要な期間を必要な精度で計画し続ける。

フューチャーの
セットを1 2週間単
位で計画

2∼3時間
精度のタスクを１
日の初めに計画
EM ZERO Vol3.1より引用


目的

目的

目標


目的

目的 ∼のために

目標


目的

目的 ∼のために

目標 ∼までにこの目標を達成する


要求の基本
戦略オペレーション

ビ
ジ
ネ
ス

シ
ス
テ
ム
要求開発資料より

要求の基本

ビ
ジビジネス戦略
ネ
ス

シ
ス
テ
ム

要求の基本

ビ
ジビジネス戦略ビジネスオペレーション
ネ
ス

シ
ス
テ
ム

要求の基本

ビ
ネ表(価値) What How 裏(実現)
ス

シ
ス
テ
ム

要求の基本

ビ
ス

シ
スシステム要求
テ
ム

要求の基本

ビ
ス What 表(価値)

裏(実現) How
シ
スシステム要求
テ
ム

要求の基本

ビ

裏(実現) How
シ
スシステム要求システム設計
テ
ム

要求の基本

ビ

裏(実現) How
シ
スシステム要求システム設計
テ
ム表(価値) What How 裏(実現)


スクラムでは

ビ

裏(実現) How
シ
ス機能など
タスク
テ（バックログ項目）


チーム


自己組織化


通常の開発体制

PM
長期にわたる
指示報告だれが、何を、いつ
詳細な計画と指示
開発メンバー

プロパー協力会社

メンバー間のコミュニケーション


スクラム

スクラムマスタースプリントごとの
タスクカンバン
バックログから
日々タスクを選択
開発チーム


メンバー間のコミュニケーション


スクラム


主な責任部分
ビ
ジ
ネ
ス表(価値) What How 裏(実現)
What 表(価値)

シ裏(実現) How

ス
テ


主な責任部分
ビ
ジ
ネ経営層業務担当

What 表(価値)

シ裏(実現) How

ス
テ
プロダクトオーナー開発チーム


主な責任部分
戦略オペレーション POの
調整範囲
ビ
ジ

What 表(価値)

シ裏(実現) How

ス
テ


主な責任部分
調整範囲
ビ
ジ

What 表(価値)

シ裏(実現) How

ス
テＳＭの
ム表(価値) What
調整範囲
How 裏(実現)


顧客潜在主な責任部分
ニーズ
表(価値) What
調整範囲
ビ
ジ How 裏(実現)


What 表(価値)

シ裏(実現) How
イノベーション

ス
テＳＭの
ム表(価値) What
調整範囲
How 裏(実現)


オブラブ2010アレグザンダー祭りの懇親会でスクラム
トレーナーのジム・コプリンエン氏から聞いた言葉

それだけ、組織にインパクト
がある変革が必要な場合があ
るという意味です。
真に受けてやりすぎないよう
に！w


権限


権限の逆転？

• スクラムでは、チームに権限があってス
クラムマスターにはない。

• これって通常組織で可能なの？
ここらへんからは私個人の私
見です。
みなさんの状況であうかどう
かは各自でご判断を。


通常の開発体制
権限
組織の指示、発注
PM(課長)
上下関係

契約関係

開発メンバー



スクラム
権限なし

スクラムマスタ(課長)

スクラムチーム

権限あり


スクラム
権限なし

組織のスクラムマスタ(課長)
上下関係

契約関係


権限あり


たとえスクラムスクラム
でもこの関係は変
えられない
権限なし

組織のスクラムマスタ(課長)
上下関係

契約関係


権限あり


こういうこと？
権限なし

スクラムマスタ(平社員、契約社員)
組織の
上下関係契約関係


権限あり
部長課長社長次長


矛盾


スクラム
権限なし
（本当はある）


権限あり
（本当はない）


スクラム
権限なし

指示


権限あり


スクラム
権限なし
質問、
指示
促し

権限あり


スクラム
権限なし
質問、回答、
指示
促し提案

権限あり


あれ？

これってうまく
いってる普通の
組織じゃんただし、このよう
に、うまく行ってい
る組織はあまり多く
ないのが現状？

スクラムは組織マ
現実のスクラム
ネージメントがうま
くいくための矯正ギ権限なし
ブスとして機能する
かも。
チームに対する
スクラムマスタ(課長) 責任があることには
質問、促し、変わりない

回答、提案
期待、モチベート
信頼に応える
外部の雑音から守る

権限あり


スクラムに
親和性のあるスキル

• ファシリテーション
• コーチングスクラム認定セミナーでも
ファシリテーションについ
て触れられている

• グループコーチング
• アサーション

「リーン開発の本質」監訳者、平鍋氏の後書き

多くの間違った標準化が、
「人は本来怠け者でありしっかり働か
せるために規則をつくらなければなら
ない」とか

「人は交換可能である」というメンタ
リティーから発している。



もし、組織の文化や方針の中心にこの
ような考え方があると、

もしくは多くの管理者がこのように考
えている組織では、

リーン活動は決して成功しない。



そうではなく、「人の持つ工夫のモチ
ベーションを活かす」こと、
「一人ひとりの人を育てる」ことこそ、
マネジメントの中心となるべきだ。

「人」の要素はプロセスの中心である。


なぜアジャイルか


なぜアジャイル
じゃないのか


「アジャイルプロセスで開発しやすい契約書」アジャイルプロセス協議会、契約と見積ＷＧより

3.ソフトウェア開発環境の変化
３０年以上前の「ソフトウェア開発環境」（某ＩＴ企業）

Copyright © 2010, Agile Process Association, All rights reserved. 85


開発事務所



開発事務所

開発計算センタ



開発事務所


ﾊﾟﾝﾁｶｰﾄﾞ



開発事務所


ﾊﾟﾝﾁｶｰﾄﾞﾊﾟﾝﾁｶｰﾄﾞ



開発事務所
おかしいなぁ





開発事務所
わかった！





開発事務所
わかった！

デバッグ完了！






グーッ！
開発事務所
わかった！







グーッ！
開発事務所
わかった！



データ処理ﾊﾟﾝﾁｶｰﾄﾞ

の主体




グーッ！
開発事務所
わかった！


１日単位での作業周期開発計算センタ

データ処理ﾊﾟﾝﾁｶｰﾄﾞ

の主体



３０年以上前の「ソフトウェア開発環境」での１日（某ＩＴ企業）

始業時刻↓ ↓終業時刻
就業時間帯




就業時間帯
就業時間帯




就業時間帯
就業時間帯

開発作業




就業時間帯
就業時間帯
計算センタに依頼↓ ↓依頼結果の受取
開発作業




就業時間帯
就業時間帯
開発作業開発作業




就業時間帯
就業時間帯
開発作業待ち時間開発作業




就業時間帯
就業時間帯

ﾃﾞﾊﾞｯｸﾞ(ｺﾝﾊﾟｲﾙﾘｽﾄ上)
ｺｰﾃﾞｨﾝｸﾞ(ｶｰﾄﾞﾊﾟﾝﾁ)
先輩に質問
後輩の指導
仕様書の修正
息抜き




就業時間帯
就業時間帯

ｺｰﾃﾞｨﾝｸﾞ(ｶｰﾄﾞﾊﾟﾝﾁ)
先輩に質問ペアプロで、
後輩の指導やられていること
仕様書の修正が意外と多い
息抜き




就業時間帯
就業時間帯

時間との戦い ｺｰﾃﾞｨﾝｸﾞ(ｶｰﾄﾞﾊﾟﾝﾁ)
先輩に質問ペアプロで、
後輩の指導やられていること
仕様書の修正が意外と多い
息抜き



「ソフトウェア開発環境」の変遷（某ＩＴ企業）

開発ﾘｿｰｽの開発作業の
時期開発の進め方
価格サイクル

非常に高価１コンパイル計算センタでの実行結果
３０年以上前待ちの間に、いろいろな
(大型計算機使用) ／１日作業実施

同上
かなり高価１コンパイル
３０年前（確認待ち時間は、「時
(ﾜｰｸｽﾃｰｼｮﾝ使用) ／１∼２時間間単位」に短縮された）

安価１コンパイル即座に実行結果を確認
現在
(ﾊﾟｿｺﾝ使用) ／数分可能になった




1日にやり直せる回数
開発設備の価格

1970年 1980年 1990年 2000年 2010年




1日にやり直せる回数
開発設備の価格

結果の確認に結果の確認に
１日必要数分必要
（１回/日） (数100回/日)

1970年 1980年 1990年 2000年 2010年



３０年くらい前の「開発対象物件」（回顧）



業務の電算化が盛んに行われていた（と思う）




【業務の電算化の進め方】




現状の業務手続の記載（明記）




記載（明記）された業務手続を実装




すべての業務手続を実装完了




実装完了したソフトウェアのテスト




テスト完了




テスト完了
ソフトウェアの納品





開発途中での
仕様変更なし
テスト完了





開発途中での
仕様変更なし

開発可能
ＷＦ型で
テスト完了



３０年以上前の契約における手続きのながれ
ユーザベンダ
契約前



ユーザベンダ
業務の電算化をし
たいんだけど
契約前



ユーザベンダ
業務の電算化をし電算化できるのは
たいんだけど ○○○業務ですね
契約前



ユーザベンダ
契約前

どのくらいで電算化
できるのかなぁ



ユーザベンダ
契約前

どのくらいで電算化 ○○○円で
できるのかなぁできますよ



ユーザベンダ
契約前


契約締
結合意合意



ユーザベンダ
契約前


契約締
結合意合意
契約締結後

システム設計書、
ソフトウェアなど



ユーザベンダ
契約前


契約締
結合意合意
契約締結後

承認（検収）ソフトウェアなど



ユーザベンダ

（逆戻りの必要なし）

時間の流れ
契約前


契約締
結合意合意
契約締結後




ユーザベンダ
契約前

要求仕様、要求開発
などの概念が、
契約締
結合意合意

存在しない取引
契約締結後




「ソフトウェア開発環境」と「契約」での変遷の比較

開発環境の変化
時期開発ﾘｿｰｽの開発作業の契約での変化
価格サイクル

非常に高価１コンパイル
３０年以上前
(大型計算機使用) ／１日

かなり高価１コンパイル
３０年前請負契約書ベース
(ﾜｰｸｽﾃｰｼｮﾝ使用) ／１∼２時間

安価１コンパイル
現在
(ﾊﾟｿｺﾝ使用) ／数秒


産業の歴史
• 産業革命 1760-1830
• 豊田織機製作所 1867
• トヨタ自動車 1937
• 第２位時世界大戦 1939-1945
• 商用汎用機 1950
• トヨタ生産方式-カイゼン 1950

ソフトウエアの歴史

• 商用汎用機 1950
• ソフトウエア工学 1968
• ウォーターフォール 1970
• Machintosh 1984
• Windows95 1995

アジャイルの歴史
• トヨタ生産方式ーカイゼン 1950

• 建築のデザインパターン 197*

• Machintosh 1984

• 野中,竹内論文(The new new development game) 1986

• スクラム 1993

• 組織・プロセスパターン Jams coplien1994

• Windows95 1995

• GoF デザインパターン 1995

• XP Kent Beck 1999

• アジャイルアライアンス 2001

開発と製造
開発製造
レシピを作る料理を作る
実践利用に要求に
適しているか？合っているか？

バリエーションOK バリエーションNG

反復は価値を生む反復はムダを生む
「リーンソフトウェア開発」メタボリックス山田正樹より引用
http://www.metabolics.co.jp/SoftwareProcess/SRC040903/LSD02.pdf


歴史整理
現在(2010)
産業(1760)
産業革命(1837) ・1950 ・1960 ・1970 ・1980 ・1990 ・2000
デザインパターンアレグザンダー(1970代)

日本の製造業の台頭

カイゼン、JIT トヨタ(1950) PC-10 Canon(1982)
City ホンダ(1981)
ワイガヤホンダ(1946)
野中、竹中論文(1986) 「開発」としての
SCRUM (1995) ソフトウェア
第２次
世界大
デザインパターンGof (1995)
戦組織パターン coplien(1994)
(1939-
1945) Plop (1993) XP (1999)

リーンソフトウェア開発
商用汎用機 UNIVAC(1950) リーン MIT(1980代) Poppendieck(2003)

オブジェクト指向(1972) Agile Aglience (2001)
ソフトウェア産業 Java 1.0 (1995)

ソフトウェア工学(1968)
ビジネス変化のスピード拡大
ウォーターフォール(W.W.ロイス1970)
新規技術の増大
工場ラインの製造としてのソフトウェア複雑化
コンパイル時間目安
数週∼数日に１回 1日に数回 1日に数百∼数千回

eiichi hayashi (cc)

Agileの価値観
私たちは，

プロセスとツールよりも ……… 個人と対話に
包括的なドキュメントよりも ……… 動くソフトウェアに
契約交渉よりも ……… 顧客との協調に
計画に沿うことよりも ……… 変化に対応することに

価値をおく．

アジャイル宣言(http://agilemanifesto.org/iso/ja/)
原則(http://agilemanifesto.org/iso/ja/principle.html)


第２部朝会ワーク


朝会 (デイリースクラム)‫‏‬



毎日の１５分だけの状況報告ミーティング

•
毎回同じ場所、同じ時間

•
３つの質問
‒
昨日はなにをしたか
‒
今日は何をするか
‒
そのタスクの障害になることはなにか


目的

１．チーム全体が，必要な情報を短い時間で共有すること。

２．昨日やったことを振り返り，今日やることを各自が
認識しコミットすること。

３．朝，気持ちよく仕事のスタートを切ること。



グランドルール
他人を非難しない
悪いニュースは良いニュース
部外者に発言権はない（鶏と豚）
その場で解決しない
（その場で解決したほうがいいか判断すること）


朝会のポイント

司会者に報告するのではなく、全員に報告する。
司会者は微妙にアイコンタクトをはずす。

硬さとやわらかさのバランス。
適度なアイスブレークを。

ルール違反はその場で軽く指摘。

正直に話せる雰囲気

自己組織的


クリエイティビティースコア

• 幼稚園児
• 小学生
• 中・高校生
• 大学生
• 大人

トニーブザン講演より


• 幼稚園児 95%
• 小学生 75%
• 中・高校生 50%
• 大学生 25%
• 大人 10%以下



• 幼稚園児 95%
• 小学生 75%
• 中・高校生 50%
• 大学生 25%
• 大人 10%以下

これは「普通」のことだけど、
「自然」なことではない


グループワーク

朝会をやってみよう


普通の朝会

• ３つの質問を順番に
• 前回からやったことは？
• 今日やることはなんですか？
• 問題になっていることはありますか？


だめだめな朝会
• みなさんの課題や問題になっていることを
朝会でやってみよう

•例
• やる気が無い人
• 報告がながい
• 険悪モード（仲悪い人がいる）

すごい朝会

理想の朝会をやってみよう



気付いたこと


模造紙
課題

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


ご参考。

グループコーチング

「グループ・コーチング入門」本間正人 (著) より一部引用

• 他の部下に同時に意識を向ける
• メンバーに目配りする
• うなづく
• 一人だけではなく周辺の人の動きを目の端で同
時に感じる

• 場の空気をよむ
• 自分への報告ではなく、全体への報告になるよ
うに促す

• 承認メッセージ重要
• 相手の可能性を引き出すことができる
• 相手の名前をちゃんと呼ぶ
• 「∼さん、どうですか。」
• 意見が尊重されている体験が重要


• コーチングのGROWモデル
• GOALS 目標の明確化
• REALITY 現状の把握
• RESOURCE 資源の発見
• OPTIONS 選択枝の創造
• WILL 意志の確認、計画の策定

• コーチングのGROWモデル朝会
ではココまで

• GOALS 目標の明確化
• REALITY 現状の把握
• RESOURCE 資源の発見

• OPTIONS 選択枝の創造

• WILL 意志の確認、計画の策定

質問のテクニック
• 課題に関する思いや観点を持っていそうな人から聞く
• 状況により指名型と公募型を使いわける
「∼さんどう？」と「意見ある人いる？」
• 問いかけ方で行動の変化を促す
楽しかった？ → どこが面白かった？
寂しいですか → どんな楽しいことがありました？
• なぜの扱いに注意！
対象を物にする「何がそうさせるのですか？」


質問のテクニック

これらを状況によってくみあわせる
• 自由回答で意見をもとめる質問
• 自由回答で事実をもとめる質問
• ＹＥＳ，ＮＯで答えられる質問
• 選択枝を選ばせる質問


質問のリズム

広げて情報を収集→
閉じて明確化→
広げて対策の可能性を広げる→
閉じて対策を具体化

広閉広閉
...

グループのモード
• 停滞モード
• 険悪モード
• 独走モード
• 孤立モード
• 沸騰モード
• 迷走モード
• 苦悩モード

• 停滞モード
答えやすい質問にきりかえる。指名型。具体的な質問。
• 険悪モード
休憩必要。他の人の意見も聞いてみようとふる。
• 独走モード
本人にまとめさせる。「そうかなるほど、Ｂさんにも聞いてみよう」
• 孤立モード
発言しなさいの叱咤は厳禁。
成果がないメンバーには成果ではなくプロセスを褒める。
「工夫があるねとか、頑張ってるね。」
• 沸騰モード
今の中ですぐに実行できるものについて考えてみよう
• 迷走モード
目的を再度提示。「目的は∼だったね、ここに立ち返ってみよう。」
• 苦悩モード
困ったと一緒に言う。共感、連帯をつくる。
もう一度整理してみよう。時系列での整理。


課題の対策を考えてみよう


５５５(Triple Nicels)
カー
ドの上部に各自、
自分の組織の課題を
Ａ６情報カード
１つ書いてくださ
い

アジャイルレトロスペクティブズ強いチームを育てる「ふりかえり」の手引き
Esther Derby (著), Diana Larsen (著), 角征典 (翻訳)

Osaka-No001-01-suc3rum-20100616

Osaka-No001-01-suc3rum-20100616

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a Osaka-No001-01-suc3rum-20100616

Semelhante a Osaka-No001-01-suc3rum-20100616 (20)

Mais de Sukusuku Scrum

Mais de Sukusuku Scrum (20)

Último

Último (9)

Osaka-No001-01-suc3rum-20100616