ポンコツPdM

「新しい版を配置する」「画面を確認する」「問題があれば戻す」。この三行だけでは、夜間に別の担当者が同じ作業を安全に実行できません。何を見て成功と判断し、どこで中止し、戻した後に何を確かめるかが抜けているからです。 この場面では、操作の列挙より、続行・中止・切り戻しを判断できる情報を優先します。 コマンドの羅列より先に、判断する人と観測する結果を決めます。 ここでは架空の問い合わせ管理アプリで、件名の文字数チェックを修正する小規模なWeb改修を例にします。対象はKubernetes上の inquiry-we ...

一つのテストを選んで実行すると成功するのに、クラスやプロジェクトのテストをまとめて動かすと失敗する。このとき最初に疑うのは、JUnitの気まぐれではなく、先に実行されたテストが後続へ何かを残していることです。 私なら、テストの順番を固定する前に、失敗したテストが読んだ共有状態を調べます。題材は架空の受付番号発行機能。staticのオブジェクトを共有して起こる失敗を再現し、各テストが自分で初期状態を作る形へ直します。その後、DBとファイルで同じ問題をどう見つけるかまで扱います。 まず単独と全件の差を再現する ...

「昨日まで通った期限判定テストが、今日になったら落ちた」。期限を固定して期待結果だけ書き、判定の中でLocalDate.now()を呼んでいると起こる失敗です。テストのたびに予定日を書き換える運用では、期限当日と翌日の境界を保証できません。 ここで取る方針は、現在日時を業務ロジックの入力として扱い、Clockを渡すことです。題材は「締切日当日まで申請でき、翌日からできない」という架空の申請機能。画面表示やDB保存ではなく、期限判定を毎日同じ条件で確かめます。 現在日時をコード内に埋め込むと、テストから動か ...

APIで空の件名を送ると400になる。ところが画面側では、どの欄を直せばよいか分からない。ステータスコードだけ合っていても、入力画面を作る側には足りません。 私なら、エラー応答を利用者が修正できる項目名とメッセージだけに絞った契約にします。スタックトレース、例外クラス名、送信された秘密値を返す必要はありません。ここでは Java 21、Spring Boot 3.5系、Spring MVC の @Valid @RequestBody を例にします。 応答形式を先に決める APIのエラー応答に必要な要素。A ...

「小さな修正だから、ついでに入れて」。これが一日に何件も届くと、何が合意済みで、何が今回のリリースに入るのか分からなくなります。 この場面では、変更を止めるより、まず『追加・不具合・未決』を分けることを優先します。 分けずに作業へ載せると、バグを後回しにしたり、新しい要望を無償の修正として扱ったりします。変更自体は歓迎しても、影響と決定者は記録します。 以下は架空の問い合わせ管理アプリです。件名は1〜100文字、受付済みの問い合わせの件名は投稿者が変更できない、という仕様をいったん合意した前提にします。 ...

注文APIで、注文者名が空なら400になるのに、明細の品番が空でも保存される。コントローラー引数に @Valid があるのを確認しても、原因が見えないことがあります。 私なら最初に見るのは、親から子へ検証を進める指定があるかです。親の検証は、子の中身を自動で全部たどるわけではありません。注文と複数明細を例に、検証する階層を見える形にします。以下は Java 21、Spring Boot 3.5系と spring-boot-starter-validation の例です。 症状を一つのJSONで再現する { ...

「1〜100文字を許可する」という仕様をテストするとき、10文字の正常系を一つ書くだけでは、length < 100という間違いを見つけられません。境界の値を表にしても、その表がコードから離れていれば、仕様変更後にテストだけ古くなることもあります。 この記事では、架空の問い合わせ管理で「件名は空白だけを認めず、Unicodeコードポイント数で1〜100」という仕様を採用します。私の結論は、同じ判定を異なる入力で繰り返す境界値だけをパラメータ化することです。null、空白、絵文字の数え方のように失敗の ...

申請フォームに開始日と終了日を追加した。両方に @NotNull を付けたのに、「終了日が開始日より前」の申請が保存されてしまう。これはアノテーションが壊れたのではありません。@NotNull が確認するのは一つの値で、二つの日付の関係は別の仕様だからです。 ここでは「開始日・終了日は両端を含み、同じ日でも申請可能」と決めます。二つの値を持つDTOにクラス単位の制約を付け、エラーは終了日へ返します。題材は架空の申請アプリです。コード例は Java 21、Spring Boot 3.5系、spring-bo ...

「件名の入力がおかしいです」と連絡されても、受け取った人は何を入力したのか、どの画面で、どうなるはずだったのか分かりません。調べる側が再質問している間にも、同じ問題が起き続けます。 この場面では、原因の推測より、別の人が同じ条件を試せる記録を優先します。 最初の報告に「Controllerが悪い」と書く必要はありません。事実と推測を分けてください。 この記事では架空の問い合わせ管理アプリを使い、曖昧な報告を、開発担当者が着手できる報告へ書き直します。 「保存できない」では調査を始められない まず、次の一文 ...

リリース判定の会議で「切り戻したら、変更後に登録したデータはどうなりますか」と聞かれた。アプリの実装は説明できるが、切り戻し手順は見ていない。ここで「たぶん大丈夫です」と返すと、未確認のままリリースの判断が進んでしまう。 この記事は、顧客や他チームに説明する機会が増えた開発担当者に向けたものです。即答するための言い回しではなく、答えがない状態を、相手が誤って判断しない返答へ変える方法を整理します。 「未確認です」でよい。ただし、判断できない範囲と次の連絡を添える。知識がないことを隠すより、何を確認するかを ...