Day 1
安全かつ高速に進めるマイクロサービス化
トレジャーデータ社でも無茶な作りのシステムで苦労したりすることあるんだなーというのが新鮮だった。超人集団だからソフトウェアも完全無欠な印象がある。（自分の中で、日本のWeb系エンジニア界隈における超人集団の会社は、10年前がはてな社、5年前がクックパッド社、現在がトレジャーデータ社という風に移ろっている）
明け方まで自分のスライド作りをしてて寝不足だったので細かいところを意識が飛んでて聞き漏らしたので、動画が公開されたら見直したい。
学校をより良くするために、エンジニアができるたった一つのこと
事業ドメインが同じというか競合なのでいろいろ事情が似てるなーと思った。
発表後にささたつさんと少し話して自分の発表内容の話もして（マイクロサービス化）、「同じ問題を抱えているのに結論が逆なのは面白いですね（クラッシー社は一旦一つに統合する戦略）」、という話をしたが、実は発表では割愛したけどクイッパー社はマイクロサービス化に合わせて monorepo 化も進めており、サービスは細分化していくがデプロイなどはむしろ単純にしていく戦略をとっている（k8s のクラスタ？を常にまるごとデプロイする、みたいな感じらしい。そのプロジェクトにあまり関わっていないので詳しいところを説明できるほどには理解していない）
365日24時間稼働必須サービスの完全無停止DB移行 〜MongoDB to Amazon Aurora〜
データ移行の戦略が全体的に「ソフトウェア・エンジニアリング」って感じでかっこよかった。フラグごとのポリシーの設定の仕方とか、 DB アクセスをプロキシする層をかませそびれてないかどうかをチェックする方法が「mongo driver にパッチ当てて警告ログ出すようにして production デプロイして数日ログを眺める」とか、実践的。「jruby 使うことになるだろうなーと思いながら最初から jruby でも動くように作った」とか、その勘もわかるしすごい。「最終的に別のプログラミング言語のディレクトリが爆誕」とあったのでてっきり go か rust でも出てくるのかと思った。7億ドキュメントの持ち主は何者だったのか、7億ドキュメントが平均的なユーザーと比べてどの程度異常だったのか気になる。
Microservices Maturity Model on Rails
「マイクロサービス化の意義は、各サービスがそれぞれのタイミングでリリースできるので、ビジネスの速度を早められる」みたいなことをたしか言っていて、「それだけじゃないよなー」と思いつつも、ビジネス側の人に意義を理解してもらうには一番効く説明方法になるだろうなと思った。
Day 2
Observability, Service Meshes and Microservices
マイクロサービスまだ不勉強なので内容を理解できたとは言い難いが、クックパッド社は相変わらずすげーなーと思った。
余談だけど、個人的にここ数年の「Web系エンジニア界隈ノリ」が苦手で（LGTM 画像とか、アニメとアイドルの話をスライドに盛り込むとか、ウェーイとか）、なぜかクックパッド社の人たちのプレゼンは、独特のノリが盛り込まれていつつもあまり苦手に感じなくて、社風というか文化みたいなものなのかなーと思った（なんとなく柔らかい・優しい感じ。「サービスメッシュ自作勢」とか、「○○勢」っていう言い回しも、近年の若手Webエンジニア界隈の用語だと認識していて、基本的にこの言い回しを使う人を見かけると「あっ、こいつとは気が合わない」と感じてしまうのだが、今日は不思議とそうは感じなかった）
冴えてるRailsエンジニアの育て方
選考において気にしてるポイントはほぼ同じだった。というか、俺が気にしてるポイントは全て押さえられていて、プラスアルファについて学びがあった、が正しい。
- コード試験の課題を課すとき、予実（完成までの見積もり作業時間と、実際にかかった時間）を出してもらう、というのは考えもしなかった
- スキルとゲームプレイのヒアリングシートを記入してもらって面接時の質問ネタにする、というアイデアは素晴らしいと思った
Railsと非Railsの間
default_scope の活用例について、 Day 1 の wovn.io の人のアプローチが使えるんじゃないかな、と思った（どっちもアリなのかな、と思いつつ、フレームワークの機能で暗黙に動作するよりも、自分のコントロール配下におけるもののほうが制御しやすくて信頼できそうな気もする）
バス因子が自分でバス因子を脱するための方法
私的ベストトーク。なんだけど、途中で心を揺さぶられるような内容があって、それ以後の話が頭に入ってこなかった。
それは「自分が他の誰よりもはやく誰かの『困りごと』に対応するのが正義だと思ってやってきたが、『なんでも知っててなんでもできるあなたが誰よりもはやく対応し続けると、他のひとから機会を奪っている。だから対応してはダメ」という話で、もちろん実際にはこんな強い言い方ではなくてもっと優しさのあるコミュニケーションだったのだろうと思うし、結果的に挑戦・学習する機会を奪っているのも事実なわけでもっともな意見だと思うのだが、「自分が最速で対応するのが正義」は 100% 正しい。正しいのに、自分が正しいと思うことをやっていたらいつの間にかそれが他者や組織にとっての悪になってしまい、自分が正しいと信じることが「やってはいけないこと」になってしまった、というのは、悲しすぎる。悲劇だ。正直、「いや、他の奴らが対応遅いのが悪いだろ。速く対応してるのは偉いじゃん。なのになんで『やってはいけない』になっちゃうんだよ」と思ってしまった。
スタートアップの立ち上げ時期から働いてて、「なんでも自分でやるのが当たり前」という意識でいるひとと、そうでないひとの間のギャップ、みたいなのもあるのだろう（発表でも触れられていたような気がする）。たぶん、こういう出来事がターニングポイントになる気がしていて、自分の信念を貫きたいという想いが勝るなら「自分が最速で対応することが正義でいられる場所」を他に探すのだろうし、自分の信念を曲げてでも「今ここでやっていること（事業とかサービスとか）」に意義がある・価値を置くなら、自分を変えるのだろう。
Qall - Docker で作る Quipper の開発環境
同僚の話だし会社でいくらでも聞けるから聞かなくてもいいかなぁと思ったりもしたけど、 Qall そのものの話以外の部分が良かったので、発表を見に行って正解だった。
RubyKaigi 2017 のときにも感じた記憶があるが、彼の発表は問題意識の視座が高いのがすごいと思う。近年、技術カンファレンスなどで発表されることは、「ある人・組織などにおいて、特定の背景・文脈・ユースケースにおいて云々」という風にスコープが狭められているものが多い（自分の発表からして、もろにそういうものだ）。それはそれで勉強になるし、コンテキストを共有できる範囲に固定しないと見当違いの反論をされたりして困るので予防的になってきたという面も否めないのだが、「Docker を開発環境に使う、ということにまつわる諸問題について皆と議論したい」という彼の問題意識・問いかけは、「届ける人間・コミュニティの範囲」という点でスコープをある意味まったく狭めようとしない。こういうスケールで物事を考えられるのはすごいことだと思う。
たぶん全然関係なくて誰にも理解も共感もされないと思うけど、 Text::Xslate という Perl のテンプレートエンジンライブラリがあって、これは高速さが売りなのだが、「テンプレートエンジンというソフトウェアの特性（文字列操作が多い）を考慮して、文字列操作を高速に処理できるバーチャルマシンを実装するアプローチを採用して高速化した」という作者談があり、これを思い出した。ふつうは「自分・自社のユースケースだとこういう事情で既存のテンプレートエンジンでは速度が問題だったので、高速化した（そのテクニックとして VM 云々）」という話で終わってしまうと思うのだが、これを一段抽象化して「そもそもテンプレートエンジンとは何がどうで」という話ができるというのは、やはり思考の段階として数段高くなければできないことだと思う。
「社内ツール作成サークル」活動記録
「ソフトウェアエンジニアとして、使い方がわからないツールなど無い、常に『こんなこともあろうかと』ってできたい」という話が心に染み入った。他、いろいろ全体的に良かった。ノウハウ的な部分もいろいろためになった。
一日目の昼間は昼前の発表からランチの時間帯まで、スライドを作ったりマチマチ社の藤村さん（元同僚）と近況報告でお喋りしたりしてた。たぶん数年ぶりに再会したけど、いろいろ背景を共有できてる人と話すのは安心感あるなーと思った。
