✍️ 필사 모드: 成長のプロセス（フィードバックループ）とソースコード漏洩対応法

Plan（計画）
  → 目標を設定し、実行方法を計画する
Do（実行）
  → 計画を小規模で実行する
Check（確認）
  → 結果を測定し、期待値と比較する
Act（改善）
  → 差異を分析し、改善方案を策定する
  → 次のPlanへつなげる

Observe（観察）
  → 現在の状況をありのまま把握する
Orient（状況判断）
  → 観察した情報を既存の知識、経験、文化的文脈と結合して解釈する
Decide（決定）
  → 解釈に基づいて最適な行動方針を決定する
Act（行動）
  → 決定を実行する
  → 実行結果が再びObserve段階の入力となる

目標設定（Goal）
  → 具体的で測定可能な目標を立てる
  → 例：「今四半期中にTypeScript型システムの深掘り学習」

実行（Execute）
  → 毎日30分学習し、実務に適用する
  → 小規模プロジェクトで実験する

測定（Measure）
  → 学習時間、完了した課題、適用したパターン数を記録する
  → 定量的指標が重要

振り返り（Reflect）
  → 「何が効果的だったか？」
  → 「どこで詰まったか？」
  → 「なぜ詰まったか？」

調整（Adjust）
  → 学習方法を変更する
  → 目標を修正する
  → 新しいサイクルを開始する

Keep（維持すること）
  → うまくいっているので継続すること
  → 例：「デイリースクラムでブロッカーを素早く共有する文化」

Problem（問題点）
  → 改善が必要なこと
  → 例：「コードレビューに3日以上かかることが多い」

Try（試みること）
  → 次のスプリントで試すアクションアイテム
  → 例：「レビュー依頼後24時間以内に初回レビューのルール導入」

Liked（良かったこと）
  → チームの雰囲気、達成感などポジティブな経験
  → 例：「ペアプログラミングで知識共有がうまくできた」

Learned（学んだこと）
  → 新しく知った技術、プロセス、教訓
  → 例：「E2Eテストの重要性に気づいた」

Lacked（不足していたこと）
  → リソース、時間、ツールなどの不足
  → 例：「QA環境が不安定でテストが遅延した」

Longed for（望むこと）
  → 今後備えたいもの
  → 例：「ステージング環境自動デプロイパイプライン」

Start（始めること）
  → 新たに導入するプラクティス
  → 例：「週次テック共有セッション」

Stop（やめること）
  → 非効率的または有害な慣行
  → 例：「金曜午後のデプロイ」

Continue（続けること）
  → 効果が実証された慣行
  → 例：「リリースノートの自動化」

// 悪いレビューコメント
「この変数名を変更してください」

// 良いレビューコメント
「この関数が二つの責務を持っているように見えます。
データ検証と変換を分離すると、テストしやすくなると
思いますが、いかがでしょうか？」

ポストモーテム構成:
1. タイムライン（何が起こったか）
2. 影響範囲（誰に、どれだけ）
3. 根本原因分析（なぜ起こったか）
4. うまくいった点（何が被害を軽減したか）
5. 改善点（何が不足していたか）
6. アクションアイテム（具体的 + 担当者 + 期限）

Objective: フロントエンドパフォーマンス50%改善
  KR1: LCP 2.5秒以下達成 -> 現在3.1秒（進捗60%）
  KR2: バンドルサイズ30%削減 -> 現在20%削減（進捗67%）
  KR3: Core Web Vitals全項目Good -> 2/3達成（進捗67%）

レビュー結果:
  -> KR1は画像最適化でさらなる改善が可能
  -> KR2はダイナミックインポートの拡大適用が必要
  -> 全体的に順調だが、残り期間を考慮すると集中が必要

ステップ1：感情を分離する
  → フィードバックを受けた時、すぐに反応しない
  → 「このフィードバックは自分の行動に対するもので、自分という人間に対するものではない」

