10年分のレガシーに挑む！ジンジャー開発チームが『しめごろし』で挑んだ無停止移行戦記

みなさん、こんにちは。jinjerプロダクト開発部の福与です。前回はログ基盤の構築についてお話しさせていただきましたが、今回はその続編とも言える、レガシーシステムのモダン化についてお話しさせていただきます。jinjerは2016年にサービスを提供して以来、10年に渡って勤怠

生成AIで、Webアクセシビリティ対応を開発フローに組み込めるか 🔖 1

はじめにこんにちは。jinjerでフロントエンド開発をおこなっている坂井です。最近の開発は、ほとんどがAIコーディングです。そのなかで気になったのはWebアクセシビリティです。専門家というわけではないのですが、いま自分にできることはないか、と考えています。「アクセシビリティ

Goの単一リポジトリでCIを9分から4分へ高速化した対処法。ボトルネックはコードではなく環境にあった 🔖 1

はじめにこんにちは。jinjer プロダクト開発部 SE の今道です。今回は、チームの開発体験をじわっとよくした「CI 高速化」の話を書きます。PR を出すたびに CI の完了を待つ数分。1回あたりは小さくても、1日に何度も、チーム人数分積み重なると地味に効いてきます。この「

感覚的な「らしさ」をチームの「共通言語」へ。デザインマネジメントが果たすべきプロダクトブランディングの役割 🔖 1

「このデザイン、なんか違う。」デザインレビューで、そんな言葉を耳にしたことはないでしょうか。違和感はある。しかし、その理由をうまく言語化できない。レビューを受ける側も「どこを直せばいいのか」がわからず、結局はレビュアーの感覚に合わせるしかない。こうした状態では、デザイン品

# 「コーディング頑張る」と宣言した34歳元CS、1年後にコードを書くのを辞めて「新規アプリの仕様」を握ることになった話

「コーディング頑張る」と宣言した34歳元CS、1年後にコードを書くのを辞めて「新規アプリの仕様」を握ることになった話こんにちは！jinjerの坂本です。営業、パートナーセールス、CSを経て、34歳未経験のまま開発の扉を叩いてから早1年半が経ちました。まずは、前回のブログ（2

AIは「読める」だけでは調査できない ―― New Relic / AWS MCP でつくる「測るAI」

AIが自分で「測れる」足場を MCP でつくり、その上に鑑別診断の規律をのせて、経費精算プロダクトの性能を一つずつ改善した記録です。 きっかけ：性能テストで課題が山積みにあるスプリントで経費精算プロダクトに性能テストを一斉にかけると、「一覧が数十秒」「詳細がときどき失敗

【AWS Summit 2026】AIエージェントの実務活用術と、現場が直面した「レビューの壁」

こんにちは！プロダクト開発部に所属している心はSREの酒井です。2026年6月25日・26日の2日間にわたり幕張メッセで開催された「AWS Summit Japan 2026」のDay2に参加してきました！昨年もAIに関することが大部分を占めていましたが、今年のAWS S

AIに嘘をつかせないために

はじめに「AIって嘘をつくから信用できないよね」という言葉は、IT業界に関わる人なら必ず聞いたことはあるでしょうし、その他業種の方でも度々目にする言葉だと思います。ただ、果たしてAIは、意図的に嘘をつきたくてついているのでしょうか（もしかしたら、そういうパターンも我々の知ら

Claude Code × New Relic MCP Server でSLO設定を自動化！SREが実践したAI効率化術

はじめにこんにちは、jinjerで SRE をしている与儀さねです。jinjer沖縄オフィスで活動しています。jinjerでは HR 領域の SaaS を複数プロダクト展開しており、各プロダクトのアプリケーションは New Relic APM で監視しています。これまで S

AIで開発は爆速になった。じゃあインフラは？AWS Summit 2026でジンジャーのSREがECSの進化に震えた理由 🔖 1

