エンジニアからコンサルに転職した理由

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

今回は、僕が設計開発エンジニアから業務コンサルタントに転職した理由についてです。

僕は新卒から4年半通信機器の設計開発エンジニアとして働き、その後20代後半の時に、現在の業務コンサルタントに転職しました。一般的にはあまり聞かないキャリアチェンジということで、なぜ転職したのかよく聞かれます。（自分としては、特に変わったことをしたとは思っていないのですが。）そこで、8つに分けてその理由をまとめてみます。

前向きな理由

まずは前向きな理由からです。4つ挙げてみました。

1. 将来やりたいことに近付く

転職した理由1つ目は、コンサルになった方が、エンジニアでいるよりも自分が将来やりたいことに近付くと考えたからです。具体的には以下3つの考えがありました。

・独立できそう

学生時代から、漠然と独立したい、あるいは個人名で仕事をしたいという想いがありました。そう考えた時に、コンサルは、会社員ではあるものの頑張れば個人名で仕事をしやすいイメージがあり、転職候補になりました。エンジニアでも専門性を深めていけば不可能ではないですが、コンサルよりも時間がかかりそうだし難易度も高そうだと思いました。

なぜ独立したいと思っていたのか、ですが、振り返ると小学校くらいから、集団行動に向いていないんじゃないかと直感で思っていたことが一因だと思います笑。あと、その他大勢と同じことをしたくないという、天の邪鬼なところがあるからですかね。

大学時代には、時間管理からある程度解放されると、自分の時間が誰かに管理されるのもあまり好きではないことに気付きました。僕は理系で、理系は皆研究室（文系の方で言うゼミ）に所属するのですが、一般的な研究室は、会社勤めと同じで朝9時〜17時まではいなければいけない、みたいな謎のルールがあったりします。僕はそれがどうしても嫌で、成果を出していれば研究室に来なくとも良いという方針の研究室を選びました。それくらい、時間に縛られることが嫌いです。これは今となってはコンサルの働き方に近いなと思います。

つまり、煩わしい集団行動をしなくとも良いし時間的に自由だから、という理由で独立したいなあと思い、そうなるための近道がコンサルではないかと考えた、ということです。

・経営者目線が身に付きそう

独立するとは一人で事業を行っていくということなので、当然経営の知識や考え方、経営者マインドが必要になります。コンサルになれば、エンジニアでいる時よりもそういう経営者目線が身に付きやすいのではないかと思いました。経営者や経営目線を持った方と話す機会が増えそうだし、そういう方と対等に話すために自分もそういう目線を持たないといけません。それを早く身に付けるには、コンサルは打って付けだなと思いました。

・汎用的なスキルが身に付きそう

とは言え、もちろん独立してもうまくいくか分かりませんので、会社員に戻ることも十分考えられます。ただ、会社員を続けるとしても、いつかクビになるかも知れない、という恐怖感がありました。不況生まれ、不況育ち、不況な奴は大体友達の僕なので、そういう気持ちを持つのはある意味当然です。

そんな状態でも最悪、どこでもやっていけるスキルを身に付けておく必要があるなと。そう考えたときに、コンサルであれば汎用的なスキルが身に付くだろうなということで候補に挙がりました。

2. 視野を広げたい

僕は割と好奇心旺盛な方で、会社、職種、業務、技術を浅く広く知りたい、考えたいという想いを持っています。そんな性格に合っていた、というのがコンサル転職理由の2つ目です。

エンジニアは、1つのことを深めることが好きな方の方が合っている職業です。なる前に気付けよと思うのですが、やってみて、1つのことを深め続けるのは無理だなと実感しました。後述しますが、担当技術に興味が無かったのもあり、色んなことに興味が移っていって、目の前のことになかなか集中できなかったんですよね笑。

一方コンサルは、お客さんが毎回変わって様々な会社と関わることが出来ます。更に、設計業務コンサルとなると、お客さんは設計エンジニアだけではなく、営業、生産管理、購買、製造現場の方など、多くの職種の方と関わることになります。設計は製造業の根幹であるため、全ての部署の方と関わるのです。そうなると、各職種の方がどんな業務をやっているのか知らないといけません。それに、お客さんの会社が様々という事は、各社が扱う設計技術も様々です。という事で、色々興味がある自分には設計業務コンサルがより合いそうだ、と思った訳です。

3. やり切った

3つ目は、エンジニアとしてやりたかったことをやり切ったと思えたからです。エンジニアをやっていたのはたった4年半でした。そんな短期間しか経験していないのにやり切ったとか、やりたかった事はどんだけ薄っぺらかったんやという話ですが笑、実際そう思ったのです。まあ正確には、定年までの間にできる事はやり切った、と言った方が正しいです。

他にもやりたい事はあったのですが、あまりにも絵空事過ぎて、定年までいても出来なそうやなというのが分かってきたということです。もうここのエンジニアとしてやりたい事はやり切った、次行こう、となった訳です。

もちろん、一部とは言え、後世に残るようなやりたかった事はできたし、反対にできなそうなことも見えたので、エンジニアになって良かったと思います。

4. 都心への憧れ

4つ目、しょうもないかも知れませんが、都心で働いてみたかったからです笑。コンサルに転職したのは、30代も押し迫ったギリギリ20代の頃です。僕の出身は大阪ですので、そこまで田舎者でもないと思っているのですが、それでもやはり、せっかく大阪から出てきたし、一度は日本の中心である大都会東京の真ん中で働いてみたいな、と。

エンジニアの頃も勤務地は東京でしたが、23区内ではなかったので、都心で働いている感は皆無でした。職場の最寄駅には何も無かったですし笑。

コンサルは都心でバリバリ働いていてカッコ良いイメージがあったので、完全なるミーハー心でやってみたいなと思いました。そして転職してみて、確かに職場自体は23区内になり念願は叶いました。自宅も都心に引っ越してやりました。

ですが、現実は少し違いました。僕が転職したのは設計業務コンサルです。コンサルの仕事は、基本お客さんと話してなんぼです。じゃあ設計をしているお客さんはどこにいるかと言うと、そう、田舎です笑。メーカーの設計者は、田舎にある工場の一室で設計をしていることがほとんどなんですよね。つまり、週の半分は、都心ではなく地方の田舎に出張しています笑。これは誤算でした。

