アジャイルの知見の少ないメンバーの多いチームづくりの1年半をふりかえる

by Jun Nakajima

Slide 1

Slide 1 text

アジャイルなチームづくりの  1年半をふりかえる  2024/09/28 #xpjug 2024 Jun Nakajima

Slide 2

Slide 2 text

自己紹介  なかじま（@jnuank_）  ● 株式会社ユーザベーススピーダ事業プロダクトチーム  ● 3年半前からJoinしてからXPを実践してます  ● 社内で和尚と呼ばれます  ● XP祭り登壇3回目です  ○ 2023: より協力的なペアプロを促すにはどうするかを考える   ○ 2021: スクラムを実践していた私がXPの現場に来て感じたこと   2

Slide 3

Slide 3 text

今回のテーマ：  アジャイルなチームづくり 

Slide 4

Slide 4 text

とりあえず言いたいこと：  チームづくりはとても難しい 

Slide 5

Slide 5 text

チームづくり、とっても難しい！  ● つくる前にいろんな人の記事やメンバーに相談した  ● それでも、最初思い描いてたとおりにはできなかった  ● チームづくりに最適解はないし、再現性も少ない  ○ チームづくりは、そのときのコンテキストを内包するから  ■ 自分・チームのスキル  ■ プロジェクトの状況  5

Slide 6

Slide 6 text

それでも先人の経験知は無駄ではない  ● 先人の教訓・知恵を必要な場面で思い出して、自分たちの状況に合わせて使えた  ● 今日の発表もそのうちの一つとして思い出してもらえたら良いなと思ってます  6

Slide 7

Slide 7 text

1.　チームづくりの経緯・目指したかったもの  7 2.　1年半のタイムライン  今日話をすること  3.　採用・オンボ・FBののびしろ 

Slide 8

Slide 8 text

1.　チームづくりの経緯・目指したかったもの  8 2.　1年半のタイムライン  今日話をすること  3.　採用・オンボ・FBののびしろ 

Slide 9

Slide 9 text

まずは前提として  私たちの開発組織の文化 

Slide 10

Slide 10 text

スピーダ事業 Product Teamの文化  ● ミッションは「技術力で、ビジネスをリードする」  ● そのために変化に強い自己組織化されたチームを目指している  ● チーム全体100名  ○ SWE、SRE、MLE(DS)、TE  ○ その中で4〜5人のプロジェクトチームに分かれてプロダクトの開発をしている  10

Slide 11

Slide 11 text

自己組織化されたチームを目指すために  ● アジャイル開発の実践  ○ 主にXPの考え方をベース  ● シェアド・リーダーシップ  ○ 明確なリーダーというロールは置かず、メンバーそれぞれが自分の得意領域でリーダーシップを発揮する考え  ● チームシャッフル  ○ 3ヶ月ごとにメンバーが、自分の行きたいチームへ移動できる  ● カオスWeek  ○ チームのキーパーソンを1週間コミュニケーション取れない状態にする  11

Slide 12

Slide 12 text

実践しているアジャイルのプラクティス  12 『Clean Agile』p.47 

Slide 13

Slide 13 text

色濃く取り入れているプラクティス・考え方  ● ペアプロ・TDD（ATDD）を8時間フルタイムで常に実践  ○ 1時間〜1時間半でペアをローテーションする  ● 技術選定はチームで行う  ● DDD、マイクロサービス  ○ フロント、BFF、バックエンドで違う技術スタックである事が多い  ● トランクベース開発（継続的インテグレーション）、コードの共同所有  ● ユーザーストーリー、カンバン  ● 四半期サイクル（リリース計画）  13

Slide 14

Slide 14 text

大事にしているValue  14 ● コミュニケーション  ● シンプルさ  ● フィードバック  ● 勇気  ● リスペクト 

Slide 15

Slide 15 text

