研修概要
こんにちは！DDDDbox開発チームでマネジメントを担当しています、柴田と申します！
先日、下記のRegistered Scrum Master® Trainingを受講してきました。こちら、2日間のオフライン研修で、研修後の認定試験に合格すればスクラムマスターとして認定されるプログラムになります。
無事合格することができました！
この記事では、研修で得た学びや気づきを整理し、所属チームで直面している課題と今後の展望についてまとめたいと思います。
私が所属しているチームでは、すでに「スクラム開発」に取り組んでいますが、正直なところ、これまではスクラムガイドや経験者の話を参考にしながら形だけ取り入れていたため、「そもそもスクラムとは何か」「なぜスクラムをやっているのか」が曖昧なまま進めていたのが実情でした。
そこで今回、本物のスクラムを理解するために研修に参加しました。
スクラムとは？（簡単に）
スクラムに関してはネット上でいくらでも情報があるので、ここでは簡単にスクラムの概要を記載します。
スクラムには「3・5・3」と呼ばれる基本の枠組みがあります。
3つの役割（Roles）
- スクラムマスター：チームがスクラムを正しく理解・実践できるよう支援する
- プロダクトオーナー（PO）：プロダクトバックログを管理し、価値の最大化を担う
- 開発チーム：自律的にスプリントゴールを達成するために動く
5つのイベント（Events）
- スプリント：1〜4週間の開発サイクル。計画から実行・振り返りまでを含む箱のような期間。
- スプリントプランニング：スプリントで何を達成するかを決め、スプリントバックログを作成する。
- デイリースクラム：開発チームが毎日15分以内で進捗と課題を共有する、短い打ち合わせ。
- スプリントレビュー：スプリントの成果（インクリメント）をステークホルダーと確認し、フィードバックを得る。
- スプリントレトロスペクティブ：チーム自身のプロセスや関わり方を振り返り、次のスプリント改善につなげる。
3つの成果物（Artifacts）
この「3・5・3」がスクラムの骨格です。
もっと簡単にいうと
スクラムは 1〜4週間の短いサイクル（スプリント） を区切りに、
- 計画
- 実行
- 振り返り
をスクラムチームで繰り返していき、インクリメント(スプリントの成果物)を生み出していくフレームワークです。
私たちのチームでは、2週間のスプリントを設定しています。
（詳細はスクラムガイドを参照 →Scrum Guide 日本語版）
チームの現状と課題
私が所属しているチームの現状を整理すると、一部ですが、以下のような課題があります。
- スプリントプランニングとバックログリファインメントを同時に実施しているため、見積もりが不十分でゴール設定が曖昧なまま終わってしまう
- スプリントゴールが明確でなく、完了の定義も曖昧なまま進行してしまう
- ベロシティを活用できておらず、適切なストーリーポイントを設定できていない
- そもそもスクラムの理解や共通認識がそれぞれのメンバーで異なるため、なんとなくスクラムをやっている
まずはチーム全体で「スクラムの基本的な枠組み」を正しく共有し、本来のスクラムを理解することが出発点だと感じています。
スプリントプランニングとバックログリファインメントの統合
現在、スクラムの5つのイベントのうち、私たちのチームでは スプリントプランニング・デイリースクラム・スプリントレトロスペクティブ を実施しています。
研修に参加するまで、スプリントプランニングの時間にバックログリファインメントもまとめて行っていたため、制限時間内にすべてのバックログを見積もりきれず、スプリントゴールが曖昧なまま終わってしまうことが多々ありました。
研修で講師の方にこの状況を相談したところ、「リファインメント専用に時間確保をせず、プランニングと一緒に扱うチームは珍しくない」とのことでした。スクラムガイドに沿った理想形ではないものの、実務上致し方ないケースの様です。。。
このような状況だったので、８月からまず変えられるものから変えていこうと社内で動きがあり、現在はスプリントプランニングとバックログリファインメントを別々に実施して、効果を測定中です！
スプリントレビューの有無
現在、私が所属しているチームではスプリントレビューは開催していません。
似たような形で過去に開催していたことはあるのですが、現状のチームの開発サイクルでは毎回必ず目に見える形のインクリメントが生まれるとは限らないため、レビューを実施しても「見せるものがない」という状況になることがありました。
本来であればスプリントごとに開催するのが理想ですが、何も生まれないイベントを頻繁に開催しても意義が感じられないため、現在は月に1回オフラインでDDDDboxチームの責任者が集まる機会があるので、そこで共有するようにして、フィードバックをいただいています。
レトロスペクティブ
レトロスペクティブについては、KPTを実施していますが、Problemとして挙がった課題が次のスプリント改善に十分つながっていないのが現状です。
本来であれば、スプリントレビューで得たステークホルダーからのフィードバックをレトロスペクティブでも共有し、それを次のスプリント計画に反映することで、改善のサイクルを回していくのが理想だと思いますが、課題が挙がっても他のタスクを優先してしまい、改善に着手できないまま流れてしまうことが起きているので、改善タスクを次のスプリントで必ず１つは入れるなどルールを決める必要があると感じています。
チーム・ステークホルダーの共通理解
スクラムのイベント全体で見ると、導入当初は「お手本通りにすべてを正確にやろう」とすると、どうしてもコミュニケーションコストが大きく感じられます。スクラムに慣れてスムーズに進められるようになるまでには、時間管理やチーム・ステークホルダーの理解が必要だと感じました。
また、メンバーやステークホルダーの中には複数プロジェクトを兼務していることもあり、「できるだけ会議を減らしたい」という意見が出ても不思議ではないのかとも感じています。
だからこそ、スクラムイベントは必ず時間を区切り、時間内に結論を出すことが理想 なのだと思いますが、中々うまく結論へ導けない難しさも日々感じています。。。
その進行を適切にコントロールし、イベントを効果的に機能させるのは、まさに スクラムマスターの手腕の見せ所 ですが、中々思うようにいかず、私自身もスクラムマスターとしてまだまだ未熟だと痛感しています。このあたりは今後、スクラムを進めていく上でチームで慣れてくると、阿吽の呼吸でもっとスムーズにいくのかとも感じています。
突発タスクへの対応
チーム・ステークホルダーの理解が必要だと感じる点をもう一つ挙げると、突発的に発生するタスク についても課題があります。
スプリントプランニングで決めていないタスクは、バッファ用のストーリーポイントを超えると基本的に次のスプリントに回されてしまいます。その結果、人によっては「すぐに対応してほしいのにできない」というもやもやが溜まるケースがあるかと思います。
こちらに関していうと、スクラムのルールやあるべき姿の共有や共通理解が不十分だと起こりうるケースなので、やはりチーム全体でスクラムの考え方を正しく理解し、共通認識を持つことが先決だと感じています。
組織体制とスクラムの成熟度
バックログ準備の負担
スクラムは明確な目的（バックログ）をもとにサイクルを回すことで成立するため、バックログの準備が出発点になります。
そのため、プロダクトオーナーは次のスプリントに備えて、事前に整理されたバックログを用意しておく必要があります。研修では「常にスプリント2〜3週分のストックを確保しておくのが理想」と教わりました。
しかし、バックログの準備は想像以上に負担が大きい作業です。特に、組織の事情でチームを兼任している場合には、十分な時間を確保するのが難しくなることもあります。つまり、スクラムを効果的に回すためには、組織体制が整っていることが前提 だと強く感じます。組織に余裕がないまま導入すれば、バックログが枯渇してスプリントが回らなくなるリスクもあります。
個人の感想ですが、スクラムの導入は 組織とチーム双方に一定の余裕があって初めて効果を発揮するものではないかと感じています。
タスクの平均化と技術力向上
スクラムを迎え入れる組織体制の課題をもう一つ挙げると、タスクの平均化と技術力向上 です。
スクラムでは、担当者が「自分の得意なタスク」だけを優先するのではなく、チーム全体でタスクを分散し、誰もが幅広く対応できるようにすることが理想とされています。その進め方をコントロールするのはスクラムマスターの責任であり、同時にメンバー全員の技術力向上が不可欠です。
（もっとも、技術向上自体はスクラムに限らず、どの開発手法でも求められることですが。）
開発にスピードが求められてくると、どうしてもメンバーそれぞれが得意なタスクに割り振られることは現実よく出てくることかと思いますが、スクラムを導入するには、そんな場面でも今後のスクラムチームとしての成長を組織が迎え入れる余裕が必要になってくるのかと思います。
まとめ
課題をつらつらと書いてきましたが、まだまだスクラム導入段階でチームとしては伸びしろしかないと感じています。ただ、今回の研修を通じて、スクラムは単なる開発手法ではなく、組織やチームの成熟を前提としたフレームワークであるとも実感しています。
- 基本の「3・5・3」を理解し、形骸化させずにできる限り、本来のスクラムに沿って実践すること
- チームとステークホルダー全員がスクラムの意図を正しく理解し、共有すること
- 組織体制に余裕があり、学習と改善に時間を割ける環境を整えること
これらが揃って初めて、スクラムは効果を発揮するのだと思います。
私自身、まだスクラムマスターとして未熟ですが、まずはチームにスクラムの本質を伝え、できるところから改善を積み重ねていきたいと考えています。
今後も試行錯誤を続けながら、チームがより自律的に成長できるスクラムを実現していきたいです。
今はスクラムの導入段階なので、これからスクラムを導入してチームがどう変わったかを今後の記事で共有していきたいと思います。
