付録A　演習サイクルとチームレビューの進め方

この付録の目的

この付録では、本研修の 1 章ごとの学習サイクル(講義 → 個人演習 → Git 提出 → チームレビュー → 発表 → 講師補足)を、共通ルールとしてまとめます。

各章のテキストには「演習課題」「Git への提出」セクションがありますが、それらをどんな時間配分で・どんな心構えで進めるか、までは書かれていません。 本付録は、章をまたいで共通する運用ルール を一箇所にまとめた 読み物兼リファレンス です。

第 0 章との役割分担

文書	内容
第 0 章	この研修で 何を学ぶか(C# / .NET / VS2022 / 全体像)
付録 A(本付録)	この研修を どう進めるか(1 章ごとのサイクル運用)
付録 B	VS2022 の 道具としての操作
付録 C	Git の 道具としての操作(本付録の A-4 から委譲)
付録 D	VS2022 のショートカットキー
付録 E	エラー時のトラブルシューティング(本付録の A-9 から委譲)

本付録は最初に通読し、その後は 詰まったときに読み返す 使い方を想定しています。

---

A-1　1 章あたりの学習サイクル

各章は、原則として次のサイクルで進みます。

[1] 講師による説明              ← 章の目的・新しい概念を共有
       ↓
[2] サンプルコード/操作の確認     ← 動かしながら手で覚える
       ↓
[3] 設計タイム(コメント・枠づくり) ← ペア/グループで設計。コメントとクラス・メソッドの枠まで
       ↓
[4] 個人演習(ソロ・タイマー計測)  ← 枠の下に実装ロジックを書く。必須課題 → 余裕があれば発展課題
       ↓
[5] Git で提出                  ← 完成・未完成にかかわらず提出
       ↓
[6] チームレビュー              ← 動作確認・コードを見る・気付きを共有
       ↓
[7] チーム発表(代表者)          ← 短く、要点を絞って
       ↓
[8] 講師による補足・答え合わせ   ← よくある間違い・別解・実務観点

時間配分の目安

章の規模によって変動しますが、おおよその配分は次の通りです。

活動	目安時間
[1] 講義	15〜30 分
[2] サンプルの確認	10〜20 分
[3] 設計タイム(コメント・枠づくり)	10〜15 分(評価対象外。章の規模で調整)
[4] 個人演習(ソロ)	章ごとの「ソロ時間」(基礎章 25〜40 分、Forms/Web 章 60〜90 分)
[5] Git 提出	5 分以内
[6] チームレビュー	10〜15 分
[7] チーム発表	1 チームあたり 3 分以内
[8] 講師補足	10〜15 分

各章の演習の時間配分(設計タイム・ソロ時間)は、章末の「演習課題」セクションに記載しています。

時間内に完成しなくても OK

演習の目的は「正解を写すこと」ではなく、「自分で考え、試し、エラーを見て、改善する」サイクルを回すことです。 時間が来たら手を止め、できたところまでを Git に提出して、レビューに進んでください。

---

A-2　設計タイム(コメント・枠づくり)

個人演習(ソロ・タイマー計測)に入る 前 に、設計タイム を設けます。 ここはペアやグループで相談しながら、これから書くコードの 設計 を行う時間です。評価対象外 で、タイマーも回りません。

なぜ設計タイムを分けるのか

本来、プログラムは「何をどう作るか」を設計してから実装するのが理想です。 しかし演習はソロの時間が限られているため、いきなり実装に入ると、

• 構造を考える時間と、コードを打つ時間が混ざってしまう
• 設計の発想にかかる時間は、初学者と経験者で大きく差が出る
• 丁寧なコメントを書く時間が、実装時間に押し出されてしまう

という問題が起きます。 そこで、設計(みんなで相談してよい)と実装(各自ひとりで書く)を分け、設計を先に済ませてからソロのタイマーに入ります。

設計タイムで「作ってよいもの」

ペア・グループで相談しながら、次まで作って構いません(ソロのコミットにそのまま残してOK)。

作ってよいもの	例
ヘッダーコメント	課題番号・プログラムの目的・氏名(第 7 章コラム参照)
処理の流れを示す 意図コメント	// ここで base を使って親コンストラクターを呼ぶ など
クラス・メソッドの 枠(シグネチャ)	public int GetPaymentAmount() の宣言と { }(中身は空)
プロジェクト・クラスファイルの用意	プロジェクト作成、Employee.cs などの空ファイル

// 設計タイムに作ってよい「枠 + 意図コメント」の例(ソロ前)
public int GetPaymentAmount()
{
    // TODO: 正社員は月給をそのまま返す
}

枠を作ってよいのは「問題文が指定している範囲」まで

第 7 章以降の課題は、多くが 仕様書スタイル(クラス名・プロパティ・メソッドのシグネチャを問題文が最初から指定)です。この場合、枠を作ること=仕様の書き写し であって設計でも解答でもないので、プロパティ・メソッドのシグネチャまで作って構いません。 一方、発展課題のように「どんなクラス・メソッドに分けるかを自分で考える」課題では、構造を決めること自体が演習 です。この場合の設計タイムは 意図コメント(処理の流れのメモ)まで とし、クラス・メソッドの枠はソロで作ってください。

課題のタイプ	設計タイムで作ってよい範囲
仕様が提示されている(多くの必須課題)	コメント + 問題文どおりのプロパティ・メソッドの枠
構造を自分で考える(多くの発展課題)	コメント(意図コメント)まで。枠はソロで

迷ったら「その枠は問題文に書いてあるか?」で判断してください。書いてあれば写すだけ(OK)、自分で決めるなら設計の一部(ソロで)です。

ソロ(タイマー計測)で書くもの

タイマーが回るソロ時間で書くのは、枠の下の「実装ロジック本体」 です。

// ソロで書く部分(コメントの下の実装)
public int GetPaymentAmount()
{
    return MonthlySalary;   // ← ここがソロで書くロジック
}

評価対象は「実装ロジック」

設計タイムのコメント・枠は ペアで作ってよく、ソロのコミットに残してかまいません。 タイマーで 測るのは、その下に各自が書く実装ロジック です。 設計は「みんなで考える」、実装は「ひとりで書く」── この役割分担が、設計力の差をならしつつ、個人の実装スキルを公平に測る ための工夫です。

完成しなくても、設計コメントは残る

タイピングが追いつかず実装が途中でも、自分で書いた枠と意図コメントが残っていれば、理解していることは伝わります。 コミットメッセージの「どこまで完成 / 詰まったポイント」と合わせて、できたところまでを提出してください。

---

A-3　個人演習の進め方

個人演習では、次の点を意識してください。

心構え	意味
自分で考えてから質問する	5〜10 分は自分で試す。それでも分からなければ素直に質問
エラーメッセージを必ず読む	多くの場合、メッセージに原因が書いてある
途中まででも保存する	F5 で実行できる状態を、こまめに残す
メモを残す	つまずいた点・解決方法を一行で書き留める(後の自分が助かる)
時間になったら手を止める	時間内に完成しなくても OK。完成度より「やりきった」より「振り返りができる」状態を優先

演習中に詰まったときの順序

1. エラーメッセージを読む
2. 章末の「よくあるつまずき」表を見る
3. 該当する付録(B / C / E)を見る
4. 隣の人と相談する
5. それでも解決しなければ、講師を呼ぶ

「自分で 5〜10 分試す → 詰まったら素早く相談」が、研修中も実務でも基本のテンポです。 1 つのエラーで 30 分溶かすより、講師に 1 分質問するほうが、結果的に学びが多くなります。

「分からない」は恥ずかしいことではありません

第 30 章でも触れたとおり、本研修では 「分からないと言える力」「相談する力」も実務スキル として扱います。 黙って詰まり続けるより、声に出して詰まりを共有してください。

---

A-4　Git 提出のタイミング

各章の演習が一段落したら、できたところまでを 必ず Git に提出します。

ルール	内容
完成・未完成を問わず提出	未完成でも提出する。「できたところまで」が研修の文化
提出前にビルドが通るか確認	エラーで Visual Studio が真っ赤な状態のままにしない(ただし、解決を試みた痕跡として残す場合は除く)
講師指定のリポジトリへ push	リポジトリの場所は講師から案内される
コミットメッセージは章ごとに分ける	例:Chapter05 繰り返し処理

基本コマンド

git status
git add .
git commit -m "Chapter05 繰り返し処理"
git push

コマンドの詳しい説明・初回設定・トラブル対処は付録 C を参照してください。 本付録では「いつ・なぜ提出するか」だけを扱い、操作の詳細は付録 C に委譲しています。

未完成のまま提出するときに添える情報

未完成のまま提出する場合、次の点をチームレビューや発表で共有できるよう、自分の頭の中で整理しておきます。

- どこまでできたか
- どこで止まったか
- どんなエラーが出たか
- 何を試して解決を図ったか
- 次に何をやればよさそうか

未完成であること自体を責める必要はありません。どこで止まったかを説明できる ことのほうがはるかに大事です。

---

A-5　チームレビューの目的と進め方

目的

チームレビューは、他の人のコードを採点する時間ではありません。 次の 5 つを目的とします。

1. 自分の理解を確認する
2. 他の人の考え方・書き方を知る
3. 良い工夫を見つけて、自分にも取り入れる
4. つまずいた点を共有して、チームで解決する
5. 発表で扱う内容を決める

進め方(1 サイクル 10〜15 分の目安)

[1] 画面を実行して動作を確認する          (各人 1〜2 分)
       ↓
[2] その章で重要なコード箇所を見る         (説明する側 + 聞く側で 2〜3 分)
       ↓
[3] 良かった点を 1 つ以上見つける          (必ず 1 つ)
       ↓
[4] 気になった点を「質問」として伝える     (改善案として)
       ↓
[5] チーム発表で扱う内容を決める           (代表者 + テーマ)

コードを すべて細かく読む必要はありません。その章で重要なポイント(章の「学んだことチェック」「ペア確認」)に絞って確認します。

レビュー観点(章に応じて選ぶ)

観点	チェックする例
課題の条件を満たしているか	必須課題の動作シナリオが通る
プログラムが実行できるか	F5 でビルド・起動できる
変数名・メソッド名が分かりやすいか	役割が名前から読み取れる
処理の流れが読みやすいか	メソッドが長くなりすぎていない
例外処理・入力チェックがあるか	該当章で扱った場合
Git に必要なファイルが出ているか	bin/obj/.vs が混入していない

毎回すべての観点を確認する必要はありません。その章のテーマに合った観点を 2〜3 個選んでください。

---

A-6　レビュー時の伝え方

レビューで一番大事なのは、コードの中身そのもの よりも 伝え方 です。 言い方を一つ変えるだけで、相手の受け止め方も、自分の学びの質も大きく変わります。

基本姿勢

守ること	理由
人ではなくコードを見る	「誰が書いたか」ではなく「何が書いてあるか」を話題にする
否定ではなく改善案として伝える	「だめ」ではなく「こうすると、さらに良くなりそう」
完成していない人を責めない	未完成でも参加する文化を守る
分からない点は質問として伝える	「なぜ?」を責めるのではなく、知りたい姿勢で
良い点を必ず 1 つ以上見つける	探そうとすれば必ず見つかる
動いた・動かないだけで終わらせない	その先(なぜ動いたか・どこで止まったか)に踏み込む

言い方の対比

❌ 避けたい言い方	⭕ 望ましい言い方
このコードはだめです。	この部分はちゃんと動いていますね。ここをこう変えると、さらに読みやすくなりそうです。
全然できていません。	ここまではできていますね。次はどこを進めようと思っていますか?
なぜこんな書き方をしたんですか。	この書き方を選んだ理由を聞いてもいいですか?
エラー出てるじゃないですか。	このエラーはどの入力で起きましたか? 一緒に追ってみましょう。

良いレビューの会話例

A: この部分は課題の条件を満たしていますね。
B: ありがとうございます。社員ID の検索を追加するときに迷いました。
A: 変数名が "keyword" で揃っていて読みやすいですね。
B: 文字列補間のところは、最初 "+" でつないでしまっていました。
A: ここはメソッドに分けると、さらに読みやすくなりそうですね。
B: なるほど、確かに同じような処理が 2 回出てきていますね。

レビューは、欠点を探すだけではありません。良い点を見つけて自分にも取り入れる、相手のつまずきを自分の学びにする 時間です。

---

A-7　チーム発表

チームレビューが終わったら、各チームの代表者(またはチーム全体)が短く発表します。

発表者の決め方

毎回同じ人だけが発表しないように、次のような方法を組み合わせます。

- 前回発表していない人を優先する
- その章で理解が深まった人が発表する
- つまずきを言語化できた人が発表する
- チーム内でローテーションする
- 講師が指名する場合もある

発表が得意な人だけに集中させず、全員が説明する機会を持つ ことが目的です。 説明は、聞く以上に学びになります。

話す内容(発表の型)

長く説明しすぎず、次の 5 点に絞ります。

1. 何を作成・改造したか    (一文)
2. うまくできた点          (一つ)
3. 工夫した点              (一つ)
4. つまずいた点            (一つ)
5. チーム内で話題になった点 (一つ)

発表例

この課題では、社員一覧を DataGridView に表示するアプリを作りました。
うまくできた点は、検索結果の件数を Label に出せたことです。
工夫した点は、SQL の WHERE 句にバインド変数を使ったことです。
つまずいた点は、Oracle 接続の接続文字列でした。
チーム内では、SQL*Plus で先に SELECT を確認してから C# に持っていくほうが
切り分けしやすい、という話になりました。

発表の時間目安

形式	時間
個人発表	1〜2 分
チーム発表(代表者)	3 分以内

長さよりも 要点が伝わるか が大切です。コードを全部読み上げる必要はありません。

時間が押している場合

すべてのチームが発表できないこともあります。その場合は代表チームのみが発表し、ほかのチームは資料(Git 上のコード)で共有とします。 発表できなくても、レビューでの会話自体に価値があります。

---

A-8　講師による補足・答え合わせ

発表後、講師が必要に応じて補足します。

補足で扱う内容

- 課題の重要ポイント
- よくある間違い
- 別解(別の書き方)
- より良い書き方・現場での書き方
- 実務での考え方や注意点
- 次章へのつながり

時間が足りない場合

研修の進度や演習の盛り上がりによっては、講師補足が短くなることがあります。 その場合は次のように対応します。

状況	対応
重要ポイントだけ伝えたい	講師が「この章のポイントだけ」を 5 分で要約
別解は時間外	別解は資料で共有(後日読む)
質問が多すぎる	個別質問は休憩時間や次回冒頭に回す

講師補足は、自分一人では気付きにくい観点を得る貴重な時間 です。 発表時間を短く保ち、補足の時間を確保しましょう。

---

A-9　困ったときの動き方

研修中、必ずどこかで詰まります。詰まった時の動き方を整理しておきます。

詰まったときのフロー

[1] エラーメッセージを読む            ← まずはこれ
       ↓ 解決しない
[2] 該当章末の「よくあるつまずき」表    ← 8 割の問題はここで解決
       ↓ 解決しない
[3] 該当する付録を見る                  ← 種類ごとに参照先が違う(下表)
       ↓ 解決しない
[4] 隣の人・チームメンバーに相談        ← 説明するだけで自分でも整理できる
       ↓ 解決しない
[5] 講師を呼ぶ                          ← 遠慮なく

種類ごとの参照先(付録の使い分け)

詰まりの種類	参照先
プロジェクトが作れない、テンプレートがない	付録 B「VS2022 のセットアップと基本操作」
ショートカット・コード整形・名前変更	付録 D「VS2022 ショートカットキー、入力効率化」
Git の操作・初期設定・push エラー	付録 C「Git のインストールと提出ルール」
赤い波線・NuGet・Oracle 接続・DataGridView 表示・MVC 表示	付録 E「トラブルシューティング」

質問するときの伝え方

質問するときは、次の情報をセットで伝えます(口頭・チャット・対面、どれでも同じ)。

1. 何をしようとしていたか
   例:第 24 章の課題 24-2 で、検索フォームに "山" を入れて検索しようとした

2. 何が起きたか(エラーメッセージは原文のまま)
   例:System.InvalidOperationException: ORA-12541 ...

3. どこまで自分で確認したか
   例:接続文字列を SQL*Plus で試した、リスナーは起動していた

4. 試したこと
   例:VS を再起動した、NuGet を復元した

5. 推測している原因(あれば)
   例:bind 変数の型が合っていないかも

「何が起きたか + 何を試したか」 がそろっていると、講師は最短で回答できます。 「動きません」だけでは、講師も動けません。

質問は恥ずかしいことではありません

第 30 章でも触れたように、本研修では「分からないと言える力」「相談する力」も評価対象です。 黙って詰まり続けるより、5 分で講師を呼ぶほうが、自分にもチームにもプラスです。 配属先でも、同じ姿勢が求められます。

---

まとめ

• 1 章のサイクルは「講義 → 設計タイム → 演習 → Git 提出 → レビュー → 発表 → 補足」
• 設計タイム(ペア/グループ・評価対象外)では、コメントとクラス・メソッドの 枠 まで作ってよい。測るのは、その下に各自が書く実装ロジック
• 個人演習は 時間内に完成しなくて OK。できたところまでを必ず Git に提出する
• Git の操作詳細は 付録 C に委譲。本付録では タイミングと心構え を扱う
• チームレビューは 採点の場ではなく、理解を深める場
• レビューでは 人ではなくコードを見る、否定ではなく改善案として伝える
• 発表は 5 つの型(何を / うまく / 工夫 / つまずき / チーム話題)で短く
• 講師補足は 自分一人では気付けない観点 を得る時間。発表を短くして時間を確保
• 詰まったら 5〜10 分で相談 が基本。詰まりの種類に応じて付録 B / C / D / E を使い分ける
• 「分からない」「相談する」も実務スキル。研修中から練習する

このサイクルを 30 章 + 到達確認(第 30 章)分 繰り返すことで、本研修の学びを最大化します。