こんにちは！jinjer株式会社でSREを担当している吉川です。6/25、26に開催されている「AWS Summit 2026」に今年も参加してきました！毎年新しい技術の熱気に包まれるこのイベントですが、今年の進化スピードには本当に驚かされました。いち早くみなさんに情報をお届

「動いたからOK」を卒業せよ！AI時代のジュニアSEが直面する「3つの壁」とシニアSEへの道

こんにちは！jinjerの安東です。今回の記事では、AIを用いた開発が一般化してきた中でのSEの成長についてのお話をしようと思います！ 現場の風景が変わった「Claudeに聞けば、だいたい動くコードが返ってくる」。そんな一文が、もう冗談でも誇張でもなくなりました。思い

Python Lambda 本番運用ガイド：SnapStart × NewRelic の導入と落とし穴

はじめにこんにちは！プロダクト開発部に所属している酒井です。弊社では、プロダクト開発において Python と AWS Lambda を使っている箇所があります。その際、想定以上に動作が遅いという課題に直面しました。細かく調べてみると、原因の大半は Lambda の C

「主体性を持て」と言うのをやめたら、チームが自走し始めた。泥臭い現場のリアルな生存戦略

「主体性を持ってほしい」「もっと自分ごとで考えてほしい」——そう呼びかけ続けるほど、私のチームはむしろ受け身になっていきました。こんにちは。jinjer株式会社でプロジェクトマネージャー（PM）をしている、与儀しげです。プロジェクトマネジメントに携わる方であれば、「QCDを達

シンプルなプロンプトでも開発者体験を高めるマルチエージェント構成 実践編

実践編ナビゲーション[説明編](./シンプルなプロンプトでも開発者体験を高めるマルチエージェント構成 説明編.md) | [構成編](./シンプルなプロンプトでも開発者体験を高めるマルチエージェント構成 構成編.md) 構成編の振り返り構成編では、TREパイプライン

シンプルなプロンプトでも開発者体験を高めるマルチエージェント構成 構成編

構成編改めてjinjer株式会社でバックエンドエンジニアをしている池沼です。今回は構成編になります。 説明編の振り返り説明編では、AIエージェント活用における開発者体験の課題と、TREアプローチによる解決策の基本概念について説明しました。シンプルなプロンプトで高品質な

シンプルなプロンプトでも開発者体験を高めるマルチエージェント構成 説明編

説明編 はじめにはじめまして。jinjer株式会社のバックエンドエンジニア池沼です。今回は、私が普段から愛用している多層型マルチエージェント構成について説明しようと思います。かなり長くなっていたので皆さんには3部構成でお届けします。 構成について本記事では、説明

『エンジニアリングリーダー』から学ぶ、沖縄SEチームが目指す「自己改善する組織」の作り方

はじめに2026年1月にjinjerにジョインした豊田です。現在、沖縄拠点でSEを務めており、ジンジャーの開発業務に従事しております。jinjer開発部では、全社を挙げて「日本一の開発組織」を目指し、現場主導でボトムアップなアプローチをとる「ティール組織」を基本としておりま

全部Terraformで管理してはいけない？「かつての最適解」が生んだ管理の壁と、私たちが引き直した境界線 🔖 112

導入：ジョイン直後に感じた「開発サイクルの重さ」「入社して3ヶ月、私はある『ジレンマ』を抱えていました。」2025年11月、SREとしてjinjerにジョインした私を迎えたのは、Terraformによって厳格にコード化されたインフラ基盤でした。すべてのリソースがIaCで管理さ

【キャリアの転換点】日本一を目指すエンジニアが、あえて「コードを書くのをやめた」理由

こんにちは。jinjerの田島です。エンジニアリングに携わる方であれば、「できる限り長く現場でコードを書き続けたい」「マネジメント層に回るやり甲斐がイメージできない」と考えたことが、一度はあるのではないでしょうか。かくいう私も、以前は完全にその一人でした。自分でコードを書く時

【RxSwift入門】③カウンターアプリでMVVMを学ぶ

