多様な働き⽅のチームでどうやってアジャイルにやるの？(雁行陣開発)

2. Toshihiro Ichitani All Rights Reserved. Ichitani Toshihiro 市⾕聡啓ソフトウェア開発17年 SIer→サービス→受託→起業仮説検証とアジャイル開発ギルドワークス株式会社代表株式会社エナジャイル代表 DevLOVE コミュニティファウンダ The Agile Guild オーガナイザー 0 → 1 @papanda https://ichitani.com/

3. 4刷 https://www.amazon.co.jp/dp/4798153346/

8. 本⽇のテーマ

9. 働き⽅、働く場所がバラバラのチームでどうやってプロダクトづくりをするの？

10. 働き⽅、働く場所の多様性の広がり副業、複業の時代・昼間はSIerや⼤企業。夜や⼟曜は副業でサービス開発。・いきなりフリーランスというハードル以外の選択肢。・何でもって正業、副業とするか⾒分けがつかなくなる (複業) リモートワーク・導⼊率11.5% (総務省、2018年7⽉調査) ・働く場所を問わない現場がこの5年で増えてきている。・週1リモートのような部分適⽤も。

11. Photo credit: bourgol on Visual Hunt / CC BY-NC-ND ギグ・エコノミー (Gig Economy)

12. ギグ = ⼀夜限りの仕事ギグとは？・もともはミュージシャンが⼀夜限りの契約でライブ演奏に参加することを指した。・代表的なギグなサービスといえば「Uber」・フリーランス、副業はギグ的になりやすい。仕事における⾃分の役割、責務を果たした時点で仕事を終える。・アメリカではインディペンデント・コントラクター (独⽴業務請負⼈)と呼ばれる。ギグワークとは？

13. https://theagileguild.org/

14. https://theagileguild.org/

15. 多様性の広がり = 現場の複雑性の⾼まり副業、リモートワークの課題とは？・本⼈の課題感以上に、周囲の課題感が⾼まる。・副業=時間の分断、リモートワーク=場所の分断。・副業とリモートワークの2⾝合体で時間と場所の分断が同時に起こる = コミュニケーションの分断・ギグ側が「⾃分の責務を果たしたら仕事は終わり」という感覚だとしたら。チームとしてどうやって上⼿くやる？

16. …とはいえ、副業やリモートが悪なのではない働き⽅の多様性↑ = ⼈の多様な価値観を受け⼊れる世界になってきているということ・なので“同席”が正しい、副業・リモートが間違っているという⼆元論で⽚付けることではない。・「同席の頃はどうでこうで」と⽐べることには意味がない。・別の基準(働き⽅)で選択したこと重視するならば、仕事のやり⽅で最適化を⽬指すより他ない。 (それでもダメなら諦めよう)

17. プロダクトづくりの複雑性にどう向き合うか「コミュニケーションの分断」による複雑性 Vs マネジメント？・作戦1「マネジメントを無くす」= ⾃⼰組織化、ティール化マネジメントしようとするから無理がある、やめる。 → ⾃⼰組織化を⽬指すのは、理想だが時間はかかる。

18. プロダクトづくりの複雑性にどう向き合うか「コミュニケーションの分断」による複雑性 Vs マネジメント？・作戦1「マネジメントを無くす」= ⾃⼰組織化、ティール化マネジメントしようとするから無理がある、やめる。 → ⾃⼰組織化を⽬指すのは、理想だが時間はかかる。・作戦2「フォーメーション・パターンで適応する」=今回のお話⽬の前の状況に「⼀辺倒のチーム運営」ではなく、フォーメーション(役割分担+相互作⽤のあり⽅)を期限性で切って適応する。

19. 解決したい課題の解像度を上げる

20. 副業稼働時間帯があわない稼働時間に偏りがあるリモートワーク⾮⾔語コミュニケーションできない相⼿の様⼦がわからない背景⾒えずタスク指向になりがち時間の分断場所の分断集まる⼈達の経験の幅が広くなる経験の分断

21. 副業稼働時間帯があわない稼働時間に偏りがあるリモートワーク⾮⾔語コミュニケーションできない相⼿の様⼦がわからない背景⾒えずタスク指向になりがちスクラムイベントができない (同期しにくい) 1PBI開発あたりのコミュニケーションコスト⾼い伝わる内容、分量が圧倒的に少ない異常検知が働きにくい Whyが弱いため間違いに気付きにくい「コミュニケーションの分断」によって⾼まる複雑性時間の分断場所の分断集まる⼈達の経験の幅が広くなる経験の分断仕事のやり⽅が⼈によってバラバラオーバーヘッド同期やり⽅内容分量異常検知分断による6つの問題 PBI…プロダクトバックログアイテム No Why

