JavaScript ～進化し続けるフロントエンドエンジニア～各種フレームワークの位置付けとTypeScriptの台頭
※本記事は、2019年11月に公開された内容です。
2018年に行われたFLEXY主催のCTOmeetupでも好評だった、JavaScriptテーマ。 今回もフロントエンドのプロフェッショナルな方々に、とことんJavaScriptについて語っていただきました。
2019年の今、最前線で技術を研鑽し続けるエンジニアはJavaScriptの現在や未来をどう見ているのか。
フレームワークの選定基準や、フロントエンドエンジニアに求められる資質、採用手法なども網羅しています。
【ご登壇者】
- 株式会社リクルートテクノロジーズ・グループマネージャー 古川 陽介さん
- 株式会社ZIKU Technologiesフロントエンド開発担当者執行役員/UXエンジニア
株式会社Emotion Tech プロダクトアドバイザー
株式会社GIG プロダクトアドバイザー 林 優一さん - STUDIO株式会社 技術顧問 菅原 孝則さん
【モデレータ】
- 株式会社ビットジャーニー 代表取締役 井原 正博さん
目次
フレームワークの選定基準
開発における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でも何でもいいんですが、これらのツールで何かを作ることは普通のことで、できないとすればフロントエンドエンジニアとして致命的なんです。
その上で必要なことは、個々人が軸を持つことだと思います。パフォーマンスにこだわっているといったことでも何でもいいんですが、いわゆる非機能要件を満たせるようなフロントエンドエンジニアが、今後活躍していくのではないでしょうか。そこもできないとなれば、設計力が試されます。
フロントエンドエンジニアの採用と教育
スタートアップでも大手企業でも、技術広報の効果は非常に高い
井原：後半は、フロントエンドエンジニアの採用や教育についてディスカッションしたいと思います。
どうすれば優秀な人が来てくれるのか、一番大手のリクルートさんの場合はいかがでしょうか。
古川：私が見ている基準からすると、前半で言及したように何か軸があるかどうかですね。
例えばReactでアプリケーションを作りましたというだけでは特に面白みはありません。
こういう意図が合って作ったのだというこだわりポイントを聞きたいです。パフォーマンスを出すためにここまで頑張ったとか、最終的にブラウザの仕様がどうなっているか理解できたといったことを語れるなら、良い人材と言えると思います。
井原：どうやって母集団形成をしていくのか、ノウハウはありますか？
古川：リクルートはリクルートですから、もちろんスカウティングの基盤があります。
エージェントを使うことが多いですよ。ただ実際のところ人を集めるために工夫しているのは、ブログでフロントエンドエンジニアの技術をアピールしたり、こういったイベントに登壇したりすることですよ。
地道なPRですが、結果的にそれがフロントエンドエンジニアとして一緒に働いてみたいという気持ちにつながると思うので、積極的に取り組んでいます。
案外馬鹿にならないんですよ。ブログを見て応募したという子も多いです。
菅原：小規模な企業における採用活動における壁は、認知がないのでそもそも組織に魅力を感じてもらう機会が少ない事なんですよ。 だからまずは昔一緒に仕事をしたことのある優秀な人に声をかけていくことになります。リファラルですね。そのストックも1～2年もすれば尽きるので、やはりイベントに登壇したり、技術広報でPRします。
私の場合そこで意識したのは、いかにイケてる企業に見せるかということです。
今後、流行の波が来るだろうとあたりをつけたアーキテクチャをプロダクトに実際にプロダクションで活用して、こんなに最先端なことをしているんだよと言ってしまいますね。感度の高い人にはアプローチできると思います。
井原：その場合、サービスへのリスクはありますよね。
菅原：小規模組織だからこそできることかもしれませんね。
どんな技術でもそうですが、一度導入してみないと上手くいくかは実際のところわかりませんし、だったらよりカッコ良く見せた方がいいだろうという考えです。それで問題なく動けばいいわけですし。
林：以前LIGという会社に所属していたのですが、採用方法が少し特殊でしたね。
エージェントなどはなるべく使わずにインバウンドでの採用が一番多かったんです。
当時は技術ブログしかり、ちょっと面白そうなことをしている会社というブランディングが流行っていて、実際に非常に効果がありました。
ただ今はそれもすっかり乱立状態で、「とりあえず技術ブログを作っておけばいいだろう」という企業も多いです。
情報が多いし質もバラバラなので、とても見きれません。記事がSNSのTLに流れてきてもタイトルだけ流し見してしまいます。
だから技術ブログで広報しようと思ったら、ライティング能力も必要です。
LIGの場合は技術記事であろうと何であろうと、全て編集者がチェックして、素人が見ても読みやすいレベルの平易な言葉に手直ししていたくらいです。
ほかの例ではやはりリファラル採用が一番多いですね。仲の良い知り合いを引っ張ってくるだけではなく、こういうイベントの場で知り合って誘います。
やはりコミュニティに参加しているような人はアンテナの感度が高いですし、優秀なエンジニアを捕まえたかったら直接会いに行くのが一番だと思いますよ。
このイベントの後に行われる懇親会も同じで、良い人がいたらその場でスカウトします。
右側：林 優一さん
株式会社ZIKU Technologiesフロントエンド開発担当者執行役員/UXエンジニア
株式会社Emotion Tech プロダクトアドバイザー
株式会社GIG プロダクトアドバイザー
左側：ファシリテーター 井原 正博さん
株式会社ビットジャーニー 代表取締役
フルスタックエンジニアになるか、ピーキーなスペシャリストになるか
井原：特にフロントエンドエンジニアに特化した採用基準はあったりしますか？
古川：当社の場合はフルスタック寄りのフロントエンドエンジニアを採用しています。
リクルートにおいてフロントエンドエンジニアは、HTML、CSS、JSを触るだけの人ではないんですよ。裏側のNode.jsも見なければいけませんし、そこからバックエンドのAPIを叩くのでAPIにも詳しくなければいけません。
一方でインフラをどうするのかにも口を出してほしい。さらにデザインや企画の領域で、何をやりたくてどう進めたいのかをやり取りする必要もあります。
もともとフロントはコミュニケーションのハブとなることが多いのですが、当社の場合は全般的に何でもしなければならないので、フルスタック的な能力が求められるんです。
井原：インフラエンジニアよりも求められる条件が広い感じですね。
フロントエンドエンジニアという枠で括りきれない感じがします。一方で本当にフロントしか触れない、という人も居るには居ますよね。
菅原：それならWebGLやWasmなどレアな技術を持っていて、その領域に関しては一番キツい作業を投げられても良いクオリティを出せますというくらいじゃないと今時スペシャリストじゃないかなと思います。自分も含めそうでないので近接領域くらいは拾っておくべきと。
井原：林さんにはこんなフロントエンドエンジニアを採用したいという理想はありますか？
林：フロントエンドに限らずですが、採用したいという点で言えば技術よりもサービス理解がどれくらいあるか、あるいはどれくらい好きかということを一番重視しますね。本音を言えば、技術がそこそこでもサービスが好きな人ならいくらでも教えたいです。
逆にサービスに興味はないけどこの技術だけやりたいと言われても教える気にはならなくなります。飽きたらどこかへ行ってしまうんだろうなと思いますし。
私の場合は自社サービスに対して自前で最新機材を用意して、そこそこお金使ってます。もちろん真似をしろというわけではありませんが、それくらい私はサービスに入れ込んでいますし、だからこそ採用するのもサービスを愛してくれる人がいいです。
右側：古川 陽介さん
株式会社リクルートテクノロジーズ・グループマネージャー
左側：菅原 孝則さん
STUDIO株式会社 技術顧問
優れたエンジニアは世にあるサービスとその設計を常にリサーチしている
井原：JavaScriptのエンジニアを採用するときに面接で設計力を知りたいと思ったらどうしますか？
古川：私は応募者の経験を深堀りする過程で、「こういうときはどうしますか」という想定外の質問をしますね。それに対してどこまでリアルに答えられるかを見ます。
林：例えばTwitterやSlackなど、SPAを利用しているサービスは多いと思うのですが、TwitterがどういうState設計で作られているのかすぐに想像できるエンジニアは非常に優秀です。
Slackなんかは最近Reactで作り直されていますが、それも瞬間的にState設計を想像できる、あるいはあのサービスを作ってくれと言われて作るイメージが湧くのなら、設計力はずば抜けていますよね。そういう人はそもそも世の中のサービスがどうやって作られているのか興味を持って、常にリサーチしているんです。実際にSlackのStateを見に行くことはできますしね。
古川：私もTwitterは一度見たことがありますよ。ツイートするフォームの仕組みが面白かったです。打ち込んで何文字かはあえてReactでStateを回していて、ある程度バッファが出来たら流すという形にしていました。
井原：具体的なサービスに対して自分だったらどう設計するだろうという思考を常日頃から持って、実際にトライしてみると大きな学びになりますしね。
古川：そういうところに興味があるといいですよね。
何を学び、何にこだわるのかを見定めることでエンジニアとしてのレベルが上がる
井原：フロントエンドエンジニアが生き残っていくために、自分も含めたエンジニアの教育は非常に大事だと思うのですが、何をしていくべきなのでしょうか。
古川：ちゃんと勉強の時間を確保すべきですよね。軸を作るべきと再三お伝えしていますが、勉強するにしてもデザインならデザイン、パフォーマンスならパフォーマンスと、こだわりポイントを作った上でした方がいいでしょう。
井原：会社なら組織としてそういう学びの環境を用意するということですよね。
古川さんご自身としてはどんなことをしていますか？
古川：仕事としては今マネジメントなどをしているのですが、フロントエンドエンジニアとしてのプロ意識は絶対に忘れないようにしようと思っています。
決めているのは、毎日1つは何かしらにコミットすることですね。リクルート内部では、不備を改善していくことを常に意識しています。ReactにしろAngularにしろVue.jsにしろ、組み合わせで開発を進めると必ず不備が生まれるんです。
コンシューマードリブンの例で言えば、JSON Schemaが書きづらかったりもします。そういう負債を少しずつライブラリに書いて改善するといったことを行なっています。
菅原：人の成長という視点から言えば、自分で考えて試しに作って、フィードバックをもらってまた作るというサイクルをどれだけ数多くこなせるかというだけの話ではあります。マネジメント側もしっかりオーナーシップを渡して、失敗する機会を与えてあげればいいだけです。
フロントエンドエンジニアという部分に限って言うなら、この領域はユーザーの触り心地を左右する最後の砦だと自覚を促すことです。だから私はひたすらダメ出しします。ここフレームレート落ちてるぞ、60FPSにしないとダメだと注文をつける。ユーザーがプロダクトに触れたときにどういう気持ちや感覚を抱くのか、意識をしっかり植え付ける感じですね。
井原：自分自身で心がけていることは何ですか？
菅原：何も考えない場合は最低60fpsを出すことです。そのためなら技術選定から変えます。と言っても重視しているのは速さよりも気持ち良さで、遅くても演出で結果心地よければいいんですよね。誤魔化し方はいろいろありますから。
井原：林さんはいかがですか？
林：フロントエンドエンジニアとしてプロフェッショナルでいたいと思うのなら、デザイン視点は必須だと思います。菅原さんもおっしゃっていましたが、ユーザー体験の最後の砦がフロントエンドです。例えばデザイナーがデザインしきれない非機能要件であったり、エラー発生時にどういうメッセージをどのタイミングでどこに出すのかといったデザインで漏れがちな部分を考えようと思ったら、デザイン経験の有無が非常に大きな要素になります。自分でデザインしたものを人に触ってもらうという経験です。トライしてみても最初はきっと上手くいきませんし、操作性やレスポンスが悪いと言われます。でもそこで初めてエンジニアとして一段階レベルアップするのではないでしょうか。
井原：教育という意味ではいかがでしょうか。
林：自社サービスをリデザインしてみるのがおすすめです。使いづらいところを直して、それを実際にメンバーに見てもらう。
自社サービスなら社内でフィードバックしやすいですし、各エンジニアにデザインを上げてもらい、投票してみてもいいと思いますよ。
最後の懇親会では、今回のイベントのPMのFLEXY若色と共に記念に写真を取っていただきました！ご登壇有難うございました！
企画/編集：FLEXY編集部
