スクラム開発は、少人数のチームで実施することから小回りが利きやすく、市場のニーズや顧客の要望に柔軟に合わせられることから最近さまざまな業界で採用されている開発手法です。
導入時に教育や試行錯誤が必要なものの、個人のモチベーション向上や作業の効率化、さらには自分で考えて動けるメンバーを育成することができ、コミュニケーションが活性化することで職場全体の雰囲気や環境が良くなるという副産物もあるようです。
このようなスクラム開発について、その歴史や事例などを交えてご紹介します。
スクラム開発の意味と概要
ソフトウェア開発の手法～ウォーターフォールとアジャイル～
ソフトウェア開発には、ウォーターフォール開発やアジャイル開発などさまざまな手法があります。
ウォーターフォール開発は、プロジェクトを作業工程順に1段階ずつ進めていく手法です。これは、古くから使われてきた手法で、比較的長期にわたるプロジェクトなどに向いています。対して、アジャイル開発では、プロジェクトを1〜4週間単位の短い期間に区切って進めていきます。この区切った期間のことをイテレーションと呼びますが、イテレーションごとに達成する目標を設定し、細かく段階的にプロジェクトを管理します。
近年、多くの業種で、このアジャイル開発の手法を採用する企業が増えてきています。
スクラム開発とは
アジャイル開発の中でも、チーム内のコミュニケーションをより重視した手法がスクラム開発です。
スクラムというと、ラグビーのスクラムを思い出す方も多いのではないでしょうか。ラグビーにおけるスクラムでは、選手たちが組み合って1つのボールを奪い合います。この様子を開発手法になぞらえて、1つのプロジェクトに向かってチームで協力して取り組むということでスクラム開発と名付けられました。
スクラム開発では3人から9人程度の少人数のチームを結成し、プロジェクト全体を数週間の単位で区切ります。
この区切った期間を、アジャイル開発ではイテレーションと呼んでいましたが、スクラム開発では「スプリント」と呼びます。本来イテレーションという言葉は反復、繰り返しという意味であるのに対し、スプリントは短距離走という意味があります。イテレーションとスプリントは同じようなニュアンスで使われることもありますが、スプリントのほうがより短い期間で全力疾走するようなイメージです。
スプリントの期間は1カ月以内がのぞましいとされていますが、チームのサイズによっては数日や1週間という短いサイクルで設定することもあります。また、プロジェクトの規模が大きい場合でもチームの人数は少人数のままにとどめ、複数のチームを作ることで対応します。
スクラム開発のメリット・デメリット
スクラム開発では短い期間のスプリント単位で開発を進めていくことから、プロジェクト途中での仕様変更に対して柔軟な対応がしやすいというメリットがあります。さらに、スプリント単位で開発期間を見積もることによって作業の工数を予想しやすく、全体の納期を比較的短縮することができます。
一方、デメリットとしては習得の難しさが挙げられます。これまで主流のウォーターフォール開発に慣れていると、考え方が違う点が多く、どうしても導入時に研修などの教育コストが必要となります。また、スプリントを繰り返すことが逆にスケジュールの全体像を見えにくくする場合もあります。さらに、スクラム開発では頻繁にミーティングを行うことが重要ですが、コミュニケーションが苦手な人が苦痛に感じたり、開発メンバーがミーティングの時間を無駄だと思ってしまったりすることもあるようです。
スクラム開発はどういう経緯で生まれたのか
1986年に野中郁次郎氏と竹内弘高氏によって書かれた研究論文『The New New Product Development Game』の中で、柔軟で自由度の高い開発手法として紹介されたのが、スクラム開発の始まりです。その後の1993年に、実際にスクラム開発のチームを組んでオブジェクト指向プログラミング設計・分析ツールを構築し実践したのが、ソフトウェア開発手法としてスクラム開発が用いられた最初の例となっています。さらに2003年には『アジャイルソフトウェア開発スクラム』として要件がまとめられ、スクラム開発の手法が確立されました。
もともとは日本発の開発手法であるスクラム開発は、現在、世界中で多く活用されています。公式の『スクラムガイド』にはスクラム開発のルールや理論が明記されており、現在もアップデートされ続けています。日本語に翻訳もされているので、ぜひ目を通してみてはいかがでしょうか。
スクラム開発の具体的手法
スクラム開発を実行するポイントとして、「スクラムチーム」の結成と「スクラムイベント」の実施があります。
スクラムチーム
スクラム開発のチームは、プロダクトオーナー、開発チーム、スクラムマスターの3つの役割で構成されます。チームでは、メンバーがお互いの能力を尊重し、密にコミュニケーションを取ることが大切です。そして、メンバーは全員が一定のスキルレベルを持っていることが求められます。
プロダクトオーナーは、チームの作業を明確化し、納品物のクオリティを保障する責任者にあたります。開発に必要な作業や要件を順番に並べたプロダクトバックログを作成し、管理します。チームメンバーのみならず、組織全体がプロダクトオーナーの決定を尊重する必要があります。
開発チームは、実際に作業をするメンバーです。専門領域であってもできるだけ属人化させず、作業の責任は開発チーム全体が持ちます。
スクラムマスターは、チームのリーダー的存在です。プロダクトオーナーと開発チームのどちらも公平に支援し、時にはスクラムチーム外の社員やクライアントとの調整も行います。
スクラムイベント
スクラム開発では、プロジェクトを1カ月以下のスプリントで区切り、その中でスプリントプランニング、デイリースクラム、開発作業、スプリントレビュー、スプリントレトロスペクティブといったイベントを実施します。
まずスクラムチームが協力してスプリントプランニングを行ないます。スプリントプランニングとは、スプリント中で達成すべきゴールを作成し、そのために必要な作業を洗い出す工程です。スケジュールや要件、作業工程などをリストアップしてチームで共有します。
スプリント中は毎日15分程度のミーティングを行います。このミーティングをデイリースクラムと呼び、前日の作業の確認や次の作業予定の計画、やるべきことや問題点などを議論します。これはコミュニケーションを活性化させるとともに、そのほかのミーティングを取り除くために行うもので、スクラム開発では重要なイベントとされています。
スプリントが終了したら、スプリントレビューを行ないます。スプリントレビューとは、ステークホルダーも交えてスプリントをふりかえる作業です。スプリントでうまくいった点や問題点などを議論し、成果物へのフィードバックを受け取ったりします。ここでの目的は次に行なうべき作業や目標、スケジュールなどを設定し、次のスプリントで使用することにあります。
最後にスプリントレトロスペクティブを行ないます。スプリントレトロスペクティブとは、スクラムチームの確認をすることです。スプリントレビューが成果物の確認をする場であるのに対し、スプリントレトロスペクティブでは働き方やツール、人間関係などの観点からスプリントを検査します。そして次のスプリントがより効率的で楽しいものとなるよう、改善案や必要な項目の整理をします。
このようにスクラム開発の手法は、チームで作業をするときのフレームワークとなります。少人数のチームで協力しながら進めることであれば、システム開発でなくとも応用可能と考えられています。ここで大切なことは、デイリースクラムやスプリントレビューなど、イベント自体が目的になってしまわないように気をつけることです。あくまでも目的はプロジェクトのゴールであり、各イベントはその手段に過ぎません。
スクラム開発事例
ある企業ではスクラム開発を取り入れたことによって、コミュニケーションの活性化で意見交換がスムーズになったり、チームメンバーそれぞれが主体性を持って動くことができるようになったりといった効果がみられたようです。
しかし、そのためには導入時にスクラムマスターによるコーチングや、チーム人数とスプリントの調整、コミュニケーションをするための工夫など、準備コストをしっかり取ったといいます。スクラム開発はルールがしっかり確立されているとはいえ、実際の現場ではプロジェクトの内容やチーム環境に合わせて試行錯誤をしながら取り入れることが多いようです。
チーム単位を重視することで、いままでの縦割り型の組織にはそぐわない場合もあります。そのため、新しい体制を柔軟に受け入れ、継続的に改善していくことが必要となります。
「スクラム開発の手法とは。スクラム開発の歴史や事例」についてのまとめ
従来のウォーターフォールなどによる開発手法では、個人の技量に委ねられる部分も多くありました。
しかし、スクラム開発ではチームとしての成果を重要視するため、メンバー全員が考え動くことが必然となります。ひいては自分の専門外の勉強が必要になることや、ミーティングによって作業時間が減ることもあり、時にそれは負担となる場合もあるかもしれません。組織としても教育コストや改善案の許容が求められます。
結果として、メンバーの意識が大きく変わり、自ら考えて動くことができる人材を育成できることは、これからの時代の組織運営に大きな利点となるのではないでしょうか。今回ご紹介したスクラム開発手法を、ぜひ今後のプロジェクト管理やチーム作りに役立ててみてください。
公式ガイド：
http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf#zoom=100
