スクラム開発とは？手順やメリットデメリットを詳しく解説

コンピュータ・システムは今やビジネスでも生活でもなくてはならない存在になりましたが、ここまで進化した背景には開発手法の進化があります。

システムに効率よく高度な機能を搭載できる開発手法が次々生まれたことで、優れたシステムが短時間、低コストでつくれるようになりました。

画期的なシステム開発手法の1つにアジャイル開発がありますが、今はさらに進化したスクラム開発が注目されています。

ラグビーのスクラムのように、開発担当者がスクラムを組んで一気にシステムをつくっていく手法です。

この記事ではスクラム開発がどのようなもので、どのようなメリット、デメリットがあり、従来のアジャイル開発とは何が異なるのか解説します。

また、スクラム開発にはどのようなスキルを持った人が必要で、作業がどのように進むのかも紹介します。失敗を予防するのに適している手法といえます。

アプリ・システム開発のプロが開発のお悩みを解決します

アプリ・システム開発の6割が失敗すると言われています。クライアントのリピート率100%のリレイスにご相談ください。

＼ まずは無料相談！1営業日以内に返信 ／

アプリ・システム開発の相談をする まずは資料をダウンロードする

スクラム開発とは

スクラム開発を理解するには、先にアジャイル開発を知っておいたほうがよいでしょう。

アジャイル開発とは

アジャイルは「素早い」という意味です。ではアジャイル開発は何より素早いのかというと、ウォーターフォール開発より素早いことを意味します。

ウォーターフォール開発は従来の開発手法で、計画、設計、実装、テストを1つずつ進めていきます。計画が終わらなければ設計に進まず、設計が終わらなければ実装に進まない、といったように作業していきます。

一方のアジャイル開発は、要件定義ができたら、優先順位が高い要件から次々実装やテストを行っていきます。

アジャイル開発は開発途中で仕様変更が生じても柔軟に対応できます。

アジャイル開発の進化形としてのスクラム開発

スクラム開発はアジャイル開発をベースにしています。

スクラム開発でシステムをつくっていくことが決まると、プロジェクトチームのメンバーをいくつかの小グループにわけます。それぞれの小グループに役割やタスクを与えて、自分たちの仕事に専念してもらいます。

ある小グループは他の小グループの進捗とは関係なく、自分たちの仕事を進めることができます。

もちろん、ある小グループの仕事が終わらないと別の小グループの仕事が滞ることもあります。その場合はボトルネックになりやすい仕事を担う小グループのメンバーを増やしたり、スキルが高い人をその小グループに入れたりします。

ウォーターフォール開発の場合、ある作業が停滞すると次の作業に進めなくなるので、アジャイル開発の進化形のスクラム開発は、それより格段に早くシステムをつくりあげていくことができます。

スクラム開発を導入するメリット

システム開発のプロジェクトチームがスクラム開発を導入すると次の3つのメリットが得られるでしょう。

• クライアントからの要求に柔軟に対応できる
• 最終段階での大幅なつくり直しを回避できる
• チーム内で補い合うことで生産性を向上できる

1つずつ確認していきます。

クライアントからの要求に柔軟に対応できる

クライアント（システムの発注者）のなかには事前準備が十分でない会社もあり、開発に着手してから機能を追加したいと思い立つことがあります。また、開発途中で予算不足が判明し当初予定していた機能を外すこともあります。

開発者（システム会社）はクライアントのこのような無茶ぶりにも対応しなければなりませんが、スクラム開発ならそれが可能です。

例えば、機能の追加であれば新しく小グループをつくってタスクを与えるだけで対応できます。

機能の削除であれば、担当していた小グループを解散して、そのメンバーを他の小グループに加えることができます。

この柔軟性こそ、スクラム開発の最大のメリットといえるでしょう。

もし事前にクライアントが要件変更を頻発するタイプであることがわかっていれば、開発手法はスクラム開発の一択になるでしょう。

最終段階での大幅なつくり直しを回避できる

スクラム開発は、ウォーターフォール開発の最大の弱点を解決します。弱点とは、最終段階での大幅なつくり直しです。

ウォーターフォール開発でシステムをつくっていくと、クライアントが大まかな様子を確認できるのは、システムの全体像がみえてきたころです。もしその段階でクライアントが「思っていたのと全然違う」と言ったら、作業全体を巻き戻して抜本的につくり変えなければなりません。

一方でスクラム開発なら、例えば要件 A が完成していても要件 B はまだ着手していないという状態になります。完成した要件 A をクライアントに確認してもらって NG が出たとしても、要件 A だけを修正すればよいので要件 B の作業には被害は及びません。

