コンサルタントとは

いま ERP の設計をしている顧客のところには、我々が入る前にコンサルタントが入っていた。コンサルタントと自称する営業などではなく、コンサルタントという「職種」の人たちと仕事をするのは実ははじめて。

彼らは我々のことを SIer (=システム屋) と呼ぶ。SIer より先に入って我々のことをそう呼ぶのであれば、すでに業務プロセスの As-Is (=現状) は分析し、To-Be (=あるべき姿) もモデル化されており、我々の仕事は To-Be モデルの実装化なのだと思いきや、さにあらず ...

「To-Be は実装に大きく依存・影響するのでモデル化していません (≒できません)」と彼らは言う。まあ、そういう面は確かにある。プロダクトを担いでいないと顧客に To-Be モデルの提示もできないであろうことは薄々感じていたが、コンサルタントが自分ではっきりそういうのたまうとは ... 結局、To-Be 業務プロセス設計も我々が行うことに。ところが、モデル化していないどころか、To-Be 業務プロセス設計のために必要な As-Is の業務プロセスや文書も彼らは整理していない。

では「何をするコンサルタントなんだ?」と問えば「プロジェクト管理」だと。プロジェクト管理など、それこそ SIer の仕事 (の一部) ではないか。先に入っていながら As-Is の業務プロセスも文書も整理していないでプロジェクトを管理していると言えるのか?

彼らに「システム機能と業務部門が多岐にわたり複雑に絡まっているため、それぞれの機能について SIer 側設計主管が誰で、顧客側承認者が誰か、みな理解できないでいることがボトルネックとなり要件定義が進まない。整理し、部門間調整してくれ」と依頼すれば、「ではその資料を作成してくれ」と付き返される。その資料を作成して再度依頼すれば、関係者がわからないから調整を依頼している私に「ミーティングを設定したから、その資料を持って勝手に出席してくれ」と言い残して、自分は出席しない。管理業務とは「管理業務を分割して人に振る仕事」か? そりゃトートロジーだ。プロジェクト管理も我々に振るのなら、我々が入る前に我々の仕事の納期を勝手に決めないでくれ。それは権限と責任のミスマッチだ。

何の付加価値を生まない仕事に Fee を支払っているのは顧客だから別に思うところはないが、確かに聡明・利発な彼らが (いくぶんの侮蔑を込めて) SIer と呼ぶ我々の仕事のサブセットしかできないでコンサルタントと称することに自尊心が痛むことはないのかと疑問に思う。

新卒の時、私はコンサルタントになりたかった。しかし、理想論者であった私がコンサルタントという職種につけばきっと現実から乖離して使い物にならなくなると思い、自社プロダクトを持つ事業会社の法人営業部門で実業に携わりながら、一方で自分流コンサルティングを行う道を選んだ。それが正しい判断だったという状況証拠はいままで数多くあれど、ここにきてついに物的証拠を得たのだと思う。

彼らが業務コンサルティングを半ば放棄しているからこそ、めざしていたその仕事を私が担うようになっていることを考えれば幸せなのかもしれないとも思いつつ、本来業務と振ってくる管理業務を合わせた高い負荷に今日も耐える。