ポンコツPdMの開発メモ – 学習と現場をつなぐ

2026/10/15

エンジニア転職はいつ考える？学習で解ける壁と職場環境の壁を切り分ける

「もっと学べば前に進める」と思っても、試す仕事や相談相手がないなら努力の量だけでは解けません。まず、足りないものを分けて考えます。この記事の立場学習で補える不足は学ぶ。学習だけで変わらない環境は相談し、改善しなければ他社も比較する。たとえば「設計をやってみたい」と勉強しても、任されるのは以前と同じ作業。年数や資格の数だけでは、学習が足りないのか、試す機会がないのかは分かりません。転職活動を始める前に、知識と仕事の機会・支援を分けて確かめる。それでも現職で改善の見通しが立たなければ、外の仕事を比較する ...

仕事・チーム開発

2026/9/18

リモートで新人から質問が来ない｜「いつでも聞いて」より途中の成果を見る

環境構築を頼んだ新人から、一日連絡がなかった。終業前に聞くと、午前中から認証エラーで止まっていた。「困ったら聞いて」と伝えたはずなのに、どうして黙っていたのだろう。この記事は、リモートで新人の受け入れやOJTを担当する人に向けたものです。本人が質問できるようになるまで待つのではなく、質問が来なくても行き詰まりを発見できる仕事の渡し方を作ります。最初の仕事では、完了報告だけを待たない。途中で見せる成果、止まったら連絡する条件、受け手の返信時点を決めます。「分からないことはない？」より「どこまで動いたか見 ...

実装・エラー解決

2026/10/15

Spring Bootで500エラーが出たら｜再実行する前にログと更新結果を確認する

注文を登録したら画面に500エラーが出た。もう一度押せば通るかもしれない。でも最初の注文が登録されていたら、二重になるかもしれない。この記事は、Spring Bootアプリで初めて500エラーの調査を担当する人向けです。例外名を探すだけでなく、同じ操作を繰り返してよいか、どこまで処理が進んだかを確認する順序を示します。更新系の操作は、500だから失敗したとは限らない。まず対象リクエストを特定し、保存や外部送信の成否を確認します。原因の確定を待たず、分かった影響と次の連絡時点を共有してください。 500 ...

仕事・チーム開発

2026/9/18

仕様確認メールの書き方｜食い違う資料から、相手が答えられる一通を作る

設計書ではユーザーIDが必須になっている。しかし前回のレビューでは任意と決まったはず。このまま実装すると、外部連携側と条件が合わないかもしれない。確認メールを書こうとして、経緯を全部説明したら長文になった。この記事は、そんな仕様の食い違いを、設計担当や顧客へ確認するエンジニア向けです。相手に答えてほしい問いを一文目に置く。その後へ、食い違っている根拠、実装への影響、判断が必要な時点を付けます。短くする対象は挨拶の重複であり、判断材料ではありません。「確認をお願いします」だけでは、回答が決まらない次 ...

学習・成長

2026/9/27

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

目標シートに「Javaの理解を深める」と書いたら、上司から「具体的には？」と返された。資格名や学習時間を足したものの、実務で何が変わるのかは自分でも曖昧なまま。この記事は、初めて業務目標やOJTの目標を作るエンジニア向けです。立派な将来像を作る前に、今できずに困っている仕事を一つ選び、その成果を誰と確かめるかを決めます。目標は教材の消化量ではなく、仕事でできるようになることから作る。「何のために」「何を残すか」「どう確認するか」を先に書き、そのために必要な学習を選びます。「一冊読む」は行動。「調査結 ...

学習・成長

2026/9/18

コピペしたコードが説明できない｜「動いた」の次に確認する三つの前提

別のバッチを参考に処理を書いたら動いた。でもレビューで「失敗したら、どこから再実行される？」と聞かれて答えられない。コピー元にも同じ処理があるから大丈夫だと思っていた。この記事は、既存コードを参考に改修できるようになったものの、採用理由や失敗時の動きを説明できない人向けです。コピー自体を禁止する話ではありません。コピー元で成立していた前提が、今回も成立するかを確かめます。全部を読む前に、結果が変わる条件を一つ選ぶ。入力・失敗・再実行の三つを問い、動く理由を予想してから試します。説明できない条件は、調べ ...

実装・エラー解決

2026/10/15

Javaのスタックトレースの読み方｜Caused byの後、どのコードを開けばいい？

ログに何十行も赤い文字が出ている。Caused byが大事だとは聞いたけれど、一番下の例外名を検索した後、どのコードを直すのか分からない。この記事は、Javaの不具合調査を初めて担当する人向けです。ゴールは例外名を覚えることではなく、失敗した値と、その値を作った処理を調べ始められることです。注文CSVの例に加え、Springで実際に発生させた400エラーを比べます。自作コードの行が出ない場合にどこへ戻るか、行が出た場合に何を直して再確認するかまで追います。原因例外を読んだら、自分たちのコードへ戻る。 ...

実装・エラー解決

2026/9/18

git add後の変更はコミットされる？消したデバッグログが残る理由と確認方法

レビューへ出したコードに、削除したはずのデバッグログが残っていた。エディタでは消えているし、手元のテストも通っている。なぜ古い内容がコミットされたのか。 git addの後に編集した内容は、自動ではステージへ反映されません。この記事では、通常のgit commitを使う場合に、何が記録されるかを二つの差分で確かめます。commit -aやファイルを直接指定するコミットは、今回の例には混ぜません。 addは「このファイルを予約する」ではなく、「今の内容を次のコミット用に置く」操作。add後の修正も入れるなら ...

仕事・チーム開発

2026/10/15

仕事を引き受けすぎたときの相談方法｜「全部急ぎ」に優先順位をつけてもらう

明日リリースする機能のテストが残っている。そこへ別の上司から「この調査も明日まで」と頼まれ、反射的に引き受けてしまった。今さら断りづらい。でも、両方を終える見通しはない。この記事は、複数の依頼を抱え、期限を自分では変更できない開発担当者に向けたものです。必要なのは、もっと速く働く方法より先に、同時に守れない約束を、決める権限のある人へ戻すことです。結論：仕事量ではなく、衝突している二つの約束を見せる。「Aを先にするならBはいつになるか」を示し、優先順位・期限・担当のどれを変えるか決めてもらいます。着手 ...

仕事・チーム開発

2026/9/30

「自分でやった方が早い」を抜け出す仕事の任せ方｜手順だけ渡しても仕事は減らない

支援メンバーが来た。手順も説明した。それなのに質問が来るたびに自分が調べ直し、最後は「ここからは自分でやる」と引き取っている。これでは、人数が増えても自分の仕事は減りません。この記事は、実務を抱えながら後継者を育てているリーダーに向けたものです。対象は、週次報告や問い合わせ対応のように繰り返し発生する仕事。「人に任せるのは大切」という話ではなく、次の一件をどう渡すかまで決めます。先に結論手順書を渡すだけで終わらず、実際の仕事で「何を見て、なぜそう判断したか」を見せる。その後、途中で確認できる範囲から本 ...

« Prev 1 2 3 4 5 6 … 19 Next »