「一つのことをうまくやる」に忠実たれ。Serverspec開発者mizzyが語る成功するOSSの設計

宮下剛輔さん：大学で経営学を学び、大手SIerでサーバー、ブラウザ製品のプリセールスに従事。その後、paperboy & co.（現GMOペパボ）技術責任者として同社のサービス開発・マネジメントをこなす。現在、独立してフリーランスのエンジニアとして、サーバー構築のコンサル、構築支援、ソフトウェア開発を行っている。著書に『Serverspec』、監訳書に『Infrastructure as Code』がある（共にオライリージャパン）。

──大学では経営学を学んだとお聞きしましたが、そこから一転、プログラマ・エンジニアとなったのはなぜだったのでしょうか。

宮下　パソコンは子供のころから好きで、中学生くらいまでは『マイコンBASICマガジン*1』に掲載されているゲームプログラムを入力して遊んでいました。高校ではパソコンからは離れたのですが、大学のゼミの先輩が卒論でWebの研究をしていて、先輩の卒業後にゼミのWebサーバーの管理を引き継いだことで、再びパソコンやプログラムに接する機会が増えたんですね。

こんな経緯があってサーバーやネットワークなどインフラが好きになり、1997年にSIerに就職したんです。最初に就職したのは、Netscape社の代理店をしていた会社でしたね。ブラウザだけでなく、サーバー製品も取り扱っていたので、そうした製品のプリセールスエンジニアをしていたんです。その後、Web業界に行きたくなって、paperboy & co.（現GMOペパボ）に入ったんです。

──職業としてサーバー構築など手がけた経験がServerspecの開発に影響を与えたのですか。

宮下　以前私がいた会社では、サーバー構築は、Wordの手順書に従って目視と手動でやる、とか、長いシェルスクリプトを実行したりとか、非常に手間がかかり見通しの悪い作業でした。これはなんとかしないといけない、と思って、2006年ころからサーバー構成管理ツールとしてPuppetを使うようになりました。

Puppetに関しては、宮下さんが2010年に発表したスライドにも詳しい。

ただ、Puppetも長年使っているうちに、やはり自分の書いた最初のPuppet用コードをリファクタリングしたくなってくるんですよね。最初からベストプラクティスが存在していたわけではなく、試行錯誤の連続で使っていたわけですから。古いコードはベストプラクティスに沿っておらず、コードの見通しも悪くメンテナンスしにくいので、もっときれいなコードにしたい、と思うわけです。ただ、リファクタリングのためには

• テストコードを書く
• テストコードを実行して、テストを通す
• コードを書き換える
• 書き換えたコードをテストする

こんなテストプロセスが必要になるわけです。当時、Puppetのコードに対してこうしたプロセスを行えるツールがなかったんです。いや、厳密には近い機能を持つツールはあったのですが、自分の欲しい要件を満たすものがなかったんです。

既存のものがなければ、自分で作るしかないと考えて、2013年ころにServerspecの開発に着手したんです。構築はPuppetで自動化できているのに、テストはチェックリストを作って手動でやっていましたから。

実は、Serverspecの前身となる「Assurer（アシュラ）」というツールを開発していたのですが、これは機能を広げすぎて、結局自分でも使わなくなってしまった。やりたいことを詰め込みすぎて、複雑で使いづらいものになったのかもしれません。その反省もあって、「要はRSpecでサーバーのテスト“だけ”ができればいいんだ」という思想で、もっとシンプルなツールを作ろうと思ったんです。それがServerspecです。

──著書では、Serverspecが「インフラコード開発におけるリズムを作り出す」と語っておられます。このリズムとは具体的にどんなことでしょうか。

宮下　いわゆるテスト駆動開発では、「Red（失敗するコードを書く）」「Green（とにかくコードを動くようにし、テストを通す）」「Refactor（コードをきれいにする）」というサイクルがあります。コードを書き、テストをし、フィードバックが得られる。そして、フィードバックを元にまたコードを書いてテストをする、というリズムが生まれます。書けばすぐに結果が分かるわけですから、開発が楽しく気持ちよくなってくるんです。いわば、“開発が進んでいる感じ”が実感できるわけです。

