Explore every episode of the podcast くわラジ

「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

仕事しない同僚や部下にイライラしてモチベーションが下がる——そんなとき、どう対処すればいいのか？今回のくわラジは、エンジニアの職場あるあるでもある「働かない人へのフラストレーション」との向き合い方を深掘りします。

「他人の仕事は他人の仕事と割り切る」というkuniwakに、へんてこが「でもサボりを見逃してない？」と食い下がるところから、話は性善説と性悪説の使い分け、採用の失敗と人事評価の構造、そして「人はコントロールできない」という核心のメンタルモデルへ。

後半は上司との1on1で「期待に添えてますか？」と役割を確認する習慣や、オープンクエスチョンではなく案を持って提案するコミュニケーション術など、明日から使える実践的な話が続きます。イライラの正体が「見積もりの甘さ」と「情報の非対称性」にあるという分析は必聴です。

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

・仕事しない同僚にイライラするのはなぜ？モチベーションが下がる構造

・自分の実力とチームの実力を切り離す考え方

・フラストレーションの正体は「見積もりの甘さ」と「情報の非対称性」

・性善説と性悪説の使い分け——現場は性善説、評価・採用制度は性悪説

・「人はコントロールできない」——選択肢を提示して相手に委ねるメンタルモデル

・上司との1on1で「期待に添えてますか？」と役割を確認する習慣

・オープンクエスチョンで聞かない——A案B案C案を持って提案する

・「信頼はするが期待はしない」——リーダーの心の守り方

▼こんな人におすすめ

・仕事しない同僚・部下へのイライラで消耗しているエンジニア

・チームの成果と自分のモチベーションの折り合いに悩んでいる人

・1on1やマネジメントでの役割・期待のすり合わせ方を知りたい人

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

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

YouTube: https://youtu.be/m04Ly5IYq-o

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

X: https://x.com/kuwa_raji

AIコーディングエージェント全盛のいま、なぜあえてVimに戻るのか？Claude Codeを使い込んだ先に待っていたのは、まさかのVim回帰とCLI/TUI時代の到来でした。スーパーエンジニアkuniwakの約15年にわたる開発環境の変遷を一気にたどります。

Perlの会社で素朴にVimを使っていた新人時代、クラッシュ多発のXcodeからJetBrains AppCodeに逃げ込んだiOS開発時代、「どの言語でもIDEがある」JetBrains教の時代。

そして定理証明支援系Isabelleで数学の証明に朝活で挑んだ日々を経て、Claude Code・Codex・Geminiを使い比べるAI時代へ。

へんてこの「もっと詳しく教えてください」に答えながら、「1+1=2はどう証明するのか」から「AI時代にエンジニアはどう生き残るか」まで、ゆるく深く語ります。

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

・Vim→Xcode→JetBrains（AppCode/Rider/CLion）—エンジニア15年の開発環境遍歴

・定理証明支援系とは？Isabelleで「1+1=2」を証明する仕組み（ペアノの公理）

・SledgehammerとSMT/SATソルバー、定理証明ライブラリのセキュリティリスク

・Claude Code vs Codex vs Gemini—AIコーディングエージェントの使い分けと乗り換えの理由

・AIの日本語を自然にするjapanese-tech-writingスキル×Geminiという最強の組み合わせ

・「モデルよりワークフロー」説—サブエージェントによるコードレビューとフォーカスのさせ方

・Claude CodeのCtrl+GでVimが開く—Vim回帰とプラグイン断捨離、それでも手放せないvim-surround

・全部70点のAIに人間は「偏愛」で勝つ—AI時代のエンジニア生存戦略とエネルギー効率の話

▼こんな人におすすめ

・Claude Code・Codex・GeminiなどAIコーディングエージェントの使い分けに悩むエンジニア

・Vim・Neovim・ターミナル環境が好きな人、エディタ遍歴に一家言ある人

・AI時代のエンジニアのキャリア・生存戦略を考えたい人

▼関連リンク

・Vim: https://www.vim.org/

・vim-surround: https://github.com/tpope/vim-surround

・Claude Code: https://claude.com/claude-code

・Isabelle: https://isabelle.in.tum.de/

・Lean: https://lean-lang.org/

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

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

