スクラムマスターの頭の中:あのときスクラムマスターは何を考えていたのか?

3.2K Views

November 04, 22

スライド概要

Scrum Fest Sapporo 2022
https://confengine.com/conferences/scrum-fest-sapporo-2022/proposal/17273

profile-image

https://twitter.com/ikikko

シェア

埋め込む »CMSなどでJSが使えない場合

各ページのテキスト
1.

スクラムマスターの頭の中 ~ あのときスクラムマスターは 何を考えていたのか?~ Tomonari Nakamura (ikikko) 2022/11/04 Scrum Fest Sapporo 2022

2.

中村 知成 ( ikikko ) • 所属:クリエーションライン株式会社 • 役割:スクラムマスター / アジャイルコーチ • 大切にしている価値観:現場で働くチームの役に立ちたい! • エンドユーザーへ価値を届けることを見据えつつ • その価値を産み出すチームもより活き活きと動けるように • 得意なこと・興味があること:チームやプロセス改善、CI/CDをはじめとし た自動化周り

3.

アウトライン • 背景 • ケーススタディ • ケース1:スクラムマスター • ケース2:フロー効率とリソース効率 • ケース3:完成の定義 • まとめと今後

4.

参画した現場の状況 • スクラム&LeSSを採用したチームで、3,4チームで一つのプロダクト開発 に携わっていた • メンバーもそれなりに多く、現在進行系で増えていっている最中だった • 上記の背景から、アジャイルやスクラムに関する知識について、メンバー によっても多少バラツキがあった

5.

参画してやったこと そのときの現場の状況や問題に応じて、アジャイルに関する概念やプラク ティスを、LT形式で定期的に共有していくことに

6.

参画してやったこと • 参画1ヶ月後から、月1ペー スで1年間程度やってきまし た • 今回は、Vol.1, Vol.6, Vol.7を ケーススタディとして取り上 げます

7.

アウトライン • 背景 • ケーススタディ • ケース1:スクラムマスター • ケース2:フロー効率とリソース効率 • ケース3:完成の定義 • まとめと今後

8.

ケース1:スクラムマスター

9.

ケース1:スクラムマスター • [a-1: 状況] • その現場では初となる、専任スクラムマスターとして参画した直後 • メンバー側から見て、スクラムマスターに対して何を期待していいか分から ない、期待にバラツキがある • [a-2: 問題] • 「期待することを何もやってくれない」「何をやっているのか分からな い」となり、不信感が芽生える恐れがある

10.

ケース1:スクラムマスター • [b: 目指した状態] • スクラムマスターに期待していいこと / 期待しない方がいいことの認識 が、メンバーと合っている • 「なんか知らないけど、勝手に動いてるな」ではなく「あー、〇〇な意 図を持って動いてるのね」という理解と信頼が得られている

11.

ケース1:スクラムマスター • [c-1: LTで共有した内容] • 「スクラムマスターとは何であるか?」や「自身のスクラムマスターと しての座右の銘」を説明 • [c-2: 付随した取り組み] • やろうとしていることをカンバン形式で共有

12.

ケース1:スクラムマスター • スクラムマスターについての説明資料

13.

ケース1:スクラムマスター • スクラムマスターについての説明資料

14.

ケース1:スクラムマスター • 取り組もうとしていることを、見える化して共有

15.

ケース1:スクラムマスター • 取り組もうとしていることを、見える化して共有

16.

ケース1:スクラムマスター • [d: 結果] • 目に見える振る舞いの変化はなかった • (後から聞いたら)スクラムマスターへ期待することが明確になって、 動きやすくなったという人はいた 元スクラムマスター 兼リーダー

17.

ケース2:フロー効率とリソース効率

18.

ケース2:フロー効率とリソース効率 • [a-1: 状況] • それまで取り組んでいたことが一区切りして、2チームいる開発チーム が次にやることを考えている • [a-2: 問題] • 各チームが別々の機能を対応していることから、新機能のリリースまで に時間がかかっている

19.

ケース2:フロー効率とリソース効率 • [b: 目指した状態] • 新機能が一通り使えるようになるまでのリードタイムを短くする

20.

ケース2:フロー効率とリソース効率 • [c-1: LTで共有した内容] • フロー効率とリソース効率について説明 • [c-2: 付随した取り組み] • フロー効率を優先という意思決定を、POと共に判断 • 上記の意思決定のもと、2チームとも同じ機能に取り組むための体制の 整備

