見出し画像

LeanとDevOpsの科学を読むと統計学を学びたくなる

科学的見解にチャレンジしたDevOps解説本を読んでみた。

それが、LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速するだ。アンケートの取り方や用いた統計手法まで章を割いている点が特徴的。何が科学的なのか?が問われる内容だ。

目指したのは継続的に成果を上げる方法

本書でハイパフォーマーは質も高く量も多い結果となる組織傾向が見えてくる。4年かけて集めたデータの質にこだわり続けた結果か。実務に活かせる話がこの手の書籍の源流の一つである点は押さえておきたい。

今回は特に潜在的構成概念を軸に統計的なデータを算出した記録の意欲について読み解きたい。

どうやって直接測定できないものを読み解くのか

潜在的構成概念を持つデータの信頼性の話が冒頭に出てくる。部屋の温度と違って、直接測定できないもの、今回だと組織文化をどうやって測定するか?という話が主題となっている。

第13章 計量心理学入門より。アンケート調査は質問によってバイアスがかかるのが常だが、本書ではNPS®(ネットプロモータースコア)を扱っている点が特徴的。バイアスがかからない計らいがなされている。

これであれば、エンゲージメントサーベイや商品の顧客満足度のようにある程度の妥当性は導けるのかもしれない。

第14章 アンケート調査を採用する理由でも、アンケートのメリットを活かしたデータ観測の結果だと主張。相関を見出していると読み解けそうではある。

ただ、この点が正解を導き出すための答え探しにも人によっては見えるらしく(やや因果にこだわりが見られる点も)、統計の難しさを感じる。対象の標本を考えると適切なのかどうか中々読み解くのが難しい。

この視点から、統計学についてもっと詳しくありたいなと思わせる動機にもなった。

Four Keysの整理

ソフトウェアデリバリーのパフォーマスの4つの測定基準(デプロイ頻度、リードタイム、MTTR、変更失敗率)。これも、エビデンスベースで語られる。

・デプロイの頻度:組織による正常な本番環境へのリリースの頻度
変更のリードタイム:commit から本番環境稼働までの所要時間
変更障害率:デプロイが原因で本番環境で障害が発生する割合(%)
サービス復元時間:組織が本番環境での障害から回復するのにかかる時間

https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance

参考はGoogleから読み解くとして、なんでこの指標が出てくるのかというと、ハイパフォーマーはローパフォーマーの質も量も上回るという点。つまり、生産性も高ければ、顧客数満足度も高い製品を世に送り出していると。

デプロイの頻度はもちろん高く、リードタイムにかかる時間も短い。障害発生率とサービス復元時間は障害後の復旧の容易さも潜んでいるのだろう。これが容易な環境はどんどんデプロイされ継続的な成果が出るのだろう。

また、ハイパフォーマーが賛同できると答える組織文化はケイパビリティ(組織として持つ能力、機能)視点でも語られる。

文化が大事というのは統計的に読み取った結果判断されたのだろう。この本書前後あたりからパフォーマンスの計測のあり方が変わってきているのだと感じた。

Googleもこちらのサイトでその解説とまとめ(六年の調査)と指標の実践方法を案内している。

統計学を学び続けたい

DevOpsとは何で何でないかを知りたい場合は他の書籍が良さそうだが、近年のパフォーマンスについての指標の話や、継続的デリバリがいかに大事なのかの元となった情報がつまった書籍と言える。

この業界に限らずパフォーマンスの高い組織作りにサーベイ(もちろん適切な質問ではなく陳述)が欠かせないと踏んだ。

13章は統計についての知識があると理解が進む。例えば、NPSは順序尺度にあたり、質的変数として捉えることで、計測可能といった点だ。この手の話を読むと統計学がもっと知りたいなと思うのであった。

統計学周りは勉強しなおしているので、継続していこうと思う。

この記事が参加している募集

読書感想文

この記事が気に入ったらサポートをしてみませんか?