Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

スクラムのマインドの中では、自分たちの伸びしろやチームとしてもっとうまくプロダクトを作るためにはどうすればよいか?ということを模索するために継続してレトロスペクティブ(ふりかえり)をしているチームが多いでしょう。

私個人がチームを育てていくなかでこの振り返りについて課題に感じていたのが振り返りがフロー情報で流れていってしまう点でした。当該チーム内の暗黙知として共通認識となればよいのですが、新入社員を受入れていったりチームが大きくなる段階では流れてしまった振り返りで得られた「自分たちのプラクティス」がストックされないのは、チームの学び・成長に対しての確かな実感としては少々弱いのではないでしょうか?

そこで私がチームビルディングの考え方でインスパイアされたのが、建築家クリストファー・アレグザンダーの「パタン・ランゲージ」という概念の文脈で語られる、自分達に合わせてチューニングした「プロジェクト・ランゲージ」というものです。

われわれはスクラムのフレームワークを土台として日々のプロダクトづくりをするわけですが、あくまでそれは汎用的フレームワークであるがゆえ自分達に合わせて最適にチューニングする必要があります。フレームワークにないプラクティスを採用したり新規に自分達のプラクティスを生み出すこともあるでしょう。

弊チームではそのような組織ローカルなプラクティスの連なり・一連を次のブログで紹介していて一定の反響を頂いておりました。

https://devblog.thebase.in/entry/bank-practices-2020

本トークでは、自分達のプラクティス集や日々の語彙をいかに振り返りから育てていくか、チームで実践している実例を紹介いたします。

Kazuki Higashiguchi
PRO

October 02, 2021
Tweet

More Decks by Kazuki Higashiguchi

Other Decks in Technology

