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

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

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

Excelやスプレッドシートでテストケースを管理していると、最新版が分からない、進捗集計に時間がかかる、不具合情報と紐づかないといった問題が起こりやすくなります。 最初は手軽に運用できても、案件数や関係者が増えるほど、確認作業や報告資料作成に追われやすくなります。 ただし、テスト管理ツールは「便利だから導入したい」という理由だけでは承認されにくいものです。 承認者が知りたいのは、現場の使いやすさだけでなく、会社として投資する必要性、費用に見合う効果、導入しない場合のリスクです。 そのため稟議書では、導入目

「不具合管理とテスト管理は同じものなのか」と迷う場面は、テスト工程を管理する立場になるとよく起こります。 不具合票は作っているのに、テストケースの消化状況、未実施項目、品質リスク、リリース可否を説明できない現場も少なくありません。 結論からいえば、不具合管理は発見された問題の対応を管理する活動であり、テスト管理はテスト活動全体を管理する活動です。 不具合管理では、見つかった不具合を記録し、調査、修正、再テスト、クローズまで追跡します。 テスト管理では、テスト計画、テストケース、実施状況、結果、不具合情報、

システムテストに入ると、要件定義書、設計書、テスト仕様書、不具合管理表が別々に動き始め、どの要件をどのテストで確認しているのか見えにくくなります。 その結果、要件とテストケースの対応関係を説明できない、テストの抜け漏れが不安、品質レビューで根拠を求められて困る、といった悩みが起こりやすくなります。 システムテストでは、単にテストを実行するだけでなく、要件・設計・テスト結果・不具合をつなげて管理することが重要です。 トレーサビリティ管理を理解すると、テストの網羅性、仕様変更時の影響範囲、不具合対応の優先度を

G-gen の今村です。当記事では、Cloud SQL で提供されているパフォーマンス最適化機能の1つである インデックスアドバイザー について解説します。 概要 インデックスアドバイザーとは 仕組み 料金と要件 料金 対象エディションと要件 有効化の手順 推奨事項の確認 推薦インデックスの確認方法 画面に表示される評価データの内容 Gemini による支援 推奨事項の適用 概要 インデックスアドバイザーとは Cloud SQL の インデックスアドバイザー 機能は、Cloud SQL で実行されたクエリ

はじめに 登壇資料 登壇内容 発表の背景 なぜ全部自動化しなかったのか 作成したCLIの概要 半自動設計のポイント 細かいTips LLMに渡す範囲を狭くする 読み取りを自作ツールで行う ツールを絞る Claude Code標準プロンプトは必要な場所だけ使う 登壇してみて まとめ はじめに こんにちは！ エンジニア４年目のTKDです！ 今回は、2026年5月12日に開催されたClaude Code Meetup Japan #5で「Claude Agent SDKを活用した脆弱性調査自動化」というタイトル