B-Testing.fm

今回から新しいテスト設計技法シリーズがスタートします。取り上げるのは「クラシフィケーションツリー技法」。テスト対象のデータ領域を樹形図で可視化するこの手法について、初心者の方でもすぐに実践できるよう、コーヒーショップのカスタマイズを例にステップ・バイ・ステップで詳しく解説します。📌 今回のエピソードのポイントクラシフィケーションツリー技法の定義とメリット基本用語「ルート」「クラシフィケーション」「クラス」の役割コーヒーショップの複雑な価格設定をツリーで整理する手順「最下層は必ずクラスにする」など、作成時の重要なルール感想紹介：テスト設計コンテスト（ASTER）の魅力について📕参考文献JSTQB用語集🕒 チャプター(00:00) オープニング(02:06) クラシフィケーションツリー技法とは何か(03:08) 完成イメージと用語（ルート・クラス等）の解説(03:46) 実践！コーヒーの価格テストを題材にしたツリー作成(05:02) ステップ1：確認したいこと（ルート）を一番上に書く(05:28) ステップ2：テストに使う条件（クラシフィケーション）を抽出する(06:47) ステップ3：条件に対応する要素（クラス）を書き出す(08:54) 最下層の「クラス」がテストで使う値になる(09:55) 感想コーナー：テスト設計コンテストへの興味(11:24) エンディング📢 あなたのご意見をお聞かせください「テストデータの整理に図解を使っていますか？また、皆さんのこだわりのコーヒーカスタマイズがあればぜひ教えてください！」X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

E2E（エンド・ツー・エンド）の自動テストを作成する際、一つの長いシナリオにするか、細かく分割するか迷ったことはありませんか？今回は「テストの目的」に焦点を当て、ピザの注文システムを具体例に、状況に応じた最適なテストの組み方について深掘りします。テスト実行時間の短縮と、不具合の検出精度を両立させるためのヒントをお届けします。📌 今回のエピソードのポイントE2Eテストの定義と前提条件（UI経由・実データ接続）一連の業務遂行を確認したい時の「長めシナリオ」のメリット不具合検出を優先したい時に「シナリオを分割」すべき理由後続工程のバグを隠さないための、直接URLアクセスの活用術質問コーナー：スプリント開発における「QAの待ち時間」の厳密な評価は必要か？🕒 チャプター(00:00) オープニング(01:32) E2E自動テストの作り方は「目的」で変わる(03:27) シナリオを「長くする」か「分ける」かの判断基準(05:01) まとめ：最適なテスト設計のために(05:32) 質問コーナー：QAの待ち時間を厳密に評価する方法はある？(08:01) エンディング📢 あなたのご意見をお聞かせください自動テストのシナリオ設計で、あなたが「これだけは譲れない」というこだわりや、逆に失敗してしまった経験などはありますか？X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

前々回の「デシジョンテーブルの作り方」に続き、今回は作成したテーブルをどのように効率化していくか、その具体的なテクニックを深掘りします。テストケースをロジカルに、かつ「機械的に」削るための「簡略化」と「禁則」の考え方を解説。ただ削るだけでなく、あえて「削らない」という戦略的な判断基準についても触れています。📌 今回のエピソードのポイントデシジョンテーブルにおける「簡略化」の定義と手順「ハイフン（ー）」を用いたパターンの圧縮方法期待結果が異なる場合に陥りがちな簡略化の罠「禁則」を用いて物理的に不可能なパターンを削除する100件を超える膨大なテストケースへの向き合い方JIS規格と実務的な「見やすさ」を両立する記法比較🕒 チャプター(00:00) オープニング(01:43) 本編：デシジョンテーブルのパターンを機械的に削る(01:59) 「簡略化」によるパターン削減の考え方(04:36) 実践！ハイフンを使った列の圧縮プロセス(07:26) 「禁則」による不要な列の削除(09:21) あえて圧縮しない？戦略的な判断とTips(11:14) デシジョンテーブルの様々な表記方法（JIS規格 vs オススメ）(12:36) 質問コーナー：テストケースが100件を超えた時の対処法(15:11) エンディング📢 あなたのご意見をお聞かせくださいあなたの現場では、デシジョンテーブルの記法はどうされていますか？JIS規格に則った「Y/N/X」派ですか？それとも、今回オススメしたような「◯/空欄」のような見やすさ重視派ですか？ぜひあなたのこだわりを教えてください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

ゴールデンウィーク中に足を運んだ2つの大きなイベント、Podcast EXPOとScrum Fest Niigata 2026の模様をお届けします。Podcastコミュニティの熱量を感じた展示から、QA・テストの比率が高い新潟でのカンファレンス体験まで、現場で感じたリアルな刺激と発見を共有します。📌 今回のエピソードのポイント Podcast EXPO 2026の熱気： 旧校舎を活用したノスタルジックな会場で感じた、Podcastコミュニティの多様性と「即売会」のような活気ある雰囲気について語ります。 注目のPodcast番組と活動： 公共訴訟を扱う「CALL4」や、問いをテーマにした冊子が印象的な「ほんのれんラジオ」など、ブースで出会った魅力的な番組を紹介します。 Scrum Fest Niigataの魅力： 実行委員兼登壇者として参加した新潟でのカンファレンス。地元のお寿司や日本酒、オリジナルビールといった最高のホスピタリティと、QA・品質への関心の高さを振り返ります。📕 参考文献 PODCAST EXPO #306 Podcast EXPOでブース出すよ&久々のモヤッと話(りっちゃ・りょかちのやいやいラジオ) 公共訴訟ラジオ｜社会を動かす裁判の話 ほんのれんラジオ Scrum Fest Niigata 2026🕒 チャプター (00:00) オープニング (00:54) PODCAST EXPO 2026：コミュニティ主導の熱気と出会い (04:09) Scrum Fest Niigata 2026：品質と新潟の食を愉しむカンファレンス (07:23) エンディング📢 あなたのご意見をお聞かせください今回のGW、皆さんはどのように過ごされましたか？Podcast EXPOに行かれた方の感想や、Scrum Fest Niigataでの発表を聴いてくださった方のフィードバックなど、ぜひお寄せください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

「最新のAIテスト」も、紐解いてみればその根底にあるのは古くから大切にされているテスト設計技法だったりします。今回は、そんな基本でありながら奥が深い「デシジョンテーブル（決定表）」がテーマです。なんとなく思いついた順に条件を書き出していませんか？それでは考慮漏れを防ぐことはできません。本エピソードでは、パズルを解くように「機械的」にデシジョンテーブルを作成し、仕様の曖昧さまでをも炙り出すプロのテクニックを徹底解説します。📌 今回のエピソードのポイント「足し算」の罠：思いついた組み合わせを足していく作り方が、なぜ危険なのか3つのステップ：掛け算で全パターンを出し、割り算で割り当て、引き算で削る作成方針禁則と仕様の穴：ありえない組み合わせ（N/A）や、期待結果が不明な箇所を見つける重要性モデリングの効果：境界値分析やデシジョンテーブルを「図式化」することで関係者と認識を合わせるコツ🕒 チャプター(00:00) オープニング(00:25) JaSST'26 Tokyoに参加して感じた「テスト技法」の大切さ(01:39) デシジョンテーブル（決定表）の基本(03:51) 多くの人が陥る「間違った作成手順」(05:37) 正しい作成方針：掛け算・割り算・引き算(06:19) 実践！全パターンを機械的に書き出すステップ(09:12) 期待結果の記入と「禁則（ありえないパターン）」の扱い(11:42) 作成過程で見つかる「仕様の曖昧さ」(14:18) 質問コーナー：境界値の考慮漏れを防ぐには？(16:56) エンディング📢 あなたのご意見をお聞かせください皆さんはデシジョンテーブルを作る際、最初から全パターンを書き出していますか？それとも、重要そうなところから埋めていますか？皆さんの「マイルール」をぜひ教えてください！X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

