米国ベイエリアレポート（第７回）Jenkinsプロジェクトとビジネス

Google, Apple, Facebook等、IT業界を牽引するグローバルカンパニーが集積するシリコンバレー。それら先進企業においても、オープンソースソフトウェアの存在は不可欠なものとなっています。

ここではシリコンバレーにおけるIT、オープンソースの動向について、紹介させて頂きます。今回は、第7回目として、Jenkinsの生みの親であり、現在もシリコンバレーで活動されている川口耕介さんにお伺いした内容をご紹介いたします。

川口耕介さんのご紹介

川口耕介さん

(過去のご経歴をご紹介いただけますか。)

東京大学を出てから、友人と小さな会社で受注開発の仕事をしていたのですが、大学の卒論のプロジェクトを趣味で継続的に続けていたところ、サン・マイクロシステムズ社 (SUN Microsystems,Inc.)が興味を持ち、仕事の誘いがあり、カリフォルニアの方へ移動してきました。最初はXMLですとか、Javaに関連する開発に携わっており、そのときに趣味で作っていたソフトウェアが今のJenkinsの元であるHudson となりました。

最初は自分だけで使っていたのですが、だんだん同僚も興味を持ち、気づいたら周り皆が使っている、と言う状況になりました。そうなると、同僚からバグ改修のリクエストが挙げられてはすぐに対応してほしい、ということになり、それが本業となっていきました。サン・マイクロシステムズ社にいる間はほぼフルタイムでの対応を認められていました。その後、サン・マイクロシステムズ社がオラクル社 (Oracle Corporation) に買収され、その後、2か月ほど、オラクル社員として勤務していたのですが、退職をきっかけにHudsonからJenkinsへと改名しました。

オラクル社では、ツール開発の部門に所属することになったのですが、オラクル社はデータベースやERP ソフトウェアなどが主力製品であり、それらのために、8,000人近くのエンジニアが雇用されています。ツール開発の部門は、彼らの生産性を上げるための部門と言う位置づけであり、内向きの作業と位置づけられ、会社の利害と私個人の欲求との間にかい離が出始めてきました。そういう背景から、Cloudbees社として、Jenkinsを用いたビジネスにフォーカスして取り組むことにしました。

(最近はどのようなことを中心に従事されているのですか？)

現在は、Cloudbees社のCTOを担当しているのですが、会社も徐々に大きくなってきて、Jenkinsの部隊のそれぞれのメンバーに作業の注文をするなど、技術面の統括を担当しています。それとは別にJenkinsプロジェクトにかかわっている部分としては、運営の他、コミュニティの中で人をつなげることをしたりですね。オープンソースのプロジェクトは、基本、個人個人がやりたいことをやる、と言うスタンスで進められますが、そのときに、複数のメンバーが共通性のある取り組みをしているとき、作業連携に向けた調整の場をアレンジをしたり、大きな取組に対しては、旗振り役およびその取り組みへのフォロワーの動きをサポートする、と言ったことが多いですね。ですので、一つのことに集中する、というよりも、ある日はマーケティング、ある日はエンジニアリング、ある日はマネジメントというように、色々な役割を同時並行で進める、ということが多いです。

Jenkins全般について

Jenkinsのロゴ

(なぜJenkinsのプロジェクトを始められたのですか。)

私の中には3つのモチベーションがありました。

私は当時、Java EEの仕様検討及び開発を担当していたのですが、200人くらいのメンバーで、複数のJavaのパートナーベンダとうまく連携をとれるような技術の標準化策定がチームのミッションでした。

そのメンバーの中には、仕様検討その道10年といったベテランも多数参加され、それはそれで興味深かったのですが、一方、そのメンバーは仕様検討のスペシャリストでも、その仕様に基づいたアプリケーション開発の経験者が居ない、と言う状況でした。自分達が策定した仕様が本当に適しているのかを評価するためにも、自分でアプリケーションを実際に作ってみたい、と言うように思うようになり、Jenkinsプロジェクトへとつながったものであり、言ってみれば、当時、作るアプリケーションは何でもよかったのです。

そして、当時Java EEの仕様策定と同時に開発も担当していたのですが、ソースコードリポジトリーにはCVSを用いており、私がチェックインする際、ファイルのチェックインもれがあっては、同僚から、私のチェックインの後、ビルドが通らなくなった、というような指摘を受けることが多々ありました。そこで、私がチェックインした瞬間にクーロンジョブのようなものが走って、ビルド結果を通知してくれるようなソフトがあれば、と考えるようになりました。よって、アプリケーションを作りたい、という背景と合わせて、ちょうど良い題材と考えて、Jenkinsの元となるソフト、Hudsonを作ることとしました。

