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.

YukiAnzaiさんをゲストに、書籍『冒険する組織のつくりかた』の概要、軍事的世界観、組織文化に変化を起こす方法、などについて語っていただいたエピソードです。

話したネタ

• 『冒険する組織のつくりかた「軍事的世界観」を抜け出す５つの思考法』
• 書籍の概要
• 従来の経営・組織論における「軍事的世界観」（戦略、戦術、目標管理など）
• 偶発性理論（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.

久保さん、有馬さんをゲストに生成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.

• 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とサーバレスコンピューティング

• 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が狭く、振る舞いの種類が少なく、限定であり、実装の詳細に依存しないこと
• コミュニケーションコストにを下げるという寄与
• 系が閉じることによる強さ
• 閉包性とは？

• 論理削除とはそもそも何か？
• 物理削除とは？
• なぜ、論理削除が生まれてくるのか？
• 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/画面設計を作る
• 遅延レプリケーションという解法

• 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アプリケーションのパフォーマンスチューニングコンテスト

• 海外企業でソフトウェアエンジニアで働くための手段
• ビザってなぜ必要なんだっけ？
• 米国のビザってどういう種類があるの？
• 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日のタイムスケジュール、どのぐらいコーディングしているか？
• 英語力は伸びる？
• 英語が分からなかったときの対応スキルが伸びる
• 海外で働いてみてよかった点は、英語の勉強から離れられたこと
• 東京のサラリーマンが、仕事をやめてアメリカで働くために悩んだこと、行動したこと

• サイボウズはどのようなプロダクトを開発しているのか？
• kintoneの競合って？
• サイボウズって外注しているの？オフショアは？
• 組織変更したら部長がいなくなりました
• 部長がいなくなる組織変更する前はどのような組織だったのか？
• マトリクス組織、上長って複数名？
• マトリクス組織において、どのような問題があったのか？
• 職能定義に固定的に考えてしまう
• どのように組織変更を進めていったのか？
• 60組以上に今考えている課題について、ヒアリング実施
• 左右の壁と、上下の壁
• プロダクトチームはどういうメンバ構成なのか？
• 組織変更は、だれが、どのぐらいの人数で、どのぐらいかけて考えていったのか？
• ヒアリング結果は常にオープンに
• 「あれ、俺の役職なくなるんじゃね？」という懸念はあったのか？
• 旧部長の多くは、組織運営チームにJoinした
• マネージャは孤独な仕事であるが、チームを組んで考えるようになった
• 組織運営チームで解決する課題はどのように発見しているのか？
• 発見した課題の優先度付けは？
• Scrum at ScaleにおけるEAT(Executive Action Team)に近い
• EATはエスカレーションされた問題の即日解決を目指す
• 予算系のものの承認は、誰がするようになったのか？
• 予算枠確保よりも、必要なものを、必要なときに使うのが大事
• チームの活動をkintone上というオープンな場に公開する
• 公明正大が会話にまで浸透している
• チーム間の異動は自由にできるようになったのか？
• チームメンバに(社内)採用の権限を落とした
• 体験入部制度
• 公開されているJob boardでの応募はどのようにすればできる？
• 人気のあるチームに集まっちゃう問題？
• レガシーとなったプロダクトのチームで解く課題の人気
• 組織変更後の給与評価はどのようにするようになった？
• メンバの活躍をどのように把握しているのか？
• 市場価値として、社内＋社外の評価を利用している
• アジャイル開発のフレームワークは何を使っている？
• スクラムチームはどの程度ある？
• スクラムチーム間の情報交換はどうしている？
• 開発ツールとしてのコード管理は何を使っている？
• 徐々にGitHub Enterpriseから、GitHub.comの利用へ
• RSGT2020

• 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

• ソフトウェア・ファースト
• 製作委員会のnote
• 書籍執筆の動機
• エンジニアのためのマネジメントキャリアパス
• DXという言葉は使いたくなかった
• ソフトウェア・ファーストという名前がついた経緯
• モバイルファースト、AIファーストとの対比
• ソフトウェアを活用をいかにできるかを、企画から運用まで考え続ける
• トランスフォーメーションより変革という言葉
• 人と組織を変える気がないDX
• RPAは変革の途中であり、小手先の技術
• 4GLやEUC
• エンプラの技術的負債の解消？
• 事業会社がSIerへ丸投げするのは、負債の発生
• 内製化、手の内化
• メンテできるかは、技術的にのみならず、やりたいかどうかも含めて考える
• 常に触り続けるのが、負債化を避けるのは王道
• Google エンジニアリング・プラクティス ドキュメント
• 1章 ソフトウェアファースト のサマリ
• 2章 IT・ネットの“20年戦争”に負けた日本の課題と光明 のサマリ
• 日本でIT産業の競争力を失った理由
• IT産業は製造業を模倣しているが、実際は模倣できていない
• なぜ、製造業ではオーナーシップを保っているのか？
• ものづくりにおける技能オリンピック
• 経営層がITを理解しているかどうか
• 役員の中にソフトウェアがわかる人が何人いるか？
• ソフトウェアがわかるとは、どの程度まで理解していればいいのか？
• 幹部や経営層にどのような教育をお願いすればいいのか？
• 日本の経営者がITを理解できないのは、お友達が悪いから
• さくらインターネットの田中さん
• 3章 ソフトウェア・ファーストの実践に必要な変革 のサマリ
• DXの勝者と敗者：ネットフリックスとブロックバスター
• 経営陣のITリテラシ、風通しの良い組織文化、会社のミッション
• セブンペイ
• 某元国営企業のアプリ
• 技術を分かってる経営層を増やすには？
• 前回同様に、やっぱり辞めちゃえばいい、辞める気で変える
• Google TGIF
• 社内システムのリバースエンジニアリングから技術の価値を見せる
• 4章：これからの「強い開発組織」を考える のサマリ
• 5章：ソフトウェア・ファーストなキャリアを築くには のサマリ
• 組織を作るのはプロダクトを作る人、人事はサポート
• 組織に対するオーナーシップをどうやって持ってもらうか？
• 組織はコミュニティと一緒である
• 書籍の制作秘話、何が大変だったのか？
• 受託開発のように受け身で執筆してしまっていた
• ペルソナを後で書いた
• 書籍が、自分の分身になっていなかった
• 3万字を捨てる決断
• プロダクトマネージャーカンファレンス 2019
• プロダクトマネージャーカンファレンスを始めたきっかけ

• Segment Routingとはそもそも何か？
• Segmentはどういう単位か？
• Source Routingとの関連は？
• Segment Routingで、どういう問題が解けるのか？
• 現在のバックボーンネットワークにおけるMPLS
• MPLSでネットワークを構成したときの課題
• Segment RoutingだとNetwork Nodeが、よりステートレス
• Segment Routing MPLSの動きは？
• Segment Routing v6では、どういう拡張ヘッダを付与する？
• Segment Routing Header(SRH)
• Segment IDは128bit
• SRHはネットワークノードで剥がすのか？
• Segment Routingだからこその特徴は？
• SRv6は世の中でどういうフェーズか？
• IETF側で基本的な部分は決まってきている
• SRv6の実装状況はどうか？
• Juniperの指摘はSegment IDが広いという点
• Kamueeって何でしたっけ？
• InteropにおけるShownetとは？
• InteropでKamueeをどう組み込んだ？
• Service Chain周りで組み込んだ
• Service Chainでは、どんな機能がつながった？
• SRv6だと、Security Functionと上手くいかない部分がある
• SR Proxyという機能
• SRv6に対応していない機器が、SDHを見たときにどう動く？
• SRv6の実装はどの辺が大変だった？
• VRF(Virtual Routing and Forwarding)とは？
• パケット作るのは簡単
• VRFにおけるルーティングテーブルの選択ロジックは？
• Kamueeのネットワークデバッグ機能とは？
• SRv6の課題は？
• ソフトウェアルータの課題は？
• Segment Routingは自由研究のネタになる

