振り返りを積み上げて自分たちのプラクティスとして昇華•体得していくための仕組みと考え方 / ScrumFestMikawa2021

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 当発表の根底にある課題意識 “私個人がチームを育てていくなかでこの振り返りについて課題に感じていたのが振り返りがフロー情報で流れていってしまう点でした。当該チーム内の暗黙知として共通認識となればよいのですが、新入社員を受入れていったりチームが大きくなる段階では、流れてしまった振り返りで得られた「自分たちのプラクティス」がストックされないのは、チームの学び・成長に対しての確かな実感としては少々弱いのではないでしょうか？” 2 https://confengine.com/conferences/scrum-fest-mikawa-2021/proposal/15589 - Kazuki Higashiguchi (@hgsgtk) -

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 当発表によって得られないもの ● パタン・ランゲージを始めとしたクリストファー・アレグザンダー氏の考え方の詳説 ● パタン・ランゲージの実践としての事例 ○ パタンが持つ幾何学的構造やcentoring processなど未実装の点が多く、パタン・ランゲージの実践という視点で見ると不十分な点があります ● シンプルに振り返りを通じてよりチームが成長するために行った施策・事例としてお聞きください 4

Slide 5

Slide 5 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. @hgsgtk Kazuki Higashiguchi 東京に住まう Software Engineer / BASE BANK, Inc. Engineering Manager 自己紹介 5 Agile Testingへ意識高めたり、 Pattern Languageに興味持ったり、チームの成長の試行錯誤をしたり、学習のフィードバックループをいかに最速で回すかに強い関心があります

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. Inspired by 「プロジェクトランゲージ」 “そこで私がチームビルディングの考え方でインスパイアされたのが、建築家クリストファー・アレグザンダー氏の「パタン・ランゲージ」という概念の文脈で語られる、自分達に合わせてチューニングした「プロジェクト・ランゲージ」というものです。” 8 https://confengine.com/conferences/scrum-fest-mikawa-2021/proposal/15589 - Kazuki Higashiguchi (@hgsgtk) -

Slide 9

Slide 9 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 建築家クリストファー・アレグザンダー ● XP・Wiki・Design patternなどソフトウェア開発に大きな影響を与えた都市計画家・建築家 ● 生き生きとした場所をもたらすことを目的とし追い求めている ● 「パタン・ランゲージ」・「無名の質（Quality Without A Name)」...etc 9 https://en.wikipedia.org/wiki/Ch ristopher_Alexander “すべての建築の目的、その幾何学的構成の目的とは、生き生きとした場所をもたらすことである。建築の中心的課題は、人が生きるに値する暮らしを送れるように、生き生きとした心地よさ、深い満足—時には刺激—を維持し、促進するような構造を想像することである。このような目的が忘れ去られたとき、語るに足る建築など全く存在しない。“ Christopher Alexander 著『The Battle for the Life and Beauty of the Earth: A Struggle Between Two World-Systems』

Slide 10

Slide 10 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. パタン・ランゲージ ● 建築において繰り返し現れる構造を再利用しやすい形式にまとめたもの ※1 10 ※1 非常に雑にまとめたので詳細は『デザインパターンの使い方をパタン・ランゲージとの比較から考える / design-pattern-usage-inspired-by-pattern-language』など参照のこと ● 利用者と設計者の共通言語（ランゲージ）として使うことで、利用者が自分自身で建築の設計を行い、本当に望んだ建築を実現できるようになることを目指した

Slide 11

Slide 11 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. プロジェクト・ランゲージ ● それぞれのプロジェクトに合わせて調整した「プロジェクト・ランゲージ」を作成する ※1 ● この捉え方にインスパイアされて、汎用的な概念を実際に用いるには、自分たちのチームが自然と使える語彙を作ることが重要だと考えた 11 ※1 井庭崇著・編集中埜博他著『パターン・ランゲージ:創造的な未来をつくるための言語 (リアリティ・プラス) 』内の中埜博氏の解説 ● “パタンランゲージからプロジェクトランゲージへ” ● “From pattern languages to "a project language": a shift proposal from existing pattern community”

