記事更新日: 2021/04/14
スクラムとは、アジャイル開発の中でも、近年特に注目されている手法のひとつです。
最小の労力で最大の効果が得られることで人気を集めており、近年多くの企業が取り入れています。
しかし、はじめて導入するからこそ、どういう順序で進めていけばいいのか、どのような人材が適しているのかなど、情報を集めただけではわからないことが多いですよね。
本記事では、「スクラム」がどういった手法なのか、進め方やメリットをはじめ、失敗を避けるために注意すべきことを解説します。
このページの目次
「スクラム」とは、ソフトウェアやシステムを開発する代表的手法で、体系的には「アジャイル開発」に属します。
「アジャイル開発」は、少人数の開発チームがプロジェクト達成のために定期的に話し合いを設けながら作業を進めていく手法です。
ベースとなる考え方は「アジャイルソフトウェア開発宣言」。2001年に17人の技術者が集まり、開発過程の重要事項を定義しました。
従来型の「ウォーターフォール開発」と比較すると、機能を小さな単位に分けて開発を進めることや、途中の仕様変更などに柔軟に対応できることが「アジャイル開発」の大きな特徴として挙げられます。
「アジャイル開発」の中でも、特に人気の手法が「スクラム」です。
Ken Schwaber（ケント・ベック氏） とJeff Sutherland（ジェフ・サザーランド氏）の２人によって考案され、いくつかの失敗プロジェクトを立て直す経験から生まれました。
「スクラム」の定義は、「スクラムガイド（公式）」で以下のように定義されています。
スクラムは、1990 年代初頭から複雑なプロダクトの作業管理に使用されてきたプロセスフレームワ ークである。プロダクトを構築するプロセス、技法、決定的な方法論などではない。さまざまなプロ セスや技法を取り入れることのできるフレームワークである。
引用：「スクラムガイド（公式）」2017年、日本語版
「スクラム」の特筆すべき点は、開発チームの技術的な側面ではなく、チームコミュニケーションを重視することにあります。言うなれば、円滑にプロジェクトを進めるための枠組みとしての位置づけです。
実践では、機能を小さな単位に分け優先順位の高いタスクから進めていきます。毎日短時間のミーティングを行いタスクの進捗状況のシェアと抱えている課題の改善を話し合います。
この密なコミュニケーションの積み重ねが、短期間で最大限の効果があげられることにつながっているのです。
これこそが「スクラム」が世界的に多く普及しているフレームワークとなっている所以です。
では、「スクラム」はどのような流れで行われているのか、具体的に解説していきましょう。
まずは、開発計画を立てることからスタートします。
顧客から提示されるプロダクトへの要望をまとめた「バックログ」を作成し、開発ひとつの期間（スプリント）に必要となる機能を選びます。
開発期間は4週間以内とし、優先順位に基づいて並べ替えるのがポイントです。
開発計画を具体的に立てる会議を「スプリントプランニングミーティング」といいます。
スプリント内で「何を作るのか」「どのくらいのボリュームを作るのか」といった目標を設定し、バックログをさらに詳細なタスクに分類した「スプリントバックログ」を作成して、実装する機能リストを可視化していきます。
バックログごとに工数を見積もり、開発メンバーにセクションを割り振って、内容を実施していきます。
「スクラム」では、毎日定刻に5～15分ほどのミーティングを行います。これを「デイリースクラム」といい、チームの状況を共有するために実施します。
開発メンバーは、「昨日の作業報告」「今日の作業予定」「抱えている問題・障害」の3点を必ず報告します。プロジェクトの状況や進め方に問題がないか、毎日正確に把握することが求められます。
密なコミュニケーションを重視することで、スプリントの課題を早期に解決することが可能となるのです。
開発がある程度進むと、プロダクトの成果物を確認する場を設けます。それを「スプリントレビュー」と呼び、スプリント最終日に機能のテスト・評価を行います。
画面キャプチャや資料でなく、実際に機能を動作させるのがポイントです。機能が最初に設定したバッグログの基準を満たして正しく動作しているか、をチェックします。
「スプリントレビュー」を終えると同時に、スプリントを振り返ることを目的に「スプリントレトロスペクティブ」と呼ばれるミーティングを開催します。
良かった点、悪かった点、改善点などチームメンバーで議論し、プロダクトバックログの内容と優先順位の見直し等を立案して、次回のスプリントに反映できるようにしておきます。
「スクラム」の全体の手順について説明しましたが、各チームメンバーが課せられた役割を全うしてはじめて、効果的に「スクラム」のフレームワークが機能します。
「スクラム」は少人数のチーム制で運営され、「プロダクトオーナー」「スクラムマスター」「開発チーム」の３つのポジションで構成されています。
それぞれの役割について詳しく解説していきましょう。
プロダクトオーナーは、プロジェクトの全責任を担います。スクラムチームの全体を統括、プロジェクトのビジョンを設定しメンバー全員に共有します。
プロジェクトの方向性やミッションについて誤解が個々に生じないよう、わかりやすく明確に表現し、実際に行う作業を指示しなければなりません。
また、プロダクトにどんな機能が必要なのか割り出し、優先順位の高い順にタスクを並び替えるなど、全体のスケジュール調整や予算管理などを行って作業の価値を最適化していきます。
プロジェクト内の最終決定は、プロダクトオーナーの意志を尊重しなければなりません。プロダクトバックログのタスクについて優先順位の変更が生じる場合は、必ずプロダクトオーナーに相談する必要があります。
スクラムマスターは、プロダクトオーナーと開発メンバーの間に立ち、双方の支援型リーダーとしての役割を担います。
スクラムの理論や実践、ルール、価値の定義を、チームメンバー全員に理解してもらえるよう、個々人に合った効果的な方法でコミュケーションを促します。
具体的な支援内容は、開発メンバーが無理な要望によるタスク増で残業などストレスがかかる場合、プロダクトオーナーに相談を持ちかけて作業環境を整えます。
また、効果的なプロダクトバックログの管理方法を模索することでプロダクトリーダーの支援をします。いわゆる、縁の下の力持ちとしてチームを支えているのです。
スクラムマスターは開発メンバーと兼任することも多く、作業の進捗をリアルに把握することでスケジュール管理にフィードバックできるメリットがあります。
現場視点を持つことは、チーム全体のモチベーションアップに大きく貢献します。
開発メンバーは、実際にプロダクトの開発を行うことを担います。
主に10人以下の少人数で構成され、メンバーに肩書や序列など上下関係は一切なく、全員が平等な立ち位置です。
メンバー全員に、設計、ドキュメント作成、コーディング、テスト、運用と、エンジニアとしてある程度成熟したトータルスキルが求められます。
苦手分野がある場合は、スクラムマスターと相談しながら他メンバーとスキルを補完し合いつつ、プロダクトの完成を目指します。
チームの役割分担を明確にし、密なコミュニケーションをとることで「スクラム」の効果が得られます。
しかし、作業状況や日々変化する情報の伝達頻度の多さが、逆にストレスを引き起こすのではないだろうか？と疑問に感じる方もいらっしゃるのではないでしょうか。
この章では「スクラム」のメリットとはどういうものなのか、具体的に解説していきます。
「スクラム」では、スプリントの期間が短く、必要な機能を優先立てて開発を進めるため、プロダクトに対して顧客から早期にフィードバックを受けられるといった特徴があります。
これによって、作っている機能が正しいのかどうか定期的に顧客に確認してもらうことで、開発途上でも早期に軌道修正でき、その流れで早期リリースできることにつながるのです。
「スクラム」では、スプリントごとに作業工程の計画を立てるため、工数見積もりの精度が高くなり、正確性がアップします。
また、タスクごとに微細な調整をすることも可能なので、仕様変更や追加へも柔軟に対応できるのも魅力のひとつです。
スプリントごとに開発メンバーにタスクを割り振り、各メンバーがみずから工数見積もりを立てて期限を設けるため、一人ひとりがより自立的にプロジェクトを遂行する姿勢になります。
スプリントプランニングミーティングでは、プロダクトオーナーと議論しながらタスクの優先順位を決めます。
デイリースクラムでは、自身が見つけた課題についてどう改善するかをチーム全体で話し合います。
すなわち、メンバーの発言の一つひとつがプロダクト開発のクオリティを高めることにつながるので、自身の担当タスク以外にも視野を広げる必要があります。
チームの成果をいちばんに考えて開発を進めていくため、自立的なチームづくりが促進できるのです。
「スクラム」では毎日ミーティングを開催します。どんな小さなこともでも「わからないこと」「困っていること」をその都度素直に話すことが推奨されています。
そのため、チーム内で問題が発生している場合でもすぐに検知し、チーム全体で解決に導くことができます。
どんなにチーム全体のスキルが高くても、「スクラム」の本質を理解していなければ最高のプロダクトを完成することはできません。
そこで「スクラム」をスムーズに運営するために注意しておくべきポイントを２つ挙げます。それぞれ解説していきましょう。
役割分担がしっかりできていれば、必ずしも滞りなくプロジェクトが進行するというわけでもないようです。
プロダクトを確実に完成させるためには、メンバーは、「プロダクトオーナー」「スクラムマスター」「開発チーム」それぞれのポジションの役割についてしっかりと理解することが大切です。
誤った理解のままプロジェクトを進めると、自己判断でビジョンの設定を変更したり、タスクを増やしたりするなど、開発途上でチーム全体として混乱を招いてしまいます。
最悪の場合は、スケジュール通りに作業が進まず、プロダクトが完成しないことも。
プロジェクト成功のためには、メンバー全員がそれぞれの役割についてしっかりと理解を深めることが不可欠なのです。
メリットの多い「スクラム」ですが、ひとりでもルールから逸脱した行為をするとチームプレーがうまく働かず、結果的にプロダクトの質を下げることにつながってしまいます。
いってみれば、「スクラム」のルールやその意味をメンバー全員が正しく理解していればうまくいきます。理解不足のメンバーがいるのであれば、ルールを正しく把握してもらうためにしっかりと説明をする必要があります。
開発に着手する前に、大元の「アジャイル開発」について理解を深めることが鉄則です。「アジャイルソフトウェア開発宣言」で共通の価値と原則、「アジャイルソフトウェアの12の原則」には、開発を進めるための具体的な心構えについて書かれています。
あわせて、メンバー全員が何でも話しやすい環境をつくることも大切です。チーム一丸となって目標を達成するために、意識的に風通しの良い人間関係を構築していきましょう。
「スクラム」は、チームのコミュニケーションを重視した手法を用いたフレームワークのひとつです。現場に合わせてカスタマイズできるのが魅力です。
しかし、はじめて「スクラム」を導入しようとする際は、チームメンバー同士の相性などうまくいくのだろうかと、不安も大きくなるものです。
失敗を回避するためには、まずは「スクラム」のルールをチーム全体で理解を深めることを重視したいものです。円滑なコミュニケーションをとりつつ、顧客に最高のプロダクトを提供していきましょう！
画像出典元：Burst、PEXELS
