転職活動で気をつけること

先日 web 開発者として初めて就職活動1 をしたが結果的に 失敗した2 ので 次回同じ轍を踏まないようにメモを残しておく。

これをそのまま質問事項としても利用できるし、事前に共有もできるのでそういう意味でも残しておくことに価値はあると思う。

以下にあげたものは今まで気をつけていた点も含むので、必ずしも今回の失敗から得られた知見ではないことを予め断っておく。

概要

次回もし就職・転職活動するなら以下のようなことを気をつけたい。

  • マイクロマネジメントを避ける
  • 密室での会話が少ないか確認する
  • 開発する上での心理的安全性が確保されているか
  • 開発者のレベルを可能な限り把握する
  • 人の入れ替わりに気を配る
  • 最初はお互いに切りやすい契約内容にしておく

以下、具体的な内容を書いていく。

見出しに必ずしも合致しない内容も含んでいるかもしれないが、勢いで読んでほしい。

マイクロマネジメントを避ける

ここでいうマイクロマネジメントは、以下のようなものを想定している

  • 出社の強要
  • 日報の強要
  • 同期コミュニケーションが多い
    • 口頭でのやりとり
    • 定期的なMTG
    • etc.

出社の強要

自分はスタートアップでしか働いたことがないので、他は知らないが、今の時代において場所の制約を設ける必要性はまったくない。 基本的にオンラインで完結するようになってることがほとんどなので。

目の届く範囲に部下を置いておきたいんだろうな、程度の感想しかなく、嫌悪感すらある。

セキュリティ的な観点から場所の制限を受けるケースはあると思うが、そもそもそういう仕事は自分は受けられないと思う。 Google のように快適なオフィス環境が約束されていれば話は変わると思うが。

もしこれに時間の制約も加われば朝から満員電車にSAN値を削られ効率がダダ下がりするという結果になる。

結局 適切にアウトプットを評価する仕組みが整っていれば、どこで働くか、いつ働くか、は重要ではないので、 その点に同意できない人と働くのは難しい。効率を重視したい。(もちろん法律の許す範囲で)

日報の強要

基本的に他人を信用しておらず、事細かに何をやってるか把握したがるのかなと思ってる。 信用できない人間を雇う時点でそもそもおかしいので、採用戦略を見直すところからはじめてくれ、という気持ち。 (日報に書いたことは無条件で信じるのか?という疑問もある)

自分は性善説派なので、そもそも宗教的にわかりえない。

普通の web 開発者であれば、 GitHub などで日々成果物を上げたり、ドキュメントを残したりするので、 日報は二度手間でしかない。

何をやったか頭を整理したり、次の営業日に何をやればいいかわかりやすくなる、 等といったメリットを本人が信じて自主的にやる分には問題ないと思う。

個人的には GitHub に WIP でも何かしらアウトプットを残すので、そこだけ見といてくれと思う。

同期コミュニケーションが多い

出社の強要とつながる部分もあるが、そういう人間ほどチャットで済む内容をわざわざ口頭で確認したりする。 そしてドキュメントを残さない。

人間は不完全な生き物なので、口頭でのコミュニケーションが増えると「言った・言ってない問題」がどこかで起きる。 これも効率面で無駄なので極力避けるようにしている。もちろん口頭でのコミュニケーションの情報量の多さは テキストでは埋められないので、知り合ってすぐは何度かそういったスタイルを取っておくと非同期のコミュニケーションが うまくいく、ということは感じている。 また複雑な仕様などについて質問したり議論したりする場合も口頭でのコミュニケーションが早いケースもある。

MTG をやるにしても以下を守る(当たり前のことだができてない人は多い)

  • 参加メンバーが事前に話すことや質問する内容を準備している
  • 「何を決めるか」を明示した上で MTG を始める
  • 終わったら決まった内容(や議論した内容)を残しておく

以前フリーランスで働いていたときは必要なタイミングで Slack call や appear.in を使ってうまくやれていた。 お互いにちゃんと上記の手続きを守っていた点, 相手がとても優秀だった点が大きいと思う。

ただこれらをまともにやりだすと「定期的なMTG」を設けることがいかに時間を奪うかわかると思う。 基本的にはチャットや雑談でサクッと済ませて、「MTG を設けるのは最後の手段」くらいのスタンスで仕事をしてほしい。

また「リモートワーク可能です」「フルフレックスです」などの会社で用意されてる制度を前面に押し出しているケースは鵜呑みにしない。 上司や部署単位でその制度が十分に活かされないケースがあるということがある。 結局はそういった一見裁量を与えているような制度があっても、上長がマイクロマネジメント派だと (自分にとって)働きづらい職場に早変わりするので、事細かに確認しておく必要がある。

密室での会話が少ないか確認する

これはとてもシンプルで、

  • チャットツールにおけるDM比率が少ないか
  • MTG回数が少ないか

の2点を確認するだけである。

前者は Slack の場合、その割合を見れるページがあるのでそれを見せてもらえば十分。 (組織内で複数の Slack team を作っていたら少しややこしいかもしれない)

後者は正確にデータを取っているところは多くないと思うが、

  1. 定期的な MTG の内容(目的)と頻度
  2. MTG を減らすための工夫

の2点を聞けば大体察することができると思ってる。

MTG は必ずしも密室での会話には当たらないかもしれないが、特定の人間の間だけで情報を隠し、 コントロールしようとする組織は、余計な交渉コストが発生しがちなので効率面で良くない。単純に馬鹿らしいというのもある。

社員の個人情報関係以外の情報は基本的に全社員がアクセスできるようになっていることが好ましい。

開発する上での心理的安全性が確保されているか

