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
- 14. なぜ、エンタープライズ業界でアジャイル・リーンは普及しないのか？話したネタ
- なぜ、企画と開発が責任を押し付け合う会社の前途は暗いのか？
- 計画が悪い vs 実装が悪い、というどっちが悪い論
- 問題の理解と、その実装（人・システム）が時間軸で離れると学習がない、課題の理解は実装で深まる
- 市場、世界は悠長に回っていない
- 将棋でのメタファーとRTSでのメタファー
- 上手くいかないのは全体という前提をどこまで作れるか？
- 仕様が固まってから開発の後半で発生する変更を怖がる
- あたかも世界の時間が止まっているように振る舞う
- オーシャンズ11
- その場の状況にあった計画を立て直していく、情報を得続ける
- 現代の戦争は火力戦・物量戦から変わってきている
- 企画と開発も同じコンテキストで話さないと、リアルな変化に追従できない
- ピラミッド構造は例外処理が役割の1つ
- 手順書はQ&Aに答えてくれない
- Q&Aに答えられる人が現場にいない
- リーンスタートアップやアジャイルなやり方が出てきた背景は？
- ウォーターフォールに対するアンチテーゼ、開発技術・環境の成熟
- Organizational Patterns of Agile Software Development
- Quattro Pro
- いつも不機嫌な管理者、満足しない顧客、いつも怯えている開発者
- 開発環境、コードの共有、IDE、リファクタリング、テスト容易性などの技術の進化
- オブジェクト指向の成熟
- 顧客開発と製品開発にあった別のループを統合した
- 未来に予見できないことがたくさんあるときに、どうやったら製品と顧客の両方側で学びを獲得するか
- クラウドやRails
- 売れてもいないのに、最大アクセスの条件で試算する
ビジネスに追いつけない日本のシステム開発の構造欠陥とは？- プライムをとれないSIをやると辛いことがある
- 「仕様書に書いてないので、やらなくていい」「書いてないことやっちゃダメ」と言われる
- ミッションが「仕様書通りにやり遂げる、納期通りに納める」になる
- 本来であれば仕様書は動くもの
- SIの調達モデルとは
- イノベーションは調達できるの？って話
- ソフトウェアは材料として変わっている
- 鉄鋼は産業の米
- 鉄鋼は垂直ドメインに共有できる、水平ドメインの材料だった
- ソフトウェアも同様に考え、各会社がシステム子会社を作った
- その割には、ソフトウェアの中身を見ると垂直ドメインの言葉が入っている
- ソフトウェアは材料ではなく、垂直のビジネス構造と設計している
- とくに業務システムでは、ビジネスとソフトウェアは切り分けられない
- ソフトウェアの事業の中核である
- ソフトウェア工学領域で「ビジネス」という言葉の登場回数が、90年代後半から増えているかも
- 作る側とビジネスをする側が、調達という壁を挟んで交渉関係になってしまう
- 対立するのではなく、協調することによって得られる価値に向かう時代
- なぜ、エンタープライズ業界でアジャイル・リーンなやり方が普及しないのか？
- 考え方の普及と、ビジネス構造の変革速度に差がある
- ITが事業の中核と理解している企業は、どんどん中にエンジニアを採用している
- 就職で入りたいランキングにおいて、SIerは上位
- 20代の時期を何に投資するか？
- 企業内イノベーションの実現に向けた7つの提言
- “経営陣がアジャイルを理解し、企業文化を醸成すること”の狙いは？
- 経営陣に1人でも理解者・擁護者がいないと、熱に急激に冷めてしまう
- イノベーションをやるという意味、ソフトウェアの重要性・特性、ソフトウェアを使ったビジネス企画の特性として企画と開発が一緒にいるという点、を理解している経営者が必要
- “既存の情報システム部門と別に、イノベーション部隊を建設すること”の背景は？
- 大企業になればなるほど、組織をどう作るか、組織間コミュニケーションを変えるのは大変
- 小さくて良いので、ビジネスの目標・作りたいものを持っているチームを作るほうが、エネルギーを消耗しない
- 離れている時間が長い、成果が出ない場合は役員が意味を伝える
- “イノベーション部隊を既存の進捗管理から切り離し、企画と開発を一体化すること”とは？
- 年次の予算、売上を月次で追うが、イノベーションはそのとおりに行かない
- できないもんはできない
- どれぐらいコストをかけるのか？どういう目論見であがってくるのか？チェックポイントはどこなのか？ぐらいで抑える
- 上手くいかない場合は、ここまでという期限を決めて切る、といった投資判断
- 仕事をした気になって疲れる
- お客様と話をできるチームをたくさん作る、上にあげなくていいから、これができるかどうか
- “経験のあるアジャイルコーチ、スクラムマスターを招き入れる、もしくは採用すること”の狙いは？
- 本を読んでもアジャイルにできない
- 本を読んでも自転車に乗れない、暗黙知伝達の最たるところ
- アジャイルコーチや、スクラムマスターを1人、2人と有機的に増やす
- “アジャイル開発の教育を行い、徐々に経験者をふやすこと”の理由は？
- 効率良くやるためには、形式的知識伝達もやる
- 全体的な体系をわかった上で実践に入る
- “技術力のあるエンジニアを招集すること”
- 結局、スクラムの教育をいくらやっても、作れないものは作れない、ウォーターフォールも同じ
- 技術力のない人がものづくりをするのはおかしい
- パワポという黒魔術にひっかからない
- エンジニアの召集という言葉の意味
- “コミュニティへのエンジニア参加を推奨し、外部交流を行うこと”
- 熱を受け取る場面
- この人と出会った、この人の話を聞いて人生が変わったという転機
- 会社で誰かがイベントに参加したい、といったら是非是非出させてあげるべき
- （イベント参加の）報告書は別にいらない、その人の中に溜まる
- ワンクリックデプロイ ∼いつまで手でデプロイしてるんですか？∼
- 会社は度量を持つ
- 会社からの退職者数の傾きを見る
- 古くからいるマネージャーの役割はどうなっていくのか？
- 得意なことで、変化の中心になっている人を支援する
- 上からじゃなくて、新しいバリューシステムの一部になれるか、気持ちを持てるか
- 取締役からのメッセージも重要
- バリューを出せる人は、どうやってもバリューを出せる
アジャイルスタジオ福井で見学募集中See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.43 min - 13. ペアプロやテストの疑問とか、ソフトウェアエンジニアの育成とか話したネタ
- ペアプロにおけるビギナーとベテランの組み合わせ3パターンについて
- ビギナーとビギナーの組み合わせで効果はあまり期待できない（チームビルディングでは意味がある）
- ベテランとベテランは、一番効果を発揮するペアである
- 意思決定をライブでできる重要性
- 設計上の妥協点をその場で合意できる
- ビギナーとベテランで、ビギナーはナビゲーターをするのか？
- コードを書いてるところを見てもらうのは大事なプラクティス
- ベテランもプレッシャーを持ってコードを書ける
- 見られているだけでコードの質は高まる
- リアルタイムでないコードレビューがあるだけで、コードの質は高まる
- コードレビューのインフラに投資する
- 流しのペアプロ業をする中で、ドメイン知識がない状態でペアプロへ参加して価値をだせるか？
- 一番の学びは教えることから発生する
- 相手から、相手自身の学びを引き出す
- チームの暗黙知を、暗黙知のまま伝える、強化していく
- テストを書く場合に、RDBやKVSなどをどこまでモック/スタブするのか？
- ノートPCにインストールできるものは本物を使い、入らないものはモック/スタブを使う
- プライベート関数はテストするのか？
- 技術的には、プライベート関数のテストはパブリック関数からテストできる
- プライベートの実装に基づいたテストは脆い、現状追認のテストになりがち
- フロントエンドのテストはどこまで書けばいいのか？
- 書くけど、書きすぎない
- 画面の構造が変わっても、影響にされにくいものをテストする
- ビジュアルリグレッションテスト
- 魑魅魍魎のUIの世界
- テストのカバレッジ、どの程度まで書けばいいのか？
- ユニットテストを含めて、グレーボックス・ブラックボックスの観点から書くのが望ましい
- カバレッジは何らかの管理の道具にすると、うまく回らない
- 不具合は思い違いから発生する
- カバレッジ100%は誤った安心感を与えがち
- カバレッジツールは自分達の見落とし・過信を見つけるために使う
- カバレッジを絶対値ではなく傾きでみる
- CIではテストの成功/失敗だけではなく、カバレッジやコードの複雑度を取る
- バグ収束曲線は、現代の開発ではFitしないことのが多い
- 品質指標の形骸化
- 外注が多く、内製が少ない組織で、ソフトウェアエンジニアをどうやって育てていけば良いのか？
- 内製にシフトするなら、技術者のhiringも必須
- 小さく始めて、大きく育てて勝つパターンを積み上げる
- 段階的に内製開発にシフトしていく
- 社内の特区、信頼貯金を使って展開していく
- 内製を全然していない会社が、内製にシフトするためには4-5年かかる
- 新人を育てるためにはどうしたらいいか？
- 配属ガチャ
- 技術力の高いエンジニア新人を孤立させない
- 事業部内に閉じた情報流通
- 全社Slackがないのはよくあるサイロ化
- 技術者の横のつながりを維持する、リアルタイムコミュニケーションのチャネルを作る
- 内製を始めるモードになったエンプラ企業はイメージ付けが必要
- 技術者が社名を背負ってアウトプット
- 大企業Hack
- 意思決定層にこれからのソフトウェア開発に認識を改めてもらう
- 組織やチームにノウハウをどうためて、育てていくのか？力を貯めるいいやり方？
- 再現可能にするのが大事
- 前提が違う、変動する中でソフトウェア企業としての強さを保つ
- 公開し検索可能にすることが大事
- URL重要
- 心理的安全性の重要性
- 価値観から行動原則、品質基準を考えていく
- 経験していない場面にチェックリストは効かない
- 誤っていたこと、失敗は良いチャレンジとして評価されるように
- 社内でアンチパターンを共有できる組織は強い
- 社内FailCon
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.57 min - 12. エンプラ向けの組織改革とか、スクラムでのチーム作り・人事評価とか話したネタ
- 古くから大企業・組織で、ryuzeeさんならどう切り込んでいくか？
- 現場だけで変えられる範囲には限界がある
- 組織改革を若手がやるのは厳しい
- ボトムアップでやるには気の遠くなる話が多すぎる
- ミドルマネージャーや意思決定の権限を持つ
- 改革の範囲を全社ではなく、自分の部だけにする
- 徐々に広げていくのは、ボトムアップでは鉄板
- トップダウンでいく場合は、ミドルマネージャーが障壁になりやすい
- 全社ルール・ガイドラインと、どう付き合っていけば良いのか？
- 複数のガイドライン/オプションを用意しておく
- ガイドラインをかならず守らなきゃいけないのは思い込みなこともある
- 緩い、自由があるガイドラインだと進めやすい
- 権限委譲が非常に難しいのではないか？
- 権限のないプロダクトオーナー問題
- プロジェクト開始の時点で、決められる範囲の線引き
- 大きな会社になればなるほど、スクラムマスターが重要
- スクラムマスターの役割は半端じゃなく大変
- 大きな会社だとチームの外側に課題がある
- スクラムマスターは大きな会社のプロパーがやるべき
- プロダクトオーナーとスクラムマスターはチームの内外でバランスをとる
- プロダクトが目に見える成果を出してないケース
- プロダクトを売らずに、組織改革ばっかりしてもしょうがない
- 綺麗事ばっかり言ってるのはダメ
- 失敗することは是である
- 傷の浅いうちに、ダメなものを見つけてサービスを畳めるのも成功である
- 弾をたくさん投げるのが良いこと
- 出島とは？
- 全員同席、外部から雑音をシャットアウトする
- エンドポイントを一箇所に絞る
- 治外法権
- 人気ある部門へ人が集まりやすいが、過疎化はどう防ぐ？
- お金を稼いでるけど、不人気な部門の問題
- 辞めるにしてもいい関係で辞めてもらう
- 給与テーブルが自由に設定できない問題
- やりたいことができるように、また仕事しやすい環境を与える
- 周囲のバックオフィス系の部門にどの程度、アジャイル的な考え方を理解してもらうのか？
- バックオフィスは、プロジェクト開始時に巻き込んでおく
- たとえば品質管理部門の人に入ってもらって、完成の定義を考える
- AWSでShip判断
- us-east1から他リージョンへのロールアウト
- 開発チームはどの程度、顧客の声を知る必要があるのか？
- チームが無関心なのは一番辛い
- サポートエンジニアを一緒にやるプラクティス
- 開発と運用のチームは結局どうしていけばいいのか？
- 基本的には1チームが良く、部門が別れているならバーチャルチームで1つに
- 少数精鋭のチームでものづくりすると、運用しないように寄せていくことで、本業に集中する
- 必ずしも新規技術を使う必要はない
- チームの力量・状況にあわせて、技術や言語を選んでいく
- 1week sprintの振り返りだと、長期的な課題がでにくい？
- ベロシティを1.5倍、2倍にするためには何したらいいの？
- KPTは断面を切る振り返りであり、時間軸があまりない
- 振り返りは適度に変えていく
闇鍋という振り返りプラクティス- ドット投票における問題
- 給与査定という観点での人事評価はどうやればいいか？
- プロダクトの結果が出ていれば、個人の評価はどうでもいいのでは？
- チーム一律評価 + 360度評価 を組み合わせるのが落とし所
- 新サービスを出したばっかりのPOはどう評価するか？
- 人事部とエンジニアの採用プロセスの関わり？
- アトラクタでお仕事募集中
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.51 min - 11. dockerネットワーキングとか、kubernetesネットワーキングとか話したネタ
- dockerを立ち上げたときに、ネットワークに何が起こるのか？
- iptablesでは何が起こるのか？
- dockerのbridgeとは何なのか？
- libnetworkとは何か？
- docker network pluginを作るためには、何を書くのか？
- dockerを使うと出てくるvethとは何なのか？
- dockerコンテナのIPを誰が振っているのか？
- IPAMとは？
- dockerから出ていくとき、どういう要素を通って外に出ていくのか？
- –network host の Host とは？
- Overlayとは何か？
- VXLANとは？
- BUM(Broadcast, unknown-unicast and multicast traffic)トラフィック問題
- ARPプロキシ
- ARPの情報をどうやって、あらかじめ知っておくのか？
- VXLANはVLANの拡張か？
- VXLANではどうやってカプセリングするか？
- VXLANのオーバヘッドはどうなのか？
- VXLANのオーバヘッドの解決策
- CNMとCNIとはそれぞれ何か？
- CNMとlibnetworkの関連性は？
- kubernetesのネットワーク思想は？
- CNIの代表的なものは？
- flannelとCalico
- flannelの特徴は？
- Calicoの特徴は？
- L3 Fabricとは？
- CLOSネットワークについて
- なぜBGPを使うのか？
- kubernetes Serviceとはそもそも何か？
- Cluster IPとは何か？
収録後補足: ClusterIPはコンテナ（Pod）に直に付くIPではなく、サービスクラスタとして定義されたPod郡へ通信するためのLBのVIPのようなもの、Pod間は別途PodにアサインされたIP同士で通信可能（CNIによる）- kube-proxyとは何か？何をしているのか？
- iptablesを使ったkube-proxyのオーバーヘッド
- IPVSとは何か？
- IPVSを指定した場合に何が起きているのか？
- IPVSはサイドカーで置かれるのか？
- NodePortとは何か？
- NodePortを実際のサービスで使うときは？
- k8sのLoad Balancerとは？
- ingressとは何か？
- k8sにおける名前解決とは？
- IPアドレスを意識して通信しない
- iptablesの沼
- ネットワーク屋さんがiptableを見なくてよくなる世界線はない
- Network Policyとは？
- OpenStackのネットワークと、k8sのネットワークの下回りは同じ
- Linux namespacesとは？
- JapanContainerDays v18.12
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.57 min - 10. 大企業HACKS! - 大企業で実現するイマドキのサービス開発話したネタ
- WebRTCとは？SkyWayとは？
大企業HACKS! 大企業で実現するイマドキのサービス開発とは何か？その定義は？- 大企業のメリットを上手く利用して、大企業のデメリットを上手く回避して働く
- 大企業で何がやばいか？
- 世の中の変化が早い、人材の流動性が低い、変化を恐れる人が多い
- なぜ、変化を恐れる人が多いのか？
- 守る価値がある、プロダクトライフサイクルが長いビジネスを持っているから
- 制約条件がある中で、どう上手くいっていくのか？
- 守りと攻めを意識して分けていく
- 変態ミドル
- 理想的なチームとは何か？
- 相互作用がプラスに働いている状態
- アジャイルマニフェストにある自己組織化するチームを目指すこと
- 勝手にチームが進化していく状態を目指す
- オーナーシップを持ってもらうように、自由・権限を与えて自分たちでコントロールできる感覚をめざすこと
- 目的・意義を示すこと
- 心理的安全性を拡大するための具体的な行動として何をしているか？
- EM.FM
- ミッション・ステートメントは、なぜ必要なのか？
- 内発的動機づけの3要素にある目的
- ミッション・ステートメントは、誰がどう定義するのか？
- ビジョンとミッション・ステートメントの違いは？
- ビジョンは理想の状態を言語化したものである
- 言葉にするのは、夢を実行可能に行為である
- いきなり若者にビジョンを考えろ、というのはアンチパターン
- ビジョンを考えるのはむちゃくちゃ大変
- 飲み会や懇親会のビジョン
- マネージャーがビジョンを考えないのはサボり
- なぜ、若手に責任と権限を与えるのか？
- Think Globally Act Locally はどういう意味で使っている？
- 会社を一生懸命変えるのは非常に時間がかかる
- 大企業をトップダウンで変化させるためのプラクティスは何があるか？
- 社外の実績を使う、草の根のネットワークを作る、社内政治を頑張る
- エンジニアの言語と経営者の言語の両方で話す
- 大企業で戦ってみたときの強みは？
- 経営者に情熱をぶつけるという方法
- 経験の学校、良い経験がしやすい
- 採用するに当たって、何か気をつけている・頑張っていることはあるか？
- 1人の人事と、多くの現場の社員が協力する
- 会議を上手くやるために、気をつけていることはあるか？
- パワポはなぜダメなのか？
- 上から来る兼務の指示に対して、どう部下を守るのか？
- 共通業務・年貢からはできる限り部下を守る
- なぜ内製しないといけないのか？
- ソフトウェアの開発力が、企業の競争力の源泉である
- R&D、プロダクト部門でキャズムを乗り越えるには？
- 大企業で製品を出すために、何が大変なのか？
- 社内には実証実験、外にはベータ版というHack
- R&Dが事業部門にプロダクトを出すときと、事業部門が受け取るタイミングとが異なる
- チームビルディング合宿はなぜやるのか？
- チームの中で意見のぶつかり合いが増えてきた
- 根本的な価値観が違うときに、表面的に話してもダメ
- 性格診断と価値観アンケートを使って全員でレビューしていく
- アンカンファレンスで議論する
- チームビルディング合宿の教科書は無く、自分たちで考える
- 日本の大企業はどうやって、この先生きのこっていくべきか？
- R&Dと事業部門のいいとこ取りの組織を作る
- 失敗するのが苦手、認めない文化
note.muでの記事See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.52 min - 9. エンプラ業界でアジャイルになるためのプラクティスとか、社内/社外勉強会とか話したネタ
- エンプラでアジャイルをやろうとすると何が大変なのか？
- 内製開発がデファクトじゃない
- なぜ内製はデファクトではなかったのか？
- エンプラ業界で内製が増えてきたきっかけは何だろう？
- 通信事業者のルータやスイッチの調達はどのぐらい時間がかかる？
- アジャイル開発センターって何？
- その後のきっかけとなった法人向けのアジャイル案件ってどんな契機で始まった？
- 小さく成功を作って広げていく
- 既存の業務プロセスに、アジャイル型開発はどう付き合っていくか？
- 意思決定をアジャイル開発センターに集めていく
- アジャイル開発センターの隔離
- Cynefin Framework
- アジャイル開発センターをどう設立していったのか？
- アジャイル開発センターって名前はかっこよくないけど、実は意味がある
- ニュースリリースの見出しにのる名前を狙う
- (新しいもの入れる場合に)社外から社内を攻める
- (新しいもの入れる場合に)社内の攻め方 - 擁護者を徐々に増やす
- 彼らのわかる言葉で説明する
- エンプラはしがらみが多い
- 特区によって、社内ルールの一部を特例として認めてもらう、代替手段で守る
- 聞いちゃうとアウトだけど、聞かなければグレーなルールはどうするのか？
- グレーです、と宣言して進める
- 謎のチェックリストが生まれる
- 失敗すると後続が死んでしまう
- アジャイル開発センターの場のデザインはどうしている？
- うなぎの寝床みたいなチームスペース
- Ops専用部署があるにもかかわらず、アジャイルな開発で作ったもののOpsはどうするのか？
- 運用の要件・要求によってOpsのスタイルを分ける
- エンプラは標準化しようとする
- 標準化で決める部分をアジャイル開発センター・チームに権限委譲する、自由度を持たせる
- 大量のガイドライン・チェックリストとアジャイルの付き合い方
- ガイドラインのHowをWhyに戻して考える
- 会社のルールを変えず、現代のやり方を適用する
- 障害が起きるとルールが増える
- ルールを増やしても守れない
- ルールを増やしてもシャドーが増えるだけで意味がない
- 半端じゃない数のチェックリスト
- 誰かが始めないと変わらない
- 運用へ渡すときに自動化しすぎない
- 承認フローをあえて挟む
- 内製をしていなかった企業で、内製エンジニアをどう集めるのか？
- デベロッパーを集めたいなら、デベロッパーコミュニティに行く
- Tech-Onという社外勉強会と、Tech-Inという社内勉強会の目的は？
- 前例があると突破できる
- 前例を知るために社内勉強会ネットワーキング
- 社内勉強会を実際に始めるとすごいパワーがある
- 会社に熱を持っている人は見えてない範囲にいる、隠れている
- どうやって社内勉強会に巻き込んでいったのか？
- 会社の命令で参加させるのはダメ
- 影響力ある人から集める
- ちゃんとした人は、ちゃんとした人を呼んでくる
- ルール化しましょう、というアンチパターン
- せっかく燃えていた火を消化させない
- 70回以上、続けているTechLunchという社内勉強会
- 運営側が燃え尽きない
- 社内勉強会をオープンな場所でやる
- 自分が発信すると、情報が外から入ってくるという体験をさせる勉強会デザイン
- デベロッパーリレーションズを、なぜエンプラでやるのか？
- 社外勉強会で外のモノサシを知る
- 社外で話す、コミュニティ活動をどう社内で評価するのか？
- エンプラだけど、使ってるツールや言語は普通にエッジなもの
- メンバーシップ型社員とスペシャリスト型社員の評価制度は同じで良いのか？
- お客様に価値を届けられる人間が対価を得るべき
- 2018/11/12 Tech-on Meet Up #03
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.1 hr - 8. AWS Aurora、GCP Spannerへ辿り着くまでのDBの進化話したネタ
- 山喜旅館でたまたま会って急遽収録
- これまでデータベースがぶつかってきた問題について
- メモリが高価、HDDはメモリに比べれば安いのでそれを使っていく
- HDDはシーケンシャルアクセスならランダムアクセスより早い
- IBMのInformation Management System(IMS)
- CPUとメモリの間のキャッシュ、メモリとHDDの間のキャッシュの違いとは？
- バッファプールをHDDに対するキャッシュとして使う
IBM ARIESの公開- WAL / Write Ahead Logging
- ログの中にundo/redoの両方が必要
- ログシーケンスナンバによるリカバリ
- バッファプールを食わせるデータ量を増やすのが最適化の一歩
- マルチコア時代への突入、メモリのビット単価の低下
- インメモリDBの問題
- 論文ジェネレータとは？
- データベースは研究のトレンドとしては人気がなかった
- Writeが増えたときのトランザクション性能が伸びない問題
- 垂直分散、水平分散でアプリケーションレイヤが辛くなる話
- AuroraはARIESからDBを理解した人がフルスクラッチで変えたように見える
- AuroraはUndoの情報をログに含めず、Redoを含める
- Auroraの場合は、Redoログを受け取るのがHDDではなくクラウド
- ページの一貫性を担保する責任をクラウドへ押し付けた
- メモリをディスクへ書き戻す必要がなくなる
- Redoログ一辺倒になったのでチェックポイントがいらなくなった
- データベースのチェックポイントについて
- Auroraはマルチマスタ化？
- Auroraのそもそもの思想はシングルマスタ
- 悲観的に巨大にロックを取る
- SpannerはRDBではなく、分散KVSに近い
- Spanサーバの役割
- Spannerを支えるPaxosとは？
- 分散合意の難しさ
- Cockroach DBはAuroraよりベンチマークで1000倍速い？
- TPCCのレギュレーションについて
- SpannerとAuroraの使い分けは？
- 今後のデータベース界隈の展望は？
- クラウドのDBはOracleの牙城を崩しに行く
(補足：32:45-33:43 は収録都合により、別マイクにて再収録しているため音質が異なります)
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.34 min - 7. CI/CDとか、CircleCI自体の設計・開発プロセスとか話したネタ
- 継続的インテグレーション(CI)とは何か？
- 継続的デリバリ(CD)とは何か？
- おかんにCIを例えで説明する
- CIをしていない場合、どこから始めればいいのか？
- たくさんのテストがないとCIを使う意味がない、というよくある誤解
- 最初からクライマックス
- 継続的デリバリと継続的デプロイの定義と差異
- CI/CDの真の力
- CircleCI 2.0とは？
- LXCベースからDockerへの置き換え
- CircleCIアーキテクチャの刷新について
- CircleCI 2.0以外の名前の候補
- CircleCI 2.0は爆速
- gRPCを使いつつ非同期に
- CircleCIはJenkinsと違って何が嬉しいのか？
- Jenkinsのプラグイン運用辛い
- 野良Jenkins問題
- CircleCIに限らずSaaS版のCI/CDで出来なくなることは？
- GPUビルド
- セキュリティおじさんに対する回答
- CircleCI Enterprise
- コード自体がシークレットになってはいけない
- Reprecated
- CircleCI EnterpriseのKubernetesへの移行について
- CircleCI の内部設計とは？
- 自作スケジューラからHashicorp Nomad
- Nomadはバッチ処理に向いている
- CircleCIのQueueとして使われるRabbitMQ
- RabbitMQの運用で困ったこと・苦労したことは？
- CircleCIの内部で使われる言語はClojureについて
- CircleCIも最初はRuby on Railsだった
- CircleCIの開発運用で使うCI/CDはCircleCI
- 自分で自分の足を踏む
- 電動キックボードにハマっている
- 電動キックボードの原付き化
- 電動キックボードを日本で買うといくら？
- CircleCIの開発はどうやっている？アジャイル？
- プロダクトチームが、どういう機能が求められているか吸い上げる
- Jiraを使った管理
- CircleCIリリース時に承認は必要なのか？
- Ship!Ship!Ship!
- 本番環境でテストする
- 継続的デプロイができれば、ロールバック(Revert)も簡単
- 品質管理おじさんが作りたがるチェックリストはある？
- 動いてるんだから良しとする、何かあればFixする
- 継続的デプロイは組織自体も変革する力がある
- コンウェイの法則
- CircleCIにおけるコードレビューはどうやっているのか？
- CircleCIにおけるペアプロ
- paring is caring
- 全世界に分散した開発
- Remote Firstという文化
- お互いに助け合うという文化
- CTOが乱入するお客様対応
- 「今忙しいからできない」とは言わない
- SlackよりZoomを使う
- 100の言葉よりも、1分のZoom
- CircleCIにおけるチームビルディング、All Hands
- Twitter CircleCIJapan
- We’re hiring at CircleCI
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.53 min - 6. モブプログラミング 60分間1本勝負話したネタ
- 一般社団法人 アジャイルチームを支える会
- モブプログラミングとは？
- 1台のマシンを使うのは重要？
- 複数マシンのコードの同期はどうする？
- 各々のマシンの環境が微妙に違う問題をどう対応する？
- ペアプログラミングとモブプログラミングの差分は？
- Whole Team Approach
- 情報同期がキーポイント
- 新規メンバーのJoinやLeaveにどう対処する？
- 情報の足りないメンバーがドライバーをやる
- ドライバーは仕事を止める権利をもっている
- 「わからない」と平気で言えるのが重要
- 「わからない」って言っても良いチームは素敵
- モブプログラミングにオススメの環境は？
- 「うるさいな」って言う人は羨ましい
- 楽しそうに仕事をしているチームは会社全体に影響がある
- 名前をあげて、人を褒めるということ
- チームでよく飛び交うワード
- モブプログラミングはリモートで、できるのか？
- コミュニケーションの不平等さ
- あえて全員リモートで入る
- ナビゲーターとドライバー間でスキル差がある場合はどうするのか？
- 知識の差がある場合にどう対応するか？
- コミュニケーションの多寡の問題
- チームのコミットメントを高めるきっかけとしてのモブプロによる可視化
- モブプログラミングは問題を見えやすくするアプローチ
- マネージャーに入って欲しいかどうか
- モブプログラミングの生産性？
- 生産性を妨げる行動って何なのだろうか？
- よくあるコミュニケーション問題に真正面からぶつかるのモブプログラミング
- 兼務も生産性を妨げる
- モブプログラミングで向き不向きがあるタスク
- 結果の見通しが良いものはモブプログラミングでやる必要はない
- 一方で大体の仕事は問題解決であり、モブプログラミングに向いている
- チームの状態、作業の質をみてモブプログラミングを使い分ける
- 分担するよりも一緒にやったほうが良い、という気付き
- 分担はパラレルで仕事するだけではなく、全体の同期する仕事する時間もある
- ドライバーとナビゲーターは、どういうタイミングで交代するのか？
- 我が家方式による交代
- ドライバーってどれぐらい喋れば良いのか？
- モブプロ、めっちゃ疲れる問題
- どのように休憩(ブレイク)を入れるのが効果的か？
- 休憩の入れ方はチームのセンスが問われる
- ポモドーロと組み合わせた休憩テクニック
- モブコーヒー
- どうやってサボるかを、真剣に考える
- Deepで集中する、Deepで休憩する、Deepでサボる
- モブプログラミングにて、振り返りをどの程度していくか？
- 手を止めて、仕事を俯瞰する振り返り
- スクラムとモブプログラミングの組み合わせはどうやったらいいか？
- モブプログラミングとスクラムは相性が良い
- 1Day Sprintというアプローチ
- プロダクトオーナーやプロダクトマネージャーのモブへの参加度合い
- お客様から直接Feedbackをもらうことに価値がある
- モブプログラミングの中に、お客様に入ってもらう
- 全員プロダクトオーナー
- 管理職・マネージャーをどう説得するか？説得する必要があるのか？
- モブプログラミング実施について説得する必要はない
- より良い仕事をするためにモブプログラミングをしている
- マネージャーはチームが上手く働けるようにサポートすること
- チームの理想をWhatで提示、Howは権限委譲する
- Howに興味があるのは子供扱いしている状態と同じ
- 1on1で上司をメンタリング
- 受け入れてくれるマネージャーは多い
- 双方向メンタリング
- よっぱらったときに書いたコードやばい問題、深夜に書いたポエムやばい問題への対応
- モブプログラミング スタートアップマニュアル
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.59 min - 5. アジャイルコーチ、リーン・アジャイルの考え方、心理的安全性とか話したネタ
- omoiyari.fm
- アジャイルコーチという職種って何やってるの？
- 会社に対するオーナーシップ
- プロダクトオーナーシップが全員必須というわけではない
- プロダクトオーナーシップはあると何が嬉しいのか？
- 1on1におけるフレーミング
- 1on1における本人と業務のギャップが大きい場合の対処はどうすればよいのか？
- リーン、アジャイルとはそもそも何なのか？その関連は？
- スクラムと開発速度の考え方
- 効果と効率
- モブプログラミングは意外とベロシティが出る
- モブプロで浮き彫りになるコミュニケーションの質
- スクラムの何が好き？
- omoiyari.fmのFearlessChangeネタは？
- ykmc09の好きなFearlessChangeのパターン3つ
- Face to Faceで話すことの効果
- 心理的安全性をチームで高めるにはどうすれば良いか？どう場を作ればよいか？
- “雑”ということの重要性
- 大企業/組織における心理的安全性を高めるための社内Podcast
- いつかSIerに戻ってみたい理由
- 生涯でやり遂げたいことはある？
- アジャイル、モブプロにおける人事評価
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.59 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）
245 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