退職エントリ公開タイミング、転職先への配慮と注意点

「退職エントリ、もう下書きはできてるんですけど、公開はいつがいいですか」——内定を承諾した候補者から、退職の伝え方が固まった後にこう聞かれることがあります。

IT・Web業界を中心に800名以上の転職支援に携わってきましたが、退職エントリのトラブルは「炎上するかどうか」よりも、公開のタイミングと書く内容の線引きを間違えたときに起きているというのが実感です。今回は、在職中の下書き作成から内定先への配慮、秘密保持義務との線引きまで、キャリアアドバイザーとして見てきた実務のポイントをお伝えします。

目次

1. 退職エントリの公開タイミングが、転職先での評価を左右する理由
2. 退職エントリを書く人が、IT業界に多い理由
3. 在職中に下書きを進めるなら、保存場所と端末に注意する
4. 公開はいつが安全か、内定承諾後・入社後・試用期間後を比較する
5. 秘密保持義務・NDAとの線引き、書いてはいけない情報
6. 会社名・プロジェクト名・エージェント名をどこまでぼかすか
7. 元同僚と気まずくならないための書き方
8. 炎上を招くNGパターンと、感謝は直接伝えるべき理由
9. よくある疑問に答えます
10. まとめ、退職エントリは「書く」よりも「いつ・何を出すか」で決まる

退職エントリの公開タイミングが、転職先での評価を左右する理由

退職エントリというと「炎上するかどうか」ばかりが話題になりますが、私が現場で相談を受ける内容の大半は炎上対策ではありません。「いつ出せば角が立たないか」という、公開タイミングそのものへの迷いです。

これは無理もないことで、退職エントリは書いている本人にとっては一度きりの区切りの儀式でも、読む側から見ると現職・転職先・元同僚という3方向に同時に発信される情報です。どのタイミングで出すかによって、同じ文章でも受け取られ方がまったく変わります。

内定承諾前に出せば現職に転職活動そのものが漏れるリスクがありますし、入社直後に出せば転職先の上司や同僚に「もう外部発信を始めるのか」という印象を与えかねません。書く内容以前に、公開の時点を設計することが最初の分岐点になります。

退職エントリを書く人が、IT業界に多い理由

そもそもなぜIT・Web業界では退職エントリを書く人がこれほど多いのか、疑問に思ったことのある方もいるかもしれません。私が見ている範囲では、エンジニアという職種そのものが技術ブログやSNSでの発信に慣れているという文化的な背景に加えて、転職の回数が他業種より多く、その都度キャリアを言語化する機会が生まれやすいという事情が重なっています。

一度きりの転職であれば胸の内にとどめておくことも、3回目・4回目ともなると「何が変わって、何が変わらなかったか」を自分自身のために整理したくなるものです。加えて、次の転職やカジュアル面談で経歴を説明する練習台として、退職エントリを書きながら頭の中を整理しているという候補者にも何人も会ってきました。

その意味で、退職エントリを書くこと自体は前向きな行為です。問題になるのは「書くかどうか」ではなく、ここまで述べてきたように「いつ、何を、どこまで書くか」という運用の部分に尽きます。

在職中に下書きを進めるなら、保存場所と端末に注意する

退職エントリは思い立ってすぐ書けるものではなく、多くの人が在職中の数週間から数ヶ月かけて少しずつ下書きを進めています。ここで見落とされがちなのが、どの端末・どのクラウドに保存しているかという点です。

貸与PCのローカルフォルダやデスクトップに下書きを置いたまま退職日を迎え、返却時にそのまま会社の管理下に残ってしまったという相談を、私はこれまで何件か受けたことがあります。多くの企業は退職者の貸与端末のデータを一定期間保全しており、業務用クラウドストレージ(会社アカウントのGoogleドライブやOneDriveなど)に保存していた場合も同様です。

社用のメールアドレスで下書きファイルを自分宛てに送っていたケースもありました。悪意がなくても、退職前後の情報システム部門のログ確認やアクセス権限の整理の過程で、担当者の目に触れる可能性はゼロではありません。下書きは私物の端末・個人のクラウドアカウントで管理し、会社のネットワークやアカウントを経由させないというのが、最低限のルールです。

