アジャイル開発とは?【ウォーターフォール開発との違いも踏まえてわかりやすく徹底解説】

残り5社! 文字単価3円で発注できる記事作成代行サービスはこちら

集客を自動化させるインスタ運用代行はこちら

システム開発現場で用いられるアジャイル開発という手法を耳にしたことがあるかもしれません。

興味があって調べてみても専門用語ばかりでよくわからないという方が少なくないのが現実です。

理屈がわかれば様々な開発シーンで応用ができる手法ですので、今回はアジャイル開発について詳しく解説していきます。

目次

アジャイル開発とは

アジャイル開発はソフトやシステム開発における手法の一つです。

開発の速度と柔軟性を併せ持った手法で、様々なシーンで活用されつつあります。

アジャイル開発の由来

アジャイル開発のアジャイル(agile)は「敏捷」や「素早い」という意味の英単語です。

また活発な状態頭の回転が早いことを意味する単語でもあります。

単語が表す通りに素早い開発が可能になり、その素早さ故に小回りが利くということを表しています。

計画から設計、実装からテストという開発の基本的な流れを各機能ごとの小さな単位で行い、それぞれの機能を1つの集合体として大きなシステムに組み上げる開発方法です。

アジャイルソフトウェア開発とは

アジャイル開発はアジャイルソフトウェア開発とも呼ばれ、特にソフトウェアなどの開発においては主流になりつつある手法です。

ソフトウェアの開発には時間がかかりがちです。アジャイルソフトウェア開発ではその時間を短縮することができるような手法を採っています。

開発期間を短くすることができればサービスインまでの開発期間が減り、収益化までの速度が高まります

素早くサービス開始に繋ぐことができる開発手法のためアジャイル開発、ソフトウェアの場合はアジャイルソフトウェア開発と呼ばれています。

アジャイル開発のメリット

アジャイル開発はソフトウェア開発の主流になりつつある手法なだけあって、非常にメリットが多い開発方法です。

まずはアジャイル開発のメリットを紹介していきます。

柔軟な対応が可能

開発過程を細かく分割していくため、問題が発生しても大規模な問題にはならず開発を続けられるというメリットがあります。

新しい機能を急遽組み入れることになった場合でもその機能だけを別に開発し、追加することも容易です。

開発現場において柔軟な対応が可能な手法は非常にメリットの大きい手法と言えるでしょう。

開発中のトラブル対応力が高まる

急な仕様変更を受けた場合、総合的な開発をしていると根底から作り直しになってしまう場合があります。

開発の現場において仕様変更は起きて欲しくないものではありますが、よくあることでもあります。

アジャイル開発の場合、仕様変更が起きた際も該当箇所に関わる部分だけの修正で済む場合が多いのが特徴です。

また不具合などが見つかった場合でも同様に該当箇所だけの修正で済ませられる可能性が高く、トラブル対応力の高い手法と言えるでしょう。

サービスインを早めることができる

細かく分割して開発をしているため、最低限の機能だけを組み込んで部分的なサービス開始をすることができるのもアジャイル開発のメリットです。

開発期間はコストだけがかかり収益が発生しない期間です。

しかし、部分的であってもサービスインすることで収益を得られる可能性があります。

特に中小企業では収益化の速度は死活問題になることもあります。

このような観点からもサービスインを早められる可能性のあるアジャイル開発は有益な手法といえます。

顧客満足度を高めやすい

部分的であってもサービスインを行うことで不具合が早期に見つかったりする場合があります。

当然不具合は少ない方が良いのですが、早めに見つかってトラブルを未然に回避できるに越したことはありません

顧客側からしても自分の指摘でサービスが改善されるとわかれば満足度は上がりやすい傾向にあります。

また今後どのような機能が望まれているのかは実際に使用している顧客の声を聞くのが一番です。

完全に出来上がっていない状態でも顧客の望む形に向けて方向修正が可能というのも大きなメリットです。

サービスイン後のトラブルにも対応しやすい

ソフトウェア開発においては、サービスイン後には様々機能を拡張していくことが当然になっています。

新機能が既存の機能と噛み合わないというのはよくあるトラブルです。

この場合新機能の方を根本的に作り替えなければならないことがありますが、新機能の方もアジャイル開発の手法で分割して開発が行われていれば修正がそこまで難しくならないケースが多いのもメリットです。

新機能に伴って既存の機能の方を修正する必要がある場合でも同様です。

該当部分の修正だけで済む可能性があるのはアジャイル開発のポイントです。

アジャイルソフトウェア開発宣言とは

