Amazon を退職してAutify に入りました

7 年勤めた Amazon を辞めて、Autify という startup に Technical Support Engineer として入りました。場所は変わらず Vancouver, Canada のままです。これからは副業も何かやってみようと思っているので、お気軽にお声がけ下さい。

Amazon で学んだこと

1 つ前の entry が Amazon EKS のチームに移った話で、もう辞めてしまう話になってしまったのは少し残念ではありますが、EKS でも S3 の時と変わらず、人があまり触らない様なところを拾い続けることで存在感を出す形になっていました。例えば、運用で使う CLI の build や deploy が tool によってまちまちになっていたのを統一してみたり、AWS 特有の新しい region を立ち上げる時に自分達の service を bootstrap する作業の効率化だったりです。この辺は Amazon 内部だと team を移ってもさほど変わり映えしないので、いくらでもやれる一方で、個人的には新鮮味がない状態ではありました。

それから、機能開発にも(ようやく！)携わることができて、Amazon EKS Connector の一部実装を行いました。ここでも、機能そのものというよりはその周辺で必要になるもの、具体的には Amazon では Canary と呼ばれる継続的に integration test を回し続けて監視する仕組みを実装しました。色んなものをうまく繋げてあげないと Canary の実装は難しいので、僕がやってよかったと思います。

というわけで、EKS の前の S3 の時と合わせて約 3 年半ほど Amazon の Systems Development Engineer として働いてみました。元々、これ以前には 1 年ほどしか開発の経験がなかったのですが、Solutions Architect として cloud service と関わる内に、どうしても中がどういう仕組みで(system だけでなく組織も)動いているのかを見てみたくて、苦労の末に internal transfer をしました。その辺りの話はこちらに。

最初は右も左もわからなかったものが、3 年後には Senior に promotion することもできて、複数の team でも働くことができました。特に、文書を書く技術とコードを読む技術は飛躍的に上がって、自分の武器になりました。

Distributed system や Fault tolerant の仕組みについてはしっかりと体に染み付いたので、cloud/SaaS の作り方なら一通り best practice を語れるくらいにはなりました。この辺は、まぁ向こう 5-10 年くらいは変わらないので、普遍的な知識として持っておいて損はないです。特に cell architecture は cloud の最先端技術なので、cloud/SaaS を開発している人は cell architecture を知っておくとこの先生き残れます。cell architecture について知りたい方がいればいつでも声かけて下さい。以下の re:Invent の発表などが参考になります。

また、S3 の様に 10 年以上熟成された system と、 EKS の様にまだ数年だけど劇的に巨大化してしまった system の両方を見てきて、どの様に技術的負債が溜まっていき、返済するにはどういう手法をとると有効なのか、またはどうすればそもそも負債を少なくできるのか、といった勘所も否が応でも身につきました。この辺は言語化は難しくて匂いがするものなんですが、1 つ明確に言える例は、resource の ownership を早いうちから適切に扱わないと、割と短い時間で大きな負債として返ってきます。この辺も話が聞きたいという方がいればいつでも声かけて下さい。

それから、いかに安全に deploy や operation を行うか、という知見も相当に磨くことができました。CI/CD はもちろん、それをいかに監視や dashboard と関連づけるか、どういった deploy が安全なのか、どうやれば risk を減らすことができるのか、といった話もこれまた普遍的でずっと役に立つ技術なので、これからも有効活用していきたいです。取り急ぎ、これらについても話を聞きたいという方がいれば（略

大企業で働くことに飽きた

ここからは、なぜ転職したのかという話です。1 つには、Amazon の前も含めて僕は大企業でしか働いてこずに、かれこれ 10 年以上経過してしまって、そろそろ飽きてしまったというのがあります。大企業では、人や team 間での交渉や政治が重要というか、それがないと仕事が回りません。大企業じゃなければそれが不要かというとそんな風には思いませんが、大企業で働いていると交渉や政治が主になってくることが多くて、これは Software Engineering なのか？と疑問を持つことも多かったです。

Startup の様に小さい組織が、どのような理屈で動き、そしてどうやって大企業になっていくのか、という部分は自分ごととして体験したことがなかったので、ちょうどいい時期かなと思って転職を決めた、という部分はあります。また、そういう環境において、自分がどういう風に振る舞うものなのかを自分でも見てみたかったです。僕は多分大企業ではうまく生き残れる質だと思うんですが、startup だとどんな感じになるのかを直接体験してみようという気持ちもありました。その結果を踏まえて、5 年先くらいに何をするかを考えることになると思います。

Software Engineer として働くことに飽きた

念願かなって Software Engineer として働いてみましたが、先日人に言われて改めて気づいたのが、僕は Software Engineer になりたかった訳ではなくて、Software Engineer をしてみたかっただけなんですね。これに限らず、僕は知らないことをやってみるのが好きな質なので、裏を返すと基本的にはすぐ飽きてしまうのです。なぜなら、やってみてしばらくすると何が起こるのか予測ができるようになってしまうからです。予測が難しく何が起こるか分からないのが楽しいんだけど、3 年もやると目新しいことがなくなってきました。ちなみに、Solutions Architect でも同じ様な感覚があって、結果として 3 年半で role change する形になりましたので、これはもう繰り返しですね。

