くわラジ

形式手法を実務で使いたいけど、何から始めればいい？ 第29回は、kuniwak がその第一歩としてすすめる「Property-Based Testing」と「契約による設計」の話です。FizzBuzzを例に、事前条件と事後条件とは何かを噛み砕いていきます。

番組では、従来のExample-Based Testingを、いくつかの「点」を試すテストにたとえます。Property-Based Testingでは、機械が入力を大量に生成してテストを回します。そこで立ちはだかるのが「assertに何を書けばいいのか」という壁です。へんてこ が FizzBuzzの性質を考えながら穴を見つけていく掛け合いを通して、ジェネレーターの作り方や性質の見つけ方が見えてきます。後半では、事前条件を満たさない入力の扱い、防御的プログラミング、バリデータやソート関数の事前条件、停止性と部分正当性まで話が広がります。ホーア論理への入り口としてもどうぞ。

▼チャプター

00:00 オープニング

01:51 実務での第一歩：Property-Based Testing

06:37 FizzBuzzを例にした性質の定義

12:58 事前条件と事後条件（契約による設計）

33:06 次回予告：定理証明支援系

33:40 エンディング

▼この回で話していること

・形式手法を実務で始めるには？最初の一歩

・Property-Based Testingとは？Example-Based Testingとの違い

・Property-Based Testingの性質の見つけ方とジェネレーター

・FizzBuzzで考えるProperty-Based Testingの書き方

・契約による設計とは？事前条件と事後条件の違い

・事前条件違反と防御的プログラミング

・停止性と部分正当性（ホーア論理）の関係

・Web APIや比較関数の事前条件はどう考える？

▼こんな人におすすめ

・形式手法に興味はあるけど、何から始めればいいかわからないエンジニア

・ユニットテストの網羅性に限界を感じている人

・Property-Based Testingや契約による設計を実務で試してみたい人

▼関連リンク

- くわラジ 公式サイト: https://kuwa-raji.henteko07.com/

- くわラジ Spotify: https://open.spotify.com/show/6uUjalUT94ugSgtLI5WF6a

- くわラジ Apple Podcasts: https://podcasts.apple.com/jp/podcast/id1894147982

- Hypothesis（Python）: https://hypothesis.readthedocs.io/

- fast-check（JavaScript/TypeScript）: https://github.com/dubzzz/fast-check

- Eiffel Software「Design by Contract」: https://www.eiffel.com/values/design-by-contract/

- Building bug-free O-O software: An introduction to Design by Contract: https://archive.eiffel.com/doc/manuals/technology/contract/

- Hoare logic（Wikipedia）: https://en.wikipedia.org/wiki/Hoare_logic

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアの kuniwak に一般エンジニアの へんてこ が「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。感想は X でハッシュタグ #くわラジ をつけてつぶやいてください。

#くわラジ #形式手法 #PropertyBasedTesting #契約による設計 #事前条件 #ホーア論理 #テスト

- くわラジ 公式サイト: https://kuwa-raji.henteko07.com/

- くわラジ Spotify: https://open.spotify.com/show/6uUjalUT94ugSgtLI5WF6a

- くわラジ Apple Podcasts: https://podcasts.apple.com/jp/podcast/id1894147982

- Hypothesis（Python）: https://hypothesis.readthedocs.io/

- fast-check（JavaScript/TypeScript）: https://github.com/dubzzz/fast-check

- Eiffel Software「Design by Contract」: https://www.eiffel.com/values/design-by-contract/

- Building bug-free O-O software: An introduction to Design by Contract: https://archive.eiffel.com/doc/manuals/technology/contract/

- Hoare logic（Wikipedia）: https://en.wikipedia.org/wiki/Hoare_logic

─────────────

YouTube: https://youtu.be/vCBmcs2dEGM

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji

形式手法（フォーマルメソッド）とは何か？ 日本語で書いた仕様書はなぜ「顧客が本当に欲しかったもの」とズレるのか——数学を土台に仕様を書き、解釈のブレをなくすという形式手法の考え方を、入門としてざっくり解説する回です。

「形式手法がまったく分かってない」と言うへんてこに、kuniwak が動物園や三角形の面積のたとえで、形式言語・数学基礎論・定理証明支援系とのつながりを噛み砕いていきます。後半は、AI に TLA+ や Lean で後から検証させる「バイブ形式手法」の落とし穴を取り上げます。テストとの違いである「有限の壁」や、"何が保証されていて何が保証されていないか" を人間が把握すべき理由も話しています。数学が苦手でも「道具として使えればいい」と思える、形式手法シリーズの第1回です。

