2018年9月10日、JavaScriptをテーマにしたイベント「CTO meetup JavaScript～進化し続ける技術について～」が開催されました。各企業でコンサルタントや技術顧問、エンジニアとして活躍するJavaScriptのエキスパートの方々を登壇者として迎え、前半はどのように技術選定を行っているのか、現在の技術の課題解決方法を始めとした技術に関する話題を。後半は現場が求めるフロントエンドエンジニアについてなど、人材に関するトークをメインに語っていただきました。

「CTO meetup JavaScript～進化し続ける技術について～」

登壇者情報

モデレータ

技術の流れが速い中、どうやって技術選定をしている？

案件のスピード感や企業規模によって異なる技術選定基準

小林：フロントエンドにはさまざまなトピックがありますが、今回はJavaScriptを中心にディスカッションしていきたいと思っていますので、よろしくお願いします。 まずは現在の技術の流れが速い中で、みなさんがどのように技術選定をしているのかというテーマですが、簡単に今までどのような技術を使ってきたのか、その選定基準などを教えていただければと思います。

林：管理画面系のフラットアプリケーションの構築にAngularを採用しました。いろいろな選択肢がある状態だったのですが、迷っているだけの時間がなかったことと、Angularに詳しいメンバーが多かったという要素が採用の大きな理由です。

古川：僕の場合は3年前に開発を始めた案件でReactを採用しましたが、完全にタイミングでした。 まず、リクルートテクノロジーズというある程度大きな企業の中では、新しすぎるものは採用し辛いという前提があります。それが下火になってしまったときに、技術者に影響を与えてしまいますから。3年前の時点では、Reactは徐々にコミュニティに火がついて加速し始めているような状態でした。2年ほど前にはかなり主流になってきていたので、「このままいきましょう」ということになり、Reactを使い続けて今に至っています。 当時はReduxも主流になってきていましたし、その前ならjQueryがかなり多かったのですが、今後採用するには懸念点が残るだろうという結論でした。現実路線プラス、「少し新しいものを」という部分でReactを選び、それがたまたまうまくいったという感じです。とはいえ、そろそろ新陳代謝の時期かもしれません。

菅原：株式会社ファームノートに入社したのが2年前で、そのときにbackboneとbaseで7.2メガくらいのJSが入りました。しかし、閉じたりはちゃんとできるけれど、崩れてしまうという状況で、、にもかかわらずそれを運用しなければならないため、コンポーネントベースで作っていこうと考え、差し込みやすかったVueを採用するところからデザインシステムを開始しました。 その後、一ヶ月でAndroidとiOS両方でアプリを出すというオーダーがあり、今度はReactを採用しました。とはいえ、当時ReduxやReact界隈のセオリーは全くわかりませんでしたね。ただ、これまで利用していたVuexというVueの標準サーバーがMobXを参考に同じ設計意図で制作されていたことを知って、とりあえずReactはMobXを用いて運用することになりました。

技術がプロダクトにマッチするかどうかの見極め方法は多種多様

小林：新しい技術が登場したときは一度試験的に手を動かして作ってみるとは思うのですが、実際にそれがプロダクションの開発に使用できるかどうかはどのように判定しますか？

林：一つ基準として見ているのは、サードパーティ製のライブラリの数です。僕はスタートアップ企業に関わることが多いので、これから立ち上げ、またはサービス開発の途中というフェーズにおいては「サービスをいかに早くローンチさせるか？」が最も重要なポイントになります。その場合、サードパーティのライブラリに頼りながらいかに早くいいものを作るか、という勝負になるので、サードパーティでもライブラリが揃っていないと使えませんね。

古川：弊社の場合は、ある程度の規模を想定して一度作ってしまいますね。ReactやReduxを採用したときも、ホットペーパービューティーを想定して、それ相当の機能を持ったWebアプリケーションを最初に作りました。そこで過不足を見極めながら判断をします。 それから、全く話にも上がってこないような技術を標準にしようとは思わないですね。ある程度みんなが使っている雰囲気は日本のQiitaでよく書かれているかどうかなどでもわかるので、そのあたりは重視しているかもしれません。