Serverspecで実現したかったのは、こうしたテスト駆動開発の心地よいリズムをインフラコード開発に持ち込むことでした。サーバー構築が自動化されているのに、構築のテストがチェックリストに基づく手作業だったりすると、このリズムを実現できませんから。

──リズミカルな開発の心地よさは、Serverspec開発以前から実感していたのでしょうか。

宮下　テスト駆動開発によるリズムの心地よさは、CPAN（Perlの統合ライブラリ）モジュール開発で実感していました。自分はもともとPerlの人で、CPANモジュールはテストコードが必ずセットになっていて、make testでテストを実行する、という文化です。こうしたリズムのもたらす心地よさを知っていたからこそ、インフラコード開発の世界にもリズムを持ち込みたかったんです。

他者の知が集約されたツール

──さて、興味深いのは、肝心な「RSpecでサーバーのテストをする」というアイデアは実は宮下さんのものではなかった、ということです。

宮下　そのとおりです。RSpecでサーバーのテストをするというServerspecのアイデアをくれたのは、元同僚のhiboma（ @hiboma ）です。hibomaが当時、コンテナのテストをRSpecで書いていたんですが、このアイデアにさらに汎用性を加えたのがServerspecです。

RSpecにmatcherという比較用のメソッドがあって、hibomaはmatcherを独自にカスタムしてテスト用に使っていました。このカスタムmatcherを定義する方法を参考にServerspecを書いたのが最初です。

──かくしてリリースされたSeverspecですが、当初の反応や反響についてどうお考えですか。

宮下　作ったときに、自分でもけっこう便利なものができた、という手応えはありましたが、それでも予想以上の反応でしたね。Hacker Newsに投稿してもらったり、GitHubのスターがすぐに3桁（現状は2,000以上）にいったり。

──みんなに使ってもらうための工夫などもあったのでしょうか。

宮下　分かりやすいREADMEは心がけましたね。読めばすぐに試すことができて、すぐに分かるようにしました。他には、世の中のサーバーが、すべて最新のものを使ってるわけではないので、古いRubyでも動くようにするとか。

──敷居の低さ、という部分がAssurerと大きく異なる印象があります。

宮下　『UNIXという考え方』という本があり、その第8章に「一つのことをうまくやろう」という記述があります。Assurerの失敗はこの哲学を体現していなかったことにあるでしょう。『The Art of UNIX Programming 』という本でも同様の哲学がくみ取れます。単機能でも完成度が高ければ使いやすいツールになりますし、それらを組み合わせれば、複雑な処理も柔軟に対応できます。

Assurerを作っていたとき、こうしたUNIX哲学を忘れていたわけではありませんが、「自分のやりたいこと」を詰め込みすぎてしまったんですね。結果、自分でも使わなくなってしまった（笑）。

──では、Serverspecは順調な船出だったと？

宮下　いえ、リリース当初は課題だらけでしたね（笑）。自分の作業を楽にしたいという動機で開発していますので、機能は必要最小限、ユースケースも自分の環境や用途に限られていましたし、とりあえずSSHで使えればいいという状態でした。ローカル実行さえできなかったんですよね。

リリース後はいろいろな人がプルリクエストをくれましたが、この課題を解決してくれたのが、raphinkさんのプルリクエストでした。

──他に印象に残るアドバイスなどはありましたか？

宮下　非常に大きいのはtkmr（ @tkmr ）さんがツイッターでくれたアドバイスですね。Serverspecでテストする対象は文字列で記述していたのですが、これだと例えば「httpd」としたときに、デーモンの名前なのか、パッケージの名前なのか区別がつきません。

宮下さんとtkmrさんのやりとりはこのtogetterにまとめられている。

どう解決すべきか悩んでいたのですが、tkmrさんが「文字列ではなく、オブジェクトを返すようにすればいいのでは」とアドバイスしてくれたんです。「それだ！」と唸りましたね。