▼チャプター

00:00 オープニング

00:12 形式手法の定義と「形式」の意味

08:08 数学基礎論と論理的検証

14:25 形式手法における理学と工学の側面

19:06 バイブ形式手法の注意点

30:18 実装先行の課題と設計段階での活用

33:33 エンディング

▼この回で話していること

・形式手法とは？「形式」の意味と、数学で仕様を書く理由

・自然言語の仕様書（PRD など）が曖昧になる問題

・プログラミング言語も形式言語の仲間という話

・数学基礎論・数理論理学と、ヒルベルトによる数学の形式化

・四色定理や Lean など、定理証明支援系による証明の現在地

・AI に TLA+ / Lean で検証させる「バイブ形式手法」の注意点

・テストと形式手法の違い——「有限の壁」と使い分け

・テスト容易な設計と同じく、証明しやすい設計は最初から

▼こんな人におすすめ

・形式手法・形式検証に興味はあるけど、何から知ればいいか分からないエンジニア

・AI に検証やテストを書かせていて、「本当に保証できているのか」が気になる人

・数学が苦手で形式手法を敬遠していた人

▼関連リンク

・くわラジ 公式サイト: https://kuwa-raji.henteko07.com/

・くわラジ Spotify: https://open.spotify.com/show/6uUjalUT94ugSgtLI5WF6a

・くわラジ Apple Podcasts: https://podcasts.apple.com/jp/podcast/id1894147982

・Lean（定理証明支援系 / プログラミング言語）: https://lean-lang.org/

・The TLA+ Home Page（Leslie Lamport）: https://lamport.org/tla/tla.html

・形式手法（Wikipedia）: https://ja.wikipedia.org/wiki/形式手法

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアの kuniwak に一般エンジニアの へんてこ が「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。感想は X でハッシュタグ #くわラジ をつけてつぶやいてください。

─────────────

YouTube: https://youtu.be/lnR1JfJmX1k

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji

「AIがコードを書くなら、テストはE2Eテストに全部寄せればいいのでは？」──Xで話題になったE2Eテスト全振り論に、kuniwak が真っ向から反論します。E2Eテストは単体テストの"上位互換"なのに、なぜ全部をE2Eにしてはいけないのか。テスト戦略とは何かを、AI時代の視点から掘り下げる回です。

E2Eテスト（エンドツーエンドテスト）が見つけられるバグ・見つけられないバグ、保守コストと実行コストが「100倍〜1000倍」になる理由、単体テストと組み合わせると同じコストでより多くのバグが見つかる仕組みを、FizzBuzzの例で噛み砕きます。へんてこ が個人開発で書かせたE2Eテストが25分かかっている実体験も交えつつ、AIにテストを後から書かせると何が起きるのか、テストオラクルを誰が握るべきかまで話が広がります。

▼チャプター

00:00 オープニング

01:32 E2Eテストのコストと課題

15:26 E2Eテストシナリオの選定基準

19:13 AI時代におけるE2Eテスト

34:13 セキュリティ観点から考えるテスト戦略

37:27 エンディング

▼この回で話していること

・E2Eテストとは？ 単体テスト・結合テストとの違いと「結合バグ」

・E2Eテストの保守コストと実行コストが高すぎる理由

・テストケースは結合するほど組み合わせ爆発する

・E2Eテストのシナリオはどう選ぶ？ ユーザー価値と収益導線のハッピーパス

・AIにE2Eテストを書かせると「実装の追認」になる問題

・テストファーストでE2Eテストを先に書くのはアリか

・テストオラクルを実装にしてはいけない理由

・形式手法・オブザーバビリティも含めたテスト戦略は人間の仕事

▼こんな人におすすめ

・AIコーディングでE2Eテストに頼りきりになっている人

・テストピラミッドやテスト戦略の考え方を整理したいエンジニア

・CIのテストが遅くて開発が止まりがちなチーム

▼関連リンク

・くわラジ 公式サイト: https://kuwa-raji.henteko07.com/

・くわラジ Spotify: https://open.spotify.com/show/6uUjalUT94ugSgtLI5WF6a

