【退職エントリ】渋谷の Web ベンチャーを退職しました

こんにちは、Nash です。

この記事は「自分の思い出＋思考の整理を兼ねての渋谷の Web 系ベンチャーの退職エントリ」です。

下記のようなトピックで書いてあります。

  • SE⇒Web に転職しての気付き
  • SE と Web 系ベンチャーに対する比較・考察
  • 自分がやってきたことの振り返り
  • 退職後にやる予定のこと

ただ、ブログ書くのも初めてだったので、1 万字を超える長さになってしまいました。 というわけで、めちゃくちゃ長いので、ある程度ななめ読みにしたり、分割して読んだほうが良いです。

では見ていきます。

はじめに

SE 業界から Web 業界に飛び込んできたが、思えば既に 1 年半も経っていたとは思えない。

SE→WEB に来るときは悩みに悩んで「人生の大きな決断だ」くらいのレベルで移動して来たが、今回退社する際は、そこまで大きな覚悟や方針をみっちりと持たずに辞めるので、「だいぶ WEB 業界の色に染まったのかなー」とも思う。つまり、大体の方向があっていればまずは試してみよう！という経験主義なところだ。

「コンパスの指す方向が向こうを向いているので、この会社から離任する。その先には行ってみないと正直わからないよね？」

くらいの感覚である。ともあれ、1 年半も入れば色々な発見もあったので、そこらへんをまとめておく。

ベンチャー

というわけで、俗に言うベンチャーである弊社に入社したわけだが、びっくりしたのは何より年齢が若い。自分は 26 歳だったが、それでも、若手組の中で、ちょっと上の「お兄さん」くらいの位置に属していたような感じだった。その上は跳ね上がって 40 代の俗に言う「大人」という組（いや、自分らも大人だけど）という構成。会社に入ってメンバーのテンションを見て最初に思ったのは、「ここは学校の延長かな？」だったわけだが。

自分が入社した 2016/06 頃は 40 人くらいだったが、2018/11 頃は 70 人にまで増えている。自分のように途中で離任していくメンバーもいるので「単純に 30 人増えた」というよりも「増減があった最終結果が 40 人 →70 人」となっているため実際はニューカマーは 30 人以上なので、自分が退職するときはもはや知らない人の比率の方が高かったと思う。

また、SE 畑から来ると、Web 畑のエンジニアのバックグラウンドの多様性には驚かさせる。特に、この会社が、「未経験でもポテンシャルがあれば積極的に採用する」というスタイルを取っているところもあり、自分のように SIer 上がりや、他の現場から来た人の方が少ないくらいに感じる。

前提

そもそも、

  • SIer 　 → 　 Web 業界

  • 大手　 → 　成長中ベンチャー(自分が入ったとき 40 人くらいだったのが、今は 70 人くらい)

  • 顧客折衝系の上流工程中心　 → 　 WebDeveloper として Back 中心に Front/Infra も行う

と前回の転職は環境も仕事内容も尋常ではないレベルで全てが変わる内容だった。その感想を書く。

結論、幸福度が跳ね上がったのでこの会社／業界に来たことは良かった。ただし、給与は大きく落としているがやりたい方向に向かっているので、そこまで気にしていない。

この会社への入社目的

そもそも、この会社へ転職するに辺り、下記を大方針として考えていた。

  1. エンジニアリング：プライベートを犠牲にしても伸ばす
  2. ロール：ディレクションなどのいろいろなロールも経験してみる
  3. 経験：Web 開発を経験を通して理解する
  4. ニッチ技術：尖ったニッチ技術を得る

結論、ほぼ全てを叶えている。一つ一つ見ていく。

1. エンジニアリング

もともと、SE→Web に来る際に

「プライベートは出来る限り捨てて、エンジニアリング能力向上に全コミット」

を大方針として決めていたもあり、人間関係の拡大やビジネススキルや人間性の向上はそこまでしていない。むしろ、見方によっては下がったところもあるくらい。だが、そこは自分が好んで選択した方向なので、不安になるときもあったが後悔はない。その分、エンジニアリング能力はそれなりに向上できたとは思う。その上での反省や気付きをまとめておく。

