言語やフレームワーク、何を使ってる？

オープニングで参加者によく使う言語やアプリケーションフレームワーク、ライブラリなどについて訊ねたところ、Vue.jsが73名と約半数近く。次いでJavaScript、Reactが28名ずつ、jQueryが25名、AngularJSがとTypeScriptが10名ずつ、その他であった。

イベント冒頭では、ラクスル水島壮太氏、freee加藤慧氏、サイボウズ小林徹氏が、各人のキャリアならびに会社・サービス（プロダクト）の紹介が行われた。今回は、その後のパネルディスカッションと合わせてレポートする。

自社サービスではどのようなフロントエンド技術を使っているか

最初のテーマは、「自社サービスではどのようなフロントエンド技術を使っているか」。「変遷」「選定基準（新技術を使うことに対する見解）」ごとに分けて紹介していく。

▲freee株式会社 人事労務開発チームでエンジニアを務める加藤慧氏

【変換】

加藤：『人事労務freee』がローンチされたのが2013年の12月で、当時の名残と言いますか、そのとき流行っていた言語や環境をそのまま現在に至るまで使っている状況です。

ただ、それぞれの規模感は変わってきています。今ではJavaScriptが1000を超えていて、Sass（scss）が365、CoffeeScriptが275という状況ですが、私がfreeeに入社した2年半ぐらい前は、CoffeeScriptの方がJavaScriptよりも多く、600くらいありましたから。

【選定基準】

加藤：先ほどの話の繰り返しになりますが、その時々で流行っていた言語を取り入れてきました。言い方を変えれば、長いものには巻かれろ的な感覚です（笑）。新しいものを取り入れると、エンジニアも喜ぶことが多いですからね。Vue.jsを入れたのは、まさにそのような考えからです。

ただあまり多く使われていない、言ってみれば真新し過ぎる言語を使うと苦労することが多いので注意をするようにしています。新しくてもそこそこコミュニティのプラクティスが習熟していて、評価が高い。スターが多いものを採用するようにしています。

▲ラクスル株式会社 執行役員兼CPO（Chief Product Officer）の水島壮太氏

水島氏は、ラクスルのことだけではなく、これまでのキャリアにおけるフロントエンド技術の変遷についても言及したので併せて紹介する。

【変換】

水島：新卒でIBMに入ったころは、フロントエンドエンジニアという言葉はありませんでした。ただ僕自身は自らJavaScriptをゴリゴリ書いて、オリジナルのJSフレームワークのようなものをつくっていましたから、今でいうところのフロントエンドエンジニアのような動きをしていたと思います。

その後、転職したDeNAでは、Flashで動くガラケーのアニメーションをHTMLに変換し、ロースペックなAndroid上で高速再生させるライブラリーのメンテナンスに携わっていました。

Vue.jsが流行り始めたのは、DeNAに在籍していた時期の後半からですね。ラクスルに転職した当時は、モノリシックなレガシーアプリ部分にはjQueryが入っていた程度でしたが、その後新しい画面には部分的にVue.jsを入れていき、現在では全面的にVue.jsやnuxt.js等に加えてグラフィック、3D領域に強い、Fabric.jsやthree.jsも採用し始めています。

【選定基準】

水島：Vue.jsを入れたのは、僕がラクスルにジョインした頃の2017年です。変更しようと思った基準は、先にも言いましたが巨大で多機能化したモノリシックなシステムから、マイクロサービスほど小さくはありませんが、個々のドメイン毎にアプリケーションをきちっと分割しようとする動きがあったからです。そのタイミングで、一緒に言語も新しいものを採用しようと。Reactと悩みましたが、Vue.jsの方がプログレッシブフレームワークとして導入しやすいという判断で採用しました。

フロントエンド開発に限ったことではありませんが、既存システムを分割、切り出す。あるいは、新たなドメインを開発するなどのタイミングで、思い切って新しい開発環境にチャレンジすることは、大切なことだと考えています。

先ほど加藤さんがおっしゃられたとおり、新しいものを使った方がエンジニアの目が活き活きとする。プロダクトマネージャーである僕の立場としては、エンジニアのやる気はとても大事なので特に意識しているところでもあります（笑）。

一方で、新しいものを取り入れるデメリットもあります。ビジネスサイドの人たちがSPA（Single Page Application）の概念をあまり理解していないことです。これまでタグマネージャーを使えばできていたことができなくなったり。新しいサービスを追加しようと思ったときに問題が発生したり。ビジネスサイドと開発サイドの議論をしながら進める必要があると考えています。

