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

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

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

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

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

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

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

techgrowup.net

アンチパターン１０選

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

なぜスクラムによるアジャイル開発が注目されているの？

　スクラム開発はソフトウェア開発の現場でよく利用される方法で、アジャイル開発とセット利用されることが多いです。昨今のソフトウェア産業では、ユーザーのニーズの移り変わりが早く、開発している途中でクライアントからの要求が変わったり、スピーディーにリリースすることが求められています。

　そのため、プロジェクト開始時に決定されていない事が多く、不確実性が高いプロジェクトが増えています。このような場合に従来の開発手法であるウォータフォール型の開発を適用することは不可能です。

　ウォーターフォール型では要件定義・基本設計・詳細設計・実装（プログラミング）・単体テスト・結合テスト・システムテストを経て、リリースの流れで進めますが、詳細設計の最中に要件が変わった場合、「要件定義」に戻らなければならなくなるからです。

　こんなときに、アジャイル/スクラム開発の手法を使うこと、クライアント（ユーザー）のニーズを常に更新しながら開発を進めていくことが出来るのです。

スクラム開発とは

　スクラム開発とは、１９９０年代にジェフ・サザーランド氏とケン・シュエイバー氏という方達が中心になって作られたもので、Scrumの名前は日本人である野中郁次郎氏と竹内弘高氏によって提唱されたものです。

　スクラム開発では、プロジェクトのゴール（プロダクトを作りあげること等）に向けて、チームが一丸となって取り組むべき作業・会議・成果物を定めます。具体的には以下のような役割と作成物、会議を進める必要があります。

スクラム開発で作る物

プロダクト/製品

　プロジェクトのゴールは、ユーザーに対して売上をあげられるような製品や、事務作業等を簡素化できるようなソフトウェアなどを開発していくことです。スクラム開発でも同様で、最終的なプロジェクトの目的に対して、プロダクト/製品を作成（開発）していきます。

プロダクトバックログ

　プロダクトバックログとは、プロダクト/製品を開発するにあたって、どの優先度で要求を実現していくかを視覚化したものです。各要求では必ず優先度が重複しない形になっている必要があり、プロダクトバックログを見れば、どの要求から手を付ければよいか分かるようになっていることが大切です。

スプリントバックログ

　スプリントバックログとは、プロダクトバックログを具体的にタスク（作業）として分割したものです。プロダクトバックログはプロダクトオーナー（後述）が作成するものですが、スプリントバックログは開発メンバー（後述）が作成するものになります。

スクラム開発での役割

プロダクトオーナー

　プロダクトオーナーとしての大きな役割は、プロダクトに対して最終的な決定権限を持っていることです。同時にプロダクトに対して権限を持つということは、プロダクトバックログに対しても最終決定権元を持っています。

　スクラム開発を始めるにあたって、プロダクトオーナーは必ず１人必要で、以下の役割を持っています。

　もちろん、常にプロダクトバックログを１人で更新したり、ステークホルダーの説明をプロダクトオーナのみがする必要はありませんが、最終的な権限と責任を持っているのはプロダクトオーナーです。

スクラムマスター

　スクラムマスターとは、スクラム開発の手法を開発メンバーに理解させたり、会議の進行を行ったりする、スクラム開発のリード役と言えるでしょう。役割としてはスクラムを円滑に回していくための全ての作業を担っており、スクラム開発における指南役となります。

　プロジェクト立ち上げ期では、スクラム開発が浸透していない場合が多々あるため、スクラム開発を行うための準備を行ったり、スプリント期間中にはプロダクトバックログの書き方、スプリント計画（後述）の作り方などスクラムに対して様々な事を積極的に行う必要があります。

　一方、スクラムマスターの最終的な目標としては、プロダクト/製品を作り上げるだけでなく、スクラムマスター自身がいなくてもチームが運営されることが役割として存在します。なぜならスクラムマスターはスクラム開発の指南役ですので、チームが成熟すればスクラムマスターは必要なくなるからです。（少しさびしいですが、、）

　プロダクトオーナーと違って明確な作業だけでなく、抽象的な仕事を自ら生み出して率先して行っていく力が求められますので、自発的にチームを良くしたいという方が向いていると思います。

開発メンバー

　開発メンバーはその名の通り、実際にプロダクト/製品を開発するメンバーです。通常３名から９名で構成されることが多く、３名より少ない場合は属人化が避けられず、９名以上になる場合はコミュニケーションによる時間が掛かりすぎてしまうので、３名から９名の間に抑えることが必要です。

　開発メンバーはプロダクトを開発するために、要求分析、システム設計、実装（プログラミング）、テストを行う必要があり、これらは特定のチームとして機能させるべきではありません。例えば８名の開発メンバーがいる場合に、「特定の２名がテスト担当」のように振り分けるのではなく、全員がプロダクトを開発するための工程をできるようにするのが理想です。

