深圳

僕はアジアの猥雑な雰囲気が大好きである。

昨日は、深圳の空港に着くなり、ここに住んでいる中国人の友達が夕飯に連れていってやるというので、お言葉に甘えることにした。

彼の運転する車に乗っていると、突然バケツをひっくり返したような大雨になり、道路は見る間に池になってゆく。翌日のニュースによれば7人死んで4人が行方不明というのだから、我が人生で一番の大雨と言うのに何の誇張もない。そんな中でも、彼は動ずる訳でもなく「車が洗う手間が省けてよかった」とか何とか言いながら豪雨で何も見えない夜道を突き進んでいく。僕は猥雑なアジアも好きだが猥雑な友人も好きである。

食べ物屋の集まる地区の一本裏手の路地に車を停め、川と化した道を走ってお店に駆け込むと、期待通りの「中国の赤提灯」とでもいうべき趣のところであった。自分だけではとても来ることはなかったであろう。しかも、折からの突発豪雨でそこら中の屋根が雨漏り、というよりか天井に幾つも水道の蛇口がついたみたいになっており、ドラム缶サイズのバケツが下に置かれて水を受けている。そこら中のテーブルや床に水溜りができ、中庭は雨水が溜まってプールの有様で、このまま雨が続いたら店ごと水没するのは必定と思われた。

しかし、そんな中でも、厨房からはいい匂いがし、店員はテーブルの合間を縫って忙しげに食べ物を運び、人々は串に刺さった何かの肉を喰い、ビールを飲み、大声で手を振り回して何かを語り合い、あるいはもう飲みすぎたのか机に突っ伏しているのである。一体この空間は何なのか。明日地球に隕石が落ちて人類が滅びることになっていたとしても、ここはこのままなんじゃないのか。

僕はこの豪雨で大概動揺していて、ここで人生が終わったら悔いはないか？などと考えていたのだが、この様子をみてすっかり馬鹿らしくなってしまい、同じ最期を迎えるのなら、せめて美味しいものとビールに囲まれてと思い直して夕飯をいただくことにした。辛くてビールもすすみ、大変美味しくて、それで一人頭1000円にもならなかった。

全くもって忘れられない夜になってしまった。これだからアジアはやめられない

Continuous Delivery Foundationが発足しました

既に幾つかのニュースサイトでは記事が上がっていますが、今週、Linux Foundationの傘下で、CloudBees, Google, Netflixなどをはじめとする幾つかの会社や、Jenkins, Jenkins X, Spinnaker, Tektonの４つのプロジェクトが、「Continuous Delivery Foundation」という新しい財団を発足させました。

• CI/CDの世界を標準化？　新たに発足した組織「Continuous Delivery Foundation」とは (@IT)
• Linux Foundationが、継続的デリバリーの協業を促進する新ファウンデーションを発表 (時事ドットコムニュース)
• JenkinsやSpinnakerなどの開発をホストする「Continuous Delivery Foundation」発足。CI/CDの普及とエコシステムの発展を促進 (Publickey)
• Linux Foundationが、継続的デリバリーの協業を促進する新ファウンデーションを発表  (産経ニュース)

CDFの発足は僕にとっても大きな仕事で、これからもこの組織を育てる仕事に色々関わっていくつもりです。なので、その立場から、このニュースを解説したいと思います。

まず、開発者向けツール業界で起こっている大きな流れの一つとして、コモディティ化と合併・大型化というのがあります。Amazon, Microsoft, Googleの三巨人がパブリック・クラウド市場の覇権を掛けて血みどろの殴り合いをする中で、中小ISVは足元で踏み潰されるネズミのような様相を呈しているのです。というのも、三巨人が付加サービスを実質コストのみで提供してしまうので、中小ISVのサービスが単独のビジネスとして大きく成長する絵が描けなくなっているのです。

CI/CD関連では、CodeShipがCloudBeesに買収され、ShippableがJFrogに買収され、また直近ではTravisがIderaという誰も知らない会社に叩き売りされたのは記憶に新しいところです。

Jenkinsはサービスではなくオープンソース・プロジェクトなので三巨人には踏み潰されずに済んでいるのですが、一方でオープンソース陣営には別の問題があります。オープンソースの開発者向けツールには単独ベンダ主導のものが多く、それぞれが分断されています。

また、ユーザー企業のほとんどは複数のツールを連携させて開発プロセスを構築しているのに、その連携・統合の部分を引き受けるコミュニティが存在しないので、様々な会社で車輪が再発明されてしまっているのです。

