結論

アジャイルとは、短い周期で動くソフトウェアを作って見せ、変化に合わせて計画を直し続ける開発の考え方です。スクラムなどの手法の総称です。

この記事でわかること

  • 4つの価値・12の原則の公式訳と要点の表
  • スクラム・カンバン・XPの違い表と判断表
  • 架空アプリのバックログ10件とバーンダウン計算

2026年10月17日更新|スクラムガイド2020・Python 3.11 で計算確認

アジャイル開発では、次の小さな周期(スクラムではスプリントと呼びます)を何度も回し、そのたびに作るものと順番を見直します。

flowchart TD
    A[プロダクト<br>バックログ] --> B[計画<br>今回作る分を選ぶ]
    B --> C[作る<br>1か月以内]
    C --> D[動くものを<br>見せる]
    D --> E[ふりかえり]
    E -->|次の周期| A

用語と中身の早見表です。

知りたいこと 答え 出典
アジャイルの意味 短い周期で作り、変化に合わせて直す考え方 アジャイル宣言(2001年)
4つの価値 個人と対話・動くソフトウェア・顧客との協調・変化への対応 アジャイル宣言
12の原則 4つの価値を行動に落とした指針 アジャイル宣言の背後にある原則
代表的な手法 スクラム・カンバン・XP 各公式ガイド
スクラムの中身 責任3つ・イベント5つ・作成物3つ スクラムガイド2020
1周期の長さ スクラムは1か月以内の決まった長さ スクラムガイド2020
向く案件 要件が変わりやすい・早く出して確かめたい 本文の判断表
向きにくい案件 仕様と期日が固定・関係者が関われない 本文の判断表

確認環境:アジャイルソフトウェア開発宣言と12の原則は agilemanifesto.org の公式日本語訳、スクラムは公式のスクラムガイド2020年11月版(日本語版)と改訂履歴、カンバンは The Kanban Guide(2025年5月版)、XP は Agile Alliance の用語集で確かめました。架空の Web サービスのバックログとバーンダウンの数値は、Python 3.11.15 で計算した出力をそのまま載せています(確認日 2026年10月17日)。

本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。

(記載例)出典:株式会社RJC「アジャイルとは|4つの価値・12の原則とスクラムを実例で解説」

アジャイルとは(アジャイル開発の意味)

アジャイル(agile)は英語で「素早い」「機敏な」という意味です。 ソフトウェア開発では、2001年に公開された「アジャイルソフトウェア開発宣言」の価値観に沿った開発のやり方をまとめて、アジャイル開発と呼びます。

宣言は、2001年2月11日〜13日に米国ユタ州のスノーバードに集まった17人の開発者がまとめたものです(agilemanifesto.org の「History」より)。

アジャイルは1つの手法の名前ではありません。次のように、考え方から具体的なやり方まで、層になっています。

層 中身 例
価値観 何を大事にするか 4つの価値
原則 価値観を行動に落とした指針 12の原則
フレームワーク・手法 チームの進め方の枠組み スクラム、カンバン、XP
プラクティス 日々の具体的な技法 ユーザーストーリー、テスト駆動開発、継続的インテグレーション、ふりかえり

「アジャイルで進める」と言うときは、たいていスクラムなどの手法を選び、その中でプラクティスを組み合わせています。手法は道具で、価値観と原則が目的に当たります。

従来の進め方との違い(一言で)

工程を順に1回ずつ進めるウォーターフォール型では、最後にまとめて完成品を渡します。アジャイル型では、短い周期ごとに「動く一部分」を作って見せ、その反応で次に作るものを決めます。

違いの中心は「いつ確かめるか」です。 アジャイルは、作ったものが役に立つかを早く・何度も確かめます。工程・費用・契約まで含めた詳しい比較は、関連記事「ウォーターフォールとアジャイルの違い比較表|開発手法の選び方診断」で扱っています。

アジャイルソフトウェア開発宣言の4つの価値

宣言の本文は、左右の項目を比べる形の4行です。公式の日本語訳の文言をそのまま載せます。

