【スクラム開発】よくあるスクラム導入時のつまづき例

スクラムメンバーとして開発を３年半、スクラムマスターとして１年と少し経験し、プロダクトオーナー研修とスクラムマスター研修で資格も取れたことで、「スクラムを導入しよう！本で学習した！さあやってみよう！」とした時に失敗しがちなことに色々気づけだしました。

それらのまとめをしてみたいと思います。

まず前提として、下記とします

・ウォーターフォールの経験がある
・スクラム導入がはじめてのメンバーばかり
・スクラムの本は読んだ

ちょうどスクラムがいいという噂を聞いて導入したばかりのチームに多いパターンかと思います。
私もはじめは上記な感じでした。

失敗例

スクラムの型にウォーターフォールのノウハウを当てはめてしまう。
とりあえず本で学んだやり方で下記を実施してみる

・デイリースクラム（朝会）を開催
・スプリントを１，２週間でやってみる
・スプリントプランニングを開催
・スプリントレビュー・レトロスペクティブの実施
・仕様書はあまりつくらない
・タスクをストーリー化してみる
・プロダクトオーナー（PO）とスクラムマスター（SM）を立ててみる

ここまではよいのですが、ウォーターフォールの経験から以下のことをやりがち

・PMがPOかSMをやったり役割が曖昧だったりごちゃまぜだったりする。
・仕様をPMが決める
・仕様はチームが決めるものですが、PMやPLが決めがち
・チームが指示待ち。仕様を自分たちで決めない。
・チームが率先して動くべきですが、POやSMにPMの動きを期待して率先して動かない、またはPMの権力があり動けない。
・仕様変更が受け入れられない
・スプリント毎にアウトプットしてフィードバックを受けるということを繰り返すはずが、ウォーターウォール感覚になれすぎて、フィードバックを貰う単位の規模が大きすぎて、その結果変更内容が大きな仕様変更と受け取り、仕様変更は受け入れられないという心理になりがち。

気づくとスクラムの型だけ利用した従来どおりのやり方になって、「スクラムの良い所はなにか？」がわからなくなってきて「従来どおりのやり方でいいのでないか？」と疑問に感じてきます。

なぜスプリントを切っているのか？スプリントプランニングやレトロスペクティブの利点などを実感できないままやっぱり元に戻そうという事になってしまいがちです。

役割ごとの問題

POの問題
プロダクトの責任者がすべきだが、その方がお客様でスクラムの知らなかったり、PMがPO代理として役割を担い存在が曖昧になる。
エピック・ストーリーの作成や優先順位に責任を持つ必要があるが、実施できておらずバックログが整っていないことになりがち。結果として何が重要かが曖昧になる。

SMの問題
チームをうまく回す役割だが、ウォーターフォールに慣れたPMの方がなった場合はPMの役割を演じてしまうことでSMとして動かねばならいことと相反してしまいがち。
仕様をなぜかSMが決める場合も。チームの管理者的に動いてしまうことはよろしくなくチームのサポートをする役回りとして動くべき。

チームの問題
PMの影響下で受け身になってしまう。
仕様はチームが決めるはずなのにPOやSMに任せてしまう。
「仕様が決まってない」「仕様が変更された」など、本来は自分たちが率先して決める部分で不満を貯めてしまう場合も。
仕様はチームが率先して決めることでPMに集中していた部分を分散すべき。

スクラムの誤解・認識違い

仕様書は作らなくてよいという誤解
仕様書が必要な場合は作る必要はある。不要な場合は作らなくてよい。無駄を省くことが大切なだけですが、スクラム本などの都合のよい部分（楽そうな部分）だけをピックアップしがち。

仕様は変更してもよいという誤解
仕様は変更してもよいのではなくて、仕様変更が起こることは、ニーズが変わって要求が変更されたりすること。
仕様が変更になったのではなくて、新しい改善案が出てきたと捉えるとよいと思います。
提供できる価値にともなって優先順位順に改善を繰り返すことが重要です。

ポイント見積もりを時間で実施してしまう
ポイントの見積もりを個々人ができる時間で計算してしまう。
何人日でできるかなどで出してしまうことでスケジュールを組んでしまいリリース日が予想と大きく異なってしまうことがある。

ポイントを相対見積もりではなく絶対見積もりで実施してしまう
時間にも該当するが、時間をやめた場合も相対見積もりができない。また相対見積もりの利点がまだ実感できていない。

ポイント見積もりを一人で行ってしまう
チーム全体でプランニングポーカーなどをすべきところを担当者が時間で見積もってしまう。
そして個々人のスキルによる見積もりになりポイントがバラバラになってしまう。
ベテランメンバーがやればこのポイントだが、新メンバーだとポイントが多くなるなどの問題が起こる。

ポイントをノルマだと思ってしまう
ポイントはベロシティーを測る上で重要だが、ポイントを見積もる時にノルマだと思ってしまい、自分だったら少なくできるように見積もってしまう。
「この簡単なのがそんなにポイントかかるの？」とか言われないか心配して少なく見積もってしまう。

ベロシティーを測らない
ポイント見積もりが間違っているのでベロシティーが正しく計測できない。
そしてベロシティーから実装完了目安を立てない、立てれない。

エピックやストーリーなどの作り方が曖昧
ユーザー視点で記載することを試してみるが、うまくいかず結局実装視点の記載になる。

エピックやストーリーの洗い出しができていない
はじめから分かっていたことでも、あとから作られてきてしまう。

エピックやストーリーの優先順位が決められていない
すべて重要やどんどんあとから作られるチケットが並んでいるだけで優先順位が適正でない。

スプリントプランニングができていない
PMが指示を出す場と化してしまっていたりしている。
みんなで認識合わせを行い取り込むことが重要

スプリントレビューでチームが主役ではない
その場で見せるのはお客さんにPMが見せたりして実装者が見せたりしない。
実装者がデモを行わないとPMを介してフィードバックを受けることになり適切なフィードバックが伝わらないため実装者がデモを行うべき。

スプリントレビューを実施できていなかったりする
全体が完成してないからデモができないと思っている。見せてフィードバックを受けることが重要。

チケットの完了条件が曖昧
完了条件が曖昧なためクローズできなかったり、次に繋げられなかったりする。

ストーリーやタスクの粒度が大きすぎる
チケットは小さくすぐに取りかかれてすぐに終わる粒度にすべきだが、大きめのチケットを作ってしまい、１スプリントでは終わらず、なかなかクローズできない。１スプリント以内で終わるようにチケットを細分化する必要がある。

スプリント レトロスペクティブを毎スプリントごとに実施していない
振り返りをスプリントごとに行わないため、改善タイミングを逃してしまっている。小さく改善を繰り返すことが重要。

まとめ

色々書きましたが、ずっとやっていても常に改善していくことが起こるので、振り返りを行い改善を続けていくことが重要なのだと感じています。

最初から全部できる必要もなければ、最初からすべてをやる必要もない。
一つづつ取り組んでうまく行けば次のことに取り組む。
これがチームを改善していく上でとても重要なのだと感じています。

丁度自分が所属しているチームもスプリント１００を超えましたが、スプリントごとに振り返りを必ず行っているので何かしらの問題があるのが常々感じられます。
それを繰り返していくことで、チームメンバー全員が能動的に動くようになっており、本当によいチームだなと感じることが多いです。

今回はつまづきポイントを書いてみましたが、実はつまづくのも大切だと思っています。
そこが改善ポイントにもなるので、みんなで乗り越えて行くのがよいと思っています。