▲サイボウズ株式会社 フロントエンドエキスパートチームの小林徹氏。株式会社SmartHRのフロントエンド技術顧問も務める

【変換】

小林：今回、モダンフロント勉強会というタイトルですが、当社の大きなプロダクトであるkintone、Garoonにおいては、ご覧のとおりです。一部Reactを使ったりしていますが、開発当初からほぼClosureとjQueryで開発してきましたから、モダンとは言えません（笑）。ただ別のプロダクトにおいてはReactやTypeScriptといった、割と最近の技術も使っています。

【選定基準】

小林：Kintoneの開発は2011年からですから、ReactやTypeScriptがまだない時代でした。kintoneはただのプロダクトではなく、ユーザーがkintoneプラットフォーム上でJavaScriptを書いてカスタマイズできるなど、大規模アプリケーションに成長すると予測していましたから、安全で信頼できる言語という基準でClosureを選定。いま振り返ってみても、この選択は間違っていなかったと思っています。

ガチガチなシステムにはなりましたが、反面、新しいものを入れることが難しいとの問題に最近は直面しています。そしてこの問題はGaroonの開発環境でも同じです。Garoonにおいても新しいライブラリなどはほぼ入れることなく、jQueryのみで開発してきています。

フロントエンド開発はReactの登場で大きく流れが変わったとは思いますが、それ以降の技術で、特に採用したいと思うものはありません。もちろん入れるメリットがあったり、適するプロダクトを開発するのであれば採用していくつもりですが。

採用基準は基本、プロダクトチームが自由に選定しています。ただ大規模・長期間になるプロダクトにおいては、先の2つのプロダクトと同様、安全・信頼の担保を会社としてもしっかりと確認するようにしています。

サービスのパフォーマンスを高めるためにしていること

水島：ラクスルのサービスは主にtoBであり、お客様に利用していただくピークの時間帯も平日の昼間です。そのためtoC向けサービスに比べるとトラフィックもそこまで集中しないため、正直、あまりパフォーマンスは意識していません。もちろんキャッシュはサーバーサイドでといった、当たり前の施策は行っていますが。

意識していることといえばUXです。サービスの特性上、多くのファイルをサーバーサイドで非同期処理することが多く、ユーザーが数分ほど待つ場面が生じます。その間、ユーザーが不快に感じないよう、フロントエンドエンジニアが気の効いた見せ方を工夫するカルチャーがあります。

小林：当社もtoBサービスなので、フロントエンドのパフォーマンスに関しては、あまり意識していません。ただサービスの性質上、サーバーサイドの負荷がボトルネックになることはあるので、そちらのパフォーマンスについては注意しています。

一方で、これも水島さんの意見と同じですが、クライアントサイドのパフォーマンスをよくしたい、という話題が度々出ます。そこで現状のプロダクトのパフォーマンスとはどんなもので、どのような課題があり、解決するにはどうしたらよいのか。「そもそもパフォーマンスとはなんぞや？」といった内容のレベルから勉強会などを開催し、パフォーマンスの向上に取り組んでいます。

アメリカにもサービスを提供しているのですが、向こうは日本と比べるとネットワーク環境が安定していないため、ファイルサイズを圧縮するなどのケアをしています。

加藤：Reactを採用する以前、Backbone.jsを使っていたころは、ブラウザの仕組みを理解した上でパフォーマンスチューニングを行う必要がありました。そのためそれなりに勉強していました。しかしReactを使い出してからは、仮想部分を正しく使うことが一番効果的であり、それが全ての世界観だと分かりましたから、今はあまり気にしていません。何だか寂しい気もしますが。

品質を担保するための取り組み

加藤：コストが嵩むようなテストは行っておらず、逆に低コストでありながら、いろいろと使い勝手のよいツールを導入しています。よく使うのはStorybookで、コンポーネントを追加してスナップショットテストなどを行っています。

あとは当たり前のことですが、静的解析のlintをかけたりしています。

水島：E2Eテストは以前から行っていて、最近はTestCafeを使っています。lintも少しずつですが導入しています。

あとはエンジニアあるあるですが、「IEでの動作は確認した？」を口癖のように言っています（笑）。フロントの障害の殆どはIEで発生しますので。

小林：機能を考えるプログラマと品質保証を行うQAが、プロダクトにもよりますが、相談したり議論するなど協力しながら品質を担保しています。たとえば機能を考える段階からテストを書いたり。またCI（継続的インテグレーション）ツールは当たり前に導入しています。

最近よく出る話題は、大規模なE2Eテストで全てをカバーするのではなく、スモールなテストを増やすことで、テスト領域をより広げようと考えています。

