TopPodcast.com
Menu
  • Home
  • Top Charts
  • Top Networks
  • Top Apps
  • Top Independents
  • Top Podfluencers
  • Top Picks
    • Top Business Podcasts
    • Top True Crime Podcasts
    • Top Finance Podcasts
    • Top Comedy Podcasts
    • Top Music Podcasts
    • Top Womens Podcasts
    • Top Kids Podcasts
    • Top Sports Podcasts
    • Top News Podcasts
    • Top Tech Podcasts
    • Top Crypto Podcasts
    • Top Entrepreneurial Podcasts
    • Top Fantasy Sports Podcasts
    • Top Political Podcasts
    • Top Science Podcasts
    • Top Self Help Podcasts
    • Top Sports Betting Podcasts
    • Top Stocks Podcasts
  • Podcast News
  • About Us
  • Podcast Advertising
  • Contact
Not in our directory?
Add Show Here
Podcast Equipment
Center

toppodcastlogoOur TOPPODCAST Picks

  • Comedy
  • Crypto
  • Sports
  • News
  • Politics
  • True Crime
  • Business
  • Finance

Follow Us

toppodcastlogoStay Connected

    View Top 200 Chart
    Back to Rankings Page
    Technology

    fukabori.fm

    技術・組織・マネジメントなどを深掘りして楽しむPodcastです。

    Advertise
    • Apple Podcasts
    • Google Play
    • Spotify

    Latest Episodes:
    74. PMFしているスタートアップがスケールする上での組織課題と解法 w/ kameike Jun 15, 2022
    Show notes

    話したネタ

    • タイミーのプロダクトとは
    • スタートアップがスケールするにあたっての組織課題とは?
    • プロダクトの優先順位を決める上で意識していることは?
    • プロダクトバックログの優先順位の判断はどのようにしている?
    • CTOとしてのビジョン、未来の組織とは?
    • 専門性を分化させて、プロセスを高速化させる
    • 採用は答え合わせ
    • Engineering Manager の責務と Tech Lead の責務
    • Google re:Work
    • プロダクトHRとは何をしている?
    • セールスの採用とエンジニアの採用との違いは?
    • タイミーにおけるエンジニアの目標設計・評価とは?
    • キャリアラダーの上げ下げは、誰が・どのように判断している?
    • チームトポロジーを成功させる実践方法の探求 - Team Topologies Study
    • タイミーにおける採用戦略とは?
    • 採用で必要な人数はどのように決定している?
    • タイミーにおけるコミュニケーション設計とは?
    • コミュニケーションで上手くいかなかったこと・上手くいったこと
    • 伝わらないと透明性は出ない
    • 組織としてドキュメントを書く力をどのようにつけていくか?
    • タイミーエンジニア公式Twitter
    • kameikeさんのTwitter
    • fukabori用のmeety
    • エントランスブック

    エピソード提供スポンサー

    • 株式会社タイミー

    73. Value Object w/ kumagi May 16, 2022
    Show notes

    話したネタ

    • Value Objectについて整理しよう
    • Value Object とは何か?
    • Value Object で複数の値をくるむcompoundの具体例は?
    • Value Object のメリット・デメリットは?
    • 別名参照問題
    • Value Object は何でないか?
    • YAGNI原則
    • 不変オブジェクト (Immutable Object)
    • 書籍: リファクタリング 既存のコードを安全に改善する(第2版)
    • マーチン・ファウラー氏のblog記事 - ValueObject
    • Value Object Obsession と Primitive Obsession
    • Primitive Obsession のメリットは?
    • Value Objectの言説はどこから生まれてきたのか?
    • 「オブジェクト指向エクササイズ」でクセの強いコードを矯正しよう
    • 書籍: Effective C++ 第3版
    • 書籍: Effective Java 第3版
    • 書籍: CODE COMPLETE 第2版 上 完全なプログラミングを目指して
    • 書籍: CODE COMPLETE 第2版 下 完全なプログラミングを目指して

    72. 2022年のフロントエンド開発、特にCSS事情 w/ tsukkee May 02, 2022
    Show notes

    話したネタ

    • 最近のフロントエンド開発ってどんな感じ?
    • なぜ、 transpile などの変換が必要なのか?
    • CSS Grid とは? 何が良いのか?
    • もともと昔はどうやってレイアウトしていた?
    • Table から Float へ
    • 阿部 寛のホームページ
    • Flexbox とは
    • XUL
    • Grid と Flexbox の違いは?
    • HTML(意味) と CSS(スタイル) の分離って、実際の開発ではどう?
    • CSSで変数利用って、どう進化してきた?
    • Sass や SCSS
    • Custom Properties
    • Custom Properties のメリットとは?
    • Web Component との関連
    • この先、SassやSCSSはこの先どうなっていく?
    • CSS Nesting Module
    • CSS Animation / Transition の進化
    • JSでアニメーション実装をすると、何が難しいのか?
    • Apple Interface Guideline
    • アニメーションの使い時はいつか?
    • アニメーション習いたてで使いたくなっちゃう問題
    • Animation と SVG との組み合わせが便利
    • CSS の仕様を、どうやって追っかけているか?
    • web.dev
    • チームでフロントエンド情報をどうやって学習しているか?
    • CSS設計をどうやって決めている?
    • Shadow DOM と スコープ
    • 実際のプロダクト開発では何を使っている?
    • CSS Layer
    • :has() 疑似クラス
    • CSS Houdini
    • Painting API
    • Layout API
    • 採用: ストックマーク社 エンジニア募集中

    71. アジャイルソフトウェア開発と統計的品質管理 w/ sakata_akinori Apr 17, 2022
    Show notes

    話したネタ

    • JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
    • 書籍: エクストリームプログラミング
    • 「アジャイル開発は品質が悪い?」という風評・言説
    • この言説はどこからやってきたのか?なぜ生まれたのか?
    • ハイブリッドアジャイル、ハイブリッドウォーターフォール、ウォータースクラムフォール
    • コードの複雑性をマネジメントできない状態
    • マネジメントプロセスの原因はどこにあるのか?
    • 絶対イヤだ or 偉くなる
    • バグ密度曲線などの指標は、どこからきて、何がしたかったのか?
    • 品質指標は、いつもと同じかどうかを見ていただけ
    • メインフレーム や COBOL
    • いつもと同じかどうか、を見るのは過去において意味があったのではないか
    • ウォーターフォールのメトリクスはコストに由来しているのではないか
    • 2022年において、いつもと同じかどうかを見る手法は意味があるのか?
    • 統計的品質管理の考え方自体は現代でも有効
    • アジャイル開発では、何を指標として追えばいいのか?
    • スピードに着目したメトリクス
    • リードタイム、サイクルタイム
    • 審議プロセスにおける納得感とは?
    • そもそもリスクを小さくしている、ということで納得する
    • 常に上限値におさまるというのは統計的にありえない
    • 代用特性とは? と 温度計での例
    • ソフトウェアにおける品質特性(国際規格ISO/IEC 9126)
    • 狩野モデル
    • “品質は誰かにとっての価値である” / ワインバーグ
    • SQuBOK
    • ホーソン実験
    • 魅了的品質をどう高めていくか?

    70. チームトポロジー(後編) w/ miholovesq Mar 16, 2022
    Show notes

    話したネタ

    • 書籍: チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
    • チーム間のインタラクションの3モードについて
    • コラボレーションモードとは?
    • XaaSモードとは?
    • ファシリテーションモードとは?
    • 認知負荷を下げるのが重要
    • サービス境界をどう設定するかがポイント
    • 組織設計をするためにエンジニアリング能力が必要
    • 認知負荷(cognitive load)とは何か?
    • チームサイズを認知負荷に合わせて設計する
    • ダンバー数
    • 設計は人を驚かせるべきじゃない
    • Clean Code アジャイルソフトウェア達人の技
    • スモールチームで小さくて良いのでフィーチャーをデリバリできるのが大事
    • モブプログラミング・モブワーク
    • Amazon audible
    • 書籍翻訳の裏話

    リスナーの皆様へのお願い

    fukabori.fm リスナーアンケートを実施中です!ぜひ回答お願いします! (2022/3/31 まで)


    69. チームトポロジー(前編) w/ miholovesq Mar 07, 2022
    Show notes

    話したネタ

    • 書籍: チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
    • 書籍: SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発
    • チームトポロジーという書籍の概要
    • コンウェイの法則とは?
    • wikipedia: Conway’s law
    • 逆コンウェイ戦略とは?
    • ソフトウェアを設計するように組織を設計する
    • ストリームアラインドチーム とは?
    • プラットフォームチーム とは?
    • イネイブリングチーム とは?
    • コンプリケイテッドサブシステムチーム とは?
    • ストリームアラインドチーム と プロダクトチームとの違いは?
    • アジャイル開発とチームトポロジーとの関連は?
    • 書籍: LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する
    • 現代型マネジメントと人間関係論
    • マインドセットがなくてもアジリティを出せるのではないか
    • Agile PBL祭り 2022
    • Agile PBL祭り 2022 スポンサー募集中
    • Agile PBL祭り での最大のアンラーニングとは?

    リスナーの皆様へのお願い

    fukabori.fm リスナーアンケートを実施中です!ぜひ回答お願いします! (2022/3/31 まで)


    68. エンジニアリング組織に溶け込むHRBP w/ yamamuteking Mar 02, 2022
    Show notes

    話したネタ

    • HRBP(Human Resource Business Partner)とは何か?
    • HRBPの登場背景とは?
    • ハーバード・ビジネス・レビュー21年12月号 これからの人事
    • プロダクト開発組織におけるHRBP
    • プロダクトマネージャー、エンジニア、デザイナー、QAというチーム構成
    • 人事がプロダクトチームになぜ入る必要があるのか?
    • 役割1. 採用の加速
    • 候補者体験を最大化するためのルート整備
    • 社内のエンジニアに対する深い理解
    • 役割2. リテンション
    • エンジニアでは見落としがちな課題を早めに拾う
    • 人事がエンジニアの朝会に入って課題設定する
    • スクラムマスターに近い振る舞い
    • エンジニア オンボーディングでの期待値調整
    • 役割3. チャレンジマネジメント
    • HRBPが深く入るチームの優先度付けは?
    • m3 HRBP募集ページ
    • (退職を検知する)人事的センサーとは?
    • 多様性がチームを強くする
    • どうやってHRBPをスケールさせるか?
    • スタートアップでHRBPを置くならいつが良いか?
    • エンジニアリングマネジメントを「ちゃんと」やる?とは
    • エンジニアリングの成果 と 経営 を接続する
    • m3 採用情報ページ

    リスナーの皆様への依頼

    fukabori.fm リスナーアンケートを実施中です! (2022/3/31 まで)


    67. 良い命名とは? と heyのエンジニア組織 w/ ffu_ Jan 31, 2022
    Show notes

    話したネタ

    • プログラミングにおける命名規則になぜこだわるのか?
    • 名前のないプログラミング言語
    • WEB+DB PRESS Vol.110 もしくは WEB+DB PRESS総集編[Vol.1~120]
    • 入門 名前
    • 命名規則における「良い」とは何か?
    • CODE COMPLETE 第2版 上 完全なプログラミングを目指して
    • 名前の意味と挙動が一致していること
    • parse という関数命名における例
    • primary と primal
    • 全体の名前のルーツになる命名は丁寧につける
    • 日本語を、命名規則に使うのはどうか?
    • 関数・変数名を短くすべきか?長くすべきか?
    • Clarity over brevity in variable and method names
    • Haskell での命名
    • 紛らわしい動詞をやめる、例: check()
    • 値を返すのか、副作用があるのか分からない
    • Ruby の predicate メソッド
    • hey のプロダクト開発組織デザインとは?
    • 横断チームとプロダクトチームを作り分ける判断基準は?
    • チーム・組織が遠くなると、話にいくハードルが上がらないか?
    • オンラインで話しかけやすいようにするための工夫は?
    • 全社ミーティングでの愛のあるいじり
    • CTO本部って何をしている?どの課題を解こうとしている?
    • エンジニア組織のマネジメントをチームで進める
    • 得意な人・知見がある人がファイナルアンサーを持っている
    • 権限委譲をどのように進めているか?
    • 8象限 と RACI
    • デリゲーションポーカー
    • heyの評価制度は?
    • heyのエンジニア採用戦略は?
    • ABM
    • 採用でやらないと決めていることは?
    • 採用サイト
    • hey BOOK for Engineers

    エピソード提供スポンサー

    ヘイ株式会社


    66. 問いかけの作法(後編) w/ YukiAnzai Jan 17, 2022
    Show notes

    話したネタ

    • 書籍: 問いかけの作法:チームの魅力と才能を引き出す技術
    • 問いを引き出す基本定石とは?
    • 上司が至らなさに光を当ててしまう
    • 問いかけは相手の意見・個性を引き出すために使う
    • いたらなさになぜ、スポットライトをあててしまうのか?
    • 「何か良いアイデアはありますか?なんでもよいので」
    • 「これまでのボツネタのなかでもったいない、と思うものはありましたか?」
    • 質問のスポットライトの良い角度をどのように探すか?
    • 同じものをみているふりして違う意味で使っている
    • 定義されていない言葉は とらわれ の可能性が高い
    • 理念を良い意味で各現場が解釈していく
    • 現場の理念のすれ違いをどうやって、すり合わせしていくのか?
    • パラフレーズという問いかけのパターン
    • ブレストのアイデアをどのように収束させるか?
    • アイデアの決め方を事前に合意しておく
    • 多数決と多様決
    • 組織の創造性を引き出すエンジニアリングとは
    • MIMIGURI 採用・求人

    65. 問いかけの作法(前編) w/ YukiAnzai Jan 11, 2022
    Show notes

    話したネタ

    • 書籍: 問いかけの作法:チームの魅力と才能を引き出す技術
    • “問いかけの作法” の概要について
    • 書籍: 問いのデザイン: 創造的対話のファシリテーション
    • 書籍: リサーチ・ドリブン・イノベーション 「問い」を起点にアイデアを探究する
    • 前著2冊との関係性は? なぜ問いかけの作法を執筆したのか?
    • 両利きの経営とサクセストラップ
    • 孤軍奮闘の悪循環 とは?
    • 誰も意見を言ってくれないお通夜のようなミーティング
    • 孤軍奮闘の悪循環は、どのような起点で生まれてくる?
    • 学校の先生にファシリテーションの方法を伝えると、教育効果が悪い
    • ファシリテーションで、介入するタイミングは?
    • 相手の思考のステータスを観察する・見立てる
    • オンラインで観察するコツ・工夫は?
    • コミュニケーションのチャネルを複数にしておく
    • ハードルが低い方から段階的にアウトプットしてもらう
    • 【エッセイ】どうして日本人は質問しなくなるのか
    • 意見・質問を出せる環境を作っていくのが大事
    • 「問いかけの作法」で言及される4つの現代病とは?
    • 認識の固定化・関係性の固定化・衝動の枯渇・目的の形骸化
    • 関係性が固定されている状況では、非常に意見が言いにくい
    • のび太がこんなに優秀なはずがない
    • 3人のレンガ職人のメタファーにおける1人目の凄さ
    • 現代病に対して、我々はどう振る舞っていくべきなのか?
    • 「うちの会社って、伝統があるのでリセットできないんですよ」
    • 固定観念は、昨日までの強力な武器である
    • こだわりと、とらわれの二項対立を往復する
    • 知の探索と知の深化との両方をやり続ける大変さ
    • 構造的に分担するアプローチ と 文脈的両利きのアプローチ
    • 個人で探索と深化のループを回すにはどうしたらいいか?
    • 評価制度と連動させるのが重要
    • MIMIGURIにおける制度での連動例
    • MIMIGURI 採用・求人

    Previous 1 2 3 4 5 10 Next

    Related Podcasts

    Reply All

    1

    Reply All Games & Hobbies
    Inside VR & AR

    2

    Inside VR & AR Gadgets
    Note to Self

    3

    Note to Self News
    BrainStuff

    4

    BrainStuff Natural Sciences
    This Week in Tech (Audio)

    5

    This Week in Tech (Audio) News
    Hands-On Tech (Audio)

    6

    Hands-On Tech (Audio) Technology
    footer-logo

    Contact Us

    Toll Free: 844-670-7747

    Links

    • Home
    • Top Charts
    • Networks
    • Apps
    • Independents Podcasts
    • Podcast Advertising
    • Podcast News
    • Contact Us
    • About Us
    • Analytics & Insights

    Stay Connected

      Privacy, Terms of Use & Our Code of Ethics Protecting Content Creators Copyrights