はじめに こんにちは、株式会社タイミーでプロダクトAIエンジニアとして働いている貝出です。直近は、タイミーの求人内容などのコンテンツモデレーションにLLMを利用した、システム開発や性能改善を行っています。 2026年3月9日（月）〜3月13日（金）に開催された「言語処理学会第32回年次大会（NLP2026）」に、今年は初めて現地参加しました。大会2日目は記録的な大雪に見舞われ、会場にたどり着くだけでひと苦労でしたが、それでも現地ならではの熱気は格別で、ポスター発表や他社エンジニアとの立ち話など、オンライン

金融システムは、一度の障害が社会的な信用失墜や利用者の資産毀損に直結する「社会基盤」です。 そのため、メガベンチャーのようなスピード感が重視される環境であっても、他業界とは比較にならないほど厳格な品質管理と統制が求められます。 しかし、現場では「チームごとにテスト方針がバラバラ」「膨大なExcel管理が破綻している」「監査対応が形骸化し、現場が疲弊している」といった課題に直面しているQAマネージャーも少なくありません。 QAが開発のボトルネックではなく、事業成長の中核として機能するためには、部分最適から脱

こんにちは、セーフィーのリアーキ推進Gの金成と申します。 今回は、自分たちのチームで開発している認証サーバーのデプロイ改善について話させてください。 課題感 認証サーバーのリリースは、影響するサービスが多く、より安全にリリースすることが求められていました。具体的には、下記のような課題がありました。 意図せずに破壊的な変更がリリースされる可能性がある 本番のみで発生するエラーを事前に検出できない可能性がある 影響範囲をコントロールできるようにしたい etc こういった課題を解決するために、まず安全にリリース

こんにちは。LINEヤフー研究所でヒューマンコンピュータインタラクション（HCI）分野の研究をしている山中です。クラウドソーシングで収集したデータを使って、とても精度が良いとされているモデルに当てはめ...

メガベンチャー規模のプロダクトにおいて、マイクロサービス化や頻繁なシステム刷新が進む中、QA（品質保証）の現場では「本番環境でしか起こり得ない不具合」をいかに未然に防ぐかが共通の課題となっています。 従来のステージング環境でのテストだけでは、複雑に絡み合うデータパターンやリアルなユーザー負荷を完全に再現するには限界があるからです。 そこで注目されているのが「シャドウテスト（トラフィック・シャドーイング）」です。 本番トラフィックを複製し、ユーザー体験を損なうことなく裏側で新システムの挙動を検証するこの手法

メガベンチャーのように急成長を遂げる組織において、複数プロダクトやマイクロサービスが絡み合う複雑なシステムを管理する際、避けて通れないのが「予期せぬ不具合」への対応です。 各チームが個別最適でQAを進めていると、リリース直後に思わぬ境界条件で障害が発生し、手戻りやサービス停止を招くリスクが高まります。 そのリスクの正体こそが「エッジケース」です。 エッジケースは、通常の利用シーンでは滅多に遭遇しない極端な条件を指しますが、大規模サービスにおいては「万が一」が必然的に発生します。 QAマネージャーや品質推進

本記事は 2026 年 3 月 11 日 に公開された「 Amazon Redshift DC2 migration approach with a customer case study 」を翻訳したものです。 この記事は、AWS パートナーである Classmethod のソリューションアーキテクト、石川 覚氏によるゲスト投稿です。 2025 年 4 月、AWS は Amazon Redshift DC2 インスタンスの廃止を発表し、Redshift RA3 インスタンスまたは Redshi

今回は、 第5回の「営業」の回 に続き、再び「幕間」として、技術とは少し異なる、しかしQAエンジニアにとっては避けて通れないテーマについてお話しします。 そのテーマとは、「品質」です。 QAエンジニアと名乗る以上、「品質」という言葉は常に私たちの隣にあります。 私はこの言葉をなんとなく分かった気で使っていました。 そして、(今となっては幸いなことに)あるタイミングで、この言葉を明確に言語化する必要に迫られました。 その過程で出会ったのが、TQMという品質マネジメントに関わる包括的な方法論です。 私自身、T

