保険システムのテストでは、申込画面が正しく動くかを確認するだけでは十分ではありません。 保険料計算、引受査定、契約成立、収納、契約内容の変更、解約、失効、復活、保険金支払、帳票作成、会計処理、外部システム連携など、確認すべき領域が広範囲に及びます。 さらに、年齢、契約日、保険期間、払込方法、保険金額、特約といった条件の組み合わせによって、期待される結果が変わります。 すべての組み合わせをテストしようとするとケース数が膨大になり、納期や要員の制約から実行できなくなることも少なくありません。 だからこそ、保険

証券システムのテストを任されたものの、一般的な業務システムとの違いが分からず、どこまで確認すればよいのか迷うケースは少なくありません。 証券取引では、注文受付、発注、約定、残高更新、顧客への通知といった複数の処理が連動します。 そのため、画面が仕様どおりに動くことだけを確認しても、取引全体の品質を十分に保証できません。 注文データが正しく市場へ送信されているか、約定結果が口座残高へ反映されているか、通信障害の発生時にも二重注文を防げるかなど、確認すべき範囲は多岐にわたります。 さらに、相場急変時のアクセス

GitHubでIssueやコード変更を管理していても、テストケースや実行結果はExcel、スプレッドシート、社内Wikiなどに分散しがちです。 情報が複数の場所に分かれると、最新版のテストケースを探す、テスト結果を転記する、同じ不具合をGitHubへ登録し直すといった作業が発生します。 プロジェクトやメンバーが増えるほど、こうした小さな負担が積み重なり、テスト漏れや対応状況の認識違いにつながります。 そこで役立つのが、 GitHubと連携できるテスト管理ツール です。 テストケースや実行結果を一元管理し、

品質戦略のレイヤーに、QAがいない。 PdMやDevには役割を広げていくキャリアパスが見えている。PdMはプロダクト組織のリーダーへ、Devはアーキテクトやテックリードへ。でも、QAの先は確立されていない。AI時代になって、この空白がさらに際立って来るように感じる。 ソフトウェア開発の現場には、3つの主要ロール、いわゆる3アミーゴがいます。 PdM（プロダクトマネージャー）：「何を作るか」を決める人 Dev（開発者）：「どう作るか」を実現する人 QA（品質保証）：「それで正しいか」を問う人 自分は開発者→

はじめに：なぜKafkaのエンドツーエンド暗号化なのか？LINEメッセンジャーでは、毎日数十億件のメッセージがやり取りされています。この膨大なデータはさまざまなシステムに送信されますが、その中には個人...

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

山下さんとの往復書簡、第四回目（そして私のパートの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が出力する結果の妥当性をどう判断し、どのように安定性を担