ITエンジニアの登壇・SNS・技術ブログ｜機密との切り分け

ITエンジニアの転職活動では、登壇資料、技術ブログ、SNSの投稿が「実績」として扱われることがあります。一方で、未公開の設計や顧客名が混ざると、就業規則や秘密保持の確認が先です。一次情報の入口は、IPAの情報セキュリティ関連ガイド、経済産業省の不正競争防止法案内、文化庁の著作権案内です。このページは、社内の事前確認窓口、公開してよい粒度、個人アカウントと会社アカウントの区別に留めます。何を投稿してよいかの適法断定、機密の持ち出し手順は書きません。

事前確認

登壇資料や記事を公開する前に、会社が指定する窓口へ確認する手続です。有無は就業規則によります。

SNSガイドライン

社名や業務に触れる発信の社内ルールです。無い場合は窓口の有無だけ確認します。

営業秘密

法令上の類型です。本編は営業秘密です。このページでは該当判定をしません。

OSS公開

コードをオープンソースとして出す手続です。本編はOSS貢献です。

対外発信の確認は、NDAと副業プロジェクト、営業秘密の法令入口、OSSの公開プロセスと切り分けます。このページは登壇・SNS・ブログの社内ルール確認に限定します。

• 中心テーマ：対外発信と機密の確認側は「登壇・SNS・ブログの社内ルール」。隣接側は「—」。
• NDA・副業：対外発信と機密の確認側は「契約の読み方」。隣接側は「NDA」。
• 営業秘密の法令：対外発信と機密の確認側は「入口は関連テーマ」。隣接側は「営業秘密」。
• OSSの公開：対外発信と機密の確認側は「ライセンスとCLA」。隣接側は「OSS貢献」。
• 適法・持ち出し：対外発信と機密の確認側は「断定・手順を書かない」。隣接側は「公式案内・専門家」。

求人票の「発信歓迎」「勉強会登壇」は、機密の公開許可ではありません。登壇の事前承認、資料レビューの有無、個人名義の制限を面談で確認してください。

• 社内の発信ガイドラインの所在を探した
• 事前確認窓口の有無をメモした
• 投稿の適法断定をしない方針にした
• 現職の未公開設計を資料に入れない方針にした
• NDA・営業秘密・OSSの記事と分けた

情報の取扱いはIPAの情報セキュリティ関連ガイド、営業秘密は経済産業省の不正競争防止法、著作物は文化庁の著作権案内が入口です。投稿の適法断定と持ち出し手順はこのページの範囲外です。

対外発信と機密の確認では、ツール名の羅列より、自分が判断した範囲の説明が先です。秘密情報は一般化し、確認できない数字は書きません。

1. 01
   ガイドラインを探す

   就業規則とSNS・広報案内の発信ルールだけをハイライトします。投稿文の適法診断はしません。

2. 02
   窓口を確認する

   登壇・執筆の事前確認先があるかを人事または広報へ尋ねます。

3. 03
   関連する職種・テーマと分ける

   NDA、営業秘密、OSS貢献です。

4. 04
   実績の粒度を決める

   公開済みの一般化した説明だけを経歴に使い、未公開仕様は書きません。

対外発信と機密の確認の応募可否は、肩書や媒体の並び順ではなく、次の順で切り分けます。

• 発信ガイドラインの所在を探す
• 事前確認窓口の有無を確認する
• 投稿の適法を自分で断定しない
• 未公開設計を資料に入れない
• NDA・営業秘密・OSSの本編は関連テーマへ
• 現職の機密を相談先に渡さない

Geekly・レバテックキャリア・TechGo・TechClipsには、次の職場の登壇・発信ルールが書面にあるかを質問できます。現職の未公開設計は相談先に渡さないでください。

• Geekly・レバテックキャリア

  次職の登壇・発信ルールが書面にあるかの確認に使えます。

• TechGo・TechClips

  プロダクト系で発信が評価される求人の、事前承認の有無確認に使えます。

• 自己管理

  未公開の設計図や顧客名をスライドに入れない方針を、規程の言葉で確認してください。

相談先を複数使う場合は、企業名・求人ID・応募経路を一覧にして重複応募を防いでください。転職支援とスカウトでは受けられる支援が異なるため、同じ基準で単純比較せず、目的に合う窓口を選びます。

• 発信歓迎を公開許可と読む

  求人の歓迎は機密の公開許可ではありません。窓口を確認してください。

• ブログなら問題ないと思う

  媒体が違っても業務情報の範囲は規程次第です。適法断定はしません。