チームづくりに至った経緯  ● いろんなプロジェクトをやりながら、私自身がアジャイルのプラクティスを実践し、ユーザーに価値を届け続けることはある程度できるようになった  ● だが、同じようなチームを自分で1からつくれるかどうかは疑問だった  ● 事業部の拡大に伴い、人を集めるところからチーム組成をしないかと話が上がり、挑戦することにした  15

Slide 16

Slide 16 text

私が目指したチームづくり  ● 自己組織化されたチーム  ○ 各々が自分たちでどうするかを考えて、チームとして意思決定できる  ■ 究極、私がいなくても動けるチーム  ● アジャイルの知見の少ないメンバーで構成する  ○ アジャイルの価値観・プラクティスを伝えてスケールさせるという技術的チャレンジ  16

Slide 17

Slide 17 text

1.　チームづくりの経緯・目指したかったもの  17 2.　1年半のタイムライン  今日話をすること  3.　採用・オンボ・FBののびしろ 

Slide 18

Slide 18 text

18 タイムライン  2023/04 2023/10 3人チームで立ち上げ 2024/01 2024/04 2024/07 2023/07 1人Leave 2人Join 5人チーム 1人Joinして 4人チーム新機能開発チーム2つ目を作って拡大新規PJ 人を採用する・アジャイルを伝える人が増やしてもアジャイルの練度を上げるチームとして技術的なチャレンジ 2チームのアジャイルの練度を上げる出来事チャレンジだったことチーム立ち上げ時期チーム拡大時期チーム激動時期

Slide 19

Slide 19 text

19 タイムライン  2023/04 2023/10 3人チームで立ち上げ 2024/01 2024/04 2024/07 2023/07 1人Leave 2人Join 5人チーム 1人Joinして 4人チーム新機能開発チーム2つ目を作って拡大新規PJ 人を採用する・アジャイルを伝える出来事チャレンジだったことチーム立ち上げ時期チーム拡大時期チーム激動時期人が増やしてもアジャイルの練度を上げるチームとして技術的なチャレンジ 2チームのアジャイルの練度を上げる

Slide 20

Slide 20 text

チームの立ち上げ時期 

Slide 21

Slide 21 text

● アジャイルを多少経験がある・アジャイルな開発にチャレンジしたいというメンバーを業務委託で採用始める  ○ 基本的には技術よりValueマッチしそうな人で探す  ● 2人集まった  ○ コミュニケーションが好きな人  ○ 技術的にリードができそうな人  人を集めるところから開始  21

Slide 22

Slide 22 text

基本となるプラクティスを伝え続けた  ● 主要となるプラクティスに馴染めるように伴走することを目標とした  ○ ペアプロ  ■ ペアプロの心得・弊社のペアプロガイドライン  ○ TDD  ○ プランニング  22

Slide 23

Slide 23 text

アジャイルを理解するための助け  ● イテレーションふりかえりの中でアジャイルがよくわからないとなる  ○ Clean Agile輪読会  ■ 実践しているプラクティスとの関連性を補足  ○ もっと数をこなして身体に馴染ませる  ■ 1時間イテレーション  ■ ペアプロで数分以内にドライバー交代する  23

Slide 24

Slide 24 text

開発組織のValueを理解する助け  ● 1週間別チームから人を借りて一緒にペアプロする  ○ レンタル移籍という仕組み  ○ 私以外のロールモデルとなれる人と一緒に働いて、その人の考え方や技術を見て盗んでもらう機会をつくる  ■ 私自身も勉強になる  24

Slide 25

Slide 25 text

やってみた結果  ● 1時間イテレーションやキーボードを奪う工夫は良かった  ○ その時のメンバーは「とにかくやって覚える」という傾向が強かったのもあるかもしれない  ● チームが自律的に意思決定ができるようになるところはのびしろ  ○ この時期は私がボトルネックになりがちだった  25

Slide 26

Slide 26 text

