はじめに

2020/01/08(水) から 01/10(金) にかけて行われた Regional Scrum Gathering Tokyo 2020 に参加してきました。参加した多くのセッションを通して手もとに残した膨大なメモの中からピックアップしてまとめました。
自分向けのメモをカスタマイズしたので現場にいない人にはわかりにくい面もあるかもしれません。

総括

Fun / Done / Learn でまとめてみました。このあとのメモがダラダラ長いので先にまとめを書きます。

Fun

この場に来ると刺激が多く自分のネジを巻き直せる。
様々な経験をもつ人たちからいろいろな話を聞ける。
Open Space Technology が楽しい。
- 午後まるまるこれをやる日があってもいい。
台湾から来て登壇した方から Scrum ビールをもらった。
会場で淹れられたコーヒーがおいしい。

#RSGT2020 #縁の木ハッシュタグできてる！美味しいコーヒーいつもありがとうございますー pic.twitter.com/owGPckg098
— Miho🍺Nagase (@miholovesq) January 9, 2020

Done

初対面の人とお話ができた。
Regional Scrum Gathering® Tokyo 2019 では参加しなかった OST (Open Space Technology) へ参加した。
登壇した人に話しかけることができた。
自分が日ごろ考えていることの答え合わせや補正ができた。

Learn

scrum のもともとの意味を知ることができた。
- scrummage: 取っ組み合い。
モブプログラミングの楽しさや意義について具体的に知ることができ、自分のチームでやるにはどうしたらよいかイメージをふくらませることができた。
ぼくは / ぼくたちはどうしたいのか、なぜそうしたいのか、いまどういう状態なのか、ということについて定点観測する必要性に気づいた。
スクラムマスターの思考性について改めて考えるきっかけを得られた。
- チームに対してどのように向き合えばよいか?
- 積極的にやることは? 我慢すべきことは?

Day 1

The Ten Bulls of the Scrum Patterns

初日のキーノートスピーチ。

概要

日時と場所

2020/01/08(水) 10:10 - 11:40 Sola City Hall

スピーカー

James Coplien さん

資料

メモ

常に Scrum であろうとすること

自然の道

水が上流から下流へ流れるように
調和を意識する
- チームとの調和
- ビジネスとの調和

十牛図で Scrum における自分の状態を把握する

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

尋牛

越境して調和を求める。

よりよい方法がないか探し求める。
- まだ Scrum を知らない。
- なにか分からないが足りないものがあると感じている。
  - 本当に自分でやりたいこととして進めていない。
  - 上に言われたから、という理由。

見跡

なにかよいものがあることに気づく。

学びを得たいと思っている。
書籍や他者の経験から知見を得はじめる。

見牛

実際にやっている人やチームを見つける。

高い生産性にワクワクする。

得牛

実際にやってみる。

スクラムコーチを雇う。
プロダクトバックログを作ってみる。
- 古いプロジェクトマネジメントの考え方が通用しないことに気づく。
  - ここには要件が存在しない。
  - プロダクトバックログを作る理由を深く理解しないと古いやり方に戻ってしまう。
    - プロダクトオーナーがユーザーの最も欲しているものが何なのかを体現したもの。
    - チームがそれを理解する必要がある。
      - なぜそうなのか?

牧牛

守破離の守。

でも何かモヤモヤが残っている。
やり方がひとつだけじゃないことに気づく。
- Scrum は実験室。
  - 50% のスプリントが失敗しているぐらいでよい。
    - 改善は反省なしでは起こり得ない。
    - しっかりとコントロールされた環境下で失敗をいくつも重ねて成長する。
  - 規律の中で計画する。
    - 計画を変更することも許容する。
プロダクトバックログ
- 優先順位ではない。
- デリバリーの順番。
  - 毎スプリントでデリバリーの順番ややりかたを変える。
  - スプリントのタイムボックスが短ければ短いほどピボットしやすい。

騎牛帰家

手なづけて我が物にする。

Scrum の構成要因の意味や関係を理解している。
- 無名の質を理解できている。
  - それぞれのアクティビティやアーティファクトがなぜ必要なのか?
  - それらが相互にどう効果を与え合うのか?
  - 無名の質についての参考資料: 名前のない品質とパターン言語 - ITmedia エンタープライズ
- 自己組織化されたチームになる。
  - マネージャーは会社やプロダクトを管理するのであってチームを管理しない。
