社内SEに転職してキャリアアップ! そのために知っておきたいことは?

  • このエントリーをはてなブックマークに追加

現在エンジニアとして働いているけれど、社内SEに転職を希望している、という方が多いようです。その理由は様々ですが、やはりエンジニアならではの苦労、心労がうかがえます。一方で、社内SEと言ってもその活躍の場は様々です。業界が違えば仕事内容も変わりますし、仕事内容も多種多様です。 このページでは社内SEの様々な仕事内容を紹介し、転職を成功させるコツについても触れています。社内SEに転職を希望する方はぜひ最後までお読みください。

★厳選!おすすめ転職サイトランキング★
転職サイト名 HOP経由登録者数 求人を探す
GEEKLY(ギークリー)

詳細を見る

DODAITエンジニア

詳細を見る

forkwellscout

詳細を見る

1.社内SE(システムエンジニア)にはどんな転職先がある?

・商社系、金融、物流、Web系…業界別の仕事の違いは?

●まず、社内SEの基本的な役割について

社内SEというのは、自社の事業目的・事業戦略に見合ったITシステムを(原則として)自社内でつくり上げるSEです。ただし、企業の業務内容や企業規模によって、社内SEの役割・業務内容は千差万別。まずは、その基本的な役割を整理しておきましょう。

ただし、その役割や職種の名称も企業によって異なってきますので、ここではITエンジニアリングの世界で比較的馴染みのある用語を使ってその概要を示すことにします。

社内SEが求められる役割を上流工程(マネジメントレベル)から下流工程へと総覧していくとおおよそ次のようになります。

▼CIO:Chief Information Officer
企業の経営戦略に従って社内の最適な情報システム戦略を企画・立案・運用する最高責任者。
▼システム企画
マネジメントクラスの経営戦略を受けて、社内の情報システム戦略の企画・立案を実行する職種。
▼インフラ/ネットワーク担当
社内LANの設計・構築からサーバの構築・運用・保守・管理など(主にハード寄り)を担当。
▼システムアナリスト
社内の業務フロー解析、システム化に必要な要件定義などを担当。システム企画が兼ねる場合も。
▼アプリケーション担当
システム設計・開発の実行行為者。社外ベンダーへの発注・進捗管理、あるいは自社開発も。
▼ヘルプデスク
社内システム、社内ネットワークの保守・管理、各業務部門でのシステムトラブルへの対応など。

もちろん、すべてのIT企業がこれら社内SEの役割や職種のすべてを持っているとは限りません。担当者の人数に限りがあれば、他の役割を兼務したり、ときには個別の役割や機能を社内SEが社外ベンダーにアウトソーシングしたりすることもあります。

このような社内SEの基本的な役割・職種を前提として、各業界別にその仕事の特徴を見てみましょう。

●商社系の社内SE

商社は、作り手(メーカー)と売り手(小売)、さらには使い手(ユーザー・消費者)をより良い形でつなぎ、市場に商品やサービスを提供する企業です。この商社には総合商社と専門商社があります。

まず総合商社ですが、これは企業規模が非常に大きく、きわめて多岐にわたる商品やサービスのアイテムごとに多様な専門の部門が細分化されています。例えば、食品、日用品、繊維、鉄鋼、自動車部品、エネルギー資源、あるいは金融サービス、物流・流通サービス、さらには宇宙開発にいたるまで、ありとあらゆる商品・サービスを手がけるのが総合商社です。

このような多様な部門の専門性に対応するように業務が細分化されているのが、総合商社の社内SEの特徴だと言えます。

もちろん、全社で使用するネットワークシステムや財務・会計システム、物流システムなどのように、全社的な統一性と汎用性を必要とするシステム構築などは、全社システムに対応する一つの社内SE部門が担当します。

しかし、企業規模もきわめて大きく、細分化された専門事業部門の集合体である総合商社では、それぞれの部門に専門的なシステム構築を必要とするため、個別の部門ごとに個別の専門性をもった社内SE部門が対応していなければなりません。個々の部門業務を支援するシステムを、個々の社内SE部門が日々カスタマイズしていかなければ、その事業部門の円滑な業務を損なうことにもなりかねず、結果として会社全体の業績にも影響してしまうからです。

このような専門事業部門の集合体である総合商社では、必然的に必要となる社内SEの業務内容や役割は多種多様です。もちろん、そこに従事する社内SEの人員も相当な数にのぼります。

一方、ある特定の専門品目やサービス事業を一社で手がけるのが専門商社です。総合商社が持つ複数の専門事業の一部門が、一つの会社になっているとイメージしていいでしょう。食品商社、医薬品商社、化学瀕商社、繊維・アパレル商社、エレクトロニクス商社、機械部品商社など、事業分野の専門性によって、専門商社の事業形態も実に多様です。

その事業・業種の系列から見ると、メーカーのトレーディング部門が商社へと独立したメーカー系商社、総合商社の関連子会社として独立した総合商社系、それ以外の独立系商社と、創業の経緯はほぼ3つに分類されます。

専門商社での社内SEの役割は、総合商社の個別の専門部門の事業を専門の社内SEが支援したように、専門に扱う商品事業・サービス事業をシステム側から支援することにあります。扱う商品・サービスの品目は多くありませんから、社内SEの業務もその商品・サービスに対応した専門的なシステムに特化したものになります。必然的に、社内SEの部門の規模も人数も、専門商社としての事業規模に対応することになります。

総合商社であれ専門商社であれ、そこには共通する役割と業務があります。

一つの事業部門が扱う特定の品目に特化されたシステム開発、その運用・保守・管理までを一貫して担当するということです。

商社が業務支援のために新規のシステムを開発する場合には、社内SEが中心となり社外ベンダーに発注することがあります。外注してできたシステムの検証、運用、管理は、もちろん社内SEの仕事です。

既存のシステムの運用においては、他部門からの要請でその保守・調整を依頼されたり、改良のためのプログラムを行ったりすることが主な業務です。

商社ビジネスでは、商品価格や市場の流動性、世の中の技術革新の速度、情報価値の変化などによって、その事業内容をフットワークよく変容させていくことが求められます。そのため、業務に必要な基本のシステムは、それらの流動性や変化に合わせて、逐次カスタマイズしていかなければなりません。社内SEとそのスキル向上が商社において求められるのは、このようなスピード感あふれる商社の事業特性が強く反映しているからにほかなりません。

●金融系の社内SE

金融と一口にいっても、銀行、証券、保険など、その業態の多種多様です。ここでは、金融とIT・システムとの関係を一般論として、特に社内SEとのかかわりを中心に記していくことにします。

金融におけるIT・システムという位置づけは、他の業種・業態とは異なっています。

というのも、金融はマネーという数字的な情報のやり取りそのものがビジネスになっているからです。つまり、情報処理それ自体が業務の核に位置づけられているのです。

また、金融機関のSEになるということは、システム構築・運用等という業務を通して経営の一部に携わることを意味します。この点は金融の社内SEという職種・職能を考えるとき、きわめて重要です。

特にCIOやシステム企画といった上流工程を担当するケースでは、金融業務の全体のシステム像をデザインすることにもなります。それはつまり、金融機関としての経営戦略・事業戦略をシステム上に描き出すというポジションを得ることになるわけですから、社内SEの責任は重大です。

また、金融商品の多様化・複雑化に伴ってITシステムの開発速度・更新速度も増し、個々の金融システムの複雑性も増すことになります。そうなると、マネジメントクラスに近い上流工程だけでなく、インフラ整備、システム解析、アプリケーション開発、ヘルプデスクなど下流工程における社内SEの業務も重要度を増していきます。システムが多様化・複雑化すればするほど、ユーザー(他部門)とのコミュニケーション頻度も増え、社内SEによる金融実務支援の重要性も高くなっていくわけです。

そこで求められるITスキルについても、個別に細分化されたシステムに対応するスキルや経験が問われます。例えば、インフラ系・アプリケーション系のどちらか、オープン系・Web系・メインフレームのどれか、使用経験のあるOS・ミドルウエア・開発言語は何か、などです。

また、過去に経験した金融機関・SE業務は何か、あるいはそのフェーズは何かも、金融系の社内SEのリソースとして重要です。特にファーズに関しては、要件定義、設計、開発、運用、保守・管理など、どの段階の業務に関わったかによって、社内SEのスキルレベルが推し量られることになるのです。