菅原：僕はとりあえず入れてみますね。組織のサイズにもよりますけど、そういうことができる組織であれば、まずはやってみます。 あとはエディターなどの書き心地や、サポートとの組み合わせは結構見ています。Vueは昔よりはマシになってきましたが、そのあたりの対応はReactと比べると全く進んでいませんから。 小林：現在のフロントエンドエンジニアというくくりを見ると、サーバーサイドをやっていてフロントは少しだけ…という人もいれば、デザインをメインにしていてフロントエンドはJSを少しやっていただけ、という人もいる。チーム構成によって技術選定は変わってくると思いますが、その点はいかがですか？

古川：無関係になることは基本的に無いですね。ReactなのかVueなのかAngularなのかは些細な問題で、組織の中のメンバーの中にどういう人がいるのか、という話で最終的には決まってくるところだと思います。

菅原：僕も同意見ですね。メンバーのスキル構成に合わせてセレクトは変えていく必要があります。

現在の技術における課題とその解決方法は？

技術継承が上手くできていない、技術の進化スピードが早すぎるという問題

小林：技術における課題と解決方法について。これは直訳するとみなさんの辛さを語る時間かなという気がしますが…(笑)。どうでしょうか？

林：自分が辛いということはあまりありませんが、フリーランスで技術顧問をやっていると、JavaScriptやフロントエンドまわりで相談に乗ってほしいという依頼がたくさん来ます。その中で一番多いのは、メインのエンジニアが抜けてしまって引き継ぎや技術継承ができていない、という相談です。その次はパフォーマンスが悪かったりバグが多いなど、構造に関わる問題などですね。

小林：前任者が辞めてしまった、というケースはどのように解決するのでしょうか？

林：僕が見られる場合は見ますが、そうでない場合は今いるメンバーにどう業務内容を共有するのか、という部分のアドバイスになりますね。ノウハウのキャッチアップ方法などを基本的にお伝えして、必要であれば面談をしたり一緒に食事をしたりして、方法論だけでなくモチベーションを上向きにする、といったこともします。

古川：僕の場合、Reactの各エコシステムのライフサイクルが短すぎるのが辛いですね。アップデートが早すぎる。今までは年に1回のリファクタリングでよかったものが、半年に１回になっている雰囲気です。付き合えない会社は辞めていってしまうのでは、という懸念があります。

小林：逆に技術が進化し続けている、と言うこともできますね。ずっと変わらないJQueryがいいのかというとそうではない。

古川：もちろんアップデートするからにはいいことがあると思うんですが、Reactに関して言えば、React周辺のエコシステム全ても同じスピードの進化と付き合わなければならなくなってきているので、そうなるとエコシステムを内製した方が早いんじゃないか、みたいなデメリットの方が大きく感じる。「これに毎年ついていけるの？」というのが、最初に言っていた新陳代謝のシーンかなと思う一つの要因でもあります。

菅原：しんどいところで言うとVueやReactか、という技術選定部分に関してはエンジニアの対応もどうにかなるのですが、その領域外の部分の対応が一つ課題です。例えばRechartsで単純に処理量が多いものを最適化しようとすると、仮想DOMが邪魔になることが間々あります。そこを素直に処理してくれるエンジニアはあまりいないんです。今は結果的に自分でやるか、ということになってしまう。

小林：Vueを入れたとしたら、Vue以外のところをガリガリやってくれる人がなかなかいない、ということでしょうか？

菅原：はい。主に描画処理系の部分をやってくれる人材は貴重ですね。

これからのフロントエンドのトレンドや動向は？

Web ComponentsやPWA（Progressive Web Apps）などの新技術に対するエンジニアの見方

小林：では次はフロントエンドの未来予測に関する話題です。例えば最近はコンポーネント志向と言われていて、当然その延長線上としてWeb Componentsに夢を見る方も多いと思うのですが、いかがでしょうか。

古川：僕は夢を見てはいないんですが（笑）、正直パフォーマンスなどを考えるとWeb Componentsがすごく流行るという未来は見えないですね。