Scrum はプロダクトを作るためのプロセスを構築する。
- Scrum のパターンはフレームワークとして個々人をサポートするだけ。
- プロセスは個々人が心のなかに持っている意思に基づく。
  - 本に書いてあるから、じゃない。
  - 腹落ちが重要。
アジャイルであること
- 常に変化し続けること。
- 常に良くなっていること。
- チームが場を作れている状態。
  - エネルギッシュである / 情熱を感じている。
  - 素晴らしいことをやっているという感覚。
Scrum をやる理由
- 無名の質を高めるため。
- 素晴らしいチームを作るため。
別々のことをやらない
- 1つのチームはひとつのことを集中して行う。
  - チームの中に小さなサブチームがあって別々のことをやると抜け漏れやブロック要因を多く生む。
  - いくつもの案件を同時並行できるというのは古いプロジェクトマネジメントの幻想。

忘牛存人

当たり前の状態になる。

無為
- 変化に毎日対応すること。
- チームが機能するには個人が中心に据えられないといけない。
Scrum のパターンはもともとなかったんだ、という心境。
- すでに個々人の心のなかに染み付いて無意識のうちに無名の質を高めている。
- 作業がオーバーラップして存在し、それをチーム全員が当たり前のように取り組む。

人牛倶忘

何もない状態。

Scrum 自体を忘れる。
息をするように価値を生み出せる。

返本還源

チームが様々なことから学ぶ。

ステークホルダーから
組織から

入鄽垂手

守破離の離。

パターンから自由になって価値を生み出す。
- 本当に価値を生み出せるやりかたを実践できる。

自分なりのやりかたや道を見つける

数多くの失敗をすること。
すべてのことに Why を見つけること。

所感

『カイゼン・ジャーニー』の一節にある「あなたは何をする人なんですか?」という問いを突きつけられているような気がした。

十牛図になぞらえるメソッドは RSGT2019 のワークショップで聞いたのを思い出した。
- 自分やチームがどの状態にいるかを常に意識しておくと、足りていることと足りていないことがわかり、次のステップに進むために必要な物事が見えてくると思う。
  - まさに経験主義。
無名の質を得てそれを高める、という考えかたはなるほどと思った。
- プロダクトやアーティファクトにそれを求めるというよりも、チームの無名の質を高めればおのずとアーティファクトの無名の質が高まり、最終的にプロダクトの無名の質が高まる、というロジックになる。

アジャイルコーチ活用術

アジャイルコーチは何をする人か、何を助けてくれるのか、どうすると効果的に活用できるのか、といったお話。

概要

日時と場所

2020/01/08(水) 13:00 - 13:20 Sola City Hall West

スピーカー

吉羽龍太郎さん

資料

メモ

読むとよさげな書籍

アジャイルコーチング | Ohmsha

頼む前に期待値をはっきりさせること

コーチングを受けて何を実現したいのか?

はっきりさせることで得られる効果
- コーチングの仕方が決まる。
- 自分たちが変化するために必要なことが明確になる。
- やめどきがわかる。

アジャイルコーチが関わって3ヶ月ぐらいで変化が目に見えてくる

それを過ぎていたら何らかの問題がある。

コーチの問題
チームの問題
- プラクティスだけやって満足、みたいになる。

チームのゴールはコーチの支援が不要になること。

所感

コーチングの範囲の広さがすごいと思った。
期待値をはっきりさせることはこの件に限らず何をやるにしても必要なこと。
幸い自分のチームはプラクティスだけやって満足、という状態ではないことに気づけた。

みなさんのプロダクトバックログアイテムは Outcome を生み出していますか?

Output だけでなく Outcome (成果) にも着目しよう。

概要

日時と場所

2020/01/08(水) 13:25 - 13:45 Sola City Hall West

スピーカー

中村洋さん

資料

メモ

Output と Outcome

Output: 作った機能
- 重視しがち
  - わかりやすいから。
Outcome: Output によって利用者がどう変わったか
- 2種類
  - Business Outcome
    - 売上が上がる
  - User Outcome
    - できなかったことができるようになる
    - やりにくかったことがやりやすくなる
- 軽視されがち
  - 計測がめんどくさいから。
どちらか片一方だけを重視するわけではない。
- バランスが大事。
  - Output がないのに Output を語るのも…
  - Output だけ気にかけられて Outcome がなにもないのも…

