自分戦略研究所 | 自分戦略研究室 | キャリア実現研究室 | スキル創造研究室 | コミュニティ活動支援室 | エンジニアライフ | ITトレメ | 転職サーチ | 派遣Plus |


〜自分戦略研究所 転職者インタビュー〜
転職。決断のとき

第19回 下請け現場での苦労をバネに

岩崎史絵
2004/10/8

 スキルを上げるため、キャリアを磨くため、給料を上げるため――。エンジニアはさまざまな理由で転職し、新しい舞台で活躍する。では、転職の決断をするのはいつなのか? そしてその決断に至った理由とは何だろうか? その決断のときを、@ITジョブエージェントを利用して転職したエンジニアに尋ねた。

今回の転職者:佐藤弘美さん(仮名・32歳)
プロフィール■大学卒業後、派遣オペレーターとして3年間勤務。1997年に都内のシステム開発会社(SI会社)に就職、2000年問題対応プロジェクトを担当し、COBOLをマスター。その後別のSI会社に転職を果たし、VBやCなどオープン技術を使ったシステム開発を担当。2001年、九州の人材派遣会社に登録し、約3年間開発者としてさまざまな“火を噴いたプロジェクト”を経験する。2004年7月、@ITジョブエージェントを通じて都内SI会社に転職。

 「崩壊したプロジェクトで誰が最も苦労するかご存じでしょうか。地方の下請けSI事業者なんです。そもそも、最初の設計段階から技術的に無理なことを元請け会社は“できる”といっている。いくらお金や期間をつぎ込んでみても、絶対に動かないのです。そうしたプロジェクトは仕事のない地方に回されます。下請けですと、システム設計書を正すこともできません。結局、何とかつじつまを合わせるために月数百時間もの残業になるのです」。今年7月、地方のSI会社から都内のSI会社に転職した佐藤弘美さん(仮名・32歳)はこう語る。

■派遣オペレーターとしてIT業界へ飛び込む

 佐藤さんがITの世界に飛び込んだのは大学を卒業した1994年のこと。しかし、初めからエンジニアを希望していたわけではないという。「バブルが弾け、女子の求人が極端に少なくなった時期と大学の卒業時期が重なっていたのです」(佐藤さん)。ちょうど「女子就職氷河期」という言葉がマスコミに喧伝されていたころだ。職種を選んではいられない。佐藤さんは派遣会社にオペレーターとして登録した。いろいろな会社に派遣されるうちに、技術をしっかり身に付け、開発者としてキャリアを積みたいと思うようになった。

 もともと勉強熱心な佐藤さんは、それまでの実績を見込まれ、1997年に都内のシステム開発会社に就職した。正社員としては初めてだったが、それまでのキャリアがあるので新入社員というわけではなかった。

 佐藤さんが転職した時期は、IT業界が2000年問題で揺れていた時期だ。そのため、配属されたのは2000年問題を担当する部署。メインの技術はCOBOLだった。確かに仕事も技術も覚えられるが、果たしてCOBOLは開発者のキャリアとして適切なのか。こうした疑問が頭をもたげてきた。一緒に研修を受けた同期は、Visual Basic(VB)やCなどのオープン系技術を使った開発に従事している。そうしたオープン系技術の方が、今後はメインになってくるだろう。佐藤さんはそう感じた。

 「技術者は、与えられた環境で決まりきった技術を使っていればいいというわけではありません。やはり、いま旬の技術にはどういうものがあり、どういう特性があり、何が求められているかを知らなければ、技術者としての価値は半減してしまいます。私は技術者としての価値を高めるために、旬の技術を身に付けたかったのです」(佐藤さん)

 部内の雰囲気も独特だった。「古くからのCOBOL開発者は、あまりオープン技術を認めたがらない風潮がありました。また、年配の方が多いためか、私が何か提案をすると『よく分からないのに口出しするな』とばかりに取り上げてもらえませんでした。そうした視野の狭さも合いませんでした」(佐藤さん)。社内異動も考えたが、2000年問題対応で大わらわしていた時期で、技術者はいくらいても足りないといった状況だった。こうした中で異動が認められるはずもない。会社に通いながら、帰宅後と週末には自宅でオープン技術を勉強する日々が続いた。キャリアアップの観点から、退職を決意したのは2000年問題への対応が終わった1999年3月のことだ。

