転職する際に調べたことをまとめた雑メモ 2023年6月26

目次
はじめに
転職する上で絶対に抑えたい点
改めて自分の価値観を整理する
Whyからはじめることで、感情を動かすことができる
ゴールデンサークルを通して知ったこと
人間の認知
ビジュアライズ
- ビジュアライズするためのアクション
なぜエンジニアになったのか
本当に作ることが好きなのか
どんなサービスを面白いと思うのか
心のブレーキを外す
心で記憶する
レンガ職人の話
その他の気づき
まとめ
参考記事

はじめに

転職活動を通して、考えたことをメモしようと思います。

転職する上で絶対に抑えたい点

最低限の給料が担保されている

お金は幸せの土台であるため。
そこが担保されていないと、機会損失をしたり、良いように利用されがちになる。あと、周りの人を信用できなくなる。

人が多すぎない

人が多いとバッターボックスに立てる回数が減る
とはいえ、極端に人が少なくてもやっていけるってレベルに自分は到達していない。人を育てる環境があって、かつ同じくらいのレベルの人がいる方が適度に競争が出て良いと思う。

わからないことをわからないと言える環境である

前職では自分で調べて考えた上でわからないと聞いても、「よく考えて」と言われる機会が多かった。もちろんどの物事に対して考えるべきか、そもそもの考える対象がずれていた可能性もある。ただ、上手くヒントを出して最適解に誘導するのが良いのかなと個人的には思う。このような環境は結構精神的にきつかった。

人を育てる環境があるか

創業間近のスタートアップを経験して、面白いなと思う部分もあったが、成長しているという実感があまり湧かなかった(ここでの成長しているとは、できることが増えたということである)。もちろん、拡張性のあるコードを書き方やインターフェース設計力みたいなのはついたと思う。退会機能やパスワードリセット機能など、重要な機能もできるようになった。ただ、もう一度再現しろと言われるとちょっとできるか不安である。コードレビューを通して指摘はされるのだが、なんでそうするのかがあまり印象に残らなかった。そう考えると自分ができるようになったことが増えている実感が湧かなかった。「自分で積極的に巻き取って自発的に成長する」という考えは根本にはあったが、創業初期のスタートアップではそういう人をサポートするだけの環境がないので、なかなか適度に難しいタスクを振ってはもらいづらい(もちろん自分がその人たちを信用させるくらいの結果を出せなかったっていうのもあるけど)。あと、他の理由もあるので、それについては、次の「そのサービスが好きか」でも深ぼる

そのサービスが好きか

今までエンジニアをやってて、自分の仕事が面白いなと感じることがほぼほぼなかった。なんなら、自分の時間を優先したいから、片手間でやっていた気がする。なんでなんだろうと考えた。

そもそもそのサービスが好きではないから
そのサービスを作っても誰かの人生を良い意味で変えたりしないから
自分が機能を作っても、誰かに良い影響を与えたり感謝をされたりしている実感がないから

という結論になった。やっぱり自分はそのサービスがなぜ存在するのか、そこが自分の価値観に合っていないとやる気が出ないんだなと感じた(もっと作りたいと思わない)。なので、転職する際はなるべくそこは合わせて行きたい。インタラクティブ動画もEC事業も面白いと思うが、なぜ存在するのかが自分の価値観と合わなかった気がする(つまり、このサービスが人に与える影響が自分が良いなと感じる価値観と合わなかった)。そう考えるとフリーランスとか本当に自分に合っているのかなと不安になってきた。他者に貢献できているからまだ良いのかね。未知すぎる。

その場にいる人が好きか

これは結構大事。サービスが不特定多数の人にどんな影響を与えているか正直分からない。しかし、自分がした行動が身近な人にどんな影響を与えているかは分かる。周りの人が好きだったら、より行動すると思う。だからこそ、その場にいる人が好きかは大事。

サーバーサイドをメインでやれるか

