「顧客志向を当たり前に」AI接客プラットホームのPdMを募集

時給 4,000円 ~ 5,500円
雇用形態: 副業転職(業務委託から正社員)
勤務地:
Vuex
の転職・求人情報
1~20件(61件)

時給 4,000円 ~ 5,500円
雇用形態: 副業転職(業務委託から正社員)
勤務地:

年収 800万円 ~ 1,000万円
雇用形態: 正社員
勤務地:

時給 1,500円 ~ 3,000円
雇用形態: 業務委託
勤務地:

時給 4,000円 ~ 8,000円
雇用形態: 業務委託
勤務地:

時給 4,700円 ~ 5,200円
雇用形態: 業務委託
勤務地:

時給 4,000円 ~ 6,200円
雇用形態: 業務委託
勤務地:

時給 4,700円 ~ 5,200円
雇用形態: 業務委託
勤務地:

時給 4,000円 ~ 6,000円
雇用形態: 業務委託
勤務地:

時給 4,000円 ~ 6,200円
雇用形態: 業務委託
勤務地:

時給 4,000円 ~ 6,500円
雇用形態: 業務委託
勤務地:

年収 700万円 ~ 900万円
雇用形態: 正社員
勤務地:

時給 4,000円 ~ 6,200円
雇用形態: 業務委託
勤務地:

時給 4,100円 ~ 6,300円
雇用形態: 業務委託
勤務地:

時給 4,700円 ~ 5,200円
雇用形態: 業務委託
勤務地:

時給 4,000円 ~ 6,200円
雇用形態: 業務委託
勤務地:

時給 5,000円 ~ 8,500円
雇用形態: 業務委託
勤務地:

時給 5,000円 ~ 8,500円
雇用形態: 業務委託
勤務地:

時給 5,000円 ~ 8,500円
雇用形態: 業務委託
勤務地:

時給 5,000円 ~ 8,500円
雇用形態: 業務委託
勤務地:

時給 5,000円 ~ 8,500円
雇用形態: 業務委託
勤務地:


