読者です 読者をやめる 読者になる 読者になる

入社して3年が経ちそうなので振り返り

日常

もうすぐ社会人になって丸3年。
いい機会なのでここまでやってきたことの棚卸しをしてみる。

1年目

同期より2ヶ月ほど早く入社し、いきなり新規サービスの立ち上げに参加させてもらった。
僕は2年目の先輩エンジニアの下について、ユーザーのコンテンツ投稿画面のフロントエンドを中心に開発をしていた。

このときAngularJSみたいなフレームワークの導入もできたのに「JSの勉強も兼ねてjQueryだけでやってみよっか」と大きなフレームワークなしで設計/実装にチャレンジさせてもらえたことにとても感謝している。
JSのオブジェクトや関数について理解を深めるきっかけになった。
この時期にJavaScriptパターンを読みまくっていた。

JavaScriptパターン ―優れたアプリケーションのための作法

JavaScriptパターン ―優れたアプリケーションのための作法

サーバーサイドもPHPJavaを使った基本的なwebサービス開発をしていて
学生時代には意識したことのなかったMySQLの基本的なクエリチューニング(といってもEXPLAIN程度のものだけど)も教わった。
ミドルウェアやインフラを意識した開発は初めてだったので新鮮なことが多くてすごく楽しかった記憶がある。

半年ほど経った9月頃には、チームを移ることになった。
次のチームでは海外向けメディアを扱っていて、僕は今に至るまでこのチームに在籍することになる。

1番最初のチームでは作業のほとんどがアプリケーション実装だったのに対し、今のチームではインフラ関連の作業をやることが多くなった。 少し責任範囲が広がった感じ。

当時、先輩が1人で6サイト運用しながら、さらに2サイトの新規開発をしていて 運用するだけで手一杯、アプリケーションにバグも埋もれていたりコードのコピペもあったりと直し放題の環境だったので 1チーム目のときに教わったことをそのままこのチームにも展開していった。

あげだすとキリがないけど
運用面ではJenkinsによる自動化やバッチ実行管理、リリースノートを含むドキュメントの整備、backlogで管理していたチケットの整理と、とにかく散らかってるものを全て整理していった。
アプリケーションに関してはまずコピペ脱却のために各種機能を役割ごとにクラスやモジュールに切り出していく作業をひたすらやっていた。またその過程で見つけた誰も知らないバグをひたすら潰してた。

チームメンバーが兼務だらけで、とにかく散らかっていて整理されてない状態だったことや
プロダクトマネージャーが(幸運なことに)裁量を与えて自由に動かせてくれるタイプの人だったことにより
開発/運用/その他もろもろのいろんな種類のタスクを自分で見つけ、優先順位をつけてつぶしていくコツをこの時期にかなり学べたと思う。

またミドルウェアを触る作業が増え、先輩からインフラ系作業を教わることができた。
MySQLのチューニングやLinuxカーネルチューニング、nginxの設定について勉強し始めたのがこの時期だった。
それ以来nginxが好きで、社内のQiita::Teamにnginxの設定に関する記事をよく書いていた。

また、この時期に勉強したことがISUCONでめちゃくちゃ役立っていて、教えてくれた先輩にはめちゃくちゃ感謝している。 takanamito.hateblo.jp

そういえば仕事をする上で相談することが苦手だった僕が下手なりに相談できるようになったのは、この時期にミドルウェアに関する相談をこの先輩が嫌がらず聞いてくれたおかげな気がする。

年が明けるころには大きなインフラ移設も行っていて
さくらVPSで動かしているメディアが成長していき、スケーラビリティと地理的な条件からAWSに移行することになった。

設計からサービス無停止での移行の実作業を1人でやることになった。
この作業はかなりきつくて、そもそもインフラはどうやって設計するものなのか、どう考えて組み立てていくのかなどなど
何がわからないのかもわからない状態だったと思う。
とにかく理解を深めるために、既存のインフラをAWS上で再現するために必要なリソースをリストアップして図に起こしていく作業をやっていた。

