転職:2017

新卒で入社した車載システムの大企業に10年近く勤め、3つの職種を経験し、退職しました。最初はプログラマーで、次に企画職を少し、最後は複数のソフトウェア開発チームに対して技術支援をする職種でした。退職してから転職活動をし、巨大企業で研究開発をすることになりました。前職のキャリアと転職活動を振り返り、記すことにします。

自分にとってのキャリアの整理のために書くのですが、もしかすると似た境遇の人が参考になるかもしれないですし、公開する文章にした方が本腰を入れて書けるので、ここに書きます。時折見られる華々しい転職エントリとは異なり、凡人のキャリアについての文章です。社名は本旨には関係しないので載せていませんが、いくらか調べれば出てくるでしょう。

駆け出し:2007〜2008

私は大学で情報工学を学んでいました。学業では周囲に比べると劣等生で、あまり研究は好きではありませんでした。その代わりといっては何ですがDTMを何年か続けていて、音楽とコンピューター技術に関する仕事に就きたいと考えていました。といっても、それは漠然としたもので、特にやりたいことが明確になっていたわけではなく、「シンセサイザーやDJ機器を作るのがいいかなぁ」程度の気持ちで楽器メーカーやオーディオメーカーを受けました。確か5社くらい受けて、2社から内定を得て、1社は最終面接で不採用と判定されました。その不採用となった最終面接では、面接官から「あなたの希望する職に就けない可能性もあるが、それでもよいか?」と問われて『絶対にダメです。何のために応募したと思っているんですか。』と答えました。きっとそれが不採用の原因だと思います。

結局、入った会社でも第一希望の部署には配属されず、車載デジタルテレビの開発部門にてソフトウェア開発に5年半従事することになりました。この5年半で組込みソフトウェア開発の基礎を習得し、電機メーカーにおける企画・調達・開発・生産・市場投入・市場調査という流れも理解しました。学生時代には全く知らなかった調達部門・生産部門・品質保証部門の存在・役割も知ることができました。

ソフトウェア開発メンバーとして配属されたのですが、最初のタスクは意外にもテスト用のハードウェアの開発でした。その辺に転がっている水晶発振子と分周ICを使ってパルスを生むものでした。ユニバーサル基板上に実装し、ケースも作りました。これはハードウェア開発を行う会社らしいところですね。

ソフトウェアの開発では大学時代に学んだ知識が役立ちました。例えば、情報工学の知識は、マルチプロセスにおける同期処理の仕組み、デバッガ上に見えるレジスタの意味、論理回路の理解に役立ちました。また、ディジタル無線の知識も、性能測定やフィールドテストの際に役立ちました。

あまり自信がなかったのがプログラミングです。というのも、学生時代に書いたコードといえば、演習課題を除けば一番大きくて1000行程度のJavaアプリケーションしか開発したことがなく、ソフトウェア工学らしい知識も幾つかのUML図と簡単なユニットテストくらいしか知らなかったからです。ところが、プログラマーとして働くことは思ったより難しくなかったというのが開発に携わって間もない当時の感想でした。テクニック、ライブラリ、ツールの知識がさほど無くても仕事をすることはできました。むしろ職歴5年10年の先人が書いたソースコードを見て、「プロって意外と大したことないな」と思っていました。実際に先輩に対して「何年やってるんですか」と大人気なく煽ってしまったこともありました。

仕事にもある程度慣れてきた頃、あまり勉強せずとも周囲の開発者と同様に仕事ができることに疑問を感じました。というのも、学生時代に比べて本を読んで勉強しなくなったからです。「書店には沢山の技術書が並んでいるのに、それらを全く読まずとも仕事ができているのはなぜか?」「さすがに学部レベルの知識で仕事ができるのはおかしいのではないか?」と思いました。また、学生時代に周囲にいた人々の中には、フリーソフトウェアを開発したり、技術書を翻訳したり、国際プログラミングコンテストに出場するなどの能力のある人々がいました。そうした人々と自分たちを比べると「プロが大した事ないのではなく、周囲の多くのプロはプロレベルに達していないまま仕事をしているのではないか?自分もプロレベルに達していないのに気づかなかったのではないか?」という疑問がわいてきました。今振り返ると周囲の実力も自分の実力も適切に評価できていなかったと思いますが、当時はそう疑問に思ったのです。