Outcome を可視化する

各ユーザーストーリーに Outcome の数値をつける。

相対的に決める。

チーム全員で話し合って決める。
- 自信がなければ仮説検証を先にやる。
- 認識がずれていたらすり合わせる
  - ICE スコアなどで手短に。
    - 影響力: Impact
    - 信頼度: Confidence
    - 容易性: Ease

例

大阪のカラコン制作会社
- Outcome を「ダイヤ」という単位でつけてみる。
- ROI を意識できるようになった
  - すぐ終わるストーリーだけどダイヤが高い = ROI が高い
BtoB のシステム開発会社
- どの顧客向けでどれぐらいもうかりそうかを見える化した。
  - 売上や数値目標についても場に出した。
  - それをチーム全員で叩いて作戦を練った。
- PO が利用者からのよい声を吸い上げてフィードバックしていた。

Outcome をユーザーストーリーに反映する

何をどう変えたいのか? をちゃんと記述する。
- そのうえでやるかやらないか、どうやるかを話し合う。

まとめ

いくら Output が多くても顧客に届かなければ意味がない。
着眼点として Outcome を足してみるとプロダクトバックログアイテムへの考えが変わるかも。

所感

Start with why を常に意識するとこの考えかたに行き着くと思った。
- 誰にどんなインパクトを与えたいからやるのか、なぜやるのか。
プロダクトバックログアイテムの並び順の決め手として Outcome の大小を見える化する取り組みは興味深かった。

見積りしないスクラム

Scrum の既成事実と違う話をします。
見積もりやめよう、という話でもないです。
- 見積もりについて考える切っ掛けになればいいな。

概要

日時と場所

2020/01/08(水) 14:00 - 14:20 Sola City Hall East

スピーカー

陶山育男さん

資料

メモ

見積もりの負の側面

どうやっても正確にならない
- 絶対にブレる
パーキンソンの法則
見積もり結果に対するコミット圧力

アジャイルな見積もりと計画づくり

見積もったうえで計画をしなさい。
我々が必要なものは見積もりの数字ではなく以下がほしい。
- 計画
  - これが一番ほしい。
- 効果
- 理由

スクラムガイドによる見積もりの意味

優先順位付けのため
キャパシティプランニングのため
進捗管理のため

PBI の最小化

1週間で終わる程度に小さくする。
- 依存関係を敢えて飲んで分割する。
- バーチカルスライスする。
  - 機能で分けるのではなく、価値単位で分けることは死守する。
  - そうしないとフィードバックや学びを得られないから。

スプリントのすすめかた

スプリントのゴールにコミットする

スプリントバックログのすべてを終わらせるわけではない。
そのスプリントで何を最もデリバリーしたいかにコミットする。

モブプログラミングで勇気を裏打ちする

モブプログラミングをやると依存が小さくなる。
依存が小さくなるとサイクルタイムが安定する。
サイクルタイムが安定するとスループットが安定する。
- 個々人の事情に左右されない。
スループットが安定すると予測可能性が上がる。
パーキンソンの法則を打破できる。
- 1人で考えるよりも無駄な作り込みを省ける。

所感

見積もりではなく計画をする、という考えかたには非常に同意できる。
翻って自分のチームを見てみると、見積もりの負の側面に押しつぶされることなく有効に活用しながら計画ができていると思う。
このセッションを聞いてから、モブプログラミングをやってみようと思い立ってチームで実践し始めた。
- まだ実験段階。

The Product Owner and Scrum Master Brain Transplant! MWUHAHAHAHAHA!!!

概要

日時と場所

2020/01/08(水) 15:15 - 16:00 Sola City Hall East

スピーカー

Alex Sloley さん

資料

Brain Transplant.pdf

メモ

プロダクトオーナーとスクラムマスターの性質

プロダクトオーナー

会社にコミット
理論的
数値を重視
分析的

スクラムマスター

チームにコミット
人間臭い
人が大好き

プロダクトオーナーとスクラムマスターの脳を入れ替えてみたら?

プロダクトバックログに対してスクラムマスターのスキルを活かせる

コーチングの技能を持てる
- プロダクトバックログをコーチングできる。
- リファインメントではなく。
  - プロダクトバックログをコーチングするためにチームをコーチング (助ける) できる。
