スクラム開発の失敗から学ぶ4つのケーススタディ

前回、スクラム開発の基礎についてお話しました。今回は、応用編ということで、実際の運用事例を取り上げていきます。スクラム開発を導入したはいいけど、なかなかうまく運用できていないというチームは多いのではないでしょうか。

20160314_1

その原因のひとつは、定められたルールの“意味”をメンバーが理解できていないこと。でも、それは裏を返すと、その意味を理解してさえいれば、成功確率はグンと上がるということでもあります。
ここでは、そのような「理解不足が原因で起こる失敗」にスポットを当て、その事例を

・なぜそれをやってはいけないのか?
・どのような考え方で改善すべきなのか?

というポイントから、分析していきます!

【失敗例①】プロダクトオーナーの要望により、もともと予定していたよりもスプリントで実施する作業をふやしてしまった

「プランニングミーティングを実施したあとに、プロダクトオーナーの鶴の一声で、急に計画が変更になった」というケースを経験したことがある方も多いのではないでしょうか?
「偉い人の意見だからしょうがない」とあきらめてしまいがちなこの運用方法、実は、なんとしても避ける必要があるのです。

■なぜそれをやってはいけないのか?

20160314_2

メンバーの混乱と不信感、無理な残業を生む。

 
立てていたスケジュールをすべて変更しなければならなくなるので、メンバーは混乱してしまいます。
ひどいときには「なにか計画しても、どうせ後からコロコロ変えられてしまうのだろうな…」という不信感が生まれてしまうことも。また新たな作業がふえると、工数がオーバーしてしまうので、無理な残業などで対処しなければならなくなります。

■どのような考え方で改善すべきなのか?

20160314_3

作業量を増やさないよう論理的にプロダクトオーナーを説得する。

 
こんなとき、立ち上がらなければいけないのがスクラムマスター。その役割において何よりも大切なのは、「開発メンバーを守ってあげる」ということです。

そのため、勇気を持って、スプリント中に作業量を増やさないようにする必要があります。その機能がユーザにとって必要であれば、次回以降のスプリントに含めるよう、プロダクトオーナーを説得するとよいでしょう。また、不要な機能なのであれば、思いきってスコープから落とすことも考えます。

交渉をする際には、決して感情的になるのではなく、
・現在、それぞれの開発メンバーはどのくらいのボリュームの仕事を抱えているか
・メンバーごとの開発スキル、スピードはどのくらいか

などの具体的な数字をあげ、「こうした理由で作業ボリュームがあふれてしまうため、追加の仕事をすることはできない」と論理的に伝えられるようにしましょう。

【失敗例②】バックログが適切な順番で優先順位づけされていない

プロダクトオーナーや開発メンバーがバックログを作ってみたのはいいものの、優先順位づけをすることが面倒くさくなり、順番がバラバラになっているケースもよく見かけます。
単に「順番がおかしいだけ」のように見えるこの事例、どうしてダメなのでしょうか。

■なぜそれをやってはいけないのか?

20160314_5

無駄な工数を発生させ、メンバーのモチベーションを下げる。

 
バックログが適切な順番になっていない場合、チームのメンバーは「このプロダクトがどこに向かっているのか」というビジョンが見えなくなってしまいます。その状態で開発をすすめてしまうと、それほど重要でない機能にやたらと時間をかけてしまったり、ひどい場合にはせっかく作った機能がボツになり、無駄な工数が発生してしまったりも。
そうなってしまうと、開発メンバーのモチベーションも下がってしまいますよね。

■どのような考え方で改善すべきなのか?

20160314_6

優先付けすることをルール付ける。

 
「優先順位づけをしていないのであれば、開発を進めてはいけない」というルールを設け、スクラム開発を運用していくべきです。また、バックログの優先順位づけをしたメンバーは、プランニングミーティングの際に、「どうしてこのような優先順位にしたか」を他のメンバーに説明してあげる必要があります。

【失敗例③】なるべく開発の時間をふやしたいので、レトロスペクティブミーティングをやらないようにした

