はじめに
こんにちは、株式会社ispecのフロントエンドエンジニアのs.katoです。
私たちは医療系のシステム開発を行っており、特に電子カルテシステムや医療従事者向けのWebアプリケーションの開発を担当しています。
この記事では、そういったアプリケーションの開発にあたって私たちがどのような技術選定を行っているのかについて紹介していきます。
フロントエンドの技術選定とひとことに言っても、フレームワークからテストツール、linter、日付データを扱うライブラリまで、対象は様々です。今回はプロジェクト最初期に選定するもののうち考慮すべき事項の特に多いものを抜き出して扱います。
標準技術
開発に利用する技術には、社内で統一し標準化するものとプロジェクトごとに選定するものの2種類があると考えています。この章では前者について紹介します。
ispecではフロントエンドのベースとなるライブラリとしてReactを、スタイリングフレームワークとしてTailwind CSSを標準技術として採用しています。コミュニティの大きさからくる豊富な情報量や、開発効率の向上といった観点からこれらは選定されています。
また、APIはGraphQLで構成しているので、クライアントライブラリとしてApolloClientを採用しています。こちらはGraphQLへ移行した当初から採用されていたこともあり、社内ですでに知見が溜まっていたことが理由としては大きいです。比較的規模の大きいアプリケーション開発において、豊富に提供されている機能が有用であった点も選定理由にはなっているのかなと思っています。
同様のクライアントライブラリとしてurqlやrelayもあるので、最近そちらの採用も視野に入れて検証してみようという動きがあります。
選定基準、観点
具体的な「現在何を択として持っているか、何を採用しているか」は、プロジェクトが始まるたびに選定をする前提のものにおいてあまり重要ではないと思っているので、それはあくまで例として挙げる程度にとどめ、観点にフォーカスして紹介していきます。
フレームワーク/アーキテクチャ
アプリケーションの全体、あるいは一画面あたりの機能数、開発体制(開発に関わるメンバー)はアーキテクチャやフレームワークの決定に関わってきます。
一画面あたりの機能数が多い複雑なアプリケーションの実装が必要なら、その複雑性の解決のために自律分散型アーキテクチャを採用したい。こういった時、例えばNext.jsのReact Server Component(RSC)やSuspenseによる遅延レンダリングは相性が良さそう。
逆に、比較的シンプルなアプリケーションならReact Routerのような軽量なフレームワークで必要十分な機能をもって実装していく方が、フレームワークからもたらされ得る余分な複雑さも減らしつつ効率的な開発ができそう。
といった感じで検討しています。
また、toCのアプリケーションであれば、エンドユーザーの端末のスペックを問わず一定のパフォーマンスを出せるようにするためにSSRを採用し、それをもとにフレームワークを選択することもあります。
他にも、社外のエンジニアの方と連携して開発する場合、メンバーが精通している技術を採用する場合もあります。
UIコンポーネントライブラリ
ispecでは社内デザインシステムを作成しているので、もしそれを採用できるのであれば自然と利用するUIコンポーネントライブラリはshadcn/uiに決まります(デザインシステムが依存しているライブラリなので)。
それ以外でライブラリを選定する際は、まず社内で標準技術となっているReact、Tailwind CSSに対応しているかどうかがまず前提条件として挙がります。必要に応じてRSCに対応しているかどうかも見る必要があります。
サービス側にデザイン規約が存在しておりそれを遵守する場合、UIコンポーネントライブラリの選定にあたって「カスタマイズ性」に注意する必要があります。細かく色や角丸の具合などを調整しようとした時、毎回CSSで上書きが必要なのか、テーマ変数設定から容易に調整できるのか、など。
ライブラリのメンテナンスがどれだけの頻度でされているか、は安定性や将来性の観点から気にする必要があるので、Githubの最終コミット日やissueの解決具合などを参考にしています。
コミュニティの大きさや、日本語の情報はどれだけ存在するかなどもキャッチアップコストに関わってくるのでみておきたいですね。
プロジェクトのスピード感やデザインの制約によっては、Chakra UIなどのようなリッチなコンポーネントが提供されているものを全面的に採用することも視野に入れることができます(Chakra UI自体はスタイリングの仕方が独特ですが)。
実際の選定例
例A
概要
1画面あたりの機能数は一般的な量。フロントエンド担当エンジニアは社内エンジニア3名程度。デザインに関して特に規約などはなし。
技術
React RouterのSPAモードでシンプルな構成をとりつつ、中央集権型アーキテクチャを採用。自社デザインシステムを用いてスピード感のある実装を目指しやすい形を実現。
例B
概要
1画面あたりの機能多数。全体的にリッチな機能を有しており複雑性はかなり高い。フロントエンド担当エンジニアは社内メンバーに加え、社外のエンジニアの方も参加する形で大規模な開発になる。デザインに関する規約あり。
技術
Next.jsを採用し、RSCや遅延レンダリング機能を活用。また自律分散型アーキテクチャで設計することで、機能のボリュームや複雑性に耐え得る形を実現。UIコンポーネントライブラリはカスタマイズ性の高さからshadcn/uiを採用。
例C
概要
機能数の少ないシンプルな管理画面系のアプリケーション。ミニマムかつ超短期間での実装が必要。フロントエンド担当エンジニアは社内メンバー1名のみ。担当者は元々バックエンドをメインで担当していたエンジニア。デザインは特に指定なし。
技術
キャッチアップコストの観点から、React RouterのSPAモードで必要最小限の実装基盤を構成。UIコンポーネントライブラリはChakra UIを採用し、スタイルの調整は最低限にしつつ基本的に提供されているコンポーネントを組み合わせるのみで実装を進める方針に決定。スタイリングについてもChakra UI側で提供されているインターフェースがそのまま利用できるので、Tailwind CSSを用いるパターンよりシンプルになると判断。
おわりに
当初は現在採用している技術をつらつらと並べて、それぞれ採用理由を差し込んでいくという記事の構成を考えていました。
しかし、新しい技術が次々出てきて採用する技術も流動的に変わっていく可能性がある中、今その瞬間採用している技術をスナップショット的に書き残すのは、個人的には書くモチベーションの湧かないものでした。理由は「選定基準、観点」項冒頭で述べたとおりです。
なのでもっと踏み込んで「技術選定のロジック」、あるいはそのロジックに必要な「観点」をメインに据えて書く形で書かせていただきました。
この記事を通じて、技術選定という難しい判断の一助となるような視点を少しでもお伝えできていれば嬉しく思います。
Discussion