はじめに第1回・第2回ではPlaygroundを使ってRxSwiftの基礎概念とジェネリクス・エクステンションを学びました。今回からは 実際にアプリを作りながら RxSwiftを学んでいきます。この第3回では、シンプルな カウンターアプリ を題材に、以下を身につけます：

Kiro × NotebookLMで挑む「仕様書駆動開発」の最前線。HR SaaS開発の現場を支える「自動同期」と「共通ルール」の裏側

エンジニアを「単純作業」から解放するためにAIによるコーディング支援が浸透した今、僕たちが直面しているのは「いかにAIに最新の仕様を正しく伝えるか」という新たな課題です。小規模なバグ修正なのに、AIへの説明に時間がかかりすぎる（くるみを割るスレッジハンマー問題）コードを直

9年目フロントエンドエンジニアの「視点の転換」——ソロ開発から組織のリーダーへ。HR SaaSの現場で学んだスケールの極意

9年間のキャリアと、僕が持ち込んだ「ソロ開発」の矜持22歳からエンジニアとしてキャリアをスタートし、約9年間、フロントエンドの領域を走り抜けてきました。SESやフリーランスとしての期間が長く、数々の現場を「一人のフロントエンド担当」として渡り歩いてきた自負があります。当時は「

②DB障害を追う——レプリカ遅延の犯人は、ダム決壊。事件解決——のはずだった

「コミット済みなのに、Replicaから読めない」前回の記事で、Tx内の外部API呼び出しがlock waitとデッドロックを爆増させる構造と、その改善パターンを実測しました。表の右端に「Stale Read」という列があったのを覚えているでしょうか。パターンデッドロ

③DB障害を追う——NOT FOUNDの犯人は、2人いた

「登録したはずのデータが読めない」データを保存する処理は成功している。しかし直後に走る後続処理で、そのデータがNOT FOUND（Laravel/Eloquentの ModelNotFoundException: No query results for model [...]

① DB障害を追う——lock waitの犯人は、たった1行のAPI呼び出しだった

障害発生ある日、本番システム（MySQL 8.0 / InnoDB）で以下のエラーが多発していることがわかりました。Error: 1205 (HY000): Lock wait timeout exceeded; try restarting transaction（ロッ

② DB障害を追う——NOT FOUNDの犯人は、2人いた

「登録したはずのデータが読めない」データを保存する処理は成功している。しかし直後に走る後続処理で、そのデータがNOT FOUND（Laravel/Eloquentの ModelNotFoundException: No query results for model [...]

デザインシステムに「顧客」はいたか？ 陥りがちな神話と、リードエンジニアが挑む真のUI/UX再構築 🔖 3

「一貫性」という理想の裏に、迷い込んでいませんか？「プロダクトが多角化する中で、どうすれば一貫した体験を維持できるか」「開発スピードを落とさず、ブランドの信頼を守り抜くには？」現在、多くのプロダクト開発現場で、デザインシステムはこれらの問いに対する「銀の弾丸」として期待され

コード品質はAIに任せろ。エンジニアとして成長するための「思考をサボらない」レビュー戦略 🔖 1

導入：AIレビューが導入された。「もう人間は何もしなくていい」のか？最近、私たちのチームでもAIによるコードレビューを導入しました。GitHub CopilotやCursorといったツールの進化により、プルリクエスト（PR）を出した瞬間にAIが飛んできて、コードの不備を指摘して

DI、DIP、クリーンアーキテクチャ - ログ基盤の差し替えで繋がった3つの点

はじめにDI（依存性の注入）、DIP（依存性逆転の原則）、クリーンアーキテクチャ。それぞれ名前は知っていたし、なんとなく「良いもの」だとは思っていました。でも、それぞれが別々の知識として頭の中にあるだけで、つながりは見えていませんでした。それが、ログ基盤の差し替えという実務

【RxSwift入門】②ジェネリクス&エクステンションを理解する

