Regional Scrum Gathering Tokyo 2020 1日目イベントレポート

RSGT2020に参加しています。
1日目のイベントレポートを書いていきます。

Regional Scrum Gathering® Tokyo 2020
9回目となるRegional Scrum Gathering® Tokyoは、2020年1月8-10日の3日間、昨年までとは場所を変え御茶ノ水のソラシティカンファレンスにて開催します。
Regional Scrum Gathering Tokyo 2020
このページは、Regional Scrum Gathering Tokyo 2020( #RSGT2020 )のセッション公募サイトです。 イベントについては Regional Scrum Gathering Tokyo公式サイトをご覧ください。 ここではセッションを投稿する

細かい出来事はどこかで総括でも書くとして、今日のところは参加したとこだけ紹介。

Welcome Note

ゴールドスポンサーのKDDIから、佐野さん。

スクラムという言葉の意味の話から。
すくらみっじ?と言っていたと思うけど調べても出てこなかった・・・。

そのあと、去年のスクラム、アジャイル関連イベントのまとめ紹介。
RSGTをはじめ、アジャイルジャパン、Scrum Interaction等々。

「中でもメインイベントは・・・」と言って出てきたのはラグビー。
試合中のスクラムの成功率の集計結果紹介。
前日に試合見直して数えたとのこと。(マジですか?笑)

総括:スクラムのもっとも強いチームが世界一になりました!

感想

それスクラム違いやで!!!!

The Ten Bulls of the Scrum Patterns

Keynote。
James Coplienさんの講演だと思っていたら、「急遽これなくなって・・・」と実行委員の方が。
「では私からスクラムを説明・・・」といいかけたところで会場後方から何やら声が。

James Coplienさんがこの格好で出てきました。
「スミマセーン。Do you have サケ?」と言いながら登壇。
楽しい演出。最初普通に信じた。

内容は、十牛図という禅の入門書になぞらえた、スクラムの習熟度の話。
十牛図はこちら。

十牛図 | 禅のこみち――萬福寺

以下、印象に残っていること。

  • スクラムは、ガイドを見たりWebで調べたりして出てくるものではない。
  • 50パーセントは失敗すべきで、そこから学ぶことが重要。
  • 無名の質を求める。ベロシティ、ROIなどは名前のある品質である。
  • 正しいプロセスを作れば正しいプロダクトが作られる。(By トヨタ)
  • 何かをやるのではなく、何かになるのがアジャイル。
  • スクラムはプロセス、組織を構築する。
  • 自分が信じているから真実であって、本に書かれているから、ではない。
  • 真の自分、真のチームの姿を見つけ出す。=無名の質
  • コントロールされた失敗がスクラム。
  • スクラムは一つの門に過ぎず、その先にこそ気づくものがある。

感想

なんだかスクラムマスターのトレーニングを受けているような気分でした。

失敗から学べるってわかっていてもまだ完全に行動に落とせてないなと認識できたことと、気を抜くとすぐにスクラムにとらわれてしまって本質から外れがちだな、と痛感。

特に大きかったのは、「正しいプロセスを作れば正しいプロダクトが作られる」というところ。
今までうまく言語化できなかったものがしっくり来たような感じがしました。

メルカリで購入したまま放置しているトヨタ生産方式をちゃんと読んでみよう。

スクラムの理解を深めるスクラムショーワークショップ

森さん(@viva_tweet_x)、Vasseurさん、大谷さん(@katzchang)、笹さん(@sasakendayo)のワークショップ。
行った時にはすでに始まってたけど、少し覗こうくらいの感じでふらっと入室したら、少し席が空いていたので途中参戦。

90秒でスクラムの良さを表現する寸劇を完成させるワークショップでした。
4,5人の版が6班に分かれていて、班ごとに作成。
寸劇づくりもスクラムで、スプリントは3回。
レトロスペクティブまでしっかりやりました。

合計100分くらい。超高速で進めていくので、気を抜くとおいていかれそう笑
でも結果的にまあまあ納得いくものができました。

感想

スプリントレビューでは別の班にそのスプリントで完成した寸劇を披露しなければいけないので、とにかく最低限披露できるところまでは固めるという強制具合が良かったです。
最近、実務でやってるスプリントが「終わらなくてもまあ・・・」みたいな雰囲気があったので尚更、ね。
寸劇の場合はアドリブやらで頑張って披露しさえすれば改善に有効なフィードバックをもらえたので、そういう特性もうまくはまってるなという感じがしました。

あとVasseurさんが以前一度だけ会ったことあるのを覚えててくれてうれしかったです。

アジャイルコーチ活用術

アジャイルコーチを使ってみたい人向けのお話。
自分で考えることのできる状態に育てるのが、アジャイルコーチ。

ティーチングとコーチングの違いについて。

ティーチングは教えてあげる。
コーチングは質問や傾聴を使って相手にきづいてもらう。
アジャイルには両方必要である。
リテラシが低いチームなら、ティーチングから始める。
成長に対する責任度合いと、結果に対する責任度合で、ティーチングとコーチングの使い方が変わる。

スクラムマスターとの違いについて。

スクラムマスターは、チームのゴールに責任持つ。
アジャイルコーチは、それよりも一歩引いた客観的な立ち位置。

アジャイルコーチの頼み方

アジャイルコーチの支援の種類は、組織的な支援もあれば、プロダクト支援もあれば、開発の仕方、チームの関係性も対象にすることがある。
どれを頼むにしても、まずは期待値を設定する。
期待値がないままに外部の人を呼んでも意味がない。
期待値は一つとは限らない。
優先順位をはっきりさせて、同時に複数のことをやろうとしない。

コーチを呼ぶときの頻度や期間について

これも期待値に紐づいて決まってくる。
予算ありきで考えると効果が出ないことが多いので、期待値ベースでコントロールする。
多くの場合は期間が短すぎると効果が出ない。
変化がわかるまでに大体3か月くらいかかるので、予算としてもそれくらいは考えておく。

何も変化が出なかった場合は、コーチに問題がある場合もあるし、政治的な環境問題などが原因になることもある。
フルタイムなどの長すぎる時間はほとんどの場合無意味。
最初は週1か週2くらいで、だんだん回数が減っていく流れ。

新規アジャイルチームを立ち上げたいという依頼はよくある。
準備期間は2から4週くらいで手厚くしておくとよい。
すでにアジャイルやっている開発のサポート依頼もあるが、その時点で苦境な状態だと難しいこともある。
基本は最初に相談したほうが良い。

アジャイルコーチの仕事

スクラムチームがやる作業をコーチに依頼しない
例えば、バックログ作成、ステークホルダとの調整など。
チームが持っていないケイパビリティを増やすための存在であるべき。=アウトソースではない。
スケジュール、スコープなどの「達成」のための支援を依頼しない。
達成に向けて責任を持つのは自分たちであるべき。

アジャイルコーチのカバー範囲は幅広い。
その対応にはそれぞれ準備が必要で、それこそがコーチングの質を上げている。
なので、アジャイルコーチが忙しすぎるのはダメ。
その活動の単価を時給で見ないでほしい。⇒経験や準備含めて提供するので。

広範囲ゆえに、得意不得意はある。
全部をカバーするような人はほとんどいないので、期待値を明らかにしたうえで、必要な領域を選定する。

良いアジャイルコーチの見つけ方

長期間一緒にやることを考えると、相性は大事。
期待値を明確にして、実際に会ってみる。
そこで質問するなどして評価したり、カンファレンスで話しているのを聞いたりする。
あとは、誰かに紹介してもらうなど。

アジャイルコーチの成果を定量的に評価するのは難しい。
チームの様子など、定性的なものにせざる負えない。
完了条件がつけにくいが、離れてもらって、また呼ぶもあり。
月一くらいで来てもらえるように関係を残しておくのもよい。

感想

チームのゴールには責任を持たないことで、客観的な視点をもつというのはいいなと思いました。私自身、ついつい口を出したくなってしまうので、客観的にそういところを見ていて注意してくれるというのもありがたい。

日常業務にアジャイルコーチ的な一歩引いたものの見方を取り入れられたら、もう少し広い視野で組織改善していけるだろうなと思うので、この気づきを活かしていこうと思います。

テックリードは未来の話をしよう

楽天の椎葉さん(@bufferings)の講演。
1日目ラスト。

スクラムにテックリードはいらない?

最初の話は、メンバーに肩書はない、とガイドに書かれているんだからスクラムにテックリードは不要ではないか?というお話。

テックリードを置かないでやったとしても、結局テックリード的な人しか見えないようなこともあって、「みんなでやっていこう!」はうまくいかないらしい。
その結果テックリード的な人に負荷がかかってきて、その人がもやもや。

そもそもスクラムをやるために開発しているわけではないので、テックリード置いて円滑に回したほうがいい。
その場合、ずっとテックリードをやるんじゃなくてチームに渡せるものは渡していく。

チームの活動を支える

最終的には一番後ろで奉仕する形になる。
ポイント3つ。

  1. 変化に適応する
  2. 信頼を大切にする
  3. 心を否定しない

1.変化に適応する
⇒チームの成長に合わせて立ち位置がかわる。

2.信頼を大切にする
⇒やってくれるという結果ではなくて、コミットメントを信頼する。
献身を信頼する。
全力であったことを信頼する。⇒もっとできたんじゃないか、ではない。
「うまくサポートできなくてごめんね。」となる。

3.心を否定しない
例:テストを書くのがめんどくさいから書かなかった。
⇒めんどくさかったということを認める。
そのうえで、その源泉はどこにあったのかを一緒に探して、取り除く。

テックリードのスクラムの中での動きは、外部との差分吸収もある。
開発チームのリズムを崩さないために、外部からの割り込みタスクの一次受けとなったりする。
受けてから、扱いを判断して良きタイミングでバックログに入れたりする。
リードタイムが長いチーム外との調整も、必要なタイミングを考慮して進めておく。

そもそも、スクラムが本当にスタートできる状態のチームであればテックリードは不要。
開発チームは「専門家の集まり」である。
そこにたどり着くまでに、どうしていくかという話。

正解がない状態で、どうしたらいいかを考えていく。
だから、「未来をつくる」。

未来をつくる

正解のない世界で、自分たちの道を切り開く。

  1. 現在地確認 =現状を受け入れる
  2. 目的地確認 =自分色のビジョン
  3. 進む =選ばない選択

の繰り返し。

1.現状を受け入れる
わからないものはわからない、できないものはできないというチームの現状を受け入れ把握する。
期待があると、足元が見えにくくなる。
期待からのマイナスではなく、現状とそこからのプラスをみる。

2.自分色のビジョン
個人のビジョンに向かう。
チームは成長する場としてあればよくて、その人が去っても場としては成長していけばよい。

3.選ばない選択
あのアーキテクチャを選択しておけばよかった、というのは、何かを選ばないということを選んだ、ということである。
失敗と学習を繰り返していく。
失敗を恐れない!

まとめ

テックリードが必要な場所に立って実感したのは、今自分が立っている場所だった。

テックリードをサポートする中で学んだこと。
自分に優しくしよう!
⇒テックリードはストイックで自分に厳しい人が多い。
テックリードは自分自身にも、ここまでのチームに対する考えかたを適用するのがよい。
3つのポイントと、3つのステップで、今の自分を受け止めて、一歩ずつ失敗しながら。

チームにやさしく、自分にやさしく、チームと自分のために未来の話をしよう。

感想

どうしてもスクラムガイドがよぎってしまうけれど、ルールにこだわりすぎることこそ本質から外れているのかもしれない、と思いました。
内容的にもやっぱり「チームを支える」存在なので、自己組織化されたチームが主役であるのはどのロールも変わらないなあ。

「全力であることを信頼する」は、アジャイル関係なしにマネジメント層とかに求められそうだなと感じました。

そして、
「期待からのマイナスではなく、現状とそこからのプラスをみる」
これが一番、個人的に刺さりました

一日目を終えて

RSGTに限らず、こういうイベントに出ると本当にアジャイルは気づきが尽きないな!とうれしくなります。
あと、プロフェッショナルの話を聞くことでこれまで自分では言語化できずにいたもやもやがスッキリします。

明日もまた有意義な時間にしたい!
あともっとガンガン交流したい!

コメント

タイトルとURLをコピーしました