システムは、顧客が直面している問題を解消する手段になる。従って、システム提案は、顧客の要望を聞いて、それを実現する手段を示すことになる。しかし、上流の領域に足を踏み入れると、それだけでは済まなくなる。

 筆者がITコンサルティング事業をはじめたころの話をしよう。営業リーダーからの依頼で、ある大企業の情シス責任者への提案活動に加わった。このとき、営業チームで既に提案を2回していたが、いずれも相手にしてもらえていなかった。筆者は、営業リーダーから禅問答のような議事録を見せられ、責任者への説明に同行するよう依頼されたのだ。

 情シス責任者のやりたいことは、業務を可視化し、部門横断で最適化することであった。初回の提案は、各部門にヒアリングして全社業務モデルを組み立てて可視化するものだったが、「各部門へのヒアリングは必要ない」と指摘されていた。進め方に対する指摘だと考え、2回目の提案で、先に全社業務モデルの仮説を描き、各部門に見てもらって修正して完成させる進め方を提示した。ところが、今度は「業務モデルを作成する必要はない」と指摘を受け、完全に行き詰まっていた。

 情報の可視化には、その対象となる何らかの情報モデルが必要である。業務の可視化には、業務モデルが必要であり、それが現実の業務を正しく表していなければ、全体最適化ができるはずがない。従って、正しい業務モデルを作るには業務部門の担当者から何ららかの方法で情報を取り入れる必要がある。どちらも不要というのは誤解があるに違いないと営業リーダーは考えたのだ。この案件に提案していた競合他社も成果を挙げられていなかった。

 筆者も最初は営業リーダーの主張はもっともだと思っていた。ところが、話を聞いていくと、この責任者が誤解していなかったことが判明する。

新アイデアは理解が難しい

 当時、可視化と言うと、UMLのアクティビティー図などを用いてモデリングするという先入観があった。しかしこの責任者は、作業者の活動をシステムが監視し、それを関心のある人に通知する新しいアイデアを思いついたという話をしていたのだ。システムが把握した活動の内容を部門横断で取りまとめて可視化すれば業務の最適化ができるという議論だった。

 だとすると、正しい業務モデルはシステムによって自動的に組み立てられる。つまり、業務部門へのヒアリングも業務モデルの作成も必要ないという責任者の考えは正しかったのだ。