スクラムマスターになって１年経った

昨年11月からネットオン開発チームのスクラムマスターをやっています。ぐっさんです。

前々スクラムマスターDさん、前スクラムマスターたけむらさんらの築いたネットオン開発チームのスクラムのかたちを引継ぎつつ、いいところは残し、環境に合わなくなったところはテコ入れし…と、いろいろ奮闘していたところあっという間に１年が経ちました。

ちょうどブログの当番が回ってきましたのでこの機に振り返ってみたいと思います。

そもそもスクラムとは、スクラムマスターとは

スクラムガイドを再読しました。(日本語版PDFが「Download the official Scrum Guide」にあります)

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。

簡単に⾔えば、スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。

プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに並べる。

スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。

スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。

繰り返す。

はい。

ざっくりですが、スプリント中に実施するタスクを準備する→こなす→こなした結果を振り返り、次のスプリントに生かす。スクラムマスターはその活動をいい感じに促進する。ということしょうか。

スクラムはシンプルである。まずはそのままの状態で試してほしい。そして、スクラムの哲学、理論、構造が、ゴールを達成し、価値を⽣み出すかどうかを判断してほしい。スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。スクラムは実践する⼈たちの集合知で構築されている。スクラムのルールは詳細な指⽰を提供するものではなく、実践者の関係性や相互作⽤をガイドするものである。

スクラムフレームワークの中で、さまざまなプロセス、技法、⼿法を使⽤できる。スクラムは既存のプラクティスを包み込む。あるいは、その存在を不要にする。スクラムによって現在のマネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になるのである。

……ともあるように、スクラムフレームワーク自体は非常にシンプルです。なので、チームによってスクラムのありかたは特色があるでしょう。ネットオン開発チームのスクラムも、他社の開発チームのスクラムとは異なる物になっていると思います。

ネットオン開発チームのスクラム

現在のネットオン開発チームの体制はスクラムマスター１名・プロダクトオーナー１名・テックリードを含む開発者数名の構成です。同一スクラムチームではありませんが、デザインチーム・マーケティングチームも別に存在し、ともにプロジェクトに取り組んでいます。

1スプリントは2週間(10営業日)、月曜開始～翌週金曜の午前中までをタスクの遂行時間としています。

下記のような定期MTGにて情報共有や課題の解決、物事の合意をとりつつ、スプリント毎のゴール達成に向けて、実施すべきタスクをバックログより選定して進行します。

デイリースクラム

毎日の始業時・終業前に朝会・夕会として実施します。おもに下記の共有を行い、発生したタスクは当日・翌日の予定にモレのないよう組み込みます。

システム不具合情報の共有
- ユーザー(社外・社内)からの、システム不具合・クレーム情報
- システムアラート
今日やること・やったこと
困っていること

朝会・夕会ともに10～15分ずつ程度の開催のため、1日30分程度、必ず情報共有に割いていることになります。数値で見ると多いようにも感じられますが、開発チームは原則フルリモートワークでメンバー全員が自宅で業務にあたっているため、意図的に会話をする・気持ちを切り替える場を設けているという側面もあり、必要な時間と感じています。

スプリント遂行のため、スクラムマスターとして気を使っている点としては、以下のようなものがあります。

メンバーが自ら行動を考え、決めるための情報提供がなされること（タスクの優先度付けなど）
今、どのメンバーが、どのタスクを、どこまで遂行しているか開示されること
メンバーが困っている・人手を欲していることがあれば開示され、チーム内で必要なヘルプやアサインがされること

スプリントゴールに向かってメンバーが迷いや滞りなく担当タスクを全うできるよう、進めるべきものが進むよう、止めるべきものがあれば止めるようにガイドをしています。

ふりかえり(レトロスペクティブ)

スプリント最終日(隔週金曜)の午後、スプリントを終えた後に行う振り返りのミーティングです。お互いをねぎらい、次のスプリントに生かすための行動を抽出します。

メンバー間で Thank you! & Good Job!のフィードバック
今スプリント「チャレンジしてみたこと」の共有
KPT法によるふりかえり共有
- Keep（継続したいこと、やりやすかったこと）
- Problem (問題視していること・改善したいこと、やりにくかったこと)
- Try(試したいこと)
- Action（次スプリントで実施する行動）

スクラムマスターとしては「何らかの行動を抽出したものの実施されない」となるともったいないため、MTG後に簡単な議事メモを作成しリマインドや実施者のアサインを行うよう心掛けています。

ただ、TryやActionの当事者メンバーはもっと仕事を良くしたい！と解決に燃えていることが多いので、あまりほったらかしになることはなく、毎スプリントコツコツと着実・確実にカイゼンを行えるのがネットオン開発チームの空気感だと思っています。

スプリントプランニング

ふりかえりののち、次回のスプリントでこなすタスクをバックログから決定します。バックログに蓄積されるタスクは主に記に分類され、発生経緯はさまざまです。

