57
ふりかえりの基礎はこれだ! 年末特別版! 2014/12/19 開場:ネットイヤーグループ (公開版、口頭コメント追加、ワーク部分削除) すくすく・スクラム すたっふ セントラルソフト株式会社 事業推進部 林栄一 第49回 すくすく・スクラム 勉強会

No49 振り返りの基礎はこれだ!年末特別版 suc3rum-20141219

Embed Size (px)

Citation preview

ふりかえりの基礎はこれだ! 年末特別版! 2014/12/19 開場:ネットイヤーグループ

(公開版、口頭コメント追加、ワーク部分削除)

すくすく・スクラム すたっふ セントラルソフト株式会社 事業推進部 林栄一

第49回 すくすく・スクラム 勉強会

自己紹介

•楽器メーカーで開発業務 5年

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

•鉄道関係の研究開発 2年

•シンセサイザーオペレータ 1年

•ネットワーク保守業務 1年

•現職 ただいま19年目

はじめに

EM ZERO VOL2

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

EM ZERO VOL2

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

自分の頭で考えよう!

同じプロジェクトは 一生に1回だけ 何をどう使うか! どうやって

適応させるか!

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

「なぜ」が見えたら たとえアジャイルな現場じゃなくても 「よくする」の役に

たつはず。

ここにいる みんなで

知恵をだしあって 共有しよう!

それが!

すくすく スクラム

今日やること

ふりかえりとは

わーく

ふりかえり

振り返りのすべてではなく、私が実際にやってみてうまくいったこと、ポイント、思いを中心にお話します。 みなさんの気付きや発見もみんなで共有しましょう!

このワークのきっかけは、すくすく・スクラム スタッフ振り返りでの「振り返り」です。

これをすくすくそのものでやろうと!笑

ふりかえりとは

なんだっけ?

スプリントプランニング

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

スプリントレビュー

スプリントレトロスペクティブ(反省会)

ミーティングフロー

スプリントプランニング

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

スプリントレビュー

スプリントレトロスペクティブ(反省会)

繰り返しの最後に行う、打ち合わせ PDCAのCとA

ふりかえりの目的?

ふりかえりの目的

チーム全体が、行動可能な改善策を探し、試す勇気を得ること

チーム全体が、これまでの行動を思い返し、  新たな気づきを得ること

チーム全体が、やってみてうまくいった行動を、チームに定着させること

チーム全体が、メンバーの多様性を受け入れ、信頼関係をきづくこと

「プロジェクトファシリテーション実践編 ふりかえりガイド」より (株)永和システムマネジメント オブジェクト倶楽部 天野勝

ふりかえりの目的

勇気

気づき

定着

信頼関係

「ふりかえり」の目的は「ふりかえる」ことでは

ない!

未来を作ることだ!

ふりかえりのやりかた

KPT

K:つづけたいこと P:問題 T:ためしたいこと

ふりかえりの構成

ふりかえりの構成

始める

まんなか

終了する

ふりかえりの構成

場を設定する

データを収集する

アイディアをだす

何をすべきかを決定する

ふりかえりを終了する

ふりかえりのおとしあな

ふりかえりのおとしあな

マンネリになる

対処する問題が把握できない

アイディアがでない

根本的なカイゼンのアクションがでない

ふりかえりの構成

場を設定する

データを収集する

アイディアをだす

何をすべきかを決定する

ふりかえりを終了する

問題はココにありあます!

問題のコンポン

起こった事象が把握できていない。

起こった事象をうまく評価できない。

目的の力

目的の光

プロジェクトの目的=ミッションが鮮明であるほど、影のように課題が鮮明に浮き彫りになる。

目的の光

事象

評価

課題

目的がちがえば課題も違う

目的1の光

事象

評価

課題

目的2の光

評価

課題

目的がちがえば課題も違う

品質

事象

評価

評価

速度

不良率

課題はどこ?

プロジェクトの範囲

わかっている課題

解決している課題

組織の範囲

ココをあぶり出す

こっちはより上級

わかってる課題は意外にすぐ枯渇する

課題はどこ?

プロジェクトの範囲

わかっている課題

解決している課題

組織の範囲

PJの目的

事象

評価

課題

組織のミッション

課題

評価

アクションへ

課題

原因

アイディア

アクション

修正プロセス

アクションからカイゼンへ目的の光

事象

カイゼン

アクション

目的の共有

目的の共有

与えられる目的

創作する目的

チームで探求する

どうしたいか

どうあるべきか

起こったことの把握

おこったことの把握

あらゆるビューでみる

プロダクトの成果

ベロシティー

レビュー結果

時間軸、イベント

事実、感情

その回で起こったことや、やったことためしたこと、思いが、メンバーの頭のなかにありありと想起できるようにする。

目的を共有したすぐあとだと、起こった事実の評価→課題が自動的にメンバーの頭のなかに浮かんでくる。(公開資料用メモ)

