こんにちは、データドリブン推進室の鶴です！ 日々アップデートされてどんどん使いやすくなってきているLightdashですが、先日カラーパレット機能の強化アップデートが行われました！ Lightdashのカラーパレット機能って？ Lightdashのカラーパレットは、チャート作成時に使われる色をあらかじめ定義しておける機能です。 元々、カラーパレット機能はLightdash内の組織(Organization)レベルで設定したパレットしかチャートで利用できず、違う色を選択するには手動で色を選ぶ必要があったため

2026年6月の主な製品アップデートをご紹介します。 製品アップデート リリース準備状況 – パブリックベータ Release Readiness Indexは、ソフトウェアテストにおいてQAチームが直面する最も難しい問いの一つである「リリースできる状態にあるのか？」に答えるための機能です。 カバレッジ、実行の進捗、欠陥リスクを組み合わせ、各マイルストーンごとに単一の準備状況スコアとして可視化することで、リリースに対する確信度をデータに基づいて明確に把握できます。また、リリース判断を行う前に注意が必要な領

システム開発では、定例会議で「少し遅れているものの挽回できる」と報告されていたにもかかわらず、重要な節目の直前になって成果物が完成していないと判明することがあります。 遅延が明らかになると、現場には作業の前倒しを求め、顧客や経営層には事情を説明し、利用部門とはリリース後の計画を調整しなければなりません。 しかし、状況が見えないまま作業を急がせても、手戻りや不具合が増え、さらに納期が延びるおそれがあります。 重要なのは、単純に作業速度を上げることではなく、 現在地・残作業・遅延原因・影響範囲を可視化すること

納期の遅れ、不具合の増加、終わりの見えない仕様変更が重なると、「すでに炎上しているのではないか」と不安になりやすいものです。 定例会議で「対応中」「確認中」という報告が続き、正確な進捗や完了予定日が見えなくなっている場合は、単に忙しいだけでは済まない可能性があります。 システム開発の炎上は、一つの大きな失敗によって突然起こるとは限りません。 要件の曖昧さ、無理な見積もり、進捗管理の不備、品質の悪化、意思決定の遅れ などが連鎖し、徐々に立て直しにくい状態へ進んでいきます。 こうした状況で責任者の交代や人員追

システム開発のWBSを任されたものの、工程をどこまで細かく分ければよいのか分からず、手が止まってしまうことは珍しくありません。 過去に使われたテンプレートがあっても、開発する機能や体制、契約範囲が異なれば、そのまま流用するだけでは必要な作業が抜けたり、不要な項目が残ったりします。 WBSは作業名を並べるだけの表ではなく、 成果物を起点に必要な作業を分解し、担当者・工数・期限・依存関係・完了条件を整理するための土台 です。 適切に作成すれば、見積もりの精度を高められるだけでなく、タスクの抜け漏れや認識のずれ

システム開発を進めるとき、開発会社から提示されたスケジュールを見ても「 この期間で本当に間に合うのか 」「 どこを確認すればよいのか 」と不安になる場面は少なくありません。 特に、初めて開発を発注する場合や、社内の関係部署をまとめる立場にある場合は、専門用語や工程の多さに戸惑いやすいものです。 システム開発のスケジュールは、単なる日程表ではなく、 納期・品質・予算を守るための設計図 です。 工程ごとの目的や期間の目安を理解しておくと、開発会社との打ち合わせでも確認すべきポイントが見えやすくなります。 また

システム開発で要件変更が起きる原因や費用・納期・品質への影響を解説します。変更を受け入れる判断基準、追加費用の確認項目、発注側と開発側が揉めない変更管理の手順も紹介します。 「 画面を少し直したいだけなのに、開発会社から追加費用と納期延長を提示された 」 このような予期しない状況に戸惑うケースは少なくありません。 開発側でも、現場や顧客の要望には応えたい一方、変更を無条件で受け入れれば、予算超過や品質低下につながるという悩みがあります。 システム開発における 要件変更 は、必ずしも失敗やトラブルを意味する