YouTube: https://youtu.be/h6I-_B9dpa4

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

X: https://x.com/kuwa_raji

巨大な仕様書を全員に「読ませる」運用は、もう負けかもしれません。今回のテーマはSSoT（Single Source of Truth＝信頼できる唯一の情報源）。信頼できる唯一の仕様書を一つだけ管理し、そこからCS担当者向け・パートナー企業向けなど、読む人ごとに最適化された「専用ビュー」を自動生成するという仕様書運用の考え方を深掘りします。

スーパーエンジニアのkuniwakが、巨大なシーケンス図・状態遷移図から必要な部分だけを畳んで見せる仕組みや、GitHub Actionsで日本語の仕様書から英語版を自動翻訳するパイプラインなど、実際の現場で運用している実例を紹介。

「ドキュメントが腐る」あるあるを、コミットごとの自動生成と生成AIでどう解決するのかが具体的にわかります。後半は仕様記述の理論的バックグラウンドへ。

契約による設計（Design by Contract）の事前条件・事後条件、「アサートを書けばいいんでしょ」というよくある誤解、ホーア論理からBDDまで、へんてこの質問でゆるく噛み砕いていきます。

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

・SSoT（信頼できる唯一の情報源）とは？仕様書運用への応用

・巨大なシーケンス図・状態遷移図から「読む人専用ビュー」を自動生成する仕組み

・ドキュメントが腐る問題を防ぐ、コミットごとの自動生成と自動英訳パイプライン

・C4モデルのコンテキスト図とシーケンス図の整合性をツールで検証する実例

・仕様記述の専門家「マニピュレーター」という役割と、AI・スキル化による代替

・契約による設計（Design by Contract / DbC）とは？事前条件・事後条件とアサートの正しい理解

・RESTful APIの404は事前条件違反ではない？契約による設計でAPI仕様を読み解く

・巨大ドキュメントをLLMにそのまま読ませる vs 読む人ごとにビューを分ける

▼こんな人におすすめ

・仕様書や社内ドキュメントが「腐る」問題に悩んでいるエンジニア・PM

・契約による設計（DbC）を名前だけ知っていて、正しい理解を手に入れたい人

・生成AI時代の仕様書・ドキュメント運用の実践例を知りたい人

▼関連リンク

・信頼できる唯一の情報源（Wikipedia）: https://ja.wikipedia.org/wiki/信頼できる唯一の情報源

・C4 model: https://c4model.com/

・PlantUML: https://plantuml.com/ja/

・契約プログラミング（Wikipedia）: https://ja.wikipedia.org/wiki/契約プログラミング

・ホーア論理（Wikipedia）: https://ja.wikipedia.org/wiki/ホーア論理

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

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

YouTube: https://youtu.be/pLIjwXXqGW4

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

X: https://x.com/kuwa_raji

LLM（AI）にシーケンス図や設計のレビューを任せたら、なぜ見逃しだらけになるのか？答えは「漠然と探させている」から。ルールベースの検査ツールで怪しい箇所を列挙し、LLMの注意を「意味の構造」にフォーカスさせると、検出精度がほぼ100%まで上がる——そんな検査ツールの作り方を深掘りする回です。

スーパーエンジニアのkuniwakが開発中の、仕様と実装設計を検査するツールの裏側を一般エンジニアのへんてこが根掘り葉掘り聞いていきます。

PlantUMLで書いたシーケンス図の「矢印の連続性」をGo製ツールで解析してLLMにジャッジさせる仕組み、C4モデル（コンテキスト図・コンテナ図）との整合性チェック、そして「誤警告してもいい」というlintツールとの決定的な違いまで。

後半は、LLMに良い設計をさせる鍵としてのテスト駆動開発（TDD）とロードマップ、プライベート関数という抜け道の塞ぎ方、さらにLLMが得意なプログラミング言語と型検査の「税金」の話へと展開します。

AIコーディングエージェントのレビュー精度に悩んでいる人ほど刺さる実践知が詰まっています。

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

・シーケンス図の落とし穴とは？矢印の連続性に隠れた「暗黙のシステム」

・LLMが図の検査で見逃しを連発する理由——漠然とした探索と計算が苦手

