Rubykaigi2023
去年の感想、会社の方のブログに書いちゃって自分のブログに書くの忘れてたんですよね。今年は書きます。
RubyKaigiがかえってきた
かえってきたというとやや語弊があって、2020年も2021年も2022年も、RubyKaigiのオーガナイザーの方々は急激な変化の中で完全オンライン開催や制限付きオンライン開催を継続してくれました。なので正確に言うと、2023年にやっと2019年以前のRubyKaigiに戻ることができただと思います。本当に頭の下がる思いです。
そんなこんなで2023年のRubyKaigiは、2020年に開催を予定していた松本でのリターンマッチが無事成功した感じでした。各種イベントも戻ってきて、特にアフターパーティーは凄かったなぁと思いました。
リアル空間で頭の上にアバターを
あなたは誰、という課題
RubyKaigi2023が、2023年5月11日から13日まで長野県松本市で開催されました。COVID-19が猛威を振るい、2020年のRubyKaigiがキャンセルされてから3年が経ち、ようやく本格的にRubyKaigiが帰ってきたという実感がありました。
三年です。三年ですよ？ そりゃ人の風貌も変わりますよ。なんだかんだ以前は出社というイベントがあり、最低限の歩行運動くらいは勤め人なら毎日していたのが、WFHでまーったく出歩かなくなり、日光に当たることも無く、三年という不摂生な時間はゆっくりと人の外見を変化させていったのです。以前から、オフラインのイベントでは思ってました。「さっき話したあの人、誰だったんだろう……」と。オンラインのアイコンとオフラインの人間のマッピングがうまくいかず、それに加え人の顔を覚えることが苦手な自分は、ただですらRubyKaigiで会う人が誰かわからないことが多くあったんです。それに加えて、もうわかんないんですよ、誰が誰なんだか。
自分を人に認識してもらうためには、不変の何かを見せるしか無い。そう、アイコンです。
これまでの試み、今回の試み
まずは自分のシールのアイコンを作った気がします。誰か（Ruたんだったかな？）がやっているのを見て良いじゃんと思い真似しました。名刺やカンファレンスのパスケースなど、目につくところに貼りまくりました。
次にやったのは、マスクに貼るシールです。これはRubyKaigi2022で、SmartHRのブースアイテムとして自分が企画しました。いつの間にか人の顔面に巨大なキャンバスが標準装備されることになったので、そこにレンダリングしようという奴です。
そして今年は、もうちょっと目線の位置にということで、こういうものを作りました。
SmartHRに転職してもいいなって人は、ぜひ頭にこのアイコンついてる人に声かけてね #rubykaigi pic.twitter.com/Zxqyqp7fQQ
— kinoppyd (@GhostBrain) May 12, 2023
自分のアイコンが印刷されたカチューシャです。頭の上に乗っているので、まるでゲームの中のアバターみたいでナイスじゃないですか？ ないですか。
ナイスかどうかはひとまず置いておき、今年はこのアイコンを頭の上に浮かせるカチューシャで勝負することにしました。作り方を掲載するので、誰でもすぐに真似できます。
ブログを静的ジェネレータに置き換えたので、どこにホスティングするか？
静的サイトのホスティング
ブログをJekyllに移行しました。 これまでのWordpressと違い、配信を勝手にはやってくれないので、何かしらの方法を使ってホスティングと配信する必要があります。
前回にも書きましたが、ブログを静的ジェネレータに移行した理由は、Wordpressを動かしているサーバーの値段がバカらしいこと、サーバーの更新が面倒で放置しがちになるのでセキュリティ的に良くないことがあげられます。なので、ホスティングに何を使うかの選択はJekyll移行の目的を達成できるかどうかにも関わってきます。やっていきましょう。
実際にたどった順路（TL;DR）
ホスティングに求められる機能は二つです。静的ファイルの配信と、これまでのtolarian-academy.netでのアクセスをkinoppyd.devにリダイレクトする機能です。
まずはGitHub Pagesが候補でした。ですが、GitHub Pages のJekyllサポートは、使用できるプラグインの中にpagination-v2が含まれておらず、パーマネントリンクを多用している自分のブログでは使用することができませんでした。
次にS3の静的ホスティング機能を使おうとしました。しかし、SSLに対応していないので、CloudFrontが必要だということもわかりました。今回移行した .dev ドメインは、HSTSという仕組みでブラウザアクセス時に強制的にHTTPSプロトコルにリダイレクトがかかるようになっており、HTTPS対応は必須でした。しかし、CloudFrontに刺す証明書をACMで取ろうとしたところ、Route53以外で取得したドメインではうまく証明書が割り当てられないことがわかり、AWS構成は諦めました。
さらなる候補はGCPで、GCSから静的ホスティングを行いCloud Load Balancingを使ってマネージド証明書を利用する方法でした。この方法はうまくいきましたが、Cloud Load Balancing の転送ルールに時間ごとに0.025ドルがかかり、月あたりまあまあな額の課金が発生します。これまでWordpressを配信していたサーバー維持費よりもさらに倍以上の値段がかかってしまうため、この方法もイマイチでした。
最終的には、GitHub Pages に対して Actions でデプロイができるベータが始まったことを知り、そこに移行しました。割と簡単な設定で、自前でビルドした成果物を置けるので、前述のパーマネントリンクの問題も解決です。
残っている課題は、tolarian-academu.net ドメインからのリダイレクト設定をどうしようかという点です。一旦GCP側に設定を残していますが、これも近日中に何かしらの解決策を見つけないといけないです。
hello jekyll
このエントリは、SmartHR Advent Calendar 2022の1日目です。
Hello Jekyll
ブログをWordpressからJekyllにお引っ越ししました。3年くらい前からWordpressから静的サイトジェネレーターに乗り換えたいなぁと思ってたけど、大分腰が重かったです。めちゃめちゃ重かったです。移行したことを褒めてほしい。すげえ気持ちが大変だった。
いっっっっっちばん腰が重かった理由はMySQLで、ブログを始めた当時の自分はブログ以外にもいろんなプロダクトとDBインスタンスを共有しようと思っていたので、Wordpress用のサーバーとは別にMySQL専用のVPSを借りました。そしてWordpressとMySQLはインターネット経由でつなぐため、SSLで通信していました。ブログにも書きましたね。なんですが、2014年にHeartbleed脆弱性が見つかり、各OSが古いバージョンのOpenSSLを使った通信を拒否するようになりました。なので、2018年とか2019年頃に「Wordpress移行してえなぁ……」と思っても、Wordpress用のDBからJekyll用のファイルに直接エクスポートツールがMySQLとSSL経由で通信できなくなり、いろいろな手を講じてエクスポートするのがとにかくめんどくさくてめんどくさくて……2022年11月まで放置することになりました。まあ結局、Wordpress側にXMLエクスポート機能がついていることに気づき、XMLをJekyllのMarkdownに変換するためのツールもあったので、それを使うことによって今までのSSLに関する努力は全部無駄になりましたが。
Why Jekyll
ブログの移行先は静的サイトジェネレーターを使うことは決めていました。Webアプリケーションとして動いているブログは、アップデートに追従するのが精神的負担すぎると感じたためです。デプロイなどの自動化を行うというのもありますが、その自動化をメンテするコストもバカにならないし、自動化されたシステムを維持するのって金銭的コストもかかるんですよね。お金を生んでくれるシステムならいいんですが、単なるブログに月に数千円払うのはだいぶ経済的な負荷が高いなと感じます。それならば、単純な静的ファイルを生成してくれるジェネレーターの方が良いなというのが理由です。コメント欄がなくなるくらいしかデメリットないですしね。
zoomガチャ
いえーい、どもども、ハッピー……何だっけ？ 12月なんだから何かしらがハッピーな……えーっと、あれよ、その……アレだ、いえーい！ ハッピー！ やったー！
この記事は SmartHR AdventCalendar の1日目です。
アジャイルチームとガチャ
SmartHRの各チームでは、今年はだいぶアジャイルチーム、とりわけクロスファンクショナルチーム化を目指す流れがありました。多分クロスファンクショナルチームをググると、各分野の専門家たちが1つのチームで問題解決に当たる的な話が出てくると思いますが、SmartHRではその特色をさらに進めて「専門家のもとで誰でもなんでもできるようになる」ような結構スパルタな感じの開発チームを作っています。例えば、チームのQA専門家のもとでプロダクトエンジニアは全員QAの自動テストにコミットできるようになったり、UXWと呼ばれるプロダクトの文言を万人に使いやすくするためのライティングチームのもとプロダクト内で使う文言に全員で注意を払ったり、プロダクトデザインチームの監修のもと開発時にデザインの草案とアクセシビリティを意識したデザインプロトタイプ駆動の開発全員で行ったり、結構いろんなことをプロダクトエンジニアをはじめとするチームの全員がやっているような感じです。
当然、チームのスプリントを計画するスクラムイベントを中心としてスプリントレビューやリファインメント、プランニングや日々のデイリースクラムまで、ありとあらゆるミーティングで属人化の排除が進むようになっています。これは、特定の誰かがチームから離脱したとしても、それによってチーム全体の活動に悪影響を及ぼさないようにという理由からで、特にスクラムイベントのファシリテーションにおいては全員がすべての役割をこなせるように、トークスクリプトを用意した上でランダムに割り当てられたチームメンバーが行います。
さて、ここで問題になるのが誰がファシリテーターをやるかです。先ほどお話した「チームから離脱」というのは、有給なんかも該当します。たとえば、スクラムイベントでいつもファシリテーションをやってくれる人が、その日に体調悪くなって休んだりしたらじゃあ延期だねとはならないですよね？ つまり誰でもファシリテーションができなくてはいけないんです。自分がいるチームでは、ファシリテーターのトークスクリプトと、ランダムにファシリテーターを決めるという運用でこの問題に立ち向かっています。でも、どうやってランダムにファシリテーターを決めるんでしょうか？
答えはガチャです。ガチャ。射幸心を煽る悪い文明のアレです。僕も結構嫌いですよ。でもまあ、リスク（例えば課金とか税金とか）さえなければ、わりとガチャは公平で良い文明です。何の理由もなくサイコロ振ってるのとそう大して変わらないですからね。
単に限定的なメンバーの中で回すガチャは、比較的簡単です。なぜなら、その限定的なメンバー全員をSlackのカスタムレスポンスで登録して、特定のキーワードでランダムに選ぶということが可能だからです。しかし、参加者が不特定なケースでのガチャって、どうすれば良いんでしょうか？ 例えば、毎週木曜日に開催されるエンジニア定例だけど、参加自由で誰が来るかわからない、参加の候補者は40人を超えるけど実際に来るのは20人みたいなケースです。事前に登録しておきますか？ 無理ですよね。なんならハズレのほうが多いですし。じゃあ当日にzoomのミーティングに参加している人の中からダンダムに選びたいってなったら、どうすれば良いんでしょうか？
zoomとガチャ
これに関しても答えは簡単です。zoomのAPIを使って、今現在ミーティングに参加している人の一覧を取得し、その一覧を何かしらの方法でランダムにシャッフルすれば良いのです。簡単。
大急ぎでRails+Reactのアプリケーションを作るときにやったこと後編
ある日突然、大慌てでWebアプリを作らなくてはいけなくなった
このエントリは、第二のドワンゴ Advent Calendar 2020の23日目です。
このエントリは、大急ぎでRails+Reactのアプリケーションを作るときにやったこと前編の続きです
このエントリは、自分は仕事でRails+ReactのAPI+SPAプロジェクトをいくつか経験してきたが、0からその環境を作ったことがないということに気づいてしまった私の記録です。多くの躓きを経て、非常に非常にかんたんな機能しか持たないアプリをつくるのにのべ20時間ほどの時間を要しまし、自分はReact+Railsエンジニアになったつもりでいたという反省文、その話の後編です。これから書くことは、0からRails+React環境を用意したことのない人に向けて書く、まさに書くは一時の恥、書かぬは一生の恥のエントリです。
前回までにやったこと
前編では、サンプルアプリ「ねこねこかわいい」を作るために以下の工程を説明しました。
-
rails new
-
DBの用意
-
Webpackerの設定
-
RailsとReactのインテグレーション
-
UI FrameworkとしてSmartHR UIの導入
後編のこのエントリでは
-
axiosのクライアントを用いてReactからRailsに通信
-
Google OAuthでユーザー登録
-
S3に画像の投稿
-
Herokuへのデプロイ
までを解説します。
axiosクライアントの作成
大急ぎでRails+Reactのアプリケーションを作るときにやったこと前編
このエントリは、SmartHR Advent Calender 2020 の1日目です
ある日突然、大慌てでWebアプリを作らなくてはいけなくなった
先日、勤め先のSmartHR社である奇妙な福利厚生制度が爆誕し、盛り上がった。この福利厚生制度に関してはちょっとした理由で詳しく書けないので、ぜひSmartHR社にカジュアル面談という形で話を聞きに来て確かめてほしい。
で、その福利厚生制度は、あるルールで複数の従業員の組み合わせが条件を満たしたときに効力を発するものだった。その組み合わせの条件はそんなに大変ではないが、自分から能動的に制度を利用しようと思う人でなければなかなか面倒というか、とにかく誰もかもが「制度を使うためにマッチングしてくれるアプリほしいな」と思っていた。私もそう思った。だから、普段仕事で使っているRailsとReactでサクーっと一晩で社内マッチングアプリを作り、社内でのｽｰﾊﾟｰﾊｶｰの名声をほしいままにしようとした私は、早速 rails new した。
そして気づいた。確かに自分は仕事でRails+ReactのAPI+SPAプロジェクトをいくつか経験してきたが、0からその環境を作ったことがないということに。薄々気づいていたが、もしかして自分は用意された環境でしか仕事が出来ないのではないか。いやそんなことはない。そういう気持ちを打破するためにも、なかば強迫観念に突き動かされるようにマッチングアプリの作成に取り掛かった。結果として、多くの躓きを経て、非常に非常にかんたんな機能しか持たないアプリは4日後に完成し、なんとのべ20時間ほどの時間を要した。
最終的にアプリは完成したが、この簡単なアプリを作るために20時間を要したという事実は、私の心臓を強く締め付けた。普段社内で「いやー僕RubyとかRailsとかReactとかできまっす」みたいな顔してる自分が急に恥ずかしくなってきた。頬に含羞の色が浮かび、空恥ずかしさに心がざわめき、穴があれば入りたい、生き恥をさらすとはまさにこのことである。しかしだからこそ、これから書くことは同じく0からRails+React環境を用意したことのない人に向けて書く、まさに書くは一時の恥、書かぬは一生の恥のエントリである。
ねこねこかわいい
突然だが、最近猫を飼い始めた。いろいろあって猫を飼うのが夢だったが、それが叶った形だ。猫は可愛い。本当に可愛い。だから、うちの猫を自慢したくなる。ということで今回は、社内の福利厚生マッチングアプリで得た知見をもとにうちの猫を自慢するためのアプリケーションをRails+React構成で作ってみようと思う。なお、最速で完成させつつアプリを大きく成長させるための土台もしっかり作ることを目指すので、まずはSPAとかのしゃらくさい方法はとらず、Webpackerを使いRailsからReactのコンポーネントをレンダリングするし、RailsはAPIモードとかにはしない。しかし、すぐにでもWebpackerを抜け出し、Webpackでフロントを完全に管理し、RailsはAPIとして機能できるようにする準備もやる。だから、きっちりした構成を最短で作るための、自分がやった最速の構成ということになる。そのため、それなりの分量があるので、前編と後編で分けることにした。
このアプリ「ねこねこかわいい」が目指すのは
-
RailsでバックエンドのAPI作成とWebpackerで作成されたアセットの配信
-
React+TypeScriptでフロントの作成
-
axiosを使用してReactからRailsに通信
-
Google OAuthでユーザー認識
-
S3に画像の投稿
-
Herokuへのデプロイ
の5つの項目となる。S3はActiveStorageを使うのでGCSでもいいし、Herokuも大して変わらんのでBeanstalkやAppEnginでもいい。BeanstalkはEC2のことを考えるのがめんどくさく、AppEngineは無料でFlex環境が使えないからHerokuを使うだけだが、とりあえずこの構成で始める。
また、このエントリの流れをコミットしたリポジトリも用意した。
https://github.com/kinoppyd/nekonekokawaii
各見出しの中では、実際に手順をコミットしたパーマネントリンクも提示する。
rails new
APIがカオスってたプロダクトでOpenAPI対応やってみた
このエントリは、 SmartHR Advent Calendar 2019 1日目の記事です
こんにちは、SmartHRでエンジニアやっているppydです。いま会社では、SmartHRに蓄積されたデータを可視化して分析する簡易BIツールを開発するチームに居て、フロントエンドとバックエンドとインフラのエンジニアをやっています。それくらい人手が足りてません、みんなSmartHRにきてください。助けて。
カオスったAPI
いまのプロダクトには途中参加なので、先人たちの名誉のために言っておきますが、そもそものAPIの設計がカオスっていたというわけではありません。グラフを描写するフロントライブラリのAPIの都合や、検索フィルタの条件が複雑すぎるために、エンティティの一部がカオスっていたというのが正しい表現です。とはいえ、それのおかげでAPIのレスポンスの全容がつかみにくく、またきちんとした型定義が無かったために、せっかくフロントはTypeScriptを使っているにも関わらず型の恩恵を受けられない箇所があったことは残念でした。他にも、現在のバックエンドはRailsを使っているのですが、ActiveRecordを使った実直な実装が果たしてこの先BIツールの要求に対して耐えられるのであろうかということも検討する段階にあり、もしバックのアーキテクチャを変えたときにフロントと不整合を起こさないためにも、APIの厳密な仕様を確定させることが必要だと感じていました。
そのため、フロント側のAPIクライアントを型付きで自動生成したい、そしてバックエンドの変更でフロントを破壊したくない、という2つのモチベーションで、プロダクトにOpenAPIを入れることにしました。
OpenAPI
すでに有名なので軽く触れるくらいにしておきますが、OpenAPIはRESTのWebAPIにおける仕様の記述方法です。もともとSwaggerという名でしたが、後にOpenAPIという名前に変更になり、現在はバージョン3が公開されています。RESTのAPIのかなり厳密な仕様を、YAMLもしくはJSONで記述します。
RubyとOpenAPI
Ruby製のプロダクトで（別にRubyに限った話ではなく、ほとんどの言語でこうだと思いますが）OpenAPIに対するアプローチは2つの方法があります。
1つは、何かしらの方法でOpenAPIの仕様に則った定義ファイルを書き、その定義をcommitteeなどのGemで常にチェックする方法です。これはOpenAPIの定義そのものに則りAPIサーバーを作成する、いわばTDD的な手法です。この方法の優れた点は、正しいテストがあればOpenAPIの定義を守ることを実装に強制することができることです。もちろん、APIを作成してからOpenAPIの定義を書くことも多々あると思いますし、これからお話する内容もそうなので、完全にTDD的とは言えません。が、方法としてはまず定義があり、実装を合わせていく、ということに変わりはありません。
もう1つは、swagger-grapeなどを使い、実際のAPIの実装仕様そのものからOpenAPIの定義を作り出す方法です。この方法の優れた点は、OpenAPIの定義が絶対にAPIサーバーの実装と乖離しないことです。そのため、APIサーバーから自動で生成されるOpenAPIの定義から、更に自動で生成される各言語用のAPIクライアントは、常に間違いなく最新のAPIサーバーの仕様を満たしていると保証されている点です。
この2つの方法には、それぞれ利点と欠点があり、そしてほぼお互いに真逆の特性を持っていると言えます。前者のメリットは、APIの定義は決してズレないということであり、後者のデメリットはAPIサーバーの実装によって定義はすぐに変わるということです。そして後者のメリットは、極力少ないコードで型情報付きのAPIのクライアントを自動生成できることで、前者のデメリットはAPIの定義の作成や変更に大きなコストがかかることです。
技術書典7で、「ActiveRecord完全に理解した」という本を出します。
免責事項
本書のタイトルにある「完全に理解した」とは、ActiveRecordを完全に理解することではなく、あくまで社会通念上相当のActiveRecord「完全に理解した」であり、本書はActiveRecordを完全に理解することを何ら保証するものではありません。
技術書典7
ドワンゴを退職してSmartHRで働き始めそろそろ一ヶ月のkinoppydです。技術書典に出ます。場所は「◎貴サークル「トレイリア学園」は、 か01C に配置されました。」です。ブックマークはここからどうぞ。今回は、ActiveRecordのソースコードリーディングの本を出そうと思います。500円です。前回はメタプログラミングRubyの解説本でしたが、それを書いている過程で「そろそろActiveRecordのソースとか、俺でも読めたりするんじゃないかな……」という気持ちになったので書いてみました。
そんな思いつきから、ひたすらActiveRecordのソースを読んでみた結果を、簡単にまとめて本にしてみました。
内容としては、ActiveRecordで最もよく使われている（であろう）機能のestablish_connection, find, where あたりのメソッドがどうやって動いているのかを、実際にソースコードを追いながら見ていく本です。実は7月の頭あたりからこの本の構想を考え、がんばってActiveRecordのソースコードめっちゃくちゃ読んだんですが、いかんせん相手は巨大すぎて、全てを読むことはできませんでした。そのため、一応自信を持って解説できるであろう範囲に狭めて深堀りしていく内容の本となっています。
そのため、AssociationやMigrationやSTIの内容などは全く出てきません。というより、それらのソースコードをまだ読めていないので、多分次の技術書典では「ActiveRecordなにもわからない」という本を出すと思います。
この本を読むためには
この本を読むためには、メタプログラミングRubyを通して読んだことがある程度の知識が必要である前提になっています。
株式会社ドワンゴを退職します（5年2ヶ月ぶり1回目）
2019年8月末で、株式会社ドワンゴを退職します。これは主に社内の友人に向けた文章ですが、一応自己紹介は書いておきます。
誰
私はkinoppydという名前で、2014年にドワンゴへ入社し、Scala/Rubyエンジニアをやっていました。最初に配属されたプロジェクトはニコニコ生放送のScala化プロジェクトで、ニコ生のScala化、ニコ生のHTML5化のお手伝い、公式生放送の老朽化した機能のマイクロサービス化などを行いました。その後はチームを異動し、ニコナレのバックエンド開発に従事しました。
他にも、社内でSlack芸人やBot芸人をやっており、なんか記事にされたりしたこともありました。
【bot、暴走中！】「Slackは福利厚生」と言い切る、ドワンゴ流・Slackの超活用術とは
絵文字コミュニケーション術、サーバーワークスとドワンゴが明かす
趣味はRubyのコードを書くことで、OSS活動としてSinatraライクな書き味のBotフレームワーク Mobb の開発などをやっていたり、技術書典でSinatraのコードリーディング本やメタプログラミングRubyの副読本などを書いていたりしました。次の技術書典では「ActiveRecord完全に理解した」という本を出します。
退職の理由
大まかに言うと、ライフスタイルが変わったためです。具体的に言うと、結婚をしました。
人生にはお金が必要です。ドワンゴからもらっていた給与は、私一人で生きていく分には十分なものでした。しかし、私自身の人生と将来生まれてくる子供の人生の2つを支えるには不十分でした。また、昇給のペースなどを考えても今後私が求める水準に達するにはかなりの努力と時間がかかると思い、転職して給与を上げる決断をしました。
私はとても夜型の人間です。そしてドワンゴには、真の裁量労働が存在しています。成果を出しチームの中で合意があれば、何時に出社しても何時に帰っても何も問題はなく、なんなら一日8時間働く必要すらありませんでした。私は在籍中、月に160時間働いてない月がそこそこあるくらいです。そのため、私は概ね昼の12時から14時の間に出社し、夜の20時から0時の間に帰る、という生活を続けていました。しかし、妻は9時に家を出て20時に帰ってくるという生活を送っており、夫婦間で生活時間の不一致が問題となりました。私は真の裁量労働の権利を持っているので、その時間に合わせて生活すればいいとは思いましたが、努力しても夜型の生活を改善できませんでした。そのため、定時が存在する会社に勤め強制的に妻と同じ時間を生きることを決めました。
また、ドワンゴは2019年2月の経営陣交代以降、事業の集中と選択を進めており、私の所属するチームが持っていたニコナレもクローズの運命からは逃れられませんでした。ニコナレの使っている仕組みの一部をScala化するなどをしていたため、この仕事を離れるとなるとそれなりの引き継ぎが必要でした。しかしサービスのクローズにより、私の持ち物は何もなくなってしまいました。結果としてとても身軽になったことも決断の大きな後押しになりました。
他にもいろいろな理由はありますが、まあこの3つに比べると些細なものです。
思い出
会社では、とても友人に恵まれました。まさか社会人になってからこんなにたくさん友達ができると思っていなかったので、驚きと感動があります。ドワンゴに入ってからの新しい友人に影響された結果様々な趣味に目覚め、今までの人生の中で考えられないほど自分の変化があった5年間でした。ポーカーやロードバイク、創作活動を始めたのもそうですし、そもそも今のメイン言語であるRubyを書き始めたのもドワンゴに入ってからです。ドワンゴは、非常に多種多様な人たちが在籍しており、積極的に関わっていくとプラスだったりマイナスだったりの影響をガンガン受けていきます。
仕事で関わる人達にも恵まれ、多くは良き友人で尊敬できる仲間でした。特に、生放送チームで一緒に働いた先輩と後輩、そしてニコナレチームの上長とチームメイトは、一緒に働けたことが光栄に思えるほどでした。私は本当に幸運で、働いている間に人間関係で困ったことにほぼ出くわすことがありませんでした。後述する理由でドワンゴには大変気難しい人も多い中で、このことは本当に運が良かったとしか言いようがありません。
ドワンゴは、自分の中の感覚で一言で表せば、良くも悪くも十数年前のインターネット・アトモスフィアをだいたい東銀座に再現した会社です。人々はネットでコミュニケーションをとり、その雰囲気は独特で、世間にさらけ出すと微妙な顔をされそうな世界観と価値観がありました。社内コミュニケーションツールのSlackにはその影響が特に色濃く出ており、私にとっては心地よかったけどこの空気に馴染めない人は本当に馴染めないだろうなぁという感じです。他人の認識はアイコンとハンドルで、実際に顔を合わせてもその人の名前すらわからないことも多々あります。Slackで雑談するのが大好きで、古のインターネットのコンテキストをずっと積み重ね続けたような会話が繰り返され、さながら歩くインターネット老人会のようでした。00年代や10年代にネットで流行った出来事をみんな知っているのが半ば当然のような、生まれたときからネットしてたんじゃないかみたいな人たちがたくさん住み着いていました。繰り返しますが、自分はそんな雰囲気が大好きでした。しかしその弊害として、やはりネットの中で繋がることが好きな人が多く、実際の対人関係では頻繁に衝突を起こす人も多かったです（ネットの上で衝突している人もいましたが）。これが私がドワンゴに気難しい人が多いと思う理由で、人と話すときにはその人のコンテキストをきちんと把握する努力が必要だと感じるところです。
挨拶
ドワンゴのインターネッツを去ることは、とても寂しいことです。すっかり自分の中に染み付いてしまった感覚を忘れることは、恐らく一生無理でしょう。同僚としても友人としても仲良く接してくれた人達にはいくら感謝を伝えても足りません。また、何度も退職の決意を鈍らせるくらい、一緒に働き続けたいと思えた上長にも、会えて本当に良かったです。いま、ドワンゴが大変な時期に離れてしまうことをとても心苦しく思いますが、ニコニコという文化をこれからも守り続けてくれると、一人のユーザーとしてこれほど嬉しいことはありません。
これから
9月からは、SmartHRという会社でRubyエンジニアをやっていく予定です。今後もよろしくお願いします。