あでぃの〇〇製作所 
2019/1/9〜11でRegional Scrum Gathering Tokyo2019(RSGT20129)が開催されました。
大部分は体調不良で不参加 and いるときもスポンサーブース近辺にいたためあまり多くは聴講できなかったのですが、そのときに参加したスクラムパターンのワークショップが非常におもしろかったので、その感想を書きます。RSGTは初参加でした。
明日現場で使える！とにかく明るいScrum Patterns活用ワークショップ
こちらのワークショップに参加してきました。
ワークショップ主催の笹さんの記事を貼っておきます。
タイトル通りとても明るい雰囲気のワークショップでとても楽しかったです笑
スクラムパターン？
まず、パタン・ランゲージというものがあります。パタン・ランゲージとは元は建築理論・建築設計の話ですが、簡潔に書くととある領域の経験則/知識を言語化、定型化してまとめたものです。
プログラミング文脈だとデザインパターンとか、DDDとかがパタンランゲージであると言われ、語弊を恐れずに書くならば「こういうことがしたいときにはこれを使ってみるといいよ」みたいなものの集合体です。
その、対象領域がScrumであるパタンランゲージだと思います。
このワークショップについて
このワークショップは、とあるプロダクトの開発チームをHyperproductive Teamにするべく
- チーム立ち上げ期
- チーム結成後
- その後の発展
という3つの時期に大きく分割し、スクラムパターンを適用して数多の問題をなぎ倒していくというものです。
僕のテーブルでの結果はこのような感じでした
以下、僕の考えたこととざっくりした感想を書いていきます。
チーム立ち上げ時
- 各期で起きそうな問題を個人で考える
- 各人から出た課題を、チームで解決したい順に並び替える
- スクラムパターンを眺める
- 優先順位の高いものから、どのパターンで解決できそうか？を考えて適用していく
- 4を優先順位の上から繰り替えす
- 結果を話し合う
という流れでした。
この時期では
- チームメンバーのスキルをお互いに知らない。誰が何できるの？
=> 「職能型チームになってしまっている」
- MTGでの空気の読み合いが発生する。言いたいことは言えない。
=> 「信頼関係が構築できていない」
- で、結局何を作る(目指す)プロジェクト？
=> 「ゴールが見えない」
- そもそもスクラムやろうとしてるけどスクラムって何？
=> 「スクラムへの理解度が低くセレモニーに消極的」
みたいな意見がありました。
「ゴールが見えない」という問題は立ち上げ時だけではなく、ちゃんと定めていないと新しいメンバーがジョインしたときや、チームリーダーが変わったりしたときとか、なんどか起きるタイミングが存在しているように感じます。
これに対してはビジョン、プロダクトバックログといったパターンが出されました。
僕としてはビジョナリーな人のサポートをしていたいという強い思いがあるので、ビジョンを掲げていくのは好きですし、大事だと思います。ただ、ここで目的にあうようにビジョンを活躍させるには解釈の余地を残さない方が良い(チームメンバー全員が同じ風景を描けると良い)と思うので「このプロダクトで良い世界をつくる」とかじゃ作っても意味ないと思います。かといってどこまで書けばいいかもIt depends.なので難しいなと思いました。
チーム結成後
流れは立ち上げ時と同じです。
この時期では
- タスクがスプリント内に終わらない。次のスプリントでいいんじゃない？
=> 「タスク完了の定義/優先順位が不明確」
- ベロシティをあげてほしいらしい、見積もりを大きくすればベロシティがあがるね。
=> 「見積もりの精度 / 無理にベロシティ(のみ)をあげ始める問題」
- よくわかんないけど、このタスクなかなかdoneにならないね？
=> 「タスクサイズが大きすぎる問題」
- デイリースクラムに人が来ない。みんな忙しいからスキップでいいよね？
=> 「セレモニー自然消滅問題」
みたいな意見が出ました。
セレモニー自然消滅問題というのはよく聞きますね。毎日報告することなんてないよ(そんなことないと僕は思っていますが)っていう人が出始めてデイリーMTG参加者が減ってく話とか。身の回りではプランニングの負荷の高さから原義どおりにはやらない事があったりします。
ただこれは個人的には決断することが大事、みんなできめることが大事だと思っているので、なぜやるのかという意図を理解した上でチームにとって不要だと思ったらルールは消せばいいと思います。問題は自然消滅であることですね。
これに対しては、ワーキングアグリーメントを定めると良いと思いました。メンバー間で取り決めを作るものです。僕自身のチームでは「デイリーMTGは5分以内に終わらせる」「デイリーMTGの開始までにホワイトボードに共有事項(差し込みで対応したものなど、前日に共有できていなかったものとか)を書いておく」とかがあったりしました。そしてこれを振り返りのたびに見直しをします。これをデイリーMTGをする場所に貼り出しておくとすごく効果があります。「これ守ってくださ〜い」をメンバー全員が気軽に指差しで指摘できるようになったりします。あと張り出すときはテンションが少しでもあがるようにポップなスライドにしたいですね。土日をこれの作成のために潰したこともあります(僕がセンスが無いのに変に凝り性なだけです)
さらに、タスクが正常に終わらない問題に対しては「完成の定義」「準備完了の定義」を考えます。例えば「XX機能をつくる」という項目に置いて完了の定義は何になるのか。コードがかけていればOKか？PRはマージされているべき？テストは？リリースに関するドキュメントはある？誰かに報告するんだっけ？パフォーマンスとか平気？出たバグはどうしようか。などなど。準備完了の定義は何になるか。どのくらいで終わるか見積もれている？このタスクに自分以外の関係者とかいる？必要なもの揃ってる？優先順位とか判明している？などなど。
チームによって要不要は様々です。そもそも作っているものによって変わるので、これだ！ってものはあまりない気がしますね。でも逆に、何に対してでもある程度応用が効くと思います。これをチームメンバーで話し合えると良いですね。テンプレートなどはあれど、チームメンバーがほしいと思っている情報を揃えることが大事で、これによって余計なことを考えずに大事な作業に集中できる環境へ一歩近づけると思います。
さらなる高みを目指して
最後に、全てのスクラムパターンを机の上に並べ、「これを使ったらもっとこんなチームにできるのでは！」「これ取り入れたらこんな部分がよくなりそうだね！」みたいな話をします。
例えば「スクラムマスターが隠れる」パターンによってセレモニーにメンバーが責任を持てるようになりそう！とか、自分たちがこのイベントを楽しむには？のような話を誘発できそう。とか、「幸福指標」パターンによって、プロダクトを自分たちで作り上げている意識が強くなりそう、ミスを恐れぬチャレンジへ導けそう。など。様々な話があったのですが、このへんはすみません盛り上がっていてあまり覚えていないです笑
まとめと感想
スクラムはフレームワークなので、本当に様々な要素があります。そして、全てをそのまま突っ込もうとするとスーパーマンだらけのチームでない限り失敗します。失敗するというか、僕個人としては現状がわかりすぎてダメな部分がよく見えてきてスクラム自体が嫌いになるメンバーが出てくるとかチームとして悪い方に向かってしまう、って気がします。
このスクラムパターンにはとても良いこと、納得味のあることがよくまとまっています。けど、全て本質はチームの現状把握のために「とことん言語化」「ところん見える化」「とことん共有」すること。そしてチーム内のプロダクトに関する情報の非対称性をとことんなくしていくこと。チーム内の行動や世の中に価値を出すことにおいて、情報の非対称性から来る逆選抜をなくすことなんだなと感じました。
あと、正月休みにスマブラをしすぎると風邪をひきます。みなさんお気をつけください。リトルマックを強くしてください桜井さん。飛び道具に勝てません。