システム開発現場にて「アジャイル開発」はすっかりその中心として存在するようになりました。本稿ではそのアジャイル開発について分かりやすく解説します。
アジャイル開発という概念が誕生したのは2001年のこと。同時、システム開発において専門性の高い有識者が集まり「アジャイルソフトウェア開発宣言」を策定したことが始まりです。これによるとアジャイル開発は以下12の原則に従ってシステム開発を進めることと定義されています。
- 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
- 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
- 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
- ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
- 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
- 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
- 動くソフトウェアこそが進捗の最も重要な尺度です。
- アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
- 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
- シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
- 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
- チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
結局アジャイル開発ってなに?
上記の12原則を見ただけでは「結局のところアジャイル開発って何なの?」という疑問が残りますね。
アジャイル開発とは簡単にいえば「小さな開発単位を設けて要件を分離し、開発とテストを、それと改善を繰り返していくことで従来のシステム開発手法よりも早く、そして柔軟性を持って進めるシステム開発手法」のことです。ちなみにアジャイル(Agile)とは「素早い」う「俊敏」という意味です。
そんなアジャイル開発の基本プロセルは「リリース計画」と「イテレーション」のたった2つで構成されています。
リリース計画
新しいソフトウェアを開発したり新しい機能を実装するにあたって、大体の仕様と要件を定義するのがリリース計画です。仕様および要件は細部まで定義するのではなく、あくまで「大体」定義します。これはアジャイル開発が「システム開発途中に仕様や要件が変更されるのは当たり前」という前提を持った開発手法だからであり、仕様および要件が明確に定義されていないからこそ顧客からの急な変更にも対応できるようになっています。
従来のシステム開発モデルである「ウォーターフォール開発では、最初にシステム全体の仕様と要件を細かく定義して、一連の流れに沿って開発を進めていきます。しかし、それでも仕様および要件の変更は起こるものです。ウォーターフォール開発は工程の後戻りが難しい側面があるため、ちょっとした変更が開発スケジュール全体に影響を及ぼすこともあります。
その点アジャイル開発はそうした不測の事態を想定しているため、ちょっとした仕様や要件の変更が起こっても即座に対応でき、かつ開発スピードを落とさずにプロジェクトを進行できるというメリットがあります。
イテレーション
イテレーション(Iteration)とは「反復」という意味です。アジャイル開発においては小さく区切った開発単位を指します。リリース計画によって仕様と要件の定義が完了すると、優先度の高いものから「計画」「設計」「実装」「テスト」を反復的に行います。このことから、アジャイル開発はイテレーションごとにウォーターフォール開発のようなプロセスを持っていると考えてよいでしょう。
「計画」「設計」「実装」「テスト」という開発プロセスをイテレーションごとに区切るとより手間がかかるのではないか?と考えることもできますが、実際には仕様および要件ごとの基準をクリアするスピードが早く、かつ柔軟性の高い対応ができるため効率良くシステム開発を進めていくことが可能です。
イテレーションは通常、開発するシステムや実装する機能に応じて1週間~4習慣程度で区切ります。それ以上長くなるとアジャイル開発としての利点を失うことが多いためです。
こうしたアジャイル開発に適したシステム開発とは、モバイル向けのアプリケーション開発やWebサービス開発等です。これらの分野は技術進歩が早く、かつ顧客ニーズも多様に変化します。そうした変化のスピードに対応するためにも、アジャイル開発によって素早い開発を行うことが有効的です。
その反対に、長年手作業で行われてきた業務プロセスをシステム化することには不向きです。そうしたシステム開発では仕様と要件が固定的で変更も少ないため、一連の流れで開発し、開発工程ごとに成果物を設けて着実にプロジェクトを進めていくウォーターフォール開発が有効的です。
アジャイル開発の中にも種類がある
一口にアジャイル開発といっても、その種類によって特徴が異なります。それが「スクラム」「XP(エクストリームプログラミング)」「FDD(Feature Driven Development:ユーザー機能駆動開発)」です。
スクラム
メンバー自身がイテレーションごとの計画や設計、実装を進めていき進行に問題はないかを精査するコミュニケーション重視のアジャイル開発です。メンバー同士で定期的に進捗を管理します。コミュニケーションが不足するとリリースした機能が正常に動作しなかったりといった問題が生じます。
XP(エクストリームプログラミング)
プログラマー中心のアジャイル開発であり、「コミュニケーション」「シンプル」「フィードバック」「勇気」という4つの価値を共有することで開発を進めていきます。仕様や要件の途中変更への柔軟性を重視したものなので、変更に立ち向かう「勇気」がとっても重要です。
FDD(Feature Driven Development:ユーザー機能駆動開発)
顧客にとっての機能価値(Feature)とは何か?に主眼を置いてプロジェクトを進めるアジャイル開発です。ユーザー側のビジネスの見える化を実施してから、実際に動作するソフトウェアを適切な間隔で開発していきます。
Azure DevOpsでGitHubを連携させる!
ソースコードの組織的管理やフィードバックの迅速化を行えるGitHubなら、適切なアジャイル開発を実現します。アジャイル開発ではメンバー同士のソースコード共有や、組織的なバージョン管理が欠かせません。これを如何に適切に行うかによってアジャイル開発の成否が分かれます。
GitHubアカウントを使用してAzure DevOps にサインインできます。これにより、GitHubアカウントだけでリポジトリからデプロイすることが可能となります。便利な機能なので、ぜひお試しください。