これ以外にも問われる経験とスキル要素として、年齢に応じたマネジメント経験や英語力の比重も軽くはありません。マネジメント経験も、プロジェクトマネジメント、ピープルマネジメント、ベンダーマネジメント等によって、必要とされるスキルレベルが判断されます。英語力については、外資系金融機関は言うに及ばず、海外展開している日系の金融機関なら、海外向けのシステム担当や海外拠点への異動を前提とすれば、当然のスキルと言っていいでしょう。

●物流系の社内SE

物流業界は他の業界に先駆けてIT化を推進してきた歴史があります。POSシステムによって物品販売の売上実績の集計をシステム化し、CRM(顧客関係管理)システムによる商品と顧客情報のマッチングでサービスの向上をめざすなど、物流業界におけるIT化の先駆性は、今日のビッグデータ応用技術へとつながるポテンシャルを秘めていたと言えます。

物流系におけるシステム化・IT化の流れは、商品にデジタル情報をタグ付けすることによって、主にその情報管理をシステムに担わせ、流通と商品配送の信頼性や精度を向上させることにあります。

商品とデジタル情報を一対一で対応させ、その情報をシステム上で一括管理すれば、情報と同時に流通する商品そのものの流れを高い精度でコントロールすることができるからです。

また、ICタグなどを使ってトレーサビリティ(商品の追跡可能性)を追究する最近の物流システムは、こうした物流系のIT化の流れに沿ってより進化してきたものです。さらには、個人情報保護などITにおける安全性確保の課題も探求されつつあり、信頼性・安全性指向の技術の向上によって、顧客企業や消費者の顧客満足度を上げようとしているのが物流系企業の今日の姿だと言えます。

物流系企業におけるIT技術の進化は、産業界全体のサプライチェーン・マネジメントの効率化・合理化、ロジスティクスにおけるコスト削減などにも大きく寄与してきました。その意味では、物流系企業の社内SEの仕事は、産業界全体の成長力に貢献できる重要性を秘めていると言えます。

このような物流系企業の社内SEが、専門のIT知識を持ち、常にそれを更新させていなければならないのは当然でしょう。そのうえで、最新のIT技術をキャッチアップしていくことが要求されます。また、商品=モノの流通に対する見識だけではなく、商品の運び手(配送員など)や受け取り手(企業や消費者)といったあらゆるユーザーの気持ちに対する洞察力も必要とされます。

物流系企業が持っている先進性のあるIT技術は、まだIT化の発展途上にある企業に対するコンサルティング業務にも応用が期待されています。そこでは、本来は自社のシステム業務に従事している社内SEが、他社の物流システムの構築や運用などへのコンサルティングを行ったり、場合によっては、他社の物流システムの開発を受注する、いわば外部ベンダーとしての役割を担ったりすることもあります。

●Web系企業の社内SE

Web系企業と通称されるのは、インターネットを通じて自社でサービスを提供する会社のことです。

知名度の高いところを並べると、GoogleやYahooといった検索・ポータル系、FacebookやTwitterなどのSNS系、Amazonや楽天などのEC(Electronic Commerce:電子商取引)系、DeNAやGREEなどのソーシャルゲーム系などがあります(有名すぎる会社ばかりですが)。

それぞれのWeb系企業に事業目的と業態の違いがあるように、その社内SEのあり方にも違いはあります。ですがここでは、Web系企業の社内SEに共通した役割と特徴について述べることにします。

Web系企業の社内SEは、基本的に自社サービス開発者であるという点において共通しています。つまり、自社の事業目的・事業戦略に見合った自社オリジナルのサービスやプロダクトをつくるということです。

例えば、EC系であれば、ユーザーがいかに使いやすく、しかもトラブルなく買い物ができるかということを前提に、フレンドリーなインターフェイスから確実な取り引き決済までを遅滞なく可能にするトータルなシステム構築をめざします。

そのためには、自社ビジネスの事業目的や事業戦略を明確に認識し、それらを反映したサービス・システムをつくべく、開発の上流工程である企画段階から業務に携わることが一般的です。そして、設計から実装・リリース・運用・メンテナンスといった下流工程に至るまで、システム構築における複数の工程にかかわることも少なくありません(企業規模や企業風土によって事情はいくらか異なりますが)。その意味では、一つの会社で腰をすえてじっくり仕事に打ち込みたいタイプのSEには、向いている業務だと言えます(社内事情が許せば、スケジュール管理も担当者の責任である程度は斟酌できます)。

そもそも事業目的の戦略的意味を把握して上流工程から開発に臨んでいますから、責任をもって自ら手がけた運用中の自社サービスをどのように進化・成長させるかという課題は、社内SEの頭の中で常に渦巻いているはずです。

すると、エンジニアとしての技術情報やスキルだけでなく、社内外のさまざまな情報キャッチアップ、あるいはユーザー情報の取り込みなど、オールジャンルの情報にセンサーを働かせ、ときには社内コミュニケーションを活性化させながら、常に現状の自社サービスに更新をかけていく(つまり進化・成長させていく)という業務がいつの間にかルーティンとして発生しいていきます。この段階になるともう、社内SEにおけるIT担当のエンジニアとしての意味は限定できなくなります。自社Webの運営からWebマーケティングの分野にまで、仕事の守備範囲が拡大していくことになるからです。

ひょっとしたら、このような事態を好むか好まないかによって、Web系企業の社内SEの適性が見えてくるかもしれません。つまり、自社システムの成長・進化を手がけるに伴い、エンジニアとしての成長だけでなく、ビジネススキルやコミュニケーションスキルも手に入れ、プロのビジネスマンとしての成長を喜びとすることができるかどうか、これがWeb系企業の社内SEを選択する際の重要な判断基準になるわけです。

最後に一言。

Web系企業の社内SEにとって、次々と生み出されている開発言語のスキル向上はきわめて重要です。Web系の自社サービス開発で必要とされる開発言語は、主として、Java、Ruby、Perl、PHPのほか、Linux、MySQLなど。どの開発言語を使うかによって、そのSEの個性やンスが表現されることに通じるので、使用言語への研鑽は社内SEにとっては必須と言えます。

●病院の社内SE

医療現場の社内SEについて少し記します。

最近は病院にも多様な情報システムが導入されるようになっています。

高度な技術をかたまりである医療機器と医師のPCとを無線LANでつなげたり、カルテ情報を電子化したり、レセプト(受付)業務などの医療事務のペーパーレス化を図ったり、あるいはホームページを作成して各専門医療部門のガイダンスを行ったりと、院内の光景はIT化によって様変わりしています。

医師による診断情報の判断迅速化、医療事務の合理化・効率化(例えば待ち時間を短縮すること)、医療機関とユーザー(患者)とのリレーションシップ促進などがその目的ですが、その背景にあるのは医療現場をできるだけユーザーや社会に近づけるという社会的ニーズです。

一方で、病院が扱う情報の中には、膨大な量の個人情報が含まれているため、院内システムに強力なキュリティ機能を持たせることがきわめて重要な課題の一つとなります。そのために、外部ベンダーに開発依頼をするのではなく、院内ですべてのシステム構築を完結させることが必要となり、セキュリティ技術に精通した社内(院内)SEが強く求められるわけです。

病院のIT導入に臨む際、最初に注意しなければならないのは、環境や使用ソフト、プログラムなどに仕様のバラつきがあることが多い、ということです。また、現状で設置してある医療機器によっては、院内ネットワークにつながりにくいものがないとは言えません。病院サイドのニーズによっては、ハード、ソフトにかかわらず、かなりの個別システムや機器類をリプレイスしなければならない場合もありえます。

そうなると、合理性・信頼性の高い、しかもセキュリティのしっかりしたシステムをつくり上げるためには、確実な予算管理が必要になってきます。もちろんこの問題は、病院の規模や業務レベル・予算レベル(ときには病院経営者の経営能力)によっても異なってきますが、社内(院内)SEにとっては避けて通れない業務マターの一つです。

要するに、病院などの医療機関に従事する社内(院内)SEは、純粋にエンジニアとして業務をこなすと同時に、ITに疎いかもしれない院内関係者との折衝能力も含め、さまざまな部門とのコミュニケーション能力が不可欠ということです。これはどの業界のSEでも多かれ少なかれ必要となる能力かしれませんが、病院という世界には医師を中心とした特有の文化があることも心得ておく必要がありそうです。

・自社サービス開発と受託開発の違いとは?

「Web系企業の社内SE」の項目で触れましたが、自社サービス開発とは、自社の事業目的・事業戦略に見合った自社オリジナルのサービスやプロダクトをつくり上げることを言います。

それに対して、他社からの依頼・受注によってその会社のためのシステムをつくるのが、受託ビジネスです。

