全部説明できたらアジャイルマスター？ 知っておきたいアジャイル用語34選：新規参入者への用語集としても活用できる

TechTargetは2025年1月13日、「知っておくべきアジャイル用語」に関する記事を公開した。アジャイルは、多くの開発プロジェクトの基盤となっている。この用語集をアジャイルの専門用語や概念を素早く確認できるレファレンスとして役立ててほしい。

[TechTarget]

印刷

見るPost

Shareシェア

はてなブックマーク

SharePocket Button

　TechTargetは2025年1月13日（米国時間）、「知っておくべきアジャイル用語」に関する記事を公開した。

知っておくべきアジャイル用語34選（提供：TechTarget）

　アジャイルは、その誕生から20年以上を経て、ソフトウェア開発における主流の考え方へと成長している。

　アジャイルは数多くの手法や派生フレームワーク、方法論を生み出し、現代の開発者が仕事に取り組み方に大きな影響を与えている。それだけでなく、アジャイルは独自の専門用語も生み出している。こうした用語は、キャリアを育む過程でアジャイル環境で働く可能性のある現代の開発者、テスト担当者、プロジェクトマネジャーにとって理解が欠かせない。

　本稿を活用してアジャイルを理解し、アジャイルが現代のアプリケーション開発に及ぼす広範な影響を把握するために重要な用語を再確認しよう。

1．受け入れテスト
2．アジャイルソフトウェア開発宣言
3．アジャイル手法
4．振る舞い駆動開発
5．バーンダウンチャート
6．バーンアップチャート
7．継続的デリバリー
8．継続的デプロイメント
9．継続的改善
10．継続的インテグレーション
11．デイリースタンドアップ
12．完了の定義
13．DevOps
14．動的システム開発手法
15．エクストリームプログラミング
16．イテレーション
17．カンバン
18．リーン
19．モブプログラミング
20．ペアプログラミング
21．プランニングポーカー
22．プロダクトバックログ
23．プロダクトオーナー
24．SAFe
25．スクラム
26．スクラムマスター
27．スクラムバン
28．ソフトウェア開発ライフサイクル
29．スプリント
30．ストーリーポイント
31．テスト駆動開発
32．スリーアミーゴスミーティング
33．タイムボックス
34．ユーザーストーリー

続きを読む

受け入れテスト（Acceptance Testing）

　受け入れテストは、ソフトウェアテストの最終段階で実施されることが多い。通常は、エンドユーザーやクライアントがシステムをテストし、合意された要件を満たしているかどうかを確認するプロセスを指す。受け入れテストは、組織がエンドユーザーをテストプロセスに関与させ、彼らからのフィードバックを収集するための重要な手段と言える。

» トップへ戻る

アジャイルソフトウェア開発宣言（Agile Manifesto）

　アジャイルソフトウェア開発宣言は、アジャイル手法を定義するドキュメントという位置付けだ。この宣言には、ソフトウェア開発の指針となる「4つの価値」と「12個の原則」が記されている。Agile Allianceという開発者グループによって2001年に作成された。

　アジャイル宣言が掲げる“4つの価値”は以下の通り。

• プロセスやツールよりも個人と対話を重視する
• 網羅的なドキュメントよりも動くソフトウェアを重視する
• 契約交渉よりも顧客との協調を重視する
• 計画に従うことよりも変化への対応を重視する

» トップへ戻る

アジャイル手法（Agile Methodology）

　アジャイル手法とは、製品の開発とリリースにおける柔軟性と実用性を重視する手法だ。アジャイルでは、プロジェクト管理とソフトウェア開発に反復的なアプローチ（イテレーション）を取り入れ、継続的な改善を通じてコラボレーションや適応力を高める。アジャイル開発の指針となる原則は、アジャイルソフトウェア開発宣言に記載されている。

アジャイルの12の原則はアジャイルマニフェストで概説されている

　アジャイルは、ソフトウェア開発の多くのフレームワークや手法（スクラム、カンバン、実用的プログラミングなど）の基盤となっており、柔軟性に欠けるとされる従来の手法（ウオーターフォール開発など）に対抗する代替アプローチとして考案された。

» トップへ戻る

振る舞い駆動開発（BDD：Behavior-Driven Development）

　BDDは、アジャイル開発の技法の一つで、最初にテストを定義し、そのテストが成功するようにコードを追加していく手法だ。開発者やステークホルダーの期待通りにソフトウェアが動作するかどうかに重点を置いてテストする。ソフトウェアが関係者や開発者の想定通りに動作すれば、テストは成功と見なされる。

» トップへ戻る

バーンダウンチャート（Burndown Chart）

　バーンダウンチャートは、プロジェクト管理ツールの一つで、プロジェクト内で完了すべき作業量を視覚的に表現したものだ。作業量は縦軸上のラインで表され、そのラインが縦軸の最下部に達するとプロジェクトは完了となる。