駆け出しの頃を振り返ってみると、機能追加やバグ修正などの個々のタスクをこなすことはできていましたが、より良い設計をしたり、より快適な開発環境を整えたりすることはできていませんでしたし、ユーザーの利便性を考える機会も乏しいものでした。また、担当している範囲でしかシステムを理解していませんでした。特に2年目はほとんど成長できていなかった気がして、「このまま過ごしてゆくと技術が身につかず、仕事を選べなくなったり、楽しめなくなってゆくのではないか?」と危機感を覚えました。

プロを目指して学習:2009

それから、以下の目標を立てて学習することにしました。

  • (1) 開発対象のソフトウェアがどのような仕組みで動いているのかを自身の担当範囲にとどまらず全体的に理解し、時間さえあれば一人で全てを開発できるだけの技術を身につける。
  • (2) 組込みシステム開発、ソフトウェア開発に関する基礎的な公知技術を身につける。
  • (3) 身につけた技術は仕事で実践する。

といっても、あまり気合を入れて学習したわけではありません。学習のほとんどは業務時間中に担当業務の延長線上の活動として行いました。読んだのは、規格書、他の開発者が担当する部位のソースコードや設計書、ハードウェアの設計書、開発ツールのマニュアルです。読む中で知らないことが出てくると逐一検索して調べました。ほか、プライベートの時間でやる気があるときだけ技術書を読むようになりました。平均すると2ヶ月に1冊程度のペースだったと思います。1冊あたり2ヶ月かけて読んだのではなく、2ヶ月に1回程度読む気が出たということです。

また、この頃には既にIT勉強会文化があり、IT勉強会カレンダーのおかげで存在も知っていたのですが、独学で困らなかった、自分に合った勉強会を探すのは面倒だったという理由で行きませんでした。

実践:2010〜2012

システム全体の理解が進んだので、要求同士の整合性を考慮したり、不要になるコードを見つけて削除するなど、全体最適を目指した変更ができるようになりました。他の開発者の仕事を助けたり、全体的な指示をすることもできるようになりました。全てのソースコードの詳細を理解していたわけではありませんが、各コンポーネントの重要なAPIや変数は大体覚えており、全てのソースコードと要求仕様の対応は多少の時間があれば調べることはできる程度には理解していました。

また、ハイブリッドアジャイルに近いイテレーティブな開発プロセスを組み立てて、アーキテクトのような立場で開発をリードする経験を積むこともできました。誰もアジャイルという言葉を使っておらず、私もアジャイルを目標としていたわけではありませんでしたが、今振り返ると中身はまぁまぁそれらしかったと思います。

ほか、幾つかのツールの導入や浸透に関わり、積極的に使う経験ができました。私が新規導入を提案したものも、他者が提案して私が浸透に関わったものもあります。

公知の知識を仕入れて実務で応用する機会には、社内では比較的恵まれたのではないかと思います。ソフトウェアの規模があまりに巨大であれば (1)+(3) の目標は達成できなかったでしょうし、ツールや手法を実践する機会が無ければ (2)+(3) の目標も達成できなかったでしょう*1。技術によっては実践する機会に恵まれない場合もあり、最初は反対されましたが数ヶ月の実験と説得の末に実践できたこともありました。

大企業において複数の開発チームへ並列的に関わることができた最後の職種になって思うのですが、所属組織によって成長できる経験を積みやすいか否かが大きく異なるのではないかと思います。あのチームならもっと成長できたかもしれない、あのチームだったら成長できずに腐っていったかもしれない、といったように。得られた知識を仕事で活かせるかどうかは、自分たちの状況に当てはめて利点や必然性を見出す応用能力と、具体的な実施方法・コスト・評価方法などもまとめて計画を立てて提案する能力が必要なのですが、それが受け入れられるかどうかの因子は自分がコントロールできることばかりではなく、運もそれなりに関係するというのが実感です。

「勉強しても実践するのが難しい」「教科書と現場は違う」という意見を言う方々に時々出会いますが、私はそれらの意見とは真逆の経験をすることができました。エンジニアリングを勉強して得られた知識は、応用能力・提案能力・運があれば、会社組織のビジネスで実践することができると考えています。