左(価値があると認める) 右(より価値をおく) 開発での意味
プロセスやツールよりも 個人と対話を 手順書やツールより、人が直接話して決めることを優先する
包括的なドキュメントよりも 動くソフトウェアを 進んでいるかは書類ではなく、動くもので確かめる
契約交渉よりも 顧客との協調を 発注側と開発側が敵ではなく、同じチームとして決める
計画に従うことよりも 変化への対応を 計画は立てるが、分かったことに合わせて直す

宣言は続けて「すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。」と書いています。左側を捨てるとは書いていません。 ドキュメントも計画も作ります。迷ったときに右側を選ぶ、という優先順位の宣言です。

アジャイル宣言の背後にある12の原則

4つの価値を、より具体的な行動の指針にしたのが「アジャイル宣言の背後にある原則」です。公式の日本語訳と、要点を並べます。

No. 原則(公式の日本語訳) 要点
1 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 早く・続けて届ける
2 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。 変更を歓迎する
3 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 短い間隔でリリース
4 ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 毎日一緒に働く
5 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。 任せて信頼する
6 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 顔を合わせて話す
7 動くソフトウェアこそが進捗の最も重要な尺度です。 進み具合は動くもので測る
8 アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。 無理のないペースを保つ
9 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 設計と品質に手を抜かない
10 シンプルさ(ムダなく作れる量を最大限にすること)が本質です。 作らないものを増やす
11 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。 チームが自分で決める
12 チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。 定期的にふりかえる

12の原則は、4つにまとめると覚えやすくなります。

  • 早く届けて確かめる(原則1・3・7):動くものを短い間隔で出し、それを進み具合の物差しにする
  • 変化を受け入れる(原則2・10):後から分かった要求を取り込み、作らなくてよいものは作らない
  • 人とチームを中心にする(原則4・5・6・8・11):毎日話し、任せ、無理のないペースで続ける
  • 品質と改善を続ける(原則9・12):設計に注意を払い、定期的にやり方そのものを直す

原則3の「2-3週間から2-3ヶ月」は2001年の文言です。いまのスクラムでは、1周期を1か月以内にすると決めています(次の節)。

アジャイル開発の進め方:1スプリントの流れ

スクラムを例に、1つのスプリント(周期)の中で何が起きるかを図にしました。スクラムガイドでは、スプリントは1か月以内の決まった長さで、前のスプリントが終わるとすぐ次が始まります。

flowchart TD
    PB[プロダクトバックログ<br>順に並んだ作るものの一覧] --> SP[スプリントプランニング<br>ゴールと今回の項目を決める]
    SP --> SB[スプリントバックログ<br>今回の項目とタスク]
    SB --> DS[デイリースクラム<br>毎日15分で計画を直す]
    DS --> INC[インクリメント<br>完成の定義を満たす成果]
    INC --> RV[スプリントレビュー<br>成果を見せて次を相談]
    RV --> RT[スプリントレトロスペクティブ<br>やり方を改善]
    RT -->|次のスプリント| PB

流れを言葉で追うと、次のとおりです。

  1. プロダクトバックログ(作るものを優先度の順に並べた一覧)から、今回のスプリントで作る項目を選び、スプリントゴール(今回の目的)を決める
  2. 選んだ項目をタスクに分け、スプリントバックログにする
  3. 毎日デイリースクラムで、ゴールに近づいているかを確かめ、計画を直す
  4. 完成の定義(品質の基準)を満たしたものだけを「できた」とする
  5. スプリントレビューで、関係者に動くものを見せ、次に作るものを相談する
  6. スプリントレトロスペクティブで、チームの進め方を改善し、次のスプリントへ

この流れを数字で追った例は、後の節「実例:架空の会議室予約アプリでバックログからバーンダウンまで」に載せています。

スクラムとは(責任3つ・イベント5つ・作成物3つ)

スクラムは、アジャイル開発でいちばんよく使われるフレームワークです。 スクラムガイド2020年11月版(日本語版)は、スクラムを「複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワーク」と定義しています。スクラムガイドの最新版は2020年版で、改訂履歴にもそれより後の版はありません。

3つの責任(役割)

