この記事は ex-crowdworks Advent Calendar 2024の7日目の記事です。

はじめに

今年、株式会社クラウドワークスを退職した@nisyuuです。亀ラーメンと言われたら藤一番に脳内変換できるタイプのエンジニアです。
エンジニアとしてクラウドワークステック（旧クラウドテック）というフリーランスと企業をマッチングするエージェントサービスを開発していました。

今回は、退職の仕方をテーマに引き継ぎの極意や退職者マインドについてご紹介します。

人によっては刺激的な内容が含まれるかもしれないため、経営者や組織幹部、管理職、マネージャー、退職に敏感な方はなるべくタブを閉じるか、ページをお戻りください。
もしくは、こちらをクリックしてポジティブに切り替えてください。
https://www.tokyodisneyresort.jp/

読み進みたい場合は自己責任でお願いします。

なぜ書こうと思ったか

今年、クラウドワークステック開発チームを去ってから半年程度経過するのですが、去ったチームのエンジニアが未だ辞めていません。
素晴らしいチームであることが一番の要因かもしれませんが、入念に準備を重ねて退職したことも一要因であると考えています。

なぜ一要因になりえると考えたかというと、クラウドワークス以前に在籍していた会社では、退職後に同じチームだったメンバーが大量離職してしまい部署を壊滅に追いやった経験があるためです。
引き継ぎは行ったのですが、引き継ぎ期間が短すぎだったことや退職する人オーラが漏れ出てしまっていたことが、組織を不安定にさせ、壊滅に繋がった要因かもしれません。

壊滅すると開発が継続できないため、組織上長が取引先から強くきつくが叱責を受けてしまった、なんてこともあったようです。

今後このようなことを起こさせないために、将来有望で未来ある優秀な若手のエンジニア諸君には意思を持って引き継ぎを行い、退職検討者には正しい退職者マインドを持っていただけると幸いです。

意思を持って引き継ぎする

引き継ぎは意思を持って最後まで丁寧に時間をかけてください。
安心して辞められると思ったタイミングが、最後まで丁寧に引き継ぎできたサインです。
ちなみに私は、1年以上時間をかけました。
1年は長すぎるようにも思えますが、半年に一度あるような作業の引き継ぎや、限られたメンバーだけが可能な業務の引き継ぎがあったため長く時間をかけることになりました。

引き継ぎでやることは、多くの場合このようなことがほとんどだと思います。

属人化している作業の委譲
属人化している知識のドキュメント化
権限の委譲

属人化している作業の委譲

自分だけしかできない作業があれば、まずはドキュメント化し、次の実施者を選任して作業が滞りなくできるまでサポートしてください。
このとき、可能であれば選任は1人だけでなく複数人だと望ましいです。
複数人に作業を委譲することで、バス係数を高めるとことができます。

バス係数については、こちらを参考にしてください。

属人化している知識のドキュメント化

自分だけしか知らないなような業務知識や、開発知識があれば必ずドキュメント化してください。
業務知識の属人化は、突発的な弊害になりがちです。
残っているメンバーが業務を進められず、調査から始めなければならないというのは生産的でなく損失になります。
日本経済発展のために、しっかりドキュメント化していきましょう。

権限の委譲

開発を続けていると、限られたメンバーだけの持つ権限が出てくるものです。
サーバーへのアクセス権限、本番環境へのアクセス権限、スプレッドシートの権限、ドキュメントの権限、Slackワークフローの権限など様々な権限があるはずです。
退職を考え始めたら、考え始めた当日から権限委譲するぐらいの勢いで始めましょう。

退職者マインド

退職を決めても、上司以外には一切漏らさないことが退職を成功させるための大きな秘訣です。

過去に、上司に退職を伝えた際、「仲の良い同じチームのメンバーには退職することを伝えてあげてください」と言われたのを鵜呑みにして伝えたところ、チームメンバーが私の退職月の翌月、翌々月と次々に退職してしまったということがありました。メンバーへ伝えたタイミングは、退職日の2,3ヶ月ぐらい前でした。退職確定者と仕事する中で転職について考える時間が増えてしまったのだと思います。メンバーが社長&幹部らに呼び出されていたりしたので、なんかすいません...という感じでした。
退職というのは、それだけ影響範囲が広く深い組織の改修なんだと思います。

いずれ、チームには退職することを伝えなければなりませんが、タイミングとしてはチームを去る2週間前がベターだと思っています。
もちろん、就業規則の退職ルールになるべく従い、上司にはもっと前に伝えておきましょう。

注意点としては、引き継ぎをほとんど終えてから上司に伝えるのがベストです。
事前に引き継ぎを終えておくと、退職前の引き継ぎで忙しくなりチームに負荷がかかることを防止できるほか、退職日が決めやすくなりスムーズに退職できます。

退職後にメンバーの仕事を増やさない

チームメンバーに退職を伝えた後は、退職後にメンバーの仕事を増やさないための作業をしましょう。
当番の担当者リストやSlackなどの定期通知、ソースコードの中に自分のアカウントIDが含まれている場合、事前に洗い出して削除しておくことでチームの負荷を減らすことができます。
徹底して削除することで、残っているメンバーが退職者のことを考えてしまい、退職について考えるきっかけを作らないことにもつながります。

自然に引き継ぎする

一度にたくさんの引き継ぎをしてしまうと、チームメンバーが不自然と感じてしまうため少しずつ引き継ぎをします。
意思を持って引き継ぎするで紹介している内容を参考に、時間をかけて自然に行ってください。

徐々に引き継ぎを行い、徐々に作業に関わる時間を減らしていくイメージです。

転職相談の受け方

退職することが全社に公開されると、だいたい転職相談の依頼が来ます。
相談は快く引き受けて良いと思いますが、退職前で在籍中の場合はこちらを順守しておくと良いでしょう。

転職することを薦めない
会社のネガティブな話ついて追求しない
退職理由の本音を言わない
酒は控えめに

退職した後は自由にして良いと思いますが、風評被害につながることはやめておきましょう。

ポジティブ思考

どんなに自然を装っても、勘のいい人は転職活動していることに気づきます。
例え気づかれたとしても正式に公表するまで転職活動していることを公言せず、現職で100年続けるぐらいのポジティブスタンスでいましょう。

おわりに

本記事で紹介した引き継ぎや退職前の振る舞い方は、実践した体験談に基づいています。
私が退職する前まで、エンジニアの退職者が出て次のエンジニアが退職するスパンはおよそ0〜4ヶ月と半年以内でした。
それが、半年ほど退職者が出ていないため、入念に相当な準備をしてきた効果が多少は出ているのではないかと考えています。

2度と組織が壊滅する悲劇を繰り返さないためにも、本記事をご覧になった将来有望で未来ある優秀な皆様にはここで紹介した引き継ぎ法と退職者マインドを引き継いでいただき、日本経済発展のために貢献いただけることを切実に願っています。
Growth Target