くわラジ

ミソラボ•kuwa-raji.henteko07.com

Technology

スーパーエンジニアであるkuniwakに一般エンジニアであるへんてこが技術的な質問をしながら深掘り噛み砕いていく、ゆるくてディープな技術雑談番組です。 https://kuwa-raji.henteko07.com/

Last refreshed: June 24th, 2026 at 4:01 AM

Follow on

Apple Podcasts

Spotify

RSS

Podcasts are better in Metacast mobile app

Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episodes

#10 転職は「ゲーム」だ。スーパーエンジニアの転職攻略

転職先選びを、kuniwakは「マップ上のいい点を見つけて、そこに登っていくゲーム」だと言います。譲れない軸を数字に落とし込み、質問はテンプレ化、回答がそのまま>スコアになる仕組みまで設計。一方で50社分の面接時間をどう捻出するかは地獄で、ネカフェ面接の日々まで……。さらに「市場価値を一次元の数字に丸めるのは本質を見失ってる」という持論も。ゆるくてディープな転職回です。

Jun 18, 2026•43 min•Season 1Ep. 10

「言われた仕様を満たす実装を作ったのに、問題は解決しなかった」——心当たり、ありませんか？今回はエンジニアのプロフェッショナリズムについて、kuniwak とへんてこがじっくり語ります。XY問題、顧客は本当に欲しいものを喋らない話、AIによって解を探すコストが激減した現実、それでも残る「問題を精密に言語化する」という人間の仕事。さらに後半は「プロ意識がない人はダメなのか？」という問いに、kuniwak が意外な答えを返します。働き方や評価に悩むエンジニアにこそ聞いてほしい回です。

Jun 11, 2026•30 min•Season 1Ep. 9

#8 学び続ける人は、まず疑う。kuniwak流インプット術

新しいことって、どうやって学び続けてますか？今回は kuniwak のインプットの流儀がテーマです。 ChatGPTに論文を読ませて自分の組織を「意思決定モデル」として捉え直した話から始まり、行き着いたのが「批判的精神を持つこと」と「前提を確かめること」。誰かの改善案や正論を鵜呑みにしないための土台の話です。学びのアップデートに悩むエンジニアにこそ聞いてほしい一本です。ユーザビリティエンジニアリング原論: https://amzn.to/4dUM32N ソフトウェア仕様記述の先進技法-Z言語: https://amzn.to/4dVGe3B

Jun 04, 2026•41 min•Season 1Ep. 8

#7 正論は、出禁になる。スーパーエンジニアの失敗談

今回はちょっと趣向を変えて「失敗した話」がテーマです。インシデント続きのチームの再発防止ミーティングに送り込まれ、まっすぐ正論をぶつけたら…まさかの「出禁」。いったい何が地雷だったのか。そして後日、同じことを別の人が言ったらすんなり通った理由とは？「何を言うか」より「どう伝えるか」、そして信頼の話。チャレンジには失敗がつきものだと知っているエンジニアにこそ聞いてほしい一本です。

May 28, 2026•40 min•Season 1Ep. 7

#6 プロマネってもしかして経営者では？

プロジェクトマネジメントにおける進捗の「ぐだぐだ」を防ぐ方法から、品質・コスト・納期（QCD）の経営判断、楽観・悲観の2点見積もりの重要性を解説します。AIを活用したチームマネジメントや、プロセスフロー図（PFD）による計画、プロジェクトの再計画、そして振り返りを通じた組織成長まで、プロジェクトマネージャーの多岐にわたる役割と実践的なアプローチが詳細に語られます。最終的には、アジャイル時代における計画の変わらぬ重要性を強調します。

May 21, 2026•40 min•Season 1Ep. 6

#5 「フォーム空でボタン押した時どうなる？」は仕様書の問題

このエピソードでは、プロダクト開発における多くの問題がコミュニケーションではなく不十分な仕様書に起因すると指摘し、仕様書が正しい振る舞いを定義し、エンジニア、テスター、CS担当者など多様な利用者を導く上でいかに重要かを強調します。仕様書はプロダクトのように進化すべきであり、状態とイベントで表現され、曖昧さを最小限に抑えるために疑似コードに似ているべきだと述べます。プロダクトマネージャーの役割を顧客の代弁者として再定義し、詳細な仕様書はエンジニアが作成する方が適していると提唱。さらに、「仕様アニメーション」やプロパティベースドテスティングといった先進的なアプローチも紹介し、効果的でテスト可能なデザイン作成への道を模索します。

May 14, 2026•44 min•Season 1Ep. 5

#4 MVVMもクリーンアーキテクチャもあくまで「流派」。設計で本当に大事なこと

本エピソードは、ソフトウェア設計の難しさに焦点を当て、MVVMやクリーンアーキテクチャなどの「流派」は手段に過ぎず、真に重要なのは問題に応じた適切なコード分割であると説きます。設計に自信を持つためには、数多くの小さなプロジェクトで挑戦し失敗から学ぶ「嗅覚」を磨くことが不可欠です。さらに、AIコーディングエージェントが普及する中で、人間が明確な未来の情報をAIに伝え、テスト駆動開発などを通じてAIの設計を適切に導くマネジメントの重要性を強調しています。

May 07, 2026•43 min•Season 1Ep. 4

#3 バグを"一番早く"見つけるためのテスト戦略

「どこまでテストすれば安心できるのか」という問いに対し、バグを「一番早く」見つけるための多層防御のテスト戦略を深掘りします。Lintや単体テストで見つけるべきバグをエンドツーエンドテストまで持ち越すことの非効率性を指摘し、ODC分析によるバグ発生段階の特定や、オープンソースのCI/CDから学ぶテスト設計のヒントを提供。さらに、テストピラミッドによる量的バランス、機能要件と非機能要件（UX/性能）のテストの違い、そしてAI時代にテストを人間が意図を伝えるツールとして活用する方法まで、テスト戦略の全体像を網羅的に解説します。

Apr 30, 2026•36 min•Season 1Ep. 3

#2 モックが辛いのは「コードの悲鳴」だった

本エピソードでは、単体テストでモックをどこまで書くべきかという疑問を深掘りし、モックの多さが設計の悪さを示す「スメル」であると指摘します。純粋関数と副作用のある関数の違いから始まり、サイクロマティック複雑度やオープン・クローズド原則を用いて、テスト容易性を高めるためのコンポーネント分割とビジネスの展望を見据えた設計の重要性を解説。レガシーコードの改善や、あえてテストを書かないケースについても議論し、エンジニアのビジネス感覚と技術的負債への向き合い方を提言します。

Apr 23, 2026•35 min•Season 1Ep. 2

#1 Lintはメンタルに効く！？

Lintが「メンタルに効く」という意外な視点から、開発者の自信向上に果たす役割を深掘りします。Lintの起源である「糸くず」の意味から、スタイルチェックだけでなくセキュリティやバグ検出まで多岐にわたる機能、言語仕様との関係、そして将来的なAIやフレームワークへの統合までを網羅。コード以外の仕様書などへの応用事例や、AI活用における課題と解決策についても詳しく解説し、品質保証と開発効率を高めるLintの可能性を探ります。

Apr 17, 2026•38 min•Season 1Ep. 1

Hosted on Spotify for Creators (Anchor)

For the best experience, listen in Metacast app for iOS or Android