スクラム開発とは？

スクラム開発の失敗例を見ていく前に、「スクラム開発とはなにか？」を確認しておきましょう。

スクラム開発とは、アジャイル開発の一種です。

アジャイル開発について、間違えている方も多いですが、“従来のウォーターフォール型（予測型）やプロトタイプを作成する反復型とは異なる、適応型(反復型)の開発手法の総称”です。アジャイル開発＝特定の開発手法ではありません。

アジャイル開発の具体的な手法・方式としては、エクストリーム・プログラミング（XP）、ユーザー機能駆動開発（FDD）、Dynamic Systems Development Method（DSDM）などが知られており、スクラム開発もアジャイル開発の手法の一つになります。

では、ここからはスクラム開発について見てきましょう。

スクラム開発はアジャイル開発の中でもっともポピュラーな開発手法です。

実は、スクラム開発は、スクラム開発という名前が付けられる前から、日本企業内で行われていた開発手法です。1986年に竹内弘高氏、野中郁次郎氏が発表した論文「The New New Product Development Games」がスクラム開発の原点と言われています。

この論文ではアメリカ（NASA）で行われていたウォーターフォール型の開発の比較で、日本企業（富士ゼロックス、キヤノン、ホンダ）が行っていた開発手法を、ラグビーのスクラムにちなんで、スクラム開発として紹介しています。

スクラム開発の特徴を簡素に表現すると、ラグビーではチーム全員が協力してボールを運んでいくのと同じように、各メンバーがチーム状況に応じて、役割を全うすることが期待されている開発手法です。

なお、スクラム開発のメンバーは、実際に手を動かすチームメンバー（5人から9人ほどが好ましいとされる）、成果物の責任者であるプロダクトオーナー、そして、開発作業が問題なく進められているか監督する権限を持つスクラムマスターの三者で構成されています。

スクラムマスターが従来のプロジェクトマネージャーに相当すると言われることが多いですが、前述の通り成果に対する直接的な責任者はプロダクトオーナーであり、スクラムマスターは“成果物が問題なく開発できる環境つくりに対して、間接的な責任を持つ存在”です。顧客の変更要求に対する否認を含めた、スクラムチーム内外に存在するステークホルダーとの調整が主なミッションになります。

私個人の感覚としては、スクラムマスターはPMというよりも、権限の強いPMOに近い存在だと思っています。

さて、スクラム開発の工程を確認しておきましょう。アジャイル開発では、プロジェクト開発をいくつかのタームを区切って、タームごとに開発作業を行います。スクラム開発では、このタームのことを「スプリント」と呼びます。なお、一般的にスプリントは２週間から1か月にすることが推奨されています。

実際にスプリントに入る前に、そのスプリントで何をするのか、そして、その作業にどれくらいの人日が掛かるのか見積もる必要があります。そのためのミーティングを「計画ミーティング」と呼びます。計画ミーティングと呼ぶだけあって、責任者はプロダクトオーナーですが、プロダクトオーナー一人では決めず、チームメンバーと話し合い、合意する必要があります。

そして、合意を受けて作成される、スプリント内で行う作業の一覧のことをスクリプトバックログと呼びます（スクラム全体でやるべきことの一覧はプロダクトバックログと呼びます）。スプリントに入ると、メンバーはスクリプトバックログを見て、まだ完了していない作業を自分の判断で選択して実施していきます。つまり、誰がどれをやっても問題ないのです。

なお、スプリント期間中は、スクラムマスターが司会進行役になって、毎日15分以内でスクラム会議を行うことになっています。スクラム会議では、前日から何をしたのか、本日は何をする予定なのか、進捗で困っていることがあるか、の三点を確認します。ここで問題が見つかった場合、スクラムマスターは、その問題を解決する責任を負うことになります。