その当時、Java EEを取り囲む状況としては、フレームワークが乱立しており、私の中にも、「こういうフレームワークがあれば便利なのではないか」、と言うアイディアがありました。そのフレームワークを形にしたいのと同時に、それを用いたアプリケーションを作ってみたい、と言う同機もありました。

よって、「こういう道具を使って何を作ろうか」という、動機に基づくところから、Jenkinsプロジェクトは開始しました。

(JenkinsはJava以外でも有益とお考えですか。)

はい、実際にJava以外の言語に利用している方もたくさんいます。

他のプロセスを起動できる、と言う作りになっているので、言ってしまえば何でもできるものになっています。たとえば、Pythonのユーザーであれば、Pythonのツールから出力されるレポートを構文解析 (Parse)するようなツールが提供されています。C/C++のユーザーも多くいらっしゃいますし、現時点ではPythonであったり、PHPで書かれたCIサーバーが存在しないため、そういう言語のユーザーは比較的Jenkinsを選ぶことが多いように思います。

一方、Rubyに関しては、Rubyで書かれたCIサーバーがいくつかあるので、Jenkins以外の選択肢もありますが、同時にその中でもJenkinsを利用している、と言う人も多くいらっしゃいます。

また、ソフトウェア開発以外でも利用されていることがあるようです。本の組版工程では、ソースコードのようにレイアウトを残すことが必要となるようで、その分野でもJenkinsを利用されることがあるようです。たとえば、レイアウトの中の文面の作成作業をToDoで管理しては進捗管理し、トラッキングできるようにする、と言うような使い方をされているということを聞きました。

また、SUNの社内での紹介にも、ハードウェアのチップの設計でも利用されると言う話を聞きました。チップのレイアウト設計も現在はソースコードのような形で定義されているようなので、それをJenkinsを用いて管理されていたとのことで、多くの領域での利用実績があります。

(ソフトウェアのデプロイメントはどのように実装されてますか。)

Jenkins としては世の中で様々なデプロイツールがあり、それを用いるプラグインも提供されているので、そういう面では望ましい状況にあると感じますが、Cloudbees としてどのようにしているか、については最近はChefを用いています。レシピを更新したタイミングで、サーバーがアプリケーションをアップデートし、再起動をさせる、そういう制御が行われる仕組みを用いています。

最近はImmutableなサーバー構築に取り組んでおり、更新が入ったらインスタンスを新しいものに差し替える、という事を行うような業界の流れがあり、私達もそういう流れを見据えて動いているところです。

(最近は、どのコンピューター言語をご利用されていますか。)

仕事では、必ずしも面白い言語が使われるわけではない、と言う状況です。Cloudbeesでも最初は、エンジニアが6人いては、6人がそれぞれ異なる言語を用いて、そうすると手が空いた人に他の業を依頼しようとしてもうまく行かなかったり、共通部品化もうまく作れなかったりと、組織としては効率が悪くなってしまう、と言う側面があります。なので、最大公約数としてバックエンドにはJava、フロントエンドにはJavascript と言う選択肢を取るようにしています。

部分的にはRubyやGroovyを用いている部分もありますが、コアの部分にはJavaを用いるようにしています。以前はScalaを用いていた部分があるのですが、引き継ぎで新しく入ってくるメンバーがScalaを使えるケースが少なく、また私がGroovyでテストコードを書いていたとき、他のメンバーがそのGroovyのコードを必死にJavaに変換してからテストを流している様子を見てからは、Groovyを使うのはもうやめようと決心しました(笑)。

(なぜ、JenkinsはGit リポジトリに対するコネクションが、標準でバンドルされていないのでしょうか。)

現在、Jenkinsユーザーの9割近くがgitを利用しており、以前もgitをバンドルさせるか、と言う議論があったのですが、ディストリビューションはできるだけ軽くした方が良い、と言う意見を持っている人もいました。そこでコアは小さくして、初回起動の際に必要なプラグインをセットアップするようなツールを作るのが良いのではないか、と言う議論になり、最初はGitのバンドルと言う話からスタートしたのですが、気づけばとても大きなプロジェクトとなってしまい、そこまで手が回っていない、と言うのが現状です。

