2023年3月30日に開催されたCTOmeetupのテーマは、技術選定です。Go、Rust、Kotlin、Python……モダンと呼ばれる技術は数あれど、自社のビジネスにとって最適なのかどうかは見極めが必要です。

そこで今回はUbie社とスナックミー社から3名の技術者にご登壇いただき、各社の技術選定の検討ポイントや、両社が目指す今後の技術的挑戦などについて語っていただいています。

イベント概要

• スタートアップ企業や大手企業の新規事業部署が0→1でプロダクトを立ち上げる際
• 数年運用してきたプロダクトの成長を更に加速させるためリプレイス/リファクタリングを検討する際

技術選定は要所で必要となりますが、言語選択1つをとっても、「エンジニア採用が優位に働く技術なのか」、「メンバーが負担なく開発に臨めるのか」など考える要素が多く、一概に正解がないところが難しい点ではないでしょうか？

そこで今回はUbie社からソフトウェアエンジニアの長澤さん・小谷さん、スナックミー社からco-founder＆CTOの三好さんをお招きし、自社の状況にあわせた最適な技術選定とは何かについてセッションしていただきます。

Ubie社はサービス立ち上げをサーバーサイドKotlinで行ったのち、昨年GoとNode.jsにシフトしていく方針を打ち出し。
スナックミー社についてはPHPでサービスを立ち上げたのち、現在はPythonを活用しての開発に移行。

当日はサービス立ち上げ時とリファクタリング/リプレイスにおける新技術採用、各シーンにおける技術意思決定の背景を伺うとともに、3者が意識している技術選定のポイントを語っていただきます。

登壇者

長澤 太郎さん｜Ubie株式会社 Ubie Discovery ソフトウェアエンジニア @ngsw_taro

自称Kotlinエバンジェリストで講演や執筆を通じてKotlinの啓蒙活動に尽力。

小谷 優空さん｜Ubie株式会社 Ubie Discovery ソフトウェアエンジニア @yukukotani

2019年からインターンとしてUbieに関わり、2020年に入社。症状検索エンジン「ユビー」のリリース初期より企画・開発を担当。

現在は全社横断の技術選定や標準化、設計を主導しつつ、基盤サービスの開発を行っている。

また、筑波大学情報科学類で勉強もしている。

三好 隼人さん｜株式会社スナックミー co-founder & CTO @miyoshihayato

大学卒業後建築設計事務所へ勤務。その後、ソフトウェアエンジニアへキャリアチェンジし、2014年にgeechs株式会社へ入社。技術本部のリーダーとしてモバイルアプリのプロジェクトマネージャーを経験。

2015年、株式会社スナックミーを創業以後、CTOとしてエンジニアリングチームを率いている。

Ubie、スナックミーの事例から見る技術選定の背景

Ubieのこれまでとこれから：立ち上げ期～拡大期

長澤氏：
それではまずUbie、スナックミーの2社がどのような観点で技術を転換してきたのかを重点的に聞いていきたいと思います。

小谷氏：
Ubieは創業当初からサーバーサイドKotlinを使っていましたが、最近GoとNode.jsに寄せていく決断をしました。

Kotlinの採用モチベーションは3つです。まず、初期メンバーの長澤さんが得意とする言語を使い、とにかく最速でのサービスの立ち上げや検証を重視したかったのが一点。コミュニティの盛り上がりに対する期待もありましたね。それからエンジニア採用におけるポジショニングです。当時のUbieは無名だったので、認知拡大の観点でKotlinを採用しました。

小谷氏：
メリットは、Javaから派生した言語でキャッチアップがしやすかったことや、コミュニティの後ろ盾があったことなどです。また、当時はサーバーサイドKotlinを使っている会社が少なく尖った技術だったので、急速な認知拡大ができました。私も「Kotlinの会社」というきっかけでUbieを知り、入社しています。

長澤氏：
言語としてのメリットもあります。Kotlinはかゆいところに手が届く便利な機能が搭載されていて、例えば拡張関数なんかも、これまでエンジニアが渇望していた機能だと思っています。

小谷氏：
Kotlinの快適さは、一方でつらみにもなっていました。表現力が高い分コードの属人性が高く、品質や生産性の維持にコストがかかっていましたね。

Kotlinを書ける人はAndroidエンジニア出身の方が多くサービス開発はできる一方、JVMの運用は未経験で、開発・運用のメンバーに乖離が起きてしまったのも落とし穴だったと思います。