さらに要件 A で修正できれば、その改善点を要件 B の作業にフィードバックすることができます。つまり「このクライアントはこういうところを気にするから、そこに注意していこう」と考えることができます。したがってよりよいシステムが生まれやすくなります。

チーム内で補い合うことで生産性を向上できる

スクラム開発では小グループを編成するので、小グループのメンバーや小グループに付与する作業を調節することができます。

重要な開発をする小グループには人数を多く割き、スキルが高い人を入れることができます。

高いスキルが要らない仕事であれば、新人を投入することができます。

適材適所を実現しやすくなり、結果的に生産性を向上させることができます。

スクラム開発のデメリット

スクラム開発には3つのデメリットがあります。

• チームワークが悪いと非効率になる
• メンバーに一定のスキルが求められる
• 全体のスケジュールを把握しづらい

1つずつ紹介します。

チームワークが悪いと非効率になる

スクラム開発のメリットは、プロジェクトチーム全体の総合力が高まったときに生まれます。そのためチームワークが悪いと非効率な作業を強いられることになります。

スクラム開発では小グループが複数個でき、それぞれが自分たちの仕事をこなしていきますが、ある程度仕事が進んだら他の小グループとすり合わせる必要があります。このときチームワークが悪いとすり合わせがうまくいかず作業が停滞します。

つまりチームワークが悪いと、小グループにわけたことが弊害になってしまうのです。

日々の業務でコミュニケーションを取る機会が多い開発手法なので、コミュニケーション能力も求められます。

メンバーに一定のスキルが求められる

小グループにわけてしまうと、1人ひとりの役割分担がより明確になるので、1人ひとりに高い業務完遂能力が求められてしまいます。

スクラム開発を実行するには、一定スキル以上のメンバーを集めなければなりません。

しかも小グループに与えられる仕事は「小刻み」なので、納期が短くなります。したがって、早く仕事をこなす力も必要になります。

ウォーターフォール開発は全員が一斉に同じ仕事に取り組むイメージなので、スキルが劣る人が多少含まれていても全体でフォローすることができますが、スクラム開発の小グループではそれがしにくくなります。

全体のスケジュールを把握しづらい

スクラム開発を進めるプロジェクトチームのリーダーは、すべての小グループの進捗状況を把握しなければなりません。それは大変な作業になるでしょう。スケジュールを管理するツールが必要になります。

また、スクラム開発は頻繁に要件変更を求めるクライアントの案件で採用されることが多いので、スケジュールが頻繁に変わる恐れがあります。

このような事情により、全体の開発スケジュールを把握しづらくなります。

スケジュール管理のしやすさでは、ウォーターフォール開発のほうが有利です。

ウォーターフォール開発については以下の記事で詳しく解説していますのでポイントをつかんでください。

スクラム開発に必要なメンバー

スクラム開発では小グループの編成が肝になります。

以下に紹介する役割を持つ人を指定して編成していくことをおすすめします。

• プロダクトオーナー
• スクラムマスター
• 開発エンジニア
• ステークホルダー

プロダクトオーナー （PO）

プロダクトオーナーは、システム開発プロジェクトチーム全体のリーダーです。

システム開発の最終責任者であり、調整役でもあります。

スクラム開発の小グループ内にもリーダー的な役割の人が必要になりますが、プロダクトオーナーはそれらのリーダーを束ねていきます。いわば、リーダーのなかのリーダーです。

また、クライアントの要望を受け付けるのもプロダクトオーナーの重要な仕事です。

そしてコスト管理と利益管理、人員管理もしなければなりません。

スクラムマスター （SM）

スクラムマスターは、プロダクトオーナーとメンバー（開発エンジニア）の間の中間管理職のようなポジションになります。

細かなスケジュールを管理して、タスクの 1 つひとつの業務遂行に責任を負います。メンバーがつまずいていたらフォローします。

そのため、小グループごとにスクラムマスターを置いてもよいでしょう。

そして開発するシステムの規模が大きくなり、プロジェクトチームが大所帯になると、プロダクトオーナーの補佐役としてスクラムマスターを置くことがあります。

この場合のスクラムマスターは、上記で紹介したプロダクトオーナーのような仕事をすることになります。

開発エンジニア

小グループのメンバーのことを開発エンジニアといい、実際にシステムを組んでいく人たちのことです。

スクラム開発では、小グループ内の開発エンジニアは平等になることが多いでしょう。

ステークホルダー

システム開発でステークホルダーといえば、大抵はクライアント、つまりシステムを発注した会社の担当者になります。

したがって厳密にはステークホルダーはシステム開発のプロジェクトチームのメンバーではありませんが、プロダクトオーナーは綿密にステークホルダーとコミュニケーションを取り、その要望をシステム開発に落とし込んでいく必要があります。

