2018年に行われたFLEXY主催のCTOmeetupでも好評だった、JavaScriptテーマ。 今回もフロントエンドのプロフェッショナルな方々に、とことんJavaScriptについて語っていただきました。

2019年の今、最前線で技術を研鑽し続けるエンジニアはJavaScriptの現在や未来をどう見ているのか。

フレームワークの選定基準や、フロントエンドエンジニアに求められる資質、採用手法なども網羅しています。

フレームワークの選定基準

開発におけるAngular、React、Vue.jsの位置付け

井原　正博さん（以下、井原）：前半のテーマはJavaScriptの未来、そしてフレームワークについてです。 まずは今後どのようなフレームワークを検討、検証していくべきかディスカッションしていきたいと思います。林さんいかがでしょうか。

林　優一さん（以下、林）：フレームワークの経験で言うと、AngularとReactで実際にプロダクトを作成したことがあります。Vue.jsは技術顧問の知識として知っている感じですね。 これら3つのフレームワークを比べてみると、内容に大きな差があります。 Angularはフルスタックなフレームワークですが、ReactとVue.jsはそれぞれライブラリという形で存在していて、ほかのツールとの総合的な組み合わせでフレームワークとして機能させるものとして捉えられます。 ですからAngularはある程度エンジニアの人数が多く、大規模な開発の場合に採用することが多いです。最近ではSI系や海外のオフショアに投げるケースにおいて、Angularのドキュメントの充実具合やレビューのしやすさなどが重宝されますね。学習コストは高いものの、共有コストは安いです。 スタートアップ企業などの場合は、Vue.jsよりもReactを勧めています。私自身が得意だということもありますが、Vue.jsはやや先行き不透明です。

実際にはサービス内容に左右されるのでしょうが、今スタートするならReactかなと思いますね。

古川　陽介さん（以下、古川）：リクルートはメディアのアプリを作ることが多いので、よくReactを利用します。例えばSUUMOやホットペッパーグルメなんかは基本的に検索したものを見るサービスですが、それだけならReactで簡単に作れるんです。 JavaScriptエンジニアでReactを書いている人は多いので、後々人材が必要になったときに横展開しやすいというメリットもあります。人口が多い分ライブラリも多いですし、エコシステムも成熟していますから、その点もReactの採用ポイントになりますね。 一方で、フォームを設置するといったインタラクティブな動作が必要な場合はVue.jsやAngularの方が若干簡単かもしれません。そもそもReactはモデルをツーウェイでバインディングする考え方のフレームワークではありませんから。

菅原　孝則さん（以下、菅原）：うちは今Vue.jsですが、古川さんのおっしゃるとおりだと思います。 私の今の主な仕事はデザインシステムを作成してマネジメントすることです。 デザイン段階から開発のポイントを整理して実装で揃えるということなのですが、Vue.jsはここが弱いですね。 デザインシステムの作成はどんどん定数化していくノリに近いので、型が効かないのは結構やりづらいです。そういう意味ではReactやAngularが恋しいですよ。 果たして長期的な運用に耐えうるかという点もやはりもっと楽できる環境あるよという気分ではあります。最初の立ち上げ段階で長期的にコントロールしやすいものとしてReactを選べたら良いのかなとは思います。 ただ、Reactでは各ページをラフに機能させるというのにはちょっと冗長であるというのは確かだと思います。

菅原　孝則さん STUDIO株式会社 技術顧問 2001年に19歳でフリーランスのwebデザイナーとして、デザイン・ディレクションと並行してWPF, Flex, Ios,Android, OpenGL, 等を利用したデータビジュアライズ、サービス開発を行なってきました。2016年より株式会社ファームノートに入社し、現職、UIデザインを担当しつつ、webフロントエンドにVue.js、アプリ開発にReactNativeを導入した上でデザインシステムを構築しプロダクト全体のUIアーキテクチャの開発およびデザインを行なっている。

技術が流行するタイミングがフレームワークの採用を大きく左右する

井原：サービス規模や開発体制、どんなエンジニアがいるのかといった要素など、何かしらみなさんの中でフレームワークの選定基準はあるのでしょうか？

古川：基準を持って選んでいるときもあるとは思います。ただ当社の場合はWebアプリケーションを数多く作ってきているので、フレームワークを切り替えるタイミングが早いんですよ。 2014年頃にもjQueryに切り替えています。そのとき一番勢いがあったプロダクトで採用されたのが、たまたまReactだったんです。 Angularを飛ばして選ばれてしまっただけで、もう数年遅かったらVue.jsだったかもしれません。

井原：当社のサービスもjQueryで作っていて、次にどうしようと思ったときに使われだしていたのがReactでした。やはりタイミング次第でVue.jsだったかもしませんが、そう考えるとあまりフレームワークに選択肢はないのかもしれませんね。 ReactとVue.jsのどちらを選ぶかという基準はあるんですか？