ポイント： 退職エントリの下書きは「会社の資産で作らない」が原則です。業務時間中に会社のPCで書く行為自体、就業規則の職務専念義務に抵触しうるという点も含めて意識しておく必要があります。

もう一つ見落とされがちなのが、共同編集ツールの共有設定です。NotionやGoogle ドキュメントで下書きを作り、フィードバックをもらうために元同僚や現職の友人と共有リンクを送り合っているうちに、リンクの閲覧権限が「組織内の全員」のままになっていたという相談も受けたことがあります。共有相手を個別のメールアドレスで限定し、閲覧権限が広がっていないかを公開前にもう一度確認するだけで、防げるトラブルです。

公開はいつが安全か、内定承諾後・入社後・試用期間後を比較する

公開タイミングの選択肢は、大きく分けて4段階あります。それぞれで転職先への影響とリスクの質が異なるので、自分がどの段階を選ぶかを一度整理しておくと判断しやすくなります。

内定承諾前の公開は論外として、実務上迷いやすいのは「内定承諾後〜入社前」と「入社直後〜試用期間中」の境目です。私が担当者として勧めているのは、試用期間が明けて業務にひと通り慣れてから公開するという選び方です。

試用期間中は転職先の側もまだ本人の働きぶりを見ている段階で、そこで「早速ブログを書く人」という第一印象がついてしまうと、能力とは別の軸で評価が固定されかねません。ある企業の人事担当者から「入社2週間で退職エントリを公開されて、正直まだ様子見の段階だったので身構えた」という話を聞いたこともあります。

一方で、入社前に公開したい気持ちが強い場合は、現職への配慮に絞った内容にとどめ、転職先や新しい仕事内容には一切触れないという書き方で棲み分ける方法もあります。「何を書くか」を公開時点に合わせて調整する発想が、タイミング選びをこじらせないコツです。

実際にあった例を挙げます。フロントエンドエンジニアのTさん(31歳・経験7年)は、SESで客先常駐をしていた会社から自社開発企業への転職が決まり、内定承諾後に貸与PCのGoogleドキュメントで退職エントリの下書きを進めていました。円満退職はできたものの、入社2週目というタイミングで公開してしまい、新しい上司から「社内の雰囲気に慣れる前に外部発信して大丈夫か」とやんわり釘を刺されたそうです。

Tさんに相談されたときは、まず下書きを個人のGoogleアカウントに移してもらい、公開自体を試用期間明けまで先送りするよう提案しました。あわせて、常駐先の業務内容や案件の固有名詞に触れていた箇所を削り、現職への感謝と自分のキャリアの区切りに絞った内容に書き直しています。3ヶ月後、試用期間が明けたタイミングで公開し直したところ、社内から特に反応もなく、むしろ落ち着いて仕事に向き合えていることの証明になったと本人は話していました。

なお、公開タイミングの最適解は企業のカルチャーによっても変わります。エンジニア個人の技術ブログや登壇を奨励している企業であれば、入社早々の発信はむしろ好意的に受け取られることもあります。判断に迷う場合は、入社時のオンボーディングで「対外発信のポリシー」について触れられていないか確認したり、面談で技術ブログ文化について聞いていた内容を思い出したりするのも一つの手がかりになります。

秘密保持義務・NDAとの線引き、書いてはいけない情報

退職エントリで最も注意が必要なのが、在職中に知り得た情報をどこまで書いてよいかという線引きです。多くの企業は入社時に秘密保持誓約書を取り交わしており、そこには在職中の業務情報・技術情報・取引先情報などを対外的に開示しないという条項が含まれています。

典型的には、社内システムの構成や技術選定の詳細、非公開の売上・ユーザー数などの経営指標、取引先や顧客の名称、開発中の未発表プロダクトの仕様といった情報が挙げられます。こうした情報を退職エントリに書いてしまうと、秘密保持義務違反や営業秘密の漏えいに当たるとして、企業側から問題視されたり損害賠償を請求されたりする可能性があります。