» トップへ戻る

バーンアップチャート（Burnup Chart）

　バーンアップチャートは、プロジェクト全体の作業量と、既に完了した作業量を視覚的に表現したものだ。バーンアップチャートを使うことで、アジャイルチームは全体のスコープ（範囲）の中でプロジェクトがどのくらい進捗（しんちょく）しているかを把握できる。

　バーンアップチャートには、縦軸上に2本のラインが走っている。1本目のラインはプロジェクトの総作業量を示し、2本目のラインは完了した作業量を示す。両者のラインが交わるとプロジェクトが完了となる。

» トップへ戻る

継続的デリバリー（CD：Continuous Delivery）

　継続的デリバリーは、CI/CDパイプライン（継続的インテグレーション/継続的デリバリー）における後半の工程だ。この工程では、ソフトウェアのビルドがより包括的なテストを経て、デプロイ（本番環境への配備）の準備が整う。ビルドが検証に成功すると、デプロイ用にパッケージ化され、ステージング環境（本番環境と同等のテスト環境）に移される。ステージング環境では、そのビルドをデプロイするか、開発環境に戻すかを人間が判断する。

» トップへ戻る

継続的デプロイメント（CD：Continuous Deployment）

　継続的デプロイメントは、継続的デリバリーに自動化の工程を加えた手法だ。ビルドが検証に成功した後、人の判断を介さずに自動的にデプロイが実行される。

» トップへ戻る

継続的改善（Continuous Improvement）

　継続的改善（単に「カイゼン」とも呼ばれる）は、小さな改善を積み重ねることで、長期的に大きな成果を生み出すという考え方だ。アジャイルは迅速なフィードバックループと反復的なリリースによって、ソフトウェア開発における継続的改善を促進している。

» トップへ戻る

継続的インテグレーション（CI：Continuous Integration）

　継続的インテグレーション（CI）は、開発パイプラインの初期段階を自動化する手法だ。CIでは、複数の開発者が同時にコード変更を共有リポジトリにマージ（統合）できる。マージされたコードは、ユニットテスト（単体テスト）、インテグレーションテスト（結合テスト）、リグレッションテスト（回帰テスト）などの一連の自動テストを受ける。

　CI/CDパイプラインの前半に当たる工程であり、ビルドが初期テストを完了し、より大規模なテストに進める状態になれば完了と見なされる。

CIとCDはどのように連携するか

» トップへ戻る

デイリースタンドアップ（Daily Stand-up）

　デイリースタンドアップは、アジャイルチームが毎日行う短時間のミーティングだ。これによって透明性を高め、課題を特定し、プロジェクトに関する懸念に対処し、チームの責任意識を強化する。

　このミーティングでは、メンバーがそれぞれの進捗状況を報告し、その日の作業計画を共有する。アジャイルのフレームワークには、それぞれ独自のデイリースタンドアップの形式が存在する。例えばスクラム（Scrum）では「デイリースクラム」と呼ばれ、チームメンバーの役割ごとに具体的な参加方法が定められている。

» トップへ戻る

完了の定義（Definition of Done）

　アジャイルにおける「完了（Done）」の定義とは、プロジェクト（またはユーザーストーリー）が「完了」と見なされ、次の工程に進むために満たすべき基準や要件をまとめたリストのことだ。チームはプロダクトインクリメント計画（Product Increment Planning）の際に、完了の定義を作成する。そのため、全てのチームのメンバーは、自身の役割と「完了の定義」を満たすために必要な責任を理解しておく必要がある。

» トップへ戻る

DevOps

　DevOpsは、開発チームと運用チームの連携を促進し、両者の間のサイロ（分断）を解消することを目的とした開発思想だ。DevOpsは、技術的な変化と文化的な変化の両方に重点を置き、両チームの連携を強化する。DevOpsの代表的な技術としては、CI/CDパイプラインがある。これは、ソフトウェアの継続的な開発とデプロイに関わる作業を自動化する。また、リアルタイム監視ツールもDevOps技術の一例だ。開発チームと運用チームの双方が同じデータを基に判断できるため、両チーム共通の作業基盤として連携をよりスムーズにする。

DevOpsの主要コンポーネントは、アジャイルチームがアジャイルの原則や価値観を守るのに役立つ

» トップへ戻る

動的システム開発手法（DSDM：Dynamic Systems Development Method）

　DSDMは、アジャイルフレームワークの一種で、ユーザーの積極的関与、迅速なデリバリー、ビジネスニーズを重視する。DSDMは、ソフトウェアを迅速に提供したいというニーズに応えるために開発された。

　このフレームワークでは、システム要件の優先順位付けにMoSCoW法を用いる。MoSCoW法では、要件を次の4つのカテゴリーに分類する。