要は、自社のためにつくるか、他社のためにつくるかの違いです。

しかし、それだけの違いが、その仕事の仕方やエンジニアとしてのマインドの違いに大きく影響してくるのです。

ちなみに、受託開発を行う企業を“SIer”(エスアイアー:System Integrator)と言います。

◇「会社の視点」で考える自社サービス開発、「クライアントの視点」で考える受託開発

当たり前のことですが、自社サービス開発では、スタート段階の企画、つまり「どのようなシステムをつくるか?」というメインテーマ(主題)は、SE自身が自前で考えなければなりません(もちろん開発スケジュールや予算の見積もりも、SEのマターです)。

しかし、この「自前で考える」ということの本質的な中身は、意外に単純ではないのです。

基本的に、次に挙げる3つの客観的な視点から発想しなければ、自社オリジナルのサービス開発としてはおそらくうまくいかないでしょう。

◎ユーザーの視点
ユーザーの「使いやすさ」とは、どういうものか?
◎会社の視点
どのようなサービスの提供であれば、利益を生み出せるか?
◎エンジニアの視点
わかりやすい実装、やりやすいメンテナンス、発展的な更新のために、何をどうしたらよいか?

それぞれに最適な“解”を求めていくための思考が、まさに「自前で考える」という基本姿勢につながります。これは、独りよがりな開発プロセスに陥らないための鉄則でもあります。

では、受託開発の場合はどうでしょう。

何よりも違うのは、受託開発では、「どのようなシステムをつくるか?」という基本的な主題をはじめ、予算(概算)もスケジュールも、発注者であるクライアント(他社=お客様)からもたらされるということです。つまりこの段階での案件は「自前」ではありません。

しかし、この「自前」ではない案件を請け負ったのち、SEとして「自前」の思考が働かないのなら、SE失格と言っていいでしょう。

というのも、上記の「ユーザーの視点」「会社の視点」「エンジニアの視点」という3つの客観的な視点は、受託開発においても必要不可欠なものだからです。もっとも、この場合、「会社の視点」というのは「クライアントの視点」(つまりクライアントの利益)に置き換えられることになります。

ただし、クライアントの予算とスケジュールには制限がありますから、「クライアントの視点」でその利益を考えることは、自社サービス開発の場合とは異なります。

自社サービス開発であれば、自社の利益を最大化するための予算とスケジュールは、必要なら社内の承認を経て増やしていくことも考えられますが、受託開発ではそう簡単にはいきません。

開発途上でクライアントとの折衝による必然的な変更があれば別ですが、予算内、スケジュール内に開発作業を完了させるということは、受託開発おいて受注者の最低限のモラルだからです。

いずれにせよ、変更がない限り、予算とスケジュールの範囲内で、「クライアントの視点」を持って開発業務に勤しむことは、SEとしては外せないのです。

ただ、一般的に言えることですが、受託開発のケースでは、開発地上での開発費(経費等)のコミット(相談)はありえますが、開発したプロダクトが生み出すクライアント側の最終的な利益へのコミットは、必要においても資格においても、受注者側にはありません(それはクライアント側の経営の問題です)。

しかしここで言いたかったのは、受託開発のSEとしては、クライアントの利益になるようなサービスを提供したいという、「クライアントの視点」で開発を進めるマインドは必要だということです。

◇どちらにしても“御意見番”や“批判者”の声に耳を傾ける

自社サービス開発のSEは、開発の上流工程である企画段階から業務に携わることが一般的だと、以前に述べました。

上流に位置するこの企画からスタートし、設計・プログラミング等を経て運用・保守といった下流工程に至るまで、自社システムを育てていくファーズのほとんど(全体の場合もある)に係ることが多いわけですが、当然のことながら、開発SEがすべて一人で完結させるわけではありません。

これら複数の工程を担当する間に、一緒に開発を分担するSE、ユーザーと直接向き合う営業チーム、時として経営陣など、さまざまな「他者」とコミットし、コミュニケーションを重ねていく必要があります。

つまり、自社開発であっても、社内のチームメンバーや協力者、時には“御意見番”や“批判者”となるような人たちの声にも耳を傾けながら、彼らが発する意見や批判に耐えうる自社サービスやプロダクトに育てていかなければならないのです。

考えて見れば当たり前のことです。自社サービスというプロダクトは、自社の事業目的や事業戦略を反映させ、確実に自社の利益になるシステムでなければならないのですから、自社の利益を最大化できるサービス開発はSEにとっての至上命題と言っていいものです。

もし、その自社プロダクトが、会社の存亡を左右するほどの自社サービス開発だとすれば、責任意識の強い社内SEであればなおさらのこと、社内の多様な意見・批判に耳を傾けることの重要性は心得ているはずです。

受託開発では、担当するSEがクライアント先に出向いて開発をスタートさせることがほとんどです。必要があればその都度、クライアントの発注責任者と折衝を重ねるわけですが、基本的に「お客様は神様」であるとしても、受注者として開発の責任にコミットするSEである以上、自分から提案することが必要になることもあります。SEの頭の中では、「クライアントの視点」と同時に、「ユーザーの視点」「エンジニアの視点」が常に発動しているからです。

ただ、クライアント側の責任者のキャラクターもさまざまで、忌憚のない“御意見番”や率直な“批判者”としての立ち振舞がお好きな方がいないとは言えません。その方の発する言葉の中から、「ユーザの視点」や「エンジニアの視点」に立って意味あるものを読み解き、開発に有効な論点を見出すことも、受託開発SEの資質として必要だと言っていいでしょう。

言葉を交わし、交渉し、取り引きをする相手は大人のビジネスマンであり、他社の人間であっても開発プロセスと時間を共有するチームの一員にほかなりません。そこに自社-他社の意識の壁をつくらなければ(相手はともかく、少なくとも自分からは)、クライアントの言葉もまた開発途上のシステムを育てていくために必須の要件であることを発見できるでしょう。

SEが相手にするのは、単にシステムというモノではなく、システム開発に携わるすべての関係者、つまり人だということ。その事実に気づくことによって、SEは、単に技術の専門家としてだけでなく、社会的な作法を身につけたビジネスマンとして成長していくことができるかもしれません。

◇社内IT環境整備という仕事

自社サービス開発の対象は、自社オリジナルのITサービスを開発する業務ですが、これとやや似た言葉に、社内IT環境整備があります。

これは、ITシステムに係る社内インフラの整備を行う業務のことです。

繰り返しになりますが、自社サービス開発は、自社で開発する自社のためのオリジナルサービス、つまりソフト系のシステム開発です。

これに対して、社内IT環境整備は、一つの会社の中でITシステムを円滑に利用するためのインフラツールを整備する、つまりハード系に近いインフラ環境やIT関連設備を調整する業務です。

同じ「社内」という言葉を冠していますが、このような社内IT環境の整備業務は、企業インフラ整備やオフィス環境整備支援を専門とする企業にアウトソーシングするのが一般的です。この業務を自社内で行うとすれば、総務部門に属し、インフラの保守・管理を専門とするサービスエンジニア(こちらもSEです)の仕事になります。

もちろん、IT環境整備である以上、企業内のネットワーク構築やIT運用管理、ITヘルプデスクなど、使われている既存システムのソフト面に触れる作業はいくらか生じます。しかし、既存の社内ITインフラの環境整備を行う場合、部分的にソフト面に触れることはあっても、全体システムの変更や更新に至ることはごく稀です。

新規に社内インフラとしてのIT環境を整備する場合には、社内のITインフラ整備の担当者(社内SE)が発注責任者となり、アウトソソーシング先であるオフィス環境整備支援会社などのSEとともに、オフィスのIT環境をトータルなシステムとしてつくっていくことになります。

2.社内SEへの転職に必要なスキル・経験

・エンジニアとして必要なスキルは?

ある程度の社会年齢に見合うSEとしての経験が、スキルレベルの判断指標

転職の際、どのようなスキルを持っていれば社内SEとして評価されるのか? これは確かに気になるポイントでしょう。

このスキルレベルの問題は、どのような人材観を持った会社か、あるいは、どのような組織構成を持った会社かよっても異なってきますが、ある程度の社会年齢に見合うSEとしての経験を一つの指標とする企業は多いと言えます。

社内SEとしてのスキル評価は、一般に、エンジニアとしての技術スキルのレベルはもちろん、コミュニケーション能力を基本とするビジネススキル、あるいは、より多くの社会経験を積むことによって培われるヒューマンスキルなど、いくつかの要素によって判断されると言っていいでしょう。

