スクラム開発での失敗について

　今やスクラム開発の導入率は20%も越えようとしている現代ですが、一方そのうち半数は失敗してしまっているというデータもあります。その多くでは一体どんな原因で失敗しているのでしょうか。

　ウォータフォール型のプロジェクトでは、要件追加や仕様の考慮漏れなど、手戻りが発生することで炎上するケースが多々見られますが、アジャイル開発では基本的に柔軟に対応できるよう設計された開発手法ですので、こういった理由は少ないと考えられます。

　一方、柔軟に対応できるからこそ、厳格なルールがあるのです。特にスクラム開発では守らなければいけないことを遵守しないと、チームが壊れてしまいます。今回はそんな事例を10選としてまとめてみました。

　スクラム開発について「役割」、「作成物」、「会議体」などがよく分かっていない方は、まずは下記記事をご覧ください。

最近注目のスクラムによるアジャイル開発とは？メリットは何？

スクラム開発はユーザーのニーズが目まぐるしく変わる現代では、アジャイル開発とセットで用いられることが多い開発手法です。スクラムを導入することで強固で柔軟なチームを作り上げることが可能です。

techgrowup.net

アンチパターン１０選

1.　ロールが決められていない/兼任

　スクラム開発では、「プロダクトオーナー」、「スクラムマスター」、「開発メンバー」と厳格に役割が決められています。プロダクトオーナーはプロダクトに対しての責任を、スクラムマスターはスクラムプロセスへの責任を、開発メンバーはプロダクトを開発することへの責任があります。

　スクラム開発を始めるにあたり、これらの役割を明確に決めていないとスクラム開発を上手に回すことは出来ません。また、「スクラムマスター兼開発メンバー」など人のリソースが少ないときには、しばしば兼任されるケースもありますが、絶対にしてはいけません。　

　開発に慣れたチームメンバーであれば大丈夫と思うことがあるかもしれませんが、ロールはあくまで責任領域が違うので責任範囲の矛盾してしまう部分が出てきます。兼任していると、どちらの役割の責任を全うすべきか暗黙的に優先順位が付けられてしまうので、結果的に良いプロダクトが作れなくなってしまいます。

2.　プロジェクトのゴールとミッションが明確でない

　プロジェクトを始める前にはゴールとミッションを必ず決めておきましょう。「ゴール」とはプロジェクトを進めるにあたって、最終的に目指すプロダクトや製品のことです。具体的なデザインなどを決める必要はありませんが、プロジェクトはどんな課題を解決するのか、どんなソフトウェアを作るのかをメンバー全員で共通の認識を持つ必要があります。

　「ミッション」とはゴールに進んでいくにあたって、課せられている大きな課題のことで、例えば「3ヶ月後に必ず納品をしなければならない」であったり、「Bバグは必ずあってはならない」などの大きな基準が当たります。

　プロジェクトを始めるということは、何かしらの目的があって始まります。ゴールやミッションが決められていないにも関わらずスクラム開発を始めることは絶対にやめましょう。出来ればインセプションデッキにようなものを作ることをオススメします。

3.　プロダクトバックログが作れていない/更新できていない

　プロダクトバックログはスクラム開発の中で根幹とも言えるものです。プロダクトバックログに従ってチームは実現すべき要求を進めていき、プロダクトバックログで現在の進捗が見えるのです。基本的にプロダクトオーナーが中心となってバックログを作成していきますが、プロダクトバックログが作れていない状態は避けるようにしましょう。

　プロダクトバックログは本来どのメンバーが作成しても構わないものなので、プロダクトオーナーが作成していなければスクラムマスターなどが作成をしたり、プロダクトオーナーに時間を取ってもらえるように調整をかけることが必要です。

　また、プロダクトバックログは1度作ったら終わりではありません。ステークホルダーの要求は常に変化し、市場もまた変化していきます。プロジェクトのゴールに進むに連れて、より透明度の高い要求が入ってくる場合もあります。こうした状況に対応できるように、常にプロダクトバックログを見直し、更新し続けていくことが必要です。

4.　見積もりに時間を掛けすぎている

　ウォータフォール型の開発の場合は、全ての要求仕様が完成した後で、設計・実装・テストなどの見積もりをします。しかしスクラム開発（アジャイル）の場合では、要求が固まっていないことがベースにあるので、正確な見積もりをすることは困難です。それにも関わらず見積もりをすることに大きな時間を使っているのであれば見直しましょう。

　スクラム開発では見積もりをする際に、ストーリーポイントという見積もりをすることが一般的です。人間は絶対性より相対性の方が物事の基準を決めやすいので、基準となる作業を決めたら、それより「難しそう」「同じぐらい」「簡単そう」など比較をしていくことで見積もりがしやすくなります。

　見積もりに時間が掛かっている場合は、その分作業時間を減らしているということになりますので、プランニングポーカーなどを利用して、時間を掛けないようにしましょう。

5.　レビュー時にデモを実施しない

　スクラム開発ではスプリントレビューと言われる会議が存在します。そのスプリント期間中に開発したものをプロダクトオーナーやステークホルダーに見てもらう時間です。この際に開発メンバーから資料でのレビューや口頭での説明をしてしまうことは絶対に辞めましょう。

　ソフトウェアとは本来目に見えないため、共通認識が難しくイメージしづらいものです。スクラム開発でも同様で、実際にどんなものが作られているのかを目で見ない限り、完成しているのかどうか、どんなものになっているのかが分かりません。開発が進んでいないと、資料での説明をしたくなるという気持ちは分かりますが、アジャイル開発では常に動くソフトウェアを作ることが定義されています。