CDFは、このように分断されたプロジェクトを横断した「傘」を作ることで、これらのプロジェクト間の結びつきを強め、またユーザー企業同士がより広範に協力し合うことを可能にします。HSBC, CapitalOne, Netflixといったユーザー企業が創立メンバーとして加わっているのも、このような視点を評価してくれたからだと思っています。

次に、世の中の別な大きな流れとして、「Software is eating the world」という言葉に象徴されるように、様々な業種でソフトウェアの占める役割がどんどん重要になっています。仕事柄色々な会社にお邪魔してソフトウェア開発に取り組まれている現場の人たちの悩みを聞くことが多いのですが、技術に詳しい現場の人達はDevOps,CDといった取り組みの重要性をみんなきちんと理解しているのに、会社のヒト・カネ・モノを巻き込めず、組織として取り組めていないのが現状です。

これには色々な理由があると思いますが、一つは、CDが技術の取り組みとして技術者のコミュニティで主に話されていて、ビジネスへのインパクトとして経営者のコミュニティで話されていないからです。

CDFは、ベンダやプロジェクトを横断して、CDを技術として説明するだけでなく、ビジネスの人達に通じる言葉で発信する機会になると思っています。組織を動かしている人達に理解され、その成功事例が蓄積されることによって風向きが変われば、こういった取り組みを現場で進めている人達にとって大きな追い風を作ることができます。

まだCDFは生まれたばかりなので、全てはこれからですが、こういった趣旨に賛同してくれる仲間の方がいれば、ぜひ一緒に力を合わせましょう！

9歳の息子が将来wikipediaに載りたいらしい

増田にこういうのを見つけました。

子供が大きくなるにつれて、こういう会話を流さずに、きちんと子供と向き合う機会にしたいと思うようになりました。でも、子供が９歳の頃は僕の親としての人間力が足りず、この質問に向き合うことはできなかったと思います。なので、この増田に真面目に向き合っている人がいないようで、少し残念に思いました。

僕の人間力のさらなる向上への素振りも兼ねて、ちょっと真面目に答えたいです。

僕が一番最初にやりたいのは、どうしてWikipediaに載りたいと思うのか、そこを一緒に掘り下げてあげることです。９歳だと子供は多分わかっていないと思いますが、有名になりたい、自慢したい、というような自分を中心にした視点からスタートしているのではないかと思います。そこから、世の中にインパクトのある何事かを成し遂げて、それが人に評価されることが自己満足・自己実現に繋がるんだという他人を中心にした視点を一緒に考えたいです。

そうすると、「Wikipediaに載るにはどうしたらいいか」という問題設定が「世の中で何かを成し遂げるにはどうしたらいいか」という問題設定に変わります。

世の中で何かを成し遂げるのは本当に難しい。僕もちょっとは人に知られる仕事をしたと思いますが、事を成したかと聞かれればまだまだと言わざるを得ません。でも、一つ言いたいのは、自分が情熱を感じる何かを見つけて、ひたすら打ち込まないといけないということです。先の何かに繋がるかはわからないから誰しも怖い気持ちもあるけれども、それに負けて低きに流れてはいけない。志を持たなくてはいけない。その一方で、道は唯一つではないということも教えてあげたい。皆さんも、大人ならばこういう話になればそれなりの一家言あるでしょう。

でも、子供に何か感じ取れるように言うにはどうしたらいいのか。僕は毎回、手探りです。うちの子供はあまり自分の気持をさっと口に出来るタイプじゃないので、僕の投げているボールが何かに掠っているのかはすぐにはわからない。何かに掠っていると信じて投げ続けるのですが、僕はどうやって投げ方を改善したらいいのか。

皆さんは、こういう質問を契機にして子供とどういう風に向き合うのか、ぜひ御意見を伺いたいです。

Jenkinsユーザ・カンファレンス東京をやります

Jenkinsプロジェクトでは世界のあちこちで様々なグループの力を借りて大型イベントを開催しています。今年は、San Francisco, Nice, Paris, Tel Aviv, 上海, 北京, 深圳に加えて、日本Jenkinsユーザー会の皆さんの力をお借りして、三年ぶりに東京でも開催できる事になりました。僕も発表させてもらうのですが、皆さんにお会いするのを今からとても楽しみにしています。

Jenkinsは、2004年から始めたのでもうすぐ15年に届く長寿プロジェクトになりました。Gartnerのハイプ曲線的にいうと成熟期に入って、昔ほど耳目を集めることはなくなった気もしますが、その分インストールベースは着々と成長をつづけ、より広く浸透して世の中を様々なソフトウェア開発の現場を広く支える存在になったと思っています。

そんなJenkinsですが、実は2018年は未だかつてない興奮にみちた一年を迎えています。というのも、色々な面白いプロジェクトが目白押しだからです。

