300名の本音のデータが集まるかどうかは、セキュリティ設計で決まります。守るためだけでなく、回答率と回答の質を上げるために、以下の構造で設計します。
氏名・所属は「名簿DB」、回答・タイプは「匿名IDのみの回答DB」に分けて保管。2つを突合できる鍵は本部の限られた権限だけが持ちます。
店長・エリアマネージャーには集計値しか見せず、5名未満の区分は自動で非表示。「うちの店の誰か」が特定できない構造にします。
利用目的を「配属・育成・チーム編成」に限定し、同意画面と社内規程の両方に明記。データの価値は、スタッフの信頼の上にしか成り立ちません。
回答が本部の画面に届くまで
誰が・何を見られるか。本部以外は「個人が特定できる形」では見られません
| ロール | 自分の結果 | 自店の集計 | 自店の個票 | エリア集計 | 全社集計 | 個人×実績の突合 | データ書き出し |
|---|---|---|---|---|---|---|---|
| スタッフ本人約300名 | ✓ | — | — | — | — | — | — |
| 店長約200名 | ✓ | n≥5 | — | — | — | — | — |
| エリアマネージャー数名 | ✓ | n≥5 | — | n≥5 | — | — | — |
| 本部（人事・経営）限定メンバー | ✓ | ✓ | ✓ | ✓ | ✓ | 2名承認 | 記録 |
| 開発・保守担当STORKE | — | — | — | — | 匿名 | — | — |
実装時の標準仕様
既存のGoogle Workspace／Microsoftアカウントでのシングルサインオン。パスワードを新たに持たせない。本部権限は多要素認証を必須に。
国内リージョンのデータベースに、保存時・通信時ともに暗号化。バックアップも同じ基準で暗号化し、世代管理。
「誰が・いつ・誰のデータを・何のために」見たかを全件記録。個票閲覧・突合・書き出しは本部管理者に自動通知。
退職後の個人データは一定期間（例：6ヶ月）で自動削除。統計用には匿名化した状態で残し、個人に遡れないようにする。
アプリ本体は名簿DBと回答DBに別々の権限で接続。万一どちらかが漏れても、単体では個人を特定できない。
利用目的・閲覧権限・保持期間を社内規程として文書化し、回答前の同意画面に同じ内容を表示。個人情報保護法の利用目的の特定・通知に対応。
本部管理者が確認できる記録（サンプル）
タイプと売上の「相関」は「因果」ではありません。盛り上げ役の売上が高いのは、繁華街に配属されやすいからかもしれない。だからこの仕組みは、断定するのではなくn数と範囲を必ず画面に出し、仮説を立てて検証し続ける道具として設計します。また、適性検査を採用の合否に直結させることは法的にもリスクが大きいため、用途を配属・育成・チーム編成に限定することを前提にしています。300名のデータを毎期貯めて、タイプの妥当性そのものを自社データで検証し直していく——これは御社の規模だからこそできる、他社には真似できない資産になります。