フロントエンドエンジニア座談会：Javascriptフレームワーク編

毛利：

Webサイトの機能的にフレームワークを使った方がいいプロジェクトに関しては、

制作者側で簡単に作れる機能があるものとして選びやすいのでマッチした選定になることが多いですよね。

吉田：

僕は今日何も用意せず丸腰でこの場に参加したんですけど（笑）

今までは割とjQueryやVanillaでTypescriptでゴリゴリ書いていることが多かったんですが、

先日プロジェクトでReactを使ってみたら、本当にシンプルな実装でやりたいことが全部できちゃうというか、すぐに画面に反映できて開発効率的にも良いなと感じました。

あとは全体を作るのではなくページの一部に適用できることで、なんで今までjQueryでやってたんだろうって思いましたね。

今後も絞り込み機能などはReactを使っていきたいなと思いますね。

板鼻：

吉田さんは、Reactは要件定義に含まれていたわけではないですよね？

Reactを使うことになった経緯は？

吉田：

他のメンバーと相談して、この要件ならマッチしてそうだからjQueryやVanillaじゃなくReact使って大丈夫そうだなと思って使ったという経緯ですね。

要望されたわけではなく、自分たちで相談して選定しました。

橋本：

僕も吉田さんと同じで、絞り込みやAPIからデータを受け取って処理するなどの場合に、データを取得したらDOMに反映する、絞り込みボタンを押したらデータを制御してDOMに反映する、という自分でClassなどで作っていかなきゃいけない部分をフレームワークが実現してくれるので、コンポーネント設計やデータのバインディングを考えるだけで良いのがフレームワークを使う醍醐味かなと思います。

そういう場面では間違いなくフレームワークを使った方がいいなと感じますね。

板鼻：

毛利さんはNuxt.jsと特定のHeadlessCMSがほとんど決まった状態で開始したプロジェクトもありましたよね。

毛利：

このフレームワーク使いたいです、このHeadlessCMS使いたいですという限定されているパターンの場合には、機能を実現するために大変になることもある。

作った後にこれは最適だったのか？と思うこともあります。

無理やりとは言わないですが、なんとか頑張って作った部分が運用やメンテナンスをする時には対応難易度が高くなるので他のメンバーが行えない可能性が出てきてしまい、取り回しの悪い状態になってしまいますね。

橋本：

毛利さんが言うように、他メンバーとの意思疎通や学習コストを考えると、初学者の人とかの場合にあまり流行っていないものや考え方、新しすぎるフレームワークなどを使おうとすると大変になることもあるのでちょっと怖いですね。

板鼻：

機能的にこの構成じゃ実現が難しいものもありますよね。

あとは属人的な知見になってしまう部分はどうしてもメンバーへ伝えるのが困難になってしまう部分はありますよね。

そういった意味では、実は吉田さんを始め数人のメンバーで取り組んだプロジェクトで、jQueryやVanillaなら何かあっても誰でも対応できるだろうという意図で僕が技術選定したことがあったんですが。

吉田：

そこに関しては元々あったソースコードやデータ的にjQueryの方が良かったんで、jQuery使ってますね。

それ以外ではReactを使うところもあったという感じですね。

板鼻：

なるほどなるほど。

やはり既存の部分で無理やり使うのはあまりおすすめではないですよね。

板鼻：

橋本くんは社内でもかなりVue.jsやReactを使いこなしてると思うけど、メンバー間という部分では苦労した部分はありますか？

橋本：

僕のケースですが、当時Javascriptがあまりできなかった時に先輩と分担をして実装をしたプロジェクトがあって、修正に関しては全て僕がやったんですが、その時に先輩のソースコードを必然的に見ることになり、また修正のレビューをもらうことで自分で学んでいく状況があって徐々にできるようになってきましたね。

板鼻：

初学者に対していかにハードルを下げるかという部分はフレームワーク側も考えていた部分ではあると思うけど、だれかと一緒に関わるプロジェクトではソースコードを見るだけじゃなく、それを使う場面がどうしてもあるので、こういう風にできるんだなと学ぶことは多いと感じますね。

古い新しいに関わらず、適した技術を選択することでコストやスケジュールに関して見合った状態を考える必要があります。 無理やり新しいものを導入するということではなく、最適な技術選定をすることで構築時も運用時も無理のない構築を考慮しています。

橋本：

Nuxt.jsでのプロジェクトで、後から一部だけSSGにしたいと言われた部分や、SEO的な対応を依頼された時に、今の構成だと難しいと答えた時がありました。

要件定義の段階でそういった要望をヒアリングするのはなかなか難しいと思います。

毛利：

SPAの場合でも、大体大丈夫だよっていう世の中的な認識もあるけど、検索ロボットが本当に読み取ってくれるかはできてみるまでわからないので、社内のディレクターでも説得が難しいですよね。

そういう部分は別途検証したり考えなきゃいけないところがありますね。

板鼻：

