はじめに 初めまして！ 神戸大学工学部3年の三村雄斗です。   9月5日から9月30日まで ...

シニア GTM アナリティクススペシャリストソリューションアーキテクトの大薗です。 2025 年 7 月 15 日に「 Amazon SageMaker Roadshow –Japan 」を開催しました。本イベントでは、 Amazon SageMaker 開発チームが来日し、次世代の Amazon SageMaker を開発した理由やその機能紹介を行い、AWS Japan チームからデモやプレゼンテーションを通じて Amazon SageMaker の世界観を深堀りしました。さらに NX 情報システム株式

はじめに はじめまして！ 2025年9月にソフトウエアエンジニアとしてCA Tech JOBに参加し ...

はじめに こんにちは！楽楽勤怠開発チームのoo_yoshiです。 勤怠管理システムは「打刻して残業時間や休暇を計算すれば終わり」と思われがちです。しかし、実際にシステムを開発・運用してみると、その裏には複雑なルールと例外が山ほど存在します。 勤務体系は企業ごとに違い、法律や就業規則も定期的に改正されます。有休の付与や消化ルール、代休や振休の扱い、残業の丸め処理など、ひとつひとつのルールが微妙に違い、組み合わせると膨大なパターンになります。 私たちのチームでは、そうした複雑さに対応するために9年前にDDD（

はじめに 以前、AWS は東京海上日動システムズ株式会社様（以下同社）との生成 AI を活用したアプリケーションモダナイゼーションの取り組みについて ブログで紹介 しました。この取り組みでは、Amazon Bedrock を活用し、レガシーな Java アプリケーションをサーバーレスアーキテクチャへモダナイズするプロセスを効率化する方法論の基礎を構築しました。現在同社では実際のプロジェクトへの適用が進められています。 同社では生成 AI の可能性を多角的に探求されており、アプリケーションモダナイゼーション

はじめに こんにちは、サービスシステムグループの佐々木です。 最近、多くの開発チームでマイクロサービスアーキテクチャが話題になっていますが、実際に導入してみると「思ってたより大変だった…」という声もよく聞きます。そんな中で注目されているのが「 モジュラーモノリス 」という考え方。今回は勉強会や自主学習で学んだことをまとめてみました。 モジュラーモノリスとは モジュラーモノリスは、ソフトウェアアーキテクチャの一つのアプローチです。 従来のモノリシックアーキテクチャとマイクロサービスアーキテクチャ

このブログ記事は、AWS ソリューションアーキテクトの吉澤 稔と都築 了太郎が執筆し、住信 SBI ネット銀行様が監修しています。 住信 SBI ネット銀行株式会社（以下、住信 SBI ネット銀行）は、勘定系システムの更改に向けてアマゾン ウェブ サービス（以下、AWS）のクラウド環境を採用することを決定しました。2028 年初旬の本番稼働を目指し、AWS 上での次世代勘定系システムの設計・構築が進められており、移行完了後は、同行の主要システム全てが AWS 上で稼働することとなります。将来的なスケーラビ

はじめに こんにちは！株式会社Luupで、Software部 Platformグループ Technology Enabling チームに所属している安元（やっすー）です。 一ヶ月ほど前とはなりますが、「AI活用Meetup」というイベントに「開発スケールのためのAI活用」というタイトルで登壇したので、内容をご紹介します。 https://lapras.connpass.com/event/361288/ Luup開発チームのAI活用 Luupでは、マイクロモビリティシェアのサービスを通して、人々の移動をよ

はじめに こんにちは、Recruit Data Blog担当の森です。 2025年6月23日、当社現役データエンジニアが登壇する「リク

GoでレイヤードアーキテクチャとDDD（ドメイン駆動設計）をどう実装しているかまとめます。 自分で考えて試している部分も多く、この構成でうまくいかない部分もあるかもしれません。その点ご認識ください。 レイヤードアーキテクチャについては下記が参考になります。 https://qiita.com/tono-maron/items/345c433b86f74d314c8d 例として部署情報（department）のCRUDについて書きます presentation層（interface) ├── present

1. はじめに こんにちは！配配メール開発チームのos188です。 今回は、 長年動き続けてきたレガシーシステムに向き合い、現実的なリファクタリングに挑戦した 事例をご紹介します。 1. はじめに なぜリファクタリングに踏み切ったのか？ 2. リファクタリング方針と技術選定 既存システムの構成 リファクタリングの主な方針 3. 実践！レガシーコードをモダンに生まれ変わらせるステップ ステップ1：既存ソースの徹底把握 ステップ2：新クラス構成とフォルダ構成の検討 ステップ3：ドメインモデル設計・実装 ステッ

はじめに デリッシュキッチンでiOSアプリ開発を担当している池田です。近年のAI技術の進歩により、コーディングやデータ分析をはじめとする様々な業務での活用が進んでいます。今回、非エンジニアを含むチーム全体での勉強会において、AIを活用してレジュメを作成することで、効果的な学習体験を実現できました。 その取り組みと成果を共有します。 背景 私たちのチームでは毎週振り返りを行っており、その中で私が「ドメインモデルを意識できていないため、サーバーエンジニアとアプリエンジニア間のコミュニケーションコストが増加して

出前館開発本部でサーバーサイド開発を担当している本多です。LINEヤフーのグループ会社である出前館とは資本業務提携を結んでおり、LINEヤフーが開発をサポートしています。本ブログでは以下についてお話し...

はじめに 前編では、業務の複雑さに応じた実装スタイルとテスト方針の組合せについて、書籍『ドメイン駆動をはじめよう』[1]の知見をもとに整理しました。 後編となる本記事では、私自身がテスト支援の立場で関わっている現場で直面した、「業務の複雑さに対して相性の悪い実装とテストの組合せ」についてご紹介します。そこから見えてきた課題と、より適した組合せに近づくための「最初の一歩」について考察していきます。 複雑な業務に対する“相性の悪い組合せ”とその背景 私が支援した現場では、業務の複雑さに対して、トランザクション

はじめに 「テスト項目を“消化”することが目的になってしまい、本来の品質向上や業務課題の解決につながらない」「業務の複雑さに対して、テストや設計がうまく噛み合わず、現場で手戻りや不安が絶えない」――そんな悩みを感じている方も多いのではないでしょうか。 テストケースはたくさん作っているのに、現場の“やった感”ばかりが残り、肝心の不具合や業務上のリスクが減らない 業務が複雑化しているのに、従来通りのテスト方針や設計のままで、現場の困りごとが解消されない 「なぜこのテストをやるのか？」が曖昧なまま、テスト項目を