ナガモト の blog

Full Cycle Developerを目指すエンジニアが有用そうな技術記事や、ポエムのようなよしなしごとを投稿するブログです。

第20回 Scrum Masters Night! 参加レポート

第20回 Scrum Masters Night! に参加してきたので、そのレポートです。 https://smn.connpass.com/event/94001/

スマホでざっくり書いたメモをベースにしており、精度は低めです

イベント概要

  • 参加者がディスカッションテーマを持ち寄り、投票をする
  • 各ファシリテータ(ありがたい存在)が投票数の多いものを選択する
  • テーマ別に各会議室でディスカッションする

今回は7個くらい?のテーマでディスカッションを行いました

ディスカッション

自分が参加したグループでは、テーマの掘り下げ・解決が難しかったこともあり、テーマにこだわりすぎず、発散した議論をしました

テーマ

実力に差がある場合のスクラム運用  (だいたいこんな感じ)

実力が低いメンバをいかに引き上げるのか? という意図

テーマを挙げた背景

  • 5人チームで1人実力が不足しているメンバがいる
  • 4人だけでやるほうが成果があがる程度には、フォローするコストがかかっている
  • 歩み寄る努力はしているつもり
  • 歩み寄り、ヒアリングした結果、そもそも仕事にやる気がない、向上心もないと本人が吐露

テーマに対する回答

  • スクラムには向き不向きがあるが、「やる気・向上心ないです」は向き不向き以前の問題で、打ち手がないのでは・・・
  • メンバ間の実力格差問題は、モブプロが効果的(体験談)。下を引き上げることに成功した

モブプロに関して

  • 下を引き上げることに効果的
  • 1ストーリーがなかなか終わらないときに、モブプロを実施することで、当該ストーリーを短時間(全体での工数は大きい)終わらせることができる
  • モブプロをする中で、自然とタスク分割が行われることが想定外に起きたメリット

ヘルプを求めにくい理由

  • 能力不足の露見を恐れる
  • メンバ同士が仲良くない
  • メンバ間に上下関係のようなものが存在する

ヘルプを求めやすくする工夫

  • ヘルプ用のチャットルーム(上司とか入れてない)を作る
  • times_xxのような個人チャットルーム
  • リーダ?シニア?層が率先してわからないをあえてラフに発信する
  • 昼食時に顔が向かい合うようなレイアウト
  • チームランチ
  • slackなど自作アイコン・画像の落とし穴でキャッチーにはまっていることを表現できるようにする
  • 朝会で雑談を推奨する(ローテで好きな話題を軽く話してもらう)
  • 今日は隣で作業していい?といってオフラインの距離を近くする

技術的スキル(のみ)が高いメンバについて

  • 声が大きいとメンバ間に上下関係を生じさせうる
  • ジュニア層が発言を萎縮する
  • 意思決定がスキルのあるメンバに集中し、責任も偏重する可能性がある
  • 改善するために、上司(明確に上の立場の人)の協力もほしい
  • 取り返しがつく範囲で、地雷を踏み抜いてもらい、メンバがフォローするという体験をさせるのもありかもしれない
  • 正論は理解してくれるので、googleの例などを持ち出し、心理的安全がいかに重要か理論的に説明する
  • 1人チームとして扱うことで、他チームとの協調となると協力的になったりする

パワープレイについて

  • 炎上し始めて自然とパワープレイになることはあった(体験談)
  • パワープレイ時に上下関係が形成されてしまう
  • ジュニア層は伸び悩む
  • 意図的にパワープレイした経験は参加者にはなかった

スクラム向いていない人とその対応

  • 過去の成功体験に縛られて新しいやり方を受け入れられない人は向いてない
  • スクラムは即効性がないから考えを変えるのが難しいが、根気よくやるほかない
  • 本当に向いていない人は、組織内で異動するなどがいいが難しい

大きな組織で上からスクラムをみる

  • 複数チームをスクラム的要素で比較することは難しい
  • ベロシティはチームごとに1の基準が異なる
  • 人月ベースでチームの期待値が設定されるのもやむなし
  • 上に報告する際は、ビジネス・PJ的な指標に変換するのは当然

いいチームとは

  • 雰囲気が軽い、雑談がある
  • スクラムマスターを意識してやらなくていいような状態
  • スクラムマスターにない発想で、メンバが自主的な取り組みを見せてうまくいったときは嬉しい
  • 人間関係の土壌が一番大事

所感

  • スクラムは当然銀の弾丸ではない
  • フレームワークと言われるけども、必ずしも型に嵌る必要はなさそう
  • 人間関係、コミュニケーションが一番大事で、対策をパターン化することは容易ではない
  • 当イベントのように実際のユースケースから学ぶことは非常に有意義