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
340
"スクラムっぽい"でも成果を出すチームづくり
Koichi Yoshida
June 21, 2024
Tweet
Share
More Decks by Koichi Yoshida
See All by Koichi Yoshida
人のせい? 仕組みのせい? - People or Process
kohzas
0
62
チームビルディングは"感性"で向き合おう / Team Building with Awareness
kohzas
1
1.6k
RPGで理解する “目的”と“目標”
kohzas
3
1.2k
チームビルディングは感性で向き合おう
kohzas
1
130
Other Decks in Technology
See All in Technology
AWS re:Invent 2025事前勉強会資料 / AWS re:Invent 2025 pre study meetup
kinunori
0
790
AI機能プロジェクト炎上の 3つのしくじりと学び
nakawai
0
150
RemoteFunctionを使ったコロケーション
mkazutaka
1
140
会社を支える Pythonという言語戦略 ~なぜPythonを主要言語にしているのか?~
curekoshimizu
4
900
アノテーション作業書作成のGood Practice
cierpa0905
PRO
0
270
20251027_findyさん_音声エージェントLT
almondo_event
2
490
ストレージエンジニアの仕事と、近年の計算機について / 第58回 情報科学若手の会
pfn
PRO
4
890
20251029_Cursor Meetup Tokyo #02_MK_「あなたのAI、私のシェル」 - プロンプトインジェクションによるエージェントのハイジャック
mk0721
PRO
5
1.9k
GraphRAG グラフDBを使ったLLM生成(自作漫画DBを用いた具体例を用いて)
seaturt1e
1
160
abema-trace-sampling-observability-cost-optimization
tetsuya28
0
360
可観測性は開発環境から、開発環境にもオブザーバビリティ導入のススメ
layerx
PRO
4
1.8k
オブザーバビリティと育てた ID管理・認証認可基盤の歩み / The Journey of an ID Management, Authentication, and Authorization Platform Nurtured with Observability
kaminashi
2
1.2k
Featured
See All Featured
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
Designing for humans not robots
tammielis
254
26k
Java REST API Framework Comparison - PWX 2021
mraible
34
8.9k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
3.7k
It's Worth the Effort
3n
187
28k
A Modern Web Designer's Workflow
chriscoyier
697
190k
Faster Mobile Websites
deanohume
310
31k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.2k
The Cult of Friendly URLs
andyhume
79
6.6k
Large-scale JavaScript Application Architecture
addyosmani
514
110k
Transcript
“スクラムっぽい”でも 成果をだすチームづくり Scrum Fest Osaka 2024 虎ノ門トラック 吉田 浩一
よしだ こういち 吉田 浩一 @kohzas エンジニアリング・マネージャー プロダクトは順調に成長 株式会社サイバーエージェント 大事なことは 銀英伝から学んだ
広告 AI 一つのプロダクトに 長く携わることが多い
今日のお話
今日のお話 • スクラムやってますとは言えないけど、スクラムっぽいと言ってる • どう表現すれば良いかよくわからないのでまとめてみた • デザインパターンの落とし穴を避けるように自分たちのやり方を見つけて いったらこうなった
[コラム] デザインパターンの落とし穴 • 伝説のGang Of Fourによるオブジェクト指向のパターン • デザインパターンを勉強してすぐに陥ってしまった ◦ デザインパターンをなんでもかんでも適用してしまう
• “デザインパターンの落とし穴” ◦ コンテキストに合わないパターンを使ってしまう ◦ 必要以上にパターンを盛り込んでしまう ◦ パターンに依存して柔軟性が失われてしまう • 素晴らしいパターンでも活用方法を間違えると逆効果
お話するチームについて • 立ち上げから数年が経過 • メンバーの増減はあまりない • メンバー全員がスクラムに詳しいわけではない 私・開発責任者 EMとかSMっぽい POっぽい
頼れる 開発チーム
スクラムっぽい アプローチ
スクラムっぽいアプローチ1 • スクラムの5つの価値基準と経験主義の3本柱に基づく ◦ 確約、集中、公開、尊敬、勇気 ◦ 透明性、検査、適応 • その場、その時、その人たち、に最適化していく •
しっかり考え、早く作って、見てもらう • 現在地を把握して、ゴールとの差を知る
スクラムっぽいアプローチ2 • 採用は全員参加で、チームのメンバーが一緒に働きたい人を選ぶ • (リモートだけど)密なコミュニケーション • 目標に至る手段を自分たちで考えてつくる
チームはプロダクトのために 価値あるプロダクト 価値あるプロダクトを 目指すためのチーム
開発スタイル
開発スタイル概要 方向性策定 開発項目 開発・リリース プロダクトバックログ っぽいもの スクラムっぽいサイクル プロダクトゴール っぽいもの 事業戦略
フィードバック
今ここ 目指す状態 方向性策定 なぜ、この状態が望ましいのか なぜ、この状態にする必要があるのか 今、どのような状態か 自分たちの能力や競争力は競合と比べてどうか
道のり 方向性策定
方向性を策定することのメリット • 目指す方向が正しければ、細かな誤差は気にしなくてよい • 開発をチームに任せるにあたって、方向性が合っているかの確認で済む • 目指す状態が明らかなので、振り返るときにズレをチーム自身で認識できる
開発項目 目指す状態 開発項目をブレストなど で洗い出し 目指す状態への道のりに 沿って優先度決め
開発項目を自分たちで考えるメリット • 最初にいろんな選択肢を考えられる • 軌道修正の際に、別の選択肢を再検討できる • うまくいったかどうかも自分ごと化できる
[コラム] 目標と方向性 • 目標は特定の時点での状態 • 方向性は目標を含めた長期的な指針 ⇒ ビジョン • 目標に至るルートには幅がある • 幅をもたせられるかが腕の見せ所
★ 目標 方向性
開発・リリース サブチームごとに メンバー構成が異なる ↓ 開発スタイルは自由
開発・リリース 作るものの認識合わせ (バックログ) デプロイするものの認識 合わせ (レビュー) 開発はお任せ (デイリー共有)
開発・リリースをチームに任せるメリット • プロダクトの価値を創造することに集中できる
チームの役割
チームの役割 プロダクトの方向性に より多くの責任(私) 実現の手段に より多くの責任 方向性策定、 関係部署との調整など 開発項目策定、 実験・設計・実装・システム運用
やっていないこと
やっていないこと • 定期的な1on1 ◦ 主体的に行う1on1は歓迎 • 定期的な振り返り • 定期的なスプリント 日々のコミュニケーションの中に混ぜ込んでゆるくやっている
ゆるさは、実験・失敗できる余白
[コラム] 怖い話: 主体性の喪失 • 安定したチームでイベントを何年も続けるとリスクも顕在化してくる • それは徐々に主体性が失われていくということ ◦ 信頼あるリーダーであるほど陥りやすい? •
それを避けるための振り返りすらも機能不全に陥る ◦ やる気のある人が浮いてしまう • いかに主体性の喪失に陥らないようにするかがテーマ ◦ その手段として、定例化せず必要なタイミングで実施 ◦ また、日頃のコミュニケーションの密度が担保する ◦ よく観察し、いつもと違う状態がありそうなら対話を
大事なこと
チームとして目指すところ • 主体的・能動的な取り組み ◦ 自分で決めたことをやりきれたら嬉しい ◦ それが価値あることであればもっと嬉しい ◦ 一人ひとりがこの状態にあればチームとして成果を最大化できる •
チームの状態に応じて柔軟に ◦ 一つのやり方に固定せず、今いる人たちに最適化していく ◦ 一人でも増えたり減ったりしただけでも全く別のチームと捉える ◦ 過去の歴史には敬意を払いつつ、未来は常に自分たちでつくる
リーダーシップ • チームが一つの方向にまとまるためには、一定のリーダーシップが必要 • リーダーシップの目的はチームで価値を出すこと • チームの力の分散を避け、一つの方向に集中できるように ◦ 割り込み作業やちゃぶ台返しなど、途中の介入を避ける •
信頼してもらえるような言動を心がける ◦ 上司と認識を合わせておくことで、ちゃぶ台返しにならないように ◦ “なぜ”その方向性が良いのか、論理的な筋道を誰よりも考える ◦ わからない問題はみんなで一緒に考える
ミーティング • 準備は大事 ◦ 目的を明らかにしたり、状況を整理したり、話を伝えたり意見を聞くための準備 • 準備の中でもたたき台(ポンチ絵)は重要 ◦ ゼロベースで議論を進めてもコンテキストを合わせるだけで時間が終わってしまう ◦
議論の出発地点を揃えるために用いる • フラットな状況整理が大前提 ◦ 意見を誘導したい意図を含めてしまうと、そのことに対してネガティブな印象を持たれる • 手段の話は目的・前提条件の認識があってから ◦ 議論が空中戦になるときは、前提条件が擦り合っていない • ミーティングの成果をイメージして臨む
さいごに
• やることを減らして価値に集中する • 方向性(ゴール)を定めることで、やらないことを浮き彫りにする ◦ なんでもやりたくなるときは、ゴールの解像度をあげるところから • 気を利かせて先回りして改善しようとしない ◦ “良かれと思って”って独りよがりのことが多い
• “感性”は目前の事象をより正確に捉える重要なセンサー ◦ 大事なことでも数値で測れないことがある • 現状を正しく認識できれば次の一歩を踏み出せる • どんな状況でも“楽しむ”気持ち 基本的な考え方
“スクラムっぽい”でも 成果をだすチームづくり Scrum Fest Osaka 2024 虎ノ門トラック 吉田 浩一