諸君、私はJenkinsが好きだ

諸君 私はJenkinsが好きだ

諸君 私はJenkinsが大好きだ

Email-ext pluginが好きだ
Cobertura pluginが好きだ
Maven repository server pluginが好きだ
HTML Report pluginが好きだ
Gradle pluginが好きだ
Job config history pluginが好きだ
Build pipeline pluginが好きだ

Javaアプリのビルドで
Mavenリポジトリへのdeployで
PHP Unitの実行で
Geronimoへのdeployで
バッチ処理サーバへのscpとsshで

この地上で行われる ありとあらゆるJenkinsのビルドが大好きだ

スレーブを従えたJenkinsの一斉ビルドが
轟音と共にビルドキューを吹き飛ばしていくのが好きだ
空中高く放り上げられたソースコードが
FindBugsでばらばらになった時など心がおどる

Jenkinsの操るビルド手順が
ソースコードツリーを撃破するのが好きだ
悲鳴を上げて燃えさかるリファクタリング済みソースを
JUnitとHTML report pluginが薙ぎ倒した時など
胸がすくような気持ちだった

ルールをそろえたCheckstyleの横隊が
ソースコードを蹂躙するのが好きだ
恐慌状態のプログラマーが シカトぶっこいてたeclipseの
checkstyleプラグインをあわててactiveにしている様など
感動すら覚える

SCMに乱雑にコミットされたソースコードたちを
ビルドジョブビューにつるし上げていく様などはもうたまらない
俺を先にポチってくれと泣き叫ぶビルドジョブ達が
Bulk builder pluginの振り下ろした号令とともに
次々と立ち上がるスレーブにばたばたと薙ぎ倒されるのも最高だ

哀れなプログラマー達が雑多な変更を健気にもコミットしてきたのを
Jenkinsのコミットフックビルドトリガーがchengeset番号と
コミッターのアカウント名ともにBUILD FAILUREで
つき返した時など絶頂すら覚える

後任のビルドエンジニアにJenkinsのビューを
滅茶苦茶にされるのが好きだ
必死に整理したビューが蹂躙され
無関係なビルドが追加されそこにあるはずのビルドジョブが
「すべて」にしか現れなくなる様はとても悲しいものだ

ビルド状況の雨雲の洪水に押しつぶされて殲滅されるのが好きだ
E-mail通知に追い回され 500kbを超えるコンソールログを
血眼で追うのは恥辱の極みだ

諸君 私はJenkinsを 地獄の番人の様なJenkinsを望んでいる
諸君 私に付き従う戦友諸君
君達は一体 何を望んでいる？

更なるJenkinsを望むか？
情け容赦ない 冷酷なJenkinsを望むか？
鉄風雷火の限りを尽くし 三千世界の鴉を殺す 嵐の様な執事 Jenkinsを望むか？

「Jenkins !! Jenkins !! Jenkins !!」

よろしい ならばJenkinsだ

我々は満身の力を込めて今まさにポチらんとする握り拳だ
だがこの暗い闇の底で半世紀もの間耐え続けてきた我々に
ただのビルドではもはや足りない!!

大Jenkinsを!! 一心不乱の大Jenkinsを!!

我らはわずかに一個大隊 千人に満たぬビルドチームにすぎない
だが諸君は一騎当千の古ビルド職人だと私は信仰している
ならば我らは 諸君と私で総力100万と1人の軍集団となる

我々を忘却の彼方へと追いやり 眠りこけている連中を叩き起こそう
デスマーチの葬列から引きずりだし 眼を開けさせ思い出させよう
連中に自動ビルドの味を思い出させてやる
連中にJenkinsのコンソールログの自動スクロールを思い出させてやる

プロジェクトマネージャとプログラマーのはざまには
奴らのWBSでは思いもよらない事があることを思い出させてやる

一千人のビルド職人の集団で世界のソースコードを燃やし尽くしてやる

「最後の大隊 大隊指揮官より全空中艦隊へ」
目標 法政大学 市ヶ谷キャンパス

Jenkinsユーザーカンファレンス 2012 Tokyo 状況を開始せよ

征くぞ　諸君



Inspired By 諸君 私は戦争が好きだ

HELLSING 1 (ヤングキングコミックス)

posted with amazlet at 12.07.27

平野 耕太
少年画報社

Amazon.co.jp で詳細を見る

ソフトウェア開発自動化が目指すべき姿

自動化ツールを使ったプログラミングレスなシステム開発、という流行病（はやりやまい）は数年おきに出現します。10年ほど前で言えばCASEツールがありました。もっと大昔では、シグマ計画（プププ）ではSPACEなるプログラミング自動化システムが最上位ツールの一つとされていたようです。

何らかのツールに一定の形式で要件定義情報を入力すると、アプリケーションのソースコードが完全に自動生成される、というのが、最近（昔から？）よく見かけるソフトウェア開発自動化ツールの見果てぬ夢幻です。本当にそれをやろうとすると、一定形式の要件定義情報を書くこととソースコードを書くこととの複雑さの差があっという間に埋まってしまって自動化ツールの存在が無意味化するだろうということは、きちんとしたプログラミング経験のある人間であれば誰でも本能的に察知できます。

gccやjavacのようなコンパイラがソースコードをマシン語に変換する自動化ツールであるならば、その進化形として、一定の人間語で書かれた文章と図面をソースコードに変換する自動化ツールもあってしかるべきだ、というレトリックもときどき見かけます。残念ながらそれも、中国の古い故事で言うと論理の飛躍です。ソフトウェア開発はそれほど単純なものではありません。

しかし意外にも、そうした銀の弾丸と青い鳥を探し求める傾向を、ITを使う側でではなく、IT業界の内側でちらほら見るので世の中不思議です。ITの使い方を知らないIT業界人も思いのほか存在するのです。