スクラムチームは、スクラムマスター1人・プロダクトオーナー1人・複数の開発者からなり、通常は10人以下です。2020年版では「役割」ではなく「責任(accountabilities)」と書かれています。

責任 何に責任を持つか 主な仕事
プロダクトオーナー プロダクトの価値を最大化すること プロダクトバックログの中身と並び順を決める
スクラムマスター スクラムチームの有効性 スクラムが正しく回るよう、チームと組織を支える
開発者 各スプリントで使えるインクリメントを作ること スプリントバックログを作り、品質を守って作る

5つのイベント

時間の上限(タイムボックス)は、1か月のスプリントの場合です。スクラムガイドでは、スプリントが短ければ、通常はイベントも短くなるとしています。

イベント 目的 時間の上限
スプリント ほかの4つのイベントを入れる器。アイデアを価値に変える 1か月以内の決まった長さ
スプリントプランニング スプリントで行う作業を計画する 最大8時間
デイリースクラム ゴールへの進み具合を確かめ、計画を直す 15分
スプリントレビュー 成果を確かめ、今後の方向を決める 最大4時間
スプリントレトロスペクティブ 品質と効果を高める方法を考える 最大3時間

3つの作成物と確約

2020年版では、作成物ごとに「確約(コミットメント)」が1つずつ決められています。

作成物 確約 中身
プロダクトバックログ プロダクトゴール プロダクトを良くするために必要なものを並べた一覧
スプリントバックログ スプリントゴール 今回のスプリントで作る項目と、その計画
インクリメント 完成の定義 プロダクトゴールに向けた、使える状態の成果

このほか、スクラムの土台として経験主義の3本柱(透明性・検査・適応)と、5つの価値基準(確約・集中・公開・尊敬・勇気)が書かれています。なお、2025年にはスクラムの共同考案者 Jeff Sutherland らが「スクラムガイド拡張パック」を公開しています。公式サイトでは「2020年版スクラムガイドの包括的な補完資料」と説明されており、スクラムガイドを置き換えるものではありません。

各イベントの進め方やチームの作り方は、関連記事「スクラム入門|スクラムガイド2020準拠の役割・イベント・進め方」で扱っています。

スクラム・カンバン・XPの違い

アジャイルの代表的な3つの手法は、決めている範囲が違います。スクラムは「チームの枠組み」、カンバンは「仕事の流れ」、XP は「技術的なやり方」を中心に決めています。

観点 スクラム カンバン XP
中心にあるもの 決まった長さの周期と役割 仕事の流れを見える化し、滞りを減らす 品質を保つ技術的なプラクティス
周期 1か月以内のスプリント 決まった周期は求めない 週単位・四半期単位の周期(第2版)
役割 プロダクトオーナー・スクラムマスター・開発者 定めない 定めた役割より、全員が1チームで座る
途中の変更 スプリントゴールを危うくする変更はしない いつでも次の項目を入れ替えられる 週の計画(Weekly Cycle)で次を選ぶ
主な指標 ベロシティ・バーンダウン(任意) WIP・スループット・仕掛かり日数・サイクルタイム 10分以内で終わるビルドとテスト(Ten-Minute Build)
主なプラクティス 5つのイベント・3つの作成物 WIP の上限・ワークフローの定義 テストファースト・ペアプログラミング・継続的インテグレーション
公式の文書 スクラムガイド(2020年) The Kanban Guide(2025年5月版) Kent Beck『Extreme Programming Explained』

The Kanban Guide は、カンバンを「プロセスを通る価値の流れを最適化するための戦略」と定義し、ワークフローの定義と見える化・仕掛かり中の項目の管理・ワークフローの改善の3つを実施事項にしています。WIP は「始めたが終わっていない作業項目の数」です。

XP の価値は、コミュニケーション・シンプルさ・フィードバック・勇気・尊重の5つです(Agile Alliance の用語集)。3つは組み合わせて使えます。 スクラムで周期を回し、ボードはカンバンの形で WIP を絞り、コードは XP のテストファーストと継続的インテグレーションで守る、という組み合わせがよく見られます。

