こんにちは、RELATIONS株式会社の久原です。主にフロントエンドを担当しているエンジニアです。

今回は、弊社で使用しているフロントエンド技術と、それを選ぶ際に大事にしている選択基準について、紹介していきたいと思います。

やや長文になってしまいましたので、さきに選択基準について抜粋いたします。（後半で詳述します）

情報収集のしやすさ（実現すべきUXの開発に集中できること）
分業のしやすさ（各々の得意を生かし完成度を高めること）
入れやすさ／捨てやすさ（仮説の出し入れを素早く行えること）

フロントエンド技術スタックの紹介

リリース済のプロダクトである「Wistant」を例に、技術スタックを紹介したいと思います。Wistantのサービスとしての特性は以下の通りです。

B2BのSaaSプロダクト、マネジメント支援を行うWebサービス
SPAのWebアプリ、スマホ対応（レスポンシブ）
フロントエンドはReact/Redux、バックエンドはNode/GraphQL

UI/Design

design tools: Sketch, Zeplin
catalog: Storybook, StoryShots
design framework: Atomic Design

デザインとエンジニアリングの間のフローとしては、まずデザイナーにSketchを使ってZeplinでWeb上にデザインを配置してもらいます。それに対して、プロダクトオーナーやエンジニアが質問やツッコミをペタペタ貼り付けていくスタイルを取っています。

UIカタログツールとしては、Storybookを採用しています。利点は大きく3つです；

マークアップ専門でも開発しやすい。バックエンドシステムやフロントロジックの用意が不要なので、分業して作業できるようになりました。
パターンカタログができる。パターン漏れが把握しやすくなり、チェックの分業化も実現しました。
デグレの検知がしやすくなる。Snapshot Testing (StoryShots)を連動させることで、チェックの自動化を実現しました。

最近のチャレンジとしては、Atomic Designに基づいたコンポーネント化を行っています。現時点でも、以下のようなメリットが出ています；

エンジニアとデザイナーの共通言語が生まれる。両者でUIレイヤーの認識を揃えやすくなりました。
コンポーネントの役割をレイヤで明確に分離できる。「このレイヤーの振る舞いじゃないよね」といった認識を揃えやすくなりました。
UIとロジックもレイヤーで分離できる。具体例として、molecules以下とorganisms以上を分割点とし、organisms以上にのみアプリの状態への操作権を持たせると規定したことで、UIとロジックを分業した開発が可能になりました。

フロントエンド

language: ES6
transpiler: Babel
ui lib: React
stylesheet: Stylus
framework: Redux, Redux-Saga, normalizr, reselect, Apollo Client
api layer: GraphQL, graphql-subscription
build tool: webpack, Workbox
testing: Jest, StoryShots
linting: ESLint, Prettier

APIはGraphQLを採用しています。リクエストの変化（≒UX改善）に強く、フロント担当者だけでクエリを改変することもできました。加えてgraphql-subscriptionを採用しており、バックエンドのデータ更新をトリガーに、ソケット経由でのリアルタイム同期を実現できました。

最近のチャレンジとしては、モバイルUXを高める目的で、PWAへ順次対応しています。CodeSplittingを行ってダウンロードサイズを削る、AppShellモデルに対応してFirstPaintを早める、Workboxでプリキャッシュを行う、などの取り組みによって、実際にモバイル環境での初期化処理が大きく高速化されました。

ほかに特徴的なものとしては、normalizr/reselectを積極採用していることでしょうか。開発初期はAPIと画面を1対1で紐付けていたこともあったのですが、ソケット通信などで非同期に様々なデータが更新されるアプリへと進化していく過程で難しさが発生して…このあたりの知見は別途エントリにて公開していければと思います。

インフラ

IaaS: AWS
BaaS: Firebase
CI: Circle CI
Virtualization: Docker

特に試作的なリリースを行うときは、DBにRDBではなくFirebaseを使う場合もあります。バックエンドシステムの用意が不要なことや、データモデルがドキュメントベースのため、フロント担当者だけで改造を完結できることなどが利点です。

実例として、基盤システムにはRDBを使いつつ、試作機能にのみFirebaseを導入したことがあります。仮説検証の結果がダメだったときに、捨てやすいのも特徴です（実例です…）

ローカル環境の運用は、すべてDockerにて行っています。コマンド一発で簡単に環境構築ができることから、デザイナーやPOに対しても、ラフに動作確認が依頼できています。将来的にはインフラ含めて一貫して運用したいですね。

SaaS

communication: Intercom
onboarding: Appcues
error tracking: Sentry
payment: Stripe
mailing: SendGrid
analytics: Google Analytics, Amplitude w/Segment

