Developers Summit 2025 公開資料集めてみた
2/13, 14 と Developers Summit 2025に行ってきた。
参加記録と感想のブログを書いて少しは業界貢献しようと思っているが、その準備がてら、登壇者が早々に（中には登壇前に...すごい）公開していた登壇資料をXを探して収集したので、インデックス代わりに書いておく。
日にちや発表時間枠ごとの整理は主催者である翔泳社さんのサイトであるCodezineで順次公開されると思うので、こちらは独断で作ったカテゴリ別に整理してみる。
組織、マネジメント系
【資料公開】チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング | Ryuzee.com
リアルな過去からたどり着いた事業成長を牽引するエンジニアの在り方 | ドクセル
インフラ
「mixi2の舞台裏」 TiDBで実現するSNSのスケーラビリティとパフォーマンス
インフラをつくるとはどういうことなのか、 あるいはPlatform Engineeringについて - Speaker Deck
設計・開発
Architecture to Design より良い設計を目指して | ドクセル
変わるモデルと変わらぬ本質 - 実践知の深掘りと次世代開発アプローチの探求
生成 AI アプリの本番導入を可能にした3 つの評価プロセス～DB 設計レビュー自動化の取り組み～ @Developers Summit 2025 - Speaker Deck
データの整合性を保つ非同期処理アーキテクチャパターン / Async Architecture Patterns - Speaker Deck
バックエンドエンジニアのためのフロントエンド入門 #devsumiC - Speaker Deck
https://mizchi-20250213-devsumi.pages.dev/
業務理解の深化と実践～ドメインモデリングで基幹システムを捉える - Speaker Deck
開発プロセス
【デブサミ2025登壇資料】新卒1年目が0から始めたDevOps～プルリクマージ数を8倍にした開発プロセス改善～ - Speaker Deck
初代プリウスにみるアジャイル開発の要素と現代の環境での進め方について - Speaker Deck
品質
プロセス改善による品質向上事例 - Speaker Deck
トラシューアニマルになろう ～開発者だからこそできる、安定したサービス作りの秘訣～ - Speaker Deck
リーダブルテストコード 〜メンテナンスしやすい テストコードを作成する方法を考える〜 #DevSumi #DevSumiB / Readable test code - Speaker Deck
自動テストの世界に、この5年間で起きたこと - Speaker Deck
キャリア
エンジニアが子育てとキャリア両立するには by kaori_cho #devsumi2025 - Speaker Deck
とある EM の初めての育休からの学び - Speaker Deck
私が新卒からプロへと変わる3年間～「エンジニア基礎」研修資料で伝えたエンジニアになるまでの道のり～ - Speaker Deck
組織貢献をするフリーランスエンジニアという生き方 - Speaker Deck
若手向けITコミュニティを運営する理由 - Speaker Deck
「海外登壇」という 選択肢を与えるために 〜Gophers EX - Speaker Deck
わたしの"コミュニティへの還元"リレーション #devsumi - Speaker Deck
目の前の仕事と向き合うことで成長できる - 仕事とスキルを広げる / Every little bit counts - Speaker Deck
その他
7日間でハッキングをはじめる本をはじめてみませんか？_ITエンジニア本大賞2025 - Speaker Deck
急成長する企業で作った、エンジニアが輝ける制度/ 20250214 Rinto Ikenoue - Speaker Deck
SaaSの次なる潮流BPaaS ゼロイチの事業づくりと伴走するプロダクト開発の裏側 - Speaker Deck
現場の種を事業の芽にする - エンジニア主導のイノベーションを事業戦略に装着する方法 - - Speaker Deck
【Developers Summit 2025】プロダクトエンジニアから学ぶ、 ユーザーにより高い価値を届ける技術 - Speaker Deck
脆弱性対策について、DAST,SAST,IAST,第三者診断の使い分けをどう考えるか
すごく久しぶりにメモ程度のエントリを書く。
DAST、SASTはよく話題に出るので覚えているものの、IASTってどんなのだっけ、というのをすぐ忘れるので、以下を読んだ。
読んでみて、IASTがどんなものかを思い出したので、改めてセキュリティソリューションについてどんな組み合わせが良いのか雑に考察してみた。
IASTについて
上記の記事の内容を参考に簡単にまとめると、IASTの特徴はこんな感じ。
- 何回調べても忘れがちなんだが、IASTは「エージェントをインストールしてSASTとDASTを組み合わせた観点の検査を実施して精度高く脆弱性を検出するツール」
- スキャンはシステム動作に合わせて自動的に実行される形式で、キック型ではない
- システムの動作にフックして検査を行うなど、内部の挙動に密に関わる動作を行うため、対応している言語・FWが限定的
- SAST,DASTを置き換えるものではなく、互いのデメリットをカバーして組み合わせで補完するもの
どんな組み合わせでセキュリティ対策するか
としたときに、では、SAST,DAST,IASTや第三者の脆弱性診断をどんな感じで組み合わせればよいか考えた。
いつ、どのソリューションで対策するのが適切か
- SASTはCI/CD組み込みで
- GitFlowでfeatureの直接のマージ先となるテスト環境用のブランチにマージする前に動かすなどする
- DevSecOpsの基本は多分この形
- DASTはリリースとは切り離して定期実行
- 数十分〜数時間など時間がかかるのでCI/CDパイプラインに入れるのは厳しい
- stgでリリース前に実施する、もしくはリリース頻度と乖離しない程度の頻度で（日次/週次/月次など）定期実行する
- IASTはリグレッションテストの際に実行（システムテスト環境、stg）
- 動作に合わせてスキャンされるので、それなりにテストケースを流していないとスキャンできない
- エージェントをインストールするので商用環境はパフォーマンス影響への懸念あり、開発環境全てに入れるのはやり過ぎ
- 結果的にリグレッション、負荷テスト、長期安定性試験などテストケースをガッツリ流す環境・タイミングでやるのがよさそう
第三者脆弱性診断をやるなら
これだけ多重に対策するなら第三者脆弱性診断など高額だし不要に思うのだが、「第三者が診断する」ことを重視する場合もあるのは事実。
ツールもただではない（OSSでも運用コストがかかる）ので、その場合にどんな棲み分けをするか、どれと引き換えに実施するのかなどを考えなくてはならない。
以下考えられるパターンを書き出してみる。
- 上記ツールで一通りやった上で年1回走らせる
- 正直コストかけすぎ感。ツール3種類組み合わせてできることはやっているので、人手診断は御札扱いもいいとこ。
- 内部でカバーできてるところは人手でやってもらう必要はないので、人手でしかできないペネトレーションテストに絞って実施してもらい御札をもらうのが効率的。
- DASTだけ置き換える
- 結局人手の攻撃、ペネトレーションテストなどが不足するという話なので、DASTで行う機械的なシナリオ実行も含めて外部委託する内部の動作試験はIASTに任せる
- DASTが有償なら有力な選択肢か
- DASTがOSSでもテストケースメンテやツール実行・確認などの年間の運用コストがそこそこ掛かるなら委託する費用と相殺できるか
- DAST＆IASTを置き換える
- SASTだけはやっておき、あとは動作的な試験は第三者に投げる
- ただし年1回になるのでリアルタイム性が大きく下がる
- すべてを置き換える（第三者のみ）
- SASTすらやらない、第三者診断頼み
- セキュリティ対策の外出しという意味ではこれだけという手もあるが、費用も考えると年1回程度しかできないのでアジャイルのリリース頻度からすると全然合わない
- とはいえ最大1年間脆弱性放置されると考えるとリスク高く、何か他に組み合わせて自衛しないとさすがに不足感ある
- OWASP ASVSなどを活用して人力でセキュリティレビューすることで対策するという人力に任せる策も一応あり
- OWASP Application Security Verification Standard ja | owasp-asvs-ja
考えがちょっと違っているところもあるかもしれないけど、今のところの理解はこんなところ。
Joi本「テクノロジーが予測する未来」を読んだ
表題の通り。
全体的な感想はブクログに書いて放流済みだが、こちらにも編集して残しておく。
対象の書籍はこちら。
全体的な感想
購入したのは9月くらいだろうか。発売が5月なので少し読むのが遅くなってしまい半年ちょっと寝かしてしまったことになる。 この業界だと半年も前だと一昔前と思えるほど過去の出来事に感じてしまい、内容によっては古くなることもあるだろうが、タイトル通り未来に向けての考察、特にまだ方向性が定まっていないNFTのユースケースやDAOに関する言及がメインと思うので特に問題なかった。
全体的にはここ2年くらいの間に見聞きして大まかに知っていることが7,8割といった感じなので全く知らなかった、というものは少なかったけど、改めて定義や著者の思うあるべき姿を言語化されたのを読むと自分の頭の中にも定着しやすくなるという点で良かった。
コンパクトにまとまっているので自分が言語化したり誰かに話したりする時に参照しようと思える点でも良書だと思う。
メタバースについて
メタバース言及は少なめだったが、現時点ではまだメタバースは黎明期といってもいいくらいの状態だと思うので仕方がない。
メタバースに関しては 佐藤 航陽さんの世界2.0 メタバースの歩き方と創り方 や 國光 宏尚さんのメタバースとWeb3 などがあるのでそちらを読み込んだ方が理解が深まりそう。（後者は未読）
メタバースついでに言えば、こちらも近いうちに読んでおきたい。
読書メモ
以下、付箋つけたところ。
あまり付箋は貼らなかった。
序章
- P.55『オンライン上でのコミュニケーションを前提として、何らかの価値の交換が行われている空間というのが、本書で考えようとしているメタバースの姿としてふさわしい』
第4章
P.162 （オードリー・タンさんの話してたこと）『これからは「目的」から始まる学び＝「パーパス・ベース・ラーニング」に力を入れる必要がある』
P.163 『プロジェクト・ベース・ラーニングでは、何をプロジェクトの起点としたら子どもたちの意欲が高まるかが課題でした。...（略）一方、パーパス・ベース・ラーニングでは、まず先に「社会に貢献したい」という大きな目的があります。』
P.164 『「インターネットは役に立つものですか？ それに対する僕の答えは、「あなたは、何に興味がありますか？特に何にも興味がないのなら、インターネットはあなたの役には立ちません」でした。 これはつまり、インターネットは知識や情報を得る新しい手段だから、得たい知識や情報がない人にとっては無用の長物である。「役に立つか」どうかの答えはテクノロジーそのものではなく、自分の中にあるんだ、ということを伝えたかったのです。』
P.168 『やはりweb3の分散化（非中央集権化）という点に大きな意義と可能性を感じているので、技術的にもスピリット的にもweb3化していく未来を選びたい。 そのためにも、本物のアントレプレナーシップを育てることが不可欠であり、これまで話してきた「パーパス（目的）」「パッション（情熱）」「クリエイティブ・コンフィデンス（自分の創造性に対する自信）」を育んでいけるかどうかが重要な鍵になってくる』
”テック企業はアジャイルなんてやっていない”とは（「ユニコーン企業のひみつ」読書メモ）
タイトル通り、前から読みたかった「ユニコーン企業のひみつ」をようやく読んだので、気になった部分をメモがてら残しておく。
脈絡もなく引用しつつ取り上げていくだけなのでまとまりが悪いことを先に断っておく。
気になったところメモ
以下、本書の前から順に読んで気になった、印象に残った部分を取り上げていく。 たくさんあるので逐次更新。
1章 スタートアップはどこが違うのか
1.1 スタートアップは「火星」から来た
- スタートアップは他人から時間を借りて生きている。
- 金を借りている場合もあるだろうが、調達した資金が尽きる前までの間に迅速に価値を出すというプレッシャーの方が強く感じるのだと伝わる表現。
1.2 「学習する機械」
- テック企業は従業員に財務情報を公開する。あらゆるデータを信じてゆだねる。開発者に自分のマシンへの管理者アクセス権限を与える。そして常にチームにこう問い続ける。「どんな支援があればもっと速く進める？」
- 開発者全員に初日から本番環境へのadmin権限を与えるということの意図が伝わる背景。
- 当然、チームの成熟度は考慮すべきでエンタープライズ系企業が明日からやってうまくいくわけじゃない。
1.6 "Think Different"
2章 ミッションで目的を与える
2.1 プロジェクトの問題点
ユニコーン企業がプロジェクト方式を採用しない理由として、プロジェクトの問題点が挙げられている。
- 期間があまりにも短い
- フィードバックの機会がない
- プロジェクトはあまりにも融通が利かない
- プロジェクトは力を奪う
- プロジェクトは間違ったことにフォーカスしている
特に4つ目の「力を奪う」で説明されているこの一文が強い。
プロジェクトは考えることをやめさせてしまう。
2.2 これが「ミッション」だ
2.6 ミッションの例
ミッションの原則に従うと、ミッションの予算とはチームの人数のことだ。以上。
- トップダウン的な施策で「見積もりは？必要な人員は？」と言われることに対して絵にかいた餅で説明して承認をとるのは違うよ、と。
- 決まった人数＝予算でミッションを進めるので実現時期も今年度中とコミットできるようなものではないと言える。
ミッションを設定するのは経営リーダーだが、そこにどうやって到達するのかを決めるのはチームだ。（略）
チームは自分たちで自分たちの仕事を生み出す。何を作る必要があるのかを決めるのはチームだ。チームに渡すミッションは...
- 会社にとって必要なものにしよう
- そのチームで責任を果たせるものにしよう（他への依存を少なくしよう）
- どうやって達成するかの計画はチームが協力して考えられるものにしよう
- 表現はシンプルだが、すごく難しい。
3章 スクワッドに権限を与える
3.1 スクワッドとは？
- スクワッドとは、少人数で、職能横断（Cross-Function）の、自己組織化されたチームだ（多くの場合、8名以下で編成される）。スクワッドは同じオフィスに席を並べて、自分たちが作ったプロダクトの隅々まですべてに責任を持つ。
- ちいとぽでいうところのストリームアラインドチームに近い定義。
- 「自律した小さなテックチーム」
3.2 スクワッドはどこが違うのか？
- スクワッドは（略）普段から、MVPを出来るだけ早くリリースすることが奨励されている。どうしてかって？スクワッドは最初のバージョンは「正しくない」と心得ているからだ。だから顧客からフィードバックを得たい。しかしフィードバックを得るにはリリースしなければならない。
3.8 Q&A
- 「結論を出す」という行為自体はチーム自身にやってもらうことが望ましい。なぜなら、あなたがチームの領域に踏み込んで何をすべきかを指示すればするほど、チームに与えられている権限や信頼は減ってしまうからだ。
4章 トライブでスケールさせる
（特になし）
5章 ベットで方向を揃える
5.2 カンパニーベットとは
- カンパニーベットとは、会社が取り組みたい重要事項を、終わらせたい順に並べたリストのことだ。
- 通常、小さい目標はカンパニーベットにはならない。ベットは「大きな岩」だ。
- 全社リソースの30%は常にカンパニーベットに取り組んでいる状態にしておく
- カンパニーベットはチームが常に取り組むべきものを示す指針にもなる。
5.3 カンパニーベットの仕組み
- DIBBはやるべきだと考えているを系統立てて検証するための意思決定フレームワークである
- Data, Insight, Belief, Bet のそれぞれの頭文字
5.5 やり抜くためのコツ
- 反直感的ベットとは、当初は誰も信じてくれないのだが、後から考えると実に見事で明白に思えるようなベットのことだ。コーヒー１杯で７ドルも取ろうなんて正気か？誰がお金を払って私のソファで寝たいと思うわけ？
- 念を押しておくが、自分たちの時間を何に費やすべきかの最終的な決定権はあくまでスクワッドにある。
6章 テック企業で働くということ
6.2「何をすべきかを指示するつもりはないよ」
- （スクワッド解散に伴い既存プロダクトの所有者がいなくなり）新しい2つのスクワッドは、どちらが既存のプロダクトを引き継ぐのかを合意できなかった。そこで彼らは、トライブリードである私の上司に決めてもらおうとやって来たというわけだ。ところが上司はそれを拒否した。
- 「情報が足りないとか、文脈がわからないとか、全体像に疑問があるとか、そんなときは私のところに来てほしい。だけど、これはあなた方が自力で解決すべき問題だ。」
- 本当に現場でよくある話で、決まらないものはトップダウンで決めるしかないのだと思っているが、これはあくまでも「よく話し合って両チームで決めてほしい」という回答を出すのだということ。これができる組織の強さよ。
6.3 お金の使い方が違う
- これまでの職業人生で、スピードのためにお金を使えなんて言われたことは一度もなかった。
- もし「資金を投入すれば競争に勝てる」というのなら、喜んでそうする。細かいことにこだわっている場合じゃない。
6.4 「信頼してないの？」
- 従来型企業は従業員を信頼していない。そのため、数え切れないほどの手段を用いて、あらゆる物事の進みをものすごく遅くさせている。
- （大手テック企業の場合）開発者は自分のマシンへのフルアクセス権限がある、すべてのチームが本番環境にアクセスできる
- テック企業ならこれはせめて同じ水準にしたい...が、そんなチームに所属していた経験は未だにない。
7章 生産性向上に投資する
7.3 ハックウィークを開催する
- 「ハックウィーク」とは、エンジニアが通常業務を脇に置いて、自分の好きなことをなんでもやれるイベントだ。（略）Googleはこれを「20%ルール」として実践して、同種の発想の有名な先駆者となった。
- ハックウィークに参加するのは単独でもいいし、チームを組んでもいい。内容は基本的に、やりたいことなら何でもいい。ただし一つだけルールがある、ハックウィークの最終日には必ずステージに上がって、自分の時間をどう使ったのかをみんなに示さねばならない。
- ハックウィークでは何かをリリースすること、何かをデモすることが強く推奨されている。
7.5 品質に高い期待を持つ
（コラム）新機能なしの2年間
- SpotifyのCEOであるDaniel Ekは取締役会で、CEOなら誰もやりたくないメッセージを伝えた。（略）「Spotifyは来年まで新機能を一切追加するつもりはない。その代わり、インフラストラクチャとスケーリングに取り組むことにする」
- CEOがこれを宣言するというのはどのような心境なのだろうか。想像を絶する。。
7.8 フィーチャーフラグを活用する
- フィーチャーフラグは（略）ソフトウェアの特定機能を本番環境上でオンにしたりオフにしたりできる。（略）理由は2つある。未完成の作業の統合と、実験だ。
- （フィーチャーフラグは）チームが未完成の作業をコードベースにマージしても、それをフィーチャーフラグで隠せるのだ。ソフトウェアの実際の利用者には影響を与えることなく、開発を続けられる。
- これはインテグレーションプロセスをシンプルにするので、マージが後回しになっているせいで修正が遅れているバグの数を最小限にできる。
7.9 リリーストレインでリリースする
- リリーストレインとは、完成した機能のまとまり（バッチ）を、あらかじめ決められた間隔で定期的にリリースするプラクティスだ。
（定期的なリリース継続の2つの重要な効果）
- 期日に間に合わせるために期限ギリギリまで機能を詰め込もうとするストレスから解放される
- プロダクトを小さなバッチで継続的に改善できるようになる
- バッチが小さくなれば、テストやデバッグも容易になる
リリーストレインとフィーチャーフラグを組み合わせると、継続的にリリースできる実に見事な仕組みが実現する。
8章 データから学ぶ
8.3 A/Bテストで実験する
- こうした疑問に直面したとき、テック企業はどちらかを選ぶようなことはしない。どちらも試す。
9章 文化によって強くなる
9.4 核となる信念
- 慎重で思慮深い要件収集よりも、学習と実行のスピードを重視する
（エンジニアリングについての信念）
9.5 行動は言葉に勝る
- （重要なシステムを壊してしまいトライブ全体に向けて謝罪のメールを出したメンバーに対して上司がかけた言葉）
「気にしなくて大丈夫です。よくあることですから。（略）壊したのはあなたが最初ではありませんし、最後にもならないはずです。それに、あなたに壊せてしまうような本番環境だという事実は、私たちのシステムにはまだ改善の余地があることの証拠です。」- これを一片の曇りもなく伝えることができる責任者はどれだけいるだろうか...
- 自分にも多分できない（言いながら表情が濁ってしまう気がする）。。
10章 レベルを上げる：ゆきてかえりし物語
10.10 「言い訳」を取り除く
- こんな奇抜なアーキテクチャにしたのは私じゃないし。他の誰かの仕業だし。
- すでに運用中のプロダクトを引き継いで障害が起きたりすると喉元まで出かかる言葉。これを乗り越えるのが第一歩。
訳者あとがき
ポッドキャストの聴き方、よく聴いてるエンジニア向けポッドキャスト
はじめに
少し前に、聞いているポッドキャストの公開をしているブログをいくつか見かけたので、自分もよく聴いてるポッドキャストを、エンジニア向けのものを中心に書き出してみようと思う。
またその前に、改めてポッドキャストのメリットや、自分がどんな環境で聴いているのかをまとめておく。
ポッドキャスト（音声コンテンツ）のメリット
- ながらで聴ける
- が、集中度合により適する番組が変わる
- Youtubeもそうだったが、ブログなどでしか知らなかった人の話を聴けるのが新鮮。
- 「あ、こんな声だったんだ」「こんな話し方する人だったんだ」と印象が変わる・惹きつけられる体験が得られやすい。
- 「顔出しが嫌」「動画編集が面倒くさい」がないのでハードルが下がり配信しやすい
いつ聴くのか
- 家事
- 台所での食器洗いをしてる時はわりと集中して聴きやすい
- 外出時
- 特に子供と公園に行く道中、及び遊ばせている最中
ただし、どちらの場合も、家族・子供の声や周りの音がある程度聞こえるような状態にしておく配慮が必要。
そこで、使うデバイスが重要になる。
使ってるデバイス
プラットフォーム
Google Podcasts
だいたいこれで済む。鉄板。 以前はApple Podcastをなんとなく使っていたが、PCで聞いたりスマホで聞いたり、ということがあるので登録している番組と、どこまで聞いたかをデバイス間で共有できないとつらい、と思っていたところに安定のGoogle先生のサービスを発見し、以来ずっとこれ。 登録している番組の新着エピソードなどをダウンロードしておけば、外出時に便利。 ダウンロードしてオフライン再生しているにも関わらず、Googleアカウントに繋いでいるためかそこそこモバイル通信量がかかってしまうのが気になるがまぁそこは仕方ない。
Spotify
あんまり使わないが、Podcastの紹介などがあったときにリンク先がSpotifyということが結構ある。 Google Podcastsで配信されている限りはそちらで登録するが、されていない場合は仕方なくこちらで登録する。 こちらはダウンロード可。
stand.fm
スマホ限定の配信プラットフォーム。配信やコンテンツ販売が気軽にできる。 なんか若者、女性向けっぽい感じがするな...と思ったら、ライブ配信と収録配信の両方が可能ということで「TikTokの顔出さない版」みたいな位置づけを狙ってるからだと理解。 リスナーとしてはダウンロード不可のため在宅時にしか聴けない。 アプリ仕様的になんとなく感覚合わない気がするのもおっさんだからだろうか。
e.g.
- 番組一覧を表示する導線が悪い
- エピソード詳細を見ようとタップしたら即再生される
- そのせいで再生中の誤タップで違うものが再生されてしまう事故が多い
- 1つ前に再生してたものに戻る手段がない
Voicy
今日本で一番勢いがあるだろう音声プラットフォーム。 2020年から使ってるが、去年あたりから配信者（パーソナリティ）がめっちゃ増えて爆発的に伸びた感がある。 使い始めた頃はインフルエンサー中心で審査基準も厳しかったらしいが、かなり素人っぽい人も増えたので最近は少し変わったのだろうか。
Audible
...はまだ使ってない。
ポッドキャストで聞きたいエピソードに困ったら考える。
エンジニア向けの番組紹介
EM.FM
- EMによるEMのためのポッドキャスト
- 組織論の話などは当然多い
広木さんのあまりに広範な知識量と、新しい知識を既存の知識を応用して要点を掴む能力の高さにただ驚く
印象に残ったエピソード
fukabori.fm
- 技術の話、マネジメントの話が両方聞けて楽しい
インタビュー形式で気になるところを深堀りしていくスタイルで1on1のコツみたいなものも垣間見える
- が、深堀り力とまとめ能力が高すぎ
- どんだけ予習してるのというくらい理解しているインタビュアーの鏡のようなファシリ
印象に残ったエピソード
Rebuild
- 老舗の技術系ポッドキャスト。これを聴いてアニメが趣味になったエンジニア多数。
”テック担当”（実際はテックとマネジメント担当）のnaoyaさんが出演してた頃のが好き。
- Fateは観たことないがサーバントリーダーシップの話は印象に残ってる。
今だと ひげぽんさん、及川さん、川口さんあたりが出る回は比較的面白い気がする。
- 前は集中して聞きたい話題も多かったが、今はホントにラジオ代わりに流し聞くのに良い感じ
mozaic.fm
- Monthly Web として各ブラウザのアップデートの内容とその周辺の話をするのが通常回、時々テーマを絞った回がある
- あまり分からない話も多いが、流し聞きしてると勉強になる話題がいくつか拾えたりして面白い
- 最近ではMSのIEの中の人をゲスト話してた回とWeb3の回（テーマ回）がとても面白かった
engineer meeting podcast
- 現場リーダー層くらいのエンジニアが飲み屋で仕事の話をしてる感じで流し聞きに良い
- 「30代のWebエンジニアが何か喋ってたら誰かの役に立つんだじゃないかと思って始めたPodcast」だが、vol.180 40歳になってしまった そうなので話題が少し変わってきたかも？
しがないラジオ
- SIerからWeb系エンジニアに転職したんだが楽しくて仕方がないラジオ
- Web系のコミュニティからできた人脈でゲストを呼ぶところから始まったと思うが、知名度上がるに連れ大物も来る来る。
- 最近更新なし。
hidekのエンジニアと長話
- メルペイVPoEのhidekさんがゲストを呼んで雑談がてら色々聞く形式
- しがないラジオのgamiさんがアシスタントに回ってる
- これもやってたらしがないラジオまで手は回らないよなーと納得
アジャイルラジオ
- アジャイルに関する話題を数名で語る番組
- 最近聴き始めたが、音質が他と比較して少し悪いのと、ゆずっぽいノリのテーマソングを乗り越えるのに少し時間がかかった
- 音質マジで重要
- RSGT 2022の話 や チームトポロジーの話は聴いて少し参考になった（が、もうあまり覚えてない）