それから、Software Engineer はいまや花形の職種で引く手数多な状態ですが、僕はそれがどうも性に合わないようです。Software Engineer の position の多くは替えが利くものです。もちろん、高度な技術を扱える人は希少ですが、大企業になってくると、難しくはないけれども誰かが実装しないといけない、といった類の仕事が増えてきて、個々人の level よりも人数そのものが重要になってきます (もちろん、高度な技術によってそうした人海戦術の規模を抑えることができる場合も多いですし、そういう仕事は楽しいです)。僕がそうした土俵でずっと戦いたいかというと全くそんな気がしなくて、それが多分僕が coding test の対策をどうしてもやる気がおきない一番の理由なんだと思います。

また別の軸としては、Software Engineer は自分が担当する system については文字通り上から下まで責任持って自由にやれます(“You build it, you run it” でした)が、担当外のものについては結局手が出せないことが多いなと感じました。言い換えると、自分が手を出せる範囲が非常に狭く深いです。僕はより幅広くものを見て影響を及ぼしたいので、これは結構 stressful でした。より広い範囲に同じ level で貢献できるような仕事の方が良くて、1 つには更に promotion するというのが選択肢としてあるんですが、また何年もかかるのを待つ程には情熱はないなと感じました。

そんなところが煮詰まって、こんな tweet になりました。

Autify の Technical Support Engineer

縁あって、4 つの startup と interview をして全て offer をもらいました。そのうち 2 つが Software Engineer で、もう 2 つが Support Engineer でした。どれも金額的には遜色なくて1、それ以外でそれぞれに良いところがあって中々悩みました。Autify にした決め手としては、Series A 直後でまだ stock option がそこそこ貰えるところと、CEO 近澤さんの狂おしいくらいの執念2、そして何より Technical Support という未経験の role への挑戦が大きかったかなと思います。

Autify は UI の testing automation を提供していて、その Technical Support なので必然的に browser や JavaScript について深掘りしていくことになります3。 僕は frontend については仕事で扱ったことは無くて素人なんですが、つい最近この blog を Gatsby にする時に触ったことがあったお陰で何とか interview を通ることができました。入って間もないですが、Chrome や ChromeDriver の code をちょこっと読んでみたりとかもしてて、今まで自分の知らなかったところを探求できているので楽しくやっています。ちなみに、Amazon で超巨大な code base を読み解く術を身につけたので、それと比較すると今の Autify の code base の規模感は赤ん坊みたいな小ささで可愛げがあります。

Technical Support Engineer がいいなと思った理由は、お客さんの課題を直接的に知ることができて、それを service 改善に自分でつなげやすいと思ったからです。Software Engineer だと、どうしてもそうした今起こっている課題を間近で見る機会というのは減ってしまって、ともすれば今開発しているものが一体何のためのものだったのかブレてしまうこともありがちです。Amazon で Software Engineer やっている時にはこのお客さんとの距離感が辛くて、feedback では毎回提言していました。更に、Autify の Technical Support Engineer は code contribution も期待されているので、例えば ticket 対応で見つかった bug を自分の手で直してしまうなんてことも可能です。これは Autify がまだ小さいからできている部分もありますが、僕としては service 開発側ともお客さんとも距離が近いままに、software engineering ができるというのは良さそうな感じがしています。

今後の働き方

僕は Autify の US team なので、Pacific timezone で働きつつ、夕方には日本の人と meeting があったりなかったり、という感じで基本は今までと大して変わりなく働いています。それに加えて、Amazon の時には難しかった副業をやりたいなと思っています。今回 offer をもらった startup はどこも副業に関して細かく規定するところはなかったように、これからはより柔軟な働き方もしていきたいと思っています4。

どんなことをやれば効率よく稼働できるのかまだわかってないですが、ひとまず Solutions Architect の時にやっていたような、よろず相談みたいのであれば時間さえあえばいつでも対応できるので、そんなところから始めてみようかと思っています。それに限らず何か僕に仕事を頼みたいという方がいればお気軽にご相談ください。そのうちちゃんとした site とか作りますが、distributed system や operational excellence が得意分野で、code はどんな言語でもすぐ読み書きできるようになります。

もちろんAutify も積極採用中ですので、ご興味ある方いればいつでもご相談下さい。

その先へ

本当はこの Retweet 元くらい drastic に変えたかったんですが、まだそれくらいの覚悟は僕にはないようでした。

ひとまずは、本当は去年やりたかったんだけど、小説書くのを目標にして少しずつ変化させていきたいと思います。

Footnotes

  1. ちなみに、Amazon でもらっていた給料(RSU 込)と大差がなくて、startup ってそんなに出せるものなのか、という思いと、もしかして僕は Amazon ではそんなに給料もらっていない方なのか？という思いが交錯して微妙な気持ちでした。 ↩

  2. この辺の blog を読んでました。 https://chikathreesix.com/burning-needs https://chikathreesix.com/aiming-for-no1-in-the-global-market ↩

  3. Autify for Mobile も始まっているので、Mobile の仕組みもこれから学べるので良いです。 ↩

  4. 例えば、この次の会社を選ぶ時に副業で先に関わってから選ぶなんてことができるとすごく良いなとも思ってます。 ↩