個人事業主型開発からの脱却

by bayashi

Slide 1

Slide 1 text

個人事業主型開発からの脱却 XP祭り 2024 Kei Ogane 2024/9/28

Slide 2

Slide 2 text

自己紹介ばやし@bayashimura スタートアップでエンジニアやってます。前はEMとか社内アジャイルコーチとか。最近の趣味はYoutubeでエルデンリングの考察動画を見ることです

Slide 3

Slide 3 text

Linc’wellという会社で働いてます

Slide 4

Slide 4 text

今日の話これまでいくつかのチームに関わってきて遭遇した個人事業主型開発の紹介をするとともに直近でそこからの脱却するために - 自分がやったこと - 気を払ったことをお伝えします当時転職して半年くらいリーダーになりたての自分

Slide 5

Slide 5 text

目次 - 個人事業主型開発の概要 - 脱却するためにやったこと - その際に気を払ったこと

Slide 6

Slide 6 text

個人事業主型開発とはチームではあるがチームメンバー同士のコラボレーションが存在せず、指示者とチームメンバーの一対一の関係のみがある開発スタイル指示者は多くの場合 - PdM - リーダー - マネージャなど、別ポジション、別ロールの人が担う指示者メンバーメンバー

Slide 7

Slide 7 text

個人事業主型開発とは個人事業主型開発の特徴として以下がある - タスクは指示者がメンバーにアサインする - 進捗管理は指示者とメンバーの間でのみ行われる - メンバーは自分のタスクを遂行することのみ求められるタスクA タスクE タスクF タスクB タスクC タスクD これらのタスクをお願いします。締切は ◯日です。

Slide 8

Slide 8 text

一見良さそう - 指示者がアサインすることで重要なものに取り組んでもらえる - 指示者が管理することで全体に管理が行き届く - 自分にアサインされたチケットのみに取り組むことで効率アップ！

Slide 9

Slide 9 text

実際に起こること - タスクのアサイン組み換えパズルが発生して辛い - 指示者が全員を管理するの辛い - お互いのやってることに興味なくなってきて辛い

Slide 10

Slide 10 text

タスクの組み換えパズルが発生して辛いメンバーは個々人で優先順位付けされたタスクを持っており、それぞれに締切が設定されているそのため、ひとつのタスクが遅れると後続タスクもどんどん遅れていくタスクA タスクE タスクF タスクB タスクC タスクD え、タスクAが遅れてる？じゃあ後続のタスクEも間に合わないの確定ですよね

Slide 11

Slide 11 text

タスクの組み換えパズルが発生して辛いタスクを誰かに譲ろうとしても、みんな複数タスクを抱えているため、都度優先順位の調整が行われ負荷が高いタスクA タスクE タスクF タスクB タスクC タスクD 後続のタスクEを緑服さんに渡したいけどタスクCも今週リリース予定で...

Slide 12

Slide 12 text

指示者が全員を管理しないといけないから辛い指示者とメンバーの1対1の関係があるのみなので指示者が全員を管理する必要があるそのため指示者の管理負荷が非常に高いタスクA タスクE タスクF タスクB タスクC タスクD タスクAはどうですか？タスクBの状況を教えて下さい

Slide 13

Slide 13 text

お互いのやってることに興味なくなってきて辛い自分が取り組むタスクは決まっているため、他の人が取り組むタスクに関して理解をする必要がないスプリントの計画の場では、指示者とアサインされた人以外黙って聞く場になりがちアサインされてる◯◯についてですが興味ないな... ふむふむ

Slide 14

Slide 14 text

実際に起こってたこと - 指示者が管理で多忙になる - タスクの組み換えパズルが多数発生し、締切直前で未着手が発覚するなど混乱 - メンバー間のサポートが発生せず、指示者任せに

Slide 15

Slide 15 text

なんかこんな感じにしたい - 管理は指示者の仕事ではなくチームのみんなでやっていきたい - 指示者が疲弊せず、メンバーも楽しく働けるようにしたい - チームでひとつの優先順位を追いたい

Slide 16

Slide 16 text

脱却するためにやったこと - バックログをひとつにする - 事前アサインからサインアップへ - ビジネス価値に基づかない不要な締切をなくす

Slide 17

Slide 17 text

バックログがひとつじゃない優先順位付けされた一つのバックログは存在していたが、エンジニア個々人は、フィルタ機能を使って自分にアサインされたタスクのみを見ていたバックログは論理的にはチームでひとつになっていなかったタスクA タスクE タスクF タスクB タスクC タスクD タスクA タスクE タスクF タスクB タスクC タスクD ひとつの優先順位付けされたバックログアサインでフィルタされたバックログ