アカウントを作成して、求人情報のブックマークや応募の管理ができます。
求人に関するサマリ
Vuexは、Vue.jsアプリケーションのための状態管理パターンとライブラリです。大規模なシングルページアプリケーション(SPA)の開発において、データの流れを一元管理し、予測可能な方法でアプリケーションの状態を変更するための仕組みを提供します。Vuexを使うことで、複雑なアプリケーションの開発がより簡単になり、保守性も向上します。
Vuexの中核となる考え方は、アプリケーション全体で共有される「単一の真実の源」としてのストアを持つことです。このストアには、アプリケーションの状態(state)が格納され、特定のルールに従ってのみ変更できるようになっています。これにより、データの一貫性が保たれ、バグの発生を抑えることができるんです。
Vuexを使うと、コンポーネント間のデータの受け渡しが簡単になります。親子関係にないコンポーネント間でデータを共有する場合、従来のVue.jsでは複雑な prop の受け渡しが必要でしたが、Vuexを使えばストアを介して簡単にデータを共有できるようになります。これって、結構便利じゃないですか?
Vuexを使う理由はいくつかありますが、主に以下の点が挙げられます。まず、アプリケーションの規模が大きくなるにつれて、コンポーネント間のデータのやり取りが複雑になります。Vuexを使えば、この複雑さを大幅に軽減できるんです。
次に、Vuexを使うことで、アプリケーションの状態管理が一元化されます。これにより、デバッグが容易になり、アプリケーションの動作を予測しやすくなります。例えば、時間旅行デバッグという機能を使えば、状態の変更履歴を追跡し、特定の時点の状態に戻ることができます。これ、めちゃくちゃ便利ですよね。
さらに、Vuexはリアクティブなデータ管理を提供します。ストアの状態が変更されると、その状態を使用しているすべてのコンポーネントが自動的に更新されます。これにより、データの一貫性が保たれ、ユーザーインターフェースとデータの同期が簡単になります。
Stateは、Vuexの中心的な概念の一つです。これは、アプリケーション全体で共有される単一のオブジェクトで、アプリケーションの「状態」を表します。Vuexを使用する際、このStateが唯一の信頼できるデータソースとなります。
Stateは、アプリケーションの様々なデータを保持します。例えば、ユーザー情報、商品リスト、設定など、アプリケーション全体で使用されるデータがここに格納されます。Stateは読み取り専用であり、直接変更することはできません。これにより、データの整合性が保たれるんです。
Stateの値をコンポーネントで使用する際は、computed プロパティを通じてアクセスするのがベストプラクティスです。こうすることで、Stateの変更を監視し、変更があった場合に自動的にビューを更新できます。便利でしょ?
Mutationsは、Stateを変更するための唯一の方法です。これは、Stateを直接変更するのではなく、Mutationsを通じて変更することで、Stateの変更を追跡しやすくし、アプリケーションの動作を予測可能にします。
Mutationsは同期的な操作のみを行うべきです。これは、各Mutationの前後の状態を正確に追跡するためです。非同期操作を行うと、状態の変更タイミングが予測できなくなり、デバッグが困難になる可能性があります。
Mutationsは、タイプ(文字列)とハンドラ(関数)のペアで定義します。ハンドラは第一引数としてStateを受け取り、必要に応じて追加の引数(ペイロード)を受け取ることができます。これにより、Stateの変更を明示的に行うことができるんです。
Actionsは、Mutationsをコミットするためのメソッドです。Mutationsが同期的な操作のみを行うのに対し、Actionsは非同期操作を含む複雑な処理を行うことができます。これにより、アプリケーションのロジックをActionsに集中させることができます。
Actionsは、コンテキストオブジェクトを第一引数として受け取ります。このコンテキストオブジェクトを通じて、StateやGetters、他のActionsにアクセスしたり、Mutationsをコミットしたりすることができます。非同期処理の結果に基づいて、複数のMutationsをコミットすることも可能です。
Actionsは通常、コンポーネントから dispatch メソッドを使って呼び出されます。例えば、APIリクエストを送信し、その結果に基づいてStateを更新するような処理は、Actionsで行うのが適切です。これって、結構便利じゃないですか?
Gettersは、Stateから派生したデータを取得するためのメソッドです。これは、Vueコンポーネントの computed プロパティに似た概念で、Stateの値を加工して返すことができます。Gettersを使うことで、複数のコンポーネントで同じ計算ロジックを再利用できます。
Gettersは、第一引数としてStateを受け取り、オプションで第二引数として他のGettersを受け取ることができます。これにより、複雑な計算や、他のGettersに依存する計算を行うことができます。Gettersの結果はキャッシュされ、依存する値が変更されたときのみ再計算されます。
Gettersを使用することで、コンポーネントのロジックを簡素化し、ビジネスロジックをストアに集中させることができます。例えば、商品リストから特定の条件に合う商品だけをフィルタリングする処理などは、Gettersで行うのが適切です。これにより、コードの再利用性が高まり、保守性も向上します。
Vuexを導入するには、まずプロジェクトにVuexをインストールする必要があります。npm(Node Package Manager)を使用している場合、以下のコマンドでVuexをインストールできます。
npm install vuex@next --save
Vuexをインストールしたら、Vueアプリケーションにストアを追加します。通常、src ディレクトリに store ディレクトリを作成し、その中に index.js ファイルを作成します。このファイルで、Vuexストアを定義し、エクスポートします。
ストアを作成したら、mainアプリケーションファイル(通常は main.js)でストアをインポートし、Vueインスタンスに追加します。これにより、アプリケーション全体でVuexストアが利用可能になります。結構簡単でしょ?
Vuexを使用する際の一般的なディレクトリ構成は以下のようになります。この構成は、プロジェクトの規模や要件に応じて柔軟に変更できます。
src/ store/ index.js state.js mutations.js actions.js getters.js modules/ module1.js module2.js components/ views/ App.vue main.js
この構成では、store ディレクトリ内に Vuex に関連するファイルを配置しています。index.js がメインのストアファイルとなり、state.js、mutations.js、actions.js、getters.js にそれぞれの機能を分離しています。大規模なアプリケーションでは、modules ディレクトリを作成し、機能ごとにストアをモジュール化することもあります。
この構成を採用することで、コードの見通しが良くなり、保守性が向上します。また、チーム開発の際にも、役割分担がしやすくなります。ただし、小規模なプロジェクトでは、すべての機能を index.js にまとめて記述することもあります。プロジェクトの規模や要件に応じて、適切な構成を選択することが大切です。
Vuexを使用したシンプルなカウンターアプリの実装例を見てみましょう。このカウンターアプリでは、ボタンをクリックしてカウントを増減させ、その状態をVuexで管理します。まずは、ストアの設定から始めます。
ストアのindex.jsファイルでは、stateにcountプロパティを定義し、mutationsでincrement、decrementメソッドを作成します。actionsでは、これらのmutationsをコミットするメソッドを定義します。また、現在のカウント値を取得するgetterも作成します。
コンポーネント側では、mapState、mapGetters、mapActionsヘルパーを使用して、ストアの状態やメソッドをコンポーネントにマッピングします。テンプレート部分では、カウント値の表示と、増減ボタンを配置します。このようにして、Vuexを使用したシンプルなカウンターアプリが実装できます。簡単ですよね?
より複雑なアプリケーションでは、Vuexの真価が発揮されます。例えば、ECサイトのショッピングカート機能を考えてみましょう。この場合、商品リスト、カート内の商品、ユーザー情報など、複数の状態を管理する必要があります。
ストア内では、productsモジュール、cartモジュール、userモジュールなど、機能ごとにモジュールを作成します。各モジュールには、それぞれのstate、mutations、actions、gettersを定義します。例えば、cartモジュールには、カートに商品を追加する、削除する、数量を変更するなどのアクションを実装します。
コンポーネント側では、必要な状態やアクションをマッピングして使用します。商品一覧ページでは商品をカートに追加するアクションを、カートページではカート内の商品を操作するアクションを使用します。このように、Vuexを使用することで、複雑なデータフローも整理され、管理しやすくなります。便利でしょ?
Vuexには多くの利点があります。まず、アプリケーションの状態を一元管理できることが大きな特徴です。これにより、データの流れが明確になり、デバッグが容易になります。例えば、Vueの開発者ツールを使用すると、状態の変更履歴を追跡できます。これって、開発効率を大幅に向上させますよね。
次に、コンポーネント間のデータ共有が簡単になります。従来のVueでは、親子関係にないコンポーネント間でデータを共有する場合、複雑なpropsの受け渡しが必要でした。Vuexを使えば、ストアを介して簡単にデータを共有できます。これにより、コードの可読性と保守性が向上します。
さらに、Vuexはプラグインを通じて機能を拡張できます。例えば、ローカルストレージとの同期や、ログ出力などの機能を簡単に追加できます。これにより、アプリケーションの要件に合わせて柔軟にカスタマイズできるんです。
一方で、Vuexにはいくつかの欠点も存在します。まず、小規模なアプリケーションでは過剰な設計になる可能性があります。Vuexの導入には一定の学習コストがかかるため、単純なアプリケーションでは、通常のVueの機能で十分な場合もあります。
また、Vuexを使うと、ボイラープレートコードが増える傾向があります。状態の変更には必ずmutationsを経由する必要があり、これが冗長に感じられることもあります。特に、小さな状態変更の度にactionsやmutationsを定義するのは面倒に感じる人もいるでしょう。
さらに、Vuexは非同期処理の扱いが少し複雑です。actionsを使用して非同期処理を行う必要がありますが、この概念の理解に時間がかかる場合があります。初心者にとっては、この部分が躓きのポイントになることもあるんです。
Vuexは強力なツールですが、すべてのプロジェクトで必要というわけではありません。では、どのような場合にVuexを使うべきなのでしょうか。まず、アプリケーションの規模が大きく、多くのコンポーネントが存在する場合は、Vuexの使用を検討すべきです。
また、複数のビューで同じ状態を参照・更新する必要がある場合も、Vuexが有効です。例えば、ユーザー情報やショッピングカートの内容など、アプリケーション全体で共有される状態がある場合は、Vuexを使用するのが適切です。
さらに、複雑な状態の変更ロジックがある場合も、Vuexを使うことで管理が容易になります。例えば、APIとの通信結果に基づいて複数の状態を更新する必要がある場合などです。Vuexを使えば、このような複雑な処理も整理して実装できるんです。
Vuexのストアが大きくなってくると、すべての状態や操作を1つのファイルで管理するのが困難になってきます。そこで、ストアをモジュール化することが重要です。モジュール化によって、関連する状態や操作をグループ化し、コードの見通しを良くすることができます。
モジュール化の一般的な方法は、機能やドメインごとにモジュールを作成することです。例えば、ユーザー関連の状態を管理する「userモジュール」、商品関連の状態を管理する「productモジュール」などです。各モジュールは、独自のstate、mutations、actions、gettersを持つことができます。
また、大規模なアプリケーションでは、モジュールをさらにサブモジュールに分割することも可能です。この階層構造により、複雑な状態管理も整理して実装できます。ただし、過度に細分化しすぎると、かえって複雑になる可能性があるので、適度なバランスが大切です。
Vuexにおける非同期処理の扱いは、初心者にとってしばしば難しい部分です。基本的に、非同期処理はactionsで行います。actionsは、非同期処理の結果に基づいて、複数のmutationsをコミットすることができます。
非同期処理を実装する際は、Promiseやasync/awaitを活用すると良いでしょう。例えば、APIリクエストを送信し、その結果に基づいて状態を更新する場合、以下のような流れになります:
1. コンポーネントからactionをdispatchする 2. actionでAPIリクエストを送信する 3. リクエストの結果を受け取ったら、mutationをコミットして状態を更新する 4. 更新された状態がコンポーネントに反映される
また、複雑な非同期処理を行う場合は、action内で他のactionをdispatchすることも可能です。こうすることで、処理を小さな単位に分割し、再利用性を高めることができます。
Vuexを使用する際、効果的なデバッグとテストは非常に重要です。まず、Vue Devtoolsを活用することをお勧めします。Vue DevtoolsはVuexと連携しており、状態の変更履歴やTimetravel Debuggingなど、強力なデバッグ機能を提供します。
テストに関しては、Vuexのストアの各部分(state、mutations、actions、getters)を個別にユニットテストすることができます。特に、mutationsは純粋な関数であるため、テストが比較的容易です。actionsのテストでは、モック(模擬)オブジェクトを使用して、外部のAPI呼び出しなどをシミュレートすることができます。
また、Vuexには「厳格モード」(strict mode)があります。このモードを有効にすると、mutationを介さない状態の変更を検出し、警告を発します。開発中はこのモードを有効にし、本番環境では無効にすることで、意図しない状態の変更を防ぐことができます。
ReduxはReact用の状態管理ライブラリですが、VuexとReduxには多くの共通点があります。両者とも単一の真実の源(single source of truth)を持つことを基本としています。しかし、いくつかの重要な違いもあります。
Vuexは、Vue.jsに特化して設計されています。そのため、Vueのリアクティブシステムとシームレスに統合されており、使用感がよりスムーズです。一方、Reduxは、より汎用的で、React以外のフレームワークでも使用できます。
また、Vuexではmutationsとactionsが明確に分離されていますが、Reduxではこれらが一つのreducerという概念にまとめられています。Vuexの方が初心者にとっては理解しやすい構造になっているかもしれません。
MobXは、Observable(観察可能)なデータに基づいた状態管理ライブラリです。VuexとMobXの主な違いは、アプローチの違いにあります。Vuexが明示的で規律的なアプローチを取るのに対し、MobXはより柔軟で自由度の高いアプローチを取ります。
Vuexでは、状態の変更は必ずmutationsを通して行う必要があります。一方、MobXでは、状態を直接変更することができます。これにより、MobXの方がボイラープレートコードが少なくなる傾向があります。
また、VuexがVue.jsに特化しているのに対し、MobXはフレームワーク非依存です。そのため、MobXは様々なJavaScriptフレームワークと組み合わせて使用できます。ただし、Vue.jsとの統合度という点では、VuexがMobXよりも優れています。
Piniaは、Vue.js向けの次世代状態管理ライブラリとして注目を集めています。実際、Vue 3の公式状態管理ライブラリとして採用されました。PiniaはVuexの後継として位置付けられており、Vuexの概念を踏襲しつつ、いくつかの改善が加えられています。
Piniaの大きな特徴は、Vuexのmutations概念がなくなり、actionsで直接状態を変更できるようになったことです。これにより、ボイラープレートコードが減少し、より直感的な使用感が得られます。また、TypeScriptとの親和性も高く、型推論が優れています。
さらに、Piniaではストアの分割がより簡単になりました。Vuexのようにネストされたモジュールを定義する必要がなく、各ストアを独立して定義できます。これにより、コードの見通しが良くなり、保守性が向上します。
ただし、VuexからPiniaへの移行には一定の学習コストがかかります。既存のVuexプロジェクトがある場合、すぐに移行する必要はありませんが、新規プロジェクトではPiniaの使用を検討する価値があるでしょう。Vuexの概念を理解している開発者なら、比較的容易にPiniaに移行できるはずです。
結局のところ、どの状態管理ライブラリを選択するかは、プロジェクトの要件や開発チームの経験、好みによって異なります。Vuexは安定性と豊富な実績があり、大規模なVue.jsプロジェクトで広く使用されています。一方で、PiniaやMobXなどの新しいライブラリは、より簡潔な記述や高いパフォーマンスを提供しています。プロジェクトの特性を考慮し、最適なライブラリを選択することが重要です。
エンジニア、PM、デザイナーの副業・転職採用サービス「Offers(オファーズ)」では、非公開求人を含む豊富なIT・Web業界の転職・副業情報を提供しています。高年収の求人・高時給の案件や最新技術スタックを扱う企業など、あなたのスキルを最大限に活かせるポジションが見つかります。専任のキャリアアドバイザーが、入社日調整や条件交渉をきめ細かくサポート。転職・正社員求人、副業・業務委託案件、募集をお探しの方はOffersまでご相談ください。閉じる
.png)
開催前
AIコーディングエージェントを活用する中で、「管理しているドキュメントをAIエージェントから参照させたいがうまいやり方がわからない」「複数のAIエージェントにプロンプトやコンテキストが散らばっていて、管理が大変」と感じているエンジニアも多いのではないでしょうか。 実際、複数のツールに情報が分散していると、AIエージェントが古いドキュメントや重複した情報を参照してしまい、意図しない実装が生まれる原因となります。特に、NotionやGitHub Wiki、個人のメモツールなど、ドキュメントが増えるほど「どれが最新で正しい情報なのか」がAIにも人間にも判断できなくなってしまいます。 そこで本イベントでは、実際にAIフレンドリーなドキュメント管理を実践されている松濤Vimmer氏とPochiPochi氏をお招きし、AIエージェントを用いた開発を加速させるためのドキュメント管理術を語っていただきます。 松濤Vimmer氏からはObsidianを中心とした情報整理アーキテクチャと、10年以上続くプロダクトでも信頼できるドキュメントをどう維持するか、PochiPochi氏からはGitHub WikiやCIを活用した自動更新の仕組みと、チーム全体でドキュメント管理を浸透させる工夫を学べる貴重な機会です。 ぜひご参加ください。 👇登壇者の方の記事を事前にチェック 松濤Vimmer氏 単なるメモから知的資産へ:Obsidian in Cursorで構築する知的生産システム https://note.com/shotovim/n/n5833578984bf ぽちぽち氏 スピードと品質を両立する、AI時代の開発ドキュメント戦略 https://tech.techtouch.jp/entry/aic-document-strategy

