今回、自作の作業効率アップシステムを紹介してくれたのは、GMOペパボでエンジニアリングリードを務める内村元樹さん。

内村さんは、開発中にブラウザでサーバ証明書の内容を確認する作業頻度の高さを面倒に感じたことをがきっかけに、Go言語を用いて簡単にサーバ証明書の情報を表示出来るコマンドを作成。

どのように自作システムの開発を進めたのか、工夫したことや開発を通して学んだことを具体的に紹介してくれた。

GMOペパボ株式会社
ホスティング事業部 マーケティングチーム 兼 ホスティング事業部 業務信頼性向上チーム エンジニアリングリード
内村元樹さん

大学卒業後、東京のSES企業に入社し、主に金融系のSI業務に従事。その後、東京のWeb系ベンチャーに転職、主にモバイル向けキャンペーンサイトの構築・運用等に従事。2011年に福岡に移住し、GMOペパボに入社。入社後は、社内システムの開発・運用やホスティングサービスの開発・運用などにWebアプリケーションエンジニアとして携わり、現在はエンジニアリングリードというポジションで、エンジニアリングに関するマネジメント業務と開発業務を行っている

GMOペパボの事例：Goの学習も兼ねて2週間で作成した「コマンド開発」

私が今回紹介するのは、Goによるコマンド開発についてです。

当社では2017年後半に、当社ホスティングサービスで無料SSLというサービスを提供し始めました。Let’s Encryptという認証局のサーバ証明書を無料で提供するサービスです。

私は、Webアプリケーションサイドの開発に参加していたのですが、開発中にブラウザでサーバ証明書の内容を確認する頻度が上がっていったんですよね。

それが次第に面倒と思い始めたのをきっかけに、簡単にサーバ証明書の情報を表示出来るコマンドを作成しました。

ブラウザでサーバ証明書の内容を確認するためには、対象サイトにアクセスして、アドレスバーの端にある鍵マークみたいなものをクリックして、「サーバ証明書の情報を見る」というメニューを選択し、確認したい情報をスクロールして探す……といった手数が必要です。

それを1日に何度も実施していることを疑問に思い、課題と考えるようになりました。

そこで、この課題を解決するために、プログラミング言語であるGoによるコマンド「certコマンド」を開発。

コマンドの引数にWebサイトのドメイン名を渡して実行すれば、私が確認したかったサーバ証明書の内容（発行者、有効期限や SANsなど）が表示されるというシンプルなものです。
Goの学習も兼ねていたので、業務をしながら2週間くらいで制作したと思います。

そして、これらを作成した結果、実際にサーバ証明書の内容確認に要する時間が大幅に短縮できました。特に、確認したいサーバ証明書の数が多いほど、短縮の効果を実感しますね。

また、一度にたくさんのサーバ証明書の内容を確認しようとする場合、「certコマンド」を作る以前は上述したようなブラウザでの手数をサーバ証明書の数だけ繰り返す必要がありました。

しかし、「certコマンド」作成後は、確認したいWebサイトのドメイン名を一度に渡して実行するだけで済むようになったんです。

同じ無料SSLのプロジェクトに携わっていた同僚からも「便利」という声をもらえました。私と同じように「面倒くさい」と感じていたのだと思います。

それから、次第にプロジェクトや部署を越えて「certコマンド」を使ってくれる同僚が増えていきました。

さらに、OSSとして公開していたこともあって、私の個人ブログでの紹介を、同僚や著名なエンジニアの方などが拡散してくれたことをきっかけに、想像以上の反響をいただくこともできました。

何もかもが想像以上だったので驚きましたし、たくさんの方の目にとまってとてもうれしかったですね。

コマンド作成でこだわったのは「目的を絞ること」

コマンド構築にあたり、特に「目的を絞ること」にはこだわりました。

開発を進めていると、こんな機能もあった方が良いのでは？ と考えることもあると思うのですが、このシステムを構築するにあたっては、自分が解決したい課題を解決することに集中し、機能をむやみに増やさないようにしました。

結果として、インタフェースを含めてコマンド自体がシンプルなものになったので、使ってくださる方が想像以上に増えたのだと思います。

また、開発言語にGoを選定した理由にも、技術的な判断がありました。