エンジニアを1年弱やって、フロントエンドはそこそこできるようになったと思う。しかし、サーバーサイドがまだ弱いなと感じる。サーバーサイドは機能を作る上で、とても大事。だからこそ、そこをもっと極めたい。色々な機能を実現できるようになりたい。なので、サーバーサイドは避けて通れない。サーバーサイドをやれれば良くて、なるべく言語に振り回されたくないなと思うので、Go, Ruby, TSあたりがやれれば十分である。

この章のまとめ

この章の話をまとめると、

給料
会社の規模
環境
サービスが好きか
人が好きか
サーバーサイドをメインでやれるか

以上の6点が自分にとって大事ということが分かった。もちろん、全部を満たすことはできないのは重々承知だが、極端な6角形を目指すのではなく、適度にバランスの良い6角形の会社を目指そうと思う。

改めて自分の価値観を整理する

最近アイスバーグ理論というものを知った。アイスバーグ理論をざっくり説明すると、一番下層の想いや人生哲学という土台がある人は、そこから行動や習慣など具体的なアクションを起こし、そのアクションによって能力が培われ、その能力によって成果をだすことができるという理論である。大きな結果を出すためには、仕事をするごとにこのアイスバーグを大きくできるのが理想である。

この理論を知った時にハッとした。なぜ今までやってきたエンジニアリングの仕事が楽しくないのかがなんとなく分かったからである。理由は、最下層の想いや人生哲学を意識しないでなんとなく仕事していたからである。技術がモダンであるかどうかとか、CTOなどの優秀な人が働いているとか、どんな仕事をするかとか、何(What)やどうやって(How)をすごく重視していた。または自分の想いや人生哲学に合っていないプロダクトをずっと開発していたからとも言える。What(自分は何の仕事をするか)やHow(自分はどうやって課題を解決するか)も大事だがもっと本質的に大事なのは、Why(なぜ自分はその仕事をするのか)だと気付かされた。もちろん、実力にあってない環境に自分を置いていたとか他の理由があるかもしれないが、この理由にはすごく納得できた。

自分のアイスバーグを作ってみた。上のアイスバーグの図とはちょっと違っていて、「思考」と、「なぜその価値観や想いが生まれたのか」を追加してみた。

原体験があるから、価値観や想いが生まれて、その価値観や想いがあるから思考が生まれて、その思考があるから、その思考を起点として行動をして、行動をするから能力がついて、能力によって成果が出る。

いかに図の内容をまとめてみる

成果
- 事業を立ち上げたばっかのシードスタートアップを2社経験した
- どちらも0→１を経験した
- Next.js, TS, Rails, MySQLで基本的な機能なら「仕様の決定→開発→テスト(TDD)→リリース」できる
- ex) 退会機能の作成、パスワードリセット機能の作成、メアド変更機能の作成、店頭調査向けサービスを一人で一から開発した
能力
- Next.js, TS, Rails, MySQLの基本的なコードは書ける
- インフラはまだまだ。Dockerはちょっとわかる。インフラを作るとかはできない
- Webサーバーとか全体がどんな仕組みで動いているんだとかの理解は甘い。
- CI/CDとかもできない
- デザインは全くできない
行動
- プログラミングで自分や他者のアイデアを瞬時に実現できるように学ぶ
- 欲を言うとデザインとかも自分でできるようになりたい
思考
- テクノロジーで人の人生・生活を変えるような革新的な価値を0から生み出したい。(テクノロジーと自分の相性が良かったからテクノロジーを選んだ)
- 自分の行動や力による実現によって、人に良い影響を与えるような仕事をしたい
価値観・想い
- 人の人生や気持ちを自分の行動や力でいい方向に変えたい。
- 人がこうありたいって思う理想の状態(アイデアとかも)を自分の力で実現させたい。(その人が頑張っているのに、結果が出ないとか、大変な思いをしているなら、より自分の想いが乗ると思う。こんなことが起きていいはずがないと)
なぜその価値観や想いが生まれたのか
- 浪人生時代に、たいして頭が良くなかった自分のために、親、友人、予備校の先生、チューターの方等、色んな人が応援してくれたり、勇気づけるような言葉を送ってくれた。自分のことを信じてくれた。だからこそやり切ることができた。自己実現することができた。そのような過去の経験があるから、「こうありたい！」って思って頑張っている人を見ると、応援したくなるし、全力で力になりたいなと思う。

