見出し画像
Photo by autumn_love

Ubieに入って1年半、どんなことをしてきたか振り返ってみる。

田口 信元

Ubie Discoveryに入社してあっと言う間に1年半が経過しました。
過去の自分を振り返りつつ、携わってきた業務を書き起こしてみます。

前提として自分自身と「何でも屋で器用貧乏なタイプ」と思っており、入社前は、Ubie Discoveryってなんだかスペシャリストが多そうだけど自分のバリューを発揮できるだろうか？とか思ってました。
Ubie Discoveryにプロダクト開発エンジニアとして入社したら普段どんな業務をしていくことになるんだろうか？と思っている方の参考になれば幸いです。

よく触った技術

症状検索エンジン「ユビー」

  • フロントエンド：TypeScript + Next.js + Apollo

  • バックエンド：Kotlin + Spring Boot + DGS

普段は症状検索エンジン「ユビー」の開発を主に行っています。
症状検索エンジン「ユビー」はNext.js + BFF(GraphQL) + いくつかの共通基盤サービスで構成されていて、Ubie Discoveryの中でもリリース頻度が非常に高く、複数のチームが関わるプロダクトです。
既存機能の改善や、新機能の開発においては施策の結果が分析可能であることが普段の開発チケットのACの一つになっています。
症状検索エンジン「ユビー」のユーザーは多様で、直感に反するような結果が出ることも多くあります。そのためなるべく先入観を持たずに、変数を極力少なくして小さく検証を進めていくことが重要です。
Ubie Discoveryではこういった開発のガイドラインも社内で整備されています。

DGSを利用したGraphQLサーバーの実装は入社して初めて取り組みました。複数の共通基盤サービスをうまく隠蔽できてるように感じます。
一方で最大限GraphQLの恩恵を受けられるかどうかは良いスキーマ設計によるところも大きいため、ドメイン知識が溜まってきた今振り返ると設計に後悔している部分もあります。
モデリングの負債はだんだんと大きな歪みになっていくので今年は解消に向けたアクションも取っていきたいと考えています。

管理画面

  • Ruby on Rails

プロダクトの管理画面はRuby on Railsで開発していることが多いです。初めはエンジニアだけが利用していたものが次第にユーザーサポートなどエンジニア以外のメンバーに開放されるケースもあり、全社のオペレーション最適化のために非エンジニアでも利用しやすい管理画面にしていく必要があります。

Kubernetes

アプリケーションはGKEで動いていることが多いので、Argo RolloutsやArgo Workflowsなどyamlをたくさん書きました。
Ubieではリリースの設定はmonorepoで管理されています。
前職ではpolyrepoを採用していましたが、サービスごとの微妙な構成の違いやインフラ構成の把握がなかなか難しかったと記憶しています。担当チームがはっきりしている場合はpolyrepoでも問題ないケースも多いと思いますが、Ubieのような同時多発的にサービスを行う組織では統制の観点でmonorepoの見通しがいいなと感じています。

CI/CD

GitHub Actionsをガシガシ触りました。magicpodを導入してネイティブアプリのE2Eテストを整備したり、fastlaneを使った証明書の自動管理、アプリの自動ビルドを整備したりしました。
チームの課題として大きかったのは、リリースに対して頻度が圧倒的に多いテスト用アプリをdeploygateに配信する部分と実機テストの部分だったため、この部分の改善にフォーカスしました。
余裕があればストアへの配信もfastlane管理にしたかったですが、そこはアプリのリリース頻度が上がってきたタイミングでまた取り組んで行こうと思います。

効果計測

リリースした施策の効果計測は主にBigQueryで行います。
OKRを策定した後はまず初手にKey Resultを一覧できるダッシュボードを作成します。ダッシュボードはRedashやLooker Studioを利用することが多いです。
また、定常的に確認したい指標以外に、日々の開発においてショットで行った分析結果を共有するためにBdashというツールを使うこともあります。

普段の開発では、整備されたダッシュボードを見ながらOKRの進捗を確認し、必要なアクションをホラクラシーやスクラムのフレームワークで解消していきます。
意思決定に必要なデータがまだBigQueryにない場合はBigQueryに取り込むためのBigQuery Data Transfer Serviceやtroccoを利用したETLの整備なども行うこともあります。

全社的にデータをもとに意思決定する文化があるので、チームのとるべき戦略の意思決定がしやすいようなダッシュボード作成スキルを社内のプロに師事して今後伸ばしていきたいと考えています。

ガバナンス

OKR達成のためのチームの戦略やチーム構成に問題がありそうな場合はホラクラシーのフレームワークを利用して解消します。
良いガバナンスに関しては社内勉強会の一環でチームトポロジーの読み合わせ会を行いかなり腹落ちしました。
今は普段の開発の中で、コミュニケーションパスを最小化してチームの認知負荷を下げるためにはどうすれば良いかを自然と考えるようになっています。

おまけ：採用活動

エンジニア採用チームの活動として、認知向上の施策を企画することもあります。
人材要件であるユビネスを簡単にチェックできるサイトはその一つであり、そこそこバズって認知度の向上に貢献したのではないかと思います。

以上、自分がUbie Discoveryにおいて、プロダクト開発エンジニアとして普段どんな業務を行っていたかの振り返りでした。Ubie Discoveryを気になっている方の参考になっていたら幸いです。
元々、「何でも屋」で器用貧乏なタイプではあったので、その部分を生かしつつ本当になんでもやれたなと思っています。
今年はさらなるサービスのグロースに向けて、BI関連の能力を向上しつつ、Goのキャッチアップも進めていき、さらなる「何でも屋」を目指していきたいと思っています。

サービスの成長と自身の成長にワクワクする環境です。一緒に働く仲間も募集しています。

#note書き初め


いいなと思ったら応援しよう！