組織構築としてのNuxt.jsの可能性について

概要

こんにちは、アジアクエスト株式会社でフロントエンドエンジニアをやってます、かめぽんです。Nuxt advent calendarということで、今やもっとも勢いのあるFWのVuejsですが、Nuxt.jsもかなりのインパクトを与えているので、それについて思いの丈を伝えられればと思います。
そのインパクトはエンジニアリングはもちろんですが、組織レベルでも影響を与えているんじゃ無いかと僕は考えています。そこで、今回社内でフロントエンド組織を構築していくにあたり実験的にVue、Nuxtを導入するまで、Nuxtが組織にどんな良い影響を与えて、、、もっと大きく話をすると良い技術が組織に与えるインパクトはどんなものかをNuxtの事例を踏まえながら、書いていければいいなと思っています。（本記事の内容はNuxt meetup#5で話した内容を元に構成しています。）

ターゲット

• エンジニアリングだけでなく組織構築に視点が向いている人
• フロントエンド組織を拡大させていきたい フロントエンドエンジニア
• VueとかNuxtは触ったり遊んだりするけど、組織に対してどういうメリットがあるかピンと来ていない人

メリット

• Vue,Nuxtが組織をドライブさせるにあたってのメリットの理解
• Nuxtをいますぐ始めたくなる

本題

なぜやるのか

何をやるにせよ、この問いが一番重要ですが、大きなゴールとしては組織拡大と文化の情勢にあります。

• フロントエンドがいやすい環境を作る
• レガシーによる疲弊を激減させる
• 組織をドライブさせる為

フロントエンドがいやすい環境を作る

釈迦に説法かもしれませんが、端末の多様化・それによる考慮すべきコンテキストの増加によりWebへのアクセス性がかなり複雑になってきています。その中で、いかにコンテンツまでにスムーズにたどり着けるか、発信したいことやWeb上で適切にで表現されているかが当たり前のように重要視されています。つまり何が言いたいかというと、IA・UX設計などを前提としたフロントエンド（以下、FE）エンジニアリングが今後事業に直結する事象であり、影響力があり価値であることは間違い無いということです。

そう考えると、必然的に組織にFEが必要でありそれと同時にFEがいやすい環境を作ること、中長期的に見ると（本記事では蛇足ですが）文化の醸成が必要になってきます。
では、FEがいやすい環境とは何か、福利厚生・インセンティブ・一緒に働くエンジニア・ナレッジ共有しやすいのか、などあげれると思いますが、僕は新しい技術に対して明るいかどうかが大きいと思っています。

次々と新しい技術が出てくる変わりすぎる世界の中で、変わらないモノ変わるものを見極め、事業に落とし込んでいくことが必要です。または、レガシーを正しくアップデートすることが組織の成長で必要になってきます。その際に適切な選択肢（技術）を適切に扱うことになりますが、そもそも適切かどうかを僕らは把握しなければ行けません。つまりは、新しい技術をプロトタイプでもいいので積極的に採用していき高い確度で価値になるかどうかを判断し、未来を創っていける武器になり得るかをウォッチします。それは非常に重要ですが、とてもエキサイティングで楽しいことです。そういうことが出来る文化をフロントエンドを中心に作ることが、今後大事になってくるからです。

レガシーでの疲弊を激減させる

これは、FEをやられている人なら思ったことがある人は多いと思います。レガシーまたは技術的負債の問題です。
これらは、よっぽど初期フェーズの組織で無い限りかなりの数の組織に当てはまると思います。レガシーは一概に全てが悪いとは言えませんが、大きく分けると「事業の足止め」と「メンバーを疲弊させる」の悪影響を及ぼすと考えています。
レガシーは本当は資産であるべきですが、中にはメンテできなくて負債になっているものがあります。そうなると新機能の追加や組織の次期プロダクトとして打ち出していきたいけど、そのフェーズで打ち出しにくいなどの事業的な欠点になり得ます。二つ目は、メンバーの疲弊です。技術を適用させたこと・技術自体は何も悪く無いのですが、メンテ出来ない状態があまり芳しくなく、段階的だろうと大規模リニューアルだろうと痛みを伴うフェーズが必ずあります。負債になりうる原因は様々あり、時の流れだったり純粋な技術採用のミス、メンテする人の技術力が追いつかなかったりなど様々あるので一概に何が悪い！と言うのは言えませんし、エンジニアであれば未来をアップデートさせる方向に目を向けたいものですよね。
しかしながら、事業観点からみてもレガシーなままにしておくことや開発体制が当時の技術に合わせた人員配置などにしていると、組織や採用に悪影響が出るのは必至ですし、当エンジニア達の組織定着にも少なからず影響はあります。

組織をドライブさせる為

これはフロントエンドがいやすい環境を作る、の目的にもなるのですが、組織をドライブさせる為 = 一緒に戦っていく仲間を増やすという意味で捉えてもらえればと思ってます。
一緒に戦っていく仲間を増やす、とありますがもう少し厳密にいうと**「一緒に戦っていく仲間が増えるような文化を作る」が正しいですね。
成長している会社さんやエンジニア組織として素晴らしいなと思う会社さんをみていると適切な技術は適切な人を呼ぶ**という特徴があるんじゃないかと感じています。
もう少し具体的に言うと、モダンなフレームワークまたはライブラリはモチベートされたエンジニアを呼ぶと言うことがあり、組織でどんな技術を採用しているかを対外的にアウトプットしていれば少なからずエンジニアはどんな技術を使っているかはチェックします。また、その技術に精通しているエンジニアが増えることによって組織全体でボトムアップ的に技術レベルをあげることが出来、メンバー各々が影響力を持つことでさらに人を引き寄せやすくなります。技術が人を呼び、人が技術を呼ぶ、このサイクルこそが重要項目の一つだと考えています。