• たゆまぬ前進を続けるパイプライン機能とユーザーインターフェースの革新(Blue Oceanプロジェクト)
• Jenkinsの設定自体に継続的デリバリが適用できるようにするConfiguration as Code
• Jenkinsを手動アップデート不要のアプライアンスにするJenkins Evergreen
• クラウド環境を活用してスケーラビリティや障害耐性を格段に向上させるCloud Native Jenkins
• Kubernetesをターゲットにしたマイクロサービス・ウェブアプリ開発を超絶簡単にするJenkins X

ぜひこれらの革新を皆さんにも知ってもらいたくて、Jenkinsユーザ・カンファレンスでは時間の許す限り僕はこの話をする予定です。またJenkins Xチームのリーダーの一人であるJames Rawlingsも来日してくれることになっています。

そういえば、最近Jenkinsってどうなっているのかあんまり聞いていないな、と思いませんか？３年前と同じ使い方しかしていないな、と思いませんか？

ぜひ、今月23日のJenkinsユーザ・カンファレンス東京に参加して下さい。今までとはひと味違う、本物のJenkinsをお見せしますよ！

名古屋でソフトウェアを開発しているチームに会いたい！

4/18の午前中名古屋で暇しています。この機会を利用して、名古屋でソフトウェアを開発しているチームを訪問したいと思っています。どういったソフトウェアをどういう開発プロセスで作っていて、どういう悩みがあるのかというお話をできたらいいと思っています。Jenkinsユーザーか否かは問いません。大企業でも中小企業でも構いません。この知見がJenkinsの今後の開発に活きるので、我をと思う方はぜひ！

[cloudbees][jenkins] CloudBeesは日本で技術者を募集しています

趣味の日曜プロジェクトとして始めたJenkinsも、もう10年を超え、世界で10万件以上のインストールベースと40万台規模のビルドクラスタを誇る巨大なプロジェクトになりました。今でもまだ年率約30%の成長を続けており、これも全て、日本を始め世界のユーザー＆開発者コミュニティのおかげです。

CloudBeesでは、2010年頃からJenkins関連の製品・サービス・サポートを提供する会社で働いています。僕自身は、CTOという肩書で、Jenkinsの普及を後押ししたり大きな企業での導入を手伝ったりと、色々な事をやっています。

おかげさまで会社の中の人の名前が全員覚えられないくらいの規模に成長し、主に北米とヨーロッパを中心にビジネスを展開しています。昨年度は前年比売上が約３倍となり、２５億円の資金調達もしました。技術部門も、世界中の優秀な人をほとんど場所を問わずに雇っており、アメリカは勿論のことスウェーデン、アイルランド、イギリス、ドイツ、フランス、ロシア、ハンガリー、オーストラリア、ニュージーランドなどCloudBees技術部に日の沈む時なしという勢いです。

そんな中で唯一心残りだったのは、日本のエンジニアを雇う体制が整っていないことだったのですが、今度2016年に向けて新しいプロジェクトを立ち上げるにあたって、遂にこの「バグ」を修正しました。ようやっと、これで日本の技術者が如何に優秀かというのを世界に見せつけることができます。

そこで！！

CloudBeesでは、以下の２つの職種で、世界を股にかけて活躍したい日本の技術者を募集しています。我こそはという方はぜひ僕宛(kk at kohsuke dot org)にメールを送ってください。

英語でのコミュニケーションはどちらも必須ですが、あまり自信がないという方も多いかなと思います。僕もサポートしますし、入社後に勉強してもらえる気さえあれば何とかなると思うので、あまり悩まないで挑戦してみてください。

シニアJenkinsエンジニア

技術部に所属して開発にあたります。

職責

• Jenkinsのコア、プラグイン、及び関連システムの設計、開発、運用します
• Product managersと協力してアイディアを動くソフトウェアにします
• 大きな機能エリアを管掌し、アーキテクチャから実装までの全工程を主体的に遂行します
• Jenkinsプロジェクトにも関与してバグ修正や機能追加をします
• サポートチームが難しい問題を解決するのに協力します

応募要件

• Javaの開発に関する知識と経験
• Jenkinsのコアやプラグインに関する知識
• 高い問題解決能力と英語でのコミュニケーションスキル

ソリューション・アーキテクト

営業部に所属してパートナー会社や営業の人と協力して、お客様の問題をCloudBeesの製品を使って解決する技術的なアドバイスや提案をします。技術に関する造詣も必要ですが、営業にフォーカスした仕事のため、コミュニケーション能力が重視され、クオータもあり、会社の業績に直結する花型の仕事です。

職責