Transcript

  1. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE, Inc.
    振り返りを積み上げて
    自分たちのプラクティスとして
    昇華•体得していくための
    仕組みと考え方
    1
    2021.10.02 Scrum Fest Mikawa 2021
    @hgsgtk Kazuki Higashiguchi

    View Slide

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

    View Slide

  3. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE, Inc.
    当発表で得られるもの



    ”自分たちのプラクティス”として昇華していくための
    アプローチを知る
    振り返りで得られた気づきを積み重ねる意識
    実際に現場で試行錯誤した等身大を、酸いも甘いも
    両方持って帰ってください
    3

    View Slide

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

    View Slide

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

    View Slide

  6. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE, Inc.
    当発表のメニュー



    現場で行ってる実装例 〜独自振り返りワー
    クの紹介を添えて〜
    振り返りの積み上げ・プラクティスへの昇華
    とは 〜体系立てられた理論仕立て〜
    取り組みによって得られた効果、現在進行
    形のほろ苦い課題感も合わせて
    6

    View Slide

  7. © 2012-2021 BASE, Inc. 7
    1. 振り返りの積み上げ・プラク
    ティスへの昇華とは
    〜体系立てられた理論仕立て〜
    Photo by Louis Hansel on Unsplash

    View Slide

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

    View Slide

  9. © 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』

    View Slide

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

    View Slide

  11. © 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”

    View Slide

  12. © 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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  16. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE, Inc.
    例:「ストーリーポイント」
    16
    「ストーリーポイント」の肉付けを語彙として共
    有する
    ● 使うポイントは何?
    ● 1ptの基準は?
    ● 突発的なISSUE作るときにポイントふる?ふらない?
    ● ほぼ0ptのおきもちのときどうする?
    肉付け込みで「ストーリーポイント」という言葉
    が使えるように

    View Slide

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

    View Slide

  18. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE, Inc.
    要するに、
    ● アジャイルのプラクティスをオリジナルを土台にチューニングし
    たり、独自のプラクティスを作ったりしたもの、その一連を共通
    語彙としてストックする -> 自分たちのプラクティスとして昇華
    する
    ● その起点に振り返りを使おう
    18

    View Slide

  19. © 2012-2021 BASE, Inc. 19
    2. 現場で行ってる実装例
    〜独自振り返りワークの紹介を
    添えて〜
    Photo by Becca Tapert on Unsplash

    View Slide

  20. © 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職の採用も進
    み職能横断型チームに

    View Slide

  21. © 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に分かれてプロダクト開発している

    View Slide

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

    View Slide

  23. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE, Inc.
    1. 振り返りで得られた長期的に意識する改善案を
    プラクティスの種としてストック
    2. 数回スプリントを回して実験
    3. プラクティスの種投票ゲーム
    4. プラクティスとして追加する
    どのようにプラクティスの種を積み上げていくか
    23

    View Slide

  24. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE, Inc.
    1. 振り返り
    振り返りではいくつかのワークを実施しましたが「プラクティスの種」を発
    見するという目的においてはKPT(Keep-Problem-Try)をよく用いました
    24
    振り返りによって得られたActionを、
    短期的な「作業タスク」と、
    「プラクティスの種」に振り分ける

    View Slide

  25. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE, Inc.
    1. 振り返りで得られた「プラクティスの種」をストック
    短期的な「作業タスク」はGitHub Issueへ、「プラクティスの種」はMiro上
    のボードにコピーしておきます
    25

    View Slide

  26. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE, Inc.
    2. 数回スプリントを回して実験
    26
    数回イテレーションで実際にどのような効果があるか実験してみま

    例:最近TwitterのTLで話題だったKPTの書きづ
    らさ問題
    ● →「出来事」ベースで書けることが明示的な
    ワークをやってみましょう
    ● → プラクティスの種として「YOT※1
    」を登録
    ● (Yやったこと-O思ったこと-T次にやること)
    ※1 YOTはYWTをforkした独自なワークフォーマットです。Wわかったことがお気持ちを書きづらいという課題からOおもったこと
    に変更しています。

    View Slide

  27. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE, Inc.
    3. プラクティスの種投票ゲーム
    振り返りの一つのワークとして実施、プラクティスの種の実験結果
    を踏まえて、これからやっていくかお気持ちと共に投票する
    27

    View Slide

  28. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE, Inc.
    3. プラクティスの種投票ゲームの効果
    ● Votingの温度感が表明できるので意思表明はしやすい
    ● 添えられたコメントを深ぼっていくとプラクティスが洗練される
    ○ ex. 「YOTは出来事の共有を主たる目的とするシーンで使おう」
    ○ 実験結果が反映される
    28

    View Slide

  29. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE, Inc.
    4. プラクティスとして追加する
    プラクティスの種投票ゲームの結果、「今後も共通理解として有効
    な方法として使っていこうな!」という意思のもとプラクティス
    マップに追加
    29
    Miroを更新しつつ、 詳細は文章へ

    View Slide

  30. © 2012-2021 BASE, Inc. 30
    3. 取り組みによって得られた効
    果、現在進行形のほろ苦い課題感
    も合わせて
    Photo by Fahmi Fakhrudin on Unsplash

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  34. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE, Inc.
    課題(2)プラクティスの種の棚卸しが溜まる
    ● こまめにプラクティスの棚卸しができるように考えたのが「プラ
    クティスの種投票ゲーム」だった
    ● それ以前は一定期間ごとにbulk式に一回の振り返りの時間をまる
    まる使っていた
    ● bulk式は一個一個深ぼる時間が少ないし、期間が空くと忘れてし
    まう
    34

    View Slide

  35. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE, Inc.
    課題(2)プラクティスの種の棚卸しが溜まる
    ● 学びのサイクルを早く回すにはbulk式では難しい
    ● うまく日々の振り返りのリズムの中に組み込んで習慣づけるよう
    に意識付けが必要
    35

    View Slide

  36. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE, Inc.
    当発表で得られたもの



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

    View Slide

  37. © 2012-2021 BASE, Inc. 37
    Q and A

    View Slide

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

    View Slide

  39. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE, Inc.
    Question: マップのサイズ決めてたりする?
    Miroマップの全部を一気にまとめてお伝えするっていうのを現状やって
    いないのもあり、「miroをスクリーンに収まる範囲にしよう」とかはし
    ていないです。
    Miro自体が重くなるほど増えてしまったときには精査する必要があるか
    もしれないな、とか思いました!
    39

    View Slide

  40. © 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

    View Slide

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

    View Slide