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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ケース3：完成の定義

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

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

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

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

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

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

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

ケース3：完成の定義

ケース3：完成の定義

ケース3：完成の定義

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

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

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

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

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

• https://www.creationline.com/culture

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

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

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

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

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

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

• https://alu.jp/series/アオアシ/crop/6QSe7r606Hy6000kiZwG

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

他の チーム 他の チーム

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

今後の展開

今後の展開

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

フェニックスプロジェクト 宣伝 参加費 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：スクラムマスター • スクラム現場ガイド • SCRUMMASTER THE BOOK • 仕事の進め方のヒントになるかもしれない 「アジャイル」からのつまみ食い • アジャイルコーチの道具箱 • ケース2：フロー効率 • フロー効率性とリソース効率性について • ケース3：完成の定義 • スクラムガイド

• https://www.amazon.co.jp/dp/B01D4JHITO
• https://www.amazon.co.jp/dp/B08CRMPQL8
• https://speakerdeck.com/ykmc09/sneak-tips-from-agile
• https://leanpub.com/agiletoolbox-visualizationexamples-japanese
• https://www.slideshare.net/i2key/xpjug
• https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

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