でも、結果的には結構気に入っています。なぜかと言うと通勤が快適だからです。下りなので空いてるんですよね。満員電車が大嫌いなので、むしろラッキーという感じです。地方はご飯やお酒も美味しいですしね！

後ろ向きな理由

続いては、後ろ向きな転職理由です。愚痴にならないように気を付けます笑。

1. 配属ミスマッチ

1つ目は、そもそもの話になってしまいますが、配属先が自分の希望通りではなかったことです。理系の大卒であっても、新卒でエンジニアになる場合、意外にも学生時代の専攻はあまり考慮されません（強く希望しない限り）。僕は学生時代、航空宇宙工学(機械系)専攻だったのですが、就活面接では特にその知識を使いたいという強い希望は伝えず、海外と関わりたいというのと、幅広く色んな部署と関わりたい、とだけ伝えていました。

その結果、配属先は通信機器の電気設計を行う部署になりました。実際、海外と関わるし、プロマネ的な立ち位置で働く部署だったので、面接で伝えた希望通りと言われれば、確かにそうでした。ただ、エンジニアとして一番のコアである担当技術（通信系）については、学生時代の専攻と全く違うので、未知の分野でした。航空宇宙工学を専攻していた奴が通信系・・・。当然今までの人生で通信技術に興味を持った事がなかったので、配属時点でも興味は無し笑。担当技術に興味が無いことは、エンジニアとしては致命的です。エンジニアの命題は、技術開発や技術的な課題解決ですから。そこに興味が持てないということは、エンジニアとして失格だと言っても過言では無いと思っています。

それでも、数年経験したら興味が出てくるかも、と思って頑張ってみましたが、やっぱりダメでしたね。どうしても興味が湧かない・・・。ということで、通信系のエンジニアでいることが辛くなってきてしまい、他に興味のある技術があった訳でも無いので、自然と他の職種を考えるようになりました。

釈迦に説法とは思いますが、もしこれからエンジニアになられる方がいれば、就職・転職時には担当技術に興味があるかどうかを第一優先に活動されることをオススメします。

2. 働き方ミスマッチ

またミスマッチの話なのですが、今度は働き方の方です。具体的には、毎日始業時間が決まっていたことです。エンジニアは工場とやり取りすることが多いので、工場の始業時間に合わせて職場にいる必要があります。工場はシフト勤務が普通なので、始業時間がきっちり決まっています。

エンジニアに限らず、会社員は始業時間が毎日決まっているのが普通だと言われると、おっしゃる通りなのですが、どうしてもそれが受け入れられなかったんですよね。前述した通り、僕は天邪鬼ですし、大学時代、決まった時間にいないといけない研究室には意識的に行かなかったくらいですから。

世の中にはテレワークやフレックス勤務などできる会社もあるし、そういう働き方をしたいと思っていたので、体調や前日の予定に関わらず必ず早起きしないといけないことが段々と辛くなってしまい、自由な時間に出社したいなと思うようになりました。始業時間が自由というのは、小さいことかも知れませんが、毎日のことなので結構大事なことだと思っています。生産性にも大きく影響すると感じています。

まあ、これは入社時から分かっていたことなので、完全に自分のせいです。

3. 職場環境の悪さ

3つ目は、職場環境が悪かったことです。ビルが古い、食堂がまずく周りにも飲食店は無い、という職場でした。QOLが著しく下がりました。オフィスが綺麗であることや、ランチが美味しいことは、従業員の生産性を上げるのに影響すると思いますし、健全な精神でいるためにも重要だと考えていたので毎日憂鬱でした…。当時の会社の財務状況がそれほど良くなかったことが主要因なので、仕方ない部分はあるのですが。

あとは、挨拶や私語がほとんど無い文化（？）で、そのせいで職場の雰囲気が何か暗く、それも辛かったです。職場での雑談がそれほど好きではない僕でも、さすがに何も私語が無いのはそれはそれできついなと思いました。

この経験で、少なくとも工場にオフィスのある仕事は向いていないなということが分かりました。職場環境は大事にしたいです。

4. 飽きてしまった

最後4つ目は、前向きな理由2で挙げた「視野を広げたい」の裏返しかも知れませんが、エンジニアの仕事に飽きてしまったことです。これもまた、何を甘いことを言っているんだとお叱りを受けそうなことを言ってしまっていますが、まあ僕の性格上、仕方が無いです。

以前の記事で書きましたが、エンジニアの仕事って、扱う技術は時代とともに発展していくので変化しますが、仕事の進め方自体は型が決まっていてずっと同じことの繰り返しです。それが定年まで続くのか、と考えると技術に興味が無い自分には絶対無理だなと。

エンジニアをやってみて、飽き性の自分には1つのことを突き詰める仕事は向いていないことが分かりました。趣味なら良いんですけどね。やってみないと分からないことってたくさんありますね。

最後に

以上、エンジニアからコンサルへ転職した理由を振り返ってみました。これらの仕事に興味がある方は、参考にしていただければ嬉しいです。

あと、後ろ向きな理由を後半に持ってきたことで、少し嫌な気分で終わってしまうのは心苦しいので、最後に前の職場を？エンジニアの方を？フォローしておきます笑。僕がたまたまエンジニアに合わなかっただけで、もちろんイキイキと前向きに働かれている方もいましたし、技術が好きであればそれを追求できる環境ではあったので、エンジニアはハマれば楽しい仕事だと思います。

それと、上では書きませんでしたが、実際にはコンサルだけを視野に入れて転職活動していた訳ではなく、他にも色々受けていました。結果としてコンサルになることができ、なってみて自分には割と合っていることが分かったということです。

それでは、今回はここまでです。次回は、これまた皆さんが気になるであろう、コンサルの忙しさや給料について、実態を書こうと思います。

最後まで読んでいただき、ありがとうございました。

<

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

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

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

さて、本題です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最後に

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

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

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

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

それでは、また。

ドキュメンテーションスキル実践方法

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

前回はコンサル基礎スキル4つのうち、「論理的思考」「仮説思考」「ファシリテーションスキル」の実践方法を紹介しました。

t14764.hatenablog.com

今回は残り1つの「ドキュメンテーションスキル」（＝「資料作成スキル」）の実践方法について解説します。

資料を見た人が理解しやすい資料を作るにはどうすれば良いか、についてです。