また、Kotlinの市場は大きいわけではないので、採用が頭打ちにもなってしまいました。

Ubieのこれまでとこれから：安定期

長澤氏：
これからについてはどうですか？

小谷氏：
最近はビジネスがスケールし、安定的な運用の重要性が増しています。組織も一緒にスケールしてきて、一人あたりの開発生産性のインパクトも高まっています。

小谷氏：
ここに対してGoとNode.jsを採用するメリットは、第一に運用コスト・難易度の削減です。Goは新しい言語なので運用のチューニングがビルトインされていて、自分たちで頑張らなくてもある程度いい感じにパフォームしてくれます。Node.jsに関してはフロントエンドでSSRを採用している関係で、どちらにせよNode.jsのサーバーを運用する必要がありました。そこに合わせることで総合的に管理のランタイムが削減し、コストが下がっています。

また、GoもNode.jsもGraphQLとgRPCのエコシステムが発展していて、通信プロトコルとの親和性があります。フロントエンドからバックエンドまで、一気通貫でコード生成ベースの開発体験を作っていけますね。さらにGoとNode.jsは静的解析ツールのlintのエコシステムも発達していて、コードの属人化を低減し、イネーブリングを自動化できるのが大きなメリットです。

つらみとなっているのは、エコシステムの進化が速く、追従に一定のコストがかかる点です。言語自体にキャッチーさがないので、技術的なチャレンジについてしっかり広報もしていかなければなりません。Kotlinに比べると、コードでドメインを表現しにくい部分もあります。

長澤氏：
今、実際に取り組んでいる部分はあるんですか？

小谷氏：
特にGraphQLとgRPCの部分はがっつり進めています。gRPCに関してはコード生成のプラグインを自分たちでOSSとして公開するなど、エコシステムを引っ張る動きもしていますね。

スナックミーのこれまでとこれから：立ち上げ期～PMF期

長澤氏：
では次に、スナックミーさんの事例をお願いします。

三好氏：
当社については、これまで選定していたPHPとPHP＋Ruby、そして現在採用しているPython＋Rubyについてお話しします。

フェーズ1の立ち上げ期においてはPHPが中心でした。創業時はスナックミーだけではなくさまざまな事業をピボットしていたので、作りやすさ最優先で使い慣れた言語を選んだ形です。

三好氏：
その結果、構想から2週間でスナックミーをローンチできたのはメリットでしたが、マイナーなフレームワークなので、触りにくいつらみがあります。

CVの構成がControllerとViewのみで、コードがまとまりにくいのもつらみです。フレームワーク特有の現象だったのか、コンスタントにCPUが暴れだすこともあり、日々ヒヤヒヤしていました。

長澤氏：
そして次のフェーズですね。

三好氏：
PMFをする段階で開発の幅をもう少し広げたかったので、PHPに加えてRuby on Railsを採用しました。業務委託に依頼する際の主軸がRailsでしたし、当時はまだ私が事業推進にコミットしていましたから、マイナーすぎない技術ならOKというスタンスでしたね。

三好氏：
メリットだったのは、やはり実装の幅が広がったことです。誰でも開発しやすいですし、コミュニティやドキュメントがしっかりしているため、PHPにはないものが基本的に全て揃っていました。

つらみだったのは、Lambdaに未対応だったことです。また、個人的にRailsを触るのが初めてだったので、書き方が属人的になっていた部分もありました。採用部分では競合が多かった感覚もあります。

長澤氏：
当時Lambdaは何で書いていたんですか？

三好氏：
Node.jsかPythonで書いていましたね。

スナックミーのこれまでとこれから：拡大期と安定期

長澤氏：
これからのフェーズはいかがでしょうか？

三好氏：
拡大期と安定期に向かっていくために、しっかりリプレイスをしようと考えています。その中でPython＋Rubyを採用したのは、学習コストの低減やコードの質・心理的安全性を担保したかったからです。

PHPはこれまで基本的にAPI開発の場面で使っていたので、PythonではFastAPIを採用した形ですね。特にPythonを選んだのは、LambdaでPythonがメインになってきたことと、弊社のアルゴリズム開発の部分でPythonの比率が上がり、Pythonを書けるメンバーが増えてきたといった背景があります。

三好氏：
メリットだったのは、DDDなので慣れれば開発スピードが速い点ですね。あとはmypyの型やテストを入れることで開発の安全性も高められたと思っています。FastAPIはswaggerが標準装備されていて、フロントエンドとの連携もスムーズになりました。

