13
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【スクラム】Q.スクラムはミーティングが多く、非効率ではないのか

Posted at

開発チームからの質問、というか不満。
※スクラムの実務経験がない個人の私見です

質問内容

スクラムはミーティング(会議・打合せ)が多く、スクラムイベントだけでスプリントの20%前後を割く。
ピラミッド型(PM・開発メンバー)の体制であれば、開発メンバーは割り当てられたタスクの遂行に集中できるため、その方が生産性が高いのではないか。

私の回答

自信を持って回答できないので、先輩SM方のご意見を伺いたい・・・が、一旦自分なりの考えを。

開発は生産性が全てではない

スクラムでももちろん生産性・効率は意識しますが、生産性を最優先に考えられたフレームワークではありません。

スクラムのメリット・強みは、短いサイクルで改善・課題解決できることだったり、強い人に極端に負荷が偏るのを防ぐことだったり、スキルの平準化を目指して一人が欠けた時のリスクを抑えることだったり、いろいろあります。

生産性だけを見ればスクラムではない形の方が勝るかもしれません。

開発チームの仕事は開発だけではない

スクラムにはPMがいません。
かといってPMがやるべきタスク(各種管理業務、顧客折衝、チームビルディング・・・)がなくなるわけではありません。
それらタスクが各ロールに分散されるのです。
(スプリント中の)進捗や品質の管理は開発チームが、顧客折衝・要件調整などはPOが、課題管理・リスク管理などはSMが。

開発チームが開発以外にもやらないといけないのですから、当然開発自体に割ける工数は減ります。
PMは多忙になりがちで、PMがボトルネックになって作業が進まないケースがよくあるかと思いますが、スクラムではそれをPOだったり開発チームに分散されるので、PJ自体の進捗が滞るリスクが減ります。
結果的に生産性で大きく劣るということはないような気がします。

何よりスクラムは楽しい

ピラミッド型だと、極論、与えられたタスクをこなしていれば良いので、一開発メンバーとしては碌にコミュニケーションを取らなくても、成果を上げられるかもしれません。
黙々と職人のような働き方をしたい人はそれでもいいかも知れませんが、仲間たちとチームの成長を実感しながら目標を達成していくのって、楽しくないですか?

決して責任感なくダラダラ仕事をするわけではなく、みんながチームの目標・活動に責任を持って良いプロダクト・システムを目指して一体感を持ってやれれば、成し遂げた時の達成感もひとしおでしょう。
実務経験ないので知りませんが。

13
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
13
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?