逆に、ITの使い方を心得たうえで自動化ツールをうまく使う企業や個人もいます。と書いてから自分のことを書くのはものすごくおこがましい（ので深くはつっこまないでほしい）ですが、私の開発したmixer2では、JDK6に標準添付されているxjcコンパイラというツールを使って自動生成したJavaソースコードを大量に使っています。XML(XHTML)という分野では非常に有効な自動生成ツールの一つだからです。

著名なプログラマの一人である小野さん率いるアプレッソ社の主力製品は、DataSpiderというデータ連携のための自動化ツールです。特定の分野において、自動化ツールを使う側ではなく自動化ツールを作る側に立ち、しかもその価値を認められて10年以上にわたり生き残っていることこそ、ITにおける自動化のなんたるかを正しく心得ている証左でしょう。ちなみに彼のブログで個人的に好きなのはバグは夜更け過ぎに仕様に変わるだろう(2007年)です。

10年ほど前、インターネットバブルに踊り莫大な赤字を垂れ流す怪しげな本屋がありました。彼らは、物理的な電子回路と仮想的な電子回路とをリアルタイムに相互変換するという不可思議なツールの価値を正しく見抜き、使い方を磨き、その結果、世界有数の先進的なITサービス企業へと変貌を遂げました。Amazon Web Serviceです。大した根拠もないピーク予想値と少ない予算という不条理のなかで、HDD容量を自動見積もりするexcelシートと向き合い納品リードタイムを気にする必要はなくなりました。ハードウェアを、いや、ミドルウェアをも、ボタン一つで増減できる自動化ツールがそこにあるからです。

10年ほど前、一人の日本の若者が渡米し、XMLというデータ形式を取り扱うコードを書きまくりました。それが現在のJava6のJAXB-APIであり、先述のxjcコンパイラもその副産物です。その道程で、彼は自らの仕事に集中するために、逆に本質的ではない煩雑で退屈な仕事を自動化するためのツールを作り上げ、親しみをこめてhudsonと名づけました。現在のJenkinsです。バックエンドデータストアとしてRDBMS等に頼らず、XMLそのものの柔軟性を最大限に生かすことによって、導入と運用のハードルの低さを実現した自動化ツールの登場です。優秀な執事たるJenkinsにビルドとテストを任せることはこの業界のデファクトとなりました。来週に迫ったJenkinsユーザ・カンファレンス2012東京（at市ヶ谷 法政大学）の参加者は1000人を超えつつあります。

ソフトウェア開発自動化が目指すべき姿とはなんでしょうか？

ここまでのように私がクドクドと書くまでもなく、先人がすばらしい示唆を残してくれています。それを紹介して、このエントリを終わりましょう。

ソフトウェアアーキテクトが知るべき97のこと オライリージャパン (2009) より クリエイティブコモンズ 表示3.0に基づく全文の転載。（太字は転載者によるものです）

煩雑なことを非属人化し、創造性を高める
萩原正義

ソフトウェア開発の完全な自動化は目指すべきではありません。

DSL（ドメイン特化言語）のスコープを十分に小さくし、生成コードの実行をWebアプリケーションの特定フレームワークに限定すれば、完全な自動化は可能となるでしょう。しかし、この自動化はDSLのスコープが限定された小さな問題領域と特定の実装技術に対してのみに有効であって、一般のソフトウェア開発が対象とする広範な問題領域、実装技術の選択肢に大して有効な解とはなりません。

それでは、問題領域を小さな部分問題に分割して、それぞれの部分問題を解くためのDSLを複数組み合わせる方法や、逆に1つのDSLのスコープを広げて汎用性を高める方法でのソフトウェア開発の完全な自動化は 可能でしょうか？

前者は分割したDSL間での依存関係や相互作用がまったく存在しない「直交化」した問題に関しては可能となるかもしれませんが、一般にはこのような単純な問題は少ないでしょう。後者は、DSLはもはや汎用開発言語の範疇になり、一般のプログラミングによる開発となんら変わりがなくなり自動化は難しくなるでしょう。

DSLやその他の開発ツール、モデル駆動型開発は、繰り返し起こる煩雑な開発を自動化することで省力化を行うためであって、ソフトウェア全体を自動化する目的で使うべきではありません。それほどソフトウェア開発は単純なものではありません。 また、問題領域あるいは解決領域のスコープ自体も、ビジネスの進化、ソフトウェア技術の進化、要求の変化によって、固定的な定義で収まるものではありませんから、ソフトウェア開発の自動化の対象領域自体の前提も成立しなくなります。進化しないソフトウェアはいずれ価値を失い、自動化の有効性はなくなるでしょう。

このように間違った目的を目指して技術を適用しようとしても失敗することは歴史が証明しています。進化するビジネスや技術、変化する要求の中で、不変の規則、原理を発見し、この規則と原理に基づき自動化するならば有効な解となるでしょう。不変の規則と原理は繰り返し現れるので、煩雑さを非属人的な 方法で省くことが可能となります。

その上で、創造性や進化が求められる部分に人間の知的作業を集中させることで、ソフトウェア開発の工業化が可能となると考えます。ソフトウェア開発の工業化を大規模な製造の自動化と考えるのはよく見られる誤りです。ソフトウェア開発での工業化は、人による創造性や知的作業と自動化の分担で実現し、その意味では、ソフトウェアは完全な工業製品というより、むしろ人の創造力を含んだ工芸品を目指しているといえなくもないでしょう。

技術と創造力を融合したソフトウェア開発の在り方は、筆者の考える「ソフトウェア工芸」の捉え方の基になっています。