通常、これらのスキルレベルは、システム解蓮の下流工程や現場実務を任されることが多いメンバークラス(若手)、そして社内SEとしてチームを率いるレベルのスキルを持つリーダークラス(中堅)、さらには開発プロジェクトなどの組織経営を担うことができるマネージャークラス(ベテラン)へと、上流工程に行くにしたがって、その要求レベルは上がっていく傾向にあると考えられます。

以下、それぞれに求められるスキルイメージの概要を示しておきます。

▼メンバークラスに求められるスキルイメージ

◇技術スキル

具体的な実装や運用現場での実務を任されることが多い若手にとって、今後、社内SEとして成長していくための基本的なテクニカルスキルは必須です。得意ジャンルがあることはよいことですが、むしろ “広く浅く”、一通りの基礎技術を持ち併せている方が評価は高いかもしれません。

⇒Web・オープン系技術、ネットワークやサーバーの構築経験、データベースやERPの経験、システム運用のサポート経験など。

◇ビジネススキル

自分以外の人間の話に耳を傾けることができるか、自分の意見は明確かつ合理的に説明できるかといった、基本的なコミュニケーション能力があれば問題ありません。若手ですから、そのポテンシャルがあれば、成長の余地はあると見らます。

◇ヒューマンスキル

自主的に行動できるか、未知の物事に対する探究心や自分を成長させようと思う向上心を持っているかなどというような、その個人の成長のポテンシャルを評価するのが一般的です。また、開発業務はチームワークによって成り立ちますから、人としての協調性が求められることも多いようです。

▼リーダークラスに求められるスキルイメージ

◇技術スキル

経験した業務によってどのような知識と技術力を蓄積してきたか、そのバランスはどうか、また技術的な強み、得意技術は何かといったことが判断されます。

⇒システム開発や運用経験によって得られた技術レベル全般、ERPやミドルウェアの導入経験など。

◇ビジネススキル

より高いコミュニケーション能力とともに、実際のチームリーダー経験から学んだチーム経営の見識、あるいは、どのような業務知識に精通しているかといった経験知が評価の対象になります。

◇ヒューマンスキル

開発現場のさまざまな声に傾聴できる力、若手をリードし教育できる能力、チーム組織やシステムの改善・更新・変革への意欲の高さなどが求められます。

▼マネージャークラスに求められるスキルイメージ

◇技術スキル

実装で必要となる個々の技術力よりも、開発の上流から下流までを通して経験してきた実績に根ざす、組織運営力やマネジメント力などが評価対象となります。

◇ビジネススキル

求められるのは、豊富な業務知識、システム開発の経験をベースにした企画力・提案力・組織運営能力などです。社内の意見・意向を調整することはもちろん、外部や他社での交渉力・折衝能力も必須です。

◇ヒューマンスキル

社内各部門との関係調整能力が高く、システム問題であれ人の問題であれ、常に全体を最適化していける判断力が要求されます。プロとしてのビジネスマインドを持ち、プロとしての行動力が発揮できる人材であることが求められるでしょう。

●社内SEのマインドとして必要な「聞く」ということ

ここで、スキルというより、社内SEの仕事を継続するために欠かせないマインドについて触れます。これはどのクラスにも共通する社内SEの基本姿勢にかかわるものです。

ここでは特に、コミュニケーションスキルの「聞く」という側面を強調しておきたいと思います。

どんな相手の言い分にも耳を傾けられるかどうかといえば、なかなかむずかしいと感じる人は多いでしょう。そこでこの「聞く」姿勢を培うために、自分が置かれた状況での「周辺領域」に対する探究心や好奇心の視点から捉えてみたいと思います。

例えばこんなことがあるかもしれません。

社内で会計システムを開発することになって、経理部門の人にヒヤリングをする必要が生じたとします。その場合、簿記について何の知識もなければ、相手の話はチンプンカンプンでしょう。そもそも貸借対照表とは何か、損益計算の仕組みはどうなっているかなど、技術的知識を習得してきただけの人間には、一見自分とは何ら関係ない「周辺情報」にすぎないと思うかもしれません。

しかし社内SEとしては、どのようなシ社内システムの開発を依頼されても必ず対応できるSEとしての姿勢が必要なのです。

とは言うものの、自分が置かれた状況においてどんな知識が必要になるのかは、その時になってみないとわかるものではありません。とするなら、その企業の社内SEとして働き続ける以上、自社のあらゆる業務、あらゆる商品・サービスについての知識・情報に対して、常日ごろから強くセンサーを働かせておく必要があるのではないでしょうか。

つまり、社内SEとして成長していくためには、技術スキル向上のための探究心・好奇心と同様に、自分が係わりを持つ可能性のある自社情報・業務知識などについては、貪欲な探究心・好奇心を持つことが大切なのです。

●社内SEにとって、すべての社員は「お客様」

「聞く」という視点に関連して、もう一つ重要なことがあります。

豊富な技術的知識を持ち、スキルも高いと自認するエンジニアが陥りやすいことの一つに、不必要なプライドを露出してしまうということです。

社内SEは社内のさまざまな部門でさまざまな人たちと接点を持ちます。先ほどの例のように、会計システムを開発する場合には、経理部門の担当者とのヒヤリングから開発業務をスタートすることがあるかもしれません。その際、簿記などの会計知識についてはプロである経理担当者も、当然のことですが、システム技術に関しては素人です。

そこで心得ておかなければならないのは、その経理システムが完成した後に、その経理担当者はユーザーとなるということです。つまり、その人は同じ会社の社員だとしても、システムを開発する社内SEにとっては「お客様」なのです。

ということは、「お客様」のどんな要望にもまずは傾聴する姿勢が重要でしょう。技術においては素人の「お客様」を、どのような意味においても見下したり、聞く耳を拒絶したりする気持ちを持ってはならないのです。

特に若手の時代に、ヘルプデスクなどの業務で、パソコンなどのデジタル機器の不具合を改善したり、メンテナンスに駆りだされて、技術知識に疎い社員との間でストレスを感じてしまう社内SEがいるかもしれません。また、前職で受託開発会社(SIer)のSEを経験して社内SEに転職してきた人は、かつて社外の顧客(素人)には「お客様」として丁寧に対応できたのに、同じ会社の社員の素人との会話では、SEとしてのプライドを捨てきれないまま相手に違和感を感じ続けてしまうということがあるようです。

しかし考えてみれば、社内SEにとって、実は自分以外のすべての社員は「お客様」なのです。

とすれば、つまらないプライドは捨てて、どんな相手とも、どんな仕事でも、すべて「ウエルカム」というマインドで臨む方が、ビジネスの現場を心地よく体験できるのではないでしょうか。

そのような懐深い姿勢を取れることこそが、むしろ、プロとしての本当のプライドというものです。

3.クライアント対応に疲れた?社内SEに転職した理由

●SIerから社内SEに転職したくなる理由を整理すると…

社内SEへ転職したいという希望や展望には、現在自分が在籍する受注開発型企業=SIerとの比較が働いています。

つまり、「社内SEに転職すれば、今のSIerよりも◯◯がよくなるのではないか?」ということです。この「◯◯」には、現状よりもポジティブなもの(こと)が入るのは言うまでもありません。

そのおおまかなところを整理してみると、次のようなものが典型例として考えられます。

  1. 残業が少なくなるのではないか?
  2. 技術スキル、ビジネススキルが多角的・実践的に習得できるのではないか?
  3. 現状よりも上流工程の業務に携わることができるのではないか?
  4. ユーザーとの距離が縮まり、自分の仕事の評価を身近に知ることができるのではないか?
  5. 給与も労働環境も良くなるのではないか?

1.と5.は、いわゆる「条件」の問題です。一般に受託開発のSIerの場合、下流工程に行くに従って給与も労働条件も厳しくなるということがあります。とすれば、社内SEへ転職して生活条件をよくしたいと思うのは当然かもしれません。

2.〜4.については、SEとしての「仕事のやりがい」に係る課題です。SEという職能を選択した以上、自らあのスキルを磨き、仕事にやりがいを感じ、エンジニアとして、あるいはビジネスマンとして大きく成長していきたいと思う心情は、誰にでもあるものです。

社内SEへの転職理由をもっと細かく言えば、まだまだあるかもしれません。

例えば、SIerは社内SEに比べてストレスが高いとか、自分で裁量できる仕事の範囲が狭すぎる、スケジュールや予算設定が厳しすぎるとか、わがままなクライアントが多いとか、周囲のエンジニアはオタクだらけとか、あるいは収入が少ないとか……。

