Skillnoteリニューアルプロダクト（X1）の技術選定理由について
記事の背景
SkillnoteVPoEの安藤です。
前回（https://note.com/daisuke_ando/n/n8ea737164414）はこの2年間を振り返り、開発チームやプロダクトの大枠について記載しました。
今回は、2021年4月にローンチしたリニューアルプロダクトについて、技術面について2回に分けて記載します。
※リニューアルプロダクトは開発コード：X1（エックスワン）と社内で呼んでおり、以降記事内でも呼び慣れた呼称にて記載します。
X1開発に至る経緯
そもそもX1の構想自体は私が入社した2019年9月以前からありました。
代表の山川が当時外部委託のみだった開発体制を内製化し、リニューアルプロダクトの開発をする、ということを意志決定しており、それが私の入社理由の1つにもなっています。
なお入社理由については以下の記事で簡単に触れています。
入社後からエンジニア採用とも並行し少しずつ構想を練っていたところ、2020年1月、とあるお客様とのミーティングにおいて、お客様より「現在稼働しているSkillnoteでは弊社のニーズをカバーできず採用することが難しいことが分かった。ついては新プロダクトの構想があったと思うが、その採用を検討したいため、検討期間を1年間引き延ばした」と共有いただきました。
そのお客様はSkillnote社としても重要なお客様であり、求められているニーズも弊社の事業、スキルマネジメントど真ん中の業務となっていることから、リニューアルプロダクトはこのお客様のニーズをとにかくカバーしていこう、それができれば、他のお客様のニーズにも十分応えられるだろう、ということで、それまで具体的な期限を決めずに検討していたプロダクトのリニューアルについて、このミーティングの30分後には「2020年10月までにX1をデモできるようにする」ことを決めました。
※なお、この時点で開発メンバーは自分一人のみ、2月に入社するメンバーが1名決定していただけ、という非常にチャレンジングな目標でした。
その後各種技術選定に入り、メンバーの入社を待ち、2020年4月頃から設計フェーズに入り、5月からアーキテクチャの検討やベンダーとのミーティングを開始、デザイン設計やカンプ作り、お客様との壁打ちを始め、なんとか最終的に2020年11月にお客様にデモできる状態に持っていくことができました。
なんとプログラム自体のファーストコミットは7月に入ってからでした・・
採用技術とその選定理由
X1で利用する技術についてさまざま検討・検証し、以下のような技術を採用することとしました。
・プログラム言語：Kotlin
・アプリケーションフレームワーク：SpringBoot
・フロントエンドライブラリ：Vue.js
・データベース：PostgreSQL
個別の採用理由の前に、Skillnoteのビジネスモデルや当時の状況として以下のような前提を考慮する必要がありました。
・B2BのSaaSシステムであること
・オンプレを要求するお客様が一定数いること
場合によってはクラウドサービス利用が禁止されているお客様も多々
・既に本番稼働して数年経過しているプロダクトが存在すること
これらを元に、X1のミッションは「10年間の運用保守に耐えられる設計とする」こととしました。
このミッションをベースに、それぞれの選定理由を記載していきたいと思います。
Kotlin
まずサーバーサイドの言語として、10年間保守するとなると、ビジネスの成長にもよりますが延べ人数として少なくとも数百人がシステムをメンテナンスすることとなります。そのため、以下のような特徴を持つ言語である必要がある、と考えました。
・静的型付け言語であること
・なるべく後方互換性を保ったバージョンアップをする言語であること
上記の特徴を持つサーバーサイド言語は、当時の自分も現在の自分もJavaしか知りませんでした。
ただし、Java言語を採用することは難しいと考えていました。その理由として「スタートアップ企業が新プロダクト開発に採用する言語として、エンジニアが興味を持つ言語であること」も採用面から考慮する必要があったためです。
それも考慮すると、選択肢が非常に狭まりました。例えばGroovyも候補でしたが、DSL利用での実績はあれども本格的なwebアプリケーションの採用実績やフレームワークの選択肢が少なく、採用を後押しする力がありませんでした。
最終的にはKotlinに決定したのですが、その決定理由は以下のような点でした。
・Javaのライブラリが利用可能
・（場合によっては）Javaを書いても動く、Javaの知識があればすぐにでも開発可能
・Android開発では標準言語となっており、サーバーサイド採用も少しずつ広がっていた
・言語の開発元の信頼性が高い
SpringBoot
このフレームワークの採用理由はほぼKotlinの採用理由と同様です。
本家のドキュメントの充実ぶりなども特筆すべき点です。（マイグレーション時の注意点もしっかり記載されているなど）
Vue.js
私自身フロントエンド開発においてはSPAなどの経験はなく、jQueryやBootstrapを利用したちょっとした動きを画面に加えるような経験しかありませんでした。
その経験の中でも、以下のような点は多人数開発を実施する上で課題になると考えていました。
・id, classのセレクタ指定はデザイン変更の影響を受けやすい
・1つしかヒットしない前提のセレクタが、いつの間にか複数にヒットし不具合を発生させる
・JavaScriptの処理中でDOM要素を操作する場合、場所を指定する記述が困難になりがち（そのため意図が伝わりにくいidが増えるなどの弊害が出る）
これらの課題を解決することに加え、以下のような点を考慮しました。
・習得の技術ハードルが高すぎないこと
・SPAでのフロントエンド実装は避けること
技術ハードルについては、当時フロントエンドのリードエンジニアがいなかったことに加え、X1のデモスケジュールがタイトであったことから、技術的なハードルをあまり高く設定できなかった、という事情もありました。
また、angularのような重厚なライブラリに頼ってしまうと、技術進化の早いフロントエンド領域で大きくロックインされてしまうことにもなるため、SPAを採用しない開発を実施するシステムにおいてはより軽いライブラリを採用したかった、ということもありました。
最終的にはVue.jsかReactかの2択で検討・検証し、細かい理由はあれど、比較的好みの問題というか、えいやで決まった、という経緯です（笑）。
PostgreSQL
詳細は次回の「不採用理由」で記載しますが、RDBMSを採用することとし、MySQLかPostgreSQLかの2択となりました。
現在はさほど差異がある訳ではありませんが、B2Bの業務システム向けの機能が充実しており、より親和性が高いと判断しました。
初期のアーキテクチャとしてはこの図のような形式になりました。
ECS FargateやAurora、ElastiCache等を採用しており、なるべくインフラ的な保守運用の負担を下げるような構成を取っています。このあたりの詳細もいずれ記事にできればと考えています。
今後採用していく技術の方向性
現在採用している技術は、当時のビジネス状況や開発メンバーの持っている技術レベル等に大きく影響を受けて選定してきています。
ミッションである「10年間の運用保守に耐えられる設計とする」もその通りいくかもしれないですし、そうでないかもしれません。ビジネス状況の変化、利用状況の変化に応じて柔軟に対応していく必要があります。
中期プロダクト戦略に従い、さらにプロダクトを増やしていく可能性もあります。
その時々で自分たちが納得しつつ、前向きなモチベーションで取り組める技術を採用することを前提として選定していきたいと考えています。
今後の技術選定は自分自身で実施することはなく、次のテックリードに任せていく方針ですが、X1のリニューアルなどもタイミングを見て決めていきたい、テンションが上がる技術には常にアンテナを張ってアイディアを出し合いながら決められると良いな、などと考えています。
まとめ＆次回記載すること
長くなってしまいましたが、今回は「採用」の理由や背景について記載しました。
次回は「不採用」になった技術について、お蔵入りしている状態ですのでこの記事を最後に供養、というか紹介させてもらい、技術選定の回を終わりにしようと思います。
X1の技術選定理由に共感した、今後の可能性についてもっと突っ込んで聞いてみたいなど、興味を持っていただけた方、カジュアル面談を随時受け付けていますので、気軽に話しにきてください！
この記事が気に入ったらサポートをしてみませんか？