• CTOの1日ってどんな感じですか？コードは書きますか？
• 会社の経営戦略と人事制度（等級制度）との関連
• 等級（グレード）ダウンってありえる？
• 報酬はどのように決定しているのか？
• 技術力評価制度はどのような全体像・プロセスなのか？
• 評価のすり合わせは、なぜ実施するのか？
• 評価者2人はどのように選定しているのか？
• 定量的な評価を最初になぜ導入したのか？
• 人の給料を決めたくない
• 評価制度とグレードの昇給ってどういう相関？
• 技術力評価制度の社内の満足感はどうか？
• 自分の成長につながるフィードバックをもらえるのが大事
• 評価する側にも学びが多い
• Voyageグループでは開発チームごとに色を出して良い
• 全社での技術ガイドラインはあるのか？
• ない、事業特性と技術特性を考慮して決める
• 流行りで技術選定しない
• 好きな技術をねじ込んでくる機会はあっていい
• 新しい技術を浸透するための勉強会などは自主的に発生する？
• 今までの延長業務でも、新しい技術を学び選択肢を増やす
• グレードを上げる判断基準は何か？
• CCFB(360度評価)の評価項目は何か？
• AmazonのLeadership Principle
• エンジニア職種以外に技術力評価制度を応用可能か？
• (技術力評価制度の)全体振り返りはどのようにやっているのか？
• 次に活かすTry項目はどのように決定するのか？
• 評価制度も自分たちでエンジニアリングしていく
• 新卒・中途採用はどのように改善したのか？
• 中途向けの面接の同席から始めた
• 評価会を通じて、採用スキルが上がる
• どのタイミングで、面接の同席を辞めたのか？
• 最悪な状況を理解して、そこさえならなければやり方を任せる
• 採用における最低のラインとは何か？
• 新卒研修をどのように変えていったのか？
• 新卒入社研修を結果的になくした
• チームとして、新卒を受け入れて育てられるスキル0
• アジャイル戦略室では何をしたのか？
• アジャイルは思想
• 振り返りの文化を根付かせる
• 振り返りでよく話す人、あまり話さない人
• インターンシップ面白すぎでは？どのように決めているのか？
• いかにインターンで、学生向けに目立つか？
• 講義をしっかりすることで学生に訴求した
• エンジニア募集中
• 2019/8/31 builderscon のランチセッションで ajito.fm の公開収録！

Autify CEO の近澤さんをゲストに、Aufity社のプロダクト組織やプロダクトの開発方法などについて語っていただいたエピソードです。

話したネタ

• Autifyの組織はどのように成長していった？
• CTO を設けていないのは？
• 組織の戦略、事業目標はどういうタイミングで考えている？
• コンテキストスイッチの多さへの対応方法
• Autifyの組織構成
• EM と Dev の比率
• PdM と Designer の配置
• 日本人が少ない開発組織で何か気をつけていることは？
• PdM はどうやってPRDを書いているのか？
• バーニング加減を探る
• n=1 をめちゃくちゃ大事にする
• 誰が、どういうシチュエーションで、なぜこうなっているの、何人言っているのか、金額価値は？
• 3つの変数：課題の大きさ・金額・実装コスト
• 基本はスクラム、2週間スプリント
• プロダクト開発からの学びをどう活かしているか？
• 実装コストが高いものは先にデモを作る
• オンボーディングプロセスはどうしている？
• エンジニアが入ってからプロダクションへの初めてのPRを出すまでの期間は？
• オーティファイ株式会社 採用情報

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

• EM.FM
• エンジニアリング組織論への招待
• エンジニアリングの定義とは？
• エンジニアリングとは不確実性を減らすプロセス
• 間に落ちてる仕事
• 多くの仕事で出くわす人の多くは良い人
• 構造によって良い人たちが感情的な対立を起こしている
• 透明人間、構造の力、空気、アーキテクチャ
• コードから書いた人、気持ちがわかるようになってきた
• 一番負債はコード変更履歴からTrackしていくのは見栄えがいい
• Cyclomatic complexity
• 知らない、わからないという恐怖は根源的なもの
• 人間はハードウェアの機能として、第一に動物である
• 本能は漏れのある抽象化をして、理性的な面を描いている
• その人のことが嫌いだよね、ってのを一般論として話す
• 多くの問題は学校の問題ほど難しくない
• 問題発見をし、明晰化する学問が弱い
• バイトを100人動かすマニュアルを書くより、EC2インスタンスを動かすほうが簡単に
• 思考のリファクタリングをすると外部入出力は変わるのか？
• 目的という抽象をもって、手段という階層をリファクタリングする
• Developer ExperienceとDigital Transformationという2つのDXとは？
• 内製化はいままで外部に持っていた異質なものを取り込む過程である
• エンジニアがビジネスのラインに自然に入り込んでいく
• マーケタもSQLを書く
• コンピュータが具体的な仕事から、より抽象的な仕事をしていく過程
• 組織というベクトルだけで解を出せないが、別の軸から解を出せる
• 仕様を決めることと、ソフトウェアを書くことが同じになっていく
• 文化的なギャップを順番に溶けていくように進めると良いが、一気にいくとハレーションが起きる
• ハレーションを恐れすぎると何もしなくなる
• エンプラに属しているエンジニアはどうやってこの先生きのこるべきか？
• 1,2回転職したらいいんじゃないか
• ロイヤリティからエンゲージメントへ、労働者と使役側が対等な関係へ
• シンプルを作るのは非常に難しい
• ソフトウェアに社内事情を組み込みすぎている
• マーケットの原理で物事を動かせない
• なぜエンジニアが流出するのか？
• 正当なリスペクト、周りに優秀な人がいる、透明性のある社風
• 価値観が違うと、甘やかすことすらできない
• その人が何を求めているのか紳士に向き合う
• なんで辞めた人に理由を聞かないの？
• リスペクトっていう概念が理解されていない問題
• 尊敬しているというのは、その人に興味を持ち、理解する過程である
• rector

• アジャイル開発で採用しているフレームワークは何か？
• スクラム、XP、モブプロ
• スプリントのタイムボックスは？
• 補足: POCとは
• スプリントプランニングどのぐらいの時間をかける？
• なぜ、1日スプリントにしたのか？
• スプリントプランニングには、SM/PO/Devの誰が参加する？
• 自分たちのモノ（社内のシステムなど）を作るのを並行してやる
• 空いている時間で新しい技術を触り続ける
• デザイン思考のワークショップには、開発チームが参加する？
• アイデアを本当に形にできるか、というのを重視ししている
• 開発時にお客様は同席する？
• プロキシPOを立てることはあるか？
• プロダクトバックログはいつ作っているのか？
• プロダクトバックログへのアイデア貼り付けはいつやっても良い
• アイデアの粒度はどの程度で書くか？
• 最近のトレンド・技術を勉強しておかないと、顧客に価値を短期間で届けない
• 学習専用の時間はあえて確保しているのか？
• アウトプットと同じぐらい、次のインプット時間が必要と考えている
• モブチームはどのように取るタスクを選ぶのか？
• Definition of Done、Acceptance Criteriaはどのように規定しているのか？
• 自分たちが状況を考えて、いまのお客様の欲しいものを仮説として考え、作り上げることを大事している
• 振り返りの手法は何を使うか？
• Fun, Done, Learn
• 振り返りのコメントはどのようなものが出るのか？
• わかりません、というのを自信を持って言いたい
• 各モブごとの振り返りと、全チームの振り返り
• Tryを蓄積していく、TryのRefinement
• インセプションデッキは作るのか？いつ作るのか？
• デザイン思考のワークショップはどの程度実施するのか？
• POC開発・検証後はどのように進めていくのか？
• チームビルディングはどのタイミングで、何を実施するか？
• オンボーディング向けに気をつけていることはあるか？
• プログラミング経験ゼロの人向けの育成モブ
• KDDI DIGITAL GATEでエンジニア募集中
• どんなエンジニアに来て欲しいか？
• アジャイル開発体験会

