2024/04/22 13:54
natsutan
わかる。若手がアサインされたタスク処理マンになっていて、横から見ていて大丈夫かな～って思ってる。
2024/04/22 14:00
zentarou
前置きがディフェンシブでとても良い
2024/04/22 14:00
hachibeechan
この中でもゴリラパターンはスクラムのアンチパターンとして明言されているけど、あれって人類の性質上絶対発生するからなあ……みたいな不自然さがチラホラあるんだよね
2024/04/22 14:13
nunulk
興味深い
2024/04/22 14:15
sugawara1991
(良い)スクラムを運営する経験は成長の機会だと思う。スクラムで開発を続けることに注力することそれのみでは必ずしも組織や個人の成長を担保しないはず。手法は手段であって目的ではない
2024/04/22 15:00
yarumato
“特定の分野の技能を身につけるには、その分野における一定量のタスクを一定の時間をかけて１人でこなしていく経験も必要だが、この作業の進め方はスクラム的にはアンチパターンにされがち”
2024/04/22 15:06
ssig33
形式的、官僚的になりがちだよね。単に納期を守らないだけのウォーターフォールだと感じることが多い。
2024/04/22 15:24
PrivateIntMain
モノを作り続けるための方法論であって、そこに学習機会に関することは含まれてない(ので別途用意する必要あり)という認識。
2024/04/22 15:26
turanukimaru
言われた事だけをやる人間や自分でタスクを立てない人はスクラムに向いていないが、新人新卒で言われないこともやったり適切にタスクを立てられる人は滅多にいない。新人教育には向かないのではないかとは思う。
2024/04/22 15:34
sinoh
っていうかきちんとできるエンジニアメンバーがちゃんと揃ってるなら いちいちスクラムがどうとかやらなくてもすんなり事が運んでいくんだよなぁ
2024/04/22 15:39
mockmock9876
受け身なやり方を続けると人や仕組みのサポートが手厚すぎて何も学ばないことになる。ある程度行動力がある人に向いてると思う。
2024/04/22 15:40
dkfj
実際のところ、良いスクラムを運用し続けるのが難しいという話なのかも。どうしても「なんちゃってスクラム」が多くなるからね。でも、それは（リスクが顕在化するところは違うが、）ウォーターフォールも同じかな。
2024/04/22 15:44
tk_musik
ビジネスを無視するスクラムは意味がないと思う。価値を生み出すことが第一義なのに。そして逆にウォーターフォールでも本来的には期限を神格化しないようにもできるはず。しかし複雑な世界において何かを為すには〜
2024/04/22 15:48
ducktoon
スクラム開発はボス的メンバーの居心地が良いだけでしょう
2024/04/22 15:55
xlc
どうもスクラムにはやること自体が目的化してしまう「武道」のような側面があるようだ。
2024/04/22 15:56
dot
行間にトップダウンな雰囲気を感じる。タスクはアサインじゃなく基本サインアップにした方が良い。ボトムアップな雰囲気を作れたら、スクラムでも若手はちゃんと育つし、今のままならスクラム止めてもアレな気が。
2024/04/22 16:00
yamadadadada2
若手を育てようという意識でやれてるだけマシなんじゃないかな。経験者の寄せ集めで好き勝手してる現場は数年後に何かの残骸が出来上がる
2024/04/22 16:07
satoru830624
“グループワーク苦手な人は苦しくなりがち” 上記は同意見だが、それ以外は微妙。というか、成長機会を奪う、というタイトルなら、その理由だけを書いてほしい
2024/04/22 16:11
renowan
そもそも納期があるものはスクラムに向いてないのでは？
2024/04/22 16:20
sun330
納期があるものはアジャイル向いてないという話がある一方、海外でウオーターフォールやってないという話をきくと本当に？どうやって？となる今日この頃…
2024/04/22 16:25
inatax
スクラムはプロジェクトの不確実性に立ち向かうためのものであって、開発速度の最大化が目的ではない、という理解だな
2024/04/22 16:39
mrmt
わからなくもないけど、なぜそれをスクラムに意見として出さないのかな。黙ったままならそりゃうまく行かないよね。「スクラムって何かムカつく! を10個程度の論旨展開にまとめて」とAIに頼むとこれが出る気もする。
2024/04/22 16:45
eichisanden
とは言え、タスクを縦割りにしてリーダがアサインして、他のチームメンバーが何やっているか分からない状況で自分のタスクに全集中するのも嫌だと思うので、スクラムに限らず試行錯誤しながらやっていくしかない
2024/04/22 16:50
easy-breezy
みんなで話し合って決めたんだからこれで合ってるよね〜でapproveしてしまう悪しき風潮はある
2024/04/22 16:51
twotiger
この記事、めちゃくちゃいいね。スクラム開発ってメンバー全員が陽キャのガンバルマン前提で、弊社はスクラムを採用してますと聞くとうんざりする、と個人的には思ったり思わなかったりする
2024/04/22 16:56
cinq_na
日本人の悪い民主主義の影響もあるのかな。学級会の多数決は絶対、少数意見は踏み潰して良い、みたいな。
2024/04/22 17:03
suikyojin
成長機会を奪うって、スクラムの問題ではなく、プロジェクトの評価方法の問題では？スクラムは柔軟性が高いから、成長機会を与えないようなプロジェクトにすることもできるというだけの話だと思う。
2024/04/22 17:10
furu_ichi
この記事に列挙された事象は確かに起こり得るけど、その人がスクラムに向いていないだけじゃないかな。スクラムは万人向きの手法ではないと思う。あと主語がでかい。
2024/04/22 17:31
tsutaken
心理的安全性、権限の委譲、多様性の尊重あたりの問題に見える。がんばれスクラムマスターの人。（著者では無いらしい）
2024/04/22 17:39
hdampty7
プロダクトの形が分かっているならスクラムは冗長だと思う。ゲームとか、一部のアプリケーションのように明確な仕様が決まっていない中でチームで試行錯誤したい場合に有効な手法だと思う。
2024/04/22 18:30
kabakiyo
スクラムとかアジャイルって参考にするものであって、最終的には自分たちで考えてやり方を作っていくものだし、型にハマらないほうが良いと思う。
2024/04/22 18:31
gomer-pyle
スクラムの問題では無さそう
2024/04/22 18:49
otation
ウォーターフォールでも個人が勝手にやり方を決めるなんてことできないけど…
2024/04/22 18:56
augsUK
企画を含む意志決定を偉い人や声の大きな人が頻繁に行う体制になると、下っ端がただのタスク処理さんになる。それこそスクラムやってた人材にはリーダーが任せられない状況に。
2024/04/22 19:06
NOV1975
初級レベルの成長過程のエンジニアがここに入っていくのけっこう大変だよな（教育コストが織り込まれるスクラム開発ってあんまりないから）。ひたすらマシーンみたいに一つのことをやる羽目になりがち。
2024/04/22 19:13
houyhnhm
何というか、スクラムで開発規模大きくするの無理じゃねとか思えてくる。
2024/04/22 19:19
fuji_haruka
“チーム内で異端となったメンバーの逃げ場がない” わかる気がする。どうやって意見の対立を調整するかみたいなコミュニケーションのやり方はスクラムのフレームワーク外だからね。
2024/04/22 19:24
ledsun
わからない。スクラム関係なくチーム運営がヘタに思える。つまり、同じチームでウォーターフォール開発しても同じような問題が起きそうに思えます。
2024/04/22 19:39
NacK
スクラム開発してるのにMBOで個人の年間目標立てろと言われて無理じゃねって最近思いました
2024/04/22 19:43
dentaro
中身はあまり同意できないが、専門性を高めるスーパーマンにはなれない、という意味でタイトルには同意する。あと優秀なスクラムマスターがいないとキツイ
2024/04/22 20:36
yasushicohi
うーーん
2024/04/22 20:36
IzumiSy
わからんでもないけど、反論記事を読みたい
2024/04/22 20:42
justgg
わかるが、そういう副作用が働くことを前提にそれぞれの問題にどう対処するかを考えたほうが、全くアジャイルをしないよりマシだと思う。アジャイルなしのチームはリーダーのトップダウンになりがち。
2024/04/22 20:42
choota
試行錯誤したり、俯瞰してプロダクト見たりするタイミングがウォーターフォールより少ないかもとは思う。//アジャイル宣言もプロフェッショナルとしての振る舞いの話ではないだし、そこに至る前の人には難しい。
2024/04/22 20:50
tanority
“チーム内でのコミュニケーションが密になりがちなので。チーム内で浮いてしまうとそれだけでかなり居心地が悪くなります”面白い現象
2024/04/22 20:53
door-s-dev
スクラムに限らないものが並んでてうーんて感じ。最後まで読んでないけど/スクラムがを主張したいなら他では発生しない理由が書いてないと説得力がね
2024/04/22 21:03
tockri
スクラムガイドにはモブプログラミングやれとも、なんでも合議で決めろとも、リファクタリングを優先しろとも書いてないよ。
2024/04/22 21:31
s-nanagi
いくつかは典型的なアンチパターンに陥っているように見える（ゴリラとか）。スクラムやるならチームビルディングも同様に重要であることも忘れがち。チームや人の問題に帰結する部分もあるので大変だし難しい。
2024/04/22 21:45
kazukan
アジャイルもスクラムもシルバーバレットじゃねーって言い始めてから何年立つんだろうな
2024/04/22 21:50
toro-chan
声が大きいってのは技術力があるってこと?それとも単にうるさくて技術力が低い?により違うと思うけど。技術力があるなら本来はうまくタスク割当してもいいとは思うが、なかなか両方は難しいかも
2024/04/22 22:20
paulownia
ここで挙げている問題点を振り返りで挙げて検討せずネットに吐き出してるのチームビルドに失敗してる感ある。これに向かい合えるチーム作りが難しいのは分かる
2024/04/22 23:13
funa-1g
なんとなくスクラムを始めると陥りがちな問題が並んでいるように思う。ハマったこともある。こういう問題のためにふりかえりとスクラムマスターの役割があるので、そこを機能させるのが大事。当然大変。
2024/04/23 00:03
georgew
実際に個人の成果は可視化されないことが多いにも関わらず、会社の評価制度が個人の成果を重んじていたりする > ここに矛盾が凝縮。
2024/04/23 00:06
santo
確かに、スクラム開発って、フォード型のライン作業者みたいになるのかもな。
2024/04/23 06:40
t2y-1979
いくつかは同意できるが、いくつかはスクラム関係なくプロジェクトマネジメントの問題。たしかにスクラムはチームの問題と言っておけば個人の責任回避ができて便利ではある
2024/04/23 06:45
clairvy
心理的安全性とか、課題解決の話？課題があるなら解決に向かうのがいいと思うけど。やれない、ということだろうか。課題があるなら変えればいいと思うけど。
2024/04/23 07:46
delphinus35
これは大前提を間違っている。スクラムは現状を把握するフレームワークであって何かを解決する訳ではない。問題が把握できてるのならそれをSM、PO、開発者全員で話し合って解決するべき（スクラム継続の是非を含む）
2024/04/23 09:16
dowson
チームワークを重視し過ぎている、という感覚は確かにある。 全員等しく優秀で、コミュニケーションも高く、同じ目線で動いているなら機能するが、そうでないメンバーにとっては煩わしく感じられる時がある。
2024/04/23 09:22
yogasa
エンジニアなら自習するから問題ないよ
2024/04/23 09:27
nemoba
アジャイル開発してないイテレーション開発に、アジャイル開発は駄目だーって批判してる人多いよね。アジャイル開発がそもそも分かりづらいんだよね。タイムボックスの柔軟性と改善繰り返し開発なにょよ
2024/04/23 09:34
ene0kcal
書かれている数点は、アジャイル開発のよくある誤解そのもの。他の数点はアジャイル開発のデメリットそのもの。もう先人が初期の段階でまとめた静的知識の類なので勉強不足です。
2024/04/23 09:59
etah
原理主義者が守破離を許さず攻撃的なので「スクラムしてます」と言いたくない
2024/04/23 10:43
sigwyg
どっちかというと、これを反証としたブコメのほうが参考になる
2024/04/23 11:02
tattyu
属人性を排除し不確実なプロダクト制作の為の手法。成長は業務外で個人で頑張るしかない。異端は残念だけどチームから外れて貰うしか無い。
2024/04/23 15:58
notojin
コード書かない奴が 、スクラム研修に参加して、スクラム開発とかスクラムマスターとか言い出して、アホかと思った
2024/04/24 11:09
yoshitaro-yoyo
スクラム関係ないペインだけど、これをスクラムのペインだと捉えている人が多いことが興味深い。スクラムの誤った解釈の普及・実践例という視点、組織の課題をスクラム運用上の課題と混同され易い問題という視点。
2024/04/24 14:27
funky--46
わかる...
2024/04/25 06:38
yuuu1993g
多分スクラムの問題ではないけど、スクラム導入によって顕在化しやすい問題だとおもた