・くわラジ Apple Podcasts: https://podcasts.apple.com/jp/podcast/id1894147982

・Playwright: https://playwright.dev/

・Selenium WebDriver: https://www.selenium.dev/documentation/webdriver/

・Test oracle（Wikipedia）: https://en.wikipedia.org/wiki/Test_oracle

・djbdns: https://cr.yp.to/djbdns.html

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアの kuniwak に一般エンジニアの へんてこ が「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。感想は X でハッシュタグ #くわラジ をつけてつぶやいてください。

─────────────

YouTube: https://youtu.be/sn1MDn-TuLI

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji

「わかっている」とはどういう状態なのか？ 自分の理解度はどう測ればいいのか？ 今回は「わからない」という感覚をテーマに、理解の基準、わからないと認められない心理、そして答えを急がず"わからないまま保留する"力について、へんてこ が kuniwak に聞いてみました。

kuniwak が理解度の物差しとして使っているのは「構成要素に分解できるか」。形式手法やECサイトの在庫・配送を例に、わかったつもりの知識を分解すると「わからない部分」が見えてくる話から、知識の裾野の広さ、AI が"どの分野も平均点以上"の専門家として隣の領域を補ってくれる話、ポアンカレ予想のように別分野の視点が突破口になる話へ。後半は、見栄や白黒つけたい心理が「わからない」を認めにくくしていること、コードレビューで「わかってました」と言われたときの向き合い方、ジュニアエンジニアの学習計画や採用面接で「わかっているか」ではなく「できるか」で判断する理由、そして AI 時代に人間が"理解を手放す"ことと意思決定の関係まで掘り下げます。

▼チャプター

00:00 オープニング

00:48 「わかっている」基準としての構成要素への分解

06:21 知識の広がりとAIによる専門性の補完

09:33 「わからない」を認められない心理と保留する力

16:10 「わかっているか」ではなく「できるか」で判断する

19:55 理解を手放すことと意思決定

25:24 エンディング

▼この回で話していること

・「わかっている」の基準とは？ 構成要素に分解できるかで理解度を測る

・わかったつもりを防ぐ：分解・例示で「わからない部分」を自覚する

・AI は"全分野で平均点以上の専門家"：隣の分野の知識がブレイクスルーを生む

・「わからない」を認められない心理：見栄と、白黒つけたくなる二分法

・わからないまま保留する力（ネガティブ・ケイパビリティ）と知的誠実さ

・コードレビューで「わかってました」と言われたら：ADR のように不採用案と理由を書く

・学習計画・採用面接は「わかるか」ではなく「できるか」で判断する

・AI 時代に人は理解を手放すのか？ わからなくても失敗しない意思決定のしかた

▼こんな人におすすめ

・自分が本当に理解できているのか不安になるエンジニア

・メンバーの理解度の見極めや育成・採用に悩むテックリード・マネージャー

・AI に頼るほど「自分はわかっていないのでは」とモヤモヤしている人

▼関連リンク

・くわラジ 公式サイト: https://kuwa-raji.henteko07.com/

・くわラジ Spotify: https://open.spotify.com/show/6uUjalUT94ugSgtLI5WF6a

・くわラジ Apple Podcasts: https://podcasts.apple.com/jp/podcast/id1894147982

・Architectural Decision Records（adr.github.io）: https://adr.github.io/

・ネガティブ・ケイパビリティとは（日本の人事部）: https://jinjibu.jp/keyword/detl/1569/

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアの kuniwak に一般エンジニアの へんてこ が「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。感想は X でハッシュタグ #くわラジ をつけてつぶやいてください。

─────────────

YouTube: https://youtu.be/vZjK6oayv0Q

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji

コーン茶（とうもろこし茶）って、なぜコーヒーの代わりになるの？ vim-jp の Slack で「AI に書けないようなことをぜひ語ってほしい」とリクエストをもらった kuniwak のコーン茶レビューを入り口に、エンジニアの「プログラミングのお供」をへんてこ が根掘り葉掘り聞いてみました。