さて、一つのスプリント期間が終わったら、次のスプリントに行く前に振り返りを行わなくてはいけません。それが、スプリントレビュー（レトロスペクティブミーティングやスプリント振り返りとも呼ばれる）です。スプリントの成果物を確認する会でもあるため、営業や顧客も参加することもあります。また、その時点の成果物を見て、仕様変更、ひいてはスクリプトバックログの追加変更が行われることも多いです。

そして、スプリントレビューで問題なくシステム開発が完了し、最終的な納品作業や販売活動へと移行するフェーズをクロージャ（終了）と呼びます。なお、クロージャを迎えるまで、次のスプリントが実施されることになります。

よくあるスクラム開発の失敗例

スクラム開発の失敗パターンは大きく分けて、「開発の失敗」と、「そもそもスクラムチームが成立していない」の二つに分かれます。

開発の失敗の具体例として、クロージャが当初予定通り迎えられず、スプリントの回数が増え、開発遅延となってしまった、というものから、顧客のアジャイル開発への過度の期待から“無茶ぶり”と言える要求変更を受けてしまい、計画が頓挫する、というパターンもあります。

そもそもスクラムチームが成立していない具体例としては、メンバーがスクラム開発の進め方を十分に理解していない、という根本的な問題を抱えているパターンが多いです。他にも、スクラムマスターの能力は不足しており、有意義な支援活動が実施できないなど、個々の能力不足に起因する問題もよく見られます。

スクラム開発の失敗の原因と対策は？

スクラム開発で失敗を防ぐ方法は、究極的にして、唯一の答えは人材レベルを上げるしかありません。

ラグビーのスクラムにちなんで、スクラム開発という名称が付けられた、ということはすでにご紹介した通りですが、メンバーの中にルールが分かっていない人、能力が全体の平均より劣っている人がいると、その人がボトルネックになって、チーム全体の能力が下がってしまう、という一面もあるのです。それこそプロチームのようにメンバーに高いプロフェッショナル性を求める点が、スクラム開発の短所です。

大半のスクラム開発の失敗は、メンバーに対してスクラム開発のメリット、目的、「禁則事項」の確認と徹底を行うことで、概ね防げるはずです。もっというと、スクラム開発で失敗しているところは、経営層など上層部主導で、現場のメンバーの納得感を得ないまま導入を急いた結果、空中分解するパターンが多いです。

だいたい、スクラム開発に懐疑的、正しいやり方もわかっていない人たちに押し付けて、出来るはずがない、という話ですよね。

また、押し付けた当人たちもスクラム開発について理解が不十分であることも多いです。例えば、スクラムマスターを単なるスクラム会議の司会進行役程度に考えて、経験が浅い社内の若手にしてしまうケースがあります。スクラムマスターの権限と義務に対する取り組みが不十分となり、チームを疲弊させる可能性が高まります。

最悪のパターンは、計画ミーティングでメンバーの合意を得ない（ひどいと開催もしない）ままプロダクトバックログを作成してスプリントに突入したものの、未完になってしまい、更に未完のまま顧客に見せたくないからとスプリント期間を延長させてしまうパターンです。

開発しきれなかったとしても、最初に決めたスプリント期間は延長させてはいけません。そもそも、未完バックログができないよう、スクラムマスターに調整・支援要請するのが正しい動きです。そして、計画ミーティング内でメンバーとスプリントバックログに合意しないままスクラムに入ることは、言語道断です。このような状態になったスクラム開発は開発遅延、そして最終的に開発失敗へとつながる可能性が極めて高いです。

まとめ：チームメンバーの能力向上がカギ

バックログから誰がどのタスクを実施しても良い、ということは、基本的には、誰もがどのタスクもできる、ということでもあります。このように、スクラム開発はメンバーの技能・スキルが一定以上であることを前提にしています。また、メンバーに対して高い要求を行うということは疲弊度も高くなることを意味します。

「とりあえず、スクラム開発」と実施する前に、いくつかの書籍などで手法やコツを学習し、メンバーの合意を得てからスタートするのがベターです。