鶏口牛後なのか鶏後牛口なのか

Web 開発経験が浅いにも関わらず SIer 時のスキルセットが活きて、この会社では完全に鶏口牛後として、リーダーやディレクション的なことを行えた。各ロールについての感想は後述するが、経験しないとわからないところもあったので、良い経験である。

だが、それと同時に、気付けばエンジニアとしてのポジションですら鶏口牛後に近くなっていたのは想定外だった。「エンジニアたるもの誰かに聞いて成長せず、自力で成長すべし」という考えを持つのは大事だと思う、というか、聞ける人がほぼ居ない環境だったので自分はまさしくそれだった。だが振り返ると「本当にそれは効率的な成長だったのか？」ともよく思う。

エンジニア界隈において、「優秀なメンター取り合わけ師匠となる人を見つけて教えを請う」というスタイルは昔から多く用いられているスタイルであるようだった。もちろん自己鍛錬はありつつもそこまで持ち上げてくれる存在は何にも代えられない。特に自分のように、「エンジニアリング能力向上」を第一優先軸として持っている人間にとっては。

「師匠を見つける」という行為は社内の先輩や優秀なエンジニアに対して行ったりするのが一般的だが、自分の場合はそのような存在が社内の近い位置にほぼ居なかったのは不幸だったと思う。とはいえ、自分が外部に師匠を探すことをしなかった、という点があるので自分の行いの結果なのだが。

もし、やり直せるなら、見つけられるか否かは運の要素が強いこともあるが、それでも社外に師匠を探す努力をしたほうが良かったな。とも思う。

自由なフィールドで自由な裁量と開発

ここの職場での最大のメリットは「自由に走り回れるフィールドが用意されている」という点だったと思う。顧客との要件を詰める際には、戦略的にどのような機能を入れるか？会社として言語／FW は何にするか？などは事前に社長や先方が重めにコミットして要件を固めるが、その後の DB 設計などのレイヤーなどからほぼ全てプレイヤーに任されていた。そのため、「手を動かして体で覚える」「試行錯誤する」「新しい技術を取り入れる」などの観点ではかなり有意義な経験を行うことが出来た。特に 0 から始まる案件はかなりの範囲を実装することが出来た。もちろん、それによる失敗も色々あるし、その代償は自分の場合は残業／休日出勤とかで払っていた感も否めないが、最初は小賢しくやらずに泥臭くやる予定もあったので、自分としては満足感はある。

2. ロール

ほぼ初プロジェクトから

ディレクター 兼 リードエンジニア

のロールで数ヶ月休み無しで活動したり、スマホゲームのバックエンドチームで

プレイングリーダー

のロールで仕事をしたりと、Web 系の経験が浅い人間には荷の思いロールをさせてもらえたが、少なくとも今日まで死ぬことなく生きていることができたのは前職のスキルセットが活きていたからだろう。

今の所、色々なロールをやっての結論は、一介のディベロッパーが今の自分には良い。

ディレクター

顧客のとこに毎週ヒアリングや状況などの報告、柔らかいところの仕様も必要に応じて固くする作業とかを行うロール。ただ、最終的に自分はディレクター業務はそこまで好きではないな、という結論にいたり、マネージャーロールの人が入ってきたので、その人に引き継いだ。

やってみた所感、ディレクション業務は出来なくはなさそうだが、エンジニアリングの方が好みだし自分にあっていたので、今後も積極的にはやらないかな。そもそもディレクション業務は前職での Sier 時のロールにものすごく似ていて、そういう仕事よりもゴリゴリと実装したい！という希望で Web 業界に来たので、わざわざやりたいとは思わない。

教育者

