はじめに こんにちは、バックエンドエンジニアのかがの（ @ykagano ）です。 2026/8/27（木）に「PHP Tech Talk Night ～ after phpcon 2026 ～」を合同開催しました。 本記事では、当日の登壇内容や会場の様子についてお届けします！ イベント概要 「PHPカンファレンスの熱量を次につなげる」をテーマに、株式会社viviONさま・株式会社kubellさま・ピクシブ株式会社さま・BASE株式会社の4社合同で開催し、会場は株式会社viviONさまのオフィスをお借りし

「だいたい○○ケースくらいですかね」の正体 テスト計画でスケジュールを立てるとき、テストケース数の見積もりはどうやっているだろうか。 正直なところ、多くの現場では「前回と同じくらいの規模感だから○○ケースくらい」「経験的にこの手の機能なら△△ケース」という見積もりが主流だと思う。自分もそうだった。 これで困るのは3つの場面。 初めての領域。 過去実績がないから「だいたい」が通用しない 説明責任。 上席に「なぜその工数なのか」と聞かれたとき、根拠を示せない 精度のばらつき。 見積もる人によって2〜3倍の差が

こんにちは。KINTOテクノロジーズ（KTC）で、ユーザーファースト推進活動の運営に関わっているる かーびー です。 KTCでは 「ユーザーファースト」 を会社の重点方針のひとつに掲げており、社内勉強会「ユーザーに寄りそわNight!」の開催もその取り組みのひとつです。 Vol.02 のレポートに続き、今回はVol.03の内容をお伝えします。 テーマは「クイックなリサーチ」。サービスに感じた「このまま進めていいのかな」という違和感を、すぐに改善案にせず、手元にある情報から一度確かめてみる進め方です。 サー

＜【連載】具体と抽象を往復しよう！ 記事一覧＞ ※クリックで開きます 【第1回】分類学とアブストラクト（抽象化）〜AI時代を生き抜くための「思考の武器」〜 【第2回】分類学とアブストラクト（抽象化）〜「思考の武器」をテスト・QAの現場に活かす〜 【第3回】『具体と抽象』から見る、デザインと直感 はじめに 前回の記事では、分類学という一見するとソフトウェア開発やQAとは遠い学問を手がかりに、「抽象化とは、複数の具体から共通する本質を抜き出し、名前を与えることだ」という話を書きました。 クジラとカバが近縁であ

はじめに ITコンサルタントのKです。以前、Webサービスの新規開発に関わっておりました。機能開発の段階だったので、機能やビジネスロジックが正しいことの評価が大半で、運用の評価はもっと先という段階でした。 昨今のモダナイゼーションにおいて、開発と運用は切り離せない関係にあります。クライアントサーバー方式からクラウドネイティブなWebサービスへと進化させるプロジェクトを例に、 「継続的な価値提供」を支えるプロセスと品質の考え方 を、鉄道の仕組みになぞらえて紐解いてみたいと思います。 プロジェクトの背景：目指

こんにちは。SHIFTでソフトウェアテストの自動化AIサービス「ネムラナイ」の開発に取り組んでいる松本です。

介護ソフトのテストを任されたものの、「一般的な業務システムと同じ観点で確認してよいのだろうか」と迷うケースは少なくありません。 介護ソフトには利用者情報の管理だけでなく、アセスメント、ケアプラン、介護記録、サービス実績、各種帳票、介護報酬請求など、介護現場のさまざまな業務が集約されています。 そのため、個々の画面が仕様通りに動いていることだけを確認しても、十分なテストとはいえません。 たとえば、介護記録への入力自体は正常でも、その情報がサービス実績や帳票、請求処理へ正しく反映されなければ、現場では重大な問

一般的なソフトウェア開発や評価の経験があっても、医療機器の開発に関わり始めると「これまでと同じテストで十分なのか」と迷いやすくなります。 医療機器では、単に仕様通り動作することを確認するだけでなく、ソフトウェアの誤動作が患者や医療従事者へ与える影響を考え、 安全性に関わるリスクが適切に管理されていることまで確認する視点 が欠かせません。 さらに、IEC 62304／JIS T 2304によるソフトウェアライフサイクル、ISO 14971／JIS T 14971によるリスクマネジメント、サイバーセキュリティ