システムやアプリは、画面上では問題なく動いているように見えても、利用環境や操作手順によって思わぬ不具合が発生することがあります。 リリース後に不具合が見つかれば、利用者からの信頼低下や問い合わせの増加、改修コストの発生、キャンペーン機会の損失など、事業に大きな影響を及ぼしかねません。 こうした不具合をリリース前に見つけ、 システムの品質を支える のが、ソフトウェアテストの仕事です。 株式会社モンテカンポ は、ソフトウェアやWEBシステム、キャンペーンサイト、外部サービスとの連携、QRコードの生成・検証まで

1. はじめに Quality Engineering Gのとみよしです。 私が所属するQAチームではオープンソースのテスト管理ツールであるTestLinkを採用しています。 :::message TestLinkとは テストケースの作成・管理からテスト計画の立案、実行結果の記録まで一元管理できるオープンソースのテスト管理ツールです。 ::: TestLinkへの結果入力は工数がかかるため、Excelマクロで結果を一括入力できるXMLファイルを生成する仕組みを運用していました。 しかしこのExcelマクロ

システム開発を進めるなかで、開発会社から想定外の追加見積もりを提示されることがあります。 「当初の見積金額に含まれていると思っていた」「本当に支払う必要があるのか分からない」と戸惑う発注担当者も少なくありません。 ただし、追加費用が発生したからといって、すべてが不当な請求とは限りません。 当初の契約に含まれていない機能の追加や、合意後の仕様変更によって作業が増えた場合は、追加費用が必要になることがあります。 一方で、当初の仕様どおりに動かない不具合の修正や、開発会社側の設計ミスまで発注者が負担すべきとは限

開発会社から見積書を受け取ったものの、提示された金額が高いのか安いのか判断できず、困るケースは少なくありません。 複数社に見積もりを依頼しても、会社ごとに項目や金額が大きく異なり、単純に総額だけを比較できないこともあります。 システム開発の費用は、必要な作業量だけでなく、担当者の単価、機能の複雑さ、求める品質、納期、開発体制など、さまざまな条件によって変わります。 そのため、見積書を確認するときは、金額の大小よりも、 どの作業が、どのような条件で、どこまで含まれているか を見ることが重要です。 算出方法や

テスト観点を軸にした品質サイクルのすすめ 「テストが終わらない」——ソフトウェア開発に携わる人なら、一度はこの言葉を口にしたことがあるのではないでしょうか。リリース直前に湧き出るバグ、収束しない不具合、膨れ上がるテストケース。なぜ、テストはいつも終わらないのか。 結論から言います。テストを「する」ことを目的にしているからです。 テストケースを消化すること、カバレッジを上げること、全項目を網羅すること。これらは手段であって、目的ではありません。本当に問われるべきは、「そのテストは品質を上げているのか？」とい

この記事では、パブリック API および Amazon Q との統合を備えた AWS Billing and Cost Management (請求とコスト管理) コンソールのクレジット詳細ページについてご紹介します。これにより、お客様はクレジットの確認と管理を一箇所で行えるようになります。 AWS クレジットを大規模に管理することは容易ではありません。組織の AWS 利用が拡大するにつれて、複数のプログラムからクレジットが蓄積されていきます。残高の追跡、消費の把握、割り当ての制御は、ますます複雑になって

こんにちは。呉爾羅探検隊 副隊長の伊藤です。（ちなみに読める人もいるでしょうが、呉爾羅【ごじら】です。そして肩書は冗談です。念のため） このIT業界では、プロジェクト管理に Jira（ジラ） をはじめとするチケット管理ツールを使うことがよくあります。

こんにちは。サイオステクノロジー武井です。 PlaywrightによるE2Eテストをできる限り自動化するためのエージェントとスキルを作りました。前提となるE2Eテストの説明から、実際に作ったエージェントの構成までを順に紹介します。 E2Eテストとはそもそも何か E2Eテストは、画面操作を伴うテストを自動で行うもの、つまりブラウザ操作を自動化する仕組みです。代表的なOSSが   Playwright   で、Microsoftが開発しています。以前は   Selenium   が広く使われていましたが、現在