この時期にゼロからWebサービスを作る時に必要な

  • 自分の考える理想的な構成を描く
  • 現実的な条件をもとに松竹梅程度の選択肢に落とす
  • 選択肢のグラデーションの中から最適解を探す

みたいな考え方を学べた。

移行が終わってからは少し落ち着いたので、当時流行り始めていたリアクティブプログラミングの流れに乗ってriot.jsを触ってみたり
レコメンドエンジンに触れたりしていた。 takanamito.hateblo.jp

2年目

2年目はチームの開発サイドリーダーとなって、自分がメイン開発者としてサービス開発を進めることが多かった。 また会社がPHP, JavaからRubyScalaへ移行することになり、Railsでのアプリケーション開発の先陣を切ることになる。

全社的にテストの重要性を意識しはじめ、CircleCIの導入を始めたりとやっと少しナウみのある開発ができ始めた。
同時にmocha, chaiを使ったJSのテストも導入したりと、作ることに対しての余裕ができて
普段の開発に効果がありそうな、自分なりのプラスを取り入れることができるようになった気がする。

それまでどのチームもテストゼロ、誰が何を作ってるのかもわからないような状態だったので
この時の開発体制の大改革はとてもありがたかった。

チームの人数が増え始めたことで、イテレーション運用をより力を入れて回すことになり 開発スケジュール管理やディレクションに関して大きな時間を割いて関わることになる。

チームのエンジニアリーダーである自分が進捗管理をしつつ、ディレクションも手伝いつつ、自分でもアプリケーションを書いていたので
特にリリース間際の佳境に差し掛かった時期には仕事をする時間が増え、見事に腰を破壊された。

年末から年明けにかけてはFuelPHP -> Rails移行のプロジェクトもあり 数十万URLの301リダイレクト処理にビビりながらも特に大きな事故なく終えることができた。
このあたりから社内勉強会で話す機会を少し増やしたり、外の勉強会でLTをするようにした。 takanamito.hateblo.jp

3年目

2年目につくったサービスのトラフィックを伸ばすための改善、運用コストを下げるための施策を中心にやっている。

インフラ移設時に手動でコンソール画面をポチポチして立てていたAWSのインフラを TerraformとItamaeの導入を進めて自動化したり (Docker導入もやりたい) takanamito.hateblo.jp

A/Bテストをリリース速度重視で行うために
今まではmunin, nagiosでやっていた監視に加えて、Datadog, Sentryを使った監視や可視化の仕組みを導入したり

A/Bテストのためのログ解析要望も高まり、fluentdとelasticsearchを使ったログ蓄積基盤を作ってサービス改善のためのログを取り始めたり
その過程でけっこうメジャーなfluentdのプラグインやsunspotといったでかいgemにPR送ったりするOSSっぽいことも始めた。

効率化という文脈では、対象を自チームだけに絞らず
趣味で社内Gyazoサーバーを立てたり、サーバーレスHLS動画配信の仕組みを作ったりして
業務に関係ないことで新しい技術には触れるようにしている。(この取り組みが自分のチームに還元できるとうれしい) takanamito.hateblo.jp

所感

3年間webアプリケーション開発に関わってみて
新しい技術を学ぶのももちろんだけど、今ある環境や生活に非効率なものがないか見渡して
それを解決することが合っている気がしてきた。

  • nginx
  • S3, Lambdaなどのいわゆるサーバーレス系サービス
  • HLS

あたりの技術が自分の中ではしばらくホットで、全部に共通しているのが
「自分の実現したいことが楽に実現できる」ということ。

すごく頑張っていいコードが書けたときもうれしいけど、やりたいことに対して「◯◯使えば一瞬で終わるしみんなが楽だ」って気付いて実現できたときの喜びのほうが大きい。

チーム内でも、もっと効率化できるとこあるなぁと思いながらも
ここ1年くらいは開発以外の業務量が増えていたという事実もあり
最近はそういった仕事の量を相談して減らして、開発に集中させてもらっている。

インフラ作業が多く、特にサービスの特徴的にもフロントエンドの重要性が低いので
しばらく触れていないJSを中心にSPAにも触れていけると楽しくなりそう。