フロントエンドとサーバーサイド、それぞれの技術選定の方針
フロントエンドの技術としては、React + ReduxやTypeScript、Next.jsなどが採用された。Reactを使用したのは、Eight開発チームで採用実績があるため知見があること、「個人的にVue.jsよりも好き」といった理由が大きかった。TypeScriptを導入したのは、型定義を用いることによる開発の効率化が目的だ。サーバーサイドにはNode.jsが採用された。
「Node.jsを選んだ理由はいくつかあります。まず、部署内にはRuby on Railsが得意なメンバーが多かったものの、現時点ではGoogle App EngineのStandard EnvironmentでRubyが使えないこと。個人的にRubyの次に得意なのがJavaScriptであること。それから、プロジェクト初期フェーズで少人数チームである間は、メンバーがフロントエンドとサーバーサイドの両方を担当できた方がいいだろうといった判断からです」
Node.jsを選べば、フロントエンドもサーバーサイドもJavaScriptであることから越境がしやすくなる。フレームワークにはExpressを採用。軽量なフレームワークで、マイクロサービスに向いているという。
API設計では、書籍『Webを支える技術』やRuby on Railsのルーティングを参考にして、設計方針の策定を実施。APIドキュメントとしては、デファクトスタンダードとなりつつあるSwaggerを用いた。
「フロントエンドの実装では、StorybookやRedux、Jestなどを用いました。特にStorybookの導入は成功でした。コンポーネント単位で動作確認をしながら開発できるメリットがあるからです。
Reduxでは、Actionsとしてtypescript-fsaを使用しています。もともとはredux-actionsを使おうとしましたが、TypeScriptとの相性が悪かったため断念しました。ReducersとしてはImmutable.jsを使っています。Immutable.jsのRecordという機能を使うことで、Reducerの設計をシンプルにできることが利点です。
また、自動テストのためにJestを用いています。RSpecライクな記法のため、Rubyに慣れた人には馴染みやすく、機能がオールインワンであることも優れています」
さらにサーバーサイドの実装としては、「コントローラーにSwaggerでAPI定義をし、データベースまわりの処理はモデルで行う」「複雑な処理はモジュールに切り出す」「認証やエラーハンドリングなどはミドルウェアで行う」などの基本方針を採用した。
最後に総括として「その事業において、何が求められているかを考えること」「（エンジニアとして）技術的に越えてはいけない一線を守ること」「より良い選択のために、日頃の鍛錬を欠かさないこと」の重要さが改めて語られ、セッションは終了した。
お問い合わせ
Sansan株式会社
- コーポレートサイト
- Sansan Builders Box：Sansanのものづくりを支える技術やデザイン、プロダクトマネジメントの情報を発信しています。
