Vue.jsエンジニアのフリーランス案件で求められるスキルと経験

Vue.jsのフリーランス案件では、Composition APIで画面をどの単位に分けるかというコンポーネント設計、Piniaを使った状態の持ち方、TypeScriptとの組み合わせ、Nuxtを使う場合の描画方式の理解が中心に見られます。画面を作れることは前提で、そのうえで「どこに何を置いたか」を説明できるかが、参画できる案件の幅を分けます。

この記事では、Vue.jsの案件で問われやすいスキルを分野ごとに整理し、経験の段階ごとに伸ばしたい点と、スキルシートや面談での示し方を解説します。独立までの準備やVue 2のサポート終了の話はVue.jsエンジニアがフリーランスになるにはにまとめています。

Vue.jsの案件で見られるスキルの全体像

求人票に並ぶ技術名は似ていても、案件側が確かめたいことは分野ごとに違います。

すべてを深く持つ必要はありません。応募する案件がどの分野を重く見ているかを求人票から読み取り、近い経験から順に示すのが現実的です。

Composition APIでのコンポーネント設計

画面を分ける単位を説明できる

Vue 3の案件では、<script setup>とComposition APIで書くことが多くなっています。面談で差が出るのは書き方の知識より、どこで部品を分けたかです。たとえば、一覧画面の行を部品にするか、検索フォームの状態を親に持たせるか、といった判断です。

• propsとemitsで親子のやり取りを明確にし、子が親の状態を直接書き換えない形にしたか
• 見た目だけが違う部品を、slotで中身を差し込める形にまとめたか
• 深い階層に値を渡すときに、provide/injectとストアのどちらを選んだか

こうした判断を一つでも具体的に話せると、既存のコードに入ってもすぐに書き方を合わせられる人として見てもらえます。

composableでロジックをまとめる

複数の画面で使う処理（ページ送り、入力の検証、APIの呼び出しと読み込み中の状態など）を、composableとして切り出した経験は評価されやすい材料です。切り出した結果、同じ不具合が複数の画面で起きなくなった、テストを書きやすくなった、といった効果まで添えると伝わります。

Piniaでの状態管理とVuexの扱い

Vue.jsの公式ドキュメントでは、新しいアプリにはPiniaを使うことがすすめられています。PiniaはVueのコアチームが保守しており、Vuexより簡潔なAPIで、TypeScriptでの型の推論にも強いと説明されています。一方、Vuexは保守のみの状態（maintenance mode）で、動作はするものの新しい機能は追加されないとされています（2026年10月時点の公式ドキュメントによる）。

このため案件では、次の2つの経験が別々に見られます。

1. Piniaで新しく設計した経験：ストアを機能ごとに分け、画面ごとの一時的な状態はストアに入れない、といった線引き
2. Vuexの既存コードを保守・移行した経験：運用中のサービスに残るVuexのストアを読み、Piniaへ少しずつ移した経験

状態管理は「全部ストアに入れる」と画面同士の依存が増え、「全部画面に持たせる」と同じデータの取得が重複します。自分がどこで線を引いたかを説明できるようにしておきましょう。

TypeScriptと組み合わせる力

新しいVue.jsの開発では、単一ファイルコンポーネント（SFC）でlang="ts"を指定し、TypeScriptで書く形が広く使われています。公式ドキュメントでは、Viteを使った構成では開発サーバーとビルドは変換だけを行い、型のチェックはしないと説明されています。そのため、型チェックはエディタの拡張機能（Vue - Official）と、コマンドラインのvue-tscで行うことになります。

案件で見られやすいのは次の点です。

• definePropsやdefineEmitsに型を付け、部品の入出力を明確にしている
• APIから受け取るデータの型を定義し、画面側で推測に頼らない
• vue-tscによる型チェックをCIで実行し、型の崩れを本番前に止めている
• テンプレートの中の式も型チェックの対象になることを理解している

