はじめに こんにちは。GENIEE SFA/CRM インフラチームリーダーのZOU（シュウ）です。 私は普段、AWSをインフラ基盤とする GENIEE SFA/CRM プロダクトのインフラ系の保守運用、コスト削減、リアーキテクチャーなどを担当しています。 今回は「Everything as Codeの践行」という事例をご紹介します。 Everything as Codeとの出会い Everything as Codeとの出会いは AWS Summit 2025 の「AI Agent 時代のソフトウェア開発

ソフトウェア開発において、テストや品質保証（QA）は安定したリリースに不可欠なプロセスです。 しかし「テストの情報共有」という目立たない作業が、チーム全体の生産性を著しく下げているケースが少なくありません。 テストケースはExcel、進捗はSlack、バグは課題管理ツール…と情報がバラバラに散らばっているため、必要な情報の確認に時間がかかり、会議は長引き、手戻りが頻発。 その結果、本来集中すべきテスト設計や自動化といった本質的な業務にリソースを割けず、開発サイクルが遅延するという悪循環に陥って

日々、品質保証（QA）やテスト業務に携わる中で、「このテストは〇〇さんがいないと回らない」「過去にどう検証したか誰も分からない」といった不安を感じることはありませんか？ 特定のエンジニアの経験や暗黙知に依存したテストプロセス、すなわち属人化は、開発速度とプロダクト品質を蝕む最大の要因です。 属人化が進むと、バグの再発（リグレッション）が常態化し、テストのたびに膨大な人的工数がかかり、結果的に開発サイクルが停滞します。 この問題は、手動テストの負荷軽減やCI/CD（継続的インテグレーション/継続的デリバリー

夜遅くまで不具合を一つひとつ丁寧に潰し、品質を維持するために奔走している…。 にも関わらず、その努力がなかなか正当に評価されないという現実にお悩みの方もいらっしゃるのではないでしょうか。 ソフトウェア開発の現場では、QA（品質保証）やテスト業務は「リリースできて当たり前」「バグがないのは当然」といった見られ方をされがちです。 開発メンバーが新しい機能を実装すれば、その成果は「機能が追加された」という形で明確に現れます。 しかし、QAの努力は「何も問題が起きなかった」という、一見すると地味な結果としてしか示

プロジェクトでバグが多発し、手動テストの負荷が増大して開発サイクルが鈍化していませんか。 品質を維持しながら開発スピードを上げるためには、非効率なテストプロセスを根本から見直す必要があります。 特に几帳面で効率を重視するエンジニアにとって、テスト管理のボトルネックはストレスの大きな原因となります。 しかし、「テスト自動化やツール導入を始めたいが、何から手をつけるべきかわからない」という課題を抱える現場は少なくありません。 本記事では、現在のテスト管理体制が限界を迎えている3つの決定的なサインを具体的な症状

日々のテスト業務で「テストを管理するための資料作成」に追われ、本来注力すべき品質検証や分析が後回しになってしまう状況は、ソフトウェア品質保証の現場で決して少なくありません。 報告用のスプレッドシート作成、テスト進捗の手動更新、各種エクセルシートのバージョン管理。こうした「テスト管理作業」が膨らむと、真に価値ある作業＝バグの発見、リグレッション防止、プロセス改善などがおろそかになる危険があります。 例えば、複数のテスターが共有スプレッドシートを使っていると、誰が最新の状態を持っているか分からず、重複作業や抜

期待を込めてテスト自動化を導入したにもかかわらず、「なぜか現場の工数が減らない」「むしろ以前より面倒になった」と感じることはありませんか。 テスト自動化は、本来、時間のかかる反復作業からエンジニアを解放し、生産性を劇的に向上させるための手段です。 しかし、多くの現場で、その期待していた「自動化＝効率化」が実現しないという現実があります。 その原因の多くは、テスト実行レイヤーではなく、テストの「管理」レイヤーに潜んでいます。例えば、以下のような状況に心当たりはないでしょうか。 「自動化スクリプトはあるのに、

こんにちは。LINEヤフーのセキュリティプラットフォーム関連の開発を行っている矢島です。LINEヤフーのセキュリティプラットフォーム部門では、インターンを実施しています。今年度は6名の方に参加いただき...

日々増加するテストケースの管理に頭を悩ませていませんか？ 手作業でのデータ入力や、テストスクリプトに直接データを書き込む「ハードコード」方式では、メンテナンスが困難になり、テスト自動化のメリットを十分に享受できないこともあります。 このような課題を解決する手段として今、注目を集めているのが「データ駆動テスト」です。 そこで今回はデータ駆動テストの基本的な概念から、具体的な実装方法、メリット・デメリット、そして明日から実践できる導入手順まで、ソフトウェアテストエンジニアが知っておくべきポイントを網羅的に解説

本記事は米国時間 8 月 13 日に公開された「 Unlock your development productivity with Kiro and Model Context Protocol (MCP) 」の日本語抄訳版です。Kiro の最新情報は、https://kiro.dev/ をご覧ください。 Kiro はその組み込み機能によって、私にとって個人的な開発加速装置となってきました。ファイルの読み書きや Bash スクリプトを実行するツールを使うことで、Kiro は 仕様駆動開発（spec-dr

近年、ソフトウェア開発の現場では、高品質な製品を迅速に市場へ投入することが強く求められています。 しかし、複雑化するシステムと加速する開発サイクルの中で、テストプロセスがボトルネックとなり、品質と速度の両立に課題を抱える企業も少なくありません。 特に、これまでテスト自動化を推進してきたものの、ツールが分散し、パイプラインが複雑化した結果、リリース直前での人海戦術が常態化しているといった状況に直面している方もいるのではないでしょうか。 そこで今回はこのような課題を解決する鍵となる「テストオーケストレーション

テスト自動化の普及と、効率化を図るためのCI/CDツールについて説明します。オンプレミス型のJenkinsの利点とデメリットについても解説しています。

このブログの内容をポッドキャストでも配信中！ ソフトウェア開発現代史年表 Ver2.07 このブログの内容をポッドキャストでも配信中！ はじめに DevOps誕生以前（〜2000年代前半） 2009年：DevOpsのはじまり Flickrの伝説的講演「10+ Deploys Per Day」 パトリック・ドボアと「DevOps」という言葉の誕生 2010年代前半：ジェズ・ハンブルと継続的インテグレーション（CI）から継続的デリバリー（CD）への発展 継続的インテグレーション（CI）とは何か 継続的デリバリ

こんにちは、コミュニケーションアプリ「LINE」のiOSクライアントアプリにおいて開発基盤を担当している、モバイル・ディベロッパーエクスペリエンスチーム所属のfreddiです。 最近、LINEのiO...

優れたレジリエンス戦略には、高可用性での運用とビジネス継続性の計画が不可欠です。また、地震や洪水などの自然災害、停電やネットワーク接続の障害などの技術的な障害の発生の考慮も必要です。AWS は、高可用性にはマルチ AZ 戦略を、ディザスタリカバリにはマルチリージョン戦略を 推奨しています 。このブログでは、米国を拠点とする保険会社であるお客様の事例を通じて、クラウドネイティブサービスを使用して 3 層アプリケーションのディザスタリカバリを実装する方法を説明します。 この保険会社では、かなりの数の重要なアプ