「次のスプリントのバックログを整理しておきます」「スプリントレビューで見てもらえますか」「そこはPOの判断ですね」——開発会社との打ち合わせで、こうした言葉が当たり前のように飛び交い、会話についていけずに固まってしまった経験はありませんか。
システム開発を外部に依頼した発注者の多くが、最初の壁としてぶつかるのが「スクラム用語」です。一つひとつ質問するのも気が引けて、結局「自分はこの会議で何をすればいいのか」が分からないまま打ち合わせが進んでしまう、という声をよく聞きます。
スクラムを解説した記事はたくさんあります。しかしその多くはエンジニア向けだったり、教科書のように用語を網羅するだけだったりして、「非ITの発注担当者が、会議で実際にどう振る舞えばいいのか」までは教えてくれません。
そこで本記事では、スクラムの用語を「開発会社の打ち合わせで実際にどう登場するか」「その言葉が出てきたとき、発注者は何をすればいいのか」とセットで、やさしく整理します。スクラムの3つの役割・主要な会議体・成果物という3つの切り口で用語を押さえれば、次の打ち合わせで話についていけるようになります。専門知識がなくても読み進められるよう、一つずつ噛み砕いていきます。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
スクラムとは？発注者がまず押さえる全体像
個々の用語に入る前に、まずスクラム全体の地図を持っておきましょう。全体像が頭にあると、これから出てくる役割や会議が「どこに位置づくものか」が分かり、会議で迷子になりにくくなります。
スクラムをひとことで言うと
スクラムとは、ひとことで言えば「チームで短いサイクルを繰り返しながら、少しずつ作って確かめていく開発の進め方」です。最初にすべての仕様を固めてから一気に作るのではなく、1〜4週間程度の短い区切り（これを「スプリント」と呼びます）ごとに動くものを作り、見て・確かめて・次に進む、というリズムを繰り返します。
名前は、ラグビーの「スクラム」が由来です。チーム全員が肩を組んで一体となって前進する様子になぞらえて、開発チームが密に連携しながらゴールへ進むイメージが込められています。
アジャイルとスクラムの違い
「アジャイル」と「スクラム」は混同されがちですが、関係を整理するとシンプルです。アジャイルは「変化に柔軟に対応しながら、価値あるものを少しずつ届けよう」という考え方・思想を指します。一方スクラムは、そのアジャイルの考え方を実践するための具体的な進め方（フレームワーク）の代表格です。
つまり「アジャイル＝目指す方向性」「スクラム＝そのための具体的な型」という関係です。開発会社が「アジャイルでやります」と言った場合、実際の進め方としてスクラムを採用しているケースが多くあります。
なぜ開発会社はスクラムを使うのか
発注者からすると「最初に全部決めて、その通りに作ってほしい」と思うかもしれません。しかし、システム開発では作っている途中で「やはりこうしたい」という要望や、市場の変化が必ず出てきます。
スクラムは、短いサイクルで動くものを見せながら進めるため、こうした変化に柔軟に対応でき、認識のズレも早い段階で見つけられます。「完成してから初めて見たら思っていたものと違った」という最悪の事態を避けやすいのが、スクラムが選ばれる大きな理由です。
スクラムの3つの役割を発注者目線で理解する
スクラムには、決まった3つの役割（登場人物）がいます。打ち合わせで「誰がどんな立場で発言しているのか」が分かると、誰に何を聞けばよいかが見えてきます。ここでは「会議で何を発言する人か」という視点で整理します。
プロダクトオーナー（PO）— 何を作るかの優先順位を決める人
プロダクトオーナー（よく「PO」と略されます）は、「何を、どの順番で作るか」を決める責任者です。限られた時間と予算の中で、どの機能を優先するかを判断します。打ち合わせでは「この機能を先に作りましょう」「今回はここまでで十分です」といった優先順位の発言をするのがPOです。
スクラムマスター — チームが円滑に回るよう調整する人
スクラムマスターは、チームがスムーズに開発を進められるよう支える調整役です。会議の進行を整えたり、開発の妨げになっている問題を取り除いたりします。「この進め方で問題ないか確認しましょう」「この障害は私が調整します」といった、場を整える発言が多いのがスクラムマスターです。管理職のような「指示する人」ではなく、あくまでチームを支える役割である点がポイントです。
開発者（開発チーム）— 実際に作る人
開発者は、実際に設計・プログラミング・テストを行って成果物を作る人たちです。スクラムでは個人ではなくチーム全体で成果に責任を持ちます。打ち合わせでは技術的な実現性や工数について「これは○日くらいかかります」「この方法なら実現できます」といった発言をします。
受託開発でPOは誰が担う？
発注者にとって最も重要なのが、この「POを誰が担うか」という点です。なぜなら、ここが自分（発注者）の関与量を大きく左右するからです。受託開発では、おおむね次のパターンがあります。
パターン | POを担う人 | 発注者の関与の目安 |
|---|---|---|
発注者側がPOを担う | 自社の事業担当者 | 多い。優先順位の判断・要望の整理を自社で主導する |
開発会社側がPOを担う（または代行） | 開発会社の担当者 | 中程度。要望は伝えるが、整理・優先順位付けは開発会社が支援する |
両者で分担（プロキシPO型） | 発注者＋開発会社の橋渡し役 | 中〜多。窓口担当が実質的なPO的役割を期待されることが多い |
もし自社がPOを担う、あるいはPOに近い窓口役を任されている場合、「何を優先するか」を決める判断が頻繁に求められます。最初の打ち合わせの段階で「このプロジェクトでPOは誰になりますか？」と確認しておくと、自分にどれくらいの関与が求められるかの見通しが立ちます。
POやバックログの役割をさらに詳しく知りたい場合は、バックログとは｜スクラム発注者が押さえる優先度の決め方ガイドもあわせてご覧ください。
スクラムの会議体と発注者が出るべき会議
「自分はどの会議に出て、何をすればいいのか」——これが多くの発注者が一番知りたいところではないでしょうか。スクラムにはいくつかの決まった会議（イベント）があります。それぞれの目的と、発注者の関わり方を整理します。
スプリントとは（すべての会議の土台になる期間）
会議の説明に入る前に、土台となる「スプリント」を押さえます。スプリントとは、1〜4週間程度の決まった長さの開発期間のことです。スクラムでは、このスプリントを繰り返しながら開発を進めます。これから紹介する会議は、すべてこのスプリントの中で行われます。「1スプリント＝2週間」のように長さを固定して回すのが一般的です。
スプリントプランニング（次に何を作るか決める）
スプリントの始まりに行う、「このスプリントで何を作るか」を決める会議です。POが優先順位を示し、開発者が「このスプリントで実現できる範囲」を見積もります。発注者が要望の優先順位に関わる場合、ここでの判断が重要になります。
デイリースクラム（毎日の短い進捗共有）
開発チームが毎日決まった時間に行う、15分程度の短い進捗共有です。「昨日やったこと・今日やること・困っていること」を手短に確認します。これは基本的に開発チーム内の会議のため、発注者が出席する必要は原則ありません。
スプリントレビュー（成果物を見て発注者がフィードバックする場）
スプリントの終わりに、その期間で作った成果物を関係者に見せて確認する会議です。発注者にとって最も重要な会議であり、ここで実際に動くものを見て、率直なフィードバックを伝えます。「ここはイメージと違う」「この部分はとても良い」といった意見が、次のスプリントに反映されます。レビューに出ないと要件がズレていく原因になるため、できる限り参加しましょう。
レトロスペクティブ（チームの振り返り）
スプリントの最後に、チーム自身が「進め方をどう改善するか」を振り返る会議です。プロダクトそのものではなく「チームの働き方」を対象とするため、こちらも基本的にはチーム内の会議で、発注者の参加は必須ではありません。
【一覧表】発注者が出るべき会議・出なくてよい会議
ここまでの会議を、発注者の関与という観点で一覧にまとめます。次の打ち合わせの前にここだけ見返せば、「自分が出るべき会議」が一目で分かります。
会議（イベント） | 目的 | 発注者の関与 |
|---|---|---|
スプリントプランニング | 次のスプリントで何を作るか決める | △ 優先順位に関わる場合は参加が望ましい |
デイリースクラム | 毎日の短い進捗共有 | × 原則不要（チーム内の会議） |
スプリントレビュー | 成果物を見てフィードバックする | ◎ できる限り参加すべき最重要会議 |
レトロスペクティブ | チームの進め方の振り返り | × 原則不要（チーム内の会議） |
迷ったら「スプリントレビューには必ず出る」とだけ覚えておけば、発注者として最低限の関与は果たせます。
スクラムの成果物の用語を読み解く
スクラムには、会議で繰り返し登場する「成果物」と呼ばれる用語があります。これらは画面に映るリストや動くソフトウェアの正体です。これが分かると、「今みんなが何を見て話しているのか」を追えるようになります。
プロダクトバックログ（やることリスト全体）
プロダクトバックログとは、そのプロジェクトで「やりたいこと・作りたい機能」を優先順位順に並べた一覧です。いわばプロジェクト全体のToDoリストで、POが優先順位を管理します。会議で「バックログを整理する」と言われたら、この一覧の中身や順番を見直すことを指します。
スプリントバックログ（今回のスプリントでやること）
プロダクトバックログ全体の中から、「今回のスプリントで取り組む分」だけを抜き出したものがスプリントバックログです。全体のToDoリストから「今週やる分」をピックアップしたもの、とイメージすると分かりやすいでしょう。
インクリメント（毎スプリントで積み上がる成果物）
インクリメントとは「増分」という意味で、各スプリントで新たに完成した、動く成果物を指します。スプリントごとにインクリメントが積み上がっていき、プロダクトが少しずつ形になっていきます。スプリントレビューで発注者が見るのは、このインクリメントです。
完了の定義（Done）— 発注者が確認すべき品質の物差し
「完了の定義」（英語で Definition of Done、略してDoD）とは、「どこまでできたら『完成』とみなすか」をチームで合意した基準です。たとえば「テストまで通って、動作確認も済んだ状態」を完了とする、といった取り決めです。
これは発注者にとって意外に重要です。「完成しました」と言われても、自分の思う「完成」とチームの思う「完成」がズレていると、後でトラブルになります。最初の段階で「このプロジェクトでの『完了』とは何を指すのか」をすり合わせておくと、認識のズレを防げます。
発注者がスクラムでつまずきやすいポイントと心構え
最後に、用語を理解した先で大切になる「発注者としての心構え」を、よくあるつまずきとあわせて整理します。
「丸投げできると思っていた」 スクラムは、発注して待っていれば完成するものではありません。スプリントごとにレビューでフィードバックする、発注者の継続的な関与が前提です。むしろ関与することで、望むものに近づけていける進め方です。
「途中で仕様を足し放題だと思っていた」 柔軟に変更できるのがスクラムの強みですが、時間と予算は有限です。新しい要望を入れるなら、何かの優先順位を下げる必要があります。「足す」ではなく「優先順位を入れ替える」という発想が大切です。
「レビューに出なくても大丈夫だと思っていた」 スプリントレビューに出ないと、認識のズレに気づくのが遅れ、手戻りが大きくなります。短時間でも参加し、率直に意見を伝えることが、結果的に満足度の高い成果物につながります。
「最終的な完成形が見えにくくて不安」 少しずつ作る進め方のため、最初に完成形がきっちり固まっていないことに不安を感じる方もいます。だからこそ、毎回のレビューで方向性を確認し、完了の定義をすり合わせることが、ゴールへの安心感につながります。
これらに共通するのは、「スクラムでは発注者の継続的な関与が前提」という点です。会議に出て、見て、率直に意見を言う——この積み重ねが、満足のいく成果物につながります。
なお、「そもそも自社のプロジェクトにスクラムが向いているのか」についてはスクラム開発とは？流れ・役割・発注者の関与ポイントを徹底解説を、「外注をどう進めればよいのか」についてはスクラム開発を外注する進め方をあわせて参考にしてみてください。
まとめ｜スクラム用語が分かれば会議が変わる
最後に、本記事で扱った用語を早見表で振り返ります。会議の前にここだけ見返せば、全体像を素早く思い出せます。
分類 | 用語 | ひとことで言うと |
|---|---|---|
役割 | プロダクトオーナー（PO） | 何を・どの順で作るか決める人 |
役割 | スクラムマスター | チームが円滑に回るよう支える人 |
役割 | 開発者 | 実際に作る人 |
会議 | スプリント | 1〜4週間の開発サイクル |
会議 | スプリントレビュー | 成果物を見て発注者がフィードバックする最重要の場 |
成果物 | プロダクトバックログ | やりたいこと全体の優先順位リスト |
成果物 | スプリントバックログ | 今回のスプリントでやる分 |
成果物 | インクリメント | 各スプリントで完成した動く成果物 |
成果物 | 完了の定義（Done） | 「完成」とみなす合意した基準 |
用語が分かれば、会議の景色は変わります。まずは次のスプリントレビューに出て、動くものを見ながら一言フィードバックを伝えてみてください。その一歩が、開発会社との対話を「ついていけない時間」から「一緒に作る時間」へ変えていきます。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
