準備ができている人間にしか機会は来ない

先日、DevLOVE関西の200回目を記念するイベントで登壇してきました。 登壇内容を考えるにあたって、大きく2案あったので、没にしたほうのネタを簡単にブログに書いて供養しておきます。

ロックバンドの成功の証は、日本武道館でのライブである、みたいなイメージがなんとなくあります。 地元の小さなライブハウスで、客席に友人しかいない状態で演奏するところからはじまって、そこそこ有名になり、対バンに呼ばれるようになって、ソロでライブハウスが埋まり、Zeppなどの大きなハコでやるようになって、そういうステップアップを繰り返した先に、ついに武道館を満員にする。

そのときの彼らの気持ちは、どんなものなんだろうか。

自分にとって、かつて武道館のような舞台がありました。 今は会場が変わりましたが、かつては毎年目黒の雅叙園で開催されていたデブサミ。ここは自分にとっての武道館のようなものでした。

2010年ごろに、地元の小さなITコミュニティの勉強会に顔を出すようになり、懇親会で飛び込みLTなどをやるようになります。ちょうど、ロックバンドが地元のライブハウスで友だちにチケットを買ってもらって演奏しているような状態でしょうか。

そんな時期に、あるとき会社を休んで、新幹線に乗って行った雅叙園デブサミは、自分にとっての日本武道館の舞台のようなものでした。 あの壇上でトークをするには、いったいどんな活躍をすればいいのだろう。地元のコミュニティの懇親会LTと、デブサミの舞台が地続きにあるとは、とても思えませんでした。

もし、自分があの舞台に立てたら、どんな気持ちになるだろうか。きっと高揚して、興奮して、叫びだしたくなるような気持ちになっているに違いない。

そんなことを想像しました。

それから10年ほどたち、Developers Summit 2020に招待スピーカーとして登壇する機会を得ます。会場は雅叙園でした。

日本武道館のライブの幕が上がる瞬間のロックバンドの気持ちはどんなものでしょうか。

デブサミにいよいよ登壇した瞬間の自分は、かつての想像とはまったく違ってとても冷静でした。もちろん「ついに雅叙園デブサミに登壇したかー」という感慨はありましたが、それ以外は、「いつもどおり」だったのです。 いつものように準備をして、いつものように練習して、そして少しばかり緊張しながら、いつものように登壇する。

これまで何十回と繰り返してきたことを、少し大きな舞台でいつもどおりにやる。これが、憧れの舞台の上での自分の状態でした。

おそらく日本武道館に立ったロックバンドも、同じだと思います。いつものようにプロとしてお客さんの前で演奏する。

そういう準備ができているからこそ、この場に立つ機会を得られるのだろう。そう思いました。

学生のころ、小説家になりたいと思っていた時期がありました。自分の著書が書店に並ぶのってどんな気持ちなんだろう、といろいろな想像をしました。

2023年に単著を執筆する機会を得て、自分の著書が書店に並びました。もちろん嬉しかったですが、かつて想像していたような大歓喜ではなく、これもデブサミと同じく「いつもの延長」でした。自分が寄稿した記事がWebメディアに掲載される。自分の書いた文章が掲載された雑誌が書店に並ぶ。共著が出版される。そういうこれまでの活動の繰り返しの先に、「単著が書店に並ぶ」という出来事がありました。

かつて想像した大きな舞台や、大きな仕事は、なにか大きな飛躍があってたどり着くものではなかったのです。日々の生活や毎日の仕事の繰り返しの中で、少しずつ飛躍があり、その「いつものこと」を積み上げた先に、少しずつ大きな舞台や大きな仕事があるのです。

それをやるための経験と準備ができているからこそ、その機会はやってくるし、いつもどおりそれをやることができるのです。

というのを自分のコミュニティ人生を少し振り返って思うのでした。

技術組織のタレントマネジメントと、タレントの定義を考える

仕事のひとつとして、技術組織におけるタレントマネジメントに取り組んでおり、勉強したことを簡単にまとめておく。

タレントマネジメントと一口に言っても、その類型にはいろいろとあり、マッキンゼーの"War for Talent"が書籍も出版されていてよく知られている。これは、簡単に説明すると、社員を成果の発揮度でA, B, Cに位置づけ、組織をAの人材で充足し、Cはなるべく数を減らす、という戦略をとる。選別の要素の強いマネジメント手法であり、あまり日本型の人事管理には馴染まない。そもそも、組織のすべてをA人材で満たす必要はあるのか、A人材のみで充足するためのコストに見合うのか、といった議論もある。

