8月の記事で、ボードゲーム研修の現場で見てきたことを書き、その設計をセキュリティ教育に持ち込むと書きました（ボードゲーム研修の現場から）。その研修のゲームを、PQC（耐量子暗号）への移行を題材につくります。この連載では、構想と要件から、学習目標、ゲームの仕組み、試作、テストプレイを経て完成するまでを、うまくいかなかったことも含めて順に書いていきます。
第1回は構想と要件です。なぜゲームにするのか、誰に向けた研修か、研修のあとに何ができるようになってほしいか、どの場面を体験させるか、どんな条件でつくるかを書きます。
なぜゲームにするのか
座学やeラーニングのように受け身で聞くだけの研修は、内容が定着しにくく、退屈に感じる受講者も多くいます。ゲームを組み込むと、受講者は講義で聞いた内容をその場で使い、実際に体験しながら理解できます。見聞きするだけでなく使うので知識が定着しやすく、楽しみながら参加できるので、講義の時間も前向きに聞けるようになります。
これは、マーケティングと財務経理のボードゲーム研修で見てきたことでもあります。受講後の振り返りで多いのは、受け身の研修と違って楽しみながらアウトプットできた、という感想です。あとでゲームの中で使う場面が控えているので、受講者は講義を聞き流さなくなります（eラーニングだけでは行動が変わらない理由）。
PQC移行は、私たちが本業のコンサルティングで支援している分野です。多くの会社にとって初めての取り組みで、手順を説明で聞くことはできても、移行の判断を実際に経験できる機会はほとんどありません。
誰に向けた研修か
受講者は、新入社員から管理職までを想定しています。いまのボードゲーム研修でも、この幅広い層に満足いただいています。人数と時間、形式は次のとおりです。
- 人数。1回あたり100名程度まで
- 時間。丸一日が基本。短いプランや、複数の日程に分けるプランも用意します
- 形式。対面が基本で、オンラインにも対応します
いまのボードゲーム研修は、講義で基礎知識を学び、ゲームで意思決定を実践し、振り返りで実務への生かし方を考える流れで進めています。今回の研修も同じ設計を使うので、この流れが土台になります。
研修のあとにできるようになってほしいこと
目標は次の3つです。
- 知識を一度きりで終わらせない。理論や知識を研修の場だけのものにせず、実際に使った手触りのある理解につなげる
- 受講者どうしの関係をつくる。ゲームを通じて、受講者どうしが良い関係でやりとりできるようにする
- 失敗のパターンを知っておく。失敗が許されるゲームの中で、できるだけ多くの失敗のパターンを経験する
1つ目は、8月の記事で書いた「一回の研修で人は変わらない」という課題に向き合うものです。研修の場で分かったつもりになって終わらせず、職場に戻ってからも使える理解にすることを目指します。
受講者どうしのやりとりは、PQC移行の実務でも欠かせません。暗号の台帳をつくるには、システムごとの担当者や委託先から情報を集める必要があり、作業の多くは部署をまたいだ調整になります（暗号スキャンの工数は段取りに消える）。
失敗のパターンを先に知っておく意味も、実務にあります。実際の移行で優先順位を誤ったり、台帳に抜けがあったりすると、気づいたときには取り戻すのに時間がかかります。ゲームの中なら、失敗しても損失は盤面の上で済みます。
一方で、同じ記事に書いたとおり、体験型の研修にはゲームの攻略で終わってしまうおそれもあります。経験した失敗が実務のどの場面に当たるのかを、振り返りの時間に結びつけることが要ります。
体験させる場面
題材はPQC移行です。知識や経験に基づいた手順を踏まずに進めると損失が出ることを、受講者に体験してもらいます。いま考えている場面の例は次の2つです。
- 移行の優先順位を誤る。社内のシステムのうち、本来は先に対応すべきシステムが後回しになり、外部から侵入されて損失が出る
- 暗号の台帳に正しい情報が集まらない。クリプト・インベントリ（暗号の台帳）をつくるときに正しい情報を集められず、そこから生まれたセキュリティ上のリスクが損失につながる
どちらも、当メディアの実務知見の記事で書いてきた場面です。実務では、移行の順番を、データを秘密にしておく年数、外部との接続の多さ、システムを更改する時期で決めます（今すぐ移行する必要はない。ただし今すぐ始める必要はある）。暗号化された通信を今のうちに集めて将来解読する攻撃（HNDL）があるので、長く秘密にしておくデータが通るシステムほど先に移します。
台帳づくりでは、ネットワーク越しに調べるスキャンツールで分かるのは証明書やTLSの設定のように通信の中で見える暗号の情報で、アプリケーションの中の暗号処理やデータベースの暗号化は、設計書の確認や担当者への聞き取りで補う必要がありました。ツールの検出結果も、どのシステムのものか分からないものや重複があり、人の手で整理しなければ台帳になりませんでした（暗号スキャンツールで分かったこと、分からなかったこと）。この確認を省くと、台帳に載らない暗号が移行の計画から漏れます。
実務では、こうした判断の結果が表れるまでに時間がかかり、誤りに気づくのが遅れがちです。ゲームでは、手順を飛ばした判断が、その場で損失として盤面に表れます。ボードゲーム研修で受講者を変えていたのも、ゲームの道具立てより、勝敗の決め方や結果を自分で確かめる工程といった構造でした。今回のゲームでも、判断と損失のつながりが見えるところが中心になります。
開発の条件
開発の条件は次のとおりです。
- 期間。2か月
- 体制。研修の設計と受注などを受け持つ2名と、研修に登壇する業務委託の講師5名
- 予算。ゲームの制作費として20万円。これとは別に、人件費と、AIやデザインツールの利用料を見込んでいます
- いまの研修から使うもの。研修の設計とゲーム開発のノウハウ
ゲームそのものはPQC移行に合わせて新しくつくり、研修の組み立て方とゲームのつくり方は、いまの研修で積み上げたものを使います。
自社で体験型の研修をつくる方へ
自社で体験型の研修をつくるときも、つくり始める前に今回の5つを書き出しておくと、途中で迷ったときの判断の基準になります。
- なぜ体験型にするのか。座学やeラーニングで足りない点は何か
- 誰に向けるのか。受講者の層、1回の人数と時間、対面かオンラインか
- 何ができるようになってほしいか。3つまでに絞る
- どの場面を体験させるか。実務で失敗すると取り戻しにくく、研修なら安全に失敗できる場面を選ぶ
- どんな条件でつくるか。期間、体制、予算。登壇を外部の講師に任せるなら、つくった人がいなくても同じように進められるよう、ルールの説明と振り返りの進め方を文書にしておく
次回は学習目標です。研修のあとにできるようになってほしい3つを、研修の中でどう確かめるかを書く予定です。