これは意外だったが、ビジネススキルの面で教育者的な発言を多くすることが多かった。プロジェクトの中でちらほらメンバーの仕事の進め方がイケてなくて、口を出す機会が多く、その結果、気付けばそういうロールに近くなっていた。それもそのはずで、職場には 20 代前半が多いので社会人経験の浅い人が多いし、そもそも技術寄りの人はビジネススキルを伸ばす機会がない。自分の前職がエンジニアよりもむしろサラリーマンだったので、そこらへんは一日の長がある状況が多かった。というわけで、メンバーへの助言やレクチャーを何度か行っていたのだが、この行為に対して次第に全能感を感じ始め、「これを続けると老害化するのでは？」「自分の成長停止が起こるのでは？」とかを思い、怖くなってきたので、今ではこういうロールからは距離を取るように心がけている。

プレイングリーダー

開発を行いつつ、チーム方針の方針や指揮などを自分が取った。このときは少人数かつメンバーに恵まれていて、こちらから何も言わなくても自走するタイプのメンバーだったので、本当に楽だった。例えば潜在的な課題を自分が発見したら、課題に対するショートな MTG の提案をすればあとは MTG 中も弱いファシリテーションで十分に MTG 進行するしそれぞれの価値観がありつつも相手の価値観も尊重してくれる、というできたメンバー達なので最終的に個人の意見とチーム方針で相違があっても、「自分の好みとは違うやり方だがメリデメは理解しているしチームで決めたことなので大丈夫ですよー」という感じで進められる懐の深さがあったりである。こういうメンバー構成でのチームリーディングは、ほぼ負荷がなく「こういう立場も悪くないかなー」と思いつつも、とはいえ、やはりエンジニアリングにフルコミットしたいな、という希望から、このロールを強くは行わなかった。

また、会社の規模拡大に伴い組織化を目指すようになったこともあり、リーダーロールだからという理由で出席が必要な会議が増えたり、そもそもリーダーに対する新しいタスクというのも増えそうになったりもしたので、ここらへんも自分の目指すべき人生の方向とは相違が出てきたところでもある。ちなみに、自分がリーダ時に考えていた根底は幸せ駆動開発であり、「メンバーが最終的に幸せになれるか？」という点を何よりも重要視してチームの指針を決めていた。（多分、自分のことを知ってる人間から知ると、意外だと思うが）

ディベロッパー

実装、設計などなどを行う人。PM を上に据えて単純なプレイヤーとして活動していたときが何より楽しくエンジニアリングを進められた。このロールを行っていたときの上に居た PM がサーヴァントリーダシップモデルをよく理解していた優秀な PM だったので、「優秀な PM の配下にいるときの開発が楽しい」だったのかもしれないが、それを抜きにしても「今の自分が好きなことは開発や設計をガリガリ行うときだなー」ということは少なくともわかった。願わくば彼のような優秀な PM のもとで今後も開発が続けられればよいな。

色々経験して思うのは、2 足のわらじは出来なくは無いし、他のロールもやろうと思えばそれなりにロール演じられるとも思う。が、そうなると何より開発の時間が削られる。「プライベートを犠牲にしてでもエンジニア能力を伸ばす」くらい、今の自分が伸ばしたいのは技術能力なので「別のロールを行う時間を行うくらいなら 1 行でも多くコードを書いていたい」というのが今の自分の目指すべき方向だった。

3. 経験( SIer / Web / Game 比較 )

SIer から Web 系とスマホゲーム開発も行ったので、そこら編の違いに関する気付きをまとめる。

SI から Web

ウォーターフォールモデルのシステム開発は SIer 時代に何度も経験していたが、「Web 業界だと色々と違うんだろうなー」と考えていたが、そのとおりだった。

最初に驚いたのはデプロイの手軽さである。SIer 時代では本番環境に数行デプロイするだけでも、 　 ① 承認を 3 つくらい通し 　 ② 本番デプロイの方法からフェイルバック方法までをプランし 　 ③ 上長への説明 　 ④ 顧客への説明を通過して 　 ⑤ やっとシステム非稼働時間の土日のどちらかに行う というレベルで 1~3 ヶ月くらいかけていた。転職してきて、この会社で初めて教えてもらったデプロイは、「Slack でメッセージを送ったらデプロイされる」というものであった。「え？本当にこれでデプロイされるんですか？え？え？」と何度も聞き直したのを今でも覚えている。今の自分の担当している各開発環境では CI が回っているので、git に push したら自動的にデプロイされているのでコマンドすら不要だが。ちなみに、人によっては、こういう CI によるデプロイスタイルは「Web 系のスタートアップだから出来る話で大企業だと無理なんですよ！」とか言うかもしれないが米国の銀行とかは既に一日 10 デプロイくらいされているシステムもある状態とのことなので、進んでいるか遅れている、という観点だけだと思う。

