転職の軸を定める

目次

概要

今回の転職の軸をどうするかを決めようと思います。

なぜこの記事を書こうと思ったのか

最近受けたカジュアル面談を担当していたCEOが、たまたま元人事兼エンジニアの方だったので、色々キャリアについて相談させていただきました。その際に以下のようなことを指摘されました。

• 0 → 1なら個人開発をいっぱいした方が良い。0 → 1できないのに、そもそも任せない。
• バックエンドはパフォーマンスチューニングの仕事とかも全然ある
• 事業ドメインに興味を持てなかったって言わない方が良い。入る前からわかったでしょって言われたら詰むだけだから。入ってみて実際にやってみていうのでも良いけど、どっちみし入る前にわからなった時点で評価は下がる。
• やりたいことの軸がはっきりしていないとすぐやめると思われる
• ユーザーの顔が見えないからやめるって理由はあんま良くない。どのサービスやってもどっちみしみえないから。ユーザーの顔はどのサービスに携わっても見えないって思っておいた方が良い。想像力の問題。想像力を掻き立ててサービスを作れるかの話。それができないなら想像力がないだけの話。
• 仕事なんで、っていうスタンスでやった方が良い。何が好きなのか自分で考える
• プロダクトマネージャーが決めたものをエンジニアは作る。エンジニアは降ってきた課題に対して、技術的でどうやってエレガントに解決するかに全力を振った方が良い。それがプロのエンジニア(プロマネが決めなくても自分で仕様は考えたいけどね)。
• 言っていることとやっていることに一貫性がないとダメ。何がやりたいかがわからないので、一貫性がない。意味がわからないなこの人、何考えているんだろうなって思われるだけ
• 会社に入ってどんなことをやりたいのか、やりたいことがはっきりしていないと、すぐ辞めると思われるし、入った後になんか違うってなってすぐ辞めてしまう。
• 自分が何をしたいのか、自分が行きたいところをもっと言語化した方が良い。

これを言われた時は、この人理論的すぎて無理だなと思ったんですけど、よくよく考えてみると確かにそうだなと感じました(ストレートに言ってくれて良い人だなと思ったけど、一緒に働きたくないタイプ)。改めて自分の軸を定めたいなと思い、今回記事にすることにしました。

これまでの経歴を振り返ってみる

今回転職の軸を定める際に、たまたまある記事を見ました。

転職する際に確認すべきは「どんな成果を求められるのか」と「業務の中に自分が楽しいと感じられるポイントがあるか」だ。今回の場合、この両方が自分には向いていなかった。

自分が何にモチベーションを感じるか、その業務に楽しいと思えるポイントはあるかを把握し、次に活かすことが大切だ。

個人的な意見だが、直感で少しでも迷いがあるなら現職に残ったほうがいいと思う。入社後に自分が選んだ選択肢を正解にしていく道もあるが、これは自分のモチベーションを上げる成果や楽しいと思えるプロセスが転職先にあることが前提だ。

tenshoku-antenna.com

この記事を読んで確かにそうだなと思いました。求められる成果が何なのか、その成果は自分のモチベーションを上げてくれるものなのか、またその成果を出す際に取り組む業務は自分にとって楽しいのか、やりたいことなのか、 ここを決めることで、楽しいと思える時間を最大化することができ、逆につまらない時間を最小化できます。ゆえに、QOLが上げることができます。

今までの経歴を振り返ってみて、どの成果に自分のモチベーションが上がると感じたのか、その成果を出す際にでどの業務が楽しかったのか、どの業務がつまらなかったのか(または不満だったのか)を考えてみます。

前職(ネットスーパー系事業)

どんな成果を出す必要があったか

• ユーザーや会社が求めている機能を、CEOやテックリード、プロダクトマネージャーと仕様を相談した上で、フロントエンド ~ バックエンドを通して実装すること

その成果は自分のモチベーションを上げてくれたのか

