こんにちは、Ubie(ユビー)株式会社 / Ubie Discoveryでソフトウェアエンジニアをしている目黒（@maguhiro）です。

前Qはクリニック業務の効率化を図るための機能開発をするスクラムチームに在籍しており、そこではスクラムマスターを経験しました。
今回は前Qにスクラムマスターとして所属したチームでの取り組みやUbie Discoveryでのスクラム支援についてご紹介できればと思います。

はじめに

前職で2ヶ月ほどスクラムマスターを経験しています。
しかしながら、本来のスクラムマスターの責務とは程遠いなんちゃってスクラムマスターでした。スクラムセレモニーのスケジュール調整や各セレモニーのファシリテーターをやるだけで、POやチーム支援という観点ではほとんどできていませんでした。

Ubie Discoveryでは入社当時からスクラム開発していましたが、前職で上手くこなせなかった経験から再度スクラムマスターをやることに今まで消極的でした。
しかし、前Qの体制変更に伴い新メンバー多めのチーム編成となったため、自分がやった方がチームにとってよさそうだしやってみるか！と手を挙げました。

Ubie Discoveryにおけるスクラム導入

手を挙げた背景にはもう１つ理由があります。
組織全体でスクラムが導入されて浸透しており、スクラムに精通したメンバーがオンボーディングやサポートをしてくれる体制が整っている点です。

Ubie Discoveryで取り扱っている0→1フェーズでは不確実性の高い分野における開発がほとんどです。チームの理解やプロダクトの状況に応じて、素早く無駄を省いて検証を繰り返し経験を通じて学習しながら最適な方法を習得していくプロセスこそが大切と考えています。
これはプロダクト開発だけでなく、マーケット開発・社内基盤構築（組織横断的なプロジェクト。例えば採用もその１つ）でも同様です。

上記の考え方はスクラムガイド2020にも記載されている理論にマッチしています。

スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から⽣まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。

Q毎にはOKRに合わせてチーム編成もガラッと変わり、異動も活発に行われます。Qの途中でも学習した結果からOKRの変更とそれに伴うリソース調整が入ることもしばしば。そのため、全メンバーがスクラムの理念を理解している状態を作る事ができると、どのチームに配属となっても課題にフォーカスしてスクラムに取り組むことができます。

こういった背景から組織にスクラムを浸透させることを目的とした横断的なチームも存在し、有志が集まって日々オンボーディングやサポートの体制をブラッシュアップしてくれています。

現在に至るまで

全メンバーがスクラムの理念を理解しているものの、結成直後は課題理解度も人によって様々ですし、スクラムセレモニーの枠組みもまだ決まっていません。このタイミングでは素早くチームが走り出せるようにスクラムマスターとしての役割に時間を割きました。

一方で、スクラムの理念を理解し主体的に行動するメンバーしかいないこの組織では、検査・適応もメンバーが率先してやってくれます。チームのスクラム基盤が整備された以降は、メンバーからの提案・適応した取り組みも沢山あります。この頃にはスクラムマスターとしての稼働は減らし、開発者としての稼働を増やすことができていました。

今回はその様々な取り組みの中から2つほど私が行った施策を紹介します。

スクラムセレモニー台本

1つ目はスクラムセレモニーの台本作成という取り組みです。
以下のような思惑で、誰でも台本に従って型化された進行ができるようにしたいという目的で作ろうと考えました。

・スクラムマスターがセレモニーの進行も当然行うべきロールという誤解を招かないため
・各メンバーがセレモニーの開催意義を理解し、検査・適応する意識を高めるため

最初の数スプリントで自分がセレモニーのファシリテーター務めながらこの台本を作り、それ以降は交代制にして台本をみながら進めてもらいました。

台本をドキュメント化し、そのドキュメントを日々のセレモニーで閲覧しながら進行するという取り組みは、「検査」という観点でも非常に役に立ちました。スクラム活動全体の検査も常日頃からしていたのですが、ドキュメント化・閲覧の習慣化はスクラムセレモニーの課題の明瞭化(「この部分がよくなさそう」という指摘がしやすい)にもなります。

