Ubie Discoveryに入社したら、見てる景色が全く違った話
こんにちは。Ubie DiscoveryのSWEのissei（_igreenwood）です。ユビーAI受診相談の開発をしています。
入社エントリから気づけば半年以上が過ぎ、入社時と比べて自分の価値観や意識が変わってきたと感じるので、Ubie Discoveryで働いてみて特に印象的だった点について書きます。
全てのメンバーが圧倒的に自走する組織
入社してまず驚いたのは、開発チームの事業への解像度の高さです。
Ubie DiscoveryではOKRとスクラム開発を導入しており、四半期ごとに１つの全社OKRと複数のチームOKRをたて、メンバーの考え方をアラインしています。
Ubie Discoveryの全ての開発者はそれらのOKRの内容について理解し、それを達成するために必要なPBI（スクラム開発におけるプロダクトバックログアイテム）を作り、それを基に開発を進めていきます。開発が終われば、プロダクトから収集したデータを確認し、OKR達成につなげるための次のPBIを考えます。途中で状況が変わった場合には、基になるOKRを作り直すこともあります。
OKRとスクラム開発の詳細は下記のリンクをご覧ください。
事業判断をするビジネスサイドからの依頼でエンジニアサイドが開発をする組織では、ビジネスサイドの判断のタイミングとエンジニアサイドの開発のスケジュールの間にどうしてもラグが生じます。
しかし、Ubie Discoveryでは開発者がOKRを介して事業戦略を正確に理解した上で、事業へのインパクトが大きい順に開発を進めていくので、何か想定外の出来事が起きても、即座にOKRやPBIの優先順位が変更され、新しいOKRに追従した開発が走り始めます。
全てのエンジニアが事業のことを常に解像度高く理解していることがもたらすメリットは絶大で、このあとの項目でも触れますが、これがUbie Discoveryの成長スピードを支えているといっても過言ではないと思っています。
事業に関する知識をインプットするためのエンジニアの負荷はもちろん増えますが、全てのメンバーがOKRを基にやるべきことの優先順位について議論するので、今までの会社でよく感じていた、自分の開発タスクが何のためのものなのかわからずにモヤモヤすることが無くなりました。なにより、自分が積んだPBIによって事業の数値が伸びるのは非常に楽しく、スタートアップでエンジニアをやる醍醐味なのかなと思っています。
何のためのコードか
入社前までは、自分にとってコードとは、ユーザーへの価値提供のための手段でしかありませんでした。ユーザーに価値を届けるために、先進的なUI/UXが大切で、より良い体験のためにマテリアルデザインガイドラインを読んだり、常にできる限り良いUI/UXを作らないといけないと考えていました。機能を開発する際には、「現時点でどこまでユーザーに気持ちのいいUI/UXを提供できるか」を考えていましたが、Ubie Discoveryのエンジニアはむしろ逆です。
「どこまでユーザーに我慢してもらえるのか、今最低限必要な体験は何か」を考えているように思います。少し過激な表現に聞こえますが、プロダクトのそれぞれの段階で、Mustな体験とNice to haveな体験がそれぞれ何かを考え、既にMustな体験が提供できていると判断すれば、その段階では必要以上に追求しません。
僕は当初、他の企業でトップを走っていたようなエンジニアやデザイナがプロダクトのUI/UXを磨き込みや、UIがマテリアルデザインガイドラインに沿っているかといった議論をあまりしないのが不思議でしたが、1ヶ月もすると、それがスタートアップとしてユーザーに価値を提供するための合理的な姿勢であることを理解しました。
スタートアップでは、限られたリソースと時間の中で最短でユーザーに価値を提供していく必要があります。事業を前に進めるためには、まずはユーザーが持つ課題を検証し、その後に課題を解決するための最善の手段について検証しなければなりません。フェーズによっては、既存の機能のUI/UXを磨き込むためのコードを書くよりも、新しい機能がユーザーの課題を解決するのか確かめるために、簡素なUIの（だが機能としては十分である）コードを書くことの方が優先度が高いこともあります。
Ubie Discoveryの開発チームのメンバーは、プロダクトが今実現したいことを考えた時に一番ROI(Return on Investiment)のよい仕様は何か、今何をどの順番で作り込むべきか、を常に悩んでいます。その上で、それを最速で実現できるコードを書きます。
個人的には、何を実現するために書いているコードなのかが明確になると、実装方法の意思決定もしやすくなり、そのPRで何をどこまで実装するべきかの議論もしやすいので非常に良いなと感じています。入社当初は「これはユーザーの体験を毀損しているな...」と心が痛むことも多かったですが、最近は「適切な順番で機能を作り込むことで、プロダクト全体でより多くの価値を届けたい」という気持ちで開発しています。
コードとの向き合い方
コードの書き方や設計などについても、Ubie Discoveryでのそれは、自分が今まで持っていたものと大きく異なっていました。
入社前までは、極端に言うと「リーダブルコードを読んで、拡張がしやすく、テストがしやすい設計をする」ということしか考えていませんでした。
Ubie Discoveryでは、今のフェーズで必要なものを決めて、それ以外はあまり深追いしません。もちろんコードの質を担保しないということではなく、まずは中長期で使いそうなコードと短期でしか使わないコードを現時点での事業進捗から予め想定し、短期でしか使わないコードを後から捨てやすいように設計していきます。
今のフェーズで質を追求しない部分については、あらかじめ負債として認識しておき、意図しない技術負債や仕様の抜けなどに関してはできるだけ防ぐように考えられています。
事業のフェーズが進み、技術負債が蓄積した場合は、技術負債が事業に与えるインパクトを試算した上で、インパクトが大きい場合は短期間でリファクタしてしまいます。
ユビーAI受診相談では、Nuxt.jsで実装されていたコードベースが１ヶ月程度で、全てNext.jsに置き換わりました。
技術負債を積む、返却する、という判断を瞬間的に行なってしまえるのは、事業への深い理解を前提としているUbie Discoveryならではの文化なのかなと思います。
もちろん諸般の事情でそれができないケースもあり、そういった負債をどうやって返していくかという課題もあり、現在いろんなエンジニアが悩みながら取り組んでいる所です。
さいごに
とりとめのない文章になってしまいましたが、Ubie Discoveryでは一緒に事業を前に進めてくれる仲間を募集中です。この文章を読んで、Ubie Discoveryに少しでも興味を持っていただいた方は、TwitterのDMなどからご連絡ください。カジュアル面談を設定させていただきます。
この記事が気に入ったらサポートをしてみませんか？