会社に入って何をしたいのかを言語化する
ハガユウキ元々人事をしていた人からの助言を以下にまとめる。
その上で自分は会社に入って何をしたいのかを考える。
ハガユウキ- 0 → 1なら個人開発をいっぱいした方が良い。0 → 1できないのに、そもそも任せない。
- パフォーマンスチューニングの仕事とかも全然ある
- 事業ドメインに興味を持てなかったって言わない方が良い。入る前からわかったでしょって言われたら詰むだけだから。入ってみて実際にやってみていうのでも良いけど、どっちみし入る前にわからなった時点で評価は下がる。
- やりたいことの軸がはっきりしていないとすぐやめると思われる
- ユーザーの顔が見えないってのはあんま良くない。どのサービスやってもどっちみしみえないから。ユーザーの顔はどのサービスに携わっても見えないって思っておいた方が良い。想像力の問題。想像力を掻き立ててサービスを作れるかの話。それができないなら想像力がないだけの話。
- 仕事なんで、っていうスタンスでやった方が良い。何が好きなのか自分で考える
- プロダクトマネージャーが決めたものをエンジニアは作る。エンジニアは降ってきた課題に対して、技術的でどうやってエレガントに解決するかに全力を振った方が良い。それがプロのエンジニア。
- 言っていることとやっていることが一致してないとダメ。何がやりたいかがわからないので、一致しない。意味がわからないなこの人、何考えているんだろうなって思われるだけ
- 会社に入ってどんなことをやりたいのか、やりたいことがはっきりしていないと、すぐ辞めると思われるし、入った後になんか違うってなってすぐ辞めてしまう。
- 自分が何をしたいのか、自分が行きたいところをもっと言語化した方が良い。
ハガユウキどういう系のビジネスがやりたいとかそこら辺は割とどうでも良いのかもしれん。
よっぽど好きではないビジネス(占いとかパチンコ)ではなければOK
ハガユウキBtoBtoCとは「Business to Business to Consumer」の略。
BtoBtoCサービスとは、『企業が個人消費者相手に商売するのを、手伝う商売』のこと。
なるほど、例えば、ドライバーを用意する会社がいて、その会社はある企業の商品をユーザーに届けるから、ビジネス的にはB to B to Cなのか。B to Bは、企業の課題を解決するようなサービスを得ること。
買った側の企業がB to Cの場合もあるので、売る側はCのニーズを踏まえた上で提案する必要がある。
ハガユウキ
これ結構参考になるな。
仕事でもプライベートでも、答えがない問題を解く際には、自分の美学や理念(何を大切にしているのか)をもとに、「自分がどうありたいか、何を求めているのか」という目的を最初に明確にしておくことが大事なんだなあ
(なにが「正解」なのかは、その人が何を求めるかによって変わるからである)
就活という答えがない問題を扱う際にも、この考え方は役に立つ気がする。
技術スタックがモダンだからとか直感で良さそうって思って会社を決めたり選考を進めることが多かったけど、それだと前職と同じ失敗を繰り返す。
その会社に入ってどんなことをしたいのか、どんな状態でありたいのか(バックエンドやインフラなどの自分が興味があることをメインでやれるのか、心理的安全性が高いのか)などの目的を明確にしてから、それに合うような企業を選ぶべきだったんだなあ。バックエンド領域をメインでやりたいって言ってたのに、フルスタックの求人ばっか応募してたから、目的は定まっているけど、目的に一致していない行動をしていたのか笑
(発言と行動に一貫性がない状態)
結局入ってみないとわからないことはあるけど、目的を明確にしてから就職した方が、後悔が少ない気がする。未経験の就活スタイルは数打ちゃ当たる戦法だけど、1年以上経験者の就活スタイルは目的ベースでやった方が良い気がする。
ハガユウキ自分にできることがX
世の中の流れがY
エンジニアでいうなら、Xは技術力などのハードスキルや、マネジメントなどのソフトスキルを表すパラメータ
Yは過去から現在を遡って、どんなタイプのエンジニアが年収高いか(どう変わってきたのか、何が違うのか)を表すパラメータ
ハガユウキバックエンドのみならずインフラなどの領域を広げられる経験を積むことが出来る環境に行きたい
ハガユウキ心理的安全性が高いというのは、このようにお互いが意見し、要求し合うようなイメージです。上司が部下に発言を促し、やさしく聞いてあげるということではないのです。
自分にとっての心理的安全性は、「失敗が許される環境であるか(チャレンジしやすい)」、「お互いを尊重して、発言がしやすいエンジニアチームになっているか、エンジニアの数が多いか(エンジニアの数が多いほど一人に依存しなくて済むし、1人の考え方に影響を及ぼされる心配もない)」、「人格攻撃をするような人がいないか」な気がするなあ。
ハガユウキ誰が言ったかは関係ない。部長が言ったからって、自分が控えめにする必要はない。
(日本では、「何を言ったか」よりも、「誰が言ったか」が重視されすぎてしまう傾向がある)
何を言ったかが重宝される。もちろん言い方は大事だが。
そういう前提を持った方が良い。
ハガユウキ心理的安全性を高める目的は、居心地がいい職場を作ることではありません。言葉のイメージからそのようなことを想像してしまうことがありますが、これは大きな間違いと言っていいでしょう。なぜ、心理的安全性を高める必要があるのでしょうか？それは、チームパフォーマンスを高めるためです。
心理的安全性の目的は居心地の良い職場を作ることではなくて、チームのパフォーマンスを高めること。
ハガユウキ１年〜３年：ジュニアエンジニア
４年〜７年：ミドルエンジニア
８年〜１０年以上：シニアエンジニア
なるほどねえ。
次転職するなら、ジュニア2 ~ 3人, ミドル 2 ~ 3人 テックリード 1 ~ 2人が良いな。
ハガユウキ組織にエンジニアは何人いるのか。そのエンジニたちのジュニア、ミドル、シニアの構成はどんな感じかを聞きたい。
ハガユウキ先輩から仕事を奪えるくらいがちょうど良い。
仕事の報酬はさらにでかい仕事(経歴書のネタになる)。
ハガユウキこの会社に入ってこの仕事をすることで得られる経験がなんなのかが、求人に書いてあるなら絶対見た方が良い。
ハガユウキ少なすぎる会社は避けた方が良いな。少なくとも開発組織は8人くらいいた方が良い。
バックもフロントもできるってなると、バグ修正や機能改善など、玉拾い的な仕事しか受注できなくなる可能性もある。しかも、どっちもやっているとどっちの専門性も中半端で伸びないから負のループに陥ってしまう。まずはバックの専門性を伸ばして、でかい仕事もこなせるようにした方が良い。
ハガユウキ- 理論的すぎて、相手の感情に寄り添わないで詰められるのはやだ
- スタートアップだと実力が全てだから、どうしてもそういう人が許されてしまう。
- 給料が少なすぎない。
- 今なら(450 ~ 500)かなあ
ハガユウキあの時の自分の反省点として、ストレスの解消方法を知らなかったこと。
今ならランニングがある。
ハガユウキ長く健康に働きたいので、体力と筋力はもっと向上させたい
ハガユウキ人間関係は大事。
ハガユウキてか次は最低でも2年以上はたらきたいな。
ハガユウキエンジニアが分かれて、小さいチームで開発する系の組織でも良いかも
ハガユウキスタートアップスタートアップしすぎていると、事業を伸ばすことをどうしても求められる。それがきちい。フェーズに着目した方が良い。開発に集中できるか。開発組織がある程度確立されている方が良いかも。
ハガユウキバックエンドエンジニアの仕事における大きな特徴は、「開発して終わりではない」という点です。
サービス運用中のセキュリティ管理や、障害発生時の緊急対応、サービスリリース後の仕様変更によるデータベースの再設計など、運用作業や保守作業にもかなりの時間を割くことになります。
開発して終わりではないっていう点が知らんかった。
ハガユウキ事業を作っていきたいのか、エンジニアとして成長していきたいのかどっちなのか。
個人的にはエンジニアとして成長したいだな。
ハガユウキ本当に解く必要のある問題なのか
楽しい時間を多くして、つまらない時間は可能な限り省略した方が良い。そのほうが人生単位でクオリティが上がる。
ハガユウキフィードバックは必ずもらった方が良い。
じゃないと自分の中で勝手に理想が高くなって、足元を見れない状態になるから。自分のプロセスを修正して向上させるとかもできないし。
ハガユウキこの人の考え方わかる。
何かになりたいわけではなくて、自分がやりたいって思うことをすぐやっていく人生でいたい。
(子供の頃にゲームに熱中してた感覚にちかい。ゲーマーになりたいからやっているわけではなくて、おもろいからやっているって感じ。)
今はバックエンドとかインフラだな。そこを面白いって感覚がある。
それを決めたら成長するために自分の時間を可能な限り投下する。
ハガユウキビューに焦点を置くフロントに比べ、バックエンドは機能を動かすということに重点が置かれますし
インフラ、DB、メモリ、ネットワーク、サードパーティ製のライブラリ… etc
様々な部分をデバッグの対象にする必要があるから。
デバッグとは、バグの原因を特定して、修正すること
何故ならバックエンドは機能が出来るか否かにフォーカスされやすいからです。
『ユーザーがアイテムを消せる』
『ユーザーがアイテムを使う』
『HPがゼロになったらユーザーは死亡する』
バックエンドはWeb技術全般に精通している必要がある。
自分の興味がある方向(RFCとかのWeb)に近い気がする。
ハガユウキバックエンドは機能を動かすことに重点が置かれる。
明らかに自分はそっちの方が向いている気がする。
ハガユウキ市場価値
- 会社を変えても価値のあるスキルを持っている
→ つまり世の中の流れに合っている技術を扱っている。 - そのスキルの賞味期限はいつまでか
- 他の会社でも通用する「レアな経験」がどれだけあるか、その経験は世の中からどれだけ強いニーズがあるか。
- 社内に自分が会社を変えても喜んで力を貸してくれる人がどれだけ存在するか。
- 自分が所属しているマーケットに今後の「成長性」はあるか
- 今後、どれだけ「自分の市場価値」は成長が見込まれるか？
どうやって市場価値を高めていくか
- 20代は専門性、30代は経験、40代は人的資産でキャリアを作れ。
会社選びの3つの基準
- 市場価値は上がるか
- 働きやすいか
- 活躍の可能性は十分か
「働きやすさ」は「市場価値」と相反しない。むしろ長期的には一致する。
活躍の可能性を確かめる3つの質問
- どんな人物を求めいて、どんな活躍を期待しているのか。
- 今一番社内で活躍して、評価されている人はどんな人か？なぜか？
- 自分と同じように中途で入った人物で、今活躍されている人はどんな社内パスを得てどんな業務を担当しているか。
会社を見極めるポイント
- 次の会社は長く勤めたいので、一番長く時間を過ごす現場のメンバーと会う会をセッティングしてもらうようリクエストした方がよい。
- 同業他社からの評判は悪くないか。
新卒で入るべき会社と中途で入るべき会社の違い
- 中途を活かすカルチャーはあるか
- 役員が新卒出身者で占められている会社は要注意。
- 自分が行きたい会社の商品やサービスに触れてどこが好きなのかをメモする
- そうか、エンジニア組織に強みを持っている会社だと、エンジニアが裁量権を持ちやすいってことか。
- どんな人材でも回るビジネスモデルかどうか
- 転職する側からすると、市場価値が上がりづらいケースが多い
転職後の給料について
- 既に給料が高い成熟企業と、今の給与は低いけど今後の自分のマーケットバリューが高まる会社とで悩むなら、迷わず後者を取った方が良い。マーケットバリューと給与は長期的には必ず一致する。
ハガユウキbeing型
being型は、「どんな人でありたいか、どんな状態でありたいか」を重視する人。自分は確実にそっちやな。
being型にとって重要な2つの状態
仕事をRPGとして考えるとわかりやすい。
- 自分の状態(主人公は適切な強さか)
- 自分の状態を強めたいなら、自分の仕事の面における市場価値を高めた方が良い。
- その上で、仕事でつく嘘を最小化する(いくらマーケットバリューが高まり、自分が強くなっても自分を好きでなければ、仕事(ゲーム)を楽しむことはできない)
- 環境の状態(自分を成長させるいい緊張があるか)
- より難しい業務をやったり、やったことのないことに挑戦できている。
being型の人間が好きなことを見つける方法
小さなやりたいことを以下の方法で探す。
- 他の人から上手と言われるが、自分ではピンとこないもの
- 普段の仕事の中で「全くストレスを感じないこと」
css嫌いすぎるし、苦痛。レイアウト組むの面白いって思わないし、これ別にこういうレイアウトでもよくね？と人の感覚に左右されることがあるので、フロントエンドは絶対向いていない気がする(人生の時間の無駄だなと感じる)。何よりも解決する課題領域が少ない。例えばログイン機能を作ろうってなった場合、ログインページとログインフォーム、apiを叩くロジック、リダイレクトさせて、別の画面にいく処理くらい。
バックエンドだったら、DBとの接続処理、メールを送信する処理、スラックに送信する処理、セッションを作る処理、ユーザーに適切なjsonを返す処理など、いろんなシステムが組み合わさって一つの機能を作っている。それが面白い。
ハガユウキ自分にラベルをはれ
-
変えのきく存在から脱出したければ、自分の好きなこと、苦にならないことを「ラベル」にして貼れ。
- 自分の好きなこと、苦ににならないことって、なるとやっぱバックエンドとかクラウド領域か。
-
ラベルに書く内容は、理想が入っていても、まだできないことでも構わない。
-
ラベルをつけたら、「そのラベルがより強固になるか」という判断軸で仕事を選んでいくこと。
転職における失敗とは何か
- 選択が失敗かどうかは、あくまで事後的にしかわからない。失敗につながる唯一の条件は、「覚悟を決める時に覚悟を決められないこと」
- 転職を阻害するのは、現実的な危険性ではなく、ほとんどが見栄か恐怖
ハガユウキいろんなサービスを組み合わせて課題を解決するとかも結構好きかも
ハガユウキ業務プロセスを改善するのも好き。他のエンジニアやCSとかにとって使いやすい構造を構築するとかも結構好きだと思う。
Railsとクラウド系のフリーランスになった方が良いな。そうしよう。そこをまずは目指そう。
そのラベルに合うような会社を目指そう。だからこそRailsとRuby力は死ぬほど磨いた方が良い。あとWebとかコンピュータの基礎知識。逆にフロントエンドとかはある程度理解しているので、今はもう勉強せんで良い。
ハガユウキそこをやらせようとしてくる会社はあわない。だから選んじゃダメ。
ハガユウキバックエンドはメモリとかHTTPとかTCP/IPとかコンピュータの基礎的な知識が求められる。だからこそ自分が興味があってやってきたことと重なる気がする。
ハガユウキGoもいいっちゃいいんだけど、Web開発に向いてねえ。
ゴニョゴニョ書かないといけないし、シナトラレベルのフレームワークしかない。
バックエンドはどうせテスト書くから、動的の方が楽。
VSCodeとRubyの相性が良くなれば最高って話。
ハガユウキどのようなキャリアパスを目指せる会社なのかはめちゃ大事。
ハガユウキWebサイトを中心に、〇〇が提供しているその他のアプリも含めたサーバサイドおよびフロントエンドの実装
↑ こういうの書いてあったら絶対向いてない。死んでも避けろ。
ハガユウキバックエンドとクラウド、AWSとterraformとか。今はそこだな。
ハガユウキ画像が重すぎる問題どうにかした方が良いな。
ハガユウキ人が少なすぎるのはダメやな。
バックエンドエンジニアはある程度5 ~ 6人いるくらいが良い。
ハガユウキバックエンドの魅力
バックエンドはシンプル。
- 機能単位でコードを書くことができる。受け付けるデータや返すデータ、どんな機能にするかが決まったら変わらない。フロントはデザインに紐づいているから、個人の感覚に依存する。
- こうあるべきが決まっている。
- Rspecやrubocopなどが良い。
- こう書いたらこうっていうのが出るのがシンプルが良い。
- アプリケーションの運用やアプリケーションの全体像がわかるようになって面白い。
- データベース設計とか、インデックスとかもできる。
- テストが自動化しやすい。
- フロントエンドは実際に人間が触らないとわからない
ハガユウキelastic-searchとrailsやってみたい。
ハガユウキ仕事以外のことを考える時間が必要。やっぱ体動かすのは偉大やな。
ハガユウキプロダクトを重視する考え方はあんまやめた方が良い。それよりも大事なものはいっぱいある。フリーランスになったらプロダクトはどうでも良くなるから。そこに楽しみを持ってはあかん。もっと技術寄りな部分が好きだと思う。目的はプロダクトの向上だけど。プロダクトってそれくらい。だから、そこをメインにしてはあかん。
ハガユウキコードを書きたいと言うか、課題を解決できるようなコードを書きたい,
受託はビジネスへの関わり方が薄いのはまさしくその通りだわ。
フルスタックエンジニアへのキャリアパスは明らかに今の自分が求めているものとは違う。
サクッとできたらすごい。
ハガユウキいつでもやめれるんだくらいの気持ちでいる。
人(エンジニア)の母数が増えた方が、良い人とか嫌な人とか気にせず済むかも。良い面の人も悪い面の人も当然いるって価値観を持った方が良い。
ハガユウキスタートアップってよりかは上場済みのスタートアップとかの方が今のやりたいこととマッチしているかも。フルスタックは自分のやりたいことと反している。rails.インフラ構築、db パフォーマンスチューニング
ハガユウキc向けの方がイメージしやすい。ドメインのレベルは簡単であると良い気がする。
ハガユウキどこかどからせた方が良い。
仕事の服装にも力入れる。
ちゃんとしている人だなと思われるために。オフィスカジュアルみたいな感じ。
ハガユウキ転職する際に確認すべきは「どんな成果を求められるのか」と「業務の中に自分が楽しいと感じられるポイントがあるか」だ。今回の場合、この両方が自分には向いていなかった。
自分が何にモチベーションを感じるか、その業務に楽しいと思えるポイントはあるかを把握し、次に活かすことが大切だ。
いわゆる「いい会社」というのは、企業規模や年収の高さではなく、自分が楽しさを感じる部分との重なりが多い会社を指すのだと思う。サラリーマン全員にとっていい会社などない。
ハガユウキ書類選考を応募してから、1日以上かかる
選考に進んでいただきましてありがとうございましたっていうタイトルのメール
それだと大体うまく行ってない可能性が高い。一つの会社に執着しない方が良い。
ハガユウキ志望動機に関しては主に2点ございます。
1点目は大規模なデータやリクエストを扱う〇〇のサービス(〇〇や〇〇等々)の開発・運用を通して、バックエンドエンジニアの専門性を高めたいためです。前職ではフルスタックに開発することはできたものの、広く浅くの開発スタイルであったため、得意な領域がない状態に不安を覚えました。そのため、今後のキャリアでは自分の興味のあるバックエンドを主戦場でやって行こうと決めました。バックエンド側のパフォーマンスの向上や新機能の開発を通して、サービスの価値向上に貢献できるように行動します。
2点目に関しては心理的安全性の高い組織に入りたいためです。前職では事業立ち上げフェーズの中でテックリードの方と2人で開発をしていたのですが、限られた予算の中で結果を出さなければならないため、失敗に許容的ではない組織文化になっていました。また、エンジニアの数もテックリードと私の2人であったため、もっと大人数のエンジニアと相談し合えるのが良いなと思いました。個人的には、もっといろんな仕事にチャレンジしていきたいと思っているので、前職のような組織よりかは心理的安全性の高い組織で色々なチャレンジをしていければ嬉しいです。そのため、今回、貴社に志望させていただきました。
志望動機に問題があったのかな。
フィードバック欲しいいい。
今考えると失敗できる場所とか言わない方が良いな。それ言っちゃうと、こいつ自走力ないのかなと思われる。
自己PRでは自走力とキャッチアップ力を売り込んだ方が良い。
ハガユウキGithubのurlとかそういうのもおくっとけばよかったか。ミスったな。
でも書類に書いているから、まあええか。
ハガユウキまじで理由も特に言わずにお断りだけは勘弁してほしい。
フィードバックがないとよくないと感じるところを修正して自分を向上させるのができない。
まあ、大前提思考が合わないってのも全然あるから、そこは問題ないか。
フィードバックがある会社がどれだけ偉大かを分かった気がする。
ハガユウキ今度フィードバックもらうときはこの記事のようにメールを送るか。
雑に送りすぎてしまったかもしれない。まあいっか。未練はねえ
ハガユウキ弊社はまだ人数も少なく、成長フェーズの方をお迎えしサポートするには環境として不足もあり、そのためご経験豊富な方を求めているのが現状です。
なるほど、つまり、人数が少ない会社はジュニア枠が少なくて、そのジュニア枠を抑えられると、経験豊富な人しか取らないってことか。なるほどな。
ハガユウキ今後の選考に役立てたいというお気持ちにこたえたいとも思いますが、各社の状況は様々ですので参考になることも少ないかとも考えております。
これは確かにそうだな。履歴書の書き方うんぬんてよりかは、会社がフェーズによっては、そのポジションの人材を求めていないケースを十分あるもんね。
ハガユウキとりあえず、志望動機とか、自己PRの問題ではないのが良かった。
ハガユウキ自分で舵を握っている感覚をもっと持った方が良い。
自分ならどうしたいんだろうって感覚をもっっと持つ。
ハガユウキ自分って成長フェーズの人間なのか。確かにそうだな。その成長フェーズの人間を経験豊富な人間にするにはバックアップ体制がどうしても必要やな。
ハガユウキ明らかにこれ無理やろって思う会社に対して、へんに期待をしない方が良いかも笑
受かったらラッキーくらいがちょうど良い。
良くも悪くも足元が見えなくなるから。自分を客観的に見れなくなる。バイアスがかかって自分を見ることになるから。
ハガユウキ正しいこと言ってたら、年齢とかそういうのは関係ない。
あとは言い方とかフォローとかそういうのを気にすればいいだけ。
自分の意見を言う前にまず相手の意見を褒めること。
ハガユウキどのレベルの人材を求めているのか、これを聞くのは結構ありな気がしてきた。