カスタマーサクセス（CS）チームに喜ばれているのがIntercomの導入で、プロダクトにメッセンジャー機能やマニュアル掲示などのヘルプセンター機能を簡単に載せることができました。これによって顧客との距離が大幅に縮まっており、プロダクトの魅力をより伝えやすくなっています。

さらにオンボーディングツールのAppcuesを導入することで、プロダクトにチュートリアルやツールチップ機能を載せることができ、離脱率の減少に寄与することができました。シナリオ作成はSaaS経由で行えるため分業でき、その改善も容易です。

上述のような、プロダクトの本質的価値とはやや異なる部分については、自分たちで作り込まずにSaaSへと積極的に分業しています。それによって得られた時間で、プロダクトの本質的価値の向上に集中して取り組んでいます。

大事にしている選択基準

最も気にしている点は「作りたいものに、いかに集中できるか」です。

ベンチャー企業に属するエンジニアとしては、事業の仮説検証をいかにすばやく回転させられるかが大事だと考えています。そのなかでフロントエンドエンジニアとしては、仮説を実現するためのUXに注力し、ノイズのない仮説を顧客に提供することが求められます。

そのためには、「実現すべきUXの開発に集中しやすくすること」「各々の得意を生かして完成度を高めること」「必要に応じて仮説の出し入れをすばやく行える環境を整えること」、この3点が重要だと考えています。その理由と事例を交えてご紹介したいと思います。

情報収集のしやすさ

実現すべきUXの開発に集中し、少ないリソースで効率的に開発するためには、イケイケのエッジな技術を採用するよりも、情報流通性の高い、多少枯れ始めているくらいの技術のほうが良いと判断しています。

エッジな技術は魅力的ですが、仕様変更やバグも多く、思わぬところで躓いてしまうことが多いと経験上感じます。その対策ばかりに時間を取られるよりは、導入事例の多い「枯れはじめの技術」を使ったほうが、変に躓かずに作りたいものへ集中できると考えています。

ただそれだけでは進化が止まってしまいますので、エッジな技術のキャッチアップと素振りは常に行っています（e.g. React Hooks, Prisma）。キャッチアップを続けることで、枯れ始めたなと感じたときに採用しやすい土壌は整備しています（e.g. Expo, styled-components）。

分業のしやすさ

1人ひとりが持てる「得意」をぶつけて、上限値を高めることが、プロダクトの価値向上につながると考えています。得意を任せ、得意の集合体をリリースするために、できるだけ得意に集中してもらえるよう、積極的に分業をしています。

たとえば弊社ではマークアップのスペシャリストに業務委託としてジョインいただいていますが、AtomicDesignやStorybookを選択し、実装レイヤーが分割可能になったことによって、その得意にコミットしてもらいやすくなりました。

自分たちで作る必要のないものは、どんどんSaaSに頼るのも分業だと考えます。Wistantで多くのSaaSを使用しているのはこのためです。注力ポイントを明確化することで、注力したいUXに対してこだわり尽くしていく姿勢を常に取っていきます。

入れやすさ／捨てやすさ

プロダクトの仮説検証をしていく最中において、顧客や環境が変化することは当然あり得ます。そういった変化にすばやく対応するために、試作的なリリースを行ったり、不要になってしまった体験の除去を行ったりと、機能の出し入れが激しく行われることもあります。

顧客の目に直接触れるフロントエンドにおいては、それは顕著です。ですからフロント技術スタックにおいては、特に機能の入れやすさと捨てやすさが重要になることが多いと考えています。

たとえば外部サービスを活用して試作リリースを行い、結果がポジなら自社開発・ネガなら捨てる。価値の確定しきっていない箇所では敢えてDRY原則を外してダブらせて開発し、ポジなら基盤化・ネガなら捨てる。

機能を出し入れしやすい、ひいては改善しやすい開発体制を作ることによって、仮説をすばやくリリースし、また環境の変化にも追従できる。そんなフロントエンド体制を維持していくことが大事だと感じます。

まとめ

RELATIONSのフロントエンド技術スタックと、フロントエンドエンジニアとして大事にしている選択基準をご紹介しました。「作りたいものに集中できる」環境を整えておくことで、事業の仮説検証と、それを実現するUXにコミットしつづけていきたいと思います。

今回のご紹介では漏れてしまいましたが、他の開発事例として、ReactNative（Expo）, react-navigation, native-base, styled-components, Firebaseなスマホアプリなども開発しています。逆にランディングページではバリバリjQueryを選択したり…。

その他の事例共有・失敗談・情報交換なども出来ると思いますので、ぜひランチなどいかがでしょうか！　お気軽にどうぞ！

https://www.wantedly.com/companies/relations