LeanとDevOps生産性の神話(2) - 数えられるものは全て数えろ
「LeanとDevOpsの科学」出版以降に触れていこう。まずは翌年2019年GitHubのカンファレンスでPull Pandaというスタートアップのアビ・ノダ氏が話した内容を見てみたい。
アビ・ノダ氏のトークは非常に面白く、DevOpsにとどまらず開発全体の生産性のメトリックについて触れている。彼の父親は長年ソフトウエア開発者をしていたそうで、息子が相談するメトリックの内容をことごとく否定するのが、多くの開発者が持つ生産性メトリックに対するアレルギーを代表しているようで、トークに一種のコミックリリーフ的なメリハリを与えている。このトークの前年に出版された「LeanとDevOpsの科学」についても触れており、この本に感銘をうけたノダ氏が父親にも読ませたところ、やれやれとばかりに頭を振り、最後には「おまえはエンジニアリング・メトリックのアインシュタインじゃないんだぞ」と言われて喧嘩になってしまう。
ソースコードの行数は計測すべきではないのか？
そもそも開発者の生産性なんか計測できないんだというのが父親の主張である。本当にそうなのか？コミットの頻度や、ソースコードの行数を例に取って、アビ・ノダ氏は丁寧に議論を進めていく。
Number of lines of code written is not a measure of your value to a project.
— Scott Hanselman 🌮 (@shanselman) April 13, 2019
ソフトウェアでは行数が多いからといって価値が高いわけではないのは、自明のことだし、同じ機能を実現できるのであれば、むしろ行数が少ないほうが価値が高いともいえる。
こうした議論はこれまで何度も繰り返されてきた。アビ・ノダ氏はこうした開発生産性のメトリックは依然として重要であるとしたうえで、これまでは、メトリックの使い方がまずかったのだと言う。
「Measure process -- not output」
アウトプットではなくプロセスを測定しよ。
プロセスという言葉は注釈が必要な気がする。日本語だと「進行、過程、経過」「方法、手順、工程」と訳されるが、ここでのプロセスはCMMIで言うプロセスと同じで、時間の経過に伴う変化の程度を指していると思う。
その観点からソースコード行数を見直すと、行数が増えたからといって単純に価値が高いと判断するのではなく、ある時間軸のなかでの行数の増減の程度を測定するということになる。場合によってはコード行数の変化が無いということ自体も重要な情報になるのだ。
「４つくれ」「２つで十分ですよ！」
「LeanとDevOpsの科学」出版以降、DevOpsメトリックの議論が巻き起こった。４つのキーメトリックで組織全体の生産性が測定できるという主張には疑義があったものの、DevOpsの生産性を測る上でのメトリックはどういったものが適切なのだろうかという問いには、誰もが自分のアイデアを言いたくてしかたがなくなるものがあったようだ。
codemotionという開発者コミュニティサイトにGilad David Maayan氏が寄稿した文章ではフォーキーズに２つメトリックを追加して６つのメトリックを提案している。同じくHubspotにStephen Roddewig氏は８つのメトリックを。Stackify社は「LeanとDevOpsの科学」出版前の2017年12月の時点で既に１５のメトリックを提案している。探せばもっと多くの提案があるだろう。とりあえず目についたDevOpsメトリックの提案例をまとめてみたのが下の表だ。
これを見てわかるのは、どんな開発組織でも有効な共通のDevOpsメトリックは存在しないのではないかということだ。
数えられるものは全て数えろ
「Not everything that can be counted… counts.」
数えられるものが全て重要なわけではない
DevOpsメトリックの議論が行われているのと同じ時期に、大きな技術革新があった。それはサービスメトリックの分野だ。
クラウドサービスの普及と共にサービスの状況を把握するための様々な技術やサービスが開発されてきた。コンテナ技術の普及がそれをさらに加速させた。
ログ収集分析のSplunk、サービス監視のNew Relic、同じくサービス監視のDataDog。AWS, GCP, Azureといったクラウドサービスも数えきれないほどのメトリックの取得ができるようになった。ビジュアライズでは、Open SourceのGrafanaによってコストをかけずに、簡単にログのビジュアライズができるようになった。同じくOpen SourceのElastic Serchの登場により、構造化されたログの分析ができるようになった。
githubやbitbucketのようなクラウドベースのソースコード管理が一般化したこともあり、ソースコードの行数の計測やcommitの頻度、Pull Requestのターンアラウンドタイムの計測のコストがほぼゼロになった。
膨大なデータをさばけるサービスメトリックの技術をもってすれば、生産性メトリック程度のデータ分析は文字通り朝飯前になった。
こうなってくると、いちいちどのメトリックを取るとか取らないとかを考えるのがバカバカしくなってくる。つべこべ言ってないで全部取ってしまって、その上でサービスメトリックのように片っ端からデータを並べて因果関係や関連性を読み取るのが重要ではないか。「数えられるものは全て数えろ」という時代になったのだ。
「私たちはLeanですよね？」
「This is Lean」という本に面白い挿話がある。
自分たちの改善プロセスに自信があるヨーロッパのエンジニアリング会社があるときトヨタの伝説的マネージャーである大庭氏を招いた。
会社の代表が、大庭氏にお墨付きをもらおうと、このように尋ねる。
「私たちはリーンですよね？」。答えはもうわかっている、といった様子で
代表者の一人が尋ねたのだが、大庭氏はただひとこと「おもしろい」とだけ発した。
どうしても大庭氏に評価してもらいたいマネージャーがさらに尋ねる。
「間違いなくリーンですよね？」と会社のマネージャーが尋ねる。すると大庭氏はまた、たったひとこと「おもしろい」とだけ答える。
痺れを切らした会長が、ついにこのように尋ねる。
「大庭さん、あなたに工場のすべてをお見せして、私たちがリーンとどう取
り組んでいるか説明させていただきました。リーンとの取り組みに、我々は誇りをもっています。あなたが見たものが世界クラスのリーンであるかどうか、教えていただければ幸いなのですが」
大庭氏の答えはとても短く、しかし的を射ていた。 「わかりません。昨日がどうだったか、知りませんから」
この挿話もまた「LeanとDevOpsの科学」の的確な批評になっているように思える。「LeanとDevOpsの科学」では４つのキーメトリックの数値から、組織がハイパフォーマンスかローパフォマンスか診断しているが、大庭氏であれば、そんな判断はできないというだろう。なぜなら「昨日がどうだったか、知」らないからだ。
この記事が気に入ったらサポートをしてみませんか？