思い返すと、ハードウェアを扱う領域ならではの面白さがありました。スマートフォンやPCなどの汎用的ではないデバイスで動くものを作るというだけでも心が踊りますし、おかしな映像が出てしまったり電源に異常が出てしまったりしたときもなぜか笑えましたし、故障品を調べていてアドレスバスのパターンが切れていたことに気づいたときは「そういうのもあるのか*2」と思いましたし、フィールドテストにて後部座席でデバッガを見つめながらおかしな挙動を見つけてその場でコードを書いて「さっきのところもう一回曲がってください」と指示して「またかよww」という会話をしたのも楽しい思い出でした。

次の道を模索:2012

開発職を5年続ける中で技術は向上したものの、プロダクトにも環境にも飽きてきました。そうした日々の中で、仕事の4分類:成長・支援・維持・再生 という文章を思い出しました。そして、「今の仕事は維持の仕事だ。成長の仕事をしよう。」と考えました。それまでの仕事はどう作るのかを考える仕事だったのですが、何を作るのかを考える仕事、更にはその自分で考えた企画に対してプロトタイプを作る仕事をやってみたいと考えました。今思うと、自分が主役になる実感を得られる成果を出したかったのだと思います。

そして、企画部門に異動しました。ここでの仕事は商品戦略に関わるため機密事項が多く、書けることはほとんど無いのですが、私は主に先端応用技術の動向を調査していました。内容によっては機能立案をしたり、商品戦略に反映させる仕事をしていました。英文を読む機会が多かったので良い訓練になりました。しかし、この部門にて自分の望むやり方で仕事をするには、複数の部署をまたいだ大幅な体制変更をする必要があり、それは自分にとっては到底マネージできない問題であり、そこに時間を費やすのはもったいないと判断して、1年足らずで企画部門を去ることにしました。事前の内情調査不足だったと反省しています。

転職か、異動か:2013

このとき転職を考えました。転職するかどうかは決めていませんでしたが、自分の市場価値を測るために何社か受けてみて、良い条件であれば転職しようと考えました。結果、数社の他業界の会社を受けて、1社から内定を得られました。同時に、社内で異動する話も進めており、迷っていました。業務内容、残せそうな成果、得られるスキル、給与、勤務時間、居住地、ビジネスモデル、財務状況などの条件を比較して考えると、転職するメリットはそれほどないと判断して、異動することにしました。この選択が妥当だったのかは今でもわかりません。どちらの選択肢にも、満足/不満足どちらの可能性も相応にあったと思います。

Software Engineering Consultant:2013〜2016

異動先、つまり前職の最後の所属部署は、複数のソフトウェア開発部署の技術を向上させる責任を持っています。この分野のスキルに関してはプログラマー時代にある程度身につけており、組織的な技術向上の実績もあったため、即戦力人材としてリーダーシップをとって遂行してゆくことになりました。特定の製品・特定の開発チームに所属せず、複数の製品・複数の開発チームに対して技術支援・問題解決をしてゆくのは新鮮でした。この職種は Software Engineering Consultant と呼ぶのが適切でしょう。*3

大きく分けて、1.コード解析ツールの全社的普及、2.テスト分析・設計手法の確立と普及、3.開発環境刷新、4.教育 という4つのことを行ってきました。多くは自分で立ち上げた仕事です(他にお蔵入りになったプロジェクトもありましたが)。この部署には3年在籍し、そして退職しました。実績を振り返ると「3年でこれだけか」とも思いますし、「まぁまぁできたかな」とも思います。自分にもっと能力があればできたことは他にもあっただろうなとも思いますし、能力があったとしても結果は変わらなかったかもしれないとも思います。

Software Engineering という技術に向き合う仕事柄、より多くの公知の知見を仕入れる必要が出てきました。以前よりも本を読むようになったり、学会やシンポジウムなどでの発表資料や論文を読んだり、JSTQB Foundation Level というソフトウェアテストの基礎的な資格を取ってみたりしました。

他社の方々と交流する機会を増やし、自身のレベル、自社のレベルを測るようにもなりました。いくらか発表する機会もありました。

そこそこ合っていた仕事かなと思います。

退職

