アジャイル開発とは？

アジャイルは、たった 1 つの賭けを中心に構築された手法群の総称です。その賭けとは、ソフトウェアは事前に詳細まで計画するには予測不可能すぎる、だから小さなスライスで届け、返ってくるものに耳を傾け、絶えず調整する、というものです。

このページでは背景を扱います。これらをすでにすべて知っているなら、East Agile Tracker はアジャイルにどう対応するか までざっと読み飛ばしてください。

アジャイルマニフェスト

2001 年 2 月、17 人のソフトウェア実践者 — Kent Beck、Martin Fowler、Robert Martin、Ron Jeffries ら — がユタ州のスキーロッジに集まり、自分たちに共通するものを書き留めました。彼らはそれを アジャイルマニフェスト と呼びました。それは 4 行です。

私たちは、ソフトウェア開発を実践し、また他者の実践を支援することを通じて、より良い開発方法を見つけ出そうとしている。この活動を通じて、私たちは以下の価値に至った。

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

すなわち、右に挙げた項目にも価値はあるが、私たちは左に挙げた項目により価値を置く。

それだけです。1 ページの前文、12 の支持する原則、そして上の 4 行。これは現代のソフトウェア実践において最も影響力のある文書です。

12 の原則

4 つの価値の背後で、マニフェストの 12 の原則が「アジャイル」が日々実際にどう見えるかを明確にしています。

1. 最優先事項は、価値あるソフトウェアを早く継続的に届けることで顧客を満足させることである。
2. 要求の変更を、たとえ遅い段階であっても歓迎する。アジャイルプロセスは、変化を顧客の競争上の優位のために活用する。
3. 動くソフトウェアを頻繁に届ける — 数か月ではなく数週間で。
4. ビジネス側の人々と開発者は、日々一緒に働かなければならない。
5. 意欲ある個人を中心にプロジェクトを構築する。彼らに必要なものを与え、仕事を成し遂げると信頼する。
6. 情報を伝える最も効率的な方法は、対面での会話である。
7. 動くソフトウェアこそが進捗の主たる尺度である。
8. アジャイルプロセスは持続可能な開発を促進する — 一定のペースを、無期限に。
9. 技術的卓越性と良い設計への継続的な注意が、機敏さを高める。
10. シンプルさ — やらない作業量を最大化する技術 — は不可欠である。
11. 最良のアーキテクチャ、要求、設計は、自己組織的なチームから生まれる。
12. チームは定期的に、どうすればより効果的になれるかを振り返り、やり方を調整し適応させる。

手法群

「アジャイル」は総称です。その下にはいくつかの異なる方法論があります。

• eXtreme Programming（XP） — この一族で最も要求の厳しいもの。ペアプログラミング、TDD、継続的インテグレーション、オンサイト顧客、小さなリリース。私たちの XP ページ を参照。
• Scrum — スプリント と呼ばれるタイムボックス化されたイテレーション、毎日のスタンドアップ、名前付きの役割（Product Owner、Scrum Master）。エンジニアリングプラクティスは XP より軽め。
• Kanban — ワークフローを可視化し、仕掛り作業を制限し、フローを最適化する。タイムボックスはなく、プッシュではなくプルする。
• Lean — トヨタ生産方式から借りたもの: ムダを排除し、全体を最適化し、速く届け、品質を作り込む。

これらの手法は重なり合い、組み合わさります。実際に働くほとんどのチームは 4 つすべてからいいとこ取りをします。East Agile Tracker は XP 寄りの考えを持っていますが — eXtreme Programming を参照 — 提供するものの大部分はどのアジャイルの流派でも機能します。

アジャイルで ない もの

名指しする価値のある根強い誤解がいくつかあります。

• アジャイルは「計画なし」ではない。 計画はより小さく、より短くなるが、計画は絶えず行われる。
• アジャイルは「ドキュメントなし」ではない。 必要なものを書く。マニフェストは、動くソフトウェアが包括的なドキュメントよりも 価値がある と言っているのであって、ドキュメントが悪いとは言っていない。
• アジャイルは Scrum ではない。 Scrum は 1 つの アジャイル手法である。手法は複数ある。
• アジャイルはツールではない。 どんなツールもあなたをアジャイルにはしない。アジャイルは働き方である。ツール（これを含む）は助けにはなるが、代わりにはならない。

East Agile Tracker はアジャイルにどう対応するか

East Agile Tracker は上記の原則を中心に設計されています。その対応関係は次のとおりです。

原則	トラッカーがそれをどう支えるか
継続的なデリバリー	1〜4 週間のイテレーション。ベロシティに基づく自動プランニング。一級のストーリータイプとしてのリリース。
変化を歓迎する	いつでもバックログを並べ替えられる。ストーリーはイテレーションをまたいで自由に動く。「イテレーションのロック」はない。
尺度としての動くソフトウェア	ベロシティはデフォルトで 受け入れられた ポイントを数える — 届けられ、動く作業だけが数えられる。
持続可能なペース	ベロシティは目標ではなく観測である。システムはあなたが実際にこなす量で次のイテレーションを計画する。
振り返り	イテレーション単位の分析: バーンダウン、却下率、サイクルタイム、予測。
自己組織的なチーム	役割は意図的に最小限: owner / member / viewer。チームが決める。
シンプルさ	詳細パネルは 1 画面。ボードは 1 ページに収まる。リリースから気をそらす機能には抗う。

2026 年のアジャイル — そしてエージェント

マニフェストは 2001 年に書かれました。それ以来、ソフトウェア開発は新しい種類の参加者を得ました。AI エージェントです。

私たちは、エージェントがアジャイルチームに属すると考えています — 名前を持つ参加者として、独自の役割を持ち、人間とともに本物の作業を行う者として。原則は今も成り立ちます。個人と対話 には今やエージェントの参加者が含まれます。自己組織的なチーム には今や、どのエージェントを迎え入れ、何を許すかを決めることが含まれます。振り返り には今や、アクティビティログでエージェントの貢献を見て、彼らが取り組んでいるものを調整することが含まれます。

East Agile Tracker は、これを実用的にするために作られています。すべてのストーリーは人間でもエージェントでも所有できます。すべての監査ログのエントリは実際の行為者に帰属させます。エージェントが取るすべてのアクションは、可視で、レビュー可能で、取り消し可能です。

さらに読む

• アジャイルマニフェスト — オリジナル。
• eXtreme Programming — 実践における XP についての私たちのページ。
• 操作手順 — トラッカーの使い方。

East Agile によって構築されました。