コーヒー好きの kuniwak がカフェインを減らすためにたどり着いたのが、ノンカフェインのコーン茶。無印良品とルピシアの飲み比べ、焼肉チェーンのドリンクバーのコーン茶との違いを「コーンらしさ」と「香ばしさ」の軸で語ります。話はそのままコーヒーへ。産地と焙煎度（ロースト）での豆の選び方、自家焙煎が難しい理由、コーヒーミルの大敵「微粉」、ハンドドリップをやめてマキネッタ（直火式エスプレッソメーカー）に落ち着いた理由まで。後半は仕事中の集中力を支えるサプリ「クレアチン」の個人的な体験談から、薬の説明書（添付文書）を"取説"として読み込む習慣、半減期の考え方、そして自分で併用禁忌に気づいた話へ。「飲み合わせのチェックこそ AI でやってほしい」という薬局 DX の話題まで、技術の話をしていないのに性格と仕事の流儀がにじみ出る回です。

※ サプリメントや薬に関する話は、あくまで一個人の体験談です。体質や持病、服用中の薬によって合う・合わないがあるので、試す前に医師・薬剤師に相談してください。

▼チャプター

00:00 オープニング：vim-jp の Slack で届いたリクエスト「コーン茶について語ってほしい」

01:20 コーン茶を飲み始めた理由：コーヒーのカフェインを減らしたい

03:15 コーン茶レビュー：無印良品とルピシア、「コーンらしさ」と「香ばしさ」

08:48 コーヒー豆の選び方：産地と焙煎度

12:17 自家焙煎はなぜ難しいのか

14:36 好きな豆とコーヒーミル：大敵は「微粉」

17:43 ハンドドリップよりマキネッタを選んだ理由

20:22 仕事中のサプリ：クレアチンを飲み始めたきっかけ

26:18 薬の説明書を読む：半減期と併用禁忌

31:08 飲み合わせチェックは AI に任せたい：薬局 DX とデータ化

34:11 エンディング

▼この回で話していること

・コーン茶（とうもろこし茶）はノンカフェイン：コーヒーの飲みすぎを減らす代わりの飲み物として

・コーン茶の選び方とおすすめ：無印良品とルピシアの違い、ティーバッグとペットボトルの風味の差

・コーヒー豆の選び方：産地（エチオピアなど）と焙煎度、どちらから好みを探すか

・自家焙煎が難しい理由と、コーヒーミルで味を左右する「微粉」とは

・ハンドドリップとマキネッタの違い：味を安定させたい人の淹れ方

・エンジニアの集中力とサプリ：クレアチンを試した個人の体験談と注意点

・薬の添付文書の読み方：血中濃度・半減期・併用禁忌を自分で確認する

・お薬手帳の大切さと、薬の飲み合わせチェックを AI・薬局 DX に期待する話

▼こんな人におすすめ

・コーヒーを飲みすぎていて、カフェインを減らしたいエンジニア

・コーン茶やコーヒー豆、コーヒーミルの選び方をゆるく知りたい人

・仕事中の飲み物・習慣など、他のエンジニアの「プログラミングのお供」が気になる人

▼関連リンク

・くわラジ 公式サイト: https://kuwa-raji.henteko07.com/

・くわラジ Spotify: https://open.spotify.com/show/6uUjalUT94ugSgtLI5WF6a

・くわラジ Apple Podcasts: https://podcasts.apple.com/jp/podcast/id1894147982

・vim-jp のチャットルーム（Slack）: https://vim-jp.org/docs/chat.html

・ルピシア: https://www.lupicia.com/

・ポーレックス（コーヒーミル）: https://www.porlex.co.jp/

・ビアレッティ（マキネッタ）: https://www.bialetti.com/

・MSD マニュアル家庭版 クレアチン: https://www.msdmanuals.com/ja-jp/home/26-その他の話題/サプリメント-栄養補助食品-とビタミン/クレアチン

・PMDA 医療用医薬品 添付文書等情報検索: https://www.pmda.go.jp/PmdaSearch/iyakuSearch/

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアの kuniwak に一般エンジニアの へんてこ が「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。感想は X でハッシュタグ #くわラジ をつけてつぶやいてください。

─────────────

YouTube: https://youtu.be/S1gKztIwhU0

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji

登壇ネタの「一般化」って、具体的にどうやるの？ 前回「発表ネタで一番大事なのは一般化」と語った kuniwak に、へんてこ が自分の実ネタ「チームで人間のコードレビューを全廃して半年、大きな事故なし」を持ち込み、登壇できる形に一般化するまでを公開添削してもらいました。

