ITコンサルで「激務」になりがちな人のパターンと理由、その対策

ITコンサルはIT分野の中では給与水準が最も高い一方で、「残業時間が多い」といった激務のイメージを持たれることも多いでしょうか。実際には、SEなどからITコンサルに転職して短期間のうちに、激務に耐えかねて離職する方もいる一方で、残業をせずに高いパフォーマンスを残し、プロモーションされている方も多くいます。

そこで、今回の記事では、激務になりがちなITコンサルのパターン、その背景や対策についてご紹介します。

【目次】

1. 「仮説を立てられない」ITコンサルは激務になりやすい
2. 「知識不足」のITコンサルは激務になりやすい
3. 「顧客に振り回される」ITコンサルは激務になりやすい
4. 「営業担当者の無理な受注」でITコンサルが激務になることも

「仮説を立てられない」ITコンサルは激務になりやすい

すべてのコンサルティングの基本手順は、仮説を立て、顧客へのヒアリングやリサーチによって得られた事実で仮説を検証し、必要がれば仮説を修正したり、新たな仮説を立てたりするサイクルを回して、顧客に最終的に報告する結論に近づきます。

例えば、顧客の既存ITシステムの問題点について、ユーザーに対してヒアリングを行う場合、ユーザーの話を黙って聞いていてはITコンサルの仕事は務まりません。ヒアリングに先立って経営層から聞いている問題認識と集めた資料に記載されていた事実から、仮説を立てて、その仮説を確かめる質問を次々に投げかけます。仮説が間違っていることが判明すれば、その場ですぐに仮説を修正し、新しい仮説を確かめる質問を投げかけます。

経験の浅いITコンサルが陥りがちなのは、この仮説の的確性が低くなることです。ヒアリングの時間は限られていますので、下手な鉄砲も数撃ちゃ当たる式の質問はできません。ヒアリング中の仮設の修正にも手こずります。そのため、ユーザーが話した内容だけを記録に残すことになりますが、それらが既存ITシステムの問題点の核心につながるとは限りません。問題の核心に迫らなければ、新たに情報収集の作業をしなければならなくなります。

また、リサーチ作業をする時に、経験の浅いITコンサルは、多方面にわたって無駄な事実の収集と考えうるすべての分析をしてしまいがちです。仮説を立てられないので、網羅的にメリハリなく作業してしまいがちです。期限が決まっている中でのこうした無駄な作業の積み重ねが激務につながります。

ITコンサルが実務経験を積み重ねていけば、仮説の精度を上げることはできるのですが、まだ経験が浅いうちは、所属会社にある過去のプロジェクトの実績を調べるなどして、補う必要があります。

「知識不足」のITコンサルは激務になりやすい

ITコンサルは、SEなどIT分野の他の職種より単価が高いため、顧客の期待値は当然ながら高くなりがちです。そのため、顧客との会話でITコンサルが知らないことが出てきても、顧客に対して「それは知りません」、「わかりません」と口にできないプレッシャーを常に受けます。「調べてみます」の一言を付け加えたとしても、「こんな高い金額を払っているのに、なぜ即答できないんだ」という顧客の視線を感じるケースもあり、中には実際に口に出す顧客もいるようです。

顧客と接する時には常に顧客と同じかそれ以上に知識をアップデートしておく必要があるため、知識が不足しているITコンサルは、次から次へと知らないワードが出てきて、毎日が調査時間との闘いで、激務になりがちです。

勿論、ITコンサルとして経験を積み、知識が累積していくにつれて、このような激務は避けられるようになります。また、プロジェクトは各分野のスペシャリストを集めたチームを組んで行うことが多いため、プロジェクト開始前の時間の余裕のある時に、プロジェクトに係る技術や業界、業務の知識をメンバーから仕込んでおくことも有効です。そのため、困った時には上司や同僚に助けてもらえるよう、社内で良好な人間関係を築くことも重要でしょうか。

