"スクラムっぽい"でも成果を出すチームづくり

by Koichi Yoshida

Slide 1

Slide 1 text

“スクラムっぽい”でも成果をだすチームづくり Scrum Fest Osaka 2024 虎ノ門トラック吉田浩一

Slide 2

Slide 2 text

よしだこういち吉田浩一 @kohzas エンジニアリング・マネージャープロダクトは順調に成長株式会社サイバーエージェント大事なことは銀英伝から学んだ広告 AI 一つのプロダクトに長く携わることが多い

Slide 3

Slide 3 text

今日のお話

Slide 4

Slide 4 text

今日のお話 ● スクラムやってますとは言えないけど、スクラムっぽいと言ってる ● どう表現すれば良いかよくわからないのでまとめてみた ● デザインパターンの落とし穴を避けるように自分たちのやり方を見つけていったらこうなった

Slide 5

Slide 5 text

[コラム] デザインパターンの落とし穴 ● 伝説のGang Of Fourによるオブジェクト指向のパターン ● デザインパターンを勉強してすぐに陥ってしまった ○ デザインパターンをなんでもかんでも適用してしまう ● “デザインパターンの落とし穴” ○ コンテキストに合わないパターンを使ってしまう ○ 必要以上にパターンを盛り込んでしまう ○ パターンに依存して柔軟性が失われてしまう ● 素晴らしいパターンでも活用方法を間違えると逆効果

Slide 6

Slide 6 text

お話するチームについて ● 立ち上げから数年が経過 ● メンバーの増減はあまりない ● メンバー全員がスクラムに詳しいわけではない私・開発責任者 EMとかSMっぽい POっぽい頼れる開発チーム

Slide 7

Slide 7 text

スクラムっぽいアプローチ

Slide 8

Slide 8 text

スクラムっぽいアプローチ1 ● スクラムの５つの価値基準と経験主義の３本柱に基づく ○ 確約、集中、公開、尊敬、勇気 ○ 透明性、検査、適応 ● その場、その時、その人たち、に最適化していく ● しっかり考え、早く作って、見てもらう ● 現在地を把握して、ゴールとの差を知る

Slide 9

Slide 9 text

スクラムっぽいアプローチ2 ● 採用は全員参加で、チームのメンバーが一緒に働きたい人を選ぶ ● （リモートだけど）密なコミュニケーション ● 目標に至る手段を自分たちで考えてつくる

Slide 10

Slide 10 text

チームはプロダクトのために価値あるプロダクト価値あるプロダクトを目指すためのチーム

Slide 11

Slide 11 text

開発スタイル

Slide 12

Slide 12 text

開発スタイル概要方向性策定開発項目開発・リリースプロダクトバックログっぽいものスクラムっぽいサイクルプロダクトゴールっぽいもの事業戦略フィードバック

Slide 13

Slide 13 text

今ここ目指す状態方向性策定なぜ、この状態が望ましいのかなぜ、この状態にする必要があるのか今、どのような状態か自分たちの能力や競争力は競合と比べてどうか

Slide 14

Slide 14 text

道のり方向性策定

Slide 15

Slide 15 text

方向性を策定することのメリット ● 目指す方向が正しければ、細かな誤差は気にしなくてよい ● 開発をチームに任せるにあたって、方向性が合っているかの確認で済む ● 目指す状態が明らかなので、振り返るときにズレをチーム自身で認識できる

Slide 16

Slide 16 text

開発項目目指す状態開発項目をブレストなどで洗い出し目指す状態への道のりに沿って優先度決め

Slide 17

Slide 17 text

開発項目を自分たちで考えるメリット ● 最初にいろんな選択肢を考えられる ● 軌道修正の際に、別の選択肢を再検討できる ● うまくいったかどうかも自分ごと化できる

Slide 18

Slide 18 text

[コラム] 目標と方向性 ● 目標は特定の時点での状態 ● 方向性は目標を含めた長期的な指針　⇒　ビジョン ● 目標に至るルートには幅がある ● 幅をもたせられるかが腕の見せ所 ★ 目標方向性

Slide 19

Slide 19 text

開発・リリースサブチームごとにメンバー構成が異なる ↓ 開発スタイルは自由

Slide 20