26 タイムライン  2023/04 2023/10 3人チームで立ち上げ 2024/01 2024/04 2024/07 2023/07 1人Leave 2人Join 5人チーム 1人Joinして 4人チーム新機能開発チーム2つ目を作って拡大新規PJ 人を採用する・アジャイルを伝える出来事チャレンジだったことチーム立ち上げ時期チーム拡大時期チーム激動時期人が増やしてもアジャイルの練度を上げるチームとして技術的なチャレンジ 2チームのアジャイルの練度を上げる

Slide 27

Slide 27 text

チームの拡大時期 

Slide 28

Slide 28 text

各要素の難易度が上がっていった時期  ● チームの人数を増やしていった  ○ 3 → 4 → 5人  ○ 純増ではなく、入れ替わりあり  ● プロジェクトの難易度も上がっていった  ○ 既存の機能にちょっとした追加  → 新しい画面・機能の追加  28

Slide 29

Slide 29 text

当時の課題  ● コミュニケーションとシンプルさを保つ  ● チームメンバー全員が意思決定をできるようになること  29

Slide 30

Slide 30 text

コミュニケーション・シンプルさの課題  ● 情報共有がうまくいかず、特定の誰かしか知らない  ○ コミュニケーションがうまく体現できてない  ● 1つのユーザーストーリーに多くのことをやろうとした  ○ シンプルさ、小さくリリースする意識が保てなかった  30

Slide 31

Slide 31 text

コミュニケーション・シンプルへのアクション  ● 理想はペアプロとペアのローテーションでコミュニケーションが取れること  ○ ただ、その時はまだ難しかったので、1日定期的に情報共有の時間を取ることにした  ● 小さくリリースについては、私からとにかく口酸っぱく言うようにしていった  31

Slide 32

Slide 32 text

今ふりかえってみて思うこと  ● Joinしたメンバー2人のコンテキストスイッチを減らすために、ペアのローテーションを半日以上と長くしていた  ○ 知ってる・知らないの情報が偏りやすかったので、やはり頻繁にペアのローテーションはした方が良さそう  ● 立ち上げ時期にも書いた慣れてないからこそ頻繁にやるというのが最初のアプローチだと感じた  32

Slide 33

Slide 33 text

メンバーが意思決定できない課題  ● 新規開発するプロジェクトだったため、自分たちで技術選定やアーキテクチャをを決める機会が増えた  ○ 決めることに慣れてないチームは「うーん…」となる  ■ アーキテクチャレベルだけではなく、1つのアプリケーションの設計やコードの書き方でも  ○ プランニングでもどう進むかと迷うことが多かった  33

Slide 34

Slide 34 text

メンバーの意思決定の経験を促す  ● 自己組織化されたチームの鍵の一つとして各々がチームに関わることで意思決定できるようになること  ○ ソフトウェアをつくる事は意思決定の連続  ● 「どうしたい？」「何に悩んでる？」と相手の考えを引き出す動きをした  ● 初期メンバーには「あえて反論してプロレスしに来て」とも伝えて健全に議論する姿も見せていった  34

Slide 35

Slide 35 text

結果  ● 開発の終わり頃は、私が積極的に意見を出さなくてもみんなでプランニングができつつあった  ○ プロジェクトが収束していたという理由もある  ● 自分たちがこうしたい、ああした方がいいんじゃないかと意見は出せるようになっていった  ○ 強い意見じゃなくても、本当にそうなんでしたっけ？と疑問を呈する頻度が増えていった  35

Slide 36

Slide 36 text

36 タイムライン  2023/04 2023/10 3人チームで立ち上げ 2024/01 2024/04 2024/07 2023/07 1人Leave 2人Join 5人チーム 1人Joinして 4人チーム新機能開発チーム2つ目を作って拡大新規PJ 人を採用する・アジャイルを伝える出来事チャレンジだったことチーム立ち上げ時期チーム拡大時期チーム激動時期人が増やしてもアジャイルの練度を上げるチームとして技術的なチャレンジ 2チームのアジャイルの練度を上げる