「ソフトウェアテストの勉強をしたいけれど、座学だけでは物足りない」「社外のエンジニアと深く交流したい」――そんな悩みを持つ若手エンジニアにぴったりのイベントを紹介します。今回は、20年近い歴史を持つ合宿型ワークショップ「WACATE（ワカテ）」を特集。実行委員長を務める視点から、イベントの魅力やユニークなコンセプト、さらには次回開催（2026年夏）の詳細までたっぷりとお届けします。Spotifyでご視聴の方は、会場の様子や参加者データなどのスライドを映像付きでご覧いただけます。📌 今回のエピソードのポイント「手を動かす」がメイン： 登壇者の話を聞くだけでなく、グループワークで徹底的に考え抜くスタイル夏と冬で異なるテーマ： 「狭く深く」掘り下げる夏と、「広く浅く」発見を得る冬データで見るWACATE： 初参加者が約半数！全国から多様な業種のエンジニアが集まる理由破格の参加費： 宿泊・4食付きで3万円前後という、コミュニティ運営ならではのコストパフォーマンス次回予告： 2026年6月27日(土)・28日(日) 幕張で開催決定！📕参考文献WACATE公式サイトWACATE 2026 夏 〜テスト千本ノック！〜 開催概要ページ#14 「失敗の許容度を設計に組み込む」：AI時代のテスト設計と品質の考え方（B-Testing.fmの過去回）🕒 チャプター(00:00) オープニング(01:50) 合宿型ワークショップ「WACATE」を開催します！(05:06) WACATEというコミュニティの概要と「はじまり」(08:20) コンセプトと夏・冬のスタイルの違い(09:47) データ公開：参加者の属性やリピート率、居住地域(12:52) 怒涛の2日間スケジュールと、宿泊型ならではの交流(13:27) 次回（WACATE 2026 夏）の開催概要と参加費について(17:34) 感想コーナー：第14回「失敗の許容度」への反響(18:43) エンディング📢 あなたのご意見をお聞かせください今回の放送を聞いて、WACATEに興味を持っていただけましたか？「合宿形式の勉強会に参加したことがないから不安」「こんなテーマを扱ってほしい」など、あなたの本音をお待ちしています！X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

前回の「境界値分析（BVA）」の基本に続き、今回は一歩踏み込んで「数値ではないデータ」や「自然言語（日本語）」にこの技法をどう適用するかを深掘りします。「〜まで」「〜から」といった日常的な言葉に潜む曖昧さが、いかにして不具合の種になるのか。テスト技法を単なる「確認作業」としてではなく、仕様の不備を見つける「議論のツール」として活用するための考え方をお届けします。📌 今回のエピソードのポイント数値でなくても「順序付け」ができれば境界値分析は活用できる「8:00から22:00まで」の「22:00ちょうど」は稼働時間か、休止時間か？同じ「新横浜駅まで」でも、文脈によって意味が変わる日本語の怖さと面白さテスト設計技法を使って、開発の早い段階で仕様の曖昧さを指摘するメリット【質問コーナー】開発者がテストを行う際に、絶対に落としてはいけない「テストの意図」📕 参考文献⁠ISTQBテスト技術者資格制度Advanced Level シラバス日本語版テストアナリスト Version 3.1.1.J03⁠🕒 チャプター(00:00) オープニング(01:30) 境界値分析（BVA）の定義を再確認する(02:12) 自然言語（数値以外）への適用例：背の順で並ぶクラス(03:11) 「以上・以下」「から・まで」に潜む境界の曖昧さ(03:54) 東海道新幹線の例で考える、文脈による境界値の変化(06:16) テスト技法を「仕様の曖昧さを指摘する」ために使う(08:05) 質問コーナー：開発者がテストの一部を担う際に気をつけること(10:11) エンディング📢 あなたのご意見をお聞かせください皆さんは、仕様書の「〜まで」という表現に悩まされた経験はありませんか？あるいは、数値以外の項目にテスト技法を当てはめてみた事例などがあれば、ぜひ教えてください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回は、テスト設計の基本中の基本でありながら、実は奥が深い「境界値分析（BVA）」を深掘りします。なぜ「パスワードの文字数チェック」のような単純な仕様でも、テストケースが膨大になってしまうのか、そしてどうすれば効率的に、かつ確実にバグを見つけられるのかを解説します。「不等号ひとつ」のミスが命取りになる開発現場で、明日から使える実践的な思考プロセスをお届けします。📌 今回のエピソードのポイントなぜ「全数テストは不可能」なのか？テストの7原則から考える境界値分析を正しく行うための4つの実践ステップコードカバレッジが100%でもバグを見逃してしまう落とし穴仕様書には書かれていない「システム上の境界」と「精度の問題」開発者とQAエンジニア、それぞれのテストの使い分けと理想的な関係性📕 参考文献ISTQBテスト技術者資格制度Advanced Level シラバス日本語版テストアナリスト Version 3.1.1.J03🕒 チャプター(00:00) オープニング(01:44) 境界値分析とは何か？(04:22) 境界値分析の具体的な実践ステップ(06:14) なぜ境界値をテストする必要があるのか：不等号のミスを防ぐ(07:44) カバレッジ100%の罠：テスト設計の重要性(09:56) システム上の境界値と「有効桁数」の落とし穴(13:17) 質問コーナー：エンジニアとQAのテストの使い分け(15:09) エンディング📢 あなたのご意見をお聞かせください皆さんの現場では、境界値のテストはどこまで厳密に行っていますか？「カバレッジは取れているのにバグが出た」という苦い経験や、開発者とQAの役割分担について思うことなど、ぜひ教えてください！X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回のエピソードでは、5月に予定されている3つの大きな登壇イベントについて詳しくご紹介します。10Xでの実践を通じた「QA＝テスト」という呪縛を解くためのアプローチや、マイクロサービスにおけるQAの進め方についての質問にもお答えします。📌 今回のエピソードのポイント【Scrum Fest Niigata 2026】V字モデルの右側にしわ寄せがいかないチーム作り【GENDA Tech Talk #04】少数精鋭のQA組織はどう戦うべきか？【Flexy meetup】10x流「シフトレフト」な品質保証を1時間みっちり深掘りリスナー質問：複数のマイクロサービスが連動する変更、QAはどう進める？📕参考文献ピタゴラスイッチテキシコーScrum Fest Niigata 2026GENDA Tech Talk #4「少数精鋭QAのリアル：プロダクトが増え続ける組織で、QAはどう戦うか」Flexy meetup「10X流・QAと開発者がシームレスに連携するシフトレフトな品質保証アプローチとは」🕒 チャプター(00:00) オープニング(01:59) 登壇告知その1：Scrum Fest Niigata 2026(05:30) 登壇告知その2：GENDA Tech Talk #04(07:30) 登壇告知その3：Flexy meetup(09:24) 質問コーナー：マイクロサービス連動時のQA戦略(13:25) エンディング📢 あなたのご意見をお聞かせください「テストが最後に詰まってリリースが遅れる……」そんな「右側のしわ寄せ」に悩んだ経験はありませんか？今回の登壇内容への期待や、あなたのチームでのQAの悩みなど、ぜひ教えてください！X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