• 正直機能を作れても、成果自体にはあまりモチベーションを感じなかった。あ、できたって感じ。
• むしろこの会社の場合、状態に対してモチベーションが上がっていたと思う。
• モダンな環境でテストから実装までちゃんとやれて、初めて開発のイロハを学べている状態に対してモチベーションが上がっていた(TDDやOpenAPIも初めて知った)
• 超優秀なテックリードの方にレビューをもらいながら開発ができたので、自分の技術力が向上しているなと感じた。つまり、自分が成長しているなというところにモチベーションを感じていた。
• 徐々に難易度の高い機能を実装する中で、自分が成長しているなと感じたのが嬉しかった。

まとめると、「技術的にモダンな環境で、強強エンジニアにフィードバックをもらいながら自分が成長していることを実感できていることに対してモチベーションが上がっていた」ということがわかりました。成果というか状態や自分の成長ですね。つまり、この環境の場合、成果自体が自分のモチベーションを上げてくれていなくて、場の状態や自分の成長に足してモチベーションが上がっていました。場の状態や自分の成長に問題があると、一気に楽しくないと感じてしまうということですね。

成果を出す際のプロセスの業務において、どの業務が楽しかったか

• バックエンドでどんなロジックでコードを書けばエンドポイントをちゃんと実装できるかを考えるのは楽しかった。機能単位で考えるのが自分に合ってて楽しかった。
• どこにコードを書いたら他のエンジニアにとってわかりやすいか、どこにコードを書いたら問題があるか、どんな実装をしたら拡張性がって変更をせずに済むかを考えるのは楽しかった。
• どんなライブラリ群を組み合わせれば機能として成立するかを考えるのが面白かった。
• インフラ、DB、メモリ、アプリケーションなど、いろんなものを考慮しながら、組み合わせて機能を作る感じが楽しかった。
• テーブルの設計でどうすれば、仕様が変更してもある機能が増えてもテーブルを大幅に変更しなくても良いかを考えて設計するのが楽しかった。
• どんなインフラ構成にすればシステムが安定的に稼働するかを考えるのが楽しかった(実際にやったわけではないけど)
• デザインのような目にみえるものよりかは機能のような、目に見えないけど機能単位で考えられる抽象的なものの方が好きな気がする。

成果を出す際のプロセスの業務において、どの業務がつまらなかったのか(または不満だったのか)