　もちろん技術スキル・知識の差はありますが、プロジェクトチームとして機能横断的なチームを作り上げることが強固で柔軟なチームを作ることに繋がりますので、できる限り各メンバーが複数の作業をできるようなチーム作りをする必要があります。

スクラム開発の会議体

スプリントとは

　会議体を知る前にスプリントについて知っておく必要があります。スクラム開発におけるスプリントとは、固定された期間を予め決めておき、スプリント期間中に計画、設計、開発、テストなどのプロダクトをリリースするための判断に必要な全ての事を行います。また、スプリントの期間はプロジェクトが始まった後に変更してはいけません。

　例えば、２週間スプリントのプロジェクトの場合、２週間ごとにプロダクトバックログにある作業を行っていき、スプリントの最終日にはリリース判断ができるプロダクトが出来ている事が必要です。

　大体多くの現場では、スプリント期間は１週間から４週間に設定されていることが多く、短すぎると作業を終えられなくなり、長すぎるとユーザーからの要求変更に対応することができなくなってしまうので、基本的には１ヶ月以内に定めましょう。

バックログリファインメント

　バックログリファインメントでは、バックログをREADY(着手可能）な状態に持っていく会議です。通常バックログはプロダクトオーナーが作成しただけでは不十分で、開発者たちに作業ができる状態まで落とし込んで貰う必要があります。

　また、バックログが少ない場合などにも、どんなバックログが必要かを議論し合う場としてりようすることもよいでしょう。

デイリースクラム

　デイリースクラムでは、スプリント期間中毎日行われるもので、コロナ下ではテレビ会議などが主流になってきましたが、基本的には毎日、同じ場所、同じ時間で状況を確認するための会議です。

　時間としては15分ほどが最適で、朝にする必要はありませんが、個人的には朝10時や11時頃に実施するのが良いと考えています。デイリースクラムでは開発チームに対して以下を確認します。

　注意点として、デイリースクラムで問題が発見された場合に、その場で解決しようとしてはいけません。問題解決が必要である場合には、デイリースクラム以外で別の会議を設けましょう。

スプリント計画

　スプリント計画では、スプリントを始めるために必要な会議で、次のスプリントで何を作るのか、どのように作るのかを計画します。

　通常２部構成で計画が行われる事が多く、１部ではプロダクトオーナー、スクラムマスター、開発メンバーで、次のスプリントで何を実現したいかをプロダクトオーナー説明してもらいます。

　続いて２部では要求された項目に対して、開発メンバー内が必要な作業を洗い出していきます。通常プロダクトオーナーが作るバックログでは、「〇〇の機能がほしい」のように作られますので、開発をする際にはタスクとして落とし込む必要があります。

スプリントレビュー

　スプリントレビューでは、スプリント中に作成されたプロダクト/製品について、プロダクトオーナーがレビューを実施します。ここでプロダクトバックログの要求が完全に満たされているかを確認することで、無駄な手戻りを発生させずに進めることが可能になります。

　注意点として、レビュー時には実際に動作しているものを見せる必要があり、単に説明をしたりパワポで見せるということはいけません。アジャイル開発では常に動作するものをリリースすることが求められているため、開発メンバーはスプリント内で必ず動作するものをレビュー物として提出しましょう。

スプリントレトロスペクティブ

　スプリントレトロスペクティブとは、前スプリントでプロダクト開発での作業を実施する上で、問題がなかったか、もっと成果を出すためにできることはないかを話し合う場です。いわゆる「振り返り」です。

　レトロスペクティブでは、あくまでチームに対しての問題点や改善点を上げ、より良いチームしていくことが目的ですので、個人を攻撃するようなことは絶対にしてはいけません。

　振り返りの方法としては、KPTが最も使われているもので、K「Keep」、P「Problem」、T「Try」の略になります。これらをチームで洗い出し、次のスプリントでより良くなるためにTryを実施します。

スクラム開発のメリットは？

　スクラム開発の説明は以上になりますが、いかがでしたでしょか。アジャイル開発は柔軟に出来るというイメージを持っていた方も多いかと思いますが、スクラム開発を組み合わせた場合、役割・作成物・会議体は必ずプロジェクト開始前に決めておく必要があります。

　そのため、アジャイルの要素を組み合わせつつ、開発スタイルを固定化することで、柔軟にかつチームを恐子することが出来ます。スクラム開発のメリットは以下です。

　逆にスクラム開発を失敗させてしまうパターンというのも存在するので、下記を参考にしてみましょう。

スクラム開発の半数が失敗？　失敗させるプロセスアンチパターン１０選

アジャイル開発手法の１つであるスクラム開発では、ソフトウェア開発を柔軟に正確に進めることを可能にします。一方間違った方法で行っていれば、上手く行きません。そんな失敗するパターンを10選まとめました。

techgrowup.net

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