第4部：理解度チェック

正解：B

案件に入ったら、まず開発環境の構築方法、コーディング規約、連絡手段（Slack/Teams等）、質問の仕方などを確認します。これらが分からないまま作業を始めると、後で手戻りが発生します。

→ 案件に入ったら最初にやること で確認

正解：B

作業依頼を受けたときは、「何を（What）」「なぜ（Why）」「いつまでに（When）」を必ず確認します。目的が分かれば適切な方法を選べますし、期限が分かれば優先順位を付けられます。

→ 作業の依頼を受けたら：確認すべきこと で確認

正解：B

「小さく作って動かす」が基本です。大きく作ってから動かすと、問題が起きたときに原因の特定が難しくなります。少し実装したら動作確認、を繰り返すことで、問題を早期に発見できます。

→ 実装の進め方：小さく始める で確認

正解：B

境界値（例：0と1の境目、上限値ギリギリなど）はバグが発生しやすい箇所です。「1以上10以下」という条件なら、0, 1, 10, 11 などの境界付近を重点的にテストします。

→ テストの進め方：境界値テスト で確認

正解：B

報告された現象が本当に不具合か、それとも操作ミスや環境の問題かを確認する必要があります。また、どんな条件で再現するかを把握することで、原因調査や修正確認がスムーズになります。

→ 不具合対応の進め方：再現確認 で確認

正解：A

指摘を受けたら、まず内容を理解し、なぜその修正が必要かを確認しましょう。分からなければ質問してOKです。理由を理解して修正することで、次回から同じ指摘を受けにくくなります。

→ コードレビューの受け方：指摘への対応 で確認

正解：B

テストコードがあると、コードを変更したときに既存機能が正しく動くかを自動で確認できます。これにより「直したつもりが別の場所が壊れた」というリグレッション（デグレ）を防げます。

→ テストコードの書き方：なぜテストコードを書くのか で確認

正解：B

悪い報告ほど早くすべきです。問題を抱え込むと状況が悪化し、リカバリーの選択肢が減ります。「悪い報告は早く、良い報告は後でもいい」と覚えましょう。

→ 報連相の基本：悪い報告こそ早く で確認

正解：B

見積もりには不確実性がつきものです。「うまくいけばこれくらい」ではなく、「問題が起きる可能性も考慮した現実的な時間」で見積もりましょう。最初は多めに見積もって徐々に精度を上げていきます。

→ 作業の依頼を受けたら：見積もりの考え方 で確認

正解：A

進捗報告では「何が終わったか」「何が残っているか」「問題や懸念はあるか」を伝えます。これにより、リーダーやチームが状況を把握し、必要なサポートを判断できます。

→ 報連相の基本：進捗報告の基本 で確認