「システムを活用するから成果が上がるのではなく、成果が上がるからシステムが活用される」という話

例によって技術ブログという位置づけにそぐわないのですが、本記事では最近なんとなく思っている「システムを活用するから成果が上がるのではなく、成果が上がるからシステムが活用される」という考え方についてまとめてみたいと思います。

※写真は全く関係ないです。

企業が業務システムを導入するとき、ユーザー企業は「せっかく新しいシステムをいれるのだから、ユーザー部門に機能をフル活用してもらって、なんらかの成果につなげたい」と考えるのが普通だと思います。

私たちベンダー側も同じことを考えています。

せっかく投資していただくのですから、システムを使い倒して”便利になったなー”とか、”導入前は見えなかった数字が見えるようになった”とか、喜んでもらいたいと思っています。（そんなこと思っていないよという擦れた人もこの業界にはいっぱいいますが、少なくともIT業界に足を踏み入れた初日は誰もがそう思っていたはずです。）

しかし、システムの導入が進んでいくにつれ”前のシステムでは承認ボタンを押したら画面に印影が表示されたのに、新しいシステムでは印影が表示されなくて不安だから別途印刷して押印してます”とか、”このボタンを押したら為替差損益が自動で計上されることは知っているけど、いままでと違うやり方を試すのはなんか怖いから、これまで通り手で仕訳を入れてるんです”といったように、負の側面(?)にフォーカスが当たってしまい、限定的にしか機能が活用されないケースがあります。

この状況にどのように対処すべきかは、ユーザー企業が「業務の標準化」というものをどう考えているかによります。したがって、私たちベンダー側がどうのこうのいう問題ではありません。

外資系企業であれば「定められた手順通りに業務を進めるべきであり、上記のような状態は是正すべきである」となり、日系企業であれば「業務のやり方はその業務に詳しい人が決めるべきなので、ある程度は許容しよう」となる傾向が強いでしょう。私たちもその辺の空気を読みながら対応を考えます。

ところで、本記事ではどこまで厳格に業務を標準化すべきかという議論はいったんおいておきまして、、私たちベンダー側のシンプルな想いとして「せっかくだから機能をちゃんと使って、”システム入れてよかったやん”って思ってくれるとうれしいなー」という観点から話を展開していきたいと思います。

・・で、話を戻しますと、システムが思ったように活用されていないとき、その理由としては以下のようなパターンが考えられます。

1. そのような機能があることを知らなかった
2. 機能があることは知っていたけど、それを使う意味がよくわからない
3. 機能の存在は知っていて、使えばどうなるかもわかっているけどなんか怖いし、なんか嫌
4. ”自分にしかできない業務”としてブラックボックスにしておきたい
5. （何かの理由により）システム導入自体、頓挫してほしいと考えている

上記の理由のうち、1は単純に説明不足ですし、4と5に対してはちょっとコメントが難しいので本記事ではスルーするのですが、、2と3の状況に対していつも私が思い浮かべるのは「人はCash on Deliveryで動くものだ」という、昔読んだ何かのビジネス書にでてきた意識高めの言葉です。

ここで言うCash on Deliveryとは、立ち飲み屋さんで330円と引き換えに牛筋煮込みをうけとるときのあれです。つまり、現金330円という対価を支払うタイミングと、牛筋煮込みという成果を手に入れるタイミングが同じであるということです。

一方、これをシステム導入に置き換えると、ユーザー視点では対価を払うタイミングと成果を手に入れるタイミングはズレるのが普通です。

業務のやり方を変えたり、新しい機能の使い方を覚えたりという苦労（＝対価の支払い）をするタイミングと、その運用がこなれてきて業務が効率化されたり、これまで見えなかった数字がみえるようになったり、という成果が出てくるタイミングは一致しないということです。

「業務のやり方を変えるために社内外の人たちと調整しなきゃいけないし、これまで触ったことのない新しいシステムの画面を使って、いままでExcelでやっていた内容が裏側で自動化されてるよとか言われても何かよくわからんし、、エラーが出て問い合わせたらマスタの設定がおかしいとか言われてなんでそれがここに影響するねん、、」みたいな状況。

