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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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チームのアジャイルの練度を上げる出来事チャレンジだったことチーム立ち上げ時期チーム拡大時期チーム激動時期

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

チームの立ち上げ時期 

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

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

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

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

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

チームの拡大時期 

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

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

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

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

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

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

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

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

チームの激動時期 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参考文献  • Kent Beck, Cynthia Andres(著), 角征典(訳) (2015) 『エクストリーム・プログラミング』オーム社
  • Robert C. Martin(著), 角征典, 角谷信太郎(訳) (2020)『Clean Agile 基本に立ち戻れ』ドワンゴ   • Zuzana Šochová (著), 株式会社ユーザベース (訳) (2022)『アジャイルリーダーシップ: 変化に適応するアジャイルな組織をつくる』共立出版   • 『アジャイルソフトウェア開発宣言』   <https://agilemanifesto.org/iso/ja/manifesto.html >  • 『ふりかえりからチームづくりの9ヶ月をふりかえる』 <https://tech.uzabase.com/entry/2024/01/10/124130 >  • 『より協力的なペアプロを促すにはどうするかを考える』 <https://speakerdeck.com/jnuank/yorixie-li-de-napeapurowocu-suniha-dousurukawokao-eru-8159298 7-dff1-44f1-9ae3-630f0d9d33e3 >    59

Thank you!

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

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

More Decks by Jun Nakajima

Other Decks in Business

Featured

Transcript