アジャイルソフトウェア開発には「アジャイルソフトウェア開発宣言」という文書が存在します。

これは2001年にソフトウェア開発で名声のあるプログラマーが集まり、開発手法を共有する議論を行った結果まとめられた文書です。

これは現在でもweb上で公開されており、70種以上の言語でそれぞれ原文を翻訳したものを見ることができます

原文は下記の通りです。

アジャイルソフトウェア開発宣言(原文:日本語)

私たちは、ソフトウェア開発の実践

あるいは実践を手助けをする活動を通じて、

よりよい開発方法を見つけだそうとしている。

この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを

認めながらも、私たちは右記のことがらにより価値をおく。

アジャイル開発宣言で提唱されている価値観

原文にある左記と右記が日本語では若干分かりにくくなっていますが、要点をまとめると下記の通りです。

文章中の「左記のことがら」 文章中の「右記のことがら」
プロセスやツール 個人と対話
包括的なドキュメント 動くソフトウェア
契約交渉 顧客との協調
計画に従う 変化への対応

上記の左記のことがらはもちろん重要であるものの、開発者としては右記のことがらをより重視するとしてまとめられています。

ソフトウェアは何かを解決する手段であって、ソフトウェア自体が目的ではありません。

それを使う人に渡って、問題解決を可能にするという価値を提供することが目的です。

そのために計画を立てることは重要ですが、必要に応じて柔軟に対応できることが理想です。

アジャイル開発宣言に伴う開発チーム構築

アジャイル開発においてチーム全体がアジャイル開発宣言を理解し、協力できるチームを編成することができるのが理想です。

個人との対話」や「変化への対応」は非常に重要で、チーム内でそういった事柄に関して共有できていればスムーズに開発を行うことができます

また「顧客との協調」に関しても価値観を共有して当たれるのが理想です。

動くソフトウェア」は当たり前と思われがちですが、アジャイル開発の場合は各々が組んだ機能を組み合わせて一つのソフトウェアを作っていく形になります。

そのためチームとして一丸になって解決策を出していくことも重要です。

アジャイル開発の手法

アジャイル開発の手法は細分化するといくつかの手法に分けることが可能です。

今回はその中でも代表的な3つの手法に関して詳しく解説していきます。

スクラム

スクラム最も一般的なアジャイル開発の手法です。

開発チームとして互いに対話を繰り返して開発を行っていくことが重要ということから、ラグビーで肩を組んでがっしり一つになっている状態のスクラムが語源になっています。

名前の通りチーム全員の協力が不可欠で、対話や共有が不足していると各機能同士の連携がうまくいかなくなったり、そもそも動くソフトウェアとならないケースもあります。

スクラム開発ではメンバーがそれぞれの機能ごとの計画、設計、実装とテストを繰り返して開発を進めます。

スクラム開発ではこの方法のことをスプリントと呼びますが、アジャイル開発の場合は1サイクルごとの単位としてイテレーションと呼ぶのが一般的です。

およそ1~2週間程度を一つのイテレーションごとの機能にかかる時間として、随時開発していく方法がよく採られています。

この期間に関してもチーム内でよく相談して計画を立てていく必要もあります。

エクストリームプログラミング

エクストリームプログラミングはExtreme Programmingの頭文字を取ってXPと略して記載されるのが一般的です。

チームワークに重きを置いている手法で、そのために必要な価値観を共有することの重要さがエクストリームプログラミングの重要な部分になります。

エクストリームプログラミングでは下記の5つの価値に重きを置いて開発を進めます。

  • コミュニケーション
  • シンプルさ
  • フィードバック
  • 勇気
  • 尊重

それぞれの価値についても詳しく解説していきます。

コミュニケーション

システム開発をチームで行うことを考えるとアジャイルソフトウェア開発宣言でも提唱されているように個人との対話が重要になってきます。

プロセスやツールももちろん重要ではありますが、チーム全体の見解をまとめて、頻繁なコミュニケーションを取ることによってこそ可能になるという概念です。

そのためコミュニケーションに価値を置き、コミュニケーションをとった上でのフィードバックを共有することを継続することで真価を発揮します。

シンプルさ

エクストリームプログラミングでは特にシンプルさを重視します。

最初の計画の時点で可能な限りシンプルに計画をし、できるだけトラブルが起きないような設計と実装を目指します。

現時点で最も必要な機能に焦点を当てて開発を行い「実際に必要となるまでは追加しない」という価値感として要約されています

実際に必要となるまでは追加しない」は“You ain’t gonna need it”を縮めてYAGNIという原則としてしばしば用いられます。

