こんにちは。 アソビューでフロントエンドエンジニアをやっています、白井です。 今回はフロントエンドをやっていく上で避けられないものの一つである、フォームバリデーションのお話です。 フォームバリデーションライブラリの React Hook Form と、バリデーションスキーマライブラリ Zod の組み合わせは扱いやすく便利なのですが、 バリデーションで使っているデータを後から動的に変化させたいようなシーンでは一手間加える必要があったため、今回はその方法を紹介したいと思います。 やりたいこと 実装方法の検討 ① Zod のスキーマとは別にバリデーションを行う ② React Hook Form にバリデーションに必要な情報を全て持たせる ③ React Hook Form では必要最低限の情報のみを持たせ、バリデーションで利用する動的なデータを zod のスキーマに渡す 実際の使用例 動的バリ

はじめに こんにちは、アソビューでフロントエンドエンジニアをしている村井です。 皆さんは、Sentryを使っていてエラーにノイズが多くて困ったことはありませんか？ 私のチームでも、Sentryを導入した際に同様の課題に直面しました。本記事では、このエラー通知のノイズを削減した方法とその効果について解説します。 Sentryを利用している方や、エラー監視の効率化を図りたい方の参考になれば幸いです。 カスタムフィルタリングが必要になった背景と課題 Sentryを導入した当初、私のチームでは想定以上のエラー通知が発生し、その多くが実際の問題解決には直結しないものでした。具体的には、以下のようなケースが頻発していました。 ユーザーの操作による意図的なエラー：フォームのバリデーションエラーや、アクセス権限がないページへの遷移など、ユーザーの操作によって発生するエラー 特定のAPIから頻発するエラー：

はじめに こんにちは、アソビュー株式会社でバックエンドエンジニアをしています竹村です。 ありがたいことにアソビューのサービスも長く続き、ご利用いただいているユーザーが増えるにしたがってデータも増え、SQLのパフォーマンス改善を行なうタスクが増えてきました。 今回はそんなSQLのパフォーマンス改善をしているなかで遭遇した問題とその対策について書こうと思います。 問題の概要と背景 パフォーマンス上問題がありそうなクエリを調査しているなかで、ごく一部のテーブルですが、数値であるべきカラムが誤って文字列型で定義されていたことがわかりました。 そしてこの型の不一致が原因で、SQLクエリの実行時にインデックスが効率的に利用できず、結果としてクエリのパフォーマンス低下を引き起こしていました。 問題の詳細 実際のテーブルとは大幅に変更、簡略化していますが、下記のような感じで本来user_statuses.

はじめに アソビュー株式会社の髙木です。 2023年に新卒でアソビューに入社し、現在はフロントエンドメインで新規プロジェクトの開発を行っています。 今回は新規プロジェクトを開発するうえでおこなった、フロントエンド周りのフレームワーク選定についてお話できればと思います。 技術的な話というより、「なぜ選んだのか」という点にフォーカスした話になっています。 背景 今年の3月から部署異動し、新規事業の開発を行うことになりました。 いきなり話はそれますが、実は入社してから携わるプロダクトすべてが新規事業で、貴重な経験をさせてもらっていると日々感じています。頑張るぞー！ 前部署は新規事業とはいえ、私がジョインしたタイミングではすでに技術選定も終わっていましたが、今回は全くのゼロからの開発なので、まず自分たちで最初に技術選定をする必要があり、私はフロントエンド周りのフレームワーク選定を担当しました。 要

こんにちは。QAエンジニアの丸山です。2023年12月にアソビューにジョインし、現在は自社サイトを中心としたQA業務を行っています。 弊社では以前にもQAチームの体制についての記事を公開していました。その中で、”QMファンネルのバランスは必要だが、そのロールに囚われすぎず、本質的な品質改善につながることを意識し実行する、変化にも強いQA実行を目指す”といったことが記載されていました。私が担当するサービスにおける役割がテストエンジニア（TE）だけでなくQAとしての活動を実行する転換期にあたり、その点について具体的な状況や取り組みをご紹介したいと思います。 ▼前回のQAチームの記事 QA体制の過去〜現在〜未来 - asoview! Tech Blog ▼その他過去のQAチームの記事 アソビュー！QAチームの紹介 - asoview! Tech Blog ◼︎担当プロダクトの現状 私が担当する個

