1年間スクラム開発を運営して実践した時に感じたアンチパターン・感想

こんにちは。
僕はエンジニアチームで開発する上でスクラム開発をしてリーダーとして仕事をしていました。
今回はそのときに感じたこと、特に失敗したことをここに書いていこうと思います。

また、本記事は「SCRUM THE BOOT CAMP」を読み勉強しつつ振り返りながら書いています。
ストーリー仕立てで読みやすく、スクラム開発について理解しやすい良書なのでぜひ。

Contents

一人が多くの複数の役割を兼任するのはダメ
SP（ストーリーポイント）の割り振りが難しい
スクラム開発はチームとして成熟していることが前提
おわり

一人が多くの複数の役割を兼任するのはダメ

僕は、「開発メンバー」「PO」「スクラムマスター」のポジションを兼任していました。要するに何でも屋のリーダーとして仕事をしていました。

ユーザーとコミュニケーションしつつ、スクラムイベントの運営をし、タスクを切り、時には開発をする。

ロールによってそれぞれの役割があると思いますが、それぞれ違う目的を持って行動しています。

開発メンバー: 保守性が高いコードを書きたい。
PO: ユーザーに使い勝手のいいシステムを作りたい。
スクラムマスター: 健全なチーム運営をしたい。

そんな中で複数の役割をもつ個人が存在したときに意思決定が曖昧になってしまう。
実際僕はリファクタリングをすべき（開発メンバーとしてのwill）なのか、システム改修を優先すべきか（POとしてのwill）の判断が迫られた時に心理的に辛い思いをした様に思う。

そんな中でこうすればよかったといった点を挙げるのであれば

チケットを切る時に何が目的なのか誰のためのチケットなのかを明確にすること

が重要だと考えます。
優先順位を考える上で「何が目的なのか」を考えることをすっ飛ばすと考えがまとまらなくなってしまう。

ただ、基本的には1ロール1人が適切だと思いました。

SP（ストーリーポイント）の割り振りが難しい

SPの決め方、これが一番スクラム開発で難しく肝の部分だと思います。

そもそもSPとはなんなのか。chatGPTに聞いてみます。

スクラム開発でのストーリーポイントについて300文字以内で内容を説明してください。

ストーリーポイントは、スクラム開発でユーザーストーリーの大きさを相対的に見積もるための指標です。
作業にかかる時間ではなく、作業量・複雑さ・不確実性を考慮してポイントを付与します。
例えば「この機能はあの機能の約2倍大変だからポイントも2倍にしよう」といった形です。チームはスプリントごとに消化できた合計ポイント（ベロシティ）を把握することで、今後どのくらいの作業を計画に組み込めるか予測でき、進捗管理や計画立案を現実的に行えます。

ありがとうchatGPT。
でも多分スクラム開発をしたことがない人はこの文章を読んでもイメージできないと思います。
簡単にいえば「チケットの難易度」なんですが、どのように値を決めるのか曖昧なんですよね。

そのためそもそもSPの定義について認識を合わせるところからスクラム開発は始まります。

このSPを決めるのが難しい