Coding Agentの時代: ソフトウェアエンジニアの未来
社内 IT の部署であるGYOMUハックでマネージャーをやっている kumataro です。私たちの取り組みから実感している次の時代のソフトウェアエンジニア像のひとつについて書いてみました。 2025年から2026年にかけて、Coding Agent が爆発的に進化しました。Claude Code や Codex、GitHub Copilot Agent など、コードを書くだけならAIが人間よりも高速かつ正確にこなせる時代が現実のものになりつつあります。 最近は、自分で1行もコードを書いていないという話も聞くようになってきました。 そんな環境ですので「AIに仕事を奪われるのではないか」という不安を抱いているソフトウェアエンジニアの方も多いのではないでしょうか。 「コードを書くことそのもの」に強いやりがいを感じているエンジニアにとっては、大きな変化に戸惑う側面もあるかもしれません。しかし「課題を解決すること」が目的であるエンジニアにとって、AI はこれ以上ない強力な武器です。私たちはこの変化を、エンジニアという職種がより本質的な価値へと回帰するチャンスだと捉えています。 Coding Agent 時代に陥りやすい罠 私たちは社内のバックオフィスの生産性を向上させるためのエンジニアチームです。Claude Code を用い、実装の速度が増したことにより、寄せられる要望に対応できる能力も高まっています。 同時に、ここには罠が存在することにも気づきました。それは、開発速度が増したことにより、寄せられた要望に素早く対応するだけの存在に陥ってしまいやすいということです。対応は感謝されるだけに、すぐに要望を実現したい気持ちはエンジニアにとっても、とても強いものです。 しかし、この先に待ち受けているのは、部門、業務ごとに個別最適化された処理やデータの乱立です。一見、業務は最適化されているように見えますが、全体的な視点では業務の重複による一貫性のなさや、データの散在が起こり、連携が困難な状況が急速に拡大するのが目に見えています。 実際に freee のバックオフィス内でも、従業員数の予測値について、労務と社内IT、財務の間でそれぞれの課題感から別々に算出している事例がありました。このような組織横断的な不整合の解決は個別の部署の業務改善では実現できません。 こうした「部分最適の罠」を回避し、AI を真の武器として活かすためには、単なる「対応力」を超えた、より戦略的なアプローチが不可欠です。そこで私たちが今改めて立ち返ったのが BPR と FDE というふたつのキーワードです。 道を切り開くふたつのキーワード、BPR と FDE BPR（Business Process Re-engineering）: 既存の業務プロセスをそのままシステム化するのではなく、プロセスそのものを根本から再設計すること。 FDE（Forward Deployed Engineer）: 本社のオフィスで仕様調整を待つのではなく、現場に入り込み、業務を観察し、課題を発見し、動くものを作って解決する「前線配備エンジニア」。 FDE は米国 Palantir 社などが先駆けて導入し有名になったポジションですが、これが「今の時代」に特にもてはやされているのには、明確な技術的・ビジネス的な背景があります。 freee でも社内のバックオフィスでは、ドッグフーディング的に自社プロダクトを利用しています。そういった環境での業務改善において、パッケージ化された SaaS をそのまま導入するだけでは解決できない企業固有の複雑な課題は残るのが現実です。 SaaS のデータと社内独自のデータの統合: 業務活動ではデータ分析の要求は常にあります。しかし、SaaS 内のデータと SaaS 外のデータを統合して扱うのは簡単なことではありません。また同じ元データのはずのものが部署毎の処理の中で異なる数字になって出てくることもあります。 スピード感: フィードバックは SaaS プロダクトに届けることができます。しかし、開発優先度の問題や SaaS としての全体最適化の中で、対応スピードは思うように上がりません。 個別最適化: SaaS という性質上、個社別の環境に最適化するわけには行かないため、個別の事情にピッタリマッチする改善はできないのが現実です。 こういった課題に対して、FDE は現場で活動している強みで、自ら解決策を提示し、導入、運用まで進めることができる役割となっています。 私たちのチームは社内における FDE として、業務をハックするエンジニアチームです。私たちが取り組んでいるのは、まさにこの FDE の動きを通じた BPR の実践です。 ミッションとバリュー では、ふたつのキーワードと陥りやすい罠を避けるために、どのようなマインドセットを持って業務に取り組めば良いと考えているのか紹介してみます。 私たちのミッションは「テクノロジーと対話を通じて、バックオフィスの生産性を最大化し、全従業員がより創造的な業務に集中できる環境を創り出す」ことです。このミッションを実現するために、以下の4つのバリューを大切にしています。 Why First（なぜ？から始める） 私たちは、表面的な要望の奥にある本質的な課題を探求することを常に最優先します。依頼された解決策をそのまま実装するのではなく「その業務はそもそも必要なのか？」「理想の状態は何か？」という問いから始めます。必要であれば「開発しない（業務自体をなくす）」という選択すら積極的に行います。 Be a Partner（最高のパートナーであれ） 私たちは、依頼者を「お客様」ではなく「課題解決のパートナー」と捉え、共に考え、共に成功を目指します。依頼者と対話し、業務のAs-Is/To-Beを描きながら、現場の泥臭い課題を共に解きほぐしていきます。 Impact Driven（インパクトで動く） 私たちは、取り組むべき改善を、そのインパクト（効果）の大きさによって判断します。 Go Simple（シンプルを追求する） 私たちは、複雑な問題を、誰もが使い続けられるシンプルで持続可能な解決策へと導きます。 私たちが目指すシステム全体像 こういった理想を実現するため、現場の課題に寄り添いながら、同時にそれを支える強固な技術基盤も並行して構築しています。現在、私たちが構築しているシステム全体のイメージ図を共有します。 開発中の基盤の全体像 Cadiz: OneLogin × AWS Cognito × Cerbosを組み合わせ、行・列レベルの認可制御を一元化した社内アプリ開発基盤。社内業務で用いる社員のセンシティブなデータも適切に守る。 Service Data Pipeline: AWS EKS 上で構築した自前のデータ連携基盤。複数の SaaS やデータソース間を柔軟に連携。 データ分析基盤: Google Cloud（BigQuery）/ Looker Cloud Core / Looker Studio Pro で構築したバックオフィスデータマネジメントを支えるデータ活用基盤。局所最適化された自動化でデータの分断が起こらないように一元化。 これらは単なるツールではなく、バックオフィスという複雑な領域を、他社にも誇れる「ショーケース」に変えるための重要なパーツです。これらの技術選定の裏側や、なぜその構成を選んだのかというトレードオフについても、また別の機会に詳しく共有していきたいと考えています。 まだまだ道半ば ここまで「FDE 的な動き」や「強固な基盤」について書いてきましたが、正直に言えば私たちはまだ、目的を成し遂げるための努力が必要な「発展途上」の段階です。 バックオフィスの現場には、未解決の複雑な業務フローや、解決すべきレガシーな仕組みが山ほど残っています。しかし、だからこそ面白い。 完成されたシステムを保守するのではなく、業務の現場に深く入り込み、技術の力で泥臭い課題を一つずつ解きほぐし、組織のあり方そのものを変えていく。この「変化のプロセス」こそが、私たちがエンジニアリングを通じて体験できる最大の醍醐味です。 これらの状況は、程度の差こそあれ、どのような会社にも存在するものではないでしょうか。 Coding Agent が強力になる中で、これからのエンジニアに必要なスキルセットは現場の深い理解（ドメイン知識）と、それを技術で最適化するアーキテクチャ設計能力の掛け合わせではないか、というのをひとつの答えとして提示してみました。 最後に GYOMUハックは、AIを武器に変え、バックオフィスの「前線」で挑戦を続ける仲間を募集しています。 「技術を使って組織を強くしたい」「コードを書く以上に、本質的な課題解決をしたい」と考えているエンジニアの方、ぜひ私たちと一緒にバックオフィスの新しいあり方を創りませんか？ hire.wantedly.com
- 生成AI
- アーキテクチャ
- AWS
- Google Cloud
AWS ElastiCache for Redis を Valkey へ移行した話
はじめに はじめまして。フリーで DBRE に所属している pon です。 弊社では 2025 年 9 月から 2026 年 1 月の期間で AWS ElastiCache for Redis のうちエンジンバージョンが Redis のクラスターに対して Valkey エンジンへ移行するプロジェクトを行いました。 本プロジェクトでは約 50 個のクラスターが対象となり、期間内での移行が完了しました。 この記事では、 Valkey 移行プロジェクトの移行プロセスや躓いた事例を共有します。今後移行を考えている方の参考になれば幸いです。 Valkey 移行を決定した背景 AWS は 2026 年 1 月 31 日に Redis 5 系エンジンバージョンの標準サポートを終了しました。これが今回の移行プロジェクトの直接的なきっかけです。 サポート終了告知にあたり、互換性・コストの2つの観点から、弊社ではまず Redis 5.0.6 を使用しているクラスターをメイン対象に移行を行うことを決定しました。 Redis と Valkey の互換性 Valkey は元々 Redis 7.2.4 を fork した OSS であり、Redis 7.2.4 との互換性を保ちながら現在まで開発が続けられています。 そのため、Redis 7 時点から見た Valkey は機能的に同等であり、アプリケーション側の移行負担は大きくならないと判断しました。 コスト削減 Redis のライセンス変更に伴い、コミュニティはオープンソースの代替として Valkey を採用しています。 AWS でも Valkey のサポートを開始しており Amazon ElastiCache for Valkey では、Redis OSS と比較してServerless において33%、ノードベースでは20%安い価格で利用できるようになっています。 そのため、Valkey 移行を行うことでコストカットが実現できると考えました。 事前検証 弊社では実際に移行を行う前に、リスク評価を行った上で互換性の調査とダウンタイム計測の 2 つの検証を実施しました。 リスク評価 弊社における Redis の役割は大きくキャッシュと Job Queue の 2 つに分類されます。 キャッシュ用途であれば、移行時に問題が生じてもアプリケーションが直接 DB にアクセスするようフォールバックするため、サービスの停止には至りません。一方、Job Queue 用途の場合はメンテナンスウィンドウの確保やダウンタイムの検証が必要と判断しました。 また、いずれの用途においても GET SET 等基本的な Redis の機能を利用している箇所は少ないことを確認しました。 以上から、移行時の影響範囲は限定的と判断し、互換性の調査は以下の方針で実施しました。 ベンチマークツールによる基礎動作の確認 リリースノートベースの互換性調査 検証環境での動作確認 互換性の調査 今回は Redis 5.0.6 から Valkey 8.1 への移行です。 まず Valkey 8.1 環境において redis-benchmark を実行し、基本的な操作が問題なく動作することを確認しました。 次に、リリースノートベースでの互換性調査を行いました。Redis 7.2.4 と Valkey 7.2 の互換性は Valkey 7.2 release notes より保証されているため、互換性の調査を行ったのは以下 2 箇所でした。 Redis 5.0.6 から Redis 7.2.4まで Valkey 7.2 から Valkey 8.1 まで 結果、Redis 間におけるマイナーアップデートには破壊的変更が存在してはいますが、弊社プロダクトへの影響がないことを確認しました。 残りのカバレッジは Integration 環境でアプリケーションを実際に動作させることで担保しました。 ダウンタイム計測 リスク評価において Job Queue 用途ではダウンタイムの検証が必要と判断したため、計測を実施しました。 AWS における Valkey 移行では、既存クラスターのエンジンのみを切り替えるインプレース方式であればダウンタイムを最小限に抑えられます。 調査段階では以下の手順で複数回ダウンタイムの計測を行い、数秒程度のダウンタイムが発生することがわかりました。 Redis 5.0.6 クラスタとそこへアクセス可能な EC2 を作成 Redis 5.0.6 に1000個のランダムデータを挿入 継続的に SET / GET 操作を行うスクリプトを実行 しかし、実際に移行を行うと、このダウンタイム中のタイミングで接続を行った場合、クライアント側でキャッシュしているクラスター構成情報が更新されるまで reader endpoint を参照してしまう事象が確認されました。 アプリケーションの構成によってはダウンタイムが分単位になってしまうかもしれないので、注意が必要です。 移行手順の概要 弊社では AWS のインフラリソースを Terraform で管理しているため、PR ベースでの移行を行いました。apply_immediately パラメータやメンテナンスウィンドウで反映タイミングを適切に制御するように注意が必要です。 実際の移行の流れを以下にまとめます。 aws provider バージョンを v5.73.0 以降にする v5.73.0 以前では engine valkey に対応ができておらず provider のバージョンアップが必要です。 valkey 用の parameter group の作成 aws_elasticache_replication_group リソースの engine / version / parameter group の変更 apply 後、プロダクトチーム側で動作確認を行う そして、リトライ機構の有無・フォールバック先の有無・データロストの許容非許容等プロダクトの特性に合わせて移行を実施しました。 躓いた事例 aws_elasticache_cluster リソースで作成された ElastiCache 上記の移行手順は aws_elasticache_replication_group においては適用可能ですが、aws_elasticache_cluster の場合には適用できません。この場合、マネジメントコンソールからも直接のエンジン変更は不可となります。今回の移行対象の中にも数個該当リソースで作成された Elasticache が存在していました。 弊社では AWS 公式手順を参考に以下のコマンドでまず既存クラスターを元にレプリケーショングループを作成し、その後 Terraform 側で辻褄合わせを行った後に通常のValkey移行手順を実施することで移行を完了しました。 aws elasticache create-replication-group \ --replication-group-id "replication groupの名前" \ --replication-group-description "replication groupの説明" \ --num-cache-clusters 1 \ --primary-cluster-id "既存clusterのid" この変更はメタデータの変更のみが行われるため、ダウンタイムやデータロストは発生しませんでした。 同じエンドポイントを使用した復旧 ElastiCache for Redis から Valkey への移行では、切り戻しはサポートされていません。仮に Redis へ戻す場合には新しく Redis の ElastiCache を作成する必要があります。 今回の移行の中で 1 件、 Staging 環境における ElastiCache にて移行後より一部の内部プロダクト間通信に問題が発生し、 Valkey 移行を中止した事例がありました。 Staging 環境かつデータロストを許容するケースだったため、止血対応として同名で Redis を再作成することでエンドポイントを共有し復旧を図りました。 しかし、作成完了後しばらくアプリケーションからもタイムアウトが続き、別名で Redis を作り直したところ接続できるようになりました。自社側、AWS 側でもテスト環境にて再現を図りましたが、この事象の再現には至っていません。 再発防止として、実際の Production 環境では復旧までの時間も考慮し、あらかじめ別名の復旧用の Redis を立てておきエンドポイントを切り替える手順に変更しました。 移行を振り返って 今回は 50 個の Redis クラスターを移行しましたが、実際の移行作業はプロダクトチームが主体となって進めました。効率的に進められたポイントは以下だと考えています。 詳細な手順書の作成 移行背景、互換性調査結果、ダウンタイム計測結果を含める レビュー観点も明記し、PRベースで自主的に進められる形に 専用チャンネルでの情報集約 各チームの代表者を集め、知見やトラブル情報をリアルタイムで共有 DBRE は手順書とサポート体制の整備に注力し、プロダクトチームが自走できる環境を作ることを意識しました。 フリーの DBRE はまだ発展途上にあり、運用保守を直接担っている領域も多くあります。その中で、今回のプロジェクトはプロダクトチームの自律化を支援する Enabling の取り組みとして成果を出せたと考えています。プロダクトチームが自身の担当領域に責任を持ち、信頼性を守れる体制づくりを今後も推進していきます。 残りの Redis クラスターについても、今回の知見をもとに移行を継続していく予定です。 最後に DBRE では一緒に働いてくれるメンバーを募集しています。 今回の記事で興味を持ってくれた方、DBREとして活躍したいという思いのある方の応募をお待ちしています！ hire.wantedly.com hire.wantedly.com hire.wantedly.com
- AWS
- Redis
- Valkey
- Terraform