　動作するものでレビューが出来ないのであれば、スプリント中に実施する開発作業を減らしたり、そもそもプロダクトバックログやスプリントバックログ、スプリント計画の進め方を見直し、スプリントレビューでは必ず動くものをレビューできるようにしましょう。

6.　自己組織化しようとしない

　スクラム開発では、スクラムチームが自己組織化され、機能横断的になることが求められています。機能横断的とは1人の開発メンバーが特定の領域だけの仕事だけでなく、他のメンバーが困っていれば助けられるような存在になるということです。複数のメンバーが複数の領域をカバーできることで、チームが自律的に助け合い相互作用を生むことが出来ます。

　良くある失敗として、「この人は設計が得意だから設計だけ」「この人はフロントエンドが得意だからフロントエンドの実装だけ」のように特定の領域を作業するようにチームが決めてしまうことです。もしかしたら偉い人が勝手に決めてしまう可能性もあるかもしれません。

　しかし、それではチームとして成長することは出来ません。スクラム開発は個人単位の成果を測るものではなく、チーム全体を強くしていくためのものですので、全員がT字型人材を目指せるよう進めていきましょう。

7.　開発者の中に専門家がいる

　これはスクラム開発を初めてやってみようというチームに良くある失敗です。チームの中に開発の専門家（エキスパート）がいる場合です。例えばECサイトを開発しようといった際に、チームの中にバックエンド、インフラのエキスパートが居て、他のメンバーがそれらの知見がない場合はどうでしょうか。

　この場合に起こり得ることとして、他のメンバーが専門家の人を頼りにしてしまうことが想像できると思います。チームとして専門家がいる場合、頼ってしまうというのは人間の普通の心情です。このような場合には専門家はスクラムチームからは外してしまい、アドバイザーとしてチーム外に居てもらうようにしましょう。

　システム開発では往々にして、炎上プロジェクトにスーパースターを投入して、沈下させるといった人海戦術がありますが、スクラム開発ではそもそもスーパースターをチームの中に入れることは結果的にチームの生産性を上げることに繋がりません。しかし専門家が居ないと進められないという場合もあるでしょう。

　特に大きなプロジェクトであればあるほど、専門家は必要になってきますので、専門家たちにいつでもアドバイスを受けられるような体制をスクラムチーム外で作っておくことがベストプラクティスです。

8.　タイムボックスを変更する

　スクラム開発ではタイムボックスを守ることは絶対です。スプリント期間の中で開発・テスト・レビューなどを必ず実行する必要があり、例えば、「後1日あればレビューが上手くいく」のような場合に、スプリントレビューを1日ずらすことを検討したくなるでしょう。

　しかしスクラム開発をする場合は、スプリント内のイベント（会議）の時間をずらすことはしてはいけません。スクラム開発でタイムボックスを利用する理由の大きな点としては、開発速度を図れるということです。スプリント期間内にレビューが上手くいかなかったのであれば、スプリント計画が失敗していたということになりますので、そのスプリント期間ではレビューは出来るところまで実施し、次のスプリント計画で綿密に見直しましょう。

　もちろんデイリースクラムの時間などは、チームメンバーの状況に合わせて1日の中の時間で、朝から夜に変更するのような柔軟性は必要ですので、大事なのは目的をしっかりと理解することです。

9.　ベロシティを無理に上げようとする

　スクラム開発をすることは開発速度をあげることに繋がるわけではありません。ベロシティとは開発速度のことで、作業をストーリーポイントで見積もれば、1スプリント中にどのくらいのストーリーポイントを消化できるか測ることができるようになります。これがベロシティです。

　納期やリリース日が迫ってくるとベロシティを上げたくなることもあるでしょう。「一時的に皆が残業をすれば」「一時的に人を増やせば」など解決しそうな案はたくさん出てきます。しかしこれらは応急処置に過ぎません。スクラムチームとは安定的にベロシティを維持・成長させていき、リリース日までのスケジュールを正確に見積もることが大切なのです。

　一時的に残業を増やせばベロシティは上がるかもしれませんが、それは本来のチームのベロシティではありませんので、そもそもベロシティを上げなければリリースが間に合わないという状態を作ってしまうことが間違いなのです。もちろん絶対に残業がいけないという意味ではありませんが、一度そういう状況を作ってしまったとしたら、次のスプリント計画やスケジュールを決める際には必ず見直しが必要です。

　また、一時的に人を増やしてもスクラムチームのベロシティは大抵あがりません。スクラムチームは今までやってきたメンバー同士の相互作用や経験があって初めてベロシティになるのです。単に人を増やしても逆にその人への教育コストなどが発生し、結果的にベロシティが下がることに繋がりますので、気をつけましょう。

10.　問題を早期に解決しようとしない

　どんな開発でも大きな問題から小さな問題まで発生します。大きな問題に対してはすぐに対処する気持ちになると思いますが、小さな問題を見過ごしてはいけません。小さな問題はいずれ大きな問題となり、プロジェクトの終盤になって炎上の原因となるのです。

　基本的にはスクラムマスターがリードしてチームの問題を解消していくことが求められますが、もしスクラムマスタがーが積極的に動いていないようであればチームメンバーから働きかけてみるものよいでしょう。また、問題を発見したら報告・共有し迅速に解決するチーム作りをしましょう。

まとめ

　スクラム開発はしっかり進めることができれば強力なチームになることは間違いないですが、失敗パターンで行っている場合はウォーターフォール型より上手くいかない場合が想定されますので、ぜひ気をつけてみましょう。

スクラム開発をもっと知りたい方は、下記のような本を読んでみてください！