この春から未経験でIT業界で働くことになった新人エンジニアです！
現在受講している新入社員向けIT研修の様子を「新人エンジニア成長記」として発信中！
今回はその第5回として、Javaプログラミング研修でのテスト、2回目の開発演習について、感じたことや学んだことをお届けします。
理解度テストで浮き彫りになった「基礎力」と「実務力」の差分
今週は、Javaの基礎学習とデータベース学習に取り組み、それぞれの理解度を測るテストを受けました。
ITエンジニアを目指すうえで、基礎技術の習得は避けて通れないステップ。今回は「どこまで理解できていて、どこが曖昧だったのか」を振り返りながら、次に活かす視点でまとめます。
学習範囲の概要
- Java基礎編
- クラスとオブジェクト
- オーバーロード
- ポリモーフィズム（多態性）
- 例外処理 等
- データベース編
- SQLの基本構文（
SELECT,INSERT, など） - DAOパターン（データアクセスの分離設計） 等
- SQLの基本構文（
実際に解いてみて：結果と学び
知識問題（基礎編：正答率70%、データベース編：正答率90%）
基礎知識とデータベースに関する選択式問題では、基礎的な理解には一定の手応えを感じました。
ただし、一部仕様の理解不足による誤答が目立ちました。
誤答の原因は以下の通りです：
staticが付かないメソッドは、インスタンスを生成しないと呼び出せないという仕様の理解不足- インターフェースが他のインターフェースを継承できるという仕様の理解不足
- 複数レコードの取得時、レコードごとに新しいエンティティインスタンスを生成する必要があることの理解不足
このあたりは、単なる暗記では対応できず、実装経験と深い理解が求められると実感しました。
リーディング問題（基礎編：正答率50%、データベース編：正答率100%）
コードの動作を読み解く問題では、Java編で1問ミス、DB編は全問正解でした。
誤答の原因は以下の通りです：
staticメソッド内から非staticフィールドに直接アクセスできない仕様の見落としこのミスは、「仕様の理解不足」によるものですが、もし事前にコードを1行ずつ処理し、変数の状態変化を紙に書き出すようなトレースをしていれば、異常に気づけた可能性があると感じました。
実務では変数の状態をしっかり頭で追うことで、実務においてバグの発生要因を見抜く力＝デバッグ力の向上に直結します。特に現場では「エラーが出ないのに期待通り動かない」といったバグに遭遇するため、デバック力の高いエンジニアが信頼される一つの基準になると実感しました。
ライティング問題（基礎編：正答率100%、データベース編：正答率0％）
実際にコードを書く問題では、結果が極端に分かれました。
- Java基礎編は全問正解
- データベース編は全問不正解（2問中0問）
データベース編の失敗は、1問目に時間を使いすぎたことで、残りの問題に着手すらできなかったことが最大の要因です。
これは完全に時間配分ミス。
技術力以前に、限られたリソースの中で成果を出すことが求められる実務の場では、最も避けるべきパターンでした。
テストを通して得た気づき
今回のテストで強く感じたのは、以下の3点です：
時間配分は実務力の一部
「どの問題にどれくらいの時間を使うか」「どこまで完璧を目指すか」を瞬時に判断できる力は、開発現場でのタスクをこなす力に直結します。
仕様の高い理解が必要
エラーの原因が仕様理解の低さだったとき、表面的な知識では不十分であることを痛感。
今後は「なぜそうなるか」「どのような制約があるか」まで踏み込んで学習を進めます。
“読む力”と“書く力”のバランス強化
今回のテスト結果は、読めても書けない・書けても読めないというバランスの偏りを浮き彫りにしました。
今後は、設計→実装→レビュー→再設計のサイクルを意識しながら、設計を通して読む力、実装を通して書く力のスキルアップを図ります。
第2回開発演習｜自分たちで設計・見積もり・テストまで担った2日間
2回目の開発演習の概要
基礎編・データベース編の理解度テストが終わった直後、2回目の開発演習に入りました。今回の開発期間は2日間。1回目とは大きく異なり、以下の点でより実務に近い開発体験となりました。
- 開発範囲を自分たちで決定できる
- データベースと連携したシステムを構築
- テスト仕様書を自分たちで作成
今回も3人チームで取り組みました。開発範囲については、チーフからは納期までに完了できそうなチームは任意課題を含めて開発範囲としてくださいと言われました。私たちのチームは全員の合意のもと「任意課題も含めて実装しよう」という挑戦的な方針を選択しました。
見積もりの難しさと、テスト設計のリアル
チームのスキルレベルは全体的に高く、コーディングそのものには大きなトラブルはありませんでした。しかし、課題となったのは「見積もりの甘さ」と「テスト設計の大変さ」です。
特にテスト仕様書の作成では、以下のような課題が浮き彫りになりました：
- テストパターン（正常系・異常系など）の洗い出しが想像以上に難しい
- 期待される出力を1つずつ明文化するタスクが時間を圧迫
- 仕様が曖昧な部分を明確化する必要があり、チーム内の認識すり合わせも必要
こうしてテスト設計に時間がかかりすぎた結果、開発スケジュールが圧迫されました。任意課題まで含めた範囲を選択していたため、私たちのチームは大急ぎで開発を進めることに。
ここで浮かび上がったのが、見積もり精度の甘さです。想定より大幅に時間がかかる項目を見誤っていたことが、後半の焦りに直結しました。
「休憩せずに開発を行う」は逆効果だった
開発が押していた私たちは、休憩時間にも開発を続行するという判断を下しました。しかしこれが裏目に出ました。
一度も休まずに集中し続けたことで、かえってその後のパフォーマンスが低下。思考が鈍り、コードレビューや設計の判断にも迷いが出てしまいました。
この経験から、「休憩は効率を落とす無駄な時間ではない」と痛感。集中力を持続させるためにこそ、適切なリズムで休むことが生産性を支えると理解できました。
最後は「チームの力」で乗り切った
最終的には、メンバー全員が役割を補い合い、納品期限までにシステムを完成させることができました。うまくいかなかった部分もありましたが、以下のような実務に通じる学びを得ました：
- テスト設計や見積もりは、開発と同じくらい重要
- 設計や実装が「思ったより時間がかかる」ことは前提として計画を立てる
- 体力ではなく、仕組みと連携で乗り越えるのがプロの仕事
今回のまとめと次回予告
今回は、Javaプログラミング研修における基礎編・データベース編の振り返り、そして第2回開発演習で得た学びについてお伝えしました。
特に印象的だったのは、時間配分の重要性です。
エンジニアは、「ただコードが書ける」だけでは通用しないと気づきました。限られた時間の中でどこにどれだけ時間を使うか判断する力は、実力の一部であり、今後の仕事のパフォーマンスに直結するスキルだと実感しています。
また、見積もりの精度がプロジェクトの成功を大きく左右することも痛感しました。
見積もりは「経験と勘」だけでなく、前提条件・仕様の複雑さ・メンバー構成といった要素を加味した上でロジカルに行う必要があります。これは、実務で求められる予測力に直結しており、今後さらに磨くべきスキルだと認識しています。
次回も、実践を通じて得た気づきや成長の記録をお届けします。ぜひ、また読みに来ていただけると嬉しいです！
コメント