■派遣先でオープン系の技術を磨く

 ところが転職活動は容易にはいかなかった。VBやCなどのオープン技術を一通り勉強していても、「実務経験がない」といわれて弾かれるケースがほとんど。「COBOL技術者はいらない」とはっきりいわれたこともあった。この当時は人材紹介会社を使わず、情報誌などを使って自分の手でアタックを繰り返していたという。

 1999年5月、佐藤さんは別のシステム開発会社へ転職を果たす。ここではVisual C++を使ったシステム開発を担当することになった。実務経験がモノをいう世界だからこそ、この会社では夢中になって働いた。「新しい技術に触れられるのは楽しかったし、家に帰って勉強するのも苦ではありませんでした」と佐藤さんはいう。社内の雰囲気も和気あいあいとしており、特に不都合は感じなかったという。

 転機が訪れたのは2000年だ。福岡にある実家から、「親が倒れた」という連絡が入った。介護が必要なため、佐藤さんは急きょ実家に戻ることになった。

 献身的な介護の甲斐があって、家族の病状はだいぶ回復した。それでもまだ予断は許さない状態だ。佐藤さんは実家から通えるように、地元のSI会社の面接をいくつか受けてみた。最終的に決まったのは、エンジニアの派遣会社だ。もともと介護の時間が必要だった佐藤さんは、これまでと同じようにいろいろな会社で技術を提供する、そんなふうに考えていた。

■地方SI会社の悲劇を体感

 一口に「派遣」といってもさまざまなケースがある。例えばあるプロジェクトの元請け会社に派遣される場合、クライアント先ではその元請け会社の社員と同じように名刺を作り、その会社の社員として働くことができる。ところがいったん元請け会社に派遣されたものの、そこから別の関連会社に派遣されたり、極端なケースではライバル会社に当たる開発元へ派遣されることもあるという。

 同時に、ソフトウェア開発の問題点もある。発注元であるユーザー企業は、「こういうシステムがほしい」と、大手SI会社に依頼する。大手SI会社はユーザー企業からヒアリングを重ね、システム設計書を作る。だが、実際に開発を行うのはその下請けだ。下請けだけでできない場合には、さらに孫請けに設計書が回される。そこでも対処できない場合には、さらに別の下請け会社に依頼する。こうなると、ユーザー企業はおろか、元請けである大手SI会社にも仕事の流れが見えない。特に大きな案件の場合、かかわる会社やエンジニアの数は膨大になる。発注金額も大きいが、間に何社も入ることで、降りてくる金額は少なくなる。そのうえ、下に降りてくればくるほど、技術的に非常に困難な部分が多くなる。一部には「こうした仕事の構造によって、ソフトウェア開発業が成り立っている」という意見もあるが、末端にいるエンジニアにとっては悲惨だ。残業ばかりが多くなり、報酬は少ないといった日々が待ち受けている。

 「地方がさらに悲惨なのは、仕事がないので中央の破たんしたプロジェクトを受けざるを得ない点なのです。断るわけにはいきませんが、どう考えても無理な設計書が回ってくる。そのうえ、プロジェクトマネージャやリーダーは、中央にある元請けの巨大SI会社から単身赴任で来るので、破たんしたプロジェクトを立て直すのは無理。そもそも設計書自体に不備があったり、プロジェクトの進め方に破たんを来しているのに、そのままの方式でプロジェクトを進めようとするため、現場に大きな負担がかかるのです。こちらから提案しても、聞いてはくれません」(佐藤さん)

 こうした破たんプロジェクトをいくつも経験した佐藤さん。多いときには残業時間が月300時間もあったという。しかし、それでも当時得ていた報酬は月額40万円前後だった。派遣なので、賞与はない。学生時代の友人から、「その仕事量でその報酬は安過ぎる」と指摘されたこともあった。

 実は佐藤さん自身は、仕事は大変なものの、報酬の点ではそれほど不満はなかったという。だが、立場が保障されない中、新しい技術の勉強ができるわけでもスキルアップの機会が望めるわけでもなく、朝出社しては日付が変わってから帰宅するという日々に疑問を感じるようになった。最大の問題は「技術が分からない元請け会社の社員だけが上流工程にかかわり、無理な設計書、仕様書を作ることがそもそも間違っているのではないか」という疑問が芽生え始めたことだ。

 「技術者は、お客さまが求めているシステムを技術的な観点から検証することもできるはずです。流行のシステム・アーキテクトや設計担当ではなく、技術力でもってお客さまと接することができると思います。ただ、地方にいるとその機会は限りなくゼロに近い。ちょうど、家族の具合も快方に向かっていたこともあり、再度東京での就職を考えました」(佐藤さん)

