1. 要件定義は「仕様を書く作業」ではない

要件定義の本質は “曖昧さの除去”。
機能一覧を書くことではない。

• 業務フローを図で可視化する

• 例外系を最初に洗い出す

• 「やらないこと」を明示する

• 入出力の具体値サンプルを必ず作る

曖昧な日本語は必ず後で炎上する。
画面項目1つでも「必須条件」「桁数」「NULL可否」まで定義する。

---

2. 設計は“未来の自分への説明書”

詳細設計はレビューを通すためではなく、
半年後の自分が読んで理解できるかが基準。

• クラス責務は1つに絞る

• 命名はドメイン用語を使う

• 条件分岐は3段階を超えたら分割

• 早期リターンでネストを減らす

複雑さは必ずバグの温床になる。

---

3. DB設計は“拡張を前提”に

• 主キーは意味を持たせない（サロゲートキー推奨）

• ステータスはENUMでなくコードテーブル化

• NULLの意味を統一する

• 論理削除か物理削除か最初に決める

そして最重要：

インデックス設計は必ずEXPLAINで検証する。

推測で貼らない。

---

4. テストは「壊しに行く」視点で

正常系は誰でも書ける。
価値があるのは異常系。

• 境界値（0、1、最大値）

• 日付の月末・閏年

• 同時更新

• ネットワーク断

テストケースは“仕様の裏側”を突く。

---

5. ログは未来の証拠

ログがないシステムはブラックボックス。

• リクエストIDを必ず発行

• 例外は握り潰さない

• 重要操作は監査ログに残す

• 個人情報は出さない

「障害は必ず起こる」前提で設計する。

---

6. レビューは人格否定ではない

コードレビューの目的は：

バグ削減 × 知識共有

指摘は具体的に。

✖「可読性が悪い」
〇「このifはメソッド分割した方が責務が明確」

感情を排除し、論理で話す。

---

7. 見積りは“悲観的に”

楽観見積りは必ず崩壊する。

• 調査時間を必ず入れる

• レビュー・修正時間を含める

• 仕様変更バッファを10〜20％取る

不確実性はコスト。

---

8. 技術選定は「流行」で決めない

評価軸は3つ：

• チーム習熟度

• 保守性

• コミュニティ規模

技術的に正しい ≠ プロジェクトに適切。

---

9. セキュリティは後付け不可

• パラメータは必ずバリデーション

• SQLインジェクション対策

• 認可ロジックはAPI単位で

• パスワードはハッシュ化

“内部だから大丈夫”は幻想。

---

10. 開発者の最大資産は「集中力」

生産性は時間ではなく集中密度。

• 通知を切る

• 25〜50分単位で作業

• 疲れたら即休む

バグの多くは疲労から生まれる。

---

最後に

優れたエンジニアは
“コードが書ける人”ではない。

曖昧さを構造化し、複雑さを制御できる人。

システム開発は論理の積み重ね。
感覚ではなく、再現性で戦う。