更に、改善点を台本に反映させようという取り組みがチームに定着化することで、「検査」だけで終わらず「適応」までやりきることができます。
改善ポイントが反映された台本を使うことで、その改善がチーム全体に浸透するという効果もあります。

一見地味な施策ではありますが、改善できているという実感がチームの中に浸透させる事はスクラムにおいて重要なポイントだと思います。

最終的に、前Qの3ヶ月でこの台本は20箇所以上更新されました。
共有以降の期間で考えると1スプリント(1週間)あたりで2箇所ずつ更新できていたということになります。

スプリントボード

2つ目はスプリントボードの作成です。
こちらはスプリント単位でセレモニーの内容や日々の変化が把握できるようにmiro上に作りました。

実際に作成したスプリントボードのテンプレートがこちらです。

プランニング/デイリースクラム/レトロスペクティブに絞っているのが肝です。これらのセレモニーはスクラム活動・チームに対する検査・適応に重心をおいたものであると個人的に解釈しているためです。

スクラム活動・チームの状態が見える化(「透明化」)されていなければ、メンバー間のズレに気づきにくくなります。
ましてやコロナ禍でオンラインコミュニケーションが増えている現状ではこのズレは致命的です。メンバー間のズレにいち早く気づき、適応させていくためにもスクラム活動・チーム状態の可視化は重要です。

スプリント毎にスプリントボードが出来上がっていくので、以下のような効果もありました。

・そのQ(3ヶ月間)の活動が振り返りやすい
・徐々に洗練されていることが実感できる

ここからはこのスプリントボードを用いたスクラムセレモニーが現在どのように取り組んでいるか紹介します。

デイリースクラム

オンライン中心のコロナ禍において、対話によるコミュニケーション価値は高まっています。
全チームメンバーが集まって対話するデイリースクラムの時間をしっかり確保することが私達のチームには最適だと判断し、少し長いように感じられるかもしれませんが毎日30分かけて以下のアジェンダを話しています。

・スプリントゴール確認
・改善アクションの進行状況確認
・困っている事・今日やるタスクに関連して相談したい事
・実装中案件デモ
・スプリントゴール達成自信度の確認
・PBIアイディアの確認

スプリントゴール・改善アクションの進行状況の確認は、意識付けが目的です。こんなスクラムチームを目撃したことは無いでしょうか？

・今スプリント何にフォーカスして取り組むのか意識できずに、本来優先度の低い取り組みをしてしまう
・課題に対する改善アクションは浮かんだのに、誰がボール持ってるか分からず実行されない

しつこいくらいに毎日確認することで、これらは解決します。
※アサインされていない改善アクションがあれば、デイリースクラムの場でアサインまでしてしまいます。

実装中案件デモも荒い状態でも見せる事ができるものがあれば、改善点をみつけて反映できます。無駄に作り込んでしまう前に確認できることで無駄な後戻りも減らせている実感があります。

スプリントゴール達成自信度は先程紹介したスプリントボードが活躍する場です。各々が達成自信度を5fingerで表明し、結果に応じて深堀りを行います。

