ポンコツPdM

自分は新しい仕組みを作りたいのに、メンバーは「今のままでよくないですか」と言う。目的を説明しても反応は薄い。リーダーだけが熱くなっているようで、腹が立つ。 初めてチームを率いる人ほど、この反応を自分のリーダーシップへの評価として受け取りがちです。ただ、全員を自分と同じ熱量にすることを目標にすると、仕事の相談が意欲の審査になります。 そろえるのは感情ではなく、仕事の合意です。成果・優先順位・守る基準・担当を決め、それが実行されているかを見ます。目的を共有した後も意見が違うなら、賛同を強要するより、仕事として ...

必要なクラスに@Serviceを付けたのに、Springが「Beanが見つからない」と言う。設定ファイルもプロジェクトにある。何が足りないのか分からず、アノテーションを追加して回っていないでしょうか。 この記事は、特にXML設定とアノテーションが混ざるアプリを保守する人向けです。定義があることと、今使っているコンテナへ登録されていることは別として確認します。 要求された型 → 登録方法 → 設定を読み込む入口、の順にたどる。候補0件なら登録と読み込みを調べます。複数件から選べないなら、登録を増やすのではな ...

公開メソッドの中でprivateメソッドを呼び、その中で外部へ通知している。通知の失敗をテストしたくて「Mockito private モック」と検索した。 この場合、置き換えたいのはprivateという実装上の区切りではなく、外部通信です。この記事では、通知サービスを例に、privateの名前に依存せず、通信失敗時の動きを確認する形へ変えます。 新しく書くテストでは、まず通信を差し替えられる依存にする。純粋な整形処理は公開メソッドの結果から確認し、成功・失敗を作りたい外部依存を置き換えます。既存のPow ...

レビューで「このメソッド、長いので分けて」と言われた。とりあえず30行ずつ切ったら、途中の変数を大量に引数へ渡すことになり、前より追いづらくなった。 この記事は、長い処理を任され、分割する境目に迷っているJava開発者向けです。行数のルールを増やすのではなく、入力・出力・失敗が説明できる仕事のまとまりを見つけます。 行数は見直すきっかけ。切る場所は処理の意味で決める。分割後の呼び出し元を読んで、何をしているか分かること。途中の状態を追うために、あちこち往復しなくて済むことを確認します。 CSV取込には、別 ...

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

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

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

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

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

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