コンサル以外の方にも役立つ内容ではないかと思います。

目次

実践テクニック

早速、ドキュメンテーションスキルの具体的な実践テクニックについて紹介していきます。

資料構成

まずは資料構成に関するものです。

資料構成は、スライド1枚1枚をどう書くかよりも大事です。なぜなら、人は全体の話の流れで理解するからです。構成が理解しやすければ、多少各スライドが見づらくとも、伝えたいメッセージは伝わるものです。

1. 目的を決める

全体構成を考える上で最も重要なのは、その資料の目的を決めることです。

そもそも、パワポによるプレゼンの目的は、誰かに動いてもらうことです。

ということは、目的としては考えるべきは、誰に何をしてもらえば良いのか、を明確にすることです。 

具体的には、

• 実務担当者に行動アイデアを提示し、議論を通じて今後の行動を決める
• プロジェクト管理者にリスクを提言し、回避する対策を打ってもらう
• 予算責任者に必要な予算額を提示し、予算を確保してもらう

などです。

そもそもの目的を考えないと、資料全体の流れがブレブレになり、何が言いたいのか分からなくなります。

せっかく行動を起こしてもらうための情報は揃っているのに、伝え方が悪いばかりに結果に繋がらないのは、とても勿体無いですよね。

ただ、「目的を考えろ」とはよく言われるものの、いざ資料作成しようとした時に意外と忘れがちです。

期限も迫っているし、早く作らないといけない、時間が無いと焦っている状態で作り始めるのが大半だからです。

ですので、オススメは、パワポを開いたら取り敢えず「目的」タイトルの空白ページを作る癖をつけることです。

5秒でできて、効果は大きいので、試してみて下さい。

2. 目次を決める

次に、目的を決めます。

いきなりスライド1枚1枚を作り始めるのではなく、目的を念頭に置きながら、それを達成できる目次を考えます。

目次を考えることで、自ずと資料全体の構成を考えることになります。

この時、前回紹介したアイデアツリーを使ったり、ノートに書いたりして構造的に考えると、全体感を把握しながら、漏れなく、論理的な構成を考えられます。

t14764.hatenablog.com

本を読むときなども、目次から読み始めると、どんなことが書いてあるのか想像でき、ざっくり理解できますよね。それと同じです。

熟練したコンサルになると、若手コンサルの資料をレビューするとき、目次を見ただけで、どんな資料を作ってきたのか分かります。

自分の考えと合っていた場合は「後は任せた」と言われ、レビューが終わりになることもあります。逆に自分の考えと違っていた場合は、即作り直しを命じられます^^;

そのくらい目次は資料全体にとって大事です。ですので、手戻りを無くすために、若手コンサルはまず、目次をレビューしてもらう習慣がついています。

3. 全体→詳細

目次を考える際にも参考となる考え方が「全体→詳細」の考え方です。

構成を考えるときは、「まず全体像を示し、その中のここの話をする」という流れにすると、すっと頭に入るものになります。

例えば、

• 資料構成はこうなっていて、今からここの話をします
• 業務全体の流れはこうなっていて、この業務の話をします
• 課題と解決策は全部でこれだけあって、まずはこの課題から説明します

というような流れで構成すると、分かりやすくなります。

これは資料作成に限らない考え方です。

例えば、海外旅行で初めての土地に降り立ったときに、地図も見ずにいきなり目的地に向かうと、自分がどこにいるのかよく分からず、途中で迷ってしまう確率が上がります。目的地に向かう前に、自分が今どこにいるのか、目的地はどこにあるのか、そこまでの距離はどのくらいか、が分かれば、迷う確率は格段に減りますよね。それと同じです。

4. 自然な流れで書く

すっと頭に入る自然な資料にするためには、自然な流れで書くようにします。時系列順は分かりやすい例です。前回の振り返り（過去）→今日の実施内容（現在）→今後やること（未来）という流れで作れば良いということです。

他に、考え方・コンセプト→具体例→結論、という流れで書くこともよくあります。いきなり具体例を書いても、なぜ具体例を書いているのか分からないですし、それに引きずられて詳細の話に入っていってしまう事もあります。なので、まずは考え方やコンセプトを示し、その具体例がこれです、と言うと、具体例の意味合いが明確になりますし、考え方の方が大事なんだ、ということを伝えられます。

そして最後に結論を書いて、言いたかったことを明確にします。

5. ストーリー（前後の繋がり）

自然な流れで書くことの一環かも知れませんが、全体が1つのストーリーとなるよう、各スライド間の繋がりを意識して作成します。無用な混乱を避けるために、各スライドに唐突感が無いようにする、ということです。

よくやるのは、話が変わるタイミングで扉絵スライドを入れたり、前ページスライドの最後に「次ページでは〇〇について示す」のように、予告を入れたりする方法です。このちょっとの工夫で、理解しやすさが全然違ってきます。

各スライド

ここからは、スライド1枚1枚について、作成するときに意識していることを紹介します。

1. 伝えたいメッセージを考える

まず、各スライドで伝えたいメッセージを考えます。資料構成の場合と同様、いきなり作成し始めるのはご法度です。繰り返しになりますが、ドキュメンテーションの目的は、資料を作成することではなく、資料を見せる相手に行動してもらうことです。ですので、「どう作るか」よりも先に「何を伝えるべきか」を考えることがとても重要です。

各スライドごとに、何が言いたいのか？言うべきか？を考えていきます。メッセージありきで作ると、資料を見た人もすぐに理解できるものになります。コンサルの資料では、見る人の脳に負担をかけさせないことが大切になります。

スライドを作りながら伝えたいメッセージが変わることもあるので、作成作業に入った後に、メッセージを見直すこともあります。もうお気付きかも知れませんが、資料作成時、実際にパワポをいじるのは一番最後になります。パワポを焦らしてあげましょう笑

2. 1スライド1メッセージ

1スライドは1メッセージにします。資料作成術の本にもよく書いてあります。これもつまるところ、何が言いたいのか、を明確にするためです。1スライドに言いたいことが複数あると、読む人が混乱します。ですので、複数あることが分かった場合は、スライドを分けます。このとき必要なのは、一度作ったスライドを分ける勇気を持つことです笑

3. タイトル、キーメッセージ、イメージ