・ルールベースの検査ツール×LLMのジャッジで検出率ほぼ100%にする方法

・C4モデル（C4ダイアグラム）とシーケンス図の整合性チェック

・lintツールとの違い：LLMが最終判断するから誤警告に寛容でいい

・LLMに良い設計をさせる鍵：未来の情報（ロードマップ）とテスト駆動開発（TDD）

・プライベート関数という抜け道をAST解析で塞ぐ、roles.tsvでモジュールの役割を先に定義する

・LLMが得意なプログラミング言語は？動的型付け言語の速さと型検査という「税金」

▼こんな人におすすめ

・Claude CodeなどのAIコーディングエージェントのレビュー精度・設計品質を上げたいエンジニア

・シーケンス図やC4モデルなど設計ドキュメントのチェックをAIに任せたい人

・TDDやlintとLLMをどう組み合わせるべきか、考え方の軸がほしい人

▼関連リンク

・PlantUML 公式サイト: https://plantuml.com/ja/

・C4 model 公式サイト: https://c4model.com/

・DeepWiki: https://deepwiki.com/

・Claude Code: https://www.anthropic.com/claude-code

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

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

YouTube: https://youtu.be/qK9uNFp9RjY

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

X: https://x.com/kuwa_raji

ソフトウェアの検証には「正当性検証（Verification）＝正しく作っているか」と「妥当性検証（Validation）＝正しいものを作っているか」の2種類があります。

単体テストやE2Eテスト、CIで確かめられるのはどっち？ユーザビリティや性能要件のような白黒つかない品質はどう検証する？今回はプロダクト検証の全体像を、スーパーエンジニアのkuniwakがへんてこの質問に答えながら解きほぐします。

仕様どおり完璧に実装しても「解きたい課題」とズレていたら意味がない——そのことを象徴する「ポテトチップスが出てくるSNS」のたとえ話から始まり、踏切を例にした安全性（safety）と活性（liveness）の分類、アジャイル・スクラムが妥当性検証を重視する流派である理由、プロダクトオーナーとスクラムマスターとエンジニアの役割分担まで、検証の考え方を体系的に整理。

終盤は、AIが正当性検証の担い手になりつつある今、人間に残る仕事は何かという話や、Figmaのモックアップとタップ数を使ってAIにUIデザインを探索・採点させるkuniwak流の最新アイデアも飛び出します。

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

・正当性検証（Verification）とは？仕様と実装の間の検証

・妥当性検証（Validation）とは？要求・課題と仕様の間の検証

・単体テスト

・E2Eテスト・QAはどちらの検証にあたるのか

・性能要件やユーザビリティなど白黒つかない非機能要求の扱い

・正当性検証の細分化——安全性（safety）と活性（liveness）

・アジャイル・スクラムはなぜ妥当性検証を重視するのか（PO・スクラムマスターの役割）

・AI時代の検証——AIは正当性検証の担い手になり、妥当性検証はどこまでできるか

・Figmaモックアップとタップ数でAIにデザイン探索させるアイデア

▼こんな人におすすめ

・テストやQAをやっているが、VerificationとValidationの違いを説明できるようになりたいエンジニア

・スクラムのPOやスクラムマスターが何を担う役割なのか腹落ちさせたい人

・AIにコード生成やレビューを任せる時代に、人間がやるべき検証は何か気になる人

▼関連リンク

・アジャイルソフトウェア開発宣言: https://agilemanifesto.org/iso/ja/manifesto.html

・スクラムガイド: https://scrumguides.org/

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

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

YouTube: https://youtu.be/Y6qt5YThwpE

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

X: https://x.com/kuwa_raji

超一流のエンジニアとはどんな人なのか？スーパーエンジニアのkuniwakが、これまでのキャリアで出会った「この人すげー」と心から思ったエンジニア・上司・役員を語り尽くす回です。

新卒で入ったミクシィ時代の同期・kubo39さんから教わったmalloc（jemalloc）やスタックとヒープといった低レイヤーの世界、Redisのforkとコピーオンライトを使ったスナップショットの「美しさ」。

前職では、あえて失敗させてくれた上司と、単体テストでは防げない結合バグを形式手法で解決してくれた"上位互換"の同僚。

