スクラム開発がエンジニアから成長機会を奪うかもしれない話 - 開発日報

おことわり 最初に断っておきますが、私はスクラム開発反対の立場をとっているわけではないです。また、スクラムマスターでもないのでスクラム開発について誤った見解を持っている可能性も大いにあります。 また、これから記載するスクラム開発のペインはあくまでも筆者の独断と偏見に基づいて記載されております。そのため、ペインの原因がスクラム開発ではなく、単にその所属組織の構成員の性質や文化的な要因であることも考えられます。おそらく、スクラム開発でなくても起こり得る問題も多く挙げていると思います。そういった側面も踏まえてご意見あれば忌憚なく反論異論いただければ幸いです。 なぜこの記事を書いたか チーム内で密なコミュニケーションをとりながら、個人ではなくあくまでもチームとしての成果を重視するスクラム開発の開発フローは、割と個人の活躍と成長機会を奪ってしまい、結果として組織としても開発成果が縮小均衡になってしま

[yuuu1993g]

多分スクラムの問題ではないけど、スクラム導入によって顕在化しやすい問題だとおもた

[inatax]

スクラムはプロジェクトの不確実性に立ち向かうためのものであって、開発速度の最大化が目的ではない、という理解だな

[renowan]

そもそも納期があるものはスクラムに向いてないのでは？

[sinoh]

っていうかきちんとできるエンジニアメンバーがちゃんと揃ってるなら いちいちスクラムがどうとかやらなくてもすんなり事が運んでいくんだよなぁ

[dot]

行間にトップダウンな雰囲気を感じる。タスクはアサインじゃなく基本サインアップにした方が良い。ボトムアップな雰囲気を作れたら、スクラムでも若手はちゃんと育つし、今のままならスクラム止めてもアレな気が。

[turanukimaru]

言われた事だけをやる人間や自分でタスクを立てない人はスクラムに向いていないが、新人新卒で言われないこともやったり適切にタスクを立てられる人は滅多にいない。新人教育には向かないのではないかとは思う。

[NacK]

スクラム開発してるのにMBOで個人の年間目標立てろと言われて無理じゃねって最近思いました

[natsutan]

わかる。若手がアサインされたタスク処理マンになっていて、横から見ていて大丈夫かな～って思ってる。

[ledsun]

わからない。スクラム関係なくチーム運営がヘタに思える。つまり、同じチームでウォーターフォール開発しても同じような問題が起きそうに思えます。

[paulownia]

ここで挙げている問題点を振り返りで挙げて検討せずネットに吐き出してるのチームビルドに失敗してる感ある。これに向かい合えるチーム作りが難しいのは分かる

[NOV1975]

初級レベルの成長過程のエンジニアがここに入っていくのけっこう大変だよな（教育コストが織り込まれるスクラム開発ってあんまりないから）。ひたすらマシーンみたいに一つのことをやる羽目になりがち。

[funky--46]

わかる...

[yoshitaro-yoyo]

スクラム関係ないペインだけど、これをスクラムのペインだと捉えている人が多いことが興味深い。スクラムの誤った解釈の普及・実践例という視点、組織の課題をスクラム運用上の課題と混同され易い問題という視点。

[notojin]

コード書かない奴が 、スクラム研修に参加して、スクラム開発とかスクラムマスターとか言い出して、アホかと思った

[tattyu]

属人性を排除し不確実なプロダクト制作の為の手法。成長は業務外で個人で頑張るしかない。異端は残念だけどチームから外れて貰うしか無い。

[sigwyg]

どっちかというと、これを反証としたブコメのほうが参考になる

[etah]

原理主義者が守破離を許さず攻撃的なので「スクラムしてます」と言いたくない

[ene0kcal]

書かれている数点は、アジャイル開発のよくある誤解そのもの。他の数点はアジャイル開発のデメリットそのもの。もう先人が初期の段階でまとめた静的知識の類なので勉強不足です。

[nemoba]

アジャイル開発してないイテレーション開発に、アジャイル開発は駄目だーって批判してる人多いよね。アジャイル開発がそもそも分かりづらいんだよね。タイムボックスの柔軟性と改善繰り返し開発なにょよ

[yogasa]

エンジニアなら自習するから問題ないよ

[dowson]

チームワークを重視し過ぎている、という感覚は確かにある。 全員等しく優秀で、コミュニケーションも高く、同じ目線で動いているなら機能するが、そうでないメンバーにとっては煩わしく感じられる時がある。

[delphinus35]

これは大前提を間違っている。スクラムは現状を把握するフレームワークであって何かを解決する訳ではない。問題が把握できてるのならそれをSM、PO、開発者全員で話し合って解決するべき（スクラム継続の是非を含む）

[clairvy]

心理的安全性とか、課題解決の話？課題があるなら解決に向かうのがいいと思うけど。やれない、ということだろうか。課題があるなら変えればいいと思うけど。

[t2y-1979]

いくつかは同意できるが、いくつかはスクラム関係なくプロジェクトマネジメントの問題。たしかにスクラムはチームの問題と言っておけば個人の責任回避ができて便利ではある

[santo]

確かに、スクラム開発って、フォード型のライン作業者みたいになるのかもな。

[georgew]

実際に個人の成果は可視化されないことが多いにも関わらず、会社の評価制度が個人の成果を重んじていたりする > ここに矛盾が凝縮。

[funa-1g]

なんとなくスクラムを始めると陥りがちな問題が並んでいるように思う。ハマったこともある。こういう問題のためにふりかえりとスクラムマスターの役割があるので、そこを機能させるのが大事。当然大変。

[toro-chan]

声が大きいってのは技術力があるってこと?それとも単にうるさくて技術力が低い?により違うと思うけど。技術力があるなら本来はうまくタスク割当してもいいとは思うが、なかなか両方は難しいかも

[kazukan]

アジャイルもスクラムもシルバーバレットじゃねーって言い始めてから何年立つんだろうな

[s-nanagi]

いくつかは典型的なアンチパターンに陥っているように見える（ゴリラとか）。スクラムやるならチームビルディングも同様に重要であることも忘れがち。チームや人の問題に帰結する部分もあるので大変だし難しい。

[tockri]

スクラムガイドにはモブプログラミングやれとも、なんでも合議で決めろとも、リファクタリングを優先しろとも書いてないよ。

[door-s-dev]

スクラムに限らないものが並んでてうーんて感じ。最後まで読んでないけど/スクラムがを主張したいなら他では発生しない理由が書いてないと説得力がね

[tanority]

“チーム内でのコミュニケーションが密になりがちなので。チーム内で浮いてしまうとそれだけでかなり居心地が悪くなります”面白い現象

[justgg]

わかるが、そういう副作用が働くことを前提にそれぞれの問題にどう対処するかを考えたほうが、全くアジャイルをしないよりマシだと思う。アジャイルなしのチームはリーダーのトップダウンになりがち。

[choota]

試行錯誤したり、俯瞰してプロダクト見たりするタイミングがウォーターフォールより少ないかもとは思う。//アジャイル宣言もプロフェッショナルとしての振る舞いの話ではないだし、そこに至る前の人には難しい。

[yasushicohi]

うーーん

[IzumiSy]

わからんでもないけど、反論記事を読みたい

[dentaro]

中身はあまり同意できないが、専門性を高めるスーパーマンにはなれない、という意味でタイトルには同意する。あと優秀なスクラムマスターがいないとキツイ