スーパーエンジニアであるkuniwakに一般エンジニアであるへんてこが技術的な質問をしながら深掘り噛み砕いていく、ゆるくてディープな技術雑談番組です。
https://kuwa-raji.henteko07.com/
番組の魅力・推薦
#19 printfデバッグしたら"負け"——デバッグは設計で決まる
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/D4bOru9qBEYWeb: https://kuwa-raji.henteko07.com/X: https://x.com/kuwa_raji
#18 「仕事しない同僚」にイライラしたら——他人はコントロールできない
仕事しない同僚や部下にイライラしてモチベーションが下がる——そんなとき、どう対処すればいいのか？今回のくわラジは、エンジニアの職場あるあるでもある「働かない人へのフラストレーション」との向き合い方を深掘りします。「他人の仕事は他人の仕事と割り切る」というkuniwakに、へんてこが「でもサボりを見逃してない？」と食い下がるところから、話は性善説と性悪説の使い分け、採用の失敗と人事評価の構造、そして「人はコントロールできない」という核心のメンタルモデルへ。後半は上司との1on1で「期待に添えてますか？」と役割を確認する習慣や、オープンクエスチョンではなく案を持って提案するコミュニケーション術など、明日から使える実践的な話が続きます。イライラの正体が「見積もりの甘さ」と「情報の非対称性」にあるという分析は必聴です。▼この回で話していること・仕事しない同僚にイライラするのはなぜ？モチベーションが下がる構造・自分の実力とチームの実力を切り離す考え方・フラストレーションの正体は「見積もりの甘さ」と「情報の非対称性」・性善説と性悪説の使い分け——現場は性善説、評価・採用制度は性悪説・「人はコントロールできない」——選択肢を提示して相手に委ねるメンタルモデル・上司との1on1で「期待に添えてますか？」と役割を確認する習慣・オープンクエスチョンで聞かない——A案B案C案を持って提案する・「信頼はするが期待はしない」——リーダーの心の守り方▼こんな人におすすめ・仕事しない同僚・部下へのイライラで消耗しているエンジニア・チームの成果と自分のモチベーションの折り合いに悩んでいる人・1on1やマネジメントでの役割・期待のすり合わせ方を知りたい人くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアのkuniwakに一般エンジニアのへんてこが「もっと詳しく教えてください」と質問しながら技術やエンジニアの仕事を深掘りする、ゆるくてディープな技術雑談番組です。─────────────YouTube: https://youtu.be/m04Ly5IYq-oWeb: https://kuwa-raji.henteko07.com/X: https://x.com/kuwa_raji
#17 AI時代にまさかのVim回帰—-CLI/TUIの時代へ
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-_B9dpa4Web: https://kuwa-raji.henteko07.com/X: https://x.com/kuwa_raji
#16 巨大な仕様書を"読ませたら"負けーーSSoTから生成する「読む人専用ビュー」
巨大な仕様書を全員に「読ませる」運用は、もう負けかもしれません。今回のテーマは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/pLIjwXXqGW4Web: https://kuwa-raji.henteko07.com/X: https://x.com/kuwa_raji
#15 LLMに漠然と探させるな——「意味の構造」にフォーカスさせる検査ツール
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/qK9uNFp9RjYWeb: https://kuwa-raji.henteko07.com/X: https://x.com/kuwa_raji
#14 "正しく作る"より"正しいものを作る"——一番大事なのは妥当性
ソフトウェアの検証には「正当性検証（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/Y6qt5YThwpEWeb: https://kuwa-raji.henteko07.com/X: https://x.com/kuwa_raji
#13 一流がすげーと思う人こそ"超一流"
超一流のエンジニアとはどんな人なのか？スーパーエンジニアの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で、匿名のお便りは公式サイトのフォームからお待ちしています。
#12 フレームワークは"補助輪"、加速装置じゃない
バニラなら一瞬でできるのに、フレームワークに載せた途端に難しくなる——そんな経験、ありませんか？今回はkuniwakの「フレームワークは補助輪であって加速装置じゃない」という一言を軸に、規格を決める側と決められる側、アップデート追従や依存の増加がなぜビジネスの速度を削るのかを深掘りしていきます。TypeScriptだけは別格な理由や、C言語・Rust・Goの立ち位置まで脱線しつつ、最後の「エンジンはお前自身なんだ」という締めがじんわり効いてくる回です。
#11 ループエンジニアリングは「マイニング」だ——AIがつくる格差の話
最近流行りのループエンジニアリング。狭い入力から広い実装が乱数で生まれるその仕組みを突き詰めると、なぜか「ビットコインの採掘」にそっくりだった——。試行回数が多い者、つまり資本を持つ者が勝続ける世界はちょっと面白くない。じゃあAI税で再分配できるのか？へんてこの素朴な疑問にkuniwakが応えながら、面白い未来と面白くない未来の分かれ道を探ります。AIで仕事や社会がどう変わるか、モモヤしている人にこそ聞いてほしい回。Claude Fable 5に作ってもらった日本語プログラミング入門教材「言語の庭」が凄い - https://zenn.dev/nextbeat/articles/2026-06-cs-edu-site-fable5
#10 転職は「ゲーム」だ。スーパーエンジニアの転職攻略
転職先選びを、kuniwakは「マップ上のいい点を見つけて、そこに登っていくゲーム」だと言います。譲れない軸を数字に落とし込み、質問はテンプレ化、回答がそのまま>スコアになる仕組みまで設計。一方で50社分の面接時間をどう捻出するかは地獄で、ネカフェ面接の日々まで……。さらに「市場価値を一次元の数字に丸めるのは本質を見失ってる」という持論も。ゆるくてディープな転職回です。
#9 仕様を疑え。AI時代のプロフェッショナリズム論
「言われた仕様を満たす実装を作ったのに、問題は解決しなかった」——心当たり、ありませんか？ 今回はエンジニアのプロフェッショナリズムについて、kuniwak とへんてこがじっくり語ります。XY問題、顧客は本当に欲しいものを喋らない話、AIによって解を探すコストが激減した現実、それでも残る「問題を精密に言語化する」という人間の仕事。さらに後半は「プロ意識がない人はダメなのか？」という問いに、kuniwak が意外な答えを返します。働き方や評価に悩むエンジニアにこそ聞いてほしい回です。
#8 学び続ける人は、まず疑う。kuniwak流インプット術
新しいことって、どうやって学び続けてますか？ 今回は kuniwak のインプットの流儀がテーマです。ChatGPTに論文を読ませて自分の組織を「意思決定モデル」として捉え直した話から始まり、行き着いたのが「批判的精神を持つこと」と「前提を確かめること」。誰かの改善案や正論を鵜呑みにしないための土台の話です。学びのアップデートに悩むエンジニアにこそ聞いてほしい一本です。ユーザビリティエンジニアリング原論: https://amzn.to/4dUM32Nソフトウェア仕様記述の先進技法-Z言語: https://amzn.to/4dVGe3B
#7 正論は、出禁になる。スーパーエンジニアの失敗談
今回はちょっと趣向を変えて「失敗した話」がテーマです。インシデント続きのチームの再発防止ミーティングに送り込まれ、まっすぐ正論をぶつけたら…まさかの「出禁」。いったい何が地雷だったのか。そして後日、同じことを別の人が言ったらすんなり通った理由とは？「何を言うか」より「どう伝えるか」、そして信頼の話。チャレンジには失敗がつきものだと知っているエンジニアにこそ聞いてほしい一本です。
#6 プロマネってもしかして経営者では？
プロジェクトの後半になるとなぜか「ぐだぐだ」になる現象、ありますよね。最近PMOになったkuniwakに、その正体と対処法を聞いていく回です。見積もりは1点じゃなく楽観と悲観の2点で出す話、QCDのどこを動かすかは「経営判断」だという話、プロジェクトの賞味期限切れを防ぐ4つの打ち手まで。話を聞いているうちに「これもう経営者の仕事では？」と思わずツッコんでしまいました。計画の立て方を学び直したいエンジニアはぜひお聞きください。
#5 「フォーム空でボタン押した時どうなる？」は仕様書の問題
プロダクト開発でPdMに「これどうなるんですか？」って聞いたら答えが返ってこなくて、適当に実装したら「違う」と言われた経験ってありませんか？へんてこの素朴なあるある相談から、kuniwakが「実はそれ、コミュニケーションじゃなくて仕様書の問題」と切り込みます。そもそも仕様書って何のためにある？よい仕様の正体って？正解と不正解の境界を引くものとしての仕様、そして「ほぼ疑似コード」になる理由を、ゆるくディープに解きほぐします。仕様書まわりにモヤモヤがある人にぜひ。
#4 MVVMもクリーンアーキテクチャもあくまで「流派」。設計で本当に大事なこと
ソフトウェア設計って普通に難しくないですか？MVVM、MVC、クリーンアーキテクチャ…新しい流派が出るたびに右往左往してしまう。でもkuniwakによれば、流派は実はどうでもいい。大事なのは「流派の上にどう城を建てるか」だと言います。クリーンアーキテクチャ＝玉ねぎの図であると思っていた人にも刺さる話になっています。自分の設計に自身が持てないエンジニアにこそ聞いてほしい回です。Clean Architecture 達人に学ぶソフトウェアの構造と設計 - https://amzn.to/4tpCH3x
#3 バグを"一番早く"見つけるためのテスト戦略
「テストってどこまでやれば安心できるんでしょう？」というへんてこの素朴な疑問から、kuniwakが語るのは"多層防御"の発想。Lint・単体・結合・E2E、それぞれの層には「ここで見つけるべきバグ」がある。本来Lintで弾けるはずのバグを単体テストで頑張って見つけようとすると、なぜ損するのか。ODC分析というバグの振り返り手法から、E2Eテストファースト、AI時代のゴールデンテストまで、ゆるくディープに掘り下げます。テスト戦略に悩むエンジニアの方は必聴です。
#2 モックが辛いのは「コードの悲鳴」だった
単体テストでモックをどこまで書けばいいのか、毎回迷いませんか？ へんてこの素朴な悩みに、kuniwakが投げかけたのは「モックが多いのは設計のスメル（臭い）」という一言。間接入出力、サイクロマティック複雑度、オープン・クローズド原則、技術的負債――テストの話から始まって、いつの間にかエンジニアのビジネス感覚にまで話が広がっていく回。設計に悩むすべてのエンジニアにおすすめです。レガシーコード改善ガイド - https://amzn.to/3OzCmwI
#1 Lintはメンタルに効く！？
「Lintはメンタルに効きます！」適当なコードを書くと絶対に怒ってくるあの「Lint」について、kuniwakに聞いてみました。すると意外な答えが！？「Lint」が何者で、どんな目的があるのかわからない人は必聴です。チームに「Lint」を導入するときの目的がはっきりとわかるようになると思います。
こちらもおすすめ
近藤淳也のアンノウンラジオ
株式会社はてな創業者であり現在もITの第一線で働く近藤淳也が、京都の宿UNKNOWN KYOTOにやって来る「好きなことを仕事にしている人」を深堀りすることで、世の中の多様な仕事やキャリア、生き方・働き方を「リアルな実例」として紐解いていきます。 . 【ホスト：近藤淳也】 株式会社OND代表取締役社長、株式会社はてな取締役、UNKNOWN KYOTO支配人、NPO法人滋賀一周トレイル代表理事、トレイルランナー。 2001年に「はてなブログ」「はてなブックマーク」などを運営する株式会社はてなを創業、2011年にマザーズにて上場。その後2017年に株式会社ONDを設立し、現在もITの第一線で働く。 株式会社OND: https://ond-inc.com/ . 【UNKNOWN KYOTO】 築100年を超える元遊郭建築を改装し、仕事もできて暮らせる宿に。コワーキングやオフィスを併設することで、宿泊として来られる方と京都を拠点に働く方が交わる場所になっています。 1泊の観光目的の利用だけではなく、中長期滞在される方にも好評いただいています。 web: https://unknown.kyoto/ . こちらから本文を読んだりコメントが書けます！ https://listen.style/p/unknownradio
八百万のOSS
毎回1つまたは複数のOSSを取り上げて、それについてエンジニアであるcatatsuyとへんてこで技術的なところも深掘りながら話をしていく番組です。 https://yaoyorozu-oss.henteko07.com/
桃山商事
コミュニケーション、男性性、恋愛、人間関係、ジェンダー、ケア、孤独、性欲、会社、友情、老い……メンバーがその時々で気になったテーマを１つ設定して、モヤモヤを言語化していくNEOな座談Podcastです。2011〜2016年「二軍ラジオ」(ApplePodcast)、2017〜2024年「恋愛よももやまばなし」(ニコ生→Podcast)を配信していました。清田隆之(文筆業)、森田(会社員)、ワッコ(会社員)、さとう(会社員)の４人でお届けします。
jkondoの朝の散歩
ポッドキャストプラットフォーム「LISTEN」や、GPSトラッキングサービス「IBUKI」、物件メディア「物件ファン」、京都の宿とコワーキング施設「UNKNOWN KYOTO」を運営する近藤淳也（jkondo）が、朝の散歩をしたりしながら、日々の出来事や考えたことを語ります。
IBUKI STATION
ここはアウトドア向けGPSトラッキング「IBUKI」にまつわる人々が集まる場所。 トレイルラン、登山、冒険、ランニング、自転車、ロゲイニング、、 スタイルは数あれど、共通しているのは自然を楽しみ、そして人とのつながりも楽しむ姿勢。 自然を目一杯楽しみ、苦しみながら、人と接する喜びにも気付く。 アウトドアを満喫するみなさんが、ほっとできるIBUKI STATIONです。 IBUKI https://ibuki.run/ 近藤淳也 IBUKIを提供する株式会社OND代表。ポッドキャストプラットフォーム「LISTEN」も展開 桑原佑輔 OND所属。IBUKI事業担当営業・テクニカルディレクター 中川和美 OND所属。IBUKI担当。トレイルランナー
OSSのレキシラジオ
エンジニアであるへんてこが毎週1つのOSSプロジェクトを取り上げてそのプロジェクトの歴史を紹介する番組です