アジャイル入門 ― 本質を理解して実践しよう！
アジャイルとは何か？ ツールと開発手法「スクラム／XP」、ウォーターフォールとの違い
もはや必須知識の「アジャイル」の基礎を解説。誕生の背景から、その概要と、よくある誤解、実際に組織／チームに適用する方法までをできるだけコンパクトにまとめる。
アジャイルとは？
最近、IT系のイベントに参加すると、そのほとんどの場合で「アジャイル」という単語が一度はどこかしらで出てくる。それほど現在のIT、特にソフトウェア開発の業界では、アジャイルが身近な手法であり、もはや必須知識といってよいだろう。
本稿では、その「アジャイル」誕生の理由・背景から、アジャイルの概要とよくある誤解、実際に組織／チームに適用する方法までを、できるだけコンパクトに説明する。
なぜアジャイルソフトウェア開発が生まれたのか？
そもそもアジャイル（Agile）という単語は、「素早い、身軽な、機敏な、頭の回転が速い」という意味の形容詞でしかない。そのごく普通の形容詞である「アジャイル」が広く知れ渡るきっかけとなったのは、2001年にアジャイルソフトウェア開発手法（当時は軽量ソフトウェア開発手法と呼ばれていた）の分野において、著名な17人がアメリカ合衆国のユタ州に会し、アジャイルソフトウェア開発宣言をまとめたことに起因している。
わざわざ“ソフトウェア開発手法”に「素早い、身軽な、機敏な、頭の回転が速い」という形容詞である“アジャイル”を付加したということは、それまでのソフトウェア開発手法は「アジャイルではない」＝「のろい、にぶい、鈍重な、頭の回転が遅い」ものが多かったことを意味する。
ではなぜアジャイルであることがソフトウェア開発に求められたのか？
※この図は、次のリンク先ページの画像を参考に、新たに書き起こしたものです。
●【参考元】「ソフトウェア開発環境の最新動向 | Microsoft Visual Studio」の「ビジネス価値を提供し続ける」 © Microsoft
図1は1990年代～2000年代～2010年代で、ビジネスとITの関係性がどのように変化していったかを示している。これを見ると、時代の流れとともにソフトウェアの役割は、「便利さを実現するための一部作業のシステム化」から「新しいビジネスを生み出す源泉」へと変わっていったことが分かる。
この変化は、従来のソフトウェア開発の手法にも課題をもたらした。1990年代のように「何らかの作業をシステム化」するだけの場合、作業内容は基本的に不変なので日々の状況に応じて仕様が変化することはほとんどなかった。しかし、2010年代のように「新しいビジネスを生み出す源泉」となった場合、日々のビジネス環境の変化に応じて仕様も変化させる必要が出てくる。そのような仕様の変化が発生する状況において、1990年代にソフトウェア開発の主流であった計画駆動型の開発手法（ウォーターフォール開発手法など）では実装が日々変化する“あるべき仕様”に追従できない。その結果、投入コストに見合う価値を生み出すことが難しいことに、多くの開発現場が気付いたのである。
その結果、上述したアジャイルソフトウェア開発宣言につながることになったというわけだ。
アジャイルとは何か？
ではアジャイル、つまり「素早い、身軽な、機敏な、頭の回転が速い」とは一体何なのか？ それを知るには、
- アジャイルソフトウェア開発宣言（以下、宣言）
- アジャイル宣言の背後にある原則（以下、原則）
の2つ（以下に全文を引用）を読み解くのが最も効率的だ。
「アジャイルソフトウェア開発宣言」の引用：
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
「アジャイル宣言の背後にある原則」の引用：
私たちは以下の原則に従う:
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
これらの宣言と原則は定められてから本記事執筆時点で15年が経過しているが、決して色あせず、陳腐化もしていない。むしろ多くの人は、スクラム、XP（eXtreme Programming）といった手法に執着するあまり、原則を軽視しているとさえ感じる（※軽視についての実例は、次節「アジャイルにまつわる、よくある誤解」で述べる）。確かに、スクラム、XP、Crystalなど世にあるさまざまなアジャイル開発手法は、原則を満たすための手段ではあるが、それらの手段を使いこなしたからといって「原則を満たす」という目的を達成していることにはならない（手段と目的が逆になってしまっていることがあるのだ）。いま一度、宣言と原則を大事にしてほしい。
もし、アジャイルソフトウェア開発をしている中で、行動や判断に不安や疑問が出てきたのならば、宣言と原則を読み返すことを強くお勧めする。
アジャイルにまつわる、よくある誤解
アジャイルの登場以後、さまざまな組織や人がアジャイルを採用し、事例などを発表してきた。しかし、宣言や原則への間違った認識のためか、アジャイルにまつわる誤解は非常に多い。
ここで全ての誤解を列挙することはできないが、筆者が以前に比べて耳にする頻度が増してきた「最近よくある誤解」に絞り、以下に列挙する。
- 1「ウォーターフォール開発をしている現場ではできない」「アジャイルをやるならWeb企業」
- 2「自分たちはスクラム／XPを完璧に実践している」
1「ウォーターフォール開発をしている現場／SIerではできない」「アジャイルをやるならWeb企業」
アジャイルが登場した当初からある誤解だが、最近はアジャイルの認知度が以前よりも増したためか、再びよく耳にするようになった。
こんにちでは、ウォーターフォール開発をしている多くの現場でも継続的インテグレーション（CI： Continuous Integration）やテスト駆動開発（TDD： Test-Driven Development）を実践している。これらがウォーターフォール開発をしている現場でも実践されているのは、開発のやり方を大きく変えることなく取り込めるからである。
こういった話をすると「○○をやっていないから、それはアジャイルじゃない！」という人もいるが、アジャイルソフトウェア開発宣言では「左記のことがら（＝プロセスやツール／包括的なドキュメント／契約交渉／計画に従うこと）に価値があることを認めながらも、私たちは右記のことがら（＝個人と対話／動くソフトウェア／顧客との協調／変化への対応）により価値をおく。」と説明しており、アジャイルは「価値重視の度合い」で考えるのがよい。つまり「どちらにより価値を置いて行動するか」であって「何をしているか」で決まるものではない。
また、あるWeb企業で「スクラムを実践している」と聞いたので、その具体的な実施内容を伺ったことがあるが、そこではスクラムマスターがストーリーからタスクに分割し、そのタスクを開発チームに割り振りしている姿を目の当たりにした（※スクラムガイドにおいて、開発チームは自己組織されており、スクラムマスターは自己組織化され機能横断的なチームをコーチすると定義されている。スクラムマスターが「ストーリーからタスクに分割して開発チームへ割り振る」という状況は、本来の手法の意図が守られていないことを意味する）。このように、肩書を「スクラムマスター」のような「アジャイルソフトウェア開発手法のもの」に変えただけで行動や価値を置く対象が変わっていないのであれば、それはアジャイルではない。
他にも、それぞれのメンバーが「スクラムをしている」と言いつつ、てんでバラバラの方法で開発をしている姿も見てきた。このようにチーム内の各メンバーが、それぞれ「最良」と思う方法でバラバラにプログラミングすることは「カウボーイコーディング」と呼ばれる。カウボーイコーディングとアジャイルは全く別の概念であり、チームメンバーがそれぞれ自分勝手に無管理・無スケジュールで開発を進めている状況というのは、やはりアジャイルではない。
「なぜアジャイルが生まれたのか」「アジャイルとは何なのか」を理解せず、自身の行動も変えないで、「アジャイル開発をしている」とポジショントークのために自称するだけでは、それはアジャイルではない別の何かだ。
2自分たちはスクラム／XPを完璧に実践している
スクラムガイドに書いてあることやXPのプラクティスを全て実践できるようになると、「自分たちはスクラム／XPを完璧に実践している」と誤解しがちである。
そもそもスクラムガイド、XPのプラクティスのどちらも、登場から何度も改訂／改定されている。ある意味、アジャイルソフトウェア開発手法も“永遠のベータ版”として常にカイゼンされており、“完璧に実践”することはできない（＝ある時点の最新に追従はできても、改訂／改定された途端に完璧ではなくなる）。
また、アジャイル開発に習熟する際によく例として出される守破離では、個人のスキル（作業遂行能力）を以下のように3段階のレベルで表している。
まずは師匠に言われたこと、形を「守る」ところから修行が始まる。
その後、その形を自分と照らし合わせて研究することにより、自分に合った、より良いと思われる形をつくることにより既存の形を「破る」。
最終的には師匠の形、そして自分自身が造り出した形の上に立脚した個人は、自分自身と技についてよく理解しているため、形から自由になり、形から「離れ」て自在になることができる。
このことからスクラムガイドに書いてあることやXPのプラクティスを全て実践できる、実践しているというのは“守”の段階である。つまり「やっと一人前」ということであり、一人前になった程度では「“完璧”とは程遠い」ということがよく分かるだろう。
もし、自分たちのやっていることが“完璧”と思えたときは、原則の、
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
という部分をもう一度読むことをお勧めする。
アジャイルを組織／チームに適用する方法
ここまでアジャイルソフトウェア開発が生まれた理由や定義を説明してきた。ここからはアジャイルソフトウェア開発を実践していない組織／チームに、アジャイルソフトウェア開発を新たに適用する方法について説明する。
前述した通り、アジャイルが実践できているかは「何をしているか」ではなく「価値重視の度合い」で決まる。よってアジャイルを適用していくには、重視する価値の度合いを「プロセスやツール ＜ 個人と対話」「包括的なドキュメント ＜ 動くソフトウェア」「契約交渉 ＜ 顧客との協調」「計画に従うこと ＜ 変化への対応」に切り替えていくことが重要だ。ただし、一度に全てを適用するのではなく、できる範囲で少しずつ適用していく（＝度合いを少しずつ変えていく）のが望ましい。
また、プラクティスやそのプラクティスを推進するツールの内容（＝バージョン管理／テスト自動化／継続的インテグレーション）には、図2のように「変化に対する柔軟性・適用性」や「導入の難易度」に違い（低い～高い）があるため、図3に記載した順番で徐々に適用していくのがよいだろう。
図2と図3で示した、アジャイルソフトウェア開発を適用していく対象（＝バージョン管理／課題管理／テスト自動化／継続的インテグレーション）について、以下でもう少し詳しく説明しておこう。なお、以下で説明する内容の多くは、そのままウォーターフォール開発でも適用できるので、アジャイル開発を採用しない場合であってもぜひ参考にしてほしい。
バージョン管理
まず、適用するのはバージョン管理だ。
原則で示されている「動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。」を実現するには、コードを頻繁に変更することになる。そのため、ファイルサーバー上で手動によるコードのバージョン管理を行うだけでは不十分であり、バージョン管理システムなどのツールの使用が必要不可欠である。バージョン管理システムには、Subversionなどの集中型バージョン管理システムや、Gitなどの分散型バージョン管理システム（DVCS： Distributed Version Control System）があるので、環境やリポジトリのアクセス形態により、適切なツールを選ぶとよいだろう。
アジャイルではリリース時期が異なるバージョンや複数の機能を同時に並行開発することもあり、“ブランチ”“マージ”といった概念をメンバー全員が理解している必要がある。もし、メンバー全員の理解が十分でなければ、事前に教育や研修などで知識や技術レベルの底上げを行うとよいだろう。
課題管理
バージョン管理を適用したら、次は課題管理*1だ。
- *1 本記事の対象読者は「開発者」を想定しているため、この順番になっているが、もし、あなたがディレクションなどの「プロジェクトのマネジメント」を生業（なりわい）としているのであれば、バージョン管理より先に課題管理を適用するのもよいだろう。
動くソフトウェアを短い時間間隔でリリースできるようになると、ユーザーの利用機会が増える。そうなれば、ユーザーからの新たな要求や改善案、障害報告といった課題があがってくるようになる。それらの課題を一元管理し、課題を解決する優先順位や現在の対応状況をメンバー全員で容易に共有できなければならない。だがそのために、Excelやテキストファイルに課題を羅列し、メールやファイルサーバー経由でやりとりをすると、先祖返り（＝別のメンバーが保存した新しいファイルを、古いファイルで上書きしてしまうこと）やファイルの破損が発生する可能性が非常に高く、運用上でのボトルネックになってしまう。
そこで、これらの問題に対処するVisual Studio Team Services（VSTS）やRedmine、GitHubのIssue*2といったツールを利用するのが望ましい。これらのツールは課題ごとに「チケット」（＝ツールごとに呼び名は異なる）を発行でき、チケット1つ1つに課題の内容や期限、現在の状況を記述できる。その結果、「何の課題のために、どういった変更を加えようとしていて、今どういった状況なのか」をトレースできるようになる。
- *2 RedmineやGitHubのIssueはそれ単体では優先順位に対応していないが、RedmineではRedmine Backlogsというプラグインを、GitHubでは2016年9月15日に発表された「Projects」という機能を組み合わせると優先順位にも対応可能になる。
テスト自動化
「何の課題のために、どういった変更をコードに加えたのか」をトレースできるようになったら、次はテスト自動化だ。
すでに読者の開発現場では、リリースする前にシステム全体が正常に動作するかどうかを常に検証しているはずだ。これは原則で示されている「動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。」を実現する場合も変わりはない。
しかし、テスト手順書に従って手作業で検証していると長い時間がかかってしまう。そして、システムの規模が大きくなる、つまり、開発が進めば進むほど検証にかかる時間も増えていくため、手作業の検証では、いつか開発している時間より検証している時間が多くなる時が来る。
このような事態を防ぐために、xUnitなどと呼ばれるユニットテストツールや、SeleniumなどのWebブラウザーの操作をテストするツールを利用するのがよいだろう。
テストを自動化する際は、次のことに注意して実施すること。
- カバレッジ（＝日本語で「網羅率」）を100％にしようとしない
- ツールの適材適所を考慮して実施する
前者は、テスト自動化のためのコストが、テスト自動化によるメリットを上回る事態を避けるためだ。効果の高い箇所から取り組むのがよいだろう。
後者は、全てのテストにSeleniumを使う、といったことを避けることを意味している。Seleniumはブラウザーを実際に起動させてテストを行うため、一般的にxUnitなどのユニットテストツールよりテストに時間がかかってしまう。時間を節約するためには、複数の画面をまたぐテストはSelenium、ライブラリや内部ロジックの単体テストはxUnitと、テストツールを使い分けるのが大事である。
継続的インテグレーション
テスト自動化ができれば、次に適用するのが継続的インテグレーション（CI： Continuous Integration）だ。
1つ前の「テスト自動化」の段階では、開発者が手元でソースコードを変更した後に、「自動化されたテスト」を手動で実行していた。その手動作業をさらに自動化するために、JenkinsやCircleCI、VSTSといったCIツールを導入することで、継続的インテグレーションを適用する。CIツールを使えば、基本的に以下のような一連の作業の自動化が実現できる。
- 開発者が、バージョン管理システムにソースコードをコミット（Gitなど）／チェックイン（Subversionなど）すると
↓ - CIツールは、それをトリガーに、最新のソースコードをバージョン管理システムから取得し
↓ - ビルドツールでビルドを実行
↓ - ビルドに問題がなければ、自動化されたテストを実行し、問題の有無をCIツールユーザー（開発者など）に通知する
CIツールの導入によって、ソースコードとそれから生み出される動くソフトウェアに問題がないかどうかを常に確認し続けられるようになる（＝継続的インテグレーションの適用）。もしビルドやテストに失敗しても、どの変更がそれを引き起こしたのかが分かるため、問題箇所の特定や除去といった対応が容易だ。
継続的インテグレーションを適用する際は、次のことに注意して実施すること。
- CIはCI専用のマシンで行う
- CIのビルドやテストに失敗したら、すぐにバージョン管理を直前の状態に戻す
前者は、「特定の端末（大抵の場合、誰かのローカルマシン）でしかビルドやテストに成功しない」といったことを避けるための対応だ。
後者は、ビルドやテストに失敗している状態で、別のコミットをすると、どちらの変更に失敗の原因があるのかが特定が難しくなる状況を避けたり、常にCIでビルドやテストに失敗しない状態を維持したりするための対応だ。
これらが問題なく実践できるようになれば、スクラムやXPなどのアジャイルソフトウェア開発手法の各プラクティスを実践するのが容易になる。逆にこれらの土台ができていない状態で、スクラムやXPのプラクティスを実践しようとしてもなかなか思うようにできないものだ。一見地味に見えるかもしれないが、まずはこれらから取り組むことを強くお勧めする。
■
以上、アジャイルソフトウェア開発が生まれた理由から、アジャイルソフトウェア開発の定義を説明し、現場への適用に関するアドバイスを紹介した。アジャイルの思想をベースとして、生まれたDevOpsやALMについてさらに詳しく理解したい場合は、続けて筆者の連載「ALM Essentials」の「第1回： ALMとDevOpsとリーンスタートアップは何が違うのか？」や「DevOpsとは何か？ そのツールと組織文化、アジャイルとの違い」もぜひ一読してみてほしい。
