- HOME >
- ポンコツPdM
ポンコツPdM

SIerでの開発・プロジェクト運営の経験をもとに、Java・Springの実装、設計・テスト、チーム開発で役立つ手順をまとめています。
学習と現場をつなぐ
「件名の入力がおかしいです」と連絡されても、受け取った人は何を入力したのか、どの画面で、どうなるはずだったのか分かりません。調べる側が再質問している間にも、同じ問題が起き続けます。 この場面では、原因の推測より、別の人が同じ条件を試せる記録を優先します。 最初の報告に「Controllerが悪い」と書く必要はありません。事実と推測を分けてください。 この記事では架空の問い合わせ管理アプリを使い、曖昧な報告を、開発担当者が着手できる報告へ書き直します。 「保存できない」では調査を始められない まず、次の一文 ...
リリース判定の会議で「切り戻したら、変更後に登録したデータはどうなりますか」と聞かれた。アプリの実装は説明できるが、切り戻し手順は見ていない。ここで「たぶん大丈夫です」と返すと、未確認のままリリースの判断が進んでしまう。 この記事は、顧客や他チームに説明する機会が増えた開発担当者に向けたものです。即答するための言い回しではなく、答えがない状態を、相手が誤って判断しない返答へ変える方法を整理します。 「未確認です」でよい。ただし、判断できない範囲と次の連絡を添える。知識がないことを隠すより、何を確認するかを ...
自分は新しい仕組みを作りたいのに、メンバーは「今のままでよくないですか」と言う。目的を説明しても反応は薄い。リーダーだけが熱くなっているようで、腹が立つ。 初めてチームを率いる人ほど、この反応を自分のリーダーシップへの評価として受け取りがちです。ただ、全員を自分と同じ熱量にすることを目標にすると、仕事の相談が意欲の審査になります。 そろえるのは感情ではなく、仕事の合意です。成果・優先順位・守る基準・担当を決め、それが実行されているかを見ます。目的を共有した後も意見が違うなら、賛同を強要するより、仕事として ...
@Serviceを付けたクラスがあるのに、起動するとNoSuchBeanDefinitionExceptionになる。XMLにも探索の指定があるなら、まず確かめるのはそのXMLを、例外を出したApplicationContextが読んだかです。正しい設定ファイルがプロジェクトにあっても、別の入口から起動すれば、その設定でBeanが登録されるとは限りません。 この記事でわかることログから要求型と候補数を拾い、「探索先のずれ」と「XML未読込」を分ける。同じSomeServiceで候補0件・1件・2件を再現し ...
公開メソッドの中でprivateメソッドを呼び、その中で外部へ通知している。通知の失敗をテストしたくて「Mockito private モック」と検索した。 この場合、置き換えたいのはprivateという実装上の区切りではなく、外部通信です。この記事では、通知サービスを例に、privateの名前に依存せず、通信失敗時の動きを確認する形へ変えます。 新しく書くテストでは、まず通信を差し替えられる依存にする。純粋な整形処理は公開メソッドの結果から確認し、成功・失敗を作りたい外部依存を置き換えます。既存のPow ...
Javaのメソッドを分ける基準は、行数よりも「名前を付けて説明できる仕事のまとまり」です。まず同じクラスのprivateメソッドへ切り出し、取込の進行と、1行を変換する規則を分けます。別クラスにするかは、その規則を独立した担当として扱う理由があるかで判断します。 分割前・分割後のコード全文と、比較用サンプル同じ入力を3版へ渡し、保存回数と例外まで比べられます。Java 17で実行できます。ZIPにはJavaソース6件、README、検証記録、LICENSEを含みます。分割前:BeforeImporter. ...
「もっと学べば前に進める」と思っても、試す仕事や相談相手がないなら努力の量だけでは解けません。まず、足りないものを分けて考えます。 この記事の立場 学習で補える不足は学ぶ。学習だけで変わらない環境は相談し、改善しなければ他社も比較する。 たとえば「設計をやってみたい」と勉強しても、任されるのは以前と同じ作業。年数や資格の数だけでは、学習が足りないのか、試す機会がないのかは分かりません。転職活動を始める前に、知識と仕事の機会・支援を分けて確かめる。それでも現職で改善の見通しが立たなければ、外の仕事を比較する ...
環境構築を頼んだ新人から、一日連絡がなかった。終業前に聞くと、午前中から認証エラーで止まっていた。「困ったら聞いて」と伝えたはずなのに、どうして黙っていたのだろう。 この記事は、リモートで新人の受け入れやOJTを担当する人に向けたものです。本人が質問できるようになるまで待つのではなく、質問が来なくても行き詰まりを発見できる仕事の渡し方を作ります。 最初の仕事では、完了報告だけを待たない。途中で見せる成果、止まったら連絡する条件、受け手の返信時点を決めます。「分からないことはない?」より「どこまで動いたか見 ...
注文を登録したら画面に500エラーが出た。もう一度押せば通るかもしれない。でも最初の注文が登録されていたら、二重になるかもしれない。 この記事は、Spring Bootアプリで初めて500エラーの調査を担当する人向けです。例外名を探すだけでなく、同じ操作を繰り返してよいか、どこまで処理が進んだかを確認する順序を示します。 更新系の操作は、500だから失敗したとは限らない。まず対象リクエストを特定し、保存や外部送信の成否を確認します。原因の確定を待たず、分かった影響と次の連絡時点を共有してください。 500 ...
設計書ではユーザーIDが必須になっている。しかし前回のレビューでは任意と決まったはず。このまま実装すると、外部連携側と条件が合わないかもしれない。 確認メールを書こうとして、経緯を全部説明したら長文になった。この記事は、そんな仕様の食い違いを、設計担当や顧客へ確認するエンジニア向けです。 相手に答えてほしい問いを一文目に置く。その後へ、食い違っている根拠、実装への影響、判断が必要な時点を付けます。短くする対象は挨拶の重複であり、判断材料ではありません。 「確認をお願いします」だけでは、回答が決まらない 次 ...