この投稿は、品川アドベントカレンダー2019　13日目です。

はじめに

なにやら久々にスクラムマスターを任されることになったので、
過去のチームで「良かったこと」「やりたかったこと」を思い起こしながら書く。
スクラムはある程度知っている人向け。DevとSMの経験があるけど、今回書くことの視点はSMに近いかな。
絶対やるべきお作法に近いところと、チームでの工夫を混ぜこぜでお届け。

案件立ち上げ時

私の参画時には案件は立ち上がっていることが多かったので
周りの案件を見ていて感じたことを書く。

アジャイルを理解している味方をたくさん作る
- アジャイルが適用されるのは開発チームだけじゃない。
- 営業・企画・開発・お客様・関連する部署…などなど。理解者は多いほど良い。
- 偉い人が味方だと色々な場面での説明が楽だし、問題発生時にも頼れる。
- 学び方は様々でよいが、目線が合っていた方が良いかも？社内外での研修、コーチを招くなど
関連するすべての人が、アジャイルで開発をする価値、理由を理解し、納得している。
- WFとの違いを認識し、このプロジェクトはアジャイル開発で実現すべきだと合意している。
関連するすべての人が、アジャイルのデメリットやリスクを理解している。
- 失敗を防ぐ。失敗したとしても、原因を適切に切り分け、改善に向けた動きができる。
定期的にリリースし、実際の利用者からのフィードバックを得る仕組みがある。
- アジャイル導入の価値の一つ。これが健全に運用されているプロジェクトは、成功していることが多い。
- それが難しい案件ならば、是非偉い人に「アジャイルでやる意味ありますか？」と問いかけてほしい。
ロールは専任。
- スクラム途上会社において、多くの人はスクラムに慣れていない。
- まずは自分のロールをしっかり全うすることから始めるべし。
- スクラム外の仕事はなるべく0にし、スクラムに本気で時間を割ける状態にしておく。

Sprint0・チームビルディング

Sprintが始まる前のはなし。

関連するすべての人が、インセプションデッキの内容に合意している。
- 完璧なインセプションデッキである必要はないにせよ、近い物は作った方が良い。
- POの道しるべになるだけでなく、Devやステークホルダーの意見の整理にも。
- 外部要因にチームが振り回されることを防ぐ。プロダクトがブレないための軸である。
チームの開発環境が準備済みであり、ツール・CICD環境などは想定できる範囲で用意してある。
- Sprint1開始からすぐに価値を生み出す活動ができる状態にしておく。
- CICD環境の構成に関しても、後からの追加変更に対応できる形だと望ましい。
スキル可視化
- 不出来な人を炙り出すものではなく、まずは「頼れる人を見つけるプロセス」と捉える
- スキルマップの記載、掲示
- 「スキ・キライ・得意・苦手」の可視化もおすすめ
  - 参考：https://note.com/saladdays/n/n4a00ba6dab0b
チームに打ち解けるために自分のキャラクターを出す
- 自己紹介の延長。自分の性格や趣味嗜好など、少しずつ自己開示する。
- SMは「いじられ三枚目キャラ」でいくと、お互いやりやすい気がする。
- 「好きなもの」を多く知り合うと、オフトピックな会話も弾みやすい。
ランチタイムを活かして遊ぶ
- 飲み会は時間・金の面で負担に感じる人も多いので、昼に交流する。
- ボードゲームやってる人多い。アンガーマネジメントゲーム・心理的安全性ゲームはよく聞く。
- 焼肉ランチや出前など、非日常を楽しむのもアリ。

チームビルディング系はSprint始まってからも継続的にやってももちろんOK。

Sprint中

よく言われるものから、ちょっとした振る舞いまで。