マッキンゼーの"War for Talent"は選別的なアプローチであり、逆に人材すべてをタレントとみなすマネジメントは、包摂アプローチと分類される。

他にもタレントマネジメントの類型はいろいろとあるのだが、技術組織としてはSTM(Strategic Talent Management)を参考とすると良いのではないかと考えている。

STM(Strategic Talent Management)とは

STMの概略は以下のとおりである。

  • 組織(チームや部門)のキー・ポジションの体系的な特定を起点とする
  • キー・ポジションの現任者や後任候補者を輩出するタレントプールを開発するための一連のプロセスをタレントマネジメントとして定義づける

STMにおけるキー・ポジション

  • リーダーシップの発揮という観点に限らない
  • 戦略達成にとって重要度の高い職能(function)・技術(technology)・地理(geography)によっても規定され、それが時間変化に応じて変更される場合がありうる

ジャストインタイムの人材配置

社内のさまざまな組織(部門, チームなど)の戦略の実現に必要なケイパビリティを特定し、事業計画や人員計画に対して適材適所かつ適時適量の人員配置を行えるように、技術組織として育成(場合によっては採用)の枠組みをつくる。また、社内の人材をタレントプールとして管理し、関係者がひとつのデータソースを参照して適材適所の議論が行えることを目指す。

タレントの定義

タレントマネジメントに取り組むにあたって、そもそも"タレント"とは何であるかを考えてみる。

タレントという概念の解釈には、いくつかの論点がある。

Dries(2013)*1によると、タレントの解釈には5つの論点があり、それぞれに両義的な性質がある。タレントの解釈は、組織によってまちまちであるので、この5つの論点それぞれについて、どの立場をとるかを定めて組織におけるタレントの概念を描出する必要がある。

何が、あるいは誰がタレントなのか?

  • 主観 (object) - タレントを人そのものと考える
    • 後継者育成計画や組織によるキャリア管理の側面が強くなる
  • 客観 (subject) - タレントを人の才能と考える

従業員のうち、どの程度の範囲がタレントとなりうるのか?

  • 包摂 (inclusive) - 組織全員をタレントとみなす
    • 個別の従業員の強みに注目するアプローチ(strength-based approach)が重要
  • 選別 (exclusive) - 上位10%をタレントとみなす
    • 従業員を複数グループに分化させた人材アーキテクチャ(differentiated HR architecture)の構築が重要

タレントとみなされるための諸要素は後天的に獲得できるか?

  • 先天的 (innate)
    • 能力を持つ個人の特定手法や、採用・選抜のあり方の模索
  • 後天的 (acquired)
    • 熟達させるための学習・コミットメントや適合を高める施策の必要

タレントとして評価する際に重視すべき側面はなにか

  • インプット (input) - 個人の努力・モチベーション、キャリア志向
  • アウトプット (output) - 個人の成果物や業績、目標の達成度

タレントは環境に左右されるか

  • 移転可能 (transferable) - 環境に依存せず活躍できる
    • 組織外部からの引き抜きで充足可能
  • 文脈依存 (context-dependent) - 活躍のためには環境への適合が必要
    • コミットメントや適合の取り組みの構築が必要

技術組織におけるタレント

上記の5つの論点について、技術組織におけるタレントの定義を考えてみる。ここからはid:daiksyの個人の意見である。

  • 何が、あるいは誰がタレントなのか?
    • 専門職組織であるので、人そのものというよりは、人の才能に重きを置くとよいだろう
  • 従業員のうち、どの程度の範囲がタレントとなりうるのか?
    • 包摂の立場をとりたい
  • タレントとみなされるための諸要素は後天的に獲得できるか?
    • 技術組織は専門職の集まりなので、当然後天的に獲得可能な要素を扱うだろう
  • タレントとして評価する際に重視すべき側面はなにか
    • これは少しむずかしい。アプトプットに基づいて評価するのが主となるだろうが、インプットにおける要素も大事にしたい
  • タレントは環境に左右されるか
    • これも難しい。専門職を持つ人員としては、移転可能であるという立場を主としたいが、文脈依存の要素も場合によっては考慮する必要があるだろう