はじめに チーム体制について スクラムの導入にあたって行ったこと スクラムガイド勉強会 スプリントゼロの実施 スプリントゼロで発生した各スクラムイベントの課題 バックログリファインメント エピック・ストーリーの粒度が不適切 仕様が不明確なため適切に見積もれない スプリントプランニング 適切なストーリーポイントの見積もりが難しい デイリースクラム 課題を持ち込むことでデイリーの時間が長引く デイリースクラムの目的を再確認 課題をデイリーの場に持ち込まない スプリントレトロスペクティブ 議論が弾まない TRYの形骸化 スプリントレビュー 成果が測れていない 成果への承認が低い おわりに 最後に はじめに こんにちは！アソビューでバックエンドエンジニア兼スクラムマスターをしている島田です！ 2023年12月にコンサートや舞台公演などの希望する座席を購入できる、座席指定システムをローンチしました。

こんにちは。Backendを担当している佐藤です。 今回Javaとは関係ない話になりますが、スマホの実機端末でテストするときにリクエストのヘッダー情報を編集する必要があったためどのように対応したかを書かせていただきます。 asoview!の一部のプロダクトではテスト環境が複数存在し、リクエストをヘッダー情報をもとにnginxで各環境へ振り分けています。 PCのブラウザ、たとえばChromeならModHeaderを使ってリクエスト情報の編集してテストをしていますが、今回実機の端末で動作確認しなければいけないことになったため調べてみました。 結論、HTTPプロキシツールをインストールして対応しました。 試してみる（セットアップ） 調べたところHTTPプロキシツールとしてCharlesとProxymanが使えそうと分かったので実際に試してみました。 大枠どちらのツールも以下の設定をおこないますが

目次 目次 はじめに 今回のおはなし 1回目に行った設計 設計詳細 結果 反省点 早くリリースしなきゃという焦りで設計が雑になった 設計書のレビューがしづらい 2回目に行なった設計 設計詳細 意識したこと ユーザーとのすり合わせを入念に行う 設計書をレビューしやすくする工夫 V字モデルの意識 結果 2回目の設計での反省点 さいごに はじめに こんにちは！2023年の新卒としてアソビューに入社した加藤です。プログラミング未経験からアソビューに参画し、現在はエンジニアとして開発業務に携わっています。 最近めっきり暑くなってきましたね...いや、もうね、暑過ぎますよ。日本はいつからアマゾン川流域になってん🥵 今回のおはなし さて、プログラミング歴2年目の私ですが、入社〜現在に至るまで2回の設計を行いました。 今回はそんな私が、設計の際に意識したことを書き留めようと思います。 1回目に行った設計

エンジニアの村松です。先日、自宅でバグを発見しました。リアルバグです。某 DB の名前にもなっているアレです。今もﾋﾞｸﾋﾞｸしながらこれを書いています。 はじめに さて、アソビューでは GitHub の Pull Request (以降、PR と書きます) を活用して開発を進めています。PR のレビューは、コードの品質担保や、(レビュイーの属人化を防止する目的も含めて) 仕様や設計を担当者以外が理解するために重要なプロセスであると考えています。 私自身、前職を含めてプロジェクトのリーダーを担うことが多く、PR をレビューする機会が多くありました。(油断すると1日で10件以上溜まることも...) これまでに多くの PR を見てきた中で、自分の中で自然と身に付いたルーティンのようなものがあるので紹介します。他の人が普段どうやって PR を見ているのか気になる方の参考になれば...。 いきなり

こんにちは。デザインリードを担当している山中です。 皆さん、毎日お仕事頑張れていますか？ 「いまやるべきことに集中！」できていますか？ 「あれもこれもやることがたくさん！」で、頭の中がごちゃついていませんか？ わたしは、年始ぐらいからプライベートでやることが膨大に増え、睡眠時間が2~3時間ぐらいしか確保できず、仕事にも影響が出始め業務生産性が低下していると感じる場面があり、改善するため試行錯誤しています。自分へのメモになりますが、参考になるかと思いますのでここに残します。 課題の見える化 現時点での課題や悩みを感情も含めて書いていく 改善できそうなこと ToDo管理、時間管理方法の見直し 脳の役割の見直し 通知管理方法の見直し よく利用するツールの見直し Arcをメインブラウザに！ perplexityで情報を調査！ まとめ 課題の見える化 まずは、課題の見える化を行いました。 現時点での