■中央の大手SI会社は分からない開発者の苦労

 「立場が保障され、スキルアップが望める環境で――」。2004年2月、大手転職サイトを使って東京のSI会社への転職を果たした佐藤さんだったが、やはりそこでもギャップに悩まされた。佐藤さんはこれまでの経験から、技術者の立場で上流工程にかかわれる、そんな仕事を望んでいた。しかし多くの開発会社は、「設計は設計、開発は開発」と職種で仕事内容を分断している。結局その会社を退職し、@ITジョブエージェントを使って転職活動を開始した。「@ITジョブエージェントなら、エンジニアの立場に立った転職活動をサポートしてくれると思いました」(佐藤さん)

 @ITジョブエージェントを通じ、キャリアコンサルタントからサポートを受け、これまでの経歴を詳しく履歴書にまとめた。派遣でいろいろなプロジェクトを見てきたので、身に付けた技術も担当してきたシステムも多数ある。コンサルタントは、その職歴をなるべく詳しく書くようにアドバイスした。

 面接を受けたのは2社。そのうち1社は、オブジェクト指向開発で実績のある有名会社で、技術もシステム設計も分かる開発者を募集していた。ところが面接では、「やはり開発は開発、設計は設計という考え方でした。これまで私が経験してきた下請けの苦労から、『開発者の立場から設計にかかわりたい』といっても、実際に下請けの状況を知るご経験がないとなかなか理解されないのでしょうね」(佐藤さん)という。結局、技術力とシステム設計力、両方を兼ね備えた人材を求めていた現在の会社に転職した。2004年7月のことだ。

 J2EEなど最新の技術を独学で、あるいは仕事を通じて習得してきた佐藤さんは、ある意味“鳴り物入り”で転職を果たした。実際、会社側のこうした期待は佐藤さんにとって少々負担なようだ。何より、ソフトウェア開発業の構造が変わらない限り、佐藤さんが本当にやりたい仕事、「開発者の視点でもって設計に携わる」という仕事をしていくのは難しい。

 「独立系のSI会社など、東京にはたくさんのSI会社がありますよね。でもその方たちはほとんど超大手SI会社出身で、末端の開発者がどんな苦労をしているか、どうすればその構造を正すことができるか、想像もしていない方が多いと思います。私1人だけの力ではどうしようもないかもしれませんが、現場で本当に苦労してきた開発者が実際にクライアントの前に立って、どうすれば要件を最適な形で実現できるのか、一緒になって考えていくこともできるはずです。近い将来、そんな日が来るのを願っています」(佐藤さん)

 「転職」という枠を超え、佐藤さんの戦いの日々はまだ続くのかもしれない。

担当コンサルタントからのひと言
 佐藤さんとお会いしたのは、前の会社をわずか2カ月ほどで退職され、再び転職先を探していらっしゃるときでした。Java関連の経験や知識などに魅力を感じたものの、いったいどういう事情で退職されたのだろうなどと、お会いする前に考えていました。

  実際に佐藤さんにお会いして話を伺うと、一見穏やかで控えめな印象だったのですが、「ソフトウェア開発はこうあるべき」といったスタンスをしっかりお持ちでした。それは、開発の最前線で非常にご苦労された体験からにじみ出るものという感じがしました。

 COBOLからキャリアをスタートしてJava系に独力でシフトしていったという点からは、ガッツのある方だという印象も受けました。前職を短期間で辞められたのも納得のいく理由でした。漫然と与えられた仕事をこなすだけの方や、それがキャリア上デメリットになると分かっていてもアクションを起こさない方が多い中、その姿勢には見習うべきものがあると思いました。

  ちなみに佐藤さんがCOBOLのお仕事をしていたときのユーザー側企業のシステム部門に、私も同じ時期に偶然ですがSEとして勤務しており、働かれていた現場のイメージもわきやすいということもありました。

 ただ、短期間で辞めた会社があること、キャリア上のブランクがあること、COBOLでの開発の時期があることなど、いざそれらを書面にしてしまうと、書類選考時のマイナスイメージを与えるかもしれない要因になり得ると考えたため、佐藤さんのアピールポイントをいかにうまく書面で強調するかということを考慮して、アドバイスさせていただきました。

 そして、Javaなどの得意な領域をうまく強調する、前職を短期間で辞められた理由もぼかすことなく明確に記入するなど、ポイントを設定したうえで、職務経歴書を作成し転職活動に臨んでいただきました。


 佐藤さんにはこれからも、さまざまなシステム開発の現場で活躍されることになると思いますが、今後もがんばっていただきたいと思います。
キャリアコンサルタント 宮脇啓二氏
       


転職。決断のとき バックナンバー



@自分戦略研究所の転職関連の記事一覧
キャリアコンサルタントのアドバイス記事などを読む
転職事例の記事を読む
転職・退職時の注意点に関する記事を読む
自分戦略研究所、フォーラム化のお知らせ

@IT自分戦略研究所は2014年2月、@ITのフォーラムになりました。

現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。

これからも、@IT自分戦略研究所をよろしくお願いいたします。