- 最高のバックログを作れる。
  - ステークホルダーをコーチングできる。
- 要求する人をコーチングする。
育てる要素を持てる
- 成長を取り入れられる。
- 必要に応じて切り捨てできる。
- 周囲に感謝を伝えられる。
- プロダクトバックログが大好きになる。
- プロダクトオーナーはバックログを愛しているはず。
- 盆栽のようにメンテナンスする。
  - 毎日眺めている。
守る
- プロダクトバックログアイテムの質
- チームがプロダクトバックログアイテムを達成できるレベルに高める
  - バランス
障害を取り除く
- プロダクトバックログアイテムを独立させる、依存のチェーンを断つ。
- チームを信頼し、チームに障害事項を指摘してもらう。
実験好きになる
- 新しいやりかたを試す
- プロダクトバックログアイテムを通して実験する。
- ダメだったら引っ込める。
  - 実験的なものとそうじゃないものとのバランスを考えてアイテムを配置する。
紛争を解決できる
- プロダクトバックログアイテムのコンフリクトを解消し適切な順序に配置する。
- チームに尋ねる。
- ステークホルダーに尋ねる。
幸せである
- プロダクトバックログがハッピーに見える。
- 順番が整理整頓されている。
- サイズが見積もられている。
- 内容がきちんと書かれている。

チームに対してプロダクトオーナーのスキルを活かせる

分析的になる
改善ストーリーを作れる
- 人にフォーカスした改善
- チームにフォーカスした改善
- プロセスにフォーカスした改善
価値と受け入れ基準を考える
- 改善ストーリーの AC を作る。
- 改善の価値を見いだして作り出す。
改善のプロダクトバックログができあがる
- チームの改善は公のバックログに。
- 人の改善はプライベートなバックログに。
- 通常のプロダクトバックログと同じ考え方で優先順位をつける。
- 価値の高さ順。
改善の DoD が作れる
- チームを評価する。
- メンバーを評価する。
- 強みを見つけて増幅させる。
改善をレビューできる
- チームの改善ストーリーはプロダクトオーナーがレビューする。
- 完了の責任はプロダクトオーナー。
  - 個人の改善ストーリーはスクラムマスターがレビューする。
改善のループを回す
- どうやったらチームと人がよくなるか、改善されるか考える必要がある。
- 改善の仕事は途切れることなくずっと続く。
- ちょっとずつ改善する。
- 改善のプロダクトバックログアイテムを常にリファインメントする。
  - チームの労力を改善に傾ける。

まとめ

チームの中でお互いに学びながら、よいところを取り入れながら改善していけばよい。
- 越境が必要。
プロダクトオーナーとスクラムマスターは利益が衝突している。
- プロダクトオーナーはチームから絞れるだけ絞りたい。
- スクラムマスターはチームが絞られることから守りたい。

所感

プロダクトオーナーとスクラムマスターそれぞれのものの考えかたや視点を少しでも併せ持つとチームやプロダクトがよくなると感じた。

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

概要

日時と場所

2020/01/08(水) 16:15 - 17:00 Sola City Hall West

スピーカー

椎葉光行さん

資料

メモ

メンバーからテックリードになると

やること増えて大変だよね。
でも未来を作る役割だから楽しいよ。

テックリードとスクラムガイドとの間にある矛盾

職能でやることを分けない。
アウトプットするものの責任はスクラムチームが負う。

実験

テックリードをなくしてみたら

結局テックリードがつらいだけだった
- 視座の違いがある。
- 結局テックリードが決めている。
- メンバーの間にこぼれ落ちるタスクが出てしまいそれを拾ってしまう。

結論

やっぱりテックリードは必要じゃないの?
- スクラムをやるために開発をしているわけじゃない。
- スクラムの枠組みに固執してもしょうがない。

テックリードがやることを減らしてチームへ委譲していきたい

チームが成長するものはチームへ。
チームが開発しやすい環境を作る下地づくりはテックリードへ。

テックリードの登場フェーズ別な立ち位置

成長を支える。
- 段階的に委譲していく
  - Managemant 3.0 "The 7 Levels of Delegation"
