「ITコンサルとSEで仕事内容が似てそうだけど具体的には何が違うんだろう」
「自分にはITコンサルとSEのどちらが合っているんだろう」
「よく同じシステム導入のプロジェクトにコンサルとSEがいるけど何が違うんだろう」
「コンサルティングファームとSIerどちらが自分に合っているんだろう」
ITコンサルへの転職を考えている人の中で、SEとITコンサルの違いがイメージできないという方もいるのではないでしょうか。どちらもシステム開発に関わる仕事であるため、似た仕事内容だと思われがちですが、実際にはその役割には違いがあります。
私自身、SEからITコンサルに転職して感じたのは、同じシステム導入でも、求められる役割や取り組む課題がまったく異なるという点です。
この記事では、ITコンサルとSEの仕事内容と求められる役割やスキルの違いについて、具体的な事例で解説します。
ちなみに、SEとITコンサルでは、コアコンと呼ばれるロジカルシンキングのスキルが圧倒的に異なると考えていて、その理由を以下の記事にまとめていますので、もし興味があれば覗いてみてください。
仕事内容の違い
まずは、ITコンサルとSEの仕事内容の違いについてお伝えします。
ITコンサルは上流担当、SEは下流担当
システム導入のプロジェクトにおいて、ITコンサルは、上流工程から携わり、顧客の企画や構想がまだ柔らかいうちからプロジェクトに入り検討を進めます。
対してSEは、システム開発の実作業を担当することが多く、要件定義までプロジェクトが進行した後の工程から携わることが一般的です。
この違いが、ITコンサルとSEの仕事の大きな特徴となります。
具体的には、ITコンサルは「どういったシステムが必要か」といった戦略や企画を立てます。その後、SEがプロジェクトに参画したら、プロジェクトマネジメントを行います。一方、SEはシステム開発をするための要件定義から開始し、実際にシステムを設計し、構築していく役割を担います。
このように、ITコンサルはプロジェクト全体を俯瞰的に見るポジションで、SEはシステムそのものを作り上げる技術者としての役割を担います。
| 違い | ITコンサル | SE |
|---|---|---|
| 参画工程 | IT戦略/企画など、上流工程から参画し、PMOとして進捗を管理。 | 要件定義、設計、開発、テスト、稼働までのシステム構築に関わる。 |
| 管理対象者 | プロジェクト全体を管理。ベンダー側、顧客側（情シスや業務部門）を管理。 | 主にベンダー側の作業者を管理。 |
| 作成資料 | プロジェクト計画書、進捗報告資料等のプロジェクト全体に関する資料 | 要件定義書、設計書、テスト計画書など、システム開発に必要な詳細な資料 |
ITコンサルは、システム開発を担当しない
SEとITコンサルの大きな違いは、携わる工程にあります。ITコンサルは、プロジェクトの最初から関わり、企画や構想策定など、システム導入のプロジェクトの立ち上げから進めていきます。
実際にシステム開発を担当することはなく、要件定義からはSEに担当してもらいます。ただ、近年、開発まで担当するITコンサルも出てきていて、各社によって色が異なります。確かに、要件がわかっているITコンサルにそのまま開発まで担当してもらった方が顧客的にも安心するのかなとも思います。
一方、近年、SE側も逆に上流からプロジェクトに参画し、構想策定から実施することでその後の工程をスムーズに進めるようにしている会社もあります。
なぜ開発を担当しないのか？
ITコンサルティングファームとSIerでは、システム導入のプロジェクト自体の位置づけが異なります。そのため、それぞれの企業がプロジェクトに参画する目的も異なってきます。
コンサルティングファームは、あまりシステム導入のプロジェクトに偏らないようにしています。システム導入のプロジェクトは、他の戦略系や業務系のプロジェクトに比べると金額規模が大きいため、システム導入のプロジェクトばかりになってしまうと一本足打法になってしまい、ファームとしてのバランスが悪くなってしまうので、あえてそういったプロジェクトを取りすぎないようにしています。
一方、SIerは、大規模なシステム導入プロジェクトを受注してなんぼなため、上流から下流までを一気通貫で担おうとします。下請けベンダーを使いながら、各工程のスキルを持った人材を集めて推進します。
違いの具体例
以下に、ITコンサルとSEの仕事内容の違いを3つの具体例で比較します。
参画する工程
ITコンサルは、システム導入のプロジェクトにおいて、上記の絵の①、②、③を担当します。
- ①IT戦略/企画：プロジェクトの全体像を描いたり、SEにプロジェクトの提案依頼するためのRFPを作成
- ②要件定義準備：プロジェクト計画書や管理計画を作成し、SEが参画後のプロジェクトがスムーズに進行するように準備
- ③PMO：プロジェクトが進行する中で、進捗や課題を管理
一方、SEは要件定義から開発/テストといった、実際のシステム作成に関わる工程を担当します。
ITコンサルの方が上流から顧客と密に関わってプロジェクトを進める役割で、SEは下流から主にシステム構築に責任を持つ役割でプロジェクトに参画します。
管理対象者
ITコンサルは、プロジェクト全体の管理を担当します。システム導入を進めるためには、SE側だけが頑張ればよいのではなく、システムが導入される側（＝顧客側）の情シス部門やそのシステムに影響がある業務の部門も自分事として携わる必要があります。
そのため、ITコンサルはSEから依頼された資料確認や仕様が合っているか、これで業務が回りそうか、実際にシステムを作ってみたのでテストしてほしいといった、SEと顧客双方でのやり取りも管理する必要があります。
一方、SEは主にベンダー側として、下請け作業者の管理を行います。顧客側にレビューしてもらう資料がある場合は、SEが顧客とのコミュニケーションをとることになります。
作成資料
ITコンサルが作成する資料は、主にプロジェクト全体に関わる資料です。これには、プロジェクト計画書、進捗報告資料、課題管理表などが含まれます。ITコンサルは、プロジェクトの大枠を把握し、顧客に向けて適切な資料を作成し、説明を行います。
SEが作成する資料は、主にシステム導入に必要なものです。例えば、要件定義書、設計書、テスト計画書などが含まれます。SEはシステムがどのように作られるべきかを具体的に記述し、その情報を基にシステムを実際に開発していきます。
求められる役割の違い
次からは求められる役割をコンサルティングファームとSIerの違いという観点から紹介します。
コンサルティングファームとSIerの違い
コンサルティングファームとSIerでは、ビジネスモデルが全く異なります。コンサルティングファームは、上流工程に強みを持ち、経営や業務の課題を解決するための戦略立案からシステム要件の定義を行い、全体的なプロジェクトをマネジメントする役割が多いです。
一方、SIerは主に大規模なシステム導入プロジェクトを好み、それを一気通貫でシステム稼働まで実現するのが主な役割です。
| コンサルティングファーム | SIer | |
| 単価 | 高い | 低い |
| 役割 | 思考 | 実行 |
| 参画工程 | 上流 | 下流 |
具体例
単価
コンサルティングファームは、複雑な課題解決やその実現手段の検討等の顧客自身ではできないような役割を担当します。その代わりとして、高い報酬を得るため、コンサルタントの単価は高めに設定されています。
一方、SIerの単価はコンサルと比べると低いです。SIerはシステム開発の実行に特化しており、その工程まで進み、SIerでも実行可能になれば、コンサルからSIerに切り替えるのが一般的です。
参画する目的
コンサルティングファームが求められる役割は、主に戦略的な思考やプロジェクトを成功に導く推進力です。上流工程では、顧客の問題を深掘り、どのように解決すべきかを考え、最適なシステムやプロセスを提案します。また、PMOとしてSE側の提案が実現可能性や進捗・課題管理でも能動的にリスクの洗い出し等を行いプロジェクトの成功に責任を持ちます。
SIerでは、実際にシステム導入を実行することが求められます。要件定義からシステム導入、運用までを一貫して担当するため、技術的な知識や経験が求められ、システム開発における具体的な作業や管理能力が重要です。
参画する工程
コンサルティングファームが参画する工程は、主に戦略や業務改善の上流工程です。それがどのようにシステムに落とし込まれるか、システムベンダーを選定するまでを担当します。また、SEがプロジェクトを進めるにあたって、PMOとしてのプロジェクトマネジメントも全工程で担当します。
一方、SIerが参画する工程は、主にシステム導入の実行部分です。コンサルが作成したRFPが出てきてから参画することが多いため、要件定義以降のシステム稼働までの工程を担当します。
スキルの違い
SEからITコンサルに転職して感じた最も大きな違いは、求められる役割の違いです。そのため、SE時代に培ったスキルだけでは、コンサルとしての役割を十分に果たすのは難しいと実感しました。特に、コンサルに求められる「ロジカルシンキング」や「戦略的な思考」が不足していると、仕事を進める上で大きな壁にぶつかることになります。
というのも、コンサルはSEよりプロジェクト全体の成功に責任を持つ役割になるため、プロジェクト全体を進行させるためにどうすべきかという、ロジカルな思考力や、リーダーシップが必須であると感じました。
SEより能動的に強烈に推進することが求められる
ITコンサルとして、SEよりプロジェクト全体が成功するためにはどうしていくべきかという役割になるため、プロジェクト全体を俯瞰して、進捗が遅れているチームの問題点とその対策を検討する必要があります。スケジュール調整や進捗管理の際に、受け身ではなく、能動的に強烈にプロジェクトを前に進めていくことが求められます。SEの時に求められていたPMOとはレベル感が異なることに気づきました。
大変な場面と必要なスキル
それでは、実際にどのような場面で大変さを感じたのか、その場面でどういったスキルが必要になったのかの具体的な例をいくつか挙げてみます。
資料作成・説明
ITコンサルとして最も大変だと感じる業務の一つが資料作成です。ITコンサルは、プロジェクト全体としてどうすべきかという複雑な問題に立ち向かっていくことが多いです。それでも、顧客へ説明する際には、これが正しいですと自信を持って説明できないと顧客の信頼を得ることはできません。
そのため、特に上司からのレビューが厳しく、資料が通らないと顧客に提出できないため、スピードと品質を両立させる必要があります。私はSE時代にも資料作成は行っていましたが、ITコンサルとして求められる資料のレベルは全く違うと感じました。
進捗・課題管理
進捗管理や課題管理は、SE時代でも行っていた業務ですが、単に進捗を追うのはコンサルに求められるレベルではありません。状況を踏まえて、リスクはないか、リスクがあればどういった打ち手が必要かを担当者に検討させたり、一緒に検討することが求められます。
リスクを早期に察知してプロジェクトを円滑に推進することが求められます。SE時代のPMO業務では、この部分を機械的に管理することが多かったのですが、ITコンサルでは、課題に対して主体的に打ち手を考える必要があります。
ミーティング調整
PMOはプロジェクト全体のスケジュールを把握し、顧客とのミーティングを調整する必要があります。SEの時は、各チームから求められたらミーティングを調整するくらいで、PMOが積極的に調整しに行くことはしなかったです。
しかし、ITコンサルでは、全体スケジュールから逆算するとこの期限までにタスクを終わらせる必要があるため、顧客レビューはいつまでに必要といったように各チームにスケジュールを出させることが求められました。顧客の繁忙期では、どのタスクを優先して進めるかを判断し、関係者との調整を行うかということもPMOの責任になります。
SEの方が自分に合うと感じた場面
ITコンサルの仕事は、良くも悪くも上流工程の企画や戦略を立てることが中心です。しかし、実際に顧客の要件を具体的な形にできるのはSEの仕事です。
SEは上流から下流の工程まで幅広く関与するため、工程の途中で顧客が抱える問題やニーズをシステムに反映させ、最終的な形になるまでを見届けることができます。この過程には、顧客の特に業務部門と直接的にコミュニケーションを取りながら進める部分が多く、非常にやりがいがあります。
コンサルは良くも悪くも形になる前の上流工程が主戦場
ITコンサルの役割は、顧客の課題を抽出し、それに対する解決策を提案することです。しかし、その提案が実際にどのようにシステムとして実現されるのか、その部分を担当するのはSEになります。例えば、ITコンサルは、企業の業務プロセスの改善案を検討しますが、そのプロセスに沿ったシステム開発や導入作業はSEが実施します。
そのため、顧客の要件が形になる過程には深く関与することができず、SEが要件定義から設計、開発、テスト、そして最終的なシステムの導入に至るまで、一貫して関与できるため、成果が目に見える形で現れることに大きな満足感を得られます。
具体例
顧客の要件を最終的な形にできる
SEの時、顧客からの要件を実装することを行っていました。顧客が抱える課題をヒアリングして、システム要件に落とし込み、システム化されたものを顧客に提案する作業を行っていました。システムがどんどん形になっていくのを目の前で見ることができ、顧客と一緒に検討したものが最終系としてシステムという形になることに非常にやりがいを感じていました。
実際のシステムで説明できるため顧客に納得感がある
ITコンサルは、まだ上流工程のため、顧客への説明が、パワーポイントの紙芝居かできてもモックアップとなってしまい、顧客が腹落ちしないまま検討が進んでしまうことが多いです。一方、SEは、システム開発の途中段階で、顧客に実際のシステムで説明できます。
これにより、顧客がシステムの仕様について不明点を質問した際に、実際にシステムを操作しながら答えることができるため、顧客に納得感を与えることができます。この実際のシステムを通じた説明は、ITコンサルタントではできない部分であり、SEとしての仕事の魅力だと感じました。
自分も手触り感がある
ITコンサルが活躍するシーンは、まだモノがない工程のため、どうしても「手触り感」が薄くなります。一方SEは、システムを設計し、開発して、テストを行い、実際に顧客の環境で動作させるという一連のプロセスを経て、システムが実際に動く様子を目の前で見届けることができます。
この「手触り感」がSEにはあり、私はその実感が非常に大きなやりがいだと感じました。自分の手で作り上げたシステムが動くのを見た時の充実感は、ITコンサルタントとしての仕事では味わえなかった部分です。
まとめ
ITコンサルとSEは同じシステム導入のプロジェクトに参画するといっても仕事内容が異なります。今回紹介した違いを踏まえて、ITコンサルとSEのどちらがあっているか等、キャリア選択の参考になれば幸いです。
コメント