Regional Scrum Gathering Tokyo 2019 メモ

概要

• 2019年1月9日から11日にかけて開催された Regional Scrum Gathering Tokyo 2019 に参加してきました。盛りだくさんのセッションとワークショップでお腹いっぱいになったのですが、その中から個人的に特によかったものをピックアップしてメモを残しておきます。
• 自分向けのメモの色合いが濃いので他のかたが見るとわからない部分もあるかもしれません。すみません。

メモ

Day 1: Outcome Delivery: delivering what matters

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

• 日時: 2019/01/09(水) 10:10 - 11:40
• 登壇: Gabrielle Benefield さん

マインドマップ

まとめ

問題を理解できていないと出てくる回答が的外れになってしまう

• 作ることにフォーカスしすぎると結果のピントがずれる。
• What から Why を洗い出す。

Agile Practice が非常に多い

7 things wrong with Deloitte’s Agile Tube Map – Bz Skits – Medium

• デロイトが作った The Agile Landscape
  • すでに Agile はシンプルではなくなっている。
• 本来の Agile って何?
  • モノを正しく作ること。
  • Scrum は間違ったものでも早く作ってリリースできる。
    • 早くリリースして間違いに気づいて修正できる。
    • 早くテストできるからさらによいものにブラッシュアップできる。
• Agile Practice をシンプルに活用するために「メビウスループ」を考えた。

メビウスループ

Outcome Delivery | Outcomes over Outputs

メビウスの輪を3つに分解する。

1. ディスカバリーループ
   • デザイン思考
     • 何をすべきかを発見する
       • 問題を洗い出す
   • モノサシを用意する
     • 効果を得られているかを評価する
2. オプションピボット
   • どうすればよいかの選択肢
3. デリバリーループ
   • アジャイルな開発
     • 正しいものを作る
     • 公開して顧客に届ける

それぞれのポイントで何をどうやるかはたくさんのプラクティスの中から最適なものを選べばよい。

Outcome Delivery

1. Discovery
   • いま何が問題になっているか、それを解消して何を得たいかを洗い出す。
     • 眼の前に見えている解決策で真に得たいことを得られるとは限らない。
   • 問題を解決するためにやることを洗い出す。
     • やることそれぞれに対して、得たいことがどのぐらい得られるかをポイント化し、トータルポイントを算出してみる。
   • 計測すべき指標を洗い出して、ループを回してその指標がどうなっていったかをトレースする。
2. Option Pivot
   • 選択肢を比較して何から実現するかを決める。
     • 最もシンプルなものはなにか?
     • 顧客に最も価値を届けるものはなにか?
3. Feedback, Learn
   • ループを回す中で得られた気付きから次に生かせるものを洗い出す。
   • どうすれば次のループをより効果的に回せるか、アクションを考えて適用する。

成果主義

• 何をやったかというよりもどんな成果を得られたか、で評価する。
• 方法にこだわるのではなく、得られる結果にこだわる。

例

• 問題
  • ある小学校の廊下が狭い
    • 終業のチャイムが鳴ると生徒が一気に廊下に出て大混雑する。
    • 廊下で生徒同士のいじめや小競り合いが始まる。
• 表面的な解決策
  • 改築して廊下を広げる
    • コストがかかる。
    • 本当に解決したい課題に到達できていない。
• 成果の出る解決策
  • 教室ごとに終業のチャイムを少しずつずらす
    • コストがかからない。
    • 本当に解決したい課題に到達できた。

気づき

いかにシンプルになれるか

• 「できるだけやらない、作らない、でも価値は提供できる」
  • 何かをやったことに価値があるのではなく、提供したものでどんな成果を得られたか、で評価する。
  • 得られる成果はなにか? を考える。
• 機能をどんどん追加することだけが価値提供ではない。
  • おばあさんのためにガムテープがぐるぐる巻きにされたTVリモコン
    • 電源 ON / OFF と チャンネルと音量が押せればそれでよく、他の機能はいらなかった。

プロダクトの状態を計測するモノサシが必要

• 状態を見える化すると、Option Pivot でどの選択肢を採用すればよいか分かるようにする。
  • ビジョンやゴールへ近づけているかの指標
  • 適用した Option が本当に目指したいことへ進むための選択肢だったかどうか