各スライドは、タイトル、キーメッセージ、イメージの構成で書きます。どのコンサルの資料を見ても、基本的にはそうなっています。「タイトル」があって、その下にそのスライドで言いたい「キーメッセージ」、そしてその下にキーメッセージを補足する「イメージ」という構成です。1スライド1メッセージを徹底しているから、この構成で書けます。

一般的なパワポ資料は、こうなっていないものがほとんどです。キーメッセージだけ書いていて補足イメージが無いため分かりづらかったり、反対に補足イメージやグラフだけ載せていて、何を言いたいのか分からなかったりします。（エンジニアだった頃の僕もそうでした^^;）

4. シンプルに

シンプルに書くことも意識します。対象は、資料構成、メッセージ、文章表現、イメージ、色使いなど全てです。ですが、シンプルに書くことは簡単に見えてとても難しいです。

シンプルに書くとは、何かを理由も無く省略することでなく、幹と枝葉をきっちりと見極めること、枝葉をバッサリと切り捨てること、だからです。幹と枝葉を見極めるには、しっかりと論理的に考えないといけませんし、未来にどう影響があるのか、を考えないといけません。切り捨てるには、結構勇気が要ります。漏れることの不安から、あれもこれも書きたくなります。

ですが、それは「他者視点」ではなく「自分視点」で考えてしまっている証拠です。「自分」が不安だから、何でも書いてしまうのです。「相手」に必要かどうか、で判断する必要があります。

5. 提案、提言

コンサルの資料なので、「提案」「提言」を入れます。これは一般的な資料と大きく違うところです。提案なので、相手に、「こうした方が良いのではないかと思います。その理由は、〇〇です。」と伝えるということです。相手もそれを求めています。

ただ単に、現状分析の結果こうでした、や、前回こういうこと議論したので次回はこういうことを議論します、ということを言っているだけの資料ではダメだということです。 相手の「だから何？」に答える必要があります。

まとめ

以上、まとめます。

• 資料作成までに、目的、目次、伝えたいメッセージを考える
• 資料は、見た人がすぐに理解できるような流れ、表現で書く
  （全体→詳細、ストーリー、1スライド1メッセージなど）
• コンサルの資料には、「提案」「提言」が必要

もちろん、これら以外にも、色使いや図形の配置など、より細かなテクニックもありますが、それは専門書に譲ります。例えば、以前の記事でもご紹介しましたが、こちらなど、本を何冊か読めば必要なテクニックはおおよそ学べます。

そして何よりも重要なのは実践です。本を読むと分かった気になってしまいがちですので、とにかく手を動かしていきましょう。（自戒を込めて） 

今回ご紹介した実践方法は、パワポ以外にももちろん使えますし。（ブログや論文など）また、人に何かを伝えるという意味では、日常会話でも使えます。

それでは、今回はここまでです。

ここ2回の記事で、コンサルで必要なスキルと実践方法については解説したので、次回は、元設計エンジニアだった僕がコンサルに転職したときに基礎スキル実践で苦労した点を共有しようと思います。コンサルになりたい方、コンサル初心者の方には参考になるのではないかと思います。

では、また次回。

コンサル基礎スキルの実践方法：何でも書く

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

前回はコンサルに必要なスキルを解説しましたが、今回は、それらを実践する方法を紹介します。

t14764.hatenablog.com

前回の記事が大作になったので、今回は軽めの記事にします。ブログはマイペースに書くもんなんやから、ええんや！と自分に甘い僕です。

今回はタイトルの通りなんですが、前回ご紹介した、コンサル基礎スキルを実践する方法をご紹介します。

結論から言うと、その方法とは「何でも書く」ことです。なんだそれだけか、と思われるかも知れませんが、そうです、それだけです笑

では、なぜ「何でも書く」ことでコンサル基礎スキルを実践できるのかご説明します。

目次

「書く」ことの良さ

コンサルはとにかく何でも「書く」

周りのコンサルを見ていても、漏れなく皆が共通して実践しているのが、「書く」ことです。 

コンサルと言えば、パワポ資料をひたすら作り、Excelでデータ分析をしているイメージがあります。それはそれで正しいんですが、実はこれらは考えたことを表現する作業でしかなく、その前にしているのが、「書く」ことなんですよね。

• ノートに「書く」
• アイデアツリーに「書く」
• ホワイトボードに「書く」

毎日、事あるごとに何でもすぐ書きます。お客さんが言ったキーワードや何気ない言葉、数字、上司から言われた資料への指摘内容やアドバイスなど、何でもです。

これには、記録する意味もありますが、コンサルにとっては、「書く」＝「考える」なんです。

皆さんは仕事中、事あるごとにノートに何か書きますか？PCでの仕事が多いと、あまりノートとペンを使わないという方も多いのではないでしょうか。書くとしても、学んだ知識などを忘れないよう記録する時だけ、という場合も多いのではないかと思います。僕もエンジニアをしていた時、あまり書くことを重要視していなかったですし、「書く」＝「記録する」でした。

 ちなみにアイデアツリーとは、ツリー状に物事を表現、整理した階層図を簡単に書けるツールです。Windows、Androidで使えます。論理的に物事を整理する場合によく使います。無料でダウンロードできるので、良ければ使ってみてください。

www.dicre.com

まあ、あくまで整理のためのツールなので、他の技法(マインドマップ)でも手書きでも何でも良いです。

ノートへ「書く」

コンサルになると、概念的・抽象的で、ふわっとした曖昧な事象を扱うことが増えました。どう表現すれば良いのか難しいのですが、概念的なことって頭の中だけでは言葉にしづらく、ふわっとしているので考えが堂々巡りするんですよね。一回考えて、そのあとあれこれ考えていると、気付いたら最初に考えていたことと同じことをもう一度考えている、みたいな感じです。伝わりますかね。とにかく、ふわっとしたことは、考えが頭の中でぐるぐるして、なかなかまとまらないなということに気付きまして。

そんな時に、コンサルの先輩方に、「考えをまとめる時はノートにとりあえず書くと良いよ」と教えていただきました。そんな簡単に考えがまとまったらコンサルなんかいらんやん。と生意気なことを思いながら、半信半疑で試してみたところ、考えが堂々巡りすることがなくなり、割とサクッと考えがまとまり、頭がスッキリしたんですよね。「手書き意外にすごいやん」と感動したのを覚えています。

なぜ考えがまとまったのかを考えてみたのですが、

• 考えの全体感（量、質）を掴んでまとめやすくなる

• 言語化・イメージ化することで、
  無理矢理モヤっとした考えを表現せざるを得ない

• 書くと、再度それについて考えなくとも良くなる
• 書くときに、無意識に不要な考えを取捨選択する

が理由かなと。

ここでコンサル基礎スキルの実践に繋がるのですが、書いているときの頭の中は、「論理的思考」や「仮説思考」しているのと同じなんですよね。と言うよりも、論理的に仮説を考えようとすると、頭の中だけで考えるのは限界があって、書かないとなかなか難しいのです。

そして、頭の中が整理されると、後はそれを表現すれば良いので、資料は完成したも同然です。ですので、基礎スキルの1つである「ドキュメンテーションスキル」を半分実践していることにもなるのです。

ノートに書く内容、方法

ノートに書いている内容ですが、以下が多いです。

• 計画（プロジェクト計画、タスク、TO DOなど）
• 仮説（3手先くらいまで。課題、リスクも）
• 問題構造（課題、原因、解決策の関係）
• 資料構成、要点（アジェンダ、ストーリー、ポイント）

共通しているのは、複数のことを考えなければならなかったり、複雑だったりすることです。頭の中だけで考えていると、余計に時間がかかるものでもあります。

書き方ですが、とりあえずノートを開いてペンを持ちます。（当たり前）そして、がーっと直感で、最初はあまり深く考えずとにかく頭の中に浮かんでいることをそのまま勢いで書きます。自分が読めれば良いので、汚くてももちろんOKです。「直感で」「深く考えず」「そのまま勢いで」というのがポイントと思っています。なぜかと言うと、頭の中がスッキリしますし、割と直感で出てきた考えは、良いところを突いていることが多いからです。書くことで頭の中を空っぽにするイメージです。

もちろんノートは何でも良いですし、（むしろ安いノートの方が気兼ねなく書けて良いかも）ペンも安いので良いです。

ただ、考えを書く場合は、タブレットのような電子デバイスよりは、紙のノートの方が良いそうです。（メンタリストDaiGo氏がYoutubeで言っていましたが、そう言う研究結果があるそうです。）

そして重要なのは、勢いで書いてそのまま終わるのではなく、書いたことの関係性を整理し構造化したり、イメージ化したりすることです。これが普通のメモとは違う、コンサル独特の書き方です。この最後の一手間で、論理的に頭の中を整理でき、考えがとても分かりやすくなります。料理で言う味付けみたいなものですね。

皆さんも今日から騙されたと思ってやってみて下さい。良い考えが生まれるかも知れませんし、頭の中がスッキリしますよ。もちろん、この記事の構成やポイントも前もってノートに書いてます。

ホワイトボードへ「書く」

会議中にも「書く」ことは大活躍します。会議はたくさんの参加者がいるので、議論が発散しがちです。各々、好きなことや気になったことを自由に発言し、その発言に引きづられ、どんどん本筋とは関係無い方に話が進んでいくことがままあります。結論の納得感を高める上で重要だったりするので、一度議論が発散すること自体は良いことなのですが、とは言え時間内に結論を出す必要があります。そんな時、「書く」ことの出番です。書く対象は、ホワイトボードです。

ホワイトボードに書く内容、方法

ホワイトボードには、

• キーワード
• 数字
• 発言をイメージ化したもの

を書きます。 

ポイントは、一旦、自分の解釈を入れず、発言者が言ったことをそのまま書く、表現することです。

これにより、

• 発言を確実に残すことで発言者が安心する
• 書くものに全員の注意が向くので、自然と認識を合わせることができる
• 共通認識したキーワードをベースに、議論を進められる
• キーワードが残っているので、発散した時に、それまで議論していた内容にすぐに戻ってくることができる

という効果があります。

書こうとすると注目を集める分、最初は実践に緊張するかも知れませんが、やることはそのまま書くだけでシンプルなので、少しの勇気を振り絞って試してみて下さい。

そしてこれが、基礎スキルである「ファシリテーションスキル」を実践する１つの方法です。ホワイトボードに書くことで、簡単に参加者全員の認識を合わせ、建設的な議論を行うことができるので、効率的に会議を進めることができます。

まとめ

以上、コンサル基礎スキルの実践方法として、ノート、アイデアツリー、ホワイトボードに「書く」方法をご紹介しました。

仕事で、もちろんプライベートでも、頭がもやもやしていたり、悩み事を考え始めて頭の中がぐるぐるしたりした時は、ノートを開いて頭の中を掃き出すイメージで書いてみて下さい。更に、構造化したり、イメージ化したりすると、言いたかったのはこういうことか、と頭がスッキリします。コンサルは、意外に地道にこうして論理的な仮説を考えています。

 また、会議でなかなか話がまとまらない時は、ホワイトボードに誰かの発言内容をそのまま書いてみて下さい。皆がそこに注目するので認識が共通になり、それを起点に議論を進めることができるので、建設的な会話になりやすく、話をまとめやすくなります。コンサルは、ファシリテーションの時によくやっています。

今回は以上です。

次回は、ドキュメンテーションスキルの実践方法について、ご紹介したいと思います。

元エンジニアから見た、コンサルに必要なスキル

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

最近は、資格勉強に充てていた時間をブログを書く時間に充てるようになったので、ブログの更新頻度が上がってきていて良い感じです。 

今回は、元エンジニアの僕が考えるコンサルに必要なスキルについて紹介します。 皆さん恐らくどこかで耳にしたことはあるであろう、基礎的なコンサルスキルはもちろんですが、個人的にはこれも実は必要だなと思うスキルやマインドについても紹介します。

エンジニアで必要なスキルとの共通点、違いも考えてみたいと思います。

今回はざっと概要を紹介し、次回以降、特に重要だと感じるスキルについて、詳しく書いていきます。

各スキルを学ぶのに読んだ本も参考にご紹介します。

目次

コンサルに必要な基礎スキル

論理的思考

1つ目は、コンサルと聞いてイメージする論理的思考。最もよく聞くスキルだと思います。もはやコンサルだけではなく、働く人、いやむしろ全人類に必要と言っても過言ではないのではないでしょうか。

 論理的に考えるとはどういうことかと言うと、例えば以下のフレームワークに沿って考えることです。

• MECE（Mutually Exclusive and Collectively Exhaustive）
  =重複なく、漏れなく
• ロジックツリー＝分類して構造的に考える
• So What＝要するに？まとめると？
• Why So=なぜそうなのか？具体的には？
• 課題→原因→解決策

エンジニアとの共通点は、どちらも論理的思考が必要なことですが、エンジニアは上記フレームワークを学ぶ訳ではないため、自己流の論理的思考を行なっていることが多いです。逆に言うと、エンジニアで上記のフレームワークを知っていれば、他の人よりもより成果を上げやすくなります。

論理的思考を学べる本もたくさん出ていますが、読むことよりも、実践することが圧倒的に大事です。まずは普段の仕事で、会議で、相手は全体のどの部分のことを言っているのだろう？結論は何なのだろう？この課題の原因は何だろう？と考えることから始めてみて下さい。 スキルが身につくのはもちろん、普段の仕事が違って見えたり、奥深さを感じ、一段と面白くなると思います。プライベートでも使えるのが良いところでもあります。

・ 論理的思考を学ベる本

たくさんありますが、考え方やフレームワークを知るには、どれか1冊読めば十分です。

僕は最も有名で信頼されている以下を読んで学びました。

僕は学生時代に買ってあまりちゃんと読んでいなかったのですが笑、 コンサルになってから改めて読むと、必要なことが無駄なくシンプルにまとまっていて、名著だと気付きました。一家に一冊置いてたまに読み返すのに最適な本です。

仮説思考

仮説思考とは、仮説を考え検証し、仮説を修正し検証し、を繰り返すことで、最短時間で目的を達成することです。これは、エンジニアは自然とできている思考です。なぜなら、エンジニアの仕事は、仮説立案、検証の繰り返しだからです。ハードウェアの設計もそうですし、プログラミングなどソフトウェアの設計もそうです。こうじゃないかと考え、実験・プログラミングしてみて、結果を見てまた次の手を考える。

で、エンジニアとして出来ていても、コンサルとして実践するとなると、これがなかなか難しい。僕も苦労しました。なぜ難しいかと言うと、仮説を作るのが難しいのです。 

コンサルが仮説思考をする場面は、エンジニアとは違い、今まで経験したことがなく、うまくいくか分からないような、霧の中にいるような中で、何とか目的達成に向けて進んでいかないといけない、というような状況です。仮説というと、多分こうだろうという予測のことですが、普通に考えると、未来のことなど分からない、となってしまいます。 

ですが、仮説思考の肝は、そんな状況でも怯まず思考停止せず、適当でも思いつきでも何でも良いから、エイヤーで、多分こうなるんじゃないか？というのを無理矢理捻り出す、その思考の粘り強さじゃないかなと個人的には感じています。

もちろん目的達成までの早さは、仮説がどのくらい正しいか、精度が高いか次第で、経験を積まないとどうしても精度は低いです。 でも、分からないから考えず、仮説無く右往左往する場合に比べ、仮説という仮のゴールがある分、進むべき方向性がおぼろげながら見えるので、圧倒的に成功確率や速度は上がります。それに何より、未来のことを考えるのは、純粋に楽しいです。

仮説思考も日常的に実践できます。街行く人を眺めて、

「あのカップルはどこへ行くのだろう？歩いている方向、服装から察するに、焼鳥屋ではなくフレンチじゃないかな？」

「あ、違う、美術館か。」

「そうか、早めにディナーを済まして、空いている遅い時間に美術館に行くことにしたのか。」

みたいな感じです笑。妄想に近いですね笑。

前項の「論理的思考」と合わせて、コンサルの仕事の基礎をなすスキルです。 

資料を作るにしろ、会議をするにしろ、何をするにも、この2つのスキルは必須です。

・仮説思考を学べる本

論理的思考ほどは多くはありませんが、それなりに名著があります。今でも読み返すのは、以下の本です。

仮説とは何か、なぜ仮説思考が重要なのか、を具体例を交えて解説してくれる良書です。僕はこれを読んで、今取り組むべき問題は何か？という問いを日々の仕事で忘れないよう意識しています。

ファシリテーションスキル

ファシリテーションもよく聞くようになった言葉だと思います。合意形成や参加者間の認識を合わせるための支援、という意味です。

会議中にそれを行う人をファシリテーターと言います。 よく勘違いされることが多いのですが、単なる司会進行役ではありません。 参加者が平等に発言できるよう促したり、話を整理したりして、その会議のゴールを達成できるよう、サポートする役割です。つまり、その場の目的を達成するために、会議全体をコントロールし、参加者を引っ張っていく必要があります。

ファシリテーターを務めるには、会議のゴール、進め方、時間、参加者を事前に理解しておき、頭の中でシミュレーションしておく必要があります。この話を出すと、おそらくAさんはこういう発言をするだろう、そうなったら、Bさんに話を振ってこういう話をしてもらって、全員の意見を出し切ったところで、最後にCさんに結論を出してもらおう、といった感じであれこれ考えておくことで、会議のスムーズな運営ができ、ゴールを達成できます。シミュレーションのためには、参加者がどういうことを考えているのかを想像し、役割や性格、関係性を理解しておく必要があります。

この時も「論理的思考」や「仮説思考」が活躍しますし、人を見抜く力も必要になります。

エンジニアの時は、ファシリテーションという言葉すら知りませんでした笑。エンジニアの時は全く使わなかったので、コンサル特有のスキルですね。

このスキルの本質は、異なる意見をまとめてゴールに導くことなので、プライベートでももちろん使えます。

・ファシリテーションスキルを学べる本

コンサルになった時は、これまで知らなかったスキルなので、初心者向けの以下の本で学習しました。

日本ファシリテーション協会フェローの堀さんの本です。初心者の僕にとっては、ファシリテーションに必要なスキルやツールが紹介されているので、とても参考になりました。 具体的な事例も豊富で、実際の会議での実践をイメージしやすかったです。

ドキュメンテーションスキル

カッコ良く書いていますが、言ってしまえばパワポ作成スキルのことです。パワポ作成スキルなんて言わなくとも普通に使えるよ、と思われるかも知れません。

ですが、コンサルのパワポを見たことがある方も多いと思いますが、とても綺麗で凝った仕上がりになっているイメージではないでしょうか？僕もコンサルになりたての頃は、エンジニアをやっていた時のパワポとは大違いで驚いたことを覚えています。

コンサルがなぜそこまで凝るのかと言うと、パワポ資料が唯一の成果物だからです。

一般的にコンサルタントに仕事をお願いすると、毎月新車が買えてしまうような（！）お金がかかります。そして、提供するのは、具体的なものではなく、お客様の成功を支援する、という無形のサービスです。 ですので、そのかけたお金でどのような成果が出たのかを証明するものとして、普段の打ち合わせで使うパワポ資料くらいしか無いのです。ということで、コンサルは唯一の成果物であるパワポ資料に並々ならぬ労力を注いで、綺麗な資料を作るのです。

言ってしまえば、後からお客さん内部の偉い人から、コンサルに高いお金を払って、成果は何かあったのか？と聞かれた時に見せる用ですね。もちろん、それまでにどのようなことを合意したのか、を残しておいて、後から議論が再度噴出した時に、戻ってくるためでもあります。

このように、誤解を生まず、頂いたお金と釣り合う成果物を作成する時に活躍するのがドキュメンテーションスキルです。

具体的には、以下のような資料を作成するスキルです。

• その会議で、資料で、伝えたいことが読むだけで分かる
• 曖昧なところが無く、誰が読んでも同じ理解となる
• 会議資料の場合、その会議の結論と次のアクションは何かが明確である

コンサルの仕事は、2割が会議、3割が分析、残り5割がパワポ資料作成です。 ですので、パワポ資料作成を効率化するテクニックも地味に重要で、細かいですが、色々あります。これはまた別の機会にご紹介したいと思います。

資料については、「外資系コンサル 資料」でググると、マッキンゼーなどの有名外資系戦略コンサルのものが出てくるので、興味のある方は見てみて下さい。思った以上に作り込んであるので、びっくりすると思います。

また、毎回の会議ごとで主題が変わるのが普通なので、基本、毎回新しく資料を作ります。 ですので、知らず知らずのうちに、メキメキと資料作成の力が上がっていきます。 

ちなみに、エンジニアの成果物は設計書や図面、実際のモノなので、パワポは必要最低限、相手に伝われば良いものでした。何なら、いかに効率的に作るかが最重視され、既存資料の流用が主でした。コンサルでももちろん効率化を考えますが、そこまで重視されないですね。

・ドキュメンテーションスキルを学んだ本

上述の通り、エンジニアの時は重視していなかったスキルでしたし、苦手意識もあったので、本はたくさん読みました。どれを紹介しようか迷ったのですが、今でも頭に残っているテクニックが多かったこの本にします。

とにかくシンプルで見やすい資料やグラフをどう作れるのか、という観点で、様々な役立つテクニックを解説してくれています。なぜ、という理由のところまで説明してくれていて、とても納得感が高いです。分析結果グラフ入りのパワポを作ることが多いのですが、凡例やグラフタイトル、単位をどう書くべきか、など細かいですが地味に役立つ技が多く、今でもよく使います。

以上、コンサルで必要な基礎スキルはここまでです。次は、それ以外に個人的に必要と感じたスキル、マインドを解説します。

その他個人的に必要と感じるもの

ここからは、巷のコンサル本にはあまり書いていないけれども、個人的にはこれも無いとコンサルが務まらないと感じるスキルやマインドをご紹介します。

とりあえず、ざっと挙げます。

• 思考体力
• 他者視点
• 知的好奇心
• 傾聴力
• 当事者意識
• 正確性
• 能動性
• やる気

結構多いですね汗。 でも、どれが欠けてもコンサルとして働くのが辛くなってくると思います。では、それぞれについて解説します。

思考体力

これは本当に必要だと痛感します。エンジニアだった頃に比べ、明らかに考えている時間が増えました。 冗談抜きでエンジニアの頃より10倍くらい考えているのではないでしょうか。

コンサルは、基本的に仕事中ずっと考え続けています。 考えることに対してお金を頂いているので、当たり前といえば当たり前ですが。エンジニアとは異なり、それまでに得た知識を使い、過去と同様の仕事をすることはほとんど無いためです。（もちろん、エンジニアの仕事が簡単、と言っている訳ではありません）決まった業務フローとかマニュアルがある訳でもないです。 

思考や作業を捻り出す時の拠り所は、プロジェクトの目的達成です。そのために、今何をすべきか、を常に自分で考えないと、お客さんから「いらない」と言われクビになってしまいます。・・・とてもシビアですよね汗

考え続けるのはとてもハードです。ですので、それに耐えられる思考体力が絶対に必要です。

他者視点

これはコンサルに限ったマインドではなく、どんな仕事も全て相手があってのものなので、全仕事で必要と言われるものではあります。

エンジニアの時も、当然意識はしていました。ただ、コンサルの他者視点は、一般的なものより幅も深さも必要です。

幅というのは、関係するお客さん全ての視点という意味です。直接の担当者の方はもちろん、その方の上司、上位上司、他部署の方、取引先の方、お客さんのお客さん、など。

深さというのは、例えば資料作成時で考えると、関係するお客さん全員が、その資料をみてどう考えるか、質問しそうかだけでなく、最終的にその資料を見た後、何をするかまで考える、という意味です。具体的には、自分の上司や他部門の人に説明しなければならないとか、予算の承認をもらわなければならない、とかです。

そこまで考えると、もっと詳細な説明がいるな、とか、こういう情報も必要そうだとか、とか、色々とアイデアが出てきます。ここまでやってようやく、お客さんに、「そうそう、自分が知りたかったのはこういうこと！」と言ってもらえます。

人はついつい自分都合で考えてしまうので、他者視点になるのは意外に難しいのですが、自分都合で考えていることに気付いたら、一歩引いて、視点を他者に変えてみると、違ったように見えてきます。それはそれで面白いです。

知的好奇心

あればコンサルの仕事が楽しくなるのが、知的好奇心です。コンサルの仕事はプロジェクトベースで動きますので、基本的に同じ内容のものが無く、毎回新しい業界、業務の知識を知る必要があります。そんな時、仕事だと思って調べごとをするのか、興味を持って調べるのか、で楽しさは全然違いますよね。それに、調査の質も全然違ってくると思います。

違う言い方をすると、飽きっぽいかどうか、ですね。僕は飽きっぽく、新しいことを知るのが好きなので、一つのことを突き詰めるエンジニアはあまり向いておらず、コンサルの方が向いているなと、なってから気付きました。コンサルになってから、仕事に飽きたことは一度も無いです。 それも、人より少しある知的好奇心のお陰です。

傾聴力

相手の言っていることをきちんと聞く力です。相手とは、お客さん、上司、部下です。きちんと聞くことは、相手からの信頼に繋がります。 コンサルや仕事に限らず、プライベートでも重要ですよね。

きちんと、というのはとても抽象的なのですが、自分のバイアスを通さず、言ったことをそのままに受け取るということです。ただし、誰にでも裏には複雑な人間関係がありますので、言外のそういった機微も読み取る必要があります。純粋にそのまま、ではないところがまた微妙で難しいところではあります。

そして、傾聴するというのは、簡単そうに見えて意外に出来ている人が少ないです。自分の言いたいことを言うのをぐっと我慢する、忍耐力がいるからではないかと思っています。ヒューマンスキル的なものですので、エンジニア、コンサル、とか職種はあまり関係無いのかも知れません。 

かく言う僕もまだまだ傾聴が足りていないなと感じるので、精進します。

当事者意識

これは、良い提案を考えるため、お客さんからの共感を得るために必要です。良い提案は、お客さんのことをちゃんと理解していない限りできません。そしてお客さんのことを理解するためには、お客さんになり切ってみることが必要です。ここは、「他者視点」と繋がる部分でもありますね。
また、お客さんになり切るためには、興味を持つ必要があるので、「知的好奇心」も必要です。 

どこか他人事でいると、お客さんはすぐ見抜きます働く姿勢を見ていないようで見ているのがお客さんです。

当事者意識を持つことができれば、普通に仕事をするよりも、数倍成長が早まります。他人事でいる時よりも、考え抜くからです。

極端な例を出すと、他人が余命3日と言われるのと、自分が余命3日と言われるのでは、気持ちや行動が全く違いますよね。そういうことです。

僕の周りには、お客さんの製品を買って、実際に使ってみて、使い手や作り手の気持ちになってみる、ということをしている方もいるくらいです。

ただ、これはあくまで第三者として支援する立ち位置のコンサルだからこそ必要な姿勢だと思います。

エンジニアなどコンサル以外の職種であれば、自分の関わったものが会社に直接貢献するので、当事者意識を持たずとも、自ずと当事者な訳なので、あまり必要ではないものだとは思います。

正確性

これは、コンサルよりもエンジニアでより必要なスキルではあります。エンジニアが正確性を欠いた仕事をすると、それがそのまま製品の不具合になってしまうためです。

ですが、コンサルにとっても、お仕事を頂くきっかけとして信頼が大きく影響するため、その信頼を得るために必要なスキルです。

正確性が低いと、お客さんに弱みを握られてしまうことがあります。 コンサルはお客さんをリードしていく必要があるので、弱みを握られると、主導権を握りづらくなるので、避けなければいけません。僕はこれに関しては、エンジニアをやっていた経験が活きて、あまり苦労はした覚えがないです。

能動性

自主的に考え自律的に行動する、という意味で、能動性は非常に大事です。 色々と考えてくれているな、というのがお客さんに伝わって、これもまた信頼に繋がります。

能動性を持って仕事をすると、コンサルで必要である、お客さんへの提案が自ずと出てきます。目的を達成するためには、自律的に考えると、自分はこういうことが必要だと考えている、と言えるということです。

また、お客さんをリードするために、お客さんよりも先々のことを考える必要がありますが、能動的に考えていれば、自然とそういう思考にもなります。「当事者意識」とも関連が強いですね。 「能動性」があれば「当事者意識」が出てくるし、「当事者意識」があれば「能動性」が出てきます。

あと、最近思うのは、能動的に仕事をする方が絶対に楽しいです。いわゆる、やらされ仕事は面白くないですよね。

やる気

この後にも書きましたが、これが一番重要かも知れないです。やる気が一番と言うと、体育会系のノリで嫌なのですが、コンサルの仕事は自分で何かをやるのではなく、お客さんのサポーターに徹します。

その割に、お客さん以上に考えないといけないため、意外に地味で泥臭いことが多いです。 

そんな、なかなかにハードな仕事をやり抜くには、やる気が無いと絶対続きません。どんな仕事もそうで、続けられるか否かは、最後はやる気があるか無いか、だと思っています。やる気があれば、前向きに仕事ができますし、何か辛いことがあっても立ち直りが早いでよね。

じゃあ、やる気を出すにはどうすれば良いかと言うと、あの人みたいになりたい、やあの人には負けなくない、みたいな、理屈ではなく感情を元にしたきっかけがあればいいのかなと思っています。

コンサルスキルは訓練すれば身に付けられる

以上、コンサルに必要なスキルをざっと（そしてたくさん）紹介しました。

多すぎ、こんな身に付けられる訳ない、コンサル出来る人って別世界の人間・・・と不安に思う方もいらっしゃるかも知れませんが、ご心配なく。

これらは基本的に全て、訓練すれば後から身に付けられます。前職でエンジニアをやっていた僕が言うのですから、間違いありません。また、周りには営業からコンサルになられた方もいるので、必ずしも理系出身である必要もありません。

ただ、スキルを身に付けるには（そして成果を上げるには）、やる気があることが前提です。 そう言う意味では、最も重要なのは「やる気」ですね。何か体育会系な感じで、個人的にはあまり好きではない言葉ですが笑、でも、これだけは身に付けるとかそういう類のものではないので、そうとしか言い様が無いです。

繰り返しになりますが、コンサルになって、活躍しているあの人のようになりたい、目の前のお客さんを良くしたい、というやる気を持って、仕事をすることが何よりも大事です。

あと、最後に忘れてはならないのは、これらスキルは、あくまで「相手に納得してもらう」ための道具だということです。「論破する」ための道具ではないことには注意しないといけません。論破したところで、相手がアクションを起こす気が無くなってしまっては、本末転倒だからです。

コンサルの仕事は、相手を論破することではなく、成功に向けて、相手に動いてもらうようにすることですので。

それでは、長くなりましたが、今回はここまでです。

次回は、重要スキルについてもう少し掘り下げて解説します。