ITコンサルの仕事内容とは？よくある案件とPMOの1日のタイムスケジュールを紹介

「ITコンサルって、実際どんな１日を過ごしているのだろうか？」
「激務と聞くけど、人間らしい生活は送れるのか・・・」
「ITコンサルって具体的にどんな案件に入れるんだろう」
「ITコンサルに転職した後に自分のスキルを活かすことはできるのだろうか」

コンサルへの転職を考えている方にとって、ITコンサルに転職した後はどういった仕事内容になるのか、また日々どういった働き方になるのかということではないでしょうか。

コンサルは年収が高いから転職してみようか気になるけど、激務すぎるのが嫌なんだよなあ・・・と、どれくらい忙しいのか、どんな業務をしているのか、ワークライフバランスは保てるのか等、具体的なイメージがないと、なかなか転職を決意できないという方が多いかと思います。

この記事では、ITコンサルとして私の実体験をもとに、よくある案件とそのうちの一つであるPMOの１日のスケジュールを時系列でご紹介します。この記事を読むことで、ITコンサルの日常業務を具体的にイメージする参考になれば幸いです。

ちなみに、ITコンサルが仕事をする上で必要だと考えるスキルは以下の記事にまとめていますので、もし興味があれば覗いてみてください。

DX案件自体が豊富

ITコンサルとして転職すると、顧客が抱えるデジタルトランスフォーメーション（DX）の課題解決に関わることになります。

というのも、DXを進めたいと考えている企業は多いですが、組織内でその知識や体力が足りていないため、外部のコンサルに依頼してDXプロジェクトを進めることが一般的だからです。

これにより、ITコンサルが活躍できる案件は非常に多く、IT計画からシステム導入、業務改革までさまざまな範囲で活動できる機会があります。

各社自身でDXを進められないから

DX案件が豊富なのは、各社自身でDXを進められないからなのですが、企業が自身でDXを進めることができない理由は、知見の不足や社内のリソースが限られていることが挙げられます。多くの企業では、DXに必要な専門的な知識やプロジェクトマネジメントの経験が足りていないため、外部のコンサルタントに頼ることになります。

ITコンサルは、その専門的な知識を活かして顧客の課題を解決し、プロジェクトを進めるため、顧客から非常に重宝されます。このような背景により、ITコンサルは常に引っ張りだこなのです。

ITコンサルの仕事は、PMO、要件定義、IT企画/構想策定が中心

ITコンサルの仕事内容は、プロジェクトによって大きく異なりますが、大きく分類すると以下の3つが中心となります。1から順に案件数が多いです。

1. システム導入案件におけるPMO
2. システム導入時の要件定義
3. さらに上流のIT戦略や企画

PMOは全工程でプロジェクトに参画することになりますが、他は上流工程での役割であり、実際の開発作業やコーディングはSEやベンダーに委ねることがほとんどです。ITコンサルは、それらをPMOとしてマネジメント・支援する役割を担います。SEとの棲み分けは以下のようなイメージです。

---

SEが構築を担い、コンサルはその前工程を担う

ITコンサルが主に上流工程に関わる理由は、戦略や企画などの工程は抽象的で難易度が高いからです。そのため、単価が高くても、顧客はコンサルに発注します。コンサルは、企業の課題を整理し、要件を明確にして形に落としていきます。

そのため、ITコンサルは「どのようにシステムを作るか」よりも、「なぜそのシステムが必要なのか」「どんな価値を提供するのか」といった根本的な部分にフォーカスし、具体化していきます。そうして具体化された要件に対して、後続のシステム構築からSEが担当していきます。

---

具体例：私が携わったITコンサル案件

以下では、私が実際にITコンサルとして経験した3つのプロジェクトを紹介します。

SAP導入プロジェクトのPMO

SAP導入プロジェクトのPMOとして、以下のようなタスクを担当しました。

• プロジェクトの進捗管理
• 課題管理やリスク管理
• ステアリングコミッティ（ステコミ）の運営
• 各種フェーズゲート（要件定義完了、設計完了など）に向けたタスク整理と推進

コンサルは、PMOとはいえ、単に進捗を報告するだけでなく、プロジェクトがスムーズに進むよう、全体を俯瞰する必要があります。SEから報告される内容は正しいのか、その内容をもとに進捗や課題に問題はないのか等の判断や整理が常に求められます。

特に大規模なプロジェクトを進める際、コンサルが進捗管理や課題管理を行い、SE側でのプロジェクト進行が計画通りになるようにサポートします。

PMOとしての役割は、プロジェクトが円滑に進むための管理ですが、顧客とSIerの間に立って調整を行ったり、進捗が良くない場合にはSIerと直接議論して原因の追究や対策の検討をPMOも一緒に行うことがあります。

システム導入プロジェクトの要件定義

こちらもSAP導入プロジェクトでの経験ですが、SAPのようなパッケージを導入する際の導入手法として、Fit-to-Standardがあります。これはパッケージに業務を合わせる前提で要件を定義するのですが、以下のような業務を行いました：

• 現行業務とSAP標準機能のギャップを洗い出す
• ギャップを埋めるための業務フローや対応方針を検討
• 各部門と協議して、運用面の落とし所を確認

特に、顧客側の業務部門と密にコミュニケーションをとり、業務プロセスを深く理解したうえで、それをシステムでどのように実現するかを考える力が求められます。

IT戦略や構想策定等の要件定義の前

