Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

5,515 views

Published on

副業、リモートワークによるコミュニケーション分断を、フォーメーションで乗り越えるチーム開発

Published in: Software
  • Be the first to comment

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

  1. 1. Toshihiro Ichitani All Rights Reserved. 多様な働き⽅のチームでどうやって アジャイルにやるの? Ichitani Toshihiro 市⾕聡啓 「雁⾏陣開発」による 多様性を受け⼊れたプロダクトづくり
  2. 2. Toshihiro Ichitani All Rights Reserved. Ichitani Toshihiro 市⾕聡啓 ソフトウェア開発17年 SIer→サービス→受託→起業 仮説検証とアジャイル開発 ギルドワークス株式会社 代表 株式会社 エナジャイル 代表 DevLOVE コミュニティ ファウンダ The Agile Guild オーガナイザー 0 → 1 @papanda https://ichitani.com/
  3. 3. 4刷 https://www.amazon.co.jp/dp/4798153346/
  4. 4. Toshihiro Ichitani All Rights Reserved. https://www.slideshare.net/papanda/ss-66082690 「正しいものを正しくつくる」 『正しいものを正しくつくる(仮)』 2019年6⽉22⽇ごろ予定 #正しいものを正しくつくる本 (twitter)で制作過程を発信
  5. 5. Toshihiro Ichitani All Rights Reserved. https://ichitani.com/ その他、詳しくはこちら
  6. 6. Toshihiro Ichitani All Rights Reserved. スタートアップや事業会社での 新規事業、新規サービスの⽴ち上げ 事業会社での現場改善、仮説検証コーチ ギルドワークス 「正しいものを正しくつくる」 Why What
  7. 7. Toshihiro Ichitani All Rights Reserved. 仮説検証型アジャイル開発 「正しくないものをつくらない」戦略 =正しいものを残し (仮説検証)、  正しくつくる (アジャイル開発) 正しいものを正しくつくるために
  8. 8. 本⽇のテーマ
  9. 9. 働き⽅、働く場所がバラバラの チームでどうやって プロダクトづくりをするの?
  10. 10. 働き⽅、働く場所の多様性の広がり 副業、複業の時代 ・昼間はSIerや⼤企業。夜や⼟曜は副業でサービス開発。 ・いきなりフリーランスというハードル以外の選択肢。 ・何でもって正業、副業とするか⾒分けがつかなくなる (複業) リモートワーク ・導⼊率11.5% (総務省、2018年7⽉調査) ・働く場所を問わない現場がこの5年で増えてきている。 ・週1リモートのような部分適⽤も。
  11. 11. Photo credit: bourgol on Visual Hunt / CC BY-NC-ND ギグ・エコノミー (Gig Economy)
  12. 12. ギグ = ⼀夜限りの仕事 ギグとは? ・もともはミュージシャンが⼀夜限りの契約でライブ演奏に  参加することを指した。 ・代表的なギグなサービスといえば「Uber」 ・フリーランス、副業はギグ的になりやすい。仕事における  ⾃分の役割、責務を果たした時点で仕事を終える。 ・アメリカではインディペンデント・コントラクター  (独⽴業務請負⼈)と呼ばれる。 ギグワークとは?
  13. 13. https://theagileguild.org/
  14. 14. https://theagileguild.org/
  15. 15. 多様性の広がり = 現場の複雑性の⾼まり 副業、リモートワークの課題とは? ・本⼈の課題感以上に、周囲の課題感が⾼まる。 ・副業=時間の分断、リモートワーク=場所の分断。 ・副業とリモートワークの2⾝合体で時間と場所の分断が  同時に起こる = コミュニケーションの分断 ・ギグ側が「⾃分の責務を果たしたら仕事は終わり」という  感覚だとしたら。チームとしてどうやって上⼿くやる?
  16. 16. …とはいえ、副業やリモートが悪なのではない 働き⽅の多様性↑ = ⼈の多様な価値観を受け⼊れる 世界になってきているということ ・なので“同席”が正しい、副業・リモートが間違っているという  ⼆元論で⽚付けることではない。 ・「同席の頃はどうでこうで」と⽐べることには意味がない。 ・別の基準(働き⽅)で選択したこと重視するならば、仕事の  やり⽅で最適化を⽬指すより他ない。  (それでもダメなら諦めよう)
  17. 17. プロダクトづくりの複雑性にどう向き合うか 「コミュニケーションの分断」による複雑性  Vs マネジメント? ・作戦1「マネジメントを無くす」= ⾃⼰組織化、ティール化  マネジメントしようとするから無理がある、やめる。  → ⾃⼰組織化を⽬指すのは、理想だが時間はかかる。
  18. 18. プロダクトづくりの複雑性にどう向き合うか 「コミュニケーションの分断」による複雑性  Vs マネジメント? ・作戦1「マネジメントを無くす」= ⾃⼰組織化、ティール化  マネジメントしようとするから無理がある、やめる。  → ⾃⼰組織化を⽬指すのは、理想だが時間はかかる。 ・作戦2「フォーメーション・パターンで適応する」=今回のお話  ⽬の前の状況に「⼀辺倒のチーム運営」ではなく、  フォーメーション(役割分担+相互作⽤のあり⽅)を  期限性で切って適応する。
  19. 19. 解決したい課題の解像度を上げる
  20. 20. 副業 稼働時間帯 があわない 稼働時間に 偏りがある リモート ワーク ⾮⾔語コミュニケー ションできない 相⼿の様⼦が わからない 背景⾒えずタスク 指向になりがち 時間の分断 場所の分断 集まる⼈達の経験 の幅が広くなる 経験の分断
  21. 21. 副業 稼働時間帯 があわない 稼働時間に 偏りがある リモート ワーク ⾮⾔語コミュニケー ションできない 相⼿の様⼦が わからない 背景⾒えずタスク 指向になりがち スクラムイベン トができない (同期しにくい) 1PBI開発あたりの コミュニケーショ ンコスト⾼い 伝わる内容、 分量が 圧倒的に少ない 異常検知が 働きにくい Whyが弱いため 間違いに気付き にくい 「コミュニケーションの分断」 によって⾼まる複雑性 時間の分断 場所の分断 集まる⼈達の経験 の幅が広くなる 経験の分断 仕事のやり⽅が ⼈によって バラバラ オーバー ヘッド 同期 やり⽅ 内容分量 異常検知 分断による6つの問題 PBI…プロダクト バックログアイテム No Why
  22. 22. 6つの分断問題に向き合ったプロジェクト Case1 情報提供サービスの実験プロジェクト ・副業メンバー中⼼。不同期問題、オーバーヘッド問題が顕著。 ・特に、スクラムイベントを成り⽴たせることの困難さ。 ・…というのは既に⾃前プロダクトづくりで経験済なので  「曳光弾開発」(「Ship it!」) でチーム⽴ち上げ前の先⾏開発  分の実装を増やす作戦を取る。 ・ところが、アドバンテージをあっという間に⾷いつぶす状況に。  互いのコミュニケーションが⾜りず、認識齟齬が増え、バグ量産 雁⾏陣開発取らず
  23. 23. 6つの分断問題に向き合ったプロジェクト Case2 組織診断向けサービスのプロジェクト ・フリーランス(複業)メンバー中⼼。リモートワークによる分断。 ・既に事例1を⼿がけていたので、副業+リモートワークの2⾝合体  の荒ぶり⽅から次の作戦が必要なことが分かっていた。 ・そこで…新しいフォーメーション(役割分担+相互作⽤のあり⽅)を。  分断の解消にいく(時間をあわせる、会合を増やす)のではなく、  分断を環境制約として、その下でのあり⽅の最適を⽬指す。 雁⾏陣開発
  24. 24. 雁⾏陣開発
  25. 25. 雁⾏陣とは? ・「雁⾏」とは、空を並んで⾶ぶ雁の⾏列のこと。 ・「雁⾏陣」とは、いにしえの戦場での陣形のこと。または、  テニスにおける陣形。
  26. 26. 雁⾏陣開発 ・プロダクトリード、チームリードという役割を置く。 ・其々のミッション(プロダクト開発、チーム運営)での先導を務める。 <フォーメーションイメージ>
  27. 27. 背⾻PBIとお⾁PBI ⾏動 PBI 商品を 探す 商品を ⾒る カートに ⼊れる 注⽂情報 ⼊れる 商品検索 ⼀覧機能 お気に⼊り 機能 お気に⼊ りする 決済 する 履歴 ⾒る 商品詳細 機能 カート 機能 注⽂機能 決済機能 購⼊履歴 機能 ⼀覧並替 機能 背⾻バックログ お⾁バックログ ・背⾻バックログ = ユーザー体験上必ず求められるPBL           (どう考えてもこれが無いと体験が成⽴しないモノ) ・お⾁バックログ = 背⾻を前提として⾁付けしていくイメージのPBL           (1つ1つのPBIの独⽴性が⾼い) ※ユーザー⾏動フローベースで「背⾻」と「お⾁」を⾒極める
  28. 28. プロダクトリード ・チームメンバーより先⾏して「背⾻」開発に専任するメンバー。 ・背⾻先⾏開発 = 作るためにアーキテクチャや設計を決める         = 開発に必要な「制約」が先に決まる ・ゆえに、腕は求められる (設計のリード、議論のリード)。 ・場所的に分断されたメンバー向き  細やかなコミュニケーションが不要な状況をつくる。 (前衛)
  29. 29. チームメンバー ・「お⾁」開発を担うメンバー。  出来ている「背⾻」に繋げていくイメージの開発。  背⾻開発でアーキテクチャや設計、主要なデータモデルを  先⾏して決めているため、⼤ブレしにくい。 ・「お⾁」の独⽴性が⾼いため、バラバラで、並⾏して開発が  ⾏える。 ・時間的に分断されたメンバー向き。  それぞれの働く時間帯を問わない。 (後衛)
  30. 30. チームリード ・チームメンバーの活動のインテグレーションを担う。 ・チームメンバーがそれぞれ動けるように必要な情報を補完。  それぞれのアウトプットをプロダクトに統合する(受け⼊れ)。 ・独⽴して動くプロダクトリードに共有するべき必要な情報を渡す。  つまり、分断を越えて間を繋いでいく役割(媒介者)。 ・働く時間に偏りが少ないメンバー向き。  全体を俯瞰(状況を捉え意思決定)出来る⼒が求められる。 (媒介者)
  31. 31. 「リード」とは? ・「リーダー」は、⼈に張り付いた⾔葉のイメージが強い。 ・「リード」は、ある状況において前進を先導する「役割」。   役割なので、他の⼈に変わる、変えることもある、   より動的なイメージを表現したい。   (Case2でのPLは4スプリントで役割を終えた)
  32. 32. 雁⾏陣開発のイメージ 商品検索 ⼀覧機能 商品詳細 機能 SPRINT1 管理側 機能 ・PLが背⾻づくりにひた⾛る ・他のメンバーは最初は開発  のリズムを掴むべくあえて  差し障りの無い機能を作る  ところから始める。 プロダクトリード チームメンバー チームリード カート 機能 SPRINT2 ⼀覧並替 機能 ・PLは引き続き背⾻づくり ・他のメンバーは仕上がった  背⾻に繋げられる機能から  開発していく。 ・TLがスプリント終了時に  まとめて受け⼊れテスト プロダクトリード チームメンバー チームリード お気に⼊ り機能 注⽂ 機能 SPRINT3 カート 付帯機能 プロダクトリード チームメンバー チームリード 決済 機能 ・PLはひたすら背⾻づくり ・他のメンバーは前スプリント  の背⾻に機能をつなげる。 ・TLは(以下略) ・デザイナーは2スプリント分の  デザインコーディングを⾏う デザイナー
  33. 33. 副業 稼働時間帯 があわない 稼働時間に 偏りがある リモート ワーク ⾮⾔語コミュニケー ションできない 相⼿の様⼦が わからない 背景⾒えずタスク 指向になりがち スクラムイベン トができない (同期しにくい) 1PBI開発あたりの コミュニケーショ ンコスト⾼い 伝わる内容、 分量が 圧倒的に少ない 異常検知が 働きにくい Whyが弱いため 間違いに気付き にくい 「コミュニケーションの分断」 によって⾼まる複雑性 時間の分断 場所の分断 集まる⼈達の経験 の幅が広くなる 経験の分断 仕事のやり⽅が ⼈によって バラバラ オーバー ヘッド 同期 やり⽅ 内容分量 No Why異常検知 分断による6つの問題 PBI…プロダクト バックログアイテム
  34. 34. 副業 稼働時間帯 があわない 稼働時間に 偏りがある リモート ワーク ⾮⾔語コミュニケー ションできない 相⼿の様⼦が わからない 背景⾒えずタスク 指向になりがち 同期はTLが 担う (スクラムイベン ト併⽤) 独⽴性の⾼いPBI を中⼼に開発する 前衛(PL)と後衛 (TM)で細かなや り取りをへらす 前衛後衛の分担 とTLによる媒介 TLによる背景、 情報補完 時間的、場所的分断をフォーメーション (役割分担+相互作⽤のあり⽅)で適応 時間の分断 場所の分断 集まる⼈達の経験 の幅が広くなる 経験の分断 背⾻を先⾏させ てやり⽅を 規定する 独⽴性同期役 背⾻制約 前衛後衛 Why分担と媒介 雁⾏陣開発による適応 PBI…プロダクト バックログアイテム
  35. 35. 雁⾏陣開発のイメージ ・Case1は、PLがおけなかった。(TLはいた)  つまり、制約を先に置けなかった。なので、1PBIのオーバーヘッド   が⾼く、やり⽅が整うまで時間がかかった。 1PBI開発あたりの コミュニケーショ ンコスト⾼い 仕事のやり⽅が ⼈によって バラバラ ・Case2は、PLの先⾏によって1ヶ⽉以上の距離(進捗)を稼いだ。  この距離による期間的余⽩を戦略的に使える状況に。
  36. 36. ワンチームといえるのか? ・ある意味でワンチームではない? (PLと、TMの間)  → あえて疎であることで分断を越えるためのコストを下げる    そのための境界に沿った「役割」の設計。    それぞれの役割を果たすことで、ホールチームとして結果を出す ・ある意味で同期的ではない?  → ⾮同期で回しながら、同期を担う役割(TL)を置く。 ・アジャイルなの?  → スクラムとは⾔えないが、これも状況に適応するための開発の    ⼀つの形。
  37. 37. ところでCase1はその後どうした? ・プロダクトレビューの開催  ⼀同に会してプロダクトを動かし、設計上の課題を話し合い、  バグを出し、分担を決める。つまり⼀時期的に「強⼒な同期」に  よってチームの⽅向性を整えた。 逆リモートワーク(合宿)で乗り切った
  38. 38. まとめ ・世の中はギグ化する (副業、フリーランス + リモートワーク) ・その分、開発は新たな複雑性を迎えることになる ・フォーメーション (役割分担+相互作⽤によるあり⽅) で、複雑性に  適応する作戦「雁⾏陣開発」 ・フォーメーションを的確にこなすためには、練度とチームビルドが  必要 (開発もチームスポーツのようになる)

×