概要
スクラムの考え方を開発以外（csチーム:カスタマーサポート、カスタマーサクセス）にも取り入れようという方針になり、csチームのスクラム体制に関しての前例がネットで全然出てこないので実際に考慮したこと、苦労したことなどをまとめたい（現在進行形ですので続編を追って出します）
背景
全社的にスクラム体制を取り入れようという試みの中で、有志の立候補者が認定スクラムマスタ―（csm）の資格を受験したのち、スクラムマスターとして動くという活動から。
当初は新製品開発のスクラムマスタをする予定だったが、csチームにもスクラム体制を導入することになり、自分はスクラム体制は未経験だが、csチームのスクラムマスタをすることになった。
基本体制
プロダクトオーナー：1人
スクラムマスタ：1人（自分、一部開発者を務める）
開発者：8人
＊開発者＝csメンバー
開始までの流れ
スクラム体制開始までに主に以下の取り組みを下準備として実行しました。
1.スクラム体制に当たって、使用するツールと主なイベントの流れの決定
2.チームメンバーにスクラム概要の説明と導入してもよいかどうかの合意を取る
3.プロダクトゴールの設定、およびプロダクトバックログの作成
4.振り返りによる継続的な改善
1.スクラム体制に当たって、使用するツールと主なイベントの流れの決定
先ず、スクラム体制を取り入れることを提案するにあたって、
スクラムガイドに記載されているイベントのどれくらいのスプリントのどこにどのような形式で行うかを考えました。
第一に考慮しなければならない点は以下でした。
1.スクラム体制を試みたメンバーがいない
2.そもそも開発に適応するわけではない（csチーム）
3.csチーム出身ではないためチームの改善したい点をすべて知っているわけではない
1.スクラム体制を試みたメンバーがいない
1に関しては、立ち上げ途中に新製品開発側に業務委託でスクラム経験のある方が参加して頂いたので、相談したい点等が生まれれば適宜アドバイスをいただきながら進めています。
それでも自分自体は経験不足なのでできるだけスクラムガイドから逸脱しないような体制作りを意識しました。
2.そもそも開発に適応するわけではない（csチーム）
2に関しては、スクラムとは本来開発チームに適応するための開発体制フレームワークであり、csチームに適応するにあたって考えなければならない点が多々出てくるだろう（実際出てくるわ出てくるわ）という想定の下、考慮しながら体制を考えました。
3.csチーム出身ではないためチームの改善したい点をすべて知っているわけではない
自分は入社して半年ほどは開発チームにて新製品開発に努めていました。なので外側からでもわかる点以外のチーム内での改善したい点などをすべて知っているかどうかといったらそうではありませんでした。
この問題点に関してはcsチームの経験が長いメンバーの方々もスクラム体制立ち上げメンバーとして招待し、サポートして頂くことで認識を合わせていきました。
この３点を考慮した結果、以下のようなイベントでスタートしようという結論になりました。
・プロダクトゴールは四半期ごとに立てるチームミッション達成
（成果物というものがcsチームにはないので）
・スプリントは1週間（改善が多く出ることが見込まれる、まだ慣れていないので）
・デイリースクラムは11:00~から毎日15分～30分ほど、その後話す必要のある方のみで2次会
（人数がギリギリ10分、慣れていないメンバーということで焦らせないため最初は30分を確保）
・スプリントは水曜締め、木曜始まり（水曜だした改善を翌日の木曜すぐに実践できるので）
・水曜15:00～16:00にレトロスペクティブ兼スプリントレビュー
・水曜16:00～17:00にスプリントプランニングをスクラムマスタとチームの中心で
（当時は工数を付けれる人中心でやらないとカオスになると思ったが…
今思えばこれはまずかった）
・バックログツールはnulab backlog, 振り返りにはmiro
＊nulab backlog、miro
バックログの状態管理や、課題設定のルールに関しては結構練ってるので別途記事作成してまとめて貼りたい。
2.チームメンバーにスクラム概要の説明と導入してもよいかどうかの合意を取る
スクラム体制を取り入れるとなると少なからずチーム全員の業務スタイルが変わるのでその説明と、スクラムがどんなものかを概要を説明して、反対意見が出なかったので開始することに決定。
ここも今思えばもっと丁寧に説明すべきだったとは思うのだが...
かといって改善前提の体制を説明ばかりで動き出しが悪くなるのもあれだし、多分いくら説明しても不明点はでてくるし（自分もそう）...
導入時のチームメンバーへの説明ってどれをどのくらいどのようにが正解なんですかね笑
3.プロダクトゴールの設定、およびプロダクトバックログの作成
csチームでのスクラム体制での不安点の一つが目に見える成果物がないこと。
なので
プロダクトゴール→四半期ごとに立てるチームミッション達成
と設定。このミッションをmiroのマインドマップ機能を用いてバックログに登録できるようなタスク単位まで深掘り。
プロダクトバックログはカンバンのような機能もあるからそこに羅列、決めたものをnulab backlogに登録
4.振り返りによる継続的な改善
上記スケジュールにて行うと決定した振り返りを、どのような方法で行うか、様々な方法を考えた結果、オーソドックスであるKPT法に落ち着いた。
miroを用いる。
アジェンダはこんな感じ
・導入（2min）
・前の改善案状況確認（10m）
・KPT付箋出し（5min）
・整理, 付箋の確認（5m）
・重要そうなテーマ抽出（3m）
・次の1週間のアクションにつながる改善案を出す（20m）
・すぐやれるか、バックログに入れるかの振り分け（5m）
・バッファ（残り時間）
＊似たような意見、気になる意見はスタンプ押して賛同しましょう！
目マークなどが多いのを優先的に議論したいと思います！
目安箱みたいなか所を作って、ふとした疑問を列挙してもらう
Keep(継続点)など通常の付箋に加え、前回のフィードバックとして、Try(改善したかどうか)ヲ追加
miroのスタンプ機能を用いて数が多いものから議論、改善洗い出し、漏れた課題があれば後で拾ってslackなどで周知しています。
結論
年明けから体制準備を始め、中旬には開始することができました。
開始から現在1か月を過ぎ、csチームスクラム体制に関しての前例がネットで全然出てこないので少しでも参考になればという気持ち、体制の振り返りと迷走していないかどうかの再チェックを込めてこの記事を書きました。
備考
とはいってもまだまだ、改善点、困ったこと、アンチパターンが発生しており...
スクラム体制に関わる記事はこれからも書いていきます！！
（参考にした本とかもまとめたい）
Discussion