スクラムとは?スクラムガイド2020年版で読む3つの責任・5つのイベント・3つの作成物【2026年版】

「スクラムで進めます、と言われたのですが、正直ついていけていません」——開発会社との打ち合わせから戻ってきた発注担当の方から、こうした相談をよく受けます。スプリント、プロダクトバックログ、インクリメント、デイリースクラム、レトロスペクティブ。一度に押し寄せるカタカナを前に、どれが公式の用語でどれが現場の言い回しなのかも分からないまま、会議だけが進んでいく。調べてみても、記事によって説明が微妙に違います。

先に結論を書きます。スクラムを理解する鍵は、用語を覚えることではありません。『3つの責任・5つのイベント・3つの作成物』という部品が、透明性・検査・適応という3本柱を成立させるために組まれている、という関係を見ることです。スクラムガイド2020年11月版は、スクラムを開発手法ではなく「軽量なフレームワーク」と定義し、意図的に不完全であると書いています。部品どうしの関係が見えれば、自分たちの運用のどこが壊れているかを自分で特定できるようになります。

この記事では、スクラムガイド2020年11月版を一次情報として、定義とアジャイルとの関係、3つの責任、5つのイベント、3つの作成物、そして「名ばかりスクラム」と区別するための5つの問いを順に扱います。あわせて、ガイドに書かれている語と、ベロシティのように現場で広く使われている慣習語を分けて示します。なお、スクラムを外注するときの契約形態や、発注者がプロダクトオーナーを担うときの実務は本記事の範囲外です。そちらは「アジャイル開発 外注」の記事で扱っています。

私はTALENTBASE VIETNAMでCOOを務めています。人材業界の出身で、2018年からベトナム・ホーチミンに住み、約100社の開発体制づくりを支援してきました。当社が提供しているのはラボ型開発、つまり月額で専属チームを確保する形で、反復型で進める案件が中心です。「スクラムでやりたい」とご相談をいただいたとき、当社が最初に確認するのは用語でもツールでもありません。優先順位を1人で決められる方が発注側にいるか、そして何をもって完成とするかを文章にできるか。この2点です。

読み終えたら、自分のチーム(あるいは発注先のチーム)で、3つの責任・5つのイベント・3つの作成物のうち何が欠けているかを数えてみてください。欠けている数そのものより、検査と適応の機会がどこで失われているかが見えてきます。

スクラムとは——スクラムガイド2020年版が定義する「軽量なフレームワーク」

スクラムには原典があります。考案者であるケン・シュウェイバー氏とジェフ・サザーランド氏が公開している「スクラムガイド」です。最新は2020年11月版で、無償で公開されています。この記事は、この版を一次情報として書いています。まずは原典が何と言っているかから始めます。

定義: 複雑な問題に適応的な解決策で価値を生み出すための軽量なフレームワーク

スクラムガイド2020年11月版は、スクラムを次のように定義しています。複雑な問題に対して適応的な解決策を通じ、人々やチーム、組織が価値を生み出すことを助ける軽量なフレームワークである、と。

ここで押さえるのは3語です。ひとつ、対象は「複雑な問題」であること。あらかじめ答えが分かっている作業は対象外です。ふたつ、生み出すのは「価値」であって、成果物の量ではないこと。みっつ、スクラムは「フレームワーク」であって、手順書ではないこと。

ガイドは、スクラムの構造を次のように要約しています。プロダクトオーナーが複雑な問題に対する作業をプロダクトバックログに並べる。スクラムチームがその一部をスプリントの中で価値あるインクリメントに変える。スクラムチームとステークホルダーが結果を検査し、次のスプリントに向けて調整する。そして繰り返す——これだけです。登場人物と時間割が決まっているだけで、何をどう作るかは何も決めていません。

アジャイルとスクラムの関係——2001年の宣言が価値観、スクラムはその実装のひとつ

「アジャイルとスクラムは何が違うのか」は、この分野で最もよく聞かれる質問です。答えは上下関係です。

