「鯖缶」を作っていた学生が、さくらの「サバ管」に？

私は、いまから9年前にさくらインターネットに入社しました。実は、学生の頃はITとは関係の無い、水産食品科だったんです。「サバ管（サーバ管理者）」になる前には、鯖缶を作っていたとよくネタにされています（笑）。

当時は、自分がIT系のエンジニアになるなんて夢にも思っていませんでした。けれど卒業してしばらく経って、独学でインターネットの可能性に触れて。ADSLの時代にPCを買って、C言語のプログラムを書いていました。

入社後は、データセンターの運用スタッフから始めて、今では新規事業の「Arukas（アルカス）」の企画、開発から運用まで、何でも担当しています。

開発体制に合わせ、GitHub Enterpriseを全社導入

弊社はやはりインフラの会社なので、エンジニアの中でも、インフラの担当が9割ほどです。従って、「インフラエンジニアが頑張ってコードを書く」ようなことも多くあります。

昔は毎日のように、命を削りながら黙々とインフラのチューニングをしているエンジニアが多かった印象ですが（笑）。最近では、エンジニアも大幅に増員されて、とても賑やかになってきましたね。

管理コンソールを作るような、Web系のエンジニアも増えているので、開発体制にも変化が出てきています。その中で、1年ほど前にGitHub Enterpriseを全社導入しました。

それ以前は、GitLabを使っていたり、一部だけGitHub.comを使っている状態でした。ですが、デザイナーや他の職種の人たちにも広めていくためには、やはり操作しやすいGitHubが良い。そしてそれを全社的に統一するために、エンタープライズ版を導入したいという思いがありまして。

特に弊社は、東京と大阪に拠点があって、物理的に分断されているので。GitHubを全員が使っていれば、開発のやり取りもしやすくなりますし、出張先でコードを書きながらPull Requestを送ることもできます。

GitHub Enterpriseは、文字通りエンタープライズ級な価格です。200人分のライセンスを用意したとしても、年間600万程度、エンジニア1人分くらいの人件費ですよね。そう考えると、コストも安いと思います。

デザイナーから、情シスまでもGitHubを使うように

今では、デザイナーや、ネットワーク系のエンジニアもGitHubを使うようになりました。他にも、情報システム室の人が、基幹システム系のコードを管理するためにも使っています。

面白いところで言うと、私のチームでは求人票もGitHubでバージョン管理しています。私が求人票を書いて、開発メンバー全員にPull Requestで見せて、確認を取っているんです（笑）。

▼GitHub上で求人票を管理

GitHubは、もはやデファクトスタンダードなコード管理プラットフォームなので、その共通のやり方で開発に取り組めることは非常に大きいですね。

会社としても、OSS利用者に支持されているGitHubというプロジェクトにお金を払うこと自体が社会貢献になりますし、互いにWin-Winな関係が実現できていると思います。

一部、GitHub Enterpriseでは外部サービスとの連携ができないこともあるので、GitHub.comも併用していますが、もうGitHubがないと仕事にならないですね。

マーケットがない状態から、「Arukas」を立ちあげる

私が開発している「Arukas」というサービスは、Dockerコンテナのホスティングサービスです。Dockerイメージを、高品質なデータセンターの環境で起動できるというものです。

Arukasの開発を始めたのは2014年の10月頃で、まだ日本ではDockerをごく一部の人だけが使っている状態でした。ですが、海外では開発が活発で、2、3年後にはきっと大きなトレンドになるなと思いまして。そこで見切り発車的に、企画を進めていきました。

今までの弊社のサービスって、必ず「さくらの」という名前なのですが、Arukasだけ違うんです。まあ、「SAKURA」を逆から読んだだけなんですけど（笑）。

これは、「別のブランドとして見てもらいたい」という思いからです。新規事業として、今までとは全く新しい文化を、イチから作ってみようと思ったんです。

新しい文化を作るオフィス、「さくらのガレージ」

現在5人のArukasチームは、開発に集中するために、普段のオフィスとは別にマンションの1室を借りた「さくらのガレージ」で開発をしています。

弊社も、会社が大きくなったこともあり、社内がレンタルサーバーやVPSの文化に最適化されているような空気がありました。ただ、それらの事業は、拠点をまたいで何十人という単位で仕事をしているので、どうしても意思決定が遅れたり、会議が多くなったりするんですね。

Arukasのように、技術的にもマーケット的にも新しいサービスを開発するときに、その文化は馴染まないと思ったんです。

▼さくらガレージの様子

実際、さくらのガレージでは、ほぼ電話も鳴りませんし、突然会議に呼ばれることもなくて。様々なオフィスの雑音から解放されているので非常に集中しやすく、ストレスも少ないですね。

また、他のメンバーのタスクも目に見えやすいので、いつもよりペースが遅れていたりといった問題にも、気が付きやすいです。

今では他のサービスでも、オフィスとは別の場所で、少数精鋭で開発を始めるチームが出てきています。Arukasチームとして、ある程度モデルケースとしての効果を見せられたのではないと感じていますね。

Arukasの開発環境は、Docker、CircleCIを活用して整備

Arukasの開発についていうと、それ自体がDockerのホスティングサービスですが、開発にもDockerを活用しています。

Arukasのようなホスティングサービスは、ベースとなるインフラと、それを操作するAPI、そしてユーザーが使うコントロールパネルという3つの要素で構成されています。そのAPIとコントロールパネルの開発環境として、Dockerを使っています。

そしてコードの品質を保つためにも、CircleCIを活用しています。自動テストや、マージしたときにデプロイするフローを定義しておけば、誰でもテストやデプロイができるようになるので、非常に重宝していますね。

自動テストをしているのは、コントロールパネル、API、そしてインフラまで全部ですね。Arukasは、CoreOSというメジャーではないOSを使っておりまして（笑）。その構成管理に、Cloud-Configというツールを使っているのですが、その設定ファイルのシンタックスチェックを自動で走らせています。

常に変化しながらも、「ゆとり」を持ったチームへ

以前の弊社では、基本的に各自が専門性に特化して、役割が分断された形で仕事をしていました。けれどArukasでは、メンバーの数も限られていますし、全部を自分でやらなきゃいけない環境なので、難しいことも多いです。

そのような環境でも、仕事には「ゆとりを作る」ように気をつけています。ゆとりが無いと、どうしてもコミュニケーションが薄くなってしまい、次第に信頼が失われてしまいます。

信頼が薄くなると、相手に物事を伝えるためにはコミュニケーションの量を増やさなければならなくなる。そうすると今度は時間のほうが足りなくなって、ゆとりが無くなって、という繰り返しで泥沼にはまってしまうんですね。

Arukas自体、まだまだサービスの本番環境で使える品質には到達していません。誰でも簡単に、高品質なデータセンターの環境上でDockerが使えるというところを、常に変化をしながら目指していきたいですね。（了）