システム開発入門の第32週目は、今学期の最終回です。
第31週目に進めたポートフォリオ整理とシステム設計への準備を受け、今回は最終提出の確認、1人90秒のショートデモ、個別フィードバックに取り組みました。
完成した機能だけを評価するのではありません。コード、テスト、改善の記録、説明資料まで振り返り、今学期に身につけたことと次に伸ばす力を確かめる授業となりました。
最終回で確認した五つの評価軸
授業の冒頭で、先生は最終成果を見るための評価軸を共有しました。
「今日は『成果を見せる』と同時に『次に何を伸ばすか』を明確にする時間です。完璧である必要はありません。成長の跡を言葉にできることが大切です。」
評価項目と授業中に示された改善例を、提出前に確認しやすい形で整理すると次のようになります。
| 評価項目 | 確認する内容 |
|---|---|
| 機能実装 | 予定した機能を実行し、動作を示せるか |
| コードの読みやすさ | モジュールの分け方やコメントが内容の理解を助けているか |
| テストと改善履歴 | テスト結果と、「いつ、何を、なぜ変えたか」が記録されているか |
| ドキュメント | プロジェクト概要、実行手順、必要なファイルが説明されているか |
| チームでの貢献 | チーム開発の中で担当したことを説明できるか |
ポートフォリオを提出できる状態に整える
ポートフォリオとは、この授業で作った成果物だけでなく、実装、テスト、改善、振り返りまでをまとめた記録です。
提出物には、プロジェクト概要、実装の要点、テスト結果、改善履歴、学びの振り返りがそろっているかを一つずつ確認しました。未完成の箇所があった生徒は、先生から補足のヒントを受け、その場で修正して再提出しました。
不足しやすかった三つの説明
- 実行手順：動かし方が伝わるように、必要なコマンドやファイル名を追記する。
- テスト結果：結果を確認できるログの抜粋やスクリーンショットを添える。
- 改善履歴：「いつ、何を、なぜ変えたか」を箇条書きで残す。
改善履歴に変更内容だけを書くと、判断の理由が伝わりません。「入力ミスに気づきにくかったため、エラーメッセージを見直した」のように、課題と変更理由を組み合わせると、試行錯誤の過程を説明しやすくなります。
90秒のデモで成果の要点を伝える
続いて、各自がポートフォリオに沿って1人90秒のショートデモを行いました。
短い時間では、機能を順番に見せるだけでは要点がぼやけます。今回の改善提案を発表の流れに置き換えると、次の四段階になります。
- 解決したい課題を一文で示す。
- 代表的なサンプル入力を見せる。
- 期待する出力と実際の動作を示す。
- 工夫した点や改善した点を一つ説明する。
デモ後には、先生とクラスメイトから、それぞれ良かった点と改善提案を一つずつ受け取りました。
入力ガイドやエラーメッセージが丁寧な作品、テスト結果を数値で比較できる作品、モジュール分割やドキュメントが整理された作品は、取り組みの意図が伝わりやすくなっていました。
一方、発表の冒頭で課題を示すことや、サンプル入力から期待する出力までを先に見せることが、説明をさらに分かりやすくする改善案として挙がりました。
個別フィードバックを次学期の目標に変える
ショートデモの後は、生徒一人ひとりと5分から7分の個別面談を行いました。
面談では、感想だけで終わらせず、今学期の強みと次学期の行動を対応させました。
- 技術面：デバッグやテスト設計など、伸びた力と改善したい力を整理する。
- 表現面：ポートフォリオの見せ方、コードコメント、READMEの説明を見直す。
- 今後の学習：データベース設計、UML、チーム開発など、学びたいテーマを確認する。
READMEは、プロジェクトの概要や実行方法などを読む人に伝える説明文書です。動くプログラムと説明できるプログラムの間をつなぐため、コードと同じく見直す対象になります。
生徒からは、「デバッグで諦めずに直した経験が自信になった」「来期は設計をもっと学んで、チームで大きなものを作りたい」といった振り返りが聞かれました。
クラス全体の強みと次の課題
クラス全体では、小さな改善を継続できるようになったことと、テストやログを使って変化を確かめる姿勢が強みとして共有されました。
課題は、設計段階での要件整理と、運用時にも使えるドキュメントを残す習慣です。要件が曖昧なまま実装を始めると、途中で何を作るべきか迷いやすくなります。ドキュメントの更新が止まれば、完成後に別の人が動かし方や変更理由を追いにくくなります。
実装前に目的と必要な機能を整理し、変更のたびに説明も更新することが、次の学習段階で取り組む課題になりました。
次学期に向けた準備
最終回では、未提出者向けの締切、予習する分野、次のプロジェクトで希望するテーマも案内されました。具体的な締切日は授業内の案内を確認してください。
- UML設計：システムの構造や動きを図で整理する表記を学ぶ。
- データベース設計：扱うデータとデータ同士の関係を整理する考え方を学ぶ。
- 設計パターン：よくある設計上の課題に対する考え方を入門書で確認する。
次学期のプロジェクトについては、図書館システムの拡張、API連携の強化、生成AIの応用などの希望をアンケートで集めました。
学期の成果を次の設計学習へつなぐ
「皆さん、この学期は『作る、確かめる、改善する、伝える』を繰り返してきました。それがソフトウェア開発の本質です。来期は『どう作るか（設計）』を深めて、より大きなものに挑戦しましょう。良い準備ができていますよ。」
第32週目は、完成品を見せるだけの発表会ではなく、学びの過程を整理して次の目標を決める時間になりました。ポートフォリオ、デモ、フィードバックを通じて見つけた強みと課題を、次学期のシステム設計につなげます。
この記事に関連する株式会社greedenの取り組み
成果を次の設計と改善につなげるには、要件、実装、テスト、運用を分断しない進め方が欠かせません。株式会社greedenは、ヒアリングから要件定義、設計、実装、テスト、保守運用まで一気通貫でシステム開発を支援します。