状況 合いやすい手法 理由
新しいプロダクトを、決まった周期で見せながら作る スクラム 周期ごとにレビューで方向を直せる
問い合わせ対応・保守など、仕事が不規則に来る カンバン 周期を待たずに次の項目へ進める
品質の不安が大きい・変更のたびに壊れる XP のプラクティスを足す テストと継続的インテグレーションで変更を安全にする
少人数で、まず進め方をそろえたい スクラム イベントと作成物が決まっていて始めやすい

カンバンの列の作り方と WIP の決め方は、関連記事「カンバン方式のやり方 列の例とWIP制限の決め方・計算例」で扱っています。

実例:架空の会議室予約アプリでバックログからバーンダウンまで

ここからは、架空の小さな Web サービス「社内の会議室予約アプリ」を例に、プロダクトバックログ → スプリントバックログ → バーンダウンを数字で追います。チームは開発者3人、スプリントは2週間(10営業日)とします。

1. プロダクトバックログ(10項目・44ポイント)

プロダクトゴールは「社内の会議室を、スマホからすぐ予約できるようにする」です。プロダクトオーナーが価値の高い順に並べました。大きさはストーリーポイント(作業の大きさを相対的に表す数)で見積もっています。

順 ID ユーザーストーリー ポイント
1 PB-1 社員として、空いている会議室の一覧を見たい 3
2 PB-2 社員として、日時を選んで会議室を予約したい 5
3 PB-3 社員として、自分の予約を一覧で見たい 2
4 PB-4 社員として、予約を取り消したい 2
5 PB-5 社員として、予約の確認メールを受け取りたい 3
6 PB-6 社員として、定例会議を繰り返し予約したい 8
7 PB-7 社員として、モニターなどの設備で会議室を絞り込みたい 3
8 PB-8 管理者として、会議室を登録・編集したい 5
9 PB-9 社員として、予約状況をカレンダーで見たい 8
10 PB-10 社員として、予約を Slack で知らせたい 5

合計は44ポイントです。上の4項目だけで「空きを見て、予約して、確かめて、取り消せる」最小の形になります。書き方と並べ方の詳細は、関連記事「プロダクトバックログの書き方と例|優先順位の付け方とテンプレート」で扱っています。ポイントの付け方は、関連記事「ストーリーポイントの見積もり方|基準表とプランニングポーカー手順」で扱っています。

2. スプリントバックログ(4項目・タスク14個・70時間)

スプリントプランニングで、スプリントゴールを「空き会議室を見て予約し、取り消せる」に決め、PB-1〜PB-4(12ポイント)を選びました。開発者が項目をタスクに分け、時間で見積もります。

項目 タスク(見積もり時間) 計
PB-1 空き会議室の一覧を見る 画面設計 4・一覧API 6・一覧画面 6・ログイン連携 8・テスト 4 28時間
PB-2 日時を選んで予約する 予約API(重複チェック)10・予約画面 8・テスト 6 24時間
PB-3 自分の予約を一覧で見る 予約一覧API 4・一覧画面 4・テスト 2 10時間
PB-4 予約を取り消す 取消API 3・取消ボタン 3・テスト 2 8時間

合計70時間です。毎日のデイリースクラムで「残り時間」を記録しました。4日目に、予約APIの重複チェックの不具合が見つかり、修正のタスクを6時間分足しています。

3. バーンダウンを Python で計算する

バーンダウンチャートは、残りの作業量を日ごとに並べた図です。開始時の量から終了日の0まで、まっすぐ減る線を「理想線」と呼び、実際の残りと比べます。次のコードは、理想線・実際との差・1日ごとの減り・ベロシティ・残りの見込みを計算し、文字のグラフで出します。

import math

# スプリント1のスプリントバックログ(タスクと見積もり時間)
sprint_backlog = {
    "PB-1 空き会議室の一覧を見る": {"画面設計": 4, "一覧API": 6, "一覧画面": 6, "ログイン連携": 8, "テスト": 4},
    "PB-2 日時を選んで予約する": {"予約API(重複チェック)": 10, "予約画面": 8, "テスト": 6},
    "PB-3 自分の予約を一覧で見る": {"予約一覧API": 4, "一覧画面": 4, "テスト": 2},
    "PB-4 予約を取り消す": {"取消API": 3, "取消ボタン": 3, "テスト": 2},
}
points = {"PB-1 空き会議室の一覧を見る": 3, "PB-2 日時を選んで予約する": 5,
          "PB-3 自分の予約を一覧で見る": 2, "PB-4 予約を取り消す": 2}