アジャイルの出発点は、2001年に公開された「アジャイルソフトウェア開発宣言」です。そこに書かれているのは4つの価値で、プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を価値とする、というものです。重要なのは、この宣言が「左記のことがらに価値があることを認めながらも、右記のことがらにより価値をおく」と明記している点です。ドキュメントを作らない、計画を立てない、とは書かれていません。ここを誤読したまま「アジャイルだから仕様書は不要」と進めるのは失敗のもとです。

宣言は価値観であって、やり方は書いていません。その価値観を実際に回すための具体的な枠組みのひとつがスクラムです。ほかにもエクストリームプログラミング(XP)やカンバンがあります。つまりアジャイルが上位概念で、スクラムはその実装のひとつという関係になります。なお、スクラム自体は1990年代前半から存在し、1995年にOOPSLAというカンファレンスで初めて公に発表されました。宣言(2001年)より先にあった手法が、後からアジャイルという言葉で括られたという順序です。

ウォーターフォールとの対比でいえば、違いは「何を固定するか」にあります。ウォーターフォールは作るものを先に固定して期間を調整し、スクラムは期間(スプリントの長さ)を固定して作るものを毎回調整します。どちらが優れているという話ではなく、要件を着手前に確定できるかどうかで選ぶものです。

「スクラム開発」という呼び方と、手法ではなくフレームワークであることの意味

検索では「スクラム開発」という言い方もよく使われます。原典にこの語はありませんが、日本の現場では定着した呼び方で、指しているものはスクラムと同じです。この記事でも同義として扱います。

より重要なのは、スクラムガイドが自らを「意図的に不完全である」と書いていることです。スクラムはスクラム理論を実装するのに必要な部分だけを定義していて、残りは使う人が埋める。見積もりの方法も、タスク管理ツールも、コードレビューのやり方も、スクラムは何も指定していません。だから「スクラムを導入したのに何をすればいいか分からない」という感想は、実は正しい反応です。スクラムは空いた枠組みで、その中に自分たちのやり方を入れるものだからです。

経験主義の3本柱——透明性・検査・適応と、5つの価値基準

スクラムの土台は経験主義です。知識は経験から得られ、意思決定は観察に基づいて行う、という考え方です。ガイドはこれをリーン思考(ムダを減らし本質に集中する)と組み合わせ、3本柱で支えると説明しています。

• 透明性: 進行中のプロセスと作業が、作業する人にも受け取る人にも見えていること。透明性が低い作成物に基づく判断は、価値を下げリスクを上げる
• 検査: 作成物と合意したゴールに向けた進捗を、頻繁かつ熱心に調べること。そのためにスクラムは5つのイベントというリズムを用意している
• 適応: 逸脱が見つかったら、プロセスか成果物をできるだけ早く調整すること

この3つは順番に依存しています。ガイドは「透明性なき検査は誤解を招き無駄である」「適応なき検査は無意味である」と書いています。つまり見えていないものは検査できず、検査しても直さないなら検査する意味がない。この因果が、後で出てくるすべてのイベントの存在理由になります。

加えてスクラムには5つの価値基準があります。確約(コミットメント)、集中(フォーカス)、公開(オープン)、尊敬(リスペクト)、勇気(カレッジ)です。精神論に見えますが、たとえば「勇気」がなければレトロスペクティブで本当の問題は出てきません。3本柱を実際に機能させるのは、結局こうした振る舞いです。

枠組みの説明はここまでです。ここから先は、その枠組みを構成する部品を順に見ていきます。

スクラムの3つの責任——プロダクトオーナー、スクラムマスター、開発者

スクラムに登場する人は3種類だけです。プロダクトオーナー、スクラムマスター、開発者。ここで注意したいのは、これらが役職ではなく「説明責任(アカウンタビリティ)」の単位だという点です。2017年版までは「役割(Role)」と呼ばれていたものが、2020年版で責任という言い方に変わりました。呼び方の変更に見えて、意味するところは小さくありません。

スクラムチームという単位——10人以下、階層なし、自己管理型で機能横断