ここは私が法律の専門家ではない立場からお伝えできる範囲を超える論点なので、実際に何が営業秘密に当たるか、損害賠償が認められるかどうかの個別の判断は弁護士に確認することをお勧めします。エン・ジャパンが運営する人事向けQ&Aでも、企業は退職エントリの公開そのものを完全に禁止することはできないものの、就業規則に「誹謗中傷・名誉毀損の禁止」や「営業秘密・個人情報の開示禁止」を明記することで抑止力を持たせられると説明されています(出典：「退職エントリ」を書くことを禁止できる?|人事のミカタ)。

キャリアアドバイザーとして実務的に言えるのは、感謝と学びの範囲に絞れば、ほとんどのトラブルは業務情報を書く前の段階で避けられるということです。「どんな技術を使っていたか」ではなく「何を学べたか」、「誰と働いたか」ではなく「どんな成長機会があったか」という抽象度で書けば、業務の詳細情報に触れずに退職エントリとしての価値は十分に成立します。

判断に迷ったときの簡便な確認方法として、私は「その情報が求人票や会社の採用ページに書いてある内容かどうか」を基準にするようお伝えしています。採用ページに載っている程度の抽象度(業界・事業内容・チーム構成の大枠など)であれば公開情報の範囲内と考えてよく、逆に社内資料や打ち合わせでしか知り得ない数字・仕様であれば、退職エントリには持ち出さないという線引きです。

具体的な書き換え例で見てみます。「月間流通額80億円のECサイトの決済基盤を、旧システムからAWSに移行するプロジェクトを担当しました」という一文は、非公開の経営指標と技術構成が同時に含まれているため危険度が高い書き方です。これを「大規模なECサイトの決済基盤刷新プロジェクトで、クラウド移行を担当しました」まで抽象化すれば、伝えたい経験の骨格は残しつつ、営業秘密に触れるリスクを大きく下げられます。

会社名・プロジェクト名・エージェント名をどこまでぼかすか

固有名詞の扱いも、多くの人が悩むポイントです。私の考えでは、退職エントリにおける固有名詞の記載は次の3段階で判断するとわかりやすくなります。

エージェント経由で転職した場合、担当エージェントや利用したサービス名についても同様の配慮が必要です。エージェントとのやり取りの中身(提示された年収の交渉経緯や、他社の選考状況をどう伝えたかなど)を実名入りで書くと、エージェント個人が特定されたり、紹介先企業との関係に影響したりすることがあります。

私自身、過去に担当した候補者の退職エントリで実名を出されて驚いたという話を、同業のアドバイザーから聞いたことがあります。悪意がなくても、書かれた側からすれば本人確認の連絡を入れざるを得なくなるなど、余計なやり取りが発生してしまいます。エージェント名は「転職エージェントを利用した」程度の言及にとどめ、担当者の発言を引用する場合も、いつ誰から言われたかが特定できないよう抽象化するのが無難です。

元同僚と気まずくならないための書き方

現職・元同僚についても同じ発想が使えます。個人が特定できる書き方(「〇〇部の△△さんが」のような表現)は避け、役割や立場でぼかして書くことで、元同僚が読んだときに気まずさを感じにくい文章になります。

特に注意したいのが、複数人で分担していた業務を一人称で語ってしまうケースです。「私がプロジェクトを立て直した」という書き方は、実際にはチームで達成した成果であっても、読んだ元同僚には「自分の貢献が消された」と映ることがあります。成果を語るときは「チームで」「一緒に」という主語を意識的に残しておくと、同じ内容でも受け取られ方が変わります。

炎上を招くNGパターンと、感謝は直接伝えるべき理由

内定取り消しに発展するような炎上は、公開タイミングの問題というより書いた内容そのものが原因になることがほとんどです。弁護士による解説では、内定取り消しの有効性は炎上が「内定前」か「内定後」かによって判断が分かれ、内定は法律上「始期付き解約権留保付き雇用契約」という性質を持つとされています。つまり内定が出た時点ですでに雇用契約は成立していて、その後の言動を理由に取り消せるかどうかは、その内容が犯罪行為・法律上不適切な行為・道徳上の問題のどれに該当するかという段階を踏んで判断されるという整理です(出典：SNSにおける「炎上」を理由とする内定取り消しについて【弁護士が答えます】)。

この整理を踏まえると、退職エントリで避けるべきなのは、感情に任せた誹謗中傷や、特定個人への攻撃と受け取られる表現です。「上司が無能だった」「あの部署は終わっている」といった強い言葉は、たとえ事実に近い実感だったとしても、書き手の意図以上に強く伝わり、読んだ第三者から見れば単なる悪口として拡散されます。

