B-Testing.fm

私たちは普段、仕事の成果（結果）にばかり目を向けがちですが、その裏側にある「思考のプロセス」を可視化することには、実は大きなメリットがあります。

今回は、簡単な計算問題を例に、思考をプロセスとして切り出すことの重要性を解説します。なぜプロセスを細かく分けると「レビュー」がしやすくなるのか？そのトレードオフとは？

📌 今回のエピソードのポイント

• 「プロセス」の定義：手続きに着目し、対象を別のものへ変換する活動
• プチワーク：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アプリでのフォローをぜひお願いします！