はじめに ローンチまでのプロジェクト管理 開発プロセス プロジェクトの運用課題 開発スコープの肥大化 変更にかかるコストが大きい 実際には多くの不確実性を内包していた プロジェクトマネジメント 1 → 10フェーズへの移行とスクラムの導入 スクラム 実感した成果 課題感 メンバーの意識の高さに依存する チーム運用が軌道に乗るまである程度時間が必要 プロダクトマネジメント プロダクトオーナー プロダクトオーナーになる プロダクトオーナーとは プロダクトオーナーの魅力 プロダクトマネージャーとの違い プロジェクトマネージャーとの違い プロダクトオーナーの仕事 要求分析・要件定義 プロダクトバックログの管理 スプリントゴールの設定 バックログリファインメント ステークホルダーの窓口 おわりに はじめに こんにちは。アソビューでプロジェクトマネージャー・プロダクトオーナーをやっております杉浦と申し

はじめに アソビュー株式会社の野上です。 1年半前にアソビューにジョインし、プロダクトマネージャーを担当しています。 今回は私が定期的に行っている振り返りのチェックリストを公開しようと思います。 背景 アソビューに入社して始めてプロダクトマネージャーを担当していること、過去ブログでも記載したのですが、30名弱の開発チームのマネジメントとステークホルダーが80名程の方とお仕事させてもらっているためプロダクトマネージャーとして自身が課題に向き合い改善しながら前進できているかをしっかり振り返りを行いたくセルフで振り返りリストを作成し定期的にチェックをしています。 ちなみにチェックリストについては、前述した過去ブログにてマネジメントについて項目整理をした際に合わせて検討したのといくつかの書籍を読んだ結果生まれたものです。 プロダクトマネージャーの振り返りチェックリストについて 振り返りリストはこち

アソビューのQAチームの紹介 過去〜現在のQA体制と、プロダクト成熟度の関係 現在のQA体制とQMファンネルの比較 インプロセスTEとスプリットTE これからのQA目標と方向性 インプロセスTE、QA目標 スプリットTE、QA目標 プロダクト成熟度や変化に応じた横断的なQA さいごに こんにちは。QAエンジニアの渡辺です。 1年半前にアソビューにジョインし、現在QAリーダーをさせていただいております。 過去のQAチームのブログを見ると様々な掲載があり、外から見て現在の体制が分かりにくいかと思いましたので、 一度、アソビューのQA体制の過去〜現在と、これからの方向性をまとめてみたいと思います。 アソビューのQAチームの紹介 アソビューのQAチームは、現在5〜6名で構成されています。 各プロダクトチームに1名〜2名ずつQAメンバが入っており、 横断的な業務を全員1割ほどしています。 過去〜現在

こんにちは。技術本部ウラカタ開発部のkaorun343です。フロントエンドエンジニアのチームでは継続的に開発環境の改善活動をおこなっています。今回はこの活動において実施した、React Routerのアップデート作業について紹介します。 はじめに 方針 移行ガイドにそって更新作業を実施する ESLintを用いる AST Grepについて ESLintを活用した移行作業 ルート定義の修正 <Switch> の中にある <Redirect> を除去 <Switch> の中にある <Route> 以外のコンポーネントの除去 コンポーネントの修正 route propsを利用している箇所の修正 最後に はじめに アソビューの社内向け管理画面はReact Routerを用いたシングルページアプリケーションとして構築しています。この管理画面アプリケーションは長らく依存パッケージの更新がなされていなかっ

アソビュー株式会社VPoEの @tkyshat です。 はじめに キャリア不確実性が高まっており、多くの人がキャリアの悩みを抱えています。日々の生活の中でも、自分の考えを行動に移す一歩が踏み出せないことがあります。前回は、このような悩みを解放する方法として「ネガティブ・ケイパビリティ」と「計画的偶発性理論」を取り上げました。 tech.asoview.co.jp 今回は続編として、技術広報を活用することで、コントロール不能なキャリア状況にどう対峙するかを探ります。 キャリアデザインに関してはキャリアというゲームの構造原理について｜山口周に記してある 時間資本を用いて人的資本を生み出し、人的資本によって社会資本を生み出し、社会資本によって金融資本を生み出すという、超長期にわたる投資の連鎖 という原理に基づいて書いていきます。 人的資本・社会資本・金融資本を形成していくことをキャリアデザインと