クライアントも最初には想定しづらい部分だし、静的な制作だとページができてからSEO対策などを全体的に行うことが多いので、そのフローだと取り返しがつかないことがありますよね。

SEO関連でいくと、インデックスされるかよりもSNSのシェア機能が問題になることが多い印象ですね。

SPAではページ個別にOGPの設定ができないのでそれを納得してもらうのは難しいですね。

「プロに頼んでいるんだからいい感じにしてよ」という思いもわかるし、任せてくださいという部分もあるけど、いい感じとはどういう状態かを細かい部分まで相談して決められるといいですよね。

毛利：

実装面では非同期の遷移なので、普通の遷移を考えているとUIの後の挙動を作らなきゃいけない部分がありますね。

例えばハンバーガーメニューとかは静的なサイトであれば同期遷移なのでパッと切り替わりますけど、SPAで非同期遷移だと閉じるところまで考えてなかった！ということが前にありましたね。

板鼻：

一緒に作ったgood productionsで実際にあったよね（笑）

あ、これ閉じなきゃねって後から考えたりありましたね。

毛利：

そういう想定しきれていない部分が多くなってきますね。

板鼻：

吉田さんは実際にプロジェクトで課題として感じた部分はありますか？

吉田：

なにかあったかなーと思い出そうとしましたけどなさそうですね。

スキップで！（笑）

橋本：

SEO関連以外では実装面ではあまり課題感はないかもしれないですね。

SSRではサーバー上でNode.jsが動かないといけないので、ホスティング側も色々と増えてはいますけどプロジェクトとしてそこが課題になるパターンもありますね。

実際にあった例でいうと、Vercelを使った時に検証の段階から有料アカウントの用意をしたかったけど、契約的にそれはクライアントの負担になるのでなんとかそやり方を考える必要がありましたね。

そういったインフラ面でも幅広く知見を持たないといけないなと感じました。

毛利：

Vercelは海外のサービスなので、エンドクライアントまで提案が通しづらかったりもしますよね。

安心してもらえるものというと選択肢が狭くなってくるので、そういう意味でもホスティング問題は課題を感じますね。

板鼻：

料金的にも、FaaSであればSSRなどで最適な機能があってその機能を使うからという金額だけど、

普通のWebサーバーならレンタルサーバーも国内で多いしリーズナブルなのでそれが定着していると思うのでなかなか提案しづらいですよね。

MicrosoftやGoogleのサービスだと大丈夫っていう企業も多いので、AzureやFirebaseを選択することも一つの手だと思うけど、普通のWebサーバーにNode.jsをインストールして動かすっていう昔からある手法も場合によっては考えていかなきゃいけないですね。

板鼻：

それと僕はJamstackにすごく課題感を感じてるんですよね。

流行り始めてきた時に100ページくらいでビルド時間が3時間っていう状態になって（笑）

最終的にはフレームワークがバージョンアップして7分くらいになったんだけど。

それでもビルド時間を待たなきゃいけないっていうところが実際のプロジェクトではうまくいかないこともあるとおもうんですよね。

吉田：

Reactとかだと変更箇所のみビルドできますよね？

そういうので解決できる部分があると思ってます。

板鼻：

Gatsbyではそういう機能もあるし、Next.jsでは表示した時に初めてビルドされるSSRとSSGの間のような機能がありますね。

AstroでもMPAなので分割ビルドとか更新したところだけっていうのはやりやすいはずですよね。

昨今のフロントエンドの技術はそれぞれに課題もあります。

それは旧来からの構築方法も同様に課題があり進化し続けていることにはなりますが、これらの課題の解決方法や緩和できる可能性を常に考えています。

吉田：

フレームワークやライブラリとかでも新しいバージョンがどんどん出てくるけど、どういう風に選ぶか悩むことがありますよね。

もう使って大丈夫か心配もあるとおもうんですけど、どういう基準で判断してますか？

橋本：

実際のプロジェクトではVue.jsとかReactとかでもそうですけど、一番最新の一個前を選ぶことが多いかもしれないですね。

LTSであってもバグがあったら怖いのと、Vue.jsではライブラリが追いついてないことがあってすぐに最新のバージョンを使うのは怖いですね。

新しいものはちょっと使ってみてから違和感がないか確認して導入に踏み切るようにしています。

吉田：

JavascriptフレームワークだとStore管理ライブラリが色々あると思うんだけど、

試してみて良かったなと感じたものを使う感じですか？

橋本：

そう聞かれると半々くらいですかね。

直近のプロジェクトではVue.js v3でStoreライブラリはPiniaを使いましたが、

使ったことがなかったんですが、公式が推奨しているライブラリだったので使いました。

公式の開発者が推奨、非推奨にしたものはそんなに検証せずに使うケースも多いかもしれないです。

吉田：

確かに公式が奨めてるというのは使うきっかけとしては強いですね。

公式系のライブラリだとフレームワーク本体のバージョンアップでのサポートも受けやすかったりしますしね。

板鼻：

毛利さんも同時期に別のプロジェクトでPinia使い始めてたよね。