アイスバーグを作ったことで、自分が現時点でどうなりたいのか、何をしたいのかがわかった気がする。人がこうありたいって思う理想の状態(アイデアとか)を、テクノロジーを用いて、自分の力で実現すること。その結果、他者に良い影響を与えることができる。実現できること、良い影響を与えることができることに喜びを感じるのかもしれない。根本的に解決するようなアイデアを自分で考えるところまでやれると、より理想の状態を実現できる力がついて楽しそう。 そう考えると、何を勉強しないといけないのかも見えてくる。パフォーマスチューニングも大事だが、自分の場合、まずは新規サービスを作るための周辺知識を持つ必要があるなと感じる。

今までは金を稼ぐことに執着していたから、ここの価値観がいまいち定まってなくて、何を勉強すれば良いのか、どうすれば仕事を通して幸福度を感じられるのかが分からず、なんとなくモダンだからとか興味があるからとか、金が稼げそうだからとか目先のことで勉強していたと思う(WhatとかHowしか見えていない)。価値観がはっきり定まることで自分の方向性や何をやりたいのかが見えてきた気がする(Whyにフォーカスしている)。

昔、上司に「私たちは未来を作る仕事をしているんだ」と言われたけど、今ならなんで言っていたかがわかる気がするな。その時の自分は価値観レベルで自分の仕事をできていなかったんだと思う。

Whyからはじめることで、感情を動かすことができる

先日TEDを見て、ゴールデンサークルというものを知った。ゴールデンサークルとは、「What → How → Why」の順番で話すのではなくて、「Why → What → How」の順番で話すことで、人の感情を動かす話ができるという理論である。

普通の人は何か人を動かそうとした時に、Whatから話そうとしている例えば、なぜ私たちの会社が良いんですかと面接で聞かれた時に、「技術のスタックが自分が経験してきたスタックに合っているのと(What)、〇〇というサービスを用いて課題Aを解決しているところにすごさを感じて、開発に携わりたいと思ったからです(How)」と合理的な理由を伝えようとする。

もちろん合理的なことは良いことである。しかし、これを話すとその人の感情に訴えかけることができない。ゴールデンサークルに従って話した場合、「私は御社の”テクノロジーで革新的な価値を生み出す”という理念を信じています。EC事業の構築や、インタラクティブ動画プラットフォームの作成によって、多くのユーザーが直面している課題を解決してきたからです。御社の取り扱っている課題Aは、とても解決が難しい課題だと個人的に思います。しかし、その課題を解決することで、〇〇な人が快適に作業できるような社会が実現できると良いなと私も思います。そこで、私が持つ今までの0→1を構築してきた経験によって、課題解決するプラットフォームの実現に一人のエンジニアとして貢献できたら嬉しいです。」

例の話は長いが、要するに、なぜこの会社がこのビジョンを達成したいのかに対して、理由を持って賛同しつつ(Why)、私がそのビジョンを実現するためのサービスに対して、どのように協力するのか(How)、何をするのかを説明している(What)。その結果、相手の感情に訴えやすくなっている。上の話はあくまで例だが、ゴールデンサークルの構造、つまりWhyから話すことで、人の感情に訴えやすい話が作れる。結構難しいのが、面接の場合は対話なので、台本を用意している感じで話すと、用意してきた感が出てしまい、熱が伝わりづらい。

あと、話が長くなりすぎると結局何伝えたいの？ってなりがちなので、そこは気をつけたい。

ゴールデンサークルもアイスバーグ理論も似ているな。どちらもWhyにフォーカスしている。ゴールデンサークルの場合、Whyが真ん中にあって、アイスバーグ理論の場合、価値観を形成する理由がWhyになっている。