スクラムの基本単位は、1つのスクラムチームです。構成はスクラムマスター1名、プロダクトオーナー1名、そして開発者たち。ガイドは、チーム内にサブチームや階層を作らないと明記しています。「設計チーム」と「実装チーム」に分けた時点で、それはスクラムチームではなくなります。

人数の目安は10人以下です。小さいほどコミュニケーションが良く生産的だというのがガイドの立場で、大きくなりすぎた場合は複数のスクラムチームに再編成し、同じプロダクトゴール・プロダクトバックログ・プロダクトオーナーを共有することを勧めています。

チームの性格は2語で表されます。機能横断(クロスファンクショナル)、つまりスプリントごとに価値を生み出すのに必要なスキルがチーム内にそろっていること。そして自己管理(セルフマネジング)、つまり誰が何を、いつ、どうやるかをチーム内部で決めること。外から作業を割り振る人がいる状態は、この定義から外れます。

3つの責任の対応表

表の見方をひとつ補足します。3つの責任は人数と一致しません。プロダクトオーナーとスクラムマスターは各1名ですが、開発者は複数です。また、プロダクトオーナーやスクラムマスターがスプリントバックログの項目に取り組んでいるときは、その時間は開発者として振る舞うとガイドは書いています。肩書きではなく、いまどの責任で動いているかで見る——これが「役割」から「責任」へ言い換えられたことの実質的な意味です。

プロダクトオーナー——価値の最大化と、順序づけられたプロダクトバックログ

3つの中で、発注側の読者に最も関係が深いのがプロダクトオーナーです。説明責任は「スクラムチームの作業から生まれるプロダクトの価値を最大化すること」で、その手段としてプロダクトバックログを管理します。具体的には、プロダクトゴールを定めて明確に伝えること、バックログ項目を作ること、項目に順序をつけること、バックログが透明で誰にでも見え、理解されている状態を保つこと。この4つです。

ガイドがはっきり書いているのは2点です。ひとつ、プロダクトオーナーは1人であって委員会ではないこと。バックログを変えたい人は、プロダクトオーナーを説得するという経路を通ります。ふたつ、プロダクトオーナーが成功するには、組織全体がその決定を尊重する必要があること。決めた順序が会議のたびに上から覆される環境では、この責任は成立しません。

当社が支援した介護記録SaaS「CareViewer」の開発では、日本語対応のブリッジSE1名とフルスタックエンジニア2名という体制で、優先順位の判断を週次で回していました。うまくいった理由を振り返ると、機能の良し悪しを議論する場ではなく、「次の1週間で何を先にやるか」を決める場として運用できていたことが大きい。決める人が決まっていて、決める頻度が固定されている。これだけで、開発側の手は止まりません。

スクラムマスターと開発者——確立する人と、作る人

スクラムマスターの説明責任は2つです。スクラムガイドで定義されたスクラムを確立すること。そして、スクラムチームの有効性に責任を持つこと。ガイドは、スクラムマスターをチームと組織に奉仕する真のリーダーだと表現しています。

具体的な奉仕の中身は3方向に分かれます。チームに対しては、自己管理と機能横断のコーチング、完成の定義を満たす価値あるインクリメントへの集中の支援、障害物の除去、すべてのイベントが開催されタイムボックス内に収まることの担保。プロダクトオーナーに対しては、プロダクトゴールの定義やバックログ管理の技法の支援、ステークホルダーとの協働の促進。組織に対しては、スクラム導入の指導とステークホルダーとチームの間の障壁の除去。

日本の現場でよくあるのが、スクラムマスターを「会議の司会」として運用してしまう形です。司会は仕事の一部ではありますが、説明責任は別のところにあります。チームが自分たちで決められる状態を作ること、そして決められない原因が組織側にあるなら、そこに働きかけること。ここが抜けると、イベントだけが残ります。

開発者の説明責任は、使用可能なインクリメントを毎スプリント作ることです。ガイドは4つを挙げています。スプリントの計画(スプリントバックログ)を作ること、完成の定義を守って品質を作り込むこと、スプリントゴールに向けて日々計画を適応させること、そして専門家として互いに責任を持ち合うこと。なお2020年版では「開発チーム」という呼称が消え、「開発者」になりました。チームの中にもう1つチームを作らない、という前述の原則と対応した変更です。

