スクラム開発(メリット・デメリット)

スクラム

この記事では、

・なんでスクラム開発が流行っているの?
・スクラム開発のメリットは何?
・スクラム開発にデメリットはないの?

と疑問に思っている方に

・スクラム開発の特徴、メリット、デメリット
をなるべく簡単に説明します。

この記事を読むと以下のことがわかります。

この記事で読んでわかること!
  • ウォーターフォール開発と比較した時のスクラム開発の特徴
  • スクラム開発のメリット
  • スクラム開発のデメリット

スクラム開発の概要を確認しておきたい方は以下記事をご確認ください。

【簡単解説】5分でわかるスクラム開発
アジャイル開発のフレームワークである「スクラム開発」に関する概要をまとめました。会社などで「スクラム開発って何?」と聞かれた時に、困らないように5分で概要を理解できるようにまとめています!商談前、トイレの中、通勤中などの空き時間に是非ご覧ください。

ウォーターフォールとアジャイルの違い

なぜ「スクラム」なのか?を語る前に、
そもそものウオーターフォールとアジャイルの違いを説明させてください。

ウォーターフォールの場合すべての機能を工程ごとに進める

アジャイルの場合:すべての工程を機能ごとに進める

ウォーターフォール開発は、これまで多くのソフトウェア開発で活用されている手法ですが、
テスト工程で設計ミスが発覚した場合や仕様変更が発生した場合に、
手戻りが大きく、修正コスト増となることが問題でした。

一方、アジャイル開発は、必要としている機能から全ての工程を実施し開発を行なっていくため、
テスト工程で設計ミスが発覚した場合や仕様変更が発生した場合でも、
最小単位で開発しているため、手戻りも小さく、修正コストも少なく済みます。

そのため、現代の日々環境が変化する市場においては、
柔軟にゴールを変更できるアジャイル開発(スクラム開発)が効果的と考えらることが増え、年々アジャイル開発を採用するチームが増えています。

アジャイルの中で「スクラム」を選択する理由

数あるアジャイル開発手法のうち、
スクラムを選択する理由は以下です。

  • その他のアジャイル開発手法の中でも、マネージメントにフォーカスしている。
  • ソフトウェアを重視しているアジャイル開発手法ともコラボしやすい。
  • SAFeやDADなどの大規模向けのアジャイル開発手法にも活用されている。
  • 使われているアジャイル手法のうち半数以上を占めている。
  • 資格や外部研修が充実している。


@15th State of Agile Report (P.13)

スクラムが66%と過半数を占めている
スクラム関連の手法も含めるとアジャイル開発のうち約8割がスクラムですね。

アジャイル開発の導入率やチーム推移・経験数などは、アジャイル開発レポートを参考に以下記事にまとめています。

アジャイル開発 レポート 2021年7月
2021年7月9日に15回目のアジャイルレポートが公開されましたので、印象的だったものを簡単にまとめてさせていただきます。アジャイルの導入チーム数、アジャイル導入時の恩恵・メリット、逆にアジャイル導入時の障壁など、どれも参考になるデータばかりでしたので、是非ご確認ください。
とも坊

要は、汎用性が高くて、学習しやすいから、多くの企業や団体で使われてるってことね!

スクラム開発のメリット

細かいメリットはたくさんありますが、特徴的なものを選択して記載します。

  • すぐに開発を始められる。
  • スプリント単位でスクラムイベントを実施することを繰り返すため、開発リズムと学習サイクルが生まれる。
  • フィードバックを繰り返し反映させることで、目的に適した(価値のある)プロダクトを開発できる。(検査と適応)
  • 定期的に動くものを見ることができるので、プロダクトのイメージがしやすい。
  • スプリント単位で振り返りを実施するため、チームやプロセスの問題にすぐ気づける。
  • 役割と責任が明確化されているため、チームメンバーが効果的に働ける。(学習効果も高い)
  • 「スクラムガイド」が無料で公開されているため、誰でも実践できる。

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

結論から言うと、完全にデメリットと言えるものはないと思います。
ただし、スクラム開発に不向きな案件やスクラム実施時の注意点はあります。

    [不向き]
  • 予め開発スコープや実装する機能が明確に決定しているもの。
  • 細かくユーザーのフィードバックを得る必要がないもの。
  • 業務内容が極めて複雑で、品質に問題があるとクリティカルな影響が出るもの。

  • [注意点]
  • 「スクラムガイド」のルールにプラスして、チームやプロダクトの状況に合わせて、必要な要素やプラクティスを適応していく必要がある。
  • ステークホルダーの期待とチームの行動や成果がミスマッチすることがある。
  • 短いサイクルを繰り返している間に全体像が見えづらくなり、開発の軸がズレたり、スケジュールのコントロールが難しくなることがある。
  • スクラムでは要求の追加や変更を受け入れられるので、気がつかないうちにチームのキャパシティを超えたスコープになってしまうことがある。(不要な機能は捨てる選択をする必要がある)

もちろん上記のデメリットを軽減させる・発生するリスクを減らすためのプラクティスは準備されています。

※ プラクティスは別記事を作成する中で順次紹介していきます。

スクラム以外の代表的なアジャイル手法

こちらはおまけですが、
スクラム開発以外の代表的なアジャイル手法2つ紹介します。

エクストリーム・プログラミング(XP)

アジャイル開発の先駆けとなった開発手法です。
スクラムガイドの作成にも携わったケント・ベック氏が提唱したものです。
5つの価値(コミュニケーション、シンプルさ、フィードバック、勇気、尊重)を重視し、
開発者が行うべき実践方法や原則を12のプラクティスとしてまとめています。

ユーザー機能駆動開発(FDD)

ユーザー目線で価値のある機能を中心に開発を進める手法です。
ジェフ デ・ルーカ氏が発案したもので、
ユーザーに価値のある機能をfeatureとしてリストアップし
featureごとに6つのマイルストーンを定義し順次完了させて行きます。

まとめ

  • アジャイル開発は、すべての工程を機能ごとに進めるため、手戻り・修正コストが少なく済む。
  • スクラム開発は、他の開発手法とも相性が良いため、アジャイル開発の中で最も選ばれている。
  • フィードバックを繰り返し反映させることで、目的に適した(価値のある)プロダクトを開発できる。
  • 要求追加や変更を受け入れやすいので、チームのキャパシティを超えたスコープになってしまうことがある。(不要な機能は捨てる選択をする必要がある)
Sponsored Link

コメント

タイトルとURLをコピーしました