スクラム開発はステークホルダーの細かい要望をききやすいというメリットがあります。そのメリットを活かしてステークホルダーの要望をかなえることができればよりよいシステムをつくることができます。

スクラム開発なら、ステークホルダーを「メンバーの一員」と考えることができます。

スクラム開発の手順

スクラム開発は次のように進みます。この流れは重要です。

システム分野においてスプリントはあまり聞き慣れない言葉だと思いますが、スクラム開発ではこれがとても重要な概念になります。

スプリントとは

ステップ1に入る前にスプリントを解説します。

陸上競技のスプリントは短距離走のことです。スクラム開発ではプロジェクトチームを小グループにわけ、それぞれに業務やタスクを付与します。そのため小グループが携わる1つひとつの業務は短期間で終わります。

それで1つひとつの業務のことをスプリントと呼びます。

スクラム開発ではスプリントを多くつくり、1つのスプリントを短期間で完了させて次のスプリントに移るという進め方をします。

スクラム開発は小股で早歩きするイメージで、ウォーターフォール開発は大股でゆっくり歩くイメージです。

ステップ1：スプリント・バックログをつくる

バックログとは残務や積み残しという意味です。スプリント・バックログとは、1つひとつのスプリント（細かい業務）を一覧にしたもの、と理解してください。

スプリント・バックログは「やることメモ」と言い換えてもよいでしょう。プロジェクトチームのなかでスプリントをすべて挙げることができれば、それをすべてやり終えるとシステムが稼働することになります。

スプリントはクライアントからの要望を元につくりますが、それ以外でもプロジェクトチームのメンバーたちの意見も重要になります。

ステップ2：スプリント・プランニングを立てる

スプリント・バックログができあがったら、つまりすべてのスプリントが出そろったら、優先順位をつけたり、難易度を測ったりします。これをスプリント・プランニングといいます。

スクラム開発は「やることメモ」の項目が多くなるので、優先順位をつけないと開発がスムーズに進みません。

そして難易度をつけることによって、難しいスプリントをスキルが高い小グループに任せることができます。

誰にどの仕事を任せるか、いつまでに完成できるか、工数はどれくらいかかるか、開発エンジニアは何人必要か、といったこともスプリント・プランニングで決めていきます。

ステップ3：デイリースクラムを行う

デイリースクラムとは、毎日の小打ち合わせのことです。

小グループが複数個できるスクラム開発では毎日1回、メンバー全員が顔を合わせる機会が必要になります。

小グループのリーダーに進捗状況を報告させるだけでもいいですし、ときには雑談をしてもよいでしょう。時間は30分でも15分でもかまいませんが、毎日行うようにしましょう。

小グループでスプリントをこなしていく作業方法であっても、どこかで他の小グループの仕事とドッキングさせる必要があります。

デイリースクラムによって、そのドッキングをスムーズに進めることができます。

ステップ4：スプリント・レビューでチェックする

スプリント・レビューは、完了したスプリント（1つひとつの仕事）についてクライアントなどにチェックしてもらう作業です。

スプリントが1つ完了したら、クライアントの前でデモンストレーションをして講評をもらいます。

またスプリント・レビューをすることで、冒頭で掲げたスプリント・バックログを消化しているかどうかチェックすることができます。

そしてスプリント・レビューを実行することで、新たに必要になるスプリントがみつかるかもしれません。その場合は、スプリント・バックログに追加していきます。

クラアントが参加できないときでも、プロダクトオーナーはスプリント・レビューを受けなければなりません。

ステップ5：スプリント・レトロスペクティブを行う

レトロスペクティブとは、過去に遡る、という意味です。

スプリント・レトロスペクティブとは、完了したスプリントを振り返る打ち合わせのことです。

スプリント・レビューの内容を開発エンジニアにフィードバックするためにスプリント・レトロスペクティブを開催します。

ここで次のスプリントに向けた話し合いもします。

スクラム開発で知っておくべき用語

ここまで登場した「スクラム開発用語」を1、2行で短く紹介します。用語集としてお使いください。

まとめ

スクラム開発にはメンバー個々の力量が問われるため、どのチームでもすぐに始められるものではないでしょう。

しかし業務の効率化にも、クライアントの要望をかなえるのにも有効な開発手法なので、試してみる価値はあります。最初は一部の工程をスクラム化してみてはいかがでしょうか。

開発エンジニアたちも慣れてくれば、「スクラム開発のほうが仕事がやりやすい」と感じるはずです。

開発エンジニアたちの仕事のしやすさは、完成するシステムのクオリティに大きく関わるため、開発チーム全体の底上げにつながるはずです。