ゼロからプロダクトを立ち上げた時の技術選定で考えたこと、そして懺悔
0. はじめに
こんにちは、UPSIDERのVPoEをしています清水と申します！
今回はUPSIDERのAdvent Calendarのトップバッターということで、なにをテーマにしようか考えていたんですが、弊社の法人カードプロダクト立ち上げ当初の技術選定について、どういう理由で今の構成にしたのかを聞かれることが結構あるので、当時どんなことを考えていまの技術スタックにしたのかについてまとめたいと思います。
1. 前提
いきなり身も蓋もないことを言いますが、技術選定に正解はありません。
会社の置かれている状況、プロダクトの性質、技術選定の時期、開発メンバーの経験etcetc…によって最善と考えられるものは大きく変わるからです。
その上で、まずは弊社の技術スタックをご紹介します。
※ちなみに、弊社はカード決済を取り扱う会社のため、Webシステムとは別に決済システムが別に存在していますが、そちらは今回触れません。今回お話するのはあくまでWebシステム側、その中でもServerSideについてです。
言語：Kotlin
ソフトウェアアーキテクチャ：Clean Architecture
Webフレームワーク：Ktor
そして、技術選定の前提となる当時の状況はこんな感じです。
時期は2018年9月頃
短期で使い捨てるプロダクト・コードではなく、中長期で運用していくことを想定
ServerSideを開発するエンジニアは当初僕一人 & 最初は副業での関わりだった
技術選定はほぼなにも進んでない
当然ソースコードも一行もない
お金もない
立ち上げ当初のスタートアップあるあるで、なかなかにカオスな状況です。
そんな中で、技術選定をどんな流れで行ったかについてお伝えしていきたいと思います。
2. 言語
前提にもあるように、「中長期で運用する」ことを想定したプロダクトのため、静的型付けの言語にすることは初めから決めていました。
かつ、ServerSideの開発者は僕一人でしかも副業での関わり方のため、シンプルに初めて触るような言語のキャッチアップにかけられるような時間的猶予は皆無。なので、「僕自身が早期にアウトプットを出せる」ことが最重要でした。
静的型付けでかつ僕が一定習熟していると言える言語はJavaとKotlinだったため、キャッチアップの時間をかけない前提だともはやこの二択になります。
当時はまだまだServerSideでKotlinを使っている事例というのはあまり多くありませんでしたが、自分自身前職（というか当時は現職）でもServerSide Kotlinを使っており、Javaと比較してもほぼ不便なく安定して運用できることはわかっていました。
また、null safetyであること、コレクションの扱いやすさなど、開発生産性の上でも（僕が開発するという意味で）Kotlinのほうが上だったため、言語に関してはあまり悩まずKotlinで行くことに決めました。
3. アーキテクチャ
ソフトウェアアーキテクチャに関しては、誤解を恐れず言うと、正直「別になんでもいいや」と思っていました。
ただ、依存関係がぐちゃぐちゃになって地獄絵図が展開されるプロジェクトを過去何度も見てきたため、依存関係の矢印がとっちらからないような仕組みが絶対必要だし、そこには確実にこだわりたいと思っていました。そのためにはソフトウェアアーキテクチャの仕組みを使って「依存関係の矢印をできる限り一方向になるよう強制する」のが最も確実です。
レイヤー間でクラスの変換が必要になるため、作成するクラスの数はどうしても多くなりますが、それを差し引いても依存関係を整理するほうが寄与するメリットが大きいと考えました。
そういう意味ではオニオンアーキテクチャでもCleanArchitectureでもよかったので、そこは割とえいやで決めた感じです。
実際開発を進める中で、クラウドベンダーがAWSからGCPに変更になったり利用するメール配信システムが変更になったりといったこともあったんですが、CleanArchitectureにしていたおかげでサクッと変更できたので、そういう意味ではきちんと恩恵も享受できました。
4. Webフレームワーク選定
当時、ServerSide Kotlinで使われていたフレームワークは、圧倒的にSpringBootでした。（というかそれ自体はいまもあまり変わっていない）
実績も多くあり、僕自身も業務経験があり、必要なものはなんでも揃っている。
一方で、SpringBootにはいくつか懸念もありました。
CleanArchitectureを採用することを決めていたため、極力ビジネスロジックがWebフレームワークに依存しない形にしたいが、SpringBootは全部入りな分、SpringBootからの依存を脱却させるのが難しい（DIとか、Transaction管理とか。むしろSpringBootでCleanArchitectureやってる方々は、このあたりどうしているのか聞いてみたい）
少なくとも当初はそんなに必要な機能が多いわけではないため、必要な機能だけ入れて軽快に動かしたい
個人的にSpringBootのアノテーション地獄があまり好きじゃない（完全に好みの話）
これらの懸念を解消するため、軽量なWebフレームワークを探したところ、JoobyとKtor、2つのフレームワークを見つけました。
この2つは思想としてはだいぶ似ているんですが、JoobyはJava（Kotlinにも対応済み）、KtorはKotlinで作られています。
せっかくならできる限りPure Kotlinに寄せて、Kotlinのnull safetyな世界にどっぷり浸りたいなあと思っていた（Java製のライブラリはKotlinでも普通に使えるが、Kotlin対応されていない場合null safetyが壊れることがある）ため、Ktorの利用が問題ないかを検討することにしました。
調べてみると、必要な機能は一通り揃っており、必要な機能だけ組み込むことが可能なため動作も軽快。
最大の懸念は、まだVersionが1.0に到達していなかったこと。そのため、僕が知る限り国内でKtorをプロダクションコードとして採用されている例はまだ存在しませんでした。
開発時点で、まだ安定版に到達していないというのは当然リスクなのですが、もう致命的なバグはほぼ解消済みで1.0リリースに近づいていそうだった（事実、開発初めて二ヶ月ほどで1.0がリリースされました）ことと、JetBrains製で突然メンテされなくなるみたいなリスクはだいぶ低そうだったことを考えると、だいぶリスクは抑えられているように思います。
しかもちょっといやらしい話をすると、まだどの企業もプロダクションコードとして採用されていないktorを採用することで、会社としてのブランディングができて最新技術にアンテナを張っている技術力の高いエンジニアの採用にきくのでは、という気持ちもありました。
※ 事実、弊社のリードエンジニア数名はこれがきっかけで弊社に興味を持ってくれ、採用に至った経緯もあるため、一定この狙いは当たったのではと思っています。
かくして、WebフレームワークはKtorを採用することに決め、大枠での技術選定が固まったのでした。（そしてこの後ORMapperやDIコンテナなどの選定の沼にハマることになる）
めでたしめでたし。
5. 懺悔
さてここまで、色々と技術選定の経緯を述べてきましたが、もう（勝手に）時効だと思うので告白します。
全部ウソです。
いや、ウソは言いすぎた。上記に書いた理由はたしかに当時考えたことなんですが、それは「この技術スタックでやってみたいんだけど、なんかうまいこと理由付けできないかなー」という考えのもと、後からねじ込んだ理屈です😇
ServerSide KotlinにしたのはKotlin大好きだからだし、CleanArchitectureは今まで実務でやったことなかったからやってみたいだったし、Ktorは「Pure Kotlin＆JetBrains製とかめっちゃ楽しそうじゃんげへへ」でした。
割と僕は「モチベーション駆動開発」タイプで、楽しいかどうかが生産性に直結する人間です。自分の中のワクワクが最重要なのです（かつエンジニアには結構な割合で同類がいると信じています）。
当然、その技術を使ってビジネスがうまくいかなかったら元も子もないので「それで進んじゃってビジネス上問題が発生しないか」はちゃんと調査しますし、最終他の人たちを納得させられるような理由付けがうまくできなければ諦めますが、そこさえクリアできたらあとは正直「だって使ってみたいんだもん」しか考えてませんでした。
でも、スタートアップに集まっている人なんてだいたいみんなワクワクしたくてやってるんですよね？自分のやりたいこと進めるために後から理由考えたことだってもちろんありますよね？ね？？
とはいえ僕のそんな浅薄な考えなど他のメンバーはお見通しだったと思うので、それでも温かく僕の選択を見守ってくれたみんなには本当に感謝してもしきれません。
当時の事例からもわかるようにUPSIDERは、エンジニアみんなのワクワクを大事にする会社です。
我々がミッションとして掲げる「挑戦者を支える世界的な金融プラットフォーム」になるための下地がようやくできてきて、いよいよそのための本格的なチャレンジを始めていく大変エキサイティングなフェーズなので、ご興味お持ちの方はぜひお気軽にコンタクトください！（無理やりまとめた）