エンジニアリングに学ぶコンサルティングの本質

コンサルティング業界に飛び込んでしばらく経って気づいたことだが、エンジニアリング的思考は、コンサルティングの思考と非常に似ている。

エンジニアリングの基本的な考え方を知っておくことは、ビジネスパーソンとして、大きな差別化となるはずだ。

システムエンジニアリングの概念
写真＝iStock.com／metamorworks
※写真はイメージです

コンサルティングとエンジニアリングで最も似ている部分は、「データや事実に基づいて議論を行うこと」である。

一般論だが、お客様は、その業界において多くの経験をされているため、普段はその経験に基づいて、経営の意思決定を行っている。

しかし、外部の人間であるコンサルタントは、その会社での実経験があるわけではない。長年、常駐していたりすると別だが、コンサルタントはよくも悪くもその会社での実経験はない。

そのため、コンサルティングでは、データを客観的に収集し、インタビューにより客観的な事実を集め、それらを並べてクライアントと議論することになる。上司・部下のしがらみも利害関係もないため、ファクトベースで、本音で議論を行う。

実は社内のメンバーだけだと、この「本音の議論」はやりにくい。空気を読まず、上司に本当のことを言ったら、飛ばされてしまったというのはよくある話だ。

データを集めて仮説を立てて検証する作業の繰り返し

データや事実に基づき、客観的に議論するのはコンサルタントの付加価値の一つである。

若くても戦略コンサルタントとして通用する部分があるとすると、事実に基づいたデータの収集と客観性である。

エンジニアリングも同様で、データをコツコツ収集し、そこから仮説を見つけて、検証を行う。多数のインプットデータに対し多数のアウトプットデータが出てくるわけだが、なぜそのようなアウトプットになるのか、そのメカニズムを解明し、数学的にモデリングし、さらに新たなデータで検証する。

データ収集→仮説→モデリング→検証→仮説修正→検証……の繰り返しである。このデータ収集→仮説→検証の繰り返しは、コンサルティングで行われていることと、大きくは変わらない。

コンサルタントの元祖ともいうべき、科学的管理法を確立したフレデリック・テイラー氏がハーバードの法学部に入学しながらも中退し、その後、技術者として成功したことを考えると、当たり前なのかもしれない。