February 21, 2004
2/19にWebMethods社のイベントに参加しました。
基本的にはEAIなどは異業種であるが、Business Activity Monitoringというキーワードに惹かれて参加しました。言葉の意味は、文字通り、仕事の流れの中でいろんな問題が起きるわけですが、その問題をシステムがリアルタイムで把握できるようにしておくことで、問題が起きたときにすぐ知ることができるというものです。
例えば、カーナビを例に出していましたが、車を運転していて、この先で道が渋滞しています。カーナビは渋滞情報をリアルタイムに知ることができるので、渋滞を回避するようにナビゲーションしましょう。
これを仕事に置き換えたものが「BAM」というコンセプトだそうです。
担当者が日々の対応に追われ、果たしてこれが正しいのか？正しくないのか？実は、損をしてるのか？儲かってるのか？がわからなくなっているケースってのがあって、そこのところをコンピュータを使うことでリアルタイムに定量的に判断して、必要なら上司に素早く連絡してあげることで、必要なビジネス判断が遅れるのを防ぐことで、効率化しましょう・・・という説明で大丈夫でしょうか？
このシステムの肝は、結局のところ「KPI」というパラメータをどうやって決めるか？というところにあると思います。
KPIとは、Key Peformance Indicationの略で、仕事のある部分に着目して、そのパフォーマンスを定量化して、何が正常なのか、異常なのかを判断するビジネス判断の設計とでも言えば良いのでしょうか？
例えば工場なら、ある特定の機械の一時間あたりの生産個数とかそういうことですかね？この数が計画に対して多いのか？少ないのか？を数えることで、すごく単純に言うと、そのプロセスが、期待通りに動いているのか？動いていないのか？が判断できますよね？この判断基準と、周辺工程の機械の稼働率などをロギングしておくことで、例えば前工程の機械の段取り替えに時間がかかると、後ろの機械は生産能力が落ちてしまって、結果、納期遅れを出してしまいます。だったら前の機械の段取り替えの改善をする投資をしましょう・・・とか、そういうことを考えられるようになりますよね。広範囲のログを分析することで、問題の相関関係が分析できるようになりますし、それをリアルタイムに判断することができます。今まで生産管理の人がExcelを駆使して分析していた仕事をリアルタイムで教えてくれるようになるというわけですね。トヨタのアンドンの発展版と考えれば良いでしょう。
しかし、そもそも論として、このPKIなるパラメータが、定量的に判断しにくい仕事、・・・そうですね、例えばWebデザインとか、その他、いわゆる知的労働だけど、極めて製造業的な数作ってナンボの分野になるでしょうか。このような業種では、効率と品質が特定の人のパフォーマンスに依存してしまっている状態ですね。どれも単位は時間ですが、その進み方が人それぞれ一様ではない。それは、結局のところ全部終わってみないと、現実的な工数がはっきりしないという構造的な問題を抱えています。
納期は遅いけど、クオリティは高い。仕事は速いけどデザインはイマイチ。これはどっちが正しいのでしょうか？というのは、結局、案件ごとの顧客ニーズに対してケースバイケースという現実があります。
こういう業種に対するPKIを決めるのはすごく大変だぞーという、漠然と思っていたことが、余計に明確になってしまった次第です。何を持ってして、正常なのか異常なのかが案件および人に依存してしまっている状態なわけですね。
でも、その人たちのパフォーマンス如何で、納期遅延の原因になったり、利益が失われたりする現実があるなら、やはりトラッキングはしていかなくてはいけないし、それを蓄積していき無駄を改善するための努力をしていかなくてはいけない。さらに案件間の調整となれば、リアルタイムな経営判断で担当者より上の人が制御していくことも必要でしょう。
それらの基礎となるパフォーマンスの計測ルールどのように定量化すれば良いのか？というビジネス設計が、難しいポイントだと思います。スタートとエンドの時間を計測するだけなら簡単にできますが、それにしては一人当たりの仕事の重要度も時間もコストも高いわけです。
効果測定のルールですが、効果を測定しようとするからには、プロセスの変革が不可欠ですが、そこで仕事をする人の「今までのやり方」とぶつかったりするわけですね。ワークプロセスが企業ルールで標準化されていない場合には、仕事のやり方はアナログ的なフローが、すでに既得権益になっているわけです。（だからこそ、改善しようと思うわけですけどね。）
つまり、そこの効果測定のルール自体も「人それぞれ」になっている。では、それをあっさり変えられるか？というと、必ずしもそうでもなかったりして、それはいろいろ都合があると思いますが、外注が絡んだりすると、ただのトップダウンでは済まなかったりします。
外注に対しては、それを使うことで明らかなビジネスメリットをコミットメントしてこそプロセス改革に賛同していただけるものだと思いますので、そういうところまで考えないとこういう話は進まないわけですね。しかし、何もなかったところに効果測定のルールを入れるからには、あきらかに手間が増えることになりますので、それは外注にとっても、現状の担当者にとっても賛同したくない現実があるわけですね。
さらに、言葉は悪いですが商社みたいに入れ替えが容易でない場合には、このシステムに賛同しない業者を切ったりすることは、担当者の利益にも絡んでくる。しかし、例外はシステムの稼働率を下げることになりますので、みんながハッピーになるためには、ただモノを作ればいいわけではないという、当たり前のことにぶつかります。
当たり前だけど、ビジネス設計がきっちりできていないことには、話は進まない。でも「今までのやり方」を変えるのは大変。できるところからやりましょうってのは、ことと次第では「何もできない」ことに繋がるケースもありますね。
・・・とまぁ、そんなことを考えさせられたセミナーでした。そもそも、一開発エンジニアには手に余る話です。
ちなみに、パネルディスカッションで、戦略系コンサルなどの方々が出ていらっしゃって、いろいろ勉強になりましたが、一点だけ気になったのは、こういう意見です。
「ユーザー部門は、目の前の利便性を重視するので、ここに投資額が多く使われる傾向にある。利便性は、実はビジネスプロセスに効果がないことが多い。」
うーん、かなり目上からの意見ですね。やはり場違いだったかなぁと思った瞬間。
立場が違いますから、言わんとする本質は、なんとなくわからなくもないですが、それは言って欲しくなかったと思ったりもしました。エラーを起こすデザインだったら、改善しなくてはいけませんね。どんなに原発が安全だと言っても、それを壊すのは人間のエラーであって、その原因が、いわゆる「利便性」の欠如だったら、どうします？というヘリクツも言いたくなります。でも、実際に、「利便性の欠如」から、とんでもないことが東海村で起きたわけですが。もちろん、それに「無知」というパラメータが加わったとしても重大なエラーです。これを危険率とみなさないのが原発安全論なわけですが、それに近いものを感じますね。
それはさておき、現実には、こういう話があるからにはUIなどに時間もコストもかけられないし、後に改善するチャンスも失いかねないことになってしまう・・・いや、それは確実に大げさだったとしても、僕らとしては最初に作る時にできる限りの範囲で、みんながハッピーなシステムを作れるようになりたいよなぁと、下流工程を支えるものとしては考えさせられました。今流れる時間を大事にしないと、使う人が不幸になるぞ！と。
もしよいGUIを作ることで、諸々の問題が改善されるようになったら、それをネタに、この手の商売でも始めようかな（笑）