ゴールデンサークルを通して知ったこと

人は「何を」ではなく「なぜ」に動かされる。そして自分がその価値観を信じているということを行動で示そうとする。
人はWhatの情報から、その製品の良し悪しを判断できない。この製品のここが優れていると言われてもよく分からない。

人間の認知

ゴールデンサークルの理論は生物学でも証明することができる。人間の認知は以下の順番で行われる

目や耳から情報を得て、大脳辺縁系という脳の中心部に近いところにまずは情報が入る。つまり、まずは無意識の部分で情報を認知する。大脳辺縁系は食欲や睡眠等、感情を司る部分。
大脳辺縁系に行った後に、大脳新皮質という脳の外側の部分に情報が伝わって、初めて意識的に情報を認知することができる。大脳新皮質は新しい情報を記憶したり、論理的に考えるために使われる部分。

この結果から、人は何か物事を論理的に決める場合、論理的に決める前に感情を司る無意識の部分の影響を受ける。Pepper君を開発したGROOVE Xの林氏によると、物事を実際に決めているのは無意識層で、実際は意識は決めていない。つまり、人の意思決定は意識できる論理ではなくて、人の全ての意思決定は感情がおこなっている。この結果から、自分の意見を通したいなら人を動かしたいなら、人の感情を動かすのが大事。論理は「無意識で決めた」ことに対して後付けでついてくるだけ。

ビジュアライズ

ビジュアライズとは、情景が目に浮かぶように具体的に話すこと。ドラマのワンシーンのように鮮明に場面が浮かぶことで、より人の感情に訴えかける話になる。ビジュアライズで心が動く理由は感情移入できるから。人は無意識に、人の話をもし自分だったらと置き換えています。「もしこの人が自分だったら」と考えているからこそ、ドキドキしたり涙が出る。そのときは具体的な場面が多ければ多いほど感情移入しやすくなる

ビジュアライズするためのアクション

ストーリーを作る
- ただの事実だけではなくて、自分のストーリーを話す。起承転結がしっかりしているとなお良い。起でおこして、承で起を承ってふかぼったり広げたり、転で変化を起こして、結で終わらせる
ドラマの一場面を見せるように具体的に話す
- その時の場面を相手が想像できるように具体的に話せば良い
心の声を入れる
- 心の声を入れると、より聞き手が感情移入できるようになる。「もう無理だと思った」とか見たいな心の声をたくさん入れる。人は共感力の高い生き物なので、嬉しい、悲しい、楽しい、つらいというような感情を見ると、誰しも心が動く。
表情、声のトーンで再現する
- 声の強弱を作って話す

人の心を動かしたいなと思ったならば、自分の話が鮮明に浮かぶほどビジュアライズされているかが大事

なぜエンジニアになったのか

大企業自体にSEの仕事をしていたが、スキルのたまらない仕事だったので「この生き方をしていると、クビになったときに人生詰むな」と危機感を感じたため。
塾講をしていたときに、数学や教えるというスキルを使った仕事をしていたので、スキルを使った仕事が向いているのかなと感じたため。
数学とITに親和性があったため、ITもいけるでしょと感じたため。
サービスを実現することによって、人の生活を変えたり、人の理想を実現したいと感じたため。

本当に作ることが好きなのか

作ることが好きというか、サービスの実現を通して、人の生活を良くしたり、人の理想の状態を実現できることに喜びを感じるのかもしれない。なので、今は、いかに人のアイデアや自分のアイデアを瞬時に実現できるかができるようになりたいなと思っている。作ることだけが好きというか、作った後に実際に役立ったり感謝されないと、何のために作ってるの？ってなってしまう。作ること自体が好きなんじゃなくて、作ることが実際の誰かに役立ってないと意味ないと思ってしまう。これは知り合いのパン屋も同じことを言っていた。パンを作って終わりじゃなくて、パンを作って美味しいよとか言われないと、モチベーションが全く上がらないって言ってた。
もちろん速さだけではなくて、そのサービスが長期的に運用されるように、ソフトウェアが拡張的に設計されていること、実装されていることはマストである。