Day 1: チームワークの会社で最高のプロダクトを目指すチームができるまで -強くてスケールするチームの作り方-

サイボウズさんのチーム作りのプラクティス紹介。

チームワークの会社で最高のプロダクトを目指すチームができるまで / RSGT2019 - Speaker Deck

• 日時
  • 2019/01/09(月) 13:00 - 13:45
• 登壇
  • サイボウズ株式会社
    • 天野祐介さん
    • 大友聡之さん

マインドマップ

まとめ

エンジニアをどんどんユーザー / ビジネスサイドへ巻き込む

• 来た要求をこなすだけじゃない
• 「なぜ作るの?」を追求

チームに「ゴールテープを胸で切る」ぐらいでゴールしてほしい

• とにかく全力でスプリントを走り抜けてほしい。
• 「固定枠」や「ゆとり時間」みたいなバッファがあると全力感がない。
• 全力で駆け抜ければ、仮にスプリント内のストーリーがすべて Done しなくても、PO も認めてくれる。
  • PO とメンバーとの信頼関係があるから全力をつくすべき。

2週間スプリント → 1週間スプリント

• 「月に失敗できる回数が増える」という考えかた
  • 改善できる回数が増える。

スプリントプランニング

• 事前のバックログリファインメント担当の廃止
  • 詳しい人が事前調査をしていて、その人の調査結果に基づいてストーリーポイントや時間見積もりがされていた。
    • スプリントバックログに固定枠があった。
  • その人が忙しくなったら身動きが取れなくなるので、事前調査タスク担当を決めて作業する制度をやめたほうがよい。
• 固定品質向上枠の廃止
  • 全体工数の2割ぐらいを品質向上やスキルアップのためにとっていたがそれをやめる
• まる1日レベルのプランニング
  • コードを見ながらどうするかをその場で話し合いながら決めていく。

スプリントレトロスペクティブ

• 問題共有の場から仮設・検証の場へ
• ふりかえりの Try もプロダクトコードを書くことと同じぐらい重要

デイリースクラムの改善

• ふりかえりの改善アクションをデイリースクラムで確認するようになった
• デイリースクラムの意義をメンバーが考えて議論するようになった
  • モブやっているので情報共有はあまりしない
    • じゃあ何を話そうか?

苦痛なプランニングからの脱却

聞く時間を短くしてプランニングを苦痛なものにしない工夫。

• アウトプットの時間を短くする
  • パーキングロット
    • とにかく疑問点を全員に書き出してもらう
    • パーキングロットに挙がった疑問点を潰す
• 複数チーム間で1か月ぐらいでメンバーを入れ替えちゃう
  • コンフォートゾーンに入れさせない
    • 自然と自律する

気づき

• およそ1年でここまでやったのがすごい。
• 「胸でゴールテープを切る勢いでスプリントを駆け抜ける」
  • CSM 研修でこの手の話あったな
• パーキングロット使えそう。
• コンフォートゾーンに入れさせない工夫がおもしろい。
  • 大友さん「僕がやれって言ったんじゃなくて天野さんの趣味ですけどね」

Day 2: Learning to Experiment

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

• 日時
  • 2019/01/10(火) 10:10 - 11:40
• 登壇
  • Chris Lucian さん

マインドマップ

まとめ

どんな人か?

Chris Lucian

• モブプログラミングの提唱者。黎明期からやっている。
  • 所属する Hunter Industries でモブプログラミングをやり始めたのがきっかけ。
• あらゆることをモブでやっているらしい。

実験をしよう

茹でガエルの法則の話。

• 何かを変えようとするきっかけは緊急事態が発生しないと生まれない。
  • しかし大抵の場合はその時点ですでに手遅れ。
    • 競合他社に大差をつけられているかも。
    • 会社を去らなければいけない事態になっているかも。

どうして大事故や緊急事態が起こるまで待っているのか? その前に実験をして自分で変えていこう。

どうやって実験できる状態にするか?

• 安全性の確保
  • 心理的安全性
    • 批判がない
    • 互いのフィードバックを自由に言い合える
  • 変えたいことがあったら作業を止めて議論して安全に変えていく

失敗する可能性の高い実験こそが学習を最大化させる。

チームが必要とするもの