そして現職コインチェックでは、即断即決で組織を加速させるCTOの石川さんと、集合論でアクセス権限を語りClaude Codeのトークン使用量が社内No.1の専門役員・澤村さん。

へんてこが「なぜその人はすごいのか」を深掘りしていくと、低レイヤー知識による差別化、失敗という資産、意思決定の速度、ドメイン知識と表現力の掛け算という、超一流に共通する要素が見えてきます。

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

・超一流のエンジニアとは？一流が尊敬する人の共通点

・mallocに複数の実装（jemallocなど）がある世界——低レイヤー知識がエンジニアの差別化になる理由

・Redisのバックアップに見る「美しい設計」——forkとコピーオンライト（Copy-on-Write）の仕組み

・パフォーマンスチューニングとセキュリティは上から下まで一気通貫の知識が必要

・失敗は個人の資産——あえて部下に失敗させてくれる上司のすごさ

・単体テストでは防げない結合バグと、形式手法という解決策

・数学の「静的な世界観」が実務を変える——Promise.all / Promise.raceの多数決を否定的に証明した話

・即断即決のCTOがなぜ組織を速くするのか——意思決定の速度というメリット

・集合論でアクセス権限を説明する執行役員——ドメイン知識×表現力×手を動かせる最強のプロダクトオーナー

▼こんな人におすすめ

・「超一流のエンジニア」「すごいエンジニアの特徴」が気になる人

・低レイヤーや形式手法を学ぶ意味を知りたいアプリケーションエンジニア

・意思決定の速い組織・尊敬できる人がいる環境に身を置きたい人

▼関連リンク

・D言語 公式サイト: https://dlang.org/

・Redis 永続化ドキュメント（RDBスナップショット）: https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/

・MDN Promise.all / Promise.race: https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Promise

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアのkuniwakに一般エンジニアのへんてこが「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。感想はXで、匿名のお便りは公式サイトのフォームからお待ちしています。

バニラなら一瞬でできるのに、フレームワークに載せた途端に難しくなる——そんな経験、ありませんか？

今回はkuniwakの「フレームワークは補助輪であって加速装置じゃない」という一言を軸に、規格を決める側と決められる側、アップデート追従や依存の増加がなぜビジネスの速度を削るのかを深掘りしていきます。

TypeScriptだけは別格な理由や、C言語・Rust・Goの立ち位置まで脱線しつつ、最後の「エンジンはお前自身なんだ」という締めがじんわり効いてくる回です。

最近流行りのループエンジニアリング。

狭い入力から広い実装が乱数で生まれるその仕組みを突き詰めると、なぜか「ビットコインの採掘」にそっくりだった——。

試行回数が多い者、つまり資本を持つ者が勝続ける世界はちょっと面白くない。じゃあAI税で再分配できるのか？へんてこの素朴な疑問にkuniwakが応えながら、面白い未来と面白くない未来の分かれ道を探ります。

AIで仕事や社会がどう変わるか、モモヤしている人にこそ聞いてほしい回。

Claude Fable 5に作ってもらった日本語プログラミング入門教材「言語の庭」が凄い - https://zenn.dev/nextbeat/articles/2026-06-cs-edu-site-fable5

転職先選びを、kuniwakは「マップ上のいい点を見つけて、そこに登っていくゲーム」だと言います。

譲れない軸を数字に落とし込み、質問はテンプレ化、回答がそのまま>スコアになる仕組みまで設計。一方で50社分の面接時間をどう捻出するかは地獄で、ネカフェ面接の日々まで……。

さらに「市場価値を一次元の数字に丸めるのは本質を見失ってる」という持論も。ゆるくてディープな転職回です。

「言われた仕様を満たす実装を作ったのに、問題は解決しなかった」——心当たり、ありませんか？

今回はエンジニアのプロフェッショナリズムについて、kuniwak とへんてこがじっくり語ります。XY問題、顧客は本当に欲しいものを喋らない話、AIによって解を探すコストが激減した現実、それでも残る「問題を精密に言語化する」という人間の仕事。

さらに後半は「プロ意識がない人はダメなのか？」という問いに、kuniwak が意外な答えを返します。

働き方や評価に悩むエンジニアにこそ聞いてほしい回です。

