CBcloud Advent Calendar2019 一日目の記事の続編となります。

前職との相違点

前職はフロントエンドに完全に集中して実装することが許される環境でした。
相違点を簡単にまとめてみます。

前職

※所属していた会社そのものではなく、常駐先の環境となります。

大企業
客先常駐
応答率90％以上の完璧なレベルのヘルプセンターで、エンジニアがユーザーの問い合わせに直接対応することがない。
完全な役割分担がなされ、フロントエンド実装のみが我々のチームに依頼されてくる。
- フロントエンド系のバグ修正。
- 新機能のフロントエンド実装。
障害が起きた場合、専門のチームが対応。
マーケティング部門で入念に検討・分析・企画された上で具体的な案件としてチケットが作られ、エンジニアが対応する体制が確立されており、スケジュールも余裕を持った期間が取られている。
エンジニアがたくさんいる

CBcloud

ベンチャー企業（スタートアップ）
本社勤務
問い合わせについて一次対応者が返答できない場合に、その問い合わせが直接エンジニアに回ってくる。¹
役割分担がなく、インフラ・バックエンド・フロントエンドをできる人がメインでやり、興味があればいくらでも手を出せる。
依頼内容・実装の要望がフロントエンドに収まらず多岐にわたる。
障害が起きた場合、自分たちが直接対応する。
差し込み対応が多く、短い期間で可能な限りを実装することが多い。
エンジニアには機能開発全体を任されている
エンジニアは少数

フロントエンドだけでは、できることに限界があった

新機能実装をする場合、前職だとフロントエンドだけを担当し、他は任せきりで何の問題もありませんでした。
現職の場合、機能開発全体をやり切る必要があり、UIだけでなくサービスの仕組みづくりそのものが求められています。

おのずとフロントエンド実装のみで対応する場合、できる範囲に限界が見えてきました。
実は入社した時から「フロントエンドは教えるので、バックエンドを教えてください」と言っており、
それもあって少しずつScala、そしてRubyを書いていくことになります。

ログイン処理の変更

急にScalaの案件を任されたと思ったらこれだよ！
2週間ほど苦しんだ覚えしかありません。

ここがとっかかりで、他にもScalaコードの修正対応を続けていくことで経験を重ね、
データの変更などの処理がある程度書けるようになり、リファクタリングもできるようになりました。

パスワード再発行画面＋API

こちらはいろいろあってRuby on Railsです。
Grape環境を入れる所から始めました。
やはり環境作りと実装で2週間ほど苦しみました。
Rubyのif文の書き方やmapなどの構文も最初はおぼつきませんでしたが、リファレンスを読んだり、他の詳しいエンジニアに都度聞きながら覚えていきました。²
とはいえ、Rubyの実装自体はScalaに比べると素直に書けるので、一番の鬼門は環境構築だったと思います。
今ではデータを変更するだけなら難なくできるようになりました。

クエリのチューニング

入社当時からサーバーが不安定になることが度々あり、
フロントエンドだけ行っているときは手出しできない領域でした。

少なくとも結合用のキーにはindexを貼ること
スローログが出ている怪しいクエリはexplainで計測すること
クエリを見直し、不要なサブクエリが発行されている箇所を改善すること

しかし、他のエンジニアと一緒に解決していったことで、クエリのチューニングができるようになりました。

データ分析・統計・可視化

前職だとSQLを全く触る必要がなかったのですが、
SQLツールを当たり前に使い、データ出しや分析のためにクエリを書くことが増えたため、
必然的にMySQLクエリを書くスキルが磨かれました。

Metabase

毎回生のクエリを書いて出すのは大変＋データ出し用のページを実装するのも手間ということで、
Metabaseを使うようになりました。
変数も使えるので可変になる部分は変数で定義しておけます。

Metabase環境構築自体はつよつよエンジニアに任せてノータッチだったりしますが、
出来上がった環境で現在までに50個ほどクエリを書いています。

GoogleDataPortal

他のエンジニアからすると「使いにくい、わかりにくい」との評価でした。
ただ、実際使ってみるとGoogleスライド＋データの可視化ツールといった感じで、
GoogleスライドとMySQLが使えれば使えるという感じで、
今までDBに持っているだけだったデータの可視化に大きく貢献してくれています。

これらのサービスを使うまでは独自のページを実装したり、依頼の都度SQLツールでクエリを叩いてCSV出力する泥臭いことが多かったです。
metabaseやGoogleDataPortalを使うと、クエリを書くことに集中できる＋URL共有できる＝Slackで簡単に伝えられるので便利です。

また、事業会社で重要な「日々の数字を意識すること」がグラフ化・可視化されたことで行いやすくなりました。

個人向けサービスの改善企画

MySQLのクエリを本格的に書かざるを得なかったのがこの案件でした。
当時Excelは使えたのですが、Select文とwhere句を覚え立ての段階でやりました。
CSV化したデータをExcelに張り付け、どこの数字を上げると、最終的な売上に一番貢献するのかを算出し、
それを基にやるべき施策を導き出しました。

感覚ではなく、データを基に企画し、施策を決めるという初めての経験でした。
作ったExcelデータについては予想以上の分析を提示できていたらしく、CEOから好評だったようです。

やれることをいろいろやったら、身についた

いろいろやったら、スキルが身についてきました。

今の自分にできないことを簡単にできる凄い人を見ると「神だ！」と思ったり、
「自分にはとてもできない！すごい！」と感じて終わったりすることが度々あると思います。

しかしながら、「神」と崇めているだけでは何も技術は身につかないですし、
最初は何もできない所から始めて当然なので、無暗に崇め奉らないこと、
「自分もやってみよう」と考えてみることが大事なのかな、と今では思っています。

contributions

参考までに2016年〜現在までのGitHub contributionsの数を載せておきます。
扱う領域が増えた分、自分が編集する箇所も増え、contributionsが年々増えていっているのが分かります。

年	contributions
2016	13³
2017	1064
2018	1601
2019	2230

まとめ

フロントエンドだけだと機能開発が1から10まで出来ない
教えてもらったり調べたりして、ScalaとRubyを覚えた
SQL文が書けるとどこに行っても役に立つ
データ可視化ツールを活用して、本質部分に集中する
「神」で思考を止めないこと

電話応対を直接行うわけではなく、電話応対している方がSlack上で問い合わせてくるため、そこに回答を提示する形。入社当時は電話応対者がいない場合に直接電話対応することも、無くはなかったです。 ↩
このRubyに詳しいエンジニアはPickGo以外のプロダクトを担当していたため、環境を作ったり直接実装するのは私の担当でした。 ↩
前職だとコミットはGitHub Enterprise上だったので、寂しい数値となっています。 ↩