リファレンスチェックは難しい
難しいと感じた観点は２つ
依頼するとき
解釈をしてもうとき
自分は転職活動中で選考フローの中にリファレンスチェックがある会社が幾つかありました。まだ多数ではなく、今回受けた会社では３分の１くらいがリファレンスチェックをしていました。
自分の選考を受けた会社はスタートアップ系の会社 + 開発組織が大きくなってきているフェーズの会社が多かったため、サンプルには大いに偏りがあると思います。
そんな中で、今回の転職活動で初めてリファレンスチェックをお願いすることになりました。そのときに感じたモヤモヤを文章として綴ってみました。自分は特殊ケースの転職だと思うので、一般的なリファレンスチェックで当てはまるかは分かりません。
依頼するとき
まず感じたのが、書いて貰う人の時間を取ってしまって申し訳ない。
リファレンスは貴重な情報だとは思うけれど、もう少し気持ちよくお願いできるようになったらいいのにと思う。
依頼してもらって嬉しいと言う声もありますが、依頼する側の自分は恐縮してしまう面が大きいです。
さらに、複数企業で選考を進んでいて、複数のリファレンスチェックのサービスで依頼を受けると、何人もリファレンスチェックをお願いするか、同じに人に何度もリファレンスチェックが必要になります。厳しい、、。
今回も複数のサービスへの回答をお願いしなければならないケースがあって、かつ、かなり真剣に書いてくれたようで、とても大変だったと聞きました。幾ら仲が良くても、仕事とプライベートって別だと思うので、そんな中で人の特定の時間を期限付きで奪うのって、それは仕事ではないの？と感じました。自分のお願いする人たちって偉い人たちばかりなので、その人達にお願いするのは普通だったら数万円くらいは支払われるべきと感じたりしてます。
書き手にとって何の報酬もなし行う善意に乗っかって実現できているビジネスモデルの印象で、あまり良い気持ちがしていないです。リファレンスチェックの会社が書き手に対して明確に報酬を出してもらえると嬉しいのだけれど、難しいのかなー
解釈してもらうとき
リファレンスで書かれた情報だけでは理解するための情報として不足している要素が多そうに感じました。ピックアップした事例は１つの角度から見えたことや観測した事象があったことは分かるけれども、その背景や書き手の意図は伝わらないだろうなと思いました。
普通の面接だと、会話のキャッチボールが必要なので、聞かれたこと、知りたいことに対して答えていく必要があります。リファレンスの内容は自分は知ることができないので、相手の質問力に期待するしかありません。
しかし、自分の課題や改善で大きな気付きがあったことを聞かれても、思い当たる失敗が多すぎてわかりません笑
組織の大きな変化は こちらに書いた記事にも書いてあります。
この記事に書いたことはあくまで客観的で汎用性がある形に抽象度を高めた改善案です。全てに失敗が紐づいており、上記の記事にある組織の大きな変化６つの時におきた、具体的な出来事で自分が上手く出来なかったことは両手両足があっても足りません。
何が１つの言葉が響いたことはなく、日常的に失敗が発生し、常にみんなの意見を受け止め、直ちに次の改善を起こすことしか出来ません。そのような失敗の中からリファレンスにある１つの失敗を見つけて答えるのは、砂漠にある鍵を見つけるような難しさだと感じました。
これは質問する人が悪いのではなく、私のやっていた仕事の背景が複雑であり、同時期のタイミングで１つのチームや１つの抽象度で仕事をしていないため、片面から見た場合に不足の対応に見えるケースが多く発生していたと感じます。これは自分のスキル不足も大いに影響がある話だと思います。
しかし、表面的に見えていることは結果でしかなく、その原因がマインドなのかスキルなのかを判断することは大事です。そして、評価のポイントでマインドのズレがクリティカルなのか、スキルの不足がクリティカルなのか、それぞれのポテンシャルがどの程度あればいいのか？その判断基準は会社によります。しかし、知らないままに判断されてしまうのは、何だかモヤモヤするなーと感じました。
ここで伝える必要があることは、別の優先順で動いていたものは何か？制約はなにか？どんな努力をしていたか？当時のミドルマネジメントの視点での視座の不足や対処スキルの不足していたことは何か？それによって、自分のマインドとは別でスキルの不足で起きてしまった結果的なことは何か？根底に持つマインドは何なのか？
それらを説明する必要があるなぁ。でも、難しいなぁ。と思いました。
逆を言えば、これらの事情をリファレンスだけで説明するのは難しいなぁと思いました。これが主題です。
この難しい状態の仕事のリファレンスを書いてくれたみんなには本当に感謝です。
色々考えたのですが、仮説を検証するために、選考中の会社にお願いして自分の経歴をひたすら話す時間をもらいました。
ここまでが、「解釈してもらうとき編」の前フリです。長いｗ
今回の具体的にアクションしてみたこと
実際に面接でそれを感じたことがあり、選考中の次の別の会社の信頼できそうな方に「おそらくリファレンスチェックで色々書かれていると思うが、事実を詳しく説明して理解していただきたい。そのために、この様な形で話をしていきたい」と図を作って説明させてもらいました。
前提として「私の目標は選考に通ることではなく、みんなと一緒に会社を成長させて喜ぶことです」 と前提に共有させて頂き、この内容を聞いた上でフラットに評価して頂ければ、お見送りでも全然問題ないことをお伝えしました。
この話の目的は「当人だけが知りうる事実の共有」と「解釈のギャップの理解」を通して、私の改善ポイントを見つけ出し、成長の種を得ることです。
この図で理解して欲しかったポイントはリファレンスの内容を直接聞きたい訳ではなく、リファレンスだけでは不足している情報を共有する目的であ
ることです。
その際に、リファレンスを書いた解釈を知りたいのではなく、事実の背景を補う説明がしたいため、リファレンスで触れられているプロジェクトや事実は質問してもらうことはあるが、個別の人を特定したり、解釈に反対するためのものではないことを確認しました。
この解釈と事実を分け、背景を知ることは面接の時にも使える方法かなと思います。
図を見ながら以下のポイントを押さえて話したいことを共有しました
１．リファレンスを書く人の性格や考え方
２．見えていた範囲の定義
３．事実の共有
４．解釈のズレの確認
５．新田への改善のポイントのフィードバック
次の資料として、自分の課題は何が上がりそうか？を想定し、４つのカテゴリに分けました。基本的に組織づくりはこれらが複合的な要因で関係し合うのですが、どこに軸足があるエピソードなのかを確認します。
ここでは、この中にあるか、ないかだけ確認しました。この想定の範囲外のエピソードだと、自分の事実の共有ではカバーできていない領域になってしまうからです。
自分からの事実の共有
▼ 今回リファレンスを依頼した人の人柄
客観的な事実での紹介と主観的な感想での紹介を簡単にしました。
自分へのコメントをどんな風に書くかもイメージが付きます。
▼ 組織の掌握範囲と組織図上の変化
こちらの記事にも一部載っています。
１．メインチームの立ち上げ ( 採用や開発プロセスの導入等から)
２．メイン組織の事業を実現するためのサブラインを実現するための別組織の立ち上げ(後に横断組織のチーム)
３．M&Aによる会社の受け入れ。開発部門のマネジメントの追加と連携 (EM不在の会社)
４．メイン事業を前提にした次の大きな事業を実現するための新規事業を並行した立ち上げ
５．採用関連の活動、採用広報、技術広報
メイン組織のチーム分割を含めると組織図が複雑になってしまうため説明しませんでした。
全社から見た組織の立ち位置と組織内部で別事業の文脈をもつチームが３つ４つ立ち上がって、それらを１人目として立ち上げたり、受け止めたりする役割がありました。
▼ 事業変化のタイムライン説明
様々な文脈で自分の担当する開発組織領域にチームが立ち上がったり、M&Aで合流したりしていました。チームに肩書きをつけたら終わり、合流したら終わり、、、という訳ではなく、常に並列でメインで担当している事業とは別で動いていました。
チーム立ち上げの１人目のため、何をどう作るべきかをある程度落とし込んで必要技術を定義し、採用ペルソナを立て、採用し、受け入れ、依頼し、チェックする流れまでを上手くチームで回るまで作っていくことが必要でした。
この複雑なタイムラインは時期によってやっていることや軸足が変わってしまうため、図に書いて説明しました。
図には組織の事象や人との関係、上手く出来なかったことも書いてあるのでモザイクにしています。会社事業に影響のある秘匿の話や個人名は出していませんが、関わった人が私の解釈だけで書かれていることもあるので、詳細は何かのイベントなどで会った時に聞いて下さい。モザイクはしてありますが、どんな伝え方をしたのか雰囲気だけ伝われば良いかな。
▼ 個別状況の深堀り質問
リファレンスベースでも、そうでなくても良いので、気になる時間軸 x チームで質問をしてもらいました。メイン事業の質問が多かったですが、私からはリファレンスの内容を深堀りしたい質問なのか、そのときに本人が興味を持ったから深堀りしたい内容なのかは分かりません。
１つだけ伝えたいのは、自分のやりたいことはエンジニアに活躍してもらうことです。一緒に働くエンジニアのパフォーマンスを信じているので、契約形態や役職で可能性を切り捨てたりはせず、その人のスキルや思考性、やりたいことを実現する方法を常に考えたいと思っています。
契約社員等も含めて全員と1on1をして課題を拾い、自分のできる範囲で組織やチームの変化に繋げて行けるようにします。その時に納得感が高くなるように、全体議論の場を作ったり、個別で1on1で課題を聞いたり詳細を説明したりします。
チームの立ち上げのときと、チームを引き渡したときと、自分の手が回らなくて困ったときと、任せてたと思っていたが上手く出来ていなくて巻き取ったときと、タイムライン上で色々な文脈やエピソードがあります。
それらを聞いてもらった上で、個別の事情だけでなく、私のベースとなるマインドと現時点でのスキルを知ってもらえたのではないかと思います。
共有後のギャップの確認
リファレンスの細かな解釈を聞くことは出来ないので、感想だけ聞いたのですが、「読んだだけでは分からない背景が数多くあった」「経緯や制約を含めたら、全く違う解釈に繋がることもあった」と聞きました。
具体的に聞くとリファレンス内容に触れないと難しいので、結果としてはここまでですが、自分の仮説は正しかったのではないかと考えています。
共有後の改善の確認
ギャップを確認したあとは、当初目的の自分の改善の種をみつけることです
選考面談なのに真摯にフィードバックをしてもらい、自分の不足を理解することが出来ました
▼ １つめは自分の共有力の不足
共有力で足りなかったと理解したスキルが２つ
A. 観点
課題になっていなければ報告することもないと判断したこともあるし、成果になるまで同じことを何度も伝えても価値は薄いと考えていました。
B. 要約力
４つの大きなプロダクト開発があり、それぞれに課題の深さと時系列変化の広さがあるため、全てを伝えることは不可能。実務で対応している自分は深さと広さの情報を理解して実務的なアクションしているが、伝える時に何を伝えるかの切り口を考えて状態を伝える必要がある。実務的なアクションは成果が出ていない状態のものも多かったため、報告していないことが多くあったが、自分自身のプレイヤーコストを掛けなければならない箇所は負荷が高まっていた。
▼ ２つめは頼る力の不足
弱さを見せることが良いと受けて、それは確かにしっかりできていないと感じました。
さらに、自分は出来ないことを明確にすることが大事だと思いました。出来ないことが明らかにすれば、助けてくれるメンバーがたくさんいました。その線引きが曖昧だと助ける方も助けにくく、期待している部分が不満や不安になってしまいます。困っている部分をどの様に取り扱うかを明確にし、助けてもらう必要があることは助けてもらえればと考えています。
全く助けをお願いできなかったかというとそうでもなく、役割分担や期待が明確な仕事はそれぞれに推進できていたことも多くありました。しかし、一時的な負荷の上昇や組織の流動的な変化により曖昧になってしまった仕事や対応が足りなくなってしまった仕事を明確にアプローチして定義できていなかったことが課題だったと感じます。
この記事の本題に戻る
このように自分にとって得るものがあった会になったのですが、この記事の本題に戻ると、リファレンスチェックの内容だけではシンプルな仕事のときには正しい解釈ができるが、複雑な事情を持つ仕事を解釈することは難しいのではないかと感じました。
そして、リファレンスを活用して理解するには、正しい質問が出来て背景を深く知ることが出来なければならないと感じます。
リファレンスチェックの情報は本来的には選考で使わない了解はあると思います。ですが、全く使わないことは不可能だと思うし、その意見を無視するのは本質的ではないと思う。しかし、他の人から見えていたことは一面でしかないので、書き手も知らない背景は確認できたら良いと思ったのでした。
まとめ
▼ 依頼するとき
報酬を出すなど、書き手が掛ける労力に見合うものを渡すことは出来ないのか？
▼ 解釈するとき
書かれた内容はあくまで一面であり、見えていない事実と書き手の解釈を通したもの
選考で使うには事実をベースにして会話しながら、書き手が見えていない背景を理解する必要があり、背景が見えていない情報は確定的に取り扱わない
▼ 自分の希望
リファレンスチェックは海外では当たり前な会社も多いが、日本ではまだまだ始まったばかりの取り組み。「転職なんてとんでもない！」みたいな会社もあるので、日本の文化特有の取り入れ方が必要だと苦労していることと思います。
リファレンスチェック自体は、意味のある取り組みで有用だと感じています。しかし、それらに関わる人達はまだまだあまり良い体験ができているとは感じていません。
リファレンスを書くことをお願いされた人、リファレンスを取り扱う人、それぞれの人達の体験が良くなって、みんながその候補者を気持ちよく推せるようになれると良いなと思います。
この記事が気に入ったらサポートをしてみませんか？