LeanとDevOpsの科学を読んだ(前編)
なぜ読もうと思ったのか
最近の悩みは、自分が今やっている形の見えない成果を出すための取り組みは果たして意味があるのかどうかということだ。
例えば、とある機能の実装を担当した。これは形の見える成果だとおもう。
例えば、チームのコミュニケーションを改善するために〇〇を行った。これは形の見えない成果だと思う。
ここ２年位、そういう形の見えない成果を取り扱うことが多く、それって意味があるのかなと思うことが増えてきた。
詳しくは先週のnoteに書いてあるので興味のある方は見てください。
○買った動機
大学院のPBLでチームが上手く言っているとはどういう指標で計れるのか、開発がうまく言っているとどういう基準で言えばいいのかということが分からなかったのでこちらの本を購入した
○どういうことを学びたかったからか
開発組織をどうやってうまく回すか、指標づくりのヒントになることはあるかを学びたかった
内容について
○タイトル
LeanとDevOpsの科学 テクノロジーの戦略的活用が組織変革を加速する
○目次
第1章 業務を加速させるということ
第2章 開発組織のパフォーマンスを計測
第3章 組織文化のモデル化と測定、改善の方法
第4章 技術的プラクティス -継続的デリバリの基本原則と効果
第5章 アーキテクチャのキーポイント
第6章 デリバリライフサイクルに情報セキュリティを組み込む
第7章 ソフトウェア管理のプラクティス
第8章 製品開発のプラクティス
第9章 作業を持続可能にする -デプロイ負荷とバーンアウトの軽減
第10章 従業員の満足度、アイデンティティコミットメント
第11章 変革型リーダシップとマネジメントの役割
第12章 統計学的背景
第13章 計測心理学入門
第14章 アンケート調査を採用する理由
第15章 データの収集方法
第16章 ハイパフォーマンスを実現するリーダシップとマネジメント
第17章 終わりに
○概要と切り口
「慣例上、学問の世界でしか用いられてこなかった厳格な研究方法を用い、結果を産業界にも公表することで、ソフトウェアの開発とデリバリの状況を改善すること」である。単なる逸話やチームの体験談を提供するのではなく、統計的に優位な方法でパフォーマンスの改善を促すケイパビリティを特定・理解する方法を確立することで、業界全体の水準向上の一助となるのではないか考えた
○読了までの所要時間
4時間~5時間くらい
良かったところ
成熟度ではなくケイパビリティ(組織の能力あるいは機能)に焦点を当てよう
この本の研究ではソフトウェア開発のパフォーマンスを統計的に優位な形で改善できるケイパビリティを24個特定できた
その24個のケイパビリティを５つのカテゴリに分類している。
・継続的デリバリ
・アーキテクチャ
・製品とプロセス
・リーン思考に基づく管理と監視
・組織文化
付録にはそれぞれのケイパビリティの指標が作成されており勉強になった。
例えば、トランクベースの開発手法の実践の項目では、「コードリポジトリでアクティブなブランチの数は３つ未満」「統合前のブランチとフォークの寿命は非常に短い(たとえば一日未満)」など基準が書いてあって指標に活きそうだった
望ましい尺度とは何か?
４つの尺度で計れるのではないか？これはこの本を読んでよかったと思ったポイント。
ソフトウェアデリバリのパフォーマンスの「テンポ」を測るもの
・デリバリのリードタイム: 顧客のリクエストからそのリクエストが満たされるまでの所要時間
・デプロイの頻度
「パフォーマンスを改善したチームが、作業中にシステムの安定性を犠牲にして改善を実現したのかどうか」を測るもの
・サービス復旧の所要時間
・変更失敗率
気がついたこと
組織文化の測定方法
p41にリッカート尺度を用いた組織文化判定用の質問の例がある。
これを真似すれば組織を評価できるのではないか？と思った。
長くなりそうなので、noteを分割することにしました。
続きは来週書く予定です。
エンジニアとして働いている成長記録やおもしろいと思ったこと色々書いていこうとおもいます 頂いたご支援は、資料や勉強のための本、次のネタのための資金にし、さらに面白いことを発信するために使います 応援おねがいします