AIコーディングツールの普及により、コードを生成するスピードは飛躍的に向上しました。しかし、その一方で私たちは「何か」を失いつつあるのかもしれません。今回は、JetBrains社のQA責任者が提唱した「AI時代のQA」に関する考察を紐解きます。コードを書くコストが下がる代わりに増大する「理解の負債」や「意図の負債」、そして変化するバグ修正のコスト曲線など、AIと共に歩むこれからの品質保証活動について、理論と実感の両面から掘り下げていきます。📌 今回のエピソードのポイントAIコーディングツールがもたらす「理解の負債」と「意図の負債」とは？コード量ではなく「1行あたりの理解度」が減るという質的な変化修正コストの要因が「手戻りの量」から「理解のギャップ」へシフトするプロアクティブ（予防型）なQAがAI時代にますます重要になる理由人間とAIツールの「調整コスト」をどう抑えるか📕参考文献QA in the Age of AI-Accelerated Development翻訳記事「AIコーディングツールによって加速するコード生成に品質保証活動はどう立ち向かうか」#9 テストを早めに行うことの大切さ（B-Testing.fmの過去エピソード）#22 都道府県、いくつテストする？テスト設計の基本「同値分割法」を徹底解説🕒 チャプター(00:00) オープニング(01:31) 翻訳記事の紹介(03:11) コードを書くコストと引き換えに失われる2つの知見(06:34) 「コードが増えた」のではなく「理解が減った」という質的変化(07:33) 修正コスト曲線の変化：理解の負債がコストを押し上げる(11:42) 積極的（プロアクティブ）な品質保証と反応的な品質管理(14:03) コスト関数で考える「人間とAI」の調整コスト(18:55) 感想コーナー：第22回「同値分割法」へのフィードバック(20:25) エンディング📢 あなたのご意見をお聞かせください開発現場でAIコーディングツールを使っていますか？AIが書いたコードの「意図」を読み解くのに苦労した経験や、AI時代のテスト・品質保証について感じていることをぜひ教えてください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