コードで語ってほしい。作者がうれしいプルリクエスト

──集合知でServerspecが洗練されてきたのがよく分かります。宮下さんにとって、ありがたいプルリクエストとはどんなものでしょうか。

宮下　粒度が小さいものは良いですね。一つのプルリクエストに対して、トピックも一つ、のように。トピックが複数あると、このトピックはいいから取り込みたいけど、このトピックはダメだから取り込みたくない、といった場合の対応が難しかったりするので。

──そういえば、著書では宮下さんご自身も修正は小さく、「早めのリリース、しょっちゅうリリース」を心がけていると書いていらっしゃいますね。

宮下　大規模な修正やアップデートは、差分が大きくなりすぎ、問題が起きたときに、何が原因か特定するのが難しくなってしまいます。開発の見通しをよくするため、一つ修正するごとにリリースをしていった方がいいということです。

──なるほど、他にいいプルリクエストの要件はありますか。

宮下　意図が明確に示されているものがうれしいですね。さらに言えばテストコードの形で示されているのがありがたいです。コードさえあれば、実行すれば正確に判断できるので。自然言語よりもプログラミング言語の方が、やはり意思疎通はしやすい（笑）。

──「コードで語れ」というわけですね（笑）。

宮下　リポジトリに「Issues」を置いていないのも、そういった理由からです。なにか要望があれば、コードとともに送ってほしい、という意図はREADMEにも記載しています。

ServerspecのリポジトリにあるREADMEには上記のような記載がある。

ただのリクエストや要望だと、意図が明確でなかったり誤解が生じたりしますよね。「こんな機能じゃなかった」というような。やりとりは英語ですが、自分もネイティブというわけではないし、相手もネイティブじゃない場合もあります。

せっかくエンジニアなんだから、コードがあれば伝わるし、お互いの理解に齟齬はなくなるはずです。このポリシーに対して、ツイッターなんかで「あいつは何様だ」とディスる人もいますが、自分自身、他のOSSにプルリクエストを送る際は、コードとともに送ることを心がけています。

オープンにすると、道が拓ける

──宮下さんがOSSにこだわるのはなぜでしょうか。Serverspecをプロプライエタリでリリースするという意思はなかったのでしょうか。

宮下　Serverspecに関しては、全くなかったですね。OSSへのこだわり、という意味ではSIer時代の経験がすごく影響していると思います。SIerとして取り扱っていた製品は、当然OSSではなくプロプライエタリだったのですが、その場合、何か不具合があったときに、ベンダーに対して質問や要望を投げ、回答や場合によってはパッチが来るまで待たなければなりません。自分ではどうにもできないことに、もどかしさを感じてしまったんです。

SIerからOSSをフルに活用するWeb系の企業に転職したのも、こういった背景からです。OSSを活用して仕事をするのであれば、システムの中身は全て自分で触れます。もちろん、その分の責任も生じますが、やりがいや楽しさを感じるんです。

──最後に、ご自身のエンジニアとしてのライフスタイルを築くにあたり、オープンソースというカルチャーが与えた影響などがあれば教えてください。

宮下　さっきも言ったように、SIerからWeb系の仕事に移ったのはOSSの影響が大きかった。もう一つ、“オープンにする” という価値観が自分にとっては肌に合っていたというか、楽しいものだったんです。ソフトウェアに限らず、技術情報をブログなどに書いて情報を公開したりするのも重要です。

ペパボに入ったのも、ブログを書いていたら、当時のペパボの代表である家入さんの目に止まったからでしたし、ペパボで技術責任者として仕事ができたのも、OSS活動の実績を認めてもらっていたからだと思っています。

月並みな言葉ですが、ソフトウェアや情報をオープンにすることには、ギブアンドテイクがあります。自分から出していくことによって、得られる“何か” がきっとある。自分の経験上でもそう実感しています。積極的にオープンにしていくことには意義があるし、得られるものもある。きっとこの先のキャリアでも、同じことが言えるだろうな、と思っています。

取材：中尾真二