アジャイル方式とは？主な手法や開発工程を徹底解説！

システム開発の手法にはさまざまなものがあり、特に「アジャイル方式」「ウォーターフォール方式」はメジャーなものとして聞いたことがあるという方も多いものです。しかし、メリット・デメリットを知らなければ手法を選ぶのは難しいでしょう。

ここでは特に、「アジャイル方式とはどんなものなのか」を、主な手法や各開発工程に焦点を絞って解説していきます。またウォーターフォールモデルとの違いも紹介しますので、開発手法を選ぶ際の参考にしてください。

アジャイル開発とは

アジャイル開発とは、とにかくスピード重視でプロジェクトを進めていく開発プロセスのことです。文字通り開発スピードが速く、全体を作りながら随時修正を行っていく方法になります。

アジャイル（agile）は「素早い」という意味の英単語です。アジャイル開発ではすべての工程を臨機応変に移動するため、見切り発車で開発を進めることができます。例えば、設計の後にプログラミングを行い、プログラミングの段階で設計に問題があることがわかったら設計書を修正する、といったことが可能です。

ウォーターフォール開発との違い

大まかにいうと、スピード重視のアジャイル開発、丁寧さ重視のウォーターフォール開発という違いがあります。開発会社に多いのはウォーターフォール開発であり、アジャイル開発は現状実績が少ないというデメリットがあります。ただし、最近は開発のスピード感が重視されるようになっていて、アジャイル開発で開発を進める事例も目立つようになってきました。

ウォーターフォールモデルはじっくり時間をかけて各工程を進め、手戻りは最小限に抑えます。そのため、アジャイル開発のように見切り発車で次の工程に進むようなことはできません。先の工程も見越した上で、問題がないことを確認しつつ開発を進める必要があり、開発に時間がかかります。

アジャイル方式の主な手法

アジャイル方式には複数の手法があり、具体的には「スクラム」「エクストリーム・プログラミング（XP）」「ユーザー機能駆動開発（FDD）」が挙げられます。それぞれの手法について解説していきます。

スクラム

スクラムは、アジャイル方式でもっとも有名な手法です。メンバーがチームとなり、一丸になってプロジェクトを遂行していく手法です。この「スクラム」という言葉は、ラグビー用語のスクラムと同じで、チームでがっちり開発を進めていくという意味になります。

コミュニケーションを密に取れるという特徴もあり、メンバー間で互いにどのような作業を行っているのか、進捗はどうか、といったことをこまめに確認しながら進めます。確認の手間は生じますが、連携ミスによる手戻りが少なくなるというメリットがあります。

またシステム開発のプロジェクトでは必ずエンジニア間でスキルに差があり、新人のメンバーがアサインされているケースも多々あります。新人のエンジニアにとって、作業だけ割り振られて放置されることは非常に不安でストレスが大きいものです。

スクラムなら、こうした新人エンジニアへのケアも行いやすいので、プロジェクトメンバー間でスキルに差がある場合も開発を成功させやすくなります。

エクストリーム・プログラミング（XP）

エクストリーム・プログラミング（XP）とは、技術面を重視するプログラマー主導の手法です。「コミュニケーション」「シンプル」「フィードバック」「勇気」の4つの価値を共有して進められます。

特に「勇気」が重視されています。エクストリーム・プログラミング（XP）における勇気とは、仕様変更などを積極的に行うという考え方のことです。初期の設計に従うというよりは、プログラマーが自由にプログラミングを行うという考え方も根底にあります。

各プログラマーが自由に動く分連携は必要不可欠になるので、その分をコミュニケーションで補います。スクラムは全員で同じ方向を向いて開発を進めるという発想でしたが、エクストリーム・プログラミング（XP）には個人主義の側面もあります。しかし、完全に個人主義では、1つのシステム開発チームとしてまとまらないので、コミュニケーション・連携には注意しなくてはならいない方法です。

ユーザー機能駆動開発（FDD）

ユーザー機能駆動開発（FDD）は、ユーザーの機能価値を重視した開発手法です。ユーザービジネスの見える化を行い、適切なシステム開発に取り組んでいきます。スクラムやエクストリーム・プログラミング（XP）は開発の体制に関する方式でしたが、ユーザー機能駆動開発（FDD）は体制ではなくユーザー機能価値重視という価値観に関する方式です。

そのため、ユーザー機能価値が向上するならどのような体制、手順で開発を進めても問題ありません。ただしユーザー機能価値向上のためには見える化が重要なので、ソースコードを書くだけでなく、「ソースコードの内容を設計にわかりやすく落とし込み、ユーザーに提供する」といったことは必要になります。

アジャイル手法のメリット・デメリット

ここからはアジャイル手法のメリット・デメリットについてそれぞれ解説します。

アジャイル手法のメリット

アジャイル手法の主なメリットとしては、開発スピードの速さや臨機応変な対応、顧客満足度の高さなどが挙げられます。

アジャイル開発の方式を複数紹介しましたが、いずれも開発速度が高いと言えます。なぜなら工程の手戻りが許されるので、見切り発車でも開発を進めていくことができるからです。ウォーターフォールモデルは後戻りができないので、徹底的に失敗のリスクを考慮する分開発が遅くなりがちです。

