ScrumMaster実体験 - FURYU Tech Blog - フリュー株式会社

1. はじめに
2. 前提
3. ScrumMaster活動記録
4. 課題
5. 課題を分析する
6. まとめ

1. はじめに

こんにちは。ピクトリンク事業部開発部開発1課に所属している村上です。

テックブログリレー５日目を担当します。４日目は昨日投稿された「アジャイル開発における改善の大切さを非エンジニアに説明してみた件」でした。

非エンジニアに対しての例え話がとてわかりやすかったです。SMとして非エンジニアに説明する際に活用させていただきます！

そして、5日目は開発者がScrumMasterになった実体験についてお話ししたいと思います。私自身ScrumMasterが、実際にどんな業務をするのか明確にわからないなかやってきたことや、やってみて見えてきた課題についてまとめていこうと思います。

この記事を書いてるのはこんな人です。

悪い人に見える(見えるだけ)
喋り出すとめちゃくちゃ喋る
ムーミンが好き

なぜ書こうと思ったのか

私の考え方や経験したことを共有することにより、同じような悩みを持っている方に少しでも参考になればと思い記事を書いております。

※課題の解決方法について具体的な解決策は記載していません。(所属する環境や立場によって変わるので参考にならないと考えた為です。)

2. 前提

構成
- フロントエンドとバックエンドの機能開発と機能改善を行うチーム（以降サイトチーム）
  - Developer: 7名（バックエンド：2名、フロントエンド:5名）
  - ScrumMaster: 1名
  - ProductOwner: 1名
  - ServiceDesigner: 1名
    - ユーザーストーリーの作成
    - ユーザーストーリーマップの作成
  - UIUXDesigner: 1名
    - 画面レイアウト、画面フローの作成
  - 計: 11名
スクラム関連
- スクラムイベント
  - 1スプリント = １週間
  - 下記の図のようにスクラムイベントの実施

事業部からサイトチームへの期待
- 他部署、他チームから依頼される施策の実施
- リリース速度の向上
- チーム内で課題を解決できる力を向上
プロダクトの性質
- サイトチームが担当するプロダクトは、長年稼働しているピクトリンクのバックエンドとフロントエンドの継続的な運営
- 機能に紐づくマイクロサービスが複数個存在し、サイトの機能変更により適宜他のマイクロサービスの改修を余儀なくされる

3. ScrumMaster活動記録

サイトチームのScrumMasterとしての活動です
- チーム結成期
  - インセプションデッキの実施
    - 我々はなぜここにいるのか？
      - 個人の強みや弱点を知る
      - チームの強みを知る
      - 組織的な目的からチームへの期待値を分析しチーム目標を設定する
    - ご近所さんを探せ
      - RACIチャートと、オニオンモデルを用いて、関係者の役割と距離をチーム内の共通認識として理解する
    - 夜も眠れない問題
  - DODの決定
  - スクラムイベント設計を実施
  - KANBANボードの設計を実施
    - ScrumMasterが草案を作成し、それを元にチームで作成をした

実際に見せたアジェンダ

チーム稼働開始〜現在まで

ロールごとに支援した内容の図

約半年から一年間の活動をざっくりとまとめてみました。

全体的に気をつけていた内容は下記内容になります。

チームの邪魔にならないようにする
自己肯定感から、必要のないフォローや厚かましくならないようにする
チームに対してのアドバイスやフィードバックをする際には、論理的な根拠や論理的な言動を心がける
改善活動の前後に変化を計測できるようにする。(心がけていたが、できていないことの方が多かった)
チームの現状がわかるように定期的にデータの分析を行う
抽象と具体的を意識し説明を行う（文字だけでなく、絵を描くことを心掛けた）
一定期間で必ず自分自身の振り返りを行う

4. 課題

上記の活動を通じて、サイトチームにおける課題を以下にまとめます。

チーム内に複数の目的が存在する(組織的な課題)
- リードタイム改善
- 売上アップの為の施策検討、実施
本来の目的であるサイトの機能開発以外の差し込み業務や保守業務が多く、計画がずれることが多い
特定のメンバーが施策等のスケジュールを調整や整合することが多く、チーム全体での目的達成への温度感に差がある状態
特定メンバーのスキルへの依存があり、進められる業務に偏りがある

と、代表的な課題を挙げてみました。(このほかにも課題は沢山ある...)　

5. 課題を分析する

下記課題をピックアップして分析してみました。

チーム内に複数の目的が存在する(組織的な課題)

リードタイム改善

売上アップの為の施策検討、実施

チーム一丸となり、企画→開発までのプロセスを見直すことにより、リードタイムの削減に貢献しているが、ロールの違いにより、優先される目的が違い、チーム内に溝を生んでしまう。

Developerとして掲げている目的のリードタイム改善の為には、古くなった技術の更新や、複雑性を帯びたコードの修正をすることで、リードタイムの改善を目指しているがコストが高い。 ServiceDesignerや、企画者は施策の検討や、施策の実施準備等をすることで売上アップの為の施策検討を実施している。

各ロールが持っている目的にそった手段を取ることは間違いではなく、馴染みのある作業や、アウトプットを出しやすい手段に着地する。

結果として、PBLの優先順位や整合等で細かな認識のズレが肥大化し、生産率の減少へとつながっていると分析しました。

この課題を解決にするにはまず、チームに求める目的を一本化することが望ましいと考えています。一つのチームに複数の目的が存在し、どちらの目的を優先的に進められるかの判断が曖昧になり、結果として目指すべき目的が達成できない確率が高くなると考えています。