アソビューでVPoTをしているdisc99🐼です！ 今回は、弊社のSRE(Site Reliability Engineering)と、その役割を果たすSREs(Site Reliability Engineers)について紹介させて頂きます！ アソビューのSREsが向き合う課題 弊社は現在、複数のサービスを提供しており、これらのサービスは規模としても大きく成長しています。 サービス全体像 システム規模 これらの状況の中で向き合う課題も複雑化してきており、代表的なものを上げると以下のようなものがあります。 多数のサービスと複数チームの意思決定を支えるSLO、SLI構築のリード 一秒間に数千リクエストを処理するためのスケーラビリティの向上 年々成長し続けるサービス、増え続ける会員/施設、拡張していくシステムの可用性の強化 人気商品発売やセールなど偏るトラフィックに対するノイジーネイバー問題

これはアソビュー！ Advent Calendar 2023の25日目です🎅 今年のアドベントカレンダーは2面公開なので、ぜひそちらも御覧ください！ アソビューでVPoE兼Tech Leadをしているdisc99🐼です！ 今年のアドベントカレンダーは1日に技術的取り組みを紹介させてもらったので、最後の今日は組織的な取り組みの紹介をできればと思います🎁 はじめに 起こる問題 コミュニケーションパスの問題 組織構造の問題 多様性 変化への適応 目的 Holaspirit 期待する効果 可視化による効果 アップデートプロセスによる効果 最後に はじめに 現在アソビューでは、プロダクト開発を行っているプロダクト組織(*1)が110名、会社全体では300名(*2)を超えています。 また、中心事業であるマーケットプレイスやパートナープラットフォーム他、ギフトやふるさと納税などの新規事業を展開して

こちらの記事は、アソビューAdvent Calendar 2023の22日目(B面)です。 はじめに 座席指定システムとは 対応方針 1. 公演選択画面 2. エリア選択画面 3. 座席選択画面 4. 券種選択画面 5. 購入画面 まとめ We're hiring！ はじめに こんにちは！アソビュー株式会社でフロントエンドエンジニアをしている村井です。 先日、社内の輪読会でアクセシビリティについての本を読み、アクセシビリティとその重要性について学びました。それをきっかけとして、弊社でもアクセシビリティの改善をはじめています。 今回は開発中の座席指定システムにおける購入導線のアクセシビリティ改善について紹介します。 輪読会の詳細については、弊社の櫻井が先日投稿した記事をご覧ください。 tech.asoview.co.jp 座席指定システムとは 会場全体図や座席図などから任意の座席を選択し、チ

こんにちは！こちらの記事は、アソビューAdvent Calendar 2023の21日目(A面)です。 はじめに 要求分析 ユーザーストーリーマッピング ユースケース分析 要件定義 設計・開発 スクラム まとめ We're hiring！ はじめに アソビューでプロジェクトマネージャーをしている杉浦と申します。現在、この度弊社では興行領域にチャレンジすべく座席指定可能なSaas型のチケット販売システムの開発を行なっております！ 私自身興行領域のプロダクトに携わった経験がなく初めは何を作ればいいのかもわからない状態でした。しかし多くの方々の協力の元なんとかプロジェクトを立ち上げることができました。これもひとえに開発にご協力いただいた関係部署のお陰だと感じています。今回はプロジェクト立ち上げから上流工程〜プロダクト開発までの長い道のりを振り返ってみたいと思います。 要求分析 私がアソビュー入社

これは アソビュー！Advent Calendar 2023のB面 21日目です。 🎄 今年のアドベントカレンダーは2面公開なので、ぜひそちらも御覧ください。 エンジニアリングマネージャーの服部です。 昨今の生成AI登場に伴うエンジニア不要論によってキャリアクライシスに陥ったり、キャリアに対するどうしようもない不安に駆られてしまう人は少なくないのではないでしょうか。 この悩みや不安をネガティブ・ケイパビリティと計画的偶発性理論の観点から手放せるようになった話をします。 各理論について 計画的偶発性理論 計画的偶発性理論（Planned Happenstance Theory）は、心理学者のジョン・D・クランボルツ教授が提唱した理論です。 ビジネスパーソンとして成功した人のキャリアを調査したところ、ターニングポイントの8割が本人の予想しない偶然の出来事によるものだった、ということが理論提唱