くわラジ

ミソラボ

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

  1. 2d ago

    #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/pLIjwXXqGW4 Web: https://kuwa-raji.henteko07.com/ X: https://x.com/kuwa_raji

  2. Jul 31

    #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/qK9uNFp9RjY Web: https://kuwa-raji.henteko07.com/ X: https://x.com/kuwa_raji

  3. Jul 16

    #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/Y6qt5YThwpE Web: https://kuwa-raji.henteko07.com/ X: https://x.com/kuwa_raji

  4. Jul 9

    #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で、匿名のお便りは公式サイトのフォームからお待ちしています。

  5. Jul 2

    #12 フレームワークは"補助輪"、加速装置じゃない

    バニラなら一瞬でできるのに、フレームワークに載せた途端に難しくなる——そんな経験、ありませんか？ 今回はkuniwakの「フレームワークは補助輪であって加速装置じゃない」という一言を軸に、規格を決める側と決められる側、アップデート追従や依存の増加がなぜビジネスの速度を削るのかを深掘りしていきます。 TypeScriptだけは別格な理由や、C言語・Rust・Goの立ち位置まで脱線しつつ、最後の「エンジンはお前自身なんだ」という締めがじんわり効いてくる回です。

  6. Jun 25

    #11 ループエンジニアリングは「マイニング」だ——AIがつくる格差の話

    最近流行りのループエンジニアリング。 狭い入力から広い実装が乱数で生まれるその仕組みを突き詰めると、なぜか「ビットコインの採掘」にそっくりだった——。 試行回数が多い者、つまり資本を持つ者が勝続ける世界はちょっと面白くない。じゃあAI税で再分配できるのか？へんてこの素朴な疑問にkuniwakが応えながら、面白い未来と面白くない未来の分かれ道を探ります。 AIで仕事や社会がどう変わるか、モモヤしている人にこそ聞いてほしい回。 Claude Fable 5に作ってもらった日本語プログラミング入門教材「言語の庭」が凄い - https://zenn.dev/nextbeat/articles/2026-06-cs-edu-site-fable5

  7. Jun 18

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

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

  8. Jun 11

    #9 仕様を疑え。AI時代のプロフェッショナリズム論

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

See All (16)

About

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

Information

  • Creator
    ミソラボ
  • Years Active
    2026
  • Episodes
    16
  • Rating
    Clean
  • Copyright
    © ミソラボ
  • Show Website
    くわラジ

You Might Also Like