「コンサルって、SEと何が違うの？」
SEとITコンサルでは役割や必要なスキルはそれほど変わらないというのが私の意見ですが、細部で異なる部分はあります。コンサルへの転職を考えるSEの方にとって、業務の進め方や求められるスキルの違いは、細かくても気になるポイントかと思います。
この記事では、元SEで現役のITコンサルである筆者が、自身の実体験をもとに「確認の仕方の違い」と、その背景にある考え方をご紹介します。SEの時と意識することが全然違うと思いましたので、そのポイントを具体例を用いて整理します。読み終えたころには、ITコンサルがどのように確認を行い、なぜそれが重要なのかが、きっと腹落ちするはずです。
※ちなみに、私がSEこそITコンサルに転職すべきと考える理由は以下に記載しています。
結論：前提や仮説をもって、確認する論点を明確に
SEからITコンサルに転職して、SE時代との大きなギャップだった一つに、確認の仕方があります。SEの時はオープンクエスチョンで顧客等に確認していたのですが、コンサルでは基本的にNGです。何かを確認する際には、論点を明確にして、仮説や前提を持って行うべきという共通認識があるからです。
漠然と「これで大丈夫ですか？」と聞くのではなく、「この前提でこう考えているのですが、認識が合っていますか？」というように、確認する側がある程度の仮説を立てて伝えることが基本姿勢です。このような確認ができると、会話の精度が一気に上がり、確認された側も論点が明確になってフィードバックしやすくなるためです。
理由：曖昧な質問では、曖昧な回答しか返ってこない
SE時代は、「確認＝相手に正しさを聞くこと」と捉えていた場面が多く、よくあるのが「このように資料を作ったのですが問題ありませんか？」というような聞き方をしていました。ところが、ITコンサルの現場ではこのような確認は通用しません。なぜなら、確認する側の論点が曖昧だと、相手の確認時間もかかりますし、何を気にしているのか全く分からないからです。曖昧な確認は、フィードバックが抽象的になり、結果的に双方の時間を浪費するだけでなく、信頼関係にも悪影響を与えかねません。確認の質＝論点の解像度が成果の質を決めるといっても過言ではありません。「この前提のもと、この考えで資料を作りました。この考えの場合、AがBになる認識なのですが、認識合いますか？また他の部分でも気になる点があれば指摘をお願いします。」といった感じだと答える側も答えやすいし、他の部分でもコメントしやすくなります。
確認で意識すべき点
何かを確認する際には、意思をもって確認する必要があります。仮説をもって話したり、前提を置いて結論付けて話さないと、確認された側は、何を確認されているのかわからないし、前回言ったことの前提がすり替わってしまう可能性があるからです。
具体例1：仮説をもつ
たとえば、顧客の業務フローに対して改善提案を行う場面。
NG例： 「ここのプロセス、少し改善したほうがいいと思うのですが、どうですか？」
OK例： 「現状のプロセスではA→B→Cと進んでいますが、Bの部分が属人的になっており、ここがボトルネックになっているように見えます。たとえば、Bを標準化してDの工程に組み込むことで効率化できると考えていますが、この仮説の方向性は合っていますか？」
このように仮説を立てて確認することで、相手はその仮説の妥当性について明確な意見を述べることができますし、ズレている場合も「何がどう違うのか」という観点でフィードバックがもらえます。
具体例2：前提をすり合わせる
確認するうえでもうひとつだと考えているのは、前提をすり合わせることです。
SEの現場では、「この仕様でOKですか？」というような聞き方が多いですが、これでは相手との前提が揃っていないと、認識違いが起こりやすくなります。たとえば、 「Aという前提のもと、これから説明する仕様を考えたのですが、まずは前提の部分で認識が異なる部分はありますか？」 というように、どの条件下での議論なのかを明示すると、共通の土台の上で会話ができます。
前提を明示しないと、途中でボタンの掛け違いが起こってしまい、議論そのものが無駄になりかねません。
まとめ：確認とは「自分の意思を持って問う」こと
ITコンサルでは、単なる質問ではなく、前提や仮説を明確にした意思を持った確認が求められます。確認の仕方を磨くには、常に自分の仮説や前提を持ち、確認内容の解像度を高めたうえで、それを相手に伝える意識をすることだと思います。これは、SE時代にはあまり意識してきませんでしたし、求められなかった点になりますが、コンサルにとっては日常の基本動作です。確認の仕方ひとつで、相手の信頼や、議論の質、成果のアウトプットが大きく変わってきます。
コメント