部品としての人はそろいました。ただし、決める人が実質的に不在のままイベントだけを始めると、毎日15分集まっているのに何も決まらない状態になります。人の次は、時間の設計を見ていきます。

スクラムの5つのイベント——スプリントという器と、その中で起きる検査と適応

スクラムには5つのイベントがあります。ただし5つが横並びなのではありません。スプリントという器がひとつあり、その中に4つのイベントが入る、という入れ子の構造になっています。この形を先に頭に入れると、あとの説明が一気に楽になります。

スプリント——1か月以内の固定長。終わったら次がすぐ始まる

ガイドはスプリントを「スクラムの心臓の鼓動」と表現しています。定義は明快で、1か月以内の固定長のイベントであること。そして前のスプリントが終わったら、次のスプリントがただちに始まること。間に準備期間を置く、という運用はガイドの想定に入っていません。

スプリント中のルールも4つ決まっています。スプリントゴールを危うくする変更は行わないこと。品質を低下させないこと。プロダクトバックログは必要に応じてリファインメント(洗練)すること。そして、学びが増えたらプロダクトオーナーとスコープを明確にし、再交渉してよいこと。

ここは誤解されやすいところです。「スプリント中は一切変更できない」のではありません。変更できないのはスプリントゴールを危うくする変更であって、ゴールを保ったままスコープを調整する交渉は認められています。逆にいえば、スプリントゴールが決まっていなければ、何を守るべきかの基準が存在しないことになります。

現場では1週間や2週間で回すチームが多く、解説記事もそう書いていることが多いのですが、これは慣習です。ガイドの定義は「1か月以内の固定長」で、短くすれば学習サイクルが増えてリスクを小さい時間枠に限定できる、と説明されています。なおスプリントを中止できるのはプロダクトオーナーだけで、中止できるのはスプリントゴールが陳腐化した場合に限られます。

イベント一覧(目的・参加者・タイムボックス)

タイムボックスはすべて1か月スプリントを前提とした上限です。ガイドは、スプリントが短ければイベントも通常は短くなる、と述べるにとどまり、短いスプリントでの具体的な上限は示していません。2週間スプリントで運用する場合は、各イベントの上限をチームで決めて合意し、その保持をスクラムマスターが担う形になります。

もうひとつ、表からは読み取れない設計意図があります。ガイドは、イベントを規定どおりに運用しないと検査と適応の機会が失われる、と書いています。つまりイベントは会議ではなく、検査と適応が起きる場所そのものです。「忙しいのでレトロスペクティブは今回なし」という判断は、会議を1つ減らしたのではなく、進め方を直す機会を1つ捨てたことになります。

スプリントプランニングとデイリースクラム——計画の場と、日々の再計画の場

スプリントプランニングは、スプリントの入口です。ガイドは扱うトピックを3つに整理しています。

トピック1は「このスプリントはなぜ価値があるのか」。プロダクトオーナーが価値と有用性の向上について提案し、スクラムチーム全体でスプリントゴールを定めます。ガイドは、スプリントゴールはプランニングの終了までに確定しなければならない、と明記しています。

トピック2は「このスプリントで何ができるのか」。開発者がプロダクトオーナーと話しながら、バックログから項目を選びます。過去の実績、今回の稼働可能量、完成の定義を知っているほど、予測の確度は上がるとされています。

トピック3は「選んだ作業をどのように成し遂げるのか」。選んだ項目ごとに、完成の定義を満たすインクリメントを作るための作業を計画します。多くの場合、1日以内の単位に分解します。どう分解するかは開発者の裁量で、他の誰も指示しません。

この3つの成果物——スプリントゴール、選ばれた項目、実現計画——をまとめてスプリントバックログと呼びます。

デイリースクラムは15分です。目的は、スプリントゴールに向けた進捗を検査し、必要に応じてスプリントバックログを調整して、翌日の計画を適応させること。開発者のためのイベントで、複雑さを減らすために毎営業日同じ時間・同じ場所で行うとされています。