毛利：

そうですね。

公式が推奨しているというのは知っていて使ったんですけど、今思うと博打だったかもしれないですがあまり悩まずに使ったところはありましたね（笑）

判断基準として公式が推奨しているのは判断しやすいし、情報量も多いので選択しやすいですよね。

全く情報のないものは怖いしNPMとかでアクティブかどうかをみて使われている数とかでも判断してますね。

ただ、そもそも一般的に良く使われるライブラリはそこまで深く考えずに使ってたりしますね。

板鼻：

Swiperとかはカルーセル機能をつけるなら選択することは多いですよね。

同じ機能のライブラリを見つけた場合にGitHubスターが少なかったりするとちょっと使いづらいのはみんな一緒なのかなと思いますよね。

橋本：

バージョンとかではなく機能で選定したい場合は、そのライブラリにしかできないものとかがありますね。

グラフ系のライブラリとかだと、大手のサイトでは使われているけど、カスタマイズ性が高すぎてドキュメントもすごい量だけど、英語でしか情報がない場合に苦労したことがあります。

でもそれじゃないと実現できないという場合には使うしかないですよね。

板鼻：

そういうライブラリを使うと終わりが見えないというか、どれくらいでできるのかわからない場合もあるよね。

橋本：

そういう部分で苦労した覚えはありますね。

より安全、だけどスピーディーに。

そういった部分や特殊な状況にも対応しやすいような技術選定を行っています。

毛利：

うーん、端的にスケジュールがほしい（笑）

というのも、静的な制作と変わらないスケジュールのことがあったりして、設計が必要なのにその部分に時間を割けないケースがありますね。

進行のノウハウは貯まってきてるので、今後そういった制作フローを提示していきたいと思ってます。

板鼻：

その中で、何か準備しているものはありますか？

毛利：

設計のフォーマットなどは以前固めたので、そういうものを活用して効率化を図っていこうと思ってます。

スケジュールの部分もそうですけど、誰がやる場合でも同様に進められるようにしていく必要があるので、ナレッジ化していきたいと思います。

吉田：

開発進めながらでもできちゃうものはあるけど、コンポーネント設計とかstoreの設計とかは前もってできるといいですよね。

Storeの設計とかロジックを考える部分も事前にできていた方がいいと感じますね。

共通化を先に考えておけば効率的に開発を進めることができると思います。

そのためにもあらかじめ要件をちゃんと把握しておく必要があるし、技術選定にも関わるので要件定義の段階から設計していけば効率的に進められるんじゃないかなと思います。

橋本：

意識しているのは、プロジェクト固有ではないベースのコンポーネントを作る機会があるなら汎用性を高めて作るようにしています。

どのプロジェクトでも効率的に使うことができるのでそういった準備はしていますね。

よりDEPARTとして準備できる部分としては、個人ベースではなくDEPARTとしてのライブラリ化をすることができるといいと思ってます。

あとはみんなが言うように、事前に設計できるといいですね（笑）

板鼻：

クライアントと一緒に設計したりそのためのヒアリングができるといいなと思いますね。

SEOの話でもありましたけど、後から出てくることを先にヒアリングする必要があるとおもうし、伝えたり提案する必要があるとおもいます。

あとは動かしてみないとわからないって部分は多いと思うので、Mockで確認しあうことも必要だなと感じますね。

橋本：

Mockを作って要件を固めることで何度も作り直しにならなくて良い部分も見えてくるので、デザインフェーズの効率化もできますよね。

ただ、そのMockをいかに早く作るかという部分が問題になってきますね。

板鼻：

だからこそDEPARTとしてのライブラリ化やベースのコンポーネントが必要になってくるよね。

橋本：

ただ条件によっては難しい場合がありますよね。

APIのデータ構造がわかってない状態や、バックエンド側の機能がわからないと、フロントエンド側でできることが定まらないので、そういった部分はクライアントやパートナーと協力していく必要がありますね。

UIやUXが先行してしまうとそもそもできないとか、やりたいことと違ってしまうなどもあるので、全体の機能設計やデータ設計を先に進めていく必要があると思います。

毛利：

そのためにも早い段階で全容を知っていく必要があると思うし、ヒアリングをしないとクライアントも気づかない細かい部分があると思うので、そういった部分を相互に準備できる流れが作れるといいと思います。

自分達だけではお客様のご都合やビジネス的制約を計り知ることは難しい部分ですので、良いものを作り上げてくためにも、叶えたい目的とそこで起こる課題を一緒に考えさせてもらえればと思っています。

DEPARTではJavascriptフレームワークでの制作・開発も行っており、静的サイト構築とは違った視点での進行や提案に関しても随時強化しています。

Jamstackに関しては静的サイトと同様に効率的に制作ができるようにという観点でも効率化や課題解決に向けて動いていますが、ただ作るだけではなくSEOなどWebサイト運用に関しても日々検討しています。

ぜひ一緒に設計段階から実現したいことを話し合っていきませんか？