いわゆる「webサービス業界」というものに入ってから、今年の12月で丸5年が経とうとしている。
一般的に使われる「web業界」（もう死語かな）ではなく「webサービス業界」と書いたのは、「作って別の組織に納品して終わりというスタイルの開発だけではない開発をするようになってから5年が経とうとしている」という意味で区別したかったので、本エントリではこのように書くことにする。因みにそれ以前はSIerと受託開発をしていた。
この5年間はどんな5年間だったかを一度ここらで振り返っておきたい。
最初の3年間
完全に自分の力を伸ばすための期間だった。
当初の所感とかは以下のエントリに書いている。
serihiro.hatenablog.com
serihiro.hatenablog.com
この業界でやりたいことも将来やりたいことも何も考えずに、ひたすら自分のスキルを伸ばして、業界内での存在感を出そうとしていたように思う。とにかくエンジニアとして周りと比べて劣っている自分を何とかする、ということしか眼中になかった。
当時具体的にやったことを書いていく。
まず与えらえた仕事はかなり必死こいてやった。スキルも大したことがなかったので「必死こかざるを得なかった」というのが正解かもしれないが、とにかく早く、正確に、与えられたタスクをひたすら消化することに集中していたと思う。
夜9時に退社するのも普通に感じてたのもこの頃だった。自宅で勉強することよりも職場で学べることの方が圧倒的に多かったので、職場で大量に仕事をこなすことが一番の近道だと信じていた。実際、自分よりも何年もキャリアが長くスキルも高い先輩に囲まれて、とにかく自分が頑張れば頑張るほど自分の成長が見えて楽しい時期だったし、仕事もそれなりに上手くいっていたように思う。
この間、仕事で使う言語もjavaとrubyの２つの言語を経験したことで、静的型付け言語と動的型付け言語の両方のpros/consを学ぶことができた。どちらもOOP言語だったことで移行がスムーズだったように思う。その前のphp→javaが結構大変だったのに対して。
仕事以外の活動として、勉強会を主催するようになった。渋谷javaという、今でも別の方による運営が続いてる勉強会を立ち上げて、自分で運営して、ついでに自分も発表するというようなことをしていた。
ただ、当時はjavaを極めてjavaで一生食ってこうなんていう気持ちはあまりなかったように思う。自分自身が色んな勉強会に出るようになったことで感じたミュニティの力の大きさに感動して、とにかくコミュニティに貢献したいという気持ちと、自分のプレゼンスを上げて会社外でも名前を知られる存在になりたいという感じの自己承認欲求が主なモチベーションだった。
それを実現するためのテーマとして、当時仕事で使っていたjavaを選んだという感じだった。実際、このころ何かjavaについて取り立てて詳しい訳でもなく、OSSのプロダクトも作っていなかったから、発表した内容はせいぜい自分が見つけた便利なライブラリ紹介をする程度に留まっていた。それが限界だった時代だった。
今でこそembulk、digdagといった著名なjava製のツールをソースレベルで仕様を調べてそれなりに使っているので、もう少し気の利いた話を出来そうなものである。しかし、当時の自分にとって、javaはwebアプリケーションを書くための言語という位置づけでしかなかった。そもそもwebアプリケーションを書くのが自分が出来る精いっぱいのことだったし、それ以外の世界を知らなかった。
次の2年間
10年後ぐらいにこの2年間を振り返った時、大きなターニングポイントになった2年間だったと自分が評価するであろう期間だと思っている。
この2年間で大きく変わったのは自分への評価だ。
それまでは、最初の3年間が終わるその時まで、自分は同業者に対してものすごい劣等感を感じ続けていた。そしてそれをモチベーションに仕事をしてきた節があった。
しかし、この2年間でその劣等感はだいぶ払拭されたように感じる。単なる思い込みや驕りかもしれないが、一応webアプリケーションを書いてる人間としては、そこそこ出来る方の側に属するのではないか、と感じるようになった。
転職して仕事のスタイルが大きく変わったことも大きい。以前、以下のエントリにも書いたが、セルフマネジメントをしなければならない領域が最初の3年間と比べて大幅に増えた。
serihiro.hatenablog.com
具体的な指示もない中で自分で会社にとって何が必要か、今何をすべきかを必死に考えて実践しなければならなくなった。恐らく世の中のスタートアップと呼ばれる企業はどこもそのような要素を多かれ少なかれ含んでいるのだと思うが、自分が入った会社もまさにそうだった。
この環境で鍛えられたのは単純な技術的なスキルというよりは、何をすべきかを自分で考え出すスキルだったと思う。
プロジェクトにアサインされている時は、APIメンテナとして要件をまとめて設計をし実装とテストをするというそれまでと変わらない仕事もした。しかし、それ以外に、今プロジェクトの中で自分が何をしなければならないか、何をすればプロジェクトがうまく進むのか、ということを考えて行動する必要が出てきた。
特に人を動かすという部分ではそうだった。エンジニア出身でない人に何がどういう理由で必要かを説明し、説得し、動いてもらう。そういう技能が要求される画面が増えた。
それまでは、ほぼエンジニアとデザイナ（フロントエンドの実装も兼任する）とマネージャー（エンジニア出身の）とだけコミュニケーションが取れればよく、コミュニケーションに悩んだことはあまりなかった。コンテキストが重なる領域が多いので、ある程度ツーカーで会話ができていた。
しかし、エンジニアリングの知識が無いが、重要なドメイン知識を持つメンバーと仕事をするケースが増えた。そのため、そういったメンバーとのコミュニケーションを行い、上手くその人達と協業するためのコミュニケーションを円滑に行うというタスクが大幅に増えたと言える。
今まで単にそういうことが必要なかったのは他の人がやってくれていたおかげだが、組織が変わってそれを自分でやる必要が出た。最初はうまくいかない面も多かったが、最近はそういうコミュニケーションミスに起因して発生するトラブルを先回りして回避するためのプロジェクト進行上のテクニックがかなり身に付いたように思う。
プロジェクトにアサインされていない時は、今メンテしているプロダクトに何が必要かを考えてタスクを自ら生み出す必要があった。
これは逆にこれまでの貯金が生きた部分で、驚くほど上手くハマった事例をいくつか作ることができた。今までのプロジェクトでやってよかったこと、悪かったことに関する知見をフルに活かすことができた。
今の職場での入社直後に集中的にこれまでの知見を用いて開発環境をもろもろいじったのだが、何をやったかは以下のエントリに書いた。
serihiro.hatenablog.com
プロダクトの設計面では、自分が以前から構想していたrailsにおける非同期jobを管理するためのアーキテクチャを導入して実装したりもした。サブシステムを丸々一つ一人で実装するようなこともあって、そういう時はこれまでやりたくてもやれなかったようなアイデアを堂々と導入することができた。
それ以外の面では属人化していたスキルや知識をパブリックにすることに力を注いだ（誰も気にしていない領域だったので勝手にやった）。
自分が入るまで特定のエンジニアにしか出来なかったことを管理画面に移植してセールスやサポートチームでも出来るようにしたり、社内コミュニケーション用のツールとして使っている esa.ioに #知見 というタグをつけて、こまめに社内向けの知見（歴史的経緯で分かりづらくなっている機能の仕様だとか分かりづらいモデリングに関する解説だとか）書き残したりしている。
特に、特定のプロダクトや機能に関する解説資料は、 #徹底解説シリーズ というタグをつけてかなりの長文で解説記事を書いたりもした。読まれているものもそうでないものもあるが、主に自分が仕様を思い出したり、他のエンジニアに仕様を説明したりするのに役立っている。
これまで書いた #徹底解説シリーズ で一番社内の反応が多かったのは、APIが参照しているDBのモデルに関する解説記事だった。
これは、主要なモデルに関するドメインレベルでの解説と、それらのモデルを検索するための用途別のSQL例をセットで記載したもので、非エンジニアにもSQLを覚えれば自由にデータを参照できるようになってもらうことが目的だった。まぁ実際にSQLを書いてくれる人が増えた訳ではなく、結局エンジニアやデータサイエンティストがSQLを書いてデータをBigQueryから取り出す状態は変わらなかったが、それでもこれから入ってくるエンジニアやデータサイエンティストのためのオンボーディング資料として役に立つんじゃないだろうか。
仕事以外の部分ではいくつかのgemをリリースした。殆どがrailsに関連するものだが、例えばflatten_routesは自分が趣味で作ってたrails productで必要だったので作ったものだが、実際にこれは似たようなgemを見たことがないという点ではそれなりに意味のあるgemだったのではないかと思っている。あとshoryuken, google-auth-library-ruby, ruby-openid といったgemにcontributeすることもできた。
github.com
あと開発手法に関するLTを社外で2回行った。どちらも大した話はしてないが、両者ともその後の懇親会ではそれなりに好意的なコメントを直接いただいた。
speakerdeck.com
speakerdeck.com
こういった経験で得たいくつかの成功体験を通して、自分自身はまぁまぁ出来る方のエンジニアだなとうっすらと感じるようになった。（もちろんやらかした事例もある）
現職の他のエンジニアも優秀なメンバーが多いと感じるが、彼らとうまく連携して仕事ができているという点と、それまで出来ていなかったことをそれなりに達成できたという点で自分もまぁそれなりにできる方になっていたのではないかと感じる。特にrailsによるweb appの開発という面において技術面では大きな課題を感じたことは殆どなかった。どちらかと言えば課題を感じたのは、上述したプロジェクトの進め方をいかに円滑にするかという部分だった。
新しく興味を持ったもの
一方で、ここ2年間で技術的にはwebアプリケーション以外の領域に目が向くようになった。
今何か作りたいものがありますか？と聞かれたら自分はBigQueryのような大規模データ分析基盤、もしくはそのBackEndで動作する分散job workerか分散File Systemと答える。
きっかけは今の会社に入ってから使うようになったBigQueryで、これは本当に革新的だと思った。
BigQueryは使う人から見たらただのRDBMSじゃん、と思うかもしれない。しかし、MySQLやOracleを仕事で使ってきた人なら分かると思うが、比べ物にならないぐらいのreadパフォーマンスを何のチューニングもしなくても出せるという一点で、RDBMSとは全く異なる存在である。
実際自分も使ってみるまではそのパフォーマンスに懐疑的だったが、数千万行から数億行のレコードをフルスキャンしなければ実現できないような集計クエリが20秒程度で返ってきた時は度肝を抜かれた。また、日々どれだけレコードが増えてもパフォーマンスが殆ど劣化しない。雑にBQにdatasetとテーブルを作ってembulkで流し込みさえすれば、後は自由にクエリを書いてデータをシュッと取り出せる。
この体験は使ってみないと分からないと思うが、入社して初めてnginxのログをBQで検索したときは本当に革新的だと思った。こういうものこそが自分がそれまで必要としていたものだった。
これまで、著名なサービスを除けば世の中のサービス開発はデータを軽視されていたと個人的に感じていたのだけど、それは大規模なデータを取り扱うためのDWHのようななにがしかを「サービスが稼働し始めた後から」作るイニシャルコストが無視できないほど大きかったからだと考えている。大企業はともかく、スタートアップとしてはそのような大型投資を簡単にできない状況が多いと思われる。
しかしBigQueryは、PaaSとしては高い方だと思ったけど、テーブルを作ってデータをinsertするだけなら大した額はかからない。しかも、すぐに始められるから、どれぐらいの投資が必要か判断できなくてもスモールスタートで「とりあえずこのテーブルだけ分析できるか検証してから決めたい」という時にすぐに判断ができる。本番のDBに投げたら絶対返ってこないようなクエリがすぐに打てる。これがビジネスにどれだけの影響を与えるか。
というような具合に、ビジネス面でのインパクトも感じたが、一方でそもそもどういう風に実装されているのかという点に自分は興味を持った。
分散データ処理と言えばおなじみMapReduceだが、そもそも自分はMapReduceを使ったこともなければ使いどころについても検討したことがない。まずはこっからだ、ということで今年に入ってからMapReduceのオリジナルの論文や、Hadoopの高速化に関する論文を読んだり、ここ数年のビッグデータの処理基盤に関する傾向を調べたりした。
分かったことは、今の時代ではHadoopがかつて抱えていた問題（それこそ論文で議論されていたような）を解決するようなossが増加し(spark, kuduなど)、MapReduceはオワコンみたいな話をえらい人がパブリックな場でするようになって、もはや枯れた技術となってきているということが分かった。が、大規模なデータを処理するためのアルゴリズムとしては優れており、それを支えるためのストレージ/NWの技術は着実に進歩しているし、個人的にはまだ研究したいと思える技術ではある（まぁproductionで使ったことないし）。
次の5年間
今までは自分の劣等感をモチベーションとした「成長」だけを意識して仕事をしてきたが、これからは作りたいものを作るための技術習得にフォーカスして、作りたいものをやるために仕事をしようと思う。ビジネスのための手段としてwebアプリケーションを作るという意識が強かったが、単純に自分が作りたいと思うものに技術をつぎ込んだ結果、それがビジネスになり自分のお賃金になる。そういうポジションを目指したいと思う。