22. 6つの分断問題に向き合ったプロジェクト Case1 情報提供サービスの実験プロジェクト・副業メンバー中⼼。不同期問題、オーバーヘッド問題が顕著。・特に、スクラムイベントを成り⽴たせることの困難さ。・…というのは既に⾃前プロダクトづくりで経験済なので「曳光弾開発」(「Ship it!」) でチーム⽴ち上げ前の先⾏開発分の実装を増やす作戦を取る。・ところが、アドバンテージをあっという間に⾷いつぶす状況に。互いのコミュニケーションが⾜りず、認識齟齬が増え、バグ量産雁⾏陣開発取らず

23. 6つの分断問題に向き合ったプロジェクト Case2 組織診断向けサービスのプロジェクト・フリーランス(複業)メンバー中⼼。リモートワークによる分断。・既に事例1を⼿がけていたので、副業+リモートワークの2⾝合体の荒ぶり⽅から次の作戦が必要なことが分かっていた。・そこで…新しいフォーメーション(役割分担+相互作⽤のあり⽅)を。分断の解消にいく(時間をあわせる、会合を増やす)のではなく、分断を環境制約として、その下でのあり⽅の最適を⽬指す。雁⾏陣開発

24. 雁⾏陣開発

25. 雁⾏陣とは？・「雁⾏」とは、空を並んで⾶ぶ雁の⾏列のこと。・「雁⾏陣」とは、いにしえの戦場での陣形のこと。または、テニスにおける陣形。

26. 雁⾏陣開発・プロダクトリード、チームリードという役割を置く。・其々のミッション(プロダクト開発、チーム運営)での先導を務める。 <フォーメーションイメージ>

27. 背⾻PBIとお⾁PBI ⾏動 PBI 商品を探す商品を⾒るカートに⼊れる注⽂情報⼊れる商品検索⼀覧機能お気に⼊り機能お気に⼊りする決済する履歴⾒る商品詳細機能カート機能注⽂機能決済機能購⼊履歴機能⼀覧並替機能背⾻バックログお⾁バックログ・背⾻バックログ = ユーザー体験上必ず求められるPBL (どう考えてもこれが無いと体験が成⽴しないモノ) ・お⾁バックログ = 背⾻を前提として⾁付けしていくイメージのPBL (1つ1つのPBIの独⽴性が⾼い) ※ユーザー⾏動フローベースで「背⾻」と「お⾁」を⾒極める

28. プロダクトリード・チームメンバーより先⾏して「背⾻」開発に専任するメンバー。・背⾻先⾏開発 = 作るためにアーキテクチャや設計を決める = 開発に必要な「制約」が先に決まる・ゆえに、腕は求められる (設計のリード、議論のリード)。・場所的に分断されたメンバー向き細やかなコミュニケーションが不要な状況をつくる。 (前衛)

29. チームメンバー・「お⾁」開発を担うメンバー。出来ている「背⾻」に繋げていくイメージの開発。背⾻開発でアーキテクチャや設計、主要なデータモデルを先⾏して決めているため、⼤ブレしにくい。・「お⾁」の独⽴性が⾼いため、バラバラで、並⾏して開発が⾏える。・時間的に分断されたメンバー向き。それぞれの働く時間帯を問わない。 (後衛)

30. チームリード・チームメンバーの活動のインテグレーションを担う。・チームメンバーがそれぞれ動けるように必要な情報を補完。それぞれのアウトプットをプロダクトに統合する(受け⼊れ)。・独⽴して動くプロダクトリードに共有するべき必要な情報を渡す。つまり、分断を越えて間を繋いでいく役割(媒介者)。・働く時間に偏りが少ないメンバー向き。全体を俯瞰(状況を捉え意思決定)出来る⼒が求められる。 (媒介者)

31. 「リード」とは？・「リーダー」は、⼈に張り付いた⾔葉のイメージが強い。・「リード」は、ある状況において前進を先導する「役割」。役割なので、他の⼈に変わる、変えることもある、より動的なイメージを表現したい。 (Case2でのPLは4スプリントで役割を終えた)

