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
Takafumi ONAKA
PRO
November 15, 2024
Technology
40
16k
強いチームと開発生産性
2024-11-15 開発生産性Kaigi
https://developer-productivity-engineering.connpass.com/event/332852/
Takafumi ONAKA
PRO
November 15, 2024
Tweet
Share
More Decks by Takafumi ONAKA
See All by Takafumi ONAKA
ADRを運用して3年経った僕らの現在地
onk
PRO
21
21k
1文字エイリアスのすゝめ
onk
PRO
0
26
すこやかなサービス運営のための PWG (Performance Working Group)
onk
PRO
0
96
オブザーバビリティの Primary Signals
onk
PRO
2
4.8k
Cache Stampede
onk
PRO
1
2k
ORM - Object-relational mapping
onk
PRO
2
3.6k
デュアルトラックアジャイルとの向き合い方
onk
PRO
5
12k
技術記事を書く&楽しむチームの作り方
onk
PRO
0
1.7k
グルーミングしながら進めるプロダクト開発
onk
PRO
0
2k
Other Decks in Technology
See All in Technology
生成AI×財務経理:PoCで挑むSlack AI Bot開発と現場巻き込みのリアル
pohdccoe
1
880
完璧を捨てろ! “攻め”のQAがもたらすスピードと革新/20250306 Hiroki Hachisuka
shift_evolve
0
170
人生を左右する「即答」のススメ: 一瞬の判断を間違えないためにするべきこと
takasyou
9
1.2k
Aurora PostgreSQLがCloudWatch Logsに 出力するログの課金を削減してみる #jawsdays2025
non97
1
280
AIエージェント元年@日本生成AIユーザ会
shukob
1
290
社内でKaggle部を作って初学者育成した話
daikon99
1
180
30→150人のエンジニア組織拡大に伴うアジャイル文化を醸成する役割と取り組みの変化
nagata03
0
420
DevinでAI AWSエンジニア製造計画 序章 〜CDKを添えて〜/devin-load-to-aws-engineer
tomoki10
0
260
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
37
24k
目標と時間軸 〜ベイビーステップでケイパビリティを高めよう〜
kakehashi
PRO
8
1.1k
4th place solution Eedi - Mining Misconceptions in Mathematics
rist
0
160
Codar: Arte ou Ciência?! A Jornada de um DEV na Creator Economy
vclementino
0
160
Featured
See All Featured
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.5k
How GitHub (no longer) Works
holman
314
140k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Designing for humans not robots
tammielis
250
25k
GraphQLとの向き合い方2022年版
quramy
44
14k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.3k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
115
51k
KATA
mclloyd
29
14k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.5k
RailsConf 2023
tenderlove
29
1k
Navigating Team Friction
lara
183
15k
Transcript
強いチームと開発生産性 id:onk 2024-11-15 開発生産性Kaigi 1
自己紹介 • 大仲 能史 a.k.a. id:onk • 芸歴20年目 ◦ バックエンドとインフラが得意
• 株式会社はてな ◦ チーフエンジニア ◦ いろんな役割があるけど、今日は 「開発チームの一員」の立場で話します 2
3 開発生産性とは
開発生産性とは • 生産性=生産する能力 • アウトプット / インプット • 突っ込んだ量に対して、返ってくる量の割合 4
開発生産性とは • インプット ◦ 労働人数 ◦ 労働時間 ◦ 開発人件費 ◦
総事業コスト 5
開発生産性とは • アウトプット ◦ 書いたコード量 ◦ リリースした施策数 ◦ リリースした施策の効果 ◦
売上 ◦ 新しい体験を提供し、人の生活を豊かにした量 6
開発生産性とは • 単位時間あたりのアウトプット ◦ Lv1: 仕事量(書いたコード量〜施策数) ◦ Lv2: 期待付加価値(施策数〜施策の想定KPI変化) ◦
Lv3: 実現付加価値(KPI変化〜売上) 7
開発生産性とは 8 https://qiita.com/hirokidaichi/items/53f0865398829bdebef1
9 アウトプットとアウトカム
アウトプットとアウトカム • アウトプット ◦ 自分が出力した量 ◦ 仕事量〜期待付加価値 • アウトカム ◦
自分が出力したことによって起きた、対象の変化量 ◦ 期待付加価値〜実現付加価値 10
開発生産性とは 11 アウトプット
開発生産性とは 12 アウトカム
アウトプットとアウトカム • アウトプットが凄くてもアウトカムが無い ◦ 結果に結びついていない無駄な努力 ◦ 高速にゴミを作っている ◦ 「ビルドトラップ」 13
14 デュアルトラック
15 デュアルトラック https://www.jpattonassociates.com/dual-track-development/
デュアルトラック • 仮説検証サイクルを早く回す • 仮説検証で最も遅い方法は、製品を作ること ◦ コストを掛けて本物を作る前にダメな案を高速に潰す • ディスカバリートラックで確からしさを検証 •
検証済みのものをデリバリートラックで作る 16
デュアルトラック • ディスカバリー ◦ プロダクトマネージャー寄りの仕事 ◦ 作るものを決める ▪ ユーザーインタビュー等 •
デリバリー ◦ コーディングを伴う ◦ いわゆるスクラムチームの仕事 ▪ 作って、リリースして、ユーザの反応を伺う 17
目的に辿り着くことで例えると • ディスカバリーは地図、カーナビ ◦ どこに向かうかを見定める • デリバリーは車 ◦ いろんな車があるよね ◦
速い車、遅い車 18
どちらも大事 • 地図が無いと迷子になる • 速度が遅いと時間が掛かる 19
20 正しいものを、正しく作る
正しいものを、正しく作る • シフトレフト ◦ 間違ったものを早めに潰す ◦ 修正が早い段階であればあるほどコストが掛からない ◦ リリース ->
テスト -> コードを書く時 -> 企画段階 21
22 ディスカバリーと デリバリーは両輪
23 と、言われているが 開発チーム目線では 両輪ではない
24 デリバリーが先、 ディスカバリーが後
遅い車はとにかく問題 • 地図が合っていても三輪車じゃ辿り着けない ◦ せめてエンジン付き。できれば常に整備しておきたい • 方向がベクトル90度以内に収まってればいい ◦ 象限が合っていれば十分 ▪
それ以上の精度が本当に必要? ◦ イテレーションを素早く回せば修正できる ▪ 回すことすらできない方が問題が大きい 25
開発生産性 26 アウトプット ここが低いと話にならない
高速ゴミ製造機をより好む • もし良い企画に当たったら高速にアウトカム を作れる地力がある ◦ 止まった時計も1日2回は正しい時間を指す • 高速にPDCAを回すことができる ◦ PDCAを回した数だけチームとしての強さが増す
◦ 改善している実感を手に入れられ、役割分担が自然と され、目標達成にコミットできるチームになっていく 27
もちろん場合による • 打席に立てる回数には限りがある • ゴミを作ってる余裕がまったく無いなら当た る企画だけを作るしかない ◦ アウトにならないようなヒットを狙う ◦ 打率を上げることに注力する必要がある
28
29 アウトプットを評価する
30 Four Keys
Four Keys • デプロイの頻度 • 変更のリードタイム • 変更障害率 • サービス復旧時間
31
Four Keys 32 https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition
33 強いチームはDevOpsが前提
DevOps 34 Kharnagy, CC BY-SA 4.0 • DevOpsツールチェーンの活用 • 自動化
• 継続的デリバリー • 組織文化の転換
Four Keys (2021) 35 https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition
36 開発生産性を阻害する力
ツラみが自然と溜まっていく例 • データの蓄積によるレスポンス悪化 • 仕様変更による設計の無理 • ライブラリの更新への追随を怠る • 突然応答しなくなるサーバ •
人の流動によるノウハウの低下 37
38 何もしないと開発生産性は どんどん悪化する
39 ツラみが溜まってきたのを 検知したい
ツラみの検知とFour Keys • デプロイの頻度 • 変更のリードタイム • 変更障害率 • サービス復旧時間
40
ツラみの検知とFour Keys • デプロイの頻度 ◦ おそらく変わらないだろう • 変更のリードタイム • 変更障害率
• サービス復旧時間 41
ツラみの検知とFour Keys • デプロイの頻度 • 変更のリードタイム ◦ 徐々に劣化していくはず • 変更障害率
• サービス復旧時間 42
ツラみの検知とFour Keys • デプロイの頻度 • 変更のリードタイム • 変更障害率 ◦ 徐々に劣化していくはず
• サービス復旧時間 43
ツラみの検知とFour Keys • デプロイの頻度 • 変更のリードタイム • 変更障害率 • サービス復旧時間
◦ チームの練度がどこまで下がるか次第 44
45 Four Keysでツラみの 検知はできそうだけど 基準が欲しい
46 SLO
SLOとは • サービスレベル目標 (Service Level Objective) • サービスにおいて目標値とされ る「適切な信頼性のレベル」 47
適切な信頼性のレベル • 100%の信頼性を目指すのではなく、 見極める • 信頼性にはコストが掛かる ◦ 可用性 99.9% =>
43分/月の停止が許容される ◦ 可用性 99.99% => 4分/月 ◦ 可用性 99.999% => 26秒/月 48
SLOと開発生産性指標 • デプロイ頻度 ◦ 毎日なら30日に20回デプロイ • 変更失敗率 ◦ 5%なら20回に1回発生する •
平均修復時間 ◦ 30分なら1回の障害で30分障害になる 49 障害予想時間= デプロイ頻度×変更失敗率×平均修復時間 → 30日に30分程度 障害になると予想
SLOと開発生産性指標 • 可用性 SLO 99.9%なら、43分/30日のダウ ンタイムが許される • 変更起因障害の割合 ◦ 「Binary
Push」と「Configuration Push」が該当 ◦ 障害全体の60%が変更起因障害として、26分程度が 変更起因で障害にできる許容時間 50
SLOと開発生産性指標 • 障害予想時間:30分/30日 • 障害許容時間:26分/30日 • このチームパフォーマンスだと、SLOに違反 する可能性がある 51
SLOと開発生産性指標 • ユーザー行動とビジネス価値 → SLO • SLO → エラーバジェット •
開発生産性指標 → 障害予想時間 • エラーバジェット ⇔ 障害予想時間 52
SLOと開発生産性指標 変更障害率とサービス復旧時間が 許容できなくなるところは、決められそう 53
54 リードタイム劣化の基準は 作れそうか
変更リードタイムの目標値 • 変更リードタイムが劣化=ベロシティの劣化 • ベロシティが劣化=見積もりが外れている • 見積もりの予実を見ていると検知できる 55
見積もり精度のズレを見る 56 https://speakerdeck.com/i35_267/why-do-business-failures-due-to-technical-debt-occur
見積もり精度のズレを見る 57 https://speakerdeck.com/i35_267/why-do-business-failures-due-to-technical-debt-occur
見積もり精度のズレを見る 58 https://speakerdeck.com/i35_267/why-do-business-failures-due-to-technical-debt-occur
見積もり精度のズレを見る 59 https://speakerdeck.com/i35_267/why-do-business-failures-due-to-technical-debt-occur
見積もり精度のズレを見る 60 https://speakerdeck.com/i35_267/why-do-business-failures-due-to-technical-debt-occur
アウトプット量を減らす力を可視化す る • SLOも事業計画も、事業責任者の関心事 • Four Keysをただの「開発生産性指標」に留 めず、事業責任者の関心事に沿った形で負債 の量を測る武器にする 61
62 「作業」と「仕事」
「作業8割、仕事2割」 • 私の持論 • 「作業」は今日の飯の種を得るための業務 • 「仕事」は未来のお金を作るための業務 • 未来のお金≒時間 ◦
機械にやらせたり、一目で分かるようにしたり、 誰でも判断できるようにしたり 63
「作業8割、仕事2割」 • 仕事が1割を切ると生活が良くなっていく未来 が見えなくてしんどい • 逆に3割を超えるとカイゼンにうつつを抜かし てる状態 • 15〜20%ぐらいを劣化力との戦いに使ってい るとバランス良いんじゃないか
64
65 アウトプットを作るチー ム
66 グループからチームへ
グループとチーム 67 『組織行動のマネジメント』スティーブン P.ロビンス著、髙木晴夫訳、2009年、ダイアモンド社
グループとチーム 68 https://asana.com/ja/resources/group-vs-team
69 毛づくろい
毛づくろい • 社会的グルーミング ◦ サルはお互いに毛づくろいを行う ◦ 毛づくろいは、集団の絆を維持するための「社交」 ◦ 集団のサイズが大きくなると毛づくろい時間も増える ことが知られている
70
毛づくろい • サルにおけるお互いの毛づくろい ◦ 自分の時間を相手のために使うよ ◦ 相手から触られることが不快じゃないよ ◦ 信頼の土台を築いていく •
人間における毛づくろい ◦ 雑談は毛づくろいに当たると言えるのではないか ◦ 関係性を構築する行為 71
72 得意を知る
得意を知る 73
得意を知る • ボケ、ツッコミ、客のどの役割を持つか ◦ こういう発言をするとこういう拾い方をしてくれるだ ろうという安心感 • 「心理的安全性」 ◦ お互いが相手の得意に合わせて、想定しながら動く
74
得意を知る • 相手がどういうやり方が得意なのかを知る ◦ 具体で伝えるか、抽象で伝える方が良いか ◦ マイクロマネジメントが良いか、放任が良いか ◦ 瞬発的に考えて話すか、じっくり考えてから話すか ◦
物理出社したいか、リモートが良いか 75
76 阿吽の呼吸の チームを作るのは 時間がかかる
77 ハイパフォーマンスなチームを解散す るのは、単なる破壊行為では済まな い。企業レベルのサイコパスと呼ぶべ きものだ。 ──アラン・ケリー、『Project Myopia』
78 得意を組み合わせるよう 座組を考える
座組を考える • 役割を網羅することを考える 79
座組を考える • PdM、PjM、TL、… ◦ サービス開発に必要な各役割 • 問題発見、課題化、遂行 ◦ 問題を見つけられる人、タスクに落とし込める人、 タスクを遂行する人
◦ 考える人だけ集めても、手を動かす時間が取れなかっ たら問題は解決しない 80
座組を考える • 専門家 ◦ 深く掘らないと解決できない問題を、解決まで持って 行ける人 • ジェネラリスト ◦ 複数の領域が必要な問題を、人と人を繋げたり、両方
の仕事をやったりして、解決まで持って行ける人 81
座組を考える • ムードメーカー ◦ ハードな状況でもチームをポジティブなムードに持っ て行ける人。提案に対して第一声が「面白そう」な人 • 気が利く人 ◦ なんか漏れてるものを拾ってくれたり、ムラがあるの
で解消しませんか or 私がやりますって言い出したり 82
83 体制作りで気をつけること
84
「年老いた組織」 85 『技術の創造と設計』畑村 洋太郎著、2006年、 岩波書店
ドイツ人の仕事、日本人の仕事。 86 https://www.huffingtonpost.jp/toru-hisai/post_b_11478870.html
個人技は必要 • 個人技が足りないと、手 を伸ばす余力を持てない • 領域を重複するよう設計 できず、穴だらけになる 87
個人技は必要 88
個人技は必要 • 低レベルクリアは戦い方が限られる ◦ バラモスよりも素早くベホイミを撃てないと詰むとか • 今の戦力で限られた戦い方を探すよりも、個 人技を鍛える方が楽になることは多い 89
90 まとめ
まとめ • アウトプットとアウトカム ◦ 開発チームとしてはアウトプットで80点をまず目指す • アウトプットを阻害する力 ◦ 負債を見える化。SLOを決めて対応を判断する •
強いチームは生産性が高い ◦ コミュニケーションと体制設計と個人技で強くする 91