Slide 18

Slide 18 text

バックログをひとつにするチームでひとつの優先順位を追い、チームで大事なものから達成していきたいので、バックログを統合具体的には - アサインされた人ごとにフィルタするビューを見るのを止めた - バックログの優先順位を厳密にした

Slide 19

Slide 19 text

とはいえ事前アサインされると、自分のアサインされるチケットのみに着目しがちなのは変わらないタスクA タスクE タスクF

Slide 20

Slide 20 text

事前アサインからサインアップへチケットが作成されたタイミングで指示者が担当者をアサインしていたが - 着手するタイミングで事前アサインした人が適任かはわからない - 事前にアサインされることで自分がやるタスクのみに着目しがち - やらされ感がすごいなどの理由からサインアップ方式に変更タスクA タスクE タスクF タスクB タスクC タスクD タスクFは青服さんタスクDは緑服さん

Slide 21

Slide 21 text

サインアップとは指示者がチケットをアサインするのではなく、作業者が自分で実施するチケットを選択する方式

Slide 22

Slide 22 text

サインアップやりたいって言った時に言われたことサインアップってエンジニアが自分のやりたいタスクしかやらなくなりそうで嫌大事なタスクが放置されそう

Slide 23

Slide 23 text

サインアップとはチームの状況を鑑みて、自分がやるべきタスクを自分で判断して取っていくやり方決してメンバーがやりたいタスクを好き勝手にやるやり方ではない

Slide 24

Slide 24 text

誰が着手するかを決めるか誰がタスクの作業をすべきだろうか？作業をすばやく正しくできる人が最適なのは明白だ。それでは、その人が別の重要なタスクを担当していたり、病欠していたりして、手が空いてなかったらどうだろう？誰がタスクの作業をするかについては、さまざまな要因が影響する。これらの要因を考慮して意思決定をするのは、チームメンバーの共同責任である。エッセンシャルスクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド Kenneth S.Rubin (著), 岡澤裕二 (翻訳), 和智右桂(翻訳), 髙木正弘(翻訳), 角征典(翻訳)

Slide 25

Slide 25 text

バックログひとつにしてサインアップにした結果 - タスクの優先順位をみんな認識するようになった - 事前にアサインされたタスクがなくなったことで、サポートしやすくなった - (自分がやるかもしれないし)スプリントの計画の場ではみんなが活発に発言するようになったタスクA タスクE タスクF タスクB タスクC タスクD タスクA タスクE タスクF タスクB タスクC タスクD

Slide 26

Slide 26 text

ちょっとずつ良くなってきてるけどバックログをひとつにして、事前アサインからサインアップにすることでチームでひとつのことに向きあえるようになってきたしかし、まだ大きな問題がひとつあったそれは

Slide 27

Slide 27 text

たくさんの締切たち今週リリースマストです僕も今週リリースマストです僕は来週リリースマストです締め切りA 締め切りB 締め切りC

Slide 28

Slide 28 text

たくさんの締切たち今週リリースマストです僕も今週リリースマストです僕は来週リリースマストです締め切りA 締め切りB 締め切りC 全部最優先！

Slide 29

Slide 29 text

次に問題になったのはタスクに設定された無数の締切たち多くのタスクに締切が設定されているため、優先順位の組み替えが難しい事態に陥った今週リリースマストです

Slide 30

Slide 30 text

日付を握ると日付を握ると、どうしても最優先になるチームで最優先なものが複数生まれるとチームとしての優先順位は崩壊し、各々が各締切を各個撃破するほかなくなる個々人が異なる締切に追われる図

Slide 31

Slide 31 text

締切を紐解くなんでこんなたくさん締切あるんだろう？締切を紐解くといろんなケースが出てくる - 特定の日付に出すビジネス的必然性が存在する - 「締切を切らないと一生やらない」と思われている - 「これくらいで出せそう」がいつの間にか約束になっちゃってる

Slide 32

Slide 32 text

ビジネス的必然性が存在する締切すべての締切が不必要ではない - クリスマス向け機能 - 12/10までにリリースしないと誰も使わない - ◯◯月の法改正対応 - それを過ぎてしまうと法令違反状態になる上記のようにビジネスの必然性に基づくタイムリミットも確かに存在するただそれ以外はコミュニケーションと期待値の問題なので、できるだけ減らしていく

Slide 33

Slide 33 text

