元設計エンジニアがコンサルになって苦労したこと

業務コンサルタントのT（@T14764）です。

1月に本ブログを始めて、本記事でちょうど10記事目です。1つの区切りとして目標にしていたので、まずはうれしいです。朝一でブログを書く習慣が付きました。コンサルとして働きながらなので、あまり時間が取れず、毎日書いても月に4〜５記事と遅筆にはなりますが、これからも読んでもらえると嬉しいです。

さて、本題です。

僕は元々、通信機器の設計開発をやっていました。新卒入社後4年半経験し、その後現在の設計業務コンサルタントに転職しました。

今コンサルは4年目ですので、まだエンジニアをやっていた経験の方が長いですが、いずれも3年以上経験し、どちらも基本的な仕事はある程度分かりました。

そこで、両方の仕事を経験した者として、エンジニアからコンサルに転職した際に苦労したことについて共有します。

振り返ってみると、僕が苦労したことは、エンジニアに限らず、コンサルに転職した方は多かれ少なかれ経験することだと思います。乗り越え方、克服法も合わせて紹介しますので、コンサルに興味のある方や、なったばかりの方には少なからず参考になると思います。（根性論チックなものが多くなりましたが・・・）

全部で6つ挙げてみました。

1. ゼロベースで考えること

苦労したこと1つ目。何をするにも基本的にはゼロベースから考えないといけないところです。

・帰納法ではなく演繹法である

エンジニアの場合、使う技術は共通しているので、過去の設計資産をある程度流用できます。また、工数が限られていて納期もあるので、流用することが当たり前でした。何か新しい設計を考える場合でも、まずは過去の設計資産を調査し、使えるものはないかを探した上で設計を始めます。今ある情報を積み上げて結論を導く、帰納法的な仕事の進め方です。

一方、コンサルはその逆で、毎回お客さん、テーマ、課題が異なるので、過去やってきたことがそのまま使えることはありません。また、他社事例などを参考にすることはありますが、個別要素も多いので、設計のようにそのまま流用することは不可能です。

お客さんはコンサルに、まずは理想を語ってほしいと思っています。ですので、過去のことは一旦忘れて、ゼロからあるべき姿を考える必要があります。まずこうじゃないかという結論・仮説ありきで、そこから必要な情報を漏れなくダブりなく集めていく、演繹的な仕事の進め方です。

それまで設計職としての頭の使い方が染み付いていたので、いざコンサルになった時に、逆のことをしなければならずとても大変でした。癖とか習慣を変える、特に頭の使い方となると、本能的な拒否感もあって辛かったです。

乗り越え方としては、そういう頭の使い方を実践するしかないです。自分が何かを考えているなと思ったら、もう一人の自分を登場させ「帰納法的に考えていないか？」と、考えている自分に質問するイメージです。いわゆる、メタ認知ですね。

ただ、演繹的なアプローチは一度身に付けてしまえば、どんな時でも使えるスーパー汎用的思考法なので、苦労を乗り越えて良かったなと、今となっては思います。

・タスクがころころ変わる

エンジニアの仕事は、基本的にはタスクが決まっています。要求仕様明確化→基本設計（試作をしたり図面案を書いたり）→詳細設計（最終図面を書く）→設計レビュー→試験仕様書作成→試験→梱包→出荷、のように。これらそれぞれのタスクの期限を、納期に間に合うよう逆算で切っていけば、計画が完成します。あとはそれに従って予実管理を行い、遅れそうな場合は対策を打ちます。技術的な課題の解決は大変ですが、それさえクリアできれば、残りはいかに早く正確に仕事をができるかが勝負の世界です。

一方、コンサルの仕事は、何をするフェーズか（構想企画？業務モデリング？要件定義？）は決まっているものの、お客さんも違えば目的や課題も違うので、プロジェクト毎にタスクが全く違います。定型的にタスク化することは不可能です。

もちろん、プロジェクト開始時に計画を立てるので、その時点で仮のタスクは考えます。ただ、大体は１ヶ月もすれば、当初立てた計画は見直しになります。なぜなら、そもそもが誰もまだ経験したことの無いことを実現しようとしているためです。未来をどう実現すれば良いかを正確に予測することなど不可能です。当初の想定と異なる情報が入ってきて進め方が変わったり、経営層が変わりプロジェクト予算や期待が変わって方針もガラッと変わったり、などは日常茶飯事です。何ならプロジェクトの目的自体が見直しになることもあります笑

このような計画の見直しは、下手すると毎週起こります。そしてその度に、進め方が変わっても目的が達成できるよう、タスクそのものを考え直す必要があります。

