はじめに

この記事は弥生 Advent Calender 2023 の25日目の記事です。

こんにちは。2023年4月に弥生株式会社に入社したTakumioooです。

メリークリスマス皆さんいかがお過ごしでしょうか？
クリスマスといえば、イルミネーションですね。きれいですよねイルミネーション。
イルミネーションを見ると、電飾の回路構成と、消費電力が気になりますよね。制御コードもどんな内容なのか気になります。規模が大きくなると信号の遅延もあるため、アニメーションのようなものを表現しようとすると、結構大変だと思うんですよね。

まぁ、そんなことはさておき、私は現在、でスクラムマスター担当しています。
弥生に入社してからスクラムマスターとして働き始めたため、まだまだひよっこです。
今回の記事では、スクラムマスター初心者が、スクラムマスターになってからここまで何をしてきたのかを備忘録もかねて書いていこうと思います。

スクラムマスターになった経緯

弥生では、2023年4月ごろからサービス開発にスクラム開発を導入しています。今までは、U字プロセスという、ウォーターフォール開発のV字プロセスをベースに、できるだけ手戻りを減らすことを意識した開発プロセスで開発をしていました。基本はウォーターフォールなので、市場へのリリースする期間や、ユーザーフィードバックを反映し、改善する期間が課題となっていました。
そこで、スクラム開発を導入し、サービスの市場への投入、ユーザーフィードバックの反映を素早く行い、顧客へ価値を素早く届けるための体制づくりを進めています。

そんな中で、いいタイミングで、少しだけスクラム開発の経験（1年未満）がある私が入社しました。入社時点では、スクラムマスターをやる予定など微塵もありませんでした。
そしていろいろあり、スクラムマスターを担当することとなりました。
スクラムマスターを担当すると決まったタイミングでは、スクラムマスターが何をやるかなどほぼ知りません。そもそもスクラム開発についての、知識、理解も足りません。何もわからない状態でした。

スクラムマスターになってからやったこと

知識的な部分

まずは、アジャイルマニフェスト開発宣言、スクラムガイドを読みました。
最初にスクラムガイドを読んだ時の感想は、「何も分からねぇ...」でした。

スクラムガイドにも書かれているように、あくまでガイドであり、不完全なものになっています。何をすべきとも書いていません。
そこでさらに知識を得るために、いくつかスクラム開発に関する書籍を読みました。

書籍には、スクラム開発の全体像や、スクラムイベントでは何をするのか、どの様に運営するかなどが書かれており、実例なども含まれているため、スクラムガイドを補完するようなことを知ることができました。

さらに、弥生ではアジャイルや、スクラム開発について社内教育も実施し、会社全体でアジャイルな状態を目指しています。社内教育を実施することで、アジャイルやスクラムが共通言語になりとても良いと思いました。

いろいろなできごと

EBA

しかし、知識として知っていることと、やった経験があることには大きな壁があります。
それを、EBAというイベントで実感しました。
EBAの詳細については以下の記事をご覧ください。実事例として参考にしていただけると思います。

EBAには、パーティーと、パーティー準備期間があり、特に準備期間で経験不足を実感しました。

まずは、1か月という準備期間で、何をし、パーティーで何ができそうかを議論しました。
しかし、議論の中でスクラムマスターとして何をすべきなのかが分からない。この時は、プロジェクトマネージャーの経験しかなかったので、何をいつまでにやるかという点を気にして、なぜやるかや、顧客価値とは何かなどを議論できたらよかったなとふりかえって思います。
ただそんな中でも、議論を繰り返す中でメンバー間の壁も徐々になくなっていき、議論がどんどん活発になっていきました。さらに、スプリント期間を切り、プランニングでゴールを決め、レトロスペクティブでふりかえるという流れが作れたのはとてもよかったなと思いました。AWSさんの支援にもとても感謝しています。
その後、スクラムイベントはEBAのリズムを崩さないよう、変更せず継続することにしました。

しかし、1～2スプリントほど実施したあとの振り返りで、