デイリー
- SMではなく、Dev全員に向けて話す(口調、目線など)　SMはおまけくらいの感覚。
ファシリテート
- 話の流れをホワイトボードに書いて整理する、図解するなど。
- チームの一部のみが理解できる、暗黙の了解が無いようにする。(指示語の多用など)
- 決めの問題で長々と議論させない。
PBI
- 「このPBIが完了となった時にプロダクトが発揮する価値」をPOが説明できること。
- 「PBIが完了になった時のシステムの状態」をDevがイメージできること。
POのその先に対する意見を伝える。
- POが作ったPBLは、プロダクトの絶対的な方向性ではない。疑問に思ったら、POと意見交換しよう。
- Devは、単なる動くものを作る役割ではなく、共に仮説検証をするパートナーである。
スクラムのイベントの見直し
- スクラムイベントが価値あるものになるよう、改善を試みる。
- 例えば、レトロスペクティブでKPTの効果が疑問視されたなら、他のやり方を用いる。
- チームの環境などが原因で、どうしてもそのイベントが価値を発揮しないなら、廃止も検討する。
褒める
- 人をポジティブにさせる。「えらい」「良い」「すごい」「神」など…シンプルなものでも何でもよい。
- 誰彼構わず褒める。ソースコードやツールも褒める。お菓子も褒める。
- 「ナイス自己組織化！」「肩に〇バッキー乗ってんのかい！」もうボディービルダーの掛け声。
返事をする
- わかったら返事をするのは吹奏楽部の名残(？)
- 「結局このタスク誰がやるんだっけ？」の迷子を防ぐ。
音楽かける
- みんなゲーム好きだったので、SFC時代のBGM集をかけて盛り上がってた。
- かつてない熱い気持ちで仕事した。
謎のキャラクターを登場させる
- 「大きいSBI気になるオバサン」「透明化の鬼」「UT自信ニキ」などなど
- 常態化しつつある問題をやんわり指摘するときや、チームのプロを呼ぶときに使う。楽しい。
  - 例：「大きいSBI気になるオバサン来ちゃうので分解しましょう」
  - 例：「どうも透明化の鬼です、これも貼っときますね」
様子がわからない人にpingを打つ
- 看板やチャットの様子など、動きが無い人は困ってタスクを抱えていることが多い
- 全員が全員の状況を分かる場所(チャット、チームの開発部屋など)で困り事が無いかを聞いてみる。
見える化
- インセプションデッキ、バーンダウンチャート、看板、スケジューラなど
- 実装イメージ(クラス図、DB構成、ロジックなど…)は何Sprintも追記して使った。
自己組織化
- 人によると思うが、まずは「何もしていない状態を作らない」を目指す。
- 手すき、抱え込みは常にアピールする。同一ロケなら「手すきです！」って声で伝えるのもアリ。
- チームで「今の自己組織化だね～」など声をかけ、お互いを鼓舞し合う空気感を作る。
モブプロ・ペアプロ
- スキルトランスや、属人化してしまった実装部分の解消。
- 最初からモブプロとしてタスクを作っても良いが、行き詰まった時のヘルプ案としても活用できる。
勉強会の実施
- チーム内勉強会を実施し、スキルトランスを図る。SPOFを解消する。
- チームに誰も詳しい人がいない場合は、外部の有識者を招いて勉強会。
- それでも解消しないようであれば、協力してくれる外部チームを作るのもアリ。
スクラム座談会
- 「各々が良いスクラムを回すために何を考えているか」をざっくばらんに話し合う。
- お互いに期待していることや、チームの理想と現状のギャップの認識などを語る。
- レトロスペクティブよりももっとマクロな観点で、スクラムに対する思いを語る。
- スクラム初心者が多いチームで、ある程度心理的安全性が確立した状態でやると効果的か。
スプリントの終わり、リリース時に軽い打ち上げ
- 無事にスプリントが終わった、リリースができた。そんなタイミングで軽くお祝い。
- アイスやお菓子を食べながら、お互いを称えたり、感想戦を続けたり、燃え尽きていたり…

さいごに

こういう取り組みはチームによって合う合わないがあるから、今回書いたものは一例に過ぎないけど、どこかの誰かの参考になればと思う。
自分もこれらに捉われず、次のチームではまた新しいやり方を試行錯誤していきたい。