ポンコツPdMの開発メモ

2026/11/5

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

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

実装・エラー解決

2026/11/4

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

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

仕事・チーム開発

2026/10/15

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

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

仕事・チーム開発

2026/9/30

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

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

仕事・チーム開発

2026/9/8

開発が遅れたら増員すればいい？『人月の神話』から考える判断材料

開発が遅れると、「あと一人いれば」と考えたくなります。人手が有効な場面はありますが、人数の分だけ残り日数が減るとは限りません。先に結論何が止まっているかを先に分ける。作業量の不足と、仕様・環境・判断待ちでは必要な支援が違う。渡して受け取れる仕事があるかを見る。引き継ぎ、受入条件、レビュー担当、残り期限まで確認する。増員・範囲・期限を同じ前提で比べる。増員は必ず遅れを悪化させるものでも、解消するものでもない。『人月の神話』を入口に、小さなチームの架空ケースで考えます。出版社・書誌の紹介情報に基づく ...

設計・テスト・レビュー

2026/11/4

改修のテストはどこまでやる？単体・結合・手動の範囲を決める例

「単体テストは通った。でも、画面やDBまで全部試すべき？」改修のたびに、どこまで確認すればよいか迷うことがあります。先に結論見つけたい失敗から、確認する範囲を選ぶ。変更した行数やケース数だけで決めない。実物とモックを明記する。「単体・結合」は確認する範囲、「手動」は実施方法として分ける。未確認のリスクも残す。省く確認は、判断する人と補う方法をセットで相談する。この記事では、架空の問い合わせ管理を使い、入力・権限・検索の3つの改修からテスト範囲を考えます。確認を省くときの伝え方も、記入例で示します ...

設計・テスト・レビュー

2026/11/5

AIが書いたコードをそのまま使っていい？提出前の確認チェックリスト

AIのコードで画面が動き、テストも通った。それでも、このまま仕事の成果物として提出してよいのか迷うことがあります。先に結論利用許可と、渡す情報を確認する。アカウント・用途・操作の範囲は、契約や設定と合わせる。仕様は、許可・拒否・失敗の場面で照合する。正常に動いたことだけで判断しない。確認済みと未確認を分けて採用を判断する。未確認がある相談用の成果は、その状態を明記する。架空の問い合わせ管理を使い、提出前の判断材料を整理します。特定製品の性能や契約条件を比べる記事ではありません。所属先の規程と、採 ...

実装・エラー解決

2026/11/4

JavaのOptional.of(null)でNullPointerExceptionになる原因｜ofNullableとの違い

AIによる要約Optional.ofはnullではない値だけを受け取り、nullを渡すと生成時点でNullPointerExceptionになります。後ろにorElseを書いていても到達しません。nullを「値なし」として扱う仕様ならOptional.ofNullableを使うと、nullはOptional.emptyへ変換されます。ただし、必須値の欠落までofNullableで隠すのは危険です。ofとofNullableはNPEを避けるために機械的に選ぶのではなく、その値にnullを許可する契約かどうか ...

仕事・チーム開発

2026/9/8

開発が納期に間に合わないときの報告｜残作業と相談を伝える例文

約束した日に終わらないかもしれない。でも原因も完成日も、まだはっきりしない。そんな段階でも、いまの状態と必要な相談は先に共有できます。先に結論完了・残作業・期限への影響を伝える。完全な原因分析や回復時刻が出るまで待たない。現状と、決めてほしいことを分ける。期限・範囲・支援のどこを調整したいか示す。次に状況を返す時点を決める。完成の約束とは区別し、未確認でも続報する。題材は、問い合わせ管理へ必須・1〜100文字の件名を追加する架空の改修です。以下の期限や時刻も説明用で、実際の予定や成果の報告ではあ ...

実装・エラー解決

2026/10/15

Javaの「non-static method cannot be referenced from a static context」原因と直し方

AIによる要約non-static method cannot be referenced from a static contextは、staticメソッドなど現在のインスタンスが存在しない場所から、どのオブジェクトに対する処理かを指定せずにインスタンスメソッドを呼んだときのコンパイルエラーです。mainはstaticなので、非staticメソッドを呼ぶには対象オブジェクトを生成して変数経由で呼びます。メソッドがインスタンス状態やDIされた依存を一切使わない純粋な共通処理ならstatic化も候補ですが、 ...

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