はじめに第1回では、RxSwiftの基本概念（Observable、Subject、Disposable）を学びました。今回は、これまで何気なく使っていた Observable<T>の<T> や .rx.tap といった記法の仕組みを深く理解していきま

実務で役立つSQLパフォーマンス改善：遅いクエリを「集合」の視点で整理する

はじめにSQLのパフォーマンス改善というと、まず「インデックスを貼る」という発想になりがちです。もちろんインデックスは重要ですが、実務ではクエリの書き方そのものを見直すことで改善するケースも多くあります。今回、実務の不具合調査、新機能開発、パフォーマンス改善を行う中で、どう

AI×仕様書駆動開発をチームに導入してわかった「個人では得られない相乗効果」

はじめにこんにちは。jinjerプロダクト開発部SEの今道です。先日、社内勉強会でAI IDE「Kiro」を使った仕様書駆動開発のチーム導入について発表する機会がありました。特に反響が大きかったのは以下のポイントです。ステアリングでチーム全体のコード品質を底上げできるこ

uvでAWS Lambdaのデプロイ時間を10倍高速化した話 - CDK PythonFunctionからの移行

TL;DRCDK PythonFunction から Function + Layer 構成に移行し、デプロイ時間を14分→78秒に短縮uv による依存関係のビルドで、従来の pip 比で大幅な高速化を実現CDK Synth単体では13分→10秒（約78倍高速化）

初めてのアジャイル開発で、Gitブランチ戦略を改善した話

はじめにこんにちは！jinjerプロダクト開発部SEの関根です。2025年の3月に入社し、ジンジャー人事評価のバックエンドエンジニアを担当しています。今回は私が初めてアジャイル開発をやってみて気づいた課題と、どう改善をしていったかをお話ししたいと思います！ なぜ今、ブ

【完全公開】なんとなくで作らない！8つのSTEPで進める「jinjer流・アイキャッチ制作」の裏側

こんにちは！jinjerでコミュニケーションデザイナーをしている立川です。デザインチームではほかの部署から「アイキャッチ」の制作依頼を受け、デザインの制作・提案をおこなっています🎨今回は、先日公開したnote記事『子どもも大人もワクワク！jinjer Family Day 2

SwiftからiPhone内蔵のAIと対話してみる

1.はじめに昨今のAI進化は凄まじいものがあり、ワクワクしています。しかし、分かりやすいネックとしては、従量課金制であることだと思います。どんなに良いサービスを思いついたとしても、従量課金制のAIサービスを利用しなければいけない場合、常に運用コストを気にしないと行けなくなりま

UIUXレビューgemを活用してみた！ 忙しい中でもフィードバックを得るデザインプロセス

こんにちはジンジャーのプロダクトデザイナーの野口です！今回はgemsを活用してデザインプロセス効率化に挑戦したことを記事にしてみます。 デザインの質向上とデザインレビュー時間の削減を同時に実現！一人でデザインに向き合っていると視野が狭くなり、修正漏れや別動線の検討などの

Claude CodeでTerraformのドキュメント作成を効率化した話

はじめに：新人でも「提案」即「実装」できる文化こんにちは。プロダクト開発部 SREグループに所属している酒井です！2025年9月に入社し、ちょうど3ヶ月が経ちました。「入社してまだ3ヶ月」ですが、私の所属する組織では 「年次に関係なく、良い改善提案は即採用」 という文化が

【RxSwift入門】①Observable、Subject、Disposableを理解する

はじめにRxSwiftはクセがあり最初はとっつきにくいのですが、理解すれば非常に強力なツールです。この記事では、RxSwiftとはなんぞや？というところから、ミニマムなコード例とともに理解を深めていきます。!📂 サンプルコードこの記事で使用しているコードの完全版はGit

プロダクトの解像度を「実装レベル」まで高めるプロダクトマネージャーの Cursor 活用術

こんにちは、jinjer でジンジャー給与のプロダクトマネージャー（PdM）をしている佐藤と申します。jinjer のプロダクトマネージャー組織内でも AI を業務で使うのは当たり前になってきており、自分としても AI を普段の業務に組み込む「型」のようなものがある程度できてき

