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
440
アジャイルの名を捨ててアジャイルをやる ─アジャイルに忌避感のある現場での“困りごと駆動”の実践─
kumaGoro95
October 04, 2025
Tweet
Share
More Decks by kumaGoro95
See All by kumaGoro95
昭和の職場からアジャイルの世界へ
kumagoro95
1
650
DDDやってみたら 実装以前の領域での学びが深かった話
kumagoro95
13
8.6k
要件定義で得た学び・気づき
kumagoro95
4
2.6k
メンバーのわかりませんはチームが成長するチャンス.pdf
kumagoro95
1
420
ふりかえりでふりかえることしかできなかったジュニアチームが、次の打ち手を出せるチームになるのにやったこと
kumagoro95
3
1.5k
Githubのアクティビティ履歴からチームの健康状態を知る(Findy Teams使ってみた)
kumagoro95
0
590
プログラミングで小数計算すると なんで誤差が発生するのか?
kumagoro95
0
240
導入事例を通じて理解するドメイン駆動設計
kumagoro95
0
400
The Assembly ~ directly controlling CPU ~
kumagoro95
0
410
Other Decks in Programming
See All in Programming
問題の見方を変える「システム思考」超入門
panda_program
0
190
Swift Concurrency 年表クイズ
omochi
3
230
イベントストーミングのはじめかた / Getting Started with Event Storming
nrslib
1
360
高単価案件で働くための心構え
nullnull
0
120
「10分以内に機能を消せる状態」 の実現のためにやっていること
togishima
1
270
「正規表現をつくる」をつくる / make "make regex"
makenowjust
1
300
仕様がそのままテストになる!Javaで始める振る舞い駆動開発
ohmori_yusuke
6
3.1k
What’s Fair is FAIR: A Decentralised Future for WordPress Distribution
rmccue
0
160
自動テストを活かすためのテスト分析・テスト設計の進め方/JaSST25 Shikoku
goyoki
2
610
JJUG CCC 2025 Fall: Virtual Thread Deep Dive
ternbusty
3
260
組織もソフトウェアも難しく考えない、もっとシンプルな考え方で設計する #phpconfuk
o0h
PRO
10
4.1k
Functional Calisthenics in Kotlin: Kotlinで「関数型エクササイズ」を実践しよう
lagenorhynque
0
120
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.3k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.1k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.8k
The Art of Programming - Codeland 2020
erikaheidi
56
14k
Building Adaptive Systems
keathley
44
2.8k
Gamification - CAS2011
davidbonilla
81
5.5k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.2k
A Modern Web Designer's Workflow
chriscoyier
697
190k
Docker and Python
trallard
46
3.6k
Embracing the Ebb and Flow
colly
88
4.9k
The Invisible Side of Design
smashingmag
302
51k
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