• コードとは関係のない仕事(店頭調査や冷蔵庫の搬入、商品の梱包など)。これはエンジニアの成長という点でも関係ないので、嫌だった
• 好きではない場所での仕事。Door to Doorで1時間を超えると流石に嫌だなと思ってた。
• 出社すると自分の業務とはどうでも良い仕事(洗剤買ってたりちょっと梱包手伝う)をやらないといけないので、それが嫌だった。コードに集中したいというか、自分の業務で結果を出したいし成長を感じたい。なので途中からリモートしたいですと提案してリモートにしてもらった(そこら辺を理解してくれる社長でもあったので良い人なのは間違いない)。
• フロントエンドはデザインと紐付きすぎていて、デザインも考慮しないといけないからあんま好きではない。デザインって人の感覚に強く依存する。自分はこれでも良くねってデザインでも普通にダメだったりするからなんでやねんって思うことがよくあった。そこに自分の人生の時間を使いたくない。
• cssが嫌い。cssはいろんな書き方で目的のデザインを達成できるので、やり方に正解がない(まあ良いという書き方はあるけど)。あんまりそこのやり方に対してこだわりがなく、目的のデザインが成立してればよくね？と思ってしまうので、そこをうるさく言われるのが嫌だった。
• htmlでサイトの骨組みを作る際も、個人的には成立していればよくねって思ってしまうので、そこをうるさく言われても知らんがなって感じだった。
• 多分自分の中でcssやhtmlに関して何か強いこだわりはなかったんだろうなそこに対して面白いと思わなかったり興味がなかったためだと思う。
• 唯一フロントエンドで面白いなと思うのは、「ユーザーにとってどうやったら使いやすくなるかを考える部分」だと思う。ユーザービリティは割と好きかも。
• バックエンドが楽しいからバックエンドを専門的にやりたかったけど、会社的にはフルスタックな人材が求められる。フルスタックはどちらかのスキルがめちゃくちゃ向上するわけではなく、中途半端にスキルが向上するから、ある領域に特化して勉強したりがしづらく、かつある領域がめちゃくちゃできるって状態にはなりづらい。その結果、スキルがあまり向上しないから玉拾い的な仕事からなかなか抜け出せない(会社的にはそういう人を求めていたと思うけど)。
• 事業立ち上げたばっかのスタートアップが故に気軽に失敗ができる環境ではなく、大きな仕事をなかなかできなかった(これに関しては自分の仕事の実力にも原因があるけど)。
• バックエンドにこだわりを持ってレビューしてくれるのは嬉しかったけど、フロントエンドのcssとかhtmlに関しては興味なさすぎてもうええやん何回レビューやり取りすんねん、こだわり強すぎんねんって感じだった。
• テックリードの方と2人でやっていたけど、圧倒的な実力差があったり、相性が悪いと2人は辛いなと感じた。コミュニケーションを取りたいと思わないけど、難しい機能を任せられる、でも作った成果に対してはモチベーションが上がったりしないのですごい負のループだった。いろんな人に聞けたり、相性が良いと良いんだろうなと感じた。
• どのようなキャリアパスを目指せる会社なのかはめちゃ大事。バックエンドが専門的にできるようになったりクラウドインフラがめちゃくちゃできるようになったり、割とそっちに関心があるからそこを目指せる会社に行った方が良い。
• この時はフロントエンド5割、バックエンド5割くらいでやってたかも。入った当初はどっちもやりたかったんだけど、入って半年くらいしてから、バックエンドメインでやりてええと思うようになって、そっからフロント嫌だなと思うようになったのかもしれない。

前々色職(SaaS系事業)

どんな成果を出す必要があったか

• ユーザーや会社が求めている機能を、CEOやCTOと仕様を相談した上で、フロントエンド ~ バックエンドを通して実装すること

その成果は自分のモチベーションを上げてくれたのか

• 正直機能を作れても、成果自体にはあまりモチベーションを感じなかった。やっとできたって感じ。
• 成果というか、修羅場を乗り越えてきたCTOにレビューをしてもらいながら、自分が成長しているんだって感じることにモチベーションを感じていたのかもしれない。
• だんだんと難しいタスクに挑戦できることが嬉しかった。あの時はフル出社だったしコードを書くことに専念できたから、良くも悪くもサポート体制は充実していたと思う。CTOもこれはどっちでもいいよねってところに関してはフラットにレビューしてくれるし、優しく教えてくれるのですごいやりやすかった。

成果を出す際のプロセスの業務において、どの業務が楽しかったか

• 初めてReact * TSとRailsで難しい機能(ページネーション)とかを実装できた時は達成感がすごかった。
• この時はフロントエンドを7割、バックエンド3割くらいのレベルでやってた。この時はどっちもやりたかったので、どっちもできてよかった。

成果を出す際のプロセスの業務において、どの業務がつまらなかったのか(または不満だったのか)