「顧客に振り回される」ITコンサルは激務になりやすい

SEも同じですが、ITコンサルがシステムの開発や保守、運用などの業務を担当する場合に、顧客側の事情により予期せぬトラブルが起き、その対応で激務になるケースもあります。

ITコンサルが参画するプロジェクトにおいて顧客に報告書を提出する場合、最初のドラフト版を作って、顧客のレビューを受けて、内容を少しずつ修正していくことが一般的です。

ITコンサルが関与するのはITによって経営課題を解決するプロジェクトですから、顧客側の複数部署が関わります。顧客側で複数部署の要件を調整したうえで、プロジェクトに反映させる体制ができていない時には、ITコンサルに次々と報告書の修正要求が出されます。複数の関係者から出た修正要求が相矛盾することもあります。最悪のケースでは、顧客の部門間の利害対立が、ITコンサルが提出する報告書作成に持ち込まれてしまいます。部分的な修正で済めば問題ありませんが、報告書の骨格に修正を入れるのは負荷がかかり、ITコンサルは激務になりがちです。

このようにならないよう、一般的にプロジェクト開始前に、ITコンサル側の営業担当者とプロジェクトマネジャーが顧客と交渉し、顧客側の対プロジェクトの窓口を一本化してもらえるような体制を組んでもらうのですが、これがいつもうまく機能するとは限りません。また、顧客側の窓口が一本化されていても、報告書をまとめる最終段階で、顧客のキーパーソンの一声で内容がひっくり返されることもあります。「こうしたプロジェクトにアサインされるのはある意味運」という意見もありますが、事前にクライアント先や案件の状況を見極める目線やネットワークも重要でしょうか。

「営業担当者の無理な受注」でITコンサルが激務になることも

コンサルティングファームやSIerが仕事を獲得する際には、ITコンサル一人ごとの単価に時間数をかけて合算した金額を、顧客と合意したうえで契約します。この時間数が過小に見積もられている時に、ITコンサルは激務を強いられがちです。ITコンサルが実際に作業に要した時間が見積もった時間を超過しても、超過分を顧客に請求できませんので、超過した時間は、ITコンサルが勤務先から評価されない稼働時間となってしまいます。責任感と目先の仕事をすることが自分の成長につながると自分に納得させて激務に耐えるといったケースが起こりがちです。

近年では、プロジェクトの利益率も評価の対象とする会社は増えてはいますが、参画するITコンサルがプロジェクトに計上する時間を少なくさせることで原価を抑えて、利益率を上げることもできるため、営業担当者もタイトなスケジュールで、作業量も過小に見積もって、とにかく受注しようとするパターンもあります。

ITコンサルのプロジェクト原価の大部分は人件費であり、「プロジェクトに計上する時間を予定内に抑える」プレッシャーがITコンサルにかかるしくみが会社にあるために、このようなことが起きてしまいます。

悪質な営業担当者は、初めからこのしくみを利用することを見込んで、ITコンサルに過大な負担を負わせることになると知りつつ受注するケースもあります。このような確信犯的な営業担当者が高い評価を受けるような会社には早々と見切りをつけるのも一つの手でしょうか。

=================

ITコンサルのキャリアに関する記事

「ITコンサルから監査法人アドバイザリー」というキャリアパスとその際の注意点
https://www.axc.ne.jp/media/change-jobs-knowhow/itandauditor

「戦略ファームの役員になれる」ITコンサル、「システム屋で終わる」ITコンサル
https://www.axc.ne.jp/media/careertips/itconsultantst

SEとITコンサルが言う『上流工程』の違いと特色
https://www.axc.ne.jp/column/axis-column/se_cous/02.html

=================

今回の記事では、激務になりがちなITコンサルのパターン、その背景や対策についてご紹介しました。

キャリアでお悩みの方は、ぜひアクシスコンサルティングにご相談ください。