CIの変遷について
西村：アジャイルアカデミーは、企業にもっとアジャイル開発が根付いてほしいという考えのもと設立され、5つの講座で構成されています。企業でアジャイル開発を取り入れるための入り口として、技術系であるライトウィングの講座にTDDとJenkinsを、レフトウィングとしてチームとしての活動であるScrumと見積りを、その両翼を司るプロダクトオーナーシップとして製品開発を設けています（下図参照）。どの分野から取り入れるかというのは企業によってさまざまですが、特徴的なのは「本当に必要だと思われる講座構成と、実践経験が豊富な講師陣で、アジャイル開発をしていく上で必要な軸を作る」という部分です。
西村：では、Jenkinsの講座の前に、まずCIの位置づけ的なところを教えてもらえますか？
太田：元々はXPのプラクティスに含まれていて、その中でCIは必須の活動と言われていました。チームで話しながら開発するとか、みんなで見積りしたりと同じような意味でテストコードを書くことやCIも同時に語られていたものです。今はそれぞれがバラバラに語られることも多いのですが、元々はひとかたまりのものだと認識しています。
西村：第一次というか、昔CI周りではCruiseControlが先進的なアジャイル開発者の間で使われていた時期がありますよね。
和田：元々CIがはじまった時代というのは、本が考え方を主導していた時代です。マーチン・ファウラーやケント・ベックが、考え方に名前をつけることによって、はじめて概念として認識されたといえます。CIが、先ほど太田さんがいっていたXPのプラクティスの中に入って「ああ、そういうものがあるんだ」と皆が認識した。
そこから「実際どうやるのか。定期的にシェルでもたたくのか。CIを実行するためのソフトウェアがあって、それを使ってやるやり方もある」など関心が実務に向かっていくんですね。
CIは「地続き」になっています。自分たちで書いたシェルを定期的に手で動かすところから、専用のソフトウェアがあってサイクルがグルグル回るところまで、なだらかな地続きになっている。
CI専用のソフトウェアがあって、自分たちでシェルなどをゴリゴリ書かなくても専用ソフトをポンと入れると、まぁまぁのところ、五合目からスタートできる、というような触れ込みで最初に流行り始めたのが、CruiseControlです。
その後、もっとセットアップなどが簡単なものがないかということで出て来たのがHudsonでした。
太田：日本ではHudson（後にJenkins）が劇的にセットアップが容易なことと、Jenkinsの開発者川口さんが日本人だったことが大きいです。CruiseControlに比べて、Javaで開発するのがエンタープライズ系の人にも導入しやすかったのでしょう。そこで劇的に『キャズムを超えた』という感がありますね。
Jenkinsが出てきて、CIという概念が普通に技術者の中に浸透した感じがします。私自身も仕事で別のCIサーバーであるApache Continuumを使っていましたが、Jenkinsほど垣根が低くなかったですね。
Jenkinsは、確かに本当にセットアップが簡単だし、とりあえず乗せることで50％がすぐできるというのは劇的でした。