AI コードレビュー＋テスト、実装前に「なぜ変えるのか」を GitHub Issue に言語化し、影響が大きいものだけ事前レビュー、実装後はギャップを洗い出す——そんなへんてこ のフローに対して、kuniwak は「金融や航空宇宙の人が聞いたらどう思う？」と想定聴衆を広げたり切り捨てたりしながら一般化を進めます。刺さってほしくない人に刺さると何が起きるのか、発表で本当に伝わるのは何割なのか、聴衆に何を持ち帰ってもらえば「大成功」なのか。後半はネタに合わせたイベントの選び方、カンファレンスのアンケート結果の読み方、そして勉強会主催者目線のプロモーション事情（X 広告の1クリック単価やインフルエンサー登壇の効果）まで話が広がります。

▼チャプター

00:00 オープニング

01:10 事例紹介：コードレビューの廃止

04:32 想定聴衆の絞り込みと一般化のプロセス

11:19 ネタに合わせた発表場所の選び方

19:28 イベントの規模とフィードバックの獲得

23:40 勉強会のプロモーションとコミュニティの活用

30:35 エンディング

▼この回で話していること

・人間のコードレビューをなくして AI コードレビューとテストに置き換えた開発チームの事例

・登壇ネタの一般化とは？ 想定聴衆を「足す」「切り捨てる」選択の連続

・タイトルで刺さる人を選ぶ理由——想定外の聴衆に刺さると炎上する

・発表は3割しか伝わらない：How は資料に任せ、次のアクションにつながる「取っ手」を残す

・説得力を上げる数字の出し方（リリース頻度×事故ゼロ）

・小さな勉強会と大きなカンファレンス、登壇経験を積むならどっち？ iOSDC のルーキーズLT枠も

・カンファレンスのアンケート結果の読み方：回答率と評価分布の見方

・勉強会の告知・集客方法：X 広告のフォロワーターゲティング、インフルエンサー登壇、Slack コミュニティ

▼こんな人におすすめ

・社内の取り組みを勉強会やカンファレンスの登壇ネタにしたいエンジニア

・AI 時代のコードレビューのあり方や、レビュー待ちの解消に悩んでいる開発チーム

・勉強会を主催していて、集客やプロモーションに悩んでいる人

▼関連リンク

・くわラジ 公式サイト: https://kuwa-raji.henteko07.com/

・くわラジ Spotify: https://open.spotify.com/show/6uUjalUT94ugSgtLI5WF6a

・くわラジ Apple Podcasts: https://podcasts.apple.com/jp/podcast/id1894147982

・Claude Code Code Review ドキュメント: https://code.claude.com/docs/ja/code-review

・iOSDC Japan 2026: https://iosdc.jp/2026/

・connpass: https://connpass.com/

・X 広告 フォロワーターゲティング: https://business.x.com/ja/advertising/targeting/follower

・vim-jp のチャットルーム（Slack）: https://vim-jp.org/docs/chat.html

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアの kuniwak に一般エンジニアの へんてこ が「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。感想は X でハッシュタグ #くわラジ をつけてつぶやいてください。

─────────────

YouTube: https://youtu.be/3PZdb--AJW4

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji

勉強会やカンファレンスで登壇し続けるには、発表ネタをどう作ればいいのか？ 登壇回数50回超、年に4〜5回のペースで発表を続けるスーパーエンジニア kuniwak に、一般エンジニア へんてこ が「ネタの作り方」を根掘り葉掘り聞きました。答えの中心にあるのは「一番大事なのは一般化すること」という一言。自社固有の話が刺さらない理由から、一般化しすぎると逆に解けなくなるジレンマまで、登壇ネタの設計論を掘り下げます。

前半は「ネタが先か、場が先か」。kuniwak はネタを先に作り、それに合う発表の場（JaSST・iOSDC・builderscon のようなカンファレンスから小さな勉強会まで）を選ぶスタイルで、へんてこ は「自分は逆だった」と気づきます。聴衆の層を読むコツとして「参加費が有料か無料か」で求められる内容が変わる話や、招待講演では空気を読むという裏話も。中盤はスライド作りのプロセス。伝えたいことを3行で書き出し、マインドマップでアウトラインを組み、テンプレートに流し込んで20分の発表を1〜2時間で仕上げる「職人技」を公開します。ブログ執筆で Gemini を使う理由や、AI が作ったスライドへの率直な評価も飛び出します。終盤は「日常のタスクを一般化して種を溜め、成功したものだけ発表する」というネタのストック術、AI 時代に自作ツールや OSS の発表はまだ価値があるのかという議論、そして CFP やイベントの探し方（なければ勉強会を自分で作る）へ。最後にたどり着く結論は「課題を探し続けろ」です。