林：ReactベースだとCSSとかの挿入は、styled-componentsとかstyled-jsxなどを使う。AngularだとCSSを中に入れるとそのcomponentsだけに該当するCSSみたいな形になるんですけど、そういった意味で見ると、Web Componentsがなくてもやろうと思えばできる部分なんです。 Web Componentsがあることでそれらのフィールドが不要になるという手軽さはあると思うのですが、それが技術的に根本的な意味の革新的をもたらしたり、ビジネスにとってプラスになるかと言われると、ちょっと疑問です。

小林：ではそのほかの技術に関してはどうでしょうか？

菅原：トレンドの話でいうとプロトタイピングツールのFramer Xというのが最近出ています。これはもともとコードはJSベースで作るFramerというツールがあって、それにXがついたものです。XはReactコンポーネントをデザインツール上に配置して組み合わせたりできるプロトタイピングツールです。触ってみたら意外と生産性が高くて、flashに近しい感覚がある。Framer Xでアウトプットまでいくかというといかないとは思うんですが、プロトタイピングの表現力が今後高まっていき実装もそれに付き合う必要が出てくれば、よりインタラクションにフォーカスした作り方が求められるようになるのではないでしょうか。Reactは正直インタラクションの作りは面白くないので、進化していってほしいですね。

古川：PWAについては、Service Workerなどを利用しています。ただ、オフラインでも見られるようになる、といったときにうれしいものとうれしくないものがありますよね。例えばホットペーパービューティーのような、予約できるかどうかを見たり、実際に予約ができないと意味が無いサービスがある。とはいえ、Service Workerなどのライトなレベルであれば、使ったほうが良いのは間違いなさそうです。 あと、これからのトレンドとして僕が期待しているものはGuess.jsというプラグインです。Googleアナリティクスのデータを利用したもので、「ユーザーがAというページを開いたら、次はBというページに行きやすい」というデータがあれば、Aページに来た瞬間にBページを先に読み込んでしまう。パフォーマンスは基本的に光の速さの壁は超えられない状態なのですが、それを超えるために先読みするというわけです。 現在は職人が勘と経験に基づいてService Workerなどを活用して先読みをしていると思うのですが、Guess.jsなども含めて光の壁を超えよう、という動きがさらに出てくると、さらにパフォーマンスを高められるのではと思います。機械学習などの知識も必要なので、自前でやろうとすると大変ではあるのですが。

林：未来に期待したいのは、僕が開発しているアバターを利用したWebミーティングツール「vmeets」で現在使用しているWebRTC。規格自体は結構前からあるもので、最近ようやく使えるレベルまできたというところがあります。最近はRealtimeDatabaseとかFirsbaseとかがそういった意味でこれからはかなりリアルタイム通信に近づいていく、あるいはそれが基本になると思います。 ReactやAngularやVueなどのSPAとリアルタイム通信はかなり親和性が高くて使いやすいですし、しばらくReactやSPAのテーマは続くと思います。WebRTCも、まだまだハマりどころはあるんじゃないでしょうか。

小林：僕自身は、2015年からここ数年あまり変化が無いなと感じていて、そろそろすごく大きな変化がどこからかくるのではと見ています。そういった意味ではデスクトップPWAは少し面白い。デスクトップアプリは今Electronくらししか作るものがないのですが、Electronまで必要ないものも結構あるので、そういったものはデスクトップPWAで作ると意外といいんじゃないかなと思う。すごく期待していますね。

今現場に最もほしいフロントエンドエンジニアとは？

アプリの開発、運用、エンハンス経験。さらに、プラスαの「何か」が必要

小林：では最後に人材に関するテーマです。「今現場に最もほしいフロントエンドエンジニア」とは？みなさんいかがでしょうか。