• DECって会社は何をやっていた？
• IBMと7人の小人達
• メインフレームに対するアンチテーゼ、ミニコンピューター
• NEC PC-9801が大流行した時代
• この時代の日本のIT企業は何をしていたのか？
• 通産省とのタッグ
• 富士通、日立、NEC、日本IBMで市場を分け合っていた時代
• ソフトウェアはハードウェアのおまけだった
• SIerという名前が生まれてきた背景
• 当初は何と何をインテグレーションしていたのか？
• トークンリングとイーサネット
• 90年代の日本の技術者は、どのような開発をしていた？
• ユニコードがない時代なので、国際化は大変な仕事だった
• IT業界の下請け構造はどの時期から発生しはじめたのか？
• Unixがのるワークステーション vs Windowsがのるパーソナルコンピューター
• デヴィッド・カトラー
• Windows95のこの時代もUXが優れていたのはAppleだった、ただこの頃のMacは不安定だった
• AppleTalkは素晴らしかった
• 90年代の日本のIT企業は強く、ソフトウェアの出来はとても良かった
• オープンシステム流行の背景
• エンドユーザーコンピューティング
• 4GL
• なぜ、この時代の日本製品のソフトウェア品質が高かったのだろうか？
• UIのちょっとしたミスが製品全体の品質の疑いにつながる
• 一番やってはいけないのはリコール
• 現代のWeb向けのサービスは、リリースまでに直すもの、リリースしてから直すものを分けて考える
• ITに対する捉え方の違いが、国内・国外との差を広げたのではないか
• ヨーロッパ、アメリカ、日本のソフトウェアの捉え方の違いは？
• 科学・製造・ビジネス
• 経営者自身がソフトウェアを攻めの道具として捉えたのが米国だった
• 日本と米国の状況は危機的、スピード感が違う
• 日本では、減ってきたもののIT/ソフトウェアの価値をまだ理解していない
• 及川さんのエンタープライズ向けのDXセミナーは娯楽
• 静かに暮らしたい人たち
• 年功序列、終身雇用、企業内組合という三種の神器
• 安定を望む人も多いが、もうそんな場所はない
• むしろ自分自身に自信を持てることが安定につながる
• 米国的なジョブ型採用があるからこそ、社会・産業全体の最適化につながる
• 社内のマイノリティの動きを、いかにしてメインストリームにもっていくか？なぜ難しいのか？
• 新しいことにチャレンジするコストよりも、転職するコストのが安い
• みんな辞めればいい、そうすれば経営者は危機感を持つ
• Exit Interview
• 人は会社と心中する必要はない
• 本当に古い会社が変わらないといけない危機意識を持つために人材流動は大切
• いつでもやめられる、けどやめない社員がいる会社は強い
• 辞める気になって会社に働きかけてみましょう、本当にやれることを全部やってますか？
• 井深さんの「説得工学」
• 足りないのはやり切る覚悟
• 一番必要なのはアントレプレナーシップ、起業家精神
• 本当にあなたが成し遂げたいときに、どこまで覚悟をもってやっていますか？
• オーナーシップを持って進めるのが少なくなってきているのではないか
• 日本は、誰かがやったものをより良くやるので上手くいっていた民族なのでは？
• 他国のをまねして上手く仕上げて、外に出せばいい
• スタートアップと同じことを、大企業でなぜできないのか？
• アマゾンの成功から日本の部品メーカーが学ぶべき理由
• 最初のiPhoneにはSDKがなかった
• まず自社の体験でユーザ体験を作り上げて、徐々に広げていく戦略
• どのタイミングで、AmazonはAWSを始めようと判断したのだろうか？
• リテール業界でAWSを使わなくなる傾向
• IT業界でいうエコシステムは、プラットフォームが絶対に勝つエコシステム
• Mircosoftの遡上である開発ツールのプラットフォーム化
• 部品メーカーも思想を変えれば、プラットフォーム化できる
• nVidiaは部品メーカーからプラットフォーマーへの例
• 日本で足りない役割としてのBizDev、パートナー開拓
• (エンプラで)内製したい若者が、上の人を説得するときにどう説得・行動すればよいか？
• エンジニアとエンジニアじゃない人が組む社内ハッカソン
• 採用は一種の営業活動である
• 組織、環境を魅力的にして外に広報していく働きが必要
• 採用に本当に困ってるんだったら給料を上げればいい
• エンジニアを引きつける3つの魅力
• 雇用条件・給与、プロダクト・ミッション、技術者としての面白さ
• 3つ出来なくても、1つは突き抜ければ良い
• 技術的に魅力的がないところには、優秀なエンジニアは来ない
• エンジニアが他の職種と違うところ
• 高い課題設定を魅力設定として打ち出す
• リファラル採用はやったほうがいい、なぜか？
• 本当に紹介できる・できないのリトマス試験紙になる = エンジニアのリテンションリスク
• 「いやー僕はいいんだけど、こいつは誘えないな」というときの理由
• 大企業が変わらないと、日本は変わらない
• エンタープライズから日本を変えていけると楽しいのではないか

• NTTComを退職してNTTComに入社します
• NTTComを退職してスペシャリスト社員になって1年ちょっとたちました。
• メンバーシップ雇用とは何か？
• スペシャリスト雇用とは何か？
• 変則ミッショングレードという制度
• Inside “Security Operation Center” ～セキュリティ人材を生かす５つの改革～
• メンバーシップ雇用は何が良くて、何が悪いのか？
• 特定のスキルを持った人の報酬が定義できない
• 市場価値と比べて低い給料になり、入社が減少し、退職が増加する
• やりたいことが曖昧な場合には効果的
• Planned Happenstance Theory
• スペシャリストとメンバーシップを選べる、移動できるような柔軟性が求められる
• スペシャリストである、となぜ公言しにくいのか？
• 役職定年、中途採用、転職に対するカウンターオファー（引き止め）
• 社内のエンジニアのモチベーションを上げたい
• メンバーシップからスペシャリストに変わるような生き方、選択肢を当たり前に
• 中途採用が上手くいく秘訣は何か？
• 自分たちの仕事が魅力的であることを発信する
• 採用制度を独自に作り上げる
• 技術試験を採用プロセスに含める
• パケットキャプチャをあえて改ざんして、応募者に解析してもらう
• 本質的な理解をしているか、確かめる
• バイナリで読めるのはBGPだけ
• スペシャリストになって、何が具体的に変わったのか？
• 福利厚生は変化、お給料もある程度上がった
• 評価の仕組みが大きく変わった
• 評価の指標は、エンジニアリングマネージャーとすり合わせて決める
• 1年前の目標って古すぎないか？
• 給料爆上げ
• 隗より始めよ
• 働いてる環境ってどんな感じ？
• Security Operation Centerでの個人環境
• メモリは16GB
• G Suite、Confluence、Jira、Slack
• 社内システムはクローズドなので、使いにくい
• アジャイルな開発・コミュニケーションを促進する新オフィスを作りました - Lean Agile Base
• 会社の悪いところは？
• プロフェッショナルな人材が、マネージャー層より上に少ない
• Executiveの中途も進むと良い
• 雇用制度の違いによる利害の不一致
• (ep.15から)高度なスキルほど、サポートがないとパフォーマンスが出ない
• 従業員満足度が上がり、退職率が下がると、会社としての給与引上げ圧力が弱まるという課題にどう対処するか？
• 業務として、チームとして成果を出して経営へアピールすること
• 個人として転職活動を常日頃しておく
• 業界を盛り上げること
• ラグビー部のおしかけってあった？
• 大手町の綱引き大会で優勝
• ラグビー部社員はスペシャリスト
• なんで、まだ会社に残っているの？
• ジャパニーズ トラディッショナル ビッグ カンパニー
• 会社に対する愛はある
• （難しい環境であっても）いかに変えていくのか、に面白みを感じる
• 契約と、それに基づいた評価の規定
• 対外発表を契約項目に含める
• 一定額の給与で裁量をもたせて、やらせてほしい
• 古くからある企業で、変わり始めてる事例を紹介するエピソード
• （出演者全員）中途採用してます！

