ep5. マイクロサービスアーキテクチャのアレコレとエンジニアの転職 (ゲスト: @ota42y)
※この記事は2019/06/15収録の「マイクロサービスアーキテクチャのアレコレとエンジニアの転職」の文字書き起こしです。一部、編集を入れています。
オープニング(00:00〜)
treby：きのこるエフエムは技術分野、キャリア属性の異なる私たちパーソナリティーがこの先生き残る上でのキャリア戦略を共有したり議論することで、シニアのソフトウェアエンジニアのみなさんのキャリア、人生設計に貢献することを目的にしたPodcastです。
番組はマネジメントに攻めるRubyistのtrebyと、
banjun：スペシャリストになりたいiOSデベロッパー、banjunがお送りします。
treby：よろしくお願いします。
banjun：よろしくお願いします。
ゲスト紹介(00:35〜)
treby：前回予告しました通り今回もゲストにお越しいただいております。ゲストのota42y(太田)さんよろしくお願いします。
太田(以下、ota42y)：はい。よろしくお願いします。太田です。どうもどうもです。
treby：簡単に30秒程度で自己紹介のほうお願いしてもいいですか？
ota42y：はい。太田です。Twitterだと「@ota42y」みたいな感じのIDでやってます。
所属はこれが収録中はヘルスのテックベンチャーにいたんですけれども、これが公開されてる頃には所属が変わっているはずです。言っていいかちょっとあいまいな状態で、あと分かんないんで詳しくはTwitterを見れば言ってる可能性があって、言ってなかったらちょっとまだ公にできないやつです。あとは私は主にここの文脈でいうとRuby系のサーバーエンジニアとしてやっているはずです。という感じですね。
treby：あとで話もありますけどいろいろと言語分野も変わってきてるんですよね。転職するたびに。その話も深掘りしていけれたらいいなって思います。
スペシャリストの中でも同じ分野じゃないところに攻めていくスペシャリスト。ヘルスなテックなベンチャーのやつでいうと記事書いてましたね。5月ぐらいに。
ota42y：ですです。
treby：そちら見たら社名まで分かっちゃうっていう(笑)
banjun：社名言わないんですか？
ota42y：普通に出してるんで大丈夫です。
treby：ちょっと配慮的な(笑)。ota42yさん、太田さんというふうに呼称していきたいと思います。
パーソナリティとの繋がり
treby：banjunさんとはArt ofが初めて？
banjun ＆ ota42y：そうですね。
treby：それまで特に会ったことはない。
ota42y：ないですね。
treby：確かota42yさんはbanjunさんがファシリテートしてた回で出てたんですよね。
banjun：あ、そうですね。多分そういうふうに組んだ気がします。
treby：じゃああんまり記憶には残ってない？
ota42y：まあ、誰がファシリテートしてたかとかそんなに。内容のほうは覚えてます。
banjun：まあ、結構いっぱいいっぱいで。ただ私の回はどっちかっていうとアプリ寄りみたいな感じがあって、エンジニアのアプリ寄りみたいな感じだったので。
treby：私のほう(の繋がり)としてはShinjuku.rbのね。よく来てくれてた。過去形になってますけど。
ota42y：Shinjuku.rb最近ないんで(笑)
treby：次ありますよ。5月末。
ota42y：あ、やります？
treby：あ、6月か。6月末にやります。Extreme Fish Bowl やるんでぜひ来てください。
banjun：え、何それ？
treby：モブプロみたいなの。
banjun：あー、はいはいはい。
treby：Extreme Fish Bowlっていう名前がついてるらしいですよ。
ota42y：モブプロとは違うんですね。
treby：そう。みんなお酒とか飲みながらなんですけど。前にコードを書く人とディレクションをする人がペアで出てくるんですね。最初コード書いてる人は次は観客側になって、逆にディレクションしてる人はコードを書く人になるのかな。逆だったかもしれないですけど。
っていうのでみんなでどんどん回していって、一つのお題のプログラムを組んでいく。5分1クールとかなんで本当にスピード勝負っていうような遊びがあるんですけども。
RubyKaigiでの登壇内容
treby：それでota42yさんはこの前のRubyKaigiで登壇されてましたね。
ota42y：そうですね。RubyKaigiでちょっと登壇をさせていただきました。
treby：強い人。
banjun：強い人だ。
ota42y：いやいやいや。
banjun：いわゆるスペシャリスト側の強い人の例です。
treby：どんな発表してたんですか？
ota42y：私がちょうど前にやっていたOpenAPI3っていうことについて話してました。OpenAPI3が何かっていうと、要はREST APIに対して、そのREST APIがどういったインターフェースを持ってるかっていうのを定義するような仕様みたいな感じですね。
YAMLファイルで定義することで定義していって、定義が割としっかりしてるんでプログラムからすごい読みやすくて処理もしやすいような感じになってます。
それをRubyでうまく定義されたファイルを読み込んで、実際にAPIに対してバリデーションをかけたりとか。本当に定義通りのリクエストとレスポンスになってるかっていうバリデーションするためのgemみたいなものをちょうど作っていたので。
その流れでRubyKaigiでOpenAPI 3のエコシステムとか、実際の実装みたいなところについて話させてもらったっていう感じですね。
treby：OpenAPI 3はRubyだけのものじゃないのですね。
ota42y：そうですね。言語に特に依存してないので、普通にGoとかnodeとかで動いてるやつとかもバンバン(あります)。
banjun：Swaggerだったやつですか？
ota42y：そうですね。2.0のときはSwaggerっていうふうに呼ばれていて。Swaggerっていうのはある会社が持っているやつなんですけども、それが寄贈されてOpenAPI 3っていうふうな形に次のバージョンとして出てきたっていう。
banjun：ふーん、なるほど。じゃあSwaggerだったものの次のバージョンが3なのね。OpenAPIの。
ota42y：そうですね。
treby：じゃあOpenAPIとOpenAPI 2はないんですか？
ota42y：OpenAPI 2はSwagger とイコールなんです。
treby：ニアイコール？もうイコールなんですね。そこでバトンタッチして3になった。
ota42y：そうそう。
treby：そうだったんですね。
ota42y：完全に同じものとして2.0とか。
OpenAPI3とマイクロサービス
treby：(OpenAPI3は)結構マイクロサービスっていう文脈と近いんですかね。
ota42y：そうですね。マイクロサービス、ちょうど私がーーこれを公開されたときは前いた会社かなーー前いた会社ではマイクロサービスをやっていて。そうするとAPIの数がやっぱり普通に3ケタ、4ケタいくんですよね。
banjun：3ケタ、4ケタ？
treby：4ケタもあるんですね。
ota42y：4ケタぐらいはあった。
banjun：4ケタのエンドポイントが。
ota42y：軽く数えたけど4ケタあったはずなんで。それだけあるとさすがに面倒見きれないんで。いちいち全部読むの大変ですし。
あとはiOS、Androidのクライアントのバックエンドサーバーとしてのマイクロサービスって形だったので、iOS、Androidの人にRubyのコード読んでレスポンス把握しろっていうのはちょっと無理があるんで。
なので、こういったOpenAPI3みたいなどちらでも読めるような、かつインターフェースだけをちゃんと記述されたドキュメントっていうのを介して、「われわれはこういったインターフェースを提供してるので、そちらはそれを想定した状態で開発を進めてください」みたいなことをするためにOoenAPI 3を使っていたっていう。
banjun：(ota42yさんが所属していたFiNC Technologiesは)BFFというか「Backends For Frontends」の構成にしたようなことを聞いてるんですけれども、この(BFFにしている)段階でなおクライアント側にさらしてるのは4ケタとか。裏側は裏側(で別)だよね。
ota42y：BFFはちょっと動いてはいるんですけれどもすべてがBFFになっているわけではなくて。やっぱりBFFを介さずに直接アクセスしているみたいなものもあります。
またうちは今BFFを……まだうちだ(笑)これを収録時はうちなんですけれど公開時はうちではないんですよね。
treby：ややこしい(笑)
ota42y：ややこしい。
BFFも二つちょうど作っていて。古いやつに関してはサーバーエンジニアが全部BFFを作ってあげて、GraphQLのクエリとしてクライアントに提供するってやつなんですけれども。
新しいほうがサーバーサイドKotlinで動いていて。クライアントエンジニアがKotlinを書いて後ろのバックエンドサーバーから必要な情報を取ってきて、まとめてクライアントに返すみたいなことをやるんです。
なので、そうするとクライアントエンジニアはBFFを作る必要がある。BFFは後ろのバックエンドサーバーにアクセスする必要があるんで、そこでやっぱりバックエンドサーバーが一体どういったAPIを持っているのかっていうのが重要になってくるんでやっぱり重要性は高まってくる。
banjun：なるほど。BFFの人がバックエンドのAPIを理解するためにOpenAPIのドキュメントになると良い、と。
ota42y：ですです。
treby：外向きっていうのか内向きっていうのかは分かんないですけど、マイクロサービスのAPIっていっても、バックエンド側でつながるところもあるじゃないですか。
OpenAPIを使うのは、あくまでクライアント側の人たちとつながるところで使ってたっていうイメージ？
ota42y：基本的にはバックエンドも使ってました。やっぱりRailsアプリが40、50ぐらいあって。するとほかのRailsアプリでどういったAPIを持ってるかとかも調べるっていうのは手間ではあるんですね。
treby：まあそうですよね。読みたくないしね。
ota42y：っていうのでドキュメントとしてあればいいですし。
また一部に関してはRubyのクライアントライブラリみたいなのも提供していて、入れるだけで勝手にアクセスができるようになるみたいなものも提供してたりします。そのクライアントライブラリはOpenAPI3からgenerateできるんで、作ってRubyライブラリをササっと。定義を書けば簡単にアクセスできるようになる、っていうところまで提供してる。
treby：それいいな。
banjun：必須ですよね。その4ケタのAPIのドキュメントがあったとして、そのクライアントコード作れなかったら実際にはめちゃくちゃな工数かかりますよね。
ota42y：4ケタのAPIがあると、ドキュメントを更新し忘れとか絶対出るんで。そうするとドキュメントが信頼できないから結局コード読まなきゃ駄目じゃんってなってしまう。
でもちょうど私が作っていたgemっていうのが実際にレスポンスとリクエストが定義通りになっているかっていうのをテストでチェック、担保できるような感じの機能を提供していて。
それを作ることによってちゃんとこのドキュメントが信頼できるものであるっていうのをある程度のレベルにおいては担保してあげるようなことができるんですね。
なので、ドキュメントの信頼性みたいなところに関しても、普通にExcelでドキュメントを書くんじゃなくてちゃんとOpenAPI3で書くっていうことはそういった意味があるんです。
treby：ということで今日はRubyのバックエンドエンジニア。最近は特にマイクロサービスに強みを持たれてるota42yさんとお送りしていきます。よろしくお願いします。
ota42y：よろしくお願いします。
banjun：よろしくお願いします。
大学でのHCI分野の研究(10:06〜)
treby：まずota42yさんのバックグラウンドの話からしていけたらいいなと思ってますと。そもそもota42yさんは今社会人何年目ぐらいですか？
ota42y：社会人何年目だ。2013卒だったので。
treby：同期じゃん(笑)
banjun：あ、本当？
ota42y：2013年……19年で、7年目か。
treby：マジか。ということは俺も7年目なんだ。あんまりもう数えないよね。そこまでくると。
ota42y：数えないですね。3年目ぐらいまでは多分、分かりますけど。
treby：大学院までは行った？
ota42y：大学まで行ってました。
treby：別に留年とかしてない？
ota42y：留年とかはしてないので、ちょうど今30歳。
treby：88世代。
ota42y：そうですね、昭和なんですよ。
treby：ギリ昭和で。
banjun：ギリ昭和？
ota42y：全然昭和。
treby：ここみんな昭和だから大丈夫(笑)
banjun：うん。昭和です。
treby：もともとコンピューターサイエンスやってたんですか？
ota42y：そうですね。コンピューターサイエンスのHuman Computer Interactionっていう分野で大学院までやってました。
treby：それはどういうことを研究する感じですか？
ota42y：どういうことを研究するかっていうと結構広いんですけど、簡単に言うと「コンピューターが人間をどう幸せにするかを考える」みたいな感じですね。
コンピューターが人間との関わりみたいなものをどういうふうに関わっていけばいいのかっていうのを考えていくような分野で。代表的なものだとするとこの分野としては、GUI自体がそもそもこのHuman Computer Interaction、HCI分野なんですけど。
GUIっていうのがHCI分野の1個のでかい成果としては上がってますね。ただあとはマウスみたいな。
treby：そうか、そうか。物理的なところと、あと画面上のCLIからGUIになった変遷の話であるとか。
ota42y：みたいなのがHCI分野の主な成果になってます。
treby：デジタルサイネージとかね。人間とコンピューターの接点となる部分に関する全てを取り扱うということを研究してたんですね。
ota42y：だからVRとかも全然含まれてたり。逆に普通に社会学みたいなものもあって。例えば、インドのあるコミュニティの人たちがどういうふうにスマートフォンを使ってるかの調査研究みたいなのが出てきたりとかもする。
treby：それはどうつながっていくんですか？
ota42y：社会においてどのようにインターネットとかコンピューターみたいなのが使われているかっていうのを研究とか調査する、報告みたいなのが出てくるって感じですね。
treby：国内だけじゃなくて海外もっていう中の一つでインドが出てくる。
ota42y：そうですね。どっちかっていうとそれはアメリカのほうのかなりでっかいカンファレンスでの話ですね。
treby：研究発表とかしてるわけですね。
ota42y：実際のシステム作るのもそうですし、システムをどういうふうに使われてるのかみたいなものも研究対象には入ってます。
treby：インプリっていうか実際に作るところもやるし、それがどう浸透していくかっていうのを見ていけるってことですね。
ota42y：あとはほかにも例えば、すごい人間の特性に寄った話とかもあって。例えばマウスカーソルが合わせやすいボタンはどういった条件を持っているのかを調べるという。
「マウスカーソル合わせやすくするにはこれぐらいのサイズのボタンが必要ですね」っていうのを数式として表してあげるみたいなことを研究する。
banjun：画面の端っこにくっついてるほうが実は合わせやすいみたいな。
ota42y：とか、「画面上にカーソルが複数個あって、それを切り替えられるほうが速いんじゃないか」みたいなのがあって、そういった研究をするんですね。
就職活動と会社選びの軸
treby：へえ、面白いね。また何でその人間学からコンピュータサイエンス分野にいこうと思ったんですか？
ota42y：もともとコンピューターを中学ぐらいから触ってて。中学なんで2000年とか1999年ぐらいからですね、触っていて。
treby：じゃあ初めて触ったのは中学生ぐらい？
ota42y：そうですね。それぐらいですね。Mozillaがfirefoxではなかった頃ぐらいですね。から触っていたって感じですね。
なので、コンピューターを使って生きていこうみたいなものはもう大学に入った時点で決まってましたね。
treby：大学選ぶときにもじっくり選んでた？
ota42y：そうです。
treby：コンピューターを使ってっていうのはエンジニアっていうのはまだ限定はしてなかった？
ota42y：ほぼエンジニアで。
treby：プログラマーみたいな？
ota42y：そうですね。
treby：何年後とか。
ota42y：そのときはまだエンジニアみたいな具体的なイメージができてなかったんで、多分ふわっとですね。で、入ってみてそのときの研究室、研究室に情報系の学部だったんで。
ちょうど、うちの学校だと3年生で研究室に配属されるんですけども。その中ですごい一番面白そうだったのがHCI分野をやってる先生だったのでそこに入った。
treby：そこで4年間やって？
ota42y：です。
banjun：研究室が4年間？
ota42y：そうです。
ota42y：そうです。大学で3年、4年で2年間で、そのまま院で同じ研究室だったんで2年。
treby：学部から院に進むときって就職っていう選択肢もあったと思うんですけども、またなぜ院に？
ota42y：(当時は)就職みたいなのことを特に考えてなかったですね。学部だと。一応、軽く就職活動みたいなものはしたんですけれどもそんなに本気ではなかったっていう感じですね。
treby：なんか感覚分かる気がする。何となく理系だと大学院まで行くよねっていう雰囲気ありましたよね。今どうなのか分かんないですけど。
banjun：うん。まあ雰囲気はありました。
ota42y：雰囲気あります。でも3年、4年とかの学部のときに軽く就職活動をしておくと大学院で就職活動するときに、経験があるから分かりやすいみたいなのがあったんでちょっと楽でした。
treby：インターンシップとか行ってみたりするよね。分かる。学生時代って、就職活動どうしていいかって分からないですよね。
ota42y：軽くやってみてちょっと期間を置いてもう1回チャレンジができるっていうのは割と良かったなと。
treby：新卒で入る会社なんですけども、どういう軸で選びました？
ota42y：もともと、そのところは完全にエンジニアとして生きていこうみたいなことは決めていたので。エンジニアとしてやりやすく、かつ大企業みたいな感じの、Slerみたいなところとかではなくもう少し現場に近いというか、実際にコードを書けるほうがいいかなっていうふうに思ったので、基本的にはネットベンチャー系を主に受けてましたね。
treby：そこの区別はついてんですね。最初就職する前って大きいところなのかちっちゃいところなのかって、会社の大きいちっちゃいぐらいは分かるにしても、実際にコードを書くか書かないかってイメージつきづらくなかったですか？
ota42y：そんなにではなかったですね。基本的に確か受けたのがほぼサービスを提供してる会社だったので、SaaSとか。
BtoCとかでサービスを提供してる会社だったんで、かつそれを自社で作っているところっていうのを受けていったんで。入ったときにどういうふうになるか分からない会社みたいなのは結構なかったです。
treby：じゃあ中がある程度分かる会社を受けてたっていう。
ota42y：そうですね。
treby：すごい。業界分析ができてますね。
banjun：さすが2回目の就職活動。
ota42y：1回目はちょっとよく分からなかったんで、ん？って感じでした。
新卒入社の会社ではRubyじゃなくC++を書いていた
treby：それで新卒で入った会社がどちらになるんでしたっけ？
ota42y：株式会社ドリコムっていうソーシャルゲームを作ってる会社ですね。
treby：われわれenzaでお世話になってますけどね(笑)
banjun：まあenzaで。
treby：1社目からドリコムってね、すごい筋がいいなって思いますけど。何、上から言ってんだっていう話ですけど(笑)
banjun：いや、本当。
ota42y：今はRubyの人なんですけれども、実はドリコムに入ったとき、ドリコムにいたときはRubyは一切書いてなかった。
treby：何書いてたんですか？
ota42y：普通にC++を書いていてiOS、Androidのゲーム側を作ってた。Rubyは新卒研修で1回とか。あとなんか軽くちょっと書いてたりとかしかない、スクリプトでRubyを書いたぐらい。
なので、ちゃんと外にプロダクトとして出るRubyはほとんど書いてない感じですね。
treby：フロントのアプリのエンジニア。ゲームでC++ってことはCocos2d-xとか？
ota42y：そうですね。Cocos2d-xでずっとやってました。
treby：何年ぐらいやってたんでしたっけ？
ota42y：2016年の5月、6月ぐらいにやっているはずなんで4年間ぐらい。
treby：その4年の中ではどういうことをしておられたんですか？
ota42y：ほとんどC++側のゲームしか書いてないです。
treby：あ、本当に？プロダクトが変わったりとかしたんじゃないんですか？
ota42y：最初に一瞬、1ヶ月だけ別のプロダクトにいたんですけど、そのあとはもう残りの期間はずっと1本のゲームを書いてましたね。
treby：その4年間ずっと同じプロダクトだと結構飽きないんですか？
ota42y：そこまで飽きはしなかったですね。作ってるコンテンツが結構好きだったりとかもしたので。
treby：大事ですね。ゲーム作りだと。
ota42y：そうですね。割と面白くやらせてもらいました。特に最後の後半とかは結構PM、ガリガリコードを書くというよりかはみんながうまく回ってもらえるようになるとか。
treby：ああ、リーダーみたいなね。
ota42y：ミドルとかそういうちょっと別の領域に切り替えたりとかしてたんで、そこまでつまらないみたいなことはなかったですね。
treby：今でこそota42yさんはRubyの人のイメージが強いんですけども、当時はRuby書いてなかったわけですよね。
ota42y：そうですね。
treby：コミュニティとか勉強会とか当時は行ってました？
ota42y：Rubyの勉強会とかはほとんど出てなかったですね。Cの勉強会とかも全然出てないはずですね。ちょくちょく出てはいました。
treby：当時の関心事ってどこだったんだろうなっていうのが今のota42yさんから想像がつかなかったので聞いてみたかったんですね。
ota42y：でも勉強会みたいなのは情報科学系の勉強会みたいなものは毎年あったやつだったんで、そういったのに顔出したりとかはしました。年に1回なのか。情報科学若手の会っていう。
banjun：若手の会？へえ、そんなのが。
ota42y：情報科学系の若い人が集まる会みたいなのがあったんで。
banjun：何歳まで行けるんでしょう。
ota42y：自分が若手だと思ってる限りは行けるようにします(笑)
treby：本当だ、ある。情報科学若手の会っていう。しかも「wakate.org」なんですね。
ota42y：そうなんですよ、ドメインを持っている。
treby：強い。こちらのほうには今は行ってるんですか？
ota42y：ちょっともう若手じゃないんで。
banjun：自分がそう思わなければ若手じゃない。
banjun：僕はゲームの開発やったことないんですけど。iOS、AndroidでC++っていってもCocos2d-xだと基本的にはC++でフルに書けるんですかね。
そのゲーム部分とかそうじゃない部分とかっていうのは分かれてなくて、C++だけやっているとアプリの全てが作れるみたいなそういう世界だった？
ota42y：そうですね。
banjun：それ以外の部分はやんなくても大丈夫だったんですか？
ota42y：基本的にはゲームを作るにおいてはC++ですべて完結はします。要はボタンとかも全部C++の世界でCocos2dが提供しているので、それを触るだけでいけるようになります。
ただプラットフォーム特有の機能を使うときにだけやっぱり、iOSであれば当時はObjective-C だったりとか、AndroidであればJava層を触ることが出てくる。例えば当時はTwitterのフレームワークはiOSに入っていたので。
banjun：入ってましたね。
ota42y：そうそうそう。それを呼び出したいときはObjective-Cを書く必要があるみたいなのがあったりとかします。だからボタンとか音を鳴らすとかにおいては、基本的にはCocos2d-xの世界で方が付くようにはなってますね。
banjun：じゃあ本当にほぼほぼフルC++エンジニアっていう感じなんですね。
ota42y：そうですね。なので、Androidとかはもう全然書いてなかった。分かんないですね。iOSだとそこそこObjective-Cが染み出すところがいくつかあったりしたんで分かるんですけど。
treby：そのツイートする部分とかAndroid版はどうなってたんですか？
ota42y：Android版は当時のドリコムだと、Cocos2d-xを社内用に改造したフレームワークにしてたんで。社内用に改造しているチームっていうのが別にいて、そこら辺がかなりいいAPIとかを作っている感じで。基本的にはそこのAPIを呼ぶだけみたいな。
treby：作ってくれてる？
ota42y：そうそう。
banjun：だからC++層だけを見ていれば全部できるみたいになってる。
ota42y：ですです。
treby：イメージ的にC++は結構下のほうのレイヤーなイメージがありますけど、そこから作ることもあるんですね。
ota42y：ですね。
転職の動機
treby：そんなドリコムさんは良い会社だと思うんですけど、また何で転職活動しようと思ったんですか？
ota42y：いくつか大小さまざま理由があるんですけれど。
一番大きいのは、ドリコムでやっているのは基本的にエンターテインメントを作るっていうことだったんですけど、どっちかっていうとテクノロジーの力で世界を良くしたいみたいな方向がちょっと気持ちとして強くなって。
実際後半に関しては直接ゲームを作るというよりかはチームがうまくゲームを作れるようにサポートしてあげるとか、CIの整備とか、そういった技術面でみんなをサポートするみたいなことが多かったので、徐々にテクノロジーで人をサポートしてあげるみたいなものが面白そうだなっていうふうに思っていたんです。実際研究でもコンピューターの力で人々を幸せにするみたいなことをやるような分野だったので。
なので、テクノロジーの力で何かしら価値を提供するような。そのテクノロジー自体が価値になるようなことがしたいなっていうふうに思っていて、ちょっとエンタメとは向いてる方向がずれてきたんで転職を考えたっていう感じです。
treby：そうだよね。最初は新卒で入って周りに強い人もいたんだけど、だんだん自分も強くなっていってどちらかというとチームをまとめるだとか、プロダクトを提供していくとかいう方向になってきて自分がやりたい、エンジニアとしてもっと強くなりたいんだっていう方向とはずれてきたのかなっていうのが一番大きな理由だったんですね。
ota42y：そうですね。
treby：その(転職の)際にはいろいろと会社さんとかは見て回ったりしたんですか？
ota42y：そのときはほとんど見て回らなかったですね。私が転職する半年ぐらい前に転職した同期がいたので、そこ経由で良いエージェントみたいなものを紹介してもらって2社だか3社ぐらいを紹介してもらって決めたっていう感じでした。
treby：その2、3社見た中での決め手のポイントというか、どこを重視するとかっていうのは決めてたりしたんですか？
ota42y：やっぱり転職理由となったテクノロジーの力で世界をしようみたいなものは絶対条件として秘めていましたね。
treby：あとは会社の規模とか？
ota42y：会社の規模はそこまで見てなかったですね。一番でかかったのはヘルスケアの分野っていうのが強くて。自分あんまり健康的ではない生活をしているので、かつテクノロジーの力でこれがなんか改善したらいいなって思ってて。
実際ヘルスケアってそんなに当時はまだ、もてはやされていなかった時代だったので。今だとかなりAppleとかがすごい、すげえ頼もしいみたいな感じですけども。ちょうど私が転職する頃はまだまだそこまで、ちょっと機能としてあるよぐらいのレベルで、みんなのヘルスケアの研究もそこまで関心は高くなかった時代だったんで。
そういったときにテクノロジーでヘルスケアをすごく良くできるんだったら世界にとっても良くなるし、その中に自分も含まれてるんで自分もうれしいみたいな感じなので決めたっていう感じです。
treby：ビジョナリーですよね。
アプリエンジニアからサーバサイドエンジニアに転向した理由(26:21〜)
treby：転職するとき、普通に考えたらアプリエンジニアとしてな気がするんですけど、なぜそこからサーバーサイドに移っていったんでしょうか？
ota42y：もう少しサーバーサイドをやってみたかったっていうのが一番でかいですかね。
treby：転職するときにサーバーサイドとして応募したのか、転職したあとにサーバーサイドになったのかどっちですか？
ota42y：転職するときにもうサーバーサイドとしていこうって感じで決めましたね。
banjun：それはドリコムにいた時代からサーバサイドのプログラミングは仕事以外で何かやってたって感じですか？
ota42y：仕事以外では特にはやってなかった。自分の仕事ではなくて自分の家で動くサーバーサイドアプリみたいなものは作ってたりとか。自分の家のRaspberry Piで動くGoのサーバーアプリケーションみたいなものは書いていたので。
treby：ラズパイで何をするんですか？
ota42y：ニュースサイトとかいろいろめくって、いい感じに触って、自分(専用)のHTMLとして吐き出してくれるみたいなものを作ってたりしてました。
treby：なんかちょっと良さそうです。NewsPicksとかGunosyみたいな感じでレコメンドしてくれそうな。
ota42y：そうそう。ちょうどGunosyが出始めた頃の段階だったので、もうちょっと自分好みにチューニングされたやつがほしいっていう感じで作ってた。
banjun：個人プロジェクトみたいなのでサーバーサイドやって、仕事でもやるかみたいな。
ota42y：そうそう。(ドリコムは)Rubyの会社だったんで、スクリプトとか、要はCIスクリプトとかは自分で書いてたんでRuby良さそうじゃん。で、Rubyでサーバーサイドないかなっていう。
当時はGoが1.4とか1.5の時代だったんで、プロダクションでのGoはほとんどなかったので。Goでの仕事は見つからないって感じでした。
treby：そうか。その転職活動してるとき(所属してた)会社で使ってたサーバーサイドの言語ってことでRubyなんですね。
ota42y：です。
treby：それを聞いて思ったのはドリコムさんでRubyエンジニアってのは一応あったんじゃねっていう。
ota42y：それはどっちかっていうとエンターテインメントではない。
treby：のところで軸が駄目だった。
ota42y：そうですね。自分の方向性とはずれているので。当時ドリコムにあったほかのサブプロジェクトとかもそこまで自分がやりたい方向性とは似てなかったので、やっぱり方向性が一番大事かなっていうのはあった感じですね。
treby：そのあとにFiNCさんを選ばれて入った。
ota42y：です。
banjun：名前出ましたけど(笑)
treby：調べれば分かる(笑)
ota42y：調べれば分かります。RubyKaigiの資料とかに書いてるので。
banjun：書いてましたね。FiNCって、すごいいってるけど大丈夫？
ota42y：大丈夫です。
banjun：僕の行ってきた話では、ロビーの廊下とかになんかテープ置いてあって、身長ごとの歩幅表示みたいなものがあって、自分の身長のライン歩くと歩幅が合うみたいな、そういう表示とか、なんか面白いなって。
ota42y：いろいろ健康的になるような仕掛けがまだまだあります。
treby：トレーナーさん会社に来てくれるのすごくいいですよね。
ota42y：会社に来てくれるっていうか、FiNCの会社の半分は今ジムなんで。
treby：あ、そうなんだ。
ota42y：そう。ジム事業やってるんです。
banjun：左行ったらオフィス、右に行ったらジムみたいな。
ota42y：そうそう。普通にトレーナーさんが同僚としているっていう。
treby：ああ、同僚なんですね。そこは知らなかった。普通に料理の会社みたいに食材を置いてってたまに来てくれるっていうことをしてるわけじゃなくて、事業としてジムをやってる。
ota42y：そうですね。事業としてジムをやってます。なので、FiNC Fitっていうので原宿とかにも確か、いろんなところにジムがあったりします。
FiNCでのお仕事
treby：そのFiNCではどういう仕事をしてたんですか？
ota42y：FiNCではRuby on Railsのサーバーサイドエンジニアとしてほとんどやってましたね。基本的にはほぼずっとRailsを書いていたっていう感じですね。
treby：とはいえ当時ってまだFiNCのアプリ出てなかったんですよね。
ota42y：表には出てなくて、招待制みたいな。招待制じゃない、ジムの会員になると使えるみたいな感じだったりとか。FiNCが提供している有料プランに入った人のサポートツールみたいな位置づけとしてアプリが存在しているっていう感じでしたね。
treby：じゃあ入ったときにはもう既にプロジェクトは動いててっていう？
ota42y：そうですね。割とリリースもされていて、2年ぐらい確か動いているって感じですね。
treby：じゃあそのマイクロサービスのアーキテクチャ(の技術検討)とかに絡んでたわけではない？
ota42y：そうですね。マイクロサービス自体は私が入った時点でも5個か6個ぐらいはあったはずです。そこからマイクロサービスはかなり初期からやっていてそれを広めるのに一役買ったみたいな感じです。
treby：FiNCさんの中では技術分野、どこに意識をかけて開発をしていたとかはありますか？
ota42y：転職したときには基本的にはゼロからスタートだったので。
もともとアプリエンジニアでRubyをちゃんとお仕事としてしっかり書いた経験はほとんどないので、一番下からスタートなんでRailsに慣れるみたいなことをやっていきましたね。
treby：あ、そうか。Railsを書いたことなかったってことなんですね。
ota42y：研修のときにやって、Rails 3とかは書いたことがあるって感じでしたね。転職した当時でRails 4.2ぐらいが出てて、5も出てたんだっけな、ぐらいの時期だったので。
割とRailsに慣れるっていうところから始まりましたね。あとはそもそもサーバーサイドに慣れるっていうところですね。データベースの話とかも、クライアントでもデータベースはあるんですけれどちょっと事情がだいぶ違うので。
treby：トランザクションとかが全然違うよね。
ota42y：そうそう。(トランザクション)っていうのがありますよね。みたいなところから慣れていくのを、はじめはやってましたね。あとはどれぐらいだろうな、1年か1年半ぐらい経つと大体まあ一端のRailsエンジニアになったぐらいで。
なので、そこからは割りと並行してなんですけども、割とチーム間の課題を解決するみたいな横断的な活動みたいなものを並行してやっていたりとかはしてました。
treby：私の中のイメージなんですけど、ota42yさんは、割かし複数チームにまたがった仕事をやってる、マイクロサービスの面倒を見てるっていう表現が正しいんですかね、してたと思うんですけども、そのポジションになったのが転職して1年とか経ったぐらいだったんですか？
ota42y：どっちかっていうとFiNCのマイクロサービスはちゃんとマイクロサービスしてなくて。1個の機能を作るためにマイクロサービスを超えての依存みたいなものがいくつか発生してしまっていたので最初期から。
どこかのマイクロサービスだけをやればおしまいみたいなことは実はなくて、「ここ」と「ここ」と「ここ」を触らないとそもそも機能が作れないみたいなことがたまに割と初期の頃はちょくちょく起きてたので。
なので、必然的にマイクロサービスと横断的な動きをせざるを得ないみたいな感じで動いてたんですね。
treby：ota42yさんに限らずみんなやってたっていうことなんですね。
ota42y：ですです。
treby：入って1年ぐらいでエンジニアの数も増えていったんじゃないですか？
ota42y：そうですね。ちょうど私が入った時期ぐらいがかなり急拡大をしていた時期で。私が入る直前から1年ぐらいで2倍ぐらいに増えてる感じです。
treby：その中でチームのメンバーも増えていって、マイクロサービスも増えていくと思いますけど大変なことってあったんじゃないですか。
ota42y：そもそもFiNCだと昔からあるマイクロサービスになる前のすごいやばいモノリシックになって、そこから徐々にマイクロサービスを切っていくんですけども。
このやばいやつの中には長く生きてる分、当然いろんな重要なビジネスロジックみたいなのが大量にはまってるんで、それいかにほかのマイクロサービスに移していくかみたいな話っていうのがやっぱり一番大変でした。移すっていうこと自体には特に何の価値もない。ユーザーから見たときには新しい価値を提供できないんで。
treby：ああ、リファクタリングのジレンマみたいなね、ありますよね。
ota42y：そうそう。なので、じゃあ移す工数がないから、こっちには新しい機能を作ってでも古いやつとうまく連動しようかみたいな話になってくるとマイクロサービス機能を超えて実質1機能を提供するみたいな、すごいややこしい形になったりとかするわけです。
マイクロサービスアーキテクチャを採用してみて
treby：モノリシックなものをマイクロサービスに切り出すってことはーーota42yさんが旗を振ってたかどうかはさておきとしてーーやろうとしたときに、こういうことには気をつけようと思ってうまくワークしたこともあればそうじゃないこともあると思うんですね。それらについてお聞かせ願うことはできますか？
ota42y：うまくいったことに関しては、私がいる最中に0から作ったマイクロサービスが何個だろうな、3つか4つぐらいなんですね。
そのうちの1個っていうのが主に健康系のアプリなんですけれども日々の食事とか体重とか歩数みたいなものを保存する、マイクロサービスっていうのがありまして。それっていうのを新しく作ったっていうのが割とうまくいったかなっていう感じです。
それはどういった情報がほしいかってのは、もともとやばいモノリシックにある程度動いていて、更に機能拡張する上で新しくもっと早く開発したいから新しいマイクロサービスに切り出して、そっちに移していきましょうみたいな流れで、作られたものなんです。
それに関してはもう新しい、これはもうどんどん回していこうみたいな。この機能をどんどん育てていこうみたいなコンセンサスがエンジニアもそうですし、ビジネスとか全社的にもある程度コンセンサスがそろっていたので。
切り出したあとも比較的すごい早いPDCAを1回回してどんどん機能拡張をしていくみたいなことがすごいうまくいったかなっていうので挙げられます。
treby：開発としてもビジネスサイドとしてもうまく回った例がそれだっていうことですね。最初マイクロサービス進めていく上で何か気をつけなきゃいけないなって思ってたこととかありました？手探りが多かったですか？
ota42y：そうですね。ただマイクロサービスをやる上ではオライリーの『マイクロサービスアーキテクチャ』っていう蜂の巣みたいな表紙の本がありまして。
それの読書会っていうのを同僚のqsonaさんっていう人が開催していて、割とアンチパターンみたいなものはすごいかなりしっかりと書かれている本なので。
結構サーバーサイドエンジニアとかも含めてエンジニア全体として、マイクロサービスはこうやるとやばいからこういうのは避けようかみたいなのがある程度共通理解として固まった上で進めたので。割と明らかにやばい方向に進むみたいなことはそんなになかった。
treby：極端にやばい方向に進むことはなかった。
ota42y：そうですね。実際に会社としても多分二代目か三代目ぐらいのマイクロサービスなので。一番最初にマイクロサービスやってるやつとかは全然うまくいかなくて。
マイクロサービスのアンチパターンと言われるいわゆる分断されたモノリスみたいな状態のやつがいまして、そこから次の段階として何とかうまくマイクロサービスに切り出したんだけれどもそこまでうまくチームとして回せないみたいな段階があって。
今言ったマイクロサービスの本を読んだあとの第三段階としてのマイクロサービス切り出しとして入れたやつとかは大体そんなに壊滅的にまずいみたいなものは全然なかったっていう感じ。
treby：気をつけようとして思ったのは、まず開発者陣の目線をそろえようっていうことなんですね。
ota42y：そうですね。っていうのとわれわれの知らないアンチパターンみたいなものをしっかりと理解した上でしっかり切っていこうみたいな感じ。
treby：マイクロサービスとかなじみありますか？banjunさん。
banjun：なじみないんです、私は。モノリスでしかやったことないですね。
treby：アプリエンジニアだとサーバーサイドっていってもバクっと、APIがあれば何とかなるっていうイメージがある。APIのAPIって感じですよね、マイクロサービス。
ota42y：そうですね。
treby：あれ一番いいのはコードベースをある程度ちっちゃい単位で回すことができるから変に調整が要らないんですよね。
ota42y：開発する影響範囲はすごいある程度コントロール下に置けるんで、割と早いPDCAを回してもあまり触ってないところっていうのは一切影響を与えないみたいな状態が作れるんです。
例えば課金系とフロントを共生すると、課金系は別途に変更しないから壊れてほしくないところでする。でもフロントはめちゃくちゃ早く回したい。なので、フロントの変更で課金系がぶっ壊れたりとかすると死んじゃうわけですよ。
っていうのをコードだけに完全に物理的にもしっかり分けてしまうことによって絶対に影響がないっていう状態、保証ができるんでフロントはすごい勢いでPDCAを回せる。で、課金系はゆっくりPDCAを回せるみたいなことができるようになる。
banjun：さっき言ってたのはRailsが何十個か立ってると。
ota42y：そうですね。
banjun：だから一個一個のマイクロサービスに対してRailsが立ってみたいな認識でいいんですね。
ota42y：ですです。Railsアプリが40、50ぐらいある、別々に。
banjun：また別の視点でいうと、Railsアプリが個別に立ってることで新しく入ってきた人とかがRailsアプリ1個単位で新しく作るなり、ウエイトを回収するなりっていうのはやりやすくて。
あるいはRailsアプリを1個増やすとかっていうのが普通にできるのはいいことかなって思って。逆にモノリスだったら、何だろうなめっちゃ気使うじゃないですか。「ここも変更していいか」みたいな。
しかもそのRailsアプリを「じゃあ1個作りますよ」っていう経験もする機会が皆無になるじゃないですか。と思っていて、それなんかアプリとかでも一緒で、iOSアプリとかってあんまり分割できないんですね。
それはお客さんに見える単位だから分割したらお客さんも分割に対応した使い方をしなきゃいけないんで。設計図のモチベだけで切るわけにはいかないんですけど。
そうするとアプリをスクラッチで作るっていう経験をする頻度っていうのが下がるような気がしていて、そういうのはなんかうらましいなって思うんですけどね。
ota42y：確かにアプリはユーザー体験に直結するんで分割とかは難しいですよね。
banjun：そうなんですよね。
ota42y：Facebookとかのはメッセンジャーをよく分割したなっていう感じです。FiNCとかもアプリとしては多分3つか4つぐらいに分けれるレベルの機能が載ってるんですけれども、ユーザー体験としてはやっぱり1個のほうがいいよねっていうのが分かるんで難しいですよね。
treby：メッセンジャーはもうあれだけでメールのオルタナティブな感じになってますからね。あれはすごいと思います。ビジネス上でめちゃ使ってます。
banjun：なんかかまたくっつけるとかくっつけないとかって話出て。
treby：あ、そうなんですか？
banjun：いや、よく知らないですけど。
treby：よく障害起きますよ。あれ障害起きると割と困るっていう、連絡取れなくなるから。
banjun：ああ、そうなんですね。
treby：そう。
マイクロサービスのアンチパターン(41:44〜)
ota42y：マイクロサービスだったら無限に話せます。これもRails Developer Meetupで30分ぐらい話したんで。
treby：ね。マイクロサービスの話とか。
ota42y：でもあれ5時間分ぐらい話すネタを出したうえでの30分なんで無限に話せます。
treby：やばい(笑)
せっかくだから聞いてみたいのが、マイクロサービスのアンチパターン。今からマイクロサービス始めようとしてるときの、そもそも導入するきっかけとか。勘所とか。ここはしくじったからやめたほうがいいよみたいなのがあれば、ぜひ。
ota42y：マイクロサービスは意外とコストが高いんです、マイクロサービス自体を維持するのが。
というのもマイクロサービスやると複数のまずサーバーが立つんで、そもそも通信して向こうと連携しなければいけないっていうので通信重なることによって通信が返ってこなかったらどうするとか、遅れて処理されたらどうするみたいな。確かそういう12の原則みたいなのがあるんですけど。
treby：何だっけ？Twelve-Factorなんちゃら。(The Twelve-Factor App)
ota42y：そうそうそう。Twelve-Factor何とかみたいな感じのことを考えなきゃいけないんで。当然一つのRailsアプリケーションとかだったらメソッド呼び出しが失敗するっていうことはまず考えなくていい。
banjun：ないですね。
ota42y：ので、そういった考えなければいけないところがめちゃくちゃ増えますと。当然トランザクションとかもかけられないんで、そこに対する対策のことを考えないといけないですし。
treby：通信自体がオーバーヘッドになってしまいますよね。
ota42y：っていうのもあるんで割と高価であるし、それがマイクロサービスと分割してうれしいぐらいの状態になるまでに割と時間がかかるんですよ。
チームの規模が大きくなってそれぞれが独立して動くようになったりとかすることによって初めて価値が出てくるんで。すごい小さいチームでマイクロサービスを、例えば3人のチームで5個のマイクロサービスを運営してますみたいな状態はすごいめちゃくちゃコストもかかってるので、どのタイミングでマイクロサービスにするかっていうのはすごい気をつけないといけないなっていうのがあります。
treby：一方でモノリスで進めたものをいざマイクロサービスにしようとしても、それもなかなか難しい話だと思いますね。
ota42y：まあ難しい話になるんですよね。Amazonぐらいまででかくなったときにマイクロサービスやってないと絶対死ぬんです。でも3人のスタートアップでマイクロサービスやってたら死ぬんで、そもそも。
最終的には絶対マイクロサービスなんですけども、じゃあいつモノリシックからマイクロサービスにするか、やっと移行するとなったとして、移行するのはじゃあどれくらいの規模なのか、っていうのは答えがない問題ではあるので。本当にケースバイケースだったりとかするのでめちゃ判断にすごい迷うなあ。
treby：アンチパターンは、エンジニアの数よりもマイクロサービスの数のほうが大きくなったらそれはあかんわなっていう気がしますけどね。
banjun：ああ、やっぱそうなのかな。
treby：じゃないとメリットを享受できなくない？って思う。そもそも大人数の人で一つのモノリスなのを開発してると、調整とか影響範囲が読めないからやりづらいよねってのが生まれてくるんですよね。
ただ「2枚のピザ理論」じゃないですけど、多くても8人ぐらいで一つのリポジトリは見たほうがいいと思ってて。
ota42y：かといって一人で5個見てもしょうがないんですよね。
treby：そう。マスタープッシュとかしてどんどん、分かんないけど見えないところで「クソコード」がプッシュされるみたいな。リスクがあるわけだとね。
「クソコード」っていう表現をあえて使いましたけど、ノンレビューのコードっていう。
ota42y：そうです、そうです。ただ難しいのがやってるときはすごく楽なんですよ。それはもうだってレビューされずに自分の会社だと100%通るし、しかも規模も超小さい。
マイクロサービスにすれば本当に自分が見渡せる範囲ぐらいのRailsのアプリケーションになるので、本当に全能感みたいな感じで。めちゃくちゃ作ってるときは超楽しい。
それがほかのところと連携したときとか、メンテをして長期間してるとか、長期間運用していくとだんだんあとからつらいのがやってきて。
treby：そこそこファットになってきたときに、あるマイクロサービスとあるマイクロサービスの設定試走が違うとかが生まれるし、下げようとしたら、あれ？うまくつながらないじゃないっていうのはあるし。
ota42y：とか、どっか一箇所が落ちるとそれに依存するほかのマイクロサービスもどんどん落ちていくみたいなところもあるし。このデータはどこから来たのか分かんない、けど何か入っているみたいなのがあったり。
treby：マイクロサービスに問い合わせて帰ってきたデータの元データがそのマイクロサービスじゃないとこから来てるパターンとか。
ota42y：とかもそうですし。あとセキュリティとかの問題もあって。例えば50個あるとどこかに1個にやばいgemの脆弱性とかが入ってるとアップデートしないと困るわけじゃないですか、そいつを。
でも50個あるとメンテしきれないんで、自分の脆弱性が半年以上放置されていましたみたいなのがあったりするとやばいわけです。
treby：ありそう。
ota42y：っていうのを割とコストがかかる。例えばモノリシックとかだったらとりあえずやばい状態っていうのはみんなが見てくれるんでコントロール下に置けるじゃないですか。「やばいこれ、gemは脆弱性があるけれども自分たちのところであそこの数を踏んでないから無視しよう」みたいな意思決定ができるんですけども。
50個あると見きれないのでやばいやつがいるかもしれないっていうアンコントローラブルな状態になるっていうのがめちゃくちゃやばくて。
treby：誰もボールを持ってないリポジトリでそれが起きてたりするとただやばいっていう状況になるし。
banjun：だからそのために一つはマイクロサービスの数よりエンジニアが多いことみたいにして、どのリポジトリも誰かが常に見ているというふうにしたいっていう、そういうことですか？
treby：その辺りがまさにマイクロサービスが組織論だっていうふうに言われてるとこの大元かなと思いつつ。ただマイクロサービスは組織論じゃねーよっていうふうに言ってらっしゃる御社のqsonaさんとかも言ってただけですけど、彼らの主張はどういうことなんですか？
ota42y：割と私とqsonaさんの意見は結構全然違う方向向いていて。というのもおそらくいる立場が違っていて。
qsonaさんはどちらかというとSREみたいな。要は横断的に見る場所としての意見、私はどちらかというとアプリケーションエンジニアとして、Rails側の直接アプリケーションを書いたりとか、チームのKPIをコミットするみたいな方向からの意見からなので。
割とそこで多分意見の、立場の違いと向いてる方向の違いから出てくる意見がずれるのかなっていうのがあります。
treby：レイヤーが違うと意見が変わるんですね。
ota42y：そうですね。
treby：どちらも開発者という意味では近いのかなと思ったんですけど。
ota42y：どっちかっていうと、例えばマイクロサービスにすると当然自分のチームと別のチームとの間に存在するボールっていうのがやっぱり増えてくるので。
マイクロサービスが増えていくと当然マイクロサービス間の問題っていうのがボンボン出てきて。同じモノリシックだったら起きなくてもいいとか、モノリシックだったら無視できるような問題であっても、マイクロサービスだとやっぱり問題が無視できなくなる。
例えば通信が失敗するとかまさにその例で。モノリシックだったら通信とかないんで失敗しないじゃないですか。でもマイクロサービスだとはそこに関して考えていかなければいけない。
でもアプリケーション側のチームとしてのKPIを考えていきたいほうとしては、できる限りそういったものがないと、それを解決したからといってKPIが伸びるわけじゃなくて正しい数字に戻るだけなんです。それによってユーザーにとっていい価値を提供できるわけではないので。
そういった問題は可能な限り少ないほうがいい。そういった問題にやっているよりもKPI、要はユーザーにとって価値のあるコードを作ったほうがいいって話になる。
かつ、FiNCの場合だとチームにエンジニアが一人で複数個のマイクロサービスを持つんで、チームにサーバーサイドエンジニアが一人しかいないわけですよ。するとマイクロサービス間の横断的な課題を解決してる間、そのチームのKPI伸ばすための活動ができる人はできる0人になるっていう問題が起きるわけです。
そうすると自分たちのチームとしてKPIを伸ばしていくっていうのが目標として置かれているんですけれども、当然ほかのことに、このほかのことやっている間、やると自分たちのKPIは伸びないっていう。
でもほかのことを放置してるとそれはそれでバグとかになり、やばい状態になって最終的に困るっていう。直したいんだけれども直すと逆に今度は自分たちの目標が達成できなくなるんで、すごい今度はかなりジレンマってのが起きるんですよ。
treby：リソースをどっちに振るかってことなんですね。
ota42y：そうそうそう。っていう意味でマイクロサービスとしての問題はかなり大きく捉えていて。当然それが技術横断的な場所だとすると、当然チームとしてのKPIが多分KPIになるので。そうすると当然注目するべき場所っていうのが違うので。
treby：言わんとすることが分かってきました。
ota42y：っていうので印象っていうのが多分全然違う方向を向いていくっていうのはそういうことなのかな。
treby：置いてるKPIが違うから当然関心するところも、関心を持つところも変わってくるよねっていう話。SREっていうのはチーム横断の課題を何とかするっていう意味合いで使ってたわけですね。で、アプリケーションはどちらかというと事業にコミットする側なので、と。
ota42y：新機能を作ってユーザーに新しい価値を提供していくっていうのが最も重要な目標として捉えられる。そうでない活動っていうのに関してはすごく動きにくい。
でも、そういったところの問題がめちゃくちゃ増えると、めちゃくちゃ動きにくいところにめちゃくちゃでかい問題があるっていう状態になってしまうのですごいあまりよくない印象。
treby：デザインパターンってあるんですかね。アプリケーションエンジニアとインフラエンジニアがなんとなくギクシャクしてしまうところのロジックに似てる気がしますけど。
ota42y：人数がいれば全て解決するんです。
例えば今のだったらチームに3人いればそのうちの二人をチームのやつに渡しといて、一人はほかのチームとの間にある問題を解決に入りましょうみたいなこともできるんでいいんですけれども。
一人とかにすると、それをやっている間チームが動かなくなってしまうっていうジレンマがあるんです。そういった意味でチームの数が多すぎるとアプリケーション側としてはすごい大変になってくるんじゃないかなっていう印象は受ける。
treby：人数が多かったらそれはそれで今度マネジメントの話が出てくると思うんですけどね。そこのはやりがあるからエンジニアリングマネージャーってのが今伸びてきてるんだと思ってますけど。
ota42y：人数が少ないは少ないです、レイヤー。
treby：今の御社で見えてる問題としてはそもそも人数がそんなにいないという感じですかね。
ota42y：とはいえそこに関してコストを払って無視するっていう解決方法も1個あって。うちとか今は40個ありますけれども、その分のコストを払って何とかしているんで。
そのコストが払えるんだったら最終的に、例えば今から人数が10倍になったときにマイクロサービスに切り出すっていうのも当然コストはかかるので、だったら最初からマイクロサービスで、最初から最終系に近いほうが全体見たときは楽ではあるっていうのは確かにその通りではあるので。
本当にそのコストを払う覚悟があるんだったら最初からマイクロサービスするっていうのもう1個の解決法かなっていう感じはします。
ちょっと前の私に伝えたい「英語は大事だよ」(52:56〜)
treby：はい。じゃあいつものコーナー行きまーす！
ota42y：ワー。
treby：なんかね、元気出していったほうがいいらしいんですよ。
banjun：元気ねえ。出せるなら常に出すべきや。
treby：あ、本当？出していいの？なんかこのテンションの中でで一人だけうざいやついるとさ、はみ出るじゃん(笑)じゃあ出していきましょう。
banjun：はい。
treby：はい。じゃあちょっと前の私に伝えたいのコーナー！
ota42y：ワー。
banjun：元気やなあ(笑)
treby：めっちゃ笑い声聞こえてくるね(笑)ということでこのコーナーの趣旨ですね。今までもうota42yさんも6年エンジニアをやっとるわけですけども、少なくともジュニアではないと思っておりますと。
ちょっと前のちょっと前はもうそれぞれで考えていてほしいんですが、このときにこう考えてたら良かったなとかいう反省点、もしもあればそれをお聞かせ願いたいというコーナーでございます。
ota42y：むずいやつですね。
treby：ありますか？
ota42y：そんなにそこまでやっちまったみたいな感じの後悔はないことはないんで。うーん、英語は大事だよっていうのを、学生時代ぐらいまでガッツリ戻って(伝えたいですね)。
banjun：英語ですか？
treby：banjunさんが反応してる(笑)
banjun：最近私も英語登壇したんで。英語大事ですね。何で英語大事だと思ったんですか？最近あったんですか？
ota42y：そもそもRubyKaigiは英語で発表なので。英語が分かってればもっと直接発表者のしゃべってることみたいなことを理解できるんで。
banjun：それは英語で登壇をしたという意味ではなくて英語で登壇されるスピーカーが多いから、その話は普通にスラスラと聞いて、何なら質問しに行きたいみたいな。
ota42y：したいですし、英語で発表できれば当然より多くの人に対してアプローチができるので。そういった意味では英語ができれば良かったかなって1個ありますね。
treby：何か今アクションを取っていたりとかするんですか？
ota42y：とりあえず今だと、サファリオンラインっていう、オライリーか。オライリーの英語版のほうなんですけれども、そっちのほうは読み放題プランっていうのがありまして、英語版のオライリーのほう。
ota42y：それに入ってとりあえず英語を読むことを意識しようみたいなことをやってたりします。
banjun：読んでるんですね。
treby：リーディングのほうなんですね。
ota42y：とりあえずリーディングから。あとヒアリングも何とかしたいんですけどね。スピーキングが一番むずい。
treby：まずヒアリングしないと返しようがないよね。聞き取れないんだよね。
banjun：でもしゃべる気で聞かないとそもそも聞こえないみたいな。
treby：あ、そうなんですね。
banjun：なんかそんな気もして。ついどっちが先？みたいな。英語を聞きたい、あるいはしゃべりたい動機っていうのは海外登壇者、日本語以外、英語で登壇する人の話を聞きたいっていうことになると、そういうコンテンツをたくさん聞けたらとりあえず良さそうですけど。どうなんですか？RubyKaigiとかは動画とかは上がる？
ota42y：RubyKaigiは全て動画上がるので、そういったのは見ていこうかな。とりあえずちょうど今無職中なので、暇なので。
banjun：お、無職中。
ota42y：動画を見たりとかしていこうかなっていうのは考えたりしてます。あとは何だろう、あ、数学から逃げない、数学は頑張りましょうっていうのはちょっと。
ちょうど何だっけ、『ゼロから作るDeep Learning』っていう本を読んでいて。そいつは本当にディープラーニングの理論から入って、コードを書いて実装するみたいな感じなんですけども。
やっぱり理論の部分でなかなか何なんでこうなるんだ？っていうのがいくつかあったりとかするんで、やっぱり数学はしっかり勉強しておくと後々いいことがあるっていうのを学生時代ぐらいのときに伝えたい。
treby：そう。学生時代の勉強って一見役に立たなさそうに見えるんだけども、学びたいって思ったときにショートカットできるのはいいよねって思いますよね。行列とかでもやったんじゃないですか？
ota42y：そうですね。割とやってたんですけど、やっぱり理解のクリア解像度が全然違ってたなっていう感じがありますね。それこそ行列同士の掛け算とか普通にできるんですけども、ちゃんと証明が読めるようになる、タスクもそうですし。
その行列同士の掛け算はどういうふうに現実世界に応用していくのかみたいなところに関しては全然視点が足りなかったんで。そういったところは割としっかりと勉強していくべきだったかなって感じですね。
treby：学生のとき勉強できたかっていうと結構怪しい気もしますけどね。なんか紐づかないと思うんだよね。
ota42y：そうなんですよね。
treby：有効桁数って俺全然学生のとき理解できなかったんですよ。何で有効桁数必要なん？みたいな。
ota42y：実験とかやらないと分かんない。
treby：実験とかやったりだとか、そんな細かいところは気にしなくてもいいとか。あと割と工学のほうなんですけどね。情報っていうよりも工学のほうなんですけども、「倍半分は誤差のうち」っていう言葉があったりして。10倍、1/10ぐらいのレンジにいらないと、それは誤差のうちに入らないですね。だから大雑把でもいいからとりあえず値出して仮説を立てるのが大事だっていう。現場を知ってるからかその肌感ですね。
ota42y：学生時代にいっぱい本を読んでたんですけども大体忘れてしまってるのでちゃんとメモ残すとか。なんかアウトプットしとかないとあんまり頭には残んないよっていうのは伝えておきたい。
treby：でもそれ今からでも使えそうですけどね。
banjun：これから読むもの。
treby：そう。アウトプットする習慣。
ota42y：学生時代に1000冊ぐらい本読んでたんで。それを全部残して読んだら良かったんですね。
treby：めっちゃ読んでるやん(笑)
ota42y：それを全部残しておけばいい、
treby：ログね。
ota42y：ログになってたのにっていうのはちょっとありますね。
treby：アウトプットサボりがちだよね。分かる。
ota42y：そうなんです。アウトプットサボるすることが多かったんで、そこはもうちょっとアウトプットしたほうがいいよってのは伝えたい感じです。
treby：同じもののアウトプットを3回ぐらいしたら記憶に結構定着してくれる気がする。肌感的に。どう思います？
ota42y：でも3回も、とりあえず1回やるとやらないのだと、1と0だと全然違います。
treby：全然違う。でも今からでも全然やっていけそうなことが多いですね。
ota42y：そうですね。
treby：英語、数学、記憶。
ota42y：時間のある学生のうちにやっておけば。
banjun：やっていけるのかな。時間はね、本当に時間食う内容ばっかりじゃないですか、それどれも。
ota42y：どれも時間が食うんです。
treby：時間がある今のうちに。
ota42y：時間がある今のうちに。全部やろうとするととてもじゃないけど時間が足りないんですよ。
treby：時間があってもね、やらないものなんですよ。なんかね、追い込まれてたほうがね、やるってこともあったりするから。そこの、ハックしながらやっていきたいですね。
banjun：まあそうですね。英語も登壇することになるとめっちゃ追い込まれて何でもやるぞみたいになったり、いいかもしれないですね。
treby：なんか仕組みで解決したいよね。それを世の中はライフハックって呼んでるんだろうけどね。
banjun：まあそう。好きなときに追い込まれるような仕組み。
ota42y：頭に全部インストールできるようになってほしい。追い込まれなくても自動で済んで。
treby：そもそも人間の頭の欠陥だから、外部記憶なりなんなりでフォローして、と(笑)
ota42y：1回で覚えられないとおかしくないですか？
treby：ディストピアですね(笑)
おたより「RailsのJSONシリアライザって次は何使うべきか」(1:00:34〜)
banjun：はい。じゃあ次のコーナーはお手紙のコーナーですね。ふつおたってやつです。ふつおたなんですけど、今日はota42yさん宛にtakanamitoさんからお便りが来てまして、読みますね。
「RailsのJSONシリアライザって次は何使ったらいいんですかね」っていう話で。
treby：ガチ質問やん(笑)
ota42y：ありがとうございます。ガチ質問だ。
banjun：すごいなんかね、技術的な質問でした。
ota42y：分からない人のために説明しておくと、Railsは基本的にHTMLを吐き出すためのフレームワークなんですけれどもJSONモードってJSONを介すようにするモードっていうのがあるんですね。
それを書くときにはRuby上のオブジェクトがどういうふうにJSONにマッピングされるかっていうのを書かないといけないんですね、基本的に。そうじゃないと全部のデータが出てしまうんで、必要ないデータとかも全部シリアライズされて出ていってしまうので。
そうではなくて必要なものだけを動かしてあげるみたいなものを書く必要がある。Railsって標準でもいくつかあったりするんですけどもあんまり使いづらいので、割とみんなJSONにシリアライズするための自分みたいな、ガイドラインみたいなものを入れてることが多いんです。
ちょうど今界隈ですごい使われてるのがActiveModelSerializersっていうやつで、みんなそいつを使ってJSONにシリアライズしてることが多いんですけれども。1年か2年ぐらい更新が止まっていて。公式のREADMEにも、これはもうメンテされないんでっていうふうに書いてあるんです。
banjun：お？
ota42y：なので、みんな次どうしようかっていうのがみんな考えていて特にこれだっていう決定的なやつがないので、こういう質問がいろんなところで出ている。
ActiveModelSerializersの代わりなんですけれどもfastjsonっていうライブラリがありまして。Netflixだっけな、か何かが出しているfastjsonっていうFastHubを出してたときに。これがいいんじゃないかなっていう感じですね。
treby：その根拠は？
ota42y：fastjson自体はJSONを書き出す以上のことをやっていて、JSON:APIっていう規格があるんですけれども。それでJSONを書き出すみたいなことをやっているんですけれども。
JSON APIじゃなくて単にただJSONをシリアライズするためだけでも使えるという話を聞いたので、かつこいつらめちゃくちゃ早いっていう点があるのでこれを使うのがいいかなというふうな感じです。JSON APIの部分はオーバースペックすぎるんですけれども、JSONを書き出すだけでも使えるのでいいんじゃないかなと。あ、fastjsonじゃない。fast_jsonapiか、Netflixの。これが良いのではないかな。
treby：じゃあota42yさんのおすすめはこちらのNetflixだと。
ota42y：そうなんです。もしくはblueprinterっていう同じく確かJSON API用のやつがいて、そいつもJSONで書き出せるんですね。
そいつはActiveModelSerializersのREADMEとかにも、次はこれを使うといいよみたいな選択肢の中でも分かってるぐらいなので。そのblueprinterかfast_jsonapiのどっちかかなっていう感じ。
一応、ActiveModelSerializersをメンテするって方向性も考えたんですけれども、ActiveModelSerializersは結構入り組んでいるので、まあメンテは無理かなという感じがしました。ほかのに乗り換えるのが良さそうかなと。
banjun：そのJSON:APIっていうのは何ですかというか。
ota42y：JSONって要はただ単にkeyとvalueだけなんです。JSON:APIは、keyとvalueだけではなくてJSON機体で例えばリンクを表現しよう、例えば次の要素はここありますよみたいなリンクを表現することによって(利便性を高めようとしている)。
例えばJSONってAPIを知らないと戻り値が得られないじゃないですか。でもJSON APIを使うと、例えばあるトップページにアクセスしてJSON APIのレスポンスをもらいます。
そうするとその中にこの情報を得たい場合はこのAPIにアクセスしてくださいねみたいなリンク情報が添付されているんですね。そのリンクをたどっていくといくことによってさらにほかのデータが手に入る。いわゆるHypermedia。
banjun：まさにHypermediaですね。link metaみたいな？
ota42y：そうそう。みたいなものをJSONで表現使用みたいな感じの仕様。
banjun：だから何かをゲットしたときに、次に見るべき項目のIDが入ってるんじゃなくて次に見るべき項目のエンドポイントがもう書いてあるからそこを叩けばいいみたいな。
ota42y：それを叩くだけでオッケー。ただ今おそらくそこまで作り込むことでクライアント側もそれに対応したように作りこまないといけなかったりしますし。かなりオーバースペック。
banjun：シリアライズとかの話とはまるで違うレイヤーの話。
ota42y：そうそう。違うレイヤーの話になってしますのでオーバースペック。なんですけれどもそこの機能は使わずに普通にシリアライズだけでも使ってもいいので。
treby：大規模のアプリケーション作るときは、そのJSON APIの規格にのっとったようなJSON Schemaっていうんですかね。何かあるじゃないですか。
ota42y：いや、JSON SchemaとJSON APIはまた別ですね。
treby：別なんですか？
ota42y：そうなんです。JSON Schemaは本当にそのJSONでオブジェクトを定義するための仕組みみたいもので、JSON SchemaはOpenAPIもJSON Schemaに依存しているぐらいの感じの関係性なんですけれどもJSON APIはそうではなくて今言ったようにHypermediaとしてのほうなんですね、表現的に。
banjun：Hypermediaね。例えばSwiftのクライアントみたいな、型つきで扱いたい場合に場合どう扱っていいかとかなんか結構課題あるなって思ってるんですよね。
ota42y：でもブラウザとかもCで書かれてるんで型つきでできるですよ。
banjun：やばい。何だろうウェブページ自体は別に型ついてないから(笑)
treby：ウェブページに型はないから。
banjun：うん。そうそうそう。
ota42y：Hypermediaを解釈するブラウザってのを作る。JSON APIを解釈するブラウザってのを作って、いろいろ実装するんですよ。
banjun：要するにブラウザのことですね。
ota42y：そうです。
banjun：はい。ありがとうございます。
今回の転職について(1:07:05〜)
banjun：今回ota42yさんに来てもらってますけど。最近退職エントリとかで聞いて、この度転職されるということで。ちょっと言える範囲でいいんですけれども、もう次に行くところとかその時期とかっていうのは何か決まってたりするんでしょうか？
ota42y：実際どこまで言えるかどうか分かんないんですけれども、転職先としてAI系のベンチャー企業に入る。時期としては7月1日からなので、おそらくこれが公開時には既に新しい転職先で働いているっていうのがあります。
treby：AI系ってことはRailsじゃないんじゃないですか？
ota42y：そうなんですよ。おそらくPythonガリガリっていう感じですし。あとは例えば社内とかでアノテーションツールみたいなのがあったとしても、メインはおそらくPythonなのは確実かなっていうのはあります。
treby：Python書けるんですか？
ota42y：FiNCでRailsエンジニアって言ったんですけれども、実はちょうどRubyKaigi終わったあとからはRubyを全然書いてなくてですね。5月、6月はずっとPythonを書いてたんですよ。
banjun：とはいえ最近の話ですか。
treby：慣らし始めた(笑)
ota42y：SparkってHadoopの上に乗るやつがあったりとか。
banjun：apacheの？
ota42y：そうそうそう。っていうのを使った機能を作っていて。一応SparkっていうのはScalaなんですけれども、PySparkっていうPythonからも使えるようになっていて。
https://spark.apache.org/docs/latest/api/python/pyspark.html
ひたすらそのPySparkで延々とやっていたのでほとんどRubyを書かずにPythonをずっと書いてるみたいな感じだったんです。
treby：それは機械学習みたいな機能ですか？
ota42y：いや。どっちかっていうとマイクロサービスをやってると分断されたモノリスではなくて、きちんとマイクロサービスごとにデータベースがあるっていうような構成を取ってるんですね、FiNCは。
ただ、ユーザーから見た時ときには当然マイクロサービスとか関係なくて、一つのFiNCアプリとしての世界観なので当然マイクロサービスごとに点在しているデータをつなぎ合わせて1個の処理がしたいとか、1個の体験を与えたいみたいなものがやっぱりどうしても出てくるわけです。
じゃあそういったときにどうすればいいって話なんですけども、データベースの共有はさすがに死んでしまいますし、例えばAPI経由でデータをやり取りするっていう場合もちょっとぐらいだったらいいんですけれども、すごい大量のユーザーとかになってくると死んでしまう、同じように死んでしまうんで。
そういったときに各データベースから、例えばS3とかにデータを書き出しといて、そのすべてのデータがたまっているデータ、データ履歴っていう一般的には言われるらしいんですけど、そういったデータがたまっているような場所っていうのを作っといてそこに対して予告して処理をするみたいなことがしたいなという感じになって。
そのときにSpark、AWSのSparkを。AWSがSparkマネージドサービスみたいなものを提供してて、それを使って全てのマイクロサービスのデータを予告して処理するみたいなことをやっていたんです。
treby：ちなみにRubyKaigiのあとからPythonを書き始めたってことなんですが、RubyKaigiの時点ではもう転職すること決まってたんですか？
ota42y：そうですね。転職自体はそもそも去年の12月ぐらいから考えてて、1月ぐらいから動くかみたいな感じで考えていました。それで、2月とか3月ぐらいで転職活動していたっていう感じです。
ただ2月と3月で、2月はAWSのコミュニティ系のイベントと3月はRails Developer Meetupってやつと、4月はRubyKaigiってやつがあって、3カ月連続で100人以上ぐらいなのが連続してたんで。
treby：カンファレンスラッシュですね。
ota42y：そうそう。
banjun：全部登壇したの？
ota42y：全部登壇して。なので、それと並行してみたいな感じなんで、そこまでがっつりと転職活動、多分この1個前のぷりんたいさんみたいに100社回りましたみたいなことはなくて。
treby：まあ100社はやばいよね。
banjun：まあやばさの方向が違うけど。
ota42y：実際選考に進んだのは10社ないはずなんですよね、今回。5社ぐらいしかないはず。
treby：そうなんですね。
ota42y：何社か聞きに行ったのも合わせると10社行ったかなぐらいの感じ。
treby：その転職活動するにあたって大事にしてた軸とか、こうしてみようって思ってたとことかあるんですか？
ota42y：転職理由に関しては割と強く考えてて、テクノロジーとしてより伸ばしていくかすごいもっとプロダクトに寄っていくかっていうのはちょっと迷ってたんで、その両方の軸でいくつか会社を見て回ったりとかしました。
treby：でも不思議ですね。プロダクトの軸と迷ったんですね。
ota42y：そうそうそう。どっちかっていうともっと小さい企業でプロダクトをバンバン作くっていくっていうのもまあ面白くはあったので。FiNCでそういうふうなチームに、一時そういう感じのチームになっていたのでそういったことをもうちょっと会社としてやってるところに行こうかっていうのもちょっと思ったりとかはしてました。
treby：というのもドリコムさんでは結構プロダクトとしてやってたことがあったと思うんですけど、そのときは技術の軸で転職したのに次の転職ではプロダクトの軸に入りそうになってたんですよね。
ota42y：そうなんです。
treby：心変わりとかはあったんですか？FiNCでの2年間で。
ota42y：心変わりというか、どっちかっていうとそもそも大きな方向性としてはよりテクノロジーが価値に直結する場所に行こうっていう。
treby：そこは一貫してるんですね。
ota42y：そうですね。それか、例えばまだあんまりまだまだ直すところがいっぱいあるプロダクトに行って、プロダクトを直しつつもテクノロジーの力で価値のあるプロダクトを作るっていう軸で行くのか、それとももっとより難しいテクノロジー、高度なテクノロジーでほかの人には解決できないような問題を解決していくみたいな方向で行くかどっちで行こうかなっていうのを考えていたって感じ。
treby：技術を研鑽する方向か研鑽した技術をすごくより使っていくか。
ota42y：そうそう。より使っていく方向かどっちかなっていうんで回ってた感じ。
treby：じゃあさっきのAIやってるベンチャーってことは、最終的には前者のほうを選んだっていうこと？
ota42y：そうですね。もっとより。実際問題世界的に見たプログラマーの中で私はどれくらいかっていうとおそらく中の中の上にいたらいいな、中の中ぐらいかなみたいなレベルなので。もっとレベルを上げたいなっていう。
もっともっとレベルを上げていかないといかんなっていう感じで。より自分よりも強い人がいっぱいいるところに上がっていく。
treby：一番の下手くそはいいよね。それは大変だと思うんですけども、本当に。転職してからしばらくしたらね、きのこるのほうにも来ていただいて、近況お話を聞かせてください。
ota42y：差分を話せれば、と。
クロージング(1:13:57〜)
treby：そろそろお別れの時間が近づいてきました。きのこるエフエムでは番組へのお便りをお待ちしております。
banjun：お便りはきのこるエフエム公式Twitterアカウントへのリプライか「(ハッシュタグ)#きのこる」をつけてツイートしてください。お待ちしております。
treby：お待ちしてまーす。今日1日ありがとうございました。
ota42y：いえいえ、ありがとうございました。
treby：どうでした？撮ってみて。
ota42y：いや、話すことがないかなって思ったんですけど、意外とあったんで。
treby：めちゃ話してましたね(笑)すごいこちらとしてはota42yさんのことを深掘りできて。
banjun：よく技術ネタは多いですね。
ota42y：そうですね。でもこのちょうど直前にぷりんたいさんの収録を私横で聞いていたんですけど、ぷりんたいさんはめちゃくちゃしゃべる、しゃべるなんで。それと比べると全然しゃべってないけど大丈夫かなって。
treby：まだ自己紹介終わってないですからね、彼(笑)
banjun：そうそう。自己紹介がね。でもそれに引きずられていっぱいしゃべろうっていう気持ちがもしあったならそれはいいことですね。
treby：今から新しい環境ということでですね。これ出た頃には頑張ってらっしゃると思うんですけども、意気込みみたいなのはありますか？
ota42y：とりあえず試用期間でクビにならないように頑張ります。
treby：めっちゃね、ota42yさんがお腹さすりながら言ってるのが新しいなって思うんですけどね(笑)
banjun：常に新チャレンジで行くということで。
treby：私からしたらどんどんota42yさんが遠いところに行くって感じもしますけど。それではそろそろ締めたいと思います。また次回の配信をご期待ください。番組はマネジメントに攻めるRubyistのtrebyと、
banjun：スペシャリストになりたいiOSデベロッパーのbanjunとゲストの、
ota42y：ota42yです。
treby：ありがとうございました。
banjun：ありがとうございました。
ota42y：ありがとうございました。
treby：バイバイ。
この記事が気に入ったらサポートをしてみませんか？