2020年版で変わったのが、いわゆる「3つの質問」(昨日やったこと、今日やること、困っていること)が定型から外れたことです。ガイドは、スプリントゴールへの進捗に焦点を当て、翌日の実行可能な計画を作れるなら、構造や技法は開発者が選んでよいとしています。進捗報告会になっているチームが直すべきは時間ではなく、この焦点です。

なお、当社のチームはベトナム・ホーチミンにあり、日本との時差は2時間です。デイリーを日本側と同じ時間帯に置けるので、朝に出た疑問が同じ日のうちに回答まで戻ります。反復型で進めるとき、この往復の速さは会議の数より効きます。

スプリントレビューとスプリントレトロスペクティブ——プロダクトの検査と、進め方の検査

スプリントの出口には2つのイベントが並びます。検査する対象が違うので、まとめてはいけません。

スプリントレビューは、スプリントの成果を検査し、今後の適応を決める場です。スクラムチームが主要なステークホルダーに成果を提示し、プロダクトゴールへの進捗を話し合います。環境の変化も合わせて確認し、次に何をするかを共同で検討する。ここでプロダクトバックログが調整されることもあります。ガイドは「作業セッションであり、プレゼンテーションに限定すべきではない」と釘を刺しています。報告会にするな、ということです。

スプリントレトロスペクティブは、スプリントの最後に行います。検査する対象はプロダクトではなく、自分たちの進め方です。個人、相互作用、プロセス、ツール、そして完成の定義について、うまくいったこと・起きた問題・その問題が解決された(あるいはされなかった)経緯を振り返る。そして最も効果の高い改善を特定し、最もインパクトのあるものはすぐ着手する。次のスプリントバックログに入れることもあります。

この2つが両方あって、はじめて「何を作るか」と「どう作るか」の両方に検査と適応が働きます。片方だけのチームは、プロダクトは良くなっても進め方が変わらないか、進め方は整っても作るものがずれていくかのどちらかになります。そのデイリーは、何を検査していますか。

スクラムの3つの作成物と3つの確約——バックログ、インクリメント、そして周辺の用語

スクラムの作成物(アーティファクト)は3つです。プロダクトバックログ、スプリントバックログ、インクリメント。ガイドはこれらを「作業や価値を表したもの」と説明し、重要な情報の透明性を最大化するために設計されていると書いています。書類を作ることが目的ではありません。

作成物と確約の対応表——透明性を担保するための組み合わせ

2020年版の大きな変更点が、それぞれの作成物に「確約(コミットメント)」を紐づけたことです。確約は、その作成物が何に向かっているかを示す目印であり、進捗を測る基準になります。

右端の列が、この表で最も実務的な部分です。作成物だけを用意して確約を決めていないチームは珍しくありませんが、そのときに失われるのは書類ではなく判断基準です。

プロダクトバックログとスプリントバックログ——順序づけられた一覧と、今回の計画

プロダクトバックログは、プロダクトを改善するために必要なものを並べた、創発的で順序づけられた一覧です。ガイドは「スクラムチームが行う作業の唯一の情報源」と書いています。ここに載っていない作業は、原則として存在しないものとして扱われます。

大切なのは「順序づけられた」という一語です。優先度の高低をラベルで付けるのではなく、上から順に並んでいる。同率1位は存在しません。この形にしておくと、「どちらを先にやりますか」という問いに対して、一覧そのものが答えになります。

項目を実際に着手できる状態にする作業を、プロダクトバックログリファインメントと呼びます。項目を分解し、説明や順序、サイズを加えて精緻にしていく継続的な活動です。サイズの見積もりは、実際に作業する開発者が行います。プロダクトオーナーはトレードオフの理解を助けることで影響を与えられますが、数字を決める人ではありません。なお、リファインメントは5つのイベントに含まれない、継続的な活動として位置づけられています。

スプリントバックログは、今回のスプリントの計画です。構成は、スプリントゴール(なぜ)、選ばれたプロダクトバックログ項目(何を)、それを届けるための実行可能な計画(どうやって)の3つ。ガイドは、これは開発者による、開発者のための計画だと明記しています。スプリント中に学びが増えれば随時更新され、デイリースクラムで進捗を検査できる程度の詳細さが求められます。

