【基礎知識】アジャイル開発とは？特徴や全体像、失敗しないポイントも解説
新しいサービスを開発をしたいが進め方がわからない。開発を始めたが手戻りが多く非効率で困っている方は、こんな事で悩まれているのではないでしょうか？
「新しいサービスを開発したいけど進め方がわからない。いい方法はないかな？ 」
「アジャイル開発って聞いたことがあるけど良くわからない。アジャイル開発は普通の開発と何が違うの？ 」
その他にもそもそもアジャイル開発とは、アジャイル開発と普通の開発の違い、アジャイル開発のメリットやデメリット、といった点も知っておきたいですよね。
今回は、これさえ読めばアジャイル開発に関する全てがわかるようにを紹介します。
この記事を読んで、自分の開発が、時間的にも経済的にもより効率的にすすめられるようになれば幸いです。
では、それぞれ見ていきましょう！
目次
アジャイル開発とは
アジャイル開発のアジャイル（agile）という単語の意味は「素早い」「機敏な」であり、その意味の通り迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称をいいます。
アジャイル開発は2001年にアメリカ合衆国でアジャイルソフトウェア開発手法の分野において名声のある17人によって「アジャイルソフトウェア開発宣言」として提唱され、現在もソフトウェア開発とそれに基づく12の原則を定義したアジャイル開発の公式文書として広く認知されています。
アジャイル開発の特徴
アジャイル開発の最大の特徴としては、とにかく開発期間がスピーディーということです。
具体的にいうと、設計とプログラミングの開発工程を機能単位の小さいサイクルで繰り返し、トライアンドエラーをしながら高速で改良していくところであるといえます。
また「ソフトウェア開発に変化はつきもの」という前提で進められるので、仕様の変更に対する適応力が高いことも特徴です。
そうすることによりプロダクトの価値を最大にすることが可能になります。
さらに優先度の高い要件から順に開発を進めていけば、サービスインまでの期間を短縮することができるので、ビジネスのスタートを早くきることができます。
ウォーターフォール開発とアジャイル開発の違い
アジャイル開発とよく比較されるものにウォーターフォール開発があります。ここでは、ウォーターフォール開発とは何かを説明し、アジャイル開発との違いを理解しましょう。
ウォーターフォール開発は、ソフトウェア工学では非常に古くからある非常にポピュラーな開発モデルで、数あるソフトウェア開発手法の中でも、最も計画重視の開発手法とされています。
ウォーターフォール開発では、要件定義、分析、設計、実装、テストの各工程を、計画された順序に厳格に従って行います。
原則として前工程が完了しないと次工程に進まない（設計中にプログラミングを開始するなどの並行作業は行わない）事で、前工程の成果物の品質を確保し、前工程への後戻り（手戻り）を最小限にすることが狙いです。
ウォーターフォール開発の利点は工程の進捗管理がしやすいことで、開発の計画や予算の見積りが容易になることです。
また、工程ごとの開発担当者は専任の技術者で開発を行うことが多く、ウォーターフォール開発は基本的には工程以外の技術を必要としないため、人材育成や採用が比較的容易といえます。
アジャイル開発に向いているプロジェクト
アジャイル開発は1週間から1か月といった短期の反復期間内で、どんどん機能を追加していく「反復型開発」の開発プロセスによって開発は進んでいきます。
アジャイル開発は、ソフトウェアやアプリ開発といった、開発中で仕様の変更や新しい機能が追加される可能性の高いプロジェクトに向いています。
例えば、モバイル分野などの日進月歩で技術や構造が進化している産業では、システム開発の途中で仕様の変更や追加の発生が容易に予想できます。
アジャイル開発では、リリース計画段階で厳密な仕様を決定しないため、途中変更の多いプロジェクトとの相性が良いといえます。
またリスクマネジメントの観点からは、アジャイル開発の得意とする条件は以下の4点とされています。
- 顧客の業務に重大な支障をきたす可能性がなく、人命に関わらないシステム)の場合
- アジャイル開発に精通した開発者が参加する場合
- 開発中に頻繁に要件が変わる場合
- 混沌とした状況に対しても意欲的に取り組む組織的文化
以上「アジャイル開発に向いているプロジェクト」をまとめると以下になります。
- 素早いサービスインが求められていて開発期間の短いプロジェクト
- 要求仕様に未決定の項目が多く、開発途中の変更が避けられないプロジェクト
- 市場のニーズや反応を基に改善を重ねていきたい方針のプロジェクト
アジャイル開発の手法は主に３つ
これまではアジャイル開発に関しての概要を説明してきました。 ここからは実際にアジャイル開発を実施する場合に、具体的にどのような手法があるのかを見ていきたいと思います。 以下にその中でも代表的な手法を3つ紹介します。
スクラム（コミュニケーション重視）
スクラムは、アジャイル開発のなかでも最も有名な開発手法で、開発を進めるためのフレームワークのことを指します。
その名の通りラグビーの「スクラム」のように、ワンチームががっちりと連携し合って開発を進めていきます。
このスクラムで重要視されるのは、特にチーム間のコミュニケーションです。チームは自らで計画を立案して、イテレーション毎に開発の状況や進め方、開発途中の機能の品質などについて精査を行います。
逆にコミュニケーションが滞ってしまうと、スクラムは失敗します。
リリースした機能が正常に動作しない、要求された通りの機能になっていないなどの問題が生じる可能性が高くなります。
このように逐次確認し合いを行い情報共有をはかることが非常に大切なスクラムでは、日々の中で定例朝会などのミーティングをはじめ、コミュニケーションの機会を増やすことが非常に重要になるのです。
エクストリーム・プログラミング (XD)（柔軟な仕様変更を許容）
エクストリーム・プログラミング（Extreme Programming）はXPとも略され、事前に立てた計画よりも途中変更などの柔軟性を重視する手法です。
特に変化する顧客の要求への対応力を高めることを目的としたソフトウェア開発プロセスであり最も柔軟に対応可能な手法となります。
ときには顧客が開発メンバーの1人としてチームに参加することもあり、そのメンバーを「オンサイト顧客」として位置付けます。
そうして開発メンバーはオンサイト顧客との調整の中で生じた仕様変更の要望を受け入れ、少しずつ完成を目指していくことになります。
エクストリーム・プログラミングは、技術的な手法を駆使して仕様変更に対応することを目指しており初期の計画よりも技術面を重視しているため、プログラマー中心の開発手法であるとも言われます。
ユーザー機能駆動開発 (FDD)：ユーザーの目線を重視
ユーザー機能駆動開発とは、顧客（ユーザー）目線で価値ある機能を中心に開発を進める手法です。
開発する機能によってチームを分けて計画・設計しコーディングを行うため、アジャイル開発の中でも大規模な案件に対応しやすいのが特徴だといえます。
この手法で開発を進めるためには、まずユーザーがプロジェクトに求めるものを明確にする必要があります。
「その機能に対して顧客が本当に求めるものは何か」を明確にすることで、ユーザーの要望に応じて必要な機能の選定を行い、適切な計画で開発を進めていきます。
実際に動作するシステムを反復して開発を行い、ユーザーにとって適切な間隔で提供することが目的です。
そのため、この手法でも開発の計画段階からユーザーとのコミュニケーションが重要となります。
顧客がソフトウェアの各機能に求める根本的な要望に対応することを重視することから、品質が高い機能を開発しやすい手法と言われます。
アジャイル開発の大まかな流れ
まずは優先度の高い要件から決まった期間内に実装できそうな量を決めて機能ごとに開発していくのがアジャイル開発の特徴でしたね。
開発サイクルを繰り返して、少しずつアプリを完成形に近づけていくイメージです。
アジャイル開発にも要件定義・設計・実装・テストといった工程は存在しますが、最初にすべての要件を決めてスタートし最後にリリースするウォーターフォール開発とは大きく異なります。
以下にアジャイル開発において気をつけるべきポイントにフォーカスして紹介します。
チーム環境を整える
アジャイル開発では、たくさんの文書を書くことよりも、プロジェクト関係者間で必要な時に即座に直接顔を合わせて意思疎通を行うべきであるといわれます。
ほとんどのアジャイル開発チームでは、ソフトウェア開発に必要な関係者全員が、1か所の作業場所で仕事をする場合が多いです。
なぜならアジャイル開発手法では、各反復が終了するごとに、機能追加された新しいソフトウェアをリリースすることを目指します。
各反復が終了するごとに、プロジェクトチームは、プロジェクトにおける優先度を評価し見直しを行うといったことが非常に短いサイクルで頻繁に行われるからです。
アジャイル開発では毎日朝会を行ったり、イテレーション（反復期間）ごとに振り返りの場を設ける慣習があります。
もし開発チームから朝会などに誘われた場合は、依頼元だからと言って遠慮をすることはなく積極的に参加すべきです。受発注の関係ではなく、あなた自身も含めたチームにすることがとても大切です。
以上のようにアジャイル開発では、あなた自身も含めて直接顔を合わせた意思疎通ができるチーム環境を整えることが肝心で、アジャイル開発の成功に必要な要因の1つなのです。
必要不可欠な機能のイテレーションを決める
アジャイル開発はいくら仕様変更に強いといっても、「とりあえず開発をスタートしてみて、やりながら検討しよう」という進め方はよくありません。
思いつきで機能開発をスタートしてしまうと、本当はユーザーにとって必要ではない機能を開発したり、いつもまでも終わらないような開発をしてしまうなど、本末転倒な結果を招く非常に非効率な開発になってしまう可能性があるからです。
しかし皆さんの中にはその機能がはっきりしていない状態なのでアジャイル開発をしようと思っていらっしゃる方もいると思います。
ここで重要なのが、必要不可欠な機能のイテレーション（反復期間）を決めるということです。
イテレーションとは「反復」という意味で、ここでは開発を小さな単位に分け「計画」→「設計」→「実装」→「テスト」を繰り返すことをいいます。
イテレーションという縛りがあると、「この期間内でできる確認はなにか？」「これは本当に必要なのだろうか？」など、自然と必要不可欠な機能を検討することにつながるからです。
そうすることによって、アジャイル開発本来のメリットを生かすことができるのです。
機能に対してリリース計画を立てる
アジャイル開発では機能に対してリリース計画を立てるも重要です。
アジャイル開発では、ソフトウェアの計画段階で厳密な仕様を決めずに大枠の仕様と要求だけを決めます。
これは開発の仕様や設計の変更があることは当たり前という前提があることがアジャイル開発の大きな特徴だからです。
おおまかな計画のみではその後の実装フェーズで問題が起こりそうですが、逆にきっちりと仕様が決まっていないからこそ、途中で変更があっても臨機応変に対応でき、顧客のニーズに最大限応えることができるのです。
ただしその場合も前章でも述べたイテレーションの考えは非常に重要です。
イテレーションは1週間～2週間ごとが一般的で、イテレーションごとに毎回機能をリリースします。
「イテレーション1」「イテレーション2」「イテレーション3」…と繰り返しながら、細かく開発を進めていきますが、イテレーションを用いたアジャイル開発のポイントは、どの機能を優先して開発してリリースしていくかを明確にすることです。
この部分はアジャイル開発を実施するうえでも、重要な部分となりますのでしっかりとチームで議論をして進めていきましょう。
アジャイル開発でよく使われる関連用語
これまで説明をしてきたように、アジャイル開発の最大の特徴は、小さな開発サイクルを何度も繰り返すこと。
時には顧客も直接チームとして参加することにより仕様変更にも柔軟に対応でき、従来の開発手法よりもリリースまでの時間を短縮できるのが特徴です。
このプロダクトの価値を最大化することに重点を置いた新しい手法をより有用に活用するために、顧客の立場としてもアジャイル開発を語るうえで欠かせない関連用語を理解しておくことは非常に大切です。
そこで以下に重要な関連用語を解説しますので是非覚えておいてください。
ユーザーストーリー
ユーザーストーリーとは、アジャイル開発における要件を、顧客や利用者目線で簡潔に記述したものです。
顧客や利用者の目線から見た要件を書き出しておくことで、その事業の目指すべき成果や価値を明確にすることが可能となります。
たとえば「出張で飛び回っている忙しいビジネスマンは公共交通機関の遅延情報をタイムリーに入手し、事前にアポイント予定のトラブルを回避する」といった形で、ユーザーストーリーを考えることができます。
このように具体的なストーリーを作ることで軸ができ、求められる成果や要件を具体的な形で可視化することが可能です。
アジャイル開発を進める際にはこのユーザーストーリーを設定して、顧客・利用者の目線を常に意識できるような環境を作ることが望しく、それを開発関係者間で共有することができれば、開発プロジェクトがブレずに進行していきます。
アジャイル開発を実行する際には、同時にユーザーストーリーを設定し、要件を顧客目線で簡潔に記述することが求められるでしょう。
イテレーション・スプリント
イテレーション（iteration）はこれまでの説明の中にもできていましたが「反復・繰り返し」という意味で、短期間で反復しながら効率的に開発を進めるアジャイル開発のサイクルを表したものです。
アジャイル開発の手法の1つであるスクラム開発では、その開発サイクルを「スプリント（Sprint）」と呼ばれますが、意味は一緒です。
開発手法によって呼び方は変わりますが、いずれも開発期間の単位を表していると理解してください。
イテレーションの期間は一般的に1〜2週間程度、スプリントの期間は1週間から1か月設定され、各期間終了後に機能をリリースします。
期間の設定は開発チームによって変化するので注意しましょう。
ベロシティ
開発チームが1回のイテレーション内に完了できるユーザーストーリー（要求）の規模の合計値をベロシティと言います。
つまり、チームの開発量を表したもので進捗状況を計る目安になります。
「期間」と「実力」を数値化して、1イテレーションでどれだけのモノを提供できるのかを算出するための準備をします。
同一チームかつ同一期間で実施するようなケースでなければ、通常ベロシティの量は不確定なため、イテレーションを回しながら実数値を計測し、開発の終盤には正確な見通しが出せるように環境を整えていきます。
リリース計画
リリース計画は、どの機能がいつ実装されるのかについての期待を反映したロードマップです。
ただし、ここで重要なことはアジャイル開発では「開発途中に仕様や設計の変更があることは当たり前」という前提があるのであくまでも期待値の計画ということです。
リリース計画は、使用可能な機能や製品のさまざまなセットをいつ顧客に納入できるのか、プロジェクトを進めていく中でチームの計画と顧客の要求を随時すり合わせていくことを目的に使用することが良いでしょう。
したがって、リリース計画は各インテレーション・スプリント毎変わるものだということも認識として必要です。
アジャイル開発のメリットとデメリット
システムやソフトウェアの開発において、プロジェクトにマッチした開発手法を選択することは非常に重要です。ここまでアジャイル開発について紹介してきましたが、メリットとデメリットを理解した上で適切な開発手法を選択することが必要です。
メリット：ユーザーニーズの最大化と修正コストの低さ
アジャイル開発のメリットは、計画段階で綿密な仕様を決めないため、開発途中でユーザーとコミュニケーションを取りながらフィードバックを行い、確認をしながら進められます。
仕様変更や追加に臨機応変に柔軟な対応が可能で開発スピードが速いことなので、ユーザーのニーズに最大限応えることができ、高い満足度が得られる点がメリットでしょう。
また、不具合が発覚した際に戻る工数が少ないことも大きなメリットです。
初めに決定した設計・計画を重視するウォーターフォール開発の場合には、最初に決定した設計・計画を重視するため、トラブルの発生箇所によっては戻る工数が大きく、時間やコストが膨大に膨らむ可能性がありました。
しかし、アジャイル開発の場合は、小さな単位で計画から設計、実装、テストを繰り返しているため、テストで問題が発生してもその該当するイテレーション内を戻る分の工数で済みます。
デメリット：スケジュール管理の難航化しやすさ
プロジェクト全体の納期はあるものの、アジャイル開発では仕様・要件ごとにスケジュールを設定して開発に臨むため、全体スケジュールのコントロールが困難になる傾向にあります。
チームごとに小単位で開発を繰り返すため、全体の進捗を把握しきれず気付いたら納期に間に合わないということも発生する可能性があります。
また、さらに良くしようと改善を繰り返し、テストやフィードバックで変更・追加を加えていくことで、開発の方向性がブレてしまい当初の計画からズレてしまうことが理由です。
このようなことを避けるには、アジャイル開発の経験があるプロジェクトマネージャーを中心に計画を立てたうえで開発を進める中で、開発の方向性もブレないように進捗を出すことが重要です。
アジャイル開発で失敗しないためのポイント
アジャイル開発は仕様変更に対応しやすい手法ですが、失敗も多いため注意が必要です。ではどうすればプロジェクトを適切に進められるのでしょうか？それにはまずは開発案件を成功させる体制を整えることが大切です。
では失敗を防ぐためにはどのように対応すれば良いのでしょうか？最後に、アジャイル開発を成功させるポイントを見ていきましょう。
ユーザーストーリー（要件定義書）などのドキュメントはしっかり残す
システム開発を行うにあたり、要件定義を事前に実施しておくことは非常に大切なことですが、アジャイル開発ではシステムは何らかの課題を解決するためのものが多く、作り始める時点では未知のものである場合が多くなります。
つまり「こういうシステムがあれば、課題が解決できるはず」という仮説を検証することが要件定義になります。
アジャイル開発ではこの要件定義とはいうことはなく、その代わりに前述した「ユーザーストーリー」という概念があるのです。
これは顧客の意図や要求の断片であり、開発とフィードバックのサイクルを回す上での手がかりとなるもので、開発の方向性をブレないように進捗をさせるのに非常に重要となります。
ユーザーストーリーはプロジェクトの初期に顧客、もしくはスクラムでいうプロダクトオーナーが作成しますが、最初から全部を出し切る必要はありません。
無理なく思い付く範囲で主要なものを書き出し、後からいつでも思い付いたときに追加してかまいません。
特に機能ごとに開発サイクルを繰り返すアジャイル開発では、どうしてもテキストベースのドキュメント資料が不足しがちになります。
また、開発をいつも同じチームに依頼するとは限りません。別のチームに引き継ぎを行う必要が発生した場合、何の資料も残っていなければ引き継ぎが出来ず、非常に大きな問題になります。
リリース後も徐々に機能やサービスをブラッシュアップしながら運用していくことを考えると、ユーザーストーリーを軸としたモデル図など現在のシステムを表すような資料は必ず残すようにしましょう。
運用開始後の方向性も共有しておく
いくらアジャイル開発が柔軟に対応が可能だとはいえ、機能の要件が出てくるたびに暫定対応をしているとシステム全体の設計が悪くなってしまいます。
柔軟に対応することと暫定的に対応することでは、まったく意味が異なることをしっかりと理解しておくことは大切です。
そのためには事前に顧客と開発会社との間で、アプリで実現したいことや運用後の方向性についてしっかり共有しておくことです。
そこで重要なのは前項でも取り上げた「ユーザーストーリー」が共有できているかということになります。
きちんと未来を想定して「ユーザーストーリー」が共有していれば、自然と柔軟な対応ができるようになり、システム全体の設計もより効率的になるでしょう。
時間をかけてでもチームメンバーの相互理解を高める
アジャイル開発のチームの立ち上げには多少の時間を必要とします。
なぜならば開発をチームで行うので、その流れをチーム全体に浸透させたりチーム内での意思疎通や相互理解を高めることが必要になるからです。
しかしこれは逆に言えば、開発を進めていくうちに相互理解がさらに進み、徐々にスケジュールが立てやすくなっていくのもアジャイル開発の特徴です。
最終的には「決められた期間内にどれくらいの量を実装できるか（ベロシティー）」を高い精度で見積もることもできるようになりより計画性が増すでしょう。
もし開発が進んでしばらく経っているのにまだ計画とズレが生じるようなときは、チームのマネジメントがうまくいっていない可能性が高いので、チームメンバーの相互理解が深まっているかを含めて確認が必要です。
要点を抑えてアジャイル開発を成功させよう
以上、アジャイル開発についてその特徴や全体像、失敗しないポイントなどを詳細に説明をしてきました。
一口にアジャイル開発と言ってもいざ自社で実施しようとすると、経験が必要な部分が多くなかなか簡単ではないなと思われたかもしれません。
しかし、アジャイル開発は今後も非常に有用な開発手法になると思いますので、ぜひ一度挑戦してみてはいかがでしょうか？
最後に説明をしたように、アジャイル開発で肝になることはチームワークです。
弊社では、大手ITベンダー・大手webディレクター2人体制でプロジェクト管理を徹底し、素晴らしいチームワークのもと非常に高いアタリマエ品質をご提供することが可能なプロの集団です。
開発の前段階ではフルカスタマイズのデザイン作成にも対応。保守フェーズでは円滑な業務遂行を支えるDB定義書や保守ドキュメントの作成まで実施します。
デザインを通じて最終イメージを擦り合わせられるため、安心感のある開発が強みです。
「保守性が高く、クイックで健康的な開発支援」をお探しの方は、是非一度弊社までお問い合わせください。
より効率的により早くあなたのサービスを世の中に提供できる一助になれれば幸いです。
弊社では、アプリ開発における概算費用を簡単に1分程度で算出するアプリ開発見積もりシミュレーターを提供しております！
参考価格をサクッと知りたい時に利用してください！
アプリ開発費見積もりシミュレーター：https://swooo.net/estimate