Slide 20 text

開発・リリース作るものの認識合わせ（バックログ）デプロイするものの認識合わせ（レビュー）開発はお任せ（デイリー共有）

Slide 21

Slide 21 text

開発・リリースをチームに任せるメリット ● プロダクトの価値を創造することに集中できる

Slide 22

Slide 22 text

チームの役割

Slide 23

Slide 23 text

チームの役割プロダクトの方向性により多くの責任（私）実現の手段により多くの責任方向性策定、関係部署との調整など開発項目策定、実験・設計・実装・システム運用

Slide 24

Slide 24 text

やっていないこと

Slide 25

Slide 25 text

やっていないこと ● 定期的な1on1 ○ 主体的に行う1on1は歓迎 ● 定期的な振り返り ● 定期的なスプリント日々のコミュニケーションの中に混ぜ込んでゆるくやっているゆるさは、実験・失敗できる余白

Slide 26

Slide 26 text

[コラム] 怖い話: 主体性の喪失 ● 安定したチームでイベントを何年も続けるとリスクも顕在化してくる ● それは徐々に主体性が失われていくということ ○ 信頼あるリーダーであるほど陥りやすい？ ● それを避けるための振り返りすらも機能不全に陥る ○ やる気のある人が浮いてしまう ● いかに主体性の喪失に陥らないようにするかがテーマ ○ その手段として、定例化せず必要なタイミングで実施 ○ また、日頃のコミュニケーションの密度が担保する ○ よく観察し、いつもと違う状態がありそうなら対話を

Slide 27

Slide 27 text

大事なこと

Slide 28

Slide 28 text

チームとして目指すところ ● 主体的・能動的な取り組み ○ 自分で決めたことをやりきれたら嬉しい ○ それが価値あることであればもっと嬉しい ○ 一人ひとりがこの状態にあればチームとして成果を最大化できる ● チームの状態に応じて柔軟に ○ 一つのやり方に固定せず、今いる人たちに最適化していく ○ 一人でも増えたり減ったりしただけでも全く別のチームと捉える ○ 過去の歴史には敬意を払いつつ、未来は常に自分たちでつくる

Slide 29

Slide 29 text

リーダーシップ ● チームが一つの方向にまとまるためには、一定のリーダーシップが必要 ● リーダーシップの目的はチームで価値を出すこと ● チームの力の分散を避け、一つの方向に集中できるように ○ 割り込み作業やちゃぶ台返しなど、途中の介入を避ける ● 信頼してもらえるような言動を心がける ○ 上司と認識を合わせておくことで、ちゃぶ台返しにならないように ○ “なぜ”その方向性が良いのか、論理的な筋道を誰よりも考える ○ わからない問題はみんなで一緒に考える

Slide 30

Slide 30 text

ミーティング ● 準備は大事 ○ 目的を明らかにしたり、状況を整理したり、話を伝えたり意見を聞くための準備 ● 準備の中でもたたき台（ポンチ絵）は重要 ○ ゼロベースで議論を進めてもコンテキストを合わせるだけで時間が終わってしまう ○ 議論の出発地点を揃えるために用いる ● フラットな状況整理が大前提 ○ 意見を誘導したい意図を含めてしまうと、そのことに対してネガティブな印象を持たれる ● 手段の話は目的・前提条件の認識があってから ○ 議論が空中戦になるときは、前提条件が擦り合っていない ● ミーティングの成果をイメージして臨む

Slide 31

Slide 31 text

さいごに

Slide 32

Slide 32 text

● やることを減らして価値に集中する ● 方向性（ゴール）を定めることで、やらないことを浮き彫りにする ○ なんでもやりたくなるときは、ゴールの解像度をあげるところから ● 気を利かせて先回りして改善しようとしない ○ “良かれと思って”って独りよがりのことが多い ● “感性”は目前の事象をより正確に捉える重要なセンサー ○ 大事なことでも数値で測れないことがある ● 現状を正しく認識できれば次の一歩を踏み出せる ● どんな状況でも“楽しむ”気持ち基本的な考え方

Slide 33

Slide 33 text

“スクラムっぽい”でも成果をだすチームづくり Scrum Fest Osaka 2024 虎ノ門トラック吉田浩一