• 割とビジネス色が強いエンジニアで実装できれば良しみたいなタイプだったので、コードがめちゃくちゃ汚かった。故にそれを読むのが辛かった。これサービス成長したら絶対リファクタリング必要だし、てか拡張性あるの？っていう話。
• ビジネスを進めることに重点が置かれていたので、拡張性を意識したコードを書いたり、TDDに乗っとてテストを書くみたいなのはなかなか教えてもらえなかったし、会社がそれを重視していなかった(テストを書かない文化の会社だったので、デグレしまくりだった)。
• 社長が論理的すぎて、一緒にやってて辛いなと思っていた。ただ、フル出社で顔が見える分まだ怖くはなかった。フルリモートで論理的で顔が見えないとまじで何考えているか分からなくて、怖いよ。その人のテンションも見えづらいし。
• 最後ら辺リサーチャー業務をやっていたので、エンジニアじゃなくね？と思ってモチベーションダダ下がりしていた。
• 事業を前に進めようって話をよく聞いていたけど、そこに全く興味がなかった。まずはエンジニアリング力を磨きたいってのが本音だった。
• 給与がめちゃ低いし、昇給の幅も小さかったので、そこもモチベーションが落ちる原因の一つだったと思う。

前々前職(クレジットカードの金融系事業)

どんな成果を出す必要があったか

• システムを安定的に稼働させるために、インシデントが発生したら保守すること
• 議事録を書く
• 庶務(ゴミ捨てや備品補助の注文、手紙配達や出力シートを整理して配布すること)を全うすること。

その成果は自分のモチベーションを上げてくれたのか

• 全くあげない。成果自体にモチベーションは上がらんし、成果を出すプロセスの業務もめっちゃつまらんかった。
  • IT企業に入ってコードを書きたかったのに、そことは全く違う部署に入れられたのでそもそも問題があった(配属ガチャは大企業を選ぶ際のデメリット、ただ大企業は人の質は良いと思う。同期や先輩はすごい良い人ばかりだった、ただ業務がつまらなかった)。
  • てかそもそも自分がどんな仕事をしたいのかもまだ定まってなかったし、その時は彼女がいて彼女と一緒に楽しく人生送れればいいなって甘い考え方をしていたので、そこにも問題があると思う。結局人生の大半の時間は仕事なので、仕事が楽しくなかったり自分がやりたいことではないとそもそも自分の人生を楽しいと思えないし、その分を彼女との楽しい時間で補おうとすると余計彼女に執着して良くない関係になってしまう。自分は、自分のやりたい仕事をやらなくても、プライベートを充実させて嫌いな仕事でも適当にやろうと考えることができる人間ではなかったんだな、自分の人生を向上させたいなら、自分のやりたい仕事をやる必要があるんだなとそこで実感した。

成果を出す際のプロセスの業務において、どの業務が楽しかったか

• 楽しい業務はなかったが、強いていうなら、SQLのプログラムを作ってた時が楽しかった。

成果を出す際のプロセスの業務において、どの業務がつまらなかったのか(または不満だったのか)

• 庶務や議事録に関しては、なんでSEとして入ったのにこんなことやる必要があるんだよという気持ちが強かった
• 保守も、マニュアルが決まっていて、それ通りやれば解決するので、全然面白くなかった。不規則なタイミングでインシデントが出るから夜に急に対応したりして、インシデントに人生振り回されている時間が無駄すぎて嫌だった。
• 新しいツールの導入に反対するような保守的な文化だったので、そこもあまり自分にあってないなと感じた。新しいツール導入すればもっとコミュニケーションが潤滑になって仕事の生産性が上がるのにと思っていた。
• 割とめんどくさい仕事は後輩に押し付ければ良いやの精神の人が先輩に多くて、自分は、「根本的にこの庶務のプロセスがどうやったら楽になるか、またどうやったら庶務をしなくて済むか考えようよ」ってタイプだったので、全く合わなかった(議事録書くのが嫌すぎて、課長に議事録を楽にするツールを提案して、導入してもらえたのは良い思い出)。
• 企業文化が保守的だと、保守的な人が集まる。その人たちは変化を恐れるタイプだと思う。まあめんどくさいのは分からなくはないが、実際にやっている身としては嫌だった。生産性はどんどん向上させた方が良い。

仕事をしていた際の反省点

前職を通して、「毎日運動する」、「健康的な食事を摂る」、「仕事が終わったら仕事のことは一切考えないで別のことを考える」を実践すれば良かったなと思いました。