- 支える中で学んだこと
  - 変化に適応する
    - チームの成長に合わせて立ち位置が変わる。
      - 技術もものすごい勢いで変わる。
        
        過去の成功体験に答えを求めても意味がない。
  - コミットメントを信頼する
    - メンバーのチームへの献身 (dedication) を信頼する。
    - 行動や努力に目を向ける。
    - メンバーが全力でやったのに成果が伴わないのはテックリードがサポートできないからだ。
      - ごめんね、というマインドになる。
  - 心を否定しない
    - 何かを感じることを否定しない。
    - そう思った根源を一緒に考えて取り除く。
Scrum で目指す姿とチームの現実との差を埋める役割。
- 突如差し込まれる作業依頼。
- プロダクトオーナー / スクラムマスター / テックリードである程度ほぐしてからチームに渡す。
  - ものによっては渡さずにそのまま解決してしまう。
- 次にこうしたほうがよい。という検討とやることの洗い出し。
職能別組織から職能横断組織へ向かうか?
- それぞれにメリットがあるので一概にそうだとは言えない。
- 目指す姿との差を埋め続けていくと職能横断組織になる。
  - 自己組織化される。
- 職能横断組織になることだけが正解ではない。
  - 成長を加速し続けるだけでもよい。

未来を作ること

正解のない世界で自分たちの道を開拓する。

現在地の確認
- 現状を受け入れる。
  - 期待が現在地を燻ぶらせる。
    - このスケジュールでできるでしょ。
    - 職能横断組織であるべきなのに。
    - もう何年もやってるんだからできるでしょ。
  - マイナスにこだわらない。
    - 現状のよいところをたくさん見つける。
    - 現状のよいところにさらによくするにはどうしたらよいか考える。
    - 成長に対する苦労を期待しない。
      - 楽して成果が得られればよいじゃないか。
  - うまくいかないことを誰かのせいにしているときには期待が視界を燻ぶらせていると考える。
目指したい方向の確認
- 自分なりのビジョンを持つ。
  - みんなに意見を聞いているだけだと全然前に進まない。
  - 強い信念を持って目指したい未来を描く。
    - 例
      - 成長する場としてのチーム
        
        3年ぐらいで人が抜けちゃう。
        
        でもチームには何かを残している。
        
        人に固執せずチームという場が成熟する。
進む
- 選ばない選択もある。
  - あのとき別の選択肢を取っていればよかった、という後悔は不要。
    - あれもこれもは取れない。
    - 選択しなかった選択肢もちゃんと受け入れる。
      - 選択しなかったことをリカバーすることもちゃんと考えていたんだからそれでよい。

失敗から学習する。

テックリード自身もがんばりすぎない

チームと向き合うときの考え方を自分にも適用する。

変化に適応する
コミットメントに信頼する
心を否定しない
現在地を確認する
目指す方向を確認する
進む
- 選ばない選択も尊重する。

所感

テックリードの役割から見たチームビルディングの話で、スクラムマスターが聞いても示唆に富む内容だった。
サーバントリーダーシップだと思った。
現状を直視し受け入れたうえで少しずつよくする = 自律するにはどうするとよいのかを常に考えながら様々なアプローチを選択する、というテックリードの役割がかなり大変そうだと感じたが、そのぶんやりがいはありそう。

Day 2

Lost in Translation: The Manager's Role in Agile

2日目のキーノートスピーチ。

概要

日時と場所

2020/01/09(木) 10:10 - 11:40 Sola City Hall

スピーカー

Michael Sohota さん

メモ

タイトルの由来

同名の映画から。
- 西洋から日本へ仕事に来たがやり方が全然違って困ってしまう話。
アジャイルが浸透してきたときにマネージャーがどう振る舞うかがわからず混乱する。
- マネージャーへのヒントを与えたい。
- リーダーの意識を変えてチームのパフォーマンスを向上させたい。

自己組織化されたチーム

本当にそれが実現できるチームがないのが実情。
- 「Scrum はヒエラルキーを破壊するためのもの」
  - 単純にヒエラルキーを破壊してネットワーク型組織にすることではない。
  - ヒエラルキーをひっくり返してチームが組織を引っ張る、という手法にするのも無理がある。