EBAでできていた議論ができなくなった
EBAでは短期間の方向性を決めていたが、プロジェクト全体となると方向が定まらず、バラバラの認識をしていると感じる

と意見が上がり、メンバーそれぞれが、チームの状態、プロジェクト全体を考えていることが分かって、とてもいい状態だなと感じました。加えて、チームの状態を維持することの難しさを感じました。

そんななか、スプリントを回しながらチームで考えながら、いろいろな工夫をしてきました。

サービスの担当を分ける

私のチームは、いくつかのサービスを1チームで開発する体制を取っていました。
しかし、複数のサービスをそれぞれのメンバーが見ないといけないため、内容把握に時間がかかったり、コミュニケーションコストが高いという課題が上がりました。そのため、サービスごとに2~3名で担当を分けることにしました。
今もこの体制は続けており、順調にプロジェクトも進んでいます。

メリットとして、

コミュニケーションコストが下がった
開発が早くなった
見る領域が小さくなったので、集中できる

ただ、デメリットもあり、

自分が担当になったサービス以外のサービスのことを理解しにくくなった

と、メンバーから意見が上がりました。
結果的に良い状態が続いていますが、どこかの担当メンバーが不在の際に、担当サービスの開発が止まることや、メンバー間の助け合いが難しくなるなど、リスクもあるなと考えています。

スプリント期間の変更

これは、あまり良くないといわれているパターンです。
良くないといわれている背景として、

それまでのスプリントで計測してきたベロシティが、使えなくなる
ユーザーへの価値提供が遅くなる（期間を延ばした場合）

のようなものがあります。
しかし、私たちはもともと1週間で回していたスプリントを2週間に変更しました。
これもチームで議論した結果ですが、

スプリントごとにリリースはしたいが、PBIのサイズが1週間で作りこむのが難しく、インクリメントとして挙げることができない。
スプリント2回分でリリースする対応もできるが、1スプリントごとにスプリントイベントがあるのがやりにくい

という課題があり、スプリント期間を2週間にし、開発を進めることにしました。
実際に2週間にすることで、1週間スプリントを回していた時よりも、スプリントゴールを達成する確度が増し、スプリントごとにインクリメントを積み上げることができるようになりました。
このアプローチしかなかったのかといわれると、いろいろと対応方法はあったかもしれません。
さらに、アンチパターンといわれていることをやるのは、私自身としては抵抗がありました。しかし、アンチパターンといわれているものも、チームの状態をみて、議論することでそのチームに合った状態になるなら、試してみるのも大切だなととてもよい学びになりました。

他にもいろいろありながらチームで考えて開発を進めています。

認定スクラムマスター（CSM）を取得

そして、スクラムマスターとして、半年ほどたったころにCSMの講座を受け、資格を取得しました。
この講座は衝撃的でした。スクラムマスターとしてのスタンスや、考え方は間違っている部分が多かったと感じました。
詳しい話を書くといろいろとネタバレになってしまうので、詳細は省きますが、スクラムマスターを目指す方や、スクラムマスターをしているが、まだ取得していない方は、odd-e Japanの認定スクラムマスター（CSM®）トレーニングを受講することをおすすめします。
https://www.odd-e.jp/ja/

終わりに

少し長くなってしまいましたが、弥生に入社してから約8ヵ月でいろいろな壁にぶつかり、悩みながらスクラムマスターとして日々悩み続けています。
ですが、チーム全員で考え、年齢、経歴関係なく議論をし、より良い方向を探しながらプロジェクトを進め、チームの変化を見てるのはとても楽しいです！
チームメンバーからも、レビューだけでなくコードが書けて楽しいとか、コーディングだけでなく、設計から参加できるので、新しいことに挑戦できてうれしいと声を聴くこともあり、とてもいいチームだと嬉しく思います。

これからもチームが良くなるために貢献できるよう頑張っていきたいと思います！！

そして、弥生はスクラムマスターを募集しています。
一緒にいいチーム、いい組織を作りましょう！！

以上！