こんにちはBacklogの生成AIチームのテリーです。

先日Scrum Inc.Japanの認定スクラムマスター研修を受けてきましたのでその内容をこのブログにまとめます。

スクラムマスターの研修に興味を持っている方などのお役に立てる記事になればと思います。

研修について

Scrum Inc.のスクラムマスター研修は、Jeff Sutherland、スクラムの共同創設者によって設立された組織によって提供されるプログラムです。この研修は、参加者にスクラムフレームワークの深い理解を提供し、実践的なスキルを身につけさせることを目的としています。

研修を完了すると、参加者はScrum Inc.からスクラムマスターの認定試験を受ける資格が与えられます。私はまだ認定試験の受験はしてませんが、これから時間を作って受けたいと思います。

内容について

この研修では、スクラムフレームワークの基本原則や実践方法に焦点を当てていました。参加者は、スクラムの重要性と、これらがチームの成功にどのように貢献するかを学ぶことができました。また、バックログ管理、スプリント計画、デイリースクラムミーティング、スプリントレビュー、スプリントレトロスペクティブなど、スクラムにおけるプロセスの各ステージについて詳しく解説されていました。

研修は理論と実践のバランスを取りながら、チームとしての協力と効率的なプロジェクト管理を促進する方法を学べるように設計されており、私の他にスクラム初心者が多いチームでしたが誰も取り残されることなく研修を走り切りることができました。

自分のステータスと学びについて

私の所属していたGitチームではいくつかのプロジェクト進行にスクラムのプロセスを利用していました。Gitチームにスクラム経験者がいること、社内にスクラムのプロセスに精通しているメンバーもおり今回学んだようなイベントやプロセスでプロジェクトを進めることができました。

実際に厳格なスクラム（このような言葉あるのかはわかりませんが）を適用するのはかなりチームとしてはコストがかかるように感じ現在はそのエッセンス(レトロスペクティブ、スプリントプランニング、スプリントレビューなど)をいくつかを使用した開発プロセスになっています。

以上のような背景で、会社でスクラムに詳しい人に色々教えてもらうだけでも十分学びになっていたのですが、一回体系的にスクラムのプロセス全体を知っておきたいというモチベーションで今回の研修に参加しました。

研修の感触

このプログラムはスクラムの理論と実践のバランスが非常によく取れていると感じました。講師からの具体的な事例と実践的な演習が豊富にあり、理論だけでなく、実際のプロジェクト管理におけるスクラムの適用方法を深く理解することができました。

また、Zoomを使用したバーチャルクラス形式での実施は、参加者同士の協力や交流を促進し、リアルタイムでのフィードバックや質問が可能であったため、学習体験をより豊かなものにしていました。全体を通して、この研修はスクラムマスターとしてのスキルを高め、効果的なチームワークとプロジェクトの成功に向けて必要な知識と自信を身につけられたように感じます。

もうスクラムマスターのことは任すー

受講前はスクラム？怖い。くらいの感覚だったんですが、受講後は怖さは消えて、良い開発プロセスだなぁと素直に思えるようになりました。ただ今の所まだ自分がスクラムマスターとなってこのプロセスを回すぞーっとなるまでモチベーションは高まっていません。とはいえスクラムを実際のチームに導入する際には理解できた部分もあるのでメンバーとして今回学んだエッセンスを通じて実践していきたいです。

また今回の研修中に気にいったポイントがいくつかあったので抜粋します。

T型人材

T型人材とは特定の専門分野に深い知識を持ちながらも、他の分野に対する理解やスキルを横断的に持つ人材を指します。この概念は、多様なスキルセットを持ち、チーム内で幅広い役割を果たすことができる人材を意味します。

Gitチームでは機能横断な人材が揃い、仕事を成し遂げるために必要なすべてのスキルを持っているチームになっており変化に強く効率的なチームの運営ができているように感じます。

スウォーミング

無数の虫が何かの場所や標的に群がって何かを行うことを表す英語です。英単語の意味の通りチームが特定の課題や障害に対して集中的に取り組み、それを速やかに解決するために協力するプラクティスです。

ペアプロやモブプロで難しい課題をみんなで寄ってたかって倒して行った経験が何回もあるため腑に落ちました。

仕事を終わらせる

チームメンバーが一度に一つのタスクに集中し、それを完了させることを奨励することで、無用なコンテキストスイッチを避け仕事の質と効率を高めることを目指します。これはスウォーミングにも通ずる手法に思えます。タスクのコンテキストスイッチ（作業するタスクの切り替え時の無駄）を下げて一つ一つ優先度の高いタスクから終わらせていくという話です。

研修の中ではコンテキストスイッチがいかに無駄となるかという表も参照してくれて納得感のある説明でした。

参考: https://japan.devopsagileskills.org/multitasking-impact-on-productivity-in-a-devops-environment/ 

改善

スプリントレトロスペクティブ（スプリントに組み込まれている振り返り）で改善点を特定し次のスプリントでの実践するために優先度の高いスプリントバックログとして消化していきます。

Gitチームでも一週間毎に振り返りを行っており、そこで発見される改善タスクはチームにとって有益なものがかなりありました。

要員追加よりもプロセスの改善

バリューストリームマッピングを通じてプロダクト開発のボトルネックを検出することができるとの話がありました。プロセスタイムよりリードタイムに注目し部署を横断したスクラムチームがリードタイムを効率化できる可能性があります。

ボトルネックを潰す場合は市場に近い部分つまりデプロイの部分から行う方がリードタイムの削減がしやすいという話も参考になりました。

遅くなっているプロジェクトは人員の追加をどうしても考えてしまいがちです。プロセスの改善を含めたリードタイムの減少もプロジェクトの高速化に寄与するというのは当たり前のようですが自分の頭の引き出しになかったため勉強になりました。

その日のうちにバグを直す

発見されたバグや問題を迅速に対処し、修正することで、プロジェクトの進行における遅延を最小限に抑え、品質を維持することができます。

バグを見つけてBacklogに登録して数ヶ月後にその課題を確認しても何一つ覚えてなくて結局バグを再現するところから始めることになりかなり時間がかかってしまうことが多々あります。バグについては構造的で時間のかかりそうにないものでなければ早めに着手・完了させようと思いました。

まとめ

現場で働いている一ソフトウェア開発者として、近年特に顕著な社会の変化の速さについていかなければなりません。そんな時代を乗り切るためにもスクラム開発手法の学びを、変化に強く、より良いソフトウェアをリリースするチームの組成に生かしていけたらと思います。