・自信度に大きな個人差がある場合、その差が生じているのか高いメンバー/低いメンバーに理由を聴取(保有している情報量がズレの要因となるので、聴取することで透明性が担保できる)
・全員自信度が低い場合、スプリントゴールを達成するための新しいプランを検討(スプリントの検査・適応ができる）

PBIアイディアはSlackの専用チャンネルにスクラムメンバー内外から蓄積されていく(コメントに特定のスタンプ押すと該当チャンネルに情報が流れるようにしている)ようにしています。
前日分のアイディアや現場から声をみんなで眺めながらOKRに直結しそうなアイディアをPBI化するという作業をやっています。

また、デイリーセクレタリーという役割のメンバーもいて「決定事項・誰が次にどんなアクションをするのか」を議事録としてまとめてくれています。

プランニング

事前に非同期で前スプリント・今スプリントの稼働実績/稼働予定割合を開発者ロールメンバーから表明してもらいます。
Ubie Discoveryでは採用に全員コミット・組織横断的なプロジェクトも多数あり、プロダクト開発のスクラムチームにフルコミットしていません。こういった体制のためベロシティが安定しません。
各スプリントあたりのベロシティをみるのでなく、稼働あたりの平均ベロシティをみることで、次のスプリントでどのくらいSPを消化できるかの精度を高めることができます。

次スプリントで消化できそうなSP = 全員の合計予定割合 x 過去の実績稼働割合あたりの平均ベロシティ

こちらもスプリントボードを用いながらやっています。
実際にとあるスプリントではこんな感じです。
プランニング時点では左側の予定列を記入し、スプリントの最後に非同期で実績列を表明・算出しています。

レトロスペクティブ

事前に非同期でOKR達成自信度/透明性・検査・適応がチームとしてできているかを5finger(または、4finger)で、各自が表明します。
こちらでもデイリースクラムと同様に大きなズレがあった場合、全員が低い値を付けていた場合には、内容を深堀りして課題を洗い出す工夫をしています。

その後、同様に事前に各々が書き出したFact(事実)/Keep(継続すること)/Problem(課題)を確認していきます。
誰が記載したコメントなのか分かるようにSlackアイコンも貼って、円滑な進行ができるようにもしています。

最後に一人3票まで改善したいProblemに投票してレトロスペクティブは終了します。その直後に、ホラクラシーの定例MTGの1つであるタクティカルミーティングというものを別途開催しています。
詳細は割愛しますが、タクティカルミーティングでは気になること・解消したいこと・確認したいこと・共有事項など何でも「ひずみ = 理想と現状のギャップ」をアジェンダとして各自があげることができ、1つ1つ解消していきます。
このタクティカルミーティングで、先ほど投票数の多かった「Problem = ひずみ」を順番に議論しています。その場でよいアイディア・解決策があればそれを採用しますし、別途作業が必要であればどのロール(誰に)にどういうアクションをしてもらうかというNextを決めます。
「Nextアクションが完了しているか？」「決定したアイディアがチームに浸透できているか？」という観点はデイリースクラムで検査しています。

まとめ

スクラムチームメンバーが「透明性・検査・適応」ができ、洗練されているという実感を持ってもらえることが、スクラムマスターとしての1つ大きな役割のように今回の経験を通して感じることができました。

一旦私はスクラムマスターとしての役割は降りて、イチ開発者として今は同じチームで活動しています。
前回スクラムマスターを経験した時の挫折感はなく、個人的にも満足いく結果を出して、胸を張って次のスクラムマスターへ引き継げました。
次の機会があればまたスクラムマスターをやってみたいと思います。

今回の取り組みの結果がどのくらい効果があったかわかりませんが、Q末に社内で発表される「Value Award = Ubie DiscoveryのValueを体現した個人・チームを称える賞」でValueの1つである「Launch and Launch (通称、ロンロン)」賞をチームで受賞することができました。
※他のValueについてはカルチャーガイドをご参考にしてください。

Launch and Launch 
"100の議論より1の実行"を推奨することによって、"大胆な仮説検証"および"継続的な失敗・学習"を促進。

ただこれに甘んじることなく、今Qはチームメンバーの一員としてより洗練されたスクラムが行えるよう、その先のステップを目指して活動していきます。

最後に

スクラム活動の改善の取り組み、そして、チームメンバーと改善した現在のチームの姿いかがだったでしょうか？
皆さんのスクラムチームでも参考になるプラクティスがあれば幸いです。

スクラムに関連する記事は他のメンバーも発信しているので是非そちらも読んで頂ければ幸いです。

We're Hiring!

Ubie Discoveryでは一緒に働く仲間を絶賛募集しております。
Ubie Discoveryスクラムの取り組みに興味を持って頂けた方は是非ご連絡ください。