Kazu's Log

Jun 4, 2016

転職して (もうすぐ) 4年

アマゾンで働きはじめてそろそろ4年がたつ。正直に告白すると、ずっと6月に入社したと思ってこれを書いていたんだけど、書き終えてから7月だったことに気づいた。

前職のミクシィは4年と数ヶ月で辞めてしまったので、もう半年もすると、ここが人生で一番長く働いた会社ということになる。そう考えると結構感慨深い。

最初の2年と少しは東京の目黒で、そこから縁があって本社に転勤して、いまはアメリカのシアトルで働いている。

継続的デリバリー

目黒の頃のチームでは、リードしていたエンジニアが継続的デリバリーに熱心だった。前職で Buildbot や Jenkins を使っていた親近感もあり、このあたりの社内資料は色々と読みあさっていた記憶がある。

アマゾン内での継続的デリバリーと、そのためのソフトウェアである Pipelines の話は AWS CodePipeline のリリース時のアナウンス でも少し触れられている。

我々は一度コードがチェックインされてから本番環境にデプロイされるまでに時間を計測した後で、独自の継続的デリバリーサービスを開発しました。その時間はものすごく長く、我々の開発チームが開発した機能がお客様の手に出来る限り速く届くと感じられるように挑戦するだけに十分な量でした。

更なる調査により、ほとんどの時間が実際のビルドやテストやデプロイの時間に使われていないということがわかりました。その代わりに、手動のチケット駆動のチーム間の連携が深刻に邪魔をしているということがわかりました。待ち行列にチケットが入ると誰かがそれに気づくまで待って、ビルドとテストの結果はレビューされるまで放置され、それらを動かすために人間から人間への通知が送られる必要がありました。

この、お客様から逆算して、全体をみたゴールをなんとか数字に落として、それをソフトウェアの導入で改善していく、という流れは、当時の私には結構ショックだった。今こう書くと恥ずかしいけど、私にとっての開発環境の改善は「モダン」な環境というのをどこかで見かけて、それと日常との差異をみつけて、それを輸入していく作業だった。そこには大局観みたいなものが欠けていた。

もちろん、継続的デリバリー自体は業界全体で流行っていたので (IMVU の Timothy Fitz が Continuous Deployment を書いたのが2009年で、Matrin Fowler のシリーズから Continuous Delivery の本が出たのが2010年)、それを取り入れた部分も多分にあるだろう。ただ、こういう全体をみたゴールがあったら、前職の私も、自動テストからデプロイにまで踏み込んでいただろうかと、いまさら詮無いことを考えていたのを覚えている。

運用と開発

そもそも、開発チームがデプロイをすること自体が、私にとっては新鮮だった。スタートアップに勤めている人にすると「デプロイしないほうが新鮮だよ」とバカにされそうだけど、でも、デプロイや運用にまつわる色々に手を出すようになったのは、転職してからのことだ。

これを上手く実現するには、いくつかの前提がある。

まず、それなりにホストごとの機能分担が進んでいて、自分が運用する部分と開発した部分が一致していること。いまだったら「マイクロサービス化」というのかもしれない。

次に、前述した継続デリバリーのためのソフトウェアや、The Story of Apollo - Amazon’s Deployment Engine で紹介されている Apollo をはじめとする色々な社内ソフトウェアがあって、デプロイにまつわる負荷をある程度軽減していること。

そして最後に「運用も開発の一部である」という文化的な合意があって、障害時には、たとえ夜中でも運用と開発が協力して作業にあたるのも厭わないこと。まえの2つは最初から完璧にする必要は無い、というか開発が運用に絡みはじめることで改善されていく面もある。でも、この最後の合意なしで、開発者が積極的にデプロイして、運用がその障害対応に消耗するようになってしまうと、それは組織全体として不健全だと思う。

開発と運用の分担は、社内でもチームや担当するサービスによって差異があるはずで、私も自分の周りの事例しか知らない。ただ、分業と専門化が進むはずの大企業で、開発が運用の仕事もしているのは面白い。ホッピングの話のつづき の言葉を借りるなら、これは規模から導かれる所与の特徴に逆らう、誰かが頑張って刻みこむ後天性の美点だと思う。

東京から遠く離れて

私がミクシィで働いていた時期は、いわゆるガラケーからスマートフォンへの移り変わりの時期で、Twitter と Facebook が流行りだした時期でもあった。

これらアメリカから来た「黒船」を見ながら、私は時折「東京に通勤する日本語が話せる人だけで、ソフトウェアを書く理由はなんだろう?」というのを自問していた。「日本というのは他の国々とちがう特殊な社会なので、アメリカから直接輸入したようなソフトウェアでは、人々の欲求を満たしきれない」というのが私の答えのひとつで、でも、少しだけためらった後に Facebook に実名を公開してしまう人々は、それを否定しているように見えた。

自問自答に関する答えはまだ出ていない。東京やシアトルに通勤する人とも、日本語が話せない人とも働くようになって、他人事になってしまった部分もあるし、日本では Facebook Messenger でも WhatsApp でもなく LINE が使われる特殊な市場になっていて、一方でミクシィはゲームで上手くやっているのを見ると、当時の私は悲観的すぎたとも思う。

近況とこれから

今年の頭ごろから新しいチームに入って、また新しいサーバーを書いている。

転職してから、仕事の話を表立ってすることは減っていて、これは少し不本意だ。なにかと集まって勉強会をしている東京の人々や、仕事でオープンソースなソフトウェアを開発しているグーグルの人々を羨ましく思うこともある。

それでも、突然 Ion (ひらたくいうと “Amazon’s JSON” だけど何故か S 式 がある) がオープンソース化されたり、WebDevCon という社内向けにやっていたフロントエンドむけカンファレンスが一般登録可能になったり、アマゾンジャパンのほうでも、Amazon Japan Development Center というのが出来て、エンジニア向けのインターンシップ を大々的に募集したりと、会社自体は、昔よりはオープンになってきていると思う。

新しいチームは、コードベースが新しくて謎な部分が少ないのと、時代の潮流なのか関数型の雰囲気があり、だいぶ気に入っている。しばらくはここで働ければと思う。

その先に何をするか、というのはあまり考えられていない。キャリアのゴール、せめてマイルストーンを持ちたいというのはここ数年来の TODO だけど、どこから手をつけるべきか分からないままでいる。