今回の課題を解決する方法は、当然ですが他にもたくさんあり、わざわざコマンドを実装しなくても、opensslコマンドを実行して、欲しい情報だけフィルタするようなシェルスクリプトを用意するなどすれば、大体の「実現したいこと」は実現できたのです。

ただ、課題が汎用的だと考えていたので、例えばMacではなくWindowsを使っている人や、エンジニアではない人でも使いたいシーンがあるかもしれないとも考えました。

そうなると、エンジニアではない人がWindowsでopensslコマンドを利用したスクリプトを書くというのはハードルが高そうです。

それならば、Goでクロスコンパイルを行い、Windows用のバイナリをダウンロードするだけにしておいた方がアドバンテージがあるのではと判断しました。

また、そもそもTLSに関してGoがOpenSSLに依存していない点も選定理由として大きかったです。

他には、出力形式を選択できる点を工夫しました。具体的には、テキストを整形しただけの出力に加えて、Markdown形式やJSON形式で出力できるようにしました。

機能を増やさないことにこだわったというのは上述しましたが、一方でコマンドにおける出力の利用可能性は高いので、たとえばJSONであればパイプ処理につなげて、好きな後続処理をすることができるでしょうし、Markdown形式ならば、表形式での一覧管理などをしたい場合に便利です。

キャメルケースorスネークケースの判断に悩まされた

扱っている課題も、解決のために使用した技術領域も、どちらもとても小さくてシンプルなものなので、そのあたりで難しかったことや壁にぶつかったことは、特に思いあたりません。

ただ、具体的過ぎる内容かもしれませんが、JSON出力の際に、キー名のケースを何にするかというのは少し悩みました。キャメルケースにするかスネークケースにするかです。

なぜ悩んだかと言うと、一度公開してしまうと変更が容易にできない部分だからです。JSON出力を利用している方からすれば、ある日コマンドをバージョンアップしたら、JSONのキー名のケースが変わっていて、それを利用していたしくみが壊れるといったことが、実装によってはあり得ます。

結局、確固たる正解というものにたどり着けなかったのですが、最終的にはキャメルケースにすることにしました。

有名なWeb APIのレスポンス例などを見ていると、どちらかというとスネークケースが多いのかなという印象だったのですが、JSONを生み出したJavaScriptの世界での慣習に従っておこうかなという判断になりました。

上記のような点は、課題解決される範囲を広げる上で重要になってくると考えています。

解決するためのしくみを作ったとして、それを使ってもらうという形の場合には、レバレッジを出来る限り効かせるためにも、使う側の立場から見てどうなのかといった点を考えるのが、重要かつ難しいところでもあると思いました。

「certコマンド」の開発を通して学んだこと

「certコマンド」を自分で作ってみて、何事に対しても「疑問を持つこと」が大事だなと改めて思いました。

今回のケースだと、自分が面倒な作業だと思ったときに、そもそもこのやり方しかないのか？ という疑問を持ったことがきっかけとなりました。

面倒と感じただけで思考を止めていたら、何も変わらなかったのではないかなと思います。

自分が従事している業務において、自分や他の方が取り組んでいるタスクを俯瞰し、もっと効率を上げる方法があるのではないか、そもそも実施する必要性があるのだろうかといった本質的な部分を含めての疑問を持つことで、課題解決のための着眼点を良くしていけるのではないかと考えています。

あとは、「小さいから」という理由でスルーしないことも重要だと思いました。

今回紹介させていただいたケースは、すでに述べているとおり、解決する課題も小さいですし、必要な技術要素も少なく、要求される技術力もまったく高くありません。言ってしまえば、誰でも解決できる小さな課題なわけです。

こうした課題に直面した時、場合によってはコマンドを実装するほうがコストが掛かりそうであるとか、もしコマンドを作ったとしてもOSSにして公開するようなレベルじゃないのでやめておこうといった考えが発生することがあるかもしれない。

そうしたときに、手を止めてスルーするのではなく、とりあえず手を動かしてみることが大事なのだと思います。

当然上手くいくことばかりではないのですが、場合によっては今回のコマンドのように、自分や自分の周囲だけではなく、世界で小さな課題がたくさん解決されるようなケースに結びつくこともあり、そうなると「小さいから」という理由は成り立たなくなります。

小さくても、チャンスととらえるような姿勢を持てると良いなということを学びました。