採用係長機能開発
会社やプロダクトの経営課題を解決するための機能開発をするタスク。採用係長の価値向上、販売メニューの追加、営業・サポート人員のオペレーション低減など多岐にわたります。プロダクトオーナーを含む役員MTGにて実行が決定された内容がタスク化されます。役員MTGには経営者だけではなく営業・開発現場からの意見も上がっているので、実情の反映された開発が行われます。
販売管理
採用係長にまつわる販売活動の管理システム整備や会計へ連動するデータ等の管理を行うタスクです。
インフラメンテナンス
アプリケーションサーバ・データベース等のシステムインフラ整備を行うタスクです。
バグ対応
採用係長、社内管理システム、また、開発者の利用するツール等が期待通りに動作していない場合に修繕を行うタスクです。

ネットオン開発チームではタスクの見積をStoryPointで行います。毎スプリントの平均消化StoryPoint、営業日数・休暇、その他社内行事などを考慮し、次のスプリントで何StoryPoint分のタスクを実行するか、キャパシティの上限を決定します。StoryPointの尺度はネットオン開発チーム内で共有している体感的なもののため、外部から感覚共有することは難しいのですが、現在、スプリント毎におおよそ70～80pt程度の仕事をこなしています。

必要に応じて各タスクの見積やメンバーアサインを行い、次回のスプリント内容を決定します。

チーム運営について

ネットオン開発チームの特色がある取り組みと呼べそうなものに、「ギルド」があります。チーム内のサブチームのようなものですが、スクラムガイドによると、通常、スクラムにはサブチームは存在しません。ギルドは「スプリントゴールを目的としたサブチーム」ではなく、「チーム内の自治・学習を活性化するためのチーム」として機能しており、ギルドにスプリントゴールの責務はありません。

大別して自治ギルド・学習ギルドの２種があります。

自治ギルド

日々の業務を効率化・安定化させる取り組みが主のギルドです。学校のクラス委員会活動に近い感覚だなと個人的に思っています。

ナレッジ委員
開発業務において蓄積されていくさまざまなナレッジを整備・活用するためのギルドです。詳しくはナレッジ委員長かきびぃの記事があります！
不具合発生防止／テスト戦略ギルド
開発チームの主なミッションは、当社プロダクト「採用係長」の「安定稼働」「迅速な機能リリース」ですが、これらのミッション遂行のためのソフトウェアテストのあり方を考え、実行するギルドです。テストケースのありかたやログやアラート出力方法を考えオーソライズしたり、Jest等で準備している自動ユニットテストコードの定期メンテナンス等を実施しています。
スタイロギルド
フロントエンドエンジニアとWebデザイナー間の連携を強化し、採用係長のUI/UXをよりよいものとしていくためのギルドです。目下は両者で共有するフロントエンドのデザインガイドラインや、TailwindCSSの設定・整備などを行っています。

学習ギルド

自治ギルドのように役割は持たず、特定の分野について新たに経験を積みたい場合や、属人化を解消したい場合等に経験機会を増やすためのギルドです。所属メンバーへ特定分野のタスクについて優先的にアサインするための枠組みです。

以下は過去の学習ギルドの例です。それぞれ業務経験の少ないメンバーが各ギルドへ所属し、経験の少ない業務を優先的にアサインすること学習機会として役立てていただきました。現在は役割を終えて解散しており、現在は別の専門技術ギルドが発足しています。

要件定義・設計ギルド
抽象的な課題から要件の抽出、設計を行い、具体的なプログラム成果物へ落とし込む経験を積む
小規模プロジェクトリーダー
２～３名・１～２ヶ月規模程度で開発を行うプロジェクトについてタスク分解・スケジューリング等を取りまとめ、機能のリリースまで遂行させる経験を積む

難しいこと、うまくいってること

私がスクラムマスターになる以前からネットオン開発チームのスクラムのかたちは既に存在しており、導入の苦しみのような経験は特にしていません。先人の作った基礎があるだけに、スクラムマスター就任直後には継続した運営を行うため右も左もわからず右往左往していました。ですが、現在は既存のものをただマネし続けるだけではなく、会社やプロダクトをとりまく環境への適応や、自らの考えによるカイゼンを行い、変化させつつも安定したチーム運営ができています。多分。

就任当初に難しかったのは

バックログに蓄積されているタスクの内容が理解できない
バックログの整理が追い付かない
スプリントの集計業務に不慣れで時間がかかりすぎる

など、事務的な物事が多くありましたが、「タスクを、担当したメンバーに一任する」ということの精神的ハードルを乗り越えることが最も難しかったかもしれません。

バックログに蓄積されたタスクの遂行には特定分野への深い造詣が必要なものももちろん含まれており、私自身にはそうやすやすと実行できないだろう、と感じるタスクも多くあります。その時、「自分には遂行できないかもしれないものを、メンバーにまるっと一任していいのだろうか？」という不安や心配がありました。

ただ、これはチーム論・リーダー論にも通じるのですが、リーダーはメンバーよりも必ずしもタスクの遂行能力が上回っている必要はないのです。リーダー／スクラムマスターは、メンバーに活躍してもらい、スプリントで生み出す価値を最大化することが仕事である。ということが腑に落ちてからは、得意なメンバーにどんどん任せる！そして、得意分野や自分のフィールドに自信や誇りを持つことのできたメンバーは、自らどんどん成果をあげ、さらに活躍の場を広げる！というサイクルができあがっていったように思います。

スクラムの価値基準に以下の５つがありますが、「勇気（Courage）」を勇気を持つことでスクラムの価値を実践できたということかと思います。