こうして私はスクラムマスターをやめた。【アジャイル開発エンジニア勉強会/イベントレポート】

 

登壇者はこの方

*

小林壮太 氏

パーソルキャリア株式会社
リードエンジニア

2021年にパーソルキャリアに新卒入社。アプリ開発チームのバックエンドエンジニア、スクラムマスターを経て、現在はマイクロサービス化に取り組んでいる。好きな振り返りフレームワークはeffort & painと555(Triple Nickels)です。

 

小林:今回は、「スクラムの基礎」はご存じの前提で、スクラムマスターを引き継ぐときに必要だったことを、実務経験に基づいてお話しします。

なお、以下の2点は今回のセッションでは扱いません。

  • スクラムマスターの採用方法
  • スクラムそのものの基礎的な話

スクラムマスターを卒業したくなった理由

突然ですが、皆さんは「別の職種にチャレンジしてみたい」と思ったことはありませんか?

職種を変えるタイミングはいろいろとあると思いますが、スクラムマスターも同じで、さまざまな理由からその役割を離れたくなるタイミングが訪れます。

例えば

  • チーム単位ではなく、会社全体の開発を見ていきたいという視座の変化
  • エンジニアからスクラムマスターになったが、やはり技術に戻りたくなった

 

私の場合は、モダンな技術の習得とスクラムマスターとしての経験を両立させたいと考えたのがきっかけです。

しかし、役割を放り出して辞めるわけにはいきません。そこで私は、スクラムマスターの仕事を次の人に引き継ぐことに決めました

スクラムマスターとは何をする人か?

まず引き継ぎをする前に、「そもそもスクラムマスターとは何をする人なのか?」を整理しました。よくあるイメージとして、

  • 実務をしないでチームをコーチングする人
  • 正直何をやっているかよくわからない人

…という印象を持たれがちです。

ですが本来、スクラムマスターは、スクラムの理論とプラクティスを理解し、それらを用いてチームが効果的に機能するよう支援する役割です。

 

つまり、チームで最もスクラムに精通し、かつ実践的に活用できる人がスクラムマスターです。

スクラムマスターのゴール

スクラムガイドには、スクラムマスターの役割として「自己管理型かつ機能横断型のチームをコーチする」とあります。

 

この状態を極めると、もはやスクラムマスターが不要になるようなチームが出来上がります。しかし、スクラムマスターはスクラムにおける必須ロールです。つまり、スクラムマスターのゴールは、チームの1歩先をリードし続け、組織やプロダクト全体に良い影響を与え続けることだと考えています。

そのためには、スクラムの枠にとらわれず、あらゆる改善に取り組めることが必要です。私自身もこの自由度と裁量の広さに、このロールの魅力を感じていました。

実際にどのようにスクラムマスターの引き継ぎを行ったのか

では、スクラムマスターの定義ができたところで、実際にどのように引き継いでいったのかお話したいと思います。

引継ぎ時に実施したこと

スクラムマスター候補の選定

十分な引き継ぎ期間が取れなかったため、「スクラムマスターの素質があると判断した人」に集中して教える戦略を取りました。
候補者を選ぶ上で重視したのは次の2点です:

  • やってみたい意志があるか(やる気の確認)
  • ロールがなくても現状を変えようとする姿勢があるか

スクラムマスターの仕事はやりがいがありますが、大変なことも多いため、押し付けと受け取られてしまうと疲弊させてしまう可能性があります。また、スクラムは改善を重ねるフレームワークなので、「現状を良くしよう」とする意志が何より大事です。

チーム内の役割の委譲 

私が持っていた役割は以下の2つです:

  • イベントのファシリテーター
  • 組織へのアカウンタビリティ(成果報告など)

スクラム体制が有用であることを会社に説明し、継続的に支援を得るためには、スクラムマスターが「価値を説明できること」が非常に重要だと感じていました。

振り返りのしやすさの向上

最後は、振り返りのしやすさの向上です。

スクラムマスターの引き継ぎにあたって「振り返りのしやすさ」を高めるために、以下の3つの施策を実施しました。

 

