現代のソフトウェア開発を学ぶために「正しいものを正しくつくる」を読んだ - $shibayu36->blog; に続いて、現代のソフトウェア開発について学ぶために、LeanとDevOpsの科学を読んだ。
この本は開発チームのデリバリのパフォーマンスを測るための統計的に有意な指標を示してくれていることが、とにかく素晴らしい。これまで開発チームの生産性や健全性をどういう指標で測れば良いか分からなかったが、本でデプロイの頻度、変更のリードタイム、MTTR、変更失敗率を測れば良いと示してくれた。今後は自分のチームでこの指標を測り、アーキテクチャ改善やチーム改善でこれらの指標を意識して改善していきたい。
他にも改善効果の高いプラクティスなどをまとめてくれるなど非常に参考になる本だった。
ただ自分は正直本文があまり頭に入ってこず、付録の改善促進効果の高いケイパビリティのまとめ部分と、ソフトウェアデリバリのパフォーマンスのまとめが一番わかりやすく感じてしまった。なので、もしかしたら先に付録を読んだ上で、気になるトピックについてその詳細を見ていくと良いかもしれない。
次はエラスティックリーダーシップを読んでいきたいと思う。
読書ノート
* 研究の推進力となった疑問点と判明したこと xxxvii
* ソフトウェアのデリバリとは何を意味するのか、そしてそのパフォーマンスを測定することは可能か ->
* ソフトウェアのデリバリは組織に影響を及ぼすか ->
* 組織文化は何らかの影響を及ぼすか。そしてそれはどう測定すればよいのか ->
* どのような技術的プラクティスが重要だと思われるか
* 判明したこと
* 統計的に有意な形でパフォーマンス測定可能
* 高業績の組織はソフトウェアの開発とデリバリを、他社よりかなり優れた方法で継続的に行っている
* スループットと安定性は連動する
* 組織のソフトウェア開発能力が、収益性、生産性、市場占有率を左右する
* パフォーマンスと安定性はトレードオフではなく、両立する 15
* プロセスの質を上げると速度も安定性も向上
* コード行数もベロシティも利用率も指標として良くない 20
* ベロシティは恣意的に変えられる
* 利用率は一定レベルを超えると余力がなくなる
* 望ましい尺度の二つの特徴 21
* グローバルな成果に焦点を当て、チーム同士が競争もしくは対立するような状況を防ぐ
* 生産量ではなく成果に焦点を当てる
* ソフトウェアデリバリの測定基準 25 ※
* デプロイの頻度
* 変更のリードタイム
* MTTR = 平均修復時間
* 変更失敗率
* 4指標のハイパフォーマーの基準 26
* 作業を細分化してデリバリを行う能力がとりわけ重要 32
* この能力があれば、A/Bテストなどでユーザーのフィードバックを素早く得られる
* 製品開発に実験的な姿勢で臨める能力が、継続的デリバリに寄与する技術的プラクティスと高い相関をもつ
* 組織文化の3レベル 38
* 基本前提、価値観、アーティファクト(人工物)
* 情報の流れがスムーズな組織の方が効率的に業務を行える。この特徴は 44
* すべての構成員の間で信頼関係と協力関係が成り立っている
* 質の高い意思決定が下せる組織である
* チーム内外の関係者との協同態勢が整った組織である
* 急速な変化の中で、変化に応じて革新を遂げる力(革新力)と変化に柔軟に対処する力(弾力性)が重要 46
* 革新力が大事なのは頭になかったな
* リードタイム、リリース頻度、サービス復旧までの所要時間の3つでもデリバリのパフォーマンスで妥当で信頼性のある構成概念を得られる 47
* 継続的デリバリの定義 53
* 継続的デリバリの効果。職務満足度ややりがいも高まる 60
* トランクベースの開発のマージ速度やコードフリーズの話参考になる 66
* アーキテクチャの特性の中でテスト容易性とデプロイ容易性が特に重要 75
* 重要なのはチームが他のチームに依存せずに変更できること 82
* バーンアウトを招くよくある問題 114
* 過重労働、自律性の欠如、不十分な報奨、人間関係の断絶、公平性の欠如、価値観のズレ
* 変革型リーダーは不可欠である。その特性は 142
* ビジョン形成力、心に響くコミュニケーション能力、知的刺激、支援的リーダーシップ、個人に対する評価
* チームがツールを選択できるようにっていうの何回も言われてる 150 ※
* INGのアジャイル型組織モデル面白い 214
* チーム、マネジメント、リーダーシップのそれぞれについて高いパフォーマンスを生む行動とプラクティスっていうのめちゃくちゃ参考になる 225〜227
* 文化、組織構造、直接的な学びおよび連携の重視、組織展開、フローの改善、働き方・リズム・ルーティンなどのカテゴリがある
* ハイパフォーマンスとの相関が示されたプラクティスに印がついている
* 組織を改善していくための心構え 228
* 独自のものを作り上げる
* プラクティスをコピーしようとしない。他の会社に委託して実践しようとしない。外部のコーチを雇ったとしても最終的には自分たちが変える主体となる
* 自分自身も仕事のやり方を変える
* 自己管理を徹底する
* 忍耐をいとわない
* プラクティスをまずはやってみて、振り返りと学びにつなげる
* 改善促進効果の高いケイパビリティのまとめ 235 ※
* ソフトウェアデリバリのパフォーマンスのまとめ 246 ※
付録のaとbの方が本文より分かりやすい、、、
参考
[LeanとDevOpsの科学［Accelerate］で統計学的に証明されていること｜諏訪真一｜note](https://note.com/suwash/n/n23928824d2ca)
[開発組織のプラクティスや文化を科学する：『LeanとDevOpsの科学』書評 - こまどブログ](https://ky-yk-d.hatenablog.com/entry/2018/11/23/214122)
