※この記事はモチベーションクラウド Advent Calendar 2018の13日目の記事となります。
おはようございます。
モチベーションクラウドの開発に参画している@kiiiiitaです。
はじめに
マネージメント未経験でスクラム開発経験も4ヶ月だった私が、スクラムマスターを経験して味わった成功体験と失敗体験を振り返ります。
スクラムマスターになった経緯
時系列で書くと
- スクラム導入
- 開発チームの一員になる
- 所属していたチームのスクラムマスターがエンジニアに転向するため離任
- 後任として私に白羽の矢が立つ
- 偉い人たちに呼ばれお願いされる
- 最初は断るが押しに負ける
- 開発メンバー兼スクラムマスターの誕生
のような流れです。
イベントや体制など
##スクラムイベント
- モーニングスクラム（朝会）毎日
- スナックスクラム（夕会）毎日
- スクラムマスターMTG 毎日
- 振り返り（KPT）週1
- スプリントプランニング 週1
- スプリントレビュー 週1
- 振り返りFB 週1
イベントは多分他と比べて多かったです。
他と明らかに違うだろう点は振り返りFBがあることですかね。
内容は週１振り返りでやっている内容の振り返りです。
コンサルとしてJOINしているRector社の松岡さんと広木さんにチームで振り返った内容を共有して、アドバイスを頂き振り返りの質を上げようという場です。
##チーム体制
- PO×1
- スクラムマスター×1
- 開発メンバー×4~6くらい
チームには含まれませんが、デザイナーやテストチームも存在して必要であれば連携していくスタイルです。
##スプリント期間
初期は1週間、途中から2週間で回していました。
スクラムでの成功体験
ストーリーのタスク分けを細かくした
タスクやストーリー自体が大きすぎると抽象度が上がり、見積もった以上の実績がかかることはよくあると思います。
その乖離をなくすために
- タスクは細くする
- 予実の乖離を起きづらくする
- ストーリーに対してプランニング時にガッチリ仕様を詰める
- ストーリーを進める上での影響を洗い出し不確実性をなくす
をしました。
予実管理はバーンダウンチャートを使用していたのですが、予定通り落ちていくと安心感が違います。
終わらなかったストーリーの問題を深堀りした
約束したストーリーを全部終わらせられないことはよくありました。
その時は振り返りで
- 終わらなかったストーリーのポイントを見返す
- 適正だったかを議論する
- 問題を深掘りする
- 具体的にどういうところに時間をかけたか分析
- ハマりポイントを明確にする
を行い次回のプランニング時に同じことを繰り返さない対策を打っていました。
メンバー間の心理的安全性を保つ
これはスクラムマスターになって特に重要度を感じました。
スクラムはチームで仕事をするのでチーム力やコミュニケーション力が非常に大事です。
チームメンバーの一人ひとりが気兼ねなく発言できることは、チームの状態や仕事をしていく上でのパフォーマンスにかなり影響があります。そしてコミュニケーション量を増やし、チームの雰囲気向上にも繋がります。
また、振り返り、プランニング、コードレビューでも、それぞれの考えをぶつけ合うことで質が上がる要因になっていたと思います。
スクラムでの失敗体験
2週間スプリントの難しさ
1週間スプリントに慣れてきた時に2週間スプリントに移行したのですが、難易度の高さを感じました。何故なら、MTGの時間はそのままだがプランニングの量は倍になりタスクの抽象度が上がる不確実性が増していったからです。
また、スプリントが長いため遅れていても取り返せるんだと考えがちでしたが、実態はリカバリー案がなく終わらないことが多かったです。
このことから2週間先の見込みを十分に立てることの重要性と、こまめな進捗管理が2週間スプリントでは学びました。
一つ勘違いしてはいけないのは、タスクの抽象度を上げるということは悪ではありません。成熟したチームなら抽象度が高くても仕様決めから開発までをやり遂げるでしょう。
チームの大幅な入れ替え
元々スクラムはメンバーの入れ替えに弱いです。
チームが成熟している時に追加や入れ替えが発生すると、チームビルディングをやり直す必要があるからです。ましてや大幅な入れ替えとなるとそれは必然となるでしょう。
今までのやり方が合わない新メンバーもいるため、チームビルディングをし直すこと自体はすごく意味があると思います。
しかし、既存のメンバー（私も含む）からすると大きくやり方を変えるのは難しいです。何故なら成功体験があるからです。
メンバーそれぞれの目指す方向を共通認識として持つことがスクラムでは重要だと学びました。
MTGのタイムマネージメントをできなかった
スクラムはイベント（MTG）が多いですがそのほとんどが長くなりがちでした。
その原因の一つにMTGに参加する人数が多いということが挙げられます。もちろんいて欲しい場合がありますがその殆どがその限りではありません。人が多いと議論が活発化され着地しづらくなります。必要である場合以外はMTGを最少人数でやるようにすべきでした。
また、MTG中の時間管理もしっかりできていませんでした。そのため長くなると集中力が切れ良い意見も出ません。中には自分の作業をしだして議論に参加しないメンバーもいました。
そうならないためにMTGをアジェンダ通りに進めることや、状況次第では第二回を開催するなどの対策を取るべきだと学びました。
何でもかんでも自分でやりすぎた
スクラムマスターはチームへの妨害を排除することが目的です。なので私はメンバーが開発の邪魔になりそうことはやりました
具体的に何をやったかというと
- 本番ブランチと開発ブランチのコンフリクト対応
- 開発環境に問題があった場合の調整
- 仕様の最終決定をPOと調整
- 他チームとの連携・調整
- リリースの段取り
- 実際のリリース作業
- ストーリーをバックログに追加する
などです。
これ以外に自分のタスク（開発のストーリー、スクラムイベントへの参加、振り返り資料作成）も抱えていましたが、最後はパンクしました。
ここまでやった理由としてストーリーが終わらなかったときの理由を他責にして欲しくなかったことが強かったです。
しかしメンバーを信頼して作業分配すべきだったと学びました。
まとめ
スクラムマスターを経験して多くの学びがありました。
チームとして、組織として成果を出すことの難しさを痛感してます。
また、スクラムとは単なるフレームワークなのでチーム状況に応じた柔軟な対応がいかに大事かを学びました。
最後にスクラムにとって特に重要なこと
それは心理的安全性が保たれてることだと思いました。
改めて振り返ってみると良い状態のときはあって悪い状態にはなかった要素かなと思ってます。多分この要素を満たしているだけでチームが良い状態になる可能性が高まるのではないでしょうか。
割と問題はヒトとヒトの間にあることが多いです。
チームや関わる人たちに言いたいことを言い合える環境こそが、スクラムをやる上での重要なことだと感じました。
ただし心理的安全性が保たれている＝いじりや悪口など何でも言っていいということではありません。
相手を思いやる気持ちとリスペクトの精神を忘れないようにして、質の高いコミュニケーションを心がけましょう。
私はそれで何度も失敗しました