32. 雁⾏陣開発のイメージ商品検索⼀覧機能商品詳細機能 SPRINT1 管理側機能・PLが背⾻づくりにひた⾛る・他のメンバーは最初は開発のリズムを掴むべくあえて差し障りの無い機能を作るところから始める。プロダクトリードチームメンバーチームリードカート機能 SPRINT2 ⼀覧並替機能・PLは引き続き背⾻づくり・他のメンバーは仕上がった背⾻に繋げられる機能から開発していく。・TLがスプリント終了時にまとめて受け⼊れテストプロダクトリードチームメンバーチームリードお気に⼊り機能注⽂機能 SPRINT3 カート付帯機能プロダクトリードチームメンバーチームリード決済機能・PLはひたすら背⾻づくり・他のメンバーは前スプリントの背⾻に機能をつなげる。・TLは(以下略) ・デザイナーは2スプリント分のデザインコーディングを⾏うデザイナー

33. 副業稼働時間帯があわない稼働時間に偏りがあるリモートワーク⾮⾔語コミュニケーションできない相⼿の様⼦がわからない背景⾒えずタスク指向になりがちスクラムイベントができない (同期しにくい) 1PBI開発あたりのコミュニケーションコスト⾼い伝わる内容、分量が圧倒的に少ない異常検知が働きにくい Whyが弱いため間違いに気付きにくい「コミュニケーションの分断」によって⾼まる複雑性時間の分断場所の分断集まる⼈達の経験の幅が広くなる経験の分断仕事のやり⽅が⼈によってバラバラオーバーヘッド同期やり⽅内容分量 No Why異常検知分断による6つの問題 PBI…プロダクトバックログアイテム

34. 副業稼働時間帯があわない稼働時間に偏りがあるリモートワーク⾮⾔語コミュニケーションできない相⼿の様⼦がわからない背景⾒えずタスク指向になりがち同期はTLが担う (スクラムイベント併⽤) 独⽴性の⾼いPBI を中⼼に開発する前衛(PL)と後衛 (TM)で細かなやり取りをへらす前衛後衛の分担とTLによる媒介 TLによる背景、情報補完時間的、場所的分断をフォーメーション (役割分担+相互作⽤のあり⽅)で適応時間の分断場所の分断集まる⼈達の経験の幅が広くなる経験の分断背⾻を先⾏させてやり⽅を規定する独⽴性同期役背⾻制約前衛後衛 Why分担と媒介雁⾏陣開発による適応 PBI…プロダクトバックログアイテム

35. 雁⾏陣開発のイメージ・Case1は、PLがおけなかった。(TLはいた) つまり、制約を先に置けなかった。なので、1PBIのオーバーヘッドが⾼く、やり⽅が整うまで時間がかかった。 1PBI開発あたりのコミュニケーションコスト⾼い仕事のやり⽅が⼈によってバラバラ・Case2は、PLの先⾏によって1ヶ⽉以上の距離(進捗)を稼いだ。この距離による期間的余⽩を戦略的に使える状況に。

36. ワンチームといえるのか？・ある意味でワンチームではない？ (PLと、TMの間) → あえて疎であることで分断を越えるためのコストを下げるそのための境界に沿った「役割」の設計。それぞれの役割を果たすことで、ホールチームとして結果を出す・ある意味で同期的ではない？ → ⾮同期で回しながら、同期を担う役割(TL)を置く。・アジャイルなの？ → スクラムとは⾔えないが、これも状況に適応するための開発の⼀つの形。

37. ところでCase1はその後どうした？・プロダクトレビューの開催⼀同に会してプロダクトを動かし、設計上の課題を話し合い、バグを出し、分担を決める。つまり⼀時期的に「強⼒な同期」によってチームの⽅向性を整えた。逆リモートワーク(合宿)で乗り切った

38. まとめ・世の中はギグ化する (副業、フリーランス + リモートワーク) ・その分、開発は新たな複雑性を迎えることになる・フォーメーション (役割分担+相互作⽤によるあり⽅) で、複雑性に適応する作戦「雁⾏陣開発」・フォーメーションを的確にこなすためには、練度とチームビルドが必要 (開発もチームスポーツのようになる)

多様な働き⽅のチームでどうやってアジャイルにやるの？(雁行陣開発)

Esté a ler uma amostra.

Confira estes a seguir

多様な働き⽅のチームでどうやってアジャイルにやるの？(雁行陣開発)

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a 多様な働き⽅のチームでどうやってアジャイルにやるの？(雁行陣開発) (20)

Mais de toshihiro ichitani (20)

Mais recentes (20)