スクラムとは

スクラムとは

スクラムは1か月以内の一定の期間で開発を区切り、期間ごとに動作するものを構築して計画を再検討する作業を反復するチーム開発の枠組みです。区切った期間をスプリントと呼びます。アジャイル開発と呼ばれる進め方の中で広く採用されている方式の1つで、決まりごとが少なく、細部のやり方はチームが決定する前提になっています。

チームは3つの役割で構成されます。何をどの順で開発するかを決定するのがプロダクトオーナー、実際に開発するのが開発者です。スクラムマスターはチームが決まりごとに沿って改善し続けられるよう支援します。役割であって役職ではありません。

アジャイル開発との関係

アジャイル開発は開発しながら決定していく考え方の総称で、具体的な手順までは定めていません。考え方に賛同できても、それだけではチームが毎週何をすればよいかは確定しません。確定していなければ、進め方は人によってばらつきます。計画をいつ立て直すのか、誰が優先順位を決定するのか、何をもって完成とするのかが曖昧なまま進行すると、結局は強く主張する人の要望で優先順位が変更され続けます。

スクラムはアジャイル開発を実践するための代表的な進め方の1つで、この曖昧さを具体的な決まりごとで解消しました。期間の区切り方、毎回必ず行う会議、3つの役割とそれぞれが負う責任を定めています。決まりごとはスクラムガイドとして公開されています。

発注側が関与する決まりごと

スクラムで進行する案件に関わると、スプリントごとに次の場が繰り返されます。

• スプリント計画: その期間に何を開発するかと、その期間の目標を決定する。プロダクトオーナーが出席する
• デイリースクラム: 開発者が毎日15分以内で進捗と計画の修正を確認する。開発者の場で、発注側は出席しなくてよい
• スプリントレビュー: できたものを関係者に提示し、次に何を開発するかを議論する。プロダクトオーナーに加えて、社内の関係者や役員も成果を確認できる
• レトロスペクティブ: チームの進め方を振り返り、改善点を決定する。プロダクトオーナーも出席する

開発対象の候補はプロダクトバックログという1つの一覧に集約します。その並び順の最終的な責任はプロダクトオーナー1人が担い、並べ替えの作業は他の人に支援してもらってもかまいません。スクラムガイドはプロダクトオーナーが委員会ではなく1人であること、組織全体がその判断を尊重することを求めています。どこまでできたら完成とみなすかの基準も事前に定め、基準を満たさないものは完成とみなしません。

効果

• 判断の場と日程が先に確定しているため、発注側はいつ何を決定すればよいかが分かり、判断待ちで開発が停滞しにくい
• 要望の窓口がプロダクトオーナー1人に集約され、部署ごとの要望が開発チームに直接届いて優先順位が乱れるのを防止できる
• 完成の基準を毎回守るため、ほぼできているという報告が積み上がらず、進捗を実物で確認できる
• 振り返りを毎回行うため、チームの進め方の問題が早期に判明する

コストとリスク

• プロダクトオーナーは毎スプリントの判断と日々の質問への回答のために時間を割き続ける。この負荷を計画に含めずに開始すると判断待ちで開発が停滞する
• 会議の時間が定期的に発生する。開発者の時間のうち一定の割合が計画、レビュー、振り返りに使用される
• 最初に全体の仕様と金額を確定させないため、外部に発注する場合は完成責任を負う請負ではなく、作業に対して支払う準委任で契約することが多い。契約形態の違いは要件定義で説明している
• IPAのモデル契約はプロダクトオーナーを発注側から、スクラムマスターを開発会社側から選出する形を想定している。発注側が開発会社の個々の技術者に直接作業を指示すると偽装請負とみなされるおそれがあり、厚生労働省の疑義応答集 第3集もアジャイル型開発を取り上げている。日々のやり取りで誰に何を依頼できるかを開発会社と定めておく
• 同じメンバーで継続するほど開発の速度が上がる進め方なので、チームを固定して人件費を払い続ける。案件ごとに人を交代させる体制とは相性が悪い
• チームを支援するスクラムマスターを担える人材は多くない。社内で育成するか外部から採用する費用がかかる
• 毎回動作するものを提供しようと急いで完成の基準を緩めると、後から修正する手間が積み上がる。その分だけリリース後の保守費が増加する

よくある誤解

スクラムなら計画や仕様書を必要としない

計画はスプリントごとに立て直すだけで、不要にはなりません。開発対象の一覧と完成の基準は常に最新の状態にしておく必要があります。仕様を文書として記録する量は削減できても、記録は省略できません。

スクラムマスターはプロジェクトの責任者

スクラムマスターはチームが進め方を改善できるよう支える役割で、開発するものの中身や納期を決定する立場ではありません。何を開発するかの判断はプロダクトオーナー、どう開発するかは開発者が担います。

ベロシティでチームの生産性を比較できる

報告に登場するベロシティは、1スプリントで消化したストーリーポイントの合計を指すことが多いです。ストーリーポイントはスクラムガイドの決まりではなく、チームが任意で利用する見積もりの手法で、数字の大きさはチームごとに異なります。チーム間で比較する意味はなく、評価に利用すれば見積もりが水増しされるだけです。重視すべきは事業の目標に近づくものが毎回生み出されているかどうかです。

一部だけ取り入れてもスクラムと呼べる

スクラムガイドは一部だけを実施することは可能でも、その結果はスクラムではないと記述しています。会議と役割の名前だけをそろえ、プロダクトオーナーに優先順位を決定する権限がないまま運営すると、会議の手間だけが増加して効果は出ません。うまくいかないときはどの役割や会議が欠けているか、プロダクトオーナーが自分で決定できているかを確認します。