人事チームでスクラム導入 - スクラム イベントいれてみた
こんにちわ。
メルカリ人事部門にて人事データ分析を担当しているtweeeetyです。
HR Data Managementというチームにて、いわゆるPeople Analyticsを推進しています。
さいきんは「強いチームをつくる」という個人的なミッションのもと、スクラムを導入しています。なぜスクラムか？というと、「強いチーム」とは「変化に強く自己組織化したチーム」であり、「変化に強く自己組織化したチーム」とは「スクラムチーム」であるという仮説を持っているからです。
今回は、ゼロからスクラム導入をした知見・経験をまとめるべくnoteをいくつか書いていこうと思います。
今回とりあげるのは「スクラム イベント」です。
1. スクラム イベントとは何か
スクラム イベントを説明するためにまずはスプリントを説明します。
スプリントとは、チームが一定量の作業を完了させる際の、短く区切られた期間です。
スプリントは週単位のタイムボックスと考えるとわかりやすいかもしれません。1スプリント = 1タイムボックスを何週間とするかはチームで決めることができます。1週間、2週間、4週間などチームで決めた区切りの単位をスプリントと呼びます。たとえば、1スプリント=2週間とした場合、2スプリントといえば4週間のことです。
スクラムでは1スプリントごとに何かしらの成果をあげることを目指します。1スプリントの期間中に行われるいくつかのイベントを総称してスクラム イベントと呼びます。
図だとこんなイメージです。
大きくぐるっと1周している矢印の円が1スプリント、その線上にサブ的なマルやシカクで記載されているそれぞれがイベントです。（シカク = Refinementはイベントではない説もありますが、ここでは一旦イベントとして扱います）
それぞれは以下の名前です。
スクラム イベント:
- Sprint
- Sprint Planning
- Daily Scrum
- Backlog Refinement
- Sprint Review
- Sprint Retrospective
各イベントにて、そのスプリント期間内におこなうタスクを計画したり精査したりレビューしたりしながらスプリント内で成果をあげていきます
2. なぜスクラム イベントが必要なのか
スクラムの根本的な考え方に「経験主義」と「リーン思考」というものがあります。
■ スクラムの2つの考え
経験主義:
理論よりも経験を重視し、その経験を基に物事を判断する。
リーン思考:
ムダを省き、本質に集中する。
「経験主義」をもう少し噛み砕いていうと「不確実な世の中をいくら予測しても予測の域を出ないので、経験や事実に基づいて判断しましょう」というものです。そして、各スクラム イベントが「経験主義」「リーン思考」を実践するプロセスになっています。
つまり、スクラム イベントを含むスクラム フレームワークの実践は、経験に基づきムダを省いて成果を最大化するために行われると言えます。
3. どのようにスクラム イベントを導入したか
スクラムにおいて、スクラム イベントは最重要にして最大の難関とも言えます。まさに「言うは易く行うは難し」の代表例といえるでしょう。
導入ステップ:
1. 自チームでのスクラムイベントの設計と計画をする
2. スクラムイベントの想定に合わせてJIRAをカスタマイズをする
3. マネージャーやチームに説明を行いフィードバックを得る
4. スプリント開始までに各スクラムイベントの用意を行う
- 開始に向けて各会議体の統廃合
- 各スクラムイベントの設置
- 各メンバーのスケジュール調整とイベントへの招待
- 各スクラムイベントの進行アジェンダの用意
- JIRAのProject/Board/Settingの用意
5. スプリント開始
以降では、上記のステップ1, 2について少し深堀りして説明します。
3.1. 自チームでのスクラムイベントの設計と計画をする
基本はスクラム イベントも守破離します。とはいえ、チームの状況、チームの習熟度、使っているツールによってやり方は違いが出ると思います。
そこで、ざっくりとスクラム イベントの設計・計画をします。具体的には以下のようなことをしました。
スプリント イベントの設計:
- スプリント内でのスクラム イベントの流れをつくる
- 各イベントごとに何するか/目的/どうやるかの定義をする
スプリント イベントの計画:
- スプリント開始に必要なことの洗い出し
- 設計/説明会/準備/開始のタイムラインや進め方の検討
スクラム イベントの導入をはじめて経験するマネージャーやメンバーは、中身の有用性を理解するよりもまえに「ミーティングがめっちゃ増えるんだ」という印象を抱くことも多いです。また、プランニングやスプリントレビューなど、どんなに説明しても実際にやってみるまではイメージできないことも多々あります。
はじめての導入時、何より大事なのはスクラム イベントをチームが受け入れられることだと思います。守破離が基本ではありますが、完全なスクラムを目指すものとしてゴールにおきつつ、メンバーの理解や心境を置いてけぼりにしてはいけません。
そこで、われわれのチームではメンバーからのフィードバックをうけて、スクラム イベントを受け入れやすいカタチへと一部フィットさせています。
フィットさせたこと:
- daily scrumは週2回でスロースタートに
- 名前はdailyのままだけど気にしない
- チケットの作成・更新時間を各イベントに組み込んで運用をまわす
- 普段からチケットの作成・更新を意識するのは難しい
- とにかくチケッティングがされることを重視
- 見積もりやブレイクダウンは細かくみすぎない
- 課題は急いでカイゼン案よりもチームでの共通認識を大事にする
「ルールを作ってあとはやってね」ではなく、「ルールはつくるし並走もするよ」という意識で進めました。
以下は、フィットさせるためにカスタマイズしたスクラムイベントの設計例です。
■ スプリント内でのスクラム イベントの流れ
Sprintを通して全体のながれを設計します。曜日と開催時間があるとイメージしやすくなると主ます。
以降は、自分のチームでの各イベントのWhat/Purpose/Howを言語化したものです。こういった設計や説明資料をもとに、メンバーに各イベントの説明を丁寧に行いました。
■ 各スプリントの設計 - スプリントプランニング
■ 各スプリントの設計 - デイリースクラム
■ 各スプリントの設計 - スプリントリファインメント
■ 各スプリントの設計 - スプリントレビュー
■ 各スプリントの設計 - レトロスペクティブ
4. スクラム イベントしてみてどうだったか
導入する側の感想としては、まいかい思いますが「言うは易く行うは難し」につきます。
チームの感想としては、ありきたりですが「タスクが見える化されてよかった」「各人のタスクを知る機会やリズムができてよかった」という意見が多く得られました。
スプリントイベントやJIRAの導入まえは「各人が何をやっているかだんだんわからなくなってきている」「チームに属する意味が薄くなっている」というサイロ化的な意見もありました。こういった意見もスプリントイベントやJIRAの導入でだいぶ解消された雰囲気を感じています。
しかし、スクラム イベントを導入してまだ数スプリントしか回せていません。本番はまだまだこれからです。加えて、現在はメトリクスの測定をはじめています。このあたりについても気が向いたらnoteを追加しようと思います。
参考
おわり
スプリント イベントは導入〜運用が難しいです。ひとりで導入するにはわりと気合と根性が必要です。しかし、やってみてわかることも多いので一度しっかりと守破離を目指してみることをオススメします。
スクラム導入に関しては、いくつかnoteを書いていくので追ってリンクしていこうと思います。
いいなと思ったら応援しよう！
