新人エンジニアの目標設定例｜「Javaを勉強する」を仕事で確認できる成果に変える

目標シートに「Javaの理解を深める」と書いたら、上司から「具体的には？」と返された。資格名や学習時間を足したものの、実務で何が変わるのかは自分でも曖昧なまま。

この記事は、初めて業務目標やOJTの目標を作るエンジニア向けです。立派な将来像を作る前に、今できずに困っている仕事を一つ選び、その成果を誰と確かめるかを決めます。

目標は教材の消化量ではなく、仕事でできるようになることから作る。
「何のために」「何を残すか」「どう確認するか」を先に書き、そのために必要な学習を選びます。

「一冊読む」は行動。「調査結果を説明できる」が成果

本を読む、資格を取る、動画を見る。どれも学習の行動として使えます。ただ、それだけでは、担当する仕事にどう役立ったかを振り返れません。

例えば、例外の種類を暗記しても、実際のログから自分のコードの場所を探せないなら、不具合調査ではまだ止まります。「例外処理を学ぶ」の先に、どんな場面で使うかを置きます。

曖昧な目標	仕事に結びつけた目標
Javaの知識を増やす	検証環境のエラーログから該当処理を探し、確認済みの事実と仮説を説明する
テストを頑張る	担当する変更の入力条件を整理し、境界値を含む確認案をレビューへ出す
コミュニケーション力を上げる	レビュー依頼に目的・変更点・確認済み事項を添え、質問への回答を記録する

件数を増やせばよいわけではありません。「レビュー指摘ゼロ」のように、指摘を受けること自体が損になる目標も避けます。新人の段階では、指摘から何を理解し、次にどう反映したかを確認する方が使えます。

まず今の困りごとを一つ選ぶ

「設計も実装もテストも一人でできる」は範囲が広すぎます。直近で先輩に丸ごと助けてもらった場面を振り返ります。

例えば、ログにエラーが出ても、何を切り出して相談すればよいか分からなかった。その場合、今月は「原因を一人で全部直す」ではなく、「調査の入口を作れる」に絞れます。

以下は、その課題を持つ新人の目標例です。入社年次で一律に求める基準ではありません。

目的： 不具合調査で、状況説明から参加できるようになる。

成果： 指導担当と選んだ一つのエラーについて、再現条件・例外名・自分のコードの場所・次に確認することを一枚にまとめ、説明する。

確認： 指導担当がログとコードを見ながら、事実と推測が分かれているか、次の調査先を選べているかを確認する。

この成果に必要なら、例外処理の章を読む。先に本を一冊決めるより、読む目的がはっきりします。

一か月の計画には、途中で見せるものを置く

最終週だけにレビューを頼むと、題材が難しすぎたことに気付くのも月末になります。学習の途中で成果を見せます。

区切り	やること	見せるもの
最初	指導担当と対象を一つ選ぶ	題材と、今説明できない点
前半	例外名と呼び出し箇所を調べる	ログへの注釈と該当コード
中盤	検証用データで再現条件を確かめる	予想・結果・未確認事項
最後	調査の順序を説明する	一枚の調査メモと次の課題

業務で対象にできる障害が発生するかは自分で決められません。発生を待つ目標にせず、過去の事例や練習用コードでも確認できるようにします。使う資料と環境の許可は指導担当と確認します。

上司とは、難しさだけでなく時間と支援も合意する

目標の文章が良くても、指導担当に確認する時間がなければ進みません。提出前に次の三点を相談します。

• 業務の中で、どの時間を学習と検証に使うか。
• 誰が、何を、いつ確認するか。
• 題材が難しすぎる場合、どこまで範囲を小さくするか。

「毎日帰宅後に二時間」を最初から前提にするのではなく、まず業務目標として使える時間と支援を決めます。会社の評価項目が別にあるなら、今回の成果がどの項目の材料になるかも確認してください。

振り返りは「できた・できない」だけで終えない

同じ未達でも、次の打ち手は違います。

止まった理由	次に変えること
ログを見る権限がなかった	題材や利用できる資料を変える
一機能全体を追って時間が足りなかった	一つの例外と呼び出し経路に絞る
呼び出しや例外の基礎が分からなかった	必要な基礎を学び、同じ題材で再確認する
調べたが説明が伝わらなかった	事実・仮説・未確認を分けて書き直す

成果物が残っていれば、「頑張りが足りなかった」で終えずに修正できます。学習時間は補助情報として残し、主役は何が説明・実行できるようになったかにします。

まず目標の一文目を、「何を勉強するか」から「どの仕事で、何ができるようになりたいか」へ書き換えてください。そこから成果物と確認相手を決めれば、今読むべき章も選びやすくなります。