▼チャプター

00:00 導入

04:17 発表ネタを作るための「一般化」

11:59 聴衆のニーズに応じた発表設計

17:21 スライド作成のプロセス

21:21 課題発見から始まるネタ作り

32:20 発表イベントの探し方

37:48 エンディング

▼この回で話していること

・勉強会・カンファレンスで登壇し続けるコツ：年4〜5回・累計50回登壇の kuniwak の場合

・登壇ネタの作り方で一番大事なのは「一般化」——自社固有の話が刺さらない理由

・一般化しすぎると「主語がでかい」問題：どこまで一般化するかのバランス

・ネタが先か、イベントが先か？ 発表テーマから登壇する場を選ぶ考え方

・聴衆の層の読み方：参加費の有料・無料で求められる発表内容はどう変わるか

・発表スライドの作り方：伝えたいことを3行に書き出し、マインドマップでアウトラインを作る

・20分の発表を1〜2時間で作るプロセスと、AI にスライドを作らせるより速い理由

・自作ツール・OSS の発表は AI 時代でも需要があるのか——AI は How を作り、What と課題発見は人間の仕事

・CFP・登壇イベントの探し方と、勉強会がなければ自分で作るという選択肢

▼こんな人におすすめ

・勉強会やカンファレンスで登壇したいけれど、発表ネタが思いつかないエンジニア

・CFP に応募しても採択されない、または一度登壇したあと続かなくなってしまった人

・技術ブログや OSS などのアウトプットを、登壇につなげたいと考えている人

▼関連リンク

・くわラジ 公式サイト: https://kuwa-raji.henteko07.com/

・くわラジ Spotify: https://open.spotify.com/show/6uUjalUT94ugSgtLI5WF6a

・くわラジ Apple Podcasts: https://podcasts.apple.com/jp/podcast/id1894147982

・Codex を使って障害対応の机上演習をやってみよう（Coincheck Tech Blog / kuniwak）: https://tech.coincheck.blog/entry/codex-ttx

・JaSST ソフトウェアテストシンポジウム: https://jasst.jp/

・Vint（kuniwak 作の Vim script Lint）: https://github.com/Vimjas/vint

・『イシューからはじめよ［改訂版］』（安宅和人・英治出版）: https://eijipress.co.jp/en/products/2356

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアの kuniwak に一般エンジニアの へんてこ が「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。感想は X でハッシュタグ #くわラジ をつけてつぶやいてください。

─────────────

YouTube: https://youtu.be/X8Wueh1G8Qc

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji

ポッドキャストを続けるコツとは何か？ 「9割の番組は3話で止まり、残った番組の9割も20話までに止まる」と言われるほとんどのポッドキャストが21回目を迎えられない中、くわラジは今回で第21回。スーパーエンジニア kuniwak と一般エンジニア へんてこ が、約5か月・20エピソードを続けてこられた理由を「準備しすぎない」「気負わない」「間違えたら謝る」の3つで振り返ります。

前半は Spotify・Apple Podcasts・YouTube のアナリティクスを Claude Code に集計させた「数字で見るくわラジ」。累計再生数、1エピソードあたりの再生数、最後まで聞いてもらえた割合（完聴率）、リスナーの年齢層と男女比、そして人気回・不人気回の傾向まで、個人ポッドキャストの数字をそのまま公開します。なぜか YouTube だけで再生数が跳ねた #19 printfデバッグ回の謎も。中盤は印象に残っている回の振り返りです。kuniwak が挙げるのは「間違ったことを言ってしまった」と自覚している2つの回（#13・#20）で、そこから「アウトプットすると理解の甘さが浮き彫りになる」「ポッドキャストは生成AIで偽れない媒体」という話へ広がります。へんてこ の推し回は #07「正論は、出禁になる。」。終盤は今後話したいテーマとして、形式手法の入門、勉強会で発表する技術、そして vim-jp Slack からリクエストのあった「コーン茶」まで。終了すると聞いた「エンジニアの楽園 vim-jp ラジオ」への言及と、恐れ多い野望も飛び出します。

▼チャプター

00:00 オープニング

03:45 数字で振り返るくわラジ