Webシステムや業務システムのテスト経験があっても、電子カルテでは「一般的なテストと何が違うのか」「どこまで確認すれば十分なのか」と迷いやすいものです。 電子カルテでは、単に画面や機能が仕様どおり動けばよいわけではありません。 患者情報の取り違え、診療記録の不整合、処方や検査結果の誤表示、外部システムとの連携不良などは、診療業務そのものへ影響する可能性があります。 そのため、 不具合が起きた場合に医療現場へどのような影響が生じるか を考えながらテストを設計することが重要です。 また、現在の電子カルテは電子

title はじめに こんにちは、株式会社エブリーでデリッシュキッチンのiOSアプリの開発をしている成田です。 現在は、プレミアムユーザーの登録数の向上やプレミアムユーザーの体験をより良くすることを目的としたチームで開発をしています。 サブスクリプションの解約は、これまで開発者にとってブラックボックスでした。ユーザーが App Store の管理画面で「サブスクリプションをキャンセルする」を押すとき、アプリ側にできることは何もありません。引き止めのメッセージも、オファーの提示も、そもそも解約されようとして

本記事は 2026 年 8 月 18 日 に公開された「 Characterizing SQL*Net latency in your application for Oracle Database@AWS migrations 」を翻訳したものです。 Oracle Database@AWS (ODB@AWS) は、AWS データセンター内で Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata インフラストラクチャを利用できるサービスです。ODB@

暗号資産取引所におけるテスト案件について、「一般的なウェブサービスのテストと何が違うのか」「金融や暗号資産の知識がなくても対応できるのか」と不安を感じるケースは少なくありません。 暗号資産取引所では、画面や機能が仕様どおり動くだけでなく、 顧客の資産や取引データが正確かつ安全に処理されること が非常に重要です。 国内の暗号資産交換業者には登録制度が設けられており、利用者保護の観点からシステム管理や分別管理などが求められています。 さらに近年は、署名鍵の管理だけではなく、外部委託先を経由した攻撃なども踏まえ

決済や送金などを扱うFinTechシステムでは、「一般的なWebシステムと同じテストをすれば十分なのか」と判断に迷う場面があります。 画面や機能が仕様どおり動くことはもちろん重要ですが、金融サービスでは、わずかな処理ミスでも残高不整合や二重決済といった大きな問題につながる可能性があります。 そのため、 取引・データの正確性、API（アプリケーション・プログラミング・インターフェース）による外部連携、性能、セキュリティ、障害時の復旧 まで含めて考えることが欠かせません。 また、テスト項目を大量に増やせば安心

融資システムのテストを担当すると、「一般的なシステムテストと同じ考え方でよいのか」「どの機能まで細かく確認すればよいのか」と迷いやすいものです。 特に融資業務は、申込情報を登録して終わるものではなく、 審査・承認・契約・融資実行・返済まで複数の処理が連続してつながっています 。 個人融資を扱うシステムでも、商品や申込内容に応じたワークフロー、自動審査、信用情報機関への照会、勘定系システムとの連携など、多くの機能が組み合わされています。 そのため、個々の画面が正常に動くことだけを確認しても、融資システム全体

クレジットカードシステムのテストを担当すると、「正常に決済できることは確認したものの、ほかに何をテストすればよいのかわからない」と悩むケースは少なくありません。 クレジットカード決済は金銭を扱うため、一般的な入力フォーム以上に、 テスト漏れが売上や顧客対応へ大きな影響を与えやすい機能 です。 正常なカードで購入できるかだけではなく、カード利用拒否、本人認証の失敗、通信エラー、取消、返金、二重決済といった状況まで想定する必要があります。 さらに、画面上では決済に成功していても、注文データや管理画面のステータ