目的から見て評価

議論の過程を見える化

マインドマップ、ファシグラ

時間軸マップ、BDCに書き込む

よかったことをみんなで讃える

keep → Bravo!

目的からみて、おこったことを評価

課題の種類を見極める。「問題」は原因を、「新しいパワーアップ」は新しいわくわくする工夫を探求。(公開資料用メモ)

目的から見て評価

議論の過程を見える化

マインドマップ、ファシグラ

時間軸マップ、BDCに書き込む

よかったことをみんなで讃える

keep → Bravo!

目的からみて、おこったことを評価

課題の種類を判定して見極めること課題を問題としてなのか、次へのパワーアップとしてなのかを見極める。問題と認識していることなら、目的に照らした原因があるはず。

原因が明確になったら 工夫の探求に入れる。次ぎへのトライからなら、次ぎへのアクションはアイディアや工夫を

   引き出すようなファシリテーションをおこなう。問題かトライかで、リーダーの動きは違う。

マインドマップ マインドマップで議論の過程をみえるようにしながら、整理しながらファシります。1回3~4時間の振り返りでこのくらいの大きさのマインドマップになります。

ファシリテーション重要

意見を個人からひきはなす

特定の人だけの会話にならないように

個人を責めない→チームの課題に

問題 対 私たち

話の途中でさえぎらない

ファシリテーション重要

意見を個人からひきはなす

特定の人だけの会話にならないように

個人を責めない→チームの課題に

問題 対 私たち

話の途中でさえぎらない

個人を危険から守る。そうしないと情報がでてこない。 自己組織化、権限委譲と安全 重要。 結果責任を個人に負わせすぎないこと。航空機のコクピット内の権威勾配がきついと、問題の報告が遅れる傾向がでてくる。 プロジェクトでもなんでも言えるよう、問題は個人ではなく私達の問題とかんがえる習慣をチームにトレーニングしていく。

最初から目的の設定を明確にする。目的、ビジョンが明確だと、問題は個人が悪いという観点よりもチームで取り組むべき課題という色彩が強くなる。目的を意識した上での行動は、「試してみる」の土壌 に立ってるので、失敗は悪化ではなくナイストライという解釈がなりたちやすくなる。 例えば「自主性」など一般的な「よいこと」を目的とすると うまくいかない。 リーダーの自分の言葉で、なぜ、その性質が重要なのか を、できれば、体験談をとおした内容で説明することで目的を一般ではなくこの場固有のものの位置づけを強化するほうがよい。個別化した目的は、一般化レベルの目的よりも有効に機能する。

EM ZERO Vol2

  

ブジェクト指向でやろうとしたほうなのですが、実際のプロジェクトへの適用を進めるにつれ、過度のこだわりにも消極的な姿勢にも違和感を抱くようになっていったのです。 このことは、新しい手法を組織に適用するあらゆる場面に当てはまると思います。新しい手法を試し、検証し、適用する姿勢はとても大切ですが、それを一発で解決する「銀の弾丸」と思うのは望ましくありません。いつでも一番大切なのは、今目の前にいるチームメンバーと何をするのかということだと思うのです。

 スクラムマスターセミナーを受講して1つのスプリントを行った結果をもとに、協力会社様対象にプライベートセミナーを行いました。Bas Vodde氏のスクラムマスター認定セミナーで同時通訳をしていたEmerson Mills氏にスクラムのフィロソフィーをレクチャーしていただき、私は適用状況の事例報告を行いました。60名ほどの方々に参加していただき、たくさんのQAやさまざまなフィードバックをいただき

ました。本稿は協力会社の方々からいただいた貴重なフィードバックを参考にして執筆しました。プライベートセミナーに参加していただいた協力会社の皆様には、改めて感謝の意を表したいと思います。また、Agile Conference 2008への参加を後押ししてくれた古賀社長と木村部長、そしてJeff McKenna氏との対談の機会を用意してくださったEM ZERO編集部に感謝します。

プロフィール

セントラルソフト株式会社システム開発課課長林 栄一

■参考文献『スクラム入門ーアジャイルプロジェクトマネジメント』(Ken Schwaber著、株式会社テクノロジックアート訳、日経BPソフトプレス、ISBN-13:978-4891004408)『アジャイルレトロスペクティブズー強いチームを育てる「ふりかえり」の手引き』(Esther Derby、Diana Larsen著、角征典訳、オーム社、ISBN-13: 978-4274066986)『Agile Estimating and Planning』(Mike Cohn著、Prentice Hall PTR、ISBN-13: 978-0131479418)

コラム