この変化の激しさやそのスピード感に着いて行くのに苦労しました。何というか、このタスクを進めればプロジェクトが終わるから、あとはやるだけ、みたいな状態が無いので、常に先行き不透明で安心できないんですよね。ですので、プロジェクト終了までずっと計画を練り続けなければならず、かなり疲れます笑

そんな苦労の克服法としては、過去についてウジウジ悩み、現状に対する愚痴を考えているのではなく、建設的なことを考えているんだ、と前向きに捉え自分を鼓舞すること。未来について楽しく妄想しているんだ、という心持ちで考えることですかね。

2. 明確な答えが無い中で進んで行くこと

常に明確な答えが無い中で進んで行くのは、誰しも不安です。

エンジニアの場合は、要求仕様という定量的で明確な目標があり、コストと納期を守ってその仕様を満たす製品を作ることが仕事です。もちろん、仕様を満たすところまで持って行くのが大変なのですが、少なくとも目標までの距離は分かります。

じゃあコンサルはと言うとその逆で、何が答えなのかは誰も分からない状態でプロジェクトを進めていかなければなりません。唯一、プロジェクトの目的という正解はあるものの、それも変わることがありますし、それ以外は何も決まっていない、何でもありな状態です。そんな状態の中、偉い人がこうすべきと言っている、だとか、うちの部門ではこんな業務不可能だ、など、方々から様々な自由な意見が飛んできます。

そうなると、コンサル初心者だった頃の僕は、もうブレブレです笑。偉い人がこう言ったからそうすべきなんだろう、と素直すぎる心で根拠無く信じ込み、後からその人の意見が変わったり思いつきだったことが分かったりして、手戻りが発生したこと数えきれず・・・。

つまりは、偉い人が言っていることでも間違っていることはある、ということです（当たり前ですが）。何が正解かは、自分の頭で考えるしかない。自分が納得すれば、他の人の意見はどうであれ関係無く、その時点ではそれが正解、ということです。「誰かが言ったから」は全く正解である理由ではないんですよね。

これ、頭では分かっているのですが、正直今でもまだ克服し切れていません。諦めず、粘り強く考え続け、そういう癖を付けるしか無いと思います。

3. お客さんから直接仕事ぶりを評価されること

エンジニアをやっていた時は、設計レビューなどでお客さんと接することはありました。「製品」を評価されることはあっても、「自分」が評価されることはありませんでした。まあ当たり前で、お客さんにとっては、「自分」がどんな奴であれ、要求した仕様通りに「製品」ができていれば、それで良いからです。

コンサルは、プロジェクト終了時に必ず顧客満足度アンケートを取り、「自分」への評価を直接フィードバックいただきます。払ったお金に対する貢献度や進め方、スピード感はどうだったかについてです。なぜアンケートを取るのかというと、コンサルの場合、「自分」が「製品」そのものだからです。コンサルの個人能力によって、プロジェクトの成否が変わったりします。

コンサルは「究極のサービス業」なんて言われることもあります。「キャバ嬢を参考にしろ」と言われることもあります笑。でも、これはあながちおかしなアドバイスではないなと。

こうしてお客さんから直接貴重なご意見を頂き、今後に活かすのです。無料で自分の仕事ぶりを評価してもらえるのは、ある意味贅沢な事なのかもしれません。

エンジニアからコンサルになった僕からすると、これはめちゃくちゃプレッシャーでした。常に評価されていると思うと、お客さんを訪問するたび緊張していました。自分はそんなに立派な人間でもないし、コンサルとしても未熟ということが分かっていたので、そんな自分が評価されるとか怖すぎる。なんて厳しい仕事なんだろうと。そしてそうやって萎縮すると、思い切った良い提案があまりできなかったりします。過度に評価を気にするからですね。

逆に、評価はあまり気にせず、お客さんが良くなることを真剣に考えて、小さなことでも良いからどんどん提案していこうという姿勢でいると、意外に良い評価を頂けたりします。評価は過度に気にする必要は無く、真剣にやっていれば、自ずと後から付いてくるものだということです。最近になってようやくそう考えられるようになってきました。

あと、あまり発言しない優しそうな方からの評価がとても厳しいことがあります。お客さんは、見ていないようで、結構細かなところまで冷静に見ているんだなということが分かりました。お客さんの前では気を抜いてはダメだな、と思った瞬間でした。

4. 予算達成へのプレッシャー