ただ、今回のこの質問を受けて、プロジェクトの独裁権力を行使して、gitだけは特別にねじ込まないといけないのかな、とも思いました。

Jenkinsプロジェクトとビジネス

Jenkins User Groupの様子

(オープンソースのプロジェクトを成功させる上で大切とお考えになられることは何でしょうか。)

色々なオープンソースの成功プロジェクトを見ていると、必ずしも同じレシピで成功しているわけでもないように感じます。なので、やり方が一つしかない、と言うわけではないと思いますが、その上で、私の中には一つ、成功レシピと言えるものがあります。

サン・マイクロシステムズ社にいるときにJava EEのプロジェクトを進めていた頃、その当時の社長方針ですべてオープンソースでやれ、ということになっており、JavaEEの20個程度の開発グループにおいて、順次オープンソース化に取り組んでいました。その時の経験ですが、オープンソース化での課題の一つとして、後から参加する人は元の開発者と円滑なコミュニケーションが挙げられます。対象の個々のプロジェクトはJava EE と言う大きなプロジェクトの一部であることから、他プロジェクトとの互換性の確保などによる外的要因による制約がある場合があります。つまり、プロジェクトの外的要因の縛りが多数あるのですが、時として、参加者のニーズとその外的要因の縛りがうまくマッチしないことがありました。たとえば、ある人にとっては互換性にはあまり興味がなかったりしますがプロジェクトとしては考慮する必要があります。また、SUN としてはJava のリリースにおいて、スケジュールが組まれ、メンバーが新たな機能の実装に取り組みだした際にも、スケジュールを達成するためにうまく調整する必要があります。

このように、コードを中心として、直接利害関係のない人が集まってプロジェクトを進める上で、どうすればよいかが大きな課題となり、そこでの経験から上がった教訓は、プラグインによる拡張性をとる、というアプローチです。たとえばとあるロシアの開発者がある機能に興味を持った場合には、彼のモジュールとのインターフェースを用意し、彼のモジュールについては彼に裁量権を与えるというアプローチをとりました。緊密な連携と言うスタイルを取るのではなく、彼はリリーススケジュールもコーディングスタイルも、バージョンの依存関係も彼の裁量の元作業を進めることができながら、プロジェクト全体の統制をとることができ、結果うまく連携が取れたように思います。

当時の開発ツールとしては、Eclipseが主流でしたが、Eclipseはプラグインの上にプラグインを作れるような構成となっています。それをWebアプリケーションにも当てはめたという形になります。そして、どこまでがコアでどこからがプラグインなのか、使っているユーザーからは見えないようにする、と言うことを行いました。また、ある開発者が彼のアイディアの元で作ったプラグインをコアに取り込めるようにしており、つまりJenkinsのカーネルもプラグインで構成されるような構造としています。

私の成功レシピは、拡張可能でモジュラー化されたシステムにする、と言うアプローチであり、Jenkinsのカーネル部分について、必ずしも完全に綺麗なプラグインと言う構成にはしきれませんでしたが、そういう方針を採ることによってうまく連携をとれたように感じます。

(Cloudbeesにおける主な収益源は何でしょうか。)

柱としては3つあります。

一つはJenkins Enterprise by Cloudbees と言う製品があり、これはオープンソースのJenkinsに商用のプラグインを追加して提供する、というものです。アクセス制御やハイアベイラビリティなどの機能を追加しては、それらをサポートする、というものです。ミッションクリティカルな分野で、システムが落ちると開発が止まるというようなケースでの利用を想定しています。

もう一つは、大規模になると一台のJenkinsサーバーだけでなく、複数台で走らせる必要がでてきては、管理の手間が増えるというケースがあります。そこで、中央から一括で管理できるような製品を作りました。そして同時に一人が複数台のJenkinsを管理するようなオペレーションセンターも作りました。そしてビルドの所要時間などの統計情報を吸い上げて、それら情報の遷移から、「今のペースで行けば、来年のこの時期にはマシーンを増設させる必要がある」、というようなアドバイスにもつながってくるかと期待しています。

三つ目はCloud上にホストしたJenkinsを小さい企業向けに提供するというものです。基本的にはJenkinsのホスティングサービスであり、ユーザーの方でAmazon AWSやHerokuなどにデプロイするといった使い方が考えられ、用途はユーザーの方で決めてもらうと言うスタンスをとっています。Jenkinsの運用管理業務のアウトソーシングと言えるかもしれません。