開発サーバーが型エラーで止まらないため、「動いているから大丈夫」と型エラーが残ったままのプロジェクトも見られます。型チェックの仕組みを整えた経験は、チームの品質を上げた実績として伝えられます。TypeScriptそのものの評価のされ方はTypeScriptの案件で求められるスキルで解説しています。

Nuxtを使う案件で問われること

Nuxtの案件では、Vue.jsの知識に加えて、どこで画面を描画するかの理解が問われます。サーバー側で描画するか、ブラウザで描画するか、あらかじめ静的に作っておくかによって、表示の速さ、検索エンジンへの見え方、サーバーの負荷が変わります。

• データの取得をサーバー側とブラウザ側のどちらで行うかを、画面ごとに決めた経験
• サーバーとブラウザで表示が食い違う不具合（ハイドレーションの不一致）を調べて直した経験
• ルーティングやミドルウェアで、ログインの有無による画面の出し分けを作った経験

Nuxtの公式ブログでは、Nuxt 4のリリースにあわせて、Nuxt 3の保守は2026年1月末までと案内されています。Nuxt 3からNuxt 4への更新、さらに古いNuxt 2からの移行は、運用中のサービスで続いている作業です。どの版で何を作ったかは、スキルシートで書き分けておきましょう。

画面まわりの周辺スキル

フレームワーク以外にも、Vue.jsの案件でよく求められるスキルがあります。

• フォーム：入力の検証、エラー表示、送信中の二重送信の防止。管理画面や業務アプリの案件で特に多い
• UIライブラリ：既存のUIライブラリを使いつつ、デザインに合わせて調整する力
• 表示の速さ：大きな一覧の描画、不要な再描画の削減、読み込みの分割
• アクセシビリティ：キーボードでの操作、読み上げへの配慮
• テスト：Vitestなどでのcomposableや部品のテスト

バックエンドと兼ねる案件では、LaravelやRailsとのAPIの仕様のすり合わせも求められます。PHP側のスキルはPHPの案件で求められるスキルも参考になります。

経験の段階ごとに伸ばしたいスキル

ReactとVue.jsの両方の案件を検討している方は、Reactの案件で求められるスキルと比べると、共通する部分と違う部分が見えてきます。

スキルシートと面談での示し方

Vue.jsのスキルシートでは、プロジェクトごとに次の点を書くと、案件側が経験を判断しやすくなります。

• Vue.jsとNuxtの版、Options APIとComposition APIのどちらか
• 状態管理（Pinia、Vuex）とUIライブラリ
• 担当した画面や機能と、設計に関わった範囲
• 型チェック、テスト、CIなど品質の仕組みに関わったか
• 工夫した点と結果（再描画の削減、共通部品化による修正箇所の減少など）

面談では、担当した画面の構成を口頭で説明できるように準備しておくと、理解の深さが伝わります。書き方の詳細はVue.jsのスキルシートの書き方、面談の質問への備え方は面談でよく聞かれる質問をご覧ください。

よくある質問

Vuexの経験しかありませんが、Piniaの案件に入れますか？

ストアの考え方は共通する部分が多いため、Vuexでの経験は土台として伝えられます。ただ、Piniaは書き方やTypeScriptとの相性が違うため、小さなアプリでPiniaを使ってみて、Vuexとの違いを説明できるようにしておくと安心です。既存のVuexをPiniaへ移す案件では、両方を知っていることが強みになります。

Nuxtの経験は必須ですか？

管理画面や業務アプリでは、Nuxtを使わずにVue.jsとViteで作る構成も多く、必須ではない案件もあります。一方、一般向けのサービスで表示の速さや検索への配慮が求められる案件では、Nuxtの経験が条件になることがあります。応募する案件の構成を確かめて準備しましょう。

テストを書いた経験がないと不利ですか？

テストの経験を条件にしない案件もありますが、チームで開発する案件では評価の差になりやすい部分です。composableのような画面に依存しない処理からテストを書き始めると取り組みやすく、面談でも話しやすい経験になります。