21.

ケース2:フロー効率とリソース効率 • フロー効率の説明資料

22.

ケース2:フロー効率とリソース効率 • フロー効率の説明資料

23.

ケース2:フロー効率とリソース効率 • フロー効率の説明資料 2チームいると、片方が割り込み対 応しても、もう片方のチームで進 めていける、という趣旨を補足

24.

ケース2:フロー効率とリソース効率 • フロー効率の説明資料 開発者にとっては「調整コストが増え てやりづらくなるなあ」と反発される のを懸念していたので、トレードオフ となるものを予め説明

25.

ケース2:フロー効率とリソース効率 • フロー効率の説明資料

26.

ケース2:フロー効率とリソース効率 • POと共に、影響内容をステークホルダーへ説明 • 「1機能に開発を注力するので、他の機能は後回しになりますが、この 機能をより早く利用できるようになりますよ」 • 開発者と共に、Readyの定義を今まで以上に細かく定義 • PBIの準備が不十分なときに影響を受けるチームが多くなったため

27.

ケース2:フロー効率とリソース効率 • [d: 結果] • 当初の狙い通りに、リリースまでのリードタイムが短くなった(以前は おおよそ3ヶ月程度かかっていたところが、2ヶ月程度に収まった) • 当初の主な狙いではなかったが、知識の共有化が無理なく進んだ 3ヶ月後のプロジェクトで、共有 化が進んでいたことによって、 両方のチームで対応できたた め、柔軟性が増した

28.

ケース2:フロー効率とリソース効率 • [d: 結果] • 一方、チーム間で共通認識のずれという課題が顕在化してきた • → ケース3に続く

29.

ケース3:完成の定義

30.

ケース3:完成の定義 • [a-1: 状況] • フロー効率を優先して、2チームが同じプロダクトバックログをもとに 作業を進めている • [a-2: 問題] • 2チーム間で、テストやリファクタリングなどをどこまでやるべきかの 共通認識が合っていない • その結果、チーム間で微妙なすれ違いやもやもやが発生している

31.

ケース3:完成の定義 • [b: 目指した状態] • 2チームの一体感を高めて、一丸となって価値提供に向かえる 作成物のずれに起因する問題 もあったが、それよりは感情 面の問題を中心に考えていた

32.

ケース3:完成の定義 • [c-1: LTで共有した内容] • 完成の定義について説明 • [c-2: 付随した取り組み] • チームに最適な完成の定義を、2チームのメンバー10名強をシャッフル してディスカッションするワークショップを開催

33.

ケース3:完成の定義 • 完成の定義の説明資料

34.

ケース3:完成の定義 • 完成の定義の説明資料 LT中で、一番最後の行を強く 押し出して説明

35.

ケース3:完成の定義 • 完成の定義をディスカッション:流れ

36.

ケース3:完成の定義 • 完成の定義をディスカッション:流れ

37.

ケース3:完成の定義

38.

ケース3:完成の定義

39.

ケース3:完成の定義

40.

ケース3:完成の定義 • 完成の定義をディスカッション:結果

41.

ケース3:完成の定義 • 完成の定義をディスカッション:結果

42.

ケース3:完成の定義 • [d: 結果] • 当初の予想以上に、メンバー同士がお互いに理解できるようになった

43.

ケース3:完成の定義 • 今まで接点が少なかったチーム間のメンバー同士でも、ディスカッショ ンを通じて、各自の思いや考えに触れることができた 参加者 • その結果「よく知らないけど、あっちのチームは何でこうしないんだ よ」から「あの人たちなら、色々考慮した上でこうしたんだろうな」と いう尊敬&信頼を持って行動できるようになった

44.

“ 私たちの理念は、HRT+Joyです。HRTはHumility(謙虚)、Respect(尊 敬)、Trust(信頼)の頭文字から作られたもので、それにJoy(喜び)を足し たものが私たちの理念です。“ https://www.creationline.com/culture

45.

アウトライン • 背景 • ケーススタディ • ケース1:スクラムマスター • ケース2:フロー効率とリソース効率 • ケース3:完成の定義 • まとめと今後

46.

やってみた結果と感じたこと • メンバーの振る舞いが、すぐに変わるものではない • それでも、事前に共有する機会があるとないとでは理解度が違うはず • 口頭で説明するだけより、資料など目に見えるものは分かりやすい • 馴染みが薄い概念(例:フロー効率など)だと、より効果的 • 外からの振る舞いは変わらなくても、内心では受け止めていることも