後で使うかもしれないと予測して作られたものの9割は無駄になることや、余計な機能があることで進行が遅れることを危惧するスタンスです。

チーム全体で行動することを考えれば尚更シンプルであることが求められます

チーム内の開発者が誰でも簡単に理解できることが重要で、簡単に理解できるから簡単なコミュニケーションであっても十分に意思疎通することが可能になります。

フィードバック

開発におけるフィードバックは大きく分けて2種あります。

一つは実際にシステムを動かしてみることで当初の予定通り動くのかどうかという直接的なフィードバックです。

もう一つは顧客ら開発されたものを使用した人のフィードバックとして受け取れるものです。

このどちらにおいてもシンプルさとコミュニケーションの重要性と関連します。

開発における欠陥はそのままフィードバックされるので、シンプルに欠陥部分の修正が必要です。

顧客からのフィードバックは顧客の望んでいる姿を理解することができ、そのフィードバックを受けることで本当に必要な機能を絞ることができます。

勇気

最初に計画を立てて進捗を見つつ進める開発は非常にわかりやすく、安心して計画の進捗具合を計ることができます。

しかしアジャイル開発全般に言えることとして柔軟にその日その日の細かな開発を続けていると本当に早く開発が終わるのか不安になってしまう場合もあります。

それでも勇気をもって設計の行き詰まりを避け、場合によってはリファクタリングすることを選択する必要があります。

リファクタリングにおいては場合によってはかなり時間をかけて開発した機能であっても、複雑であまり良い状態ではない機能を捨てて新しく作り直す勇気も必要です。

尊重

自尊心だけではなく、お互いに尊重する気持ちを持つことも重要です。

チームは一丸となって開発にあたるべきで、お互いに尊重しつつコミュニケーションを取っていくことで成果に繋がるという価値感です。

ここまで紹介した4つの価値観をしっかりと全員がもつチームであることが重要と述べられています。

ユーザー機能駆動開発

ユーザー機能駆動開発Feature Driven Developmentの頭文字を取ってFDDと略されるのが一般的です。

ユーザー機能駆動開発において重視されているのはユーザーの目線です。

アジャイル開発の手法の中でもユーザーにとっての機能価値に重きをおくことで、より効率的に開発を進めることを目的にしています。

そういった背景からアジャイル開発の中でも大規模な案件に対応しやすい手法とも言われています。

ユーザーが何を求めているのか、実際に使用しているユーザーがどう感じているのかという点のフィードバックを受けることが重要になります。

そのためチーム内でのコミュニケーションも重要ですが、それ以上にユーザーとのコミュニケーションを重視している手法です。

アジャイル開発の長所は機能ごとに開発していく方法なので、随時リリースされていくサービスについてユーザーからのフィードバックを受けて機能を追加することが難しくありません。

アジャイルソフトウェア開発宣言にある「顧客との協調」を最大限重視している手法です。

アジャイル開発の注意点

アジャイル開発は手法に多少の違いはあっても基本的に柔軟性に富み拡張性も高い開発方法です。

しかし、デメリットとも言えるようなポイントもいくつかあります。

アジャイル開発の手法を採用する前に、注意すべき点についても把握しておきましょう。

スケジュール管理が難しい

アジャイル開発では一つ一つの機能ごとにスケジュールを組み、問題が解決し次第で次の開発に移っていく開発方法です。

全体のスケジュールを組んで開発を進める方法と違って、随時変更が起きてしまうために長期的な進捗の状態を判断することが難しくなってしまうというデメリットがあります。

柔軟に対応できるというメリットを活かすために、対応するための時間を消費してしまっているのがデメリットになってしまうというケースです。

またメリットの一つにサービスインの早さを挙げましたが、管理が難しいことから想定している機能が不十分な状態で無理やりリリースしてしまうというケースも見られます。

基本的にアジャイル開発自体が短期で終わる開発に向いた方法であり、長期計画には向いている方法ではありません

また期限が明確に定められている開発にも向いていない開発方法といえます。

解決策としては一定のスパンごとに進捗を確認して納期目標を確認し続けることや、大筋の計画を立てて基本的な機構ができあがってから機能ごとの改善を行うなどの方法で対応も可能です。

そういった管理ができるプロジェクトリーダーを中心とした計画も必要です。

予算が膨れ上がってしまう

スケジュール管理に絡んだデメリットになりますが、想像以上にコストがかかってしまう場合があります。

より良い方法で、トラブルを回避しながら開発できる手法でもありますが、それが可能なだけに開発期間が長引く可能性があります。

