確認テスト実施
概要
- 日程: Day 4 / セッション 6
- 時間: [15:00-15:30]
- 形式: 演習（確認テスト）
- ゴール: 4日間の学習内容を網羅した確認テスト20問に制限時間内で解答し、AIによる採点結果から自分の不正解項目リストを作成できる（目標: 8割以上正解）
- 学習形式: 確認テスト
導入（3分）
4日間の総仕上げ、確認テストの時間です。
ここで少し考えてみてください。テストの目的は何でしょうか？ 合否判定？ 順位づけ？ どちらも違います。このテストの目的はただ一つ、「自分の理解の穴を特定すること」です。
だから、間違えることは失敗ではありません。むしろ間違いこそ収穫です。不正解の項目が、次のセッション（復習）で読むべき場所を教えてくれます。安心して、正直に、自力で解いてください。
本編（5分）
1. なぜ最後にテストをするのか テスト効果
読み直すよりも、思い出そうとするほうが記憶は強くなります。これを「テスト効果（検索練習）」と呼びます。
- 教材を読む: 情報が「入る」練習
- テストを解く: 情報を「取り出す」練習
- 記憶が本当に必要になるのは取り出すとき。だから取り出す練習が効く
つまりこのテストは評価装置であると同時に、4日間で最も効率の良い学習活動でもあります。解答用紙に向かう30分が、教材をもう一周読むより記憶に残ります。
ここがポイント
- わからない問題も空欄にせず、思い出そうと粘ってから答える。この「思い出す努力」自体に学習効果がある
- 教材やAIを見ながら解かない。穴の特定ができなくなり、次セッションの復習が空振りする
コラム
「忘却曲線」で有名なヘルマン・エビングハウスは、19世紀に自分自身を被験者にして、無意味な音節（「WID」「ZOF」のような）を数千個も暗記しては忘れる実験を繰り返しました。結果は有名なとおり、記憶は1日で急減します。しかし後の研究で、思い出すテストを挟むと忘却曲線が緩やかになることがわかりました。2006年のローディガーとカーピックの実験では、再読を繰り返したグループより、テストを受けたグループのほうが1週間後の成績が大幅に上でした。今この瞬間、あなたの忘却曲線は上向きに矯正されています。
2. テストの受け方とAI採点の手順
受け方のルールです。
- 制限時間は20分。選択式は即断、記述式は1〜2文で言い切る
- 教材・検索・AIは使わない（自分の頭だけ）
- 解答はテキストファイルまたはチャット下書きに「問1: …」の形式で書き溜める
20分経ったら、次の手順でAIに採点させます。
- 手順1: このファイルの「解答と解説」セクション全体と、自分の解答をAIに貼り付ける
- 手順2: 採点プロンプトを送る（下のプロンプト例を使う）
- 手順3: 採点結果から「不正解項目リスト」（問番号・テーマ・自分の誤答の要約）を作る
採点プロンプト例:
あなたは採点者です。以下の「模範解答と解説」を基準に、私の解答を採点してください。
- 選択式: 完全一致で正誤判定
- 記述式: 模範解答のキーワードと趣旨が含まれていれば正解。部分点は0.5点
- 出力形式: 問番号ごとに「正解/部分点/不正解」と一言の理由。最後に合計点（20点満点）と
不正解・部分点の問番号の一覧表を出してください。
【模範解答と解説】
（このファイルの該当セクションを貼る）
【私の解答】
（自分の解答を貼る）
ここがポイント
- 8割（16点）が目標ライン。ただし点数より「どの問を落としたか」が次セッションの主役
- 部分点の判定に納得できなければ、AIに「なぜ部分点なのか、模範解答との差分を示して」と食い下がる。それ自体が復習になる
コラム
機械採点の歴史は意外と古く、1930年代の米国で鉛筆のマークシートを電気抵抗で読み取る採点機（IBM 805）が登場しました。教師の負担を減らした一方で「マークシートで測れる力しか育たない」という批判も生まれ、以来90年、選択式と記述式のバランス論争は続いています。今日のあなたは、AIの登場で「記述式を即時採点できる時代」の最初の世代です。
💬 AIに聞いてみよう（採点後に）
- 「採点結果の不正解項目を、テーマ別にグルーピングして。私の弱点領域はどこ？」
- 「問◯を間違えた。模範解答は読んだが、なぜ自分の答えでは不十分なのかを対話で納得させて」
- 「不正解項目リストから、15〜30分で復習する優先順位を提案して。理由もつけて」
実習・演習
課題 確認テスト（20問・20分・20点満点）
第1部 選択式（各1点）
問1. 情報アーキテクチャ（IA）の説明として最も適切なものはどれか。
- (a) サーバやネットワークなどの物理構成を設計する技術
- (b) 情報をわかりやすく伝え、受け手が情報を探しやすくするための表現技術
- (c) プログラムの実行速度を最適化する技術
- (d) 画面のビジュアルデザインを美しくする技術
問2. データと情報の関係の説明として最も適切なものはどれか。
- (a) データと情報は同義である
- (b) 情報を暗号化したものがデータである
- (c) データに「価値」を与えたものが情報である
- (d) データベースに保存したものだけを情報と呼ぶ
問3. 「こうもり問題」が示す情報の特性はどれか。
- (a) 情報の永続性 (b) 情報の多義性 (c) 情報の機密性 (d) 情報の冗長性
問4. LATCH法の5つの軸の組み合わせとして正しいものはどれか。
- (a) Location / Alphabet / Time / Category / Hierarchy
- (b) Location / Attribute / Table / Category / History
- (c) Layer / Alphabet / Time / Class / Hierarchy
- (d) Location / Alphabet / Tag / Category / Hierarchy
問5. クローズドカードソーティングの説明として正しいものはどれか。
- (a) 参加者が自由にカテゴリを作りながらカードを分類する
- (b) あらかじめ用意されたカテゴリにカードを分類する
- (c) カードを使わずに頭の中だけで分類する
- (d) 分類結果を非公開にする
問6. 情報モデルの状態遷移を定義する主目的として最も適切なものはどれか。
- (a) データベースの物理容量を見積もるため
- (b) 必要な機能とプレゼンテーションを抽出するため
- (c) プログラミング言語を選定するため
- (d) 画面の配色を決定するため
問7. CRUDと典型的なHTTPメソッドの対応として正しいものはどれか。
- (a) Create=GET / Read=POST / Update=PUT / Delete=DELETE
- (b) Create=POST / Read=GET / Update=PUT / Delete=DELETE
- (c) Create=PUT / Read=GET / Update=POST / Delete=DELETE
- (d) Create=POST / Read=GET / Update=DELETE / Delete=PUT
問8. 非機能要件に該当するものはどれか。
- (a) 支出を登録できること
- (b) カテゴリ別に集計できること
- (c) 一覧画面が3秒以内に表示されること
- (d) 月別の予算を設定できること
問9. データ中心アプローチ（DOA）の着眼点として最も適切なものはどれか。
- (a) 業務の処理手順を中心に設計する
- (b) データの構造と流れを中心に設計する
- (c) 画面のデザインを中心に設計する
- (d) ネットワーク構成を中心に設計する
問10. リソース指向アーキテクチャ（ROA）と最も関係の深い技術の組はどれか。
- (a) SOAP と WSDL (b) REST と URI (c) CORBA と IDL (d) RPC と XML
問11. MVCにおける Controller の役割として最も適切なものはどれか。
- (a) データと業務ロジックを保持する
- (b) 画面の描画を行う
- (c) 入力を受け取り、ModelとViewの橋渡しをする
- (d) データベースへの永続化を行う
問12. ACID特性の「A（Atomicity、原子性）」の説明として正しいものはどれか。
- (a) 処理が全て実行されるか、全く実行されないかのどちらかになる
- (b) 処理の前後でデータの整合性が保たれる
- (c) 同時実行される処理が互いに干渉しない
- (d) 完了した処理の結果が失われない
問13. RESTful API の設計として最も適切なものはどれか（支出一覧の取得）。
- (a) POST /getExpensesList
- (b) GET /expenses
- (c) GET /api?action=list&target=expense
- (d) READ /expenses
問14. アジャイル開発の特徴として最も適切なものはどれか。
- (a) 全工程を一度だけ順番に実施し、後戻りしない
- (b) 短い反復で動くソフトウェアを届け、変化に対応する
- (c) 要件定義に全期間の半分以上を割く
- (d) テストを開発の最後にまとめて一度だけ行う
第2部 記述式（各1点・1〜2文で言い切る）
問15. 情報アーキテクチャとUXの関係を、「The Elements of User Experience」の考え方に触れながら1〜2文で説明せよ。
問16. あなたの開発テーマを例に、「見える情報」と「見えない情報（暗黙知）」を1つずつ挙げよ。
問17. 情報の整理・分類においてペルソナを定義する理由を、「価値」または「重み付け」という言葉を使って1文で説明せよ。
問18. 情報モデルが「要件と実装の橋渡し役」と呼ばれる理由を1〜2文で説明せよ。
問19. RDBの正規化と情報モデル（情報アーキテクチャ）の違いを、「誰のための設計か」の観点で1〜2文で説明せよ。
問20. 「プレゼンテーションと機能の分離」を、今日実装した構成（UI・API・JSON）の具体名を挙げて1〜2文で説明せよ。
成果物
- 解答一式（問1〜20）
- AI採点結果（合計点）
- 不正解項目リスト（問番号・テーマ・誤答の要約）→ 次セッションで使用
ヒント
- 選択式14問を10分、記述式6問を10分の配分が目安
- 記述式は「キーワード＋一言の理由」で十分。長文は不要
- 見直しの時間は取らなくてよい。第一想起の答えのほうが穴の特定に役立つ
解答と解説（テスト終了後に開くこと）
選択式
| 問 | 正解 | 解説 |
|---|---|---|
| 1 | (b) | IAは「わかりやすく伝える」「探しやすくする」表現技術。物理構成(a)や速度(c)、装飾(d)は対象外（Day1 Session1） |
| 2 | (c) | データに価値を与えたものが情報。価値は「誰にとってか」で決まる（Day1 Session3） |
| 3 | (b) | こうもりは獣とも鳥とも分類できる。分類が視点で変わる＝多義性（Day1 Session5・6） |
| 4 | (a) | Location・Alphabet・Time・Category・Hierarchy の5軸（Day1 Session7） |
| 5 | (b) | クローズドは既定カテゴリへ分類。自由にカテゴリを作るのがオープン（Day1 Session7） |
| 6 | (b) | 状態遷移を書くと必要な機能（CRUD由来）と画面が抽出できる。要件と実装の連動点（Day2 Session3） |
| 7 | (b) | Create=POST、Read=GET、Update=PUT(/PATCH)、Delete=DELETE（Day2 Session3、Day3 Session8） |
| 8 | (c) | 性能（応答時間）は非機能要件。(a)(b)(d)は「何ができるか」＝機能要件（Day2 Session5・6） |
| 9 | (b) | DOAはデータ構造を中心に据える。処理手順中心はPOA（Day3 Session1） |
| 10 | (b) | ROAはリソースをURIで識別しHTTPメソッドで操作する。RESTの設計思想（Day3 Session1・7） |
| 11 | (c) | Controllerは入力を受けModelを操作しViewへ渡す交通整理役（Day3 Session3） |
| 12 | (a) | 原子性=全か無か。(b)一貫性、(c)独立性、(d)永続性（Day3 Session5） |
| 13 | (b) | リソースを名詞のURIで表し、操作はHTTPメソッドで表す。動詞入りURI(a)(c)や独自メソッド(d)はRESTらしくない（Day3 Session8） |
| 14 | (b) | 短い反復・動くソフトウェア・変化への対応がアジャイルの核。(a)はウォーターフォール（Day2 Session5、Day3 Session9） |
記述式（模範解答とキーワード）
問15. 模範解答: IAはUXを構成する1要素であり、The Elements of User Experience では戦略・要件などの「目に見えない層」と、画面などの「目に見える層」を繋ぐ中間の層に位置づけられる。
判定キーワード: UXの1要素／見えない情報と見える情報を繋ぐ（Day1 Session1）
問16. 模範解答（家計簿の例）: 見える情報は「支出の金額やレシート」、見えない情報は「『コンビニで買うと使いすぎる』という本人の経験則」。
判定基準: 形式知的な例と暗黙知的な例が1つずつ挙がっていること（Day1 Session3・5）
問17. 模範解答: 情報の価値や重要度の重み付けは「誰にとってか」で変わるため、判断の基準点としてペルソナを定義する。
判定キーワード: 価値／重み付けが人（視点）によって変わる（Day1 Session6）
問18. 模範解答: 情報モデルはペルソナが価値を見出す情報（要件側）を、属性・関係・制約としてコンピュータで処理可能な形（実装側）に構造化したものだから。
判定キーワード: ペルソナ（要件）とコンピュータ（実装）の両方に触れている（Day2 Session1）
問19. 模範解答: 情報モデルはペルソナ（人間）が価値を見出す形の設計であり、正規化はコンピュータ（システム）が矛盾なく管理しやすい形の設計である。同じ情報でも設計の主が異なる。
判定キーワード: ペルソナ／人間のため vs コンピュータ／システムのため（Day3 Session5・6）
問20. 模範解答: UI（index.html と app.js）は画面表示だけを担い、機能はモックAPI（JSON Server）が担う。両者は HTTP と JSON という契約だけで通信するため、片方だけを差し替えられる。
判定キーワード: UIとAPIの役割分担／HTTP・JSONで通信／片方を交換可能（Day4 Session1〜3）
まとめ（2分）
今回学んだことを一言でまとめると「テストは評価ではなく、理解の穴を照らすライトである」です。
- 20問で4日間の全範囲（IA・整理分類・モデル・設計・永続化・REST・開発手法・実装）を横断した
- AI採点で不正解項目リストができた
- 間違いは失敗ではなく、次の30分で埋めるべき場所の地図
次のセッションで、その地図を使って穴を埋めます。全問正解だった人も、記述式の答えをさらに磨く時間にします。
🔄 振り返りチェック
- 自分の不正解項目リストは手元にありますか（問番号とテーマ）？
- 最も自信がなかった領域（Day何のどのテーマか）を言えますか？
- 8割の目標に対して、自分の結果と差分を言えますか？
補足資料
- 参考リンク: 各問の解説末尾に記載した該当セッション教材（Day1〜Day4）
- 発展課題: 自分の開発テーマを題材に、オリジナルの確認問題を3問作ってAIに解かせ、模範解答を自分で採点してみる（作問は最強の理解度チェック）
学習ガイド
想定される質問と回答例
| 質問 | ヒント |
|---|---|
| 時間内に終わらない | 選択式を先に全部埋め、記述式は「キーワード＋一言」で書く。空欄より部分点狙い |
| AIの採点が厳しすぎる／甘すぎる気がする | 採点基準（キーワード一致・部分点0.5）をプロンプトで明示し、疑問があれば根拠を質問する。採点の対話も復習になる |
| 8割に届かなかった | 想定内。次セッションはそのための時間。不正解項目リストが正確であることのほうが重要 |
つまずきやすいポイント
| つまずきポイント | ヒント |
|---|---|
| 記述式で何をどこまで書けばよいか迷い、時間を浪費する | 「キーワード＋理由一言」の1〜2文で言い切る。模範解答も2文以内。完璧な文章は求められていない |
| 教材やAIをつい参照してしまい、穴の特定がぼやける | テスト中は自分の頭だけ。「間違えるほど次の30分が有効になる」と割り切る |
| 採点だけで満足し、不正解項目リストを作らずに終える | 採点プロンプトに「不正解・部分点の問番号一覧表を出す」まで含める。リストが次セッションの入場券 |
| 用語の取り違え（DOAとPOA、ACIDの4要素、MVCの役割分担） | 「どこを中心に据えるか」「全か無か」など、各用語を一言の軸に圧縮して覚え直す。混同した組は復習リストで隣に並べる |