Slide 12

Slide 12 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 汎用性のあるScrum Scrumは汎用的なフレームワークとして様々なソフトウェア開発のチームで基礎として用いられる 12 “Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.” https://www.scrum.org/resources/what-is-scrum

Slide 13

Slide 13 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 事実上別のプラクティスもセットに用いる ● 技術プラクティスが骨抜きにされた「FlaccidScrum（ヘロヘロスクラム）」を回避するため、必要なプラクティスを組み合わせる 13 Scrumを擁護しておくと、技術的アクティビティをそのスコープに入れていないというだけで、それを重要だと考えなくてもいい、ということにはなっていない。有名なScrummerに話を聞くと、 Scrumプロジェクトを成功させるには技術的プラクティスが不可欠だといつも強調している。 Scrumが技術的プラクティスを規定していないだけで、実際には必要なのである。ヘロヘロScrum

Slide 14

Slide 14 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 各プラクティスは各自チューニングが必要 ● プラクティスをオリジナルに使い始めるが、Shu-ha-riを経て自分たち独自のエッセンスが追加されていく ● たとえば、「ペアプログラミング」の活用頻度はチームごとに様々である※1 。自分たちにあわせてチューニングするものが多数 14 ※1 『Clean Agile 基本に立ち戻れ』にて Robert C. Martin 氏は、ペアプログラミングについて、ペアになることは任意であり強制されるものではないし、常にペアになるわけではない点を説明しています。一人でコードを書きたいこともあるので、個人・チームがどのくらいの割合で行なうか決めればいいと。

Slide 15

Slide 15 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. Agileなチームの自分たちの語彙の重要性 ● AgileないしScrumを用いたプロダクト開発において、プラクティスは自分たちのために組み合わされ、肉付けされる ● あるいは独自のプラクティスが生み出されていく ● これらをフロー情報として流さずに、自分たちの語彙・プラクティスとしてストックできれば、迷わずにコミュニケーションできる 15

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 振り返りで学びのサイクルを回す振り返りは「抽象」のフェーズスプリント内で経験した「具体」を収集・分析、次の「応用」を発見することが目的の一つ 17 具体→抽象→応用という学びのサイクル ● 具象: 具体的に情報を収集し、 ● 抽象: 複数の具体的情報から共通するパターンを見出す・どこが重要でどこが枝葉かを判断し、 ● 応用: 実践して検証する

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 当事例のチーム状況 BASE BANK 2021年10月 Scrum Fest Mikawa 20 2019年少人数開発 2018年初期リリース 2020年徐々に人が増える 2021年1月 Engineer / Biz ++ ● 2020年徐々に人が増えたタイミングからアジャイル開発を始める ○ 2020.06 speakerdeck: 小さなチームが始めたアジャイル開発 ○ 2020.07 speakerdeck: 少人数でのアジャイル開発への取り組み実例（一歩目の踏みだし方） ● 採用活動が進みmin3人 -> 12人 ● もともとSoftware engineer職で構成されていたが、BizやDesigner職の採用も進み職能横断型チームに

Slide 21

Slide 21 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 当事例のチーム状況 BASE BANK 21 product team 2021年10月 2020年 2021年1月 feature B feature A feature A feature B Product Backlog Retrosp ective Product Backlog Product Backlog Retros pective Sprint Review Sprint Review Sprint Review ● 最初は1つのProduct Backlogでイテレーション開発を行うチーム ● 人が増え扱うFeature・Projectが多様化によるSprint Goalの違いから、2つの Scrum teamに分かれてプロダクト開発している

Slide 22