- いきなり自律でやれ、といっても死が待っているだけ。
アジャイルを採用したチームが直面する課題
- マネージメント層のサポートがない、という理由が第3位。
じゃあどうするか?
- 別のチームと相互に関係性がある責任を持ったチーム
  - ヒエラルキーは維持したまま。
    - ティールを採用した企業でもヒエラルキーはある。
  - 人を進化させる。
    - マインドセットを変える。
    - 通常のビジネスでのやり方から引き上げていく。
      - Power & Structure
      - Achievement
      - People
      - Shared power
      - Business as usual
      - Embrace complexity
    - 組織の成長は個人の成長の結果の集合。
      - どうやって進化させる?
        
        ボトムアップで始めた場合
        
        数人の意識が変わっただけで全体への影響が与えられない。
        
        小さな成功であればボトムアップでもよいが組織全体を変えるには至れない。
        
        トップダウンで始めた場合
        
        組織全体への影響を与えられる。
        
        責任のある人から始める。
        
        リーダーシップが重要な成功要因。

従来型のリーダーシップじゃダメ

アジャイルなマインドセットを持ってもらう必要がある。
- アジャイルなマインドセットとは?
  - 学びの文化: よりよいやりかたを探す。
  - 複雑かつ不明瞭な環境下でリーダーシップを取る必要があるという認識を持つ。
  - 対話の重要性。
- プロセスよりも人が重要だという認識。
リーダーが進歩的な振る舞いをすれば他の人もそれに追随する。
- セオリーX からセオリーY へのシフトが出発点。
  1. 情熱を持つ。
  2. 周りへの気遣いをする。
  3. 責任を受け入れる。
  4. 自分でやりかたを決めてすすめる。
- 少しずつ継続的に権限を委譲していく。
  - マイクロマネジメントからの脱却。
  - ステップバイステップで。
  - アジャイルに実験しながらすすめる。
    1. I decide.
    2. I decide after seeking advice.
    3. We decide together.
    4. I advice.
    5. Please let me know.

相互関連型のチームを作るためにマネージャーは何をするか?

権限を委譲できたら次にマネージャーがすること。
ロールはなんでもよい。
- プロダクトオーナー
- スクラムマスター / スクラムコーチ
- 組織コーチ
- テックリード / アーキテクト
- その他
マネージャーの権限移譲とロール変更をどうやってサポートするか?

アジャイルには肥沃な土壌が必要

肥沃な土壌に種をまかないと芽は出ない。
組織の文化がアジャイルを受容できないのが問題。
- 我々がまず変革し、リーダーへ影響を与える。
- リーダーがよいやりかたを受容し、組織の文化へ影響を与える。

凍りついた中間管理職

トップからアジャイルやれと言われてボトムからアジャイルやれと言われて固まってしまう。
トップや中間のメンタリングやコーチングが足りていない。
- まずは変化のチャンスを与える。
  - 新しいジャーニーに進むかどうかを考えてもらう。
  - そのジャーニーに乗るか乗らないかはマネージャー自身に決めてもらう。
    - もし乗らない場合には会社を去るかもしれないがそれはそれでしょうがない。
    - 強制するのではなく検討し決断するチャンスを与える。

A new way of being enables a new way of working.

心持ちと行動が周りを変えるよ。
- 自分が変われば相手を変えることができるよ。
人の成長に価値をおく。

所感

とかく会社や管理職とアジャイルをやりたい現場との軋轢や対立が取りざたされるが、ボスもちゃんと巻き込んで進められれば強くなれる。
でも管理職もいわゆる Y理論のマインドを持つ必要があり、双方の歩み寄りが必要。
アジャイルについてのトップや中間管理職へのメンタリングやコーチングが足りていない、という指摘はたしかにそうだと思った。
- アジャイルにやったところでスピードが早くなるわけではないことを理解してもらったうえで、スピード以外に得られるものについて理解してもらう必要がある。
アジャイルには肥沃な土壌が必要で、まず土を作るのは僕たちだ、という指摘にも納得できた。
- 紆余曲折あって腰折れになっちゃったけどそういう進めかたで少しずつ改善してきたことを思い出した。

チームの再定義 -進化論とアジャイル-

概要

日時と場所

2020/01/09(木) 13:00 - 13:45 Sola City Terrace Room

スピーカー

kyon_mm さん

メモ

Scrum のフレームワークをそのまま使って複数のチームを集めてやる

ポジショントークする

話す側: ポジショントークだと割り切って話す。それを聞く外部の人がいるから自信を持って話す。
聞く側: 客観的に広い視野で聞く。

効果

聞く側のスキルが向上した。
- 話す側へ関心を傾けて意識するようになった。
- 意識されていないとフィードバックが場当たり的でいい加減なものになってしまう。