感謝は退職エントリではなく、直接本人に伝えるべきものだというのが、私がこの手の相談で必ず伝えている考え方です。お世話になった上司や同僚への感謝を、公開の場を通じて間接的に伝えようとすると、伝わり方が歪みやすいうえに、感謝のはずが結果的に自分語りや自慢に読めてしまうことがあります。感謝は退職の場で直接言葉にして、退職エントリには自分自身の振り返りとして書く、と役割を分けておくと文章がすっきりします。

もう一つ実務的な対処法として、公開範囲を限定するという選択肢も覚えておいてください。noteやブログサービスの多くは、URLを知っている人だけに公開する限定公開機能を備えています。元同僚や社内の関係者にだけ読んでもらいたい内容であれば、全体公開にせず社内SNSや限定公開URLで共有するという方法で、リスクを大きく減らせます。

よくある疑問に答えます

ここまでで公開タイミングと書く内容の線引きは押さえられますが、実際に相談を受けていると、その手前で立ち止まる質問がいくつか繰り返し出てきます。最後にまとめて答えておきます。

就業規則に「退職エントリの公開を禁止する」という条項があっても、表現の自由との兼ね合いから、公開そのものを一律に禁止する規定は効力が及ばないと解されることが多いようです。ただし、名誉毀損や営業秘密の開示に当たる内容を書けば、就業規則の規定とは別に懲戒処分や損害賠償請求の対象になり得ます。就業規則の条文だけを根拠に「書いても大丈夫」と判断するのではなく、書く内容自体で線を引くという考え方の方が実務には合っています。

一度公開した文章を削除しても、SNSでの引用やスクリーンショット、検索エンジンのキャッシュという形で残ってしまうことがあります。いわゆるデジタルタトゥーの状態です。「公開後に消せば取り消せる」という前提では書かず、公開する前に一度、転職先の人事担当者が読んだらどう感じるかを想像して読み返す工程を挟むことをお勧めしています。

転職先から退職エントリについて聞かれた場合は、隠したり取り繕ったりせず、「現職への感謝を書いた」という趣旨を素直に伝えれば十分です。むしろ聞かれてから慌てるのは、内容に後ろめたさがある場合がほとんどなので、そもそも聞かれても困らない内容にしておくことが一番の対策になります。

もう一点、フリーランスや業務委託への転向を機に退職エントリを書く場合は、勤務先が変わらないケースと違って「独立の経緯」まで踏み込んで書きたくなる人が多いのですが、独立後に業務委託先として現職の取引先候補が読む可能性がある点は見落とされがちです。取引先になり得る相手が読む前提で、単価や契約条件への不満は書かない方が、その後の営業活動に響きません。

なお、退職を伝えるタイミングそのもの(有給消化や引き継ぎとの兼ね合い)は、退職エントリの公開タイミングとは別の論点です。現職とどう折り合いをつけて円満に辞めるかについては、在職中の転職活動、有給消化と引き継ぎでつまずく3つの壁で詳しく扱っているので、あわせて参考にしてください。

まとめ、退職エントリは「書く」よりも「いつ・何を出すか」で決まる

退職エントリの相談を受けていて感じるのは、文章を書く力よりも、公開のタイミングと範囲を設計する力の方が結果を左右するということです。在職中の下書きは私物の環境で管理し、公開は試用期間が明けてから、内容は感謝と学びの範囲にとどめて固有名詞はぼかす。この4つを押さえておけば、炎上のリスクも、転職先での心証を損なうリスクも、大部分は避けられます。

退職エントリは義務ではありません。書くこと自体を目的にせず、誰に何を伝えたいのかがはっきりしないうちは、無理に急いで公開する必要はないというのが、この記事で一番伝えたかったことです。

急いで公開したい気持ちが強いときほど、一晩置いてから読み返してみてください。書いた直後の高揚感がやや落ち着いた状態で読み直すと、削るべき固有名詞や、感謝ではなく愚痴に寄っている表現に自分で気づけることが多いというのが、これまで多くの退職エントリの相談に付き合ってきた実感です。