有名なシステムの開発の手法には、ウォーターフォール開発とアジャイル開発があります。その中で、注目されている開発手法がスクラム開発です。

今回はスクラム開発の定義や、そのメリット、デメリット、どういう開発に向いているのかなどについて紹介します。

スクラム開発とは？

スクラム開発というのは、少人数のチームでスクラムを組むようにして短いスパンで開発を行っていく方法です。この開発手法について紹介したいと思います。

そもそもスクラムとは？

「スクラム」という言葉はラグビーで使われる言葉。

軽い反則の後、プレーを再開する時にお互いのチームで3人以上のプレイヤーが組み合うスタイルから来ています。そこから転じて、全員が一丸になって共同で物事に取り組む事を「スクラム」と呼んでいます。ニュースで、「複数の企業がスクラムを組んで…」などと表現されたりするのも、これが由来です。

アジャイル開発の代表的な手法の1つ

実は「スクラム開発」は柔軟で自由度の高い日本発の開発手法で、「アジャイル開発」の手法の一つです。

アジャイル開発の中でも最もコンパクトな開発スタイルで、短いスパンで少しずつ、必要な機能から順番に実装していくという特徴があります。

短いスパンであるということが特徴。

どんなに大きなプロジェクトであっても、それを機能単位で細かく分けていき、単位を小さなモジュールレベルにした上で、短期間で実装を終わらせます。

そして目標とするレベルを達成できていれば、次のモジュールを実装するという流れで開発していきます。

これによって、ウォーターフォール開発で起こりがちな、最後の最後で「要件と異なる」などのずれが発生するのを回避しているのです。

チームのコミュニケーションを重視した開発手法

この開発手法を採用するには、いくつかの条件があります。

スクラム開発は柔軟かつ全人的なプロダクト開発手法ですので、共通のゴールに到達するため、開発チームが項目を共有し合いながら一体となって働くことが求められます。

つまり、チームの高いコミュニケーション能力をベースに、お互いに助け合い（スクラムを組み）ながら、プロダクトを開発するのです。

ここで、コミュニケーション能力が不足するメンバーがいた場合や、お互いを助け合うような体制が構築できないと、開発自体が頓挫してしまいかねません。

アジャイル開発の一種ですので、必ず助け合いながらの開発が求められるのです。

スクラム開発のメリット

では、アジャイル開発の中でも、このスクラム開発が持つメリットとは何でしょうか。３つの観点で紹介しましょう。

チーム一人一人が責任を持ってタスクに取り組める

まず、チームに所属するメンバー一人一人の責任感が増します。

プロダクト・バックログという実装予定機能一覧の中から、メンバー内で話し合って実装すべき優先順位や、いつまでに実装するのかなどを決めるため、タスクが自分事になるからです。

自分もその決定に関わっている事から、責任感が増えるのです。

チームで発生した問題を迅速に発見可能

スクラム開発では、自分たちが決めた期間内に実装を完了させるため、毎朝、開発に取りかかる前に、チームの状況を共有するミーティングを行います。これをデイリースクラム、もしくはスタンドアップ・ミーティングと呼びます。開発にかける期間が限られているため、ミーティングで必ず以下の内容を必ず共有します。

・昨日やったこと

・今日やること

・障害となっていること

特に3つ目が重要。障害となっている事は全力で取り組むか、もしくは開発から外すという決断をする必要があります。ミーティングのペースが早いため、すぐに障害を把握できますし、そのため軌道修正も早く行えます。

工数見積もりが正確になる

ウォーターフォール開発だと発生しがちな工数見積もりのミスを未然に防ぐことが可能。見積もりが正確になります。

ウォーターフォール開発だと、場合によっては年単位になる巨大なプロジェクトを最後まで見積もらないといけないため、工数が読みにくく、そのため、プロジェクトの遅延や失敗に繋がりやすいという問題があります、

一方、スクラム開発はアジャイル開発の一種で、短い工数で開発を区切るという特徴があります。短い工数を何度も繰り返す事で、その都度計画を立てていけるので、見積も正確になります。

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

とはいえ、もちろんデメリットもあります。ここでは大きく2つのデメリットを挙げます。

チームメンバーの入れ替わりやスキルレベルの差が弱点

スクラム開発は短い期間で開発を区切りながら、開発リズムを作っていくことが重要になります。スプリントと呼ばれる1週間から4週間を単位とした開発期間内で、こなせる作業量（ベロシティ）を順次測りながらリズムを作っていきます。

この期間内にメンバーの入れ替わりや新規採用が相次ぐと、教育や受け入れ態勢の構築に時間が取られます。これが開発リズムを悪くし、遅延にも繋がります。またメンバーの入れ替えがなくても、メンバー間のスキルレベルに差があると、こちらも教育が必要になり、ベロシティがバラバラになってしまいます。

ミーティングが苦手なエンジニアには向かない

もう1つのデメリットは、メンバーのコミュニケーション能力に依存するという点です。

毎日のデイリースクラムなど、とにかくミーティングが非常に多い上、自分のタスクや課題を簡潔に項目にまとめ発表するという、高い言語能力・コミュニケーション能力が求められます。

タスクを黙々とこなし、コミュニケーションを控えたいエンジニアには向かない開発手法です。また、そういうメンバーをもしチームに入れてしまうと、どういうポジションに当てはめるのかをよほど考えないと、どれだけスキルが高くても、そのメンバーがチームの足を引っ張ってしまうことになります。