――品質担保を考えると、自然と組織の話にも紐づいていくようです。お二人はどうですか？

水島：ラクスル事業部にはQAチームがなく、プロダクトマネージャーが兼ねています。QAチームを作ろうという議論は何度も出ているのですが、適する人材の採用が難しいこと。いざQAチームができたら、頼りすぎてしまうのではないかといった意見もあり、プロダクトマネージャーに補佐を付ける程度にしています。

加藤：QAチームはあります。ただ当社のプロダクトは法律の影響を受けて仕様が変わるため、専門知識がないと理解が難しく、各ドメインごとにプロフェッショナルがいるような状況です。そのプロフェッショナルチームが架け橋となって、テストを調整するなど工夫しています。

ワークフローで工夫していること

小林：プロダクトの流れとしては、まずは開発者がふだん使っている環境でどのように動くのか、自動でデプロイするようにしています。そのフローをクリアしたら、次は全社員が使っている環境に同じくデプロイ。その後、本番であるユーザーに公開する。このようなフローを踏んでいます。

開発フローは少し前まではスクラムがめちゃくちゃ流行っていて、どこのプロジェクトチームに行っても、かんばんが掲げてありました（笑）。それがここ1年ぐらいでモブプログラミングに移行。当社の開発拠点は、東京、大阪、松山、さらには自宅で仕事をしているエンジニアもいますので、メンバーをリモートで繋ぎながら、モブプログラミングを行っています。

モブプログラミングのメリットは、キャリアの浅いメンバーも参加できること。コードの属人性がなくなったこと。レビューコストが下がったことなどです。

一方で、デメリットも感じています。個人のタスクが当然減りますから、エンジニア個々の成長という点では、以前のように1人でひたすら考えていた環境と比べると、どうしても劣ると感じざるを得ないからです。

またモブプログラミングは丸1日かけて行う場合が多いので、シンプルに疲れます。今後は従来の開発環境と使い分けていこうと考えています。

水島：弊社もモブプログラミングを導入していますが、小林さんがおっしゃるように、かなり疲れます。なので状況に応じて使い分けていて、全員ではなく2人で行うペアプログラミングを、ノウハウを共有する目的で1時間程度で終わる軽めに行ったりしています。モブプロやペアプロは専用ブースもあります。

またスクラムを組む場合、以前だとサーバーエンジニア5人に対してフロントエンドエンジニア1人という時代があり、正直、フロントエンドエンジニアが孤独で精神的に参っていた状況がありました。

そこで現在は、兼任でもよいので1スクラムに必ず2人以上のフロントエンドエンジニアを配置するようにしています。ペアにおいても新人と中堅・ベテランを組み合わせるなどして、新人教育にも繋がるように配慮しています。

加藤：モブプログラミングに近いですが、当社ではライブコーディングを行っています。高いスキルを持つエンジニアが、思考プロセスも口に出しながらコーディングしていくことで、他のエンジニアも共有しようという狙いがあります。

ライブコーディングのいいところは思考だけでなく、ツールを使うタイミングや実際の使い方などを見て学べる点です。効率よく他のエンジニアの成長に繋がるワークフローだと感じ、最近頻繁に行っています。

フロントエンドエンジニアが働きやすい環境

水島：先の話に関連しますが、どうしてもサーバーエンジニアと比べると、フロントエンドエンジニアの数が少なく、そのためか力関係もサーバーエンジニアのほうが上のように感じてしまいます。フロントエンドエンジニアが働きやすい環境にするためには、先の5人に2人のスクラムのように、孤独にしないこと。簡単に言えば数を増やすことだと思っています。

実際弊社でも私が入社した2年ほど前は、フロントエンドエンジニアはわずか2名でしたが、現在では10名に増加。同時に3つのアプリケーションをレビューするような環境に変わりました。

小林：これまではフロントエンド、サーバーサイドと特に分けずに、同じエンジニアがプログラミングしてきました。両技術が学べるとのメリットもあるのですが、これからはフロントエンドを専門的にサポートしていくチームが必要だろうと、2017年の後半ぐらいから「フロントエンドエキスパートチーム」を設立。私も含め現在5名体制で、フロントまわりの開発に専任しています。

加藤：お互い意見が言い合えるカジュアルな雰囲気が働きやすい環境だと感じています。当社であれば、エンジニアがプログラミングを終えた後に見たファーストインプレッションをUXチームに気軽にフィードバックできる、フローならびにカルチャーがあります。

フロントエンドエンジニアに期待していること

