何を測定するのか

前回、感知－判断－アクションのトライアングルという話をしました。そのなかの感知ということについて考えていきましょう。センス＆レスポンスという言葉を聞くことがあります。何かの事象を検知し、その状態によって適切な答えを導き出し、対応するということになります。まさに、そのセンスのことです。

一見簡単そうですが、けっこう難しいのが、何を測定するのかということと測定できるのかという問題です。やたら測定するわけにはいきませんから、“そこの値”を測定するちゃんとした理由がなくてはいけません。

そこは、後ろから考えていきます。すなわち、そのプロセスのパフォーマンスは何で測るのかという問いから見ていきます。そして、これもトップダウン的なものとボトムアップ的なものがあります。

トップダウンというのは、戦略実現のためのパフォーマンスチェックです。よくやられるのは、バランススコアカードから導出されたKPIやKGIになります。ただ、これはそのままというわけにはいかないので、プロセスの測定値や計算値への翻訳が必要になります。

一方、ボトムアップというのは、オペレーショナルな意味合いのもので、どんなプロセスにもデフォルトで備わっているべきパフォーマンスで、基本的にはQCDFになります。すなわち、早く低コストで質の高い、そして変化対応力のあるオペレーションをしているかということです。

この二通りのパフォーマンス管理を分けて考えたらいいと思っています。ボトムアップはそう難しいことはなくて、早さは各意思決定のスピードを、コストは人数☓時間（これはABC：Activity Based Costingですね）をみます。では質はどうして測ったらよいのでしょう。ここでは、手戻り率を採用しています。意志決定の質でもあって、これが悪いと後工程から戻ってくるからです。

変化対応力はどうでしょうか。この場合の変化とは不確定な要求がくることですから、それにいかに迅速に応えるかということになります。おそらく応え方は、フローの順番を変える、意思決定の基準を変えるといったことかもしれません。

問題は、これを最初から予測してあらゆるケースを作り込んでおくかですが、そんなことは不可能です。では実際にそういう状況になった時にいちいちコードを書き足したり、変更したりすることでしょうか。それでは変化対応力があるとは言えません。

結局、そこが重要なところで、作り方になるわけで、コードを書かずに部品（コンポーネント）の差し替えといったことが可能なPluggableな構造にしておくことです。雪道になったらスノータイヤに取り換えて運転するといったイメージですね。