「アジャイル開発で進めます」「スクラム体制を組みます」。開発会社との打ち合わせや提案資料でこう言われて、その場では頷いたものの、後から「そもそもアジャイルって何だったか」「スクラムとカンバンは何が違うのか」と不安になった経験はないでしょうか。
発注の窓口に立つ事業部門の担当者や情シス兼任の方にとって、この曖昧さは厄介です。アジャイル・スクラム・カンバンはどれも似た文脈で登場し、用語の関係が整理されないまま比較や提案が進みます。社内に開発手法を判断できる人がいなければ、「提案された手法を鵜呑みにしてよいのか」という不安だけが残ります。
ですが、これらの言葉の関係さえ押さえれば、発注者でも「自社のプロジェクトにどの進め方が合うか」を自分なりに評価できるようになります。手法の優劣を学ぶ必要はありません。判断のカギは「自社がどう関われるか」にあります。
本記事では、アジャイル開発とは何かを非エンジニア向けに整理したうえで、代表手法であるスクラムとカンバンの違いを発注者の目線で解説します。さらに、自社のプロジェクト特性に合う選び方と、提案された手法を確認するための質問例まで紹介します。読み終えたとき、次の打ち合わせで「うちの場合はなぜこの手法なのか」と質問できる状態を目指します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
アジャイル開発とは？「素早く・柔軟に」進める開発の考え方
アジャイル開発をひとことで言うと（小さく作って確かめる）
アジャイル開発とは、ひとことで言えば「小さく作って、確かめながら進める」開発の考え方です。最初にすべての仕様を固めてから一気に作り上げるのではなく、機能を小さな単位に分け、短い周期で作っては動かして確認し、次の優先順位を決めていきます。
従来主流だったウォーターフォール開発は、「要件定義→設計→開発→テスト」と工程を順番に進め、最初に決めた計画通りに完成を目指す方式です。これに対してアジャイル開発は、進めながら方向性を調整できる点が最大の違いです。作りながら「やっぱりここはこうしたい」という変更を、後から取り入れやすくなります。
アジャイルとウォーターフォールのどちらを選ぶかという、より手前の判断軸についてはアジャイルとウォーターフォールの選び方で詳しく扱っています。本記事ではアジャイルという枠の中での話に絞って進めます。
アジャイルは「考え方」、スクラム・カンバンは「具体的な進め方」
ここで多くの方がつまずくポイントを先に整理します。アジャイル・スクラム・カンバンは並列の選択肢ではありません。三者には次のような階層関係があります。
- アジャイル … 「小さく作って確かめる」という大きな考え方（価値観・原則）
- スクラム … アジャイルを実践するための具体的な進め方のひとつ
- カンバン … 同じくアジャイルを実践するための、もうひとつの具体的な進め方
つまり「アジャイルという考え方の中に、スクラムやカンバンといった具体的な進め方がある」という入れ子の関係です。料理にたとえるなら、アジャイルが「和食」という大きなジャンルで、スクラムやカンバンが「煮物」「焼き物」といった具体的な調理法にあたります。
開発会社が「アジャイルで進めます」と言うとき、それは方向性の宣言にすぎません。実際にどう進めるかは、スクラムなのかカンバンなのか、その先で決まります。「アジャイル＝スクラム」ではないと理解しておくと、提案を読み解く解像度が一段上がります。
アジャイルの代表手法「スクラム」とは（発注者から見た特徴）
スクラムの進み方（スプリントの繰り返し）
スクラムは、アジャイルを実践する手法の中でもっとも広く使われている進め方です。最大の特徴は、スプリントと呼ばれる決まった期間（一般に1〜4週間）を区切り、その中で「計画→開発→確認」のサイクルを繰り返す点にあります（出典: アトラシアン「カンバン vs スクラム」）。
1回のスプリントの流れはおおむね次の通りです。
- スプリントの最初に「今回の期間で何を作るか」を決める（計画）
- その期間中はチームが集中して開発する
- スプリントの終わりに、できあがったものを関係者で確認する（レビュー）
- 進め方の振り返りをして、次のスプリントに入る
このサイクルを繰り返すことで、数週間ごとに「動くもの」が積み上がっていきます。発注者から見ると、一定のリズムで成果物を確認できるのがスクラムの安心材料です。
スクラムには「プロダクトオーナー」「スクラムマスター」「開発チーム」といった役割や、いくつかの会議体があります。それぞれの細かな定義はここでは深追いしませんが、発注者にとって重要なのは「自分がどこに関わるのか」です。
発注者が関わる場面（優先順位の決定・レビューでの確認）
スクラムにおいて発注者が関わる場面は、大きく2つあります。
ひとつは優先順位の決定です。何から作るか、どの機能を先に進めるかを決める役割（プロダクトオーナー）は、発注側の意向を強く反映します。社内のプロダクトオーナーが担う場合もあれば、開発会社側が担い発注者がそれに合意する形もあります。いずれにせよ「次に何を優先するか」を継続的に伝える必要があります。
もうひとつはスプリント終わりのレビューでの確認です。数週間ごとにできあがったものを見て、「これでよい」「ここを直したい」とフィードバックします。この場が、方向性のずれを早めに修正できる重要な機会になります。
裏を返すと、スクラムは発注者にも一定の関与時間を求める手法です。「作るものを継続的に決め、定期的に成果を確認する」体制が組めるかが、後の選定で効いてきます。スクラムの役割や会議でつまずきやすい用語をより詳しく知りたい場合は、スクラムとは？発注者が会議でつまずく用語をやさしく整理も参考になります。
もう一つの手法「カンバン」とは（スクラムとの違い）
カンバンの進み方（流れを可視化して継続的に回す）
カンバンは、アジャイルを実践するもうひとつの代表的な手法です。スクラムが「期間を区切って回す」のに対し、カンバンは期間を区切らず、作業の流れそのものを可視化して継続的に回す進め方です。
イメージしやすいのは、ボードに「ToDo（これからやる）」「対応中」「完了」といった列を作り、一つひとつの作業を付箋やカードのように動かしていく形です。作業が進むたびにカードが右へ移動し、いま何がどの段階にあるかが一目で分かります。
カンバンには「同時に進める作業の数を制限する」という考え方（WIP制限と呼ばれます）もありますが、発注者がまず押さえるべきは「区切りを設けず、入ってきた作業を流れるように片付けていく」という性質です。優先度が変わったら、ボードの並び順を入れ替えるだけで柔軟に対応できます。
スクラムとカンバンはここが違う
スクラムとカンバンの本質的な違いは、次の3点に集約できます。
- 期間の区切り：スクラムは数週間のスプリントで区切る。カンバンは区切りを設けず連続的に進める
- 計画のタイミング：スクラムはスプリントの開始時にまとめて計画する。カンバンは作業が空いたら次を随時取り込む
- 変更への対応：スクラムは原則スプリント期間中は作る内容を固定する。カンバンは優先度の入れ替えをいつでも反映しやすい
スクラムが「決めた期間に集中して、リズムよく成果を出す」進め方だとすれば、カンバンは「流れを止めず、変化にその都度合わせて回し続ける」進め方です。アトラシアンも、スクラムは定義したスプリントのゴールに沿って計画したいチームに、カンバンは優先順位が変わりやすく高い柔軟性が必要なチームに向くと整理しています（出典: アトラシアン「カンバン vs スクラム」）。
この違いが、後ほど解説する「自社にどちらが向くか」の判断材料になります。
スクラムとカンバンの違い早見表（発注者が押さえる5観点）
ここまでの内容を、発注者が押さえておきたい5つの観点で整理します。一般的な比較表は「チーム内部の運営」を中心に作られがちですが、ここでは発注者にとっての影響（関与度や進捗の見え方）を必ず含めています。
観点 | スクラム | カンバン |
|---|---|---|
① 期間の区切り | スプリント（1〜4週間）で区切る | 区切りを設けず連続的に進める |
② 計画のタイミング | スプリント開始時にまとめて計画 | 作業が空いたら随時取り込む |
③ 変更への対応しやすさ | スプリント中は内容を固定（次のスプリントで反映） | 優先度の入れ替えをいつでも反映しやすい |
④ 発注者の関与度・頻度 | スプリントごとに優先順位決定とレビューで定期的に関与 | 必要なときに優先度を伝える。関与のタイミングは柔軟 |
⑤ 進捗の見え方 | 数週間ごとに「動くもの」で成果を確認できる | ボード上で常時、各作業の状況を確認できる |
④と⑤に注目してください。スクラムは「定期的に時間を確保して関わる」前提があるぶん、成果も一定リズムで確認できます。カンバンは「関与のタイミングを柔軟にできる」一方で、節目となるレビューの場は自分から設計しないと曖昧になりがちです。どちらが優れているという話ではなく、自社の関わり方との相性で評価する、という視点が重要です。
発注時の選び方｜自社のプロジェクトに合うのはどっちか
ここが本記事の核心です。スクラムとカンバンの選定は「手法の優劣」で決めるものではありません。「プロジェクトの特性」×「発注者として関与できる度合い」の組み合わせで判断します。以下のチェックを、自社の状況に当てはめながら読んでみてください。
スクラムが向いているケース
次のような状況なら、スクラムが合いやすいといえます。
- 要件がまだ固まりきっておらず、段階的に決めていきたい：作りながら方向性を調整したい新規開発に向きます
- 定期的にレビューに参加できる時間が確保できる：数週間に一度、成果を確認しフィードバックする体制が組める
- 成果物の方向性を継続的に調整したい：一定リズムで「動くもの」を見ながら軌道修正したい
逆に言えば、スクラムは発注者にも「優先順位を決め、定期的に確認する」関与を求めます。この時間を割けることが前提条件になります。
カンバンが向いているケース
次のような状況なら、カンバンが合いやすいといえます。
- すでに動いているシステムの運用・保守や継続的な改善が中心：機能を少しずつ足したり直したりする作業が向きます
- 対応すべき優先度が頻繁に変わる：割り込みの要望や緊急対応が多い場合、柔軟に並び替えられるカンバンが扱いやすい
- まとまった会議時間を定期的に確保しにくい：スプリントごとの計画やレビューに時間を取りづらい状況に適します
新規にゼロから作るというより、回し続けながら少しずつ良くしていくフェーズと相性が良い、と覚えておくとよいでしょう。
迷ったら「組み合わせ（スクラムバン）」という選択肢
「どちらにも当てはまる気がする」「片方に絞りきれない」という場合は、両者を組み合わせるスクラムバンという選択肢もあります。スクラムの計画性とカンバンの柔軟性を併せ持つ折衷的な進め方で、スクラムのスプリントによる計画と、カンバンのボードや作業数の制限を組み合わせて運用します（参考: Asana「スクラムばん: 2 つのアジャイル手法をいいとこ取り」）。
たとえば「基本はスクラムのリズムで進めつつ、割り込み対応はカンバン的に流す」といった運用です。開発会社がスクラムバンを提案してきた場合は、奇をてらった選択ではなく現実的な折衷案だと理解してよいでしょう。大切なのは名前ではなく、「自社の関わり方に無理がないか」です。
提案された手法を鵜呑みにしないために｜発注者が確認すべきこと
手法選びは、開発会社に任せきりにするものではありません。提案された進め方が自社の状況に合っているかは、発注者自身が判断に参加すべきところです。とはいえ専門知識がなくても、次のような質問を打ち合わせで投げかけるだけで、提案の妥当性は十分に確かめられます。
- 「なぜ当社のプロジェクトにこの手法が向くと判断したのですか？」：手法ありきではなく、自社の特性を踏まえた提案かを確認できます。要件の固まり具合や変更の多さといった、本記事で見てきた観点に沿った説明があれば信頼できます
- 「私たち発注側は、どの頻度・どの場面で関わる必要がありますか？」：関与に割ける時間と提案手法が噛み合っているかを確認します。スクラムなのにレビューの時間を取れない、という食い違いを早めに防げます
- 「要件変更があったとき、費用やスケジュールはどう扱われますか？」：アジャイルは変更を取り入れやすい反面、追加対応の費用やスケジュールの考え方を事前にすり合わせておくことが欠かせません
これらの質問に、開発会社が自社の状況に即して具体的に答えられるかどうかが、提案の質を見極めるひとつの目安になります。逆に「業界標準なので」「最近はみんなこれです」といった一般論しか返ってこない場合は、もう一歩踏み込んで確認する余地があります。
なお、費用やスコープ（作業範囲）の扱いは契約条件にも関わる重要なテーマです。アジャイルでの発注における費用やスコープの管理については、アジャイル発注のスプリント費用とスコープ管理でより詳しく解説しています。
まとめ｜アジャイルの手法選びは「自社の関わり方」から逆算する
最後に要点を整理します。
- アジャイルは「小さく作って確かめながら進める」考え方であり、その中の具体的な進め方がスクラムとカンバンです。「アジャイル＝スクラム」ではありません
- スクラムは期間（スプリント）を区切ってリズムよく進める手法で、発注者にも定期的な関与を求めます
- カンバンは区切りを設けず流れを可視化して回し続ける手法で、優先度の変化に柔軟に対応できます
- どちらを選ぶかは手法の優劣ではなく、「プロジェクトの特性」×「自社が関われる度合い」で判断します
- 提案された手法は鵜呑みにせず、「なぜこの手法か」「自社はどう関わるか」「変更時の費用・スケジュールはどうなるか」を確認しましょう
手法はあくまで目的を達成するための手段です。どんなに優れた進め方でも、自社が無理なく関われなければ成果にはつながりません。アジャイル開発の基本的な考え方をあらためて押さえたい場合はアジャイル開発とは？メリットと進め方の基本も参考になります。「自社がどう関われるか」から逆算して進め方を選ぶことが、開発を成功させる近道になります。次の打ち合わせでは、ぜひ「うちの場合はなぜこの手法なのか」を質問してみてください。
参考にした主な情報源:
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 開発会社から「アジャイルで進めます」と言われたら、どんな質問を返せばいいですか？
「なぜ当社のプロジェクトにこの手法が向くと判断したのですか？」と聞いてください。要件の固まり具合や変更の多さなど、自社の状況を踏まえた説明が返ってこない場合は、手法ありきの提案の可能性があります。この確認が重要なのは、手法が自社の関与スタイルや体制と合わないまま進めると、後から軌道修正が難しくなるためです。次の打ち合わせでは必ずこの質問を投げかけ、具体的な回答が得られるかを確認してみてください。
- スクラムとカンバン、どちらかに絞れない場合はどうすればいいですか？
スクラムとカンバンを組み合わせた「スクラムバン」という選択肢があります。スクラムのスプリントによる計画性と、カンバンの柔軟な優先度調整を併せ持つ折衷的な進め方で、開発会社が提案する場合もあります。この選択肢が有効なのは、新規開発と保守改善が混在するプロジェクトや、割り込み対応が多い状況です。発注者としては「自社がどこに時間を割けるか」を軸に、開発会社と相談して進め方を決めることが重要です。
- スクラムを採用した場合、発注者はどのくらいの頻度で関与が必要ですか？
スプリントごと（1〜4週間に1回）に優先順位の決定とレビューへの参加が求められます。この時間を継続的に確保できるかどうかが、スクラムを採用できるかの実質的な前提条件になります。この関与が重要なのは、方向性のずれを早期に修正できる機会だからです。担当者がレビューに参加できない状況が続くと、開発が的外れな方向へ進むリスクが高まります。スクラムを検討する際は、社内体制を確認してから判断してください。
- アジャイルで開発を進めると、途中の要件変更で費用が膨らみませんか？
変更を取り込みやすい反面、追加対応の費用やスケジュールの扱いは事前に取り決めておく必要があります。契約前に「変更が発生したときの費用・スコープの扱い方」を確認することが欠かせません。この確認が重要なのは、後からのトラブルを防ぐためです。アジャイルの「変更を歓迎する」は無制限の変更を意味しません。発注者として、変更時の合意プロセスを契約段階で明確にしておくことが費用膨張を防ぐ最善策です。
- 保守・運用フェーズに入ったシステムの改善にはスクラムとカンバンのどちらが向きますか？
カンバンが向いています。すでに動いているシステムへの継続的な改善や割り込み対応が多い状況では、期間を区切らず優先度を柔軟に入れ替えながら回し続けるカンバンの特性が合っています。保守フェーズでは緊急バグ対応など予期しないタスクが発生しやすく、スプリント計画を崩しやすいためです。次のアクションとして、開発会社にカンバンボードの共有を求め、作業状況を常時確認できる体制を整えると安心です。
