ポンコツPdM

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

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

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

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

ログに何十行も赤い文字が出ている。Caused byが大事だとは聞いたけれど、一番下の例外名を検索した後、どのコードを直すのか分からない。 この記事は、Javaの不具合調査を初めて担当する人向けです。ゴールは例外名を覚えることではなく、失敗した値と、その値を作った処理を調べ始められることです。 原因例外を読んだら、自分たちのコードへ戻る。一番下の例外名は「何が失敗したか」の手がかりです。それだけで、悪い入力を作った場所や直し方までは決まりません。 まず、調べる一件を選ぶ 同じ時刻に複数のリクエストが動く環 ...

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

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

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

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

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