ポンコツPdM

振り返りで付箋が並んでも、次の二週間に何も変わらない。そんなKPTなら、参加者が「また同じ話をするだけ」と感じるのも自然です。 この場面では、たくさんのTryを採用するより、次の期間に試せる変更を一つ選び、結果を見に行くことを優先します。 KPTはKeep（続けたいこと）、Problem（困ったこと）、Try（試すこと）を話すための枠です。Problemを人の反省文にしないことも大切です。 以下は架空の問い合わせ管理アプリの改修チームが、件名の上限修正を終えた後に行う振り返りです。 会議の前に、事実を一枚 ...

APIのレスポンスDTOが、フィールド、コンストラクタ、getter、equals だけの長いクラスになっている。これなら record で短く書けます。一方、record にしただけでデータが完全に変更不能になると思うと、思わぬ共有状態を残します。 私の判断はシンプルです。値を受け渡すために形が固定された型にはrecord、生成後に状態を変える必要がある型には通常クラスを選びます。JPAのEntityなど、フレームワークが特定の構造を要求する型も、その要件を優先します。以下は Java 21 を前提にし ...

古いコードを見るたび「全部直したい」と思う一方、機能の依頼は止まりません。そこで「空いた時間にリファクタリング」とだけ決めると、影響の大きい部分も後回しになりがちです。 この場面では、きれいに見えるかより、次に触る予定のある場所で、実際に繰り返し払っている負担を優先します。 ただしセキュリティやデータ破損など、直ちに扱うべきリスクは別枠で緊急に判断します。 技術的負債は便利な比喩ですが、古いコードを全て同じ緊急度にする言葉ではありません。Martin Fowlerの説明でも、利息にあたる負担が小さい、めっ ...

作業一覧を「未着手を先、同じ状態なら期限が近い順」に並べた。最初はよく見えたのに、期限が未設定のデータが来ると例外になり、同じ期限の行も表示のたびに順序が揺れる。 複数条件のソートは、比較式を一行へ詰めるより、利用者が期待する順序を表にしてから Comparator を組む方が安全です。以下は Java 17 の例です。 実行サンプル 期限の昇順・降順を同じ5件のデータで比較し、状態・null・同日の順番も確認します。 JDK 17以上とMavenを使います。ZIPを展開し、mvn clean testを ...

Javaのクラス設計の最初の1冊。料金計算の例で、値と処理をどのクラスに置くか、送料と表示文をどこで変えるかを確かめます。

Spring Boot初心者向けの本3冊。注文APIを動かし、HTTP 201・400・409とロールバックを確かめて、自分に必要な1冊を選べます。

障害報告書の最後に「今後は確認を徹底する」と書くと、文章としては締まります。しかし次に何を変更し、誰がいつ、その効果をどう確かめるかは決まりません。 この場面では、担当者の注意喚起より、同じ条件が起きたときのシステムと運用の動きを変えることを優先します。 発生を防ぐ策と、発生しても早く気づき影響を抑える策を分けます。 以下は問い合わせ受付通知が二重に送られた、という架空の事例です。実際の顧客や障害を記述したものではありません。 まず、何が分かっているかを固定する 項目 架空の記入例 事象 受付済みの問い合 ...

3列のCSVを line.split(",") で読んでいたら、名前にカンマが入った行から列がずれた。1セル内に改行があると、行を読む時点でも崩れます。 CSV取込で私が取る方針は、区切り位置を自作しないことです。ファイルの形式と文字コードを決め、対応するパーサーへ任せます。そのうえで、ヘッダー・列数・必須値という業務上の条件を自分たちのコードで検証します。以下は Java 17、Apache Commons CSV 1.14.1 の例です。 実行サンプル 現物CSV・パーサーのソース ...

半年後に「なぜ通知処理をこの方式にしたのですか」と聞かれ、コードだけでは答えられない。担当者が異動すると、当時は合理的だった選択も、単なる奇妙な実装に見えることがあります。 この場面では、結論だけでなく、当時の条件と引き受けた不利益を残すことを優先します。 ADR（Architecture Decision Record）は、その設計判断を後から読み直すための記録です。全てのクラスやメソッドを文書化する必要はなく、後で変更費用が大きくなりそうな判断に使います。 MADRの公式テンプレートには、背景、判断材 ...

フォームを作って終わりにしない。入力の約束からエラー時の再表示、Serviceの業務判断、MockMvcでの確認まで、既存記事を読む順と確認する問いをまとめました。