非エンジニアでも3分でわかる開発用語④ スクラム
2021.03.03
こんにちは。mofmofで数少ない非エンジニア・高梨です。
エンジニアはわかって当たり前のシステム開発用語。
今まで開発にあまり携わったことのない人にとっては、カタカナや専門用語が多くてちょっと引けてしまう…なんて事ありませんか？
- 新規事業のアイディアがあって相談してみたいけど、開発用語が全然わからないからうまく話せるか心配…
- 専門用語をわかった上で、開発に関する相談をしたいけど、カタカナが多くて辛い…
そんな方におすすめ！「非エンジニアでも3分でわかる開発用語」第4弾は、mofmofの月額制受託開発「開発チームレンタル」でもよく耳にする「スクラム」に注目！今回の記事は2020年更新版のスクラムガイドとmofmofの入社時研修でも利用している「スクラムとモジャイル」を参考にまとめてみました！
スクラム＝アジャイル開発で人気な開発手法の一つ
スクラム？なにそれスライム？ラグビー？？いえいえ、今回ご紹介するのは、スライムでもラグビーのスクラムでもなく、「スクラム開発」です。
スクラム開発は、いわゆるアジャイル開発と呼ばれる開発手法の一つです。アジャイル開発には、エクストリームプログラミング・機能駆動型開発を含むいくつかの手法が存在します。中でも人気な開発手法の一つがスクラム開発なのです。
ことソフトフェア開発においては、確実に予測し計画するということが難しいことがほとんどです。
スクラム開発は、「経験主義（理論より自己の経験を重視する）」と「リーン思考（無駄を取り除く）」をベースに、起こりうるリスクを予測しそのリスクを最小限にすべく、短い期間で反復的にアプローチします。そのため、不確実性の高いプロダクト開発に用いることで効果を発揮しやすく、現在多くの開発会社で活用されているのです。
現に、mofmofの開発でも取り入れています。mofmofでは、スクラム開発をそのまま使うのではなく、mofmofにあった形にカスタマイズした「モジャイル開発」として運用しています。
（モジャイル開発にご興味のある方はこちらに概要がまとまっているので、ぜひご覧ください！）
スクラムガイドによるスクラムの定義は、「複雑な問題に対応する適応型のソリューションを通じて人々・チーム・組織が価値を生み出すための軽量級フレームワーク」とされています。非エンジニア人材の筆者には難しい言葉だったので、筆者なりの解釈でまとめると「複雑な計画やプロダクト開発を成功に導くために生まれた人・チーム・組織のシンプルな枠組み」といったところでしょうか。
スクラムチームの登場人物
スクラムチームは、【スクラムマスター1 人＋プロダクトオーナー1 人＋複数人の開発者】で構成され、通常10名以下です。
「ひとつの目的(プロダクトゴール)に集中している専門家が集まっている」という考え方に基づき、チーム内にはサブチームや階層は存在しません。
プロダクトオーナー（PO）
- プロダクトの価値を描いて伝え、プロダクトの価値の最大化に責任を持つ
- 問題に対応するための作業をプロダクトバックログに並べ、効果的な管理に責任を持つ
- スプリントおよび全体進捗を評価する
詳しくは「アジャイル（スクラム）開発でのプロダクトオーナーとその役割」をご覧いただくとわかりやすいです！
スクラムマスター
- スクラムプロセスの遂行に責任を負う
- ファシリテーションを行う
- 会社によっては一つの職種として雇用している企業もある
（ちなみに、認定スクラムマスターという資格も存在する） - 開発者やPOは原則兼任しない
モジャイル開発では2〜3名程度の少人数チームであることから、専任のスクラムマスターを置かないことが多く、エンジニアが自律的にプロジェクトを進行しています。
開発チーム
- プロダクトを開発するメンバー
- エンジニアだけでなくテスターも含まれる
- スプリントの計画（スプリントバックログ）を作成する
- スプリントゴールに向けて毎日計画を適応させる
- どのように開発していくかは自律的に判断し、専門家として互いに責任を持つ
スプリントに関しては以下の5つのスクラムイベントにて解説しています。
※スプリントバックログとは？
スプリントの進捗状況の変化を理解できるようにするため「なぜ」・「何を」・「どのように」を明確にした開発者（開発チーム）のためのタスクリスト。
※プロダクトバックログとは？
プロダクトの改善に必要なものの一覧で、一つ一つの要素だけで考えるのではなく、要素同士の相互関係を意識し、より価値を生み出しやすい順番を意識する。
操作するのは原則プロダクトオーナーが行う。
スクラムチームが行う作業の唯一の情報源で、1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングでの際には細分化されている。
関係者がいつでも内容を思い出せるようにすることを目的としている。
スクラムを大まかにまとめてみよう
それでは、スクラムの大枠を解説していきます！
スプリント（開発期間の単位）
スプリントは開発期間の単位です。
1ヶ月以内の決まった期間で設定します（短くて1週間。長くて1ヶ月）。
前のスプリントが終わり次第、新しいスプリントが始めます。そのためスプリントが重なるといったことはありません。
スプリント内で実施されることは以下になります。
- スプリントプランニング
- デイリースクラム
- スプリントレビュー
- スプリントレトロスペクティブ
スプリントプランニング（計画）
スプリントプランニングはスプリントの起点で、ここではスプリントで実行する作業の計画を立てます。計画は、スクラムチーム全体の共同作業で作成します。
プロダクトオーナーは参加者に対して、優先度の高いプロダクトバックログアイテムを提示・スプリントで開発を行う項目をチーム内での合意できるよう話し合いを進めます。また、これらがプロダクトゴールに対してズレが生じていないかを確認します。
スクラムチームは、アドバイスをもらうためにチーム以外の人をスプリントプランニングに招待してもよいとします。
計画を立てる際に必須なトピック
- このスプリントはなぜ価値があるのか?
- このスプリントで何ができるのか?
- 選択した作業をどのように成し遂げるのか?
スプリントが1か月の場合、スプリントプランニングは最大で8 時間。
スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多いです。
デイリースクラム
デイリースクラムは、スクラムチームの開発者のためのイベントです。そのためPOやスクラムマスターは、スプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加します。
特徴の一つは、スプリント期間中に毎日、同じ時間・場所で15分間開催することです。
開発者は、デイリースクラムでスプリントゴールに向けた進捗を（誰が何を着手しているか、問題が発生していないかなど）を全員確認します。このことで、開発者自身が1日の作業を明確にし、業務を透明化することが可能となります。また、コミュニケーションを改善・障害物を特定や迅速な意思決定を促進し、他に会議を開く必要がなくなります。
そして、開発者が計画を調整できるのは、デイリースクラムのときだけではありません。
スプリントの残りの作業を適応または再計画することが必要な場合に詳細な議論をする際は、開発者は一日を通じて頻繁に話し合います。
スプリントレビュー
スプリントレビューの目的は、スプリントの成果を検査し、ステークホルダーの許容範囲が逸脱していないか、またプロダクトが受け入れられているかを確認します。
スクラムチームとステークホルダーは、スプリントで何が達成され、自分たちの環境で何が変化したかについてレビューします。（成果物のデモ含む）
状況によってプロダクトバックログを調整し、次に何をするのかを議論し、次のスプリントへ繋げます。
スプリントレビューはワーキングセッションであり、スクラムチームはスプリントレビューをプレゼンテーションだけに限定しないようにします。スプリントが1か月の場合に最大4時間。スプリントの期間が短ければ、スプリントレビューの時間も短くすることが多いです。
スプリントレトロスペクティブ（振り返り）
スプリントレトロスペクティブ（振り返り）の目的は、品質と効果を高める方法を計画することです。スプリントレトロスペクティブを終えるとスプリントは終了します。
mofmofでは、KPTという振り返りフレームワークを利用しています。
スプリントが1か月であった場合は、スプリントレトロスペクティブは最大3時間。
スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くすることが多いです。
これ以上詳しく書くと3分では収まらないので、スクラムをもっと知りたい方は、記事の冒頭でもご紹介したスクラムガイドをぜひご覧ください！
また、スクラム開発に関連する記事を他にも見たいという方には、こちらがおすすめです！
・アジャイル（スクラム）開発でのプロダクトオーナーとその役割
・スクラムを採用するべきでない7つの理由(翻訳)
