輪読会スタイルで技術Podcastを聴く会を開催してみた

エンジニア組織

松崎令

2026年04月10日

技術系Podcastを「輪読会スタイル」で楽しく聴こう！

お世話になります！株式会社メンバーズ・デブオプスリードカンパニーの松崎です。

弊社にはPodcast好きが集まっており、例に漏れず私もPodcastが好きです。最近は弊社からもイドバタラジオ（技術や組織、キャリアについて語るポッドキャスト）が配信されておりまして、とても素晴らしい活動だと思っています。是非聞いてください！

ところで、私は「準備のいらない勉強会」を開催するのが好きです。今回は「Podcastをみんなで聴く」つまり「輪読会のラジオ版」をやってみようという実験を行いました。有名な技術系Podcast fukabori.fm をピックアップし4回ほど開催したので、そのまとめをお届けします。

fukabori.fm について

fukabori.fm は幅広いテーマを取り扱いながらも、深く掘り下げる歴史ある技術Podcastです。学びが多い一方で、内容が濃厚なために「一人で聴いても分からなかった……」と感じてしまうこともあります。これを複数人でリアルタイムに補完し合いながら聴くことで、学習のハードルを下げ、より深い理解が得られるのではないかと考えました。

ラジオ輪読会のやり方

今回の実験では、Google Meetなどで音声を共有しながら、Notion上でリアルタイムにメモを取るスタイルを採用しました。

同時メモ：4人で開催した今回は、Notionの1ページを4つのペインに分割し、それぞれが思ったことを自由に書き殴っていきました。
感想戦：聴き終わった後、全員で感想を述べ合う時間を設けています。
時間配分：再生速度を少し早めることで、感想戦の尺を大きくできるように調整して約1時間で完結するように設計しました。

↓ラジオ輪読会の様子

実際に輪読会スタイルで視聴した、Fukabori.fmの4つのエピソードからの学びを共有します。

Case 01：リモートワークにおけるファシリテーション

エピソード：ep77 前編 / ep78 後編（株式会社コパイロツトゲスト回）

(ep77) リモートワークにおけるファシリテーション（前編）

エンジニアリングではなく、プロジェクト運営の支援を行っている「株式会社コパイロツト」さんが登場している回です。「リモートワークにおける」という文脈はコロナ禍においてかなり注目を浴びたフレーズだと思います。

このラジオを聴いた4人も基本的にリモートワークを行なっており、業務でも会議体をやることが多々あります。各々課題感を感じることもあり、同時に聴くテーマとしてかなり良かった（はず）です。

人を集めるMTGはどのような分類ができるか？本当に価値があるMTGはどのような類か？MTGのファシリテーションや議事録は誰が担当すべきか？オンラインだからこそのメリットは何か？といったことが詰まった良い回だと思いました。

内容のまとめ
- ファシリテーションを特定の誰かがやっている状態は無理がある
- 全員がファシリテーションをできる状態であることが望ましい
- 議事録も同様で、全員でやってしまえる状態が良い
- MTGを開催するとき、ある程度のゴールを決めておくことが望ましい（例：「xxについでのアイデアを集める」など）
- 合意形成はそもそもハードルが高いので、全てをMTGで決めることは難しい
- しかし「共有する」目的のMTGはなるべく無くしていきたいよね
- MTG中に「反対意見を集めたい」ようなケースはリモートの方がやりやすい（何でも良いので、違和感を1つ “書いてください” とするなど）

(ep78) プロジェクトスプリント（後編）w/ motoi, kedamatti

このポッドキャストは、ひとつ前の「(ep77)リモートワークにおけるファシリテーション（前編）」の後編として公開され、株式会社コパイロツトさん独自のプロジェクト推進メソッド「Project Sprint」に焦点を当てた回でした。

Project Sprintとは、従来のプロジェクトマネジメント（PMBOK）の制定から時間が経過し、プロジェクトのあり方が変わった現代において、「当たり前のことを組み合わせた」フレームワークとして考案されたものです。（※ちなみに、PMBOKは2021年に第7版が発行され、アジャイルな考え方が包括的に取り込まれています。）

輪聴会参加者からは、プロジェクトを成功させるには、メンバー間の信頼関係が基盤となること、そして、定例会議を単なる報告（伝達）で終わらせずに共同でアイデアを創造し、問題解決や意思決定を行うための対話の場として設計することが重要であるとの意見が共有されました。 OSSとして公開されており、今後のプロジェクト進行を推進するためのヒントが多く得られる会となりました。

