この記事は
女性エンジニア応援 Advent Calendar 2025 22日目の記事です。
Advent Calendar は久々に参加している最中のミズサワキヌコです。
ゲーム業界でエンジニア10年目になります。
本記事では、守秘義務のある立場でも発信を続けるために、
私がやっている線引きの作り方をまとめます。
はじめに：守秘義務があると、発信が急に難しくなる
エンジニアとして働いていると、
守秘義務や契約の都合で「書かない方が安全」と感じる場面が増えます。
私自身も、記事を書いていて不安になり、ボツにすることがあります。
一方で、発信にはメリットもあります。
学びが定着する、アウトプットの習慣ができる、
未来の自分や、内容によっては同僚や上司が助かる、など。
この記事では「これなら絶対に安全」と言い切るつもりはありません。
会社・契約・職種で「線引き」の正解は変わるからです。
その代わりに、私が実際にやっていた
「書ける範囲を設計して発信を続ける」ための考え方を、
個人制作・学習・一般化できる題材を例に、まとめます。
- 許可リスト／禁止リストの雛形（コピペ運用）
- 投稿前の確認テンプレ
- 「会社の話をしない」まま成立させる記事テンプレ
を載せるので、同じ悩みを持つ方の材料になればうれしいです。
前提：不安の正体は「時間」より「再現性のない判断」
発信が止まるとき、私の中で起きていたのはだいたいこの3つでした。
- 何がダメなのか境界が曖昧で、毎回の判断コストが重い
- よかれと思って情報を出すほど、誰かに迷惑をかけそうで怖い
- 「自分の言葉」が、どこかに悪影響をおよぼさないか不安
そこで私は、今回の記事執筆をよいきっかけに
今判断の軸になっているチェックリストを言語化してみることにしました。
許可リスト／禁止リスト／記事テンプレを作ることで、
判断コストを下げ、情報漏洩のリスクを減らすことを目的としています。
事例：個人で制作しているゲームや学習から技術記事を抽出する
私が今年書いていた技術記事はざっくり以下です（タイトルはそのまま引用します）。
- 機械に任せられるコードレビューとは何か
- 【Unity】classとstructの使い分けは「コピーしていいか」が大きな判断軸になると思う話
- UnityのRigidbodyで無重力空間で噴射移動するアクションゲームを実装する
- UnityのURPで徐々に実体化するホログラムシェーダーを作ってみる
ここで大事なのは、題材の切り方でした。
会社やプロジェクトの話をせず、「個人の制作物」「学習の記録」を中心に分解すると、
比較的安全に成立しやすいと考えています。
また、転職用ポートフォリオをまとめた有料記事もnoteに書きました。
私が取った方針は、
個人で自作した作品やポートフォリオ、学習で得た知識のみ発信で扱う
というものです。
これにより、固有の業務知見ではなく、
個人制作や学習の範囲に収められると考えています。
コピペ運用できる：許可リスト／禁止リスト／確認テンプレ
ここからは、そのまま貼って使える雛形をまとめてみます。
①題材の「許可リスト」雛形
【許可リスト（自分用）】
- [ ] 自分が0→1で作ったもの（個人制作・学習制作・自主制作）
- [ ] 公開OKの素材／アセット／サンプル（ライセンス確認済み）
- [ ] 一般化した学び（特定のプロジェクト・時期に紐づかない）
- [ ] 公知の情報（公式発表など） ※引用は最小限
- [ ] 手順・判断基準・工夫中心で、内部事情に触れていない
補足：
- 「単体ではOK」でも、組み合わせで特定されないかも確認する
②避ける（禁止）リスト雛形
【禁止リスト（自分用）】
- [ ] 未公開情報（仕様・数値・日程・体制・運用・ツール構成など）
- [ ] 会社やタイトルが想起できる固有名詞のセット（地名×役割×人数×時期 等）
- [ ] 「社内では当たり前」だが外に出ていない判断基準
- [ ] 特定タイトルを連想させる表現（未発表の機能・演出・収録物・画面）
- [ ] 裏話／与太話（読者の興味は引けても、誤解と憶測を呼びやすい）
迷ったら：
- 書かない / 削る / 置き換える
③投稿前の「確認3つ」テンプレ
【投稿前に自分に聞く3つ】
1. 社内の人が読んでも困らないか？（誤解・憶測を呼ばないか？）
2. 記事の価値に本当に必要か？（省いても成立するか？）
3. 抽象化／置き換えで言えないか？（固有→一般、具体→考え方）
会社の話をしないまま、読める記事にする「本文テンプレ」
ここまでのことをふまえて、個人制作や学習で制作したものなどを載せることを決めたら、
あとは読める形にするだけです。
わたしの場合、ここで結構苦労をしたのですが、
いくつか試した結果以下の型に寄せると迷いが減りました。
一人だと詰まるところは、ChatGPTに壁打ちして整理しています。
## はじめに
- （例：この記事を書いたきっかけ、経緯をふくめた記事概要）
## 何を作ったか
- （例：Unityで無重力移動の噴射アクションを作った / 徐々に実体化するホログラムシェーダも作った）
## 狙い
- （例：操作方法 / 演出 / 実装コードの見せ方）
## 完成イメージ
- （例：アクションの様子 / ホログラムシェーダの見た目が分かるGIF画像）
## 最小コード／設定
- （例：完成イメージを再現するために必要な最小限の手順を示すもの）
## 工夫するところ
1. （例：読者の理解がしやすい最小コードに削る）
2. （例：読者がすぐにコピペして試せるよう、差分となるファイルの全コードを載せる）
3. （例：読者がどんな実装の話なのかすぐにイメージできるよう、最初に完成イメージを載せる）
## 詰まったところと想定される解決策
- （例：動き / 見た目が思い通りにならなかった → どうすれば解決出来そうか道筋を示す）
## おまけ：線引きメモ（任意）
- 会社や業務の情報に触れないようにするため、具体は適切に伏せる
このテンプレは、わたしがQiitaに技術記事を書くときに
気を付けていたポイントをまとめたものです。
わたしは、技術記事でのポイントは
再現性のある方法を読者が手を動かせる粒度まで落として提示すること
だと思っています。
このために、コードの紹介も積極的に検討しています。
コードの紹介は自分で制作したものなら、自分の許せる範囲で公開することが可能です。
※この記事で扱うのは「題材の選び方」と「書き方の型」です。
最終的な可否判断は所属先の規程に従ってください。
その他：仕事で携わった技術についての扱い
最後に、かなり現実的な話です。
仕事で携わった「技術の」記事を書きたくなったとします。
そんな時、わたしは以下のことに注意して執筆するかどうかを検討していました。
所属先に紐づいて特定されうる非公開情報
（体制、運用、未発表の仕様、非公開の技術判断など）に触れていないか
わたしの場合、実名でやっていることもあり
過去の同僚や上司、知り合いなどに所属先を一定認知されているということもふまえると
このあたりはシビアにならざるをえませんでした。
ハンドルネームでも、文脈の組み合わせで特定されることはあるので、
題材の切り方（個人制作／一般化）を優先すると安全寄りです。
発信は一発勝負ではなく、長期で信用に関わる話なので
慎重な運用が肝要かと思います。
おわりに：怖いからこそ、設計して続ける
守秘義務がある立場での発信は、どうしても慎重になります。
だから私は今回、勇気で突破するのではなく、仕組みで迷いを減らす方を選びました。
許可リスト／禁止リスト／テンプレを用意して、毎回ゼロから悩まないようにする。
もし今、発信したいのに止まっている方がいたら、まずは一つだけでも構いません。
「確認3つ」をメモ帳に貼るところからでも、少し楽になると思います。
この記事が、安心して続けるためのヒントになればうれしいです。