散々界隈で言われていることではあるし、自分は割と環境がどうであれ好きにやる傾向にあるのでそこまで気にしてはいないが、 これが確保されてないがゆえに、職場に閉塞感を感じることがあるため確認しておきたい。 (ただこれはポジションが下の3人間ほど強く感じているケースが多いと思うので、採用の場で必ずしも確認できるかと言うと怪しい)

例えば以下のような点で心理的安全性が低い、と言える。

  • build や deploy に時間がかかりすぎるため、気軽に deploy できない
  • E2E テストが不十分だったり、動作確認が複雑・困難なため、気軽にリファクタリングできない
  • 障害を起こすと評価に響く
  • コードレビューを通していても、何かあったときに実装者一人の責任になる

そもそもこういった問題が起きているのは、こういった問題意識を発言しづらい環境があることに問題があるので、 それを改善することが早急に必要になってくるだろう。

割とどこでも抱えてそうな問題なので、面接で厳し目に突っ込んで聞くことが必要そうではある。

開発者のレベルを可能な限り把握する

当たり前ではあるが、開発者のレベルを確認する方法としてこれはやっておいた方がいいな、というものを書いておく。

一番シンプルでわかりやすいのは、 直近 merge された pull-request を一通り見せてもらうことだ。 コードの質、 git をどの程度使えるのか、どういう問題意識を持ってコードを書いているか、が包括的に把握できそうに思える。 面接の場で15~30分ほどその時間を取ってもらって、担当者と一緒に一つのディスプレイに画面を映して、質問しながら進めると お互いのレベル感がわかってよさそうに思える。 気をつけることは、自分が入社後に触ることになるプロジェクト or 社内の多くの開発者が p-r を出している開発が活発なものを見せてもらうという点。 コードや p-r はキレイだが今はもう触られてないようなプロジェクト4を見せられてないか、 そのプロジェクトが今社内でどういう立ち位置にあるか、は必ず確認しておきたい。

上記が認められない場合、個人的にはその時点で胡散臭いので辞退したいところではあるが、あとは以下の方法があると思う。

最後は完全にネットストーキングであるが、わかりやすさという点では一番いい気がする。

蛇足だが、 SNS に関して言えば絶対にフォローはしないことである。 以前 SNSで同僚をフォローするのをやめた - Sexually Knowing というエントリーがあったが自分はその考えに完全に同意している。

人の入れ替わりに気を配る

直近で人がどの程度入れ替わっているか聞いておく。 「なぜ人がいなくなったのか」冷静に分析できているかどうかで、今いる人間の人に対する考え方がある程度把握できる可能性がある。

入れ替わりが激しい場合は(略

組織が若い場合は、開発部署の責任者(CTO や VPoE 的な人)がどういう組織を作ろうとしているのか、を把握しておきたい。 面接の場では綺麗事を言うので、具体的にどういったアクションを取った・取っているか聞く。

最初はお互いに切りやすい契約内容にしておく

結局いろいろと工夫しても嘘を吐かれるとどうしようもないので、最初は業務委託契約にするなどして自衛するしかない。 以前はこのように動いていて、大体1年くらい色々な会社を見て(その時点では)まともな企業を見つけることができたので、 その戦略に戻すだけ、と言ってしまえばそれだけの話ではある。

1~2週間体験入社する制度が早く一般的になってほしい。

もし先方が正社員契約にどうしてもこだわるようであれば、せめて試用期間中だけでも退職は2週間前でいいように 契約書を書き換えることを許可してもらう。 ほとんどのケースで1ヶ月前となっているが、法律上は2週間前でいいらしいので、無駄な時間を減らすためにこうしておく。 事前に話した内容に虚偽があった場合は即日退社可能にする、くらいはしてもいいと思っている。(本来はちゃんと法的な措置を取った方がいいのかもしれないが)

逆にこの条件を渋るようだと、明らかに問題があると自覚しているも同然なので丁重にお断りしたほうが無難だろう。

その他

  • 飲み会がない or あっても業務時間内に行われる
  • ランチMTGがない or あってもそれを「休憩時間」とみなさない
  • まったく仕事をしていない人がいない(適切な評価制度の有無との関連)
  • MTG することで仕事をした気になってる残念な人間がいない
  • 残業したり長時間労働する人間が低く評価されている(ペナルティがあると尚良し)
  • 初日から有給が支給される

希望条件を上げだすとキリがない。

まとめ

書き足りてない内容もあるかもしれないが、思いついたら都度更新するようにしたい。

転職のハードル高すぎないかとしか思えないが、日本の法律的にはこれだけしないと辞めるために大なり小なり疲弊してしまうというのが現状である。 これ全部やるのは大変なので自分はフリーランスでやるか、起業するか、死ぬしかないんだろうなという印象。

以前 SNS にも書いたが、もっとクビが切りやすくなった方が、真面目に効率や生産性を考えて働く人も増えるだろうし、 雇用の流動性も上がり、能力の無い人間は淘汰されて幸せだと思う。


  1. 今までは引き抜きか、声をかけられてフリーランスで働くということしかしたことがなく、一般的な面談や面接のプロセスを通じて仕事を探したのは今回が初めてという意味。 [return]
  2. 理由はいくつかあるが、1.) 開発体制、方針、価値観が合わなかった, 2.) 合わないオフィス環境での週5出社が精神的にきつかった、あたりが退職した(業務委託に切り替えた)理由になる。他にもあるが大人の事情で割愛。 [return]
  3. こういう言い方は好きではないが、他に良い言い方が思い浮かばなかった。 [return]
  4. おそらくそんな現場無いと思うが。 [return]

Contents