• 営業、サポート、技術者などとお客様の間の仲介をします
• 営業の人がお客様と電話やメールのやりとりをするのに協力します
• 弊社の製品をよく理解し、訴求点や競合製品との違いをよく理解します
• 製品のデモをします

応募要件

• ソフトウェア開発、継続的インテグレーション、DevOps等技術に関する一定の知識
• お客様の要件・環境を理解して製品の機能と結びつけ、売上につなげる力
• コミュニケーションスキル（英語も含む）
• 東京近郊在住

なぜCloudBeesなのか？

お堅い大企業で働くよりも、シリコンバレーのスタートアップの方が個人の能力を活かせ、短期間に圧倒的に面白い経験が出来ます。日本にもスタートアップはありますが、世界で活躍している企業は本当に稀です。CloudBeesはその点「本場」の会社です。

また、世界中の粒選りの優秀な技術者と（バーチャルに）机を並べて作業できます。彼らとの仕事を通じて得られる多くの経験と、自分の技術力が世界で通用するという自信はかけがえのないものです。

それでいて、日本全国津々浦々、場所を問わず自宅で仕事することが出来ます。時間も自由が効き、気が向いたらぷいっと映画を見に行ったりできます。

[book] コーディングを支える技術

「コーディングを支える技術」という本を読みました。著者の西尾さんは、未踏ソフトウェアの関連でお会いしたことがあって、また、ブログにもいつも面白いことが書かれています。

この本も実に西尾さんならでは、という感じです。プログラミング言語そのものにこれだけの興味を持って、色々な言語に関する知識を貪欲に吸収し、そして一冊の本を書いてしまうというのは中々普通の人にはできないと思います。脱帽です。

この本はプログラミングの初級者よりも、多分中級者向けに書かれた本なのでしょう。プログラミングを最初に覚える時は、多分みんな写経（本書のキーワードの一つです）から始めることでしょう。とりあえず決まり事は深く考えずに受け入れて先に進み、知識と知識が繋がって密な知識のネットワークができてからようやっと決まり事の意味を立ち返って理解を深めることができるわけですから。制御構造にしろ型にしろ、プログラミング言語の基本となる概念というのは、ある程度自分で使ってみないとまずは始まらないものです。

そう割りきって、ぜひ西尾さんには初級者向けの説明は割愛して、本は薄くてもいいので内容を濃くした本を書いて欲しかった、と個人的には思うのですが、やはり書籍という媒体だとあんまりニッチすぎる内容はできないのかな...。

コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)

さて、この本の帯には、色々な言語を比較するとか、言語に共通の知識を身につけるとか、そういう風に書かれています。でも、僕はそういった視点はこの本の本質を捉えていないように思います。

というのも、仕事でプログラミングをしている人達の間では、言語の選択の自由は限られているでしょうし、言語の技術的な仕様というのはその決定に際しての要素の一つに過ぎないからです。そして、よくできた概念というのはその成り立ちを学ばなくても理解できるものです。ちょうどアラビア数字の記法を覚えるためにローマ数字を覚える必要がないように。

じゃあ、僕に言わせればこの本は断然何が面白いかというと、普段は当然だと思って気にも留めていない事が実は全然当たり前じゃなかったとわかる、という足元に穴が開く感を体験するところです。その点、第七章の名前の話なんかは白眉です。だって変数に名前をつけるとか、みんな当然だと思っているでしょう。

日常を構成するものを分解して再構築するという体験が面白いのは、海外暮らしが面白いのにも共通するところがありますよね。食器をつかってご飯を食べるのは全然当たり前じゃない！とか。

プログラミングに話をもどすと、僕にとって一番「当たり前のことが実は当たり前でなかった」体験は、なんといってもメモリモデルです。僕はアセンブラ→C++と進んだので、僕にとってはメモリというものは０から順番に番号が振ってあって、その番地を使ってMOV AX,[BX+3]などとアクセスするものだったわけです。ハードウェアの仕組みといいCPUの仕組みといい、メモリに番地が振ってあるのは天地開闢以来の当然の決まり事だと思っていました。

ところが、Javaを学んでみると、メモリに番地がある、という決まり事はどこかにいってしまい、それどころか番地を数字として取り扱ったり任意の番地のメモリにアクセスする機能は存在しないわけです。そして、この単純な機能を取り除くことによって、アクセス制御だのバッファオーバーフローの阻止だの、プログラミング環境としてとても優れた幾つかの性質を得ることができます。当時の僕にとってはそれなりの「発見」でした。

大人になってからはこういった「発見」に感動する機会は減りましたが、こういう「発見」を面白いと思う人はぜひ本屋さんでチラ見してみたらいいと思います。