こんにちは、クロス イノベーション 本部の大岡叡です。 2025年12月19日（金）に NEC ソリューションイノベータ株式会社、キャップ ジェミニ 株式会社と合同で新卒1年目の AWS 勉強会を開催しました。この記事では、その勉強会の背景や内容をご紹介します。 背景 目的 内容 気づき・参加者の反応 開催してみての気づき 参加者の反応 まとめ・今後の展望 背景 とある外部の勉強会にて、 NEC ソリューションイノベータ株式会社の上田賢哉様、キャップ ジェミニ 株式会社の遊佐康平様と出会いました。お二人と

明けましておめでとうございます! クリスマスや年末年始を通じて、皆さんが心身ともにリフレッシュし、愛する人と一緒に時間を過ごせたことを願っています。 例年どおり、私は AWS re:Invent 後に数週間休暇を取って疲れを癒し、今後の計画を立てました。休暇の一部は、 Become a Solutions Architect (BeSA) の次のグループを計画するために使いました。無料のメンタリングプログラムである BeSA は、人々がクラウドキャリアや AI キャリアで能力を発揮するための支援手段として

みなさんこんにちは！ワンキャリアのデータエンジニアチームの塚田（Github： carbscountry ）です。 私は、今業務でデータ分析基盤の管理を行っています。 その関係で、　現在分析基盤ツールとして注目されているDatabricksに興味があり、先日Databricks主催の「DATA + AI WORLD TOUR」というイベントに参加してきました！

技術を土台にして自分なりのQAエンジニアを目指す本連載、第6回のテーマは「テスト自動化」です。 前回の記事 をご覧いただいた方はご存じだと思いますが、私は文系大学出身で、キャリアのスタートは営業職でした。 実務で、商用のプロダクトコードを書いた経験は、今もありません。 もっと言えば、かつての私は「Pythonの環境構築」をするためだけに、1カ月以上も躊躇して手が動かなくなるような人間でした。当時の上司から「Python興味あるんだったらなんで入れないの？」「やらないってことは興味ないってことじゃん」と言わ

香川大学大学院創発科学研究科修士1年の芝昌隆です。私は2025年夏季インターンシップで6週間、LINEヤフーのCloud Infrastructure本部に所属し、プライベートクラウドで提供しているソ...

こんにちは、ミイダステックオフィスです。技術書『 リーダブルコード 』や『Clean Architecture』の翻訳者として知られる角 征典さんを講師にお招きし、「アンクル・ボブに学ぶクラフトマンシップ」をテーマとした社内勉強会を開催しました。 ソフトウェアが社会の中核を担うようになった今、エンジニアはどのような姿勢でコードと向き合うべきなのか。今回の勉強会では、技術トレンドや個別の実装テクニックにとどまらず、 エンジニアとしての倫理、規律、そして仕事への向き合い方 について、改めて考える時間となりまし

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp PdM（プロダクトマネージャー）って、企業によってやることがバラバラですよね。 「仕様書を書く人」みたいになってる会社もあれば、 「戦略を決める人」だったり、「なんでも屋」だったりする。その中で、よく出てくるモヤモヤがこれです。 顧客インタビューをしていないPdMって、本当にPdMなの？ 逆に言えば、 エンジニアやデザイナーでも、顧客理解しながら動いていたらPd

はじめに こんにちは！早稲田大学 創造理工学部 総合機械工学科 3 年の野村恒晴です。   ...

はじめに 金融IT本部 2年目の坂江 克斗です。 業務にて ドメイン ベースでのアウトバウンド 通信制 限を考えるタイミングがあったため、本記事を書きました。 DNS に関する基本的な内容は こちらの記事 に、アウトバウンドセキュリティの概要に関しては こちらの記事 に記載しているので、気になる方はぜひ参照してみてください。 はじめに 概要 ドメインベースのアウトバウンド通信制御の検証 前提 Amazon Route 53 Resolver DNS Firewallの検証 Terraformの実装 デプロ

明けましておめでとうございます。 こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 私は2014年から、仕事・プライベートを問わず、毎年個人で目標を立て、その目標をさらに3カ月単位に分解して取り組むことを続けてきました。大きな方向性を定め、短いサイクルで振り返り、修正しながら前に進む。このやり方は、今のプロダクトづくりや組織づくりにも強く影響しています。 新年最初の記事ということで、今回は昨年度の簡単な振り返り

.mermaid { background-color: #ffffff !important; } import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs'; mermaid.initialize({ startOnLoad: true }); はじめに こんにちは。 エンタープライズ 第三本部 データマネジメントユニット マーケティング IT部の藤澤です。 先日、 API プラットフォー

急成長を遂げるメガベンチャーにおいて、マイクロサービスアーキテクチャの採用は事業スピードを加速させる強力な武器となります。 しかし、品質保証の観点に立つと、その複雑性はモノリスなシステムとは比較になりません。 サービスが細分化されるほど、チーム間でのテスト方針のズレや、予期せぬ場所での副作用、そして重すぎる統合テストといった課題が顕在化します。 現場の個別改善だけでは限界が見え始めている今、QAマネージャーに求められるのは、各チームを俯瞰し、リソースをどこに集中させるべきかを示す「テストの地図」を描くこと

事業が急速に拡大するメガベンチャーにおいて、複数プロダクトやマイクロサービスの品質を横断的に担保することは容易ではありません。 各チームが独立して開発を進める中で、テスト方針の不一致や手戻りの増加に課題を感じる場面も多いはずです。 これまでのUI主体のテストだけでは、リリースの高速化と複雑なシステム構造に対応し続けることは限界を迎えています。 そこで重要となるのがAPIテストの自動化です。 今回は部分最適に陥りがちな現場の改善を全体最適へと導くために、APIテスト自動化の戦略的な進め方や具体的な手法につい

リリース直前のテストや本番環境で、「まさかこんな操作をするなんて」「そこまで想定していなかった」という不具合に遭遇し、肝を冷やした経験はないでしょうか。 QAエンジニアとして真面目に仕様書と向き合っている人ほど、記載された「正しい挙動」を完璧に確認することに集中してしまい、異常な入力や予期せぬ操作に対する備え、すなわちネガティブテストが手薄になってしまうことがあります。 「テスト観点が浅い」という指摘を恐れる必要はありません。ネガティブテストが漏れてしまうのには明確な理由があり、それをカバーするための「思

システムのリリース直前、あるいは運用が始まってから「想定外の入力でエラーになった」「ネットワークが切れた瞬間にデータが消えた」といった不具合に直面し、焦った経験はないでしょうか。 仕様書に書かれた通りに動くことを確認するだけでは、現実の多様なユーザー操作や不安定な実行環境からシステムを守り切ることはできません。 品質の高いプロダクトを作るためには、正常な挙動を保証する「ポジティブテスト」と、異常な事態への耐性を確認する「ネガティブテスト」の両輪が必要です。 しかし、これら二つのテストの境界線や、よく似た言