参考文献

  • 『日本企業のタレントマネジメント』石山 恒貴、中央経済社、2020年
  • 『タレントマネジメントをめぐる類型化に関する一考察』柿沼英樹、流通科学大学論集―流通・経営編―第 35 巻第 1 号,59-72(2022)
  • 『企業におけるジャストインタイムの人材配置の管理手法の意義--人的資源管理論でのタレント論の展開--』柿沼英樹、経済論叢(京都大学)第 189 巻第2号,(2015)

*1:Dries, N. (2013). The psychology of talent management: A review and research agenda. Human Resource Management Review, 23(4), 272-285.

EM Lounge #0 を開催しました

emlounge.connpass.com

関西でエンジニアリングマネージャの憩いのコミュニティを作りたい、という思いつきでEM Lounge #0 というイベントを開催しました。

経緯

Xのタイムラインに度々流れてくるエンジニアリングマネージャ向けのイベントのほとんどが東京での開催であることに、大阪在住の人間として羨ましく思っていたところ、@ebouchi さんのポストを見かけました。

つい反射的にそのポストに、関西でもやりましょう! と返信をしたところ、@ebouchiさんからもやりたいと反応があったので、とりあえず1回なにかやってみようと思い立ちました。

その後会社のSlackの自分のtimesチャンネルでEMイベントをやるぞ、という旨を投稿したところ、同僚であるEMのid:yigarashiさんが反応してくれたので、半ば強引にスタッフに誘い、その後 @ebouchiさんが @mitsuriverさんに声をかけてくださり、スタッフが4名になったところで本格的に企画をしはじめました。

EMが集まるイベントなので、会場の手配とOSTの場さえ作れば、あとは皆さん自律的に動いてくださるだろうからなんとでもなるだろうと思っていましたが、実際なんとかなりました。

当日の様子

当日はSansan株式会社さんの関西支店のオフィスを会場としてお借りしました。 お試し開催ということもあり、"OSTをやる"という以外はあまり詳細は考えていませんでしたが、大いに盛り上がりました。

OSTとしては、4レーンで、20分ずつ2回のセッションを行いましたが、ボリュームとしては物足りなさを感じるくらいどのレーンも白熱したディスカッションがされていました。

OSTセッションは次のようなテーマでそれぞれ話をしました。

  • 第1セッション
    • メンバーの評価とキャリアパス
    • ネガティブ・フィードバックむずくない?
    • "プレイング"との付き合い方 / プロダクトのコード書いてます?
    • 異なる職能の方々との向き合い方
  • 第2セッション
    • 元気なEMになるためには / EMとしてアガる瞬間
    • EMの成果はどう測る?
    • EM Longeの今後の企画はなにをやりたい?
    • 1on1の成功と失敗 / メンバーが成長できる1on1

今後

とても楽しいイベントとなり、個人的にもとても満足度の高い内容でしたので、それほど間を開けずに次の会を開催したいなと思っています。関西在住のEMの皆さんのご参加をお待ちしています!!

エンジニアリングマネージャとして入社した最初の取り組みとして、エンジニア全員(およそ100人)と1on1をしました

はてなにエンジニアリングマネージャとして入社して2ヶ月と少し経ちました。

マネージャとしての「最初の100日」もいよいよ終盤です。

note.com

入社して最初の取り組みとして、およそ100人のエンジニア全員との1on1を実施しました。

なぜ全員とやろうと思ったか

イギリスの人類学者であるロビン・ダンバーによって提唱された「ダンバー数」というものがあります。

これは、人間が安定的な社会関係を維持することができる人数の認知的な上限について提案された数字です。大雑把に説明すると、人間が相互に認識しあって社会関係を築ける人数はおよそ150人程度、というものです。

要するに1つの組織でお互いに顔見知りの状態で活動ができる集団の人数上限が150人前後であるということです。

このエントリを書いている時点で、はてなのエンジニアはおよそ100人ほどいます。つまり、はてなのエンジニア組織は、まだダンバー数の内側の規模であるということです。

これは、わたしがはてなの技術組織のエンジニアリングマネージャとしていろいろなことを考えるに際して、ダンバー数が示す数としては、まだ全員の顔や人となりをメモリ上に載せたまま活動を行える範囲内にあるということだと考えました。

