解決策志向型の思考をする人は、現象を追ってはいけない。頻出する問題というのは、色々な課題が出てくるように見えていても、実はそれは現象でしかなく、多くの場合はその根っことなっている原因があるはずである。本質的に問題を解決するためにはその根元を叩く必要がある。
大前研一氏の「企業参謀」ではこう述べられている。
私のいままでに見、あるいは聞いてきたかぎりでは、企業内でルーティン化している業務内容改善計画やプロジェクト活動というものは、えてしてこの抽象化のプロセスを踏んでいない。したがって、解決策と問題点が短絡してしまっているのである。たとえば
「問題」＝事業部間人事交流の欠如
「対策」＝事業部間人事の流出入を容易にし、人事交流を計るといったたぐいの短絡した解決である。しかし、現象として現われている問題がなにに帰属する問題であるのか、なにに深くかかわりあいがあるのか、ということの理解なしには真の解決策は得がたい。
この前段では、問題から対策へと短絡的な結論付けをしないために抽象化のプロセスを経ることが大事だと述べられている。
私は、この段階で重要なことは、
「問題点のしぼり方を現象追随的に行うこと」
であると思う。 よく用いられる方法としては、＜図６＞に示したような抽象化のプロセスがある。
この辺りの話は最近の著ではさらに明快になっているので、そちらも引用しておこう。「実戦！問題解決法」から。
PSAの原則３｜原因と現象を混同するな
私の経験では、ほとんどの場合、５割以上のウエートを持っている原因は１つだけ存在する。たくさん問題がありそうに思えても、１つの原因が現象としていろいろな形で問題として出てくるだけなのだ。原因と現象の区別がつかない人は、問題がたくさんあり過ぎて解決のしようがない、という言い方をする。だが、現象に１つ１つにいちいち対処しても、それこそしょうがない。原因をつぶさなければ、絶対に問題は解決しないのだ。
このように、原因はたいてい１つに集約されるのだが、現象はいろいろなところに出てくるから、ＰＳＡを使わないと、現象と原因をはき違えて的はずれな対策を講じてしまうことになる。
つまり、現象を原因だと思い込み、現象に対して対症療法を施し始めるのだ。しかし原因は直っていないから、また別な形で問題が出てくる。それに対してまた対症療法を施す。そうやって際限なく見当違いの対症療法を繰り返す羽目になり、コストばかりがかさんでいく。
具体例を一つ引用しておこう。
たとえば、セールスマンに元気がなくて商品が売れない、という問題があったとする。この場合、典型的な現象に対する対症療法は、社長が各支店・営業所を回ってセールスマンを激励する、という方法だ。車座になって酒を飲んだら、みんな言いたいことを言って、明るくなった、元気が出たな、と社長は喜ぶ。ところが、すべての支店・営業所を回り終えたのに、売り上げはまだ落ちている。そのうちに誰かがセールスマンに元気がないのは固定給のせいで、いくら働いても報奨金が出ないことが問題なんです、と言い始める。分かった、じゃあ売り上げの多いセールスマンはボーナスを２倍にしてやろう、となって動機づけ、すなわちインセンティブ制度を作る。それでも売り上げは落ち続ける。すると、また誰かが、実はインセンティブ制度だと勝者と敗者に差がつきすぎるため、敗者がやる気をなくしているんです、と言ってくる。それはまずい、ということで、今度はみんな２割ぐらい増して固定給に戻す。しかし、やはり売り上げは落ち続ける。そこで再びインセンティブの議論に戻り、いくら働いても差がつかないから、できるセールスマンほど辞めていく、となる。ところが、セールスマンに同行してみると、車のトランクにゴルフバッグがあって、増えた給料がゴルフのプレー代や練習場代、クラブ代に化けていたことが分かる。
現象に対する対症療法を頻繁にやっていく会社は全部これである。常にその時その時に最大の問題ですと言われた現象に対策を打っていくから、コストだけ高いものについて、結局、何も効果がない。
だが、そういう状況でも、売り上げが落ちている原因は１つ、最大で２つしかない。ＰＳＡを使って原因を探っていくと、問題は全く違うところにあることがほとんどだ。先ほどの会社の場合だと、製造部門は一生懸命やっているから、この２年で４回も製品が変わった。しかし、セールスマンは新しい製品に関する知識が不足している。そればかりか潜在的なお客さんを見つけるスキルもなければ、お客さんを説得していくスキルもない。つまり、セールスマンとしての基本的なトレーニングができていないことが原因だったりするのだ。
* PSA = Problem Solving Approachの略
さて、ここまでの話を踏まえて、システム開発の世界にはユーザーニーズというものがある。多くの場合、これは正解とニアリーイコールとして扱われ、システム開発のゴールの指標である。
しかし、あえて指摘したい。ユーザーニーズとは、多くの場合、現象でしかない。色々な問題を思いつくがままに語っているだけである。それを一つずつ潰していっても、それは対症療法なのだ。本来、情報システムが解決すべき問題というのはその延長線上には乗っかっていないことが多い。結局、経営には役に立たないシステム、効果の表れないシステム、という扱いを受けるのである。
以前、よしおか氏が「正しいものを作ることと正しくものを作ること」というエントリを書かれていた。「正しくものを作る」のは必要条件だ。ただ、それも「正しいもの」が理解できた上でのことである。
それでは、ユーザーニーズを聞いてはいけない状況の中で、「正しいもの」とは何なのか？
それはユーザーのミッションに沿ったシステムだ。ユーザーがその企業の中で求められているものは何か。そして、そのシステムが求められる価値は何か。それを徹底的に追求しなければならない。ユーザーインタフェースの使い勝手を上げるのは重要だ。ただ、オペレーター（＝ユーザーである場合も多い）のためにシステムがあるわけではない。顧客である企業の戦略を支え、その企業が競合から一歩でもリードするためにシステムがあるのである。
システムを作るものはサービス業だという言われ方をすることがある。これは間違っていない。ただ、serveする相手を間違えてはいけないと思う。オペレーターへ親切なシステムを目指すのではない。serveすべきは企業なのである。この視点を忘れると、頑張って作って、よくできてはいるが、何の役にも立たないシステムになりかねない。
受けると思われる指摘として、それはコンサルタントの領域の仕事だろう、とか、仮にエンジニアがそれをやろうとしても現実問題できるのか、という指摘があると思う。顧客との関係にもよるが、難しいケースが多いのは承知している。大抵、システム開発の発注をかけるときにはシステムの開発をするということ自体は決定済みなのだ。それをそこから「そもそも論」で話を戻すのはよほどの裏付けがないと難しい。それが現実だ。
エンジニアでこれをできる人がどれだけいるのか、それも大いに疑問だ。いや、正直、ほとんどいないと思っている。ただ、問題の指摘はできるだろう。戦略が不在、ミッションを理解していない、というケースにはそちらを固めないとシステムへの投資は無駄になる、という指摘をすることはできる。問題提起をすれば、解決のために外部の専門家の手を借りるという選択肢も出てくるだろう。
情報システムへの風当たりが強まる中だからこそ、ここまで突っ込んでやる必要がある。なぜなら、これがシステム開発で問題となることの「５割以上のウエートを持っている原因」となっていると考えているからだ。
※念のため
途中、厳しめの表現となっていますが、「利用者に優しいシステムに意味がない」とは言っていないです。進む方向が間違っているときに、一生懸命オールを漕いでも仕方ないと言いたいだけです。方向を合わせたら、後は力いっぱい少しでも速くなるように漕げばいいと思います。