• Kindness, Consideration, Respect
• Vulnerability, Trust, Appreciation
  • Vulnerability: 自分が傷つく (損失を被る) かもしれないとわかっていながら相手と協調する
• その他、非常に高い目標
  • 継続的デリバリー: No one between code and production
  • 読めるコードの維持
  • 誰でも休暇が取れる: サイロ化していない
  • 毎日本番環境へデプロイ: サイクルタイムを極力短くする
  • Zarro baags: Zero bugs

学習セッション

実験のための燃料。

• 答えを探す時間と空間
  • 毎週2時間の枠を設けるなど
• 思考の枠を広げる

マイクロレトロスペクティブ

• 45分ぐらいの短い単位で強制的に手を止めてふりかえる、の頻繁なくりかえし。

見積もりの危険性

• 見積もりはチームの前進をスローダウンさせる
  • 見積もりは繰り返し出現するものを評価する
    • 前にやったことは見積もれる。
  • 新しい試みは罰せられる
    • 新しいことはうまく見積もれない。
    • すでに見積もりが完成しているので新しい試みを差し挟めない。
    • 緊急事態にならないといまのやり方を変えることができない。
  • サティア変化モデル (Satir Model) は無視される
    • 新しい試みがなければカオスが生まれない
• 見積もらない代わりに
  • タスクを非常に細かく分割する
  • タスクかんばんですべてのやることを見える化する
  • 頻繁にデリバリーしてプロダクトオーナーに動くものを見せ続ける

気づき

モブ作業がチームにもたらすメリット

• 学習セッション
• あらゆるものをモブプログラミングでやる

見積もりをやめる

• かんばんのアイテムを全員で各個撃破
• モブができてこそ実現できる
• 経験主義が陥りやすい弊害を打破しないとイノベーションが生まれない

変化のためには実験が必要だということ

build - measure - learn のサイクルを回す

どれだけ早く動くものをプロダクトオーナーに見せられるかがカギ

出来が悪くてもとにかく見せるとか

Effective Retrospective / とにかく楽しいふりかえり

Effective Retrospective とにかく楽しいふりかえり - Speaker Deck

• 日時
  • 2019/01/10(火) 13:00 - 13:45
• 登壇
  • 森 一樹さん

マインドマップ

まとめ

ふりかえりの楽しさが大切

• ふりかえりが楽しいと、参加者は「効果的だった」と感じる。
  • 実際に効果的だったかどうかは別にして。
• チームが楽しいふりかえりを繰り返すことで新しいアイデアが生まれ、お互いに協力しあって改善を前進させる。

ふりかえりの目的: 3つのステップ

1. 立ち止まる

• これまでがどうだったかをふりかえるためにいったん立ち止まる。
  • 形骸化したプロセスやコミュニケーションを直す。
  • 靴紐が解けたまま登山すると事故を起こすから「いったん立ち止まる」。
• 視野を広げる
  • いったん立ち止まって冷静になる。
  • チーム全員で強制的に立ち止まって問題の全体像を見つめる。

2. チームを成長させる

• 「人」と「関係」に着目する。
  • スクラムガイドにも書かれている。
  • メンバー間の関係の質を高めることを意識する。
  • ふりかえりのタイミングでチームビルディングしてみるとよい。
    • 感謝を伝える。
    • ワーキングアグリーメントを見直す。
    • 今月の目標を話してみる。
• 全体最適化を考える
  • 最もボトルネックになるところを改善する。
  • 関係の質が高くなければできない。

3. プロセスをカイゼンする

• 「改善」と「カイゼン」の違い
  • 改善: よくないところを直す。
  • カイゼン: よかったところをさらに伸ばす。
• すべての問題を解消する必要はない
  • すべてを解決するのはムリがある。
  • 最もコアな問題だけを解決する。
  • 関係の質が高ければ、メンバー内で自然に問題を解決していく。
• うまくいったところ、よいところを探して伸ばす
  • 人間は自己防衛本能のせいで失敗に目が行きがちでよいところを探しにくい。
  • この性質を敢えてはねのけてよいところを意識的に見つけるよう心がける。
    • 自己承認を意識すると他者の承認もできるようになる。
      • 自分のうまくいったところを自分で「褒める」「認める」
      • 他人のよかったところに目が行くようになる。

楽しいふりかえりにするために必要なもの

場