当社が支援した介護記録SaaS「CareViewer」の開発では、この「上から順に並べ直す作業」を週次で回していました。項目の粒度や書式より、順序を毎週決め直す場が固定されていることのほうが効きます。逆に、この場が流れると、開発側は前回の順序のまま作り続けることになります。

インクリメントと完成の定義——「できた」の基準を先に文章にする

インクリメントは、プロダクトゴールに向けた具体的な踏み石です。日本語では「増分」と訳されますが、要は前回までの成果に積み上がった、動く状態のプロダクトのことです。ガイドは3つの条件を挙げています。過去のインクリメントすべてに追加されること。すべてのインクリメントが連携して動くよう入念に検証されていること。そして、価値を提供するために使用可能であること。

1スプリントの中で複数のインクリメントが生まれることもあります。またガイドは、スプリントレビューを価値提供のゲートと見なすべきではないとも書いています。準備ができたなら、スプリントの途中でステークホルダーに届けてかまいません。

インクリメントの確約が、完成の定義(Definition of Done)です。プロダクトに必要な品質基準を満たしたとき、インクリメントがどういう状態であるかを正式に記述したもの、と定義されています。ガイドの言い方が印象的で、プロダクトバックログ項目が完成の定義を満たした瞬間に、インクリメントが生まれる、とされています。満たしていない作業はインクリメントの一部と見なされず、リリースもスプリントレビューでの提示もできません。プロダクトバックログに戻されます。

では、完成の定義には何を書くのか。ここは組織ごとに違いますが、当社の場合、品質管理として3点を標準化しています。日本人PMによる設計レビュー、Gitのプルリクエストを使ったコードレビューの標準化、リリース前のダブルチェックです。これらを完成の定義に文章として入れておくと、「レビュー待ちだが実装は終わった」という曖昧な状態が消えます。組織の標準として完成の定義がある場合、すべてのスクラムチームはそれを最低ラインとして守ることになっています。

用語の早見——ガイドに載っている語と、現場の慣習語

最後に、混乱しやすい用語を整理しておきます。左の列がスクラムガイド2020年11月版に定義がある語、右の列が現場で広く使われるが原典にはない語です。

ベロシティという語がガイドに出てこないことは、知っておいて損がありません。予測の道具として広く使われていますが、原典が定めた指標ではないので、ベロシティが上がったかどうかでチームを評価するのはスクラムの要求ではないということです。作成物は提出書類ではなく、判断のための窓です。

スクラムが前提とすること——「名ばかりスクラム」と区別する5つの問いと、向く案件・向かない案件

ここまでで部品はそろいました。最後に扱うのは、その部品が機能するために何が前提になっているか、という話です。ここを飛ばすと、用語だけが導入されて中身が伴わない状態——いわゆる名ばかりスクラムになります。

ガイドは「一部だけの実装はスクラムではない」と書いている

スクラムガイド2020年11月版の末尾に、はっきりした一文があります。スクラムのフレームワークは不変であり、一部だけを実装することは可能だが、その結果はスクラムではない、と。スクラムは全体としてのみ存在し、他の技法や方法論の器としてうまく機能する、とも書かれています。

強い書き方ですが、意図は理解できます。各要素は透明性・検査・適応を成立させるために置かれているので、どれかを抜くと必ずどこかの機会が消える。たとえばレトロスペクティブを省けば進め方の適応が消え、完成の定義を決めなければインクリメントの透明性が消えます。

そのうえで、スクラムが暗黙に前提としていることを3つに整理できます。ひとつ、順序を1人で決められる人がいること(プロダクトオーナーの決定が尊重される)。ふたつ、チームが自分たちで進め方を決められること(自己管理)。みっつ、何をもって完成とするかが共有されていること(完成の定義)。この3つが欠けたまま形式だけ整えると、スプリントは「短く区切っただけの計画」になります。

名ばかりスクラムの典型5パターンと、壊れている場所