11:07 印象に残っているエピソード

20:21 今後話したいテーマ

25:42 エンディング

▼この回で話していること

・ポッドキャストが続かない理由と、21回目まで到達する番組が少ないという統計

・くわラジが継続できている理由：準備しすぎない・気負いすぎない・間違えたら謝る

・Claude Code でポッドキャストのアナリティクス（Spotify / Apple Podcasts / YouTube）を集計してみた

・個人ポッドキャストの再生数・完聴率・リスナー属性はどれくらい？

・YouTube で再生数が伸びた回・伸びなかった回から見えるアルゴリズムの傾向

・kuniwak が「間違えた」と振り返る回と、アウトプット（言語化）で理解の穴が浮き彫りになる話

・ポッドキャストは生成AIで偽れない媒体か？ライブ感と人間がやる意味

・へんてこ の推し回 #07「正論は、出禁になる。」

・今後話したいテーマ：形式手法入門・勉強会での発表術・コーン茶

▼こんな人におすすめ

・ポッドキャストや技術ブログなどの情報発信を始めたい、または続かずに止まってしまったエンジニア

・個人ポッドキャストの再生数・完聴率・リスナー層のリアルな数字を知りたい人

・くわラジを最近聞き始めて、どの過去回から聞けばいいか知りたい人

▼関連リンク

・くわラジ 公式サイト: https://kuwa-raji.henteko07.com/

・くわラジ Spotify: https://open.spotify.com/show/6uUjalUT94ugSgtLI5WF6a

・くわラジ Apple Podcasts: https://podcasts.apple.com/jp/podcast/id1894147982

・Podnews「How to outlast 99% of podcasts: four simple rules」: https://podnews.net/article/four-rules-to-outlast-almost-every-other-podcast

・形式手法とは？（ディペンダブル・システムのための形式手法の実践ポータル）: https://formal.mri.co.jp/outline/

・エンジニアの楽園 vim-jp ラジオ: https://vim-jp-radio.com/

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアの kuniwak に一般エンジニアの へんてこ が「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。感想は X でハッシュタグ #くわラジ をつけてつぶやいてください。

─────────────

YouTube: https://youtu.be/gk4vZoDe5ss

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji

ライフプランシミュレーターを自作すると何がわかるのか？ スーパーエンジニア kuniwak が、Googleスプレッドシート製の家計シミュレーションを Go + Makefile + TSV のパイプラインに作り直し、AI（Claude Code）と一緒に約3万通りの人生シナリオを計算した話です。持ち家 vs 賃貸、老後資金、インフレ率、金融危機……「自分の場合はどうなるのか」を検算し続けた結果、行き着いたのは「大きく勝つより負けない」という結論でした。

きっかけは家を買うかどうかの決断。賃貸を続けて長生きした場合に資金が尽きるという試算が、持ち家の後押しになったそうです。スプレッドシートではバージョン管理もA案・B案の比較もつらい、という へんてこ にも刺さる悩みから、Makefile で差分ビルドできる純粋関数的なパイプラインへ移行。さらに確定申告書（e-Tax）と突き合わせて税金計算を1円単位で一致させたところ、AIが確定申告のミスまで指摘してくる「AIファイナンシャルプランナー兼税理士」状態に。約8個のパラメーターを掛け合わせて資産推移を量産すると、最も効くのはインフレ率という外部環境だった、という発見も語られます。後半は、マネーフォワード ME の「計算対象外」フラグの落とし穴や、銀行明細・クレジットカード・Eco通帳で家計データを信頼できる形に集める実践術、そして SQLite ではなく TSV と関係代数を選んだエンジニアリング上の判断まで。作ったツールは OSS として公開予定とのことです。

▼この回で話していること

・ライフプランシミュレーターとは？収入・支出から将来の資産推移を試算する仕組み

・持ち家 vs 賃貸を自分の条件で検算したら何がわかったか

・スプレッドシートの限界：バージョン管理・ブランチ（A案/B案/C案の比較）ができない

・Go + Makefile + TSV パイプラインで AI にライフプランを量産させる方法

・e-Tax の確定申告書と突合して税金計算を1円単位で検算、AIファイナンシャルプランナーの実力

・約3万通りのシナリオ分析でわかった、資産に一番効くパラメーター（インフレ率・金融危機・年金受給時期）

