mofmofでは最近、「LeanとDevOpsの科学」という本の輪読会を行っています。 この本の輪読会は定期的に開催し、順次後ろの章についてもログを投稿する予定です。
過去の記事はこちら
- 第1章：なぜケイパビリティに着目するのか。LeanとDevOpsの科学を読んだ記録（1章）
- 第2章：開発組織のパフォーマンスをどうやって測定するのか。LeanとDevOpsの科学を読んだ記録（2章）
- 第3章：組織文化がなぜ重要か？LeanとDevOpsの科学を読んだ記録（3章）
- 第4章：技術的プラクティスの重要性。LeanとDevOpsの科学を読んだ記録（4章）
- 第5章〜第7章：LeanとDevOpsの科学を読んだ記録（5章〜7章）
第8章 製品開発のプラクティス
- 4つのケイパビリティ（機能、能力）が、ソフトウェアデリバリのパフォーマンスや組織のパフォーマンス、ならびに組織文化を向上させ、チームのバーンアウト（燃え尽き症候群）を軽減することに対して有意
- 作業の細分化
- 管理の可視化
- 顧客フィードバックの収集と実装
- チームによる実験
- チームが顧客フィードバックに応じて要件や仕様を変えようとする際に、チーム外の人や組織の承認を義務付けられていると、チームの革新力は大きく削がれる
第9章 作業を持続可能にする―デプロイ負荷とバーンアウトの軽減
- バーンアウト（過労、ストレス、無力感など）とデプロイ負荷（本番デプロイ時の恐怖感や不安感）がメンバーの病気や人員欠落、生産性悪化を起こす
- デプロイ負荷への対処法の例
- デプロイしやすい設計にする
- 本番システムの状態は、バージョン情報に基づいて自動化された方法で再現できるようにする
- デプロイプロセスを簡素化する
- バーンアウトへの対処法の例
- 組織文化の改善
- デプロイ負荷の軽減
- リーダーが適切な影響力を発揮できる
- スキル開発への投資
- 作業改善のためのリソースの提供（実験・失敗・学習を奨励する環境を作る）
議論に出たこと
- 作業の細分化はエンジニアレベルでは実施できるけど、POが確認できるレベルでの細分化は難しい。チケットのサイズが大きすぎるといつまでもデプロイできないけど、POがわかる範囲での細分化には限界がある
- 顧客フィードバックの収集についてはエンジニア側からPOに情報収集して共有して欲しい旨を提言した方が良さそう
- 開発チーム以外の他部署の承認などを得る必要がないように組織も疎結合にしたい。また、他システムのUIに依存していないとか、システム面の依存関係も減らす方が良い。ステークホルダーは少ない方が良さそう
- 作業改善のためのリソースの提供（実験・失敗・学習を奨励する環境を作る）についてはmofmofでは 水曜日の個人開発 が一部補完している部分もありそう