他にもツール面での差異は色々とある。コミュニケーション面で Mail は存在しなくて全て Slack だし、Excel / word も GoogleSpreadsheet / doc に置き換わっている。タスク管理ツールは前職も Redmine で、今は Backlog とか Trello とかなので、そこまで大きな違いはないように思うがすべてを Web ベースに行うイメージが強い。

仕様を削っても良いというパラダイムシフト

さて、開発を担当し、ゴリゴリ実装を進めるが「実装する量が多く時間が足りないので、残業や土日出社するも開発が終わらないっ！！！」というときがあったが、プロダクトマネージャー的ポジションの人に報告した結果、一言「仕様を落としましょうよ」と言われてこの件は終わった。SIer 上がりの人からするとこれはかなりの衝撃であると思うが、Web 系では仕様は調整可能なスコープなのである。というよりも、アジャイル開発においては、だが。もちろん今の自分は仕様を削るという思考は当たり前で、というかむしろ推奨されるべき行為であり、仕様を聞かされてコードを書く前には、まず何より仕様を削るところから始めるくらいにまで思想が習慣に刷り込まれた。だが、その当初はものすごいパラダイムシフトが自分の脳内で起きていたことを覚えている。

スマホゲーム開発

Web 開発でほぼ 0 から１つのサービスを作ってリリースしたわけなのだが、次はスマホゲームチームでの稼動となった。

スマホゲーム開発だと、Web サービスと違って時間に対する制約がより厳しくなるので、むしろ SI チックな開発に少し戻ったように感じた。スマホゲームだと事前にイベント時期や新機能の通知をユーザに行うため、この期間を越してしまうとユーザ体験を悪化させてしまう。とはいえ、スケジュールを決めても仕様や品質も調整しないと、それを守るのは無理なものは無理、という点はご存知の通りなのだが。しかし、ビジネスの特性上、スケジュールのウエイトが Web サービスよりも高く感じた。

どういうプラクティスでここの問題はを解決するか？という点が、少なくともここの現場ではなく、スケジュールの遅延による問題意識があるものの改善施策にまで至っていない状態だったので、もしかすると他のスマホ開発の現場ではそれなりにプラクティスがあるようにも思う。というのも、自分がこの課題を感じて調べても何個か案が思いついたわけなので。結局は自分が取っていたやり方は、この現場的に一番導入コストが低く感じた方法として、出来る限り仕様を落としてからリリースして徐々に肉付けを行うという、Web サービス系の開発の王道をそのままスマホ開発にも当て込んだ動きで開発は進めた。

他社の事例を聞くと、使う技術をあえて枯れた技術にすることにより技術の不確実性を減らす方法と取っている会社もあるみたいだ。この方法は、エンジニア視点だと、「ゲーム開発を行いたい」という欲求だけの人は良いとは思うが、技術的にニッチで枯れているものを学ぶわけなので、エンジニアの成長という観点では不安を感じるし楽しくなさそうなので、少なくとも自分はそういう会社や仕事を行いたいとは思わないな、と感じる。

また、仕様と優先度の変動がものすごく大きかった。これはゲーム開発、というよりも内部制作でのあるあるの問題なのか会社としての問題なのかわからないが。スマホゲームの開発となると、仕様をリーンに削っても一つ一つの機能はそれなりに大きくなってしまう。

そのため、A 機能を作っている途中で、トップダウンで

「優先度が変わったので、A は放置して良いので、B を作成してください」

となり、B を作成している途中で

「優先度が変わったので、B は放置して良いので、C を作成してください」

となり、そのあとも（ｒｙ。となるケースが多かった。

「ゲームを作りたいエンジニア」がもしコミットしていたら、ストレスがすごそうだなーとは思いながら、「成長したいエンジニア」である自分は淡々と仕事は進めていたが。