アーカイブ公開中
昨今、AIコーディングエージェントやプロトタイピングツール(v0, boltなど)のの進化により、誰でも短期間でプロダクトを構築できる時代になりつつあります。しかし同時に、生成AIは「動くコード」を優先する傾向があり、セキュリティの観点が抜け落ちたままリリースされるサービスも急増しています。特に個人開発者や非エンジニアの参入が進む中、ハッカーから狙われやすい脆弱なサービスが量産されている現実があります。 そこで本イベントでは、延べ1万件の個人情報漏洩を発見・報告した経験を持つKyohei氏をお招きし、バイブコーディング時代に必須となるセキュリティの落とし穴と対策を探ります。実際の個人情報漏洩事例から、SupabaseやFirebaseなどBaaSを使った開発における具体的な対策、そしてkyohei氏が開発するSupabase RLS Checkerなどのセルフチェックツールの開発秘話まで、明日から実践できる知識を学べる貴重な機会です。 ぜひご参加ください。
開催日:
2025年10月7日(火)19:00~20:00

アーカイブ公開中
フロントエンド開発でフレームワークを選ぶ際、「Next.jsとNuxtの違いや特徴までは理解できないまま、とりあえずで選んじゃっているな」と感じているエンジニアも多いのではないでしょうか。 実際には、開発チームの構成や要件によって、Nuxtの方が適している場面も、はたまたNext.jsの方が適している場面も存在します。特に最近では、Nuxtに対する業界の注目度も今まで以上に高まってきています。 そこで本イベントでは、実際にNext.js・Nuxt両方の開発経験を持つエンジニアの方々をお招きし、なぜNuxtに投資するのか?なぜNext.jsに投資するのか?をお二人の立場から語っていただきます。 LayerXのypresto氏からは実際にNextとNuxtを同時運用して経験した互いの良さやツラミ、Next.jsを推進する理由を、アンドパッドの小泉氏からはVueやNuxtのエコシステムの現状や、Nuxtを推進する理由を学べる貴重な機会です。 ぜひご参加ください。 👇登壇者の方の記事を事前にチェック ■ アンドパッド 小泉氏 新規プロダクトの開発に Nuxt 3 を採用して良かったこと https://tech.andpad.co.jp/entry/2024/01/17/100000 ■ LayerX ypresto氏 Next.jsとNuxtが混在? iframeでなんとかする! https://speakerdeck.com/ypresto/nuxt-inside-nextjs-with-iframe
開催日:
2025年9月30日(火)19:00~20:00

