はじめに。
データ構造を決めないと、試験アプリは必ず詰まります
試験アプリを作るとき、
一番最初に決めるべきなのは画面でもフローでもありません。
データ構造です。
ここを雑にすると、あとで必ず詰みます。
修正が効かない、分析できない、運用が回らない。
Power Platformでは特にこの影響が大きく出ます。
なぜSharePointを使うのか
結論から言うと、理由はシンプルです。
-
Power Apps / Power Automate と相性がいい
-
権限管理が簡単
-
現場が「Excel感覚」で触れる
-
列を後から追加できる
Dataverseを使う選択肢もありますが、
-
管理が重い
-
権限設計が面倒
-
「IT部門しか触れない」空気になりやすい
今回は社内試験が目的なので、
「現場が問題を追加できる」ことを優先しました。
👉
試験問題は、IT部門が一生メンテするものではありません。
これがSharePointを選んだ最大の理由です。
問題マスタの設計
リスト名
ExamQuestions
列設計（そのまま作ってOK）
| 列名 | 型 | 役割 |
|---|---|---|
| QuestionText | 複数行テキスト | 問題文 |
| Choice1 | 1行テキスト | 選択肢 |
| Choice2 | 1行テキスト | |
| Choice3 | 1行テキスト | |
| Choice4 | 1行テキスト | |
| CorrectChoice | 数値 | 正解（1〜4） |
| Category | 選択肢 | 分野 |
| Difficulty | 選択肢 | 難易度 |
| IsActive | Yes/No | 出題対象か |
列設計の考え方
① 正解を「テキスト」で持たない
よくある失敗がこれです。
-
正解：Choice3
一見わかりやすいですが、
後で分析・集計が一気に辛くなります。
そこで、
-
正解は番号（1〜4）で持つ
-
表示だけ Choice1〜4 を使う
という形にしています。
👉
正誤判定が数値比較で済む
これが後から効いてきます。
② Category は必ず持たせる
これは後から確実に効きます。
-
正答率を分野別に出す
-
弱点分析をする
-
AIに渡す
全部この列を使います。
問題を作る時点では少し面倒ですが、
後で自分を助ける典型例です。
③ IsActive は「削除代わり」
問題は削除しません。
-
古い問題
-
ミスに気づいた問題
-
使わなくなった問題
すべて IsActive = No にします。
理由は明確で、
-
過去ログとの整合が壊れない
-
復活が簡単
-
「いつ消したか」で揉めない
👉
論理削除は正義です。
回答ログの設計
次に、一番重要なリストです。
リスト名
ExamAnswers
列設計
| 列名 | 型 | 役割 |
|---|---|---|
| UserEmail | 1行テキスト | 回答者 |
| QuestionId | 数値 | 問題ID |
| SelectedChoice | 数値 | 選んだ番号 |
| IsCorrect | Yes/No | 正誤 |
| Category | 選択肢 | 問題の分野 |
| AnsweredAt | 日付時刻 | 回答時刻 |
| SessionId | 1行テキスト | 試験単位 |
なぜ QuestionId だけを持つのか
回答ログには、
-
問題文は持たない
-
選択肢も持たない
IDだけを持ちます。
理由は以下の通りです。
-
問題文を直しても過去ログが壊れない
-
データ量が増えない
-
集計・分析がしやすい
Category を二重持ちする理由
よく聞かれます。
問題マスタにあるのに、なぜ？
理由はシンプルです。
-
回答ログ単体で集計したい
-
Power BI / Excelですぐグラフを出したい
-
Joinなしで分析したい
👉
正規化より運用優先です。
SessionId が後から効いてくる
SessionId は例えば、
-
20240201_userA -
GUID
などです。
これがあると、
-
試験1回単位で集計できる
-
途中離脱を検知できる
-
再受験管理ができる
最初は使いません。
でも、後で必ず使います。
後から効いてくるフィールドまとめ
最初は「面倒」でも、
後で自分を助ける列です。
-
Category（分析）
-
Difficulty（出題制御）
-
IsActive（運用）
-
SessionId（試験管理）
-
AnsweredAt（時間制限）
👉
Power Platformは後出し設計に弱い
だから最初に仕込みます。
問題は「覚えさせない」ために大量に持つ
社内試験でよくある失敗があります。
-
問題数が少ない
-
毎回同じ問題が出る
-
答えを暗記される
こうなると、
知識ではなく記憶力を測る試験になります。
それでは意味がありません。
今回の設計では、
問題は大量に作り、毎回ランダムに抽出する前提にしました。
なぜランダム出題が必須なのか
理由は3つあります。
① 暗記対策
同じ問題が出ない以上、
理解していないと解けません。
② 試験の価値が落ちない
問題が固定だと、
-
答えが回る
-
スクショが共有される
-
「去年の問題集」ができる
一度こうなると、制度として終わります。
③ 出題範囲を広く取れる
基礎・実務・判断問題を混ぜられます。
👉
「たまたま得意な問題だけ出た」を防げます。
問題マスタは「使う前提」で大量に作る
目安は以下です。
-
出題数：20問
-
問題マスタ：100〜200問
最初から完璧である必要はありません。
-
最初は30問
-
少しずつ追加
-
ダメな問題は IsActive で外す
この運用ができます。
ランダム抽出は「制御されたランダム」
ランダム出題に必要なのはこの3つです。
-
Category（分野バランス）
-
Difficulty（難易度の偏り防止）
-
IsActive（出題制御）
👉
ランダム＝完全ランダムではありません。
抽出の考え方（イメージ）
例：
-
IsActive = true
-
Categoryごとに
-
会計：5問
-
契約：5問
-
IT基礎：5問
-
運用：5問
-
-
Difficultyは偏らないように
Power Appsでは、
-
全件取得
-
Filter + Shuffle
-
先頭から必要数だけ使う
という流れになります。
「暗記できない」こと自体が教育になる
実際に回してみると、
-
前回と違う問題が出る
-
でも分野は同じ
-
考え方が分かっていないと解けない
という状況が生まれます。
結果、
あ、ちゃんと理解してないとダメなんだ
という空気が出ます。
これは、
e-learningでは作れなかった部分です。
まとめ：試験は「問題数」で質が決まる
-
問題が少ない試験 → 暗記ゲーム
-
問題が多い試験 → 理解チェック
Power Platformの最大のメリットは、
問題をいくらでも追加できることです。
試験は一度作って終わりではありません。
-
回す
-
足す
-
外す
-
直す
このループが回る設計にしておくと、
試験は「制度」ではなく仕組みになります。
