メトリクスのわな
メトリクスとは、何かを測定するときにその尺度となるものです。例えば、実績値を計画値で割ると計画時の見積り精度を表したメトリクスとなります。「測定なくして改善なし」は改善に対する心構えを的確に表現したデミング博士の有名なフレーズですが、その改善の現場においてメトリクスが良く使われています。本コラムでは、開発プロセスを改革･改善する組織が陥りやすい、間違ったメトリクスの運用について事例とともに紹介します。特に開発したものが見えないソフトウェア開発組織ではよくこの状態に陥ることがあるので要注意です。
間違ったメトリクスの運用事例その1
【症状】メトリクスの取り扱いを誤り改革活動への拒否感、モチベーション低下につながった。
【経緯】プロセス改革を開始するまでメトリクスを測定してなかった精密機器メーカA社。設計工程に起因する不具合を減らすべく、全不具合数に占める設計工程起因の不具合の割合を示すメトリクスを測定し始めた。改革活動の推進役を任されている安部リーダ（仮名）は、改革活動に弾みをつけようと活動に協力的なプロジェクトのメトリクスを社内の発表会で報告した。安部リーダはメトリクスで可視化され次の改善ポイントが見えてくることを他のプロジェクトリーダや組織の管理者層に伝えたかったのだが、発表されたメトリクスがなぜそんなに悪いのか指摘を受けてしまった。結果的にこれまで協力的だったそのプロジェクトのリーダの信頼を失い、また同席していた他プロジェクトリーダも同様に非協力的になってしまった。
【教訓】数値を公表することを事前にプロジェクトリーダに合意を取っておくことやメトリクスの数値だけが一人歩きしないようにプロジェクトを特定できない形で公表するなどの配慮が必要である。また得られたメトリクスの公表だけにとどまらず、悪いメトリクスを根拠に対策を実施し成功したという改善報告ができれば尚良い。
間違ったメトリクスの運用事例その2
【症状】複数のプロジェクトからメトリクスが収集できるようになり組織的に立てた目標を達成したが、なぜか実感が伴わない。
【経緯】プロセス改革を行い3年が経過した自動車部品メーカB社。この間、部品メーカとして納期をキープできるよう各フェーズの日程見積精度を表すメトリクスを測定しつづけた。収集したメトリクスを分析するとプロセス改革の開始当初に立てた目標を達成でき、組織の一部では改革して良くなったという意見も上がっている。しかし、経営者も改革推進の福田部長（仮名）も少しは良くなっていると思っているがその実感がそれほど伴わない。そこで福田部長がメトリクスの中身をより詳しく調べてみると、良くなったと言っているグループのメトリクスは良いデータも悪いデータも全て収集されていたのだが、その他のグループでは問題となったプロジェクトのデータが悉く抜けていることがわかった。問題の収束が最優先でメトリクス収集などやっている暇がないと言い訳をしていたプロジェクトである。
【教訓】良いプロジェクトデータだけを分析しても良い結果しか得られず、もちろんそれは組織全体を表してはいない。組織的なメトリクスを算出する場合、対象としたデータの素性を事前に確認し算出しても問題ないか確認しておく必要がある。今回のケースでは、分析対象としたデータに偏りがあり、そのまま分析するべきではなかった。もし分析を行うなら、プロジェクト終結後でも全データを揃えるか、全データが取れているグループだけを対象に分析する必要がある。
間違ったメトリクスの運用事例その3
【症状】プロセス改革を行い、早々に組織目標を達成したが、プロジェクトから報告されたメトリクスと実態がかみあっていない様に見える。またプロセス改革は現場からの盛り上がりに欠ける。
【経緯】トップの号令の元、プロセス改革を行い売上げに直結する工数の見積もり精度を表すメトリクスを測定し始めた電機メーカ子会社C社。当初立てた目標を1年も前倒して達成してしまった。トップは喜んだが、改革推進担当者の麻生さん（仮名）はその実感が伴わない。現場には成功プロジェクトもあるが、失敗したように見えるプロジェクトが散見されるからだ。しかし失敗したように見えるプロジェクトのメトリクスは問題ない。悩む麻生さんに、親しいベテラン開発者の古賀さん（仮名）が問題になりそうな数値は改竄しているとそっと教えてくれた。C社はトップの指示が絶対であり、悪い報告は「なぜ、なぜ、なぜ？」と追求されるだけで結局「なんとかしろ」で解決されない、正直者が馬鹿をみる組織だった。改革して早々にデータの改竄が常態化してしまっていた。
【教訓】改竄されたデータで作られたメトリクスは百害あって一利もない。もし経営者がこのようなメトリクス分析結果を使うようであれば経営判断を誤ることになる。人手を介さないで収集できるメトリクスや人手を介さないで収集できる仕組みを構築することが必要であるが、このケースでは信頼できるメトリクスが得られるよう組織風土を改革することが先決である。
メトリクスは、例えるなら自動車のスピードメータ、飛行機の計器といったところでしょうか。もちろん表示がデタラメな計器は不要ですね。信頼に足りる計器となるようメトリクスの仕組みつくりが大切です。
また、運転や操縦では計器だけを見ているわけではありません。それと同じ様に開発プロセスの改革もメトリクスだけに固執せずプロセス改革全体をみることが必要です。当たり前のように思うかもしれませんが、先にお話した事例のようなことが改革の現場ではよくあることなのです。読者の皆さんの現場ではいかがでしょうか？
執筆：高野 昌也
※コラムは執筆者の個人的見解であり、ITIDの公式見解を示すものではありません。