定量指標の導入

まず1つ目は、「定量的な指標を取り入れること」でした。

それまでのチームでは、スクラムマスターとメンバーで課題認識にズレがあることがありました。というのも、数値による状況把握ができる仕組みが整っておらず、感覚的な判断に頼らざるを得ない場面が多かったからです。

 

さらに、数値を使いたい場面でも、データの集計が手作業だったために時間と労力がかかっていました。本来はスクラムマスターを引き継ぐ前に対応しておきたかった課題でしたが、たまたま社内ツールの導入に前向きな流れがあったため、引き継ぎのタイミングで取り組むことができました。

導入したツールは以下の2つです:

 

 CAT(テスト管理ツール)
  → テスト実行状況や品質担保レベルを定量的に可視化


Findy Team+
  → 開発生産性を数値で見える化

 

CATの値

CATによって、テストの実行率や品質指標を定期的に可視化できるようになりました。
これにより、「振り返るべきポイント」が誰の目にも明確になり、客観的な議論がしやすくなりました。

 

なぜ定量化が重要だったのか?

導入した指標の目的は、次の2つの軸を明確にすることでした:

  • 生産性を向上させること(量の確保)
  • 品質を高水準で維持すること(質の担保)

私は、スクラムにおいて生産性は高ければ高いほど良いと考えています。
 それによって、スクラムの基本原則である「透明性・検査・適応」のサイクルをより速く回すことができるからです。

 

しかし一方で、アウトプットが多くてもバグや障害が多ければ本末転倒です。
そのため、生産性と品質の両方を定量的に示す指標を整備することが、スクラムの改善に不可欠だと考えています。

 

これらのデータをもとにスクラムの運用ルールを見直すことで、より実践的で説得力のあるチーム運営が可能になります。

論理的思考能力の強化

最後の施策は、論理的思考力の強化です。
スクラムマスターが自己管理型・機能横断型のチームを育てるためには、チームの出す答えを一歩上回る必要があります。
つまり、スクラム理論とプラクティスを深く理解し、それを状況に応じて的確に伝えるスキルが求められます。

 

ここでいう「プラクティス」は、よく知られた手法(ストーリーポイントやKPTなど)に限りません。チーム独自の運用ルールやノウハウも含め、それらを改善し続けることで、プロダクトゴールに近づけるチームへと進化していきます。

おわりに

スクラムマスターという役割は、単にチームを支援するだけでなく、仮説を立て、実践し、チームとプロダクトをより良い方向に導くという非常に面白く、挑戦しがいのある役割だと思います。

 

今回は「引き継ぎ」というテーマでお話しましたが、少しでもスクラムマスターの魅力が伝わっていたら嬉しいです。

 


以上で、発表は終わりです。

 

▼▼ぜひ他登壇者の発表レポートもご覧ください

アジャイル開発エンジニア勉強会
イベント中にあがったQ&Aはこちらをチェック!

www.tech-street.jp

 

こうして私はスクラムマスターをやめた。

小林壮太さんの発表内容については、以下の記事リンクからご覧ください。

こうして私はスクラムマスターをやめた。【アジャイル開発エンジニア勉強会/イベントレポート】 - TECH Street (テックストリート)

 

スクラムマスターなしでもいい感じにスクラム開発している
日下 亜紀子さんの発表内容については、以下の記事リンクからご覧ください。

スクラムマスターなしでもいい感じにスクラム開発している話【アジャイル開発エンジニア勉強会/イベントレポート】 - TECH Street (テックストリート)

 

スクラムとウォーターフォールの間で開発スタイルを模索している話
ウチノさんの発表内容については、以下の記事リンクからご覧ください。

スクラムとウォーターフォールの間で開発スタイルを模索している話【アジャイル開発エンジニア勉強会/イベントレポート】 - TECH Street (テックストリート)

Community Members

さまざまなテーマで事例や知見を学ぶ
IT・テクノロジー人材のための勉強会コミュニティ