はじめに
こんにちは。サービスインフラチームの清水と申します。
ニフティではスクラム開発が様々なチームやプロダクトに導入されています。私も現在のチームに配属されてから開発メンバーとして4年ほどスクラム開発を行ってきました。 社内でスクラム開発を導入するチームが増えていく中、スクラムマスターも増やそうといった動きがあり、2021年12月、機会にも恵まれ Scrum Alliance 社主催の認定スクラムマスター研修に参加し、認定スクラムマスターの資格を取得することができました。以来チームのスクラムマスターとして活動しています。
今回は一般エンジニアがスクラムマスターになって、どんなことを考えながら取り組んでいるか、自分のケースを取り上げて学びや試行錯誤についてお話したいと思います。まだまだ新米スクラムマスターですが、少しでも参考になれば幸いです。
サービスインフラチームでは、ID管理・決済・サービス申し込みといったシステムの開発・運用を行っています。詳しくは 基幹システムグループ サービスインフラチームの紹介です – NIFTY engineering をご覧ください！
チームを見つめ直そう
まずは、スクラムチームがいまどのような状態かを見つめ直すことから始めました。
いち開発メンバーの視点から見ると、私の属するスクラムチームはうまく機能しているように感じていました。各種イベントの実施や定期的なリリース、イテレーションによるチームの成長……。しかし4年という歳月の間にはスクラムガイドの改定も行われ、メンバー間でスクラムに対する認識のズレが生まれていました。そして、メンバーにとって居心地の良い我流のスクラムとなっていきました。
もちろんスクラムガイドには具体的な方法が書かれていないので、チームにフィットするやり方でスクラムを適用するのはむしろ望ましいことです。しかし、私のチームには以下の問題がありました。
- マネージャーがスクラムマスターを兼任しすべてやってしまいがち
- プロダクトオーナーが不在
マネージャーがスクラムマスターを兼任すると、メンバーに声が届きやすくチームビルディングが行いやすい反面、マネージャーに一極集中しやすいという問題があります。これについてはスクラムマスターの権限委譲をしてもらうことで形式上解消されました。その後自分がスクラムマスターとしてうまくチームを機能させられるかどうかについては別の話ですが……。
一方、プロダクトオーナーがいないという点について、これはスクラムガイドに則っていないチーム体制であり、メスをいれるべきものです。 以前よりビジネス部門と連携を取りながら開発を進めていましたが、開発者とビジネス担当者での1対1のコミュニケーションになりがちで、部署間のコミュニケーションにどうしても隔たりが発生していました。そして開発側の調整役はしばしばマネージャーであり、マネージャーがチームにビジネス側の要件を共有するという形になっていました。ビジネスの観点からプロダクトの成長について考えられる人がいない状態、といったところでしょうか。
スーパーマンのマネージャーによって決定や調整、問題解決が行われており、チームとしてうまく機能しているように感じていても、実際は自己管理の意識が弱かったのかもしれません。
スクラムについて学び直す場を設けよう
認定スクラムマスター研修の中で印象的だった話に、LeSS の創始者の1人であるクレイグ・ラーマンが提唱する「ラーマンの法則」というものがあります。 組織構造と文化に関する内容ですが、スクラムに当てはめてみると次のようになると言っていました。
「今やっている仕事をスクラムの用語で置き換えてしまい、本来あるべきスクラムチームの形ではなくなってしまう。」
私のチームも、スクラムに対する認識のズレを感じていたものの、それがチーム内の共通認識となっていました。研修でこの話を聞いたとき、まさに自分たちのことのように感じました。
そこで、改めてスクラムを学び直す機会を設けました。具体的には、改定後のスクラムガイドを読んでもらう、認定スクラムマスター研修で学んだ内容を「スクラム再入門」と題してチームメンバーへのアウトプットを行うなどです。
あわせてインプットも積極的に行いました。SCRUMMASTER THE BOOK やアジャイルレトロスペクティブズといったスクラム関連の書籍を読み、研修の内容と照らし合わせながら理解を深めるとともに、スクラム・アジャイル系の勉強会に参加して他社のスクラム事例やノウハウを学ぶ、といった具合です。
ただ、これらは一度やれば良いというものではなく、定期的に行うことが重要に感じています。単純にスクラムについての理解を深めるだけでなく、自分たちの都合のいいようにスクラムを解釈していないか？チームの組織構造はどうか？といった点に気づける機会にもなります。新しいメンバーがジョインしたら勉強会を開いたり、数ヶ月に1回スクラムガイドの輪読会を行うなど、慣れてきたタイミングで改めて学び直すようにしたいですね。
プロダクトオーナーを立てよう
私のチームの問題としてあったプロダクトオーナー不在問題を解消するべく、ビジネス部門の中で以前からメインにやり取りしている方にプロダクトオーナーの打診をしました。お願いをするにあたり
- スクラムの概要
- プロダクトオーナーの役割
- 具体的にやってほしいこと
を説明し、プロダクトのこれからについて一緒に考えていきませんか？といったことを伝えました。
スクラムの各種イベントに時間が取られたり新しい概念を取り入れる必要があるため、いきなりプロダクトオーナーの仕事をすべて任せるのは難しいと考え、まずはレビューやレトロスペクティブなどからイベントに参加してもらうなど段階的にチームにジョインしてもらうことにしました。
話を進めていくと、ビジネス部門も私たちが感じていた組織感でのコミュニケーションなどについて課題を感じていたことがわかりました。プロダクトのこれからの方向性やビジネス側のビジョンなどについても話したいと、ありがたいことにスクラムについて理解を示していただき、プロダクトオーナーも快諾していただけました。
まだプロダクトオーナーがジョインして時間もあまり経っていませんが、プロダクトオーナーの意見をもらえる場ができたことで、今まではなかったビジネスの視点についてチーム全体で考えられるようになっていると実感しています。
私のチームがそうだったように、ニフティの他スクラムチームもプロダクトオーナーが不在という問題を耳にします。ビジネス部門の中にはまだスクラムが浸透できていない部分もあるため、他チームのスクラムマスターと協力して組織の体制なども変えられるよう活動していく必要がありそうです。
スクラムマスターのスキルセットを意識しよう
スクラムマスターに必要なスキルでよく言われるものとして、以下の5つがあげられます。
- ティーチング
- ファシリテーリング
- メンタリング
- コーチング
- シチュエーショナリング
いわゆるソフトスキルと呼ばれるものですが、エンジニアのキャリアとしてこうしたスキルに触れる機会が少なく感じます。それぞれなんとなく理解できるのですが、いざ実践しようとすると非常に難しく試行錯誤の連続です。
たとえばスクラムイベント1つを取っても、参加する側からファシリテーションする側になったことで、メンバーが発言しやすい場にするにはどうすればよいか考えなければなりません。また、タイムボックス内でスムーズにミーティングを終わらせるために、ミーティングの事前準備がいかに重要か身をもって感じるようになりました。
ほかにも、チームの透明性が担保されているか俯瞰して見る必要があります。今までは、自分たちが作る成果物 (ソースコード・機能など) について集中していましたが、チームが自己管理できている状態にあるのか、チームの障害となっているものは無いかなど、成果物だけでなくチーム全体を見るように意識が変わりました。 このあたりは新米スクラムマスターにとってはなかなか難しいと感じていますが、幸いチームにこういった視点を持ったメンバーがいるため、相談しながら考えることができており非常に助かっています。
今までとは違った能力が要求され大変なことも多いですが、その分今までとは違った分野での成長を実感しています。チームビルディングやマネジメントといった方向のキャリアパスにも興味を持ち始めてきました。個人の選択肢が広がったように感じます。
相談できる場を作ろう
スクラムマスターはひとりになりがちです。問題に直面したとき常に明確な答えがあることは少なく、特に新米スクラムマスターは経験も浅いため、一人ではどうすることもできない状況がしばしばあります。 そのため、スクラムマスターとしての悩みを相談できる場を確保しておくことが重要です。
スクラムチームというとチーム内で完結してしまうようにイメージしがちですが、スクラムマスター同士のつながりは非常に大切で、スクラムマスターの協働によって組織が変わっていく、と研修で教わりました。 他のスクラムマスターの経験を知ることもまた自分の経験に繋がります。知り合いのスクラムマスターに相談するのも良いですし、社内外のスクラムコミュニティに参加して他チームの事例などを知るだけでも非常に学びがあります。
ニフティでは社内のスクラムマスターが集まって良かったことの共有や悩みを相談する「スクラムマスター共有会」というものが月に1度開催されています。私もこの会には非常に助けられています。自分の悩みを相談するだけでなく、他のスクラムマスターがどのような悩みを抱えているのかを知る機会にもなるため、ニフティのスクラムマスター全体として集合知、経験が培われる非常に良い循環となっていると感じています。
おわりに
約半年スクラムマスターを経験して感じたのは、これらは一朝一夕で習得できるものではなく、常に意識しながら実践と経験を積み重ねることで培われるということです。 スクラムが経験主義のフレームワークであるように、スクラムマスターもチームとともに経験して成長していくものだと感じました。
新米スクラムマスターの私の経験が、どこか他のスクラムチームの一助となれば嬉しい限りです。
