こんにちは、DXCEL WAVEの運営者(@dxcelwave)です！
こんな方におすすめ！
- プロジェクトにおけるアジャイル開発の特徴・種類について詳しく知りたい！
目次
アジャイル（適応型）とは
アジャイル開発とは、システム・ソフトウェア開発におけるプロジェクト開発手法の1つです。ウォーターフォール型開発が計画を重視し段階的に進めるのに対して、アジャイル型開発は、小単位で実装とテストを繰り返して開発を進めるのが特徴的な手法を指します。
アジャイル型の開発手法の種類
アジャイル型の開発手法は時代とともに多数の手法が提唱されてきました。代表的な手法について見ていきましょう。
スパイラル（反復型開発）
1988年にベームによって提唱された手法であり、以下の特徴を持ちます。
- 反復的なサイクル
- プロジェクトは複数のサイクル（スパイラル）に分割され、各サイクルでは計画、リスク分析、設計、実装、テストが行われます。
- それぞれのスパイラルで新しい機能や改良が加えられ、システム全体の完成度が徐々に高まります。
- リスク管理
- 各反復の初期段階でリスク分析が行われ、プロジェクトにおけるリスクを特定し、それに対する対策が講じられます。これにより、重大なリスクがプロジェクトの後半で発覚するのを防ぐことができます。
- フィードバックと評価
- 各スパイラルの終わりに、作成されたプロトタイプやソフトウェアの一部が評価され、フィードバックが得られます。このフィードバックを基に次の反復に進むため、プロジェクトは顧客やステークホルダーの要望により適合した形で進行します。
- 段階的な完成
- 最初の反復ではプロジェクトの基礎となる部分が開発され、次の反復で機能が追加され、最終的に完成されたシステムが得られます。これにより、プロジェクトが早期に動作するソフトウェアを提供し、ユーザーのフィードバックを反映しやすくなります。
DSDM（ダイナミック・システム開発手法）
1995年に提唱された事業価値を達成するために、ステークホルダー・マネジメントに焦点を当てるのが特徴的な手法であり、ステークホルダーの真の要求を捉えることを注力する手法です。
- ユーザーの積極的な関与
- ユーザーやステークホルダーが開発プロセスに積極的に関与し、要件の確認やフィードバックを提供することで、最適なソリューションを実現することを目指しています。
- 変更に対する柔軟性
- プロジェクトの途中での変更を許容し、柔軟に対応するための仕組みが整えられています。
- プロジェクト管理とガバナンス
- DSDMはプロジェクト全体の管理とガバナンスに焦点を当て、プロジェクトの進行を統制し、透明性を保つことを目指します。
XP（エクストリーム・プログラミング）
2000年にケント・ベックらが提唱している手法であり、次のような特徴があります。
- 「変化を抱擁」をスローガン
- 変化の激しいプロジェクトや、顧客のニーズが頻繁に変わる状況に適しており、開発プロセス全体を通じて顧客との緊密な連携を重視した手法です。
- テスト駆動開発（TDD）
- コードを書く前にテストを作成し、そのテストに合格するコードのみを実装します。これにより、バグの早期発見と修正が可能になります。
- ペアプログラミング
- 2人の開発者が1台のコンピュータを使い、一人がコードを書き、もう一人がそのコードをレビューする形式で開発を進めます。これにより、品質向上と知識共有が促進されます。
- リファクタリング
- コードの機能を維持しつつ、内部構造を改善することで、コードの可読性や保守性を向上させます。
- 継続的インテグレーション
- 開発者は頻繁にコードをリポジトリに統合し、新しい変更が他の部分と統合されて問題がないかを継続的に確認します。
FDD（フィーチャー駆動開発）
2002年に提唱された成果物をユーザー視点でモデル化する手法であり、次のような特徴があります。
- フィーチャー単位の開発
- 開発はユーザーにとって価値のある小さな機能（フィーチャー）に基づいて行われます。
- それぞれのフィーチャーは具体的で実行可能な単位で定義されます。
- 小さなフィーチャーが完成するたびにリリースされ、ユーザーやステークホルダーからのフィードバックが得られます。これにより、開発がユーザーのニーズに沿った形で進行します。
- 反復的なアプローチ
- 約2週間単位のプロジェクトはフィーチャーの実装を反復的に行い、各反復ごとにシステムが少しずつ完成に近づきます。
- ドメインモデルの使用
- 開発の初期段階でシステム全体のドメインモデルを作成し、プロジェクト全体の設計に一貫性を持たせます。これにより、全員が同じ理解に基づいて作業を進めることができます。
- プロジェクト全体の計画
- プロジェクトの開始時に、すべてのフィーチャーをリストアップし、それぞれのフィーチャーに対して優先順位や開発計画を立てます。これにより、全体の進捗管理が容易になります。
リーン
2003年にメアリー・ポッペンディークらが提唱した、トヨタ生産方式を手本に、ソフトウェア開発を成功させるための原則を元にして考案された手法です。
- ７つの無駄の排除
- 「作りすぎ」「手持ち」「運搬」「加工」「在庫」「動作」「不良」という7つの無駄の排除に徹底的にこだわった手法です。
- 継続的改善（カイゼン）
- リーンでは、常に業務プロセスを見直し、改善することを重視します。これにより、品質を高めつつ効率を向上させることが可能です。
- プル型生産
- 在庫を必要最小限に抑えるため、需要に基づいて製品を生産するプル型のアプローチを採用します。これにより、過剰生産や在庫の無駄を削減します。
- 価値の流れの最適化
- 製品やサービスが顧客に届くまでのプロセスを「価値の流れ」として捉え、その流れを最適化します。各プロセスがどれだけ価値を生み出しているかを評価し、非効率な部分を改善します。この時に使われる代表的な手法として「バリュー・ストリーム・マッピング」があります。
- 品質の内製化
- リーンでは、各プロセスの段階で品質を確保することを目指します。問題が発生した場合、すぐに解決することで、不良品が次の工程に進むのを防ぎます。
カンバン（JUST IN TIME）
2010年にデビッド・J・アンダーソンによりトヨタの工程管理研究をもとに提唱された手法であり、次のような特徴があります。
- ジャストインタイム（JIT）
- 必要なものを、必要な時に、必要なだけ生産するという原則で、在庫を最小化し、資源の無駄を削減します。
- 現場にける進捗の可視化のためにカンバンボード（タスクボード）を活用
- カンバンでは、タスクやプロセスの進行状況を視覚的に管理します。通常、カンバンボードと呼ばれるボードにタスクをカードとして貼り付け、各カードがプロセスのどの段階にあるかを一目で確認できるようにします。タスクは「To Do」「In Progress」「Done」などの列に配置され、進捗状況が直感的にわかります。
- カンバンボードを通じて、チームは常にフィードバックを受け取り、必要に応じて作業内容や優先順位を調整します。これにより、チーム全体の効率と品質が向上します。
- プル型のワークフロー
- カンバンでは、仕事はプル（引っ張る）型で進められます。つまり、次の作業は前の作業が完了した時点で「引っ張られる」ように開始されるため、必要以上の作業が積み重なることを防ぎます。これにより、在庫や作業量を最小限に抑えつつ、効率的に進行します。
- 制限付き作業（WIP: Work In Progress）
- カンバンでは、同時に進行中の作業の数を制限することで、チームが無理なく作業を進められるようにします。WIP制限を設けることで、ボトルネックが発生することを防ぎ、作業の流れをスムーズに保ちます。
- 継続的改善（カイゼン）
- カンバンでは、プロセスの継続的な改善が重視されます。チームは定期的にカンバンボードを見直し、作業の流れに問題がないか、改善できる部分はないかを確認し、プロセスの最適化を図ります。
スクラム
2011年にケン・シュウェイバー、ジェフ・サザーランドらが提唱する手法であり、次のような特徴があります。
特徴
- スクラムにおける6つの原則
- スクラムでは「実証的（経験を積み重ねる）プロセス管理」「自己組織化」「協業」「価値による優先順位付け」「タイムボックス」「反復開発（イテレーション）」という6つの原則に従います。
- 自己組織化チーム
- スクラムチームは自己組織化されており、メンバーは自分たちで作業の割り振りや進行を管理します。チームには特定のリーダーはなく、全員が平等にプロジェクトの進行に責任を持ちます。
- 役割分担
- スクラムには「プロダクトオーナー」「スクラムマスター」「開発チーム」3つの主要な役割があります。
- スクラム開発の流れ
- 顧客とプロダクト・オーナーが「ユーザーストーリー」を描き、それらに優先順位を付与した上で積み上げ、プロダクトバックログを構成します。次に、開発チームがスプリント計画において、プロダクトバックログから優先順位の高いユーザーストーリーを複数選び出し、スプリントバックログを構成します。そして、スプリントバックログ内のユーザーストーリーを開発することを目的とし、スプリントが展開されます。スプリントの最後には、プロダクトオーナーや顧客に対して開発物のデモを行うとともにフィードバック・承認を受けるスプリントレビューを実施します。最終的にスプリント全体を通じて振り返りを行うレトロスペクティブを実施するという流れです。
【参考】スクラムで登場する用語
スクロールできます
| プロダクト・オーナー | ・プロジェクト・チームの代表 ・顧客やスポンサーとの連携、開発するプロダクトについての責任を負う ・プロジェクト開始（インセプション）を主導し、スクラム・マスターを任命し、チームメンバーを特定する ・顧客と一緒にユーザーストーリーを作成し、プロダクト・バックログの優先順位づけを実施 ・顧客の変更要求をレビューし、必要に応じて変更のためのユーザーストーリーを作成 |
|---|---|
| スクラム・マスター | ・チームリーダーとしてサーバント・リーダーシップを発揮 ・レトロスペクティブを主導 ・チーム代表としてSoS（スクラムのスクラム会議）に出席 |
| 開発チーム | ・プロダクトバックログから優先順位の高いユーザーストーリーを引き出して、スプリントバックログとする。 ・スプリントバックログ内のユーザーストーリーをタスクに分解し、作業期間見積もりを実施 ・スプリント計画をたて、作業を完了するようコミットメントする |
| フィーチャー | ・顧客要求を個々の機能として表現したもの ・技術者の専門用語ではなく、顧客の言葉として表現されるのが特徴 |
| ユーザーストーリー | ・スクラム手法の中で定義された用語 ・ユーザーストーリーは、顧客要求の個々の事項を表現したもので、特定のフィーチャーを実現するための小さな部分を示す ・「フィーチャーをユーザーストーリーに分解」して詳細化という表現で利用 |
| エピック | ・機能の概略を示し、ユーザーストーリーの上位概念の用語 ・フィーチャーに位置付けと近しい |
| タスク | ・技術的な作業項目であり、1つのユーザーストーリーを実現に際して、複数のタスクとして表現される ・所要期間の見積もりの対象として扱われる |
| 優先順位付け | ・アジャイル型では顧客価値を早く達成するような活動が求められるため、ユーザーストーリーについて顧客価値を基準とした優先順位付けが行われる 優先順位には「顧客価値」「リスク」「依存関係」「開発難易度」等がある |
| プロダクト・ バックログ | ・プロジェクトの全体的なユーザーストーリーをを優先順位順に並べたリスト ・プロダクトオーナーが管理し、スプリントプランニングで次に取り組む項目が選ばれる |
| スプリント・ バックログ | ・スプリント期間中にチームが取り組む具体的なユーザーストーリーのリスト |
| インセプションデッキ | ・アジャイルの立ち上げ時の活動をインセプションと呼ぶ ・プロダクトづくりに関わるメンバーが各々の意見を持ち寄って共通認識をつくり出すための大事な質問、もしくは対話の場をインセプションデッキと呼ぶ |
| DONE（ダン） | ・アジャイル型で使われる完了基準の１つ ・個々のユーザーストーリを検査する「機能検査」と全ユーザーストーリーに共通の「検査項目」がある。後者の共通検査をDoneと呼ぶ。 ・Doneに合格することでイテレーション最後に、プロダクトオーナーをはじめとする顧客にデモを行うことができる。 |
| レトロスペクティブ | ・次のスプリントでの作業や改善にどう取り組むのかを話し合う活動を指す。 ・KPT（Keep, Problem, Try）と言われるキーワードをもとにして、(K)良かったところを継続し、(P)問題があれば止めたり改善したりし、(T)新しいことにチャレンジすることを決めたりする。 |
最後に
お問い合わせフォーム
上記課題に向けてご気軽にご相談下さい。
お問い合わせはこちら