ダンバー数の内側にまだ組織があるとはいえ、それでも100人を超える組織です。なにか物事を決めるときに、全員がばっちり納得できる決定ができるのが理想ですが、現実はそうではない場合もあります。ある人にとってとても喜ばしい判断が、別のある人にとっては少し不満が残ってしまう、というのは組織全体に影響する意思決定の場ではよくあることです。自分もマネージャとして物事を考えていくにあたって、このようなシチュエーションの中で全体のバランスをとる判断をしていくこともあるでしょう。ただ、その際にも、まだ組織がダンバー数の内側にあるうちは、メンバーの個々の事情や、気持ち、表情を可能な限り意識しながら判断していきたいと思いました。

また、エンジニア組織のマネージャは、そこで活躍する人たちのキャリアについての責任も持っています。わたしたち全員が成長し、よりよいキャリアを築くためには、やはりそれぞれのやりたいことや得意なことを個別に把握して物事を考えていきたい。

このような気持ちから、まだ全員と話ができる状態である今のうちに、個別に会って話をしておきたいと考えたのでした。

どのようにやったか

エンジニア全員と1on1をしようというのは、入社前から頭にあったので、どのくらいの期間で終わりそうか簡単な見積もりをしました。

1人30分として、100人と実施するとトータルで50時間。1日6人で3時間使うとして、およそ17営業日。

現実的に1日6人というのは難しいので、無理のない範囲で半分の3人ずつとすると34営業日。

他の予定などで実施できない日があったとしても、さほど無理をせずとも試用期間である3ヶ月以内には余裕をもってすべて終われそうであるということがわかりました。

やれそうであるならやりましょう、ということでメンバー全員に「全員と1on1をやります」というアナウンスをしました。

次に、メンバーを10人ずつのグループに分けました。1グループ(10人)との1on1を1週間で実施します。毎週末に、翌週実施予定のグループのメンバーとのカレンダー調整をして、それを毎週繰り返せば10週ほどですべてが終わる、という目安でスケジュールを考えました。

5月8日から開始して、全員との1on1が終わったのが7月9日。実際の期間は9週間でした。ほぼ見積もりのとおりに完走できました。

なにをやったか

1on1の目的は純粋な情報収集です。エンジニアリングマネージャとして自分のことを知ってもらう目的もあったため、これから自分がやろうと思っていることを簡単に説明はしましたが、それは最小限に留めました。まだ、タイミングとして自分の我を出す時期ではありませんし、全員の話を聴き終わらないうちに戦略だのを考えても効果があるとは思いません。

メンバーそれぞれがどういう個性を持ったエンジニアなのか。はてなでこれまでどのような仕事をしてきたのか。これらを教えてもらうことに時間の多くを使いました。

やってみてどうだったか

1on1のグループ分けは、入社の古い順にしました。これは、ベテランの人から組織全体の概観を聞いておくことで、中盤以降の若手の人たちとの会話に入る前に、その人たちの様子をある程度事前に頭に入れた状態にしておきたかったという目的がありました。

各チームの様子を知るだけなら、チームのテックリードと会話をすればおおよその様子はわかるのだろうと思います。ですが、全員と1on1をしたことで、それぞれの目線からチームや仕事がどう見えているかを聞くことができたので、実施前に想像していた以上に組織全体を立体的に知ることができました。

また、エンジニアのリストを眺めるだけではわからない、皆の得意分野や、志向について、グラデーション的に個性を知ることもできました。たとえば、ある人はiOSAndroid両方ができるけれど、iOSの方がやや得意であるとか、仕事ではPerlを書いているけれど本当はC#が好き、であるとか、そういう個性です。もちろんたかだか30分ですから、皆の個性のほんの触りの部分しかまだ知ることはできていないと思いますが、それでもメンバーリストを眺めていただけではわからないことをたくさん教わることができました。

最後に、自分にとって1on1の一番の成果は、エンジニア全員と「顔見知り」になれたことです。少なくとも最低1回は、直接対話をしたことがある、という状態は、今後マネージャとして、メンバーに声をかける際に、自分の心理的な負担を大きく軽減できます。

なにか相談がしたいと思った際に、知らない人に「はじめまして」と声をかけるのと、「先日の1on1ありがとうございましたー!」と声をかけるのとではまったく様子が違います。リモートワークが主体になっている現在の就業環境の中では特にこれは重要です。

最後に。これは自分からはわからないことですが、メンバーの信頼貯蓄が、なにもしない時と比べてわずかでも貯めることができているといいなぁ、とも思っています。そうなってるといいなー。

