※本記事は、Bardによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。
原文
Scrum sucks.. Breaking news: Scrum is bad. | by Matteo Bianchi | Oct, 2023 | Medium
意訳+要約
スクラムの批判
本記事は、スクラムというソフトウェア開発手法について、その批判的な意見をまとめたものである。著者は、スクラムの採用経験から、その欠点や問題点について指摘している。
重要な部分
- スクラムは、開発プロセスを短いサイクル（スプリント）に区切って、その都度成果物をリリースする手法である。
スクラムのメリットとして、以下の点が挙げられる。
- 開発プロセスの透明性と可視性が高まる
- 開発の進捗を把握しやすく、フィードバックが容易になる
- 開発チームのコミュニケーションとコラボレーションが促進される
しかし、スクラムには以下の欠点や問題点もある。
- 開発プロセスが複雑になり、非効率になる
- 開発の柔軟性が損なわれる
- タスクの細分化が進み、品質が低下する
- 開発チームの負担が大きくなる
具体的な批判点
開発プロセスの複雑さ
スクラムでは、スプリント計画、デイリースクラム、スプリントレビュー、スプリント振り返りなど、さまざまなプロセスが定められている。これらのプロセスをすべて実施するためには、多くの時間と労力が必要になる。また、プロセスが複雑なため、理解や運用が難しいという問題もある。開発の柔軟性の損失
スクラムでは、スプリント開始前に、スプリントゴールとスプリントバックログを定義する。しかし、開発の過程で、状況や要件が変化することもある。そのような場合、スプリントゴールやスプリントバックログを変更することは、容易ではない。タスクの細分化
スクラムでは、タスクを小さな単位に細分化して、スプリントバックログに登録する。しかし、タスクを細分化しすぎると、品質が低下する可能性がある。また、タスクの細分化は、開発チームの負担を増やす原因にもなる。開発チームの負担
スクラムでは、開発チームは、スプリント計画、デイリースクラム、スプリントレビュー、スプリント振り返りなど、さまざまなプロセスに参加しなければならない。また、タスクの細分化により、開発にかかる工数も増加する。そのため、開発チームの負担は大きくなる。
結論
スクラムは、ソフトウェア開発の効率化や品質向上に有効な手法である。しかし、その一方で、欠点や問題点もある。スクラムを採用する際には、これらの点について十分に理解した上で、適切に運用することが重要である。
プロの目線からのコメント
スクラムは、ソフトウェア開発における最もポピュラーな手法の一つである。しかし、その一方で、批判的な意見も少なくない。本記事は、スクラムの批判的な意見を、プロの目線でわかりやすくまとめたものである。
本記事で指摘されているように、スクラムには、開発プロセスの複雑さ、開発の柔軟性の損失、タスクの細分化、開発チームの負担といった問題点がある。これらの問題点を認識した上で、スクラムを適切に運用することが重要である。
Bardさんに聞いてみた
Ｑ：スクラムで開発するために必要な役割について教えてください
スクラムで開発するために必要な役割は、大きく分けて3つあります。
プロダクトオーナー
プロダクトオーナーは、プロダクトのビジョンと目標を定義し、プロダクトバックログを管理する役割を担います。プロダクトオーナーは、ビジネスの専門家であり、プロダクトの価値を理解し、それを実現するために必要な要件を定義する必要があります。また、プロダクトバックログを優先順位付けし、開発チームと協力して、プロダクトの開発を進めていきます。スクラムマスター
スクラムマスターは、スクラムのフレームワークを適用し、開発プロセスを円滑に進める役割を担います。スクラムマスターは、スクラムの原則やプロセスを理解し、開発チームにその理解を促進する必要があります。また、開発チームがスクラムを効果的に活用できるように、支援や指導を行います。開発チーム
開発チームは、プロダクトバックログに記載されたタスクを実行し、プロダクトを開発する役割を担います。開発チームは、ソフトウェア開発の専門家であり、要件を理解し、それを実現するための技術的な知識とスキルを有する必要があります。また、スクラムのプロセスを理解し、それに従って開発を進めていきます。
これらの役割は、それぞれが異なる役割と責任を担っています。スクラムを効果的に運用するためには、それぞれの役割の理解と連携が重要です。
プロダクトオーナーの役割
- プロダクトのビジョンと目標を定義する
- プロダクトバックログを管理する
- プロダクトバックログを優先順位付けする
- 開発チームと協力して、プロダクトの開発を進める
スクラムマスターの役割
- スクラムのフレームワークを適用する
- スクラムの原則やプロセスを理解させる
- 開発チームを支援・指導する
開発チームの役割
- プロダクトバックログに記載されたタスクを実行する
- 要件を理解し、それを実現する
- スクラムのプロセスを理解し、それに従って開発を進める
Ｑ：普通の開発に比べて、スクラムでの開発は、スキルの要求レベルが高い気がしますが、意見を聞かせてください
はい、その通りだと思います。スクラムでの開発は、以下の点において、普通の開発に比べて、スキルの要求レベルが高いと言えます。
コミュニケーションスキル
スクラムでは、プロダクトオーナー、スクラムマスター、開発チームの間で、頻繁にコミュニケーションを行う必要があります。そのため、コミュニケーションスキルは、スクラムでの開発において、非常に重要なスキルとなります。コラボレーションスキル
スクラムでは、プロダクトオーナー、スクラムマスター、開発チームが、チームとして協力して開発を進めていきます。そのため、コラボレーションスキルは、スクラムでの開発において、非常に重要なスキルとなります。自己管理スキル
スクラムでは、開発チームは、自己管理能力が求められます。タスクの見積もり、優先順位付け、実行、レビュー、振り返りなど、開発チームは、自分たちで責任を持って、開発プロセスを進めていくことになります。そのため、自己管理スキルは、スクラムでの開発において、非常に重要なスキルとなります。
具体的には、以下のスキルが求められます。
- 論理的思考力
- 問題解決力
- 柔軟性
- 適応力
- ストレス耐性
また、スクラムでは、短いサイクルで開発を繰り返していくことになります。そのため、短期間で成果を出すためのスキルも求められます。
もちろん、普通の開発でも、これらのスキルは求められます。しかし、スクラムでは、これらのスキルがより重要になると言えます。
スクラムを効果的に運用するためには、これらのスキルを身につけることが重要です。
Ｑ：スキルのばらつきがあると、スクラムをうまく運用できない印象がありますが、見解と要因・分析結果を聞かせてください
はい、スキルのばらつきがあると、スクラムをうまく運用できない印象は正しいと思います。その理由は、以下の3つが挙げられます。
タスクの見積もり・優先順位付けが難しい
スクラムでは、スプリント開始前に、スプリントゴールとスプリントバックログを定義します。このとき、タスクの見積もり・優先順位付けを行う必要があります。スキルのばらつきがあると、タスクの見積もり・優先順位付けが難しくなり、スプリントの成果物が不十分になる可能性があります。コミュニケーション・コラボレーションがうまくいかない
スクラムでは、プロダクトオーナー、スクラムマスター、開発チームの間で、頻繁にコミュニケーションを行う必要があります。また、開発チームは、チームとして協力して開発を進めていきます。スキルのばらつきがあると、コミュニケーション・コラボレーションがうまくいかず、開発プロセスが円滑に進まない可能性があります。タスクの完了が難しくなる
スクラムでは、スプリント期間内にタスクを完了することが求められます。スキルのばらつきがあると、タスクの完了が難しくなり、スプリントが延長される可能性があります。
具体的には、以下の要因がスキルのばらつきにつながります。
教育・トレーニングの不足
開発チームのメンバーが、スクラムの原則やプロセスを十分に理解していないと、スキルのばらつきが生じやすくなります。メンバーの経験の差
開発チームのメンバーの経験に差があると、スキルのばらつきが生じやすくなります。チームの文化や風土
チームの文化や風土が、スキルのばらつきを許容していないと、スキルのばらつきが問題視されにくくなります。
スキルのばらつきを解消するためには、以下の対策が考えられます。
教育・トレーニングの充実
開発チームのメンバーが、スクラムの原則やプロセスを十分に理解できるように、教育・トレーニングを充実させます。スキルの標準化
開発チームのスキルの標準化を図ります。例えば、必要なスキルを明確にし、スキルアップのための研修や教育を実施します。チームの文化や風土の醸成
チームの文化や風土を、スキルのばらつきを許容する方向に醸成します。例えば、メンバー間のコミュニケーションやコラボレーションを促進するような取り組みを行います。
スキルのばらつきを解消することは、スクラムを効果的に運用するために重要です
感想＋雑記
前から感じていたが、やっぱり、スクラムは思いつきで導入できるものではないと思うんだよね。。。
Bardさんと壁打ちしてたけど、風土の形成、能力の平坦化ができてないと、スクラムでやるべきことを阻害して、失敗すると思う。
そういったことを度外視して、強引にスクラムを導入しようとして失敗しているのが五万とある印象しかない。
人材移動が多いプロジェクトだと、スクラムはやり難いんじゃないかと感じている。
スクラム開発するなら、前段階として、風土の構築と能力の平坦化をした上で、徐々に移行していく形になる気がしている。
それがうまくイケば、正のスパイラルが働いて、いい感じに開発できそうだけど、そこにたどり着くまでが難しいんだよな。。。
少なくとも、毎週リリースがあるから、ストレス耐性が必須だろうな。
俺には無理だ。リリースのタイミングで、毎回、胃に穴が空きそうなくらいストレス感じてるから、耐えられない気がする。
