「ついカッとなって……」取り組んだ 開発者のための開発 で業務効率を改善させた話

開発環境の整備

Vagrant と Chef でつくるはてなブックマークの開発環境 // Speaker Deck（2013年「Hatena Engineer Seminar #2」発表資料）

以前チームを異動した際、まず最初に自分のマシンで開発環境を整えたのですが、これが1日作業となり途方に暮れました。筆者が「開発者のための開発」を強く意識し始めたのは、この出来事が大きかったように思います。

開発環境の構築は、それ自体が何かを生み出すことはありません。さらにそのチームでのセットアップ作業はいくつものコマンドを五月雨に実行していくというもので、時間ばかりが過ぎていきました。

丸々1日あれば、他にもっと生産的な仕事ができるはず。今後入ってくるメンバーのためにも、勢い付いて改善を始めました。それが上記の資料にあるVagrantとChefを使った開発環境構築の自動化です。

Build CI for Smartphone apps dev. at Hatena // Speaker Deck（2015年「【DeployGate x はてな】スマートフォンアプリ開発最前線」発表資料）

アプリケーションの開発環境を Ansible でつくる - Hatena Developer Blog

自動化の勘所を掴めたので、他のチームでも同様の取り組みをしたり、インストールするライブラリやミドルウェアの管理が手間そうだとCIの導入に悩んでいたチームに「こういうふうに負担を減らせるよ」とアドバイスして、技術を輸出したりもしました。

開発環境の整備に力を入れたところで、マイナスをゼロにする守りのエンジニアリングでしかないのではないかと悩んでいた当時の筆者にとって、自分が手にした技術でプラスの提案をする攻めのエンジニアリングに結び付いた体験は、自信を得ることに繋がりました。

パフォーマンスを計測するツール

はてなでは毎月PWG（Performance Working Group）という会を設けています。サービスを担当するアプリケーションエンジニアとオペレーションエンジニアが集まってパフォーマンスが悪化していないかを確認し、悪化していたりその兆候が見られたりしたら対策を検討することが目的です。

そのPWGのアジェンダの中にGoogle PageSpeed InsightsでJavaScriptの実行などを含めた体感ページ読み込み時間が悪化していないかを見るというコーナーがあります。

以前は、結果を見たいページのURLを都度入力して点数を確認し、前回より悪化している・変化なし・改善しているといった点を確認するという素朴な流れでした。

一見なんでもない手順に見えますが、筆者にはページを開いてURLを入力し点数の計測を待つ、その30秒程度の時間がもったいないように思えてなりませんでした。「こんな単純作業なら、自動化すればいいのでは？」と考えたのです。

PageSpeed Insights のスコアを Mackerel に投稿するアプリケーションをボタン1つで Heroku にデプロイできる状態にした - Sexually Knowing

そこで調べてみるとGoogle PageSpeed InsightsにはAPIが提供されていることを知りました。早速、簡単なアプリケーションを書いてMackerelのサービスメトリックとして毎日投稿するようにしました。

結果、毎月のPWGではMackerelのサービスメトリックのグラフを見るだけになり、これまで数クリックあった手順がなんと0クリックになりました。

それだけではなく、計測したいURLを手軽に増やせるようになり、同一のエンドポイントでも異なる条件のページを同時に計測し始めました。これにより、特定のページでロード時間が悪化していることを発見し、最近リリースした機能が影響していそうだ、というところまで分析することができました。

こうした分析が進むようになることは当初想定しておらず、思わぬ産物といえるでしょう。

デプロイの改善

Web開発においてデプロイは切り離すことのできないワークフローです。同じソフトウェア開発でもパッケージ製品や組み込みなどと大きく異なる点として、納品ともいうべきデプロイが頻繁に、しかもほとんど終わることなく続く点が挙げられるでしょう。

デプロイは重要なワークフローである一方で、それ自体はさして生産的なものではありません。にもかかわらず一定の時間、拘束され続け緊張した心持ちが続きます。

ここまで読んでいただいた読者の方は想像がつくかもしれませんが、当然、筆者はこの日々のデプロイも改善したいと考えました。

所属していたいくつかのチームでは、10分から長いときは30分近くデプロイに時間を取られることがありました。しかもこれは定期的な作業で、最低でも週に1回、多ければ1日に数回行われます。1日に30分の拘束が3回あれば、1時間半になります。しかも断続的ですからその日はほとんど集中できません。

デプロイというフローが苦痛となっていることも危うい予感がします。本来ソフトウェアが新しくなることは、我々開発メンバーにとってもユーザーの方々にとっても喜ばしいことであるべきです。

はてなブログのデプロイを約6倍高速化したはなし - Sexually Knowing

世界展開する大規模ウェブサービスのデプロイを支える技術 / YAPC::Asia Tokyo 2015 // Speaker Deck

実際的な面でも、デプロイの遅さは改善のサイクルが遅くなることに直結しますから、速いに越したことはありません。

そういった経緯があって改善を行った結果、現在のチームではデプロイに要する時間が1分を切るほどになりました。

デプロイを担当するメンバーの拘束時間が減っただけではなく、サービスの品質を維持することにも繋がります。

デプロイを高速化した後のこと、デプロイした変更に不具合が含まれていることが発覚しました。しかし迅速に変更を戻すデプロイを行った結果、影響が広がることを防げた、というエピソードがあります。

もちろん不具合を起こさないに越したことはないのですが、万が一発生した場合に規模を小さく留められるようになっていることも重要です。

新社内システムのテックリード

2016年から課金システムの開発チームでテックリードとして牽引しています。課金システムは既にあったものの、現在のサービスの要求から外れてきたことから新たに開発しています。

