「SEの経験は、他の職種でも生かすことができるのか」
「SEだとスキルが身についている実感がないが、成長できているのだろうか」
「このままSEとして働いていて市場価値は高まるのか」
SEの方なら、一度はこうした疑問を感じたことがあるかもしれません。私は、SEとして主に製造業向けのシステム構築案件に携わり、その後にITコンサルへと転職しました。転職前には、具体的にどういった自分の経験がITコンサルとして通用し、活躍できるのかイメージができていませんでした。
実際に、ITコンサルとして複数の案件を経験した今では、SE時代の経験はITコンサルとして大きな強みになると断言できます。むしろ、現役のITコンサルとしてプロジェクトを進める中で、こういう経験をしているSEは本当に頼りになると実感する場面が何度もありました。
この記事では、SEからITコンサルに転職を考えている方に向けて、どのようなSE経験がITコンサルので活かせるのかを、私自身の実体験を交えて詳しく紹介します。
※ちなみに、私はSEこそITコンサルに転職すべきと考えているのですが、その理由を以下の記事にまとめていますので、もし興味があれば覗いてみてください。
ITコンサルから見てSEの経験は羨ましい
私は現在、ITコンサルとしてPMOを主に担当し、顧客と共にプロジェクトの計画・進捗管理・課題解決に取り組んでいます。その中で常々感じるのが、SEでのチームリーダーの経験やベンダーと一緒に開発に取り組んだ経験がコンサルで仕事をする上でとても役に立っているということです。
たとえば、SEとして設計〜開発〜テストまでの一連の工程に関与していたからこそ、SEが提示してきたスケジュールに対してコメントができるし、実際の経験から対等に議論できます。これは、単なる理論ではなく現場感覚を伴った実務理解があるからこそ可能になるスキルです。
コンサルティングファームには業務知識の豊富な人材も多く在籍していますが、実際に手を動かした経験を持つ人は意外と少ないのが実情です。だからこそ、SEのバックグラウンドを持った人材は非常に重宝されるのです。
ITコンサルにはシステム導入のプロジェクトが多い
コンサルティングファームに転職して驚いたのですが、システム導入のプロジェクトが多く、またそれが重宝されているのです。システム導入のプロジェクトは規模が大きいため売上も大きくなるからです。
とはいえ、開発工程のような単価の安いリソースが競合となるような仕事はできないので、実際の開発工程をコンサルにいると経験することはできません。
SEは一連の工程を経験できる
一方、SEはシステム構築において、実装やテストだけでなく、要件定義や設計といった上流工程から参画するケースが多いです。特に大手SIer出身のSEであれば、上流〜下流までを一人称で経験している方も多いと思います。
この一連の工程をシステム開発の責任を伴ったうえで経験していることが、ITコンサルの現場では大きな武器になります。
理由はシンプルで、ITコンサルはシステム構築をマネジメントする立場であるからです。実際のプロジェクトでは、
- ベンダーの作業見積もりが妥当か
- 今の進捗で間に合うか
- 課題がプロジェクト全体に影響しそうか
などを判断する機会が多くあります。
こうした判断やベンダー側と報告の妥当性を議論するためには、システム開発の実態を理解している必要があります。その点で、SEとして実際に手を動かし、ベンダーとしてプロジェクトに携わった経験は非常に貴重なのです。
SE経験がITコンサルで活きた具体例2選
それでは具体的にITコンサルで活きたSEでの経験を紹介します。
システム構築の経験
一つ目は、システムを構築した経験です。ITコンサルからすると、SEでのITの技術的な経験全般が羨ましい経験になります。
SEは、新卒でまずはOJT等でプログラマーとしての経験を積むことが多いです。これは年次が上がった際に実際の開発現場の経験をしないと下請けのベンダーと開発に関する議論ができないためです。
そういった生々しい経験はITコンサルではできないので、ITコンサルとしてベンダーと会話する際にはSEとして貴重な経験になります。
次からシステム構築のプロジェクトにおいて何ができることがITコンサルに活かせるのかを紹介します。
下請けベンダーと会話できる
SE時代、私は下請けベンダーのエンジニアと頻繁にやりとりしていました。進捗を管理する際に気をつけるべきポイント、短納期の依頼だから伝え方を気を付けないとな、どういった調整が現実的か、といった“泥臭い現場感”を肌で学びました。
ITコンサルになると、今度はSEを管理する立場になります。ここで重要なのが、「無理を言わず、無理があると判断したら顧客と一緒にスコープ調整する」といった適切なマネジメント姿勢です。これは、SEとして現場を経験したからこそ身についたものです。
上流〜下流までの各工程が分かる
私はSE時代、要件定義からリリース後の保守までの各工程の案件に参画しました。この経験のおかげで、各工程では通常どう進め、何に気を付けるべきかを自分の経験から理解しています。
ITコンサルとしてPMOをする際、ベンダー側から出してきたスケジュールの妥当性やリスクを察知できることがあります。それはまさに、SEとして全体像を把握した経験があるからこそだと感じています。
設計書や計画書を作成できる
実施に自分で設計書や計画書を作成することで、ITコンサルとしてSEを管理する際に、SEがどんなドキュメントを作成しているのかのイメージができると管理がしやすくなります。
こういうドキュメントだと顧客レビューが必要になるのではないか、計画書では特に業務側の現場メンバとのすり合わせが必要になるのではないかと勘所が働くようになります。これはSEと対等に議論をする上で重要なスキルになります。
SAP関連のPJ経験
2つ目は、SAP関連のPJ経験になります。ITコンサルというと、ロジカルシンキングが得意な人といったイメージで新卒の時にSEでの就職を考えていた私からすると、一部の特別な人がなれる仕事だと思っていました。
しかし、実はそんなことはなく、実際のコンサル案件の中にはSAPのようながっつりシステムに関わる案件も非常に多く存在します。
そのため、コンサルティングファーム側もSAP案件を取るために、SAP経験者を採用したいと考えています。私はSAPモジュール担当ではなかったものの、PMOとしてSAP案件に深く関わっていました。
顧客との調整や進捗管理、ドキュメント作成など、現場での実務経験が評価され、ITコンサルへの転職をスムーズに進めることができました。
SAP案件の推進ができる
SAP案件の推進ができるSEはもはやコンサルと同じスキルを持っていると言えます。SEとITコンサルの仕事の内容が全然違うのではないかと思う人も多いかと思います。
確かに、SEの方が技術よりでコンサルの方が顧客寄りなことは間違いありません。そのため、提案資料を作ったり、会議でファシリテーションをする業務は増えます。
しかし、SEとして、顧客と会話して資料を作成し、会議のファシリテーションを実施することはあると思います。その経験はITコンサルでも生かすことができます。
SAPの各工程がイメージできる
基幹システムを刷新するプロジェクトはコンサルでも多いです。各企業で基幹システムは無くてはならないシステムですが、顧客自身でシステム導入することは不可能です。
だからこそ、SAPのPJ経験があり、SAPの各工程で何をやらないといけないかをわかっている人は非常に貴重でコンサルとしても求められるのです。
コンサルに転職して活躍できるか不安になるのは当然のことだと思います。自分は特別な実績がなかったり、これといった強みがないと感じる人もいるかと思います。
しかし、明確にわかるのは、SAPの知識を持ち、現場で実務経験を積んできたSEは、それだけで希少価値があるということです。
SAP学習におすすめの１冊
私はPMOとしてSAP案件に入ることが多いのですが、さすがにSAPのことを知らないと会話に入っていけないので勉強しようと思ったのですが、インターネットだけだとよくわかりませんでした。そこで本屋で立ち読みして以下の本がとても分かりやすくておすすめです。
まずは概要レベルでイメージを付けたい方にはお勧めです。特に私がイメージできなかったのが、モジュール間の連携(MMで請求書照合するとFIで買掛金が計上される連携等)でそれが分かりやすくて、立ち読みしてすぐに購入しました。
まとめ：SEの経験は、間違いなくITコンサルで活きる
SEでの経験はITコンサルで活きます。ベンダーの立場での経験は、コンサルでプロジェクトマネジメントをする際に説得力をもたらします。もし、ITコンサルに興味のあるSEの方に、この記事が少しでも参考になれば幸いです。
コメント