採用

素直さ

モチベーションの根源

自分で考える力

ポートフォリオをうごかす

AWSカルチャー

採用サイトのための撮影術

どんな人を採用したいか

採用する側の目線としては、

誰かを採用したことがなく、

故に採用によって失敗したこともないので、

具体的な「指標」と、それを測るための「方策」が見えていない

この一見相容れないものに、立ち向かわないといけない。

今のチームのノリと調和が取れる人

カルチャーフィット

自分がすごいと思える点があること

承認欲求が低い人

強いエンジニアを採りたいスタートアップをご支援してるとき、成長とか評価とかいう言葉を使うのはやめるようアドバイスしている。スタートアップに来る強いエンジニアというのは、「俺がお前を評価するんだよカス」って気持ちで来るもんなので。「助けてください」以外言わなくていい

人を増やすことのデメリット

コミュニケーション問題

お金の問題

教育にかける時間

いろいろパラメータはありそう

技術の能力

人間としてチームに調和するか

良い刺激をもたらすか

ドメイン知識がある

扱っているビジネスに関する知見が深い

感じる側の観点

そもそもなぜ、経営理念への共感を重視するのか

共感している場合としていない場合にその会社の何が変わるのか

安易に思いつく発想

モチベーションが高いので、事業に取り組んでくれる

ユーザーの求めるものが見えるので、良い提案ができる

関係ある？

果たして本当か

P: 経営理念への共感がある

Q: 会社に対する良いパフォーマンスを出す

のとき、P→Qは真なのか、そしてそれ以外に真となるものはないのか？

それに対する反論

「経営理念への共感が不要」というのは、その経営理念が練り込まれていないから。

もしくは、経営理念そのものは会社のものであるので、「エンジニアチームとしての経営理念」が別途必要

で、それにそぐう人を採用する必要がある

なぜ、この会社を選ぶか

「経営理念への共感を重視しない」ならば、「なぜ弊社を選ぶか」があまり明確にならない気もする

しかし、実際問題、そこまで経営理念で転職先選ぶか？？って気もする

実際よく見る指標って

安易なものであれば

年収、休暇、就労時間、福利厚生、名声

のような、いかに楽して金を得るかみたいたもの

エンジニアっぽいものなら

強い(とは)エンジニアがいる

そこでしか触れない技術がある

福利厚生

技術書を買ってもらえるなど

思想によるものなら、

自分には叶えたい思想があり、この会社がそれを体現している

そこのサービスが好きなので、自分も作りたい

あまり聞かないが、こういうのものありそう

これに関しては、経営理念共感に近い

こういうふうにみると、「経営理念への共感」って、言っているだけで、そんなに価値のあるものなのか？という目で見てしまう

つまり、言うて金でしょ？になってくる

「技術力は必要だ」とか「学ぶ意識が高いほうがいい」みたいなよくあるエンジニアの理想像は、たしかにそうだと思うが

そこを最も優先順位高く見てしまっていいのだろうか、という気もする

だいたいこれに尽きると思っている

「理念への共感」とか「プログラミングが好き」とかはその具体例に過ぎない

金駆動でもいいし、名声駆動でもなんでもいいから、そこに自覚的であることと、それの正確性が重要だと思っている

モチベーションの根源がわかっていれば、自分でも、他者からもやる気を促進しやすい

「この人は金が得るのがモチベに繋がるのだな」とわかれば、利益が出るけど大変なことをやらせれば都合がいい

「金もらえるけど、ツライのはやだな」となればそれは多分金駆動ではない

モチベの根源を見間違えている

ってなに

会社にいて、人の距離が近ければ、少なからず互いに影響を受ける

であれば、極論を言えば、入社当初の性質はそこまで重視しなくてもいい

洗脳力があるならば、どんな人も、カルチャーに染めることができる

強いて言うなら、「洗脳しやすい人」を入社させればいいことになる

「洗脳するコスト」 v.s. 「良い人を探すコスト」の対立構造になる

「何を大事にしているのか」は聞きたい

プログラミングについてでも仕事についてでも

e.g.

プログラミングは楽しいのが大事

プログラミングは正しいのが大事

プログラミングはユーザーが大事

仕事なら何でもやるべき

楽して生きたい

「こう答えたら正解」みたいなのはないけど、ソレを聞いた上で合ってるかどうかは判断できそう

採用側の視野の狭さによって、重視すべき視点が全く異なる

チームが複数あるような職場で働いたことがない

エンジニアがめちゃくちゃ多いような環境に身をおいていない

「人数が増えること」に対する危うさを理解していない

「採用面接」をした回数が少ない

というか0である

人の見定めに対するtry-and-errorの経験がない

採用に失敗した経験がない

gituhbとか

言うて、GitHubやプロダクトは結果に過ぎない

どちらかと言うと、ブログやScrapboxのような過程を見れたほうが良い

これはなんか僕の良い面接イメージとは違う気がする？一緒に問題を解いてくれそうか、困った時にどう対処するか、を見たいという気持ちが強いので、問題は相手にとって難しければなんでも良くて、自分が答えを知ってる必要もないと思っている。解けた解けないは重視しすぎないようにしているというか

解けてなくても、途中の考察や分岐のアイデアが良くて大満足、ってことも多いし、なんかそもそも話の流れで別の話になる場合もあるし。面接する側からすると時間内で情報をなるべく集めるゲームになってるので、出した問題が苦もなく解かれたり、手も足も出ない状態になるのは失敗、みたいに考えてる

どうなんだろ

面接対応する人が複数人いるなら有用かもしれん

「一人で作りました」をどう評価するか