• スタートアップ組織開発勉強会_scoutyの組織開発理論と実践
• 良い組織とは何か？
• 組織と複雑系とは？
• 複雑な仕組みと複雑系の違い
• 組織は複雑系である
• 採用だけ頑張っても、働く仕組みがイケてないと人は去っていく
• HRに関わるあらゆる領域に対して総合的に取り組む
• 数字でしか語れない人は害悪である
• VUCAに代表される時代
• 社会が画一的で、成長している時代ではない
• ジョブ理論とは何か？
• イノベーションのジレンマ
• 機能的側面・感情的側面・社会的側面
• OKRとは何か？なぜ必要になってきたのか？
• OKRは、当人がパフォーマンスを引き出すためのツール
• KPIを単純に分解して、達成率を目指す形だとパフォーマンスが出ない
• MBOに対する誤解
• ウォータフォール開発の論文に対する誤解
• 言い訳のための仕事を増やしてはいけない
• MVP、デザイン思考、リーン、OODAの共通点は何か？
• 不確実なことは必ず起きるという前提に立つ
• OODAとは何か？
• 良い問いと学習が重要
• そもそも、「良い問い」とは何か？
• SEDA理論とは何か？
• 当たり前だったものを当たり前じゃなくするのがArt
• SECIモデル
• パフォーマンス = (モチベーション - 阻害要因) * (スキル - 阻害要因)
• 個人のモチベーションとは何か？
• 自己決定理論
• 外発的動機付けの分類とは何か？
• 統合的調整、同一化的調整、取り入れ的調整
• モチベーションを上げるためには、どうすればいいか？
• モチベーションを高めるのはできると思っていない、いかにモチベーションを邪魔しないかが大事
• メンバーシップ採用とジョブディスクリプション採用
• モチベーションを阻害するものは何か？
• 責任の不備とは、具体的には何か？
• 本人が持っているスキルよりも、チャレンジできる課題を与えるのが大事
• スキルというものは変動性が高い、アウトプットである
• スキルの阻害要因とは何か？
• 高度なスキルほど、サポートがないとパフォーマンスが出ない
• 簡単な仕事は、関係性の影響が少ない
• 複雑性の高い仕事になればなるほど、自身のパフォーマンスを理解しにくい
• 組織が掛け算である、というのが幻想である
• その人の良さを下げないようにするのが、組織として大事
• 組織としての完成形
• Total Rewardsとは何か？
• 自分の人生と、会社の方向が重なっているのも大事
• No Ratingとは何か？
• 人は人を正しく評価できないのは前提
• お互いの納得感を重視した評価
• 期末に活躍した人が高く評価される、目の前の状況に引きづられやすい
• 心理的安全性を根付かせるためにはどうすればいいか？
• 心理的安全性はやさしさではない
• ティール組織とは何か？
• ティール組織の3要件とは
• ホラクラシーとは何か？
• Role自体に権限と責任、目的を明示する
• 自律的に組織が変えて、世の中の変化に適合する
• 寄生獣の後藤
• ディスコースとは何か？
• 社会構成主義
• 組織の壁をどうやって埋めていくか？
• ダイアログとは何か？
• お互いの一致していないものを探す場
• GoogleのTGIF
• 日本の未来をちょっとだけ明るくしたい
• LAPRAS

(一部のPodcastクライアント用に再掲) 320KZCDさんをゲストに、組織にまつわるネタ(ジョブ理論・OKR・SEDA理論・No Rating・ティールなど)について語っていただいたエピソードです。

• なぜ、企画と開発が責任を押し付け合う会社の前途は暗いのか？
• 計画が悪い 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人と有機的に増やす
• “アジャイル開発の教育を行い、徐々に経験者をふやすこと”の理由は？
• 効率良くやるためには、形式的知識伝達もやる
• 全体的な体系をわかった上で実践に入る
• “技術力のあるエンジニアを招集すること”
• 結局、スクラムの教育をいくらやっても、作れないものは作れない、ウォーターフォールも同じ
• 技術力のない人がものづくりをするのはおかしい
• パワポという黒魔術にひっかからない
• エンジニアの召集という言葉の意味
• “コミュニティへのエンジニア参加を推奨し、外部交流を行うこと”
• 熱を受け取る場面
• この人と出会った、この人の話を聞いて人生が変わったという転機
• 会社で誰かがイベントに参加したい、といったら是非是非出させてあげるべき
• （イベント参加の）報告書は別にいらない、その人の中に溜まる
• ワンクリックデプロイ ∼いつまで手でデプロイしてるんですか？∼
• 会社は度量を持つ
• 会社からの退職者数の傾きを見る
• 古くからいるマネージャーの役割はどうなっていくのか？
• 得意なことで、変化の中心になっている人を支援する
• 上からじゃなくて、新しいバリューシステムの一部になれるか、気持ちを持てるか
• 取締役からのメッセージも重要
• バリューを出せる人は、どうやってもバリューを出せる
• アジャイルスタジオ福井で見学募集中

• ペアプロにおけるビギナーとベテランの組み合わせ3パターンについて
• ビギナーとビギナーの組み合わせで効果はあまり期待できない（チームビルディングでは意味がある）
• ベテランとベテランは、一番効果を発揮するペアである
• 意思決定をライブでできる重要性
• 設計上の妥協点をその場で合意できる
• ビギナーとベテランで、ビギナーはナビゲーターをするのか？
• コードを書いてるところを見てもらうのは大事なプラクティス
• ベテランもプレッシャーを持ってコードを書ける
• 見られているだけでコードの質は高まる
• リアルタイムでないコードレビューがあるだけで、コードの質は高まる
• コードレビューのインフラに投資する
• 流しのペアプロ業をする中で、ドメイン知識がない状態でペアプロへ参加して価値をだせるか？
• 一番の学びは教えることから発生する
• 相手から、相手自身の学びを引き出す
• チームの暗黙知を、暗黙知のまま伝える、強化していく
• テストを書く場合に、RDBやKVSなどをどこまでモック/スタブするのか？
• ノートPCにインストールできるものは本物を使い、入らないものはモック/スタブを使う
• プライベート関数はテストするのか？
• 技術的には、プライベート関数のテストはパブリック関数からテストできる
• プライベートの実装に基づいたテストは脆い、現状追認のテストになりがち
• フロントエンドのテストはどこまで書けばいいのか？
• 書くけど、書きすぎない
• 画面の構造が変わっても、影響にされにくいものをテストする
• ビジュアルリグレッションテスト
• 魑魅魍魎のUIの世界
• テストのカバレッジ、どの程度まで書けばいいのか？
• ユニットテストを含めて、グレーボックス・ブラックボックスの観点から書くのが望ましい
• カバレッジは何らかの管理の道具にすると、うまく回らない
• 不具合は思い違いから発生する
• カバレッジ100%は誤った安心感を与えがち
• カバレッジツールは自分達の見落とし・過信を見つけるために使う
• カバレッジを絶対値ではなく傾きでみる
• CIではテストの成功/失敗だけではなく、カバレッジやコードの複雑度を取る
• バグ収束曲線は、現代の開発ではFitしないことのが多い
• 品質指標の形骸化
• 外注が多く、内製が少ない組織で、ソフトウェアエンジニアをどうやって育てていけば良いのか？
• 内製にシフトするなら、技術者のhiringも必須
• 小さく始めて、大きく育てて勝つパターンを積み上げる
• 段階的に内製開発にシフトしていく
• 社内の特区、信頼貯金を使って展開していく
• 内製を全然していない会社が、内製にシフトするためには4-5年かかる
• 新人を育てるためにはどうしたらいいか？
• 配属ガチャ
• 技術力の高いエンジニア新人を孤立させない
• 事業部内に閉じた情報流通
• 全社Slackがないのはよくあるサイロ化
• 技術者の横のつながりを維持する、リアルタイムコミュニケーションのチャネルを作る
• 内製を始めるモードになったエンプラ企業はイメージ付けが必要
• 技術者が社名を背負ってアウトプット
• 大企業Hack
• 意思決定層にこれからのソフトウェア開発に認識を改めてもらう
• 組織やチームにノウハウをどうためて、育てていくのか？力を貯めるいいやり方？
• 再現可能にするのが大事
• 前提が違う、変動する中でソフトウェア企業としての強さを保つ
• 公開し検索可能にすることが大事
• URL重要
• 心理的安全性の重要性
• 価値観から行動原則、品質基準を考えていく
• 経験していない場面にチェックリストは効かない
• 誤っていたこと、失敗は良いチャレンジとして評価されるように
• 社内でアンチパターンを共有できる組織は強い
• 社内FailCon