• Must-have（必須）：プロジェクトの成功に不可欠な要件
• Should-have（推奨）：重要だが必須ではない要件
• Could-have（できれば対応）：あればよいが優先度は低い要件

» トップへ戻る

エクストリームプログラミング（XP：Extreme Programming）

　XPは、アジャイル手法の一つ。フィードバックを取り入れ、開発サイクルを短縮してリリース頻度を上げることで、ソフトウェア品質の向上を重視する。

　XPでは、コードレビューやドキュメント作成などの従来の開発作業を、複数のチームで継続的かつ並行して実施するのが特徴だ。例えばペアプログラミング（Pair Programming）では、1人のプログラマーがリアルタイムで他のプログラマーの作業内容を確認しながらコードを作成する。これによって作業完了後にレビューするよりも早期に問題を発見できる。

» トップへ戻る

イテレーション（Iteration）

　イテレーションとは、開発プロセスの全ステップを一度実行することだ。例えば、開発チームが製品をリリース可能な段階まで進めれば、その1サイクルがイテレーションだ。

　イテレーティブ開発（反復型開発）では、このイテレーションを繰り返し、各サイクルでのフィードバックを取り入れながら、製品を継続的に改善する。

» トップへ戻る

カンバン（Kanban Board）

　カンバンは、アジャイルチームがプロジェクトの進捗状況を視覚的に管理するためのツールだ。カンバンには各タスクを表すカードが配置され、チームはこれらのカードを各列間で移動させることで進捗を管理する。列はプロジェクトの各ステージを示しており、例えば「作業中（Work in Progress）」の列から「完了（Completed）」の列へカードを移動させることで、そのタスクが完了したことが分かる。

カンバンは、チームが各作業項目の進捗を視覚化するのに役立つ

» トップへ戻る

リーン（Lean）

　リーン管理（Lean Management）またはリーン生産方式（Lean Production）は、無駄を減らし、最小限のリソースで最終成果物を製造することに重点を置いた手法だ。リーンの原則は、付加価値を生み出さない活動は取りやめ、業務効率を向上し、品質と効率を継続的に上げることを目指している。

» トップへ戻る

モブプログラミング（Mob Programming）

　モブプログラミングは、複数の開発者が1つのタスクにリアルタイムで協力して取り組む手法だ。チーム全体の知識を活用することで、個人では解決が難しい問題に対応しやすくなる。

　モブプログラミングは、次の3つの役割で構成される。

• ドライバー（Driver）：PCを操作する担当者
• ナビゲーター（Navigator）：モブの意見をドライバーに伝え、コードに反映させる役割
• モブ（Mob）：問題について議論し、解決策を導くチーム全体

　モブの議論をトピックに沿って進め、目の前の問題に焦点を当てる役割を担う人を「チャンピオン」（Champion）と呼ぶ場合がある。

» トップへ戻る

ペアプログラミング（Pair Programming）

　ペアプログラミングは、2人の開発者が協力してユーザーストーリーの設計、コーディング、テストをするアジャイルの実践手法だ。

　ペアプログラミングは、次の2つの役割で構成される。

• ドライバー（Driver）：PCを操作してコーディングする。
• ナビゲーター（Navigator）：ドライバーの作業を見守りつつ、全体の方向性を指示する。

　ペアプログラミングは、アジャイルチーム内での協力体制を強化し、個人では難しい問題を解決するのに役立つ。

» トップへ戻る

プランニングポーカー（Planning Poker）

　プランニングポーカーは、アジャイルの見積もり手法の一つで、ゲーム形式で実施される協力的なアプローチだ。

　この手法では、チームメンバーがカードデッキを使用し、各タスクに必要な時間や労力を個別に見積もる。各メンバーは見積もり結果を同時に提示し、意見を出し合いながら合意を形成する。

» トップへ戻る

プロダクトバックログ（Product Backlog）

　プロダクトバックログは、製品の機能、要件、改善点を優先度順にまとめたリストだ。開発チームは、このプロダクトバックログを動的な「やるべきことリスト」（ToDoリスト）として活用し、進行中の作業や今後取り組むべきタスクを管理する。

» トップへ戻る

プロダクトオーナー（Product Owner）

　プロダクトオーナーは、スクラムにおける責務（役割）の一つ。

　開発チームやステークホルダーと連携して、プロダクトの最も価値ある要素に優先順位を付け、プロダクトの目標を定義し、プロダクトバックログを管理する。また、チームがスプリント（Sprint）の目標を定義するのを支援する。

» トップへ戻る

SAFe（Scaled Agile Framework）

　SAFeは、大規模な組織でアジャイル手法を導入するためのフレームワークで、複数のチームや複雑なプロジェクトの調整を支援する。

　トップダウン型のアプローチを採用しており、開発とビジネス戦略や目標を一致させることに重点を置く。アジャイル開発、システム思考、リーンという3つの要素を組み合わせたフレームワークとなる。

