本記事は 2026 年 4 月 26 日に AWS DevOps & Developer Productivity Blog で公開された AWS Transform custom: Enterprise Code Modernization with the Learn-Scale-Improve Flywheel を翻訳したものです。翻訳は Solutions Architect の山崎 宏紀が担当しました。 エンタープライズにおけるモダナイゼーションは、大きな転換点を迎えています。1 つのリ

SCANOSS サポート担当の橋本です。 弊社では SCA ツールのナレッジベース製品である SCANOSS 製品を代理店として取り扱っています。 SCANOSS 製品の開発元である SCANOSS 社より、SCANOSS 社内の Dependency-Track 運用ノウハウドキュメントを提供いただきました。 Dependency-Track は SCANOSS 製品と統合することが可能な OSS であり、SBOM の管理運用を実施する上で有用なソフトウェアであるため、本ドキュメントを翻訳の上公開いたし

プロダクトの急成長に伴い、マイクロサービスの増加やチームの多角化が進むメガベンチャーの現場では、品質管理の難易度が飛躍的に高まっています。 各チームが独自のルールでテストを進める「部分最適」の運用を続けてきた結果、情報の分断や先祖返り、そして予期せぬ障害の増加に頭を悩ませているQAマネージャーも少なくありません。 長年使い慣れたExcelやスプレッドシートによる管理は、初期段階こそ柔軟ですが、組織がスケールするにつれて「属人化の温床」や「進捗可視化の壁」へと姿を変えてしまいます。 そこで今回はQAを「コス

はじめに Jenkins Pipelineは、ビルド・テスト・デプロイといった一連の作業を Jenkinsfileとしてコード化（Pipeline as Code） する仕組みです。 作業手順を人の手からコードへ移すことで、次のようなメリットが得られます。 再現性：誰が実行しても同じ結果になる レビュー可能：Jenkinsfileをコードレビューできる 変更履歴が残る：いつ・誰が・何を変えたか追跡できる 運用の自動化：手作業のミスや抜け漏れを減らせる しかし、Jenkinsfileは単なるスクリプトではあ

本ブログは 2025 年 7 月 21 日に公開された AWS Blog “ Beyond IAM access keys: Modern authentication approaches for AWS ” を翻訳したものです。 AWS の認証において、 AWS Identity and Access Management (IAM) アクセスキーなどの長期認証情報に依存することは、認証情報の漏洩、不正な共有、窃取などのリスクをもたらします。この記事では、AWS のお客様が従来 IAM アクセスキーを

はじめに 開発者のローカル環境では問題なくビルドが通るのに、CI（継続的インテグレーション）環境上のJenkinsなどでビルドするとエラーになってしまうような「環境依存のビルドエラー」は、多くの開発現場で一度は経験する悩みではないでしょうか。 特に、歴史の長いシステムを保守・運用している現場では、開発者のPCには最新のVisual Studioがインストールされている一方で、ビルドサーバーには古いバージョンのビルドツール（MSBuildなど）がそのまま残っているというケースが珍しくありません。 本記事では

はじめに CI/CDツールとして広く利用されているJenkinsですが、Windows環境のスレーブノードやエージェントでビルドを実行する際、特有のエラーに悩まされることがあります。 その代表的なものが、ファイルパスに関連するエラーです。 Linux環境では問題なく動作していたジョブをWindows環境に移行した際や、プロジェクトのディレクトリ階層が深くなったタイミングで、突如としてビルドが失敗することがあります。 本記事では、Jenkinsでのビルド実行時に**「パスの一部が見つかりませんでした」**と

こんにちは。LINEヤフーの永吉です。今回は2025年の締めくくりとして開催した「LINEヤフー Developer Meetup #2 in Fukuoka」の様子を振り返ります。イベント概要12月...

はじめに CI/CDツールとして広く利用されているJenkinsにおいて、ユーザー管理を効率化するためにLDAP（Lightweight Directory Access Protocol）サーバーとの連携を行うことは一般的な運用設計の一つです。しかし、この認証周りの設定変更は非常にデリケートな作業であり、設定を誤ると「管理者を含む全ユーザーがログインできなくなる」という、いわゆるロックアウト状態に陥るリスクがあります。 管理画面にすら入れなくなってしまった場合、ブラウザ上からの設定修正は不可能です。こう

はじめに こんにちは。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つの決定的なサインを具体的な症状

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