こんにちは。フィナンシャル開発センターWeb開発室の鈴木です。Web開発室は現在「LINE証券」のフロントエンドを担当しています。【LINE証券 FrontEnd】 シリーズでは、Web開発室メンバーがLINE証券のフロントエンドにまつわる様々なトピックや、LINE証券の開発中に得た知見をお届けします。今回は第1回ということで、LINE証券のフロントエンドの全体像を説明します。LINE証券というアプリがどんな技術で動いているのか、そして技術に対する考え方を知ることで、LINE証券をより身近に感じていただけると幸いです。

TypeScript + React

LINE証券は、いわゆるSPAとして作られています。最近のSPA開発で最初に決めることといえば、1に言語、2にViewライブラリですね。見出しにすでに出ていますが、LINE証券ではプログラミング言語としてTypeScriptを、ライブラリはReactを使用しています。CSSに関しては、いわゆるCSS Modulesとstyled-componentsを採用しています（プロジェクトによって異なります）。

プログラミング言語の選定に関しては、当初素のJavaScriptかTypeScriptかで議論がありました。特に、チームメンバーにTypeScript経験者が少なくかつハイスピードでの開発が求められる中で、TypeScriptの学習コストが問題になるのではないかという懸念がありました。結局、最悪TypeScriptからJavaScriptに戻すのは比較的容易であることもあり、TypeScriptを使ってみることになりました。

今となっては、もはやTypeScriptの必要性を疑うメンバーはいません。型の役割としてはコンパイル時のチェックの材料になる・ドキュメンテーションになるという2つが主に知られていますが、これらによる恩恵は計り知れません。また、これは別の記事でも取り上げる予定ですが、型定義というのはプログラムの設計を非常によく反映します。型はプログラムの設計のためのツールでもあり、設計の良さは型定義の良さとして現れます。逆に、型定義をブラッシュアップするというのは同時に設計をブラッシュアップすることでもあるのです。具体例としては、コンポーネントの設計を考えるときにまずPropsの型を書くというのは非常に有効です。

一方、Viewライブラリの選定に関してはReactにすんなりと決まったようです。これに関しては、チームにReact経験者・Reactが好きな人が多かったのが理由でしょうか。Reactとの比較対象によく挙げられるのがVueですが、VueとReactは書き心地が大きく違って一長一短なので、状況や好みによって選べばいいのではないかというのが私の正直な意見です。一般にReactの方がTypeScriptと相性がよいとされていますから、結局TypeScript + Reactという鉄板の構成に落ち着いたことになります。

ステート管理

Reactと言われれば、次に気になるのは「ステート管理をどうしているのか」でしょう。特にReactアプリケーションにおいてステート管理の方法に決まった答えはありません。それぞれのアプリが思い思いの方法でステート管理を行なっています。

まず、いわゆる「ステート管理ライブラリ」はほとんど使用されていません。その理由としては、プロジェクトの規模が大きいため人数も多く、画面間での無闇な共通化を避けたかった（共通の依存を減らしたかった）ということが挙げられます。ステートを一箇所で一元管理すると、必然的に全ての担当者がそこに手を入れることになり、特に初期開発では混乱が発生します。また、複数画面にまたがって保持されるステートがそもそもあまりありません。ルーティングのためにはreact-routerとhistoryを使用しており、ページ間でデータの受け渡しが必要な場合はそれを介してlocation.stateで渡す方法が主に取られます。ほとんどのステートが画面内で完結するため、その画面を司るコンポーネントでステートを宣言すれば事足ります。画面内でのステート管理の方法も人それぞれであり、useStateを並べる人、useReducerを使う人、コンポーネントを分割した子コンポーネントでuseStateを使用したりする人などがいます。

Reactアプリを作る際に悩ましいのがAPI呼び出しによるデータ取得の実装ですが、LINE証券ではステート管理ライブラリを使用していないことで、この部分の自由度は高めです。古いコードでは「componentDidMountでAPIを呼び出して帰ってきたらステート更新」のようなやや愚直な実装が書かれていますが、最近のコードではReact 16.8で導入されたフックの普及を受け、ステートを内包した手製のuseApiというフックを使うようになりました。このようにステートを内包したロジックを再利用可能な形で書けるのはフックの素晴らしい点の一つですが、ステート管理ライブラリを使用しないという選択によりこの方向に舵を切ることができたと言えます。

統一しないという考え方

我々のステート管理手法を知って「統一感が無い」と思った方も多いでしょう。同じことを達成するのに複数の方法があり、それぞれの人が、また書かれた時期によっても異なるやり方を選択しています。この裏には2つの考え方があります。

我々は、やり方を無理に統一する必要がないという考え方を持っています。統一されたやり方はプログラムを読むときのコストを下げる可能性がありますが、統一されていなくてもプログラムの読解力がしっかりしていれば差は微々たるものです。そもそも場合によって最適解は異なりますから、様々な要件が飛び交うアプリ開発においては、パターン認識による効率性に頼るよりもそもそも読みやすいプログラムを書くことの方がよほど重要だと感じています。

ただ、使用ライブラリを統一するといったことは依然として重要です。それはプログラムの認識しやすさ以前に、バンドルサイズ等といったより現実的な問題がある上に、ライブラリの知識を得るためのコストはプログラムを読解するコストとは別物だからです。

また、我々は、とりあえずやってみるという考え方を大事にしています。新しい手法の導入にはリスクが付き物ですが、我々は2つの方法でリスクを抑えようとしています。一つは、最大限議論して本当にやる意味があるのか、現状の問題がうまく解決されるのかを確認することです。もう一つは部分的に導入することです。例えばステート管理についても、無理にやり方を統一していないことによって新しい方法を部分的に導入するのが簡単になっています。前述のuseApiがその成功例です。

新しい手法を試したい際に我々はとりあえずやってみるという選択肢を取ることが多くあります。うまくいったものはチームに受け入れられアプリ全体に浸透します。ただし、全てが成功するわけではありません。実は、議論の上思い切って一部のページのステート管理にReduxを導入してみたこともありましたが、こちらはやってみたもののチームの考え方に合わなかったため広く受け入れられませんでした。

各々が好き勝手にやると、コードが属人化する危険性があります。我々も属人化を完全に防げているわけではありませんが、読みやすいコードにこだわったり、議論を重視することで属人化を回避しようとしています。LINE証券は、それができる素晴らしいチームによって作られています。

まとめ

この記事では、【LINE証券 FrontEnd】シリーズの第1回として、LINE証券のフロントエンドの全体像を説明しました。次回以降もLINE証券メンバーが様々なトピックをお届けします。お楽しみに。

【採用情報】

• フロントエンドエンジニア / LINE Financial / 証券  https://linecorp.com/ja/career/position/1102
• フロントエンドエンジニア / フロントエンド開発センター　https://linecorp.com/ja/career/position/475