コーディング記述ミス、あるいはコーディングミスと呼ばれる不良および欠陥ですね。

当然ながら、コーディング…すなわち「実装」工程以降に発見される問題で、多くはテスト工程（特に単体テスト）の中で消化・解決されます。ウォーターフォールであってもアジャイルであっても、設計して製造して試験する流れは同じ（対象の開発単位が違うだけ）なのでどこでも同じになるのではないでしょうか。

稀に納品され、稼働後に発覚するモノなんかもありますが、正直、このレベルのものがテストで発見されないまま世に出てしまうと、一般的なエンジニアから

　「うわぁ…」

という白い目で見られます。不良を作りこんでしまったことに対してではなく、そんな稚拙なレベルの問題すら「まともにテストしてないの？」と評価されているからです。

条件/原因

まず、問題を「問題だ」と認識した時、その原因を特定することになるためいろいろ調査すると思いますが、「コーディングの記述ミス」は次の条件をすべて満たしたときにそう断定します。

　・設計書に誤りがない
　・プログラムに誤りがある

「設計書に誤りがない」とは、その元（インプット）となる仕様書や提案書、あるいは要件定義書などを元に実現するべき機能や処理が明記されていて、且つ

　「インターフェース設計／定義が完了している」
　「インターフェースの定義にIN⇔OUTで齟齬が無い」
　「プログラムに翻訳するために必要な情報が揃っている」

と言った条件を満たした設計書となっているということです。

「インターフェースの定義にIN⇔OUTで齟齬が無い」というのは、"呼出元と呼出先"、"返送元と返送先"間で同じインターフェース定義に従っているかどうか、という意味です。

という構図をイメージした時、プログラムは原則として「インプットの確認」「アウトプットのための判断や加工・編集」しか行いませんし、行えません。だからこそＩＴ（Information Technology：情報を取り扱う技術）と言うわけですしね。

ですから、インターフェースのうち

　「インプット情報は何か？」
　「アウトプットする情報は何か？」
　「その差異をどう処理によって埋めるのか？」

の３点は最低限度明確になっていなければなりません。

「設計書」という実体にするかしないかは開発現場によって異なるでしょうが、記録化しないでユーザーやメンバーそれぞれの互いの認識が常に一致していられる自信があるのであれば、作成しないという選択肢もあっていいでしょう。

コーディング記述ミス、コーディングミスと言うのは、基本的に

　プログラマーが設計認識を誤った
　または完全にケアレスミス

場合に起こすものです。この不良が極稀に起きている程度であれば（人間が不完全な生き物であるがゆえに）何も問題は無いのですが、頻発する場合はおそらく開発プロセスそのもののどこかに構造的な欠陥が起きていることを疑った方がいいでしょう。

対策

対策するのは、次の通りです。