purintaiの日記スマートフォン用の表示で見るpurintaiの日記この広告は、90日以上更新していないブログに表示しています。自分自身の持っている先入観に負けないため。先入観でフィルターした場合だと会っていなかったが、それでも会ってみて実際に良いと思えた企業があった。どれくらいの企業規模を狙っているの?ターゲットは定めておらず、大企業でもベンチャーでも老舗でも創業直後でもよい。それよりも問題になるのは事業内容、構造、マーケット、チームメンバーの質や経営方針によることが多い。これが最後の転職ならド安定しそうな大正義大企業の正社員狙ってるだろうけど、どうせまた転職するので本当にどうでもいい。自分自身にとっての今回の転職はどういうものかいわゆる「Web系企業」の労働市場に初出品みたいな状態、これは前職のネームバリューとカンファレンス登壇や採用広報活動などの実績に依るものが大きい。github.com上記が僕の職歴だが、直近2社の経歴を隠した場合、雇ってくれるどころか書類を通してくれない会社も多いと思うし、実際前回や前々回の転職ではそのような目にあった。能動的にキャリアメイクをできるので、このへんはいわゆる新卒メガベンチャーみたいな人と比較すると周回遅れ状態だと思っている。経歴話すと「へー立派じゃん、すごいじゃん」みたいな反応されるのだけど(お世辞かも)、結局直近1社が無ければ「で、今まで何やってたんですか」になるんですよ、これはマジで。次の職種・やりたいことについて前職でやってきたことは、一般的な職種名に照らすとこのようになると思う。(DevRel)この中だと、やはり主軸はソフトウェアエンジニアであるが、これはコードだけ書いていたいと言うわけではない。プロダクトオーナーやディレクターが切った仕様とか雲の上の偉い人が決めたことをただ黙って実装していくみたいな業務は面白くないので積極的にこれを避けたい。面白くないだけでなく、エンジニアリング観点を持たないプロダクトオーナーやディレクターは得てして「実現不可能な絵空事」とか「AIでなんとかする」とかみたいなことを言うことがあり、これに対して協議・検討をする機会が設けられていないのは理不尽、または無駄と感じる。主体的にサービス開発に関わっていけるということは自分の中において必須事項であり、事業内容について納得感を持てることもまた必須事項である。採用・広報方面でのキャリアは間違いなく広がったけども、残念ながら前職におけるこれらの活動は自己の評価と企業からの評価に大きな差があり満足な評価を受けることができなかった。そのような事情もあり次の職場では採用や広報を主務とすることを捨てていきたいと感じている。これは一切やらないという意味ではなく、企画協力やレビューといった側面では積極的に手伝う意志があり、そもそも採用は一緒に働く仲間を決定する企業において最も重要なプロセスであるのでこれには今後も積極的に関わっていきたい。私がメインで関わらなければならないと感じる企業は選定においてマイナスに作用すると思われる。セキュリティ方面については自分自身の将来価値を高める一手のひとつではあると思うが、こちらは時間制限が比較的ゆるく感じるのでこれを検討しない。職歴からして1年後に自分が何をしているのかまるでわからないのでこれは考えるだけ無駄であるのだけど、今後もほぼ2年単位で転職をする気がしている。これは飽きのサイクルがやってくるのが2年単位だからという感じ。よって、キャリア全体で何を為すのかはさておいて「今回の転職」は「次の転職」を中心に考えるのが良いと感じている。スタートアップ向きの人材である。入りたい」と思った時に必要な経験が積めない(学歴が無いからこの選択肢はいずれにせよ多分無理なのだけど)。この点において現職と距離の近いような職場を選ぶよりも、離れている方が技術的な幅を広げることができるだろう。エンジニア以外のキャリアに目を向けると、例えば次も創立から浅いスタートアップに入るなどして立ち上げ期の経験を重ねるなどして、VCのアソシエイトとかインキュベーターで働くというキャリアもあると思います。特定領域の課題を深掘ってプロダクトマネージャやプロダクトオーナーを目指すというコースもあります。このようにモノを見ると、このタイミングで転職することによって得られる最良のポジションは何であるかということが大事で、何かを軸にするということは大切ではないと思っています。求める文化パフォーマンスを発揮するためには企業やチームの文化的土壌や能力水準も大事だと考えており、書き出すと書ききらないのでトピックを絞って書く。心理的安全性このキーワードは現在とても扱いづらくなっていて、何故かと言うとこの単語の持つ意味が現在二分されてしまったせいからだと思う。上での議論を眺めていると多くの場合これらが混同されており、これらに対する定義がない状態で走っているようにしか見えない。単語の羅列から意味を類推するな。これが目指す本来の状態は後者ではなく前者であり、間違っても「コードレビューの時に丁寧に言葉を選ぶこと」や「コミュニケーション上のNGワードを設けること」が「心理的安全性」ではない。担当する職務範囲においては、全ての情報を開示されることを希望する。情報のコントロールで課員をマネジメントする組織やマネージャは積極的に避けたい。サービス開発プロダクトチケットの検討にエンジニアを「関わらせてやっている」というスタンスのプロダクトオーナーやディレクターとの協働は積極的に避けたい。いるプロダクトの技術的負債はこれを歓迎する(否定しない)が、技術的負債を積極的に積むことはこれに反対である。技術的負債なんて、生まなくて済むなら生まなくてよい。設計時点で予測できなかった変化の結果生まれた技術的負債はチームの責任であるが、それが設計者の無能によって生まれたものであれば設計者の責任である。事業会社において技術的負債を返済していくことがプロダクト価値を生み出さない場合において、これを積極的にアウトソーシング(お金で解決)するべきと考えている。プロダクトチームのエンジニアはプロダクト価値を生むタスクに向き合うべきで、この時間をお金を買ってでも捻出すべきという考え。これをアウトソーシングできないほど予算に困っているのであれば単純に採算の悪いプロダクトであると考える。技術選定とは何かプロダクト単位で見れば、課題や要求に対して最適な道具を選んでいくことであり、企業単位で見れば、採用プールのコントロールであると考えている。いけるかもしれないけど。バラけていればそれでいいってのも違って、言語ごとの相性とか共通ライブラリを作ったりとか人員のローテーションにも関わってくるし、特定の言語のシニア級を取ろうとすればシニア級人員の年齢や労働市場状況によってコストも大きく変わってくるので、このへんは経営の観点がかなり求められる。個人レベルでプログラミング言語や技術を選ぶことはコミュニティを選ぶことと同等であり、長きに渡って付き合う人間を選んでいくということにもなる。採用においてコミュニティの存在は決して無視できないので、企業側も言語選定においてコミュニティの文化や層を良く見ておくことが大事、これは新規にサービスを立ち上げようとするベンチャーの方が影響がでかい。面談をまだ組んでいない企業様へこちらから面談枠を確保できますのでよろしくおねがいします。twitter.comつづく。