変化が激しい近年の開発ではリアルタイムに要件が変わってくるケースなども出てきています。特にモバイルアプリケーションやWebアプリケーションではその傾向が多いでしょう。現在ではシステム開発の方法はウォーターフォール型以外にも様々な開発フレームワークがあります。その１つが今回紹介するスクラム開発です。スクラム開発はアジャイル開発の亜種のようなフレームワークですが、より柔軟に対応出来るようになっています。
この記事ではスクラム開発とは何か、どのような特徴があるのか、どのように進めていくのかなどを紹介します。
スクラムについて
まず、ここではスクラム開発とは何かについて紹介します。
アジャイル開発の一種「スクラム」とは何か
スクラム開発とはアジャイル開発の一種になります。まずはアジャイル開発に関して簡単に紹介します。
アジャイル開発とはソフトウェア開発において用いられる開発手法であり、お客様の業務に影響を与えるような根幹業務から開発を行います。開発する際には事前に優先順位を決めておき、その優先順位に沿って小規模開発（要件定義・設計・開発・テスト・運用の一連のサイクル）を繰り返していく手法になります。
スクラム開発では、このアジャイル開発に少し手を加えた開発手法になります。まず、スクラム開発ではスプリントという小期間に区切って開発を行います。このスプリントは開発担当者の開発リズムを保つため常に一定期間にしておくことが求められます。そのため、開発項目を一覧化する際にはこのスプリントを満たすように項目を設定する必要があります。また、一定間隔で開発を行うだけでなく、チームで開発を行う点も特徴的です。スプリントの中で必要となってくる機能も様々ですので、これらの機能をチームごとに振り分けて開発を行います。そのため、チーム間で連携をすることも非常に大切であり、適切なコミュニケーションが求められます。その一方でチーム一人ひとりまで詳細に役割を決めることになるため、様々な作業を並行して進めることができ、開発の効率化を促進します。
アジャイルとスクラムの違い
アジャイル開発とスクラム開発の違いをここでは、紹介します。まず最初にですが、アジャイル開発の中にスクラム開発があります。そのため、スクラム開発もアジャイル開発の一つに該当します。その点を踏まえ、スクラム開発と他のアジャイル開発との違いは以下のような点が挙げられます。
開発期間の違い
アジャイル開発そのものでは小規模で要件定義から開発、リリースまでの一連のプロセスを行うことは決まっていますが、期間の幅は毎回のサイクルごとに変わります。一方、スクラム開発では開発担当者のテンポを重視しており、常に一定期間でのサイクルで開発が行われます。
チーム連携の違い
スクラム開発という名前からもわかるようにチーム単位で協力しあって開発を行っていく体制になっています。そのため、コミュニケーションプロセスなどがアジャイル開発に比べて強化される傾向にあります。４章の「具体的な開発の流れ」で詳細について触れていきます。
仕様変更対応力の違い
アジャイル開発は基本的に最初に開発工程の全体感が決まっています。そのため、サイクル的に開発を進めるものの、大きな変更は難しい傾向にあります。一方、スクラム開発ではバックログという今後の作業一覧を管理し、常にクライアントの要望を更新して最新の状態にします。そのため、大きな変更要望が発生しても、バックログに取り込むことで、対応することが出来ます。
スクラムの起源
スクラムというのはもともとはラグビーのスクラムからきている言葉になります。ラグビーのスクラムではチーム一人ひとりの役割が明確であり、その全員が一体となることで、ボールを奪取または保持することに繋がります。
実際にこのスクラムという言葉をシステムの用語として使い始めたのは１９９３年です。この年にジェフ・サザーランド氏とケン・シュエイバー氏の二人がスクラムガイドと呼ばれる、スクラム開発の基本方針をまとめた資料を作成し、１９９５年に正式なフレームワークとして認められたことで、その開発手法名が広がりました。
スクラムの開発体制
ここではスクラム開発ではどのようなメンバーが関わることになるのか、チーム体制を紹介します。
プロダクト・オーナー
１人目がプロダクトオーナーです。プロダクトオーナーはこのスクラム開発の全責任を負うことになります。主な作業はプロダクトバックログの管理です。このプロダクトバックログを適切に管理するために以下のような作業を行います。
- ステークホルダー（クライアントなど）から要件のヒアリングを適宜実施する
- 要件をスプリント単位で開発できるように分割する
- プロダクトバックログの優先順位などを適宜、関係者（クライアント、開発担当者）と調整し、合意を得る
- プロダクトバックログの項目が完成したかどうかを確認する
そのため、常にステークホルダーにとって最良のプロダクトはなにかを考えていくポジションになります。
スクラム・マスター
次にスクラムマスターです。スクラムマスターとは開発側の責任者です。毎回のスプリントで消化しなければならない、プロダクトバックログの項目に対して責任を持つことになります。１スプリントを成功に導くために以下のような作業を行います。
- システム開発の指揮やマネジメント
- 各チームのエンジニアの進捗状況の確認
- 開発やテスト時に問題が発生した際の対応策の検討
- プロダクトオーナーへの状況報告
開発側のマネージャーポジションとしてエンジニアを適切にコントロールし、バックログ項目の消化を目指します。
テックエンジニア
次はエンジニアです。開発を行う主力メンバーであり、一人ひとりが自分の役割を達成することが求められます。基本的には３人～９人ぐらいのチーム体制をとっており、全員揃うと一つの機能が完成に導けるスキルセットになっています。また、エンジニアだけでなく、デザイナーなどもこのポジションで一緒に開発を行っていきます。
ステークホルダー（利害関係者）
ステークホルダーとはクライアントやユーザーなどの関係者になります。基本的には資金提供をしている会社やそのシステムに接続する他のシステム担当者などが含まれます。要件定義やテストフェーズでは関係することがありますが、あまり開発には関与しません。しかし、プロダクトバックログの作成などには強い権限を持つ場合もあります。
スクラム開発の特徴
ここではスクラム開発の特徴について触れたいと思います。
軌道修正を前提とした開発
スクラム開発では軌道修正を前提とした開発を行います。軌道修正を行う場合にはバックログを最新化してどのように軌道修正を行っていくかの方向性を明示します。このように細かく軌道修正が出来るのはスクラム開発の特徴と言えるでしょう。
開発対象の具体化・明示化
スクラム開発はいかにスプリントをスムーズに行うかが課題になってきます。そのため、プロダクトバックログに記載する際には何を開発するのか、どの機能を開発するのかなどを徹底して具体化します。
この具体化、明示化の作業は期間が縛られているスクラム開発ならではの特徴であると言えるでしょう。
ミスやバグを未然に検知
スクラム開発では細かく開発からテストの流れを繰り返します。そのため、テストの頻度が増え、大きなミスやバグなどは事前に検知することができ、大きなやり直しをすることがなく、開発を行うことが出来ます。
具体的な開発の流れ
続いてスクラムを取り入れた開発はどのようなものか、詳説します。
開発対象のリストアップ・バックログ作成
まず開発を進める前に開発対象のリストアップを行います。そして、そのリストアップをされたことをスプリント単位に分割してバックログの作成を行います。これらの対応は基本的にはプロジェクト・オーナーなどのマネジメント層とステークホルダーが中心となって継続的に作業を行います。
スプリント計画の立案・策定
プロダクトのバックログが一通り作成完了したら、スプリント計画の策定に入ります。バックログの一番優先度が高い作業から実施します。このフェーズではこのスプリント内のタスクや成果物を洗い出し、何をするべきかを明確にしていきます。また、計画の策定ではスクラムマスターが中心となってタスクをブレイクダウンして、担当エンジニアが理解でき、スムーズに作業を着手できる体制を整えていきます。
実際の開発
ここでは、実際にテックエンジニア及びテックエンジニア配下のプログラマやコーダーが開発作業を行います。課題や問題点がある場合、速やかにスクラムマスターや周囲のメンバーに相談を行い、作業を進めていきます。
デイリースクラム
デイリースクラムとは日々行うメンバー内のミーティングのことです。このミーティングは短時間で行い、進捗報告と本日行う作業などを共有します。また、課題が発生した場合では、この場で報告のみ行い、解決にあたっては関係者のみを集めて別途ミーティングを開くのが一般的です。
スプリント検証・レビュー
実際に開発テストまで実施を行い、今回開発した機能のレビューを行います。レビューでは内部メンバーでも行いますし、実際にステークホルダーに確認してもらうケースもあります。このレビューを実施し、機能のリリースがなければ、このスプリントは終了、リリースが必要な場合にはリリースをして終了となります。
レトロスペクティブ
レトロスペクティブとは「ふりかえり」という意味で、今回行ったスプリントの評価を行います。スクラム開発では繰り返しスプリントを行うため、この評価という作業は非常に重要になります。このレトロスペクティブは基本的にスプリント最終日に行われ、今回発生した課題や問題点が次のスプリントでは発生しないように対策を行います。
スクラム開発のメリット
ここまでスクラム開発の具体的な開発の流れを見てきました。次にスクラム開発を導入するメリットを見ていきます。
高品質なプロダクトを生み出せる可能性が高い
１点目が質の高いプロダクトを生み出せる可能性が高いというところです。プロダクトバックログの作成やスプリント計画の策定により、常に何をするべきかが明確になっています。また、この段階では一人ひとりの能力に合わせた作業を任せることになります。そのため、エンジニアは全員自身の生産性を最大化することができ、結果的に期間内で開発出来る最高品質のプロダクトを作成できることになります。
仕様変更、軌道修正に強い
スクラム開発は仕様変更に対して柔軟に対応することが可能です。ウォーターフォール型の開発では開発段階が始まったら、要件定義にさかのぼることはしないため、基本的に仕様を大規模に変更することは出来ません。アジャイル開発でも、事前にある程度の要件が決まっている段階から、優先度をつけて対応する方法が主流となるため、仕様変更にも限りがあります。一方、スクラム開発では常にプロダクトオーナーがステークホルダーとコミュニケーションをとり、仕様変更を反映したプロダクトバックログを作成しています。そのため、大規模は仕様変更においても、プロダクトオーナーと調整できれば対応可能なため柔軟性が高いです。
PDCAサイクルの高速回転が可能
スクラム開発は数週間から１か月単位のスプリントで開発を行うのが主流です。1つのスプリントごとに都度レトロスペクティブをはさみ、課題や問題点の改善を行うため、開発のPDCAサイクルを迅速に回すことが出来ます。PDCAサイクルを迅速に回せるのは開発効率の向上だけではありません。作成したプロダクトを速やかにリリースすることで開発したらすぐユーザーに使ってもらうことができ、プロダクトの検証も速やかに行うことが出来ます。もし、検証した結果、修正が必要であると判断したらプロダクトバックログに優先度「高」で追加をすることもでき、修正も容易です。
認識齟齬を未然に防止できる
スクラム開発ではエンジニア一人ひとりのやるべきことが明確です。そのため、認識齟齬なく仕事をすることが出来ます。また、もし認識齟齬が発生していた場合にもデイリースクラムの場などで進捗状況と今日やることの認識合わせを行えるため、問題を素早く検知することができ、軌道修正が図れます。
スクラム開発のデメリット
メリットをみると、魅力的に見えるスクラム開発ですが、デメリットも存在します。ここではスクラム開発のデメリットや欠点について触れていきます。
スクラムメンバーの力量次第なところがある
１つ目はメンバーの力量に左右されることがある点です。スクラム開発ではテックエンジニア一人ひとりに明確に役割が与えられているため、この役割を達成する技術がないテックエンジニアをアサインしてしまうと、プロジェクト自体がうまくいかなくなる可能性があります。
スクラム開発を導入する場合、メンバーがどのようなスキルセットを持ち、十分な経験や力量があることを確認することが不可欠です。
状況によってプロジェクトが遅延しやすい
スクラム開発ではプロダクトバックログというものでスケジュールを管理していくことになります。そのため、全体感が見えにくいという特徴があります。改修や仕様変更が重なってしまうとプロダクトバックログ自体の管理が煩雑となり、元の目的を見失ってしまう。その結果、いつの間にかプロジェクトが遅延しているということがあり得ます。
大規模開発には不向きな点がある
スクラム開発は大規模開発には不向きです。これには大きく２つの要因があります。
１つ目は全体スケジュールの把握が困難になるということです。「状況によってプロジェクトが遅延しやすい」というテーマも扱った通り、大規模になればなるほどプロダクトバックログ自体の管理が複雑になります。その結果、いつの間にはプロジェクトが遅延しているなどの問題が発生します。
２つ目はコミュニケーションコストです。それぞれのメンバーが互いにコミュニケーションを取らなければならないスクラム開発では、開発規模が大きくなればなるほど、コミュニケーション量が多くなり、最終的にコミュニケーションに押しつぶされてしまう可能性があります。
以上から、スクラム開発は大規模開発には向かない側面があります。
スクラム習得の難度が高い
全体としてスクラム開発ができるチームを構築するのは難度が高い傾向にあります。一人ひとりのスキルや情報のキャッチアップ能力、コミュニケーション能力などを的確に把握し、チームを作り上げなければなりません。エンジニア一人ひとりもスプリント単位で成果物を作り上げなければならないため、一定のスキルが求められます。そのため、必要な技術者を揃えて、チームを作り上げるのが難しい傾向にあります。
まとめ
本記事では、スクラム開発の特徴やメリット・デメリット、開発の流れを紹介しました。スクラム開発は人材確保に依存するところもありますが、仕様変更に柔軟に対応が出来ることなど、短期的な成果が求められるスマホアプリやWebサービスでは非常に効果的な方法と言えます。一方、大規模な基幹システム開発などではこれまで通りウォーターフォール型開発の方が相性が良いという見方もあります。どのようなプロジェクトであれ、まずは現状分析・現状調査を行い、最適な開発手法を導入することが肝要です。
—————————————————————————————————————
システム開発、アプリ開発、新規事業立ち上げ、DX化の推進でお困りではありませんか？
日本全国には開発会社が無数にありますが、Webサービスやアプリサービスのスケール（規模拡大）を実現するビジネス推進力やシステムの堅牢性、可用性を意識した設計力・技術力を合わせ持つ会社は、全国で見ても多くはなく、弊社は数少ないその一つ。お客様のご要望通りに開発することを良しとせず、お客様のビジネス全体にとって最適な解を模索し、ご提案ができるビジネス×テック（技術力）×デザインの三位一体型のシステム開発/アプリ開発会社です。ITやDX全般に関して、何かお困りのことがございましたら下記の「GeNEEへのお問合せ」フォームからお気軽にご連絡いただけたらと思います。
—————————————————————————————————————