total = sum(sum(t.values()) for t in sprint_backlog.values())
days = 10  # 2週間スプリント=10営業日

# デイリースクラムで記録した「残り時間」(0日目=スプリント開始時)
actual = [70, 66, 61, 58, 60, 52, 45, 37, 28, 16, 5]
assert actual[0] == total

print(f"スプリントバックログ合計: {total} 時間 / {days} 日")
print(f"{'日':>2} {'理想':>6} {'実際':>4} {'差':>6}  グラフ(1文字=2時間、+=理想より多い分)")
for d in range(days + 1):
    ideal = total - total / days * d
    diff = actual[d] - ideal
    a, i = round(actual[d] / 2), round(ideal / 2)
    bar = "".join("+" if c >= i else "#" for c in range(a))
    print(f"{d:>2} {ideal:>6.1f} {actual[d]:>4} {diff:>+6.1f}  {bar}")

burn = [actual[d - 1] - actual[d] for d in range(1, days + 1)]
print("1日ごとの減り:", burn)
print(f"平均の減り: {sum(burn) / days:.1f} 時間/日(理想 {total / days:.1f})")

# スプリント終了時:完成した項目だけをベロシティに数える
done = ["PB-1 空き会議室の一覧を見る", "PB-2 日時を選んで予約する", "PB-3 自分の予約を一覧で見る"]
velocity = sum(points[k] for k in done)
print(f"完成: {len(done)} 項目 / 未完成: PB-4(残り {actual[-1]} 時間)")
print(f"ベロシティ: {velocity} ポイント")

backlog_total = 44  # プロダクトバックログ全体(PB-1〜PB-10)
left = backlog_total - velocity
print(f"残りのプロダクトバックログ: {left} ポイント → あと {math.ceil(left / velocity)} スプリントの見込み({left}/{velocity}={left / velocity:.1f})")

python3 burndown.py で実行した出力です。

スプリントバックログ合計: 70 時間 / 10 日
 日     理想   実際      差  グラフ(1文字=2時間、+=理想より多い分)
 0   70.0   70   +0.0  ###################################
 1   63.0   66   +3.0  ################################+
 2   56.0   61   +5.0  ############################++
 3   49.0   58   +9.0  ########################+++++
 4   42.0   60  +18.0  #####################+++++++++
 5   35.0   52  +17.0  ##################++++++++
 6   28.0   45  +17.0  ##############++++++++
 7   21.0   37  +16.0  ##########++++++++
 8   14.0   28  +14.0  #######+++++++
 9    7.0   16   +9.0  ####++++
10    0.0    5   +5.0  ++
1日ごとの減り: [4, 5, 3, -2, 8, 7, 8, 9, 12, 11]
平均の減り: 6.5 時間/日(理想 7.0)
完成: 3 項目 / 未完成: PB-4(残り 5 時間)
ベロシティ: 10 ポイント
残りのプロダクトバックログ: 34 ポイント → あと 4 スプリントの見込み(34/10=3.4)
+18時間理想線との差が最大(4日目)不具合の修正で作業が6時間増えた日
10ptベロシティ(完成した分だけ)PB-4 は残り5時間で数えない
4回残り34ポイントに要るスプリント34÷10=3.4 を切り上げ