水島：先ほど紹介した、弊社のフロントエンドエンジニアが最近よく使っているFabric.jsやthree.jsは、おそらくまだ多くのフロントエンドエンジニアは知らないと思います。しかしこれらを使えば、表現力に富んだ、グラフィカルで立体的なUIが実現でき、リアル産業を相手にするサービスでは重宝されます。UI・UXにこだわりを持つエンジニアは、新しい技術であることも含め、魅力ある開発環境だと思います

もうひとつ。これもtoBサービスならではですが、toCに比べ、ライフサイクルが4～5年、中には10年と長きにわたりプログラムが使われます。そのため負債を残さない。拡張性を持っているなどの設計マインドならびに実際のコーディングスキルが身につきます。

加藤：当社のアプリケーションで求められているのは、とにかく壊れないこと。しっかりと入出力ができる堅牢さです。またある程度開発されているため、アプリケーションの特徴を活かしつつ、さらなる問題をどう解決していくか。その部分にエンジニアとしてのやりがいを感じる方であれば、楽しく働けると思います。

小林：加藤さんの意見と同じく、当社のプロダクトもこれから新たに書き直すというフェーズではありません。新たな技術を使って、今ある問題を解決することが仕事の中心だからです。たとえばあまり使っていないCSSを消したい。その方法を考えるとか。ESLintのプラグインを自分で書いてみるなど。

特徴としては、腕力や時間をかけて目前の問題を解決するのではなく、新しい技術やアイデアで解決するカルチャーであることです。

またいずれは開発で得たナレッジをOSSとして、世界中のエンジニアにアウトプットしていければと考えています。

【Q＆A】参加者からの質問で盛り上がったQ&Aタイム

――これがないとやっていけいない、めちゃくちゃ便利という定番のライブラリ、開発ツールがあれば知りたい。

加藤：ESLintとFlow、この2つがなないとやっていけないぐらい重宝しています。理由は、静的解析に助けられているからです。静的解析に関するツールを常に調査して、使えそうなものを探していくと、自分に必要なツールを知ることができるのではないかと思います。

水島：先程挙げたもの以外に特にありませんが、強いて挙げるならばSentryですね。フロントエンドエンジニアも監視系ツールは入れていこうとの流れが、社内にあります。結構エラー出てますよ (笑)。

林：加藤さんとかぶりますが、うちもESLint、あとはPrettier、TypeScript。この3つは今必ず入れる三種の神器的な存在です。あとはReactとか。細かいところだといっぱいありますが、フロントエンドエンジニアだとnpmパッケージをたくさん使うと思うので、その更新管理に使えるリノベイト（不明）などが最近社内で注目されています。

――役割分担がグレーになっていると感じる、デザイナーとの協業はどうか。

水島：チームによって異なりますが、こだわっているときはデザイナーとフロントエンドエンジニアが、ペアプログラミングしながらアニメーションのチューニングをしたりします。

ただデザイナーは多忙な場合が多いので、フロントエンドエンジニアがある程度カスタマイズできる裁量を持っています。そして最終的にプロダクトマネージャーとデザイナーがチェックするという流れです。

小林：プロダクトによって異なります。たとえばkintoneチームであれば、デザイナーが最初にデザインを作って、エンジニアが実装して、最後調整をモブプログラミングでやって仕上げる、というパターンです。基本、一緒に開発を進めることが多いですね。

加藤：当社のデザイナーはコードを書かないので、ペアプログラミングのように、デザイナーとエンジニアが一緒にやることはありません。

ただ、こういった新しい技術を使うとこんなものが作れるよ。もっと別のUXが体験できるよ。あるいはエンジニアがコードを書いていて気づいたことを、デザイナーに伝えること、伝えやすい環境であることを意識しています。

たとえばあまりにデザインが細かすぎて、ユーザーも予測不能なUIになっている可能性がある場合などです。

――フロントエンドエンジニアの採用について

小林：フロントエンドエンジニアというくくりでは募集はしていません。サーバーサイド、フロンドサイド両方で求人をかけ、実際に働いてみてフロントエンドまわりが得意な人が担当になっていく流れです。

一方で、先ほど話したようにエキスパートチームが結成されたので、そこでの採用は別です。フロントエンドに特化したエンジニアを募集しています。

水島：フロントエンドエンジニアという名目で募集しています。また自社のオフィスなどで勉強会を開催するなどしてフロントエンドまわりに敏感なエンジニアを集め、楽しくコミュニティを形成。そこから採用する流れなども意識しています。

加藤：当社も特に分けていないので、入社してからの特性や成長を見て、フロントエンドエンジニアとして成長していく流れです。ですから面接段階ではエンジニアとしての素養である、抽象的な構造の理解力を重視しています。