Microsoftでもそうらしいこのような積み上げスタイルの見積もりは、細かくなればなるほどブレが酷くなるから役に立たなくなるんだよ。それに納期は無理に合わせると、品質も下がるし、エンジニアがバーンアウトしたり、辞めたりするのでろくなことがないよ。 - クリス曰く見積せえへんねやったらどうやって予算取りするねんという話 - 牛尾剛 https://note.com/simplearchitect/n/n1415073eb07a

Slide 34

Slide 34 text

大事なものにフォーカスするチームできるだけ締切は作らない、作ってもスプリントにひとつというスタイルでチームとして大事なものにはフォーカスする癖をつけるひとつの締切に向き合う図

Slide 35

Slide 35 text

個人事業主型開発からの脱却成功 - タスクのアサイン組み換えパズルが発生して辛い - サインアップでリアクティブにその時最適な人が最適なタスクを実施するようになった - 指示者が全員を管理するの辛い - 指示者が全部を把握しなくても、チームメンバ同士で管理をするようになった - お互いのやってることに興味なくなってきて辛い - チームとして大事なものがわかって興味津々

Slide 36

Slide 36 text

あとなんかいい感じですね - スプリントで何が大事かを認識しその達成のために協力し実際に達成するチームになった - 指示者(うちの場合だとPdMとリーダー)が疲弊しなくなった - あとみんな楽しそう

Slide 37

Slide 37 text

ただそんなすんなりやり方が変わったわけでもなくチームのやり方を変えるためにいろんなことに気を払いました

Slide 38

Slide 38 text

気を払ったこと - アンオフィシャルな会話で温度感を掴む - チーム内の構造を変える時は外から見える振る舞いを変えない - まず自分から始める

Slide 39

Slide 39 text

アンオフィシャルな会話で温度感を掴む自分は変えたいと思っているだけど - チームのみんな - マネージャー - その他チームを取り巻く人々が変えたいと思っているかはわかってなかった

Slide 40

Slide 40 text

アンオフィシャルな会話で温度感を掴む飲み会、雑談などで軽く頭出ししてみる「今こんなこと考えてるんですけどどう思います？」誰がどの程度興味関心を持っていて、どういう考え方をしているかを掴んどく

Slide 41

Slide 41 text

アンオフィシャルな会話で温度感を掴むみんなの課題感や温度感に応じて変化のための一歩目を踏み出すか、このまま今のやり方で続けて布教していくかは判断する

Slide 42

Slide 42 text

チーム内の構造を変える時は振る舞いを変えない変化したばかりの時は、周囲も自分たちも不安で一杯変化した時は一時的にパフォーマンスが落ちるってみんなわかっていても「大丈夫？」って聞かれちゃうかも自信を失わないようにできるだけ周囲からの見え方（振る舞い）を変えないようにする

Slide 43

Slide 43 text

例えばこんな意思決定をしました - これまで通り握ってしまった締切は守る（ように頑張る）　 - ステークホルダーの関心が高いタスクに関しては優先順位を上げるなど ※締切は前述の通りそもそもどんどん握らなくてしていく、優先順位もステークホルダーの関心で全部決めてると詰むので、周囲が敏感になっている時だけにしておく

Slide 44

Slide 44 text

補足この意思決定はどこにどれくらい信頼貯金がたまってるかを勘案し「このタイミングではステークホルダーからの見え方をケアしたほうが変化が挫折する可能性が低いな」と判断して実行したいつだってこのやり方がベストなわけでは無いチームメンバステークホルダー

Slide 45

Slide 45 text

まず自分から始めるやり方決めても誰も動き出さずそのまま決めたこと自体なくなることってよくありますよねそうならないように自分が率先して - 優先順位通りにタスクをサインアップ - 自分がやっているタスクを手放して優先順位が上のタスクのサポートに行くとかやってました

Slide 46

Slide 46 text

振る舞い方が分かればみんな振る舞ってくれる - やり方がわかってない - やるのが恥ずかしいなどの理由で初めの一歩が遠くなってしまうことはよくある気にせず自分が続けてるとそのうち誰かが続いてくれる

Slide 47

Slide 47 text

自分が一番好きなパターンエバンジェリスト Evangelist 要約あたらしいアイディアを組織に導入しはじめるなら、あなたの情熱を共有するためにできるかぎりのことをしよう Fearless Change アジャイルに効くアイデアを組織に広めるための48のパターン Mary Lynn Manns (著), Linda Rising (著), 川口恭伸 (監訳), 木村卓央 (翻訳), 高江洲睦 (翻訳), 高橋一貴 (翻訳), 中込大祐 (翻訳), 安井力 (翻訳), 山口鉄平 (翻訳), 角征典 (翻訳)

Slide 48

Slide 48 text

No content