4. 数字の読み方と、次のスプリントでしたこと

  • 1〜3日目:理想線より少しずつ上にずれています。最初は画面設計やログイン連携など、終わるまで残りが減りにくい作業が多いためです。
  • 4日目:残りが58時間から60時間に増えました。その日の作業で4時間減り、不具合の修正で6時間増えたので、差し引き2時間の増加です。バーンダウンが上がった日は、作業が増えたことをデイリースクラムで共有する合図になります。
  • 5〜10日目:1日に7〜12時間減り、差は縮みましたが、終了時に5時間残りました。残りは PB-4 の取消ボタンとテストです。
  • ベロシティ:完成の定義を満たした PB-1〜PB-3 の10ポイントだけを数えます。作りかけの PB-4 は0ポイントです。PB-4 はプロダクトバックログに戻り、プロダクトオーナーが並び順を決め直します。
  • 見込み:残り34ポイントを10ポイントずつ進めると、あと4スプリントの見込みです。1回分のベロシティだけでは揺れが大きいため、スプリントを重ねて平均を取り、見込みを更新していきます。

このスプリントのレトロスペクティブでは、「重複チェックのような判定の多い処理は、テストを先に書く」と決め、次のスプリントでは PB-4 と PB-5 に加えて、テストを先に書くタスクを足しました。

なお、スクラムガイドはバーンダウンチャートを必須にしていません。改訂履歴では、2011年版でバーンダウンを必須としないことにした、とあります。進み具合の見せ方はチームが選べます。

アジャイルが向く案件・向かない案件

アジャイルが合うかどうかは、主に「要件がどのくらい変わるか」と「関係者が周期ごとに関われるか」で決まります。

状況 向き 理由
新規サービス・新規事業で、何が受けるか分からない 向く 早く出して反応を見て、次を決められる
社内ツールで、使う人がすぐ近くにいる 向く 周期ごとに見てもらい、直せる
要件が決まっていて、途中で変わらない どちらでも 順に作る方式でも進めやすい
法令・規格で仕様と期日が固定されている 向きにくい 変化への対応の利点が出にくい。周期を使っても範囲は動かせない
機器の製造・据え付けなど、後から作り直せない 向きにくい 小さく作って直す前提が成り立ちにくい
発注側の担当者がレビューや優先順位決めに関われない 向きにくい プロダクトオーナーの仕事を担う人がいない
一括で納める契約で、範囲と金額が最初に固定 契約の形を検討 範囲を動かす前提と契約が合わない

当てはまる数で目安を見るチェックリストです。

4つ以上当てはまれば、アジャイルの利点が出やすい形です。1と2が当てはまらず、3と6も難しいなら、順に作る方式が合うことが多くなります。両方式の選び方の診断は、関連記事「ウォーターフォールとアジャイルの違い比較表|開発手法の選び方診断」で扱っています。

アジャイルのよくある誤解

誤解 1アジャイルは計画を立てない
→
実際計画を何度も立て直す

スクラムでは毎スプリントのプランニングと毎日のデイリースクラムで計画を直す

誤解 2ドキュメントを書かなくてよい
→
実際必要なものは書く

宣言は「左記のことがらに価値があることを認めながらも」と書いている

誤解 3アジャイルにすれば速く安くなる
→
実際早く確かめられる

作る量が減るのは、要らない機能を早く見つけて作らなかったとき(原則10)

誤解 4アジャイルとスクラムは同じ
→
実際スクラムはアジャイルの手法の1つ

カンバン・XP など、価値観を共有するほかの手法もある

誤解 5短く作るので品質が下がる
→
実際品質の基準を毎回満たす

スクラムは完成の定義を満たしたものだけを成果とし、原則9は設計への注意を求めている

誤解 6途中でいつでも何でも変えられる
→
実際変えるのは次の周期から

スクラムではスプリントゴールを危うくする変更はしない。変更はプロダクトバックログに入れる

誤解の多くは、4つの価値の「左側を捨てる」と読むことから生まれます。 実際は「両方に価値があり、迷ったら右側を選ぶ」という順位づけです。

要件をユーザーの言葉で小さく書く方法は、関連記事「ユーザーストーリーの書き方と例30選|受け入れ基準Given-When-Then」で扱っています。

よくある質問

Q. アジャイルとは何ですか? A. 短い周期で動くソフトウェアを作って見せ、変化に合わせて計画を直し続ける開発の考え方です。2001年のアジャイルソフトウェア開発宣言の4つの価値と12の原則がもとになっています。

