はじめに
本日がiRidge Advent Calendarの最終日。そして私lighttiger2505のiRidge最終出社日(1日前)になります。
会社のAdvent Calendarで退職エントリと聞かれた方は、なんで？と言われるかもしれません。
これは上長から「lighttiger2505。最後にAdvent Calendarを書いていってくれ。」と言れたとき、冗談で「ネタがないですね。退職エントリなら書きますよ25日が最終出社日ですし。」と言ったところ。上長がノリノリで、じゃあそれでと言った結果です。
大丈夫かなとビクビクしながら書いております。
iRidgeに入るまで
私のエンジニアキャリアの開始点は出身地の愛知県にある独立系の大手SIerでした。
その会社ではプログラマで開発キャリアを積んだ後、作業工程でいう上流工程へ徐々にシフトし、ひいてはプロジェクトマネージャとして現場を指揮できるようになってほしい。というキャリアパスが用意されていました。
開発という面においては、私が配属された部署は優秀な方が多く、特に最初に配属された職場の上司は相当のスパルタでした。
当時趣味(ゲーム作っていました)程度だった私のプログラミング能力はガタガタで、バグを生みまくるひどく分かりづらいコードを生み出していました。その度に上司に指摘され、製品として提供できるまでの品質を出すためのコードの書き方やテストの仕方、そして設計論などを叩き込まれました。
その後プログラミングから上流工程へ移り、慣れない顧客の打ち合わせが増えていきました。設計のすり合わせや、自分が見積もりした内容を説明をして、私の拙いコミュニケーションで顧客に怒られるといったこともしばしばありました。
次第にそういった説明にも慣れてくると、お客さんにしっかり納得してもらったうえで開発を進めるということを意識するようになりました。私はあくまでエンジニアなので、とにかくコードを書かせてくれと思ったことも何度もありましたが。
集団で開発をするとき関わる人たちの意思統一が取れていないというのは、肝心のコードを書くという作業の上で障害になり得るということを知り。
開発を良くするためにこういった調整は避けられないぞと、コードを書く以外の開発プロセスやアジャイルなどの手法の勉強をするようになりました。
学ぶことは非常に多く、今でも自分の身になっている実感があるスキルがついていった一方で、案件にジョインしたタイミングでほぼ変えられない形で決まっているサーバ構成や言語/フレームワークなどのアーキテクチャや、ウォーターフォールによる作りきりの開発プロセスに、これはシステム開発をする上で本当に効率的なやりかたなのだろうかと、徐々に疑問を感じるようになりました。
今後のキャリアに鑑みて、アーキテクチャや新しい言語。アジャイル開発などのプラクティスを学習していた私は、もしこういった先人の知恵をもとに構築された現代のシステム開発を体現出来たとしたら、どうなるのだろうという興味を持ち。それらを自分がやってみたいという好奇心に抗えなくなりました。
iRidgeでやってきたこと
エンジニアとしてそれなりに身を立てるならば、やはりITが盛んな東京で仕事をするべきであろうと思いたち、東京で転職しようと会社に退職を申し出ました。しかし東京に舞台を移しての就職活動は難航しました。
5年と6ヶ月のエンジニアのキャリアがあるとはいえ、所詮よくいるWebやってみたいな系男子。できる言語はJavaとVB。AWSやGCPはなんだかよくわからないすごいものでした。これではイケイケのベンチャー企業に採用されるわけもありません。
その中で見つけたのがiRidgeという会社でした。
iRidgeの謳っているオンラインとオフラインを繋げるという仕事には非常に魅力を感じました。また1次面接をしていただいた当時のエンジニアのリーダーお二人の雰囲気が非常に良く、なんとしても受かりたいと思いました。そのために1次面接後、拙いPythonコードを書いてWebサービスもどきを一つ作り、絶対受かりたいと必死にアピールしました。
その甲斐あり、なんとか内定をいただくことができました。
自分に割り当てられた広い机と新品のMac、そしてサブディスプレイを見て、あぁベンチャーに就職したんだなと思ったものです。
エンジニアとマネジメントの兼任
iRidgeへの入社当初、自分のもつスキル程度では、まったく戦力になることは出来ないだろうと思っていました。ですが最初に配属されたグループは、企業の公式アプリのバックエンドを作成する受注開発グループであったこともあり、お客さんの思い描いている漠然としたイメージをどう具現化するかお客さんと仕様をどう握るかが、システム開発するうえで大事な部分でした。
その大事な部分を進めるために、プロジェクトマネージャとエンジニアの役割の境界線上に存在する中空に浮いたタスクを、いかにうまくさばくかがプロジェクト成否に大きく関わるポイントでした。
元々前職でお客さんや内部エンジニアにどうOKをもらうのか。タスクをどのように管理すればいいのかを叩き込まれたのもあり。逆にそういいった中空タスクをさばく能力が、そういう経験のないエンジニアと比較して私の強みになっていました。
前職でやっていたことは全然無駄ではなかったと、強く前の会社に感謝しました。
それから徐々に仕様調整やタスクの取り回しなどのマネジメントと、エンジニアリングを兼任するような仕事のしかたをするようになりました。
転職の折、転職ドラフトに登録したのですが。そこで「目標と野望」という項があり、「どのエンジニアよりもマネジメントに優れ、どのマネージャよりもエンジニアリングに明るい人間になること」と記載したのですが、このような方針を持てたのは、このあたりの体験が大きな要因となっています。
技術の面においてもPythonという言語やDjangoというフレームワークがどういうものなのか、AWSというクラウド上のプラットフォームをどう扱えばよいのかという理解を得るたびに、取り得るアーキテクチャの幅がどんどん広がりを持っていくことが非常に楽しくありました。
プロダクト開発グループへの移籍
それからいくつか受注案件の仕事をする上で、弊社の持つpopinfo(現在ではFANSHIPと改名)というプッシュ配信プラットフォームと通信する部分が非常に多くあるプロジェクトに関わりました。その時FANSHIP側の仕様に足りない部分があり、FANSHIP開発をしているプロダクト開発グループのメンバーが忙しかったので、かわりに私が細かい機能追加や改修をしたりする機会がありました。
それがきっかけでプロダクト開発グループにジョインすることになりました。さらにマネジメントを少しやっていたこともあり、ジョインした後に4,5人のエンジニアのリーダーをすることになりました。
私のチームの主な役目は、誕生から8年以上経つFANSHIPの技術的負債を改善していくというものでした。
これをやるにあたって、当時のプロダクト開発グループのメンバーにヒアリングして回り、いくつかのクリティカルな問題を見つけました。その問題を軸に作成した改善計画の結果がDjango Congress 2019の発表内容『自社サービスのDjangoを1.3から1.11LTSにアップグレードするまでの道のり』となりました。Django Congress 2019での発表は私にとって初めての45分の長時間セッションということもあり、ものすごく緊張して発表をしました。
またシステム以外にも問題はありました。プロダクト開発グループのマネジメントがうまく回っていないのは、グループにジョインする以前から実はわかっており、以下のような部分に問題がありました。
- 具体的には機能を追加する決定をするに至ったコンテキストの共有。
- 機能を実装するために辿るべきロードマップとそのスケジュール。
- そして個々のメンバーに対するタスクの割当と進捗のトラッキング。そしてそのリカバリ。
このタイミングはタスクの取り回しを改善する絶好のチャンスだと逆に捉え。以前iRidgeの受注案件で実施したアジャイル開発を適用するために積極的に動くことにしました。
フレームワークとしてスクラムを導入し、スプリント毎で工程を管理する方針を立てました。２週間毎のスプリントの中でスプリント計画会議によるタスクの明確化し、カンバン(物理ホワイトボード)によるタスクの管理と、ふりかえりによる継続的な課題解決を一連の流れとしてチームに浸透させることを開始して一年間やり続けました。
結果としてチームにそれらの流れはなんとか定着し、私の退職が決まった今でも継続して運用されていくようです。
Vimと転職
転職を話すうえで、外せない大きな要因があります。それはVimです。そうあのテキストエディタです。
私がVimを使っている理由は、過去記事でもいろいろと書いています。
iRidgeにおいてエンジニアリングとマネジメントを兼任していた私は、両方のバランスを取る上で重要と感じたことがありました。それは速度です。ここでいう速度とは思考する以外のすべての作業のことで、コーディングからGitなどのファイル操作などもろもろです。
よくある問題として、マネジメントをしているとエンジニアとしての力量が伸びなくて辛いというのはよく聞く話です。仕事の隙間、プライベートの隙間でどれだけのコードを書くのかが、自分のエンジニアリングの伸びにつながると考えた私は、自分の環境を最適化して、作業効率を上げ、空いた時間をいかに本質的な生産性の向上に費やすかということを常に考えるようになりました。
私の今の開発環境はその結果としてあるもので、今でもこの考え方は自分のツールを作るときの大きなテーマになっています。
それから情報収集のために、VimのコミュニティであるMeguro.vimやFablic.vimなどに参加するようになりました。憧れのVimmerの方々とお会いして、テキストエディットについて語りあうことは非常に参考になりますし、何より楽しかったです。
最近もGo言語でつくるインタプリタをやってみたでインタプリタを写経していたのですが、Vimでなければあの膨大な写経量に圧倒されて、コードを書かずに本を流し読みするだけで終わってしまっていたかもしれません。
Golangはじめる
Vimでエディットするのが大好きになった私は、風のうわさでGoはVimと相性バッチリだぞとか、GoはCLIコマンドを書くのに最高だと聞き、Goを書くようになりました。
実際Goの開発ツール郡とvim-goがもたらすVim上のGoの開発体験は、これまでどの言語を書いたときよりも快適でした。
詳しくは過去記事をご参照ください。
これをきっかけにGo Conferenceやgolang.tokyo、GoあんこなどのGoコミュニティに顔を出すようになり。Goを使う企業の活用事例をいろいろと聞くことが出来ました。これは転職活動に大きな影響を与えることになりました。
ちなみに何回か登壇もさせていただいています。来年こそgoconで登壇したいものです。
そしてGoを使い始めた2017年に非常に印象的なカンファレンスがありました。VimConf 2017です。
この年は、VimConfにとって立場を本格的な国際カンファレンスへと切り替えたという大きなターニングポイントであったそうです。そしてこの年のゲストスピーカーはvim-goの作者であるFatih Arslanさんでした。これは聞く以外の手はないと思いました。
VimConf 2017後の私はものすごく興奮していて、以下のような記事を書いています。それほどにVimConfは私に大きな衝撃を与えました。このときからOSS活動でプロジェクトにコントリビュートすること、何らかの形でOSSを世に出すことを意識し始めたように思います。
それから私はCLIコマンドを作ることに傾倒していて、当時仕事で必要そうだったメモを取るためのツールや、その他もろもろをGoで書いてGitHub公開していました。正直ちゃんと他の人が使えるものは多くはないですが。
iRidge在籍中の私の成長の傍らには常にVimがあり、Vimを通してつながるコミュニティがありました。もしVimを使っていなければ、Goでツールを作ることもOSSを意識することもなく、お金を稼ぐために漠然と仕事をしていたかもしれません。
転職
DjangoやPythonの最新化、インフラのECS移行やDockernizeによるローカル環境の充実により、FANSHIPは以前と比較し、開発しやすいモダンな構成になりつつありました。
しかし、以前から抱えている大きな問題はあり、代表例は単一DBに集中されたデータとそれを取り囲む分割サービス郡がによる分断モノリス状態です。2019年はやっとその問題に取り掛かる準備が出来てきたというところでした。
解決する問題はまだ数多くあり、データのデザインを今後のスケールを考慮して考える必要があるという、難しくやりがいのある面白いフェーズですが。ここにきてFANSHIPの向かう方向性と自分のやりたいことにズレを感じるようになりました。
FANSHIPは会社の戦略により、プッシュの配信基盤からマーケティング基盤として変化していました。利用者をマーケティングの担当者にフォーカスし、そのための機能を実装していくようになっていきました。
私のようなエンドユーザ観点からは、活用する企業側の恩恵はイメージ出来ても、そこから放たれるコンテンツがエンドユーザにとって良いものになるというイメージが自身で描けなくなっていることを感じていました。
おそらくこの点に関して、自分の知識不足なところもあるのでしょう。ですがそれが正直な気持ちでした。
上記をきっかけに転職活動を進めるようになりました。転職ドラフトなどのサービスを活用したりもしていたのですが。イマイチピンときていませんでした。
そんなときMeguro.vimに参加し、以前からVimやGoコミュニティでよくお話させていただいていたdaisuzuさん(VimConfに3年連続で登壇をしている方です)に相談したところ、彼の勤めるDeNAを紹介していただくことになりました。
私の大好きなVimに興味を持ってVimConf 2019にスポンサーしている会社様には、一度お話を聞いてみたいと思っていたため。まさに渡りに船でした。
選考の途中、FANSHIPに大規模な障害などありましたが、なんとか内定をいただくことができました。最終的に転職を決めたきっかけは、面接がとても楽しかったことでした。これまでの面接で話したことがないくらいたくさん喋ったことを覚えています。
なおVimConf 2019では、私もLTという形で今年作成したdeoplete-vim-lspのお話でさせていただきました。懇親会で何人の方から、deoplete-vim-lspを作ってくれてありがとうございますと言ってもらえたことは、本当に嬉しかったです。
さいごに
結果iRidgeを辞することにはなりましたが、ろくなスキルもない完全ポテンシャル枠の私を雇っていただいたこと。その上、これまでにない成長の機会と裁量を与えていただき、その成果を評価していただいたiRidgeには本当に感謝しています。FANSHIPという月に数十億ものプッシュ通知を配信する大規模なサーバ/システムを触ることは得難い経験でした。
前述の通り、まだやり残したこと、やりたいことはたくさんある状態ではあります。内定をいただいたあとも、離れがたい気持ちでいっぱいでした。
そして常に私を支えてくれ、エンジニアとしての活動を広げてくれたVim。
そしてそのVimのエコシステムをつくる多くの開発者達とコミュニティに感謝します。