• 古くから大企業・組織で、ryuzeeさんならどう切り込んでいくか？
• 現場だけで変えられる範囲には限界がある
• 組織改革を若手がやるのは厳しい
• ボトムアップでやるには気の遠くなる話が多すぎる
• ミドルマネージャーや意思決定の権限を持つ
• 改革の範囲を全社ではなく、自分の部だけにする
• 徐々に広げていくのは、ボトムアップでは鉄板
• トップダウンでいく場合は、ミドルマネージャーが障壁になりやすい
• 全社ルール・ガイドラインと、どう付き合っていけば良いのか？
• 複数のガイドライン/オプションを用意しておく
• ガイドラインをかならず守らなきゃいけないのは思い込みなこともある
• 緩い、自由があるガイドラインだと進めやすい
• 権限委譲が非常に難しいのではないか？
• 権限のないプロダクトオーナー問題
• プロジェクト開始の時点で、決められる範囲の線引き
• 大きな会社になればなるほど、スクラムマスターが重要
• スクラムマスターの役割は半端じゃなく大変
• 大きな会社だとチームの外側に課題がある
• スクラムマスターは大きな会社のプロパーがやるべき
• プロダクトオーナーとスクラムマスターはチームの内外でバランスをとる
• プロダクトが目に見える成果を出してないケース
• プロダクトを売らずに、組織改革ばっかりしてもしょうがない
• 綺麗事ばっかり言ってるのはダメ
• 失敗することは是である
• 傷の浅いうちに、ダメなものを見つけてサービスを畳めるのも成功である
• 弾をたくさん投げるのが良いこと
• 出島とは？
• 全員同席、外部から雑音をシャットアウトする
• エンドポイントを一箇所に絞る
• 治外法権
• 人気ある部門へ人が集まりやすいが、過疎化はどう防ぐ？
• お金を稼いでるけど、不人気な部門の問題
• 辞めるにしてもいい関係で辞めてもらう
• 給与テーブルが自由に設定できない問題
• やりたいことができるように、また仕事しやすい環境を与える
• 周囲のバックオフィス系の部門にどの程度、アジャイル的な考え方を理解してもらうのか？
• バックオフィスは、プロジェクト開始時に巻き込んでおく
• たとえば品質管理部門の人に入ってもらって、完成の定義を考える
• AWSでShip判断
• us-east1から他リージョンへのロールアウト
• 開発チームはどの程度、顧客の声を知る必要があるのか？
• チームが無関心なのは一番辛い
• サポートエンジニアを一緒にやるプラクティス
• 開発と運用のチームは結局どうしていけばいいのか？
• 基本的には1チームが良く、部門が別れているならバーチャルチームで1つに
• 少数精鋭のチームでものづくりすると、運用しないように寄せていくことで、本業に集中する
• 必ずしも新規技術を使う必要はない
• チームの力量・状況にあわせて、技術や言語を選んでいく
• 1week sprintの振り返りだと、長期的な課題がでにくい？
• ベロシティを1.5倍、2倍にするためには何したらいいの？
• KPTは断面を切る振り返りであり、時間軸があまりない
• 振り返りは適度に変えていく
• 闇鍋という振り返りプラクティス
• ドット投票における問題
• 給与査定という観点での人事評価はどうやればいいか？
• プロダクトの結果が出ていれば、個人の評価はどうでもいいのでは？
• チーム一律評価 + 360度評価 を組み合わせるのが落とし所
• 新サービスを出したばっかりのPOはどう評価するか？
• 人事部とエンジニアの採用プロセスの関わり？
• アトラクタでお仕事募集中

• 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

• WebRTCとは？SkyWayとは？
• 大企業HACKS! 大企業で実現するイマドキのサービス開発とは何か？その定義は？
• 大企業のメリットを上手く利用して、大企業のデメリットを上手く回避して働く
• 大企業で何がやばいか？
• 世の中の変化が早い、人材の流動性が低い、変化を恐れる人が多い
• なぜ、変化を恐れる人が多いのか？
• 守る価値がある、プロダクトライフサイクルが長いビジネスを持っているから
• 制約条件がある中で、どう上手くいっていくのか？
• 守りと攻めを意識して分けていく
• 変態ミドル
• 理想的なチームとは何か？
• 相互作用がプラスに働いている状態
• アジャイルマニフェストにある自己組織化するチームを目指すこと
• 勝手にチームが進化していく状態を目指す
• オーナーシップを持ってもらうように、自由・権限を与えて自分たちでコントロールできる感覚をめざすこと
• 目的・意義を示すこと
• 心理的安全性を拡大するための具体的な行動として何をしているか？
• EM.FM
• ミッション・ステートメントは、なぜ必要なのか？
• 内発的動機づけの3要素にある目的
• ミッション・ステートメントは、誰がどう定義するのか？
• ビジョンとミッション・ステートメントの違いは？
• ビジョンは理想の状態を言語化したものである
• 言葉にするのは、夢を実行可能に行為である
• いきなり若者にビジョンを考えろ、というのはアンチパターン
• ビジョンを考えるのはむちゃくちゃ大変
• 飲み会や懇親会のビジョン
• マネージャーがビジョンを考えないのはサボり
• なぜ、若手に責任と権限を与えるのか？
• Think Globally Act Locally はどういう意味で使っている？
• 会社を一生懸命変えるのは非常に時間がかかる
• 大企業をトップダウンで変化させるためのプラクティスは何があるか？
• 社外の実績を使う、草の根のネットワークを作る、社内政治を頑張る
• エンジニアの言語と経営者の言語の両方で話す
• 大企業で戦ってみたときの強みは？
• 経営者に情熱をぶつけるという方法
• 経験の学校、良い経験がしやすい
• 採用するに当たって、何か気をつけている・頑張っていることはあるか？
• 1人の人事と、多くの現場の社員が協力する
• 会議を上手くやるために、気をつけていることはあるか？
• パワポはなぜダメなのか？
• 上から来る兼務の指示に対して、どう部下を守るのか？
• 共通業務・年貢からはできる限り部下を守る
• なぜ内製しないといけないのか？
• ソフトウェアの開発力が、企業の競争力の源泉である
• R&D、プロダクト部門でキャズムを乗り越えるには？
• 大企業で製品を出すために、何が大変なのか？
• 社内には実証実験、外にはベータ版というHack
• R&Dが事業部門にプロダクトを出すときと、事業部門が受け取るタイミングとが異なる
• チームビルディング合宿はなぜやるのか？
• チームの中で意見のぶつかり合いが増えてきた
• 根本的な価値観が違うときに、表面的に話してもダメ
• 性格診断と価値観アンケートを使って全員でレビューしていく
• アンカンファレンスで議論する
• チームビルディング合宿の教科書は無く、自分たちで考える
• 日本の大企業はどうやって、この先生きのこっていくべきか？
• R&Dと事業部門のいいとこ取りの組織を作る
• 失敗するのが苦手、認めない文化
• note.muでの記事

Autify CEO の近澤さんをゲストに、Autifyのバーニングニーズの見つけ方、事業進化、生成AIによる影響、ソフトウェアテストの未来などについて語っていただいたエピソードです。

話したネタ

• 顧客のBurning needsを解決する
• Autify は「誰の」「どんな課題」を解決したのか？
• Founderが売れない製品は絶対売れない
• 顧客の意見を聴くためにアンケートは使うのか？
• 売りに行くのではなく「アドバイザーになりませんか？」とアポを取る
• 製品が無い状態で契約を取るとして、技術的実現性の不安・覚悟は？
• Webからモバイルへの進出
• 生成AIによるソフトウェア開発・テストへの影響
• テスト対象（What）を見つけるのは、なぜこんなに難しいのか？
• 自動化しやすいテストと、自動化しにくいテストとは？
• 自動化可否を判定するモデル
• RAGに組み込むドキュメントは？
• 非機能要件のテストはどのようにカバーしていく？
• ソフトウェアテストは今後、どのように変化する？
• 自動化にかかるコストの考え方・バランス
• 探索的テストとの相性
• オーティファイ株式会社 採用情報
• 書籍: エンジニアリングが好きな私たちのための　エンジニアリングマネジャー入門

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