Slide 37

Slide 37 text

チームの激動時期 

Slide 38

Slide 38 text

2チーム目をつくる  ● 2024年4月に、5→7人チームとなる  ○ これも純増ではなく、1人Leave、3人Join  ● コミュニケーションコストの観点から、5人より多いチームは作らないので、4人と3人の2チーム体制  ● 私は3人チームに所属  38

Slide 39

Slide 39 text

2チーム体制の目的  ● ビジネス観点で言えば、いまの事業部で更にエンジニアを増やしたかった  ● 私自身の挑戦の観点では、2チームつくることで  アジャイルなチームをスケールさせること  ○ 常に私がいないチームが1つできるので、より他のメンバーにアジャイルを伝えるスキルが必要になってくる  39

Slide 40

Slide 40 text

結果、2ヶ月で1チームに戻した 

Slide 41

Slide 41 text

維持ができなくなった  ● 直接的な理由はメンバーのうち1人が抜けるとなったため  ○ 3人ずつのチームで常時ペアプロは冗長性が無いので、 2ヶ月で1チームに戻した  ○ その際、1人は別チームに移籍  ● アジャイルの練度が2チームとも維持できなかった  ○ バーンダウンの乖離が続く、コミュニケーションの頻度の低下  41

Slide 42

Slide 42 text

2チームはまだ早かった  ● 3→5人チームでもあったが、人が増えることでアジャイルの練度は一時的に下がる  ○ XPの価値やプラクティスを伝える機会が減るため  ● 急激に増やすのではなく、今のチームでプラクティスをしっかり実践し、自分たちで意思決定の頻度が多くなってから、人を増やしたりすれば良かった  42

Slide 43

Slide 43 text

1チームに戻して3ヶ月後 

Slide 44

Slide 44 text

チームづくりの現在地  ● 新規PJかつ新しい技術を使って不確実性が高い状況  ● 私がいない状況でも、アジャイルのプラクティスを実践しながら自律的に動けている  ○ 自己組織化されたチームになってきたと言えそう  ● もちろん練度だったり、のびしろは多い  ○ のびしろを自分たちで見つけて、少しでも良くする  カイゼンのアクションは出し続けることはできてる  44

Slide 45

Slide 45 text

チームづくりの現在地  ● 実は9月末で2人メンバーが抜けることになった  ● いろいろ相談した結果、チームづくりの取り組みは一旦終わりにする  45

Slide 46

Slide 46 text

1.　チームづくりの経緯・目指したかったもの  46 2.　1年半のタイムライン  今日話をすること  3.　採用・オンボ・FBののびしろ 

Slide 47

Slide 47 text

結局採用って上手くいってたんですか？一緒に働いたメンバー

Slide 48

Slide 48 text

採用の伸びしろ  ● 1年半の間で8人採用し、現時点で残ったのは1人だった  ○ 数字的に見て上手くいってない  ● 面談の見極めの伸びしろと、私自身どんな人と一緒に働きたいか解像度がまだ粗かった  48

Slide 49

Slide 49 text

採用について：最初見ていたところ  ● アジャイルについて経験や挑戦したいと思っているか  ● 対面コミュニケーションを取ることが好きかどうか  ○ ペアプロするにあたって、必要な要素  ● 技術的に親和性や技術的好奇心があるか  ○ マイクロサービス、Docker、k8s、TDDの経験  ○ 自分が触っている技術に関してどれだけ深ぼってるか  49

Slide 50

Slide 50 text

採用について：今ふりかえってみて  ● 個人的なのびしろは、アジャイルとの親和性の見極め  ● 経歴・経験など目に見えるわかりやすいものの比重が高かった  ● Do Agileではなく、Be Agileに向かう為に変化を引き起こす勇気を出せる素養を見極める必要があると思っている  ○ ※あくまで私個人の意見です  50

Slide 51

Slide 51 text