開発期間が長引くことで開発費がかさみ当初の予算を大きくオーバーしてしまうというのはよく耳にするデメリットです。

スケジュール管理と同様に基本的な機構を完成させた後機能ごとをブラシュアップさせていく手法で対応されるケースが一般的です。

こちらの場合でもコストを管理するマネージャーを決めておくと比較的スムーズに解決する可能性があります。

最低限の機能でサービスインを早めて収益化を図るというのもこのデメリットを回避する方法の一つといえます。

当初の計画と大幅にずれる可能性がある

チーム内での対話や、顧客からのフィードバックは重要ではあります。

しかしその影響で当初予定していたものと別物になってしまうというケースも起こりえます。

元々の仕様で開発をすすめていたところ仕様変更や追加要素の影響で、基本的な機構自体に手を加えることになってしまうというパターンです。

特定の問題を解決するための開発が目的で、当初の予定通り行かずとも柔軟に対応を考えるのがアジャイル開発です。

目的さえぶれなければ当初の予定と形が変わってしまうのは問題ありませんが、目的自体が変わってしまうのは問題です。

またこれは開発期間が延びてしまう原因の一つでもあります。

明確に目的をもって、方向性を見失わない開発を続けるよう意識する必要があります。

顧客のニーズに振り回される可能性がある

これはユーザー機能駆動開発(FDD)の手法を用いる際に起きがちなデメリットです。

顧客のニーズに対してできるだけ対応をしようと考えることで開発自体に悪影響を与えてしまう可能性があります。

ユーザーのニーズが常に正しく、絶対に必要なものとは限りません

しかし「顧客との協調」という価値感を重視するあまり意見に振り回されてしまうことがあります。

できる限りユーザーのニーズには答えるべきではありますが、チーム内でもしっかりと対話を行うことが必要です。

複雑になるほど開発に期間はかかってしまい、開発費もかさんでしまいます。

開発チーム内でも必要と考えられるものかどうかをしっかりと判断しましょう。

終わりが見えない開発になる

ソフトウェア開発においては製品としてリリースしたものをアップデートして使用していくというのは一般的なことです。

アジャイル開発は柔軟性に富んでいることもあり、拡張性にもすぐれているため、この場合は大きなメリットになります。

しかし、大規模な開発や機械などの開発の場合はこれがデメリットになってしまうケースもあります。

定められた期限内に完了する必要がある開発の場合はやはり向かない方法といえるでしょう。

反対に継続した拡張を行っていくソフトウェアなどでは新しい要素を取り入れやすいため、一長一短といえます。

ウォーターフォール開発との比較

アジャイル開発と比較されることが多い開発方法にウォーターフォール開発という手法があります。

従来ではウォーターフォール開発の方が一般的でしたが、ソフトウェア開発においてはもはやアジャイル開発の方が一般的な手法です。

しかしウォーターフォール開発にももちろんメリットがあり、アジャイル開発では向かないような開発に適性がある場合もあります。

ウォーターフォール開発とは

ウォーターフォール開発滝(Waterfall)から名付けられた開発方法です。

上から下に落下していくように開発を行うという手法が採られています。

大まかには下記のように開発をしていきます

  1. 要件定義
  2. 外部設計
  3. 内部設計
  4. コーディング
  5. 単体テスト
  6. 結合テスト
  7. 運用テスト
  8. リリース

要件定義

まずはシステムに必要な機能方向性を定めます。

この時点で予算や必要な人員リリース予定なども決定してしまうのが一般的です。

設計

設計には内部設計外部設計がありますが、それぞれに必要な機能を持たせます。

その上で内部設計では効率性やコスト、外部設計では操作性や外観などを設計していきます。

コーディング

設計を元に実際に組み上げる過程がコーディングです。

ソフトウェア以外で言えば次のテストと合わせて試作にあたるものです。

テスト

テストには単体テスト結合テスト運用テストがあります。

各機能がそれぞれ正常に動いているか確認し、それを組み合わせても問題ないかの確認

最終的に目的通りの機能を持っているか確認します。

リリース

テストで問題がなければリリースとなります。

ソフトウェア以外の場合はここから生産などが始まります

ウォーターフォール開発のメリット

ウォーターフォール開発は最初に完成の形や、そこに至るまでのコストや日数などを決めてしまうのが特徴です。

何を作る」という最初の目的に対して必要なものを計算して計画するため安定性が高い開発方法といえます。

目的通りのものが完成する

最初に決めたものを決めた通りに開発するのがウォーターフォール開発です。

