ちょっと時差がありますが、2020/12/17(木)に開催された表題の勉強会に参加したので、参加レポートを書きます。
- 勉強会のリンク
- 勉強会で発表してくれた常松さん(Retty)のスライド
- 参加したきっかけ
- 発表内容
- 全体を通しての感想
- 本勉強会について言及されている常松さんの記事
- 本勉強会について言及されている他参加者の方の記事
勉強会のリンク
distributed-agile-team.connpass.com
勉強会で発表してくれた常松さん(Retty)のスライド
参加したきっかけ
勉強会が楽しいからに尽きます。初めて参加してから2ヵ月位ではあるものの、毎週木曜を楽しみにしています！
毎度毎度濃い議論が展開されており、知識は勿論ですが、皆さんの考え方やものの見方を学べるのが、個人的にはとても気に入っています。
仕事でもプライベートでも、厳しい状況にあたった時や困った時に「XXXさんならどう考えるかな？どういうアドバイスをしてくれそうかな？」と頭を巡らせると、これまで途方に暮れていた場面でもヒントが見つかったり正解に辿り着ける場面が複数回出てきて、毎回勉強会を盛り上げてくれる方々には大変感謝しています。
参加者のレベルが高いので話の咀嚼に時間がかかる点と、議論が面白くてついつい夜更かししてしまう点は注意ですが、お勧めのイベントです。
参加したきっかけが殆ど言及されていませんね
発表内容
上に添付した常松さんのスライドのP9から順に、自分の感想と勉強会の様子をまとめていきます。
スクラムチームの評価
スクラムチームが出している価値とステークホルダーの満足度(利益)には相関関係がある(ステークホルダーが満足したり利益を上げていればスクラムチームが出している価値は高い)ので、ステークホルダーの評価を重視するのは至極全うな考えで評価の納得感も出るだろうな、と思いました。
現場で適用を勧める時は、スクラムチームA-ステークホルダーX, スクラムチームB-ステークホルダーYの構図で、ステークホルダーがスクラムチームに求める期待値を正規化する必要がある点にだけ注意したいと思いました。
また、他の方も言及していましたが、実験を評価するって素敵だなあと思いました。
自分の会社では、評価の時期が近くなると失敗を恐れてチャレンジを回避する人が増えてしまうという話が出ていたので、実験を評価すればこういう問題はなくなるんだろうな、と思いました。
スクラムチーム個人の評価
複数観点(施策・不具合対応・チーム外貢献)で評価し、どの観点をどれ位重視するかは個人と話し合ってそれぞれ決める、という部分に皆さん共感していて、自分も理想的な評価の仕方だと感じました。
1on1の開催
評価・個人の成長のための1on1(1on1というよりは面談の定義に近い？)という印象を皆さん感じたようです。
週一度30分という頻度、チームで上下関係が生まれないようにマネージャーが1on1を担当している、という話が印象的でした。
問題のエスカレーション
チーム内で解決できない課題はエスカレーションしてもらって、マネージャー間で相談して対処している、問題によってはすぐに対処するという話に対して、自分を含め皆さん感動していました。
すぐに対処する/しない課題の色分けをする考え方に自分は賛成ですが、「すぐに対処しないで「わかるけどちょっと待ってね」という対応をすると、その後すぐに対処すべきような課題が出ても相談しなくなりそう」という話も出ていて、やっぱり難しい話だな、と改めて感じました。
チームを立ち上げる時
メンバー選びをチーム主体で決めて、チーム外の人は少しのバランス調整だけする、という形が理想的だと思いました。
スクラムマスターの選定では、やる気のある人, 立候補制という話があって、個人的には本人も他の人も一番納得感がある決め方(やっぱり個人がやりたいかどうかが、モチベーション高く働くためには一番大切だと思うので)だと思いました。
ただ、「スクラムマスターになりたいスクラムマスターは(スクラムマスターの役割を勘違いしていた場合)大変」という話も出ていて、これも間違いないな、と思いました。
スクラムマスターを育てる
スクラムマスターは専任か兼任か、という問題提起が常松さんからありました。
そのため、Discord内でも話が盛り上がっていて、
- 事例を信じるのか、テキストを信じるのかっていうだけって気がする
- 兼任させたくない前提には「開発者はスクラムを通して仕事をしていても、スクラムに必ずしも習熟しない。だからスクラムマスターのようなロールを通してスクラム自体を学んでもらう必要がある」がある
などなど話が出ていました。
また、スクラムマスターの育成話を聞いて、「スクラムマスターアシスタントという観点では、実は常松さんが真のスクラムマスターだったりして」という話も出ていました。
メンバーをチームに入れるとき
「XXさんのために簡単なタスクが欲しい」が怪しいサイン、というのはめちゃくちゃ共感しました。
「粗い粒度でタスクを丸投げして、タスクをこなせなかった場合はこなせなかった人の能力の問題」という状態になると新規参入の障壁が上がり、タスクを投げる人やチームの成長も鈍化するので、チーム全員で新しくチームに入るメンバーのフォローをする空気が醸成されるように、チーム内外で工夫する姿勢が大切だと思いました。
マネージャーの育成
会社の文化や個々人の能力にもよりますが、マネージャーがプレイヤーとして手を動かすのは基本的には危ない、というのは間違いないと思いました。
個人的には、「フルスタックエンジニアは目指すものでない。一つ一つの技術に集中していった結果としてなるものだ」って話を思い出しました。
全体を通しての感想
外で発表するから綺麗に見せよう、みたいな加工が殆どなくて、現場のリアルな話をそのまま持ってきた印象を受ける発表でした。
なので、発表中は常松さんが普段見ている世界に近い世界を見れて、その世界で見えてくる問題に対して皆さんと一緒に真剣に向き合っていたような感覚を勝手に持っていました。
発表後にあったOSTでも、駆け引きをしたり遠慮をすることなく、問題に対してストレートに向き合う常松さんの姿が印象的でした。(常松さんが現場で経験したリアルな話をたくさん聴かせてもらえました)
常松さんのお話を聴くのは今回が初めてでしたが、記事の冒頭で書いた
厳しい状況にあたった時や困った時に「XXXさんならどう考えるかな？どういうアドバイスをしてくれそうかな？」と頭を巡らせると、これまで途方に暮れていた場面でもヒントが見つかったり正解に辿り着ける場面が複数回出てきて...
という点で、常松さんだったらどう考えるかな？という視点が加わったような気がしました。今後も是非お話を聞いてみたいです！