開発者目線として既存の課金システムは改善しづらいと感じるもので、折に応じて「どうにかできればなあ」と思っていました。なので「こういうプロジェクトを始めようと思うけどやりたい人いますか？」と聞かれたことは願ってもいないチャンスでした。

新課金システムは、社内で一般に求められるいくつかの要求を満たしながらも、既存システムと比べてより柔軟な設計を目指しています。これまでの反省を活かし、他のはてなのサービスがシステムの枠にとらわれず多様な課金の機会を得られるようにするためです。

これはまさしく「開発者のための開発」であり、また日頃感じていたフラストレーションが高じて機会を掴むことができたといえるでしょう。

なお、この新課金システムの詳細はScala関西2016の発表資料でご覧いただけます。

はてなにおけるマイクロサービスとScala / Microservices and Scala at Hatena // Speaker Deck

「開発者のための開発」のやりがいについて

梃子（てこ）の考え方を持つ

以上、はてなでアプリケーションエンジニアとして取り組んできた開発の一部を紹介しました。

筆者が取り組んだ内容は、既にあるものを組み合わせたり導入したりしただけで、特に技術的に目新しいことをやったわけではないじゃないか、という向きもあると思います。むしろこれこそが知ってほしいことでもあります。

筆者が実際にかけた労力に比べて得られた成果は大きいといえるでしょう。これは筆者以外のメンバーも成果を享受できることを指しています。さらにこの成果の広がりを拡張して、横の広がりと縦の広がりという捉え方もできます。

横の広がりというのは、現時点において個人やチームなどの垣根を越えて他の仲間たちに伝わるということです。

さらに縦の広がりというのは、未来の仲間も恩恵を受けられるということです。新しくチームに加わる仲間が、整えられた仕組みによって素早く開発環境を作れるということはまさしくそれです。筆者はこれを技術的負債になぞらえて技術的投資と捉えています。

このように、1つの仕事で10や20、あるいはそれ以上をなすのは梃子（てこ）の働きをなしているといえないでしょうか。筆者はこれこそプログラミングの大きな醍醐味の一つだと考えています。

開発者のための開発は、梃子（てこ）の中でも特に効果の大きい分野といえます。1から10にすることが得意なエンジニアがお互いに作用し合えば、とても大きな仕事ができそうな予感がしませんか。

自分の感じた「怒り」を信じる

こうして振り返るとよく怒っていることがわかります。既存の仕組みが遅かったり非効率であったりして、そんな現状をおかしい！と考える。

自分が明るくない分野、あるいは慣れた分野では、使いづらいだとか冗長な気がしても、そんなものだと受け入れて我慢してしまうこともあるでしょう。

しかし、誰かが我慢して少しずつ生産性を落としている状況に問いを立てることは、プログラマーの美徳の一つに数えられる短気として、ソフトウェアエンジニアにとって重要な振る舞いではないでしょうか。

ソフトウェアからなる仕組みを作ったり改善したりできるのはエンジニアならではです。ソフトウェアに対する高い専門性から気付けることもたくさんあります。

とはいえ、短気という美徳を知りつつも声を上げたり改善を進めたりするのは物怖じするかもしれません。そんなときは「人ではなく仕組みを改善する」「動くものを見せる」という点を気にかけます。

仕組みは人が作るものですが、人は不完全なので作るものに不足や欠損があることもしばしばです。それらは単に知識が足りなかったり考慮が足りなかったりするだけで、悪意なんてものはないことがほとんどです（ハンロンの剃刀という言葉もあります）。

怒りを向けるべきは非効率なままでいることの不条理であり、それを作った人ではありません。もしも作った人に怒りを向ければ、たとえあなたの主張が正論であったとしても態度を頑なにしてしまい、改善は失敗するでしょう。

もう一つ「動くものを見せる」ということも重要です。未知に対する畏れは誰しも持つものですから、非効率でも万事が成立している現状のほうが、改善を試みた結果今まで回っていた仕事が回らなくなる未来より良しとされることもあります。

そういうときは実際に動いているものを見せると良いです。実際に動いているものを前にすれば、未知のものを受け入れるかどうかという問題から、目の前にあるものが理に適っているかどうかという問題に移ります。

たとえ最初に示したものが受け入れられなくとも、得られるフィードバックはきっと有益なものでしょう。本当に何が必要なのかを知ることができるはずです。

開発者のための開発は楽しい

「開発者のための開発」と「梃子（てこ）としてのプログラミング」というキーワードでソフトウェアエンジニアとしての楽しみを紹介しました。

冒頭で既に専門性を発揮しているエンジニアと比べるような形で紹介しましたが、実際のところ対比させるようなものでも排他的な関係にあるものでもないと筆者は考えます。ましてや研鑽を必要としない分野であるということはありません。

ただ、少しばかり魅力が伝わりにくい分野であると感じています。この記事を読んだ方が開発者のための開発やプログラミングという梃子（てこ）の魅力を捉え直すものになればと望んでいます。

また、文中で紹介した筆者の取り組みの中にはOSS（オープンソースソフトウェア）として公開しているものもあります。利用していただくことであなたの助けとなればこれほど光栄なことはありません。

あるいは、この記事をきっかけにあなたの取り組みがOSSとして公開され、いつかそれを利用できるとしたら、OSS開発に取り組むエンジニアが増えることを願っているエンジニアとしての本懐とするところです。

執筆者

id:aereal

サーバサイド、Android、アプリケーションエンジニア。Web標準技術への興味をきっかけにWeb技術全般を学習しエンジニアを志す。2012年に株式会社はてなに入社。はてなブログなどの開発に携わる。趣味は自動化で、OSのクリーンインストールを毎月行うのが習慣。
ブログ：Sexually Knowing