なぜチームを作りたい?

人間には同盟を作りたがる習性がある。
緩やかでもいいからつながりを持って同盟を作ってみる。

所感

メモは内容をだいぶ削ったので見ても意味がわからないかも。
チームを作りたがる習性について言及していたのがおもしろかった。
- あと承認欲求とかフィードバックを得たいという欲望もあるのではないかと感じた。
やっていることが異なるチームもまとめてひとつのチームにすることで、話をする側と聞く側それぞれがお互いに理解できるよう工夫しながらコミュニケーションする必要性に気づいて、認識のギャップを埋めようとする試みを自律的に行っている点が興味深かった。
- 聞く側が全力で聞かないと内容を理解できずフィードバックがいいかげんになる、というのはなるほどと思った。

最高の Scrum をキメた後にスケールさせようとして混乱した話

概要

日時と場所

2020/01/09(木) 16:40 - 17:00 Sola City Hall West

スピーカー

藤村新さん

資料

メモ

最高だったとき

明確なコンセプト
3つのフェーズ
- 世に出せる状態を最初から維持していた

フェーズ1: MVP

背骨を作る
この時点でリリースできる状態のデザインは固めておく
- この時点でやらないのはアンチパターン

フェーズ2: MUST

機能追加
デザイン変更は受け入れる

フェーズ3: ADDITIONAL

最終調整
- エラーの挙動を調整
- デザインのフィードバック対応

スケールした

チームの内容

最高のチーム
保守チーム
顧客データ分析チーム

やりかた

Scrum of Scrum
開発メンバー 15名
PO が 2人

すぐに失敗した

コミュニケーションパスが多すぎる
- スモールチームがよい
チーム目線で構成を考えていない
- 組織目線
- やることの違うチームをくっつけて効率が悪化

改善

チームをちゃんと 3 チームに分けて PBI も分けてやった。
- 小さなチームで回すと自然にチーム間でのコラボレーションが発生する

所感

開発メンバーは 7±2 がよい、と言われているが、たしかにこれ以上増えるとタスクへの理解レベルの統一が難しくなる。
デザインを MVP フェーズで固めておくのはよいアプローチだと思った。
よいスモールチームは自律的に連携する、ということの好例だと思った。

Day 3

OST (Open Space Technology)

みんなと話し合いたい議題のある人が一列に並ぶ。
概要を書いた紙を持ちながら1分でプレゼンする。
その議題ごとに 30分の時間割り当てで複数箇所で話し合いをする。
- 話し合いの主催者になりたい人は立候補制。
- 話し合いに参加したい人は好きな議題のところへ。
- 話し合いに参加せず見ているだけでも OK 。

ふりかえりの悩み

30分のタイムボックスではみんなで悩みを披露する + いくつかのテーマで少し話すので精一杯でした。そのとき話した内容で覚えているのは以下のとおりです。

Action が出ないなら出ないでそれでよい。
- 本当に Action が必要なものならばまた別の機会のふりかえりで話が出てくる。
KPT あんまり好きじゃない。
よかったと思うことから、さらによくするためにどうするかを考えるほうがよい。

スクラムマスター ≠ ベビーシッター

沈黙を恐れない。
- なるべくチームメンバーに発言してもらうようあの手この手で仕向ける。
これってなんでですかね? どうしてですかね? を常に問うこと。
チームメンバーの一挙手一投足にいちいちハラハラしていてもしょうがない。
- スクラムマスターはチームメンバーから見て、友だちのカーチャンぐらいの気持ちでいるのがちょうどよい。
  - 人んちの子だからそんなにあれこれしつけるとか考えても仕方ないでしょ? 的な。

NEXT→ACTION

今回のクロージングキーノート。

概要

日時と場所

2020/01/09(木) 13:00 - 14:30 Sola City Hall

スピーカー

高橋一貴さん

メモ

資料も非公開の予定だったのとクロージングキーノートだった (OST 後に自分たちで椅子を持ち寄って座席を作り上げた) のでメモせず心に残すのみとしました。

所感

何かを変えるときに踏むべきプロセスや味方の付けかたが興味深かった。
一見すると単騎だけど内部で同じ悩みを抱える人たちや外部のコミュニティのメンバーもいるからひとりじゃない、という考えかたには勇気を与えられた。