これがユーザー部門が支払う対価です。そして多くの場合、程度の差はあれど、これは不可避です。

そのような状況が長く続いてしまうと、ユーザー側としては新しい機能を覚えて活用していくことへの意欲がどんどん薄れ、機能単位でみたときに上記2や3の状況に陥ってしまいます。

これは（特にベンダー側の立場からは）対処が難しい問題ではあるのですが、少なくとも「”システム入れてよかったやん”って思ってほしいな」という気持ちがあるうちは、上記のような構造になっているということは常に頭に入れておくべきだと私は考えています。

もちろん、構造上の問題なのでちゃちゃっと解決できるようなものではありません。

新しい業務のやり方に慣れて、新しい機能の使い方を覚えない限り、その機能を使うことによる成果は現れないからです。あたりまえのことです。

システム活用というテーマに限らず、Cash on Delivery問題への対処には3つのアプローチがあります。

１つは「Cash（対価の支払い）とDelivery（成果の受取）のタイミングをできるだけ近づける」こと、2つ目は「Cashに対して大きなDeliveryを提供する」ということです。

いずれも”それができれば苦労せんやろ”という話なのですが、大事なのは3つ目のアプローチ、すなわち「スケールや視点を変えて、CashとDeliveryが対応するように調整する」ということです。

つまり、機能単位でのCash on Deliveryは難しいけども、プロジェクト/フェーズ単位でのCash on Deliveryは実現する。できれば部門単位でCash on Deliveryを目指したい。というのが、現時点で私たちが考える最適解です。

例としてERPを新たに導入する場合を考えてみましょう。

かなりざっくりした言い方になりますが、ERPを導入するために、ユーザー部門は業務のやり方を変えたり、新しい機能を覚えたりといった対価を払うことになります。そしてその成果として、一部の業務が効率化されたり、これまで見えなかった数字が見えてきたりします。

このとき、私たちベンダー側がつい言ってしまいがちな言葉として「まずはシステムを稼働させることに注力しましょう、そして運用が落ち着いてからシステムの有効活用やデータ活用のためのフェーズに展開していきましょう」というものがあります。

この発想はとても理にかなっているし、予算やスケジュール上の制約からそのような段取りでプロジェクトを進めなければいけないことも多くあります。

しかし、これは必ずしも顧客視点での発想ではありません。ユーザー側の観点で言えば、機能単位でみたときにも、プロジェクト/フェーズ単位でみたときにもCash on Deliveryにならないからです。

対価を先に払って、成果は後から来るから待っててねということです。

そして、この発想の裏には、しばしば「データ活用をリードできる人材がいないから、あとからそういうリソースを調達する前提にしておいて、実装は次フェーズに持ち込みたい」というベンダー側の都合があったりもします。（その場合、”次フェーズ”の提案は実行されないことも多いです。）

なので、とても難しい問題ではあるものの、それでも私たちとしては多少何かを犠牲にしてでも、ユーザー部門の方から見たときにシステム導入に係る対価と成果が同じタイミングで発生するような工夫をすべきと考えています。

そのような考え方のことを「システムを活用するから成果が上がるのではなく、成果が上がるからシステムが活用される」という言い方で表現したいなと漠然と思っている次第です。

あまりキレイに考えがまとまっていないのですが。。

・・ということで、最近なんとなく思っている「システムを活用するから成果が上がるのではなく、成果が上がるからシステムが活用される」という考え方をモヤっとした文章にしてみました。これといった結論がなく、なんか根性論みたいな話になってしまいましたが、このタイミングで文章にしておいた方がいいかなと思った次第です。

何が対価で何が成果かは案件の状況や案件に携わる人の役割によって異なります。そして、「ユーザー部門も含めて、みんなハッピーになればいいな」みたいな考え方は多分に理想論ではあります。

それでも、まあなんとなくそういう想いでベンダー側もがんばっているんだな、くらいに思ってもらえるとうれしいです。