しかしながら、対外的に打ち出すだけの採用実績がなかったり技術の採用がしにくかったり、導入のハードルが高かったりすると技術で人は呼べません。また、そもそもそこにコミットする人がいなければ技術の定着もなく、先ほどのサイクルに入れない、技術が無くて人が来ず、人がいないので技術が定着しない負のサイクルに陥ってしまうことがあります。

その点、Nuxt(Vue）はそこを見事に解決出来ています。

なぜNuxtなのか、そしてそのメリット

おそらくVueをはじめNuxtでの有用性を一エンジニアが感じることはあるあるですが、チーム全体あるいは組織レベルで有用性はあまり考えてこなかったので、ピックアップしてみます。

• 劇的な親しみやすさ
• 規約での意識の共通化
• 圧倒的スピードによる開発の高速化

劇的な親しみやすさ

これは、Vueを始めてみた人は圧倒的にわかると思うんですが、とにかく親しみやすいんですよね。コンポーネント設計の考え方をインプットする必要はあるものの、HTML/CSS/jscascriptを一通りやってみた人なら扱いやすいSFCなどがありますし、CDN版を導入をするだけでも強力なHTMLベースでテンプレートが扱えます。
さらに、NuxtはVueをベースに作られたフレームワークで、create-nuxt-appコマンド一発でプロジェクトに必要な資材を配置してくれるため、圧倒的にプロダクトを作成しやすい環境が出来ています。
その影響もあるのか、サーバーサイドやデザイナー問わず新しくフロントエンドとしてジョインする人がかなり多いように見受けられます。また、そのことによって歓迎する文化がVue界隈にはある気がして、それも始めやすい親しみ易い要因でもあるかなと思ってます。
いきなりNuxtを触らせることはリスクになるんじゃ無いかと言う声もありますが、いかに自分にも出来ると意識をさせられるかが重要になるので、そういった意味だとかなり有用だと言えます。

規約での意識の共通化

これはNuxtでのカルチャーですが、Vueと違ってNuxt独特のルールがあります。例えば、Pages配下にvueコンポーネントをおくと自動ルーティングが出来たり、nuxt.config.jsでの記述によってアプリケーションのメタ情報を設定出来たり、と独自の文化があります。一見、クセがあるように思えるかもしれませんが、Nuxtにはその規約を守るコストよりも規約を守った時に得られるメリットの方がだいぶ大きいと僕は感じています。ここはかなり大きなポイントであり、チームのルールとして運用していくに当たって被る大きなメリットかと思います。
また、規約があることによりエンジニアの技術レベルに左右されず、一定の品質担保を簡単にやってしまえるからです。つまり、誰が書いても破綻しづらく盲目的にチームで意識が共通化出来てしまいます。エンジニアの技術に左右されないと言うことは、チーム内で人員配置が変わっても破綻しづらい、つまり属人性の排除が圧倒的に進められます。
良いチームは最高レベルが高いチームではなく、最低レベルが高いチームでもあるのでそこに一役買っています。

圧倒的スピードによる開発サイクルの高速化

create-nuxt-app、これに尽きるところあります。フルクラッチで構築するのもありですが、プロダクトを作っていくと結局雛形にたどり着く場合が多く規約もあるため、テンプレートを最速で作って爆速で開発していきます。
また、規約の話から繋がるのですがNuxtルールの共通認識として持っていればcreate-nuxt-appなどのコマンドに頼らずともそれに近いかつ破綻しづらいプロダクト開発が出来ます。
開発スピードが出ることによりかつてのウォーターフォールからアジャイル的な作り方や爆速プロトタイピングなどの活用もでき、作って壊し、また作っては壊しアップデートさせていくと言うサイクルが生まれます。つまりは、プロダクトの質自体も速度を持って向上させていくことが出来ます。ここでも、人間が本来集中すべき部分に集中出来る仕組みがNuxtによってもたらされるはずです。

実際に導入してみて

今回、Nuxtを導入してみて感じたこと学んだことはたくさんありますが、実感としては習得時間・実装時間の削減に繋がったかなと思ってます。多少のインプットや後々の設計周りの話などは必要ですが、初期段階としてはかなり効果があったと思ってます。また、デプロイ周りでは環境に依存せず出来ることが非常に使えるな〜と感じました。SSRで動かすのか、SPAでやるのか、SSGで静的ホスティングするのか、レンタルサーバーで置ければOKみたいな場合でもNuxtは大活躍でした。

まとめ

今回初めて組織構築ドリブンで記事を書きましたが、Nuxtの有用性について改めて可能性を感じることが出来たなと思います。正直、新しい技術を組織に導入・定着させることは時間がかかりますし、何と言っても周りの人たちを巻き込んでいく形をとるので、体力は必要だなと感じました。
しかし、エンジニア組織を構築をしていく上で文化の醸成は絶対に必要で、技術に対してみんなでキャッチアップしてく姿勢とトライアンドエラーが必要です。そのためには、まず触って体験してもらうことが一番で、その上でこれはいけるじゃん！と言う確信が入ることが、技術的組織のアップデートに必要なことです。
そこでNuxtがもたらすスピード感、規約ベースの意識統一、開発サイクルの高速化、確信は組織構築ドリブンで考えた時にかなりメリットがあるので、どんどん使っていきつつ次のフェーズへ進められたらと思っています。
長々とした文章ではありましたが、ここまで読んでいただきありがとうございます。