つらみは、慣れるまでには多少時間がかかることです。ここはしっかりサポートする体制を今後考えていきたいですね。PythonがAPIを担うイメージも今はあまりないので、広めていきたいです。

長澤氏：
コードの属人性は、Python導入によって払拭できたのでしょうか？

三好氏：
そうですね、だいぶできたと言いきれます。

まとめ：モダンと呼ばれる技術の選定によるメリット/つらみ

長澤氏：
ここまでの話をまとめると、Ubie、スナックミーさんそれぞれが感じた技術選定によるメリットとつらみは以下のような形になります。

長澤氏：
Ubieのメリットとしては、エコシステムの盛り上がりや、一貫して安全なコードを素早く書ける部分がありますね。一方、つらみはエコシステムへの追従や採用ブランディングの複雑化などです。

スナックミーさんのメリットは、サービス提供のスピードを含めてユーザー体験全体がいい感じになってきたこと、アンラーニング思考が身についたという部分ですね。一方つらみは、選定技術への過渡な依存や、プロダクト考察よりも技術仕様に時間を要してしまうところです。

両社がそれぞれさまざまな観点で、自分たちにとって最適な技術を選んできたと伝わったのではないでしょうか。

流行りだけでは決めない、自社にとって最適な技術を選定するには？

長澤氏：
次に、両社が技術選定において意識していることについて聞いていきたいと思います。それぞれポイントを3つ列挙していただいていますので、Ubieから説明をお願いします。

小谷氏：
Ubieが一番大事にしているのは、事業や組織の未来を想像することです。目の前の課題に精一杯になってしまう気持ちはわかりますが、今後事業が成長していくためにどんなシステムをどんな技術で作ればいいのか、逆算して考えるようにしています。ここは組織作りにも影響しますね。

使う技術が自分たちにフィットするかどうかはもちろん、その技術自体やコミュニティがどんな哲学、志向性を持っているのか、どんな方向へ進化しようとしているのかを観察するのも大事です。必要なら、自分たちがコミュニティを引っ張っていけるかどうかも見積もります。

また、頭を動かして技術を選ぶだけではなく、実際に導入した技術がどう課題解決できているか、新たにどんなペインが出てきているのか、肌感を確認するために手を動かし続けるようにもしています。

三好氏：
当社にとっては1番と2番がメインですね。1番は、技術側として解決したいコア技術は何なのかといった部分です。FastAPIでいくと、APIに特化する分ほかのものの優先順位が下がる部分がありますから、そういう観点をしっかり判断・整理した上で技術を選んでいます。

もう一つは、プロダクトの負を解決するために最適解なのかどうかを考えるというポイントです。技術とプロダクトの目線をしっかり両軸で持てるのが大事ですね。片方だけではなかなかモチベーションは上がりません。

その中でいくつか候補を並べて検討しますが、コミュニティの活発度合いが最後の後押しになりやすいと考えています。

最後に：今後注力していきたい技術的挑戦

長澤氏：
最後に、今後注力していきたい技術的挑戦について3つずつ挙げていただきました。Ubieから解説をお願いします。

小谷氏：
まずは本格的なGraphQLの活用ですね。また、静的解析がしやすい状態になってきたので、さらに強化してメンバーが立ち上がりやすく、コードの品質も守られるような状態を目指したいです。あとは組織開発と両輪でのアーキテクチャ整理も継続していきたいですね。

三好氏：
当社はまずRailsからの脱却です。Railsのコードがだいぶ大きくなりすぎてバージョンアップが大変になっているため、変に依存しない仕組みを作っていきたいです。またLambdaをガンガン活用していますが決して効率が良いとは思っていないので、開発効率の向上には注力していきます。

モジュラーモノリスへの取り組みもあります。当社のおやつ事業にはオペレーションやキッチン、出荷などそれぞれしっかり軸を持った業務があるので、このあたりをいつでも切り出せるような状態を作っていきたいです。

Q&A

ここからはイベント中に参加者からいただいた質問に回答していただきました。

技術をやめる意思決定をする際の基準は？

Q.選定した技術の実行ループを回す、とのことでしたが、これまで採用してやめた技術とかはありますか？またやめる意思決定をする際の基準とかはありますでしょうか？

