Shows / くわラジ
くわラジ
スーパーエンジニアであるkuniwakに一般エンジニアであるへんてこが技術的な質問をしながら深掘り噛み砕いていく、ゆるくてディープな技術雑談番組です。 https://kuwa-raji.henteko07.com/
Episodes
- くわラジ
#27 形式手法ってなに？——"数学で仕様を書く"ただの道具の話
形式手法（フォーマルメソッド）とは何か？ 日本語で書いた仕様書はなぜ「顧客が本当に欲しかったもの」とズレるのか——数学を土台に仕様を書き、解釈のブレをなくすという形式手法の考え方を、入門としてざっくり解説する回です。 「形式手法がまったく分かってない」と言うへんてこに、kuniwak…
- くわラジ
#26 E2Eテストに全振りするな——AI時代こそ"テスト戦略"は人間の仕事
「AIがコードを書くなら、テストはE2Eテストに全部寄せればいいのでは？」──Xで話題になったE2Eテスト全振り論に、kuniwak が真っ向から反論します。E2Eテストは単体テストの"上位互換"なのに、なぜ全部をE2Eにしてはいけないのか。テスト戦略とは何かを、AI時代の視点から掘り下げる回です。…
- くわラジ
#25 "わからないまま保留する"力——「わかってる」より「できる」で判断しよう
「わかっている」とはどういう状態なのか？ 自分の理解度はどう測ればいいのか？ 今回は「わからない」という感覚をテーマに、理解の基準、わからないと認められない心理、そして答えを急がず"わからないまま保留する"力について、へんてこ が kuniwak に聞いてみました。 kuniwak…
- くわラジ
#24 "AIに書けない"コーン茶レビュー——vim-jp Slackで届いたリクエストに答えてみた
コーン茶（とうもろこし茶）って、なぜコーヒーの代わりになるの？ vim-jp の Slack で「AI に書けないようなことをぜひ語ってほしい」とリクエストをもらった kuniwak のコーン茶レビューを入り口に、エンジニアの「プログラミングのお供」をへんてこ が根掘り葉掘り聞いてみました。 コーヒー好きの…
- くわラジ
#23 発表は"3割"しか伝わらない——コードレビュー廃止ネタを一般化してみた
登壇ネタの「一般化」って、具体的にどうやるの？ 前回「発表ネタで一番大事なのは一般化」と語った kuniwak に、へんてこ が自分の実ネタ「チームで人間のコードレビューを全廃して半年、大きな事故なし」を持ち込み、登壇できる形に一般化するまでを公開添削してもらいました。 AI…
- くわラジ
#22 一番大事なのは"一般化"——登壇50回で分かった発表ネタの作り方
勉強会やカンファレンスで登壇し続けるには、発表ネタをどう作ればいいのか？ 登壇回数50回超、年に4〜5回のペースで発表を続けるスーパーエンジニア kuniwak に、一般エンジニア へんてこ…
- くわラジ
#21 気負わない・準備しすぎない——21回続いたポッドキャストの裏側
ポッドキャストを続けるコツとは何か？ 「9割の番組は3話で止まり、残った番組の9割も20話までに止まる」と言われるほとんどのポッドキャストが21回目を迎えられない中、くわラジは今回で第21回。スーパーエンジニア kuniwak と一般エンジニア へんてこ…
- くわラジ
#20 大きく勝つより"負けない"——リスク嫌いエンジニアのライフプラン自作
ライフプランシミュレーターを自作すると何がわかるのか？ スーパーエンジニア kuniwak が、Googleスプレッドシート製の家計シミュレーションを Go + Makefile + TSV のパイプラインに作り直し、AI（Claude Code）と一緒に約3万通りの人生シナリオを計算した話です。持ち家 vs…
- くわラジ
#19 printfデバッグしたら"負け"——デバッグは設計で決まる
printfデバッグやステップ実行に頼るデバッグは「負け」——その心は、デバッグのしやすさ（デバッガビリティ）はデバッグ手法ではなく設計で決まるから。今回はスーパーエンジニアのkuniwakに、一般エンジニアのへんてこが「熟練者と初学者で差が出るデバッグのやり方」を聞きました。…
- くわラジ
#18 「仕事しない同僚」にイライラしたら——他人はコントロールできない
仕事しない同僚や部下にイライラしてモチベーションが下がる——そんなとき、どう対処すればいいのか？今回のくわラジは、エンジニアの職場あるあるでもある「働かない人へのフラストレーション」との向き合い方を深掘りします。…
- くわラジ
#17 AI時代にまさかのVim回帰—-CLI/TUIの時代へ
AIコーディングエージェント全盛のいま、なぜあえてVimに戻るのか？Claude Codeを使い込んだ先に待っていたのは、まさかのVim回帰とCLI/TUI時代の到来でした。スーパーエンジニアkuniwakの約15年にわたる開発環境の変遷を一気にたどります。…
- くわラジ
#16 巨大な仕様書を"読ませたら"負けーーSSoTから生成する「読む人専用ビュー」
巨大な仕様書を全員に「読ませる」運用は、もう負けかもしれません。今回のテーマはSSoT（Single Source of…
- くわラジ
#15 LLMに漠然と探させるな——「意味の構造」にフォーカスさせる検査ツール
LLM（AI）にシーケンス図や設計のレビューを任せたら、なぜ見逃しだらけになるのか？答えは「漠然と探させている」から。ルールベースの検査ツールで怪しい箇所を列挙し、LLMの注意を「意味の構造」にフォーカスさせると、検出精度がほぼ100%まで上がる——そんな検査ツールの作り方を深掘りする回です。…
- くわラジ
#14 "正しく作る"より"正しいものを作る"——一番大事なのは妥当性
ソフトウェアの検証には「正当性検証（Verification）＝正しく作っているか」と「妥当性検証（Validation）＝正しいものを作っているか」の2種類があります。…
- くわラジ
#13 一流がすげーと思う人こそ"超一流"
超一流のエンジニアとはどんな人なのか？スーパーエンジニアのkuniwakが、これまでのキャリアで出会った「この人すげー」と心から思ったエンジニア・上司・役員を語り尽くす回です。…
- くわラジ
#12 フレームワークは"補助輪"、加速装置じゃない
バニラなら一瞬でできるのに、フレームワークに載せた途端に難しくなる——そんな経験、ありませんか？ 今回はkuniwakの「フレームワークは補助輪であって加速装置じゃない」という一言を軸に、規格を決める側と決められる側、アップデート追従や依存の増加がなぜビジネスの速度を削るのかを深掘りしていきます。…
- くわラジ
#11 ループエンジニアリングは「マイニング」だ——AIがつくる格差の話
最近流行りのループエンジニアリング。 狭い入力から広い実装が乱数で生まれるその仕組みを突き詰めると、なぜか「ビットコインの採掘」にそっくりだった——。…
- くわラジ
#10 転職は「ゲーム」だ。スーパーエンジニアの転職攻略
転職先選びを、kuniwakは「マップ上のいい点を見つけて、そこに登っていくゲーム」だと言います。 譲れない軸を数字に落とし込み、質問はテンプレ化、回答がそのまま>スコアになる仕組みまで設計。一方で50社分の面接時間をどう捻出するかは地獄で、ネカフェ面接の日々まで……。…
- くわラジ
#9 仕様を疑え。AI時代のプロフェッショナリズム論
「言われた仕様を満たす実装を作ったのに、問題は解決しなかった」——心当たり、ありませんか？ 今回はエンジニアのプロフェッショナリズムについて、kuniwak…
- くわラジ
#8 学び続ける人は、まず疑う。kuniwak流インプット術
新しいことって、どうやって学び続けてますか？ 今回は kuniwak のインプットの流儀がテーマです。 ChatGPTに論文を読ませて自分の組織を「意思決定モデル」として捉え直した話から始まり、行き着いたのが「批判的精神を持つこと」と「前提を確かめること」。 誰かの改善案や正論を鵜呑みにしないための土台の話です。…
- くわラジ
#7 正論は、出禁になる。スーパーエンジニアの失敗談
今回はちょっと趣向を変えて「失敗した話」がテーマです。 インシデント続きのチームの再発防止ミーティングに送り込まれ、まっすぐ正論をぶつけたら…まさかの「出禁」。いったい何が地雷だったのか。そして後日、同じことを別の人が言ったらすんなり通った理由とは？「何を言うか」より「どう伝えるか」、そして信頼の話。…
- くわラジ
#6 プロマネってもしかして経営者では？
プロジェクトの後半になるとなぜか「ぐだぐだ」になる現象、ありますよね。 最近PMOになったkuniwakに、その正体と対処法を聞いていく回です。見積もりは1点じゃなく楽観と悲観の2点で出す話、QCDのどこを動かすかは「経営判断」だという話、プロジェクトの賞味期限切れを防ぐ4つの打ち手まで。…
- くわラジ
#5 「フォーム空でボタン押した時どうなる？」は仕様書の問題
プロダクト開発でPdMに「これどうなるんですか？」って聞いたら答えが返ってこなくて、適当に実装したら「違う」と言われた経験ってありませんか？ へんてこの素朴なあるある相談から、kuniwakが「実はそれ、コミュニケーションじゃなくて仕様書の問題」と切り込みます。 そもそも仕様書って何のためにある？よい仕様の正体って？…
- くわラジ
#4 MVVMもクリーンアーキテクチャもあくまで「流派」。設計で本当に大事なこと
ソフトウェア設計って普通に難しくないですか？MVVM、MVC、クリーンアーキテクチャ…新しい流派が出るたびに右往左往してしまう。 でもkuniwakによれば、流派は実はどうでもいい。大事なのは「流派の上にどう城を建てるか」だと言います。…
- くわラジ
#3 バグを"一番早く"見つけるためのテスト戦略
「テストってどこまでやれば安心できるんでしょう？」というへんてこの素朴な疑問から、kuniwakが語るのは"多層防御"の発想。 Lint・単体・結合・E2E、それぞれの層には「ここで見つけるべきバグ」がある。本来Lintで弾けるはずのバグを単体テストで頑張って見つけようとすると、なぜ損するのか。…
- くわラジ
#2 モックが辛いのは「コードの悲鳴」だった
単体テストでモックをどこまで書けばいいのか、毎回迷いませんか？ へんてこの素朴な悩みに、kuniwakが投げかけたのは「モックが多いのは設計のスメル（臭い）」という一言。…
- くわラジ
#1 Lintはメンタルに効く！？
「Lintはメンタルに効きます！」 適当なコードを書くと絶対に怒ってくるあの「Lint」について、kuniwakに聞いてみました。すると意外な答えが！？ 「Lint」が何者で、どんな目的があるのかわからない人は必聴です。チームに「Lint」を導入するときの目的がはっきりとわかるようになると思います。