そのため当然と言えば当然ですが、目的を達成するものが間違いなく完成します。

注文を受けて開発を行う場合においては注文通りのものを決められた期間で収めるのが重要であり、それを計画的に行えるウォーターフォール開発はこのタイプの開発に適した開発方法です。

進捗確認が容易

最初の要件定義時に日程的なスケジュールも組んでしまっているため、現時点の進捗具合に問題がないかどうかを確認することが容易です。

そのため別の開発と並行している場合でもスタッフの管理が容易になるというメリットがあります。

またメンバーの交代があった場合も、現時点での状態を把握しやすくスタッフの代えが利きやすい開発方法ともいえます。

ウォーターフォール開発のデメリット

ウォーターフォール開発においてデメリットも当然存在しています。

長い開発期間を要する場合が多い

要件定義の時点でほとんどのことを決定してしまうウォーターフォール開発は要件定義にかなりの時間を要するという欠点があります。

次で紹介するデメリットにもかかってきますが、後になってから計画を変えることが非常に難しいために要件定義を慎重に行う必要があります。

そのためスピードが要求される開発には不向きというのがデメリットです。

また要件定義を慎重に行える経験豊富なベテランのマネージャーが必要になってしまうというのもポイントです。

仕様変更が難しい

要件定義で決められたものを開発するのがウォーターフォール開発です。

仕様変更はかなり困難というのが現実です。

ソフトウェア開発においては仕様変更は頻繁に起きうるものです。

先ほど解説したように開発そのものに時間がかかりがちなウォーターフォール開発では、開発中に現在の仕様では使えない物になってしまうという可能性があります。

そうなってしまえば計画そのものが頓挫してしまい大きな損失になってしまうケースもあります。

計画にずれが起きると修正が難しい

開発の現場において遅延というのもまたつきものです。

しかし、明確にリリース日を定めてしまっているウォーターフォール開発では遅れが許されません

計画にずれが生じた場合かなり無理なスケジュールで開発を行わなければならない可能性があり、スタッフへの負荷は当然大きくなります

無理なスケジュールがまた別のトラブルの元となってしまう可能性は十分にあり、修正は非常に難しいものです。

ウォーターフォール開発とアジャイル開発の違い

ウォーターフォール開発のメリットとデメリットを解説しましたが、紹介した通りメリットは堅実で安定性が高い開発方法であることです。

しかし、ソフトウェア開発においてアジャイル開発が主流になったのはスピーディな開発を求められることが多い事に起因しています。

まだウォーターフォール開発のデメリットでも解説したように開発期間がかかってしまうことで、リリースするころにはすでに古い仕様となってしまうケースも珍しくありません。

アジャイル開発は長期的な計画や予算、人員などに不確定要素が大きい開発方法ではありますがウォーターフォール開発と比較すれば開発が早いことが多い手法です。

また柔軟性に富んでいるため仕様変更にも強いというメリットもあります。

短期的でスピードが求められる開発ではアジャイル開発長期的で堅実な成果が求められる開発にはウォーターフォール開発が向いているといえます。

アジャイル開発の実用事例

アジャイル開発の手法を使って成功した事例をいくつか紹介します。

登録エリア災害・避難情報メール

KDDIの提供する災害情報などを伝えるメール配信システムの開発にはアジャイル開発の一つであるスクラムの手法が用いられました。

チームとして全員で目的を共有し開発を行うことで比較的短期間でのシステム開発成功に繋がったという結果です。

関係各社との情報連携も必要なため、アジャイル開発の手法で分割して対応するのが適していたといえます。

エリアごとの災害情報をまとめる機能や、その該当エリアに居る人を分けるための機能をそれぞれ分割して作ることができるアジャイル開発は最適な手段といえます。

顧客管理システムの刷新

アクサ生命ではアジャイル開発の手法を取り入れ、複雑な顧客管理システムの統合と刷新をおこないました。

様々な情報を扱う必要がありましたが、それぞれの情報を扱う機能をそれぞれ開発していくというアジャイル開発の手法がマッチしたこともあり現在も稼働しています。

複雑な機能を求められている場合にはアジャイル開発が有効です。

まとめ

今回はアジャイル開発について開発にあまり触れる機会がなかった人であってもわかりやすく解説を行いました。

ソフトウェア開発においては仕様変更や拡張性が重要です。

その要件を満たすことができる開発方法としてアジャイル開発がソフトウェア開発の現場では主流となりつつあります

他の開発現場においても短期的な計画では有効な方法ですが、他の開発方法との比較の上で慎重に検討をしましょう

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

目次