菅原：バックエンド主体でやっているフルスタックエンジニアと呼ばれる方々もいらっしゃいますが、CSSがいまいち書けないとか、フロント系がそんなに得意ではない、という方もいるわけです。そこを僕の中では「アーキテクチャを作るフロントエンドエンジニア」と「インタラクションを作るフロントエンドエンジニア」という分け方できっちり線引きしている。足りないのは、後者のエンジニアですね。 60fpsを崩さずにきっちり作ってくれる最適化の鬼のような人もいれば、単純に気持ちいいアニメーションを作ってくれる人もいるのですが、その中でもプロダクトの「触り心地」にコミットできるエンジニアがほしいな、と思います。

古川：僕が関わっているのはReactやVue、Angularというリッチなウェブアプリケーションを作る案件ではありますが、それだけに閉じずに、それをもとにそもそも何をやっているのかということをきちんと調べられる人だとうれしいですね。僕は採用をやっていますが、多いのは「アプリケーションを作ってみました」という人です。そのレベルだと判断しきれない。実際にアプリケーションを運用してどこに困ったのか、きちんとドラマとして語れる人がほしいんです。 例えばReactのアップデートが大変で、自分はどうしたかったのか、どう解決してきたのか、ということを語ってほしい。ただ開発をしただけではなく運用した、運用しただけではなくエンハンスも含めて行ったなど、深く入り込んでアプリケーションを作ってきたという経験値が重要です。

林：そういう意味では、現在は技術プラスαで何かを持っているということが流行なのかなと思います。マルチスタックエンジニアということですね。バックエンドとフロントエンドという技術一つひとつの話ではなくて、さっきのインタラクションで言うとデザインやUXなどの話もできること。さらに、マーケティングやビジネス的要素も含まれる。技術選定においてこういった作りにしよう、ここはあえて諦めようといった判断をするときに、技術プラスαの知識が求められているんじゃないでしょうか。特にスタートアップはそういう部分がかなり大きいですね。

「悩む時間」が若いエンジニアの技術力を磨くための経験になる

小林：フロントエンドエンジニアという領域おいてすべての分野を高レベルでこなせる人材はほとんどいないと思いますが、その上で今ほしい人材を想定すると、「なんでもいいから一歩突き抜けていてほしい」という感じになるのかもしれませんね。 では、例えばフロントエンドエンジニアになりたい若い子を採用したとして、そのときはどんなふうにアドバイスしますか？

菅原：まさに今月からエンジニアリングもデザインも知らない子と一緒に仕事を始めたのですが、その子にはまずデザインから教えています。その上でエンジニアリングを勉強せよと。自分でサービスデザインやアプリケーションデザインをするということは、プログラミング言語をキャンバスにするということです。画材をきちんと扱えないのに画家を気取ることはできないぞ、というスタンスではいながら、まずはデザインという目線から入ってもらっている感じです。

古川：新卒にも満たない若い子から「フロントエンドをやりたいんですがどうしたらいいんですか」という質問を受けたときに一番言っているのは、ReactでもVueでもAngularでも何でもいいから、何かアプリケーションを作ったほうがいい、ということですね。アプリを作ることで生まれる「自分ではこうしたいけどうまくいかなくて、どうしよう」と悩んでいる時間が技術力を育んでくれるので、そんな経験をしてほしいと思います。

林：僕も基本的に古川さんとあまり変わらないのですが、自分で作って人に見てもらうということが一番経験値になるかなと思います。それから、エンジニアはそもそも実際にコードを書いている時間よりも悩んでいる時間の方が長いかもしれないくらい「悩む時間」が多いので、これはとにかく経験した方がいいですね。

10月開催の【CTO meet up】と、flexyイベント告知

【CTOmeetup】あなたの会社のDevOps

●日時：2018年10月17日（水） 19:10〜21:40（開場18:40〜） ●内容：各会社毎にどうやってDevOpsを文化、プラクティス、ツールと言う観点で実現しているかについてパネルディスカッション形式でお話を伺っていきます。 リリースしてからがスタート。日々の改善活動や安定運用を行うため、開発（Development）と運用（Operations）が協力し合いながらビジネス要求に早くかつ柔軟に対応していくかが求められる昨今。 多くのサービスをリリースしている会社や大きくサービスや組織を伸ばした会社。また、その安定稼働を支えるツールを提供している会社の観点などからDevOpsを深掘りしていきます。