「毎日運動する」を選んだ理由としては、運動すると運動することに必死になって考えることをやめようとするのが良いなと感じたためです。あと体力がないと長時間仕事したりするのが辛くなるので、運動は継続してた方が良いなと感じました。

「健康的な食事を摂る」を選んだ理由としては、食事は自分自身のモチベーションを上げてくれたり、体の体調が良くなったりして、結果的に仕事のパフォーマンスに直結するためです。

「仕事が終わったら仕事のことは一切考えないで別のことを考える」を選んだ理由としては、仕事が終わったら仕事のことは一切考えない方が、メリハリが効くし、視野が狭くなって思い詰めなくても良いためです。仕事以外に必ず楽しいイベントだったり、仲良い人と話す時間を週に1回は作った方が良いなと思いました。あと運動している間も仕事のことを考えなくて済むので、運動も良いなと思いました。

転職の思考法を読んで今の自分のフェーズにあってそうだなという考えをまとめる

市場価値について

市場価値の高い人は、ざっくり以下の傾向がある

• 会社を変えても価値のあるスキルを持っている
  • つまり世の中の流れに合っている技術を扱っている。
  • そのスキルの賞味期限はいつまでか
• 他の会社でも通用する「レアな経験」がどれだけあるか、その経験は世の中からどれだけ強いニーズがあるか。
• 社内に自分が会社を変えても喜んで力を貸してくれる人がどれだけ存在するか。
• 自分が所属しているマーケットに今後の「成長性」はあるか
• 今後、どれだけ「自分の市場価値」は成長が見込まれるか？

どうやって市場価値を高めていくか

• 20代は専門性、30代は経験、40代は人的資産でキャリアを作れ。
  • 専門性があるから、難しい貴重な経験ができる仕事が降ってくる。人的資産はほどほどにしつつ20代で専門性と経験は欲しい。P.39に書いてあった

会社選びの3つの基準

• 市場価値は上がるか
• 働きやすいか
• 活躍の可能性は十分か
  • 「働きやすさ」は「市場価値」と相反しない。むしろ長期的には一致する。

活躍の可能性を確かめる3つの質問

• どんな人物を求めていて、どんな活躍を期待しているのか。
• 今一番社内で活躍して、評価されている人はどんな人か？なぜか？
• 自分と同じように中途で入った人物で、今活躍されている人はどんな社内パスを得てどんな業務を担当しているか。

会社を見極めるポイント

• 次の会社は長く勤めたいので、一番長く時間を過ごす現場のメンバーと会う会をセッティングしてもらうようリクエストした方がよい。
• 同業他社からの評判は悪くないか。

新卒で入るべき会社と中途で入るべき会社の違い

• 中途を活かすカルチャーはあるか
  • 役員が新卒出身者で占められている会社は要注意。
• 自分が行きたい会社の商品やサービスに触れてどこが好きなのかをメモする
  • そうか、エンジニア組織に強みを持っている会社だと、エンジニアが裁量権を持ちやすいってことか。
• どんな人材でも回るビジネスモデルかどうか
  • 転職する側からすると、市場価値が上がりづらいケースが多い

転職後の給料について

既に給料が高い成熟企業と、今の給与は低いけど今後の自分のマーケットバリューが高まる会社とで悩むなら、迷わず後者を取った方が良い。マーケットバリューと給与は長期的には必ず一致する。

being型

being型は、「どんな人でありたいか、どんな状態でありたいか」を重視する人。自分は確実にそっちやな。

being型にとって重要な2つの状態

仕事をRPGとして考えるとわかりやすい。

• 自分の状態(主人公は適切な強さか)
  • 自分の状態を強めたいなら、自分の仕事の面における市場価値を高めた方が良い。
  • その上で、仕事でつく嘘を最小化する(いくらマーケットバリューが高まり、自分が強くなっても自分を好きでなければ、仕事(ゲーム)を楽しむことはできない)
