CIの導入ポイント、そしてJenkins講座が生まれた背景について
西村：Jenkinsではいろんなプラグインも提供されているので、いろんなことができますよね。では、実際にCIを導入することによって、開発の現場はどう変わると言えますか？
太田：理想論としては、ビルドに関わるタスクがすべて自動化される、です。しかし、実際にはまず自動化できるルーチンワークを最小限CIに載せることによって開発の時間に余裕ができることが一番です。
西村：導入する際に困ることとはなんでしょう？
太田：一番は、概念は分かったけれど具体的にどうやっていいか分からないという点。インストールだけは5分もかからずにできますが、いざそれを回すというのが難しい。だから導入にあたっては、組織の成熟度に合わせて段階的に取り入れるというやり方が良いと思うのですが、その中でも個人的には、CIと自動テストを同時にやるのが一番効果が高いと思っています。テストは、プロセス改善を伴う導入と、プロセス改善を伴わなくても最小限のものでできるものと2つありますが、例えばビルドやデプロイは実はどの組織でも半自動化していることが多い。それをCIに乗せるだけでまず負担が下がる。まずそこから初めていくのが一番いいと思っています。皆が実はすでにやっていて、微妙に半自動となっているものを、全自動化してあげる。
最終的にテストそのものはチームを巻き込まなければいけないけれど、その前に「CIってなんで嬉しいの？」ということを皆で共有して理解してもらうのがいいと思います。
例えばAndroidやiOSのインストール・パッケージを作るということは、単純にパッケージングするわけではない。
複雑なミドルウェアを組み合わせて作成したり、同時にJavadocを作ったりなど、非定型でかつ間違えると半日が1日になってしまう作業をCIの上に乗せてあげるというのが、一番チームにとって「あ、CI嬉しいよね」ということになる。皆の負担をちょっと減らすことによって、「あ、CIはいいな、この上で何かできないか」という風にチームがCIのことを知ってくれることにつながるわけです。
和田：TDD講座でもやっているテストは1人で書くこともできますが、CI前提でテストを書く場合はみんなで書かないと効果が薄いんですね。
太田：でも、そこに到達する前にCIが頓挫してしまうと、「CIってなんなんだ」ということになりかねない。なので、まず大きく思考転換しなくて済む、チームに余裕を生み出すことのできるタスクやプロセスをCI上でやっていくのがいい。
「Jenkins Boot Camp Premium」の講座では、デプロイやコンパイルなどの静的解析も入れていますが、それは「自動テストも重要だけれども自動テストを書かなくてもできること、自動化できることがたくさんあるよ」というところからやった方がいい、という考え方が背景にあります。
和田：CIのうまみのある部分はさまざまですが「まず入れてみることができる」というのが大きいですね。例えばCIを入れましょうとなったときに、「うちはまだ自動化されたテストがないし、うちの言語はコンパイル不要だから入れる意味あるの？」という質問があったりしますが、どんな言語にも大体静的解析機能があるので、今のままで入れてもCIは機能する部分があるんです。テスト駆動開発は、個人としてコードを書くやり方として結果的に個人で完結しています。ただ、それをチームで導入しようとなると、プロセスそのものになんらかの改革が必要になって1人目から2人目へ仲間を増やす難しさがある。以前私が以前アジャイルアカデミーのインタビューで「講座に2人で来てください」と言ったのも、それは1人から2人へはものすごく負荷がかかるからです。最初から2人で来て、2人から始めれば、だいぶ楽になります。
私はよく講演でソフトウェア開発の技術的な3本柱として、『バージョン管理』『テスティング』『自動化』を挙げています。そして導入の順番は、バージョン管理からが良いと言っているのですが、実はバージョン管理やテスティングは周りの人の理解を得ないと正しい意味では使えないんです。
でも、自動化だけは後だしにできる。『事前に許可を得るより、あとで許してもらうほうが楽（It is better to seek forgiveness than to ask for permission.）』という言葉があるんですが、要するに、「やっておきましたので見ておいてください」と唯一言えるのが自動化だと思っています。ある知り合いの例では、チームにアジャイルの文化を入れる際にまずどこから着手したかというと、自分のノートパソコンにJenkinsを入れてチームのビルドを自分のパソコン上で自動化し、完全に自動化できた時点で上司に見せて「もうこうなっているからこれだけ時間が短縮できる」と説明したというエピソードがあります。
「Jenkins入れようと思うんですけど」と許可を求めるのではなくて、もうできましたので、見てみてください、と言えるのがCIですね。1人でゲリラ的に始めて結果を出せる（笑）。
西村：Scrumはそれはないからね（笑）。
太田：一応チーム展開のノウハウも講座の中ではお話ししていますが、段階ごとに最初は個人でやっていくのがおすすめの方法です。講座のレベル感としても、仮に「Jenkinsやって」と急に投げられたとしてもローカルPCで最低限の自動化ができることを講座のゴールとして仮定しています。ビルドパイプラインまで1日できること。最終的にはビルドプロモーションまでを目指すというか。
単体テストが合格して静的解析が一定の基準までいったら初めてマニュアルテスト環境にあげますとか、単体テストが終わってインテグレーションテストのSeleniumの自動GUIテストまで完了したら今度マニュアルテスト環境に上げますよ、というのがビルドプロモーションなのですが、今まではそれを半自動とはいえ、いちいち人が個々の段階でチェックして行っていた。それを完全自動にするとマネージャーも開発の人の負担も軽くなる。その概念は講座でビルドプロモーションとしてこういうことが楽になるよ、ということで伝えています。
西村：今まで人手で行っていた単純な作業を、CIの導入である程度まで自力で自動化できるということですね。さらに講座の中では、受講したみなさんの現場の事情にあわせて、自分たちでどこを人手で行う単純作業から自動化するのかという勘所まで分かるという理解で良いでしょうか？
太田：そうですね。私の経験上、最初は自動化されたことに「おおっ！」と思うんですけど、そのうちもっとここを自動化したいという要望が出てきて、それが具体的に出来上がっていく。そういう形でチームのみんながJenkinsを使えるようなプラットフォームになっていくというのがいいかなと思っています。講座としては、受講することでチーム内のインフルエンサーを目指してもらう狙いがあるのですが、できればそれが組織に広がっていって普通になんでもCIにしていくというのがいい。
これは私の個人的な見解ですが、なるべくしなくてもよい繰り返し作業は減らして機械にまかせ、そのぶん他のことに時間を使うべきかなと思っています。私なんか3回くらいマニュアルのデプロイで発狂しそうになったら、「まず自動化できないかな」と自動化してしまいますね（笑）。
西村：受講したことで、「この作業はJenkinsを使って自動化できるぞ！」と手を動かしたくなるような。
太田：講座で体験してもらいますが、考え方の根底は他の製品にも共通するところなので。組み込み系の受講生も多いのですが、例えば他の製品を使って名前や使い方が違うとししても「プロモーションをしたい」とか何をしたいとかいうのは共通なので、基本的に受講して持ち帰ってもらって、自分たちの製品でできると思っています。