• 安心して対話できるような場作りが必要
  • 心理的な場作り
    • 前向きな対話ができる準備をする。
      • 5~10分程度のアイスブレイク。
      • 漫然とやらずに意図を持って場作りをする。
    • プラスのことを考える「前向きスイッチ」を入れる。
      • 心に余裕があるときによいアイデアが生まれる。
        • 例: Good & New
          • 今週の活動の中で「よかったこと」はなんですか?
          • 今週の活動の中で「新しい発見」はありましたか?
    • 議論ではなく対話
      • 互いの意見を尊重してミックスした新しい意見を生み出す。
        • アクティビティ: DPA (Design the Partnership Alliance)
          • ふりかえりの場をどうするかを全員で決める。
            • 今回のふりかえりはどのようにしたいですか? どんなゴールを目指したいですか?
          • グラウンドルールをファシリテーターが決めるのではなく、参加者が決める。
            • ふりかえりを「他人ごと」から「自分ごと」へ引き寄せる。
  • 物理的な場作り
    • 会話しやすい環境づくり。
      • 人 vs 問題の構図にする。
        • 対面式でなくホワイトボードに対してみんなが向き合う。
        • 付箋紙を貼りながら全員が動く。
    • 空間を最大限活用する。
    • リラックスする。
      • BGM
      • 飲食

学びと成長

• 学びを大切にする
  • 過去からの学び
  • 現在からの学び
  • チームからの学び
• 学びを共有する
  • コラボレーションを生み出しやすい。
  • アクティビティ
    • Fun / Done / Learn
    • Celebration Grid
    • 学習マトリックス

成長を実感する

• うまくいったことを自覚するとモチベーションを高めることができる。
  • 自己効力感
    • 自身のスキルの成長
  • 集団効力感
    • チームメンバーとしての成長
    • チームの成長
• 「ここまでできる」と境界線を引ける
  • 自信が持てる
  • さらなるチャレンジにつながる

気づき

非常に実践的でおもしろいセッションでした。過去にやっていたアクティビティを再認識するきっかけにもなりました。

• ファシリテーターはチームメンバーに、場作りを通して問題に対して全員で向き合う姿勢を作り出すことが重要であることに気づけた。
• ファシリテーターはチームメンバーに、課題にばかり目を向けて後ろ向きになるのではなく前向きな思考にさせるようファシリテートする必要があることに気づけた。
• アイスブレイクが重要。昔やったっけ。

総括

Fun / Done / Learn でまとめてみました。

Fun

• かつて学んだこと、忘れかけていたことを再び思い出すことができた。
• Keynote session がどれも刺激的だった。
• みんな話しかけるのに積極的。
  • 他のカンファレンスだとこんなのないと思う。
  • よく考えたら CSM 研修のときもいかに積極的に話しかけるかがカギだったことを思い出した。
  • ボケっと立っていると誰かに話しかけられる。
    • 話しかけるのを自身の目標にしている人。
    • 懇親会でお酒が入るとさらに気さくになる。
    • 話しかけるきっかけづくりのチラシを配っているブースがあった。
      • 「書かれているお題で話しかけた3人に、チラシの欄に猫の絵を書いてもらったらベルティあげる」
• 壁に貼られた「学んだこと」の付箋紙の山がすごい。

うわー、うわー、うわー！！！

つくってよかったー！！
うわー！

感動！#RSGT2019 pic.twitter.com/gysEwW1Kk3

— びば（森のフレンズ）／技術書典6 ふりかえり読本 学び編 (@viva_tweet_x) 2019年1月11日

Done

• ワークショップへ参加した。
  • 本当は3つ全部出たかったけど2つだけ。
• 登壇した人へ話しかけることができた。
• Coach's Clinic を活用できた。

Learn

• グラフィックレコーディングやってみようと思った。
  • マインドマップでもいいかもしれないけど絵でまとめたほうが理解を深められそう。
  • ガー・レイノルズ『シンプルプレゼン』の世界と同じ。
    • 深く思考するときにデジタルツールはご法度。
• アウトプット大事。
• やり方じゃなくて価値観を解くことに軸足を置くべきだと気づいた。
• 次はこっちから誰かに話しかけてみたい。
• Scrum が「人にフォーカスしたフレームワーク」だと改めて気づいた。
  • お前それ CSM 研修で聞いてただろ。