また、スマホゲーム開発は規模が大きい分、担当する領域が生まれてしまう。Frontend / Designer / Backend / Infra / Planner / Debugger / Marketer … etc。小規模な Web サービスならフルスタックと言われる技量を持っている人なら 3 役くらいは兼任できたりするが、スマホゲームでは多くても 2 つとかだと思う。なぜなら、そもそも実装する大きさが大きいので技術力的に出来るか否かよりも、時間的な制約が強いので。そのため、完全にチームでの開発が前提・必須となる。

自分の傾向として、「出来る限り自分で全部やりたい」「不明瞭な点があるのが気持ち悪い」という点もあるので、Backend を中心にフルスタックになれるように領域を伸ばしたい。

求められる技術領域と根本的な開発サイクルの違い

Web サービス系とスマホゲーム系を比較すると掲題の通りで求められる技術領域とビジネス要件が異なるので、言語が同じだからと言って同じような開発スタイルであるとは思わないほうが良い。

Web サービス系は、実装速度こそ命。という観点が強かった。機能実装もライトなものが多く、プロジェクト感で共通して実装したい点も多い分、高度に抽象化されたライブラリも多くある。

スマホゲーム系では、実装速度を上げる代わりに品質を下げるという戦略はまず行われないし、一つ一つの機能がヘビーなので必然的に１つの担当あたりの実装時間やデバッグ時間なども長くなる。マーケティングの観点で新しい機能をリーンで小出しにリリースするよりも、大きく１つの機能として出したほうがユーザーインパクトが強いので戦略的に仕様をリーンにしない場合もある。また、ユーザがチートをするのが前提なので初期の設計時から強く意識していないといけない。データアクセスに対しても一般的な Web サービスとは比較出来ないほど圧倒的に多く、かなりデリケートに考える必要があるので、DB 設計で意図して正規化を行わないこともあるし、Cache 化を初期の時点から行わないといけないものもある。

結論、深く物事を考えないといけないスマホゲーム系と、素早く数多くの機能を手がけていく Web サービス系、という点が、根本的に違う。

両方を経験して、今の自分は数多くの色々な経験を行いたいという希望があるので、今後は Web サービス系を中心に仕事を行いたい。

4. ニッチ技術

この会社に入る大きな理由の一つとして、ニッチ技術を取り扱っているという点にあった。

前職は SIer で国際決済に関する会社の業務を行っていたが、ここのジャンルが国際決済の中でもかなりニッチで日本でも 2 社しか取り扱っていないようなもので、大手のメガバンについては、ほぼこの会社が独占している状態だった。尖っているからこそハマれば強いが、逆に潰しが利かない、などの特性があるこのニッチ戦略というものについては理解していて、SI→Web 業界の途中でのキャリアチェンジにあたり、この戦略を取った。

結論、求めていた技術のポジションを勝ち取ってアサインされ、業務を通してかなり学べたし、それに対しての有意義な気付きを得られた。

ニッチ技術保持者の人的価値

自分はこの会社を離任するが、別に転職するわけでもフリーランスになるわけでもない。ニッチ戦略が有効だったかどうか？は、自分が転職したりフリーランスとして仕事を受注するときの判断材料としてどう見られるか？となる。そのため、ニッチ戦略を取った結果がどうなるか？という点のジャッジを行うには今の時点では時期尚早であるので、これは後日、ジャッジ出来るタイミングにでも書こうかと思う。

ニッチではなくエッジ

自分がこの会社に入社する際に先程からニッチと言っている技術に関して調べたが、確かに導入実績がかなり少ない技術であったので、「この技術はニッチ技術だ」と自分がジャッジして、入社したわけだが、正確にはニッチ技術ではなく、Cutting-edge と言われる先端技術であった（以降、エッジと記述）。 ニッチ技術が「需要と供給の母数が少ない技術」だとすると、エッジ技術は「年齢が若い技術」だと言える。エッジ技術は他にも、導入実績が少ない分ナレッジが少ない・そもそもエッジ技術が一般的に広がるかはわからない・機能アップデートに対する変更が破壊的なケースが多くアプリケーションへのメンテコストとキャッチアップコストが高い、などが挙げられる。 エッジ技術は全て英語での情報収集なので自分の英語力（笑）も少しは上がったような気にはなる。また、社内では神のようなフルスタックなテックリードが一人居て、この人が数少なくエッジを追える人なので、会社レベルでの新しい技術選定という意味合いでもこの人が会社の技術を引っ張っていたようなに見える。