では、なぜこのような転職理由がSIerのSEには共通して見られるのでしょうか?

●SIerから転職したくなる背景に、IT業界のヒエラルキー構造が

SIerから社内SEへの転職理由を考える上で、SIer業界が背負っている一つの“構造”があることを知っておいてもいいように思います。この“構造”を理解すれば、SIerからの転職理由の真相が見えてくるからです。

それは、受託開発型であるSIerの多くは、いわゆる“ITゼネコン”と呼ばれる大手ITベンダーを元請けとして、下請け、孫請けというヒエラルキーをもった産業構造の中でIT関連の開発ビジネスが回っているという事実です。

大手ITベンダーは、大手企業などの顧客から案件を受注し、その開発実務をSIerに下請け、孫請けの形で発注するのです。

通常、大手ITベンダーの担当者が開発プロジェクト全体のリーダーとなり、その下の複数のSIerにシステムの特定部分(サブシステム)が発注されます。このサブシステムの受注において、今度は各SIerが複数の(1社の場合もあり)孫請けのSIerに開発実務を振り分けるのです。

ただ、開発実務とは言っても、孫請けのSIerには、プログラミングやテスト、メンテナンスなどの下流工程ばかりが発注されることも少なくありません。発注元の顧客との打ち合わせには、大手ITベンダーの担当者とともに下請けSIerに出向きますが、孫請けSIerが顧客と面談できる機会はあまりありません。

少し想像がついてきたかもしれませんが、このようなヒエラルキーを持つ産業構造の中では、発言権の弱い中小の下請けや孫請けのSEは、発注された範囲内で自分の単発の技術を発揮するだけのケースが多いので、SEとしてマネジメントスキルを学び、ビジネスマンとして成長するチャンスを奪われていると言っていいでしょう。この事態は孫請け会社のSEにおいて顕著です。

技術的なスキルアップに関しては、下請け段階のSIerであれば、受注案件に多様な技術要素が絡んでくることが多いので、現場で実践的に学ぶことができます。多くの場合、チームで取り組むことになりますから、お互いの技術知識を交流させるということを通して、自らの技術レベルを上げていけるのです。

ただ、下請け段階のSIerで可能な技術のスキルアップも、孫請け以下になるとむずかしいかもしれません。特定された下流工程の部分的な受注が多いからです。そうなると、独学や勉強会などで技術知識を蓄えていくしか道がなくなります。

下請けの中には比較的大手(東証第一部上場)のSIerもあります。しかしそのレベルのSIerであっても、下請けという立場で、元請けと孫請けの人間関係の板挟みにあって、ストレスを増大させてしまうリーダークラスやマネジャークラスのSEもいます。

上下の人間関係ばかりでなく、スケジュール管理、予算管理などにおいては、そのストレスも相当なレベルに及ぶでしょう。特にスケジュール管理に関しては、ヒエラルキー上位の会社に比べ、下位の会社にその抑圧が過度にかかってくることも普通です。孫請け以下のSIerに残業が増えてしまうのも、この問題の影響が大きいと言えます。

また収入面でも、このヒエラルキー構造による影響は小さくありません。元請けから下請け・孫請けに受注が降りてくるに従い、中間マージンが発生し、下位に行くほど受注費が低く抑えられてしまうからです。

このようなヒエラルキー構造の下位にあるSIerで長年働いていると、転職マーケットでSEとしての自分の価値も下がってしまうのではないかという不安がよぎることもあるでしょう。

SEとしてより高度な技術スキルを育み、プロのSEとしての成長を望むうえでも、また給与や労働環境をよくしていきたいという生活上の展望のうえでも、受託開発会社が抱える構造から脱したいと考えることはしごく自然なことです。

●SIerから社内SEへの転職理由が消える日

社内SEへの転職理由を述べるために、その背景にある受託開発(SIer)のネガティブな構造的問題をピックアップしすぎたようですが、必ずしもすべてのSIerのSEがこのような悪条件の中に置かれているわけではありません。

風通しのよい企業風土とフラットな組織構成を持つ元請け=大手ITベンダーは、競争力のある下請けに対するパートナーシップをしっかりと結び、 “発注-受注”関係の古い慣習を改めようとする傾向にあります(ただし、孫請けとの関係はまだ旧態依然のものが多いかもしれません)。

その背景には、自社ビジネスでシステムをどのように活かすかという視点から、社内SEによる自社開発型のIT企業が増え始めているという事情があります。これまで受託中心だったSIerもこの自社開発型のIT企業との関係に着目するようになっているため、大手ITベンダー側もこれまでの“受注-発注”構造を考えなおさなければならなくなっているのです。

このように変化しつつあるIT業界の文脈の中で、比較的大きなSIer、あるいはベンチャー性のある自社開発型のシステム開発会社は、受託開発と自発開発とのバランスを取りながら、新たな展開をしています。すなわち、受託開発で一定の受注を獲得しながら、その利益によって自社開発を進めていくというビジネスサイクルです。

このビジネスサイクルでは、これまでの受託開発型のSIerが、自社開発事業へと少しずつ軸足をシフトしていくことによって、大手ITベンダーとのこれまでの“受注-発注”関係だけに依存することのない業態へと変わっていくことが可能になります。

こうなると、受託開発型のSIerで働くSEが社内SEへ転職する理由もなくなってしまいます。本来は受託開発であった同じ会社内にいながらにして、社内SEとしての仕事もできるからです。

もちろん、大手ITベンダーとの関係改善の機運に乗りながら、従来通り受託開発を行っているSIerはまだまだたくさんあります。そこで見られるのは、改善されつつあるといえども少なからず存在するストレスの要因(つまり転職理由)を抱えながら、そのストレスをむしろ自己成長のバネとして努力を重ねているSEたちの姿です。

もちろん、それらのSEたちの個別の転職欲求は、現状においては尊重されなければなりません。

しかし、近年増え始めている自社開発型やベンチャー性の強いIT企業が新しいIT技術をキャッチアップし、さらにその応用によってより優れた自社サービスやオリジナルプロダクトを数多く世に出していく光景が増えていけば、多くの受託開発型SIerのSEたちも、少しずつでも自社開発型のITビジネスを創造することに手を染めていく状況が生まれるかもしれません。

その先に、この国の大型システムの開発受注をほぼ専有している大手ITベンダーの発注構造に変化をもたらす可能性が見えてくるでしょう。

4.社内SEへの転職失敗例

確かに、事前に転職先の実情を知るということはむずかしいものです。

転職前に情報を掘り下げたり、キャリアアドバイザーに相談したり、面接でも相手から念入りに情報を得ようとしたりと、事前の情報収集の努力には誰でもが用意周到になっていたはずです。

ところが、実際に転職してみると、求めていたものとは違う、何か「落差」を感じてしまう──。

しかし、どうでしょう。逆に、転職後の職場に「完全な満足」というものがあるのかどうか。

そこで、上の項目(社内SEに転職した理由)で列挙した5つの典型的な転職理由を前提にして、いくつかのケースを見てみましょう。繰り返しになりますが、もう一度確認のために記しておきます。

  1. 残業が少なくなるのではないか?
  2. 技術スキル、ビジネススキルが多角的・実践的に習得できるのではないか?
  3. 現状よりも上流工程の業務に携わることができるのではないか?
  4. ユーザーとの距離が縮まり、自分の仕事の評価を身近に知ることができるのではないか?
  5. 給与も労働環境も良くなるのではないか?

▼まずは残業問題。

社内SEなら残業がない、あるいは格段に少ないだろうと考えていたとしたら、それは想定そのものが間違っていたのではないでしょうか。

「残業を極力しない」という社内ルールを決めている会社も増えていますが、そのような文化を社員間で共有できている会社はまだまだ少ないでしょう。状況によって残業するしかないというケースは、どの会社にも普通にあります。

もし、現状の仕事が好きで、しかも面白いと感じていたら、残業のことなど気にもかけないでしょう。そもそもやりがいを感じている仕事は、知らず知らずに“オーバーアチーブ”になってしまうものです。寝食を忘れて打ち込める仕事であれば、残業を残業と感じることすらないはずです。

もし残業を苦痛だと感じ始めていたら、それはむしろ、その仕事やその周辺に何か別の問題を感じているせいではないでしょうか? 例えば、上記の5つの転職理由のうちの1.以外のどれかです。