また開発のスピード感により納品が早くなれば、顧客満足度が高くなるでしょう。今の時代は特に、「スピーディーに納品され、すぐに運用が開始できること」の価値が高まっています。加えて、臨機応変な対応ができるので、仕様変更の要望にも応えてもらいやすいでしょう。

一方ウォーターフォールモデルの場合は、仕様変更があると前の工程から手順通りにきっちり作業を進めなければならず、時間がかかります。

顧客にとっては、仕様変更の申し出をしにくい、仮にできても納品が遅くなるからと天秤にかけて考えなければならないといったことがあります。その点アジャイル手法ならすぐにシステムに反映してもらうことができるので、対応してもらいやすいことは十分にメリットと言えるでしょう。

アジャイル手法のデメリット

一方で、アジャイル手法の主なデメリットとしては、納期管理の難しさや、全体の進捗状況の確認が難しい、という点が挙げられます。

ウォーターフォールモデルの場合は、手順通りにきっちり作業が進められるので、現在どこまで開発が進んでいるのか状況を把握しやすいです。

しかしアジャイル手法の場合は、エンジニアがそれぞれ自由に開発を進めていくので、納期管理や全体の進捗状況の把握が難しくなります。結果的に「それぞれのエンジニアがやっている作業がちぐはぐになってしまう」ということも起こり得るのです。連携ミスが生じると大幅な手戻りにつながるので、アジャイル手法ではコミュニケーションと連携が特に重要と言えるでしょう。アジャイル手法を選択する場合、ウォーターフォールモデル以上にコミュニケーションを積極的に取っていくべきです。

アジャイル開発の工程と一連の流れ

アジャイル開発も工程は基本的にウォーターフォールモデルと同じです。具体的には、「要件定義→基本設計→詳細設計→プログラミング→単体テスト→結合テスト→システムテスト→運用テスト→リリース→運用・保守」という流れになります。

ただアジャイル開発の場合は、手戻りをしても問題ありません。一段階前の工程だけでなく、自由にどの工程に飛んでも問題ないというイメージです。

一般的には、「プログラミングをしながら設計書を随時書き変える」「テストの結果に応じてソースコードを書き変える」などが、システム開発では起こりやすいでしょう。ウォーターフォールモデルの場合、手戻りが発生するなら正式な手続きが必要で、戻った工程からすべてやり直す必要があります。

これに対してアジャイル開発の場合、ある程度帳尻が合わせられるのであれば、工程を自由に行き来しても問題ありません。もちろんまったく設計をせずにいきなりプログラミングの工程に進むような開発手法はNGです。しかし必要な要件を満たしながら工程を進めていけば、ある程度見切り発車で工程を進めても問題ないということです。

各工程について概要を解説すると以下のようになります。

まず要件定義はシステムの概要を話し合い、決定する作業手順です。プロジェクト内のエンジニア同士で話し合うことはもちろん、システム開発を依頼した企業の担当者も交えて話し合いを行います。

次に基本設計で、システムの大枠の設計を記載した書類を作成します。具体的な処理ではなく、必要な要件をある程度細分化して記載していく内容になります。

詳細設計では具体的な処理を決めて記載していきます。基本的には、処理の内容を日本語で記載しますが、ソースコードを直接文書に記載することも少なくないでしょう。

プログラミングでは、詳細設計に基づいて実際にソースコードを記載していきます。そのため、設計で詳細に記述しておくことで、後のプログラミング作業を効率化できます。

もっと言えば、プログラミングの良し悪しを決めるものとしても設計の作業手順を最適に行うことが大切なのです。

プログラミングが完了したら、テストを行います。まずは単体テストにより、各々の処理一つひとつをテストしていきます。

次に結合テストです。結合テストでは、単体テストを通過した複数の処理を結合・連携して、全体として問題がないかをチェックしていきます。

さらに総合テストでは、結合テストを通過した処理をシステム全体として動かします。この総合テストでも問題がなければ、運用テストに進みます。これは、実際の運用環境でシステムを稼働運用させてみるテストです。

もちろんリリース後にも、保守・運用を行います。顧客側で、保守・運用後に改修やメンテナンスが必要になったら随時対処します。大幅な改修が必要な場合は、再度プロジェクトを発足して要件定義から実施していく必要もしょうじるでしょう。

これらの手順の詳細はプロジェクトによって異なります。設計書が基本設計と詳細設計で分かれていなかったり、単体テストをプログラミングしながらざっくりしか行わなかったりといったケースもあるでしょう。例えば単体テストの一部を省略して、早い段階で結合テストに移っていくという場合もあります。現場によって臨機応変に動いているので、実際には上記の基本から崩しながら運用されていると理解しておきましょう。

まとめ

アジャイル開発はスピード感があり、工程の行き来の自由度が高い開発方法です。アジャイル開発の中でももっとも多いスクラムは、自由度が高いながらもコミュニケーションを密に取り、チームで開発を進めていきます。

また、アジャイル開発、スクラムに興味がある場合は、「Cloud Native Dojo」の利用を検討してみましょう。「Cloud Native Dojo」は企業に向けたアプリケーション開発者育成プロジェクトで、システム開発の内製化に役立ちます。また、「Cloud Native Dojo」参加の企業で躓かないアジャイルの導入と実施を、株式会社エムティーアイが「DX推進支援サービス」としてサポートしています。