» トップへ戻る

スクラム（Scrum）

　スクラムは、アジャイルプロジェクト管理と開発のフレームワークの一つで、責任の明確化、チームワーク、反復型の開発に重点を置いている。

　スクラムチームは、次の3つの責務（役割）で構成される。

• スクラムマスター（Scrum Master）：スクラムの実践と原則の定着を支援する役割。
• プロダクトオーナー：プロダクトの目標を定め、価値の最大化に責任を持つ。
• スクラムデベロッパー（Scrum Developers）：プロダクトの開発作業を行うチームメンバー。

　スクラムは、スプリントと呼ばれる短い反復サイクルを通じて作業を進める。スプリントは、開発作業をより短い反復に分割することでリスクを最小限に抑えることができる。これによって、チームはより動的にフィードバックを収集し、取り入れることが可能になる。

スクラムは、3つの役割または責任で構成される

» トップへ戻る

スクラムマスター（Scrum master）

　スクラムにおける3つの主要責務の一つ。スクラムマスターはチームのファシリテーター兼アジャイルコーチを務める。チームの進捗を妨げる障害を取り除き、チームがアジャイルの原則に従うよう指導することが主な目標となる。

» トップへ戻る

スクラムバン（Scrumban）

　スクラムバンは、スクラムとカンバンを組み合わせたハイブリッド型のアジャイル開発フレームワーク。クラムのイベント（スプリント、デイリースクラム、レトロスペクティブ）を使い、ワークフローと進行中の作業の制限事項（WIP：Work In Progress）を一目で分かるようにするカンバンの利点を取り入れている。

» トップへ戻る

ソフトウェア開発ライフサイクル（SDLC：Software development lifecycle）

　SDLCは、ソフトウェア開発プロセスを複数の明確なフェーズに分割したもの。フェーズとしては、計画、分析、設計、実装、テスト、デプロイメント、保守が含まれる。SDLCによって、ソフトウェアプロジェクトの構想からデプロイメントに関する反復可能なガイドラインが提供される。

» トップへ戻る

スプリント（Sprint）

　スプリントは、一定の期間内に開発作業を完了させるためのタイムボックス（期限の決められた時間枠）のこと。スプリントは、プランニングセッション、デイリーミーティング、スプリントレビューで構成される。スプリントレビューでは、チームの完了した作業がステークホルダーに示され、フィードバックが集められる。スクラムでは、スプリントの期間は1カ月を超えないものと定められている。

» トップへ戻る

ストーリーポイント（Story points）

　ストーリーポイントは、アジャイルにおける見積もり手法の一つで、タスクやユーザーストーリーの完了に必要な労力を測定する。ストーリーポイントは、作業に要する時間ではなく、作業の難易度や複雑さ、リスクに基づいて見積もる点が特徴だ。

» トップへ戻る

テスト駆動開発（TDD：Test-driven development）

　TDDはアジャイル開発手法の一つであり、大まかに言えばコードの作成前にテストを書くというアプローチのこと。

　ソフトウェアコードを記述する前にテストを作成するアジャイル開発プラクティス。TDDの開始時にはコードが存在しないため、全てのテストが不合格になる。その後、テストに合格するまでコードを段階的に記述する。

» トップへ戻る

スリーアミーゴスミーティング（Three Amigos Meetings）

　スリーアミーゴスミーティングは、スプリント計画や評価のために、ビジネス（業務）、開発、品質保証（QA）の3つの視点を統合、調整することを目的として協力的なセッションだ。

　業務担当者またはプロダクトオーナー、開発者、QAの専門家で構成されるのが一般的で、どのようなプロダクトを製造すべきか、どのように製造するか、製造したプロダクトをどのように評価するかについての合意を形成するのに役立つ。

» トップへ戻る

タイムボックス（Timebox）

　タイムボックスとは、タスクまたはアクティビティーを完了するために指定される割り当て時間のこと。アジャイルにおいては、多くのアクティビティーがタイムボックス化されており、例えばスプリントは通常1カ月以内と定められている。

　アジャイルアクティビティーの多くには、タイムボックスが明確に定められている。例えば、スプリントは一定時間内（通常は1カ月以内）に完了することが定められている。タイムボックスを定めることで、アジャイルチームの集中力と効率を高めることができる。

» トップへ戻る

ユーザーストーリー（User Stories）

　ユーザーストーリーは、ソフトウェアの機能や要件をユーザー視点で簡潔に記述したもの。一般的に、次の形式で表現される。

「（ユーザーとして）、（行動）したい。そうすることで（結果）が得られる。」

　ユーザーストーリーは、特定の機能や要件がエンドユーザーにどのような価値を提供するかを説明する。また、開発者が作業の優先順位を付けるためのツールとしても利用される。