所感
LeanとDevOpsの科学を読了しました。
私はアジャイルやDevOps礼賛本はやや苦手なのですが、本書は各種プラクティスの効果をエビデンスに基づいて検証しており、非常に科学的、かつ実践的な内容であると感じました。
印象に残った点
パフォーマンスの計測尺度
本書で採用したのは下記の４つ
- デリバリのリードタイム
- デプロイの頻度
- サービス復旧の所要時間
- 変更失敗率
これらの尺度によって測定した「ソフトウェアデリバリのパフォーマンス」が「組織全体のパフォーマンス」に寄与することが調査により確認された
下記の尺度はパフォーマンスの計測尺度としてふさわしくない
ストーリーポイントを合算して記録した「ベロシティ」
- これは「キャパシティ計画の立案ツール」として使うべき
- ベロシティは絶対的ではなくチーム依存の相対的な尺度
- ベロシティを生産性の測定尺度にすれば、必然的にチームはベロシティを悪用するようになってしまう
リソースの利用率(エンジニアの稼働率)
- 利用率は一定レベルを超えてしまうと余力（余裕）がなくなって予想外の仕事や計画変更、改善作業を入れる隙がなくなる
- 「待ち行列の理論」で言えば、利用率が100%に近づくにつれて、リードタイムが無限大に近づく
アーキテクチャのポイント
システムのタイプとデリバリのパフォーマンス
システムのタイプがSoR（いわゆる勘定系システム）かどうか、組み込み系かどうか等により、デリバリのパフォーマンスに差が出ると予測していたが、実際には相関関係が見られなかった。差が見られたのは次の２つのタイプのみ
- 他社（外注先）が開発したカスタムソフトウェアかどうか
- メインフレームのシステムで作業を進めているかどうか
アーキテクチャの特性のうち次の２つの事項がデリバリのパフォーマンスに大きな影響を及ぼしていた
- テストの大半を、統合環境を必要とせずに実施できる(テスト容易性)
- アプリケーションを、それが依存する他のアプリケーションやサービスから独立した形で、デプロイまたはリリースできる(デプロイ容易性)
継続的デリバリの最強の促進要因
『テストとデプロイの自動化』よりも次のケイパビリティをチームが備えているか否かが重要
- チーム外の人物の許可を得なくても、対象システムに大幅な変更を加えられる
- 対象システムの変更作業で他チームに頼ったり、他チームに相当量の作業を課したりすることなく、対象システムに大幅な影響を加えられる
- チーム外の人々とやり取りしたり協働したりすることなく作業を完遂できる
- ソフトウェア製品やサービスを、それが依存する他のサービスに関係なく、オンデマンドでデプロイ、リリースできる
- 統合テスト環境を必要とせずに、オンデマンドでテストの大半を実施できる
- デプロイメントを、無視できるほどわずかなダウンタイムのみで、通常の勤務時間内に完了できる
変更管理プロセス
- 本番環境に対する変更については必ずチーム外の人や組織（管理者や変更詰問委員会）の承認を得なければならない
- データベースの変更などハイリスクな変更関してのみ、承認を得なければならない
- 変更の管理はピアレビューだけで済ませている
- 変更承認プロセスはない
上記4つの方針とパフォーマンスの相関関係を調べたところ、1のパフォーマンスが低く、3と4のパフォーマンスが高かった。
1の方針は「リードタイム」「デプロイ頻度」「サービス復旧までの所要時間」との間に負の相関関係があり、「変更失敗率」とは相関がない。つまり、チーム外の人や組織の承認を得らなければならない場合、本番環境のシステムの安定性は向上せず、むしろ確実に作業の遅れを招いてしまう。
本書が推奨するのは「ペアプログラミングやチーム内でのコードレビューなど、負荷の軽い変更承認プロセスとともに、望ましくない変更を探知・排除するためのデプロイメントパイプラインと併用する」