• OSSの職種・テーマと同じ手続だと思う

  コード公開の本編はOSS貢献です。登壇許可と混ぜないでください。

1週間で、社内ガイドラインの所在、事前確認窓口、NDA・営業秘密・OSSとの違いまで終えます。投稿文案の適法診断はしません。

1. 01
   月：規程探索

   発信ルールの文書名を控える。

2. 02
   火：窓口

   事前確認の担当を質問。

3. 03
   水〜木：切り分け

   NDA・営業秘密・OSSのリストと分ける。

4. 04
   金：経歴

   公開可能な粒度だけ残す。適法診断はしない。

対外発信と機密の確認の用語は、公式資料の定義と求人票の言葉がズレることがあります。次の表で、経歴に書く粒度と求人票での確認先を揃えてください。

対外発信と機密の確認では、媒体記事より公式資料を先に開き、分からない点だけを相談先と公式窓口に分けます。

1. 01
   IPA 情報セキュリティ関連ガイド

   情報取扱いの参考入口 一方で、投稿の適法根拠には使わない

2. 02
   経済産業省 不正競争防止法

   営業秘密との切り分け 一方で、該当判定はしない

3. 03
   文化庁 著作権

   資料の権利との切り分け 一方で、帰属の個別断定はしない

• 手順1：発信ガイドラインの所在を探す
• 手順2：事前確認窓口の有無を確認する
• 手順3：投稿の適法を自分で断定しない
• 手順4：未公開設計を資料に入れない
• 手順5：NDA・営業秘密・OSSの本編は関連テーマへ
• 手順6：現職の機密を相談先に渡さない

• 社内の発信ガイドラインの所在を探した
• 事前確認窓口の有無をメモした
• 投稿の適法断定をしない方針にした
• 現職の未公開設計を資料に入れない方針にした
• NDA・営業秘密・OSSの記事と分けた
• 棚卸し「ガイドラインを探す」を経歴の1行にした
• 棚卸し「窓口を確認する」を経歴の1行にした
• 棚卸し「関連する職種・テーマと分ける」を経歴の1行にした
• 棚卸し「実績の粒度を決める」を経歴の1行にした

• 避けること：発信歓迎を公開許可と読む

  求人の歓迎は機密の公開許可ではありません。窓口を確認してください。

• 避けること：ブログなら問題ないと思う

  媒体が違っても業務情報の範囲は規程次第です。適法断定はしません。

• 避けること：OSSの職種・テーマと同じ手続だと思う

  コード公開の本編はOSS貢献です。登壇許可と混ぜないでください。

• 対外発信と機密の確認の希望軸を一文で言えるようにした
• 公式資料の入口URLをブックマークした
• 曖昧な条件は応募理由の主軸から外した
• 相談先は2系統、重複応募の管理表を用意した

ITエンジニアの登壇・SNS・技術ブログ｜機密との切り分けの応募準備では、「知っている」「使った」で止めず、どの入力を受け、何を判断し、どの成果物を残し、障害時にどこまで対応したかを分けます。対象領域は登壇・技術ブログ・情報セキュリティです。公開できない固有名詞や数値は一般化し、公式資料（IPA 情報セキュリティ関連ガイド、経済産業省 不正競争防止法、文化庁 著作権）で確認した定義と、自分の担当実績を混同しないでください。

1. 01
   公式定義を一つ選ぶ

   IPA 情報セキュリティ関連ガイド、経済産業省 不正競争防止法、文化庁 著作権を開き、登壇・技術ブログ・情報セキュリティに関係する用語を一つ選びます。版や更新日が分かる場合はメモし、求人票独自の表現と分けます。

2. 02
   担当箇所を図にする

   入力、処理、出力、依存先を四角で描き、自分が変更・レビュー・運用した場所だけに印を付けます。触れていない箇所は実績に含めません。

3. 03
   失敗例を一つ添える

   正常系だけでなく、失敗の検知、切り分け、復旧、再発防止の順に一例を整理します。秘密情報と確認できない改善率は書きません。

4. 04
   求人ごとに質問へ変える

   必須条件と歓迎条件を分け、主担当・補助利用・学習予定のどれに当たるかを記録します。回答が曖昧な項目は応募理由の主軸にしません。

• ITエンジニアの登壇・SNS・技術ブログ｜機密との切り分けで自分が決めたことを一文で説明できる
• 登壇・技術ブログ・情報セキュリティの利用経験と設計・運用経験を分けた
• 成果物、レビュー責任、障害時の担当を確認した
• 出典のない求人数、年収、改善率を書いていない
• 求人IDと応募経路を管理し、重複応募を防いだ