こんにちは。Data Platform部に専任QAとしてジョインし、現在QAチームの立ち上げに奮闘しているokanです。 皆さんはQAチームの立ち上げと聞いて、どのような状況を想像しますか？ 「テストが全くない無法地帯に秩序をもたらす」「バグだらけのプロダクトを立て直す」…。 私も最初はそんな火消しのようなミッションを想像し、「これまでの経験を活かして、バリバリテストを回すぞ！」と意気込んでいました。 しかし、いざData Platformチームに入ってみると、そこには嬉しい想定外が待っていたのです。 今

PSSLの佐々木です。 E2Eテストは重要だとわかっていても、Playwrightのコードを書くのが面倒で後回しにしていませんか？ 本記事では、 Markdownファイルに日本語で操作手順を書くだけで、Playwrightが自動実行してくれるE2Eテストフレームワーク の作り方を、実際のプロダクション事例をもとに解説します。 この記事でわかること Markdownシナリオ駆動のE2Eテストの全体アーキテクチャ 自然言語ステップをPlaywrightアクションに変換する仕組み フォーム入力の多段フォールバッ

ども！気になった単語や技術をAIにぶち込み続けている龍ちゃんです。 Xを眺めていると、知らない単語が流れてきますよね。「ふーん、なんか面白そう」で終わって、次の瞬間には忘れている。みんなもそういう経験ないですか？ 自分もずっとそうで、Draw.ioのMCPが1ヶ月ほど「気になるリスト」に眠ったままでした。 ある日、Claude Codeで検索のSKILLを作ったんです。そしたら効率が爆上がりです。やったことは「気になった単語をぶち込んだ」だけなのに。 実際にやっている手法の紹介です。 Claude Cod

急成長を続けるメガベンチャーの現場では、プロダクトの多角化や組織の拡大に伴い、ある深刻な課題が浮き彫りになります。 それは、チームごとにテスト方針や管理手法が異なる「品質管理の分断」です。 「あるチームはExcel、別のチームはNotionで管理し、バグ報告だけがJiraに集まってくる」 このような状況では、プロダクト横断での品質担保は難しく、QAマネージャーは現場との板挟みや、リリース直前の予期せぬ障害対応に追われることになります。 個別最適の限界を超え、QAを「ボトルネック」から「価値創出の基盤」へと

急成長を遂げるメガベンチャー企業のQAマネージャーにとって、組織の拡大は誇らしい反面、深刻な「品質管理の分断」という課題を突きつけてきます。 プロダクト数が増え、マイクロサービス化が進むなかで、チームごとにテスト方針や運用ルールがバラバラになり、全体像が見えないまま障害や手戻りが増えていく。 そんな状況に限界を感じている方は少なくないはずです。 個別最適の改善では、もはやスピードと品質を両立させることはできません。 今求められているのは、テスト管理ツールを軸としたAPI連携による「品質データの民主化」と「

こんにちは。タイミーでPlatform Engineeringグループのマネージャーを務める橋本（ @kaz-under-the-bridge ）です。 2026年1月26日〜28日の3日間、AWS様と共同で AI-DLC Unicorn Gym （以下UG）を開催しました。私はタイミー側のカウンターパートとして、企画・準備から当日の運営、振り返りまでを担当しました。 AI-DLC（AI-Driven Development Life Cycle）は、要件定義からリリースまでの開発プロセス全体にAIを深く

.entry .entry-content .table-of-contents > li > ul { display: none; } はじめに こんにちは、グローバルシステム部フロントエンドブロックの林です。 私が所属するチームでは ZOZOMETRY というBtoBサービスを開発しています。スマートフォンで身体を計測し、計測結果を3Dモデルやデータとして可視化・Web上で管理できるサービスです。 私たちのチームではAIにユニットテストを書かせ、マージまでの過程を改善する施策を実施しました。結果とし