日々の開発に欠かせない「レビュー」ですが、実は「なんとなく」で行われてしまいがちな活動でもあります。今回は、レビューを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アプリでのフォローをぜひお願いします！