予算についても、エンジニアは基本的にはあまり気にしなくとも良い話です（もちろん、気にした方が良いですが）。エンジニアで気にするのは、予算責任のある管理職以上の方でしょう。現に僕がエンジニアをやっていた頃は、良い悪いは別にして、部門や自分のチームの売上などほとんど気にしたことが無かったです。原価低減の目標はあれど、売上の目標はありませんでした。

コンサルは、新入社員かどうかなど関係無く、全員に予算（売上額や遂行額）が割り振られます。これはどういうことかというと、年次など関係無く、1人1人が「プロ」として見られるということです。そしてその結果がそのまま個人の業績評価になり、年収が決まります。イメージ通りかと思いますが、実力主義の世界ですね。

実力主義には、人によっては向き不向きがあるとは思います。僕はあまり深く考えずに飛び込んだのですが、結果的には実力主義の方がモチベーションが上がるので、自分には合っているのかなと感じました。

でも、お客さんからの評価とともに、常にプレッシャーはあるので、うまく付き合わないと、押しつぶされるかも知れません。どう乗り越えるかですが、プレッシャーをあまり気にしないような鈍感さを身に付けることと、無理やりにでもポジティブ思考になるしかないかなと思います。僕は本を読みまくって、自分は鈍感でポジティブな奴なんだと洗脳しました笑

5. プライベートでも勉強が必要なこと

エンジニアの頃は、もちろん技術知識の習得は必要でした。ですが、プライベートの時間を使ってまで勉強しなければならない、というほどでもありませんでした。仕事の一環として、技術書を読んだり、不明点を調べたりということはありましたが、それで充分仕事を廻せました。（僕が担当技術にあまり興味が湧かなかったのもあります笑）

一方、コンサルの仕事はプロジェクトベースで進むため、基本は毎回お客さんの業種も違えば、抱えている課題も違います。当然、対象業務も違いますし、知っておくべき解決策も違います。そうなるとどうなるかと言うと、仕事の中だけでの知識習得では間に合わなくなります。ただでさえ、コンサルはお客さんを導いていかなければならない存在です。お客さんの業界・業種の外部環境や、業務の基礎知識、そのあるべき姿を知らない、という状態では、お客さんを導いていくことなど到底できません。ですので、プライベートでの勉強は、趣味というよりも義務に近いです。

僕の場合は、元々新しいことを知るのは好きなので、勉強すること自体にそこまで苦痛は感じませんでした。ですが、プライベートの時間が少なくなることには、やはり抵抗がありました。趣味に時間を割きたいし、ブログを書きたいし、家事もあるし、（たまには）デートもしたい。

その気持ちとどう折り合いをつけるのかですが、勉強しなければいけないのは仕方ないと諦め、いかにして楽しむかというスタンスで知識を学ぶのが良いと思います。義務を趣味にしてしまうということですね。僕は勉強に限らず、コンサルの仕事もそんなスタンスでやっています。

6. 改善点を正論で詰められること

これはエンジニアでも無くはないです。エンジニアは皆ロジカルなので、正論は得意です笑。それでも、詰められるというよりは、技術的に不安を感じるところや気になるところを論理的に指摘されるイメージです。それに、指摘内容はあくまで技術的な観点のみです。

コンサルの場合、作成した資料や分析結果に対してはもちろん、仕事に対する姿勢や頭の使い方にもロジカルに指摘が入ります。自分の行動に対しても論理的に指摘され、改善を求められる、ということです。これが、一般的に「コンサルは詰める文化」と言われる所以かなと。上司ももちろんコンサルなので、その指摘内容がドの付く正論で、グーの音も出ないところが辛いし悔しいところです笑。行動への指摘なので、その原因は自分の怠慢さであることがほとんどなんですが。自分のことを思っての指摘なので、むしろ感謝すべきなのですが。

この辛さ・悔しさをどう乗り越えるか。それは、その悔しさを逆手に取ってバネにすることですね。指摘は裏を返せば、それを行動に繋げればコンサルとして成長できるということなので、素直に非を認めて、成長に向けて実践あるのみ！です。とは言え、メンタルは傷付いているので、その日は早く寝ることです笑。睡眠は馬鹿にできないメンタル健康法だと思っています。

最後に

こうして考えてみると、コンサルになった時は、ポジティブさ、鈍感さ、素直さを身に付けられれば、苦労を乗り越えられるというのが結論ですね。

元々そうである方は苦労せずコンサルをやれるので、是非活躍して下さい！ですし、僕のようにそうでない方でも、努力すれば後から身に付けれられるのでご心配なく。

それでは、今回は以上です。

次回は、自己紹介でも予告していた（ことを思い出した）、僕がコンサルへ転職した理由について書きたいと思います。

それでは、また。