おひとりさま開発基盤グループでの業務の進め方

はじめに

この記事は Speee Advent Calender の23日目の記事です。

こんにちは！ロボット大好き系エンジニア、開発基盤グループ所属の森岡です。ガンダムはF91とクロスボーン以外はほぼ全て視聴済み、フロントミッションも携帯ゲーム以外は全てコンプリート。フロントミッションとアーマードコアの最新作をずっと待ち続けています。好きなMSはリックドムです。

さて、僕が所属している開発基盤グループですが、グループという名前が付いているものの、実際に所属しているのは現在森岡１人だけで、完全におひとりさまグループとなっております。この記事では、１人で開発基盤グループを進めていくためにやっていることについて、ご紹介させていただきます。

開発基盤グループのお仕事

開発基盤グループは Speee全社におけるwebサービスの技術的な品質向上 をミッションとして業務を行っています。具体的な業務としては、下記のようなものが挙げられます。

全社的に利用されているDatadog, Sentry, Sidekiq Proなどのツールの導入・管理
開発に関するガイドラインの作成
全社のサービス品質を向上するための各種ツールの作成

tech.speee.jp ※ 1部、Speee Cafe Meetupでお話しさせていただきました

現在、このような業務を進めている開発基盤グループですが、過去は異なるミッションを持って仕事を進めていました。

"全社的な開発効率の向上"から"サービスの技術的な品質向上"へ

先月(2017年11月)まで、開発基盤グループのミッションは、全社的な開発効率の向上でした。そのミッションに従って、僕たちはRevieeeという確認環境の自動構築ツールを作っていました。

tech.speee.jp

しかしながら、このツールは現在開発を停止しています。その理由は下記の通りです。

人の異動などで、恩恵を受けられるプロダクトのエンジニアが少なくなった
AWSのインフラが大きな役割を持つwebサービス増え、Revieeeでそれらをカバーすることが難しくなった

また、弊社で採用している言語、フレームワークが多様化してきたこともあり、Revieeeのような Railsに特化した確認環境構築ツールは、現在のSpeeeにおいて 多くのエンジニアに価値があるとは言い難い ものになってしまいました。

このように開発効率の向上というミッションは、採用する技術や、そのときの人の配置に依存する部分が大きく、開発基盤グループが１人という現状では達成することが難しいものでした。そこで、2017年11月にミッションの見直しを開始しました。

新しく作るミッションは、人の入れ替わりや利用している技術に依存せずに価値を出せる必要があります。それが何かと考えたときに、弊社が運用している 全てのサービスの技術的な品質向上 が適切であると考えました。

このミッションを進めていく手順は下記のようになっています。

f:id:selmertsx:20171222204619p:plain

これだけでは具体的なイメージが湧かないと思うので、現在行っている業務内容を例に説明させていただきます。

画像圧縮の全自動化

現在、開発基盤グループでは、Speeeにおける全てのwebサービスにおいて、ユーザーにとって最適な画像を配信する ことを目的として、デザイナーやフロントエンドエンジニアの人たちと一緒に、その仕組みづくりを進めています。

なぜ 画像の最適化 を最初の施策として選んだのかと言うと、現状パフォーマンスの向上に最も寄与し、画像を用いる全てのサービスにおいて有効で、ページの表示速度を早くしたいという事業の意図とも合致するものであったからです。 画像の最適化 ができる仕組みを作るために、下記の内容で仕事を進めています。

画像取扱ガイドラインの作成
サイトの評価ツールの作成
画像を自動圧縮するツールの作成
CIでの未圧縮画像検知

画像取扱ガイドライン

ガイドラインの作成にあたっては、Googleの資料を参考にさせて頂いています。

Image Optimization | Web Fundamentals | Google Developers

ガイドラインには下記の項目を記載しています。

JPG、PNG、SVG、GIFの選定基準
JPG、PNGの圧縮ツールおよび、圧縮レベル

Googleの資料においては、PNGではなく WebPの使用を勧めていますが、現状の対応ブラウザ状況を見ると、WebPへの完全移行を進めることは難しい状態にあります。そのあたりは僕たちで判断しガイドラインの作成をしております。その詳細については、またどこかのタイミングで発表させていただこうと思います。

未圧縮画像の検知ツールの作成

さて、ガイドラインが出来たら次に必要になってくるのは、僕たちのサイトの評価ツールです。評価ツールは、slackのslash commandがインターフェースとなっており、下記のような方法で利用できます。

f:id:selmertsx:20171223184619p:plain

実行すると、slack上で改善点や、改善した場合にどの程度容量を圧縮できるか教えてくれます。 slackを利用した理由は、エンジニアだけでなく全ての職種の人に結果を見てほしかったからです。

f:id:selmertsx:20171223185232j:plain

この機能は AWS API Gateway と AWS Lambdaを使って実現しています。 Lambdaの中で headless Chromeを使ってページを閲覧し、分析を行っています。詳細については、また別の機会に説明させていただきます。もう少し調整が出来たら、OSSとして公開しようかなと考えています。

その他、開発予定のツールについて

ここから先はまだ未着手のものですので、構想だけのお話しになります。ここまでで、ガイドライン、そして評価ツールを作りました。次に必要になってくるのは、手軽に画像を圧縮できるツールと、未圧縮の画像がコミットされたときに、それを検知できるCIツールです。rubocopもrspecも、CIで実行されるようにならなければ、きっとこれほど価値を出すことができなかったでしょう。

画像の圧縮については、Gitフックを使って実装しようと考えています。コミット時に自動で圧縮されるので、特に意識せずとも圧縮した画像をGitHubで扱えるようになるかと思います。