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
320
"スクラムっぽい"でも成果を出すチームづくり
Koichi Yoshida
June 21, 2024
Tweet
Share
More Decks by Koichi Yoshida
See All by Koichi Yoshida
チームビルディングは"感性"で向き合おう / Team Building with Awareness
kohzas
1
1.5k
RPGで理解する “目的”と“目標”
kohzas
3
1.1k
チームビルディングは感性で向き合おう
kohzas
1
120
Other Decks in Technology
See All in Technology
Rubyの国のPerlMonger
anatofuz
3
720
Oracle Cloud Infrastructure:2025年7月度サービス・アップデート
oracle4engineer
PRO
1
110
Lambda management with ecspresso and Terraform
ijin
2
120
AI によるドキュメント処理を加速するためのOCR 結果の永続化と再利用戦略
tomoaki25
0
380
Bet "Bet AI" - Accelerating Our AI Journey #BetAIDay
layerx
PRO
4
1.5k
リリース2ヶ月で収益化した話
kent_code3
1
170
AIに目を奪われすぎて、周りの困っている人間が見えなくなっていませんか?
cap120
1
420
2025-07-31: GitHub Copilot Agent mode at Vibe Coding Cafe (15min)
chomado
2
360
Claude Codeが働くAI中心の業務システム構築の挑戦―AIエージェント中心の働き方を目指して
os1ma
9
1.5k
Findy Freelance 利用シーン別AI活用例
ness
0
290
Amazon Q Developerを活用したアーキテクチャのリファクタリング
k1nakayama
2
170
Perlアプリケーションで トレースを実装するまでの 工夫と苦労話
masayoshi
1
400
Featured
See All Featured
KATA
mclloyd
31
14k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
332
22k
Thoughts on Productivity
jonyablonski
69
4.8k
Designing for Performance
lara
610
69k
What's in a price? How to price your products and services
michaelherold
246
12k
Git: the NoSQL Database
bkeepers
PRO
431
65k
Facilitating Awesome Meetings
lara
54
6.5k
Making Projects Easy
brettharned
117
6.3k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Building Applications with DynamoDB
mza
95
6.5k
Embracing the Ebb and Flow
colly
86
4.8k
Gamification - CAS2011
davidbonilla
81
5.4k
Transcript
“スクラムっぽい”でも 成果をだすチームづくり Scrum Fest Osaka 2024 虎ノ門トラック 吉田 浩一
よしだ こういち 吉田 浩一 @kohzas エンジニアリング・マネージャー プロダクトは順調に成長 株式会社サイバーエージェント 大事なことは 銀英伝から学んだ
広告 AI 一つのプロダクトに 長く携わることが多い
今日のお話
今日のお話 • スクラムやってますとは言えないけど、スクラムっぽいと言ってる • どう表現すれば良いかよくわからないのでまとめてみた • デザインパターンの落とし穴を避けるように自分たちのやり方を見つけて いったらこうなった
[コラム] デザインパターンの落とし穴 • 伝説のGang Of Fourによるオブジェクト指向のパターン • デザインパターンを勉強してすぐに陥ってしまった ◦ デザインパターンをなんでもかんでも適用してしまう
• “デザインパターンの落とし穴” ◦ コンテキストに合わないパターンを使ってしまう ◦ 必要以上にパターンを盛り込んでしまう ◦ パターンに依存して柔軟性が失われてしまう • 素晴らしいパターンでも活用方法を間違えると逆効果
お話するチームについて • 立ち上げから数年が経過 • メンバーの増減はあまりない • メンバー全員がスクラムに詳しいわけではない 私・開発責任者 EMとかSMっぽい POっぽい
頼れる 開発チーム
スクラムっぽい アプローチ
スクラムっぽいアプローチ1 • スクラムの5つの価値基準と経験主義の3本柱に基づく ◦ 確約、集中、公開、尊敬、勇気 ◦ 透明性、検査、適応 • その場、その時、その人たち、に最適化していく •
しっかり考え、早く作って、見てもらう • 現在地を把握して、ゴールとの差を知る
スクラムっぽいアプローチ2 • 採用は全員参加で、チームのメンバーが一緒に働きたい人を選ぶ • (リモートだけど)密なコミュニケーション • 目標に至る手段を自分たちで考えてつくる
チームはプロダクトのために 価値あるプロダクト 価値あるプロダクトを 目指すためのチーム
開発スタイル
開発スタイル概要 方向性策定 開発項目 開発・リリース プロダクトバックログ っぽいもの スクラムっぽいサイクル プロダクトゴール っぽいもの 事業戦略
フィードバック
今ここ 目指す状態 方向性策定 なぜ、この状態が望ましいのか なぜ、この状態にする必要があるのか 今、どのような状態か 自分たちの能力や競争力は競合と比べてどうか
道のり 方向性策定
方向性を策定することのメリット • 目指す方向が正しければ、細かな誤差は気にしなくてよい • 開発をチームに任せるにあたって、方向性が合っているかの確認で済む • 目指す状態が明らかなので、振り返るときにズレをチーム自身で認識できる
開発項目 目指す状態 開発項目をブレストなど で洗い出し 目指す状態への道のりに 沿って優先度決め
開発項目を自分たちで考えるメリット • 最初にいろんな選択肢を考えられる • 軌道修正の際に、別の選択肢を再検討できる • うまくいったかどうかも自分ごと化できる
[コラム] 目標と方向性 • 目標は特定の時点での状態 • 方向性は目標を含めた長期的な指針 ⇒ ビジョン • 目標に至るルートには幅がある • 幅をもたせられるかが腕の見せ所
★ 目標 方向性
開発・リリース サブチームごとに メンバー構成が異なる ↓ 開発スタイルは自由
開発・リリース 作るものの認識合わせ (バックログ) デプロイするものの認識 合わせ (レビュー) 開発はお任せ (デイリー共有)
開発・リリースをチームに任せるメリット • プロダクトの価値を創造することに集中できる
チームの役割
チームの役割 プロダクトの方向性に より多くの責任(私) 実現の手段に より多くの責任 方向性策定、 関係部署との調整など 開発項目策定、 実験・設計・実装・システム運用
やっていないこと
やっていないこと • 定期的な1on1 ◦ 主体的に行う1on1は歓迎 • 定期的な振り返り • 定期的なスプリント 日々のコミュニケーションの中に混ぜ込んでゆるくやっている
ゆるさは、実験・失敗できる余白
[コラム] 怖い話: 主体性の喪失 • 安定したチームでイベントを何年も続けるとリスクも顕在化してくる • それは徐々に主体性が失われていくということ ◦ 信頼あるリーダーであるほど陥りやすい? •
それを避けるための振り返りすらも機能不全に陥る ◦ やる気のある人が浮いてしまう • いかに主体性の喪失に陥らないようにするかがテーマ ◦ その手段として、定例化せず必要なタイミングで実施 ◦ また、日頃のコミュニケーションの密度が担保する ◦ よく観察し、いつもと違う状態がありそうなら対話を
大事なこと
チームとして目指すところ • 主体的・能動的な取り組み ◦ 自分で決めたことをやりきれたら嬉しい ◦ それが価値あることであればもっと嬉しい ◦ 一人ひとりがこの状態にあればチームとして成果を最大化できる •
チームの状態に応じて柔軟に ◦ 一つのやり方に固定せず、今いる人たちに最適化していく ◦ 一人でも増えたり減ったりしただけでも全く別のチームと捉える ◦ 過去の歴史には敬意を払いつつ、未来は常に自分たちでつくる
リーダーシップ • チームが一つの方向にまとまるためには、一定のリーダーシップが必要 • リーダーシップの目的はチームで価値を出すこと • チームの力の分散を避け、一つの方向に集中できるように ◦ 割り込み作業やちゃぶ台返しなど、途中の介入を避ける •
信頼してもらえるような言動を心がける ◦ 上司と認識を合わせておくことで、ちゃぶ台返しにならないように ◦ “なぜ”その方向性が良いのか、論理的な筋道を誰よりも考える ◦ わからない問題はみんなで一緒に考える
ミーティング • 準備は大事 ◦ 目的を明らかにしたり、状況を整理したり、話を伝えたり意見を聞くための準備 • 準備の中でもたたき台(ポンチ絵)は重要 ◦ ゼロベースで議論を進めてもコンテキストを合わせるだけで時間が終わってしまう ◦
議論の出発地点を揃えるために用いる • フラットな状況整理が大前提 ◦ 意見を誘導したい意図を含めてしまうと、そのことに対してネガティブな印象を持たれる • 手段の話は目的・前提条件の認識があってから ◦ 議論が空中戦になるときは、前提条件が擦り合っていない • ミーティングの成果をイメージして臨む
さいごに
• やることを減らして価値に集中する • 方向性(ゴール)を定めることで、やらないことを浮き彫りにする ◦ なんでもやりたくなるときは、ゴールの解像度をあげるところから • 気を利かせて先回りして改善しようとしない ◦ “良かれと思って”って独りよがりのことが多い
• “感性”は目前の事象をより正確に捉える重要なセンサー ◦ 大事なことでも数値で測れないことがある • 現状を正しく認識できれば次の一歩を踏み出せる • どんな状況でも“楽しむ”気持ち 基本的な考え方
“スクラムっぽい”でも 成果をだすチームづくり Scrum Fest Osaka 2024 虎ノ門トラック 吉田 浩一