はじめに
本日が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 Congress2019の発表内容『自社サービスのDjangoを1.3から1.11LTSにアップグレードするまでの道のり』となりました。Django Congress2019の発表は私にとって初めての45分の長時間のセッションということもあり、ものすごく緊張して発表をしました。
またシステム以外にも問題はありました。プロダクト開発グループのマネジメントがうまく回っていないのは、グループにジョインする以前から実はわかっていました。
- 具体的には機能を追加する決定をするに至ったコンテキストの共有。
- 機能を実装するために辿るべきロードマップとそのスケジュール。
- そして個々のメンバーに対するタスクの割当と進捗のトラッキング。そしてそのリカバリ。
それらの流れがうまく回っておらず、この問題をうまく正すことも課題の一つでした。これについては、以前iRidgeの受注案件で実施したことのあるアジャイル開発を適用し、タスクの取り回しを改善する絶好のチャンスだと逆に捉え。積極的に動くことにしました。
フレームワークとしてスクラムを導入し、スプリント毎で工程を管理する方針を立てました。２週間毎のスプリントの中でスプリント計画会議によるタスクの明確化し、カンバン(物理ホワイトボード)によるタスクの管理と、ふりかえりによる継続的な課題解決を一連の流れとしてチームに浸透させることがその狙いです。
結果としてチームにそれらの流れはなんとか定着し、私の退職が決まった今でも継続して運用されていくようです。
Vimと転職
転職を話すうえで、外せない大きな要因があります。それはVimです。そうあのテキストエディタです。
私がVimを使っている理由は、過去記事でもいろいろと書いています。
iRidgeにおいてエンジニアリングとマネジメントを兼任していた私は、両方のバランスを取る上で最も重要と感じたことがありました。それは速度です。
よくある問題として、マネジメントをしているとエンジニアとしての力量が伸びなくて辛いというのはよく聞く話です。仕事の隙間、プライベートの隙間でどれだけのコードを書くのかが、自分のエンジニアリングの伸びにつながると考えた私は、自分の環境を最適化して、作業効率を上げ、空いた時間をいかに本質的な生産性の向上に費やすかということを常に考えるようになりました。
私の今の開発環境はその結果としてあるもので、今でもこの考え方は自分のツールを作るときの大きなテーマになっています。
それから情報収集のために、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を使っていなければ、Goを使いツールを作ることもOSSを意識することもなく、お金を稼ぐために漠然と仕事をしていたかもしれません。
転職
DjangoやPythonの最新化、インフラのECS移行やDockernizeによるローカル環境の充実により、FANSHIPは以前と比較して開発がしやすいモダンな構成になりつつありました。
しかし、以前から問題になっていた単一DBによるデータ集中と取り囲む分割サービス郡がいる、分断モノリス状態という大きな課題は残っており。やっとその問題に取り掛かる準備が出来てきたというところでした。
解決する問題はまだ数多くあり、データのデザインを考える必要があるという難しくやりがいのある非常に面白いフェーズですが。ここにきてFANSHIPの向かう方向性と自分のやりたいことにズレを感じるようになりました。
FANSHIPは会社の戦略により、プッシュの配信基盤からマーケティング基盤として変化していました。利用者をマーケティングの担当者にフォーカスし、そのための機能を実装していくようになっていきました。
私のようなエンドユーザ観点からは、活用する企業側の恩恵はイメージ出来ても、そこから放たれるコンテンツがエンドユーザにとって良いものになるというイメージが自身で描けなくなっていることを感じていました。
おそらくこの点に関して、自分の知識不足なところもあるのでしょう。ですがそれが正直な気持ちでした。
上記をきっかけに転職活動を進めるようになりました。転職ドラフトなどのサービスを活用したりもしていたのですが。イマイチピンときていませんでした。
そんなときMeguro.vimに参加し、以前からVimやGoコミュニティでよくお話させていただいていたdaisuzuさん(disuzuさんはVimConfに3年連続で登壇をしている方です)に相談したところ、彼の勤めるDeNAを紹介していただくことになりました。
私の大好きなVimに興味を持ってVimConf 2019にスポンサーしている会社様には、お話を聞いてみたいと思っていたため。まさに渡りに船でした。
選考の途中、FANSHIPに大規模な障害などありましたが、なんとか内定をいただくことができました。
最終的には面接がどれだけ楽しかったのかを基準にしました。これまでの面接で話したことがないくらいたくさん喋ったことを覚えています。
なおVimConf 2019では、私もLTという形で今年作成したdeoplete-vim-lspのお話でさせていただきました。懇親会で何人の方から、deoplete-vim-lspを作ってくれてありがとうございますと言ってもらえたことは、本当に嬉しかったです。
さいごに
結果iRidgeを辞することにはなりましたが、ろくなスキルもない完全ポテンシャル枠の私を雇っていただいたこと。その上、これまでにない成長の機会と裁量を与えていただき、その成果を評価していただいたiRidgeには本当に感謝しています。FANSHIPという月に数十億ものプッシュ通知を配信する大規模なサーバ/システムを触ることは得難い経験でした。
前述の通り、まだやり残したこと、やりたいことはたくさんある状態ではあります。内定をいただいたあとも、離れがたい気持ちでいっぱいでした。
そして常に私を支えてくれ、エンジニアとしての活動を広げてくれたVim。
そしてそのVimのエコシステムをつくる多くの開発者達とコミュニティに感謝します。