アーカイブ公開中
CloudRunは個人開発やPoC開発での採用が増えている一方で、中規模・大規模での運用事例が少なく感じている方も多いのではないでしょうか。特にCloudRunで構築したアプリケーションが成長し、複数サービスが立ち上がってきた際に「このまま長期運用できるのか?」「いつKubernetesに移行すべきか?」といった疑問を抱いているエンジニアも少なくないはず。 そこで本イベントでは、Google Cloud Japanの頼兼氏、実際にZennでCloudRunを運用している和田氏お招きし、長期運用を見据えたアーキテクチャパターンと運用ノウハウを探ります。 Google Cloud Japan の頼兼氏からは最新のCloudRun機能アップデートと長期運用にも耐えうる代表的なアーキテクチャ事例を、クラスメソッド 和田氏からはZennにおける実際の運用で得た知見とベストプラクティスを学べる貴重な機会です。 ぜひご参加ください。 👇登壇者の方の記事を事前にチェック 和田さん Zennのバックエンドを Google App Engine から Cloud Run へ移行しました https://zenn.dev/team_zenn/articles/migrate-appengine-to-cloudrun
開催日:
2025年9月25日(木)12:00~13:00
.jpg)
アーカイブ公開中
MCPを含むAIの進歩は目覚ましく、多くのエンジニアが開発効率化への期待を抱いているでしょう。しかし実際には、全てを自動化するまでは難しいと感じている方も多いのではないでしょうか。特にフロントエンド開発におけるUI/UXは、結局手動での調整や再実装が必要で時間がかかってしまうと感じている方も多いはず。 そこで本イベントでは、実際にMCPを使ってUI/UXの実装を行っている2社の実践者をお招きし、AIで簡略化できる部分と、そうでない部分を探ります。デザインシステム「Spindle」を運用するサイバーエージェントのHara氏と、MCPで爆速デザイン開発を推進するUbieのCTO 小谷氏から、理論だけではなく、日々の業務の中でどのように活用し、どこに限界を感じているのかといったリアルな運用事例を学べる貴重な機会です。 ぜひご参加ください。 👇登壇社の方の記事を事前にチェック☑️ Ubie さん 社内デザインシステムをMCPサーバー化したらUI実装が爆速になった https://zenn.dev/ubie_dev/articles/f927aaff02d618/ サイバーエージェントさん Spindle MCP で変わるデザインシステムの開発 ~ Figma 連携で実現する超高速開発 ~ https://developers.cyberagent.co.jp/blog/archives/56844/
開催日:
2025年9月4日(木)19:00~20:15