古川：TypeScriptがきちんと使えるかどうかという部分はありますね。

菅原：Reactはエディターサポートがいいんですよ。Vue.jsは関数で色々合成する的な作りなので、エディターサポートをするのが苦しいっぽいです。

林：顧問として参画した企業ではVue.jsを採用しているところもあったのですが、そこはjQueryで作成したベースとなるプロダクトが既に存在していました。 Reactを入れようとするとrootを丸ごとアプリケーション化して、JSXにしなければならない状況に陥りがちです。 その点Vue.jsの良いところは、SPAとして使うエコシステム的な部分に加えて、既存アプリの一部だけをVue.jpで構築してバリエーションを作れることです。 検索フォームだけVue.jsで作成して、それ以外はサーバーサイドでレンダリングしたりもできます。 要するに、従来のjQueryやRuby On Railsなどで作成したプロダクトに対して後から差し込みやすいんです。 そういう基準でVue.jsを採用しているケースが一番多いと思いますね。 新規で開発するとなればフラットな技術選定になりますから、Reactの割合が多くなるはずです。

古川：Vue.jsはTypeScriptとの親和性がReactほど強くはないので、そこはそもそも型を用意したりはせず、とりあえず見た目を綺麗にするところから始めよう、という話が多い気がします。 一方でReactはTypeScriptで型を綺麗に整えたり、Storybookを書いたりする部分をしっかり進めようと考えて採用しているイメージです。大人数で開発しても影響が出ないようにするためですね。

林：Angular自体は良くも悪くもライブラリというよりは完全にフレームワークなのが大きいんですよね。途中から導入しようという場ではまず候補に挙がりません。 TypeScriptも必須ですし、書き方の問題もあります。Decoratorを知っている人も少ないのではないでしょうか。入門書を読んでも書いてありません。 その中で勉強していかなければならないのが、難易度の高い部分です。

林　優一さん 株式会社ZIKU Technologiesフロントエンド開発担当者執行役員/UXエンジニア 株式会社Emotion Tech プロダクトアドバイザー 株式会社GIG プロダクトアドバイザー UXエンジニア/フロントエンドエンジニア 複数のIT企業にてエンジニア、部長、CTO、プロダクトマネージャー、VPoEなどを歴任。 現在はフリーランスとして顧問業の他、UXを意識したフロントエンド開発を担当。 細かなUXにも配慮したサービス開発が得意。

JavaScriptの未来について語る

ドラスティックな変化が望めないからこそ、周辺のツールチェーンが進化する

井原：次のテーマに移りたいと思います。JavaScriptの未来について、ReactもVue.jsも20年後にあるかと言えばそうではないですよね。

古川：そもそも20年続く技術が無いのでそこは考えすぎなくていいと思います。

菅原：TCP/IPなんかは長いですけどね。

井原：先程TypeScriptの話もでましたが、その当たりも含めて今後JavaScriptはどうなっていくと思いますか？

古川：JavaScriptの仕様や規格を決めている団体があるのですが、基本的にその人たちが毎年JavaScriptをアップデートして、新機能を追加しています。 ブラウザやWebアプリケーションを作っている人たちがJavaScriptが今後どうあるべきかを議論して、共通理解を深めながら民主的に決めていくんです。これはJavaScriptならではの特徴ですね。 RubyやPythonなんかは一人の人が「こうだ」と決めてしまいますから。 JavaScriptはコンセンサスを得ながら進んできたんです。もちろんそれは良い面があるものの、ドラスティックな変化は望めません。変化に時間がかかります。 私が数年前に JavaScript の仕様を決めているエンジニアに対して、「型って JavaScript に入れないんですか？」と聞いたことがあるのですが、非常に渋い顔をされました。 そんなことは10年以上議論してきて、尚決められていない。それをぽっと出てきた TypeScript のような型がある言語を仕様に入れようみたいな話をされても難しいという反応だったんです。 数年先程度の未来では、 JavaScript に TypeScript のような型は入らないでしょうね。 JavaScript そのものが変わるというよりは周辺のツールチェインが変わっていくのではないかと思います。

菅原：私の中ではもうJavaScriptはアセンブラ言語みたいな感じになっています。

古川：アセンブラがどんどん進化している感じですよね（笑）。

古川　陽介さん 株式会社リクルートテクノロジーズ・グループマネージャー 大学卒業後、2007年4月に富士ゼロックス株式会社へ入社、その後、株式会社DeNAにて勤務。現在、株式会社リクルートテクノロジーズでグループマネージャーとして活躍中。Japan Node.js Association 代表理事、 リクルートテクノロジーズ所属。「Node学園祭」の主催者。Node.jsコラボレーター、HTML5 experts、 Node.js official evangelist としても活動している｡

いずれはTypeScriptが主流になる未来が予想される理由

