83
43

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【スクラム】スクラム開発はどういう開発に適しているのか

Last updated at Posted at 2024-06-03

スクラムって結構PJを選ぶフレームワークだと思うんですよね。
どういう開発に向いてそうかな〜、というのを考えてみます。
※スクラムの実務経験がない個人の私見です

スクラムってこういうところ微妙だよね

生産性・効率

スクラムって開発チームでもスプリントの20%はイベントに費やされて、そもそも開発作業に取れる時間が少なくなりますよね。
自分が携わらないかもしれない機能(PBI)についてもリファインメントや見積もりをしないといけないし、開発や要件定義をするわけでもないスクラムマスターという人にも工数・コストがかかっちゃう。

かけた工数・時間に対してどれだけの機能を作れたか、みたいな生産性・効率という観点において決して優れた手法ではないように思います。

納期が決まっていてずらせないものは対応しづらい

スクラムでも一応見積もりはするし全く無計画でプロジェクトが進むわけではありませんが、見積もりは不正確なもの・ズレるものという前提ですし、なんだったら見積もりなんてしないほうがいい、という論調もあるぐらいです。
スクラムにおいて確実なのは実績だけであり、未来のことは不確実で揺蕩っているものなので(なんだか量子力学のような表現になりましたが)、常に変化に柔軟に適応して行って、より良い未来を目指そうね、ってスタンスだと思っています。
なので、納期やそれまでに実現させるべきことが明確に決まっていて調整の余地がないような案件には適さないように思います。

スクラムチーム結局維持できない

スクラムはPJごとにチームを解散するのではなく、同じスクラムチームで次々PJをこなしていくのが望ましいとされます。
スクラムはチームとしてスプリント回すごとに成熟していこうぜ、というフレームワークなので、短期PJには向いておらず、中長期PJ向きです。
せっかくチームとして良くなってきたところでPJ終わって解散、だとあまりに勿体ありません。
が、現実はPJ半ばで要員の増減もあるし、PJ終わればメンバーは散り散りになることも往々にしてあるでしょう。

プロダクトオーナー、ステークホルダー軽視されがち

スクラムってまだまだ日本だと主流ではないと思うので、会社や顧客からの理解を得られず、プロダクトオーナーやステークホルダーについて軽視されがちな気がします。
プロダクトオーナーとしてしっかり工数を確保してもらえなかったり、ステークホルダーが全然レビューに参加してくれなかったり。

ていうかクライアントワークに向いてなくない?

顧客側の担当者といえども、もともとやってる業務もあり、システム開発の担当になったからとしてそれに専念できる人はなかなかいないと思います。
スクラムだと顧客側でプロダクトオーナーを立ててほしいし、その人にはPBI作成や市場の調査、優先度の検討などをしてほしいので、しっかり時間を取ってもらいたいんですが、なかなかそうはいかず。

スクラム、こういうとこいいよね

スキルアップ

チケット渡されてやっといて、じゃなくみんなでコミュニケーションとりながら1つずつPBIを終わらせていくので、自分が知見のない部分が補われていって、広くスキルアップできるように思います。
また、レビューで顧客折衝やレトロで課題管理・改善意識向上みたいな、マネジメントスキル・ビジネススキルも培われそうです。

成果・効果にコミット

スクラムは生産性ではなく、成果・効果を追い求めていきます。
「検索機能を使いやすくする」ことが目的なのではなく、「1ユーザー当たりの検索機能利用数増加」を目指します。
極論、1スプリントで1機能しか実装できなかったとしても、それによりユーザーやサービスにめちゃくちゃいい影響(登録者数が爆増するとか解約数が激減するとか売上がめっちゃ伸びるとか)を与えられればそのスプリントは大成功なわけです。
それはチームがみんなでサービス・顧客への効果を意識して意見し合うから出せるのです。

働きやすさ、楽しさ

スクラムではチームの一体感が大事です。
スクラムマスターがチームビルディングも意識して色々アドバイスしてくれます。
馴れ合い・ぬるい環境、という意味ではなく、心理的安全性が高く意見しやすい、仲間感のあるチームを目指します。
ネガティブなことを我慢し続けることも良しとしませんし、そういうチームでやる仕事って楽しそうですよね。

開発だけでなく様々な業務に応用できる

組織運営や採用・営業なんかでもスクラムでやれるかもしれません。
こういう、終わりがなく常に改善していくことが大切な取り組みには非常に効果を発揮するものと思います。

結局スクラムってどういう開発に適してんのよ

自社サービス開発

そんなわけで結局、ずらせない納期がなかったり、実装内容も都度柔軟に変更できたり、サービス・顧客への効果を追い求めたり、PO・SMの用意のしやすさとか考えると、やはり自社サービス開発向けなのかなと思います。
お客さんが協力的であれば、準委任で体制組ませてくれるクライアントワークでも全然いいと思いますが、開発チームからすると自社のサービスではないので、そこまで熱意を持ってコミットできるか疑問ですし、クライアントからするとかけた金額の割に機能的に大きな変化がないと不安が大きくなると思うので難しそうだなぁと感じます。

83
43
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
83
43

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?