2026年3月の主な製品アップデートをご紹介します。 製品アップデート Jira連携設定の操作性と可視性を強化 Jira連携の設定画面が刷新され、PractiTestに同期する対象やマッピング内容を、より明確にコントロールできるようになりました。 接続するJiraプロジェクトを選択できるほか、ワークアイテムの種類をPractiTest上の「要件」または「課題」としてどのように対応付けるかを定義できます。 これにより、実際の開発・テストのワークフローに沿った、よりシンプルで分かりやすい連携が実現します。 JiraスプリントをPractiTestのマイルストーンへ自動同期 JiraのスプリントをPractiTestのマイルストーンとして直接同期できるようになり、開発とテストの進行を一体的に管理できます。 進行中および今後のスプリントは自動的にマイルストーンとして作成され、関連する項目もあわせて取り込まれます。 また、スプリントの範囲に変更があった場合も、重複を生じさせることなくリアルタイムで反映されます。詳細は Jira Cloud または Jira Server のドキュメントを参照してください。 テストセット内の課題を一元的に把握 テストセットに追加された「Linked Issues」タブにより、そのセットに関連するすべての課題をまとめて確認できるようになりました。 テスト実行中に作成された不具合も、モジュールを切り替えることなく追跡できるため、可視性が向上し、テスト結果を文脈に沿って効率的にレビューできます。 詳しくは Test Sets & Runsのヘルプページ をご覧ください。 全プロジェクトへのグローバルフィールド適用（Corporateアカウント向け） アカウントオーナーは、すべてのプロジェクトに対してグローバルフィールドを強制適用できるようになりました。 これにより、大規模な環境でも一貫した構造とデータモデルを維持できます。 適用されたフィールドは各プロジェクト単位で削除できないため、アカウント全体でのデータ整合性の標準化に役立ちます。詳細は Global Fieldsのヘルプページ をご参照ください。 今後の予定 PractiTestライブトレーニング カスタマーサクセスチームによるライブセッションに参加し、MCPやAIを活用したテストワークフローについて学べます。 AIツールをPractiTestに接続する方法や、AIの出力を実際のテストアクションに変換する手法、さらに可視性とトレーサビリティを保ちながら管理する方法を解説します。 ヨーロッパ： 4月15日（水）14:00（CEST） 北米： 4月22日（水）14:00（EDT）／11:00（PDT） アジア太平洋： 4月15日（水）14:00（AEST） ライブトレーニングへの登録 PractiTestとその先へ Quality Leadership Academy：QAリーダーに求められる実践スキルを習得 テストが意思決定を支える分野へと進化する中で、QAリーダーには実行力だけでなく、より高度なスキルが求められています。 Quality Leadership Academyでは、現場の実務者によるセッションを通じて、リスクベースの優先順位付け、有効なKPI設計、スケーラブルな自動化、ビジネスコミュニケーション、責任あるAI活用といったテーマを学び、そのギャップを埋めることを目指します。 参加申し込み オンデマンド配信：Securing LLMs（Maryia TuleikaによるLinkedIn Live） 最近開催されたLinkedIn Liveを見逃した方のために、「Securing LLMs」をオンデマンドで視聴できるようになりました。 本セッションでは、Maryia TuleikaがOWASPのセキュリティ原則をLLM搭載アプリケーションにどのように適用するかを解説し、プロンプトインジェクションやデータ漏えい、不十分な保護策といった一般的なリスクが実際のシステムでどのように現れるかを具体例とともに紹介しています。 録画を視聴

DevOpsグループCREチームのy.s.です。 2026年3月25日に開催された CRE Camp #5 現場でつくるユーザー信頼性 ー LTと対話のセッション ー に参加してきました。 CRE Campは、Customer Reliability Engineering（CRE）やCustomer Support/Successに関わるエンジニアが集まり、プロダクトの信頼性向上やユーザー体験の改善について事例共有・対話するMeetupです。今回の会場は弁護士ドットコム株式会社（六本木）。LTと対話セッション、そして後半にはアンカンファレンスという構成でした。 なお、2025年10月の