新入社員エンジニアリングマネージャーの入社1ヶ月の仕事

出戻りとして入社して1ヶ月が経ち、試用期間の1/3が終わろうとしています。

前回のエントリにも書きましたが、「技術グループ」というチームを横断した横串のエンジニア組織の専任エンジニアリングマネージャとして仕事を開始しました。

入社前に最初の1ヶ月でここまではやりたい、と思っていたことがおおよそできたような、少し届いていないような、そういう感覚です。

具体的になにをやったのかを、簡単に書いておこうと思います。

観察と情報収集

daiksy.hatenablog.jp

↑上記エントリでも書いたように、基本的には情報収集に最も時間を使いました。

毎朝30分CTOと1on1をし、目についた端からドキュメントを読みあさり、疑問があればまたCTOとの1on1で掘り下げる。主だったMTGを見学し、ひたすら観察する。こんな感じです。

エンジニア全員1on1

エンジニア組織専任のエンジニアリングマネージャとして仕事をするので、社内に会話をしたことがないエンジニアがいる、という状況で仕事をすべきではありません。

そこで、エンジニア全員との1on1を開始しました。

具体的な人数はここでは書きませんが、はてなでは従業員のおよそ半数がエンジニアです。全員1on1と言ってもかなりの人数と話をする必要があり、このエントリを書いている時点で4割ほどとの対話が終わりました。

来月中には終わってるといいな〜。というイメージで引き続き取り組みます。

これだけ大勢の人と対話をしていると、それぞれの開発チームに対して複数の視点から話を聞くことができるので、組織像がかなり立体的に浮かび上がります。

エンジニアリングマネージャとして、組織全体のおおよその地図を頭の中に描くためにも、これはやって良かったと今の時点ですでに思える活動です。

もう一つの目的としては、技術組織のエンジニアリングマネージャは、現場のエンジニアから見るとなんの仕事をするのかよくわからない人であろうと思います。そのため、一人ひとりに自分の仕事を説明して回りたい、という意図もあります。

バックログづくり

今後の技術グループの取り組みの手がかりとなる、バックログづくりに着手しました。

まずは、主だったメンバーで合宿を開催し、現状の課題や将来の展望などを話し合いました。

最終的にできあがったバックログのオーナーは自分です。合宿の内容を咀嚼しつつ、スクラムにおけるプロダクトオーナーがプロダクトバックログをつくる要領で、バックログアイテムを作成しました。

そのバックログアイテムに対して、重要度と困難さという2軸で重み付けをし、これに基づいて取り組む順番を決めていきます。重要で、すぐにできることは素早く取り掛かる、という具合にです。

このバックログの進捗状況をある程度オープンにしながら取り組んでいくことで、技術組織の業務を現場メンバーに理解してもらい、組織が進歩しているという実感を持ってもらいたいと思っています。

まもなくこのバックログがひととおり完成する予定なので、いよいよこれを手がかりにさまざまな問題や課題に取り組んでいこうと思っています。

入社直後の新任マネージャーの暮らし

今の会社に入社してから10営業日目を迎えました。

前回の転職のときにも書きましたが、マネージャーとしての転職は、他の職種とは違った難しさがあるのを実感する日々です。

マネージャーの仕事は、社内の人々からさまざまな期待をされる役割ですが、リモートワークということもあっていまいち何をしているのかみんなには伝わりづらい仕事です。そこで、毎日日報を書いたり、社内チャットの分報チャンネルにこまめに雑談も含めて吐き出したり、グループウェアに文章を書いたりしています。

このような入社直後のマネージャーの様子を、社内向けにグループウェアに投稿した文章をアレンジして書いておこうと思います。世の中の新任マネージャーの参考に少しでもなりますように。

どういう役割として入社したか

はてなでは、組織・基盤開発本部エンジニアリングマネージャーという役割をもって入社しました。

はてなは、はてなブログやMackerelなど複数のプロダクトを運用しており、それぞれに専門のチームがあります。各チームにはエンジニアやデザイナー、セールスなど、プロダクトを運用するために必要なさまざまな役割の人が所属します。

それとは別に、エンジニアやデザイナーといった専門職の場合、その職種の人々が横断的に所属する専門職グループがあります。いわゆるマトリクス型の組織です。

https://speakerdeck.com/hatena/engineers-recruitment

