測定無くして改善無し、なんてことは無し

「測定無くして改善無し」という言葉をよく聞く。一見、正しい。しかし本当は、違うと思う。厳密に言うと、組立機械産業における生産工程のように測定しやすいドメインで、かつ非常に改善レベルの高い組織であれば成立する。しかしソフトウェア開発のように測定しにくいドメインで、かつそんなに改善レベルが高いわけでない組織の場合は成立しないと思う。

そんなに改善レベルが高いわけではない組織の場合、「測定無くして改善無し」の原則を貫こうとするとどうなるか。まず問題点を把握するために測定を行う。しかし把握するために測定するのだから、問題点は分かっていない。いや現場は分かっているのだが、測定を推進する人は分かっていない。するとイキオイ、結果系のメトリクスばかり測定するようになる。バグ密度とか。少し気が利いている人だと、レビュー密度とか。で、統計解析を行うわけだ。

統計解析というのは怖いもので、何かデータを入れれば、何か式が出てくる。すると、何かが分かった気になる。「レビュー時間が少ないから、不具合が多いのだ。ほら、この式とグラフを見よ。一目瞭然だ」。

このセリフに違和感を感じた人は、正常だと思う。そんなことは、言われなくても現場は皆分かっている。一目瞭然どころか、見なくても知っている。それをわざわざコストをかけて測定し分析しても、ありがたみは無い。むしろコストアップになって有害である。

改善レベルが高いわけではない組織には、問題点がたくさんある。しかもその多くは、現場が肌感覚として認識している。であれば最初にすべきことは、何も分からない状態で測定することではない。

最初にすべきことは、どんなトラブルがどれくらい起こっているかを棚卸しすることだ。次に現場の開発者が寄り集まって、無理ならキーマン達だけでも集まって、現場で起きている問題点からトラブルまでを丁寧に紡いでいくべきだ。この作業に、測定はいらない。必要なのは、トラブルを見つめ直すこと、自分たちが普段感じている問題点を吐き出すこと、そして論理的にそれらをつないでいくことだ。落ち着いて、腰を据えて、時間をかけて、取り組むことだ。

そうやって「トラブルのモデル」を作ったら、次に改善策を設計する。ここで改善策をブレーンストーミングなどの“思いつき”で挙げてはならない。良いトラブルモデルは、適切な改善策を示唆するからだ。もし適切な改善策が示唆されないのであれば、頭を抱えてう～んと呻るよりも、トラブルモデルを見直した方がよい。もし余力があれば、その改善策が形骸化する状況まで推察するとよい。

そこまでできて始めて、測定の登場に相成るわけだ。トラブルの根本原因となっている悪さを示すメトリクス、トラブルの起き方を示すメトリクス、改善策が有効に機能していることを示すメトリクス、改善策が形骸化することを示すメトリクスを定義し、測定するのだ。これらのメトリクスは、トラブルモデルがきちんと組まれていると容易に決められるだろう。

こうやって決めたメトリクスは、結局のところトラブルモデル通りにトラブルが発生しているかどうかを確認するためのもので、何だか分からない問題点をあぶり出すために測定するものではない。測定で何か新しいことを把握する前に、やるべきことがたくさんあるのだから。

そうやって改善策を実施していくと、測定しなくても改善していることが現場の開発者には実感できるはずだ。改善効果を実感するために測定せよ、なんてことを言う人がいるが、良い改善策であれば、改善策を実施していると改善できていることが測定しなくても実感できる。測定はあくまで、その実感を追認するためのものだ。

この文章は別に、測定そのものを否定しているわけではない。測定は改善のための強力なツールであることは全く同意する。だからこそ、この強力なツールを最大限に活かさないといけないのだ。あまりに強力であるがゆえに、測定すれば何か新しい問題点が分かり、測定すれば改善されると誤解してしまうのである。しかし本当は、強力なツールだからこそ、使う側の我々が現場をよく知り、よく考えねばならないのだ。測定は目的ではない。知恵を絞って現場の問題を考え抜くための道具なのである。ソフトウェアの開発を改善しようとしている人達には、そこを誤解しないで欲しいと強く思う。