勘定系システムは、預金、振込、融資、利息計算、残高管理など、金融機関の中核業務を支える仕組みです。 そのため、小さな不具合であっても、顧客の資産や金融機関の業務、社会的な信用にまで影響が広がる可能性があります。 画面が設計どおり動くことだけを確認しても、十分な品質を保証できるとは限りません。 業務の流れ、周辺システムとの連携、夜間処理、データ移行、性能、障害からの復旧まで、複数の観点をつなげて確認する必要があります。 一方で、すべての機能や条件を同じ深さで確認しようとすると、膨大な工数がかかります。 大切

山下さんとの往復書簡、第四回目（そして私のパートの2回目）の記事となります。 前回が画鋲付き（！）とは気づかずに答えていました・・・。 今回の往復書簡は、当然ながら一つ前の記事を書いたのが自分ではないので、ひとりで書いているときと比べて注意ぶかく読んだうえで続きを書こう、という努力をしています。そうすると、繰り返し読むうちに考え方や文体の違いがだんだんと見えてきて、単純に直接会ってディスカッションしているときとはまた違った趣があります。 さて、話を本題に戻しまして。前回の山下さん記事の内容に対するコメント

この2つが混同されるだけで、チームの品質活動はズレていく 「テスト計画を作って」と言われて、あなたが作るものは何ですか？ テストのスケジュール？ テストケースの一覧？ 担当者の割り当て？ それとも、リスク分析やテスト方針？ もし「全部ごちゃまぜにしたドキュメント」を思い浮かべたなら、あなたは多数派です。そして、その混同こそが、チームがテストで迷走する根本原因です。 正直に言えば、そもそもテスト計画を作らず、いきなりテスト設計に入る現場のほうが多い。計画書があったとしても、前回のものを流用して日付だけ変えて

本記事は 2026 年 4 月 20 日 に公開された「 Getting started with the Oracle Database@AWS high performance networking 」を翻訳したものです。 Oracle Database@AWS (ODB@AWS) は、AWS データセンター内で Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata インフラストラクチャへのアクセスを提供します。Oracle Exadata イン

キャッチ。 伊藤さん、バトンを受け取りました。 冷房の効いた室内と近年とりわけ気候変動によって過熱している屋外とで、寒暖差の激しい日々が続いておりますが、いかがお過ごしでしょうか。 ノーコードテストツールのバトンは画鋲付きで渡した気分でした。 しかし、誠実に答えてくださり、ありがとうございました。 テスト自動化は運用が大切、というのは私自身、伊藤さんから繰り返し学んでいたことでしたね。 そして、ノーコードかコードベースかといった軸とは全く違うパラダイムの進化というのは大変示唆的です。 そもそも生成AIの多

チラシやポスター、商品パッケージ、店頭POPなど、印刷物からWebサイトへ誘導する手段として、QRコードは広く利用されています。 手軽に作成でき、スマートフォンで簡単に読み取れる。その便利さから、 QRコードそのものの品質や確認工程 については、十分に意識されないまま制作が進んでしまうことがあります。 しかし、QRコードは印刷後に不具合が見つかっても、 Webページのようにその場で修正することはできません 。 読み取れないQRコードが印刷されてしまえば、 チラシやパッケージ、販促物の刷り直し が必要になり

キャンペーンサイトの公開前に必要なのは、 制作担当者による最終確認だけではありません。 数百万円から1,000万円規模のキャンペーンで、応募フォームやLINE連携、QRコードなどに不具合が起きれば、サイトを修正するだけでは済まないことがあります。 応募できなかった利用者は戻らず、発注元の担当者は社内から、代理店や制作会社の責任者はクライアントから、「 なぜ公開前に見つけられなかったのか 」と問われる可能性があります。 そこで検討したいのが、 制作に関わっていない第三者によるサイト検証。 第三者検証は、代理

テスト観点が書けない・・・・、その壁、壊せます。 前回の記事で「テスト観点で語れ」「足りない観点を指摘しなさい」と書きました。でも、こう思った人もいるんじゃないでしょうか。 「で、テスト観点ってどうやって書くの？」 テスト観点という言葉は知っている。大事なのもわかる。でも、いざ書こうとすると手が止まる。何を書けばいいのか、どこまで書けばいいのか、これで合ってるのか。その不安が、最初の一歩を阻んでいます。 この記事では、テスト観点が書けない原因を3つの壁に分解して、それぞれの乗り越え方からチームでの運用方法

🎯はじめに 古くは業務パッケージ製品、そして近年はLow-Code Platform製品(以下LCPと略)を用いて、短期間で業務アプリケーションを構築できる時代になりました。 一方で、LCPによる開発では、画面や業務ロジックの実装がスムーズに進む分、「実現したい業務が動くか」といった機能面の確認に意識が向きやすくなります。しかし、本番運用を見据えたときに重要になるのは、それだけではありません。性能・可用性・セキュリティ・拡張性・運用保守性といった、いわゆる非機能の観点も、あわせて抑えておく必要があります。

LLM as a Judge とは、AI・エージェントの回答品質を自動的に評価する手法の一つで、大規模言語モデル（LLM）を「評価者」として活用し、人手による評価コストを大幅に削減しながら、一貫した基準で大量のテストケースを継続的に評価する方法です。 現在、生成AI（LLM）を自社の業務プロセスや自社プロダクトへ組み込む企業が急速に増えています。しかし、検証を進める中で多くの開発現場が直面するのが「AIの品質管理（QA）の難しさ」という壁です。 AIが出力する結果の妥当性をどう判断し、どのように安定性を担

はじめに  就職ITソリューション1課のM.Yです。  本記事では開発の実務経験がないまま上流工程の業務を担当することについての自分の考えを述べています。自分自身も（配属時から数えると）まだ3年も経験していない身で恐縮ですが、自分自身の振り返りも兼ねております。  なお、本記事についてはあくまで個人的な考えによるもので所属部署・PJの方針ではないことをご承知おきください。  想定読者  ・新卒入社や異動などをきっかけに、開発経験がないまま上流工程を担当する

はじめに「AIを導入すれば生産性が上がるらしいが、私たちのチームはどこから手をつければいいのだろう？」と悩んだことはありませんか？既存のレガシープロジェクトをAI主導型プロジェクト（AI-driven...

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

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

テスターの信頼構築——再現性のあるパターン バグを報告した。正確に書いた。でも開発者の反応は「ふーん」の一言で終わった——テスターなら、一度はこの経験があるんじゃないでしょうか。 問題は、報告の質ではありません。あなたの話を、開発者は聞いていますか？ 戦略的思考の前提には、「この人の意見は聞く価値がある」と開発者に思われている状態が必要です。これがなければ、どんなに鋭い分析も、どんなに正確なリスク予測も、チームには届きません。 この記事では、テスターが開発者からの信頼を獲得するための、再現性の高いパターン