エッジ技術を追っていての気付きをまとめる

英語力が必須

よく「エンジニアは英語力が大事！」と声高に求められている以上のレベルがエッジを追うには必要だと感じた。具体的には、リスニング／速読／精読。

リスニング：カンファレンスで言語／FW の重要な意思決定や理由の説明を話すし、貴重なナレッジもここにかなりの数がある。

速読：本／ブログ／フォーラムなどの大量の情報から重要な情報をピックアップしつつ読む力。エッジはリソースが少ないと言ったが英語でならそれなりにある。

精読：ドキュメントの内容によっては抽象的な定義で説明されているものもある。抽象を抽象のまま英語で理解できるレベルがないとそもそも理解できないし、具体例だけ見ても応用が効かない知識になりかねない。わかりやすく噛み砕いたドキュメント量も少ない。

楽しい

個人的な感想だがエッジ追うの楽しい。追加される機能は基本的に技術トレンド的に先端技術なので、有用なものが多いしワクワクできる。

基礎がないと辛い

エッジは基礎技術の詰み重ねや既存技術の解決として生まれるので、基礎や既存に対する理解が浅いと背景知識が乏しい分、理解が腹に落ちにくい。

ぼっちでエッジを追うと寂しい

自分が取り扱っていたジャンルについて社内ではテックリードの人くらいだった。が、他にこの技術のエッジを追う人が居なかったので、こっちからメンバーへの一方向なエッジな知識提供になるケースが多いし、なによりぼっちで追うのは少しさみしかった。

エッジを追う人は技術力が高い

というケースが多い印象。というのも、基礎ができてる人がエッジを追っているケースが多いのでスタートラインの時点でレベル高い人が多いし、そもそもエッジを追う人は技術好きな人も多いので、という印象。

結論

結論、エッジ技術を追うのすごい楽しいし、ここのテックリードの人を見て憧れたのもあり、今後も

「エッジを攻めるエンジニア」

という方向性で自分の成長を進めていきたいな、という希望はかなり強くあるが、それとは別にエンジニアの生存戦略の一環としても「海外でも働けるようになる」という点が今の進めたい方向でもある。そのために汎用的な技術に対する学習を中心に行わないといけないなーという葛藤もあるので、悩ましい。

というわけで、この会社への入社目的として考えていた点については満たすことができた。予想していなかったが、これらとは別に「思考」も変わった点があるので、そこらへんの気付きも整理しておく。

5. 思考の変化

アジャイル的思考

この会社に来たから、というよりも、この業界に来ることによって思考に幅と深さを持つことができるようになった。とりわけ、アジャイルの考え方が自分の生き方に対しても影響を与えていると思う。

もともと自分の性格的にかなり慎重に物事を進める＋ SIer 出身もあり、固く物事を進める気質があったが今はまだ、経験主義的アプローチによる利点をロジカルに理解できたのもあり、頑固さが少しは取れたかな。とは思う。また、以前からロジカルな気質が強かったが、その点はより拍車がかかった感はある。

成長するために残業する

以前は「圧倒的な成長には過酷な環境によるスパルタ式が大事」と考えていた。今でも、その思想は基本的には崩れていないが、最近は残業をやめて自宅での自習の時間を確保している。これは、アカデミックな学習による成長も大事、という観点の元だ。圧倒的な物量をこなすことで成長を促進したいときは残業しても手を動かし続けるが、アカデミック／業務外な学習は自習時間を確保して行う、という具合である。

自分の強み

環境が変わると顕在化していなかった、自分の強みがわかるようになった。

その上での結論、自己評価は「バランスが良い一人でも自走できるエンジニア」というタイプ。

