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
Koichi Yoshida
June 21, 2024
Technology
0
190
"スクラムっぽい"でも成果を出すチームづくり
Koichi Yoshida
June 21, 2024
Tweet
Share
More Decks by Koichi Yoshida
See All by Koichi Yoshida
チームビルディングは"感性"で向き合おう / Team Building with Awareness
kohzas
0
1.1k
RPGで理解する “目的”と“目標”
kohzas
2
200
チームビルディングは感性で向き合おう
kohzas
0
83
Other Decks in Technology
See All in Technology
DynamoDB でスロットリングが発生したとき/when_throttling_occurs_in_dynamodb_short
emiki
0
250
OCI Security サービス 概要
oracle4engineer
PRO
0
6.5k
Application Development WG Intro at AppDeveloperCon
salaboy
0
190
ドメインの本質を掴む / Get the essence of the domain
sinsoku
2
160
TypeScript、上達の瞬間
sadnessojisan
46
13k
初心者向けAWS Securityの勉強会mini Security-JAWSを9ヶ月ぐらい実施してきての近況
cmusudakeisuke
0
130
VideoMamba: State Space Model for Efficient Video Understanding
chou500
0
190
心が動くエンジニアリング ── 私が夢中になる理由
16bitidol
0
100
Can We Measure Developer Productivity?
ewolff
1
150
アジャイルでの品質の進化 Agile in Motion vol.1/20241118 Hiroyuki Sato
shift_evolve
0
170
10XにおけるData Contractの導入について: Data Contract事例共有会
10xinc
6
660
OCI Vault 概要
oracle4engineer
PRO
0
9.7k
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
16
2.1k
Scaling GitHub
holman
458
140k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
44
2.2k
Code Review Best Practice
trishagee
64
17k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
370
A Modern Web Designer's Workflow
chriscoyier
693
190k
YesSQL, Process and Tooling at Scale
rocio
169
14k
It's Worth the Effort
3n
183
27k
Building a Scalable Design System with Sketch
lauravandoore
459
33k
The Power of CSS Pseudo Elements
geoffreycrofte
73
5.3k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
GitHub's CSS Performance
jonrohan
1030
460k
Transcript
“スクラムっぽい”でも 成果をだすチームづくり Scrum Fest Osaka 2024 虎ノ門トラック 吉田 浩一
よしだ こういち 吉田 浩一 @kohzas エンジニアリング・マネージャー プロダクトは順調に成長 株式会社サイバーエージェント 大事なことは 銀英伝から学んだ
広告 AI 一つのプロダクトに 長く携わることが多い
今日のお話
今日のお話 • スクラムやってますとは言えないけど、スクラムっぽいと言ってる • どう表現すれば良いかよくわからないのでまとめてみた • デザインパターンの落とし穴を避けるように自分たちのやり方を見つけて いったらこうなった
[コラム] デザインパターンの落とし穴 • 伝説のGang Of Fourによるオブジェクト指向のパターン • デザインパターンを勉強してすぐに陥ってしまった ◦ デザインパターンをなんでもかんでも適用してしまう
• “デザインパターンの落とし穴” ◦ コンテキストに合わないパターンを使ってしまう ◦ 必要以上にパターンを盛り込んでしまう ◦ パターンに依存して柔軟性が失われてしまう • 素晴らしいパターンでも活用方法を間違えると逆効果
お話するチームについて • 立ち上げから数年が経過 • メンバーの増減はあまりない • メンバー全員がスクラムに詳しいわけではない 私・開発責任者 EMとかSMっぽい POっぽい
頼れる 開発チーム
スクラムっぽい アプローチ
スクラムっぽいアプローチ1 • スクラムの5つの価値基準と経験主義の3本柱に基づく ◦ 確約、集中、公開、尊敬、勇気 ◦ 透明性、検査、適応 • その場、その時、その人たち、に最適化していく •
しっかり考え、早く作って、見てもらう • 現在地を把握して、ゴールとの差を知る
スクラムっぽいアプローチ2 • 採用は全員参加で、チームのメンバーが一緒に働きたい人を選ぶ • (リモートだけど)密なコミュニケーション • 目標に至る手段を自分たちで考えてつくる
チームはプロダクトのために 価値あるプロダクト 価値あるプロダクトを 目指すためのチーム
開発スタイル
開発スタイル概要 方向性策定 開発項目 開発・リリース プロダクトバックログ っぽいもの スクラムっぽいサイクル プロダクトゴール っぽいもの 事業戦略
フィードバック
今ここ 目指す状態 方向性策定 なぜ、この状態が望ましいのか なぜ、この状態にする必要があるのか 今、どのような状態か 自分たちの能力や競争力は競合と比べてどうか
道のり 方向性策定
方向性を策定することのメリット • 目指す方向が正しければ、細かな誤差は気にしなくてよい • 開発をチームに任せるにあたって、方向性が合っているかの確認で済む • 目指す状態が明らかなので、振り返るときにズレをチーム自身で認識できる
開発項目 目指す状態 開発項目をブレストなど で洗い出し 目指す状態への道のりに 沿って優先度決め
開発項目を自分たちで考えるメリット • 最初にいろんな選択肢を考えられる • 軌道修正の際に、別の選択肢を再検討できる • うまくいったかどうかも自分ごと化できる
[コラム] 目標と方向性 • 目標は特定の時点での状態 • 方向性は目標を含めた長期的な指針 ⇒ ビジョン • 目標に至るルートには幅がある • 幅をもたせられるかが腕の見せ所
★ 目標 方向性
開発・リリース サブチームごとに メンバー構成が異なる ↓ 開発スタイルは自由
開発・リリース 作るものの認識合わせ (バックログ) デプロイするものの認識 合わせ (レビュー) 開発はお任せ (デイリー共有)
開発・リリースをチームに任せるメリット • プロダクトの価値を創造することに集中できる
チームの役割
チームの役割 プロダクトの方向性に より多くの責任(私) 実現の手段に より多くの責任 方向性策定、 関係部署との調整など 開発項目策定、 実験・設計・実装・システム運用
やっていないこと
やっていないこと • 定期的な1on1 ◦ 主体的に行う1on1は歓迎 • 定期的な振り返り • 定期的なスプリント 日々のコミュニケーションの中に混ぜ込んでゆるくやっている
ゆるさは、実験・失敗できる余白
[コラム] 怖い話: 主体性の喪失 • 安定したチームでイベントを何年も続けるとリスクも顕在化してくる • それは徐々に主体性が失われていくということ ◦ 信頼あるリーダーであるほど陥りやすい? •
それを避けるための振り返りすらも機能不全に陥る ◦ やる気のある人が浮いてしまう • いかに主体性の喪失に陥らないようにするかがテーマ ◦ その手段として、定例化せず必要なタイミングで実施 ◦ また、日頃のコミュニケーションの密度が担保する ◦ よく観察し、いつもと違う状態がありそうなら対話を
大事なこと
チームとして目指すところ • 主体的・能動的な取り組み ◦ 自分で決めたことをやりきれたら嬉しい ◦ それが価値あることであればもっと嬉しい ◦ 一人ひとりがこの状態にあればチームとして成果を最大化できる •
チームの状態に応じて柔軟に ◦ 一つのやり方に固定せず、今いる人たちに最適化していく ◦ 一人でも増えたり減ったりしただけでも全く別のチームと捉える ◦ 過去の歴史には敬意を払いつつ、未来は常に自分たちでつくる
リーダーシップ • チームが一つの方向にまとまるためには、一定のリーダーシップが必要 • リーダーシップの目的はチームで価値を出すこと • チームの力の分散を避け、一つの方向に集中できるように ◦ 割り込み作業やちゃぶ台返しなど、途中の介入を避ける •
信頼してもらえるような言動を心がける ◦ 上司と認識を合わせておくことで、ちゃぶ台返しにならないように ◦ “なぜ”その方向性が良いのか、論理的な筋道を誰よりも考える ◦ わからない問題はみんなで一緒に考える
ミーティング • 準備は大事 ◦ 目的を明らかにしたり、状況を整理したり、話を伝えたり意見を聞くための準備 • 準備の中でもたたき台(ポンチ絵)は重要 ◦ ゼロベースで議論を進めてもコンテキストを合わせるだけで時間が終わってしまう ◦
議論の出発地点を揃えるために用いる • フラットな状況整理が大前提 ◦ 意見を誘導したい意図を含めてしまうと、そのことに対してネガティブな印象を持たれる • 手段の話は目的・前提条件の認識があってから ◦ 議論が空中戦になるときは、前提条件が擦り合っていない • ミーティングの成果をイメージして臨む
さいごに
• やることを減らして価値に集中する • 方向性(ゴール)を定めることで、やらないことを浮き彫りにする ◦ なんでもやりたくなるときは、ゴールの解像度をあげるところから • 気を利かせて先回りして改善しようとしない ◦ “良かれと思って”って独りよがりのことが多い
• “感性”は目前の事象をより正確に捉える重要なセンサー ◦ 大事なことでも数値で測れないことがある • 現状を正しく認識できれば次の一歩を踏み出せる • どんな状況でも“楽しむ”気持ち 基本的な考え方
“スクラムっぽい”でも 成果をだすチームづくり Scrum Fest Osaka 2024 虎ノ門トラック 吉田 浩一