• エンプラでアジャイルをやろうとすると何が大変なのか？
• 内製開発がデファクトじゃない
• なぜ内製はデファクトではなかったのか？
• エンプラ業界で内製が増えてきたきっかけは何だろう？
• 通信事業者のルータやスイッチの調達はどのぐらい時間がかかる？
• アジャイル開発センターって何？
• その後のきっかけとなった法人向けのアジャイル案件ってどんな契機で始まった？
• 小さく成功を作って広げていく
• 既存の業務プロセスに、アジャイル型開発はどう付き合っていくか？
• 意思決定をアジャイル開発センターに集めていく
• アジャイル開発センターの隔離
• Cynefin Framework
• アジャイル開発センターをどう設立していったのか？
• アジャイル開発センターって名前はかっこよくないけど、実は意味がある
• ニュースリリースの見出しにのる名前を狙う
• (新しいもの入れる場合に)社外から社内を攻める
• (新しいもの入れる場合に)社内の攻め方 - 擁護者を徐々に増やす
• 彼らのわかる言葉で説明する
• エンプラはしがらみが多い
• 特区によって、社内ルールの一部を特例として認めてもらう、代替手段で守る
• 聞いちゃうとアウトだけど、聞かなければグレーなルールはどうするのか？
• グレーです、と宣言して進める
• 謎のチェックリストが生まれる
• 失敗すると後続が死んでしまう
• アジャイル開発センターの場のデザインはどうしている？
• うなぎの寝床みたいなチームスペース
• Ops専用部署があるにもかかわらず、アジャイルな開発で作ったもののOpsはどうするのか？
• 運用の要件・要求によってOpsのスタイルを分ける
• エンプラは標準化しようとする
• 標準化で決める部分をアジャイル開発センター・チームに権限委譲する、自由度を持たせる
• 大量のガイドライン・チェックリストとアジャイルの付き合い方
• ガイドラインのHowをWhyに戻して考える
• 会社のルールを変えず、現代のやり方を適用する
• 障害が起きるとルールが増える
• ルールを増やしても守れない
• ルールを増やしてもシャドーが増えるだけで意味がない
• 半端じゃない数のチェックリスト
• 誰かが始めないと変わらない
• 運用へ渡すときに自動化しすぎない
• 承認フローをあえて挟む
• 内製をしていなかった企業で、内製エンジニアをどう集めるのか？
• デベロッパーを集めたいなら、デベロッパーコミュニティに行く
• Tech-Onという社外勉強会と、Tech-Inという社内勉強会の目的は？
• 前例があると突破できる
• 前例を知るために社内勉強会ネットワーキング
• 社内勉強会を実際に始めるとすごいパワーがある
• 会社に熱を持っている人は見えてない範囲にいる、隠れている
• どうやって社内勉強会に巻き込んでいったのか？
• 会社の命令で参加させるのはダメ
• 影響力ある人から集める
• ちゃんとした人は、ちゃんとした人を呼んでくる
• ルール化しましょう、というアンチパターン
• せっかく燃えていた火を消化させない
• 70回以上、続けているTechLunchという社内勉強会
• 運営側が燃え尽きない
• 社内勉強会をオープンな場所でやる
• 自分が発信すると、情報が外から入ってくるという体験をさせる勉強会デザイン
• デベロッパーリレーションズを、なぜエンプラでやるのか？
• 社外勉強会で外のモノサシを知る
• 社外で話す、コミュニティ活動をどう社内で評価するのか？
• エンプラだけど、使ってるツールや言語は普通にエッジなもの
• メンバーシップ型社員とスペシャリスト型社員の評価制度は同じで良いのか？
• お客様に価値を届けられる人間が対価を得るべき
• 2018/11/12 Tech-on Meet Up #03

• 山喜旅館でたまたま会って急遽収録
• これまでデータベースがぶつかってきた問題について
• メモリが高価、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 は収録都合により、別マイクにて再収録しているため音質が異なります)