または、転職先の社内事情の問題も考えられます。配属部署の人員が少なすぎるとか、チームメンバー同士の仕事配分に問題があるとか、チームリーダーのスケジュール管理がスムーズでないとか…。

もしこれらに問題があって、その改善に問題意識を感じるなら、プロのSEとして前向きに改善提案を出してみるという方法もあるはずです。

もしそのような積極的な改善策を示せないのなら、ある程度の諦めの気持ちを持って、要領よくやる技を身につけるしかないでしょう。

しかしそんな状態が日常化していけば、他の誰かに残業のツケが回ってしまい、結局、自分のためにもならず、会社やチームにとっても何の改善にもなりません。会社組織やチームを自分のよき職場と感じることができないまま、残業の苦痛だけが残ることになります。

そうなったら、また転職を考えますか? それは愚かな繰り返しではないでしょうか?

ただし、仕事が好きで面白い、つまりやりがいがあると感じながら、あまりに過剰な残業を強いられた結果、過労で倒れてしまったのでは本末転倒です。

そのような状況になるまで残業が増えてしまっているとしてら、それはやはりその会社の組織や労務管理に問題があるに違いありません。上長や経営レベル(組合があれば組合)に相談して、何らかの改善要求をだす必要があります。

もっとも、過労で倒れたフリをして休養をとり、もう一度自分の将来について考え直す時間をつくってみるという方法もあります。これは、自分を自ら防衛するための、ある種の“緊急避難”です。

▼給与が上がらない

「転職してやりがいのある仕事に出会ったが、収入がなかなか上がらない」という声もよく聞きます。

しかし、転職して1〜2年しか経っていない段階なら、まだそれを失敗と判断するのは早すぎます。

しかも「やりがいのある仕事に出会った」という事実があるのなら、現状ではその仕事に誠実に勤しむことが何より肝要だと思われます。仕事に打ち込むその姿こそ、SEの会社における“評価価値”につながるからです。ですから、自分の給与レベルについては、焦って判断すべきではありません。

世の中の経済状況にもよりますし、会社の規模や供与体系にもよりますが、自社開発型の社内SEの場合、SEの基本給はそれほど高くない反面、ボーナスの水準が高く設定されています。やりがいのある仕事に注力できているのなら(何という幸運でしょう!)、ボーナスに期待するという手もあります。

▼予想したスキルアップもキャリアアップも望めない

例えば、「前職よりも明らかに給与・待遇がいいいう理由で転職してみると、自分と同じような年齢の転職者ばかりの職場だった」などというケースがあります。

一見、同じような境遇の仲間たちと一緒に仕事ができるので、気持ちがラクだと思いきや、実はとんでもない落とし穴が待ち受けていることがあります。

というのも、「即戦力!」と称して中途採用者ばかりを集める企業の中には、中途採用者が前職で培ってきた多様なスキルを吐き出させることを主たる目的とする企業があります。新卒採用者を教育するためには膨大な費用がかかるので、その教育研修コストを削減するためです。

そのような企業では(悪質な場合)、スキルや経験の蓄えがある中途採用SEでも、小さなチームのリーダークラス程度にはしますが、グループリーダーなどの責任ある地位には就けさせません。

スキルも高く、経験も豊かな中途採用者は、転職後に、ある程度責任のある上流工程のリーダーになれる可能性を想定していることが多いのですが、このタイプの企業では、その期待を裏切ることがあるのです(もっとも、この点は転職前に確認が必要なのですが)。

また、ことあるごとに、企画や提案書を提出させるのですが、そこに記された技術情報をファイルすることがあっても、その企画や提案が実を結ぶことが少ないのです。

こうなると、開発現場でSE同士が真摯に交わりながらお互いのスキルを磨き合うなどという職場には程遠いかもしれません。SEとしてのスキルアップなど望めないと考えてしまうのも仕方がないでしょう。

こういう会社は、確かに経営者の資質や社風に問題があります。しかし、一度転職した以上、単に自分の経験やスキルを吐き出すだけでは、転職の際に費やしたエネルギーが無駄になってしまいます。

この場合も、ある程度自分のスキルと経験を披露することを“復習”や“棚卸し”だと考え、その後に自分の扱いがどうなるかもうしばらく様子を見てみることをお勧めします。

中途採用SEばかりの職場だとすれば、自分と同じように感じているSEも多いはず。誠実で率直なコミュニケーションの取れる仲間と情報交換をしながら、長期的展望をもって自分たちのスキルアップの方法や働き方を地道に探究していくことが大切でしょう。

また、社内だけでなく、社外にも自前のネットワークを張りめぐらし、転職だけにでは得られないかもしれない自己成長の方法を事前に創っておくことも有効です。

●転職前にすべきことをどの程度したか?

少し視点を変えて、転職後のイメージ「落差」への対処法ではなく、転職前の問題に目を向けてみたいと思います。

転職先で求めていたものとは違う「落差」を感じる原因には、転職前の自分サイドに問題の所在があるかもしれないからです。転職動機そのものの、転職の準備やそのプロセス、そしてスキルレベルの自己評価・自己認識の正確さなどです。

「転職したいという人の話を聞くと、転職の動機を明確に語れない、いわば『なんとなく転職』のタイプの人が意外と多い」と、転職希望者に厳しい目を向けるキャリアアドバイザーもいます。確かに、そうであっては転職がうまくいくはずがありません。転職の本当の理由が自分に見えていないのですから。

しかも、「こんな会社がいい」、「こんなポジションなら自分の思い通りの仕事ができる」、「自分ほどのスキルレベルならマネージャークラスで採用するはずだ」などと、転職先での勝手な希望や条件イメージばかりが先行させて、転職しようとしている自己評価・自己認識に正確さが欠けている場合が少なくありません。

そうなると、例え運よく転職できた場合でも、時間経過とともに、転職した職場での「落差」の感覚が次第に強くなりはじめ、その結果、「この会社はダメだ」と、自分と会社のズレを会社側のせいにだけ負わせる“不幸な事態”に陥ってしまいます。そんなイメージ「落差」の強大化は、大人のビジネスマンがすることではありません。

しかし、こうした“不幸な事態”は、転職前に自己評価・自己認識を明確に行い、どういう会社(職場)において、どういう自分の状態であれば、自分の力を発揮できるかということを客観的に描き出し、その上で転職活動を始めることができていれば、かなりの程度、事前に防ぐことができます。

つまり、転職前の準備として、転職の動機を明確に整理し、正しい自己評価・自己認識のうえで、自分と先方が求める条件とのベストマッチングを図るということが必須の要件なのです。

もし、そんなこともできないのなら、もともと前職で本当にベストを尽くすビジネスマンだったかどうか、一度、心底振り返ってみる必要があるでしょう。転職後のイメージ「落差」をつくりだすのは、現在の自分のあり様なのかもしれません。

・管理能力、社内の調整能力が結構必要?

▼自信はあったのに、大手IT企業の面接で“憧れ”を語って失敗

社員50名の受託開発IT企業に勤めていたKさん(35歳)の転職失敗談です。

ネットワーク構築や監視・運用のプロジェクトを多数経験し、着実にキャリアを積んだ後、30歳直前に社員120名規模のSIerに転職。いくつかのチームリーダーとして活躍していましたが、開発の中身にやりがいを感じられる案件になかなか出会うことができず、自分のスキルアップのチャンスも頭打ちだと感じるようになっていました。

そこで再度の転職を考えていた矢先、著名な大手IT企業が自社開発部門の社内SEを大募集しているという情報を得ます。

自分には手の届かない存在だと思っていた大手企業の募集でしたが、採用年齢の条件もぴったりであるうえ、採用後には現職ではあまり経験していない上流工程のリーダークラスに就けるということだったので、早速、応募してみることにしたのです。

ところが、書類選考はスムーズに通ったものの、第一次面接で残念ながら不合格になってしまったのです。

しかし、落胆していたKさんには心当たりがありました。

これまでKさんが前職で培ってきたスキルは、先方の大手企業が期待するような、コンサルティングやシステム企画、要件定義など、最上流工程のビジネスを遂行するに足りるほどのレベルには達していないと判定されてしまったのです。

もちろん、Kさんに自分なりの自信がありました。そこそこの人数(30数名程度)のチームリーダーを何度も務め、現職では社内トップクラスの技術レベルの持ち主と評価され、近々、最年少のマネジャー候補かと言われていたKさんです。

しかし第一次面接の際、Kさんは、なぜか的確な自己アピールができず、残念な結果になってしまったのです。Kさんは反省の弁を述べます。