47.

やってみた結果と感じたこと • 定期的に共有の資料をまとめるコストはそれなりにかかった • 当初は週1を目指していたが、最終的には月1ペースに • LTという時間の制約上、一方向の発信が多くなってしまっていた • 意見や質問を聞く・答える時間をもっと増やすと、より納得感が出たか もしれない(事後に質問を受け付けるアンケートなど)

48.

やってみた結果と感じたこと

49.

やってみた結果と感じたこと

50.

やってみた結果と感じたこと • 自分のためにも、考えの整理と後 のふりかえりには、大いに役立っ た(ある意味、この発表自体も、 ふりかえりと言える) • 一度言語化しておくと、別の局面 での再現もやりやすくなるはず https://alu.jp/series/アオアシ/crop/6QSe7r606Hy6000kiZwG

51.

今後の展開 • こういう活動を、もっともっと広げていきたい! • 今いるチームにとどまらず • 社内の他のチームに対しても • 社外で共創していく顧客に対しても

54.

他の チーム 他の チーム

55.

共創する 顧客 共創する 顧客 他の チーム 他の チーム 共創する 顧客

56.

今後の展開

57.

今後の展開

58.

今後の展開 • 理想までは遠い道のりで、心折れそうなこともありますが、一歩一歩 • まずは、社内にこういう活動をやってたよと共有しつつ • 一緒に共創している顧客を巻き込みながら、広げていく

59.

フェニックスプロジェクト 宣伝 参加費 DevOpsシミュレーション研修 無料 無料体験会@札幌 2022 11/19(土) 開催 in札幌 開催概要 フェニックスプロジェクトDevOpsビジネスシミュレーション研修の無料体験会を札幌で開 催します。 ITサービスのパフォーマンスを向上させるためにDevOpsを適用したい方、仕事 の流れをより効率よくしたい方、 より素早いデプロイがしたい方など、 是非この機会にフェニ ックスプロジェクトを体験してみてください。 期 間 参加人数 定 員 1日間(8時間、うち食事 1時間) 場 北海道立道民活動センター 所 開催形式 集合研修、現地開催 ※オンラインでの参加はできません 参加費 無料 持ち物 特になし 申込期限 2022年11月8日(火) 18:00 支援内容 ・スクラムチームの活動を観察し気付いたことを伝える。 ・アジャイル開発の理解を深めるための研修やワークショ ップを実施する。 どんな人におすすめ? ・アジャイル開発を始めようと思っているが詳しい人がいないチーム ・既にアジャイル開発を始めているが期待した効果が出ていないチーム 推し ポイント 験を通じ、 アジャイル開発の エキスパートがどう振る舞 うのかを身近で感じられ、理 10名〜12名 2022年11月19日(土) 10:00-18:30 アジャイルコーチによる伴走 •実際のアジャイル開発経 1名からお申込みいただけます。 日 時 1 解を深めることができる。 お申し込みは こちらから JoyRangersとは? 2 推し ポイント •アジャイル開発の基本的 な知識を身につけることが できる。 •アジャイル経験豊富なコ ーチが直接様子を見て、 話 を聞き、 アドバイスやフィー ドバックを得られる。 JoyRangersによる伴走 支援内容 ・顧客メンバーと弊社メンバーがスクラムチームを構成 し、一緒にアジャイル開発を実践する。 ・技術プラクティスの研修やワークショップを実施する。 どんな人におすすめ? ・アジャイル開発を始めようと思っているが、アジャイル開発もソフト ウェア開発にも自信がないチーム ・プロダクト開発進捗が滞っているチーム 「Joy:ユーザーが楽しんで使えるシステムを作る」 をモットーに弊社のアジ ャイル開発エキスパートと御社メンバーで1つのチームを組み、 アジャイル開発に必要なノウハウを間近で習 得しながらプロダクト開発を進めていく内製化支援サービスです。

60.

引用資料 • ケース1:スクラムマスター • スクラム現場ガイド • SCRUMMASTER THE BOOK • 仕事の進め方のヒントになるかもしれない 「アジャイル」からのつまみ食い • アジャイルコーチの道具箱 • ケース2:フロー効率 • フロー効率性とリソース効率性について • ケース3:完成の定義 • スクラムガイド

61.

共創する 顧客 共創する 顧客 他の チーム 他の チーム 共創する 顧客