Ubie創業期にKotlinを導入した私が、社の技術選定の転換について思うこと
Kotlinエバンジェリストとして、ガッカリしょんぼり…！？
Ubieが、KotlinをやめてGoとNode.jsへの転換を決定したことについて、私がこれをどう受け止めたのか…
こんにちは。私はたろうと言います。
Ubie株式会社 Ubie Discoveryに勤めるソフトウェアエンジニアです。
業務外では、Kotlinエバンジェリストとして講演や執筆を行なったり、技術カンファレンス「Kotlin Fest」の運営代表を務めたりしています。
先日「Ubie は Go と Node.js の会社になります」という記事が、同じくUbie Discoveryのyukuというソフトウェアエンジニアにより発信されました。
新しいアプリケーションを立ち上げる際には、その役割に応じてGoで書くかNode.jsで書くかの2択となり、今後はKotlinを使わない。記事の内容を噛み砕くと、そんな感じです。
私がKotlinエバンジェリストであること、UbieはサーバーサイドKotlinを推していたこと。これらをご存知の方にとって、この記事は衝撃的に映ったのではないでしょうか。
本記事では、私がどのように考えているのかを、背景から詳しくお話しします。
Ubie創業期にサーバーサイドKotlinを導入し、技術と採用を牽引した
私がKotlinという素晴らしいプログラミング言語に出会ったのは、その正式リリースの4年前である2012年。それから今までずっと、Kotlinの虜です。
2018年に、現職 Ubie株式会社へ入社しました。6人目のメンバー、ソフトウェアエンジニアとしては2人目です。当時、プロダクトに大きな機能を追加するプロジェクトがあり、それを契機として、KotlinによるREST APIを立ち上げました。
なぜKotlinなのか？
私が好きだから。得意だから。実際、開発のスピードは出ました。
当時のプロダクトは、ユーザの課題をどう解くべきかというフェーズにあり、開発スピードはとても重要でした。そういう意味では妥当な選択だったと言えるでしょう。
それから、エンジニア採用に刺さるのでは、という仮説もありました。
当時、サーバーサイドKotlinを導入している会社は（特にスタートアップは）珍しかったこともあり、スキルの高い、尖ったエンジニアの興味を引けるかもしれないと思っていました。
思惑通り、shirajiさんやyagiさんのような、Kotlinに造詣が深いスペシャリストがUbieに入社してくれました。
思慮が浅く、半ば勢いでKotlinを導入したとはいえ、当時もたらした効果としては十分でした。
それから4年後、組織とプロダクトのフェーズが変わり、GoとNode.jsへと舵を切った
2022年、Ubieは200人規模の会社へと成長しました。
プロダクトはユーザに広く受けれられ、toCプロダクトである症状検索エンジン「ユビー」は月間利用者数が700万人を超えるまでに成長しました。
組織とプロダクトのフェーズが変わり、それに伴い技術選定に関して、いくつかの課題が顕在化してきました。
具体的な内容は、先述したyukuのブログ記事を参照してみてください。
そういった課題を受け、技術戦略を策定するロールを持ったメンバーが主導して、Ubieにおける技術選定を再検討するプロジェクトが動き出しました。
私が勢いでKotlinを導入したときとは違い、ロジカルで、透明で、再現性のあるプロセスで、全員の納得を得ながらプロジェクトは進行しました。
結果、これからのUbieは、バックエンド開発においてはGoとNode.jsを使うという決定に至りました。すなわち、Kotlinを使ったバックエンド開発は行わないということです。
正直、ちょっぴり寂しいけど、それだけ。興味があるのはユーザへの価値提供
今すぐにKotlinで記述されたコードがなくなるというわけではありません。
が、少しずつその比率は減っていく、ということです。
これは、Kotlinプログラマーである私が、Ubieで自身のバリューを発揮できなくなり、退屈な日々を送って、周囲からの評価が落ちる。そういうことを意味するのでしょうか？
確かにKotlinを導入した張本人は私であり、それがなくなるのは正直寂しいです。仕事でKotlinに触れる機会が減ることも、私にとっては明確にネガティブな変化です。
でも大丈夫！！
むしろ、今回の技術選定の転換について、私は賛成です。
そもそもの課題は以前から認識していたし、意思決定プロセスに納得感がありました。
なにより、私がUbieでやりたいことは、Kotlinを書くことではなく、事業を推進すること、ユーザへ価値を届けることです。どのような技術を使うかは、事業を、ミッションを達成することの手段に過ぎないのです。であれば、最適な手段を選択するだけです。
本質的なことしか見ていたくない
よく言われることですが、目的と手段を履き違えてはいけないと自分に言い聞かせています。センターピンを捉え、ブレずに突き進む。枝葉のなんやかんやは劣後します（が、本質を逸れた細かい議論がまた楽しいことも認めます）。
Ubie Discoveryには、カルチャーガイドがあります。
その中で記述されている行動指針を、2つ取り上げると
課題を見つけ、その解決策をゼロベースで検討し、実行する
本質を捉え、大きいリスク・検討可能な論点のみに集中する
というものがあります。
（他社ですが）Amazonのリーダーシップ・プリンシプルが好きで、ふとしたときに読み返すのですが、その中の「Have Backbone; Disagree and Commit」という項目を引用します。
Have Backbone; Disagree and Commit
リーダーは同意できない場合には、敬意をもって異議を唱えなければなりません。たとえそうすることが面倒で労力を要することであっても、例外はありません。リーダーは、信念を持ち、容易にあきらめません。安易に妥協して馴れ合うことはしません。しかし、いざ決定がなされたら、全面的にコミットして取り組みます。
私がここで主張したいことはこうです。
重要なのは、組織やチームの共通ゴールを達成すること。
そのための方針、登り方、施策、技術の考え方に、メンバー間で相違があれば（大抵ある）バチバチに議論すること。
自分の意見が通らなくとも、ゴールは同じなので、納得できる結論に行き着くことがほとんどです。仮に納得できない場合は、その懸念や違和感はどの程度重要なのか（エッジケースのために多大なコストを払おうとしていないか）、情報を自ら取りに行ったか、自分の持つ情報を出し切ったかを振り返ると、反論の妥当性が確認できます。
心配無用！私はプログラマー！
いろいろ言いましたが、実際のところどうなの？
組織全体としてGoやNode.jsを選択したことに納得感があったとて、Kotlin愛好者である私の活動に、負の影響はあるのでしょうか。
特になし。そう思います。
GoやNode.js、書きます。書けます。というか既に書いてる。
Kotlinエバンジェリストだから他の言語は得意でない、ということはまるでありません。弘法は筆を選ばないのです。
Kotlinのキャッチアップや、講演・執筆などの活動、社外アドバイザーも継続していきます。もちろん、Kotlin Festも。
私がプログラマーであることに変わりはありません。
プログラミングのアート的な楽しさも、ソフトウェアで誰かの課題を解決することも、どっちも好きです。
まとめ（記事要約）
現在の組織と事業の状況を鑑み、Ubieの技術スタックからKotlinを外す決定をしました。 創業期のUbieにKotlinを導入した張本人である私としては、少し寂しい気持ちがあることは確かです。
しかし、不満はなく、 むしろやる気に満ちています。 私の興味は、プロダクトでいかにユーザへ価値を届けるかということです。 状況に合わせて最適な手段を選択することが重要であり、今回の決定はまさに最適と言えるものです。 また、どのような言語を選択しようとも、自分なら使いこなせるという自負があります。
Kotlinエバンジェリストとしての活動も継続するつもりです。
We're Hiring!!
Ubie Discoveryでは、あらゆる職種を積極採用中です！
「テクノロジーで人々を適切な医療に案内」すべく、一緒に新しい医療体験を創りませんか？
この記事が気に入ったらサポートをしてみませんか？