こんにちは！atama plus のippei & kumeです。
こちらの記事で紹介したように、assessmentチームでは「学力の測定」と「学習」の接続をスムーズにするために検証用プロダクトの開発を進めてきました。
今回はこの検証用プロダクトの技術選定についての紹介です。
技術的な背景
本プロダクトをリリースする前提として、利用者数と利用期間は限られつつも実際に高校生に利用してしてもらうため、本番クオリティの学習体験を短期間で用意する必要がありました。
その制限の下で、今回はatama plusが保有する2つの既存プロダクトの体験部分を切り出し、検証用プロダクトに埋め込むという形を取りました。この埋め込みについての詳細は別記事に任せ、今回はプロダクト全体としての技術選定について書きます。
- 「atama＋」：DjangoのAPI＋Angularのアプリ
- 「オンライン模試」：DjangoのWebサイト＋受験画面のみVue.jsのアプリ
技術選定について
有力な候補を挙げてみる
技術選定をする上では、第一に会社/チームで実績のあるDjangoでWebサイトを作る選択肢が挙がりました。
その前提の元でいくつかの選択肢を検討するうちに、以下の理由でNext.js＋NestJSの組み合わせに魅力を感じました。
- Reactベースのエコシステムは開発体験が整っており、より良いユーザー体験を素早く作れそう。このプロダクトでは「オンライン模試」よりは体験全体が複雑でページ数も多くなる想定でリッチな体験を用意したかったこと、また「atama＋」ほど大規模で複雑な画面構成にならないと考えたため、その観点でも適している。
- チームメンバーがフロントエンドとバックエンドの両方を担当する体制であり、言語をTypeScriptに統一すると切り替えコストが抑えられる。TypeScriptは普段から利用しているため学習コストも抑えられる。
- とはいえバックエンドの開発はDjangoのようなフルスタックのフレームワークに乗りたく、Node.jsでは近々ではNestJSが一番使われていそう（meteor.jsはmongo縛りが強い等の理由で選択肢に入れませんでした）。
- ノウハウのあるRESTful APIにしつつ、型安全なクライアントを使いたい。
- 同じレポジトリ（モノレポ）で一体的に管理したい。
新規技術の検証
Next.jsとNestJSはどちらも未採用の技術だったため、1週間ほど時間を取り検証を実施しました。検証時には、下記の観点で評価を進めました。
- フロントエンドをAngularやVueにするよりも有利か
- バックエンドをDjangoにするよりも有利か
- セットでやってみて社内外で体験してきた既存の構成と比べてどうか
- 開発体験が良いか、短時間で勢いをもって開発できそうか
- 自分たちの感覚を一番大事にする
結果として、気持ちよく開発できそう、また加速させられそうという感触を得たため実開発への採用を決定しました。
ライブラリの選定
細かい選定は割とえいやで決めましたが、以下のライブラリが特に開発体験を良くしてくれたので紹介します。
- Chakra UI
- Angularの様にTypeScriptとHTMLとSCSSを使い分けるのではなく、静的型付けのあるTSX（TypeScript JSX）という１つの言語で全てが完結して、開発体験がよかった。
- OpenAPI + aspida
- aspidaによる型安全なAPI利用は、フロント側の開発体験をかなり良くしてくれる。
- OpenAPIはNestJSでサポートされているので導入しやすい。
- Djangoで書かれた「atama＋」や「オンライン模試」のサーバーともAPI連携が必要になるため、そちらもOpenAPI定義を作成することでaspidaを利用できた。
開発を終えての振り返り
- 予定していた期間で本番運用に持っていけた。
- 開発体験の良さに重きを置きつつ、実際に行けそうかチームで実際に触って評価する時間をとったことでメリットを明確にした。
→リスク管理をしつつ自信を持って進めることが出来た。 - 特に機能が揃ってきて使い勝手や見た目をブラッシュアップする段階で、フロント開発をReactにしたことが大きく寄与した。
→間に合ったかどうか以上に、限られたい時間でより良いユーザー体験を届けられた。
余談ですが、今回の検証用プロダクト開発では既存プロダクトを開発しているチームからエンジニアが１人応援に入ってもらいました。既存プロダクト部分の改修を始め、検証用プロダクト部分も素早くキャッチアップして開発を進めてくれ、非常にありがたかったです。
また次に紹介する既存プロダクトのプロジェクトでは、逆に我々今回ご紹介した検証用プロダクトの開発メンバーが上記エンジニアのチームに1ヶ月出張しての基盤作りをお手伝いしました。チームの枠を越えて柔軟に協力しあえる強さがatama plusの開発の１つの特徴だと改めて感じました。
本開発による良い副作用
実は今回の検証用プロダクトの開発でReactを採用した経験は、既存プロダクトのフロントエンドにReactを採用してリプレイスしていくという決定にもつながりました。チームとしてReactで開発した体験があったからこそ、より状況に合った技術を選定できました。弊社のエンジニアが下記の記事で経緯や詳細を紹介しておりますので、ぜひご覧ください。
まとめ
- 新サービスの開発にあたって、主に開発体験の良さを重きを置いてNestJS+Next.jsをベースとした構成を選択した。
- 特にフロントエンドの開発でメリットが出て、限られたい時間でより良いユーザー体験を届けられた。
- 新しい技術を必要に応じて積極的に採り入れ、チームとしてそのノウハウを共有する動きができた。
- チームやプロダクトの枠にとらわれず、atama plusの開発全体にポジティブな影響を与えることが出来た。
おまけ
- Next.jsの採用については、Next.jsである必要はない使い方になっていたりする現状があるので、改めて別の記事で紹介したいです。
- また、NestJSについては管理画面をNestJS内でレンダーする際のテンプレートエンジンとしてReactを採用したり、それを更にブラウザ上でhydrateする仕組みを導入するなど独自の進化を遂げており、こちらも別の記事で紹介したいです。
atama plusでは今後も情報発信を続けていく予定です。興味をお持ちの方はぜひTwitterアカウントのフォローや紹介資料のご確認をお願いします！
Discussion