小谷氏：
Ubieの場合はVue.jsですね。Ubieは現在Reactベースのフレームワークだけを使っていますが、Vue.jsも2～3年ほど使ってからやめました。意思決定の理由は、技術が生んでいるペインです。Reactとのコンテキストスイッチコストやメンテナンス、イネーブリングなどさまざまなペインがありましたし、「やめるコスト」も見た結果、「やめる価値がある」と判断しました。

三好氏：
当社はセッションでも述べた通り、属人化した部分があったためPHPをやめました。また、人を巻き込んでいるかどうかも基準としてはあると思います。当時PHPを触っているのは私だけでしたから、新しい技術に切り替える際はどうコミットしてもらえるかも考えて動きましたね。

トレンド技術以外でエンジニアを魅せる工夫は？

Q.起業をしてまさに0→1のプロダクト開発を検討しています（私自身はエンジニア職ではないです）。トレンド技術だけで進めていけない、とわかってきた一方で、協力してくれるエンジニアを引っ張るためにエッジを効かせる必要があると思います。エンジニアに協力いただくためにトレンド技術で魅せる以外の工夫とかはありますでしょうか？

小谷氏：
私の場合は技術よりもUbieの事業やミッション、美しいビジネスモデルに魅せられているので、特に0→1フェーズの場合はビジネスモデルで魅せたほうがいいのではと思います。

三好氏：
0→1を作りたいエンジニアは一定数いるので、そこにどうアプローチするかですよね。事業がピボットするかもしれませんから、どう「人」を魅せるかも大事だと思っています。

理想のアーキテクチャに対してどのようにチームを切る？

Q.チームの分け方、でいくとチームトポロジーの概念があったりすると思うのですが、今後各社理想のアーキテクチャに対して、どのような節理でチームを切っていこうと考えていますでしょうか？

三好氏：
当社の場合はおやつの事業をやっているので、ここをローテーションできるようなチーム作りをしていきたいと思っています。ナレッジや経験を共有できるような動きをとっていきたいですね。

小谷氏：
Ubieはチームトポロジーの概念に則って、組織の整理をしているところです。また、ホラクラシーによる組織の有機性はあまりなくしたくないので、チームトポロジーの概念の上で有機的に短いスパンで状況に合わせられるチームを作っていけるようにしたいです。

リファクタリングに対する経営陣との合意形成はどうする？

Q.モジュラーモノリスへの取り組みに関して、リファクタリングが必要になってきたり、かなり工数がかかると思いますが、経営陣の方にどのようにして合意形成をしてますでしょうか。

三好氏：
開発の負債については数年前から共有していたので、ある程度合意は取れていたと思います。リファクタリングというよりはリプレイスが多く、「新しく立ち上げて徐々にシフトしていく」部分の理解もあったかなと。

小谷氏：
そもそもUbieでは経営陣の反対でリファクタリングができないことは殆どありません。その上で、経営陣やビジネスメンバーが持つ「プロダクトの機能開発をしたい」という力学に対しては、できるだけ金銭的な価値に落とし込むようにしています。

エンジニアの工数がこれぐらい削減できる見込みだから何円になるよねといった形で、定量的な指標を見せますね。最近だとFour keysというデプロイの生産性を測る指標を計測し、より定量的に比較ができる形にしています。

経験がない場合どのように最適な技術選択をすればいい？

Q.登壇者の皆様のように、意思決定・合意形成の経験が多いと複数技術の中から最適な技術選択ができると思うのですが、あまり経験のない場合に関してはどのようにすればいいでしょうか…？技術顧問という方を招聘する形ですかね…？

小谷氏：
技術顧問は良い方法なのですが、それだけでは場数を踏めないので、社内や個人のサービスでどんどん手を動かしていろいろやってみるのが大事です。業務の技術選定においても、例えば自分で選定をしてみて技術顧問にレビューしてもらうなど、実際に自分で考えてみるプロセスを踏むといいですね。

三好氏：
技術顧問でなくても、知人経由で知見がある人に聞いてみてから自分で調べ、小さく初めてみて肌感を得るのは大事だと思います。

まとめ

今回はUbie社、スナックミー社の選定技術の変遷を組織/サービスフェーズ毎に見ていきましたが、いかがでしたか？

両社ともPMF前は最短でプロダクトを作るために技術選定者の得意技術を選んでいること、PMF後はメンバーの能力やサービス性質、言語の盛り上がり等鑑みて選んでいることが共通していたと感じます。

自社にとって最適な技術は何か、技術選定に悩んだ際は2社の意思決定プロセスをぜひ参考にしてみてください。