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