新しいサービスを開発したいが進め方がわからない。開発を始めたものの手戻りが多く非効率で困っている。そんな悩みを抱える方に向けて、この記事ではアジャイル開発の全体像を整理します。
「新しいサービスを開発したいけれど進め方がわからない。いい方法はないか」
「アジャイル開発って聞いたことはあるけれど、普通の開発と何が違うのか」
そもそもアジャイル開発とは何か、ウォーターフォール開発との違い、メリットとデメリット、そして代表的な手法であるスクラムの進め方まで、ひと通り知っておきたい点をまとめて解説します。この記事を読んで、開発を時間的にも経済的にもより効率的に進められるようになれば幸いです。
目次
アジャイル開発とは
アジャイル開発のアジャイル（agile）という単語の意味は「素早い」「機敏な」であり、その意味の通り迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称を指します。
アジャイル開発は「アジャイルソフトウェア開発宣言」として提唱され、ソフトウェア開発とそれに基づく12の原則を定義した公式文書として広く認知されています。ソフトウェアにおける変化を前提に、無駄を抑えながら価値を素早く届けることを重視する点に特徴があります。
アジャイル開発の特徴
アジャイル開発の最大の特徴は、開発期間が短いサイクルで区切られていることです。設計とプログラミングの開発工程を機能単位の小さいサイクルで繰り返し、トライアンドエラーをしながら高速で改良していきます。
また「ソフトウェア開発に変化はつきもの」という前提で進められるため、仕様の変更に対する適応力が高いことも特徴です。そうすることでプロダクトの価値を最大にすることが可能になります。
さらに優先度の高い要件から順に開発を進めていけば、サービスインまでの期間を短縮できるので、ビジネスのスタートを早く切ることができます。
ウォーターフォール開発とアジャイル開発の違い
アジャイル開発とよく比較されるものにウォーターフォール開発があります。ここでは、ウォーターフォール開発とは何かを説明し、アジャイル開発との違いを整理します。
ウォーターフォール開発は、ソフトウェア工学では古くからあるポピュラーな開発モデルで、数あるソフトウェア開発手法の中でも計画を重視する開発手法とされています。要件定義、分析、設計、実装、テストの各工程を、計画された順序に従って行います。
原則として前工程が完了しないと次工程に進まない（設計中にプログラミングを開始するなどの並行作業は行わない）ことで、前工程の成果物の品質を確保し、前工程への後戻り（手戻り）を最小限にすることが狙いです。
ウォーターフォール開発の利点は工程の進捗管理がしやすいことで、開発の計画や予算の見積もりが容易になることです。また、工程ごとの開発担当者は専任の技術者で開発を行うことが多く、基本的には工程以外の技術を必要としないため、人材育成や採用が比較的容易といえます。
アジャイル開発に向いているプロジェクト
アジャイル開発は1週間から1か月といった短期の反復期間内で、どんどん機能を追加していく「反復型開発」のプロセスによって開発が進みます。
アジャイル開発は、開発中で仕様の変更や新しい機能が追加される可能性の高いプロジェクトに向いています。たとえば、技術や構造が日々進化している産業では、システム開発の途中で仕様の変更や追加の発生が容易に予想できます。
アジャイル開発では、リリース計画段階で厳密な仕様を決定しないため、途中変更の多いプロジェクトとの相性が良いといえます。リスクマネジメントの観点からは、アジャイル開発の得意とする条件は以下の4点とされています。
- 顧客の業務に重大な支障をきたす可能性がなく、人命に関わらないシステムの場合
- アジャイル開発に精通した開発者が参加する場合
- 開発中に頻繁に要件が変わる場合
- 混沌とした状況に対しても意欲的に取り組む組織的文化がある場合
以上を踏まえると、アジャイル開発に向いているプロジェクトは次のように整理できます。
- 素早いサービスインが求められていて開発期間の短いプロジェクト
- 要求仕様に未決定の項目が多く、開発途中の変更が避けられないプロジェクト
- 市場のニーズや反応を基に改善を重ねていきたい方針のプロジェクト
アジャイル開発の手法は主に3つ
ここまではアジャイル開発に関しての概要を説明してきました。ここからは実際にアジャイル開発を実施する場合に、具体的にどのような手法があるのかを見ていきます。代表的な手法を3つ紹介します。
スクラム（コミュニケーション重視）
スクラムは、アジャイル開発のなかでも最も有名な開発手法で、開発を進めるためのフレームワークのことを指します。
その名の通りラグビーの「スクラム」のように、ワンチームががっちりと連携し合って開発を進めていきます。このスクラムで重要視されるのは、特にチーム間のコミュニケーションです。チームは自らで計画を立案して、イテレーション毎に開発の状況や進め方、開発途中の機能の品質などについて精査を行います。
スクラムの特徴・ロール・進め方は、この記事の後半で詳しく解説します。
エクストリーム・プログラミング (XP)（柔軟な仕様変更を許容）
エクストリーム・プログラミング（Extreme Programming）はXPとも略され、事前に立てた計画よりも途中変更などの柔軟性を重視する手法です。
特に、変化する顧客の要求への対応力を高めることを目的としたソフトウェア開発プロセスであり、柔軟に対応可能な手法となります。ときには顧客が開発メンバーの1人としてチームに参加することもあり、そのメンバーを「オンサイト顧客」として位置付けます。
そうして開発メンバーはオンサイト顧客との調整の中で生じた仕様変更の要望を受け入れ、少しずつ完成を目指していくことになります。エクストリーム・プログラミングは技術的な手法を用いて仕様変更に対応することを目指しており、初期の計画よりも技術面を重視しているため、プログラマー中心の開発手法であるとも言われます。
ユーザー機能駆動開発 (FDD)：ユーザーの目線を重視
ユーザー機能駆動開発とは、顧客（ユーザー）目線で価値ある機能を中心に開発を進める手法です。
開発する機能によってチームを分けて計画・設計しコーディングを行うため、アジャイル開発の中でも大規模な案件に対応しやすいのが特徴だといえます。この手法で開発を進めるためには、まずユーザーがプロジェクトに求めるものを明確にする必要があります。
「その機能に対して顧客が本当に求めるものは何か」を明確にすることで、ユーザーの要望に応じて必要な機能の選定を行い、適切な計画で開発を進めていきます。実際に動作するシステムを反復して開発を行い、ユーザーにとって適切な間隔で提供することが目的です。顧客がソフトウェアの各機能に求める根本的な要望に対応することを重視することから、品質が高い機能を開発しやすい手法と言われます。
アジャイル開発の代表的手法：スクラム
ここからは、アジャイル開発で最も広く使われる手法であるスクラムを深掘りして解説します。スクラムは、開発を進めるためのフレームワークであり、ワンチームが連携し合ってコミュニケーションを取りながら開発を進めていくことが特徴です。
チームは自らで計画を立案して、イテレーション（反復期間）毎に開発の状況や進め方、開発途中の機能の品質などについて精査を行います。逆にコミュニケーションが滞ってしまうと、スクラムは失敗します。逐次確認し合いを行い情報共有をはかることが非常に大切なスクラムでは、日々の中で定例朝会などのミーティングをはじめ、コミュニケーションの機会を増やすことが重要になります。
スクラムの特徴1：バックログが2種類ある
スクラム開発は、まずはバックログを作成するところから始まります。バックログには「プロダクトバックログ」と「スプリントバックログ」の2種類があります。
プロダクトバックログ
プロダクトバックログとは、製品の機能や要求、要望、修正などプロダクトに必要なものを抽出し、実現されたときに得られる価値やリスク、必要性などによって整理して優先順位を順番に並べ替えたリストです。
プロダクトバックログでは、順番が上位のものから開発します。そのため上位の項目ほど内容が具体的で詳細なものになります。さらに、計画の際に利用するためにそれぞれの項目（とくにリストの上位の項目）は見積もられている必要があり、その見積もり値は作業の量を相対的にあらわした値（相対難易度）がよく使われています。
プロダクトバックログは、一度作って順番に並べ替えたら完成ではありません。要求変更や新たな要求の追加に加え、開発する順番も状況に合わせて変わります。すなわちプロダクトバックログを更新していくことで、製品は常に適切で競争力をもち便利な方向へ開発を進められます。
スプリントバックログ
次にスプリントバックログとは、プロダクトバックログを管理可能な単位に細分化したものです。具体的には選択したプロダクトバックログ項目ごとに、具体的な作業を洗い出すなどして作業計画を立てます。その選択したプロダクトバックログ項目と作業の一覧を合わせて、スプリントバックログと呼びます。
つまり、スプリントバックログは開発チームの作業計画であり、スプリント期間中も自由に作業を追加したり削除したりすることができます。また、個々の作業は1日以内で終わるように分割するのが一般的です。
スクラムの特徴2：プロジェクトメンバーにロール（役割）を与える
2つ目の特徴は、開発チームのプロジェクトメンバーにロール（役割）を与え、実際に開発を進めていくことです。
そのためにはまず、プロダクトバックログの管理責任者であるプロダクトオーナーが、顧客の要望（ユーザーストーリーと言われます）をプロダクトバックログに優先順位を付けて反映させる必要があります。そして開発チームは、プロダクトオーナーが順位づけしたプロダクトバックログの項目を順番に開発していくという流れになります。
アジャイル開発のチーム人数は5人から9人が最適
開発チームは通常5人から9人までが適当とされています。
極端な少人数の場合は、お互いの相互作用が少なかったり、個人のスキルに依存する場合が多くなったりするため、開発チームとして活動した効果が出にくくなります。逆に10人以上の場合は、コミュニケーションコストが増えることによって開発の効率が落ちるため、開発チームを分割してサイズを適切にすることが一般的です。
開発チームは、要求の分析や設計への落とし込み、サーバの構築やテストなどプロダクトを作るために必要なすべての作業を、開発チームとして責任を持って主体的に進めなければいけません。開発チーム内での仕事の進め方は、メンバーの合意のもとで決められ、外部から仕事の進め方を指示されることはないためです。
スクラムの特徴3：スプリントと呼ばれるサイクルを繰り返す
実際の開発作業は、スプリントと呼ばれるサイクルを繰り返し実行して完成させていきます。スプリントは、要件定義・分析・設計・実装・テスト・リリースまでが1サイクルです。通常1スプリントあたりの期間は、1週間から4週間が設定されます。
しかし、たとえスプリントの最終日に作業が残っていても、基本的にスプリントは終了し、期間は延長しません。したがって、実際にはスプリントの期間はプロダクトの規模や開発チームの人数や成熟度、ビジネスの状況などを踏まえて決定します。開発チームはこの期間の中で、プロダクトバックログ項目を完成させるのに必要な作業すべてを行います。
なお、状況の変化によって現在のスプリントでの作業の意味がなくなった場合は、プロダクトオーナーの判断によってのみスプリント自体を途中で中止することができます。
スクラム開発のメリット
スクラム開発は、最初から厳密な計画を立てて進めていくウォーターフォールモデルとは異なり、チームでコミュニケーションを取りながら臨機応変にプロジェクトを進めていく手法です。具体的にどのようなメリットがあるのか、3つ紹介します。
メリット1：問題に早く気付けて失敗を防げる
スクラム開発には3つの柱があると言われています。それは「透明性」「検査」「適応」です。
スクラム開発では、「透明性」によりチーム全体に現状が正しく共有され、製品が頻繁に「検査」されることで異常が素早く見つかり、それに「適応」して製品・プロセスが修正されることが期待されます。これが実現できれば開発チームへ経験が蓄積し、製品はより良い方向へ向かいます。
日々チーム内で議論や確認が行われることにより、自然と問題の検知を早く行うことができ、それにともない軌道修正もスムーズに行えます。つまり問題に早く気付けて失敗を未然に防げるといったメリットがあります。
メリット2：実装工数を正確に見積もることが可能
スクラム開発では正確な作業の工数見積もりができるというメリットがあります。スクラム開発はウォーターフォールモデルと違って大まかなスケジュールで開発を進める手法ですが、工数見積もりは必須です。
スクラム開発では「1スプリントでどれだけの開発を行うか」によって見積もることになるため、そこを押さえれば正確な見積もりが可能になります。この1スプリントでどれだけの開発を行うかのことを「ベロシティ」といい、スクラム開発を見積もる上で重要な指標の一つになります。
それ以外にも、アジャイル開発の見積もりで過去の資料やドキュメントは大きな財産になります。各スプリントごとに見れば似たような作業工程が出てくるため、過去に同じような開発をしていれば、実際にかかった工数や、どのような問題が発生しどれくらいスケジュールに影響が生じたのかを参考にできます。スプリントごとにドキュメントを残しておくことが、後の見積もり精度につながります。
メリット3：自走するチームを作ることができる
スクラム開発はチームでコミュニケーションを取りながら臨機応変にプロジェクトを進めていく手法であることから、もう一つ「自走するチームを作ることができる」というメリットが生まれます。
1スプリントは長くても4週間という短いサイクルのため、PDCAをプロダクトに纏わるプロセス全体で素早く回す組織になる必要があります。ここで重要になるのが、日々行われるチーム内での密なコミュニケーションです。それによってデザイナー、開発者、QAなど専門性を持つメンバーが同じ目標に向かって一丸となって取り組む体制ができあがります。
そうなるとメンバー同士で協力して問題を解決するようになり、要求された時点より良いものを作ろうとするマインドが生まれ、メンバーの努力により徐々に「自走する組織」ができあがっていきます。
アジャイル開発におけるスクラムの進め方
ここからは実際にどのような流れでスクラム開発が行われるのかを紹介します。スクラム開発を導入する際の参考にしてください。
1. プロダクトバックログを作成
スクラム開発の流れは、まずプロダクトバックログを作成するところからスタートします。プロダクトバックログとは、プロダクトに必要なものを抽出し、優先順位を順番に並べ替えたリストです。ただしこのリストは一度作ったら完成ではなく、常に状況によって更新を続けて最新に保つことが重要です。
2. スプリントバックログを決定
スプリントバックログは開発チームの作業計画であり、スプリント期間中も自由に作業を追加したり削除したりできます。そのボリュームは、個々の作業が1日以内で終わるように分割するのが一般的です。
チームはスプリントで実現するバックログの項目を選択し、その項目を実現するためのタスク化を行います。チームが共同でタスク化する過程で、チーム内メンバーの認識差異がないことを最終確認することも重要です。
3. デイリースクラムミーティングを開催
スプリント期間中、チームは毎日スクラム会議を開きます。デイリースクラムは、決まった時間に決まった場所で行い15分以内で完了させるのがベストです。
会議の中では、チーム全員で「前回のスクラム会議以降、何をしたか」「問題はあるか」「次回のスクラム会議までに何をするか」などの質疑応答を行い、進捗確認とその対応の決定、今後の課題になりそうな懸念点なども共有します。
4. スプリントレビューの実施
スプリントの後には、必ずスプリントレビューが行われます。スプリントレビューでは、スプリントで開発されたソフトウェアのレビューが行われ、必要に応じて新たなバックログ項目が追加されます。
このレビューには、必ず顧客がマネージャや開発者と一緒に参加し、バックログにある顧客要求や品質の基準を満たしているか確認します。そのため、機能が不完全な状態でデモを行った場合は顧客の信頼を損ねる可能性があるため、注意が必要です。スプリントとスプリントレビューの繰り返しは、製品の機能や品質が十分であると顧客が判断するまで繰り返されます。
5. スプリントレトロスペクティブの実施
最後にスプリントレトロスペクティブを実施します。スプリントレトロスペクティブとは、スプリントの振り返りミーティングのことです。
スクラム開発ではスプリントは数回繰り返し行われるため、各スプリントの最終日にはスプリントレトロスペクティブが行われます。振り返りでは、スプリントゴールの達成度、スプリントで発生した問題、その問題に対する改善策などについて話し合われます。
アジャイル開発のスクラムで失敗しないポイント
実際にスクラム開発を実施していくうえで、なるべく失敗は避けたいものです。より成功率を高めるための、失敗しないポイントを3つ解説します。
ポイント1：動作するプロダクトを開発する
1つ目は、スプリントレビューを効率的に実施できるかが成功のポイントとなります。そのためには、スプリントで開発されるソフトウェア（プロダクト）が開発の要求を満たすものになっているかが大切です。つまり、スプリントレビューに値する動作をするプロダクトが準備できていなければなりません。
そのためには、開発チームはプロダクトを作るために必要なすべての作業ができる必要がありますが、スタート時に円滑に進められる状況になっていることはほとんどありません。それ自体は大した問題ではないものの、こうした状況への対処を怠ると、チームや組織のメンバーがスクラムを受け入れにくくなることにもつながるため注意が必要です。
解決策として、スクラム開発の最初の段階では、この方法論に関する一般的なレベルの経験と知識を感覚でつかんでもらうことが重要です。チーム内で何が足りないかを話し合い、ギャップの分析を開始するためのミーティングを開催することが効果的で、活発なコミュニケーションにもつながります。
ポイント2：スプリントの1サイクルを短く切る
2つ目は、スプリントのサイクルを繰り返し実行できるかです。スプリントは開発・まとめ・レビュー・調整を繰り返すもので、通常スプリントの期間は1週間から4週間が設定されます。開発チームはこの期間の中で、プロダクトバックログ項目を完成させるのに必要な作業すべてを行います。
一定の期間に短いサイクルで区切って開発を繰り返すことによって、開発に対してリズムが生まれ集中できるようになります。日頃の業務でも、同じことをルーティーン化してリズム良く進めることで作業の効率が向上する経験をお持ちの方は多いでしょう。また、短いサイクルで区切ることは、全体計画に対する現時点の進捗の把握や、リスクへの対応もしやすくなります。
ポイント3：頻繁に利用者からのフィードバックを得て調整する
アジャイル開発におけるスクラムでも、ソフトウェアを作ること自体は目的ではなく、成果を上げるための手段です。何のために作るのかを明らかにし、現在作っているものが本当に成果を実現できているのかを小まめに確認しながら進めていきます。
過程で当初作ろうと思っていたものよりも良いアイデアが出てくれば、それを受け入れ、作るものを変えていきます。つまり、利用者・顧客の反応や関係者からのフィードバックを継続的に得ながら、作っているもの自体や計画を頻繁に調整するということです。これはアジャイル開発の本質であり、大きなメリットです。最初の計画通りすべてが進むスクラムは基本的にはないということを念頭に入れておきましょう。
アジャイル開発の大まかな流れ
優先度の高い要件から決まった期間内に実装できそうな量を決めて、機能ごとに開発していくのがアジャイル開発の特徴でした。開発サイクルを繰り返して、少しずつアプリを完成形に近づけていくイメージです。
アジャイル開発にも要件定義・設計・実装・テストといった工程は存在しますが、最初にすべての要件を決めてスタートし最後にリリースするウォーターフォール開発とは大きく異なります。以下にアジャイル開発において気をつけるべきポイントにフォーカスして紹介します。
チーム環境を整える
アジャイル開発では、たくさんの文書を書くことよりも、プロジェクト関係者間で必要な時に即座に直接顔を合わせて意思疎通を行うべきであるといわれます。ほとんどのアジャイル開発チームでは、ソフトウェア開発に必要な関係者全員が、1か所の作業場所で仕事をする場合が多いです。
アジャイル開発手法では、各反復が終了するごとに機能追加された新しいソフトウェアをリリースすることを目指します。各反復が終了するごとに、プロジェクトチームは優先度を評価し見直しを行うといったことが、非常に短いサイクルで頻繁に行われるからです。
アジャイル開発では毎日朝会を行ったり、イテレーション（反復期間）ごとに振り返りの場を設ける慣習があります。もし開発チームから朝会などに誘われた場合は、依頼元だからと言って遠慮することはなく積極的に参加すべきです。受発注の関係ではなく、依頼側も含めたチームにすることがとても大切です。直接顔を合わせた意思疎通ができるチーム環境を整えることが、アジャイル開発の成功に必要な要因の1つなのです。
必要不可欠な機能のイテレーションを決める
アジャイル開発はいくら仕様変更に強いといっても、「とりあえず開発をスタートしてみて、やりながら検討しよう」という進め方はよくありません。思いつきで機能開発をスタートしてしまうと、本当はユーザーにとって必要ではない機能を開発したり、いつまでも終わらない開発をしてしまうなど、本末転倒な結果を招く非効率な開発になってしまう可能性があるからです。
ここで重要なのが、必要不可欠な機能のイテレーション（反復期間）を決めるということです。イテレーションとは「反復」という意味で、ここでは開発を小さな単位に分け「計画」→「設計」→「実装」→「テスト」を繰り返すことをいいます。イテレーションという縛りがあると、「この期間内でできる確認はなにか」「これは本当に必要なのだろうか」など、自然と必要不可欠な機能を検討することにつながり、アジャイル開発本来のメリットを生かすことができます。
機能に対してリリース計画を立てる
アジャイル開発では機能に対してリリース計画を立てることも重要です。アジャイル開発では、ソフトウェアの計画段階で厳密な仕様を決めずに大枠の仕様と要求だけを決めます。これは開発の仕様や設計の変更があることは当たり前という前提があることが、アジャイル開発の大きな特徴だからです。
きっちりと仕様が決まっていないからこそ、途中で変更があっても臨機応変に対応でき、顧客のニーズに最大限応えることができます。イテレーションは1週間〜2週間ごとが一般的で、イテレーションごとに毎回機能をリリースします。「イテレーション1」「イテレーション2」「イテレーション3」と繰り返しながら細かく開発を進めていきますが、ポイントは、どの機能を優先して開発しリリースしていくかを明確にすることです。この部分はアジャイル開発を実施するうえで重要となりますので、しっかりとチームで議論をして進めていきましょう。
アジャイル開発でよく使われる関連用語
アジャイル開発の最大の特徴は、小さな開発サイクルを何度も繰り返すこと。時には顧客も直接チームとして参加することにより仕様変更にも柔軟に対応でき、従来の開発手法よりもリリースまでの時間を短縮できるのが特徴です。プロダクトの価値を最大化することに重点を置いたこの手法をより有用に活用するために、顧客の立場としても関連用語を理解しておくことは大切です。以下に重要な関連用語を解説します。
ユーザーストーリー
ユーザーストーリーとは、アジャイル開発における要件を、顧客や利用者目線で簡潔に記述したものです。顧客や利用者の目線から見た要件を書き出しておくことで、その事業の目指すべき成果や価値を明確にすることが可能となります。
たとえば「出張で飛び回っている忙しいビジネスパーソンは公共交通機関の遅延情報をタイムリーに入手し、事前にアポイント予定のトラブルを回避する」といった形で、ユーザーストーリーを考えることができます。具体的なストーリーを作ることで軸ができ、求められる成果や要件を具体的な形で可視化できます。これを開発関係者間で共有できれば、開発プロジェクトがブレずに進行していきます。
イテレーション・スプリント
イテレーション（iteration）は「反復・繰り返し」という意味で、短期間で反復しながら効率的に開発を進めるアジャイル開発のサイクルを表したものです。アジャイル開発の手法の1つであるスクラム開発では、その開発サイクルを「スプリント（Sprint）」と呼びますが、意味は一緒です。
開発手法によって呼び方は変わりますが、いずれも開発期間の単位を表していると理解してください。イテレーションの期間は一般的に1〜2週間程度、スプリントの期間は1週間から1か月設定され、各期間終了後に機能をリリースします。期間の設定は開発チームによって変化するので注意しましょう。
ベロシティ
開発チームが1回のイテレーション内に完了できるユーザーストーリー（要求）の規模の合計値をベロシティと言います。つまり、チームの開発量を表したもので進捗状況を計る目安になります。
「期間」と「実力」を数値化して、1イテレーションでどれだけのモノを提供できるのかを算出するための準備をします。同一チームかつ同一期間で実施するようなケースでなければ、通常ベロシティの量は不確定なため、イテレーションを回しながら実数値を計測し、開発の終盤には正確な見通しが出せるように環境を整えていきます。
リリース計画
リリース計画は、どの機能がいつ実装されるのかについての期待を反映したロードマップです。ただし、アジャイル開発では「開発途中に仕様や設計の変更があることは当たり前」という前提があるので、あくまでも期待値の計画ということです。
リリース計画は、使用可能な機能や製品のさまざまなセットをいつ顧客に納入できるのか、プロジェクトを進めていく中でチームの計画と顧客の要求を随時すり合わせていくことを目的に使用するのが良いでしょう。したがって、リリース計画は各イテレーション・スプリント毎に変わるものだということも認識として必要です。
アジャイル開発のメリットとデメリット
システムやソフトウェアの開発において、プロジェクトにマッチした開発手法を選択することは重要です。ここまでアジャイル開発について紹介してきましたが、メリットとデメリットを理解した上で適切な開発手法を選択することが必要です。
メリット：ユーザーニーズの最大化と修正コストの低さ
アジャイル開発のメリットは、計画段階で綿密な仕様を決めないため、開発途中でユーザーとコミュニケーションを取りながらフィードバックを行い、確認をしながら進められることです。仕様変更や追加に臨機応変に柔軟な対応が可能で開発スピードが速いため、ユーザーのニーズに最大限応えることができ、高い満足度が得られる点がメリットでしょう。
また、不具合が発覚した際に戻る工数が少ないことも大きなメリットです。最初に決定した設計・計画を重視するウォーターフォール開発の場合には、トラブルの発生箇所によっては戻る工数が大きく、時間やコストが膨大に膨らむ可能性がありました。しかし、アジャイル開発の場合は、小さな単位で計画から設計、実装、テストを繰り返しているため、テストで問題が発生してもその該当するイテレーション内を戻る分の工数で済みます。
デメリット：スケジュール管理が難航しやすい
プロジェクト全体の納期はあるものの、アジャイル開発では仕様・要件ごとにスケジュールを設定して開発に臨むため、全体スケジュールのコントロールが困難になる傾向にあります。チームごとに小単位で開発を繰り返すため、全体の進捗を把握しきれず、気付いたら納期に間に合わないということも発生する可能性があります。
また、さらに良くしようと改善を繰り返し、テストやフィードバックで変更・追加を加えていくことで、開発の方向性がブレてしまい当初の計画からズレてしまうこともあります。このようなことを避けるには、アジャイル開発の経験があるプロジェクトマネージャーを中心に計画を立てたうえで、開発の方向性がブレないように進捗を出すことが重要です。
アジャイル開発で失敗しないためのポイント
アジャイル開発は仕様変更に対応しやすい手法ですが、失敗も多いため注意が必要です。では、どうすればプロジェクトを適切に進められるのでしょうか。まずは開発案件を成功させる体制を整えることが大切です。アジャイル開発を成功させるポイントを見ていきましょう。
ユーザーストーリー（要件定義書）などのドキュメントはしっかり残す
システム開発を行うにあたり、要件定義を事前に実施しておくことは大切ですが、アジャイル開発ではシステムは何らかの課題を解決するためのものが多く、作り始める時点では未知のものである場合が多くなります。つまり「こういうシステムがあれば、課題が解決できるはず」という仮説を検証することが要件定義になります。
アジャイル開発では、その代わりに前述した「ユーザーストーリー」という概念があります。これは顧客の意図や要求の断片であり、開発とフィードバックのサイクルを回す上での手がかりとなるもので、開発の方向性をブレないように進捗させるのに非常に重要となります。ユーザーストーリーはプロジェクトの初期に顧客、もしくはスクラムでいうプロダクトオーナーが作成しますが、最初から全部を出し切る必要はありません。無理なく思い付く範囲で主要なものを書き出し、後からいつでも追加してかまいません。
特に機能ごとに開発サイクルを繰り返すアジャイル開発では、テキストベースのドキュメント資料が不足しがちになります。また、開発をいつも同じチームに依頼するとは限りません。別のチームに引き継ぎを行う必要が発生した場合、何の資料も残っていなければ引き継ぎができず、大きな問題になります。リリース後も徐々に機能やサービスをブラッシュアップしながら運用していくことを考えると、ユーザーストーリーを軸としたモデル図など現在のシステムを表す資料は必ず残すようにしましょう。
運用開始後の方向性も共有しておく
いくらアジャイル開発が柔軟に対応できるとはいえ、機能の要件が出てくるたびに暫定対応をしているとシステム全体の設計が悪くなってしまいます。柔軟に対応することと暫定的に対応することでは、まったく意味が異なることをしっかりと理解しておくことが大切です。
そのためには事前に顧客と開発会社との間で、アプリで実現したいことや運用後の方向性についてしっかり共有しておくことです。ここで重要なのは、前項でも取り上げた「ユーザーストーリー」が共有できているかということになります。きちんと未来を想定してユーザーストーリーを共有していれば、自然と柔軟な対応ができるようになり、システム全体の設計もより効率的になるでしょう。
時間をかけてでもチームメンバーの相互理解を高める
アジャイル開発のチームの立ち上げには多少の時間を必要とします。開発をチームで行うので、その流れをチーム全体に浸透させたり、チーム内での意思疎通や相互理解を高めることが必要になるからです。
しかしこれは逆に言えば、開発を進めていくうちに相互理解がさらに進み、徐々にスケジュールが立てやすくなっていくのもアジャイル開発の特徴です。最終的には「決められた期間内にどれくらいの量を実装できるか（ベロシティ）」を高い精度で見積もることもできるようになり、より計画性が増すでしょう。もし開発が進んでしばらく経っているのにまだ計画とズレが生じるようなときは、チームのマネジメントがうまくいっていない可能性が高いので、チームメンバーの相互理解が深まっているかを含めて確認が必要です。
要点を抑えてアジャイル開発を成功させよう
ここまで、アジャイル開発の特徴や全体像、代表的な手法であるスクラムの進め方、失敗しないポイントなどを解説してきました。アジャイル開発と一口に言っても、いざ自社で実施しようとすると経験が必要な部分が多く、簡単ではないと感じられたかもしれません。
最後に説明したように、アジャイル開発で肝になるのはチームワークです。チームメンバーが一定で、お互いのことをわかっている開発チームと進められるかどうかが、スクラム開発の質を大きく左右します。新規開発やプロダクトの磨き込みを検討する段階であれば、開発会社に相談しながら進め方を固めていくのも一つの方法です。
アジャイル開発・スクラムでのプロダクト開発については、東証グロース上場の株式会社アイビスが運営するSwoooでも対応しています。Swoooは、ibisPaintを運営するアイビスの技術力と、新規事業の立ち上げに伴走してきた実務をもとに、要件定義から設計・実装、リリース後の運用まで、チームとして開発を進める体制を整えています。なお、最小限の機能で素早く検証から始めたい場合は、MVP開発とは？進め方・費用相場・外注先の選び方【2026年版】もあわせてご覧ください。
アジャイル開発・スクラムでの開発をご検討の方は、下記よりお気軽にお問い合わせください。