Q. アジャイル開発とは、具体的に何をするのですか? A. 作るものを優先度の順に並べ、1か月以内の短い周期ごとに上から作って見せ、反応を見て次を決めます。流れは「1スプリントの流れ」、数字の例は「実例」の節にあります。

Q. アジャイルの意味は? 英語では? A. 英語の agile は「素早い」「機敏な」という意味です。開発では、変化に素早く対応できる進め方を指します。

Q. アジャイルとスクラムの違いは? A. アジャイルは価値観と原則の総称で、スクラムはそれを実現するフレームワークの1つです。スクラムには責任3つ・イベント5つ・作成物3つが決まっています。

Q. アジャイルとウォーターフォールの違いは? A. ウォーターフォールは工程を順に1回進めて最後に完成品を渡し、アジャイルは短い周期で一部分ずつ作って確かめます。詳しい比較と選び方は、関連記事「ウォーターフォールとアジャイルの違い比較表|開発手法の選び方診断」で扱っています。

Q. バーンダウンチャートとベロシティは何ですか? A. バーンダウンチャートは残りの作業量を日ごとに並べた図で、ベロシティは1スプリントで完成した作業量(ポイントの合計)です。作りかけの項目はベロシティに数えません。

まとめ

  • アジャイルは、短い周期で動くものを作って確かめ、変化に合わせて計画を直す開発の考え方の総称。
  • 4つの価値は「左側にも価値を認めたうえで、右側により価値をおく」順位づけ。12の原則がそれを行動に落としている。
  • スクラムは責任3つ・イベント5つ・作成物3つ。最新のスクラムガイドは2020年版で、スプリントは1か月以内。
  • スクラムは枠組み、カンバンは流れ、XP は技術を中心に決めていて、組み合わせて使える。
  • 架空アプリの例では、70時間のスプリントで5時間残り、ベロシティは完成分の10ポイント、残り34ポイントはあと4スプリントの見込みになった。
  • 要件が変わりやすく、優先順位を決める人が周期ごとに関われる案件で、アジャイルの利点が出やすい。

参考・出典

確認日はいずれも 2026年10月17日です。

  • アジャイルソフトウェア開発宣言(日本語):https://agilemanifesto.org/iso/ja/manifesto.html
  • アジャイル宣言の背後にある原則(日本語):https://agilemanifesto.org/iso/ja/principles.html
  • History: The Agile Manifesto:https://agilemanifesto.org/history.html
  • スクラムガイド 2020年11月版(日本語):https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
  • Scrum Guide Revision History:https://scrumguides.org/revisions.html
  • スクラムガイド拡張パック(日本語):https://scrumexpansion.org/ja/
  • The Kanban Guide:https://kanbanguides.org/english/
  • Agile Alliance「Extreme Programming (XP)」:https://www.agilealliance.org/glossary/xp/

本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。

(記載例)出典:株式会社RJC「アジャイルとは|4つの価値・12の原則とスクラムを実例で解説」

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。

WE ARE HIRING

RJCで一緒に開発しながら、
成長を楽しみませんか?

RJCは、Web・モバイル・AIを活用した開発プロジェクトで、テックリードやPM・PMOも活躍するシステム開発会社です。会社を知る、待遇を確かめる、話を聞いてみる。気になるところ見てみてください!

  • 127日年間休日
  • 12時間平均残業時間
  • 毎日ガチャ遊びココロも大切にする福利厚生。アマギフなどの賞品ラインナップ!

ほかにも、チケットレストラン、書籍読み放題、2年ごとの慰労報奨(休暇 or 金一封)、11期連続の黒字決算。

ABOUT RJC RJCがどんな会社か知る 考え方、研修、働き方、福利厚生、社員の前職まで。RJCのことが丸わかり! RJC丸わかりページへ JOB DESCRIPTION 仕事内容・待遇を見てみる 仕事内容、給与・待遇、選考の流れ。経験者も未経験も!応募前に知りたいこと、まとめました! 募集要項を見る ENTRY エントリーする エントリーは1〜2分・履歴書不要です。まずは話を聞いてみたい、という方でも歓迎です! エントリーフォームへ

RJCで一緒に開発しながら、 成長を楽しみませんか?