はじめに
こんにちは、H×Hのセンリツ大好きエンジニアです。（同担OKです😉）
今回は自分が業務で行なっているスクラム開発について、フィットするPJとしないPJは何だろうと考えたものをまとめたものです。
ポエムなので一意見として見ていただけると幸いです！
（ご意見あればコメントお願いします🙇）
スクラム開発とは？
スクラム開発はアジャイル開発から派生した手法であり、5~10人でスクラムチームを組み各役割同士がコミュニケーションを密に行う開発形態です。
プロダクトオーナー、スクラムマスター、ディベロッパーの3つの役割があり、全ての役割が積極的なカイゼンを行うことでプロダクトの品質を上げることを目的としています。
（カタカナのカイゼンは、悪いものを良いものにする意味だけでなく、良いものをより良いものにするという意味が込められているようです。🥹）
だいたい以下のようなメリットがあるかと思います。
- 工数の見積もりが正確になっていく
- チームビルディングが行いやすい
- ユーザのニーズを反映しやすい
- 開発効率が上がる（大きな手戻りが少なくなる）
- 問題の早期発見が可能
向いていると思うPJの特徴
上記のメリットから、個人的には以下のように考えています。
- 同じメンバーで開発から保守まで長く続けるPJ
- ガッチリと要件が固まっていないPJ
- 流動的にニーズや優先度が変化するPJ
- リリースまでの日程がガチガチに決められていないPJ
一つづつ考察していきます。
同じメンバーで開発から保守まで長く続けるPJ
個人的には最も合いそうだと感じています。
スクラムは同じメンバーでやればやるほど醸成するため、どんどん開発がスムーズになります。
また、コミュニケーションの障壁が取り除かれていくため、メンバーがカイゼン意識を持っている場合はどんどん良質なプロダクトへと進んでいくんじゃ無いかなと思います。
逆に肌感が合わない方や他のことにチャレンジしたい方が抜けにくい環境になってしまう可能性も孕んでいますが、そこはチームビルディング次第ということで。。。😇
ただし、メンバーがカイゼン意識を持ち、ステークホルダーが求めるものを生産し続けないと巷で囁かれているゾンビスクラムになるので要注意
ガッチリと要件が固まっていないPJ
スクラムだとチーム全員がそれぞれの立場関係無しにアイデアを出し合うことで要件を固めていく、という初期フェーズの行動がマッチしているので良いのでは無いかなと思いました。
初期フェーズという事もあり、チームの雰囲気次第にはなってしまうのですが、やはりチームが一丸となって同じプロダクトを作るために要件を決めていくという手法はスクラムでの良い部分です。
そもそも要件が固められていれば、もうウォーターフォールで作りきっちゃった方が早いのでは？という考え方です。🤫
チームの方向性がバラバラ＆言い出しにくい雰囲気だとあまりスクラムをやる価値が無いので、初期は特にチームビルディングが大事
流動的にニーズや優先度が変化するPJ
スクラムは短いスパン（1~3週間程度）で目的を決めて開発を行うため、変化に対して柔軟に対応できます。
そのため、ステークホルダーの要求でタスクの優先順位が変わりやすいPJやユーザのニーズが変化しやすいPJだとスクラムという手法が合うのかなと思います。
（ニーズが変化しやすいものは沢山当てはまりそうですが、そこは深く突っ込まないでください🥹）
特に、スクラムは価値を出し続けないといけない風潮もあるようですので、そういった要求にすぐ対応する必要のあるPJだと真価を発揮しやすいのでは無いでしょうか。
変化には柔軟だが大局的な目的を見失ってあちこち彷徨わないよう、目的の確認は随時行う必要あり
リリースまでの日程がガチガチに決められていないPJ
これはもう当然では無いかなと思います。
「何月にリリースだ！🥸」と言われている案件では、スクラムをやる価値はほぼ無いんじゃ無いでしょうか。
スクラムは、カイゼンするために開発以外にも時間を使います。
そのため、日程がガッチリ固まっているPJでは品質より納期がファクターとして重要視されると思いますので、ウォーターフォールで一気に作りきってしまった方が良いです。
繰り返しますがこれに関しては相性の良いPJというより、最低条件なのでは？と考えています。
スクラムは開発目的でなく手法なので、合わないPJは潔く引こう
おわりに
スクラムについて個人的に考えてることをまとめてみました。
ポエムとして、気楽に読んでいただければと思います。🤯
ここまで読んでいただきありがとうございました。
以上、センリツでした🤓