「ミーティングに時間をかけると、そのぶん開発の工数がとれなくなる」と言わんばかりに、レトロスペクティブミーティングをやらなくなってしまうチームを見かけます。
しかしこの運用方法、短期的には成果が上がっても、後々とんでもないトラブルを生みだすのです。

■なぜそれをやってはいけないのか?

20160314_8

問題点が見えづらくなり、顕在化したときには最悪の状態に。

 
レトロスペクティブミーティングは、スクラムにおける単なる儀式ではなく、チームの良いところや改善すべきところなどを素直に話すことができる場。これが無くなってしまうと、メンバーは自分たちが抱える不満を話せなくなってしまい、感情をおさえこんでしまうようになります。あるときその感情が爆発し、チーム内の人間関係を悪化させてしまうことになりかねません。
また、改善すべき点の“見える化”ができていないため、いつまでたっても開発プロセスは良いものにならないのです。

■どのような考え方で改善すべきなのか?

Happy business team applauding together

ミーティングの意味と意義をメンバー全員に理解させる。

 
「メンバー同士が意見交換をしあえる場が必要だ」という意識を、メンバー全員が持つことが大事です。そのためには、スクラムマスターが普段から「なぜミーティングをするのか」ということの意味を、各メンバーが納得のいくように話してあげることが必要になります。
また、ミーティング中にメンバーからどのような意見が挙がってきても、それを「否定しないでしっかり聞く」ということも重要。こうすることで、自然と発言しやすい雰囲気がうまれ、メンバーが自主性を持ってミーティングに参加できるようになるからです。

【失敗例④】スプリントレビューで、動くプロダクトを使って成果を確認していない

スプリントレビューを開催するのは面倒だし、プロダクトを動かす準備をするのは時間がかかる。そう考えて、スプリントレビューを口頭や書類での報告ですませてしまうことがあります。
一見、作業効率化につながりそうなこの方法も、スクラム開発のプロセスを失敗させる原因です。

■なぜそれをやってはいけないのか?

20160314_11

プロダクトオーナーのビジョンに合っているか確認が出来ない。

 
スプリントレビューは単なる進捗報告ではなく、「プロダクトオーナーの考えていたビジョンに、プロダクトが沿っているか」を確認する場でもあります。そのためには、実際に動かしてみることで「ユーザがどのような体験をするのか(UX)」をチェックすることも欠かせません。
また、レビューでさまざまな入力パターンを試してみることで、アプリケーションのバグを早めの段階で発見できることもあります。

■どのような考え方で改善すべきなのか?

20160314_12

スプリントレビューのルールを徹底する”意識”を醸成する。

 
「スプリントレビューでは、アプリケーションを動かすことが必須条件であり、それ以外は許可しない」という方針を徹底します。そのためには、スプリントレビューの前に、担当メンバーに準備をうながしたり、もし準備ができていなかった場合には注意をしたりすることが必要になるのです。
そうすることで、チーム内に「スクラムプロセスを正しく運用するべきだ」という意識を醸造していきます。

すべてのスクラムプロセスに、意味はある

4つのケーススタディを“なぜいけないのか”、”どう解決すればよいのか”という視点で見てきました。すると、スクラム開発を実践するチームが重視すべき”2つの考え方”が見えてきます。

・各プロセスの必要性を理解する
・ルールは徹底して守る

この考え方をチームで醸成するために、スクラムマスターの役割のメンバーが説明を怠らないことも重要です。

「スクラム開発を導入すれば、必ずうまくいく」ということはありえません。それを成功させるには“正しい理解”と“実践”が必要になってきます。どうしてスクラム開発の各プロセスを実施する必要があるのか。その意味を学び、あなたのチームの文化をよりよいものに育てていきましょう!


最新情報はFacebook/Twitterをフォロー!


この記事を書いた人:ぞの

img_zono

Webアプリケーションエンジニアとして様々な現場に参画し、多種多様な言語を習得。エンジニアとしての強みは汎用性の高さと、メンバーとコミュニケーションを取り合いながら円滑に案件を進められること。趣味は音楽と将棋。Ruby愛好家。Twitter : @zono1009

関連する記事

facebook

案件情報や最新記事をお届けします。
ぜひチェックしてみてください。