ステップ2：核心メッセージを抽出する
  → 感情的な表現を取り除き、核心だけを見る
  → 「コードがめちゃくちゃだ」→「このコードの可読性を改善できる」

ステップ3：具体的な質問をする
  → 「特にどの部分を改善すると良いでしょうか？」
  → 「例を挙げていただけますか？」

ステップ4：実行計画を策定する
  → フィードバックを具体的なアクションアイテムに変換する
  → 期限と測定基準を定める

ステップ5：フォローアップを共有する
  → 改善結果をフィードバック提供者と共有する
  → フィードバックループを完成させる

# 週次成長日誌
## 日付：YYYY-MM-DD ～ YYYY-MM-DD

### 今週の目標
- [ ] 目標1
- [ ] 目標2
- [ ] 目標3

### 達成したこと
- 成果1：簡潔な説明
- 成果2：簡潔な説明

### 学んだこと
- 技術的学習：何を新しく学んだか
- ソフトスキル：協業、コミュニケーションで学んだ点

### 反省点
- 不足していた点と原因分析
- 時間管理、集中度など

### 来週の目標
- [ ] 目標1（優先度高）
- [ ] 目標2
- [ ] 目標3

### 感謝していること
- 同僚、環境、機会などへの感謝

### 一行振り返り
- 「今週を一文で要約すると？」

よくあるミスのパターン：
- .envファイルを.gitignoreに追加していない
- プライベートリポをパブリックに変更
- フォークしたリポに社内コードをコミット
- APIキーやデータベースパスワードのハードコーディング

サプライチェーン攻撃シナリオ：
- 依存パッケージへの悪意あるコード挿入
- CI/CDパイプラインへの侵入
- 開発ツールプラグインを通じたコード窃取

即時隔離チェックリスト：
- 漏洩したリポジトリまたはアクセス経路を遮断
- 関連アカウントのパスワードを即時変更
- VPN、SSHキーなどのアクセス手段を廃棄
- 漏洩範囲の初期把握（どのコード、どのブランチ、どの期間）

# シークレットローテーションチェックリスト
# 1. APIキーの全面再発行
# 2. データベースパスワードの変更
# 3. OAuthクライアントシークレットの再生成
# 4. JWT署名キーの交換
# 5. 暗号化キーのローテーション
# 6. サービスアカウント資格情報の再発行
# 7. 環境変数の全面更新

# BFG Repo-Cleanerを使用した機密情報の除去
# 注意：ヒストリーの書き換えはチーム全体に影響する

# 特定ファイルの除去例
bfg --delete-files credentials.json

# テキストパターンの除去例
bfg --replace-text passwords.txt

# 整理後の強制プッシュ
git reflog expire --expire=now --all
git gc --prune=now --aggressive

影響評価項目：
- 漏洩したコードの範囲と機密度
- 含まれるビジネスロジックの価値
- 顧客データの露出有無
- セキュリティ脆弱性の露出有無
- 競合他社への影響
- 法的義務事項（個人情報保護法など）

営業秘密の3要件：
1. 非公知性：公然と知られていないこと
2. 経済的有用性：独立した経済的価値を持つこと
3. 秘密管理性：合理的な努力で秘密として維持していること

「秘密管理性」が法廷で最も頻繁に争われる要件である。
→ アクセス制御、秘密表示、NDAなどが管理努力の証拠となる。

仮処分申請の準備物：
1. 漏洩事実の証拠（スクリーンショット、ログ、コミット記録）
2. 営業秘密に該当する疎明資料
3. 秘密管理努力の証拠（アクセス制御記録、NDAなど）
4. 緊急性の疎明（使用が継続されれば回復不能な損害）
5. 担保金（裁判所が定めた金額）

証拠保全方法：
- Webページキャプチャ（公証を含む）
- Gitログおよびコミット記録のバックアップ
- アクセスログの保存（サーバー、VPN、リポジトリ）
- メール、メッセージなどの通信記録の保存
- デジタルフォレンジック専門家の確保