古川：今、JavaScriptユーザーの40％ほどはTypeScriptを書いているという調査結果があります。 TypeScriptに勢いがあるということなのですが、恐らく数年後にはさらにスタンダードになっていると思います。

井原：やはり型が欲しい感じですか？

菅原：欲しいです。コードヒントが出てきたり、間違った代入をしたら違うと言ってくれるのであればあろうがなかろうがどちらでもいいのですが、今はその手段が型なんです。 型を書かなくても機械学習で良い塩梅にしてくれればいいのですが、まだもう少し待たないといけないようです。

古川：Vue.jsは型がなくても気軽に書けるので、それはそれで一つの価値なのかなとは思います。 全体的にソフトウェア開発が多人数になっている点もありますよね。だから型が欲しい。

林：それは一番大きい理由だと思います。一つのプロダクトに対してフロントエンドが何名か必要となれば、型やドキュメントをしっかり書かなければならないんです。 最近の開発だと先に型定義作ることもあります。サーバーサイドの人とJSONスキーマをもとに会話をして、お互いこの規約で作りましょうと決めるんです。

古川：うちもそれは以前からやっていますね。Consumer Driven Contractのような感じです。 普通はサーバーサイドがAPIを作るんですが、フロント側がAPIを定義します。

林：フロント側からこういう型が欲しいと先に言っておくんですね。 デザインが先にあって、それを作るためのデータ構造を考えてからサーバーサイドに依頼をするという感じですよね。

井原：結局型が必要かという問題は、ソフトウェアに関わらずドキュメントや仕様書などの共通のコンテキストを作ってみんなで理解しようね、ということなんですよね。 型情報はソースコードに対するメタ情報の一つであって、エンジニア同士の理解のためにはそれが必要だということです。

古川：少し補足すると、そもそも多人数で開発しなければならないのは画面が複雑になってきているからです。 例えばSUUMOの検索ボックス一つにしても、チェックボックスやサジェスト、検索件数の話が出てきますから、全てを一人でやろうとするのは無理な話なんです。

井原：もともとは型がなくても良かったんですよね。それに対して今は世界が複雑になってきているわけですから、そこに対して何をしていかなければならないのか、ということだと思います。

ファシリテーター　井原　正博さん 株式会社ビットジャーニー 代表取締役。ヤフー株式会社にて開発部長を務めたのち、 2010年1月よりクックパッド株式会社の技術部長として技術力の向上やエンジニアの採用に従事、 今日にいたる基礎をつくりあげる。2015年1月、株式会社ビットジャーニーを設立し、 個人の発信を組織の力にする情報共有ツール『Kibela』を開発中。 エンジニアを中心とする組織づくりに関する知見や経験を活かしたいという思いから、複数社の技術顧問を務める。

今後活躍するフロントエンドエンジニアの要件とは

林：そういう意味では、TypeScriptをやっていて絶対に損はしないんですよね。もちろん10年後はわかりませんが、今から勉強をスタートするのであれば、必須と言ってもいいと思います。 フレームワークの使い方なんかはいくらでも無料のドキュメントが手に入る時代ですから、エンジニアによって差は生まれづらいんです。全員できて当たり前になっている。プラスアルファでできることがあるとすれば、やはり設計力が大事になる気がします。

井原：設計力を身につけるために今後しようと思うことはありますか？

林：オープンソースでGitHubにライブラリをたくさん出すことでしょうか。 利用者から使いづらい点や不具合を指摘してもらって直したり、ほかのライブラリのコードを調べてベストプラクティスを探ればいろいろと学べます。

井原：自分からフィードバックをもらえる状態に身を置くということですね。菅原さんはいかがですか？

菅原：TypeScriptはもうデファクトだと思いますよ。JavaScriptはアセンブラだと思っていますし、フレームワーク的にどうこうという話は私としてはあまりありません。 どちらかといえば、状態管理を含めたアプリケーションのアーキテクチャ設計の方が、エンジニアリングとしては重視すべき点かなと思っています。 そういう意味ではやはり自分でフレームワークを組むのが一番勉強になるのではないでしょうか。メンバーに作ってもらってもいいですしね。 車輪の再発明と言われるかもしれませんが、それをあえてやる機会が成長のためには有用だと思います。

井原：古川さんはどうですか？

古川：先程画面が複雑になっているという話をしましたが、一方で方法論はコモディティ化していると思うんです。 ReactでもVue.jsでもAngularでも何でもいいんですが、これらのツールで何かを作ることは普通のことで、できないとすればフロントエンドエンジニアとして致命的なんです。 その上で必要なことは、個々人が軸を持つことだと思います。パフォーマンスにこだわっているといったことでも何でもいいんですが、いわゆる非機能要件を満たせるようなフロントエンドエンジニアが、今後活躍していくのではないでしょうか。そこもできないとなれば、設計力が試されます。

後編に続きます＞＞