エンジニアとコンサルは似ている？

こんにちは、ケンゾウです。プロフィールにも書いている通り、私はエンジニアとしてキャリアをスタートさせました。そして、第2〜3話にも書いたとおり、戦略ファームに入って沢山の苦労をしました（本連載の第2話〜第3話は、苦労話のほんの一部ですので、残りはまたいつか書きたいと思います）。

では、エンジニアとコンサルの仕事は、かなり違っているのでしょうか？最初は全く異なる仕事だと思っていたのですが、コンサルの仕事に慣れてくると、逆に、実は非常に共通点が多いと思うようになりました。

まずは、戦略コンサルでやっている仕事というのは、「探求」であり、「モノづくり」であるということ。これは、「探求」＝研究、「モノづくり」＝開発と捉えると、まさにエンジニアが行う研究開発そのものと言えます。おそらく何を言っているのか分かりづらいと思いますのでもう少し補足しますね。

まずは「探求」について。戦略ファームのプロジェクトでは、与えられた課題に対して、原因の仮説を立てて、インタビューや調査、データ収集・分析を通じて仮説を検証し、課題の原因を探求していきます。また、課題の原因さえ特定できれば、8割の仕事は終わったようなもので、あとは原因を潰すための対応策を考えれば良いわけです。実はこの作業は、エンジニアが技術的な課題を解決する時とそっくりなプロセスを踏んでいるのです。

次に「モノづくり」ですが、戦略ファームで作る報告書は、個人的には「モノづくり」に通じるところがあると思っています。まず、わかりやすく伝えるために、内容は構造化されており、ロジックが重視されます（詳しく知りたい方は「ロジカル・シンキング—論理的な思考と構成のスキル」という書籍がオススメです）。これは学術論文や技術仕様書を作る作業に通じるものがありますし、また、戦略ファームのコンサルタントは、多くの場合は職人的なところがあって、報告書の作り込みには細部までこだわりを見せることが良くあります。それは、フォントサイズから図形の角度、塗りつぶした色に至るまで、わかりやすく見せるために、様々な工夫がなされます。その様子は、私には、まさにモノづくりに見えるくらいです。

エンジニアとの違い

一方で、エンジニアと全く違うところも当然あります。最も異なるのは、正確さよりもメッセージとしての明確さを重視することです。例えば「現在のアカウント別の営業体制は効果的に機能しているか？」という質問に正確に答えようとして、報告書に「◯◯◯な時には△△△の課題が生じてしまうが、一方で×××な時には効果的に機能する」などと書こうものなら、良いのか悪いのかわからないとダメだしされるのです。シンプルに「△△△の課題が顕在化しており問題あり」と書くべきなのです。どうしても必要なら、注釈に小さく「ただし、×××な時には効果的に機能するが、めったに起こらない」などと書けばよいのです。

また、ある程度の情報でスタンスを取り切ってしまうことも重要です。つまり、良いと思うのか悪いと思うのか、賛成か反対か、自分のスタンスを明確にするのです。元エンジニアとしては、ついつい深堀りしてもっと調べたくなることがあるのですが、ここで真理を追求しにいくと時間がいくらあっても足りません。ただし、これは不十分な情報でも結論を出していいということではなく、ある程度の情報が集まった段階で、「ここまでわかればスタンスをとっても十分相手を説得できる」というポイントを見極める必要があるということなのです。

この様に、エンジニアとコンサルタントで異なる部分もありますが、個人的にはそれ以上に共通する部分が多いと思いますので、エンジニアの方はコンサルタントに向いているのではないかと思います。あなたがエンジニアで、もっとキャリアの幅を広げたいのであれば、コンサルタントへの転身を考えてみてはいかがですか？