# GitHub Actionsでのシークレットスキャニング設定例
name: Secret Scanning
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Run GitGuardian scan
        uses: GitGuardian/ggshield-action@v1
        env:
          GITGUARDIAN_API_KEY: GITGUARDIAN_API_KEY_PLACEHOLDER

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.5.0
    hooks:
      - id: detect-private-key
      - id: check-added-large-files
        args: ['--maxkb=500']

  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.4.0
    hooks:
      - id: detect-secrets
        args: ['--baseline', '.secrets.baseline']

# Gitコミット署名の設定
git config --global commit.gpgsign true
git config --global user.signingkey YOUR_GPG_KEY_ID

# 署名済みコミットの確認
git log --show-signature -1

DLP適用領域：
- メール添付ファイルの検査
- クラウドストレージアップロードの監視
- USB等外部ストレージの使用制限
- クリップボードコピーの制限（ソースコード関連）
- 画面キャプチャの監視

アクセス権限管理チェックリスト：
- ロールベースアクセス制御（RBAC）の適用
- リポジトリ別アクセス権限の分離
- 読み取り専用 vs 書き込み権限の区分
- プロダクションコードアクセスを必要な人員に限定
- 定期的なアクセス権限監査（四半期ごと）
- 一時アクセス権限の自動期限切れ設定

退職チェックリスト（セキュリティ関連）：
1. 全リポジトリアクセス権限の即時廃棄
2. SSHキーおよび個人アクセストークンの削除
3. VPNアカウントの無効化
4. メールおよびメッセージングアカウントの無効化
5. 会社端末の返却および初期化
6. クラウドサービスアクセス権限の除去
7. CI/CDパイプラインアクセスの遮断
8. 退職面談で機密保持義務を再確認

NDAに含めるべき核心条項：
- 保護対象情報の具体的定義
- 秘密保持義務期間（通常2-5年）
- 違反時の損害賠償条項
- 競業避止条項（該当する場合）
- 退職後も継続する義務の明示

ソースコード漏洩ポストモーテムテンプレート：

1. 事案概要
   - 発見日時、漏洩経路、影響範囲

2. タイムライン
   - 漏洩時点（推定）
   - 発見時点
   - 各対応フェーズ別の所要時間

3. 技術的分析
   - どのコードが漏洩したか
   - 含まれるシークレットのリスト
   - 脆弱性の露出有無

4. 対応評価
   - うまくいった点
   - 改善すべき点
   - 対応時間分析

5. 根本原因
   - 技術的原因
   - プロセス上の原因
   - 文化的原因

6. アクションアイテム
   - 短期（1週間以内）：シークレット交換、アクセス遮断
   - 中期（1ヶ月）：セキュリティツール導入、プロセス改善
   - 長期（四半期）：セキュリティ文化強化、教育プログラム

Phase 1 - 即時（1週間）：
  - 全シークレットのローテーション完了
  - 脆弱なアクセス経路の遮断
  - 一時的モニタリング強化

Phase 2 - 短期（1ヶ月）：
  - シークレットスキャニングツールの導入
  - pre-commitフックの全社適用
  - アクセス権限の全数調査

Phase 3 - 中期（四半期）：
  - DLPシステムの導入
  - セキュリティ教育プログラムの開始
  - 定期セキュリティ監査プロセスの確立

Phase 4 - 長期（年間）：
  - セキュリティ文化の定着
  - 自動化されたセキュリティテストパイプライン
  - レッドチーム/ブルーチーム訓練

コミュニケーション対象別メッセージ：
経営陣：ビジネスへの影響、法的リスク、対応状況
開発チーム：技術的詳細、即座にやるべきこと、変更点
法務チーム：証拠状況、法的対応オプション、タイムライン
顧客：影響有無、保護措置、後続計画（必要時）