1. Effective Retrospective 2018/3/29 株式会社アトラクタ 吉羽龍太郎
2. 吉羽龍太郎 @ryuzee ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ 野村総合研究所、Amazon Web Servicesなどを経て創業 ✤ アジャイル開発/DevOps/クラウドのコンサルティングとトレーニングを提供
3. 株式会社アトラクタのご紹介 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ ✤ アジャイル開発 / DevOps / チーム育成 / クラウドコンピューティング / ドメインモデリングなどが専門領域 https://www.attractor.co.jp/
4. 新刊のお知らせ ✤ Effective DevOps 4本柱による持続 可能な組織文化の育て方 ✤ 3/24 発売 ✤ オライリー 3,888円 ✤ ぜひよろしくお願いします!! ✤ http://bit.ly/EffectiveDevOps
7. Retrospectiveとは？ ✤ 日本語では「ふりかえり」(このあとはこの用語を使います) ✤ アジャイル開発でよく使われるプラクティス ✤ ただし利用範囲はアジャイル開発には限定されない ✤ ソフトウェア開発でなくても使える
8. KPTが有名だが、ほかにもいろいろある http://www.flickr.com/photos/magnus_d/5121009259/
11. 定期的に検査してちょっとずつ良くする 50 37.5 25 12.5 0 #1 #2 #3 #4 #5
12. スクラム 仕事が４倍速くなる“世界標準”のチーム戦術 ✤ 「Double the Work, Half the Time」 ✤ ジェフ・サザーランド、石垣賀子 ✤ 早川書房 (2015-06-24) ✤ ISBN: 9784152095428 / ASIN: 4152095423 ✤ https://www.amazon.co.jp/dp/4152095423
15. そう!! ✤ 人間も同じ ✤ 忙しいときほど止まれないが、止まらないと事故がおこる ✤ 強制的に立ち止まって本当にこのままでいいのか考える余裕を持つ
17. どれくらい時間をかけているか 状況 割合 30分〜1時間 55% 〜2時間 31% 30分未満 13% 半日 1%
18. どれくらいの間隔でやるとよいか ✤ ✤ ✤ あまり長い間隔だとうまくいかない ✤ プロジェクトごと => 3か月前とか半年前のことを覚えていない ✤ 直近のことだけにフォーカスしてしまい大事なことを見逃す ✤ 問題の継続期間が長くなってしまう 短めの間隔（1-2週くらい）が望ましい ✤ すぐに改善できる ✤ 改善の回数が増えるので、目に見える結果が出やすい 特定の出来事が発生した場合に追加で開催する手もある（障害など）
19. ふりかえりにおける大前提 = 心理的安全性
20. チームのルールやふるまいに注目 ✤ 個人の能力の合計とチームの能力はイコールではなかった ✤ 個々に対するアプローチより集団に対するアプローチが効果がある ✤ 成果を出したチームにほかのことをやらせても成功するが、失敗するチームは何 をやっても失敗する現象 ✤ よい集団規範の有無が及ぼす影響が大きい ✤ ✤ 不文律・習慣・行動基準（明文化の有無は関係ない） 均等な発言機会と共感力・他者理解力があると成功しやすかった ✤ ＝心理的安全性
21. Effective DevOps ―4本柱による持続可能な組織文化の育て方
22. つまり… ✤ 役職や立場の上下関係、人事評価への恐怖などで、本当に思っていること が言えなければ、本当の「問題」にたどり着かない ✤ 安全性こそが透明性を生む ✤ まずはその場を「安全」にすること ✤ したがって必要に応じて参加者の選別やファシリテーターによる宣言が必 要にもなる(マネージャーやリーダーに参加を遠慮してもらったり) ✤ 「あなた VS. わたし」 => 「問題 VS. わたしたち」
23. ファシリテーターを設定しよう ✤ うまくふりかえりを進めるために進行役（ファシリテーター）を設定 ✤ 慣れた人、やりたい人にやってもらうとよい ✤ 役職が上の人がやっても構わないが、自分の発言は我慢が必要 ✤ 誘導尋問になりがち ✤ 終わったらファシリテーターに対するフィードバックをする ✤ 徐々にファシリテーター不在でもうまく回せるようになる
24. 基本的な進め方の例 1. 場を設定する 2. データを収集する 3. アイデアを出す 4. 何をすべきか決定する 5. 終了する
25. 1. 場を設定する ✤ これから行う作業に集中できるように始め方に気をつける ✤ 参加者してくれることに感謝を示す ✤ まず全員に口を開いてもらう(抱負など)。全員参加が不可欠 ✤ 会議の冒頭に口を開くと主体的参加度があがる傾向 ✤ 進め方を説明する(タイムボックス、目標も含む) ✤ チームの約束を確認する(心理的安全性の確認など) ✤ この時間を端折ったりしない方がよい
27. どんな道具を使っているか 状況 割合 付箋紙 58% ホワイトボード 55% Confluence 20% オンラインボード 13% Google Docs 11% Google Spreadsheet 6%
28. 2. データを収集する ✤ 前回のRetrospectiveでのアクションアイテムの進捗状況や結果を確認する ✤ イベント、メトリクス、完成した成果などの客観的データを集める ✤ イベント＝ミーティング、意思決定、メンバーの変更、割り込み、障害、お祝い事など ✤ メトリクス＝バーンダウンチャート、ベロシティ、不具合数、課題数、完了した項目数、 ドキュメント数、障害数など ✤ 定性的な意見や感想もデータとなる(ストレス、ヒヤリハットなど) ✤ ボードで見える化している場合はそれを使う。オンラインツールの場合はあらかじめダッシュ ボード化しておいても良い ✤ データを共通理解や議論のための道具として使う ✤ 全部を集めないといけないわけではもちろんない
29. データの例(ほかにもたくさん) バーンダウンチャート テスト結果推移 ビルド結果 カンバン KeepやProblem 会議のログ 写真： https://www.flickr.com/photos/chrishuffman/2336990347/ https://www.flickr.com/photos/reevej/6334289004/
30. データの例(ほかにもたくさん) ✤ バリューストリームマッピング
31. Opinion vs Fact (意見 vs 事実) Problem (問題) Solution (解決策) 計測 Fact (事実) デプロイ 仮説 Opinion (意見) 設計
32. 例えば？ ✤ 「品質が悪い」=> これは意見か事実か？ ✤ 「情報共有が不足している」=> これは意見か事実か？ ✤ 「お客様のテンションがあがりすぎている」=> これは意見か事実か？ ✤ 意見だけをもとにしてアクションを決めると本質的な問題が解決しない ✤ 解決策の欠如を問題として語るのは、場の安全性、チームの信頼の欠如を 示すシグナル
33. 3. アイデアを出す ✤ データを使って課題を抽出し、アイデアを出す ✤ アイデアにはリスクや副作用がある場合もある ✤ いきなり出した解決策が正しいことは多くないので、分析的に考える ✤ ✤ いま思いついた絶対イケてそうな機能のアイデアは1日経つとイケて ないことが多い 5 Whyや根本原因分析などのテクニックも利用する
35. 4. 何をすべきか決定する ✤ アイデアの中で妥当だと思えるもののうち、上位の課題を解決する項目を 少数選んで計画する ✤ 多すぎても行動できないので無駄になるので、数個に限定すること ✤ 必要であれば機能リストやプロダクトバックログに項目を追加したり、自 分たちの計画に組み込む ✤ 誰がいつまでにやるのかをはっきりさせないと完了しない ✤ 大きすぎるアクションは完了しない。小さく分割する
36. SMART ✤ Specific ✤ ✤ Measurable ✤ ✤ 達成可能。誰もがタスクを達成するのに必要な助けをチームの他のメンバーに求めること が出来る Relevant ✤ ✤ 測定可能。そのタスクの「完了」について全員が同じ理解を持っていること Achievable ✤ ✤ 関係者全員が理解できるくらい具体的であること。それによってムダな動きを避ける 全てのタスクは目標の達成と関係があり説明可能であること Time-boxed ✤ 時間で見積もりが行われていること。大きい場合は複数のタスクに分割されること
37. どれくらいのアクションアイテムを出すか 状況 割合 1〜5個 78% 6〜10個 16% 11〜15 3% 何も出さない 3%
38. 拳から5本指 (Fist to Five) 0 この時点で決定を行なうこと自体に反対 1 重大な問題がある。そのまま決定したらアクションを起こす 2 問題がある。もっと話し合いをしたい 3 良いとは思わないが自分はそれでも構わない 4 良いので協力する 5 素晴らしいので自分が実行のリーダーになっても良い
39. 5. 終了する ✤ 決定事項や議論の内容などについて記録を残す ✤ ホワイトボードや模造紙などを写真にとっておいても良い ✤ フォローアップのアクションを決める ✤ ふりかえりの進め方がどうだったのかをふりかえる ✤ ふりかえりとそれまでの作業に感謝して終了する
41. ! 症状 ✤ 雰囲気が暗い ✤ 発言が出ない ✤ 発言が特定の人に偏る ✤ 愚痴が多い ✤ 次のふりかえりでもプロセスが変わっていない ✤ 解決策がないことを主張する ✤ 手を打ったはずの問題が再現する
42. Retrospectiveで難しい点 状況 割合 議論した内容をチーム単体で解決するのが困難 48% 安心して話せないことがある 44% チームが分散している 36% いつも特定の人ばかりがしゃべる 32% ネガティブなことばかりにフォーカスする 27% トピックの選択が良くなかったりアクションに合意しない 25% チームがやりたがらない 23% 組織やマネージャーがRetrospectiveの価値を分かってくれない 20%
43. " 原因候補：安全性欠如 ✤ 安全でないと、失敗を認 めたり、問題を明らかに したり、新しいことに挑 戦しにくくなる ✤ 高い心理的安全性を持つ チームはそれぞれが同じ くらいの持ち時間で話す 傾向がある https://www.youtube.com/watch?v=KZlSq_Hf08M
44. " 原因候補：不明確なアクションアイテム ✤ どんなアクションをいつまでにやるのか決めていない ✤ アクションが実行されたか・定着したかをどう追跡するか決めていない ✤ 何をもってそのアクションが完了するのかの基準が明確でない ✤ 数が多すぎるアクションアイテム
45. # カイゼンボード ✤ カイゼンの取り組みを見える 化する ✤ 誰が着手しているかアバター を使って明らかにする ✤ 通常のカンバンと同様にアク ションに優先順位をつける ※アジャイルコーチの道具箱 – 見える化の実例集(Jimmy Janlén 著) より引用
46. " 原因候補：マンネリ… ✤ いつも同じやり方(KPTなど)をしている ✤ いつも同じ課題や不満がでる繰り返し ✤ 同じ観点ばかりで改善点を探すと見落とすことがある ✤ KPTでは全体の流れが把握しにくく散発的になる可能性も ✤ やり方を変える ✤ 日常の場所から離れる
49. # Token of Appreciation Timeline ※Fun Retrospectivesより いろいろなふりかえり方法 Happiness Radar Star Fish Story of Story WWW
50. いろいろなふりかえり方法 SWOT FMEA (Dealing with Failure) Known Issues Future Facebook Posts Who-What-When Steps to Action
51. いろいろなふりかえり方法 (OST) ✤ 大人数向け（部門など） ✤ 手順 ✤ 参加者各自が話し合いたいテーマを 発表する ✤ 参加者はどのテーマに参加するか自 分で決める ✤ テーマごとにミーティングを行う ✤ 最後に全体の意見や決定事項を共有
52. http://bit.ly/2nLOyrV いろいろなふりかえり方法
53. どんなやり方をしているか 状況 割合 うまくいったこと/いかなかったこと 46% KPT 19% 感情分析 10% Lean Coffee 5% 特にテクニックは使っていない 3% タイムライン 2% 感謝の表明 1%
54. " 原因候補：時間的余裕の不足 ✤ そもそも忙しすぎると、改善に時間を使えない ✤ 改善した方が速くなるかもしれない、と思っても今の仕事が一時的に遅く なる点に対して恐怖を持ってしまう ✤ チームの時間の使い方や計画作りに課題があるかもしれない
55. # ✤ キャパシティプランニング 計画のとき多くの組織は1日を8時間と して計算している。つまり4時間のタ スクが2つ終わることを想定している ✤ でも実際には終わらない ✤ 右の例だと実際に開発に使えるのは 65% (平均で50〜70%) ✤ 項目 時間 社内全体会議 2 事務手続き・報告・メール 4 研修 (平均) 2 休暇 (平均) 2 スクラムイベント 4 開発作業 26 あらかじめバッファーを確保する
56. " 原因候補：改善の質が悪い ✤ 色々な改善をしても、同じような課題がしばらくして再発することがある ✤ 「気をつける」「確認する」「ちゃんとやる」などのアクションアイテム が問題を起こす ✤ 「本番作業で障害を出したので、今後は複数人で確認しながらやる」 ✤ たぶんまた発生する
57. # 仕掛けを作る ✤ 間違えようのない仕掛け・仕組みを作る ✤ ミスをしたらすぐに分かる仕掛を作る ✤ もっと安全で簡単な方法を見つける ✤ しかし時には間違った改善をすることもある（それを許容する）
58. " 原因候補：そもそもの問題設定の誤り ✤ 自分たちでは扱いきれない問題であることもある（人事・組織など） ✤ 大きすぎる問題だと手が出しにくい
59. # ✤ 自分たちでは扱いきれない問題は適切な人にエスカレーション ✤ ✤ 原因候補：そもそもの問題設定の誤り スクラムの場合はスクラムマスターやマネージャー 大きすぎる問題への対処 ✤ 相関関係を見える化する ✤ 開発と同じように、自分たちが扱えるサイズまで分割する ✤ 分割後それぞれの優先順位や効果を考える