• 継続的インテグレーション(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

• 一般社団法人 アジャイルチームを支える会
• モブプログラミングとは？
• 1台のマシンを使うのは重要？
• 複数マシンのコードの同期はどうする？
• 各々のマシンの環境が微妙に違う問題をどう対応する？
• ペアプログラミングとモブプログラミングの差分は？
• Whole Team Approach
• 情報同期がキーポイント
• 新規メンバーのJoinやLeaveにどう対処する？
• 情報の足りないメンバーがドライバーをやる
• ドライバーは仕事を止める権利をもっている
• 「わからない」と平気で言えるのが重要
• 「わからない」って言っても良いチームは素敵
• モブプログラミングにオススメの環境は？
• 「うるさいな」って言う人は羨ましい
• 楽しそうに仕事をしているチームは会社全体に影響がある
• 名前をあげて、人を褒めるということ
• チームでよく飛び交うワード
• モブプログラミングはリモートで、できるのか？
• コミュニケーションの不平等さ
• あえて全員リモートで入る
• ナビゲーターとドライバー間でスキル差がある場合はどうするのか？
• 知識の差がある場合にどう対応するか？
• コミュニケーションの多寡の問題
• チームのコミットメントを高めるきっかけとしてのモブプロによる可視化
• モブプログラミングは問題を見えやすくするアプローチ
• マネージャーに入って欲しいかどうか
• モブプログラミングの生産性？
• 生産性を妨げる行動って何なのだろうか？
• よくあるコミュニケーション問題に真正面からぶつかるのモブプログラミング
• 兼務も生産性を妨げる
• モブプログラミングで向き不向きがあるタスク
• 結果の見通しが良いものはモブプログラミングでやる必要はない
• 一方で大体の仕事は問題解決であり、モブプログラミングに向いている
• チームの状態、作業の質をみてモブプログラミングを使い分ける
• 分担するよりも一緒にやったほうが良い、という気付き
• 分担はパラレルで仕事するだけではなく、全体の同期する仕事する時間もある
• ドライバーとナビゲーターは、どういうタイミングで交代するのか？
• 我が家方式による交代
• ドライバーってどれぐらい喋れば良いのか？
• モブプロ、めっちゃ疲れる問題
• どのように休憩(ブレイク)を入れるのが効果的か？
• 休憩の入れ方はチームのセンスが問われる
• ポモドーロと組み合わせた休憩テクニック
• モブコーヒー
• どうやってサボるかを、真剣に考える
• Deepで集中する、Deepで休憩する、Deepでサボる
• モブプログラミングにて、振り返りをどの程度していくか？
• 手を止めて、仕事を俯瞰する振り返り
• スクラムとモブプログラミングの組み合わせはどうやったらいいか？
• モブプログラミングとスクラムは相性が良い
• 1Day Sprintというアプローチ
• プロダクトオーナーやプロダクトマネージャーのモブへの参加度合い
• お客様から直接Feedbackをもらうことに価値がある
• モブプログラミングの中に、お客様に入ってもらう
• 全員プロダクトオーナー
• 管理職・マネージャーをどう説得するか？説得する必要があるのか？
• モブプログラミング実施について説得する必要はない
• より良い仕事をするためにモブプログラミングをしている
• マネージャーはチームが上手く働けるようにサポートすること
• チームの理想をWhatで提示、Howは権限委譲する
• Howに興味があるのは子供扱いしている状態と同じ
• 1on1で上司をメンタリング
• 受け入れてくれるマネージャーは多い
• 双方向メンタリング
• よっぱらったときに書いたコードやばい問題、深夜に書いたポエムやばい問題への対応
• モブプログラミング スタートアップマニュアル

• omoiyari.fm
• アジャイルコーチという職種って何やってるの？
• 会社に対するオーナーシップ
• プロダクトオーナーシップが全員必須というわけではない
• プロダクトオーナーシップはあると何が嬉しいのか？
• 1on1におけるフレーミング
• 1on1における本人と業務のギャップが大きい場合の対処はどうすればよいのか？
• リーン、アジャイルとはそもそも何なのか？その関連は？
• スクラムと開発速度の考え方
• 効果と効率
• モブプログラミングは意外とベロシティが出る
• モブプロで浮き彫りになるコミュニケーションの質
• スクラムの何が好き？
• omoiyari.fmのFearlessChangeネタは？
• ykmc09の好きなFearlessChangeのパターン3つ
• Face to Faceで話すことの効果
• 心理的安全性をチームで高めるにはどうすれば良いか？どう場を作ればよいか？
• “雑”ということの重要性
• 大企業/組織における心理的安全性を高めるための社内Podcast
• いつかSIerに戻ってみたい理由
• 生涯でやり遂げたいことはある？
• アジャイル、モブプロにおける人事評価

• Kamueeとは
• NFV
• ソフトウェアルータのメリット
• Kamueeを作るモチベーション
• 既存のソフトウェアルータの限界、問題点
• DPDKとは
• Trieとは
• ラストレベルキャッシュ
• PopTrieとは
• Kamueeが他に実装しているもの
• InteropのShownetにて、バックボーンコアルータでKamueeを動かしていた話
• NTT Tech Conference #3
• Cuishark
• Cuisharkを作るモチベーション
• Cuisharkの実装
• Cursesを生で使うのは大変
• 未踏とは？
• DPDKを使うのは大変
• 未踏2017テーマ環境に対して自動最適化する高性能通信基盤の開発

• botnetとは？
• Herderとは？
• どうやって感染するのか？
• どうやってbot化していることを発見するのか？
• リスニングポストとは？
• botnetって買えるの？
• イスラエル軍が凄い
• DDoSを使う動機？
• DDoSってどうやって対策していくのか？
• セキュリティの勉強ってどうやるの？
• CTFとは？
• CTFtime (エピソード中のCTFTimesは誤りです)
• 通信事業者ってbotnet対策に何かしているの？

• なぜブログを書くのか？
• 食欲、睡眠欲、ブログ欲
• 3大ブログ書けない理由とは
• ブログメンタリング
• 相互メンタリング
• 1日24時間しかな事実は知られていない
• プログラミング講師
• 初心者にRailsを教えるコツ
• 知の高速道路を突き抜けるスピードを加速する
• モブプログラミング
• モブプログラミングに向いているお題
• 雑談をしましょう
• オートクラインとは
• トランザクティブメモリーとは
• スウォーミングとは
• チームビルディング
• 結局リーダは笑顔でいる
• kakakakkuさんの再現性
• 仕事よりブログが大事
• ブログも自分の子供

訂正: ダックタイピング -> ラバーダッキング

• IETFって何？どんなところ？
• RFCとは？
• ハミングによるコンセンサス
• IETFに参加するのはどんな人たちがいる？
• 個人で参加するには？
• IETFでの雑談、ロビーイングの重要性
• QUICって何？なぜ生まれたの？
• Google QUICとIETF QUIC
• HoL とは？
• なぜQUICは、ユーザランドで実装しているのか？
• TCP既存プロトコル vs QUIC(UDP)プロトコル
• QUICが効果的に効くところ
• 通信事業者のミドルボックスの負荷、コネクション残存
• 通信事業者はQUICをどう見る？
• ネットワークの硬直化(Ossification)
• QUICの折り合いの付け所
• QUICの将来の展望
• QUICを追っかけるにはどうすればいい？

• 自己紹介
• Podcastで今後話していくコンテンツについて

vaaaaanquishさんをゲストに、エムスリーのエンジニアリング組織運営について語っていただいたエピソードです。

話したネタ

• 聴くエンジニアtype
• マネジメントに目覚めたきっかけ
• VPoEとしてのばんくしさんの仕事
• ばんくしさんの目標設定
• エムスリーのROI文化
• 目標設定はツリー構造にしている？
• エンジニア組織のチーム構成とは？
• エンジニアリングマネジメントの役割は、チームの外にある？
• 共通のインフラチームやSREチームはある？
• 技術選定の方法
• オペレーションは誰が担っている？
• 技術的負債の対応方法は？
• 採用時にギークさをどう見極めているか？
• チーム内でどのように合意するか？
• プロダクトマネージャーと開発エンジニアはどのようにコミュニケーションしている？
• 開発エンジニアの顧客接点は？
• ギークかつプロダクト志向な人を求めている？
• 目標設定と評価はどうしている？ 期間は？
• チーム間の異動はどういう契機で発生する？
• プロダクトのクローズはどう判断している？
• チーム間の情報交流を促す仕組みはある？
• 採用情報 エムスリー株式会社

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

Aki さんをゲストに、システムコーチング®について語っていただいたエピソードです。

• コミュニティからの学び
• コーチングとは？
• システムコーチング® とは？
• ここでいう「システム」とは？
• 関係性システム™
• 何のためにシステムコーチングを使うのか？
• 3つの現実レベル
• Consensus Reality、Dream Land、Essence
• CRレベルだけで話していると何が問題になるのか？
• 響くプレゼンテーションの要素
• 書籍：プロセスワーク入門　歩くことで創られる道
• 書籍：人と組織の進化を加速させる　システム・インスパイアード・リーダーシップ　Systems Inspired Leadership
• システムコーチングを実際に受けるときのプロセス
• センシティブなトピックについて、腹を割って話せるのか？
• システムコーチングは関係性を良くするものではない
• Right Relationship™（正しい関係）
• アジャイル開発チームへの適用例
• 書籍：エレガントパズル　エンジニアのマネジメントという難問にあなたはどう立ち向かうのか

上記の™および®がついている言葉は、CRR Global Japan 合同会社の登録商標です。

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

twadaさんをゲストに、テスト駆動開発(TDD)、TDDに関するよくある誤解などを語っていただいたエピソードです。

話したネタ

• 【翻訳】テスト駆動開発の定義
• 自動テストとテスト駆動開発、その全体像
• 保守しやすく変化に強いソフトウェアを支える柱　自動テストとテスト駆動開発⁠⁠、その全体像
• テスト駆動開発とは何だったのか？
• テスト駆動開発と同じレイヤの手法はある？
• テスト駆動開発と品質保証との関連は？
• TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング
• テスト駆動開発に関するよくある誤解
• アジャイル開発との類似点（みんな丸い）
• IPAの試験での誤解
• 今回のブログを書いた（翻訳した）ことによる懸念
• サバンナ便り ～ソフトウェア開発の荒野を生き抜く～ 記事一覧
• 書籍レビュワー募集フォーム

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

Dmytro Yarmak さんに、アジャイルコーチがウクライナ軍に入隊して、どのようにアジャイル関連のスキルやリーダーシップを適用したのか、について語っていただきました。

話したネタ

• RSGT での講演 "A True Story of Agile Coaching in Ukrainian Armed Forces"
• 入隊して分かった組織の大きな課題
• スクワッド・プラトゥーン・カンパニー
• Reactive to Proactive
• 各部隊のリーダーシップレベルを変えるために実施した3つのこと
• (訂正：途中で、ダニエル・ピンクの Management 3.0 とiwashiが発していますが誤りで、 Motivation 3.0 が正しいです)
• 明確さを与えること・心理的安全性を確保すること・能力を高めること
• Trello のカンバンによる透明性の確保
• 計画を立てるスパンの短さ
• クネヴィンフレームワークの応用
• 1日2回のデイリースタンドアップ
• 短すぎる締め切り（締め切り＝今すぐ / right now）
• ウクライナの募金先(NHKのまとめ)

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

JSOLの田井さんに、ERPとは、インフラエンジニア・アプリケーションエンジニアの仕事、テスト方法、運用保守などについて語っていただきました。

話したネタ

• ERP とはそもそも何か？
• どのような業界で ERP は使われるのか？
• 基幹システムとは何か？
• ERP は Web SaaS の企業でも活用されるものか？
• ERP を使うことによって嬉しいことは何か？
• ERP を導入するために、何をすればいいのか？
• ERP(SAP) のインフラエンジニアとアプリケーションエンジニアの役割
• オンプレ or クラウド？
• データベースは何が使われる？
• ERP(SAP) のアプリケーションエンジニアは何をどう実装している？
• ABAP(Advanced Business Application Programming) 言語
• ERP(SAP) エンジニアの面白さ
• ERP(SAP) のシステムのテストでは、何をするのか？
• システム監視では、何をするのか？ ツールは何を使うのか？
• ERP(SAP) ならではでのメッセージ検知の代表例
• ERP(SAP) の運用保守では何をしているのか？
• 障害が起きてもそわそわしないための工夫
• 今後のERPエンジニアリングの世界はどう変わっていく？
• SAPエンジニア経験者の人事担当が語る、JSOLで働くエンジニアの市場価値
• JSOLキャリア採用ページ

エピソードスポンサー

株式会社JSOL

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

入門 eBPF 訳者のUchio Kondoさんに、eBPF の経緯・用途、iptablesとの違い、カーネルモジュールとの違い、CO-REなどについて語っていただきました。

話したネタ

• 入門 eBPF ―Linuxカーネルの可視化と機能拡張
• Raft + Redis な内製Redisサーバの紹介
• eBPF の始まり
• cBPF(classic BPF) と eBPF(extended BPF)
• eBPFの用途の広がり
• パケットフィルタリングとは何か？
• iptables との違い
• Cilium
• カーネルモジュールでも同じことはできるのか？
• カーネルモジュールの問題点
• eBPF VM と eBPF検証器
• Facebook での eBPF 利用
• XDP(eXpress Data Path)
• CO-RE(Compile once, run anywhere) とは？
• task_struct 構造体 と BTF (BPF Type Format)
• コンパイラのリロケーション
• 翻訳するにあたって意識していたこと
• 株式会社ミラティブ 採用特設サイト

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

Tably CTOのyoichiroさんに、Jasmine Tea、プログラミング言語を新たに実装、日本の中高生向けIT教育などについて語っていただきました。

話したネタ

• Jasmine Tea とは？
• ブロックプログラミングとは？
• ファミリーベーシック
• 現代の言語で、プログラミング初学者がGUIアプリを作るのは大変
• Jasmine Tea の想定ユーザー
• 新たに言語を作ると考えたときに何から考え始めるのか？
• インタープリタの自作、とは？
• Web上に言語を実装する場合に大変だったことは？
• JavaScript のメインスレッド専有への対応
• setTimeout() によるペナルティ
• ブラウザの差 と デバイスの差 による苦労
• 中学生向けの技術の授業でのIT教育
• 高校の情報Ⅰ で教わる内容
• 教育を起因とする日本のIT業界の課題
• 教材の重要性
• @JasmineTeaProg
• Jasmine Tea に関する問い合わせ

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

くまっしーさんをゲストに、プライベートクラウドの開発と運用、低レイヤのデバッグの実態、トラブルシューティングのコツなどについて語っていただいたエピソードです。

話したネタ

• 書籍：詳解 システム・パフォーマンス 第2版
• プライベートクラウドの開発・運用の仕事内容
• チョークのマークひとつ
• プライベートクラウドの運用の難しさ
• ライブマイグレーション
• 今回発生した、技術的に興味深い問題とは？
• Linuxカーネルのタイムスタンピング機能
• CPUコアの割り当て（占有）
• CPUの電源管理の設定とステート
• トラブルシューティングのコツ
• PR: 新卒採用情報
• PR:【インタビュー公開】NTT もクラウドを作っているって知ってた？国産クラウド開発の「秘密」に迫る
• PR:中途採用
• PR:NTT Communications Engineers’ Blog

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

スマートバンク CTOの堀井さんをゲストに、フリマアプリの運営経験からふりかえり、FinTech業界、スマートバンク社でのプロダクト開発などについて語っていただきました。

話したネタ

• なぜレッドオーシャン化する前にサービスをグロースできなかったのか？ - フリマアプリ編 - @yutadayo
• フリマアプリ開始時の外部環境・市場は？
• リリース以降の成長は？
• 上手くいっているときの経営判断の難しさ
• n=1 に愛されるプロダクト作りからペルソナを判断するポイント
• ユーザーの課題を解決する得意な会社の作り方
• CxO職の採用の重要性と難しさ
• 権限委譲が遅かった、という振り返り
• 会社を動かすレバーで良かったものは？
• 最適な組織構造を考えるためのステップは？
• FinTech業界とスマートバンクの事業
• クレジットカード決済の裏側の通信
• 0からプロダクトを開発するときに考えていたこと
• FinTech業界の難しさとは？
• 金融業界特有の非機能要件
• 金融要件に対応するシステムアーキテクチャ
• エンジニアの採用における工夫
• スマートバンク エンジニア採用

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

牛尾さんをゲストに、書籍「世界一流エンジニアの思考法」、Azure Functions チームでの開発方法、マネージャの役割などについて語っていただきました。

話したネタ

• 書籍: 世界一流エンジニアの思考法
• Azure Functions チームの体制は？
• チームでOpsまで対応している？
• オンコールでの呼び出し
• Azure Functions チームでのアジャイル開発
• デプロイに必要な承認プロセスはある？
• チームでのレトロスペクティブの有無？
• 障害発生時のふりかえり
• マネージャの役割は？
• バックログのプライオリティ付けは誰が担う？
• 1on1で主に何を話す？何が狙い？
• 採用活動は誰が担う？
• パフォーマンス評価の仕組み
• 失敗に対する考え方の違い
• リファクタリングに向けた意思決定はどうしている？
• Azure Functions のスケーラビリティのテスト方法
• Azure Functions Flex Consumption

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

ストックマークの近江さんをゲストに、大規模言語モデルをゼロから作る方法、学習のデータセット、モデルアーキテクチャ、学習環境への取り組みなどについて語っていただきました。

話したネタ

• どのような大規模言語モデルと作ったのか？特徴は何か？
• データセットに何を使ったのか？
• 日本語と英語とのバランスは？
• 最終的なToken数は？
• 事前学習モデルを作りたいとして、何から考えるのか？
• ノイズのクリーニングと、その方法
• 今回活用したモデルアーキテクチャ(Llama)
• 前回のアーキテクチャは GPT-NeoX
• 今回の学習環境は？
• AWS Trainum 32コア x 16ノード
• 学習にかかった時間は？
• 学習時に大変だったこと・上手くいかなかったことは？
• 学習中のチェックポイントとは何か？
• なぜ、Token生成が速いのか？
• 手元でLLMを動かすときの一番のネックは？
• bit数を落とすFineTuning
• Tokenizerとは何か？
• 日本語の単語区切りはどのように考えるのか？
• 今回のLLM作成のTokenizerは何を使ったのか？
• ビジネスドメインでのLLM評価
• ストックマーク株式会社のRecruitページ

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

y.kajiuraさんをゲストに、クラウド内でL2をつなげる大変さ、セキュリティグループの仕組み、スケーラビリティへの取り組みなどについて語っていただきました。

話したネタ

• 異なるハイパーバイザーにVMが収容されていてもL2でつながっているように見せることの大変さ
• なぜ、L2で接続することが大変なのか？
• encapsulationした上でのマルチキャスト・ブロードキャストのサポート
• アンダーレイ側のネットワークで対応していないものは、ユーザー側のオーバーレイ通信を提供できない
• 当初のモチベーションとしてVRRPを提供したかった
• クラウドサービスでセキュリティグループを提供するための裏側の仕組み
• 経路処理をOpsする上で大変なことは？
• OpenTechLunchの資料: クラウドの作り方（使い方じゃないよ）
• ライブマイグレーションの前後での通信継続における課題
• 当たり前の前提を見直す重要性
• Prometheus Exporter 自作
• 監視ツールの技術選定方針
• Cassandra / RabbitMQ
• ちょっと足りないのがJavaScript
• チームの雰囲気
• チーム内のSPOFへの対策
• 求人ページ: SDPFクラウド 仮想サーバ開発エンジニア

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

y.kajiura さんをゲストに、SDNの開発、カーネルモジュールのデバッグ、コアダンプの読み方などについて語っていただきました。

話したネタ

• SDNとは
• Lazy K
• SDNの開発って何をやるの？
• Tungsten Fabric
• SDNでの低レイヤ開発とは？
• カーネルモジュールデバッグ
• 見えないようと見ようとしてコアダンプを取った
• コアダンプの読み方
• カーネルモジュールのお作法
• 任意のパケットをどうやって作る？
• Scapy
• Cよりも低レイヤにいく場合
• 気づいたらアセンブリを読むようになっていた
• 低レイヤに携わることによる成長
• 求人ページ: SDPFクラウド 仮想サーバ開発エンジニア

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

jacopenさんをゲストに、Platform Engineering、話題となっている背景、DevOpsやSREとの差分、Platform as as Product などについて語っていただきました。

話したネタ

• Platform Engineering とは？
• Platform Engineering におけるツールチェインとは？
• セルフサービスのイメージ
• Platform Engineering で解きたい課題とは？
• なぜ盛り上がっている？その背景とは？
• 認知負荷、課題外在性負荷
• DevOps との差分は？
• SRE と Platform Engineering との関係は？
• ちいとぽ本におけるプラットフォームチームと、Platform Engineeringとの関連性
• 書籍: チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計
• 69. チームトポロジー(前編) w/ miholovesq
• 70. チームトポロジー(後編) w/ miholovesq
• IDP (Platform/Portal) とは？
• 業界でコンセンサスが取れているプロダクトはある？
• CNCF Platforms White Paper
• 社内共通プラットフォーム と何が違うのか？
• 社内共通プラットフォーム が上手くいかなかった要因
• Platform as a Product
• プラットフォームチームにプロダクトマネージャがいるということ？
• Platform Engineering を自社内で考えはじめるタイミングとは？
• Platform Engineering Meetup #5

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

カケハシCTOの海老原さんをゲストに、カケハシの事業領域、創業期からのエンジニア組織づくり、帰属意識の高め方、医療ドメインの難しさ・技術選定などについて語っていただきました。

話したネタ

• スタートアップの離職率の低さ
• カケハシの事業領域
• 創業期の技術開発はどう進めていったのか？
• 初年度のエンジニア・デザイナーの採用方法
• 2年目以降の開発組織のスケール方法
• 1社目でのCTO経験の反省とは？
• メタ文化：文化を大切にする文化
• 1年目から採用ハードルを高めに設定している背景は？
• 開発チームの命名方法
• 帰属意識をなぜ高める必要があるのか？
• 意図的に組織に刺激を促しているか？
• 「わたし考える人、あなた作る人」とならない組織
• 分断を生まない組織にするための組織デザイン
• マトリクスにおける目標設定・評価
• スクラムを愚直にやるために
• 書籍: ゾンビスクラムサバイバルガイド: 健全なスクラムへの道
• 医療領域におけるドメインの難しさとは？
• 入社後・オンボーディングのカリキュラム
• 技術選定の方針とは？
• 堅牢性・耐障害性を高めるための工夫は？
• 今後のエンジニア組織の展望は？
• エンジニア採用情報 株式会社カケハシ 採用サイト
• KAKEHASHI Tech Blog

エピソードスポンサー

株式会社カケハシ

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.