退職した理由はいくつかあります。

  • 人生は一度なので、他の世界も身をもって知りたい。(長く居すぎたと思った)
  • もっと興味のあるプロダクト、未来を担うプロダクトを作りたい (そういうプロダクトばかりではなかった)
  • 開発する機会を増やしたい (技術と知識の幅は広がったが、根幹となる作る力が落ちてしまった。)
  • 自分の伸ばしたい能力に関して、自分よりも秀でた人が沢山いる環境に身を置きたい。(そういう人は少なかった。それぞれ長所はあるが方向性が違う。)
  • 収入をのばしたい。(成果に見合った額はもっと高いと思った)
  • もっと海の近くに住んで気軽に釣りに行けるようにしたい。(そうするには微妙な地域だった)

全てを満たせる選択肢があるかはわかりませんが、前職では多くを満たせないと判断しました。

入社当時は10年近くも働くとは思っていませんでした。1つの部署だけでなく、自分で希望して3つの部署・職種を経験できたのは他の社員と比べて恵まれたと思います。社内という内輪の中とはいえ、自分の能力を売り込んで異動して、経験・実績を積むことができました。特に、IT・ソフトウェアという好きな分野を基軸にして楽しめる仕事ができたのは喜ばしいことでした。

転職

在職中に次の職を決めるのがセオリーらしいのですが、ものぐさな私はなかなか本腰を入れて活動できず、転職せざるを得ない状況にするために、先に退職することにしました。

希望条件は退職理由から導いた条件が中心ですが、転職活動をする中で明らかになっていった条件もあります。大まかには以下に分けられます。

条件種別
プロダクト 自分が使いたいと思えるプロダクトか?未来を担うプロダクトか?
実績 成したいことができるか?公開できるか?
スキル 身につけたいスキルを習得できそうか?既に身についているスキルを活かせるか?
労働環境 労働時間が許容範囲か?便利なグループウェアがあるか?服装などの非合理な規定が無いか?自分が改善してゆけるのか?
勤務地 周辺の家賃相場は?家族や既存の友人に会いに行ける距離か?
収入 希望額以上か?上記条件の充足具合によって変動。

これらの条件種別ごとに詳細な条件を設け、希望・前職・応募先企業を比べる表を作りました。また、前職の方が良かった条件というのは気づきにくく、応募先企業について調べる中でわかってきました。私は複数の条件のバランスを考えたので結構迷ってしまいました。「金だよ金!」みたいに1つの条件だけで選べるなら楽だなぁと。結果、前職よりも複数の条件について改善するポジションのオファーを得られました。

企業・ポジションを探すにあたり、いくつかのサービスと転職エージェントに頼りました。以下、それぞれについて感想を書きます。他の方には当てはまらないところもあるでしょう。

  • LinkedIn
    • 外資企業を探すのに役立ちました。Job Description が明確に示されている場合がほとんどで、選びやすかったです。
    • メッセージの9割は転職エージェントから。全て大手外資系企業における前職同業のポジションの紹介で、異業種へのお誘いは皆無でした。
    • 国内大手企業も中にはありますが、自分が探している業種・職種についてはほとんどが外資でした。
  • Wantedly
    • 国内新興企業が多く、自分が知らない企業を知るのに役立ちました。
    • メッセージもそれらの企業から来ます。プロフィールを読んでいると思われるものばかりでした。
    • 転職エージェントからのメッセージが一切無かったのは好印象でした。
    • メッセージの数は LinkedIn に比べるとかなり少なく10分の1程度ではないかと思います。
    • LinkedIn と同じ使い方をすることもできますが、話を聞きに行きたいボタン、社員個人に焦点を当てた文章があるなど、別の価値があると思いました。
    • リアルウォンテッドリーにも1回行ってみました。参加企業の方から「サーバーですか〜?フロントですか〜?」と開口一番に話しかけられ、ウェブしか見てない視野の狭い人達がいるものだと落胆したのを覚えています。 イベント自体は良い機会を得られるものだと思います。
  • ビズリーチ
    • メッセージの8割は転職エージェントからです。
    • LinkedIn とは対象的に全て国内企業の紹介でした。
    • 大手が多いですが、中にはスタートアップもありました。
    • LinkedIn が日本に普及できていない部分を埋めるようなサービスで、存在価値を感じませんでした。ビズリーチを利用している企業は全部 LinkedIn に乗り換えて欲しいと思いました。
  • 転職エージェント
    • エージェントとの最初の接点はLinkedIn かビズリーチである場合と、私のメールアドレスに直接連絡してきた場合がありました。
    • 転職あっせん会社/エージェント個人によって扱っている業界が異なることがわかりました。
    • 業界/企業によっては転職エージェントに頼らないと知り得ない非公開求人があることがわかりました。
    • どのような企業/ポジションを探しているのか、詳細に伝えた方が良いです。「詳細な条件を書くと該当する求人が無かったりわがままと思われるのではないか?」などと尻込みをする必要はありません。でないと全く興味のわかない企業/ポジションを紹介される可能性が増えます。
    • レジュメの書式についてアドバイスを頂くことはありましたが、スキルと求人要項を照らし合わせて合いそうか否かについてコメントして頂けることはありませんでした。
    • 転職エージェントはあくまで転職のあっせんをする役割で、キャリアアドバイザーではないと思いました。

