定義: まず「失敗するテスト」を書き、そのテストを通る最低限のコードを書き、リファクタリングする手法。 • 効果: コードの品質担保と、変更に対する心理的な安心感を得られる。 • 例: 「テストが全部緑(合格)になった時の快感」だけで生きており、実際の画面デザインが崩壊していることに気づかない。 ドメイン駆動設計 (Domain-Driven Design / DDD) • 定義: 業務知識(ドメイン)をソフトウェアのモデルに反映させることを最優先する手法。 • 効果: 開発者とビジネスサイドの認識のズレをなくし、複雑な業務ロジック変更に強いシステムを作れる。 • 例: 居酒屋の注文時も「それは OrderコンテキストにおけるBeverage集約ルートですか?」と聞いてしまい、店員を困惑させる。 ふるまい駆動開発 (Behavior-Driven Development / BDD) • 定義: 「ユーザーがどう振る舞うか(仕様)」を自然言語に近い形式( Given-When-Then)で記述し、テストする手法。 • 効果: 技術者以外(ステークホルダー)とも仕様の共通認識を持ちやすくなる。 • 例: プロポーズの言葉も「Given: 交際3年, When: 指輪を渡す, Then: Yesと言う」とシナリオ記述してしまう。 モデル駆動開発 (Model-Driven Development / MDD) • 定義: プログラミング言語ではなく、 UMLなどの図(モデル)を描くことで、そこからコードを自動生成する手法。 • 効果: 設計図そのものが動くコードになるため、設計と実装の乖離を防げる。 • 例: 完璧な設計図を描くことに全精力を使い果たし、それを壁に貼って満足してしまい、実際に動く製品が一つもない。