はじめに こんにちは、YSHP部の三上です。Yahoo!ショッピングに出店しているZOZOTOWNの店舗である ZOZOTOWN Yahoo!店 のバックエンド開発を担当しています。私は2023年10月、社内公募を経てYSHP部へ異動しました。それまでは長らくビジネス部門に所属しており、開発は未経験でした。ZOZOTOWN Yahoo!店に携わるのも初めてで、APIという言葉の意味も曖昧な状態からのスタートでした。 そんな中、2025年9月末にジョインしたのが、ZOZOTOWN Yahoo!店へのギフトラッピング機能導入プロジェクトです。この取り組みは2021年頃から構想はあったものの、Yahoo!ショッピングとZOZOTOWNの仕様差分が大きく、実現に至っていませんでした。私がジョインした時点では、仕様の多くが確定していない状態でした。一方で、クリスマス商戦前にリリースするという目標だけは明確に決まっており、開発側のメイン窓口として推進を担うことになりました。 この記事で伝えたいこと 本記事では、以下の3点についてお伝えします。 仕様が異なるシステム統合における差分整理と責任分界の設計方法 未確定事項の多いプロジェクトの推進方法 開発未経験からのキャリアチェンジでの学び 目次 はじめに この記事で伝えたいこと 目次 ギフト導入までに取り組んだこと まず着手したのは「実装」ではなく「未確定事項の可視化」 仕様差分をどう吸収したか ギフト種別の違い 包装選択肢の違い ギフト利用NG条件の違い 既存アーキテクチャに沿った拡張 本番注文データでの実運用テスト 振り返り クリスマス前のリリースと反応 仕様差分のある統合で重要だったこと キャリアチェンジ直後でも推進できた理由 おわりに ギフト導入までに取り組んだこと まず着手したのは「実装」ではなく「未確定事項の可視化」 私がプロジェクトにジョインした時点では、クリスマス商戦前のリリースというゴールは明確でした。一方で、仕様の8割近くは未確定のまま、詳細はほとんど決まっていない状態でした。社内にQA表や議事録はありましたが、以下のような課題が散在していました。 一度議題に上がったものの結論を明文化できていない事項 一部で合意しているが全体として整合が取れていない内容 社内外で認識が揃っているかどうか確信が持てない論点 そのため、最初に着手したのは実装ではなく、ドキュメントやSlackでのやりとりを横断的に確認し、未確定事項と仕様差分を一覧化することでした。 何が決まっているのか 何が決まっていないのか どこに認識差異が生まれそうか を1つずつ整理しました。社内だけでも10〜20件程度の未確定事項があり、それらをもとに社内外のMTGを設定し、「最終的にどのレイヤーで何を制御するのか」という責任範囲を明確にしていきました。実装へ進む前に、制御方針と関係者の認識を揃えることを優先しました。 仕様差分をどう吸収したか 本プロジェクトにおいて最大のハードルの1つが、Yahoo!ショッピングとZOZOTOWNの仕様差分です。両システム間では、ギフト機能の仕様や前提となる設計思想が大きく異なっており、単純な横展開ができるものではありませんでした。 代表的な差分や特に判断が必要だったポイントをいくつか紹介します。 項目 Yahoo!ショッピング ZOZOTOWN 今回の対応 ギフト種別 通常ギフト/ソーシャルギフト ギフトラッピング ZOZOTOWN側の構造は変更せずYahoo!ショッピング側で選択肢を制御 包装選択 「指定なし」あり 必須 API連携時に必ず包装が設定されるよう制御 利用NG条件 独自の制御ロジック 対応上限数・在庫種別等の複合条件 APIレスポンスで可否を返却し責任を分界 ギフト種別の違い Yahoo!ショッピングには「通常ギフト」と「ソーシャルギフト」の2種類あります。ソーシャルギフトでは、購入者がURLを共有し、受取人がお届け先を入力する仕組みを提供しています。一方で、ZOZOTOWNにはこの仕組みがなく、ギフトの前提構造が異なる状態でした。 この差分に対しては、ZOZOTOWN側のデータ構造は変更せず、Yahoo!ショッピング側で選択肢を制御する方針としました。ZOZOTOWN側に新たな概念を持ち込むと既存の注文フローや配送処理への影響範囲が大きいため、既存構造の中で成立させることを優先した判断です。 包装選択肢の違い Yahoo!ショッピングでは包装に「指定なし」を選択できますが、ZOZOTOWNではギフト注文時に包装指定が必須です。この違いは単なるUIの差ではなく注文データの構造にも影響するため、ZOZOTOWNのデータ構造に落とし込む必要がありました。 そのため、「指定なし」をそのまま連携せずに、API連携時に必ず包装が設定されるよう制御する設計としました。UIの見え方ではなく、データ連携時にどう変換するかという観点で解決しました。 ギフト利用NG条件の違い 両社では、ギフト利用可否に関する制約も異なっていました。例えばZOZOTOWNでは、以下のような条件でギフト利用可否を制御しています。 発送拠点での1日のギフト上限数到達 外部在庫の商品を含む注文 予約商品を含む注文 ギフト利用不可の商品を含む注文 また、ギフトを選択した場合には代引き・置き配との併用が不可になるほか、即日配送も一部エリアを除き利用が制限されるなど、配送・決済オプションにも影響があります。Yahoo!ショッピング側にも独自の制御ロジックはありますが、今回のプロジェクトではZOZOTOWN側の制約を確実に担保することが前提でした。そのため、これらの条件をどのように両社で役割分担しながら制御するのかを決める必要がありました。 ZOZOTOWNのギフト利用NG条件は、発送拠点の対応上限数や在庫種別など内部状況に依存します。そのため、ギフト選択有無に関わらず、ZOZOTOWN側から常にギフト可否（OK/NG）をAPIレスポンスで返却する方針を取りました。また、即日配送・置き配・代引きといった配送・決済オプションについても、ギフト設定有無に応じてレスポンスを切り分ける設計としました。一方で、システム間の責任分界の観点から、Yahoo!ショッピング側で完結できる制御についてはYahoo!ショッピング側へ委ねる形としています。 既存アーキテクチャに沿った拡張 仕様差分を吸収するためには、API設計だけでなく、商品情報の連携にも対応が必要でした。 ZOZOTOWN Yahoo!店では、商品情報の連携にDBトリガーを用いた既存の仕組みがあります。対象テーブルのカラムに更新が走ると、DBトリガーがそれを検知してログテーブルに商品IDを書き込みます。既存のバッチ処理がこのログテーブルを参照し、Yahoo!ショッピング連携用のCSVを生成・FTP連携する、という流れです。今回のギフト導入では、この既存フローを2点拡張しました。 1つ目は、トリガーの追加です。商品情報テーブルのギフトNGフラグが変更された際に、ログテーブルへ書き込まれるようトリガーを新設しました。これにより、商品単位のギフト可否が変わったタイミングで、自動的に連携対象としてキューへ入る仕組みとなります。 2つ目は、CSV出力項目の追加です。既存のバッチ処理が生成するCSVに、ギフト可否を示す項目を追加しました。この項目は、ギフトNGフラグやギフト対象カテゴリの情報をもとに「対象/対象外」を判定し、Yahoo!ショッピング側に連携します。 いずれも新たな連携の仕組みを作るのではなく、既存のトリガー・バッチ処理の延長線上で対応しています。実績のあるフローに乗せることで、影響範囲を最小限に抑えることを意図しました。 本番注文データでの実運用テスト リリース前には、本番注文データをギフト扱いに変更し、実際の運用フローが回るかを確認しました。ギフトラッピングの実作業を管轄するZOZOBASEやお客様対応を担うCSも巻き込み、実運用に近い形で検証しました。検証を通じて、ZOZOTOWN Yahoo!店の注文では、ZOZOTOWNで利用できる一部機能（梱包サイズ超過時にZOZOBASEからCSへ引き継ぐ機能）を利用できないことが判明しました。この機能はZOZOBASEで使用されるハンディ端末に依存しており、私は実機を扱った経験もありませんでした。 そこで、関連システムのソースコードを追い、仕様を読み解くところから始めました。まずHTMLテンプレートの表示制御を確認し、条件分岐によってZOZOTOWNの注文でのみ「ギフト資材超過」の機能を利用できる仕組みに気づきました。次にサーバーサイドのコードでSQL文を追い、この機能が利用された場合にDBへどのような値が書き込まれるかを特定しました。 この仕様理解をもとに、ZOZOTOWN Yahoo!店でも同じ機能を利用できるよう、関係部署と連携して修正しました。結果的に、リリース前に運用上の課題を解消できました。 振り返り クリスマス前のリリースと反応 最終的に、本機能は2025年12月10日にリリースできました。クリスマス商戦前という目標に対し、余裕を持ったスケジュールでのサービスインとなりました。本格的な訴求前の段階でも、ギフト注文は順調に発生し、一定のニーズがあることを確認できました。長年構想止まりだった取り組みを、実際の売上につなげられたことは大きな成果だったと感じています。9月末のアサインから約2か月半という期間は、決して余裕のあるスケジュールではありませんでした。それでも予定通りにリリースできたのは、序盤に未確定事項を解消したことで、後半の開発・テストに集中できたからだと振り返っています。 仕様差分のある統合で重要だったこと 今回のプロジェクトを通じて強く感じたのは、実装よりも前の整理こそが統合の成否を分けるということです。異なる仕様を持つシステム同士をつなぐ場合、以下が重要になります。 表示上の違いだけに着目するのではなく、データ構造や制御レイヤーの差分を整理すること 最終的な制御を担うレイヤーを明確にすること 一方のシステムに過度な責務を集中させず、役割を分割すること 今回も、ソーシャルギフトの扱い、包装「指定なし」の吸収、制約に関する責任分界など、すべてにおいて「既存構造を壊さず、どこで整合を取るか」という判断が求められました。仕様差分は避けられませんが、構造と責任を整理すれば前に進める、という実感を得ることができました。 キャリアチェンジ直後でも推進できた理由 開発未経験で異動した私にとって、今回の案件はこれまでで最も規模の大きなプロジェクトでした。実装そのものは外部パートナーの方にお願いしていますが、キャリアチェンジ直後でもプロジェクトを前に進められたのは、以下を徹底したからだと考えています。 未確定事項を放置せず、可視化すること 認識が揃っているかを細かく確認すること 合意事項を文章として残し、曖昧さを減らすこと 技術力だけでなく、課題整理力や調整力といったスキルも、設計や推進の一部であると今回あらためて実感しました。 おわりに 仕様が異なるシステム同士をつなぐことは、単純な機能追加より難易度が高い場合もあります。しかし、構造を整理して責任を明確にし、1つずつ前提を揃えていけば、前に進めることもまた事実です。今回の取り組みが、仕様差分や責任分界に悩むプロジェクトの参考になれば幸いです。 また、技術力そのものに自信がなくても、整理する力や問い続ける姿勢は、プロジェクトを推進する大きな力になります。同じようにキャリアチェンジ直後で不安を抱えている方の後押しにもなれば嬉しく思います。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com