スプリントとは

ではスクラム開発の、実際の開発手法について紹介しましょう。

スクラム開発は、開発期間の単位である「スプリント」を基準に行います。この「スプリント」は、開発を少しずつ区切って進めるために、期間は短めに設定されることが多く、おおよそ1週間から4週間を基準にしています。

例えば4週間をベースに開発を行う場合は、一通りの機能開発に加え、月に1回程度の機能アップデートや修正・バグ対応などに対応可能なスケジューリングとなります。

スプリントの流れ

では、この開発期間単位である「スプリント」について紹介します。

「スプリント」の流れについて、その基本的な手順は以下の通りです。

バックログを作成

まず、製品に必要な要素や機能を項目単位で書き起こした一覧を作成します。この一覧の事を「バックログ」と呼びます。

スクラム開発の場合、このバックログには2種類が定義されています。一つ目は、顧客やユーザーへの価値を一覧化したもので「プロダクト・バックログ」と呼ばれます。これには開発における優先順位が付けられています。

このプロダクト・バックログは、チームの役割を明確化し、納品物のクオリティを保証する必要があるため、その責任者であるプロダクト・オーナーによって定義される事がほとんどです。もちろん、チームからのフィードバックが反映される場合もあります。

この優先順位の高いものから開発を行うのですが、直近のスプリントでそこまで開発するのかがまとめられたものが「スプリント・バックログ」です。スプリント・バックログでは詳細な仕様と、開発の順番などが明確にされます。

スプリントプランニングミーティング

このスプリント・バックログを作成するのが「スプリントプランニングミーティング」です。

このスプリントでの目標を明確にし、詳細な仕様・項目や担当者を決めていくミーティングです。この時重要なのは、チームメンバーは勝手に優先順位を変えてはいけないという事です。また逆にプロダクト・オーナーは勝手に工数見積をしてはいけないという事です。

これら、お互いの領分には手を出さないようにしながら、スプリントで何をどれくらい開発するのか。項目を明確に決めていきます。

デイリースクラム

実際に開発に入ると、毎日作業開始前に全員で集まって行うのが「デイリースクラム」です。

ここでは昨日までの作業状況、今日の作業予定、開発の上で障害になっている項目などが話し合われます。特に3点目の情報共有は重要で、チーム全体の進捗に影響を及ぼしますので、別途時間を取ってでも検討するべき内容・項目かどうかを共有しておきます。

逆に、ここではあまり細かいことまで打ち合わせ内容にしましょう。障害について、仕様の問題なのか、技術面の問題なのか、スキルの問題なのかを分解し、バックアップができそうなのか、そもそも今回のスプリントから外した方が良いのかなどを議論するのは、別途時間を取るべきです。

スプリントレビュー

スプリントの最終日に行うものです。

プロダクト・オーナーによる品質検査で、必ず動作するアプリケーションで行います。ここを画面キャプチャなどで代用してはいけません。ここで、当初立てたプロダクト・バックログの仕様・項目をきっちりと満たしているのかの検査が行われるのです。ですので、場合によっては営業担当者や顧客まで参加する事もあります。

また、その結果として新たなバックログが生成される事もあります。新たに生成されたバックログは優先順位が付けられ、次回以降のスプリントプランニングミーティングで検討される事になります。

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

同じく最終日に行われるのが「スプリントレトロスペクティブ」です。これはスプリントの振り返りで、言ってしまえば「反省会」です。スプリントの良かった項目、悪かった項目を振り返り、次のスプリントで活かせるようにするのです。また、場合によっては次のスプリントのゴールを決める場合もあります。

クロージャー

では、いつまでスプリントを続けるのかと言えば、それは開発プロジェクトが終了するまでです。ここで「プロジェクトが終了しました」ということをしっかりと宣言する必要がありますので、それを「クロージャー」と呼びます。

この時には最終的なデバッグやマーケティング、販促活動を行います。クロージャーが終了すれば、開発プロジェクトは終了です。

スクラム開発が向いているプロジェクト

最後に、スクラム開発に向いている開発プロジェクトを説明しましょう。これを考える上では、逆に向いていないものを考えれば良いでしょう。

まず、絶対に避けないといけないのは、開発単位を1～4週間にまで分解できないような開発はダメだという事です。もちろん全機能の開発が、1~4週間という短期間で終わるような開発案件は中々ありません。

ですので、必要な機能をモジュール化し、なるべく小さく分解する事が求められるわけです。

従って、少しずつ公開する機能を増やしていくようなアプリケーションや、あとで機能追加が可能な仕組みになっているようなアプリケーションであれば、スクラム開発は向いている事になります。

逆に、そういう分解がしづらいものについてはウォーターフォール開発や通常のアジャイル開発で行えば良いでしょう。

まとめ

今回はスクラム開発について紹介しました。プロダクトの機能をしっかりと分解し、優先順位を付けて、スプリントと呼ばれる短い期間で次々と開発していく手法です。

メンバーに高いコミュニケーション能力が求められますが、手戻りが少なく、開発工数が大きくはぶれないというメリットがあります。

このスクラム開発を取り入れる事で、開発体制全体の見直しが行われますので、業務の改善や働き方改革にも貢献できると考えられています。皆さんもこの考え方や開発手法を上手く取り込み、開発に活かしていただけたらと思います。

↑目次へ戻る