REST APIの理想のエラーレスポンスを再考する

API を設計する際、エラーレスポンスの定義は意外と揺れやすく、これまでの経験では「適当に作られている」ケースも少なくありません。過去の実装の適当さに煩わされて泣くことが多く、「なんとか助かりたい」という思いからこの記事を書きました。 理想のエラーレスポンスとは構造が揃

WAFのDDoS設定をTerraformで検証するお話

はじめにこんにちは。プロダクト開発本部 SREグループに所属する大城です。SREとしては2年目となり、以前はQCとして、プロダクトの品質向上の業務に携わっていました。また、私と同じ時期にQCからSREグループへ異動した宇根さんの記事も公開されていますので、ぜひご覧ください

プロダクトを「愛してはいけない」！？

※あくまで個人的な考え方です🐖 プロローグPdM（プロダクトマネージャー）は、プロダクト開発の中でも、要件の意思決定、優先順位付け、ロードマップ、ステークホルダー調整——プロダクトオーナーとしての振る舞いが求められる場面が多い役割です。そうした文脈で、よく耳にするのがこの

【開発組織】「日本一」を目指すジンジャー開発部のワークショップ運営の秘訣：内製にこだわり、現場の声を力に変えるスクラム的改善サイクル

🏆 「日本一」を目指すジンジャー開発部のワークショップ運営の秘訣 内製にこだわり、現場の声を力に変えるスクラム的改善サイクルこんにちは！jinjer開発部 VPoE の篠田です 👋私たちの開発組織は、「ジンジャー開発日本一」を掲げ、単なる技術力だけでなく、💡 自他ともに

デザインチームでAI勉強会と輪読会をはじめました

はじめに皆さまこんにちは！ジンジャーのプロダクトデザイナー、福永美菜穂です。前回、ジンジャー給与のデザインに関する記事を出させていただきまして、たくさんの方に読んでいただきとても嬉しかったです！ありがとうございます！今回は、7月から約3ヶ月間、デザインチームでAI勉強会と

私とClaude Code 🔖 1

こんにちは。プロダクト開発部の伊藤です。早くも2回目のブログ投稿です。ジンジャーではAI導入積極推進中で、プロダクト開発部のメンバーにもCopilotやCline、Amazon Q Developerなど、さまざまなAIの利用を推奨しています。その中で、私はClaude

課題の本質を見極めることの重要性─PdM1年目の学び

はじめまして。jinjerでプロダクトマネージャーをしているそごうです。中途入社後、テクニカルサポート（現カスタマーサポート）として顧客対応を経験し、現在はプロダクトマネージャー（PdM）として日々邁進しています。今回は、PdMへキャリアチェンジしてから学んだことを振り返り

不具合調査の時間が半分に？ ジンジャー給与が取り組んだログのカイゼン戦記

給与プロダクトの不具合調査、その戦いの始まりこんにちは！ジンジャーの安東です。気がつけば、前回の記事から少し時間が経ってしまいましたね。この間、私は日々プロダクトのカイゼンに奮闘していました。今回の記事では、私が関わっているジンジャー給与というプロダクトで抱えていた「不具

jinjerのSREチーム、AI活用の第一歩を踏み出す

はじめにこんにちは！ jinjer株式会社 SREチームの宇根です。私は2023年にjinjerへ入社し、沖縄オフィスの一員としてQC（品質管理）を担当した後、2024年7月よりSREとして従事しています。QCからSREというのは、一見すると異色のキャリアチェンジかもしれま

デザイン組織でベロシティ管理を始めてわかったこと

1. はじめに私たちのデザイン組織は、複数のプロダクトとコミュニケーション案件を横断しながら日々活動しています。しかし、その活動の成果はどうしても「感覚的」「定性的」に語られがちです。「チームの進捗はどれくらい？」「どこにリソースを割いているのか？」「この施策は事業にどん