新しいことって、どうやって学び続けてますか？ 今回は kuniwak のインプットの流儀がテーマです。

ChatGPTに論文を読ませて自分の組織を「意思決定モデル」として捉え直した話から始まり、行き着いたのが「批判的精神を持つこと」と「前提を確かめること」。

誰かの改善案や正論を鵜呑みにしないための土台の話です。

学びのアップデートに悩むエンジニアにこそ聞いてほしい一本です。

ユーザビリティエンジニアリング原論: https://amzn.to/4dUM32N

ソフトウェア仕様記述の先進技法-Z言語: https://amzn.to/4dVGe3B

今回はちょっと趣向を変えて「失敗した話」がテーマです。

インシデント続きのチームの再発防止ミーティングに送り込まれ、まっすぐ正論をぶつけたら…まさかの「出禁」。いったい何が地雷だったのか。そして後日、同じことを別の人が言ったらすんなり通った理由とは？「何を言うか」より「どう伝えるか」、そして信頼の話。

チャレンジには失敗がつきものだと知っているエンジニアにこそ聞いてほしい一本です。

プロジェクトの後半になるとなぜか「ぐだぐだ」になる現象、ありますよね。

最近PMOになったkuniwakに、その正体と対処法を聞いていく回です。見積もりは1点じゃなく楽観と悲観の2点で出す話、QCDのどこを動かすかは「経営判断」だという話、プロジェクトの賞味期限切れを防ぐ4つの打ち手まで。

話を聞いているうちに「これもう経営者の仕事では？」と思わずツッコんでしまいました。

計画の立て方を学び直したいエンジニアはぜひお聞きください。

プロダクト開発でPdMに「これどうなるんですか？」って聞いたら答えが返ってこなくて、適当に実装したら「違う」と言われた経験ってありませんか？

へんてこの素朴なあるある相談から、kuniwakが「実はそれ、コミュニケーションじゃなくて仕様書の問題」と切り込みます。

そもそも仕様書って何のためにある？よい仕様の正体って？

正解と不正解の境界を引くものとしての仕様、そして「ほぼ疑似コード」になる理由を、ゆるくディープに解きほぐします。仕様書まわりにモヤモヤがある人にぜひ。

ソフトウェア設計って普通に難しくないですか？MVVM、MVC、クリーンアーキテクチャ…新しい流派が出るたびに右往左往してしまう。

でもkuniwakによれば、流派は実はどうでもいい。大事なのは「流派の上にどう城を建てるか」だと言います。

クリーンアーキテクチャ＝玉ねぎの図であると思っていた人にも刺さる話になっています。自分の設計に自身が持てないエンジニアにこそ聞いてほしい回です。

Clean Architecture　達人に学ぶソフトウェアの構造と設計 - https://amzn.to/4tpCH3x

「テストってどこまでやれば安心できるんでしょう？」というへんてこの素朴な疑問から、kuniwakが語るのは"多層防御"の発想。

Lint・単体・結合・E2E、それぞれの層には「ここで見つけるべきバグ」がある。本来Lintで弾けるはずのバグを単体テストで頑張って見つけようとすると、なぜ損するのか。

ODC分析というバグの振り返り手法から、E2Eテストファースト、AI時代のゴールデンテストまで、ゆるくディープに掘り下げます。テスト戦略に悩むエンジニアの方は必聴です。

単体テストでモックをどこまで書けばいいのか、毎回迷いませんか？

へんてこの素朴な悩みに、kuniwakが投げかけたのは「モックが多いのは設計のスメル（臭い）」という一言。

間接入出力、サイクロマティック複雑度、オープン・クローズド原則、技術的負債――テストの話から始まって、いつの間にかエンジニアのビジネス感覚にまで話が広がっていく回。

設計に悩むすべてのエンジニアにおすすめです。

レガシーコード改善ガイド - https://amzn.to/3OzCmwI

「Lintはメンタルに効きます！」

適当なコードを書くと絶対に怒ってくるあの「Lint」について、kuniwakに聞いてみました。すると意外な答えが！？

「Lint」が何者で、どんな目的があるのかわからない人は必聴です。チームに「Lint」を導入するときの目的がはっきりとわかるようになると思います。