内容のまとめ
- フレームワークの核: 「定例会議」の設計にある。PMの一元管理から脱却し、定期的な集まりを通じてプロジェクトの状況に応じた柔軟な意思決定を重視する。
- 自律的な仕組み: 何を話しても良い「場」を設けることで、メンバーの自律的な行動や継続的な改善を促す。
- 設計の工夫: 会議体をAPIに見立ててインプットとアウトプットを整理し、目的（情報共有、創造、決定など）と人数に応じて分類・設計する。
- テンショントリアージ: ホラクラシーの概念を取り入れ、プロジェクト内の「歪み」（テンション）を表明し、解決に繋げる。
- 参加者の意見: プロジェクト成功には信頼関係が基盤となること、定例を単なる報告で終わらせず、共同でアイデアを創造する対話の場として設計する重要性が共有されました。

Case 02：技術の教え方・技術研修

エピソード：ep84（kakakakakkuさんゲスト回）

我々技術教育チームのテーマと親和性の高そうな回であることがテーマから読み取れたため聴講を決めました。インストラクターのかっくさんをゲストに迎え、「技術をどう教えるか」をテーマに、大人の学習（成人教育）の特性や、効果的な研修を設計・実践するテクニックについて深掘りしています。

内容のまとめ
- 成人教育と経験学習: 大人は主体性を持ち、自身の経験とリンクさせながら、目の前の課題解決のために学ぶ傾向がある。
- 研修設計の考え方: 「知識」「体験」「思考」を組み合わせる。事前にインプットを済ませ本番はアウトプット中心にする「反転学習」や、受講者のレベルに合わせた専門用語の調整（ストーリー設計）が有効。
- 実践テクニック: 心理的安全性を高めるため、リアクションを歓迎しYes/Noで答えられる質問から始める。オンラインでは適度な休憩と、講義・演習・クイズなどの「アトラクション」を織り交ぜて集中力を維持する。
- 客観的モニタリング: 受講者と同じ条件の端末を別途用意し、配信クオリティを常にチェックする。
- 講師の強み: 豊富な実務経験に基づく納得感、継続的なブログ更新による最新知識、そして「予定通りに進めない」ことを厭わない現場の空気に合わせた柔軟な対応。

Case 03：メモリとパケットにはすべてがある

エピソード：ep105（y.kajiuraさんゲスト回）

NTTコミュニケーションズの梶浦さんがゲストの回でした。梶浦さんはIaaSサービスを提供している方で、その中でもSDN（Software Defined Network）を扱っている方になります。

低レイヤを読み解く上でのコツやどういった面白さがあるのかについて詳しく話されています。カーネルを使ってソフトウェアを開発するということがどういうことかイメージできたので、とても面白かったです。

内容のまとめ
- SDNとは: Software Defined Networkの略で、ソフトウェアでネットワークを制御しようとするもの。
- 開発手法: Juniper社のContrail（OSS版：Tungsten Fabric）を使用。新機能追加の際は開発元と協議したり、OSSへ直接コントリビューションすることで課題を解決していく。
- 低レイヤ開発: ソフトウェアのログだけでは解決しない課題に対し、メモリのコアダンプやネットワークパケットを直接読み解くことで解決を図る。
- デバッグ作業: PythonのScapyライブラリを用いてパケットを生成し、実際の挙動を確認する泥臭くも確実な解析手法が紹介された。

参加者の声

ラジオ輪読会の参加者からポジティブな感想をたくさんいただいております！

K.Tさん: ラジオを聞きながらメモを取ることで、聞くだけより中身が頭に入ってきた。自分がわかるように言葉をまとめる練習になった
S.Yさん: 感想戦では一人で聞いている時に気づかなかった視点の話が出て、一人で聞くよりも為になった
R.Kさん：メモという形ではあるが聞いた内容を即時にアウトプットする訓練にもなった。議事録を作成する機会がそこそこあるので実技として役に立っている。単純に fukabori.fmというコンテンツが思いのほか有用なコンテンツだったのでそれを知れたというだけでもプラスになった。
R.Mさん: リアルタイムに人数分のメモが勝手に伸びていったり、相互作用したりするのが見ていて面白かった。fukabori.fm は難易度が高めの回もあるので「ここがわからん！」みたいなモノローグを書いておくと、後で拾ってもらうことができて嬉しかった。