XPでは、あなたがチームの一員であると自覚して、理想的には明確なゴールと実行計画を共有していることを前提とする。  XPでは、あなたが誰かと一緒に働きたいと思っていることを前提とする。  XPでは、コストをかけずに変化が引き起こせることを前提とする。  XPでは、あなたが自身の成長、スキルの向上、人間関係の改善を望んでいることを前提とする。  XPでは、これらのゴールを達成するために、あなたが変化を引き起こすつもりがあることを前提とする。  51 『エクストリームプログラミング』p.6 

Slide 52

Slide 52 text

アジャイル組織はコラボレーションでできていて、イノベーションを促進し、高い柔軟性を必要とします。過去の経験もある程度までしか通用しません。  オープンマインドを持っていること、新しいことを学べること、他者と協力して複雑性や予測不可能性に対処できることの方が、深いけれども狭い専門性を持つエキスパートであることよりも重要なのです。  52 『アジャイルリーダーシップ』p.241 

Slide 53

Slide 53 text

フィードバックの伸びしろ  ● 良くない振る舞いをしていることに気づいてないメンバーに対してのフィードバックが遅くなってしまった  ○ どうすればなるべく傷つけないかを考えてしまった  ■ 率直にフィードバックする勇気が足りなかった  ○ 「もっと早く伝えて欲しかった」と言われた  ● ネガティブなフィードバックこそ、こまめに率直に伝えるべきだと感じた  53

Slide 54

Slide 54 text

オンボーディングの伸びしろ  ● アジャイルのプラクティスの押し付けになってた  ○ ただプラクティスが実践できるだけ  ● アジャイルの知見の少ないメンバーには、プラクティスと Value、それをつなぐ原則を何度も伝えてくれる師が必要なんだと感じた  ● チームを観察する目と（見も蓋もないが）時間をちゃんと確保してメンバーと向き合わなければいけなかった  54

Slide 55

Slide 55 text

まとめ：チームづくりを通しての学び 

Slide 56

Slide 56 text

不確実性をどのくらいコントロールできるか  ● 本質的にソフトウェア開発は不確実性が高い  ○ プロダクトの不確実性  ○ 技術の不確実性  ○ ステークホルダーとの関係性の不確実性  ○ チームの不確実性  ■ 協力関係の構築、アジャイルの練度  56

Slide 57

Slide 57 text

不確実性をどのくらいコントロールできるか  ● 私のチームづくりは、ずっとチームの不確実性が高い状態だった  ○ メンバーが安定しないことによるアジャイルの練度  ● その状態で他の不確実性が高まると、あっという間にストレッチ→パニックゾーンになってしまうので、コントロールできるものはできる限りコントロールする  ○ ※できたとは言っていない  57

Slide 58

Slide 58 text

チームづくりを通しての自身の学び  ● 自分自身のアジャイルへの解像度が上がった  ○ プランニング・カンバン・ペアプロなど  ● 自分自身が余裕無くなってくると、相手をコマンド＆コントロールする癖に気づいた  ○ 独裁モードになっていたらFBしてとメンバーに言っている  ● 自分が矢面に立つ機会が増えたので意思決定は磨かれた  58

Slide 59

Slide 59 text

参考文献  ● Kent Beck, Cynthia Andres(著), 角征典(訳) (2015) 『エクストリーム・プログラミング』オーム社   ● Robert C. Martin(著), 角征典, 角谷信太郎(訳) (2020)『Clean Agile 基本に立ち戻れ』ドワンゴ   ● Zuzana Šochová (著), 株式会社ユーザベース (訳) (2022)『アジャイルリーダーシップ: 変化に適応するアジャイルな組織をつくる』共立出版   ● 『アジャイルソフトウェア開発宣言』     ● 『ふりかえりからチームづくりの9ヶ月をふりかえる』   ● 『より協力的なペアプロを促すにはどうするかを考える』     59

Slide 60

Slide 60 text

Thank you!