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

急成長を遂げるメガベンチャー企業において、各プロダクトチームが独立して動く体制は、意思決定のスピードを速める大きなメリットがあります。 しかし、プロダクトが複雑化し、マイクロサービス化が進むにつれ、チームごとの「部分最適」な品質管理だけでは対応しきれない課題が顕在化してきます。 「隣のチームの仕様変更で、自分たちの機能に不具合が出た」 「チームごとに品質基準がバラバラで、リリース直前に大きな手戻りが発生する」 「QAマネージャーとして全体を俯瞰したいが、現場の状況がブラックボックス化している」 このような

1. マイクロサービスアーキテクチャでの変更容易性 マイクロサービスアーキテクチャ（MSA）がよく聞かれるようになり、「それで変更しやすくなるんでしょ？」という期待も一緒に耳にします。 ただし、MSAは何かインストールしたら実現されるような技術や製品ではありません。分割・デプロイ（リリース）・運用・体制などの組み合わせで実現するもので、狙った効果を得るには守るべき条件がいくつもあります。 本記事では、MSAを変更容易性の観点でひも解いて、MSAの何がそれに効くのか、そのためにすべきことを考えてみたいと思い

はじめに私たちは、社内のプラットフォームにおいて、Cloud NativeなANN（近似最近傍探索）ベクトル検索エンジン「Vald」のマネージドシステムを約4年間にわたり運用・開発してきました。本記事...

今から 20 年前の 2006 年 3 月 14 日、 Amazon Simple Storage Service (Amazon S3) は、 「新着」 ページに掲載されたわずか 1 段落のシンプルな発表とともにひっそりとリリースされました: Amazon S3 はインターネットのためのストレージです。デベロッパーがウェブスケールコンピューティングをより簡単に利用できるように設計されています。Amazon S3 は、ウェブ上のどこからでも、いつでも、どのような量のデータでも保存および取得するために使用で

はじめに 前回の記事「[Informatica IDMC] Secure Agentグループの負荷分散の仕組みと設計の基本」では、Secure Agentグループの負荷分散の仕組みと設計の基本を解説しました。複数のSecure Agentをグループにまとめることで、タスクの負荷分散やワークロードの分離が実現できることを確認しました。 しかし、パフォーマンスの観点を考慮するとそれだけでは設計は終わりません。1台のSecure Agent自体の処理能力を最大限に引き出すチューニングも同じくらい重要です。デフォ

2025年11月にAmazon Web Services (AWS) のコンテナオーケストレータ Amazon Elastic Kubernetes Service (EKS) の新機能として、EKS Capabilitiesが発表されました。 https://aws.amazon.com/jp/about-aws/whats-new/2025/11/amazon-eks-capabilities/ 本記事では、EKS Capabilitiesで提供されている機能の一つであるAWS Controllers

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

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

みなさん、こんにちは。ワンキャリアの技術広報を担当している長谷川(X： @hasehathy )です。 今回は、メルカリやCircleCIを経て2025年にワンキャリアへ参画したMark（マーク）（ @TangoEnSkai ）と、プロダクト開発部 部長の山口（ @yamat47 ）にインタビューしました！

本記事は 2026 年 3 月 9 日 に公開された「 Kinesis On-demand Advantage saves 60%+ on streaming costs 」を翻訳したものです。 Amazon Kinesis Data Streams は、あらゆる規模のストリーミングデータをキャプチャ、処理、保存できるサーバーレスのストリーミングデータサービスです。2025 年 11 月 4 日、 Amazon Kinesis Data Streams に On-demand Advantage モードが

はじめに こんにちは。Insight Edgeでデータサイエンティストをしている善之です。 「研修で基礎は学んだけど、次は何を学べばいいんだろう…」 「話題の新しいライブラリが次々と出てくるけど、どれを学ぶべきかわからない」 こんな悩みを抱えていませんか？ 先日、 新人エンジニア・データサイエンティスト に向けた研修の一環として、 最新技術をどうやってキャッチアップし続けるか というテーマでレクチャーを行いました。 本記事では、その研修内容のエッセンスをご紹介します。 本記事は新人の方本人だけでなく、 後

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

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

こんにちは、ブログ運営担当の遠藤です。 3/10（火）19:00～20:00 当社主催の勉強会「NRIネットコム TECH AND DESIGN STUDY #93」が開催されます!! 今回のTECH & DESIGN STUDYでは、当社エンジニアから「組織全体で実現する標準監視設計」と、「Infrastructure as Codeのはじめ方」についてお話します。 【1人目】組織全体で実現する標準監視設計 クラウド活用が進む中で、システムの構成や運用のあり方は大きく変化しています。 マイクロサービス化