自己点検は、この表を5つの問いに読み替えると早く終わります。今回のスプリントゴールを全員が言えるか。差し込みは誰を通るか。完成の定義は文章になっているか。前回のレトロスペクティブで決めた改善は何だったか。誰が何をやるかを決めているのは誰か。5問のうち答えに詰まるものが、壊れている場所です。

念のため補足すると、部品を全部そろえることが目的ではありません。ガイドの3本柱に照らせば、判断基準は「検査と適応の機会が残っているか」です。形式が整っていても検査する対象がないなら意味がなく、形式が簡素でも毎回の検査と適応が効いているなら機能しています。

スクラムが向く案件・向かない案件——案件の性質で判断する

スクラムはあらゆる案件に向く枠組みではありません。ガイドの定義に「複雑な問題」とある以上、そもそも複雑でない問題は対象外です。判断軸を3つに整理します。

向く案件は、作るものが着手前に確定できない案件です。新規サービスやMVP開発のように、使われ方を見ながら決めたいもの。継続的に改善するSaaSや自社プロダクト。優先順位が月単位で動くもの。そして、発注側に順序を決められる人がいて、定期的に時間を取れるもの。

向かない案件は、要件が着手前に確定していて変更の見込みがないもの。関係部門が多く、工程ごとの承認と責任分界が制度として求められるもの。総額と納期を契約時点で確定する必要があるもの。そして、発注側が判断の時間を確保できないものです。

私は前職で、ERPのプライム案件を3件、上流から下流まで担当しました。ああした基幹業務の導入案件は、関係部門が多く、業務プロセスの承認が段階的に必要で、工程ごとに責任の所在をはっきりさせる必要がある。この性格の案件に反復型を持ち込むと、承認のリズムと開発のリズムが合わずに苦しくなります。逆に、画面を見てから要望が固まるような案件で工程を固定すると、手戻りが後半に集中する。案件の性質で選ぶものであって、どちらが新しいという話ではありません。

当社の位置づけ——スクラムを名乗る前に確認する2点

当社はベトナム・ホーチミンでラボ型開発(準委任)のチームを提供しており、反復型で進める案件が中心です。2018年以降、約100社の開発体制づくりを支援してきました。

「スクラムでやりたい」とご相談をいただいたとき、当社が最初に確認するのは用語でもツールでもありません。2点だけです。優先順位を1人で決められる方が発注側にいるか。そして、何をもって完成とするかを文章にできるか。この2つが埋まっていれば、スプリントの長さが1週間でも2週間でも検査と適応は機能します。逆に、この2つが空欄のまま形式を整えると、毎日15分集まっているのに何も決まらない状態になります。欠けているのは部品ではなく前提です。

なお、外注でスクラムを回すときの契約形態(準委任が前提になる理由)、発注者がプロダクトオーナーを担う場合の実務、完成の定義と検収の関係、外注で失敗する典型パターンについては、本記事では扱いません。「アジャイル開発 外注」の記事で詳しく整理しています。当社の体制は、最小構成で日本人PMフロント+2〜3人月の月額約80万円から、1名・最短2週間で開始できます。

スクラムに関するよくある質問

スクラムについて、実務でよく届く質問に答えます。いずれも打ち合わせの場やご相談の電話で繰り返し聞かれる内容で、用語の上下関係、期間の決め方、担当者の兼任、資格の要否、そして遠隔のチームで回るのかという5点に集中します。

Q1. アジャイルとスクラムは何が違うのですか

アジャイルは2001年の「アジャイルソフトウェア開発宣言」に示された価値観で、スクラムはその価値観を回すための具体的な枠組みのひとつです。上下関係にあります。ほかにエクストリームプログラミング(XP)やカンバンがあり、スクラムだけがアジャイルではありません。なお、スクラム自体は1995年に公に発表されており、宣言より先に存在していました。

Q2. スプリントは何週間にするのが正しいですか