日々の開発に欠かせない「レビュー」ですが、実は「なんとなく」で行われてしまいがちな活動でもあります。今回は、レビューをJSTQBの定義する「静的テスト」として捉え直し、あえてプロセスに分解することで見えてくるメリットについて深掘りしました。属人化を防ぐための「レビュー・アーキテクチャ」の考え方や、AIに精度の高いレビューをさせるためのプロンプトのヒントなど、現場で役立つ視点をお届けします。📌 今回のエピソードのポイントレビューは立派な「テスト（静的テスト）」であるという認識JSTQBのレビュープロセスにおける「個々人のレビュー」をどう言語化するかテストプロセス（分析・設計・実装・実行）をレビューに応用するメリットレビューの「目的」と「観点」を分けることで属人化を防ぐAIにレビューを依頼する際、丸投げよりも「観点」指定が重要な理由📕 参考文献ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02レビューでは何を確認するといいのかな？さまざまなレビューの意図を整理して確認事項を明らかにしてみよう！(JaSST Review'22発表資料)🕒 チャプター(00:00) オープニング(01:31) ソフトウェアレビューにおけるプロセスの重要性(02:01) レビューは「静的テスト」の1つである(03:22) JSTQBのレビュープロセスと残る疑問(04:39) テストプロセスを参考にレビューを分解してみる(06:15) レビューアプローチの全体像と属人化の課題(10:52) AIのレビュー精度を飛躍的に高めるヒント(12:51) 質問コーナー：ステークホルダー間での形式化はできている？(14:02) エンディング📢 あなたのご意見をお聞かせくださいみなさんの現場では、レビューの「観点」や「手順」は明文化されていますか？それとも「経験豊富なベテランの勘」に頼っている部分が大きいでしょうか？レビューにおける工夫や悩みなど、ぜひ教えてください！X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回は、テスト設計技法の代表格である「同値分割法」をテーマにお届けします。「なんとなく」でテスト値を選んでいませんか？「なぜその値を選んだのか」を論理的に説明できることは、QAエンジニアにとって非常に重要なスキルです。47都道府県のプルダウンを例に、目的やリスクに応じた5つのアプローチを紹介しながら、現場で役立つ思考プロセスを整理していきます。📌 今回のエピソードのポイント同値分割法の定義とメリット都道府県のテストで「沖縄県」や「神奈川県」を選ぶそれぞれの理由テストケース作成時に欠かせない「理由を言語化する」ことの大切さ5つの回答例（スクロール、印刷反映、文字数、地域、コードの構造）リスナーからの感想紹介：QAとAIが共創する「建設的相互作用」の可能性📕 参考文献#14 「失敗の許容度を設計に組み込む」：AI時代のテスト設計と品質の考え方（B-Testing.fmの過去回）🕒 チャプター(00:00) オープニング(01:24) 同値分割法とは何か？(02:45) 例題：都道府県の項目、何個テストする？(03:25) 同値分割の手順と「理由」の重要性(04:30) 5つの回答例：スクロールや配列エラー、出力結果、文字数、地域、全件テストの使い分け(10:20) 感想ポスト紹介：QAとAIのシナジーと仮説検証(12:26) エンディング📢 あなたのご意見をお聞かせください皆さんは「都道府県」の項目をテストするとき、いつもどのような狙いで値を選んでいますか？「自分ならこう分ける！」というこだわりや、今回紹介した手法への感想など、ぜひお聞かせください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回は「テスト設計とテスト設計技法」の基本について深掘りします。「なぜわざわざ設計が必要なのか？」という根本的な問いから、技法を習得することで得られる意外なメリット、そして数ある技法の効果的な学習順序まで、QAの現場で役立つエッセンスを凝縮してお届けします。📌 今回のエピソードのポイント「全数テストは不可能」だからこその設計： 時間制約の中で、効果的・効率的に不具合を見つけるための戦略。「効果」と「効率」の違いを意識する： 多くのバグを出すことと、かけた時間に対してバグを出すことのバランス。技法による「省思考（しょうしこう）」のススメ： 信号機の色の順番を考えなくていいように、標準化によって脳のメモリを解放し、より独創的な仕事へ集中する。技法の学習ロードマップ： 同値分割・境界値分析といった「基本」から始めるべき理由。質問コーナー： 開発経験はQAに必須？テスト観点を養い、技法を使い分けるための「数学の公式」のような考え方。📕 参考文献Newbeeさんの動画「AI時代の品質保証最前線　決定論→確率論時代に変わるQAの在り方」スライド「テスト設計技法をチョット俯瞰してみよう」書籍『現代品質管理総論』書籍『ソフトウェアテスト技法練習帳～知識を経験に変える40問⁠～』🕒 チャプター(00:00) オープニング(01:53) 今回のテーマ：テスト設計とテスト設計技法(02:04) テスト設計はなぜ必要なのか？(03:08) テストにおける「効果」と「効率」の定義(04:41) 技法を用いることで「省思考」を実現する(07:42) テスト設計技法を学ぶべき順番(09:40) 質問コーナー：技法を使い分けられるようになるまでの道のり(13:47) エンディング📢 あなたのご意見をお聞かせください皆さんがテスト設計技法を学んでいて「これは目から鱗だった！」というエピソードや、逆に「使い分けが難しい……」と感じている部分はありますか？ぜひ教えてください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

「QAエンジニアって本当に必要？」「開発者がテストすればいいんじゃない？」そんな声が聞こえてきそうな現場に、最初のQAとして飛び込むのは勇気がいるものです。今回は、テストの価値がまだ浸透していないチームにおいて、どのように信頼を勝ち取り、スムーズにテストプロセスを導入していくべきか、具体的な戦略とコミュニケーションのコツを深掘りします。📌 今回のエピソードのポイント不具合分析から始めるプロセス導入：いきなり理想を語るのではなく、目の前の痛み（障害）を入り口にする戦略「なぜやらなかったの？」は禁句：相手を責める「評論家」ではなく、共に悩む「当事者」として振る舞うヒアリング術主語を「私」にする意思表明：テスト設計ができないことへの「困りごと」を伝えることで、周囲の協力を引き出すボトムアップ改善の鉄則：大規模組織で提案を通すなら、まずは「勝手にやって実績を作る」のが近道？📕 参考文献書籍『FEARLESS CHANGE アジャイルに効く アイデアを組織に広めるための48のパターン』🕒 チャプター(00:00) オープニング(01:37) テストエンジニアの価値をチームに伝えるには(02:39) テストプロセス導入の第一歩は「不具合・障害分析」から(04:17) チームに受け入れられるコミュニケーションのコツ(09:00) 質問コーナー：大規模組織でのボトムアップな改善提案(10:26) 参考文献『Fearless Change』に見る改善のパターン(12:26) エンディング📢 あなたのご意見をお聞かせください新しくチームに加わった時や、新しいプロセスを導入しようとした時、あなたが意識している「入り込み方」の工夫はありますか？X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

「テストを実行する」という言葉の裏側には、実は多くの思考プロセスが隠れています。今回は、多くの方が無意識に通り過ぎてしまいがちな「テスト分析」や「テスト設計」の重要性について、JSTQBの定義を交えながら掘り下げます。📌 今回のエピソードのポイント「テスト準備」を一括りにせず、プロセスを細分化するメリットJSTQBが定義する「テスト分析」「テスト設計」「テスト実装」「テスト実行」の違い無意識に行っている「何を・どうテストするか」を言語化・議論する大切さ【質問コーナー】QAからユニットテストを提案する際の「前提」とチーム文化📕参考文献ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02🕒 チャプター(00:00) オープニング(01:58) よくあるテストプロセスとJSTQBの定義(02:50) テストプロセスを4つに分けて考える(05:35) 「テスト分析」で何をテストするかを決定する(08:31) 質問コーナー：ユニットテストの提案は受け入れられる？(10:13) 開発チーム全体で品質に向き合うマインドセット(12:00) エンディング📢 あなたのご意見をお聞かせください皆さんの現場では、テストコードを書く前に「何をテストするか」を議論する時間はありますか？それとも、無意識のうちにスクリプト作成から始めてしまっているでしょうか。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

私たちは普段、仕事の成果（結果）にばかり目を向けがちですが、その裏側にある「思考のプロセス」を可視化することには、実は大きなメリットがあります。今回は、簡単な計算問題を例に、思考をプロセスとして切り出すことの重要性を解説します。なぜプロセスを細かく分けると「レビュー」がしやすくなるのか？そのトレードオフとは？📌 今回のエピソードのポイント「プロセス」の定義：手続きに着目し、対象を別のものへ変換する活動プチワーク：8×7-32÷4の解き方から見る、思考の多様性なぜ思考のプロセスを共有すると、ミスやバグの修正が容易になるのかプロセスを細分化することによる「工数」と「品質」のバランス【質問コーナー】開発側の品質保証知識はどの程度？現場で本当に必要なこと🕒 チャプター(00:00) オープニング(01:44) 思考を「プロセス」という形で表現してみよう(02:47) プチワーク：計算問題から見る「思考の道筋」(03:26) 解答へのアプローチは人によってこれだけ違う(05:33) 細かいプロセスを示すとレビューしやすくなる理由(07:34) 質問コーナー：開発側の品質保証知識はどれくらい？(11:01) エンディング📢 あなたのご意見をお聞かせください皆さんは仕事において、結論だけでなく「考えたプロセス」をチームに共有していますか？また、今回の計算問題、あなたならどんなステップで解きましたか？ぜひ感想をお寄せください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

「言語化は大事」とよく言われますが、実は言葉にした瞬間にこぼれ落ちてしまう大切なニュアンスがあるのではないでしょうか？今回は、あえて「言語化しきれていない状態」を肯定し、特にソフトウェア開発の現場で「わからない」と表明することがいかに品質向上やチームビルディングに寄与するかを深掘りします。4月からの新生活や新しいプロジェクトを控えた方には、ぜひ聴いていただきたい内容です。📌 今回のエピソードのポイント言語化することで「失われてしまうもの」の正体QAエンジニアが設計レビューで「わからない」を連発する理由個人の「わからない」を、一瞬で「チームの課題」に変換する魔法開発マネージャーから教わった、実装の「背景」を共有する重要性新入社員や現場に加わったばかりの人が持つべき「最高の武器」📕 参考文献「言語化」ってみんな言うけれど #あらたまいくお「テストは単純作業ではなく創造的な活動だ」という意識を浸透させた物語『フレーズ』で体験する、あのチーム🕒 チャプター(00:00) オープニング(02:02) 言語化の背景と、言葉にした瞬間に失われるもの(04:39) 設計レビューで「わからない」と言うことの効能(07:51) 実装方針の裏にある「背景」を引き出す技術(11:06) 魔法のフレーズ「わからない」でチームを動かす(15:20) エンディング📢 あなたのご意見をお聞かせください仕事の中で「これ、言語化できていないけど何か違和感があるな」と感じたことはありませんか？また、あなたが勇気を出して「わからない」と言ったことで、状況が好転したエピソードがあればぜひ教えてください！X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

「何をテストすべきか？」――この問いに対する答えは、実はプログラムを書き始めるずっと前に隠されています。今回は、具体的なパスワードの仕様を例に、設計段階で「テストの視点」を持つことがいかに開発コストを削減し、不具合を未然に防ぐのかを深掘りします。📌 今回のエピソードのポイント「実装前のテスト」が最強のコスト削減になる理由： バグを早期に発見することで、修正にかかる総コストを劇的に下げるメカニズムを解説。パスワード仕様から紐解く「テストの考え方」： 4〜12文字、英数字のみ……。シンプルな仕様の中に潜む「曖昧さ」をどう見つけ出すか。開発現場の「認識の齟齬」を未然に防ぐ： 「Aさんはエラー画面を作るだろう」「Bさんはボタン制御でやるだろう」という思い込みが招く悲劇。コードを書かないテストの実践： 「許容する」という言葉ひとつを定義するだけで、不具合の芽を摘み取れる具体例。📕 参考文献概説 テスト分析（例題の文章の引用元）🕒 チャプター(00:00) オープニング(01:58) 復習：なぜ実装前にテスト・レビューをするのか(03:01) 例題：パスワードの仕様からテスト内容を考える(03:53) 回答例(05:56) 仕様の行間を読む(09:24) 設計・開発時点での「思い込み」と追加コストの正体(11:37) 伝えたいこと(14:13) お便り紹介：AI時代のQAと「相性」の話(16:19) エンディング📢 あなたのご意見をお聞かせください皆さんの現場では、仕様書を読んだ時点で「これ、どう動くの？」と疑問をぶつける文化はありますか？「実装前に助かった！」というエピソードがあれば、ぜひ教えてください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回は、2026年2月中旬に開催された「Developers Summit 2026（デブサミ2026）」での登壇を振り返ります。「副業・独立・キャリアチェンジ」という異なる選択をした3名のエンジニアによるパネルディスカッション。当日はモデレーターとして話しきれなかった「自分の実力をどう表現すべきか」「ロールモデル不在をどう捉えるか」といった、キャリア構築のヒントをさらに詳しくお届けします。📌 今回のエピソードのポイントデブサミ2026登壇の舞台裏と、副業・独立・キャリアチェンジの三者三様の視点「リプレイス対応」の一言で片付けない、職務経歴書での「自分の工夫」の出し方ロールモデルは探すもの？それとも競合？ビジネス視点でのキャリア戦略1on1で見つけた「輝く言葉」をそのまま経歴書に書き写すべき理由📕参考文献副業？ 独立？ キャリアチェンジ？ それぞれの視点から語る、エンジニア人生「キャリアの磨き方」（登壇したセッション）キャリアにロールモデルを求めることは、自ら過当競争に飛び込む戦略上愚かな行為🕒 チャプター(00:00) オープニング(01:42) デブサミ2026登壇の振り返り(05:40) 私のキャリア戦略と「貢献」のモチベーション(08:42) よくある質問①：自分の実力をどう表現すればいいか(11:56) よくある質問②：周りにロールモデルがいない時の考え方(15:18) よくある質問③：年収の「天井」とそこへの到達路(16:03) カジュアル面談や1on1をキャリアに活かすスタンス(19:24) お便り紹介(20:54) エンディング📢 あなたのご意見をお聞かせくださいあなたは自分の「実績」を語る時、どんな工夫をしていますか？また、身近にロールモデルはいますか？キャリアに関するお悩みや、今回の感想をぜひ教えてください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回は、MAXさんによるブログ記事「失敗の許容度を設計に組み込む」をテーマに、変化の速い現代の開発における「品質」の定義を掘り下げます。「失敗しないこと」を目指すのではなく、「失敗をいかに早く検知し、訂正できるか」という視点。このマインドセットの転換が、AIを活用したテスト設計や、継続的なプロダクト運用においてどのような意味を持つのか、自身の共感ポイントを交えて語ります。📌 今回のエピソードのポイント品質とは「失敗を防ぐこと」ではなく「最速で検知・修正できる仕組み」であるテストの網羅性や正確性以上に追求すべき「プロセスの健牢さ（復元力）」プロダクト開発と運用は、本質的に「訂正し続けるサイクル」であるAIによるテスト設計を「仮説」と捉え、現実とのギャップから隠れたエッジケースをあぶり出す手法📕 参考文献失敗の許容度を設計に組み込む技術力あげたい🕒 チャプター(00:00) オープニング(02:00) 記事紹介：「失敗の許容度を設計に組み込む」(03:01) 品質＝「最速で検知し、修正できるシステム」の設計(04:30) テストが追求すべき「復元力」とは(06:31) プロダクト開発・運用における「訂正し続けること」の重要性(07:53) AIを活用したテスト設計：仮説と現実のギャップを意図的に作る(11:16) エンディング📢 あなたのご意見をお聞かせください皆さんのチームでは、「品質」をどのように定義していますか？また、「失敗を許容する設計」についてどう考えますか？ぜひ感想をお寄せください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回は、2026年3月20日に開催される「JaSST'26 Tokyo」でのワークショップ登壇についてお届けします。テーマは、複雑なテスト条件を整理するのに強力な武器となる「クラシフィケーションツリー技法」。JSTQBのアドバンスドレベルでも扱われるこの技法を、なぜ今ワークショップで学ぶべきなのか？その理由と、翌日に予定している恒例（？）の「テスト花見」についてもお話しします。📌 今回のエピソードのポイントコミュニティ活動としてのPodcast： 自身の活動の軸足である「WACATE」や「ASTER」への想いクラシフィケーションツリー技法とは： 複数の条件を組み合わせるテスト設計において、デシジョンテーブルとの使い分けやメリットを解説JaSST'26 Tokyoの見どころ： 2026年版「ソフトウェアテスト最初の第一歩」として、ワークを通じた体感的スキルの習得貴重な学習機会： 日本語の文献が少ないこの技法を、手順付きで学べるワークショップの希少性【番外編】テスト花見の復活： 2025年のリベンジ！エンジニア同士で語らう「テスト花見」へのお誘い📕参考文献JaSST’26 Tokyoテスト花見 2026🕒 チャプター(00:00) オープニング(01:38) クラシフィケーションツリー技法とは何か(03:03) JaSST'26 Tokyoでの開催概要(03:38) セッション内容：ワークで学ぶテスト設計の勘所(05:30) WACATEのノウハウを凝縮したコンテンツ(07:04) 翌日の「テスト花見」について(09:12) エンディング📢 あなたのご意見をお聞かせください皆さんは「クラシフィケーションツリー技法」を実務で使ったことはありますか？また、JaSSTなどのカンファレンスで「こんなワークショップを受けてみたい！」というテーマがあればぜひ教えてください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

「ASTER」という名前、テストエンジニアなら一度は聞いたことがあるはず。でも、具体的にどんな活動をしている組織なのか、詳しく説明できる人は意外と少ないのではないでしょうか？今回は、日本のソフトウェアテスト技術を支えるNPO法人「ASTER」の裏側に迫ります。📌 今回のエピソードのポイントASTERの正体は、非営利で技術振興を行うNPO法人実はここが運営！JSTQBの資格認定とシラバス翻訳の裏側20年以上続くテストの祭典「JaSST」の規模感パワポ形式で無料配布中！？驚きの教育支援と、セミナー参加者を支える「一時保育」制度📕 参考文献NPO法人ソフトウェアテスト技術振興協会JSTQBシラバスJaSST（ソフトウェアテストシンポジウム）テスト設計コンテストASTERセミナー標準テキスト🕒 チャプター(00:00) オープニング(01:30) ASTER（ソフトウェアテスト技術振興協会）とは何か(02:09) JSTQBの資格認定・運営：シラバス無料公開の価値(04:03) テストの祭典「JaSST」：全国に広がるシンポジウムの歴史(04:49) 調査研究事業：テスト開発方法論からAIの品質保証まで(05:52) 教育事業：テスト設計コンテストと社内研修に使える無料テキスト(07:42) ASTERの活動まとめ：サイトを覗いてみるだけでも価値がある(08:47) エンディング📢 あなたのご意見をお聞かせください皆さんは、JSTQBのシラバスを読んだり、JaSSTに参加したことはありますか？皆さんのASTERの活動との関わりを教えてください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

リリース直前になってバグが多発し、開発現場がパニックになる……そんな経験はありませんか？今回は、以前「Findy Engineer Lab」に寄稿した記事をもとに、開発スピードを落とさず、安全にリリース（出口）へとたどり着くための「テストの予告」という考え方について深掘りします。📌 今回のエピソードのポイント高速道路の「予告標識」が、ドライバーの安全とスムーズな走行をどう支えているのかもしも予告標識がなかったら？開発現場で起こる「急な車線変更（仕様変更）」や「事故（バグ）」の正体開発速度を維持したまま「テストを予告する」ことで得られるチームへのメリットリリース直前の「渋滞（コミット過多）」や「手戻り」を最小限に抑えるための戦略的アプローチ📕参考文献高速道路の出口案内のようなQAエンジニアでありたい ─自動テストより前にやるべきことがあると気づいた話🕒 チャプター(00:00) オープニング(02:03) 高速道路の出口標識のようなテスト活動とは(03:03) 予告標識がスムーズな合流と減速を実現する(04:41) 開発スピードとリリース（出口）をリンクさせる考え方(05:48) リリース直前の「事故」を防ぎ、次のチャンスに備える(07:12) エンディング📢 あなたのご意見をお聞かせください皆さんのプロジェクトでは、リリース直前に「突然の出口」が現れてパニックになることはありませんか？「うちはこんな予告標識（工夫）を置いているよ！」といった事例があれば、ぜひ教えてください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

「テックカンファレンスに応募したいけれど、プロポーザルがこれでいいのか自信がない……」そんな悩みを持つ人のために、GoogleのGeminiで活用できる「プロポーザル添削Gem」を自作しました。今回は、自身のDevelopers Summit（デブサミ）コンテンツ委員としての経験をAIに落とし込み、いかにして「採択されるプロポーザル」を磨き上げるか、その活用法を徹底解説します。AIに頼り切るのではなく、自分の「思考」と「言語化」をブーストさせるための新しい試みについてお話しします。📌 今回のエピソードのポイントデブサミ・コンテンツ委員の視点：約400件の審査経験から導き出された「良いプロポーザル」の観点。「プロポーザル添削Gem」の誕生秘話：ブログ記事の観点をGeminiに学習させ、壁打ち相手に変える方法。実際の添削デモ：ブロッコリーさん自身の過去のプロポーザルをAIはどう評価したか？具体的なフィードバック例を紹介。Gem活用時の注意点：評価ランク（S〜D）はあくまで目安。他の応募者との相対評価やバランスが鍵となる。修正案をあえて出さない理由：自分の言葉で語る大切さを守るため、あえて制限している機能について。📕参考文献プロポーザル添削Gemプロポーザルを書くときに心がけ、採択するときに注目していることカンファレンスの審査委員として6年で約400件のプロポーザルに投票コメントをしたときの観点note添削用のGemを作りました🕒 チャプター(00:00) オープニング(01:12) 今回のテーマ：プロポーザル添削Gemを作成しました(01:23) デブサミ・コンテンツ委員の主な仕事（採択・プログラム提案）(02:27) 参考にしたブログ記事：プロポーザルを書く際のコツと審査の観点(03:33) Geminiで活用できる「プロポーザル添削Gem」の紹介(05:05) 実演：過去の自身のプロポーザルを添削してみた結果(05:59) 項目別の評価と、具体的な改善アドバイスの内容(07:39) 活用時の注意点：評価内容が採択を保証するわけではない理由(07:42) 「修正案」の提示をあえて制限している、ブロッコリーさんのこだわり(08:41) 開発のきっかけ：note添削Gemをヒントに(09:26) まとめ：Gemを活用して、より良いプロポーザルを世に送り出そう(09:51) エンディング📢 あなたのご意見をお聞かせください「このGemを使ってみた感想」や「実際にプロポーザルを書いてみた苦労話」など、ぜひお聞かせください！X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

「テストは早めにやったほうがいい」開発現場でよく耳にするこの言葉、具体的に「いつ」から始めるのが理想なのでしょうか？今回は「シフトレフト」をキーワードに、テストを前倒しすることの真のメリットと、多くの人が陥りがちな勘違いについて深掘りします。単にスケジュールを早めるだけではない、QAエンジニアとしての立ち振る舞いや、プロセスへの関わり方についてお話しします。📌 今回のエピソードのポイント「テストを早めに」の本当の意味：何をもって「テストを開始した」と言えるのか。シフトレフトの誤解：ただ単にテスト工程を左（前）にずらすだけでは不十分な理由。実装前からのテスト：コードが書かれる前、設計や要件定義の段階でQAができること。不具合の「発見」から「予防」へ：早い段階で関わることで得られる、圧倒的なコストパフォーマンス。理想的なテストの開始タイミング：プロジェクトのどの地点からQAが介入すべきか。📕参考文献ISTQB テスト技術者資格制度Foundation Level シラバス日本語版Version 2023V4.0.J02『ソフトウェア開発201の鉄則』The Economic Impacts of Inadequate Infrastructure for Software Testing🕒 チャプター(00:00) オープニング(00:55) 今回のテーマ：テストを早めに行うことの大切さについて(01:30) 「シフトレフト」という概念：テスト工程を前倒しする考え方(02:15) シフトレフトがもたらす最大のメリット：不具合修正コストの削減(03:45) よくある間違い：テスト実行だけを早めてもうまくいかない(05:10) 実装前にQAができること：要件レビューとテスト設計の並行(06:50) 「テスト＝画面を触ること」という固定観念を捨てる(08:15) 理想の介入ポイント：企画・要件定義の段階からQAが同席する価値(09:30) まとめ(10:10) エンディング📢 あなたのご意見をお聞かせください皆さんのプロジェクトでは、どのタイミングからテストを意識し始めていますか？X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

「テストの目的はバグを見つけること」という固定観念を、さらに一歩押し進めてみませんか？今回のエピソードでは、振る舞い駆動開発（BDD）の考案者として知られるDan North氏のブログ記事「We need to talk about testing」を紐解きます。彼が提唱する「テストの目的」とは、単なる不具合の発見ではなく、「証拠を通じて、利害関係者の信頼を高めること」。第5回で紹介した「納得」というキーワードとも深く共鳴する、Dan North流のテスト観。QAエンジニアが単なる作業者で終わらず、チームの信頼の要となるためのヒントが詰まっています。📌 今回のエピソードのポイントDan Northってどんな人？：BDD（振る舞い駆動開発）を生み出し、世界の開発プロセスに影響を与えた人物。テストの真の目的：具体的な「証拠」を提示することで、関わるすべての人（利害関係者）の信頼を勝ち取るプロセス。証拠なき仕事は「テスト」ではない？：Dan Northの鋭い指摘から、自分たちの日常業務を振り返る。テスト思考：画面を操作する前の「アーキテクチャ設計」や「UIコンポーネントの選択」こそがテストの本質であるという考え方。「労力」は外注できても「能力」は外注できない：第6回のAIの話とも繋がる、エンジニア自身の思考力の重要性。📕参考文献We need to talk about testing翻訳記事「テストについて話し合わなくてはならない」🕒 チャプター(00:00) オープニング(01:24) 今回のテーマ：Dan Northが考えるテストとは何か(01:42) Dan Northの紹介と、彼が書いた「テストについて話し合わなくてはならない」という記事について(02:25) Dan North流「テストの目的」の定義(02:45) 用語解説①：利害関係者（ステークホルダー）とは誰を指すのか？(03:25) 用語解説②：「信頼を高める」ことの本当の意味(03:43) 用語解説③：議論の余地のない「証拠（データ）」の重要性(04:08) 信頼を高めない作業は「テストをしていない」のと同じ(05:07) 第5回の「にしさん」の考え方との共通点(05:59) 「テスト思考」という概念：設計段階から不具合を予防する(07:51) テスト実行の「前」に考えることの重要性(08:11) まとめ：信頼を築くために、私たちは何を証拠として示すべきか(09:11) エンディング📢 あなたのご意見をお聞かせくださいDan North氏の「信頼を高めない作業はテストではない」という言葉、あなたはどう感じましたか？X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠こちらからお気軽にどうぞ。⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

「もし明日、今の会社がなくなったら、あなたはどうしますか？」ショッキングな問いかけですが、終身雇用という考え方が薄れつつある現代において、これは全てのエンジニアが向き合うべきリアルな課題です。今回のエピソードでは、前回のAI時代の生存戦略から一歩進んで、自分が望む環境（働きやすい場所）を自ら手に入れるためのキャリア論を展開します。会社に依存しすぎず、自分のスキルを正当に評価してもらうための「言語化」の技術と、転職市場における会社とのマッチングの極意についてお話しします。📌 今回のエピソードのポイント会社依存からの脱却：リスクヘッジとしての「自立したキャリア観」を持つ大切さ。自分のスキルを証明する「言語化」：QAエンジニアにありがちな「テスト設計ができます」という曖昧な表現をどう変えるか。履歴書・経歴書は「自分を伝える武器」：自分がどういう考えを持ってテストを遂行しているか、そのプロセスを明文化する。会社との幸せなマッチング：自分の「テスト観」をぶつけることで、相性の悪い会社をあらかじめフィルタリングする手法。登壇イベントのお知らせ：2月19日(木)「Developers Summit 2026」にて、副業・独立・キャリアチェンジをテーマとしたパネルディスカッションに登壇！📕参考文献⁠⁠⁠Developers Summit 2026 での登壇セッション　”副業？ 独立？ キャリアチェンジ？ それぞれの視点から語る、エンジニア人生「キャリアの磨き方」”⁠🕒 チャプター(00:00) オープニング(01:39) 今回のテーマ：自分が働きやすい場所で働くためには？(02:08) エンジニア人生で大事なこと：自分のスキルを言語化し、会社依存を避ける(02:54) 「明日、会社がなくなったら？」という問いを自分に投げかける(04:13) 経歴書に対する会社の反応は分かれる(05:15) 給職者と会社、双方が幸せになるための「ミスマッチ防止策」(07:03) 開発者以上に難しい？QAエンジニアの成果とスキルの伝え方(07:43) 告知：Developers Summit 2026（デブサミ）登壇のお知らせ(08:57) デブサミの内容：副業・独立・キャリアチェンジ、3人の視点で語るキャリアの磨き方(09:28) エンディング📢 感想・お悩みをお寄せください「自分のスキルをどう言語化すればいいか分からない」といった具体的なお悩みも大歓迎です！X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠こちらからお気軽にどうぞ。⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

「AIがテストを自動で作るようになったら、QAエンジニアの仕事はなくなるの？」急速に進化する生成AI（LLM）を前に、多くのエンジニアが抱くこの不安。今回のエピソードでは、QAエンジニアとしてのキャリアとAIの共生について、本質的な視点から切り込みます。AIがテスト設計で見せる「新人〜中堅レベル」の実力とその限界、そして私たちがAIに代替されないために今磨くべきスキルとは何か。これからの時代を生き抜くための「自分自身の言語化」についてお話しします。📌 今回のエピソードのポイントAI時代のキャリア形成：特定の技術に固執せず、リスクヘッジの観点から「仕事の本質」を考える。LLM（大規模言語モデル）の仕組みとテスト設計：AIは「計算」しているのではなく「確率」で推測しているという事実。AIによるテスト設計の現状評価：なぜAIのバージョンが上がっても、テスト設計の精度は劇的に向上しないのか。「わからないものはレビューできない」の罠：AIに任せきりにすることの危険性と、人間のレビュー能力の重要性。今こそテスト技術を磨くべき理由：AIを使いこなすためにも、まずは既存のテスト設計技法を血肉化する。自分の能力を「言語化」しよう：AIとの対話において、自分が何を提供できるのかを明確にする大切さ。📕参考文献⁠5. QAエンジニアの仕事は今後AIでどうなるんですか？的質問について - テストウフCAST | Podcast on Spotify⁠⁠AI(ChatGPT-4)によるテスト設計作成の現状を評価する⁠⁠LLMのキモい算術⁠⁠ベテランプログラマは生成AIをどう活用しているのか？そして初学者は生成AIをどう活用すべきか？⁠⁠AI時代のソフトウェア開発を考える（2025/07版）⁠⁠ブロッコリーのポスト⁠🕒 チャプター(00:00) オープニング(00:50) 今回のテーマ：QAエンジニアのキャリアと生成AI(01:31) 参考ポッドキャスト『テストウフCAST』に見るAIへの向き合い方(03:30) 現状のAIに対する私の評価：3年前の発表から変わらぬ「新人〜中堅レベル」(04:32) LLMの「キモい算術」から紐解く、AIが答えを出す仕組み(07:41) テスト設計に対するAIの学習は、実はあまり進んでいない？(08:22) AIに投げた「お願い」がろくな結果を生まない境界線(08:43) 労力は外注できても、能力は外注できない(10:10) 私の意見：基本のテスト技術を磨き、自分を言語化しよう(11:10) エンディング📢 感想をお寄せくださいAIと隣り合わせのこれからのQA業務について、あなたはどう考えますか？X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠こちらからお気軽にどうぞ。⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

「テストをたくさんやれば、品質は上がるのか？」QAエンジニアなら一度は直面するこの問いに、ひとつの答えを提示します。今回は、日本のテスト界の第一人者である「にしさん」の2013年の講演から、テストの本質を突く3つのスタンスをご紹介します。テストを単なる「作業」や「エビデンス」に留めず、チーム全体の「信頼」に変えるための思考法を、一緒に紐解いていきましょう。📌 今回のエピソードのポイントにしさんが唱える「テストの3つのスタンス」：行動・説明、そして「納得」へスタンス1：テストとは行動である——「何件やったか」という量への注力とその限界スタンス2：テストとは説明である——「仕様を100%網羅した」という説明責任と、潜む「無責任」スタンス3：テストとは納得してもらうことである——ステークホルダーと「全体像」を共有する対話の重要性「納得」を生むためのテスト設計力：モデリングやテスト設計技法が、なぜ「納得」への近道になるのか開発者と責任を分かち合う：バグが見つかった時にお互いを責めない「合意」の作り方📕参考ページ⁠テスト設計コンテスト 2013 関西地域予選の招待講演の動画（タイムスタンプ付きのリンクにしています）⁠⁠講演スライド⁠⁠文字起こしの記事⁠🕒 チャプター(00:00) オープニング(00:48) 今回のテーマ：テストは「納得してもらうこと」である(01:35) 抜粋元：テスト設計コンテスト2013でのにしさんの招待講演(03:16) テストに対する3つのスタンス(03:40) スタンス1：テストとは行動である（期間や件数での対話）(05:28) スタンス2：テストとは説明である（仕様書網羅と説明責任）(06:51) 説明責任が招く「説明無責任」とは？(07:57) スタンス3：テストとは納得してもらうことである(08:26) 「押し付け」ではなく「一緒に検討する」コミュニケーション(09:05) なぜ今、テスト設計力やモデリングが重要なのか(11:11) まとめ：3つのスタンスを使い分けていますか？(11:41) エンディング・お便り募集📢 感想をお寄せください今日の話を聞いて、あなたはどのスタンスでテストに向き合いたいと感じましたか？X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠こちらからお気軽にどうぞ。⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回のB-Testing.fmは特別編として、2026年2月3日(火)に開催されるオフラインイベントの告知をお届けします。テーマは、『脱・テスト待ち』 〜"速さ"と"品質"を両立させる、組織とプロセスの再設計〜。QAエンジニアとして、また本業の10X社での活動を通して日々向き合っている「テスト待ち」という課題。これをいかにして解消し、開発のスピードを落とさずに品質を担保していくのか。イベントの見どころや、共に登壇するメンバーとの「縁」についても深く語ります。📌 今回のエピソードのポイントイベント概要の紹介：QA目線で語る「リリース頻度向上」のリアルな悩みと乗り越え方。「脱・テスト待ち」の本質：前回の「テストの目的」とも繋がる、不具合の「予防」という考え方。オフラインならではの楽しみ：イベント後の懇親会で、リスナーの皆さんと直接お話しできることへの期待。📕参考ページ⁠イベントページ「『脱・テスト待ち』〜"速さ"と"品質"を両立させる、組織とプロセスの再設計〜」( https://bitkey.connpass.com/event/377909/ )⁠⁠【QA部屋第4回】「QAのキャリア論とテスト設計の魅力」ゲスト：株式会社ナレッジワーク・河野哲也さん - 10X.fm⁠( ⁠https://open.spotify.com/episode/20WhZHEukFphvByQHvgaTZ )🕒 チャプター(00:00) オープニング(00:45) 今回は特別編！2月3日開催イベントの告知(01:08) イベント詳細：『脱・テスト待ち』〜組織とプロセスの再設計〜(01:57) 「不具合を予防する」——テスト待ちを解消するための思考(02:45) 登壇者紹介①：ナレッジワーク・tettanさんとの大学時代からの縁(04:37) 登壇者紹介②：ビットキー・白木さんとの前々職時代のエピソード(05:22) 当日のタイムスケジュールとパネルディスカッションの内容(06:05) オフライン開催への想いと、懇親会での交流について(06:45) エンディング・お便り募集📢 イベント参加・お便りをお待ちしています！イベント当日に東京にいらっしゃる方は、ぜひリアルでお会いしましょう！X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠こちらからお気軽にどうぞ。⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

「テストってバグを見つけるためにやってるんですよね？」もしあなたがそう聞かれたら、どう答えますか？実は、テストの目的はバグ探しだけではありません。今回は、世界的なテスト技術者資格「JSTQB」のシラバスを参考に、テストが果たすべき4つの重要な役割について深掘りします。ソフトウェアの品質を支える「テスト」の真の意味を知ることで、明日からの開発や評価の視点が変わるはずです。📌 今回のエピソードのポイントバグを見つけるだけじゃない？ テストが持つ「多角的な目的」とはJSTQBシラバスの変遷：2011年版と最新版で何が変わったのか「意思決定」の材料としてのテスト：ステークホルダーを納得させるための情報提示「欠陥の作り込み防止」という予防的視点：開発プロセス全体をどう改善するか参考ページJSTQBシラバスChapters(00:00) オープニング(01:33) そもそも、なぜテストを行うのか？（よくある意見）(02:34) JSTQB（2011年版）に記載されたテストの4つの目的(07:02) 最新のJSTQBシラバス（2023年版）での定義の変化(08:53) まとめ(09:22) エンディング・お知らせ📢 リスナーの皆様へB-Testing.fmでは、皆様からの感想や質問を募集しています！X（旧Twitter）：ハッシュタグ #b_testing でポストをお願いします。お便りフォーム：こちらからお気軽にどうぞ。フォローのお願い：Podcastアプリでフォローしていただくと、最新回の通知をすぐに受け取れます。

「品質を上げろ！」とよく言われますが、そもそも「品質」の正体とは何でしょうか？実は、私たちが普段使っているこの言葉には、時代や文脈によってさまざまな定義があります。書籍『現代品質管理総論』や『ワインバーグのシステム思考法』などを引用しながら、ソフトウェア開発における「品質」の真の意味を解き明かします。「品質＝バグがないこと」だけではない、多角的な視点を持つことで、あなたのチームの品質への取り組み方が変わるかもしれません。📌 今回のエピソードのポイント「品質」の語源を知る：「品（しな）」ではなく「品（ひん）」が良いとは？JIS規格による定義：対象に備わっている特性が、要求事項をどれだけ満たしているか速報性 vs 正確性：オリンピックの金メダル速報を例に、時代で変わるニーズを考える「誰かにとっての価値」という視点：フェラーリの排気音は騒音か、それとも価値か？チームで語り合う大切さ：代表者（CEO）も含めて「品質」を議論した実体験参考ページ書籍 『現代品質管理総論』( ⁠https://www.asakura.co.jp/detail.php?book_code=27566⁠ )書籍『ワインバーグのシステム思考法』( ⁠https://www.kyoritsu-pub.co.jp/book/b10011607.html⁠ )Chapters(00:00) オープニング(01:11) 「品質」って何だろう？——言葉の定義を掘り下げる(01:42) 書籍『現代品質管理総論』から紐解く語源(02:44) JIS規格における品質の定義：要求事項を満たす程度(03:09) 具体例：オリンピック報道に見る「品質」の変化(05:09) ワインバーグによる定義：「誰かにとっての価値」(05:47) フェラーリを例に考える「価値の多様性」(06:40) 組織ごとに異なる「品質」の重み：コーヒーショップの例(08:15) CEOと品質について議論した実体験(09:05) エンディング・お知らせ📢 感想をお寄せくださいあなたや、あなたの所属する組織にとっての「品質」とは何ですか？ぜひお聞かせください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠こちらからお気軽にどうぞ。フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

ついに始まりました、テストと品質の深淵を探求するポッドキャスト「B-Testing.fm」。記念すべき第1回は、本番組のホストであるブロッコリーの自己紹介回です。なぜ今、ポッドキャストという形で「品質」や「テスト」の考え方を発信するのか。これまで培ってきた豊富なキャリアや専門的な実績を交え、今後の番組の展望についてお話しします。テストの自動化やプロセス改善に悩む方はもちろん、アジャイルな開発組織を目指す全ての方に向けた「品質の学び場」の第一歩を、ぜひお聞きください。📌 今回のエピソードのポイントブロッコリーって何者？：社内ツールの開発からQA、そして「B-Testing」としての独立までの軌跡受賞歴とコミュニティ活動：色々な社外活動をしていますなぜ「言語化」にこだわるのか：イベント登壇だけでは伝えきれない、深い考えをPodcastに込める理由今後の配信予定：毎週10分、テストや品質の「リアル」を届けるための目標📕参考ページ⁠WACATE⁠⁠JaSST⁠⁠Developers Summit⁠🕒 チャプター(00:00) オープニング：2026年、新番組「B-Testing.fm」スタート！(00:58) ブロッコリーのプロフィール：開発エンジニアからQA・品質保証の世界へ(02:02) 本業と副業：QAチームの立ち上げやコンサル実績について(02:26) 具体的な実績：様々な会社・団体での活動(04:22) 専門的な資格：日本唯一の「Holistic Testing」公式トレーナー(05:24) 受賞歴の紹介：Developers Summitでの評価と、発信への想い(06:15) 社外コミュニティ活動：WACATEやJaSST Review、そして「SReEE」のリーダー(08:38) 執筆実績：Agile TestingやBDD（振る舞い駆動開発）に関する翻訳書籍(08:55) これからの番組展望：日本中、世界中のテストに興味がある方へ届けたい(10:10) エンディング📢 感想をお寄せくださいこれから取り上げてほしいテーマや、ブロッコリーへの質問をお待ちしています！X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠こちらからお気軽にどうぞ。番組フォローのお願い：次回から本格的な「テスト・品質論」が始まります。Podcastアプリでのフォローをぜひお願いします！