12. エンプラ向けの組織改革とか、スクラムでのチーム作り・人事評価と‪か‬ fukabori.fm

話したネタ

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

闇鍋という振り返りプラクティス
ドット投票における問題
給与査定という観点での人事評価はどうやればいいか？
プロダクトの結果が出ていれば、個人の評価はどうでもいいのでは？
チーム一律評価 + 360度評価 を組み合わせるのが落とし所
新サービスを出したばっかりのPOはどう評価するか？
人事部とエンジニアの採用プロセスの関わり？
アトラクタ