「先方が求めていたのは、マネジメントスキル、クリエイティビティ、あるいは顧客との折衝能力や問題解決能力という、本当に最上流を担当するにふさわしいスキルレベルです。あれほどの大手の採用担当者となれば、それらのスキルが私の中にあるかどうか、見抜く力がないわけがありません。おそらく私は、単に“憧れ”を語ってしまったのかもしれません。決して自分のスキルに自信がなかったわけではないのに、相手の大きさの前に、“背伸び”をしてしまったのだと思います」。

おそらく、その大手IT企業は、上流工程を担うだけの年齢にふさわしいキャリアが足りていない、あるいは、プロジェクト経験の規模が小さく、自分たちのような大手の規模では即戦力にはならないと判断した可能性があります。Kさんも、その点にフォーカスして自己アピールをつくしたはずなのですが、先方は、Kさんの言うように、彼の口調に“背伸び”を感じ取ってしまったのかもしれません。

先方が嗅ぎ分けたのは、Kさんの口調の中に存在した、経験レベルを過大に見せようとするある種の「落差」だったのです。

まさに一期一会の面接という大チャンスの瞬間には、自分の能力やスキルをどのように表現するかということそれ自体もまた、転職を考える人間にとって最重要のスキルだと言えそうです。

▼英語も得意なので外資系IT企業への転職だったが…

「前職では開発のチームリーダーを何度も経験して自信もついていました。英語も得意だったので、待遇のいい外資系に30代前半で転職したのですが、評価の仕方や本国との関係でなじめないことが多くて、結局2年足らずで日本企業に再転職しました」と語るのは、中堅どころの社内SEでマネジャーを務めるNさん(現在38歳)。

IT企業にかぎらず、外資系企業への転職の失敗例としては、失礼ながら、典型的なものと言っていいかもしれません。

基本は、企業文化・風土の違いからくる根深い違和感でしょう。Nさんが言う「評価の仕方」とは、日系企業では、社員の仕事ぶりやビジネスの経過までを人事評価の対象に入れることが普通ですが、外資系では結果だけにフォーカスします。当然のことながら、給与や昇進に関しても、完全成果主義。一人ひとり働き方の自由度は高いのですが、結果・成果への評価はスコブル付きの厳しさです。

働き方の自由度は高いと述べましたが、業務内容の領域とボーダーはキッチリと決められているので、日系企業のように部署間の垣根を越えて協力しあうということはそう簡単にはできません。他部門との協力関係をつくって仕事をする必要がある場合には、その部門の責任者にインパクトあるプレゼンを敢行し、明確な“Yes”をもらってからにしなければ、単なる越権行為とみなされます。

ただ、部門・部署の異動は比較的頻繁に(時として唐突に)実行されるので、現状の部門での成果が評価されれば、その先が異動したい責任者の承諾さえ取れれば、希望の部門での仕事が叶います。つまりその都度パフォーマンスを出していけいば、いろいろな職能を経験できるため、専門的な知識やビジネススキルを磨くことが可能です。

もう一つ、Nさんが言う「本国との関係」というのは、外資系企業の日本法人の場合の宿命のようなものかもしれません。本国のさまざまなやり方が、日本法人の企業としての自由度を制限することがあるのです。

社員個人個人の働き方の自由度はあっても、企業としては本国の決定事項や業務上のレギュレーション(規則)に従わなくてはならない場面が多く、本国との調整にも時間的ロスが生じることがあります。しかも、本国時間が優先されて会議などが行われるため、日本側の生活時間が乱されることすらあります。また、ある日突然、日本法人のトップが交代し、経営のスタイルや直属の上司までもが一夜にして変わっていたなどということも珍しくありません。

このような外資系企業の風土・文化の違いに対しては、いかに柔軟に対応するかということが基本になりますが、そのためには、その都度動揺しないように、予めさまざまな文化的「落差」を心得ておくほかはありません。

日系企業で技術的スキルや経験を培い、自信とビジネスポリシーをしっかり持ったビジネスマンであればあるほど、その強いポリシーが外資系企業のレギュレーションとぶつかりやすいと考えておいた方がいいでしょう。自分の前職までの経験知に自信をつけていたNさんが、外資系の風土になじめなかったのは、彼がむしろ自らのビジネスポリシーを自信とともに全面に押し出しすぎるキャラクターだったせいかもしれないのです。

5.社内SEに転職したいなら転職サイト&エージェントを活用しよう

・社内SEへの転職活動で利用価値が高いのは、転職サイト? それとも転職エージェント?

●転職サイトと転職エージェントを使い分ける

転職サイトには、広くあらゆる職種・職能を紹介する総合型のサイトもあれば、特定の職種や職能に特化した専門サイトもあります。このことは、転職を考えたことのある人にはごく常識的なことでしょう。

転職先や転職目的がすでに明確になっていれば、ほとんどのユーザーは特化型の転職サイトで自分の求めに応じた転職先の検索から始めるでしょう。また、特化型の転職サイトは、総合型サイトに比べ、特定企業や特定職種・職能の求人情報が豊富にあり、アドバイザーのコラムなど、参考になるサポート情報も多く掲載されているので、例えば社内SEといった特定職種について知りたいユーザーには大きな助けになるはずです。

ここで一つ確認しておきたいことは、転職サイトとは別に、転職エージェントという人材紹介サイトのことです。

概要を言えば、転職サイトでは、自分でそのサイト内に掲載されている求人情報を検索し、自分でその求人企業への応募を進めていきます。

それに対して、転職エージェントでは、応募者に担当のアドバイザー(キャリアコンサルタント)が対応し、応募者とのやり取りの中で、求人企業への応募から面接までをアドバイスし、時にはさまざまにフォローしながら、公募者の転職活動を支援していきます。

要は、自分だけで行動するか(転職サイト)、アドバイザーに支えられて行動するか(転職エージェント)の違いです。

例えば、日系企業の社内SEの転職先情報を知りたければ、国内のIT企業に特化された転職専門サイトで検索することが考えられます。自分で国内IT企業の情報収集から始め、自分で転職活動を進めていくのなら、ここからスタートということになります。

しかし、外資系IT企業の社内SEの場合には、「外資系」に特化された転職サイトで「IT企業」へと検索を掘り下げ、「IT企業」に特化された転職サイトで「外資系」へと検索を掘り下げていくことになります。もちろん、どちらに特化されたサイトからでも、目的の求人情報を確認し、業務内容や条件が合えば、応募という段階に行くことができます。

しかし、IT企業への転職に場合、例えIT系や外資系に特化された転職サイトでも、そこに展開されている求人情報はあくまでもニュートラル(客観的)な公開情報であり、中には質の低い求人情報やモラルに欠ける企業(いわゆるブラック企業)の求人が混じっていないとは限りません。そこには、情報の質を自分で精査・判断しなければならないというむずかしさが残されます。

一般に、そのような特化型の転職サイトに掲載されていた求人情報が契機となって、例え面接まで漕ぎ着けたとしても、満足いく結果を得られる確率は必ずしも高くないというのが、とりわけSEをはじめとしたITエンジニアや技術系専門の(特に外資系の)転職サイトについての評価です(もちろん例外的な事例はあります)。

●転職エージェントは転職情報の精度を上げてくれる

そこで着目すべきなのが、転職エージェントです。

日本において「IT系」と「外資系」という二重に特化された転職情報を探索する場合には、転職エージェントを活用することがきわめて重要なのです。

転職エージェントを使うメリットを整理しておきます。

  • ◎ターゲット企業のより詳しい情報に出会える
  • ◎質の高い情報、しかも非公開の求人情報も入手できる
  • ◎アドバイザーの客観的視点で応募書類をチェックしてもらえる
  • ◎ターゲット企業に応じた面接対策が可能
  • ◎推薦状を書いてもらえる
  • ◎面接のスケジュールや条件の交渉・調整を仲介してもらえる

以上のメリットから見えてくることは、転職エージェントの役割は、「ターゲット企業に転職するための情報精度を上げること」だということです。とりわけ、ユーザーにとって大切な支援になるのは、ハードな求人情報だけでなく、アドバイザーとのやり取りによって必要なソフト情報が逐次提供されるということでしょう。

外資系IT企業への転職を扱うエージェントの場合、外資系のターゲット企業の風土や文化の違い、必要な言語(主に英語)レベル、本国にある本社との関係など、日本企業なら必要とはされない情報に関しても、ユーザーの問題意識に応じて、専門の担当アドバイザーから提供されます。また、非公開の求人情報が入手できるということは、通常の転職サイトにはない、転職エージェントならではの特徴とも言えます。

