https://zakky-dev.hateblo.jp/entry/2021/03/17/001456

リーン開発の本質

#今日の30分「リーン開発の本質」110ページまで。バリューストリームマップ作成の話。描くバリューストリームの選択、時間軸の開始と終了の選択、バリューストリームオーナーを巻き込む、シンプルに保つ。そして稼働率を高めようとして効率が逆に落ちていく話。生産性、これ見ればいいのでは？
— ざっきー dev (@zakky_dev) 2021年3月8日

#今日の30分 -1分。「リーン開発の本質」119ページまで。バリューストリームマップとスピードの話。現状のバリューストリームマップを作ったのなら、次に将来のバリューストリームマップを作ると良い。理想のマップではなく、改善の道筋がわかるものにすること。ムダを取り除く計画を作る。
— ざっきー dev (@zakky_dev) 2021年3月9日

#今日の30分 -3分。「リーン開発の本質」125ページまで。時間と待ち行列理論について。プロセスに問題があるなら、それは時間の遅れとして表に出てくる。作業がプロセスに到着した時、確実に対応できるだけの余裕があるか。そして、対応するための能力を備えているか。VSMを使いつつ考える。
— ざっきー dev (@zakky_dev) 2021年3月10日

#今日の30分 -1分。「リーン開発の本質」134ページまで。サイクルタイムの短縮方法について。作業の到着率の平準化、プロセス内のものの数とサイズの最小化、一定のリズム、作業を許容範囲内に制限、プル型スケジューリング。プロセス内の「もの」はソフトウェア開発においては未完成作業を指す。
— ざっきー dev (@zakky_dev) 2021年3月11日

#今日の30分 -1分。「リーン開発の本質」148ページまで。サイクルタイムの短縮方法、作業を許容範囲内に制限することと、プル型スケジューリングを利用すること。そして人を尊重するという原則の話。開発組織の提供能力以上の速度は出せない。仕事を多く積んだところで、見た目遅くなるだけだ。
— ざっきー dev (@zakky_dev) 2021年3月12日

#今日の30分 -5分。「リーン開発の本質」155ページまで。デミング博士の話と、改善活動が失敗する原因、そしてチームの定義について。問題が発生した時、その原因はシステムにある。故に、責任を問うならば、そのシステムを改善できていないマネジメントの責任だと言える。システムを変えるべし。
— ざっきー dev (@zakky_dev) 2021年3月13日

#今日の30分 -2分。「リーン開発の本質」165ページまで。チームを作るもの、アンチパターン、専門知識を育てる、スペシャリスト、チームに必要なリーダーシップについて。個人ごとの評価はチームのための行動を阻害するという話をよく聞く。それでも個人を評価する流れは多い。何故だろう。
— ざっきー dev (@zakky_dev) 2021年3月14日