Slide 22 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 自分たちのプラクティス BANK Team Practices ● Miro上に整理したプラクティスの一連 ● 振り返りで気づき実験した内容をマップで関係性を明示 ● それぞれの詳細について図示している 22 https://devblog.thebase.in/entry/bank-practices-2020

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 2. 数回スプリントを回して実験 26 数回イテレーションで実際にどのような効果があるか実験してみます例：最近TwitterのTLで話題だったKPTの書きづらさ問題 ● →「出来事」ベースで書けることが明示的なワークをやってみましょう ● → プラクティスの種として「YOT※1 」を登録 ● (Yやったこと-O思ったこと-T次にやること） ※1 YOTはYWTをforkした独自なワークフォーマットです。Wわかったことがお気持ちを書きづらいという課題からOおもったことに変更しています。

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. この取り組みをして得られたGoodな効果 ● 改善・学習のループを回してその結果を一つのマップにした、総決算してまとめるとチームの学び・成長に対しての確かな実感となった ● ソフトウェア開発の見積もり等の分野で、失敗から学んだ教訓も含まれたプラクティスになった ● メンバー間相互に伝えやすい（例：「そういうときはココにある通りSpikeを使ってみよう」） 31

Slide 32

Slide 32 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 課題（1）プラクティスマップの管理・記録方式 ● 最初GitHubに文章として書いていた ○ wikiのような相互リンクで連なる関係性が作りたかった ○ 「文章」は書くハードルが高い故、毎回書いて更新するのは更新不可が高く、レトロスペクティブのファシリテータはローテしても編集者は固定となっていた ○ 編集のしやすさ・全体像のみやすさを重視、Miro onlyでの更新に変更した 32

Slide 33

Slide 33 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 課題（1）プラクティスマップの管理・記録方式 ● しかし、Miroボードはいわばホワイトボードの付箋のようなもの、それだけでは新入社員の方に「こういうプラクティスがあるから参考に」と渡しにくい上記の課題感により次の方式へ移行していってる ● 全体像をMiroボードで、各詳細はBiz・Designerメンバーによる編集も見据えて社内ドキュメントツールに文章化 33

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 当発表で得られたもの１２３ ”自分たちのプラクティス”として昇華していくための考え方の一つを知る → 振り返りを起点に学びのサイクルを回して蓄積できるように振り返りで得られた気づきを積み重ねる意識 → 自分たちの共通語彙として育てていく実際に現場で試行錯誤した等身大を、酸いも甘いも両方持って帰ってください → うまくいかなくて試行錯誤した結果も参考にして帰ってください 36

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. Question: プラクティスは増えるだけなのかな？ 38 特に決めてやってるわけではないのですが、Miroのマップを見て「今もこれやってるかなぁ？」みたいなことを話す機会が半期に1回くらいありました。「今はこれむしろこういうふうにやってるよね？」と内容がアップデートされた点がよかったです。明示的にプロセスとしては取り込んでもいいかも！っていう気づきをいただきました！

Slide 39

Slide 39 text

Slide 40

Slide 40 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 参考書籍・記事 ● 西尾泰和著『エンジニアの知的生産術――効率的に学び，整理し，アウトプットする』 ● Christopher Alexander 著『The Battle for the Life and Beauty of the Earth: A Struggle Between Two World-Systems』 ● 井庭崇著・編集中埜博他著『パターン・ランゲージ:創造的な未来をつくるための言語 (リアリティ・プラス) 』 ● Robert C. Martin著『Clean Agile 基本に立ち戻れ』 40

Slide 41

Slide 41 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 参考資料 ● デザインパターンの使い方をパタン・ランゲージとの比較から考える / design-pattern-usage-inspired-by-pattern-language ○ Object-oriented conference 2020で発表した際の資料です ○ パタン・ランゲージ早わかり資料としてお使いください ● 振り返りで積み上げた開発プラクティス（2020年総まとめ） ○ 実際に積み上げたプラクティスの2020年総集編です 41