こんにちは。クライアント企業のデジタル・トランスフォーメーション（DX）を全方位で支援するスパイスファクトリー株式会社です。
変化の速い現代のビジネス環境において、多くの企業で採用されているアジャイル開発ですが、一口にアジャイル開発といってもその手法は様々です。
それぞれの手法にはどのような違いがあり、どのように手法を選択するべきなのでしょうか。
本記事では、多数のアジャイル開発プロジェクトを手掛けてきた当社の経験やノウハウ、事例なども含めて、アジャイル開発の手法やフレームワークについて詳しくご紹介します。
Contents
アジャイル開発とは？
はじめに、アジャイル開発について簡単に説明します。
アジャイル開発とは、短いスパンで開発を繰り返し、機敏にシステムを構築する手法です。
ウォーターフォール型がプロジェクトの終盤で動作確認を行うのに対し、アジャイルでは逐次開発とテストを行うため、開発中に実際のソフトウェアを確認しながら方向性を検討できます。
現代のビジネス環境では、外部環境やユーザーニーズの急速な変化があり、柔軟な対応が求められます。
実際に動作するソフトウェアをリリースしてユーザーの反応を見ながら改善していくことも重要です。アジャイル開発は、このようなニーズに応えるための適した方法論といえるでしょう。
さらに詳しく知りたい方は、日本や世界でのアジャイル開発事例を取り上げた以下の記事をご覧ください。具体的なイメージがつかめるはずです。
アジャイル開発のメリット
アジャイル開発のメリットについて解説します。
柔軟性が高い
短いスパンで開発を繰り返し、小さな機能を積み上げてソフトウェアを作り上げていくアジャイル開発は、開発内容を変更しやすいというメリットがあります。
たとえば、競合他社のサービスに新たな機能が追加され、その機能がユーザーのニーズをうまく捉えているようであれば、ぜひ自社のサービスにもその機能を取り込みたいと考えるはずです。
ウォーターフォール型開発で同じようなことをすると、変更管理プロセスに則り一定の時間をかけ、要件やスケジュールを見直すこととなり、オーバーヘッドが大きくなります。
このように、外部環境の変化に対応しやすいのがアジャイル開発の特徴です。
チーム一体となって開発を進められる
ウォーターフォール型開発では、請負契約によって発注側と開発側が明確に分けられ、発注側は開発側のプロジェクトマネージャーのみを通してコミュニケーションすることとなります。
一方で、アジャイル開発では発注側と開発側は一つのチームとしてプロジェクトを運営していきます。
発注者側の要望を深く理解したエンジニアが専門的な知見で開発する機能について検討したり、エンジニアの意見を踏まえて発注者側が意思決定をしたりといったことが行いやすくなります。
このようにチーム一体となって開発を進めることで、ソフトウェアの品質を高めやすくなる点もアジャイル開発のメリットといえるでしょう。
早期にユーザーの反応を見て開発を進められる
実際に動作するソフトウェアを早期に作り、ユーザーに利用してもらうことで、ユーザーのニーズを確認することができます。これはアジャイル開発の大きなメリットです。
新規事業開発においては、事前に市場調査やユーザー調査などを行い一定の仮説をもってプロダクトを開発しますが、そのプロダクトが本当に市場やユーザーにマッチしているのかは、実際の市場やユーザーの反応を見てみないとわかりません。
このようないわゆる「PMF（プロダクト・マーケット・フィット）」を判断するためにも、アジャイル開発で必要最小限の機能を構築したうえで、本番リリースを目指すアプローチが有効です。
アジャイル開発のデメリット
「丸投げ」はできない
ウォーターフォール型開発では発注者は要件さえ決めれば、あとはベンダーにお任せして開発を進めてもらうこともできます。
一方で、アジャイル開発ではこのような「丸投げ」はできません。発注者側にも、一定の負荷がかかる手法です。
しかしながら、本来システム開発は発注者側が主体的にコントロールし、自身が求めるソフトウェアを作り上げていくものです。発注者側が積極的にプロジェクトに参画していくことで、品質の高いソフトウェアを作り上げることができます。
必ずしも開発スピードは速くならない
アジャイル開発はアジリティ（機敏さ）に優れた手法ですが、開発スピードは必ずしも速くならないこともあります。
先述の通り、アジャイル開発は柔軟性に長けていますが、たとえば事前に明確に要件が定まっていて変更の可能性が無い場合、要件定義から設計、開発、テストと流れるように開発を進めていくウォーターフォール型開発の方が素早く開発を行えることもあります。
一概にアジャイル開発だから高速に開発できるわけではないという点は理解しておくべきです。
開発の方針がブレるリスクがある
柔軟性が高いというアジャイル開発のメリットは、方向性が定まりにくいというデメリットに化けてしまうこともあります。
一度開発した機能を何度も変更してしまえば、当然コストも開発期間も必要となります。アジャイル開発だからと言って事前に要件を決めなくてよい、というのは危険です。
少なくともプロジェクトの開始時点では、事前に開発すべきものを定めたうえでプロジェクトに取り組み、ユーザーの反応や環境の変化に応じてそれを見直していくというスタンスが重要です。
このように、アジャイル開発はメリットの多い手法ですが、もちろんデメリットもあります。目的や開発するソフトウェアの特性に応じて使い分けが必要です。
以下の記事では、アジャイル開発とウォーターフォール型開発の比較を行っております。アジャイル開発手法を採用すべきか悩んでいる方は、以下の記事も併せてご覧ください。
以下の記事で、アジャイル開発のメリットとデメリットについて詳しく解説しています。
アジャイル開発の代表的な手法・フレームワークを紹介
以下では、アジャイル開発として分類される様々な手法・フレームワークについてご紹介します。
- スクラム
- カンバン
- ラピッドプロトタイピング
- リーン
- エクストリーム・プログラミング
- クリスタル
- 動的システム開発手法 (DSDM)
- 機能駆動開発手法 (FDD)
- 適応型ソフトウェア開発（ASD）
スクラム
スクラムは、アジャイル開発で最も広く採用されているフレームワークの一つです。
開発プロセスを「スプリント」と呼ばれる短期間（通常1〜4週間）のサイクルに分け、計画・開発・レビュー・振り返りを繰り返します。
- 計画（スプリントプランニング）：チームで「今回のスプリントで何を作るか」を決定
- 開発（スプリント実行）：計画に沿って開発を進めます。日々の短い打ち合わせ（デイリースクラム）も実施
- レビュー（スプリントレビュー）：完成した機能を関係者に見せて、フィードバックを受け取る
- 振り返り（レトロスペクティブ）：スプリント全体を振り返り、良かった点・改善点を話し合う
スクラムという言葉は、ラグビーのスクラムに由来しています。ラグビーのスクラムでは、チームメンバーが肩を組んでワンチームとして力を発揮しますが、アジャイル開発のスクラムでも同様にチームが一丸となって開発を行います。
スクラムには以下の3つの役割が存在します。各メンバーが自身の役割を通して、チームを作り上げていきます。
- プロダクトオーナー：開発するプロダクトに責任を持ち、プロダクトの方向性を決める責任者。スクラムチームから⽣み出されるプロダクトの価値を最⼤化する役割を担う。
- スクラムマスター：スクラムの手法に精通し、スクラムを確立させる責任者。スクラムの理論と実践を全員に理解してもらえるよう、手助けを行う。
- 開発チーム：プロダクトの開発を担当するメンバー。プロダクトオーナーが示した要求に対して、実際にコーディングを行いプロダクトを作り上げる。
スクラムはアジャイル開発の中でも採用されるケースが多い代表的な手法といえます。スクラムについては以下の記事で詳しく解説しております。ぜひ、併せてこちらの記事もご覧ください。
カンバン
「カンバン」もアジャイル開発手法の一つとして知られています。
カンバンと聞くと、トヨタ自動車の生産管理方式を思い浮かべる方も多いかもしれません。
生産管理方式におけるカンバンとは、必要なものを必要な時に必要なだけ供給する「ジャストインタイム」を実現する、優れた生産方式です。
この生産方式が「カンバン」と呼ばれる理由は、ジャストインタイムを実現するために看板が用いられるためです。
必要最小限の在庫量を確保するために、部品に看板をつけ、部品の数量を管理します。
アジャイル開発方式においては、このカンバンをタスク管理の手段として利用します。プロジェクトの進捗状況を視覚的に把握するために、カンバンボードにやるべきタスク、進行中のタスク、完了したタスクを一覧化します。これにより、チーム全体の作業状況を素早く把握できます。
アジャイル開発においてチームが一体となってプロジェクトを進めるためには、情報共有がポイントとなります。
カンバンの活用により、タスクの進捗状況を誰でも簡単に把握できるようになります。
ラピッドプロトタイピング
ラピッドプロトタイピングは、製品やサービスの完成前に、「たたき台」となる試作品（プロトタイプ）を素早く作って、ユーザーや関係者の意見をもとに改善していく開発手法です。
ラピッドプロトタイピングの流れは、以下のようになります
- 要件の整理：ユーザーが求めるもの・必要な機能を整理
- プロトタイプを作成：画面モック、簡易アプリ、紙に書いたUIなど、最小限の形で問題なし
- フィードバックを受け取る：実際に触ってもらい、「わかりづらい」「こうしてほしい」といった意見を収集
- 改善する（繰り返し）：フィードバックを元に、プロトタイプを更新して再び確認
特に、ユーザーインターフェースやユーザーエクスペリエンスの設計において有効です。ただし、プロトタイプ作成に時間をかけすぎると、開発全体のスケジュールに影響を与える可能性があります。
そのため、「完璧を目指すのではなく、素早く検証する」ことが大切です。
リーン
リーンは、無駄を排除し、価値のある作業に集中することを目的としたフレームワークであり、7つの原則があります。
- ムダをなくす：必要のない作業はやめて、本当に大切なことだけに集中する
- 知識を作り出す：作りながら学び、失敗も経験に変えて成長する
- 決定を遅らせる：決断はギリギリまで待ち、必要なときに最適な判断をする
- 早く提供する：できるだけ早く成果物を届けて、反応をもらいながら改善する
- 権限を移譲する：チームに任せて、自分たちで考えて動ける環境をつくる
- 全体を最適化する：一部だけでなく、チーム全体や開発全体の流れを良くする
- 品質を作り込む：はじめから「正確に作る」ことを意識して、不具合を早く見つけて直す
リーンは、スタートアップや新規事業開発において、最小限の製品を市場に投入し、実際のユーザーからのフィードバックを得ることで、製品やサービスの改善を図る際に有効です。
ただし、過度な効率化を追求すると、必要なプロセスまで削減してしまうリスクがあるため、注意しましょう。
エクストリームプログラミング
アジャイル開発手法の一つであるエクストリームプログラミングは、変化するニーズに柔軟に対応しつつ、ソフトウェアの品質を高めるアジャイル開発におけるベストプラクティスです。
エクストリームプログラミングもスクラムと同様に、数あるアジャイル開発手法の中でも代表的なものであり、広く普及しています。
エクストリームプログラミングでは「コミュニケーション」「シンプル」「フィードバック」「勇気」「尊重」という5つの価値を重要視しつつ、開発を進めます。また、19のプラクティスとして、開発の進め方が指南されています。
| カテゴリ | プラクティス |
|---|---|
| 共同のプラクティス |
・反復 ・共通の用語 ・オープンな作業空間 ・回顧 |
| 開発のプラクティス |
・テスト駆動開発 ・ペアプロトタイピング ・リファクタリング ・ソースコードの共同所有 ・継続的インテグレーション ・YGNI |
| 管理者のプラクティス |
・責任の受け入れ ・援護 ・四半期ごとの見直し ・ミラー ・持続可能なペースでの仕事 |
| 顧客のプラクティス |
・ストーリーの作成 ・リリース計画 ・受け入れテスト ・短期リリース |
特徴的なプラクティスとしては、実装の前にまずテストを作成し、実装にあたってはテストを通すことを目標とする「テスト駆動開発」や、機能を追加したらすぐに既存のコードとマージして結合テストを行い、検証する「継続的インテグレーション」といったものが挙げられます。
プロジェクト管理・運営手法の色が強いスクラムと比較して、より開発現場に近いプラクティスが提唱されているのがエクストリームプログラミングの特徴といえるでしょう。
クリスタル
クリスタルは、「人との相互作用」を最重視するアジャイル手法で、プロジェクトの規模や重要度に応じて柔軟に適用できるフレームワークです。
最大の特徴は、「人との相互作用」を最重視する点にあり、プロセスやツールよりも、チームのコミュニケーションやスキルに焦点を当てています。
「クリスタル・クリア」「クリスタル・イエロー」など、プロジェクトの特性に応じた複数のバリエーションが存在します。
例えば「クリスタル・クリア」は小規模なチーム向け、「クリスタル・オレンジ」は中規模なチーム向けといったように、チームの規模やプロジェクトの重要度に応じて適切な手法を選択できるのが魅力です。
また、クリスタルは、頻繁なデリバリー、反復的な開発、ユーザーとの密な連携を重視し、チームの自己組織化や柔軟性を促進できます。 このような特性から、クリスタルは、小規模から中規模のプロジェクトや、チームの自律性や柔軟性を重視する企業に適しています。
動的システム開発手法（DSDM）
動的システム開発手法は、1990年代にRapid Application Development（RAD）を補完する形で登場したアジャイル手法で、プロジェクト全体のライフサイクルをカバーするフレームワークです。以下8つの原則にもとづいて進行します。
- ビジネスニーズに価値を置く：ただ「作る」ことが目的ではなく、「ビジネスの目標を達成するためのシステムか？」を常に意識して進める
- 時間を厳守する：スケジュールを守ることが基本。機能の優先順位をつけて、重要なものから順に完成させることで、締め切りに対応
- コラボレーションを重視する：開発者・ユーザー・ビジネス担当者など、関係者全員で協力することが成功する要因
- 品質を絶対に外さない：品質は後で考えるのではなく、常に一定の基準を守ることが前提
- 漸進的に開発する：小さな単位で少しずつ開発を進め、段階的に完成させていく
- 反復的に開発する：「一度で完璧に作る」ではなく、試作→確認→改善を繰り返して、精度を高める
- 可視化して伝える：ドキュメントだけに頼らず、口頭やビジュアル（図・プロトタイプ）でわかりやすく共有することを重視
- コントロールを維持する：プロジェクト全体の進捗やリスクを常に把握し、計画どおり進んでいるかを可視化しておくことが重要
この手法の特徴は、固定された時間、コスト、品質の枠組みの中で、要件の優先順位を調整することで、プロジェクトの成功を目指す点です。
また、ユーザーの積極的な関与や、継続的なフィードバックの取得を重視し、プロトタイピングや反復的な開発を通じて、ビジネス価値の高いソリューションを提供します。
明確なスコープと期限があるプロジェクトや、ビジネスニーズに迅速に対応する必要がある場合に適しており、特に大規模な組織や複雑なプロジェクトでの適用が効果的です。
ユーザー機能駆動開発（FDD）
機能駆動開発手法（FDD）は、1997年にJeff De Luca氏とPeter Coad氏によって提唱されたアジャイル開発手法で、ソフトウェア開発を「機能」単位で進めることを特徴としています。
ちなみに、ここでの「機能」とは、ユーザーにとって価値のある小さな機能単位を指し、例えば「ログイン処理を完了する」といった具体的な作業項目を意味します。
FDDは、以下の5つのステップから構成されます。
- 全体モデルの開発：ドメイン専門家と開発者が協力して、システム全体の理解を深めるためのモデルを作成
- 機能リストの作成：全体モデルをもとに、ユーザーにとって価値のある機能を洗い出し、リスト化
- 機能ごとの計画立案：各機能の開発順序や担当者を決定し、スケジュールを策定
- 機能ごとの設計：選定された機能について、詳細な設計を実施
- 機能ごとの構築：設計にもとづき、実際のコーディングとテストを行い、機能を完成
FDDは明確な手順と役割分担を持ち、大規模なプロジェクトや複数の開発チームが関与する場合に適しています。
各機能が小さな単位であるため、進捗管理がしやすく、品質の維持にも効果的です。
ただし、初期段階での全体モデルの作成や機能リストの整備に時間がかかるため、要件が頻繁に変化するプロジェクトには向かない場合があります。
適応型ソフトウェア開発（ASD）
適応型ソフトウェア開発は、変化の激しい環境下でのソフトウェア開発において、柔軟性と適応性を重視することを目的とした開発手法です。
ASDは、以下の3つのフェーズから構成されます。
- 推測：詳細な計画を立てるのではなく、仮説を立てて開発を進めることで、変化に柔軟に対応
- 協働：チームメンバーやステークホルダーとの密なコミュニケーションを通じて、共通の理解を築く
- 学習：開発プロセス全体を通じて継続的に学習し、得られた知見を次のサイクルに活用
ASDは、従来の計画主導型の開発手法とは異なり、変化を前提としたアプローチを取ります。
そのため、要件が不確定で頻繁に変更されるプロジェクトや、革新的な製品開発において効果を発揮するのが特徴です。
最適なアジャイル開発の種類を選ぶためのポイント
それでは、最適なアジャイル開発手法を選ぶためにはどのような観点を意識すればよいのでしょうか。以下では、いくつかのポイントをご紹介します。
フレームワークの種類と特徴を理解する
先述した通り、アジャイルフレームワークには、さまざまな種類が存在します。
各フレームワークは、プロジェクトの進行方法やチームの役割分担など、独自の特徴を持っているため、種類や特徴を理解して選ぶ必要があります。
例えば、スクラムは短期間のスプリントを繰り返すことで進捗を管理し、カンバンは作業の可視化とフローの最適化を重視するのが特徴です。
フレームワークごとの考え方や特徴を理解しておくことで、自社のプロジェクトに合った最適な選択ができるようになります。
また、導入前にそれぞれのメリットや注意点を把握しておくことで、運用後に起こりがちなギャップや課題にも事前に備えられ、スムーズに活用ができます。
自社のプロジェクトやチームの特性を分析する
適切なアジャイルフレームワークを選ぶためには、自社のプロジェクトやチームの特性を分析しましょう。
プロジェクトの規模、期間、複雑性、変更頻度、ステークホルダーの関与度などを評価し、どのフレームワークが最も適しているかを判断します。
例えば、要件が頻繁に変化するプロジェクトには、柔軟性の高いスクラムやカンバンが適しているでしょう。
自己組織化されたチームであれば、エクストリーム・プログラミングやクリスタルのような自律性を重視するフレームワークがおすすめです。
このように、自社の具体的な状況を踏まえてフレームワークを選定することで、導入後の効果を最大化し、プロジェクトの成功率を高めることができます。
フレームワークの試験運用と適応の重要性
選定したアジャイルフレームワークを導入する際には、いきなり全社的に展開するのではなく、まずは小規模のプロジェクトやチームで試験運用を行うことがおすすめです。
試験運用を通じて、フレームワークの運用方法やチームの反応、課題点などを把握し、必要に応じて調整やカスタマイズを行います。
試験運用を実施することで、フレームワークが自社の文化や業務プロセスに適合するかを評価し、導入リスクを最小限に抑えることができます。
また、試験運用の結果をもとに、成功事例やベストプラクティスを蓄積し、他のプロジェクトやチームへの展開時に活用することが可能です。
段階的な導入と継続的な改善を行うことで、アジャイルフレームワークの効果を最大限に引き出し、組織全体のアジャイル成熟度を高めることができます。
前提として、複数の手法を組み合わせてもよい
スクラムやエクストリームプログラミング、カンバンなどいくつかのアジャイル開発手法をご紹介しましたが、これらはどれか一つを選ぶべきものではありません。
複数の手法のプラクティスを組み合わせて開発を行うこともできます。
たとえば、プロジェクト体制や運営方法はスクラムに沿って実施しつつ、ソフトウェアの品質を高めるためにエクストリームプログラミングのプラクティスであるペアプログラミングやテスト駆動開発などを用いることもできます。
また、タスク管理においてはカンバンを利用することもできるでしょう。
このように、各アジャイル開発手法の良いところを組み合わせることができます。
プロジェクトメンバーの規模を考慮する
スクラムのガイドラインともいえる「スクラムガイド」によれば、以下のとおりチームは10名以下とすることが推奨されています。
スクラムチームは、敏捷性を維持するための⼗分な⼩ささと、スプリント内で重要な作業を完了するための⼗分な⼤きさがあり、通常は10⼈以下である。
⼀般的に⼩さなチームのほうがコミュニケーションがうまく、⽣産性が⾼いことがわかっている。
※引用：スクラムガイド P6より
このように、スクラムは比較的小規模のプロジェクトにおいて採用すべき手法です。より規模が大きいプロジェクトにアジャイル開発を適用したい場合、ユーザー機能駆動開発や動的システム開発手法の活用を検討します。
変更頻度によって手法を選択する
スクラムとエクストリームプログラミングのプロジェクトの推進方法は近しいですが、両者には若干の違いがあります。
たとえば、より柔軟に開発内容を変更できるのはエクストリームプログラミングです。
エクストリームプログラミングでは、開発するソフトウェアの機能を決定する「顧客（スクラムのプロダクトオーナーに該当）」により、作業にまだ着手していないことを前提に、随時要件の変更を行うことができます。
一方で、スクラム開発においてはスプリント期間中に開発内容を変更することはできません。
求める変更頻度によって開発手法を選択することも一案となります。
アジャイル開発の成功事例を紹介
最後に、当社が実際に携わったアジャイル開発の具体的な事例をご紹介します。
東京都デジタルサービス局 | アジャイル型方式によるプロトタイプ開発委託
東京都は、デジタルの力を活用した行政を総合的に推進し、都政の QOS を飛躍的に向上させるため、2021年にデジタルサービス局を設置。同局では、国際競争力の強化や都民の生活の質・利便性向上を進めるため、迅速かつ柔軟に新しい価値を創出するためのアジャイル型開発を推進しています。
当社は、同局が企画する4件のアジャイル型方式によるプロトタイプ開発プロジェクトを受託しました。
株式会社トムス・エンタテインメント | アニメーションの制作管理システム「ProGrace」の開発
「ルパン三世」シリーズや「それいけ！アンパンマン」シリーズ、「名探偵コナン」シリーズなど、数多くの著名アニメ作品を手掛ける株式会社トムス・エンタテインメント。
同社では、日本のアニメーション制作業界を取り巻く制作面、ビジネス面、人材育成などの様々な課題を念頭に「アニメSDGs -2030年までに持続可能な日本アニメ産業の未来を創る-」という構想を掲げられています。
当社では、アニメーション業界のDXの先駆けとなる「ProGrace（プログレース）」の開発を継続的にご支援させていただいております。
以下の記事では、本システムの開発をご担当されている河瀬様にインタビューを行い、開発プロジェクトの背景や今後の展望について詳しく記載しています。
株式会社ネクスウェイ | 薬局向けDI (薬剤情報) ポータルサービス「アスヤク薬局ポータル」の開発
株式会社ネクスウェイ様の薬局向け DI (薬剤情報) ポータルサービスである「アスヤク薬局ポータル」の新規開発を担当いたしました。 アスヤク薬局ポータルは DI (薬剤情報) をまとめて閲覧・管理を行うことができるポータルサービスです。
これまでメールや郵送、FAX、Webなどでバラバラに公開がされていたDIを一本化して掲載しています。また、製薬会社がこのサービスを通してDIの配信を行うこともできます。
アジャイル開発を成功させるために
この記事では、主なアジャイル開発手法の種類についてご紹介しました。
アジャイル開発と一口に言ってもそのアプローチは様々です。各手法がどの様な場面で有効となるか、各手法にはどのような良し悪しがあるかを踏まえ、プロジェクトを運営し開発を進めていく必要があります。
よって、アジャイル開発型でソフトウェア開発を行う際には、アジャイル開発のスキルや経験を保有したパートナーを選ぶことが重要です。
これまで多くのアジャイル開発プロジェクトを実施してきた当社では、プロジェクトの特性や目標に合わせ、様々なアプローチでお客さまのソフトウェア開発を支援いたします。
アジャイル型でのソフトウェア開発にご興味のある方は、ぜひお気軽にお問い合わせください。
Tags
About The Author
スパイスファクトリー公式
スパイスファクトリーは世界がより良い⽅向に向かうよう、変化を加速させる “触媒”（スパイス）としての役割を全うすることをミッションとしたDXエージェンシーです。最新テクノロジー、UIUX、アート、マーケティングなどの技術・メソッドを⽤いて、モノゴトを素早く、美しく、本質的に再定義し、幅広いクライアントのデジタルトランスフォーメーションを⽀援しています。