(Jenkinsに関連して興味を持たれたビジネスはございますか。)

ドイツのBMWの本社に行く機会があったのですが、彼らは車の開発はもはやソフトウェア開発、すなわち、車の中にバスがあり、その中に多数のマイコンのチップが取り付けられてそのソフトウェアを書くのが仕事と話されていました。その中でチップ間の通信のための標準プロトコルがあり、それら通信のためのコミュニケーションスタックを担当するチップであったり、ヘッドライトの制御にはそれ専用のチップが用いられるなど、様々なマイクロコントローラーが用いられているようです。そしてそれらの設計として、マイクロコントローラーをリソースの制約の元、共通化する、しないを検討しては設計情報に落とし込んでいくということが、設計工程で行われるようで、それらハードウェアの設計情報を変更した際に、Jenkinsにて必要とされるテストケースを自動生成させては、実行し、その結果をフィードバックする、と言うそういう用いられ方がされているようです。

あとは、ネットビジネスとして、Netflixがそうですが、一つのスタックの上でたくさんのプロダクトを作る、と言うケースがあるかと思います。その際、プロダクト開発の方法論を横展開させるために、個々のプロジェクトごとに必要なタスクをJenkinsのジョブから自動生成させるような使われ方もあるようです。

他にはWebカメラで取得された画像を比較して、大きな変化があったらJenkinsでアラートを上げるというような話も伺ったことがありますね。

(現在のJenkinsプロジェクトにおいて、必要とされていることとしては何が挙げられますか。)

今はImmutableなサーバー構築について注目しています。

Jenkinsの次のステップとしては継続的デリバリーについて考えています。継続的インテグレーションでは、ビルドとテストの連携がフォーカスされますが、ビルド、テストからさらに、ソフトウェアをデプロイし、スモークテスト、環境切り替えまでが自動化する、といった流れを継続的デリバリーと呼ばれます。そして、継続的デリバリーが実現されたとき、様々なメトリクスが取得されることになり、たとえば、コードができてからリリースされるまでのリードタイプなども取得されるようになりますが、3日かかっているリードタイムを2日にするにはどうすればよいのか、と言う議論において、各ステップの時間を調べ、どこそこの時間を短縮化させる必要があると言ったコンサルティングサービスにつなげていくことができると考えています。

そうするとビジネスサイドの人に訴求できるようになると思います。たとえばビルドの自動化、と言う話は社長が心配することではないですが、ソフトウェアリリースのリードタイムということになると、ビジネスサイドのイシューになってくるため、継続的インテグレーションとは区別して、継続的デリバリーという用語が用いられています。

最後に

(次のステップとしてはどのようなことを計画されていますか。)

私にとってはこのJenkinsプロジェクトは子供みたいなものなので、最初は趣味のプロジェクトとして始まったモノが、いつの間にか本業になり、今や10万のインストレーションがあり、ユーザーベースも数百万人くらいになっているかと思います。プロジェクト的には面白い状況になってきているので、しばらくはこちらに全力を注いで、将来どうなるのかを見てみたい、子供がどうなるのかを見てみたい、というのがありますね。

ただ、内の会社もベンチャーとして投資を受けて進めているので、どこかのタイミングで、乗るかそるか、と言う話になるかとは思います。なので子供も20歳を超えたときに結婚して、自分の手を離れる、と言うことになるのと同様、このプロジェクトもどこかのタイミングで自分の手を離れることになるかもしれませんが、そこまでは続けたいと思います。

(ソフトウェアエンジニアにお薦めの本はありますか。)

最近、あまり本を読まないので、ちょっと古い本になるのですが、ジェラルド・M・ワインバーグのプログラミングの心理学が面白かったですね。1970、80年代に書かれた本なのですが、ソフトウェアを書くという人間的なプロセスをどうしたらうまく行くのか、どういうところから生産性の差が生まれているのか、と言うことをエピソードを交えて述べられた本です。

たとえば、言語の設計でFortranは空白を無視する、と言う設計方針となっていますが、こういう風に設計すると、こういうところで躓く、といったエピソードが記されていて、印象に残っています。

扱っている言語はFortranなど、とても古いもので、今の人はあまり知らないと思うのですが、そこで述べられているプログラマの心理学については、今でも驚くほど共通しており、そういうものは時代を超えて価値があるといえるのかもしれません。

(本日はご協力ありがとうございました。)