ぼくは、はてなのエンジニア全員が所属する技術グループの専任のエンジニアリングマネージャー(以下EM)として採用されました。はてなでは初めて設置されたポジションです。

今何を考えて仕事をしているか

入社して最初の仕事として、エンジニア全員との1on1を開始しましたが、まだまだはじまったばかり。

今は毎日CTOと1on1をして、いろいろなことを教わったり、まずは小さい仕事を受け取ったりしています。 技術グループのような組織横断的な集まりを支援するマネージャーの仕事は、人事や採用が重要です。前職でもそこは多く経験したところなので、こういった自分にとってやりやすいところから仕事をやりはじめています。

新しく就任したマネージャーは最初の100日間がとても重要だとよく言われます。アメリカ大統領は、最初の100日間でまずは短期的な成果を出して国民の信頼を得ることを意識するそうです。

ヤフーの元社長で、東京都の副知事である宮坂さんが次のような文を書いています。

note.com

ぼくが前職でマネージャーとして採用された最初の生活の様子を思い出すと、とても共感します。

daiksy.hatenablog.jp

要するに、自分が所属する組織のカルチャーを何も知らないうちから、戦略だのビジョンだのぶち上げるな。まずは観察に徹して文化を学べ、ということです。

新任マネージャーは基本的に自分が仕事をする環境について何も知りません。宮坂さんも「組織内で最も無能なのに最も期待される」状態だと書かれていますが、まさにそのとおりです。この状態のマネージャーは、仕事の手がかりを外にしか持っていません。何かしらの本に書かれていた一般的にベストプラクティスとされるもの。過去の組織での経験。などです。

これらを手がかりに、最初から大きなビジョンや戦略を描くとたぶんあまりうまくいきません。実際にそれでうまくいかなかった人を何人か知っています。

既存の組織の文化を知らずにビジョンを語っても、ただの現実と乖離した空虚な理想論にしかなりません。既存の組織を一度全部破壊して、ゼロから再構築するのだ、というミッションが自分にある場合のみ、それをやればよいのですが、それは自分がはてなでやりたいことではありません。

幸いぼくは出戻りなので、完全に新規に入社した人と比べると多少ははてなに対する理解を持っています。とはいえ3年のブランクをあまくみてはいけないと思っています。

このような考えから、最初の100日間。わかりやすく、試用期間の3ヶ月間と自分で定めているのですが、この期間はできるかぎり観察に徹しようと思っています。とはいえ、その間なにもしないというわけではなく、小さな成果を積み上げられるような仕事を中心に取り組んでいきたいです。

エンジニア全員1on1をやりはじめて、自分の技術グループに対する理解が少しずつ立体的になっているのを実感しています。 5月の末には、合宿を予定しており、そこで技術グループとしてのバックログをつくり、技術グループ専任EMとしてぼくがバックログのオーナーとなるつもりです。

このあたりが進み始めると、少しずつ技術グループEMとしてやるべきことが浮かび上がってくるかなと思っています。そうするとようやく所信表明などを展開できるようになりそうです。

短期的な小さな成果を積み上げながら、大きな成果は今の学習期間が落ち着いてからの、長距離走の中で出していきたいと思います。

アルムナイ採用体験記 (株式会社はてなに2回目の入社をしました)

2024年5月1日から、株式会社はてなで組織・基盤開発本部のエンジニアリングマネージャとして働き始めました。

2014年から、2021年まで社員だった時代があるため、いわゆる出戻りという形になります。

一度退職した会社に再び入社する、というのは、通常の転職活動と違った悩みなどもあり、自分も今回の転職に際して「アルムナイ採用」などのキーワードでいくつか参考にした記事がありました。

最近は身近な事例も耳にするとはいえ、まだまだ通常の転職と比べてアルムナイ採用は例が少ない気がするので、せっかくなので体験記を書いておこうと思います。

基本的には自分の個別の事例ですので、世間一般のアルムナイ採用の実態とは異なる箇所もあることをご承知おきください。

戻ろうと思ったきっかけ

もともと最初にはてなを辞めた理由が、自分の新しいキャリアを志したチャレンジという側面が強かったため、辞めた直後からなんとなく「機会があればまたはてなで働きたいな」というのはほんのり思っていました。

その後、具体的にはてなの選考を受けることになる最初のきっかけは、とある転職支援サイトでのスカウトでした。