• 環境の状態(自分を成長させるいい緊張があるか)
  • より難しい業務をやったり、やったことのないことに挑戦できている。

being型の人間が好きなことを見つける方法

小さなやりたいことを以下の方法で探す。

• 他の人から上手と言われるが、自分ではピンとこないもの
• 普段の仕事の中で「全くストレスを感じないこと」
  • css嫌いすぎるし、苦痛。レイアウト組むの面白いって思わないし、これ別にこういうレイアウトでもよくね？と人の感覚に左右されることがあるので、フロントエンドは絶対向いていない気がする(人生の時間の無駄だなと感じる)。何よりも解決する課題領域が少ない。例えばログイン機能を作ろうってなった場合、ログインページとログインフォーム、apiを叩くロジック、リダイレクトさせて、別の画面にいく処理くらい。 バックエンドだったら、テーブル設計、DBとの接続処理、メールを送信する処理、スラックに送信する処理、セッションを作る処理、ユーザーに適切なjsonを返す処理など、いろんなシステムが組み合わさって一つの機能を作っている。それが面白い。

自分にラベルをはれ

• 変えのきく存在から脱出したければ、自分の好きなこと、苦にならないことを「ラベル」にして貼れ。

  • 自分の好きなこと、苦ににならないことって、なるとやっぱバックエンドとかクラウド領域か。

• ラベルに書く内容は、理想が入っていても、まだできないことでも構わない。

• ラベルをつけたら、「そのラベルがより強固になるか」という判断軸で仕事を選んでいくこと。

転職における失敗とは何か

• 選択が失敗かどうかは、あくまで事後的にしかわからない。失敗につながる唯一の条件は、「覚悟を決める時に覚悟を決められないこと」
• 転職を阻害するのは、現実的な危険性ではなく、ほとんどが見栄か恐怖

このラベルを貼るって考え方良いなと感じた。自分がバックエンドやサーバー、クラウドインフラ周りの専門家ってポジションを気付きたい。そこが一番苦にならず、楽しいって感じるから。

自分の就活の軸とは

これらを踏まえて、自分の思考には以下の傾向があるなと感じました。

• バックエンド(Rails, Rspec, AWS, terraform, MySQL)を専門的にやりたい
  • てことはバックエンドのポジションに応募するのは大前提か
  • クラウド系やDB、パフォーマンスチューニングの領域にも幅を広げていきたい。
  • 開発メンバーやCSメンバーの生産性が上がるような施策をサクッと実装できたら、意外と結構嬉しいかも。
  • バックエンドのポジションで成果を出せたら結構楽しい気がする。バックエンドの業務自体が楽しいから。
• 心理的安全性が欲しい
  • 具体的には、失敗しやすくてチャレンジしやすい環境か、ビジネスと開発組織がある程度分かれていて、バックアップ体制は存在するのか。
    • 少なくとも開発組織は8人くらい欲しい。バックエンドできる人は最低でも2~3人欲しい(1人だとその人に依存してしまう)。
  • おただやかな人が多い方が良い。理詰めで物事語りすぎる人はいないで欲しい。
  • お互いを尊重して、発言がしやすいエンジニアチームになっているか、