特にIT技術者や社内SEへの転職希望ユーザーにとって、単に入社そのものが目的というのではなく、入社後のキャリアをしっかりとつくっていくことが転職の真の目的のはずです。だとすれば、入社後にどのような仕事ができるか、どのようなスキルアップが可能かということに確実にフォーカスした情報を得るためには、転職エージェントの活用価値はきわめて高いと言うことができます。

日系企業の社内SEへの転職に関しても、転職サイトに比べれば、転職エージェントを利用するメリットはより高いでしょう。それは、外資系IT企業への転職と同様です。

ただ、自分のペースで転職先を探したいというタイプのユーザーには、転職サイトの方が向いていると言えます。求人情報を自由に閲覧できるということを考えれば、時間をかけてジックリ転職活動をしていきたいのであれば、転職サイトは大いに活用する価値があるでしょう。

・社内SE希望者におすすめの転職エージェント

これまで述べてきた社内SEへの転職という文脈から考えれば、ここで特化型転職サイトを紹介するよりも、外資系を含むIT企業に特化した転職エージェントを紹介する方が理に叶っていると思われます。そこで、以下にそのいくつかを挙げておきます。

必ずしもすべてがトップページからIT企業や外資系のみに特化されたサイト構成にはなっているわけではありませんが、社内SE向けの転職エージェントとしては優れたメリットを提供できるものばかりです。

◎リクルートエージェント

外資系転職に精通するグローバル専門コンサルタントが多数在籍する、業界トップクラスの転職エージェントです。

◎type転職エージェント

スキルや経験を評価されてキャリアアップしたい人には最適の転職エージェント。自社開発SEへの情報が豊富です。

◎マイナビエージェント×IT

IT特化部門なのピンポイント求人紹介が特徴で、希望転職者とターゲット企業のミスマッチが少ないことでも定評があります。

◎レバテックキャリア

IT業界でも特にWeb系に強い。非公開求人が多く、現場熟知のコンサルタントによるサポートや対応の即効性で知られており、フリーランスのSEにも好評。

◎Spring転職エージェント(旧:アデコ)

国内外資系だけでなく海外転職案件も豊富で、キャリアコンサルタントのサポートが懇切丁寧という評価の高いことにも特色があります。

◎JACリクルートメント

グローバルでハイキャリア案件に強いエージェント。キャリアに自信があり、あらゆるレベルアップに挑戦したいSEに向いています。

◎ワークポート

ゲーム業界のSE情報に強いエージェント。転職コンシェルジュと称するアドバイザーがジックリと誠実に支援してくれます。

年齢で選ぶ!年代別オススメ転職サイト一覧表

「どの転職サイトに登録すれば良いのかわからない」という方のために、年齢別におすすめ転職サイトをご紹介します。年齢によって適している転職サイトも違いますし、転職サイトはそれぞれ取り扱っている求人も違います。あなたに合った転職サイトを選ぶことが大切です。

GEEKLY(ギークリー)

  • 20代
  • 30代
  • 40代
  • 50代~

IT業界に特化した転職サイトで、特に多いのはWEB業界・ゲーム業界の求人。登録しないと見られない「非公開求人」が2,000件以上あるのでWEB・ゲーム業界の求人をチェックするなら登録必須。ITエンジニア経験が1年以上ある方にオススメ。

DODAITエンジニア転職

  • 20代
  • 30代
  • 40代
  • 50代~

ITエンジニアの転職に特化しているDODA ITエンジニア転職は全年齢がターゲットになっている転職サイト。転職者の満足度はNO.1。その理由は日本最大級のエンジニア求人情報数と取り扱い企業数にある。転職を考え始めたらまずはじめに登録をしておくべき。経験豊富なSE専門キャリアアドバイザーがカウンセリングから転職まで担当し、非公開求人の情報を個別に紹介してくれる。企業との強いリレーションがあるので企業側が求める人材を熟知していることが強み。推薦状を作成し、応募先企業へ送ってくれる点も魅力。

Forkwell

  • 20代
  • 30代
  • 40代
  • 50代~

大手の転職サイトのように一括送信されるスカウトメールではなく、本当に興味を持ってくれた企業からのスカウトメールを配信している点が大きな特徴。プロフィールは匿名で登録可能なので転職活動していることがほかの人に知られることはない。指定した企業の閲覧もブロック可能なので取引先など知られたくない企業。

レバテックキャリア

  • 20代
  • 30代
  • 40代
  • 50代~

1都3県のみ対応だが、元ITエンジニア出身の転職コンサルタントが転職支援をしてくれるので「エンジニア独特の悩み」をわかってくれる。エンジニアとして未経験の職種に転職する方から、同じ職種でキャリアアップを希望する方まで幅広くサポートしてくれる。大手・中小・ベンチャーなど幅広く求人を扱っており、エンジニアの求人を見たいなら必ず登録を。

ワークポート

  • 20代
  • 30代
  • 40代
  • 50代~

IT業界に強い転職サイトだが、IT以外の業界についても非常に詳しく求人もまんべんなく掲載されている。「エンジニアとしてのキャリアを検討しつつ、別の業界の話も聞いてみたい」なら登録をしておくこと。

リクナビNEXT

  • 20代
  • 30代
  • 40代
  • 50代~

全年齢がターゲットになっている転職王道サイト。転職成功者の8割が登録しており、求人情報数も日本最大級。IT案件に特化しているわけではないがIT案件の取扱数も多いので転職を考え始めたらまず始めに登録をしておくこと。職務経歴や転職希望条件などを匿名で登録するだけで、あなたに興味を持った 企業や転職エージェントから直接オファーが届く。転職エージェント(転職コンサルタント)がつかずに自分で求人情報を探すタイプなので、どんな求人があるか見たい人に適している。

関連記事

エンジニアの有利な転職~javaスキル歓迎はホントなのか!?

仕事の性質上長時間勤務やサービス残業を余儀なくされ、激務にあえぐことの多いITエンジニアやプログラマー。IT業界の経験を武器に、もっと待遇条件のいい企業へ転職したいといった希望を胸に秘めている人は多…

phpエンジニア必見!好条件の転職を実現するための戦略とは

「今の会社よりもよい労働条件で、年収の高い職場はないか?」 毎日ヒマさえあれば、求人情報を探している。そんなエンジニアの方は多いのではないでしょうか。あるいは仕事が多忙すぎて転職活動のた…

エンジニアの転職は年齢に厳しい?ホントのトコロ教えます!

エンジニアの世界で、まことしやかに語られる「35歳限界説」。キャリアアップのために転職を思い立ったとしても、これが脳裏にチラついて足枷となるケースがあると思われます。実際のところは、どうなのか。

20代後半までの行動が将来を決める!転職未経験のエンジニアへ贈る…

「自分のキャリアに不安がある。」「ずっと同じ職場でいいのだろうか? 」「ほかにもっと、身につけるスキルがあるんじゃないか?」「そろそろキャリアチェンジを考えるべき?」「転職すべきかどうかわからない…

エンジニアが転職するタイミングは?~実例に基づいて考えるベスト…

転職を希望しているけど、ベストなタイミングが分からない。しかも引っ込み思案で、優柔不断だから決断できない。 そんなふうに日々悩んでいるエンジニアの方々。できるだけ有利な条件で転職し、キャリ…

  1. Geekly(ギークリー)

    IT/WEB/ゲーム業界特化型で対応満足度NO.1

    • 業界特化型で対応満足度NO.1
    • IT・WEB・ゲーム業界転職を熟知
    • 業界トップレベルのコンサルタントがサポート
    • 求人票には載っていない詳しい企業情報を提供
    • Geekly独占の非公開求人も多数

    Geekly(ギークリー)の登録・詳細はこちら

  2. DODA ITエンジニア

    転職者満足度NO1業界トップクラスの求人数

    • DODA限定求人や非公開求人多数
    • 業界・職種、企業規模問わずさまざまな求人が豊富
    • 人事担当者、現場の責任者などと強いリレーション
    • 「転職者の希望条件」と「企業の条件」を的確にマッチング
    • 経験豊富な専門キャリアアドバイザーがカウンセリングから転職まで担当

    DODA(ITエンジニア)の登録・詳細はこちら

  3. Forkwell

    エンジニアのためのスカウトサービス

    • 一括送信ではないスカウトメール
    • 自分に興味のある企業がわかる
    • 登録するだけでスカウトメールが届く
    • 気になった企業にアプローチできる

    Folkwellの登録詳細はこちら

最新記事