前職での仕事が一区切りついて、転職を検討しはじめた最初に、いくつかの転職支援サイトの転職意向ステータスを変更しました。そのうちの1つで、ステータスを変更して1時間も経たないくらいのタイミングで、はてなからのスカウトを受けました。

スカウトをくれた人は、もちろん自分が過去にはてなで働いていることをご存知でしたし、自分もその方とは面識がありました。ただ、この時点ではまだ迷いのほうが大きく、具体的な話を聞くかどうかは迷っていました。

もともと働いていたことがある、とはいえ、戻りたいと表明して無条件に戻れるわけではありません。自分が活躍できるポジションが空いているか、その期の採用計画はどうなっているか、など通常の中途入社と同様のハードルが当然存在します。出戻りの場合は、それに加えてさらに変数が増えるのではないかと思います。端的に言えば、喧嘩別れした人を快く迎えられるかということ。もちろんそんなことはないでしょう。

自分は、円満に退職をしたつもりではいますが、実のところどうであるかはわかりません。

スカウトをいただいた、ということは少なくとも悪い印象は持たれてはいないだろうと思いましたが、それでも不安はありました。

ただ、はてなとは退職後もエンジニアコミュニティや、いろいろな企画で継続的に関わることも多く、こうしていろいろと接点を持ってくれるということは、大丈夫なのかもしれないな、という気持ちもありました。

そこで、退職後もたびたび連絡を取り合っていた親しい社内の人がいたので、応募する前にその人に相談することにしました。その方がぜひチャレンジしてみてください、と背中を押してくれたのが、最終的に選考に応募する決め手となりました。その後、その人の手引でカジュアル面談をセッティングしてもらい、そこでの会話の内容でさらに意向が高まり、通常の採用フローに入っていった、というのが一連の流れでした。

採用フローで注意したところ

いろいろな悩みを乗り越えて、いざ採用フォームから応募すると、ここからは通常の選考がはじまります。

自分としては、採用フローで特別扱いなどは決してせず、できれば通常よりも厳しめに見てほしいと伝えました。

自分の場合は2021年に退職してから、3年のブランクがあります。この3年間の成長(あるいは停滞?)が、入社後の期待値に大きく影響しており、最も入社後のギャップが生まれやすいポイントであるだろうと考えたからです。

よく知っている環境に戻り、同僚も自分のことをよく知っている。その状況でいざ仕事をはじめると、なにか思っていたのと少し違う...。この状況になってしまうことが自分にとって最も恐ろしいことでした。

特に自分の場合はマネージャとしての採用になるため、仕事の多くが目に見えづらい物事を扱う仕事となります。マネージャの採用で期待値にずれがあると、担当する組織全般に悪影響を及ぼします。通常の中途採用でも期待値を揃えることに細心の注意が必要な職種ですから、出戻りとなるとさらに慎重を期す必要があると考えました。

最終的に内定のオファーをいただいたあとも、その返事をする前に自分の入社後のイメージをドキュメントとして渡し、ギリギリまで期待値にずれがないかを確認しました。

入社後のあれこれ

いざ入社するにあたって最初に考えたことは、頭の中をいったんリセットしよう、ということでした。

3年の間に新しく入社した人も大勢いるため、出戻り感を出しすぎるとよくないことがたくさんあると思うからです。当然自分が知らないこともたくさんありますから、いったんはすべてリセットして、通常の中途入社の気持ちで仕事にあたろうと思いました。

いざ仕事をはじめてみると、自分が入社前に想像していた以上に忘れていることが多く、まったく勘も働かないため、普通にリセット状態でした。とはいえ油断せず初心の気持ちを心がけています。

他にもおもしろいエピソードとしてはこんな話も。

これは会社によってケースバイケースですが、業務に使用する各種アカウントなどが、新規作成ではなくサスペンドからの復帰、として扱えたものがいくつかありました。たとえばSlackの分報チャンネルであるtimes_daiksyはアーカイブから復帰できたので、3年前の投稿の続きから復帰できており、おもしろいです。

さいごに

自分は、今回社員としてはてなに出戻りをした第一号となりました。自分の近況を知ってくれた卒業生の皆さんの中には、「おっ」と思われた人もいらっしゃるかもしれません。

ちょっと気になるなぁという方は、自分が体験談も交えて相談相手になれるかなと思っていますので、お気軽にお声がけください。