どんなサービスを面白いと思うのか

分からん。サービスが面白いというよりか、サービスが実現できること、サービスを実現したことによって、人の生活が良くなったり、人の理想の状態を実現できることに喜びを感じるのかもしれない。

今までの話を通して、自分は受託気質が強いんだなと思った。ただ、今まで自社開発で働いていた経験から分かるけど、自社開発に行くなら、自社プロダクトが好きってことが必要だと思う。じゃないと、自分ごとで改善したい、開発したいって全然思わないからである。

心のブレーキを外す

「自分は何を大事にしていて、何のために何をしたいのか？」そこが分からないと、行動にブレーキをかけがち。つまり、迷いがあるからブレーキをかけてしまう。迷いがなくなればブレーキがなくなるので、悩みにぶつかってもアクセル全開で今の道に行くか、別の道に行くかを決断することができる。ブレーキがなくなれば、ぐだぐだ悩まずに、この道を進むんだと決心することができる。

心で記憶する

たとえば本で「Gitがどんな仕組みで変更を管理しているか」を見ると「Gitの仕組みとは〜」が文字と図で書いてあるだけで、そこには感動がない(もちろん短期的には身についている感じがして良いとは思うけど、長期的には3日たつと忘れてしまうので、本当に学ぶ必要があったのかと思ってしまう)。実際に自分でコードベースで作ってみて初めて「こんな簡単に作れるんだ、すげー！」とか「Gitってコードで書くとこんな仕組みだったんだ！」と感動する。感動するので、長期的に記憶に残りやすい。 (作るのはめんどくさいので、そこまで重要じゃないけど、覚えたいものは記事にまとめるとかでも良いのかなと思った)

教科書通りに勉強したことって、身についているようで身についていなかったりするので、なるべくコードで実現して感動するようにしたいなと個人的に思った。

レンガ職人の話

そういえば、昔なんかの記事で、Googleに勤めている開発者に「どんな仕事をしているんですか」と記者が聞いた時に、開発者が「世界を変えるプロダクトを作っているんだよ」と答えていたの思い出した。この人はWhyを元に働いている。つまり価値観ベースで仕事ができている。そういう自分の価値観ベースで仕事ができる人はほんと強いんだろうなと思う。

イソップ寓話「3人のレンガ職人」に学ぶ、モチベーション高く働く従業員を育てるヒント株式会社トータルエンゲージメントグループ

その他の気づき

自分の作ったものが親しい人の役に立てば、嬉しい
本は時間がないから消化できない。あと心で記憶しないので結果的に忘れる。本を読みたいなと思ったら、なるべく要約記事か要約youtubeでどうにかする。よっぽど読みたいなって思った本だけ買って読む
軸足が定まると、もうどうなってもいいって気持ちがあったな。そういえば。
夢中は努力に叶わない。
〜しなければならないって考えている時点で、本当にやりたいことではないのかもしれない。~したいがやりたいこと。
価値観が定まると、意志が強い人になる気がする。
フレームワーク特有の処理はなるべく覚えない。むしろ、フレームワークを使わない場合、どうやって実現しているのか、仕組みを実装できることが大事。
いろんなサービスを組み合わせて課題を解決する。
ぐだぐだ悩まずに、この道を進むんだと決心する
チームで働くなら、2 ~ 3年は結果出すのに時間がかかる
覚えたことを話しても人の感情に訴えかけることはできない。自分が感じたことを話す。
人の感情に訴えかけることができれば、論理が破綻してても、人は行動してしまう。

まとめ

自社開発が良いのかなと思っていたが、自分の価値観をもう一度見つめ直すことによって、サービスを0から実現する受託が良いなと思うようになりました。受託だから雑にサービスを作るのは自分のことしか考えてなくて、拡張性のある設計やコードを書くことでサービスを長期的に運用できるようにすることを常に意識したいなと思います。