もともと大手 SE で固い感じだったのもあり、「仕事の進め方」は十分に理解していただけに、Web での開発においても、そこは特にネックにならなかった。自分としては普通に行ってる仕事の進め方も、この会社だとその基準に満たないものもかなりの数がいる分、数少なく仕事の進め方を理解している人間として重宝されたように感じる。

  • ロジカルシンキング
  • ビジネススキル
  • 改善的思考
  • 英語力
  • アジャイル思考
  • チームリーディング
  • etc…

ただ、上述の通り、周りの偏差値が下がった結果、繰り上がって自分が上位に来たに過ぎず、自分の能力が上がったから出来る、とか、そもそも自分がすごくできるから出来る、とかではないと認識している。

自走という観点では、自分が必要／やりたいとか思うものは勝手に一人で始めた。社長に「ルール変えました」的な感じで事後承諾でチームの運用ルールを変えたり、チーム勉強会から、改善活動などまで。自由に走れるフィールドと自走できる能力があれば、仕事も人生もそれなりに楽しく走れるものだと思う。

ちなみに、前職から物事に対する改善思考が強かった＋ Web 業界のアジャイルのナレッジを多く読んだこともあり、継続的な改善活動は好きなジャンルであることも改めての気付きである。

退職理由

さて、ここまでは会社での気付きについてであったが、ここからは退職に関する話などである。

退職理由は「英語の学習時間をきちんと確保するため」である。

自分のキャリアプランの中長期ゴールにて「海外でエンジニアとして活動している」というビジョンがある。

海外に出ることを考えると、いろいろなことを戦略的に考えないといけないが、その中でも海外ビザの一つにワーキングホリデーというジョーカーのようなカードがあるわけなのだが、これには年齢での制限がある。今の自分の年齢が 27 歳で、大抵の国のワーキングホリーでの使用可能な年齢は 30 歳の誕生日までである。そのため、海外に行くことを考えると、逆算して今の時点から語学学習への行動を起こさなければ間に合わなくなる可能性が大いに有り得るため、語学への学習に投資をすることに決めたわけだ。

これから

実践的に会話能力としての英語が使えるようになることを目標としてフィリピンに短期語学留学、を行う予定だ。

英語に関する学習方法をいろいろ調べたことがある人なら、「わざわざ海外に行かなくても、自習できるし、今の時代なら格安でオンライン英会話があるじゃん」と思う人も居るかも知れない。

今回の語学留学での目標は実践的な会話力なのだが、それとは別にテストフライトとして、英語での環境で海外で生活などもきちんと経験しておきたい。つまり「海外でエンジニアとして活動している」というビジョンに対してのテストフライト的なところである。

まとめ

「会社での気付き」「退職とこれからについて」などを書いたわけだが、それぞれについてまとめる。

やりたい方向性

まとめると下記が自分のやりたい方向性だった。

  • 実装中心のロール
  • Web サービス系での開発
  • 一人で全部出来るフルスタック
  • エッジを攻める

今後直近でやること

また、最終出勤日〜フィリピン留学までに時間もあるので、下記も行おうと思っている。

  • 英語学習
  • 技術学習
  • ブログ作成
  • 家を断捨離
  • フィリピン留学

あと、特に前々から社内でも新人向けにビジネス的観点でのポエムを書いていたり、この退職エントリを書いていて思ったのは、自分はこういうのを書くのが結構好きである、ということも気付きである。

さて、ここの会社でしか学べないことや経験できないことは色々学べたし出来たが、会社の規模拡大や IPO 準備してるところからも今後起きる可能性があるイベントとして「上場」というタイミングでもこの会社に居たいなー、とも思うが、それとは別に自分の優先したい点があるので、離任する形となる。

願わくは、ますますの発展を。

2018/11/07 並木 駿

PS：最初は勢いで書き始め、その後にアウトライナーを整えたが、結局一万字超の大作になってしまった。本当は分割して、それぞれで別々に書きたい思いもあるが、初めて書くきちんとした自分のブログの記事としてはこのままにしておくのも良いかな、とも思うのでとりあえずこの形にしておく。