fukabori.fm – Details, episodes & analysis
Podcast details
Technical and general information from the podcast's RSS feed.


技術・組織・マネジメントなどを深掘りして楽しむPodcastです。
Recent rankings
Latest chart positions across Apple Podcasts and Spotify rankings.
Apple Podcasts
🇫🇷 France - technology
30/05/2025#98
Spotify
No recent rankings available
Shared links between episodes and podcasts
Links found in episode descriptions and other podcasts that share them.
See all- https://huggingface.co/
177 shares
- https://openai.com/dall-e-2/
146 shares
- https://amzn.to/3KmsG3p
3 shares
- https://amzn.to/3vLiz1C
3 shares
RSS feed quality and score
Technical evaluation of the podcast's RSS feed quality and structure.
See allScore global : 53%
Publication history
Monthly episode publishing history over the past years.
129. Tech業界のDE&Iの現状と課題、その解決に向けた活動事例 w/ kamiyaU
mardi 6 mai 2025 • Duration 50:56
kamiyaUさんをゲストに、Tech業界のDE&Iの現状、米国のバックラッシュによる日本への影響、国内の活動事例などについて語っていただいたエピソードです。
話したネタ
- DE&Iとは何か?
- エクスクルージョンの具体例
- DE&Iが注目された背景とは?
- 日本のIT/テック業界におけるDE&Iの現状と課題とは?
- なぜ女性比率が他産業よりも低いのか?
- 昨今、主に米国で起きているDE&Iへのバックラッシュ
- 米国のバックラッシュによる日本への影響はどうなのか?
- kamiyaU さんのDE&Iへの取り組み
- 3つの活動(Community、Resource、Paper)
- マジョリティ側のエンジニアは何をすれば良いのか?
- アライ(Ally: 支援者、仲間)としての行動
- 『LEAN IN (リーン・イン) 女性、仕事、リーダーへの意欲』(シェリル・サンドバーグ著)
- りっちゃ・りょかちのやいやいラジオ、#28 ジェンダーギャップについて思うこと【前編】 from Radiotalk
- momit.fm
- momit hub
- 書籍レビュワー募集フォーム
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
128. 冒険する組織のつくりかた w/ YukiAnzai
lundi 7 avril 2025 • Duration 52:42
YukiAnzaiさんをゲストに、書籍『冒険する組織のつくりかた』の概要、軍事的世界観、組織文化に変化を起こす方法、などについて語っていただいたエピソードです。
話したネタ
- 『冒険する組織のつくりかた「軍事的世界観」を抜け出す5つの思考法』
- 書籍の概要
- 従来の経営・組織論における「軍事的世界観」(戦略、戦術、目標管理など)
- 偶発性理論(Planned Happenstance Theory)
- 現代の価値観(キャリア観、自己実現、心理的安全性)とのズレ
- 「冒険的世界観」へのパラダイムシフトの提案
- 目標設定の再考:「スマート(SMART)の法則」から「アライブ(ALIVE)の法則」へ
- 組織文化における「ハレとケ」の活用
- 理念・パーパス・MVVの浸透と形骸化
- トップダウン「浸透」の限界と、現場での「再解釈」「再編集」の重要性
- 半年に一度の「理念の再解釈」
- 転勤・異動の意味づけの変化
- PR:株式会社MIMIGURI エンジニアリングマネージャー(EM)募集中
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
119. 生成AI導入で成功する企業・失敗する企業、国産基盤モデルの意義 w/ piqcy, kosukearima
vendredi 23 août 2024 • Duration 56:29
久保さん、有馬さんをゲストに生成AIの導入成否のポイントや、国産モデルの意義などについて語っていただいたエピソードです。
話したネタ
- 生成AI成功企業の特徴
- 定量的評価の難しさ、定性的な評価指標の重要性
- 実データに基づいた独自の評価指標の必要性 (例: 100件テスト)
- 生成AI導入における課題
- インターフェースの問題とカルチャーの問題
- 出島的アプローチの成功と失敗パターン
- 失敗の成否を分けるものは?
- 過去のBIツール導入失敗からの学び
- 巨大言語モデルの学習方法と人間の学習方法
- クラウドネイティブ化と生成AI活用の相関
- 日本における生成AIビジネスの挑戦
- 国産基盤モデル開発の意義と期待
- 生成AIの進化と次のステージとは
- aws-ml-enablement-workshop
- Claude 3.5 Sonnet Model Card Addendum
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
29. 技術選定の審美眼(2) w/ twada
dimanche 22 mars 2020 • Duration 01:17:37
- Worse Is Better - 過去を知り、未来に備える。技術選定の審美眼 2019 edition
- 集中と分散
- Good Old Webとは何か?
- 改訂第5版 PC UNIXユーザのためのPostgreSQL完全攻略ガイド(シーラカンス本)
- Linux, Apache, PostgreSQL, PHP
- 2層アーキテクチャから3層アーキテクチャへ
- EJB(Enterprise Java Beans)とは?
- SOAP(Simple Object Access Protocol)とは?
- なぜEJBやSOAPが生まれてきたのか?
- 言語依存から言語非依存、ベンダ依存からベンダ非依存へという流れ
- SOA(Service-Oriented Architecture)とは?
- Enterprise Service Bus
- XMLによる設定とマッピングが多い時代だった
- XMLエンジニアとYAMLエンジニア
- Ruby on Railsの登場へ
- How to build a blog engine in 15 minutes with Ruby on Rails
- 設定より規約(Convention over Configuration)
- システムを早く作って、市場に出してフィードバックサイクルを回すのが重要な時代が追い風に
- Ruby on Rails全盛時代に、エンタープライズの世界で何が起きていたのか?
- SpringやSeasar
- POX(Plain Old XML) over HTTPとは何か?どのような背景で生まれたのか?
- Delicious
- 成功している分散している分散システム(Web)が身近にあった
- 分散システムの設計がRPCからWebベースへ
- RESTとステートレス、Shared Nothing、スケールアウト
- XMLじゃなくてJSONで十分だったという気づき
- クラウドコンピューティングの時代へ
- ムーアの法則と、スケールアップ戦略の限界
- Dockerの登場と、コンテナ技術
- 冪等性の難しさ
- 巨大化したモノリスによる問題から、マイクロサービスへ
- BFF(Backend For Frontend)
- SOAとマイクロサービスの螺旋
- DevOps、コンウェイの法則・逆コンウェイの法則
- 組織は戦略に従う、戦略は組織に従う
- ソフトウェアがハードウェアのおまけだった時代から、事業そのものへ
- Why Software Is Eating The World / Marc Andreessen
- Swagger、GraphQL、gRPCの共通点とは何か?
- 動的型付けから静的型付けへ
- サーバ主導でのAPI定義から、クライアント主導でのAPI定義へ
- Cloud Nativeとサーバレスコンピューティング
28. 技術選定の審美眼(1) w/ twada
dimanche 15 mars 2020 • Duration 41:52
- Worse Is Better - 過去を知り、未来に備える。技術選定の審美眼 2019 edition
- フロントエンド疲れとは?
- 大筋でのトレンドは変わってないが、目が養われていないと疲れてしまう
- Gruntとgulp.js、ReactとVue.js
- イメージ的には選球眼
- 変わるもの、変わらないものを見極めるモチベーションは何か?
- 技術の世界は変化が緩やかで手堅い部分と変化が激しい部分がある
- 振子のように見えていた変化は、角度を変えて見れば螺旋であり、その差分を見るのが大事
- ベテランエンジニアの唯一のアドバンテージとは?
- プログラマとしての可処分時間はどんどん減っていく
- ベテランプログラマに求められる役割としての、語り部と老害のボーダライン
- Unix哲学
- 小さいのは良いことだ(Small is beautiful)
- 一つのことを上手くやる(Make each program do one thing well)
- すべてはファイルである
- 強い制約による高い相互接続性
- ネットワークプロトコルにおける強い制約
- REST / Web
- すべてをURLで表現できる
- DHHはどのようにRailsのコントローラを書くのか
- RDBMS / SQL
- すべては関係である、(わかりやすく言えば)集合である
- 共通なのはIFが狭く、振る舞いの種類が少なく、限定であり、実装の詳細に依存しないこと
- コミュニケーションコストにを下げるという寄与
- 系が閉じることによる強さ
- 閉包性とは?
27. 論理削除とは何か?どのような解法があるのか? w/ twada
dimanche 1 mars 2020 • Duration 01:05:48
- 論理削除とはそもそも何か?
- 物理削除とは?
- なぜ、論理削除が生まれてくるのか?
- SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
- 理由1: 心理的なハードルの高さ、怖さがある
- 理由2: 削除したデータを検索対象に入れたい場合がある
- 理由3: ログとしての用途
- 理由4: 誤操作をすぐに戻したい
- アンチパターンとは何か?
- なぜ、論理削除はアンチパターンとして捉えられるのか?
- 全てのSQL文のWHERE句に削除フラグが必ず入る
- LIMIT 1などが蔓延していく
- 論理削除に気づくきっかけは何か?
- テーブル設計や、規約から気づく
- 論理削除というアンチパターンをどのように解いていくか?
- 論理削除という概念は世の中にまずなく、お客様は論理削除という言葉を使っていない
- 要件をどのように設計すればいいのか?
- ORMの論理削除プラグインはあまり良くない
- 状態遷移として捉える方法
- Soft Delete と Hard Delete
- Doctrine 2 “Behaviours” in a Nutshell
- RDBにおけるStateパターンとは?
- UMLにある状態遷移図
- Stateパターンが使えないケースはある?
- FSM - Finite State Machine
- State Machineのプラグインをまず探す
- AASM - Ruby state machines
- 履歴テーブルを使った設計による解法
- 履歴テーブルをあえて使う強いモチベーションは何か?
- そもそも削除も更新もしない解法もある
- 発生した事実に忠実にモデリングすると、情報の削除や更新をしない、改ざんになる
- データ中心アプローチ(DOA) 椿さんとか佐藤さんとか渡辺さんとか
- T字形ER手法
- データ量が増えた場合にどうするか?
- Webシステムが流行る前後のデータ量
- イミュータブルデータモデル(入門編)
- 誤った操作をなかったことにしたい、という課題はまだ解けていない
- 教科書的なのは間違えにくいUI/画面設計を作る
- 遅延レプリケーションという解法
26. Spinnakerとは w/ k_mrgk
mercredi 5 février 2020 • Duration 38:47
- Blue-Green デプロイメントを採用したデプロイの仕組みを実装して共通基盤として導入した話 / SRE NEXT 2020
- Spinnakerとは何か?
- kubernetesのみではなく、他にも対応している?
- 継続的デリバリとは、継続的デプロイメントの違いとは?
- CDについて、Spinnakerはどこまで対応している?
- Spinnaker単体でRollbackも簡単になる?
- 国内だと、どれぐらい使われている?
- GitOpsとは何か?
- Single Source of Truth
- リポジトリはどのように分割するのか?
- Spinnakerのデプロイ戦略には何があるか?
- ReplicaSetとは?
- 訂正 fukabori ep.11は 市川さん -> 市原さん です。ごめんなさい。
- メトリクス周りでSpinnakerがケアしているくれるところはある?
- Kayenta
- 手動承認もできる
- SpinnakerのPipelineでどんな感じ?
- 何かCIやテストで選定しているものはあるか?
- kubernetesのJobでの制約は?
- Spinnaker自体のアーキテクチャはどうなっている?
- Spinnaker運用におけるトラブルシュートは大変?
- 開発チームとSREチームでの分解点、運用フローはどうする?
- PipelineをテストするPipelineとは?どのようなテストをしている?
- Spinnaker自体のモニタリングはどうするのか?
- Argo Rollouts
- Custom Resources
- アプリケーションのリリースに必要な会議を倒したい話
- Istioを使っているか?
- kustomizeとは?
- Helmとは?
- 学生向け N-ISUCON - Webアプリケーションのパフォーマンスチューニングコンテスト
25. 日本企業を辞めてカーネギーメロン大学へ入学し、Nianticで働くまで w/ noralife
vendredi 17 janvier 2020 • Duration 47:23
- 海外企業でソフトウェアエンジニアで働くための手段
- ビザってなぜ必要なんだっけ?
- 米国のビザってどういう種類があるの?
- OPT STEM
- 10:05 訂正 H1は9月に発給される -> 10/1の間違い
- 大学の出願候補はどうやって選んだのか?
- 就業中で働きながらどのように受験の勉強をしたのか?
- TOEFLとGRE
- GREの単語は無理ゲー
- リスニングはどうやって勉強した?
- 何校程度、受験した?
- 入学したCMUのコースは何人ぐらいいるの?
- コースにいる学生で米国Nativeの数は?
- CMUの学生生活はブラック
- CMUの授業はどういう形式が多い?
- CMU Software Engineering
- Introduction to Computer Systems
- mallocを実装する宿題
- 修論執筆は必須?
- Raj教授
- 卒業制作はアジャイル開発で進める
- アジャイル開発のフレームワークなどは?
- ACDM/Architecture Centric Design Method
- この授業、とくに面白かったな、って授業は?
- Raftの実装する課題
- 課題のテストケースが秘伝のタレ
- GoのTCPライブラリに仕込んである
- Databaseの授業では、ほぼDBMSを作るような課題
- b-tree自体は簡単でも、スレッドセーフ・並行処理への対応が大変
- 在学中から就職先の選定はどのように進めた?
- リファーラルが取れる場合はとったほうが良い
- 日本と違って自分の履歴書があればポジションへ応募できる
- リモートでの技術面接はどのような問題が出る?
- オンサイトでの技術面接は?
- どのように面接準備した?
- Leetcode
- Cracking coding interview
- Nianticで働いてみて、実際にどんな印象か?
- エリートといえばリスクテイク
- 同僚をみていて、日本のエンジニアという違う部分はある?
- 1日のタイムスケジュール、どのぐらいコーディングしているか?
- 英語力は伸びる?
- 英語が分からなかったときの対応スキルが伸びる
- 海外で働いてみてよかった点は、英語の勉強から離れられたこと
- 東京のサラリーマンが、仕事をやめてアメリカで働くために悩んだこと、行動したこと
24. 開発組織から部長がいなくなるまでの経緯 w/ teppeis
dimanche 29 décembre 2019 • Duration 01:06:54
- サイボウズはどのようなプロダクトを開発しているのか?
- kintoneの競合って?
- サイボウズって外注しているの?オフショアは?
- 組織変更したら部長がいなくなりました
- 部長がいなくなる組織変更する前はどのような組織だったのか?
- マトリクス組織、上長って複数名?
- マトリクス組織において、どのような問題があったのか?
- 職能定義に固定的に考えてしまう
- どのように組織変更を進めていったのか?
- 60組以上に今考えている課題について、ヒアリング実施
- 左右の壁と、上下の壁
- プロダクトチームはどういうメンバ構成なのか?
- 組織変更は、だれが、どのぐらいの人数で、どのぐらいかけて考えていったのか?
- ヒアリング結果は常にオープンに
- 「あれ、俺の役職なくなるんじゃね?」という懸念はあったのか?
- 旧部長の多くは、組織運営チームにJoinした
- マネージャは孤独な仕事であるが、チームを組んで考えるようになった
- 組織運営チームで解決する課題はどのように発見しているのか?
- 発見した課題の優先度付けは?
- Scrum at ScaleにおけるEAT(Executive Action Team)に近い
- EATはエスカレーションされた問題の即日解決を目指す
- 予算系のものの承認は、誰がするようになったのか?
- 予算枠確保よりも、必要なものを、必要なときに使うのが大事
- チームの活動をkintone上というオープンな場に公開する
- 公明正大が会話にまで浸透している
- チーム間の異動は自由にできるようになったのか?
- チームメンバに(社内)採用の権限を落とした
- 体験入部制度
- 公開されているJob boardでの応募はどのようにすればできる?
- 人気のあるチームに集まっちゃう問題?
- レガシーとなったプロダクトのチームで解く課題の人気
- 組織変更後の給与評価はどのようにするようになった?
- メンバの活躍をどのように把握しているのか?
- 市場価値として、社内+社外の評価を利用している
- アジャイル開発のフレームワークは何を使っている?
- スクラムチームはどの程度ある?
- スクラムチーム間の情報交換はどうしている?
- 開発ツールとしてのコード管理は何を使っている?
- 徐々にGitHub Enterpriseから、GitHub.comの利用へ
- RSGT2020
23. 社内ISUCON w/ yosuke_furukawa
dimanche 20 octobre 2019 • Duration 01:03:30
- Write Code Every Day
- ISUCONとは?
- エンジニア5000名が参加するISUCONとは何か
- ISUCONに参加するまでの流れ
- ISUCON問題作問する側のインフラ担当は大変
- ISUCARI
- ISUCON9予選の出題と外部サービス・ベンチマーカーについて - catatsuy - Medium
- R-ISUCONは優勝者が作問側へ
- ISUCON参加側のyosuke_furukawaの役割は?
- テディベアプログラミング
- なぜ社内ISUCONをリクルートテクノロジーズで開催しているのか?
- ISUCONの技術力を高める、リクルートのパフォーマンス課題を共通で解く
- 社内ISUCON開催に向けて、何か社内を説得 or 進めていくコツは?
- スモールスタートで始めつつ、偉い人を巻き込む
- R-ISUCON
- PortalにVM再起動ボタン
- ベンチ動きっぱなしISUCON
- NTTコミュニケーションズのソフトウェアエンジニア向け研修内容・資料を公開します - 障害注入型ISUCON
- DevOpsエンジニアリング
- エンジニアの横のつながり
- 運営メンバってだいたいどのぐらい人数?
- 社内ISUCONの言語選定は?
- 開催までの工数ってどう考えるか?
- 社内ISUCONデスマーチ
- インフラ基盤には何を使う?
- VMのOSは何を?
- 複数VMを異なるスペック、構成で提供する
- 参照実装を増やす場合に、CIなどを回す?
- フロントエンドエンジニアがISUCONでは能力を出しにくい
- フロントエンド限定のスピードハッカソン
- ユーザが体験するパフォーマンスの7-8割はフロントエンドと言われることも
- ベンチマーカはどうやってい実装している?
- データベースに入れておくデータセットはどうやって作る?
- 画像のプリセットを作るのが大変
- loadimpact/k6
- Postman
- 現代システムアーキテクチャとの乖離について
- リクルートテクノロジーズ 採用情報
- JSConf JP









