多くのユーザーに常用されるコミュニケーションアプリ「LINE」には、エンターテイメントやライフスタイル、ショッピングなど多種多様な関連サービスがあります。
その中でスマホ投資サービス「LINE証券」や、外国為替証拠金（FX）取引の「LINE FX」、個人向けローンサービス「LINEポケットマネー」、「LINE」アプリ上で損害保険に加入できる「LINEほけん」などファイナンシャル（金融）系サービスの展開も拡大しています。
こういったFintech事業に、LINEエンジニアはどう取り組んでいるのか？ 「LINE証券」を開発する3名に、事業を支える技術の詳細を伺いました。聞き手は、テスト駆動開発の第一人者でありITコンサルタント・ソフトウェアエンジニアの和田卓人（@t_wada）さん。
信頼性と高速性の両立が求められるFintech領域において、LINEはどのような工夫を行っているのでしょうか。
※ この記事は、LINE株式会社によるSponsoredContentです。
- スモールスタートで事業を高速に立ち上げる
- 金融のため型安全性で優れるTypeScriptを中心に技術を選定
- フロントエンド領域の進化にできる限り追随していきたい
- 安全対策基準に則ったマイクロサービス基盤をコンテナで構築
- 非機能要件を担う共通基盤としてインフラ基盤を整備
- Fintech領域ならではのチャレンジに醍醐味がある
- 和田 卓人（WADA Takuto、写真上段左） @t_wada
twada
- タワーズ・クエスト株式会社取締役社長、プログラマ、テスト駆動開発者。翻訳や監修を担った書籍に『テスト駆動開発』『SQLアンチパターン 』『プログラマが知るべき97のこと』『Engineers in VOYAGE』など多数。t-wadaのブログ
- ぺんぎん（pseudonym、写真上段中央）
- LINE フィナンシャル開発センター Fintech Dev Eチーム サーバーサイドエンジニア
Javaで複合機用のアプリやSI現場で共通ライブラリを作成する仕事を経て、PerlでWebサービスを作るようになる。LINEでは、開発者向けサイトやMessaging APIを作成する業務を担当。好きなプログラミング言語は、ScalaとKotlin。 - 鈴木 僚太（SUZUKI Ryota、写真上段右） @uhyo_
uhyo
- LINE フィナンシャル開発センター Front-endチーム フロントエンドエンジニア
TypeScriptコンパイラへのコントリビューションのほか、自身のブログやQiitaでフロントエンドやTypeScriptに関する記事を数多く公開。TypeScript入門書を執筆中。 - 前多 賢太郎（MAEDA Kentaro、写真下段右） @kencharos
kencharos
- LINE フィナンシャル開発センター SREチーム サーバーサイドエンジニア
金融システム開発や技術コンサルなどを経て2019年より現職。『みんなのJava』（技術評論社）第6章の執筆を担当。
※写真下段左は、アドバイザリーとして同席されたLINE株式会社 フィナンシャル開発センター 開発1室 副室長の小橋弘和さんです。
スモールスタートで事業を高速に立ち上げる
── LINEのFintechサービスはアプリを中心としたWebのシステムですから、用いられている技術にもWeb共通のものと、金融のドメイン知識をベースにするものがあるのではないかと思います。まずプログラミング言語やライブラリ、フレームワークといったところからお聞きしたいのですが、サーバーサイドの技術選定について教えてください。
前多 LINEではサーバーサイドの開発言語としてJavaが用いられることが多く、その傾向はFintechでも同じです。ツールなどはPythonやGoで実装することもありますが、サーバーサイドではほぼJavaが採用されています。フレームワークではSpring Bootが頻繁に用いられます。
新しいプロジェクトについては、Javaからのリプレースが容易なJVM言語のKotlinを使うケースも増えていますね。
リレーショナルデータベースはMySQLを使うことが多く、その他のミドルウェアとしてはRedisやKafka、Elasticsearchなど。比較的オーソドックスな構成です。
和田 さまざまな事例で拝見する、LINEの技術スタックの鉄板構成という印象ですね。プロジェクトごとに自由度の高い技術選定をする企業もありますが、LINEは技術の統一性を重視しているのでしょうか？
ぺんぎん どの技術を選択するかについては、チームやプロジェクトによっても方針が異なります。Fintech事業においては、他の事業部から社内異動で私たちのチームに移ってくるメンバーも多いので、必然的にLINEのサーバーサイドエンジニアが使い慣れているJVM言語やSpring Bootが第1の選択肢になりやすいです。
和田 開発言語やフレームワークだけでなく、アプリケーションのコンポーネント構造についても伺いたいです。
ぺんぎん 最初期はレイヤードアーキテクチャに近い形でしたが、事業フェーズごとに変遷しています。レイヤードアーキテクチャも意識的に採用したというより、プロダクトを最速で立ち上げることを優先した結果、そうなったというのが正しいです。
「LINE証券」の立ち上げ時には、開発のスピードが必要でした。エンジニアも私を含めて3名という少人数からのスタートで、アーキテクチャを整備することより、少しでも早く機能を実装することが重要だったのです。
事業が軌道にのった後で、前多さんをはじめとするSREチームのメンバーがアーキテクチャを整備してくれた結果、現在はクリーンアーキテクチャに近い構造になっています。
さらに、前多さんがアーキテクチャに沿った実装ガイドラインのドキュメントを作成してくれたことで、各エンジニアはその指針をもとに実装を進められるようになりました。
和田 スタートアップ企業やWeb企業が新規事業を始めるときの典型的な良いパターンですね。少数精鋭のスモールチームによって最速でプロダクトを立ち上げ、後から交通整理する。
この際に鍵になるのは、能力のある人を集めてくるだけではなく、各メンバーがなるべく独立して並列で作業できるようにすることです。前提として、エンジニア3名はどういう役割分担だったのでしょう？
ぺんぎん まず私は、サーバーサイドの通常の機能や共通ロジックを担当しました。別の1人は仕様の調整に強く、かつLINE本体側のプラットフォームとの連携について知見がありました。
もう1人のエンジニアが証券の価格に関する機能を専任し、情報ベンダーから価格情報をリアルタイムで取得するロジックを担当していました。
和田 並列に開発してスピードを求めるには、あるエンジニアが作業している影響をなるべく他のエンジニアが受けないように、データのやり取りなどに工夫が必要です。非同期でのやりとりを前提にとして疎結合のアーキテクチャにしておくことなどがその一例ですね。
ぺんぎん 価格情報についてはそういった工夫をしていました。データをRedisに格納する際のフォーマットを、価格を担当するエンジニアが事前に定義し、かつ共通ライブラリを準備してくれました。価格に関する機能を扱うときには、そのライブラリを用いるだけでよくなっていました。
和田 事業を高速で立ち上げるための知見ですね。なかなか表に出てこない情報ですが、技術的に面白く、エンジニアとしてはぜひ知りたいノウハウだと思います。
▼LINEのFintech事業ではプロマネ・シニアを募集中！
金融のため型安全性で優れるTypeScriptを中心に技術を選定
── 続いてフロントエンドの話を伺いたいと思います。どういった技術を選定しているかお聞かせください。
鈴木 フロントエンドの大きな特徴として、TypeScriptとReactを採用していることが挙げられます。LINEではVue.jsを用いる事業部が比較的多いのですが、ここではReactを選択しました。
これは「どちらの機能が優れているか」という意図ではなかったと当時の担当者からは聞いていますが、選定したのは2年以上前で、その頃はVue.jsよりReactの方がTypeScriptとの相性がよかったことは大きいようです。
和田 2年以上前なら、明らかにReactの方がTypeScriptとの親和性は高かったですね。
鈴木 TypeScriptの存在は、他の技術選定にも影響しています。金融を扱う性質上、型安全性を担保して品質を向上させてくれるTypeScriptのニーズは大きかったので。
── フロントエンド関連では、webpackやBabelなどはいかがでしょうか？
鈴木 どちらも採用しています。特にBabelはかなりヘビーユースしており、私の所属するチームでは独自のBabelプラグインも開発しています。
前多 この機会に私からも聞いておきたいことがあります。ステート管理においてReduxを採用していない理由と、ある時期からReact HooksやRecoilを使うようになった理由をぜひ語ってもらえますか。
鈴木 基本的に、私たちが扱うFintech領域サービスでは、大部分のステートが画面内で完結しており、画面をまたいで保持されるステートはほぼありません。そのため、Reduxのように大がかりなステート管理の仕組みは不要であり、各画面をつかさどるコンポーネント単位でステートを扱えば十分だと考えました。
React Hooksについては、正式リリースが2019年2月で、フロントエンドの開発が始まった当初はまだ登場していませんでした。リリース後に、よりモダンな開発環境にしていくため私からメンバーに推奨し、新規開発するサービスに対して積極的に導入していったという経緯があります。Recoilは、React Hooksとの相性のよさなどを理由に導入を進めました。
和田 近年のReact界隈は、各コンポーネントが各々でステートを管理する流れにシフトしてきているようです。LINEのFintech事業では、最初からそれに近い形式でステート管理してきた結果、後に登場したReact Hooksとの親和性も高かったのかもしれませんね。
フロントエンド領域の進化にできる限り追随していきたい
── コードの品質を向上させるために取り組んでいることはありますか？
鈴木 TypeScriptによる型付けをより厳密にする試みを進めています。TypeScriptで型定義のない変数は、暗黙的にany型になります。そして、any型がある場合にコンパイルエラーにするnoImplicitAnyというコンパイラオプションがあります。
初期の「LINE証券」では、このオプションをオフにしたまま開発を進めてしまっていたのですが、TypeScriptを活用して品質を向上させるには、このオプションを有効化した方がいいわけです。そこで、1年半かけて既存コードをリファクタリングし、全ての変数に対して型定義をしていきました。
Type safety initiatives for LINE Securities front-end - Speaker Deck（LINE DEVELOPER DAY 2020より）この取り組みの詳細は、2020年11月25日から27日にかけてオンラインで開催された技術カンファレンスLINE DEVELOPER DAY 2020において「LINE証券フロントエンドにおける型安全性への取り組み」というセッションで発表されました（上記の発表資料参照）。
LINE DEVELOPER DAY 2020では、LINEエンジニアや外部ゲストなど多彩な登壇者による150以上ものセッションで、最先端の技術関連情報が発表されています。
── モバイル向けアプリのユーザーインターフェースならではの工夫は何でしょう。
鈴木 フロントエンドエンジニアは画面の“動き”に関する知見を持っているので、インタラクションについて自発的に案を出して、より優れたUIに改善していくことが重要な役割だと考えています。
LINEのFintech事業ではフロントエンドエンジニアと、プランナー、デザイナーの役割が明確に分かれていて、基本的に私たちがデザインに直接関与することはありません。この方針は自分の担当領域に集中できる利点がある一方で、プランナーやデザイナーは基本的に画面単位や機能単位でアイデアを考えるため、インタラクションに関する提案が出づらいという欠点がありますから。
── 具体的にインタラクションで工夫した事例はあるでしょうか？
鈴木 例えば「LINE証券」のアプリでは、ボタンを何か押したときにローディングのアニメーションが表示される画面があります。プランナーやデザイナーからは「ローディング画像をアニメーションさせてほしい」という指定が出ますが、具体的にどんな動きをさせるかをディレクションするのはまた別の話です。
すぐにローディングの画像が出た方がよいのか？ フェードアウトやフェードインを挟み込むべきなのか？ 挟むならば、どれくらいの時間でフェードすべきなのか？
フロントエンドエンジニアが実際にアニメーション用のコードを書いて、どのような動きをさせるべきかを提案してきました。
── フロントエンジニアならではの施策ですね。ところで、フロントエンド領域は技術の進歩が早いことも特徴です。進化に可能な限り追随する、距離を取るなど対応方針は各社さまざまですが、どのような方針を選択していますか？
鈴木 可能な限り、フロントエンド領域の進化についていきたいと思っています。理由はシンプルで、新しい技術というのは既存技術の課題を解決するために登場するので、多くの場合は新しい技術の方が優れているからです。開発効率やプログラムの品質を向上させるには、新しいものを積極的に採用する姿勢が大切になります。
とはいえ、「LINE証券」では事業特性上、アプリに影響するような変更があれば徹底的にQAをして品質を保証することが求められるため、 新しいライブラリの導入や依存ライブラリのバージョンアップがなかなかできないという制約があります。使用する技術はなるべく固定化しておく方がいいからです。
そのため「可能な限り進化に追従する」方針は、基本的にFintech領域の新規プロジェクトや新しいモジュールに対して適用させていくことが多いですね。新規開発は新技術導入のチャンスだととらえて、なるべく積極的に技術を取り入れる方針を大切にしています。
▼LINEのFintech事業ではフロント・アプリ系エンジニアを募集中！
安全対策基準に則ったマイクロサービス基盤をコンテナで構築
── 11月末に開催された「LINE DEVELOPER DAY 2020」で、前多さんは「LINE証券を支えるマイクロサービス基盤の開発」というセッションに登壇されました。なぜマイクロサービス基盤を整備しようと思われたのでしょうか？
前多 前提として、金融を扱うシステムはFISC（金融情報システムセンター）による安全対策基準を満たす必要があります。他のサービスからは分離された筐体を使うこと、施錠できるラックを用いること、施錠できないならばネットワークを他のサービスからは分離して運用することといった項目が明記されています。
LINEには、OpenStackをベースとしたVerdaというプライベートクラウドがあるのですが、これではFISCの要件を満たすことができませんでした。かといって、独立したネットワーク空間にもう1つプライベートクラウドを立てることも難しい。
そこで、オンプレミスのサーバーを使う方針になりましたが、イチから構築するのは大変な作業です。当初は本番環境のサーバーをセットアップするのに、熟練のエンジニアが2〜3週間かけているような状態でした。
── かなり骨の折れる作業ですね。
前多 はい。できればエンジニアは、サービス開発だけに集中できる状態にしたい。そのためアプリケーションをデプロイするインフラ基盤を構築して、インフラ環境の構築をより省力化・効率化したいというニーズが生じていました。
また、Fintech事業が成長してサービスの種類が増えてきたこともあります。事業の特性から、「LINE証券」はそれほど頻繁にリリースできないという制約がありました。他のサービスまでこのリリースサイクルに引っ張られてしまうと、事業としての成長速度が鈍化してしまうでしょう。
さらに、特定のサービスで起きたトラブルが、他のサービスに波及することも避けたい。各サービスの独立性を向上させ、障害影響を局所化したいと考えるようになりました。
こういった理由から、マイクロサービス化を推進するようになり、オンプレミスなインフラの上にDockerコンテナクラスタによるマイクロサービス基盤を構築しています。
── どのようなオーケストレーションツールでコンテナを動かしていますか？
前多 HashiCorp社が提供するConsulやNomad、Lyft社が中心で開発しているEnvoyといったオープンソースソフトウェアを活用しています。Consulはサービスディスカバリ機能を持つツールで、Nomadは動的なコンテナのデプロイを支援するツール、Envoyはサービスメッシュの制御に特化したプロキシサーバーです。
Developing microservice infrastructure for LINE Securities（LINE DEVELOPER DAY 2020より）最初はKubernetesを使うことも検討されましたが、基盤の構築に携わるメンバーは少人数だったため、運用コストの高さからKubernetesの利用は現実的ではないと判断しました。それよりも、小さな部品を組み合わせてコンテナ基盤を構築すべきだろうと考えたのです。結果として、Amazon ECSのようなものができました。
さらにいえば、Fintech領域では障害の調査可能性を向上させることが求められるため、何かあればソースを見たり、サーバーにログインして原因を調べたりできるなど、コントロール可能な部分を多く残すことも重視しています。
非機能要件を担う共通基盤としてインフラ基盤を整備
前多 先ほどお話ししたマイクロサービス基盤は、単にサーバーリソースを提供するだけではありません。サービスに求められる非機能要件も、可能な限り基盤側で吸収するという思想で設計されています。
例えばログに関しては、アプリケーションから標準出力しておけば基盤側で適切にハンドリングしてくれますし、全サービスのメトリクス取得や分散トレーシングを横断的にできる仕組みなども備えています。
和田 非機能要件に関する部分をまるまる基盤側が引き受けてくれるのは大きいですね。アプリケーションの共通基盤があると、エンジニアは機能を実装するときに、システムの核になるアプリケーションロジックだけを意識すればよくなる。事業を大きくしていく上でこうした仕組みを整備していくことは必須要件だと感じます。
前多 そういえばちょうど今朝（インタビュー実施日の朝）、ぺんぎんさんから共通ライブラリのプルリクエストが発行されていました。
── それはどのような内容のコード修正ですか？
前多 Fintech領域はユーザーの重要な個人情報を扱うことも多いので、データの内容をログに出力する際に、特定項目をマスキングする必要があります。マスキング処理を各エンジニアが個別に実装するのはさすがに筋が悪いですから、特定のデータ型とアノテーションを用いることで、マスキング処理を自動的に適用させるよう修正されていました。
それ以外でもアプリケーション共通基盤の整備に、ぺんぎんさんはかなり尽力しています。
ぺんぎん アプリケーションを書くときは可能な限りビジネスロジックだけを書けばいい状態にし、それ以外はアプリケーションの共通基盤で吸収するのがよいと思っています。これはFintech領域だけでなく、他領域のシステムを開発する場合でも同じですね。
── 共通基盤を構築することに対するモチベーションが高いですね。
ぺんぎん 私は前職がSIerで、基盤チームに長くいたのですが、当時の上長が 「たとえ1週間で1画面しか開発できない状況でも、100人いれば1週間で100画面作れる」と言っていたのが印象に残っています。
この意味は、チームのメンバーがエキスパートであることを期待するのではなく、仮にスキルが未熟なエンジニアがたくさんいてもプロジェクトが円滑に進められるような仕組みを整備しておくべきということです。
LINEには優秀なエンジニアが多いので、細かい仕組みまで整備しなくても問題ないケースが多いのですが、共通基盤でまかなえる部分はなるべくサポートするというスタンスに変わりはありません。
和田 採用するプログラミング言語が少ない（今回はJavaとKotlin）ことも、共通基盤を整備する上ではうまく機能しますね。共通基盤となるライブラリやフレームワークができれば、スムーズにシステム全体へと波及させられます。言語が多い場合は、非機能要件を各言語で個別に対応していかなければなりません。
▼LINEのFintech事業ではインフラエンジニアを募集中！
Fintech領域ならではのチャレンジに醍醐味がある
── 開発チームまたはエンジニア個人として、今後実現したいことは何でしょうか。
ぺんぎん いくつもありますが、基本的には今後もアプリケーション開発基盤を全体的に整備していきたいです。
実施したいことのひとつに、テスト環境の改善があります。テスト環境を大量に増やせないことがQA作業のボトルネックになるケースがあるため、テスト環境をより容易に増やせるような仕組みを構築できたらよいなと。
さらに、インテグレーションテストの自動化も推進していきたいと考えています。現在は、QAチームで検証している内容のかなりの部分が、リグレッションテストに費やされています。今後はテストの開始時に、環境を構築したらデータをロードして、インテグレーションテストを自動的に走らせるような状態まで持っていきたいですね。
BFF（Backends For Frontends）の整備も進めていきたいと考えています。現在はBFFの環境が最適化されておらず、本当は1回で良いはずのAPI呼び出しを複数回行っていたり、その影響で呼び出し元のロジックが煩雑になっていたりという課題が生じています。その状況を改善していきたいです。
さらに、マイクロサービス化が進んでAPIベースでのやりとりが増えてくると、APIの後方互換性を意識する必要が生じてきます。各エンジニアが後方互換性に注意しながら開発・運用するのは疲れてしまうので、何かしら仕組みで解決できるようにしていきたいですね。
── 前多さんはいかがでしょうか？
前多 立ち上げ当初はエンジニアが3名だったという話がありましたが、現在は事業が成長してエンジニア30〜40名くらいの規模になってきました。設計思想やマインドを全員に浸透させる方法を考えなければ、チームとして機能させるのが難しいフェーズに入ってきたと感じています。今後は組織改革やチームビルディングを頑張っていきたいですね。
また、何かの課題が生じた際にスキルの高いエンジニアの個人技に頼って解決していては、組織としてスケールしなくなってしまいます。チームのどんなメンバーでも対応できるように、ナレッジの共有や仕組みづくりを行っていきたいです。
── 鈴木さんからもお願いします。
鈴木 今後はフロントエンドが対応できる領域をより拡大していきたいですね。例えば、ぺんぎんさんがおっしゃっていたBFFに自分たちで対応するのも、そのひとつだと思います。
それから、個人的にはキャッシュの活用をより最適化していきたいです。「LINE証券」では現在、大きく分けて2種類のキャッシュがあります。ひとつはCDNに静的なJS、CSSファイルなどを置いておくもの、もうひとつはRedisにサーバーサイドのレスポンスなどを保持しておくものです。
この適応領域をさらに広げることで、サーバーサイドの負荷をより軽減でき、アプリの利便性そのものも向上させられると考えています。例えば、本当はサーバーサイドのRedisに乗せる必要すらなく、フロントエンド側でうまくその情報をハンドリングできるかもしれない。従来のフロントエンド領域を超えた設計ができたらいいですね。
和田 面白いですね。キャッシュに乗せる情報のリッチさと、データ鮮度のバランスをどう取るか。高速さと正確性という本来は矛盾しそうな要素を、Webのインフラの特性を生かして両立させていくのは非常に難しい設計であり、かつ面白い部分です。
── とてもチャレンジングですね。最後にエンジニアがLINEのFintech事業に挑戦する意義についてアピールしていただけますか。
ぺんぎん 金融領域にはWeb系とは異なる文化や常識があると感じています。セキュリティに関する要件などがその一例で、そうした要素が設計や開発にも影響してきます。金融領域で求められる要件とWeb系の良い部分を組み合わせて、どうやってシナジーを生み出していくか。その達成方法を考えることはエンジニアにとってやりがいがあり、かつ優秀な方が力を発揮できる領域だともいえます。
前多 金融を扱う仕事は、世の中の流れがシステムにダイレクトに反映されるので面白いです。例えば日本で首相が交代したり、海外での新型コロナウイルスの特効薬が開発されたニュースが流れたりすると、「LINE証券」へのアクセスも爆発的に増えます。
さらに、今回のインタビューでもあったようにインフラからアプリケーションまでかなり幅広い領域を扱っていますから、エンジニアとしての総合的なスキルを身に付けたい方は、ぜひ一緒に働いていただけるとうれしいです。
鈴木 お話ししたように、Fintech領域にはプログラミング言語やライブラリのバージョンアップに制約があり、かつリリースサイクルも長いという特徴があります。一方でフロントエンド領域は技術の移り変わりが早いです。
この2つは相反する部分があるため、各種の制約をクリアしながら新しい技術を貪欲に取り入れ、ベストな状態でプロダクトを開発していく必要があります。これがFintech領域ならではのフロントエンドエンジニアのやりがいでしょうか。各種の制約があるなかで設計することや、実現が難しそうなテーマにチャレンジするのが好きな方にとっては、Fintech領域は間違いなく面白いはずです。
▼LINEのFintech事業で募集中のエンジニアポジションはこちら！
- プロジェクトマネージャー / 技術 / 銀行事業 / LINE Fintech
- シニアサーバーサイドエンジニア / 銀行 / Fintech Company
- サーバーサイドエンジニア / 証券・銀行・LINE Pay / Fintech Company
- インフラエンジニア / SRE / Fintech
- アプリケーションエンジニア / SRE / Fintech
- フロントエンドエンジニア / 証券・銀行 / LINE Financial
- クライアントエンジニア / 証券・銀行 / LINE Financial
ご応募お待ちしております！
【関連】LINEが改善に取り組む「出前館」のストーリーはこちら▼
老舗ITサービスのモダナイズに取り組みはじめたLINEエンジニアたちの挑戦！ 出前館の改善について和田卓人さんが聞いた - はてなニュース
[SponsoredContent] 企画・制作：はてな
取材・構成：中薗 昴
イラスト：いらすとや