• できればテストやOpenAPIを書いている環境であってほしい。
• 優秀でかつ優しい人からレビューをもらいたい。
• コードとは関係のない仕事、自分の成長とは関係のない仕事はやりたいない。
• できればDoor to Doorで1時間超えて欲しくない。
• コードは綺麗であって欲しい。読むから。
• 給与は420以上が良い。
• 一緒にやるメンバーが論理的すぎない。長期的な視点を持つとやりづらいから。
• 開発組織がうまく確立されていて、ビジネスを前に進めようって意識を開発メンバーが持たなくても済むか。
• バックエンドとクラウド領域を磨けるか。
• terraformとAWSを使ってたら直よし。
• てか長期的に働ける会社が良い(最低でも2年)
• 今は事業を作っていくより、エンジニアとして成長したい。そこがあっている会社が良い。
• プロダクトを重視する考え方はあんまやめた方が良い。それよりも大事なものはいっぱいある。フリーランスになったらプロダクトはどうでも良くなるから。そこに楽しみを持ってはあかん。もっと技術寄りな部分が好きだと思う。目的はプロダクトの向上だけど。プロダクトってそれくらい。だから、そこをメインにしてはあかん。
• コードを書きたいと言うか、課題を解決できるようなコードを書きたい,

全部が全部揃ってなくても良いんですけど、

• バックエンド領域を専門にやれて、クラウド系やDB、パフォーマンスチューニングの領域にも幅を広げられる
• 心理的安全性がある。失敗がしやすい。自分よりできるバックエンドエンジニアが2 ~ 3人いる
• テスト書いてる(OpenAPI書いてたら直よし)。

ここら辺が揃ってたら全然ありな会社だなと思います。この3つを軸にしていこうと思います。 そう考えるとフルスタックの求人とかを応募すると、自分のやりたいこととは合わないかもね。フェーズはめちゃくちゃ大事。 プロダクトとかは正直どうでも良くて、自分のラベル(バックエンド、サーバー、アプリやテーブル、インフラアーキテクチャの設計、クラウド、パフォーマンスチューニングの専門家)を伸ばせるような環境なのかを重視している気がします。

転職面接の際にしたい質問

• どのようなキャリアパスを目指せる会社なのか？
• どんな人物を求めていて、どんな活躍を期待しているのか。
• 今一番社内で活躍して、評価されている人はどんな人か？なぜか？
• 自分と同じように中途で入った人物で、今活躍されている人はどんな社内パスを得てどんな業務を担当しているか。
• テストを書いているか
• (terraformやOpenAPIを導入していない場合) terraformやOpenAPiなどのツールは導入しても良いのか
• ジュニア、ミドル、シニアの割合はどのくらいか。リードはいるのか
• 開発組織や開発メンバーの雰囲気はどんな感じか。

もし受かったらしたい質問

• 実際のメンバーと会う会をセッティングしてほしい。

終わり

自分は結構、「尊敬する人やすごい人たちと事業の立ち上げに0から関われる、先の見えない感じが楽しそう」って思って直感的に会社を決めていたけど、それって「求められる成果が何なのか、その成果は自分のモチベーションを上げてくれるものなのか、またその成果を出す際に取り組む業務は自分にとって楽しいのか、やりたいことなのか」等の自分が実際にやる仕事を具体レベルまで落とし込んで考えられていないんですよね。そんな直感で選んでしまったことを今は反省しています。

事業自体に直感的に面白さを感じるのは別に良いですが、実際に自分がする業務はその事業を成立させるための一部の仕事なわけであって、その一部である仕事の成果に対してモチベーションが上がったり、その成果を出す際のプロセスの業務に面白さややりたいって感じないと、結果的に自分のやりたいことと違ってしまい、モチベーションが下がってしまったり、この仕事やりたくないなと思ってしまうんですよね。そのため、事業はよっぽど嫌いでなければ、もはやなんでもよくて、むしろ自分がどんな仕事を担当するのか、どんな環境なのか、ある程度バックアップ体制が整っていて失敗に許容かに重点をおいた方が良いのかなと、自分は割とそっちのタイプなのかなと思いました。

実際に自分がするのは事業を成立させるための一部の仕事なので、「その仕事の中でも、モチベーションが上がる成果はなんなのか、その成果を上げるためのプロセスの業務は楽しいと思えるなのか」その時間を最大化した方が良いです(おそらく)。次はそこを考えてから、会社を受けてみようと思います。

以上です。

参考記事

会社に入って何をしたいのかを言語化する