Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
個人事業主型開発からの脱却
Search
bayashi
September 27, 2024
13
8.5k
個人事業主型開発からの脱却
XP祭り2024の登壇資料です
bayashi
September 27, 2024
Tweet
Share
More Decks by bayashi
See All by bayashi
エンジニアとして関わる要件と仕様(公開用)
murabayashi
0
310
スクラムフェスを支える配信の仕組み
murabayashi
1
260
締切とはなにか、どういう効果があるのか #scrummikawa
murabayashi
0
1.1k
商用アプリケーション開発基本のキ
murabayashi
0
200
(新米)エンジニアリングマネージャーのしごと #RSGT2023
murabayashi
11
10k
Active Recordについてわかったことを説明するよ
murabayashi
0
290
話を聞き出す技術
murabayashi
43
46k
フィヨルドブートキャンプ ドリンクアップ用会社紹介資料
murabayashi
0
330
カスタマーサポートから運用までみんなでやってるうちのチームのスクラム
murabayashi
0
2.9k
Featured
See All Featured
Bash Introduction
62gerente
608
210k
Scaling GitHub
holman
458
140k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
380
Done Done
chrislema
181
16k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
Why Our Code Smells
bkeepers
PRO
334
57k
Testing 201, or: Great Expectations
jmmastey
38
7.1k
A Philosophy of Restraint
colly
203
16k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
A better future with KSS
kneath
238
17k
Adopting Sorbet at Scale
ufuk
73
9.1k
Transcript
個人事業主型開発 からの脱却 XP祭り 2024 Kei Ogane 2024/9/28
自己紹介 ばやし@bayashimura スタートアップでエンジニアやってま す。前はEMとか社内アジャイルコーチと か。 最近の趣味はYoutubeでエルデンリング の考察動画を見ることです
Linc’wellという会社で働いてます
今日の話 これまでいくつかのチームに関わってきて遭遇した 個人事業主型開発 の紹介をするとともに 直近でそこからの脱却するために - 自分がやったこと - 気を払ったこと をお伝えします
当時転職して半年くらい リーダーになりたての自分
目次 - 個人事業主型開発の概要 - 脱却するためにやったこと - その際に気を払ったこと
個人事業主型開発とは チームではあるがチームメンバー同士のコラボ レーションが存在せず、指示者とチームメン バーの一対一の関係のみがある開発スタイル 指示者は多くの場合 - PdM - リーダー -
マネージャ など、別ポジション、別ロールの人が担う 指示者 メンバー メンバー
個人事業主型開発とは 個人事業主型開発の特徴として以下がある - タスクは指示者がメンバーにアサインする - 進捗管理は指示者とメンバーの間でのみ行われる - メンバーは自分のタスクを 遂行することのみ求められる タスクA
タスクE タスクF タスクB タスクC タスクD これらのタスクをお 願いします。締切は ◯日です。
一見良さそう - 指示者がアサインすることで 重要なものに取り組んでもらえる - 指示者が管理することで 全体に管理が行き届く - 自分にアサインされたチケットのみに 取り組むことで効率アップ!
実際に起こること - タスクのアサイン組み換えパズルが発生して辛い - 指示者が全員を管理するの辛い - お互いのやってることに興味なくなってきて辛い
タスクの組み換えパズルが発生して辛い メンバーは個々人で優先順位付けされたタスクを 持っており、それぞれに締切が設定されている そのため、ひとつのタスクが遅れると 後続タスクもどんどん遅れていく タスクA タスクE タスクF タスクB タスクC
タスクD え、タスクAが遅れてる? じゃあ後続のタスクEも間 に合わないの確定ですよね
タスクの組み換えパズルが発生して辛い タスクを誰かに譲ろうとしても、 みんな複数タスクを抱えているため、 都度優先順位の調整が行われ負荷が高い タスクA タスクE タスクF タスクB タスクC タスクD
後続のタスクEを緑服さん に渡したいけどタスクCも 今週リリース予定で...
指示者が全員を管理しないといけないから辛い 指示者とメンバーの1対1の関係があるのみなので 指示者が全員を管理する必要がある そのため指示者の管理負荷が非常に高い タスクA タスクE タスクF タスクB タスクC タスクD
タスクAは どうです か? タスクBの 状況を教え て下さい
お互いのやってることに興味なくなってきて辛い 自分が取り組むタスクは決まっているため、 他の人が取り組むタスクに関して 理解をする必要がない スプリントの計画の場では、 指示者とアサインされた人以外 黙って聞く場になりがち アサインされてる◯◯につ いてですが 興味ないな...
ふむふむ
実際に起こってたこと - 指示者が管理で多忙になる - タスクの組み換えパズルが多数発生し、 締切直前で未着手が発覚するなど混乱 - メンバー間のサポートが発生せず、 指示者任せに
なんかこんな感じにしたい - 管理は指示者の仕事ではなく チームのみんなでやっていきたい - 指示者が疲弊せず、 メンバーも楽しく働けるようにしたい - チームでひとつの優先順位を追いたい
脱却するためにやったこと - バックログをひとつにする - 事前アサインからサインアップへ - ビジネス価値に基づかない不要な締切をなくす
バックログがひとつじゃない 優先順位付けされた一つのバックログは存在し ていたが、エンジニア個々人は、フィルタ機能 を使って自分にアサインされたタスクのみを見 ていた バックログは論理的にはチームでひとつになっ ていなかった タスクA タスクE タスクF
タスクB タスクC タスクD タスクA タスクE タスクF タスクB タスクC タスクD ひとつの優先順位付けされた バックログ アサインでフィルタされたバックログ
バックログをひとつにする チームでひとつの優先順位を追い、 チームで大事なものから達成していきたいの で、バックログを統合 具体的には - アサインされた人ごとにフィルタする ビューを見るのを止めた - バックログの優先順位を厳密にした
とはいえ 事前アサインされると、 自分のアサインされるチケットのみに 着目しがちなのは変わらない タスクA タスクE タスクF
事前アサインからサインアップへ チケットが作成されたタイミングで指示者が担当者を アサインしていたが - 着手するタイミングで事前アサインした人が適任 かはわからない - 事前にアサインされることで自分がやるタスクの みに着目しがち -
やらされ感がすごい などの理由からサインアップ方式に変更 タスクA タスクE タスクF タスクB タスクC タスクD タスクFは 青服さん タスクDは 緑服さん
サインアップとは 指示者がチケットをアサインするのではなく、 作業者が自分で実施するチケットを選択する方式
サインアップやりたいって言った時に言われたこと サインアップってエンジニアが自分 のやりたいタスクしかやらなくなり そうで嫌 大事なタスクが放置されそう
サインアップとは チームの状況を鑑みて、自分がやるべきタス クを自分で判断して取っていくやり方 決してメンバーがやりたいタスクを好き勝手 にやるやり方ではない
誰が着手するかを決めるか 誰がタスクの作業をすべきだろうか? 作業をすばやく正しくできる人が最適 なのは明白だ。それでは、その人が別 の重要なタスクを担当していたり、病 欠していたりして、手が空いてなかっ たらどうだろう? 誰がタスクの作業を するかについては、さまざまな要因が 影響する。これらの要因を考慮して意
思決定をするのは、チームメンバーの 共同責任である 。 エッセンシャルスクラム: アジャイル開発に関わるす べての人のための完全攻略ガイド Kenneth S.Rubin (著), 岡澤 裕二 (翻訳), 和智 右桂(翻訳), 髙木 正弘(翻訳), 角 征典(翻訳)
バックログひとつにしてサインアップにした結果 - タスクの優先順位をみんな認識するように なった - 事前にアサインされたタスクがなくなった ことで、サポートしやすくなった - (自分がやるかもしれないし)スプリントの 計画の場ではみんなが活発に発言するよう
になった タスクA タスクE タスクF タスクB タスクC タスクD タスクA タスクE タスクF タスクB タスクC タスクD
ちょっとずつ良くなってきてるけど バックログをひとつにして、事前アサインからサイ ンアップにすることでチームでひとつのことに向き あえるようになってきた しかし、まだ大きな問題がひとつあった それは
たくさんの締切たち 今週リリースマス トです 僕も今週リリース マストです 僕は来週リリース マストです 締め切りA 締め切りB 締め切りC
たくさんの締切たち 今週リリースマス トです 僕も今週リリース マストです 僕は来週リリース マストです 締め切りA 締め切りB 締め切りC
全部最優先!
次に問題になったのは タスクに設定された無数の締切たち 多くのタスクに締切が設定されているた め、優先順位の組み替えが難しい事態に 陥った 今週リリースマス トです
日付を握ると 日付を握ると、どうしても最優先になる チームで最優先なものが複数生まれるとチー ムとしての優先順位は崩壊し、各々が各締切 を各個撃破するほかなくなる 個々人が異なる締切に追われる図
締切を紐解く なんでこんなたくさん締切あるんだろう? 締切を紐解くといろんなケースが出てくる - 特定の日付に出す ビジネス的必然性が存在する - 「締切を切らないと一生やらない」 と思われている -
「これくらいで出せそう」が いつの間にか約束になっちゃってる
ビジネス的必然性が存在する締切 すべての締切が不必要ではない - クリスマス向け機能 - 12/10までにリリースしないと誰も使わない - ◯◯月の法改正対応 - それを過ぎてしまうと法令違反状態になる
上記のようにビジネスの必然性に基づくタイム リミットも確かに存在する ただそれ以外はコミュニケーションと期待値の 問題なので、できるだけ減らしていく
Microsoftでもそうらしい このような積み上げスタイルの見積も りは、細かくなればなるほどブレが酷 くなるから役に立たなくなるんだよ。 それに納期は無理に合わせると、品質 も下がるし、エンジニアがバーンアウ トしたり、辞めたりするのでろくなこ とがないよ。 - クリス曰く
見積せえへんねやったらどうやって予算取りするねん という話 - 牛尾剛 https://note.com/simplearchitect/n/n1415073eb07a
大事なものにフォーカスするチーム できるだけ締切は作らない、作ってもスプリントに ひとつ というスタイルでチームとして大事なものには フォーカスする癖をつける ひとつの締切に向き合う図
個人事業主型開発からの脱却成功 - タスクのアサイン組み換えパズルが発生して 辛い - サインアップでリアクティブにその時最適な人が最 適なタスクを実施するようになった - 指示者が全員を管理するの辛い -
指示者が全部を把握しなくても、チームメンバ同士 で管理をするようになった - お互いのやってることに興味なくなってきて 辛い - チームとして大事なものがわかって興味津々
あとなんかいい感じですね - スプリントで何が大事かを認識しその達成の ために協力し実際に達成するチームになった - 指示者(うちの場合だとPdMとリーダー)が 疲弊しなくなった - あとみんな楽しそう
ただそんなすんなりやり方が変わったわけでもなく チームのやり方を変えるために いろんなことに気を払いました
気を払ったこと - アンオフィシャルな会話で温度感を掴む - チーム内の構造を変える時は外から見える振る舞いを変えない - まず自分から始める
アンオフィシャルな会話で温度感を掴む 自分は変えたいと思っている だけど - チームのみんな - マネージャー - その他チームを取り巻く人々 が変えたいと思っているかはわかってなかった
アンオフィシャルな会話で温度感を掴む 飲み会、雑談などで軽く頭出ししてみる 「今こんなこと考えてるんですけどどう思 います?」 誰がどの程度興味関心を持っていて、 どういう考え方をしているかを掴んどく
アンオフィシャルな会話で温度感を掴む みんなの課題感や温度感に応じて 変化のための一歩目を踏み出すか、 このまま今のやり方で続けて 布教していくかは判断する
チーム内の構造を変える時は振る舞いを変えない 変化したばかりの時は、 周囲も自分たちも不安で一杯 変化した時は一時的にパフォーマンスが落ち るってみんなわかっていても 「大丈夫?」って聞かれちゃうかも 自信を失わないようにできるだけ周囲からの 見え方(振る舞い)を変えないようにする
例えば こんな意思決定をしました - これまで通り握ってしまった締切は守る (ように頑張る) - ステークホルダーの関心が高いタスクに関 しては優先順位を上げるなど ※締切は前述の通りそもそもどんどん握らなくてしていく、 優先順位もステークホルダーの関心で全部決めてると詰むの
で、周囲が敏感になっている時だけにしておく
補足 この意思決定は どこにどれくらい信頼貯金がたまってるかを勘 案し 「このタイミングではステークホルダーからの 見え方をケアしたほうが変化が挫折する可能性 が低いな」 と判断して実行した いつだってこのやり方がベストなわけでは無い チームメンバ
ステーク ホルダー
まず自分から始める やり方決めても誰も動き出さず そのまま決めたこと自体なくなることって よくありますよね そうならないように自分が率先して - 優先順位通りにタスクをサインアップ - 自分がやっているタスクを手放して 優先順位が上のタスクのサポートに行く
とかやってました
振る舞い方が分かればみんな振る舞ってくれる - やり方がわかってない - やるのが恥ずかしい などの理由で初めの一歩が 遠くなってしまうことはよくある 気にせず自分が続けてると そのうち誰かが続いてくれる
自分が一番好きなパターン エバンジェリスト Evangelist 要約 あたらしいアイディアを組織に導入し はじめるなら、あなたの情熱を共有す るためにできるかぎりのことをしよう Fearless Change アジャイルに効く
アイデアを組織 に広めるための48のパターン Mary Lynn Manns (著), Linda Rising (著), 川口 恭 伸 (監訳), 木村 卓央 (翻訳), 高江洲 睦 (翻訳), 高橋 一貴 (翻訳), 中込 大祐 (翻訳), 安井 力 (翻 訳), 山口 鉄平 (翻訳), 角 征典 (翻訳)
None