If you like くわラジ, try…
Latest episodes
-
#24 "AIに書けない"コーン茶レビュー——vim-jp Slackで届いたリクエストに答えてみた
October 8, 2026 · 36 minコーン茶(とうもろこし茶)って、なぜコーヒーの代わりになるの? vim-jp の Slack で「AI に書けないようなことをぜひ語ってほしい」とリクエストをもらった kuniwak のコーン茶レビューを入り口に、エンジニアの「プログラミングのお供」をへんてこ が根掘り葉掘り聞いてみました。 コーヒー好きの kuniwak がカフェインを減らすためにたどり着いたのが、ノンカフェインのコーン茶。無印良品とルピシアの飲み比べ、焼肉チェーン…
-
#23 発表は"3割"しか伝わらない——コードレビュー廃止ネタを一般化してみた
October 1, 2026 · 33 min登壇ネタの「一般化」って、具体的にどうやるの? 前回「発表ネタで一番大事なのは一般化」と語った kuniwak に、へんてこ が自分の実ネタ「チームで人間のコードレビューを全廃して半年、大きな事故なし」を持ち込み、登壇できる形に一般化するまでを公開添削してもらいました。 AI コードレビュー+テスト、実装前に「なぜ変えるのか」を GitHub Issue に言語化し、影響が大きいものだけ事前レビュー、実装後はギャップを洗い出す——そんなへんてこ…
-
#22 一番大事なのは"一般化"——登壇50回で分かった発表ネタの作り方
September 17, 2026 · 40 min勉強会やカンファレンスで登壇し続けるには、発表ネタをどう作ればいいのか? 登壇回数50回超、年に4〜5回のペースで発表を続けるスーパーエンジニア kuniwak に、一般エンジニア へんてこ が「ネタの作り方」を根掘り葉掘り聞きました。答えの中心にあるのは「一番大事なのは一般化すること」という一言。自社固有の話が刺さらない理由から、一般化しすぎると逆に解けなくなるジレンマまで、登壇ネタの設計論を掘り下げます。 前半は「ネタが先か、場が先か」。kuniwak…
-
#21 気負わない・準備しすぎない——21回続いたポッドキャストの裏側
September 10, 2026 · 28 minポッドキャストを続けるコツとは何か? 「9割の番組は3話で止まり、残った番組の9割も20話までに止まる」と言われるほとんどのポッドキャストが21回目を迎えられない中、くわラジは今回で第21回。スーパーエンジニア kuniwak と一般エンジニア へんてこ が、約5か月・20エピソードを続けてこられた理由を「準備しすぎない」「気負わない」「間違えたら謝る」の3つで振り返ります。 前半は Spotify・Apple Podcasts・YouTube のアナリティクスを…
-
#20 大きく勝つより"負けない"——リスク嫌いエンジニアのライフプラン自作
September 3, 2026 · 46 minライフプランシミュレーターを自作すると何がわかるのか? スーパーエンジニア kuniwak が、Googleスプレッドシート製の家計シミュレーションを Go + Makefile + TSV のパイプラインに作り直し、AI(Claude Code)と一緒に約3万通りの人生シナリオを計算した話です。持ち家 vs 賃貸、老後資金、インフレ率、金融危機……「自分の場合はどうなるのか」を検算し続けた結果、行き着いたのは「大きく勝つより負けない」…
Show 7 more episodesShow fewer episodes
-
#19 printfデバッグしたら"負け"——デバッグは設計で決まる
August 27, 2026 · 41 minprintfデバッグやステップ実行に頼るデバッグは「負け」——その心は、デバッグのしやすさ(デバッガビリティ)はデバッグ手法ではなく設計で決まるから。今回はスーパーエンジニアのkuniwakに、一般エンジニアのへんてこが「熟練者と初学者で差が出るデバッグのやり方」を聞きました。 printfを仕込んで消すその場しのぎの確認ではなく、まず再現テストを書く。バグが出るのはアルゴリズムとドメイン知識が混ざった「もやっとした場所」だから、ソー…
-
#18 「仕事しない同僚」にイライラしたら——他人はコントロールできない
August 20, 2026 · 36 min仕事しない同僚や部下にイライラしてモチベーションが下がる——そんなとき、どう対処すればいいのか?今回のくわラジは、エンジニアの職場あるあるでもある「働かない人へのフラストレーション」との向き合い方を深掘りします。 「他人の仕事は他人の仕事と割り切る」というkuniwakに、へんてこが「でもサボりを見逃してない?」と食い下がるところから、話は性善説と性悪説の使い分け、採用の失敗と人事評価の構造、そして「人はコントロールできない」という核…
-
#17 AI時代にまさかのVim回帰—-CLI/TUIの時代へ
August 13, 2026 · 48 minAIコーディングエージェント全盛のいま、なぜあえてVimに戻るのか?Claude Codeを使い込んだ先に待っていたのは、まさかのVim回帰とCLI/TUI時代の到来でした。スーパーエンジニアkuniwakの約15年にわたる開発環境の変遷を一気にたどります。 Perlの会社で素朴にVimを使っていた新人時代、クラッシュ多発のXcodeからJetBrains AppCodeに逃げ込んだiOS開発時代、「どの言語でもIDEがある」JetB…
-
#16 巨大な仕様書を"読ませたら"負けーーSSoTから生成する「読む人専用ビュー」
August 6, 2026 · 41 min巨大な仕様書を全員に「読ませる」運用は、もう負けかもしれません。今回のテーマはSSoT(Single Source of Truth=信頼できる唯一の情報源)。信頼できる唯一の仕様書を一つだけ管理し、そこからCS担当者向け・パートナー企業向けなど、読む人ごとに最適化された「専用ビュー」を自動生成するという仕様書運用の考え方を深掘りします。 スーパーエンジニアのkuniwakが、巨大なシーケンス図・状態遷移図から必要な部分だけを畳んで見せる仕組みや、GitHub…
-
#15 LLMに漠然と探させるな——「意味の構造」にフォーカスさせる検査ツール
July 31, 2026 · 41 minLLM(AI)にシーケンス図や設計のレビューを任せたら、なぜ見逃しだらけになるのか?答えは「漠然と探させている」から。ルールベースの検査ツールで怪しい箇所を列挙し、LLMの注意を「意味の構造」にフォーカスさせると、検出精度がほぼ100%まで上がる——そんな検査ツールの作り方を深掘りする回です。 スーパーエンジニアのkuniwakが開発中の、仕様と実装設計を検査するツールの裏側を一般エンジニアのへんてこが根掘り葉掘り聞いていきます。…
-
#14 "正しく作る"より"正しいものを作る"——一番大事なのは妥当性
July 16, 2026 · 34 minソフトウェアの検証には「正当性検証(Verification)=正しく作っているか」と「妥当性検証(Validation)=正しいものを作っているか」の2種類があります。 単体テストやE2Eテスト、CIで確かめられるのはどっち?ユーザビリティや性能要件のような白黒つかない品質はどう検証する?今回はプロダクト検証の全体像を、スーパーエンジニアのkuniwakがへんてこの質問に答えながら解きほぐします。 仕様どおり完璧に実装しても「解き…
-
#13 一流がすげーと思う人こそ"超一流"
July 9, 2026 · 38 min超一流のエンジニアとはどんな人なのか?スーパーエンジニアのkuniwakが、これまでのキャリアで出会った「この人すげー」と心から思ったエンジニア・上司・役員を語り尽くす回です。 新卒で入ったミクシィ時代の同期・kubo39さんから教わったmalloc(jemalloc)やスタックとヒープといった低レイヤーの世界、Redisのforkとコピーオンライトを使ったスナップショットの「美しさ」。 前職では、あえて失敗させてくれた上司と、単体テ…