最終成果物課題：発表・評価・レビュー

← 前へ: Phase 6.1 | 目次 | 次へ: README →

概要

本課題では、これまでの研修で構築してきたWebアプリケーションを対象に、

技術的な構造の言語化
設計判断の説明
他者からのレビュー
客観的な評価

を行います。

ここでのゴールは、

「動くものを作った」状態から、「説明できる・評価できる」状態へ進むこと

です。

最終成果物

以下の3点を提出してください：

1. 発表資料（スライド）

2. 自己評価（ルーブリック）

3. レビュー結果（相互レビュー）

提出先は講師と決めた場所、または自分の演習用リポジトリです。独学で相互レビューの相手がいない場合は、下のルーブリックとレビュー観点を使って自己レビューし、代替したこと・確認の根拠・未確認の項目を記録してください。進め方はREADMEを参照してください。

コード・資料・録画を公開する前に、成果物を共有するときの注意に従い、個人情報や秘密情報が含まれていないことを確認してください。発表者名も公開版ではハンドルネームに置き換えられます。

1. 発表用テンプレ（スライド構成）

以下の構成に従ってスライドを作成してください。

Slide 1: タイトル

アプリケーション名
自分の名前

Slide 2: 作ったものの概要

どんなアプリか
何ができるか（CRUD）

Slide 3: デモ（重要）

自分のPCのループバックだけで起動し、ダミーデータで実演してください。他者に見せる場合は画面共有または録画を使い、サーバの外部公開・公開トンネル・ポート転送は行いません。

実際の操作
- 一覧
- 作成
- 更新
- 削除

Slide 4: 全体アーキテクチャ

以下を図で示してください：


HTTP → Router → Controller → Model → DB
↓
View

Slide 5: リクエストの流れ

1つのリクエストを例に説明：

どこを通るか
どこで何が起きるか

Slide 6: 各レイヤーの責務

Router
Controller
Model
View

必須

「なぜ分けるのか」を説明すること

Slide 7: ORMの設計

自作ORMの構造
BaseModelの役割
save / find / where の仕組み

Slide 8: バリデーションの設計

どこでチェックしているか
なぜModelに置いたか

Slide 9: 抽象化の判断

どこを共通化したか
なぜそこまでにしたか

Slide 10: Railsとの比較

以下を説明：

同じ点
違う点
なぜ違うのか

Slide 11: 苦労したポイント

設計で悩んだ点
実装で詰まった点

Slide 12: 学んだこと（最重要）

一番重要な理解
認識が変わったこと

Slide 13: 今後の改善

自作フレームワークの限界
追加したい機能
既知の脆弱性、未実装の防御、その影響（READMEの一覧を自分の実装と照合する）
XSS・CSRF・SQLインジェクション・パストラバーサルへの対策と、検証した範囲／残る制約

Slide 14: まとめ

この研修で得たもの
今後どう活かすか

2. 評価ルーブリック（自己評価）

以下の観点で自己評価を行ってください。

評価基準

S（優れている）

深い理解がある
設計の意図を説明できる
トレードオフを語れる
抽象化の判断が適切

A（良い）

基本的な理解がある
構造を説明できる
実装に一貫性がある

B（標準）

動作するものは作れている
一部説明が曖昧

C（要改善）

理解が浅い
説明できない
レイヤーが混ざっている

評価項目

各項目を S / A / B / C で評価してください。

1. 技術理解

HTTP / Router / Controller / Model / View の理解

2. 設計力

責務分離
抽象化の適切さ

3. 実装品質

一貫性
可読性

4. 説明能力

他者に伝えられるか

5. トレードオフ理解

なぜその設計にしたか説明できるか

安全上の必須評価

次の項目はS〜Cの評価にかかわらず必須です。満たさない場合は成果物の提出を完了とせず、修正して再確認してください。

本番利用せず、信頼できないネットワークやインターネットへ外部公開しない
実際の待受先がループバックに限定されていることを確認できる
秘密鍵を共有・コミットせず、curl -kをローカルの自己署名証明書演習だけに限定している
XSS・CSRF・SQLインジェクションの必須テスト結果を示せる。ファイル配信／一覧があればパストラバーサルも検証済みである
既知の脆弱性を説明できる。リソース制限、タイムアウト、例外時のソケットcloseなど、未実装の防御とその影響を具体的に挙げられる

テストを通しても外部公開できる安全性を保証しないことを説明してください。

自己評価コメント

以下を必ず記述：

強み
弱み
改善したい点

3. レビュー用チェックリスト

他の受講者の発表をレビューしてください。

観点1: 全体構造

レイヤーが分離されている
アーキテクチャが明確

観点2: 責務の理解

各レイヤーの役割を説明できている
責務が混ざっていない

観点3: ORM理解

Modelの役割が理解されている
DBとの関係が説明されている

観点4: 抽象化

適切に共通化されている
過剰設計ではない

観点5: 説明力

話が論理的
初見でも理解できる

観点6: トレードオフ

設計の理由が説明されている
別案との比較がある

観点7: デモ

正常に動作している
ユースケースが明確

観点8: 安全上の境界

外部公開せず、ループバックとダミーデータでデモしている
必須の防御とテスト結果を説明できている
既知の脆弱性と未実装の防御を、実装に即して説明できている
「テスト成功・HTTPS対応だけでは本番利用できない」と理解している

フィードバック記述