・リスク選好とポートフォリオ：S&P500 一本か、債券を混ぜて利回り3%で守るか

・マネーフォワード ME の「計算対象外」の落とし穴と、銀行明細・クレカ・Eco通帳で家計データを集めるコツ

・SQLite ではなく TSV + 関係代数を選んだ理由と、状態を持たない純粋関数コマンドの設計

・未来が予測できることで失われる幸せ、そして OSS 公開予定

▼こんな人におすすめ

・老後資金や持ち家 vs 賃貸を、一般論ではなく自分の数字でシミュレーションしたいエンジニア

・Claude Code などの AI を家計管理・確定申告の検算・FP相談に使ってみたい人

・スプレッドシート管理に限界を感じていて、Makefile や TSV パイプラインでの再現可能な計算に興味がある人

▼関連リンク

・金融庁 ライフプランシミュレーター: https://www.fsa.go.jp/policy/nisa2/lifeplan-simulator/

・FP-UNIV ライフプランシミュレーション: https://fp-univ.net/

・マネーフォワード ME サポート「計算対象のチェックを外すとどうなりますか」: https://support.me.moneyforward.com/hc/ja/articles/900003501566

・三菱UFJ銀行 Eco通帳（インターネット通帳）: https://www.bk.mufg.jp/tsukau/eco_tsuchou/index.html

・OECD 対日経済審査 2026（日本語概要）: https://www.oecd.org/content/dam/oecd/en/topics/policy-sub-issues/economic-surveys/Japan-economic-survey-2026-brochure-JP.pdf

・関係代数（関係モデル） - Wikipedia: https://ja.wikipedia.org/wiki/関係代数_(関係モデル)

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアの kuniwak に一般エンジニアの へんてこ が「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。感想は X でハッシュタグ #くわラジ をつけてつぶやいてください。

─────────────

YouTube: https://youtu.be/5EEq54rQOI8

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji

printfデバッグやステップ実行に頼るデバッグは「負け」——その心は、デバッグのしやすさ（デバッガビリティ）はデバッグ手法ではなく設計で決まるから。今回はスーパーエンジニアのkuniwakに、一般エンジニアのへんてこが「熟練者と初学者で差が出るデバッグのやり方」を聞きました。

printfを仕込んで消すその場しのぎの確認ではなく、まず再現テストを書く。バグが出るのはアルゴリズムとドメイン知識が混ざった「もやっとした場所」だから、ソート関数と大小比較のように分離してプロパティベーステストで固める。

iOSアプリなど状態を持つクライアントサイドでは、状態遷移をログに残す設計にしておけばAppleの審査で指摘された課金バグも一瞬で特定できる——という実話も登場します。

さらにRedux/TCAのシングルデータストアが本当にテストしやすいのかへの異論、「仮説を立てる」より「切り分け」で二分探索的に原因を追い詰める考え方まで、デバッグ観がひっくり返る回です。

▼この回で話していること

・printfデバッグ・ステップ実行が「負け」な理由と、ログ出力（debug/traceレベル）との違い

・デバッグの代わりに再現テストを書くという考え方

・バグはテスト不足のサイン——デバッガビリティの高い設計とは

・アルゴリズムとドメイン知識の分離（ソート関数と比較関数の例）とプロパティベーステスト

・ステップ実行が正当化される例外：パフォーマンス優先のホットスポット

・クライアントサイド（iOS）のデバッグ：状態機械（ステートマシン）と状態遷移ログ

・Flux/Redux/TCAのシングルデータストアはテストしやすいのか？——インターフェース分離原則から考える

・「仮説を立てる」より「切り分け」——二分探索で原因を特定するデバッグ手順

▼こんな人におすすめ

・printfデバッグから抜け出したい、デバッグのやり方を体系的に知りたいエンジニア

・テストが書きにくいコードに悩んでいて、テストしやすい設計を学びたい人

・Redux/TCAなどの状態管理アーキテクチャの採用を検討している人

▼関連リンク

・Redux 公式サイト: https://redux.js.org/

・The Composable Architecture (TCA): https://github.com/pointfreeco/swift-composable-architecture

・StoreKit（Apple Developer Documentation）: https://developer.apple.com/documentation/storekit

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアのkuniwakに一般エンジニアのへんてこが「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。感想はハッシュタグ #くわラジ でお寄せください。

─────────────

YouTube: https://youtu.be/D4bOru9qBEY

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji