「コンサルって、SEと何が違うの？」
「ITコンサルって資料作成が多いって聞くけど、特別なスキルが必要なのかな？」
「SEの時と資料作成の進め方が違うのかな？」
SEとITコンサルでは役割や必要なスキルはそれほど変わらないというのが私の意見ですが、細部で異なる部分はあります。特に資料作成の面で違いを感じました。ITコンサルへの転職を考えるSEの方にとって、業務の進め方や求められるスキルの違いは、細かくても気になるポイントかと思います。
この記事では、SEもITコンサルでも働いたことのある私が、自身の実体験をもとに資料作成におけるITコンサルとSEの違いを紹介します。SEの時と意識することが全然違うと思いましたので、そのポイントを具体例を用いて整理します。
ちなみに、私はSEこそITコンサルに転職すべきと考えているのですが、その理由を以下の記事にまとめていますので、もし興味があれば覗いてみてください。
①仮説思考
SEからITコンサルに転職して、SE時代との大きなギャップの一つに、仮説思考があります。例えば、上司に何かを確認するときに、SEの時はオープンクエスチョンで確認していたのですが、コンサルでは基本的にNGです。何かを確認する際には、論点を明確にして、仮説や前提を持って行うべきという共通認識があるからです。
漠然と「これで大丈夫ですか？」と聞くのではなく、「この前提でこう考えているのですが、認識が合っていますか？」というように、確認する側が仮説を立てて伝えることが必要です。このような確認ができると、会話の精度が一気に上がり、確認された側も論点が明確になってフィードバックしやすくなるためです。
曖昧な質問では、曖昧な回答しか返ってこない
SE時代は、「確認＝相手に正しさを聞くこと」と捉えていた場面が多く、よくあるのが「このように資料を作ったのですが問題ありませんか？」というような聞き方をしていました。ITコンサルではこのような聞き方はNGです。なぜなら、確認する側の論点が曖昧だと、相手が何を聞かれているかもわかりにくいですし、なぜ質問したのかも全く分からないからです。
確認の質を上げるというのは、仮説思考であると同時に論点の解像度を上げているということで、「この前提のもと、この考えで資料を作りました。この考えの場合、AがBになる認識なのですが、認識合いますか？」といった感じだと答える側も答えやすいです。
仮説思考の具体例
何かを確認する際には、仮説をもって確認する必要があります。確認された側は、何を確認されているのかわからないので、意図した回答を得られない可能性があるからです。
資料説明
たとえば、顧客の業務の確認を行う場面で業務フローを用いながら仮説思考で説明を行います。
NG例： 「ここのプロセス、少し改善したほうがいいと思うのですが、どうですか？」
OK例： 「現状のプロセスではA→B→Cと進んでいますが、Bの部分が属人的になっており、ここがボトルネックになっているように見えます。たとえば、Bを標準化してDの工程に組み込むことで効率化できると考えていますが、この仮説の方向性は合っていますか？」
このように仮説を立てて確認することで、相手はその仮説の妥当性について明確な意見を述べることができますし、ズレている場合も「何がどう違うのか」という観点でフィードバックがもらえます。
仕様確認
例えば、仕様を確認する際にでも、仮説思考が有効です。
SEの現場では、「この仕様でOKですか？」というような聞き方が多いですが、これでは相手との前提が揃っていないと、認識違いが起こりやすくなります。たとえば、 「Aという仮説のもと、これから説明する仕様を考えたのですが、まずは仮説の部分で認識が異なる部分はありますか？」 というように、まずは仮説があっているかの確認を行うことで、スピード感のある議論ができるようになります。
仮説や前提を明示しないと、途中でボタンの掛け違いが起こってしまい、議論そのものが無駄になりかねません。
②瞬発力
SEからITコンサルへの転職を検討している人の中には、SEとITコンサルって役割がすごい似ているけど何が違うんだろうと思っている方がいるのではないでしょうか。私自身、SEからITコンサルに転職し、最も驚いたことの一つが資料作成における瞬発力の重要性でした。SE時代はスピード感をもっている方だったのですが、ITコンサルになると全然遅くて・・・
資料作成はスピードが命であることをITコンサルになってより強く意識するようになりました。特に出だしが重要なため瞬発力が全てといっても過言ではありません。一人でじっくり考えて完成度を上げていくというよりは、すぐに形にしてみて上司にレビューをしてもらう方が結果的に品質が高い資料が速く完成します。
というのも、すぐに方向性だけでも上司と認識合わせをしないまま、方向性が合っていないことをずっと考えてしまうのが最もやってはいけないことになります。あとは、スピード感が遅いと、上司から対応が遅いなと思われてしまうリスクもあります。
依頼者はイメージを持っていない場合がある
瞬発力が重要な理由は、コンサルは抽象的だったり複雑な資料作成が多く、誰も完成系をイメージできていないことが多いからです。コンサルは、その単価の高さから、ざっくりな資料作成依頼が多く、「こんな感じの資料が欲しいんだけど作れるかなあ」と顧客から急に依頼があることがあります。
また、「ちょっとこの資料、明日の会議で使いたいんだけど」と上司から振られたりすることもあります。依頼のタイミングでは、依頼者側も資料の完成形が明確に見えていないことが多いため、このタイミングで、依頼者と完成のイメージをすり合わせておくことが大切です。依頼を受けたその瞬間から、資料作成は始まっていると言っても過言ではありません。
資料作成のプロセス
依頼を受けたその場でヒアリングとイメージ合わせ
まず、その場で可能な限り依頼者と認識をすり合わせます。
- この資料の目的は何か
- 誰向けの資料を想定すればよいか
- どのくらいの粒度でまとめれば良いか
この段階で前提と仮説を立て、資料の骨組みを頭の中で組み立てます。できれば、この段階でパワーポイントで資料を簡単にでも作成しながら、より具体的にイメージ合わせができるとベストです。その方が依頼者も具体的なイメージを持っていないことが多く、依頼者自身にもイメージを持ってもらうことができるからです。
即座に資料の叩き台を作る（2割目安）
次に、イメージが固まったらすぐに資料を作り始めます。ここでのポイントは完璧を目指さないことです。とりあえず2割の完成度で構わないので、見た目と構成をざっくり作ってしまいます。即座に作らないとレビュー者の期待値がどんどん上がっていくので早ければ早いほど良いです。
2割の段階でレビューを依頼
資料作成の目途が見えたら、上司のレビュー時間を確保します。忙しい上司の場合、空き時間の確保が最も難しいかもしれません。もちろん、依頼者が顧客の場合でも直接出さずに上司のレビューを通します。（むしろ上司のレビューが一番きつい・・・）
レビューでは、方向性の認識は合っているかを確認します。ここでのポイントは、認識が間違っていた場合に、具体的に解像度高くイメージできるまで議論できるかです。ここでしっかりと腹落ちできるレベルまで資料完成のイメージができれば目標達成です。
最終化に向けて一気に仕上げる
方向性が合っていれば、あとは一気に8割を埋めるだけです。資料作成で一番労力がかかるのは、ゼロから骨組みを作る部分なので、そこを早めに済ませておくと精神的にも非常に楽です。8割を完成させるといっても方向性の認識があっているので資料作成だけだと楽です。
実体験から得た教訓
私がSEだった頃も、スピード感は大事にして資料作成をしており、資料作成の速さでは評価されていました。しかし、コンサルに転職してからは、そのスピード感ではまったく通用しないと痛感しました。２割を作成するとはいえ、その２割さえ作るイメージが湧かないことが多く、コンサルの資料作成は複雑だと感じることが多いです。
SE時代は、依頼を受けたその場が肝心だという意識はなく、その瞬発力がその後の作業効率を決めるものだとはわかっていませんでした。依頼者は依頼の場面では完全にイメージできていないことが多く、その場である程度すり合わせてしまうことで、依頼者の期待値の調整をすることもでき
まとめ：単に資料作成をしない
ITコンサルでは、単に資料を作り始めるのではなく、まずは仮説を持ったり、そもそも依頼者と完成イメージを合わせるといったことが重要になってきます。これは、SE時代にはあまり意識してきませんでしたが、コンサルにとっては日常の基本動作です。こういったSEとITコンサルの違いを紹介することで、コンサルへの転職やキャリア選択の参考になれば幸いです。
コメント