←左が設計書に記載した定数　　右がアンチパターン定数→

定数値が与えられているものに、新しい定数を差し込む形で実装されることが考えられます。

この実装でデプロイされてしまった場合、元々DBに登録のあった3〜5の値の意味が変わってしまいます。

問題点と解決策

• 問題点：実装が想定通りにならない
  • 「定数上は6に追加、画面表示上は高校と短大の間に表示」と設計・記載していたものが、うまく開発者に伝わっていない
• 解決策：開発指示を要件定義・設計書の共有のみで行うのではなく、必要に応じて開発者の理解度を確認する必要がある
  
  
• 問題点：PRレビューを行っていない可能性がある
  • 忙しいことを理由にPRレビューを行わず本番実装されてしまうと、結局修正＆リカバリーに工数がかかってしまう
• 解決策：開発者から上がってきたPRを必ずレビューする
  
  
• 問題点：要件定義時に組み込むべき内容が組み込まれていない
  • この一覧を見て、「専門学校」が追加されるのは予想できた
• 解決策：要件定義の段階で漏れがないよう、必要であれば開発チーム全体で意見を交換しながら洗い出しを行う

上記のように name を単純に last_name と first_name に分割してしまうのは、アンチパターンといえます。

その理由は以下のとおりです。

• APIの仕様が変更されると、利用している外部システム側でも同時に対応が必要になる
• スマホアプリの場合、APIの更新にあわせてアプリのアップデートを必須にできるものの、更新のたびに利用者にアップデートを強いるのはユーザビリティ上望ましくない

API開発の場合、API利用側の立場で考えることが、良い設計につながると考えます。

理想的な対応方法

１．カラム名は置き換えるのではなく、追加をする。

name カラムを残したまま last_name と first_name を追加すれば、既存の利用者に影響を与えずに移行できる。
特に制約がない場合はもっとも手軽な方法。

ただし、管理項目が増える、通信データ量が増えるというデメリットもある。
特に利用者側がスマホアプリだと少しでも通信量は減らしたい。

{
	"name": "山田太郎",
	"last_name" : "山田",
	"first_name": "太郎"
}

２．URLを分ける

旧仕様（v1）と新仕様（v2）のエンドポイントを分けることで、両方の利用を可能にする。
外部システムやスマホアプリは移行のタイミングで v1 から v2 へ切り替えればよい。
あらかじめ v1 のアクセス期限を設定しておくことで、 v1 の切り捨てが可能。

<https://hogehoge/v1/name>
{
	"name": "山田太郎"
}

<https://hogehoge/v2/name>
{
	"last_name" : "山田",
	"first_name": "太郎"
}