システム導入プロジェクトで、SE側で要件定義を始める前段階である、そもそもどういった戦略でIT投資をしていくのかを検討します。企業の中期経営計画に従って、IT戦略を立てたり、具体的にどのようなシステムを導入するのかを企画します。ここでは、以下のような役割を担いました。

• IT戦略を描き、その実現手段としてIT企画を立案
• ベンダー選定のためのRFPを作成
• 提案内容の比較評価と選定プロセスの支援

顧客がDXを進めるにあたり、まずはその構想を策定することが重要です。経営課題や業務課題に対して、どのように改善を進めればよいかわからない場合、ITコンサルが他社事例等を含めた知見からプロジェクトを強烈に推進します。

具体的には、IT投資の計画を立てたり、業務改善に向けてどのようなシステムを導入すべきかを検討します。他社事例や一般的な業界の慣習を踏まえた提案ができるため、コンサルの提案は顧客に刺さりやすいものになっています。

また、構想策定で決まった内容をもとに、実際にシステムを開発してもらうためのRFP（提案依頼書）を作成します。ベンダーが理解してこちらの依頼通りに回答できるように正確に作りこむ必要があるため、コンサルが緻密に作成していきます。

RFPに対するベンダーからの回答をもとに、どのベンダーを選定するかを支援する役割も担います。RFP作成は、システム導入の初期段階で重要な工程であり、ここでの適切な選定が後々のプロジェクトの成功に繋がります。

チェンジマネジメント

システムを導入する際、基本的には業務をシステムに合わせるため、業務が変わることが多いです。顧客の業務とシステムがマッチしない場合、業務のフローや担当者の役割が大きく変わることがあります。この業務変化を支援するのが、チェンジマネジメントの役割です。

顧客の業務ユーザーに変化を理解してもらい、導入後にうまく業務を進めてもらうためのサポートを行います。業務ユーザーが新システムに適応できるように、適切なトレーニングやサポートを提供することが求められます。

情シス支援

多くの企業では、間接部門の人数を増やしたくないため、IT部門（情シス部門）のリソースが不足していることがあります。特にシステム導入や新しいITサービスを展開する際、定常業務に加えてタスクが発生するため、情シス部門はその負担を軽減するために、ITコンサルを活用します。

ITコンサルは、様々なプロジェクトの進捗管理、課題管理やベンダーとの交渉等、さまざまな役割を柔軟にこなし、情シス部門を支援します。ITコンサルの多岐にわたる役割と柔軟な対応力は、情シス部門にとって非常に価値のある支援となります。

PMOの1日のタイムスケジュール

次から、具体的に私がPMOとして案件に携わっていた際の実際の１日について紹介します。

ITコンサルの忙しさはプロジェクト状況次第で変わる

最初から、状況次第で変わるという抽象的なことを言ってしまい申し訳ないのですが、結論はこれになります。想像しやすいかもしれないのですが、激務かどうかはプロジェクトそのものやプロジェクトの状況次第で変わります。

ITコンサルの1日は、プロジェクトの進捗状況やマイルストーンによって大きく左右されます。特に今回は、PMOの1日になるので、より一層プロジェクトの状況次第で忙しさが変わってきます。

例えば、ステコミやフェーズゲート等のマイルストーン前であれば、準備のための会議が増えるため、定時時間内では資料作成等の個人作業を進める時間が取れず、定時後にやっと作業ができるといった状況になります。逆に、比較的落ち着いた時期であれば、資料作成に集中できる静かな日もあります。

---

ITコンサルは、論点整理・資料作成が求められる

ITコンサルは、PMOとはいえ、単なる会議の進行役や課題の抽出、ToDoの整理をしていればよいということではありません。進捗会議で遅延が発生したら、その原因と対策を一緒に考えてネクストアクションまで落とし込み、課題やToDoは予定通り終わりそうなのか、リスクはないのかを担当者と一緒に検討する必要があります。

そのため、会議以外の時間はもちろん、会議内の時間も使って作業（論点整理・資料作成）できるかがポイントになります。特に会議が多い日は、作業の時間が確保しづらく、必然的に資料作成が定時後にずれ込むことが多いです。以下では、実際のスケジュールを通してその実態をご紹介します。

実例：PMOとして働いたITコンサルの１日のスケジュール

実例として、ある日のスケジュールを紹介します。この日は、内部進捗と顧客への進捗報告があり、PMOとしては比較的忙しい日の例となります。

このように、会議と作業が交互に訪れることで、資料作成の時間が押してしまうのが現実です。

---

コンサルの業務をイメージするのにおすすめの本

今回は、私のPMOとしての1日を紹介しました。

以下の本は私も”確かに”と思うようなことばかりでしたので、非常におすすめです。非常に面白くわかりやすいので、盛っているんじゃないかと思う部分もあるかと思いますが、コンサルの実態を把握するのに一番の本だと思います。

まとめ：忙しいけれど、やりがいのある仕事

ITコンサルの１日は確かにハードです。ときには定時後に集中して作業する日もあります。資料レビューが定時後に終わり、そこから赤ペンだらけの資料を直していくことなんてざらです。しかし、その分だけ力はつくと思います。

これらを成長の糧に変えられる人にとって、ITコンサルは非常に価値のあるキャリアになります。この記事を通じて、ITコンサルのリアルな１日を具体的にイメージしていただき、転職を前向きに検討するきっかけになれば嬉しいです。