2021.08.21_pyhack
https://gyazo.com/8b2a229cd37fb9cc5856fb3d5b998489
20210821のpyhackでワクチン接種の副反応で静養しながら、ゆっくりLeanとDevOpsの科学を読みました。
つんどくしかしてなかったので、もう少し体型的に学びが得られるとよいかなと思います。
組織のソフトウェア力(競争力)を計測する
組織の価値(競争力)は、いかにすばやく、変化に対応し、顧客を満足させて、収益化するか。
その手段として、ソフトウェアを中心としたテクノロジーが重要で差別化要員。つまり、ソフトウェア力が組織パワーを示しているともいえる。
ツール利用率とか熟練度とか計測(これを成熟度モデルでの計測という)しても、成果と無関係なので組織パワーを測ることにならない
ケイパビリティ(組織全体やグループとして保持する機能や能力)モデルを使うと、成果や能力(開発能力、デリバリ能力、スピード)などのパフォーマンスの計測を主眼として実情に近づく。
生産性測定のKPIのアンチパターンまとめ
アジャイル型開発で典型的なユーザーストーリーのイテレーション完了までの時間「ベロシティ」
書いたコードの量
利用率
ソフトウェアデリバリのパフォーマンス測定の尺度の特徴
グローバルな成果に焦点をあて、チーム同士で競争や対立するような状況を防ぐ機能
生産量ではない成果に焦点をあてる
ソフトウェアデリバリのパフォーマンスの分類と相関
table: ソフトウェアデリバリのパフォーマンス(2016)
ハイパフォーマー ミディアムパフォーマー ローパフォーマー
デプロイ頻度 オンデマンド 週1-月1 月1-6ヶ月に1
変更リードタイム 1時間未満 1週間-1ヶ月 1ヶ月-6ヶ月
MTTR(平均修復時間) 1時間未満 1日未満 1日未満
変更失敗率 0-15% 31-45% 16-30%
測定のための選択肢
デリバリのリードタイム(コードのコミットから本番稼働までの所要時間)
一時間未満
1日未満
1日から1週間
1週間から1ヶ月
1ヶ月から6ヶ月
6ヶ月超
コードのデプロイ頻度(一度に進める作業のサイズであるバッチサイズは見えにくいので代わりにデプロイ頻度とした)
オンデマンド(1日複数回)
1時間に1回から1日1回
1日1回から週1回
週1回から月1回
月1回から6ヶ月に1回
6ヶ月に1回よりも少ない
ソフトウェアデリバリのパフォーマンスは組織全体の業績に重要な影響を及ぼす -> じそっしきの事業にとって戦略上重要なソフトウェア開発能力を自組織の中核的要素として位置付ける-> 戦略上重要なものはアウトソース(外部委託)することは良くない
生産性向上ソフトウェアや給与システムなどの戦略的でないものはSaaSなどにたよるべき
戦略上重要なものが何かを見極めることが重要
フレームワークやモデルの慎重な活用
学習を重んじる文化が根付いた組織であれば威力を発揮する
以前不健全で官僚的な文化のはびこる組織では、測定結果が支配のために利用され、既存のルールや戦略、権力構造をゆるかぎかねない情報は隠蔽される「恐怖心のあるところでは真実は伝わりにくいbyデミング」