この記事では、@suzukalight が RELATIONS 株式会社で技術選定したフロントエンド技術と、それを選ぶ際に大事にしている選択基準について、紹介していきたいと思います。（※技術については、記事執筆時点で 2018 年末のものになります）

大事にしている選択基準

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

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

そのためには、下記の 3 点が重要だと考えています。

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

まずは、その理由と事例を交えてご紹介したいと思います。

情報収集のしやすさ

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

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

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

分業のしやすさ

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

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

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

入れやすさ／捨てやすさ

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

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

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

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

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

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

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

UI/Design

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

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

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

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

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

フロントエンド

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

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

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

インフラ

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

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

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

SaaS

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

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

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

まとめ

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

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

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