Sign up to save your podcasts
Or
Share fukabori.fm
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
fukabori.fm
By iwashiTechnology
fukabori.fm episodes
- 72. 2022年のフロントエンド開発、特にCSS事情 w/ tsukkee
tsukkee さんをゲストに、CSS Grid、Custom Properties、CSS Transitionなどについて語っていただいたエピソードです。
話したネタ- 最近のフロントエンド開発ってどんな感じ？
- なぜ、 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
- 採用: ストックマーク社 エンジニア募集中
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.46 min - 71. アジャイルソフトウェア開発と統計的品質管理 w/ sakata_akinori
sakata_akinori さんに "アジャイル開発は品質が悪い" という言説、統計的品質管理、ウォーターフォールで利用されるバグ密度などの指標の有効性、代用特性などについて語っていただいたエピソードです。
- JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
- 書籍: エクストリームプログラミング
- 「アジャイル開発は品質が悪い？」という風評・言説
- この言説はどこからやってきたのか？なぜ生まれたのか？
- ハイブリッドアジャイル、ハイブリッドウォーターフォール、ウォータースクラムフォール
- コードの複雑性をマネジメントできない状態
- マネジメントプロセスの原因はどこにあるのか？
- 絶対イヤだ or 偉くなる
- バグ密度曲線などの指標は、どこからきて、何がしたかったのか？
- 品質指標は、いつもと同じかどうかを見ていただけ
- メインフレーム や COBOL
- いつもと同じかどうか、を見るのは過去において意味があったのではないか
- ウォーターフォールのメトリクスはコストに由来しているのではないか
- 2022年において、いつもと同じかどうかを見る手法は意味があるのか？
- 統計的品質管理の考え方自体は現代でも有効
- アジャイル開発では、何を指標として追えばいいのか？
- スピードに着目したメトリクス
- リードタイム、サイクルタイム
- 審議プロセスにおける納得感とは？
- そもそもリスクを小さくしている、ということで納得する
- 常に上限値におさまるというのは統計的にありえない
- 代用特性とは？ と 温度計での例
- ソフトウェアにおける品質特性(国際規格ISO/IEC 9126)
- 狩野モデル
- "品質は誰かにとっての価値である" / ワインバーグ
- SQuBOK
- ホーソン実験
- 魅了的品質をどう高めていくか？
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
47 min - 70. チームトポロジー(後編) w/ miholovesq
書籍"チームトポロジー" 訳者の miholovesq さんに、3つのインタラクションモード(コラボレーションモード、XaaSモード、ファシリテーションモード)、認知負荷などについて語っていただいたエピソードです。
話したネタ- 書籍: チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
- チーム間のインタラクションの3モードについて
- コラボレーションモードとは？
- XaaSモードとは？
- ファシリテーションモードとは？
- 認知負荷を下げるのが重要
- サービス境界をどう設定するかがポイント
- 組織設計をするためにエンジニアリング能力が必要
- 認知負荷(cognitive load)とは何か？
- チームサイズを認知負荷に合わせて設計する
- ダンバー数
- 設計は人を驚かせるべきじゃない
- Clean Code アジャイルソフトウェア達人の技
- スモールチームで小さくて良いのでフィーチャーをデリバリできるのが大事
- モブプログラミング・モブワーク
- Amazon audible
- 書籍翻訳の裏話
リスナーの皆様へのお願いfukabori.fm リスナーアンケートを実施中です！ぜひ回答お願いします！ (2022/3/31 まで)
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.20 min - 69. チームトポロジー(前編) w/ miholovesq
書籍 "チームトポロジー" 訳者の miholovesq さんに、チームトポロジー、4つのチームタイプ、アジャイル開発との関連、Agile PBL祭り などについて語っていただいたエピソードです。
話したネタ- 書籍: チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
- 書籍: 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 まで)
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.41 min - 68. エンジニアリング組織に溶け込むHRBP w/ yamamuteking
エムスリー VPoEの山崎さんに、エンジニア組織におけるHRBPの役割（採用、リテンション、チャレンジマネジメント）や、エンジニアマネジメントなどについて語っていただいたエピソードです。
話したネタ- HRBP(Human Resource Business Partner)とは何か？
- HRBPの登場背景とは？
- ハーバード･ビジネス･レビュー21年12月号 これからの人事
- プロダクト開発組織におけるHRBP
- プロダクトマネージャー、エンジニア、デザイナー、QAというチーム構成
- 人事がプロダクトチームになぜ入る必要があるのか？
- 役割1. 採用の加速
- 候補者体験を最大化するためのルート整備
- 社内のエンジニアに対する深い理解
- 役割2. リテンション
- エンジニアでは見落としがちな課題を早めに拾う
- 人事がエンジニアの朝会に入って課題設定する
- スクラムマスターに近い振る舞い
- エンジニア オンボーディングでの期待値調整
- 役割3. チャレンジマネジメント
- HRBPが深く入るチームの優先度付けは？
- m3 HRBP募集ページ
- (退職を検知する)人事的センサーとは？
- 多様性がチームを強くする
- どうやってHRBPをスケールさせるか？
- スタートアップでHRBPを置くならいつが良いか？
- エンジニアリングマネジメントを「ちゃんと」やる？とは
- エンジニアリングの成果 と 経営 を接続する
- m3 採用情報ページ
fukabori.fm リスナーアンケートを実施中です！
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.40 min - 67. 命名規則 と heyのエンジニア組織 w/ ffu_
hey CTOの藤村さんに、プログラミングにおける命名規則、heyのエンジニア組織設計・戦略などについて語っていただいたエピソードです。
話したネタ- プログラミングにおける命名規則になぜこだわるのか？
- 名前のないプログラミング言語
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
エピソード提供スポンサーヘイ株式会社
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.44 min - 67. 良い命名とは？ と heyのエンジニア組織 w/ ffu_h2 id=話したネタ話したネタ/h2ulliプログラミングにおける命名規則になぜこだわるのか？/lili名前のないプログラミング言語/lilia href=https://amzn.to/3gaeuLmWEB+DB PRESS Vol.110/a もしくは a href=https://amzn.to/3Gew23gWEB+DB PRESS総集編[Vol.1~120] /a/lilia href=https://speakerdeck.com/fujimura/ru-men-ming-qian入門 名前/a/lili命名規則における「良い」とは何か？/lilia href=https://amzn.to/3AGEA1YCODE COMPLETE 第2版 上 完全なプログラミングを目指して/a/lili名前の意味と挙動が一致していること/liliparse という関数命名における例/liliprimary と primal/lili全体の名前のルーツになる命名は丁寧につける/lili日本語を、命名規則に使うのはどうか？/lili関数・変数名を短くすべきか？長くすべきか？/lilia href=https://signalvnoise.com/posts/3250-clarity-over-brevity-in-variable-and-method-namesClarity over brevity in variable and method names/a/liliHaskell での命名/lili紛らわしい動詞をやめる、例: check()/lili値を返すのか、副作用があるのか分からない/liliRuby の predicate メソッド/lilihey のプロダクト開発組織デザインとは？/lili横断チームとプロダクトチームを作り分ける判断基準は？/liliチーム・組織が遠くなると、話にいくハードルが上がらないか？/liliオンラインで話しかけやすいようにするための工夫は？/lili全社ミーティングでの愛のあるいじり/liliCTO本部って何をしている？どの課題を解こうとしている？/liliエンジニア組織のマネジメントをチームで進める/lili得意な人・知見がある人がファイナルアンサーを持っている/lili権限委譲をどのように進めているか？/lili8象限 と a href=https://ja.wikipedia.org/wiki/RACI%E5%9B%B3RACI/a/lilia href=https://nuworks.jp/ja/product/del-poker/デリゲーションポーカー/a/liliheyの評価制度は？/liliheyのエンジニア採用戦略は？/lilia href=https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%83%99%E3%83%BC%E3%82%B9%E3%83%89%E3%83%9E%E3%83%BC%E3%82%B1%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0ABM/a/lili採用でやらないと決めていることは？/lilia href=https://pitpa.cc/33R7S1X採用サイト/a/lilia href=https://pitpa.cc/3AH6ElWhey BOOK for Engineers/a/li/ulh2 id=エピソード提供スポンサーエピソード提供スポンサー/h2pa href=https://www.hey.jp/companyヘイ株式会社/a/p44 min
- 66. 問いかけの作法(後編) w/ YukiAnzai
MIMIGURI Co-CEO のYukiAnzaiさんをゲストに、問いを引き出す基本定石、良い質問の角度の探し方、アイデアの収束方法などについて語っていただいたエピソードです。
話したネタ- 書籍: 問いかけの作法:チームの魅力と才能を引き出す技術
- 問いを引き出す基本定石とは？
- 上司が至らなさに光を当ててしまう
- 問いかけは相手の意見・個性を引き出すために使う
- いたらなさになぜ、スポットライトをあててしまうのか？
- 「何か良いアイデアはありますか？なんでもよいので」
- 「これまでのボツネタのなかでもったいない、と思うものはありましたか？」
- 質問のスポットライトの良い角度をどのように探すか？
- 同じものをみているふりして違う意味で使っている
- 定義されていない言葉は とらわれ の可能性が高い
- 理念を良い意味で各現場が解釈していく
- 現場の理念のすれ違いをどうやって、すり合わせしていくのか？
- パラフレーズという問いかけのパターン
- ブレストのアイデアをどのように収束させるか？
- アイデアの決め方を事前に合意しておく
- 多数決と多様決
- 組織の創造性を引き出すエンジニアリングとは
- MIMIGURI 採用・求人
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.20 min - 65. 問いかけの作法(前編) w/ YukiAnzai
MIMIGURI Co-CEO のYukiAnzaiさんをゲストに、"問いかけの作法"の概要、オンラインファシリテーション、４つの現代病、知の探索と深化、などについて語っていただいたエピソードです。
話したネタ- 書籍: 問いかけの作法:チームの魅力と才能を引き出す技術
- "問いかけの作法" の概要について
- 書籍: 問いのデザイン: 創造的対話のファシリテーション
- 書籍: リサーチ・ドリブン・イノベーション 「問い」を起点にアイデアを探究する
- 前著2冊との関係性は？ なぜ問いかけの作法を執筆したのか？
- 両利きの経営とサクセストラップ
- 孤軍奮闘の悪循環 とは？
- 誰も意見を言ってくれないお通夜のようなミーティング
- 孤軍奮闘の悪循環は、どのような起点で生まれてくる？
- 学校の先生にファシリテーションの方法を伝えると、教育効果が悪い
- ファシリテーションで、介入するタイミングは？
- 相手の思考のステータスを観察する・見立てる
- オンラインで観察するコツ・工夫は？
- コミュニケーションのチャネルを複数にしておく
- ハードルが低い方から段階的にアウトプットしてもらう
- 【エッセイ】どうして日本人は質問しなくなるのか
- 意見・質問を出せる環境を作っていくのが大事
- 「問いかけの作法」で言及される4つの現代病とは？
- 認識の固定化・関係性の固定化・衝動の枯渇・目的の形骸化
- 関係性が固定されている状況では、非常に意見が言いにくい
- のび太がこんなに優秀なはずがない
- 3人のレンガ職人のメタファーにおける1人目の凄さ
- 現代病に対して、我々はどう振る舞っていくべきなのか？
- 「うちの会社って、伝統があるのでリセットできないんですよ」
- 固定観念は、昨日までの強力な武器である
- こだわりと、とらわれの二項対立を往復する
- 知の探索と知の深化との両方をやり続ける大変さ
- 構造的に分担するアプローチ と 文脈的両利きのアプローチ
- 個人で探索と深化のループを回すにはどうしたらいいか？
- 評価制度と連動させるのが重要
- MIMIGURIにおける制度での連動例
- MIMIGURI 採用・求人
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.44 min - 64. ロボット x スキル w/ nakakura, kmat
前回に続きnakakuraさんとkmatさんをゲストに、ROS(Robot Operating System)、ロボット x スキル、ロボットに対するプログラミングの課題、テストフィードバックサイクル、などについて語っていただいたエピソードです。
- ROSとは何か？
- ロボット x スキル
- AIが判断してロボットを動かしている動画
- ロボットの身体構造におけるネックとは
- ロボット業界における車輪の再発明
- 強化学習とニューラルネットの応用
- ROS上で動作するロボットが持つ身体構造情報の活用
- ロボットの動作を作り込むときの苦労とは？何が大変なのか？
- 最も大変なのは、ロボット周辺の環境が変化すること
- シーケンス的作業の実装
- ドアを開ける場合の実装例
- ロボットプログラミングに対するテストはめちゃめちゃ大変？
- テストのフィードバックサイクル
- 物理シミュレータの利用
- ハードウェアの劣化・故障
- インターンシップ募集中
- 中途採用も募集中
- チームを一言で表現すると？
- プロフェッショナル集団
- 攻殻機動隊 - Stand Alone Complex
- 第3回 JAPAN PODCAST AWARDS「リスナーズ・チョイス」の投票フォーム
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
21 min
About fukabori.fm
From the publisher's feed
技術・組織・マネジメントなどを深掘りして楽しむPodcastです。
More shows like fukabori.fm
Rebuild
50 Listeners
バイリンガルニュース (Bilingual News)
223 Listeners
backspace.fm
10 Listeners
mozaic.fm
2 Listeners
EM . FM #EMFM
0 Listeners
歴史を面白く学ぶコテンラジオ （COTEN RADIO）
244 Listeners
ゆるコンピュータ科学ラジオ
21 Listeners
News Connect あなたと経済をつなぐ5分間 #ニュースコネクト
20 Listeners
入山章栄の経営理論でイシューを語ろう/Business Insider Japan
4 Listeners
ひまじんプログラマーの週末AI大好きエンジニアリングレッスン
0 Listeners
Qiita FM-エンジニアのキャリアを深掘り-
0 Listeners
リファクタリングとともに生きるラジオ
0 Listeners
耳で学ぶAI、ロボシンク
1 Listeners
趣味でOSSをやっている者だ
0 Listeners
小泉進次郎のポッドキャスト
4 Listeners