はじめに
ヘルステックスタートアップのUbieに転職してから3ヶ月が経過したので、転職のきっかけや実際に入社して感じたことなどを書き連ねました。いわゆる入社エントリというやつです。
転職の経緯
前職ではDMMでSREをやっていました。特定のサービスに限定した活動ではなく、組織全体に関わるチームに属し、様々な部門に対してクラウドマイグレーションやインフラの改良、SRE文化の普及といった活動をしていました。DMMは50以上の多種多様なサービスを運営しており、新規事業の立ち上げ時にインフラ設計を行ったり、既存のレガシーインフラを改善するなど、多岐にわたる経験ができたことは大変有意義でした。
一方で私が所属していた部署では「このサービスのこの部分を改善してほしい」といったスポットでの関わりが多く、もう少し長い目線でプロダクトや基盤を育てていきたいという気持ちがありました。そんな折に登録していた転職ドラフト経由でUbieから声がかかり、何度かの面接を経て今年の6月に入社することとなりました。
「なぜUbieを選んだのか？」という質問をよく受けます。一番の理由は、「今後数年でN倍の成長が見込まれる、勢いのある企業で働きたかった」からです。成長企業は多くの資本や情報が集まり、環境の変化も早いです。強いエンジニアがUbieに集まってくる様子をTwitterで見てきたことも、この決断に大いに影響しました。そういった環境で挑戦することが、自分自身にとって新鮮で興味深いと感じました。
また、その他の理由としては、ストックオプションを含む報酬体系の魅力や、オフィスを訪れた際の良い雰囲気なども挙げられます。
自分のエンジニアとしてのキャリアはまだ浅い方で、不安も少なからずありました。しかし、「情熱プログラマー」で紹介されていた"Be the worst"（一番下手くそでいよう）という言葉を思い出し、思い切って飛び込んでみることにしました。
やっていること
弊社のプロダクトの1つである症状検索エンジン「ユビー」は月間700万人以上の方に利用されています。サービスの成長に伴いスケーラビリティ、信頼性、開発効率といった点での課題が生じており、私の所属するチームでは基盤開発やSREといった切り口での解決を目指しています。
Platform Engineeringというワードが近年注目されています。
私の直近の仕事ではそこで定義されているような「製品チームによる顧客価値の提供を促進する」といった仕組みづくりに取り組んでいます。例えば、簡単に組織のポリシーやベストプラクティスに沿った方法でのサービス構築を可能とするService Templatingツールの開発や、社内のマイクロサービスのステータスやオーナーシップを可視化し、一元的に提供するInternal Developer Potalの構築などがその一例です。Platform Engineeringという概念はまだ提唱されてから日も浅いため、今後もさまざまなプラクティスやツールが登場すると予想されます。そういったトレンドを追いかけつつ、現在のUbieのプラットフォームにとって最適なHowを考えるのが難しいところであり、楽しいところでもあります。
業務のアサインに関して少し補足しておくと、私の所属するUbie Product Platformはホラクラシーという組織体系を採用しており、明文化されたロールにWill/Can/Mustを考慮しつつ人が紐づくというのを特徴の1つとしています。ほとんどの社員は複数のロールを兼任するため、自分も先ほどのPlatformに関するロールの他に、認証基盤開発やSREといったロールを兼任しています。そちらのロールでは認証基盤とのやりとりに使うSDKの開発や、Ubieのインフラが乗っているKubernetesの運用などを行っています。
実際に入ってみてどうか
カルチャー
カルチャー構築、浸透に対する熱量が高い、というのが入ってすぐ抱いた印象でした。公開されているカルチャーガイドを眺めると分かる通り、ここまでボリュームのあるカルチャーを定義している会社は多くないのではないでしょうか。社内でもこのガイドにある用語（Giant Leap: 通称ジャイリーなど）が普段から多く飛び交い、社内の定例会議などでもよく話題に上がります。
私のような新入社員はこのカルチャーを理解するだけでも結構大変だったりするのですが、それを支えるのが入社後のカルチャーオンボです。そこではカルチャーメンターが付き、共に前職のカルチャーとの差分を埋めるワークを一定期間行います。その中で今までの仕事のやり方とUbieで求められる行動指針との間で乖離があれば、どのようにそれを埋めていくかのアクションが積まれ、日々の業務の中でそれに取り組んでいきます。そのようにして新入社員が短期間で既存のUbie社員と足並みを揃え、同じ方向を向けるような仕組みが整えられています。
評価制度がない
Ubie Product Platformでは報酬に紐づく等級・評価制度を持っていません。
これは結構気に入っているポイントです。評価がないので、ある期間は上司がやたらと忙しくて捕まらないとか、評価されるために色々政治が必要とかもありません。ベテランエンジニアがメンバーの評価といったピープルマネジメントに忙殺されることもないので、プロダクト価値を上げる活動に専念できます（念のために言っておくと、これは一般的な話で前職の話ではありません）。
また基盤よりの仕事をして感じることとして、サービス継続のためにはマイグレーションやバージョンアップといった高く評価されづらいものの重要なことがたくさんある、ということです。評価がないと、余計なことを気にせず事業にとって重要なことに集中できます。
終わりに
色々と良いことを書いてきましたが、技術的・組織的な課題もたくさんあります。絶賛採用中なので興味のある方はぜひお話ししましょう！
