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
kumaGoro95
October 04, 2025
Programming
0
63
アジャイルの名を捨ててアジャイルをやる ─アジャイルに忌避感のある現場での“困りごと駆動”の実践─
kumaGoro95
October 04, 2025
Tweet
Share
More Decks by kumaGoro95
See All by kumaGoro95
昭和の職場からアジャイルの世界へ
kumagoro95
1
630
DDDやってみたら 実装以前の領域での学びが深かった話
kumagoro95
13
8.5k
要件定義で得た学び・気づき
kumagoro95
4
2.6k
メンバーのわかりませんはチームが成長するチャンス.pdf
kumagoro95
1
410
ふりかえりでふりかえることしかできなかったジュニアチームが、次の打ち手を出せるチームになるのにやったこと
kumagoro95
3
1.5k
Githubのアクティビティ履歴からチームの健康状態を知る(Findy Teams使ってみた)
kumagoro95
0
580
プログラミングで小数計算すると なんで誤差が発生するのか?
kumagoro95
0
230
導入事例を通じて理解するドメイン駆動設計
kumagoro95
0
390
The Assembly ~ directly controlling CPU ~
kumagoro95
0
400
Other Decks in Programming
See All in Programming
タスクの特性や不確実性に応じた最適な作業スタイルの選択(ペアプロ・モブプロ・ソロプロ)と実践 / Optimal Work Style Selection: Pair, Mob, or Solo Programming.
honyanya
3
140
止められない医療アプリ、そっと Swift 6 へ
medley
1
120
Let's Write a Train Tracking Algorithm
twocentstudios
0
220
非同期jobをtransaction内で 呼ぶなよ!絶対に呼ぶなよ!
alstrocrack
0
520
高度なUI/UXこそHotwireで作ろう Kaigi on Rails 2025
naofumi
4
3.4k
dynamic!
moro
9
6.4k
Playwrightはどのようにクロスブラウザをサポートしているのか
yotahada3
7
2.3k
Reduxモダナイズ 〜コードのモダン化を通して、将来のライブラリ移行に備える〜
pvcresin
2
680
なぜGoのジェネリクスはこの形なのか? Featherweight Goが明かす設計の核心
ryotaros
7
1k
開発生産性を上げるための生成AI活用術
starfish719
1
170
Django Ninja による API 開発効率化とリプレースの実践
kashewnuts
0
920
そのpreloadは必要?見過ごされたpreloadが技術的負債として爆発した日
mugitti9
2
3k
Featured
See All Featured
Site-Speed That Sticks
csswizardry
11
880
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.7k
We Have a Design System, Now What?
morganepeng
53
7.8k
Balancing Empowerment & Direction
lara
4
680
Embracing the Ebb and Flow
colly
88
4.8k
Designing Experiences People Love
moore
142
24k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Code Reviewing Like a Champion
maltzj
525
40k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
610
Learning to Love Humans: Emotional Interface Design
aarron
274
40k
Transcript
アジャイルの名を捨ててアジャイルをやる ─アジャイルに忌避感のある現場での“困りごと駆動”の実践─ くまごろー 2025.10.04
今日話したいこと 2 • 体制変更で、アジャイルに忌避感のあるチームに入った • アジャイルではなく”チームの困りごと”を起点にしたら、チームに変化が生 まれた • その活動から得た学びや気づきを共有したい
話の流れ 3 1. 背景と転機 2. 苦戦と気づき 3. 実践と姿勢 4. 起きた変化
5. うまくいかなかったこと 6. 学びとまとめ
自己紹介 4 • クリエーションライン株式会社 • 公安系の公務員→アプリエンジニア • 札幌在住(去年神奈川からUターン) • 好きなもの・関心があるもの
◦ 犬・パラドゲー(Vic3)・十二国記・蒼天 航路・幼女戦記・人類学・フィギュアス ケート 等 くまごろー(@kumaGoro_95)
背景と転機 4
もともとのチーム • 「アジャイルでやる」ことに全員が合意していた • スクラムイベントが自然に行われていた • ペアプロ・モブプロなども当たり前のようにやっていた 6
体制変更 • 体制変更で、短期的なプロジェクトチームが結成 • 「アジャイルはちょっと..」というメンバーが半数に • 以前は自然にできていたプラクティスが、強い拒否感で 跳ね返されるように 7 こないだまで当然の
ようにペアプロやっ てたのに。。
苦戦と気づき 8
苦戦とモヤモヤ 私視点では、こんな見え方だった • 今まで「当たり前」のようにやっていたことができなく なった • いい方法だと思って提案しても反発されることが多く、 苛立ちや無力感があった
• コミュニケーションがうまくいってない、議論が噛み合 わない感覚もあった 9 このやり方は効果ある のに、なぜ受け入れても らえないんだろう?
苦戦とモヤモヤ 私視点では、こんな見え方だった • 今まで「当たり前」のようにやっていたことができなく なった • いい方法だと思って提案しても反発されることが多く、 苛立ちや無力感があった
• コミュニケーションがうまくいってない、議論が噛み合 わない感覚もあった 10 このやり方は効果ある のに、なぜ受け入れても らえないんだろう? 「従来のやり方に固執しているのでは」とさえ感じていた
ある日の一幕 • 「アジャイルだったら普通はこうやります」という一言 • その瞬間に胸の中で違和感 ◦ 「普通って何?」 ◦
「なぜやるかが抜けてないか?」 ◦ 「少なくとも、説明はたりてないのでは」 → 何気ない一言だったけど、押し付けのように響いてしまうと感じた (自分がアジャイルを学び始めた時のことも思い出した) 11
固執していたのは自分だった • 知らず知らずのうちに“アジャイルの押し売り”をしていた • チームの現状を度外視して「理想のアジャイル」に近づけようとしていた • なにより「なぜそれをやりたいのか」説明が足りていなかった
→ 「アジャイル」から一旦離れて、考え方・やり方を変えてみることにした 12
どう切り替えたか • アジャイル用語を封印。用語よりも理由を伝える • チームの状況を出発点に考える • 相手の関心事や背景は徹底的に聞く
• 目の前の困りごとを起点に提案する 13 「アジャイルならこう」という考 えは一旦忘れる!
実践・姿勢
実践① モブでの資料作成 • 困りごと: ◦ 課題や進め方に対する上長との認識合わせが進まない ◦ チーム内でも理解の差・認識のズレがあった
• 提案:「関係者の認識合わせのために、皆で一気に資料を作り上げちゃいましょう」 • 工夫: ◦ 皆が同時に触れるツールで資料を作成(Web版のパワポ) ◦ 資料を作りながら認識合わせ • 変化: ◦ 上長に現状を理解してもらえて、以降の議論がスムーズに ◦ モブ作業にポジティブな印象を持ってもらえた 15
実践② プロトタイプでの早期検証 • 困りごと ◦ 不確定な仕様が多く議論が進まない ◦ 「プロトタイプを製品化してしまわないか」という不安があった
• 提案 ◦ 「捨てる前提で小さく作って、動かして調査しましょう」 • 工夫: ◦ 「プロトタイプは検証用。製品としては使わない」とチームで合意 ◦ 最小範囲で実装し、作り込まない • 変化: ◦ 具体的なサンプルによって、設計の確度が上がった ◦ プロトタイプをベースに、チームの対話が活性化した 16
姿勢① 相手の関心事を徹底的に聞く • 困りごと ◦ 提案しても受け入れてもらえない ◦ 議論が噛み合っていないと感じるときがある
• 工夫 ◦ 「自分の意見を通す」よりも「まずは聞くこと」に徹する ◦ モブや雑談で、人となりや関心事を知る • 変化 ◦ 「前提や背景を踏まえて話している」と受け止められるよう になり、提案が通りやすくなった ◦ 過去の自分の提案は、相手から見れば難しいことだったと 気づいた 17 相手の事情を理解し きれていなかった...
姿勢② ポジティブな言い換え • 困りごと ◦ 認識のズレや新たな事実の発見が、ネガティブに捉えられることが多かった • 工夫
◦ 「今気づけてよかった」「わかることが増えた」と言い換える ◦ ふりかえりで前向きな付箋を貼りまくる • 変化 ◦ ふりかえりで「認識が合ってきてよかった」という声が出てきた 18
起きた変化 12
かわってきたこと • 「拒否」から「少し話を聞いてみよう」へ • 衝突しがちだった議論が、前向きな対話ができるようになってきた • 少しずつだけど、課題が解消されてプロジェクトが前に進み始めた 20
でも、うまくいかなかったことも • 提案したが受け入れられなかった ◦ ペアプロ → 強い拒否感で断念 ◦
「設計を全部固めてから実装を始める」進め方 → 「固めたところから実装を始めません か?」という提案が拒否された • 構造的な要因もあった? ◦ 互いの会社ルールに差があった ◦ ほぼチームビルディングをせず開発に突入 → でも、こちら視点の「困りごと」を正しく伝えきれてなかったかも 21
わかったこと・学び 12
気づき/学び① 目の前の困りごとに集中 • 気づき ◦ 最初は「このアジャイルプラクティスで効果が出るはず」と固執 ◦ チームの現状を度外視して、自分にとって理想のアジャイルをやろうとしていた
• 学び ◦ 出発点は「困りごとをどう解決するか」 ◦ 判断基準は「価値を届けられるかどうか」 ◦ 用語を出さなくても、アジャイルのプラクティスは自然に実践できる 23
気づき/学び② 土台は信頼関係 • 気づき ◦ 最初は「必要なプラクティスなら納得してもらえるはず」と考えていた ◦ でも、信頼関係なしには、どんな意見も受け入れてもらえなかった
• 学び ◦ アジャイルに関係なく、相手が拒否するのには、理由や背景がある ◦ 自分の話を理解してもらうより、先に相手の話を理解することが大事 ◦ 「信頼があるからこそ、提案を聞いてもらえる」 24
さいごに • アジャイルを合意した理想のチームでなくても、できることはある • 困りごと起点で動くと、自然とアジャイルのエッセンスが活きてくる • 大事なのは「何をやるか」ではなく「なぜやるか」 • 信頼関係は全ての土台 25