スクラムガイド2020年11月版が定めているのは「1か月以内の固定長」という上限だけです。1週間でも2週間でも、固定されていればガイドの定義に反しません。短いほど学習の回数が増え、失敗したときの損失も小さい時間枠に収まります。実務では2週間から始め、レトロスペクティブで長さそのものを見直すチームが多いようです。

Q3. スクラムマスターとプロダクトオーナーは兼任できますか

ガイドは明示的に禁じてはいませんが、勧められる形ではありません。プロダクトオーナーは何を作るかの順序を決める立場、スクラムマスターはチームが自分たちで決められる状態を作る立場で、利害が衝突しやすいためです。小規模チームで兼任せざるを得ない場合は、どちらの立場で発言しているかを都度はっきりさせる運用が要注意点になります。

Q4. スクラムマスターに資格は必要ですか

スクラムガイドは資格を要求していません。認定資格(CSMやPSMなど)は理解を体系化する手段として有用ですが、資格の有無より、チームの障害物を実際に取り除けているか、イベントが検査と適応の場として機能しているかで見るほうが実務的です。

Q5. オフショアのチームでスクラムは回りますか

回ります。当社の拠点はホーチミンで日本との時差は2時間なので、デイリーを日本側と同じ時間帯に置けます。朝に出た疑問がその日のうちに戻る体制です。ただし前提は変わりません。発注側に順序を決められる方がいて、完成の定義が文章になっていること。当社の最小構成は日本人PMフロント+2〜3人月で月額約80万円から、1名・最短2週間での開始。単価は実務3年目安で1,500USD(約22.5万円)、5年で2,000USD、ブリッジSEで3,000USDを公開しています(1USD=150円換算目安)。契約形態や発注側の負担の詳細は「アジャイル開発 外注」の記事をご覧ください。

まとめ: スクラムは部品の集まりではなく、検査と適応を成立させる組み合わせ

スクラムとは、複雑な問題に対して適応的な解決策を通じて価値を生み出すことを助ける、軽量なフレームワークです(スクラムガイド2020年11月版)。手法でも手順書でもなく、意図的に不完全な枠組みで、その中に自分たちのやり方を入れて使います。土台は経験主義で、透明性・検査・適応という3本柱が、5つのイベントによって実装されています。アジャイルは2001年の宣言に示された価値観であり、スクラムはその実装のひとつ。上下関係で覚えておくと、社内の説明でつまずきません。

登場する部品は3つの責任、5つのイベント、3つの作成物です。プロダクトオーナー、スクラムマスター、開発者。スプリントという器の中に、スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ。プロダクトバックログ、スプリントバックログ、インクリメント。そして2020年版では、それぞれの作成物にプロダクトゴール、スプリントゴール、完成の定義という確約が紐づきました。確約が決まっていない作成物は、判断の基準を失って単なる一覧や作業リストになります。なお、ベロシティやストーリーポイントはガイドに定義のない現場の慣習語です。この線引きを知っていると、他社の運用を見たときに何が原則で何が選択かを切り分けられます。

自分たちの運用を点検するときは、部品が欠けているかどうかではなく、検査と適応の機会が残っているかどうかで見てください。問いは5つです。今回のスプリントゴールを全員が言えるか。差し込みは誰を通るか。完成の定義は文章になっているか。前回のレトロスペクティブで決めた改善は何だったか。誰が何をやるかを決めているのは誰か。答えに詰まったところが、壊れている場所です。そしてスクラムが前提にしているのは、順序を1人で決められる人がいること、チームが自分たちで進め方を決められること、完成の基準が共有されていることの3つ。この前提が空欄のまま形式だけを整えると、短く区切っただけの計画になります。外注でスクラムを回すときの契約形態や、発注者がプロダクトオーナーを担う場合の実務、失敗の典型パターンはアジャイル開発の外注で、月額で専属チームを確保する進め方はラボ型開発とはで詳しく扱っています。当社はベトナム・ホーチミンでラボ型開発のチームを提供しており、時差は2時間、最小構成は日本人PMフロント+2〜3人月で月額約80万円から、1名・最短2週間で開始できます。現在の体制と要件をお聞かせいただければ、スクラムを回せる前提がそろっているかどうかを含めて、概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。