「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

順番に見ていきましょう。
まずは予備知識として「アジャイル」について説明します。
「そんなの説明されなくても知ってるよ！」な人は適当に読み飛ばしてください。

アジャイルは、大雑把に言うと「作りながら考えましょう」なやり方です。
システム開発のやり方のひとつです。

もともと、システム開発というのは

１．きっちりヒアリングして～
２．きっちり設計して～
３．きっちり作って～
４．きっちりテストして～
５．完成＼（－－）／

な流れでやるのが一般的でした。
基本的には工程の後戻りをしない（実際には、よくあるけど）やり方が主流だったのです。

このようなシステム開発のやり方を「ウォーターフォール型」と言います。
水が高いところから低いところに流れ落ちるように、最初の工程から最後の工程に向かって1つずつ順番に終わらせていく やり方です。



ウォーターフォール型はウォーターフォール型で良い面もあります。
ただし、弱点もありました。
それは「予定通りに進まないと困る」という点です。

ウォーターフォール型は工程の後戻りを想定していません。
極端な話をすると、完璧な設計をやり、その完璧な設計に従って完璧に作り上げ、その完璧に作り上げたものを完璧にテストして完成させるやり方です。

とはいえ、現実的には、作っている最中で「あれ？この設計だとマズくない？」と気付くこともありますよね。
そうなると困ります。
工程の後戻りを想定していないために予定が崩れるからです。

そこで「予定通りに進むことなんて、あるわけないじゃん？」と開き直った人が

１．お客さまの要望を、ある程度ヒアリングして～
２．何となく作ってテストして～
３．お客さまに見せて～
４．１に戻る
５．１～４を繰り返して、それっぽくなったら完成＼（－－）／

なやり方を考えたのです、多分。
それが「アジャイル」な開発手法です。

注意点として

「アジャイル」は開発手法の総称

です。
一口に「アジャイルな開発」と言っても、実際のやり方は いろいろ あります。

以上を踏まえて

アジャイルなシステム開発のやり方

のひとつが「スクラム」です。
名前の由来はラグビーのスクラムです。

スクラムの具体的なやり方については、他のところで勉強してください。
頑張っていろいろな説明を読んだのですが、人に噛み砕いて説明できるほどには理解できませんでした。



まずは

アジャイルなやり方のひとつ

という点を押さえてください。
それが一番の基本です。

あとは登場人物として

１．プロダクトオーナー
２．開発チーム
３．スクラムマスター

が出てくるとか

１．プロダクトバックログ
２．スプリントバックログ

の2つのバックログを使うとかでしょうか。

細かい部分は必要になったときに調べれば良いと思います。

ちなみに、この説明を書いた状況ですが、スクラムのちゃんとした（？）定義や具体的なやり方は

https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

に書いてあります。
この内容を理解できれば、スクラムについてはバッチリ理解できたことになるはずです。