Agile Conference 2008でJeff McKenna氏にアドバイスをいただきました

 EM ZERO編集部より、カナダのトロントで行われたAgile Conference 2008会場でスクラム創始者の一人Jeff McKenna氏と話す機会をいただきました。会見は約40分を2回。よく笑うとても楽しいおじさんで、すぐに大好きになりました。Jeff氏には私のスクラムの適用の実績を見てもらい、さまざまな助言をいただきました。

・タイムラインの危険性Jeff氏「ニコニコカレンダーとバーンダウンチャートの突き合わせはあまり感心しないな。誰の責任で生産性が悪くなったという視点にならないように注意したほうがいいぞ。」→インタビューの中で、Jeff氏は一貫して、次にどうするかにフォーカスしたほうがいいということを言っています。

・レビューの注意点Jeff氏「見積もりとの差異をカードに書くのがうまくいっているならいいが、誰が悪いかという視点にならないように気をつけたほうがいいぞ。マイクロマネジメントになっていないか注意したまえ。」→マイクロマネジメントとは、細かく監視して細かい指示を与える方法はうまくいかな

いことを揶や ゆ

揄して使う言葉です。

・見積もり、進捗管理手法Jeff氏「相対見積もりを行って、合計を100%として進捗を管理する手法は良い方法だ。このほかに、プランニングやバーンダウンチャートとのとても有効な活用テクニックがあるぞ。この本(『Agile Estimating and Planning』)がお勧めだ。ぜひ読んでみたまえ。」→この本は、永和システムマネジメントの安井力さんと角谷信太郎さんが翻訳中で、

来年初頭に本屋さんに並ぶ予定とのことです。ぜひ買ってみてください。

・スプリントレビューJeff氏「君のスプリントレビュー

は目的がはっきりしていないな、スプリントレビューは目的に合わせて、2つのパートに明確に分けなさい。1つは会社の誰でも参加できるもの、もう1つはプロジェクトチームだけが参加できるものだ。」→スプリントの変わり目のミーティングは、「レビュー」と「ふりかえりとプランニング」の2つの目的にわけることを言っています。私たちはレビューとふりかえりを一緒にやっていたので、他の人がプロジェクトの内容を見る機会がなかったのです。

・プロダクトオーナーが不要の場合Jeff氏「プロダクトオーナーが機能していないということだが、本当にその役割は必要だったのかな?ユーザーの仕様の安定度が高いときには、必ずしもプロダクトオーナーは必要ないぞ。ただし、本当に安定しているかどうかはちゃんと見極めたほうがいいぞ。」→ここにも手法をそのまま使うのではなく、状況に合わせて役割を調整してよいという姿勢が伺えます。

・スクラムマスターの姿勢Jeff氏「スクラムマスターには、技術としてのファシリテーションのスキルは必ずしも必要ないが、メンバーの関係を円滑にしたり、笑顔をもたらしたり、労をねぎらったり、積極的にメンバーの気持ちを聞いたりすることが大事だという君の意見には賛成するよ。何よりも、スクラムマスターはチームを信頼することが重要で、干渉しすぎず、ただ彼らが自分たちで解決することを助ける姿勢が重要だぞ。」→なんだか泣けてきちゃいました。

■謝辞

電子楽器メーカ→陶磁器の卸会社→鉄道関連の研究開発の会社を経てIT業界に入って12年。オブジェクト指向歴約15年。教育のプランニング、PM、SE、PGなんでも。Agile Conference 2008では日本から楽器を持っていってドラムサークルを開催。目下の興味の中心はドラムサークルを使ったチームビルディング。認定スクラムマスター。認定NLPプラクティショナー。

Agile2008 で1日に90分を2日間で合計3時間ものインタビューをさせ

てもらいました。

ことごとく、個人の責任を明確にするような管理はやめるように言われました。それよりもチームで一丸となることをやったほうがいいと、、

ふりかえりの構成

場を設定する

データを収集する

アイディアをだす

何をすべきかを決定する

ふりかえりを終了する

アイディアをだす

ブレインストーム

たくさんだす

555

議論を支配する人がいる場合

全員の意見をまず聞きたい場合

目標や課題をクリアしている状態になっていることを想像して、そのために何が必要なのかを引き出す方法も有効。柔軟な発想を活かした対策をみんなで作っていきましょう。(公開資料用メモ)

ふりかえりの構成

場を設定する

データを収集する

アイディアをだす

何をすべきかを決定する

ふりかえりを終了する

対策として行うことに不都合なことが含まれていないかを最後にチェックしましょう(公開資料用メモ)

何をすべきかを決定する

必要ならプロダクトバックログへ

フィルタリング

フィルタをチームできめる

だれがいつなにを、サインナップ

ふりかえりの構成

場を設定する

データを収集する

アイディアをだす

何をすべきかを決定する

ふりかえりを終了する

ふりかえりを終了する

承認と力づけ重要

ふりかえりを簡単にふりかえる

ふりかえりのカイゼンも!

気持ちよく終わる!

おつかれさまでした。