選考方法はそれぞれです。レジュメについて深掘りする質問をされたり、技術の筆記試験があったり、ソースコードを書いたり、プレゼンテーションをしたり、その事業の・部署の現実の問題について「あなたならどうする?」と相談されるなど。印象に残っている質問は「○○(技術名)についてあなたが複数回経験した技術的な問題と、その対策を教えてください。」というものです。「その技術の実務経験があるならそれ特有の問題を経験しているでしょ?その問題に複数回ぶちあたっているならば対策も考えますよね?」という意図なのでしょう。ほか、基礎知識を問う質問に答えられずに落ち込むこともありましたが、復習の良い機会ととらえることにしました。

転職活動をして強く感じたことは2つあります。

1つは、業界や企業によって求人情報や社員個人が発信する情報への辿り着きやすさが異なることです。ここ10年で誕生した/台頭した企業や一般向けウェブサービスを手がける企業では、公式採用ページに Job Description が書かれていて、Wantedly にも載っていて、技術ブログが運営されており、SlideShare などで発表資料が公開されている傾向があります。また、社員のブログやTwitterアカウントも探しやすかったです。対して、それ以外の国内の大手企業、特にtoB事業が中心の企業になると、転職エージェントに頼らないと求人情報に辿り着けず、Job Description が曖昧という場合が多かったです。大手やtoB事業中心の企業でも外資になると、LinkedIn がある分いくらかオープンであり、Job Description もはっきりしていますが、それでも転職エージェントに頼らないと知り得ない情報があると思いました。*4

もう1つは、自分の居る業界/企業でスキルを高めても他の業界/企業では通用するとは限らないことです。と言うと当たり前なのですが、私は本業で即必要となるスキルと、少し先で必要となりそうなスキルしか得ておらず、それを何度も感じることになりました。また、業界を問わなさそうな共通スキルについても、面接の場で直接言われたわけではないのですが「我々は、あなたが解決してきた課題を既にクリアできている。それ以上の進歩を生み出してゆけるか?」と問われたと感じることが何回かありました。これについては、これからのキャリアでなんとかする必要性を感じました。*5

これから

これまでの組込みシステム中心のキャリアから一転し、主にサーバーサイドを相手をすることになる予定です。 ちょうど別の開発経験を積みたいと考えていたところであり、プロダクトも挑戦的なものです。 また、学会・シンポジウムでの発表やOSSなどで、公開できる成果を出していきたいですね。 最初のうちは要素技術と向き合うことに多くの時間を費やすことになりそうですが、ユーザーとプロダクトのことも意識的に考えてゆきたいと思います。

前職よりも複数の条件について改善するポジションのオファーを得られたと先述しましたが、それはつまり改善されないことも中にはありそうだということです。また、新たな希望や悩みを抱くかもしれません。なので、長くやってゆけるかはわかりませんが、まともな成果を出すまでは続けようと思います。

不安はあります。でも、まずは変化を楽しんでゆくつもりです。

*1:目標(1)(2)についてはもっと突き詰める余地はありましたが(3)はできたので良しとしています。自分に甘いスタイル。

*2:漫画"孤独のグルメ"の名台詞。

*3:SEPG: Software Engineering Process Group という呼称もありますが、Group というのは職種ではないというのと、日本においてはSE, PGが職種を指すのでわかりにくい呼称だと思います。

*4:Qiitaも同じように書き手や技術分野に業界の偏りを感じる。というのは別の話。

*5:「IT業界」なんて、ないんだよ。 を思い出しました