否定表現に溢れる日常（株式会社スターロジックの羽生章洋が書いてるブログ）より：

ある雨の日に3～4歳くらいの子を連れたお母さんが、事務所のある昭和通り商店街を歩いていました。子供も傘を差していて当然よたよたした歩き方になります。子供のいる家庭ならご承知の通り、雨の日には水溜まりに入らせないのは重要なことです（笑）。そこで、そのお母さんも当然子供に注意します。

そしてその注意の仕方で「！」と感じたのです。具体的には、「水溜まりに入っちゃ駄目！」とは言うのですが、「水溜まりの横を歩いて！」とは言わないのです。「水溜まりに入らないようにしなきゃ駄目」とも言いました。普通の日本語であり違和感はないのですが、よくよく考えると相当に難易度の高い指示であると感じます。

ん～？なんか、違和感がある。。。ところで、「前回」があるようなので、それも見てみる。

否定表現と仕様書（株式会社スターロジックの羽生章洋が書いてるブログ）より：

昔から私は駄目な仕様書に共通することとして「曖昧な表現が多いこと」というのを挙げていました。そしてこの「曖昧な表現」は具体的には「否定表現」だったりするのです。「ではない」「しない」という表現です。

例えば、「Aの場合にBでなく、あるいはCでなければ、当該処理は実施しない」というようなものです。

上記の表現は当該処理なるものを実施しない場合の話です。なので、プログラムを書く側とすると「いつ実施するのか？」というのが必要になるのです。何故なら実施しないというのは、その処理の実行についてのコードを「書かない」のですから、端的に言うとこの仕様はプログラミング上は無意味いうことになるのです。しかし大抵は上記の表現から「文意を読み取る」「行間を読む」という行為を通じて、処理の実施タイミングを理解することを求められます。

そこで頑張って「Aの場合で、BかつCであれば、当該処理を実施する」と読み取ったとします（要するに、if(A and B and C)ですね）。

んー。。。最初の、駄目な仕様書に共通することとして「曖昧な表現が多いこと」というのは、同意。で、次の表現。う～ん？そうなのかなぁ？これって、このように書けるよね？

void someMethod() {
    if (A && (!B || !C)) { return; }
    // do some process...
}

非常に簡単で単純明快だと思うのですが。。。いえ、もちろん、((A && !B) || !C) かもしれません。ここは曖昧だと思いますが、「～の場合、当該処理を実施しない」というのが曖昧だとは思えないです。あるいは、「いつ実施するのか？」というのが必要になるとは思いません（もちろん、場合によっては必要になることもあると思う）。全ての場合から、実施しない場合を除けば、実施する場合になります。上のコードは、そのようにコーディングした例です。もちろん、if が何重にも入れ子になるようなケースは、「見やすさ」の観点から、遠慮したいです。

で、一つ目の引用に戻る。

子どもが水たまりに入ろうとしている時。この時、親が思い浮かべるのは、次のうちのどれかではないでしょうか。「１．水たまりで、ビチャビチャ足踏みして遊び出す」「２．水を盛大にはねて、靴下やズボンを濡らす／汚す」

親が「入らないで！」というのは、「入ってはいけない」と言っているのではなく、入るという原因で発生する結果を避けようと思って言っているのではないでしょうか。つまり、実際に伝えたいのは、「入ってはいけない」のではなく、「入って、（子ども自身、親、周りの人の）服を汚さないで」ではないでしょうか。

このとき、最も大事なのは「服を汚さない／泥水を跳ね上げない」ということで、「水たまりに入らない」ということではありません。例えば、水たまりが浅ければ、そうっと入るのはかまわないのです。たいていは、それでも撥ねたり、意外に深くて濡らしてしまうことになるのですが。

確かに、指示を受けた方は、難しいでしょう。しかし、様々な方法を試みる自由がある、とも言えます。また、考える力を鍛えることが出来るとも言えるでしょう。

否定表現に溢れる日常（株式会社スターロジックの羽生章洋が書いてるブログ）より：

同様に私どもの仕事においても、例えば「バグを出すな」とは言われますが、では「このようにして」と具体的に明示されることは意外とないように感じます。つまり問題の指摘をしてそれをするなという否定表現は容易なのですが、何を持って正解とするのかを明示するというのは咄嗟には難しいということなのかもしれません。

これは、「難しい」どころか、ほぼ不可能ではないでしょうか。

「バグ」とは、なんでしょう？プログラムに対して、「こう動いて欲しい」という期待があります。その期待にそぐわないことが、「バグ」ではないでしょうか。「バグを出すな」ということは、「期待通りに動作させろ」ということです。

「期待」は、仕様によって規定されているでしょう。しかし、「期待通りに動作しない状態」は、規定されていません。そして、そのような状態になる方法は、無数にあります。それら一つひとつに対策を考え、対策方法を指示していくのでしょうか。ナンセンスだと思います。

もちろん、「このように書く」というのを規定して、「これに従って書いて」と言うこともできます。でも、このときでも、「これに従って、バグの無い様に書いて」と言うでしょう。それは、コーディング規定に沿っても、ロジックについては規定されていないからです。

ひとつの問題に対して、解決策はいくつもある場合が多いです。それらの中から最良なものを探して提示する、というのもひとつの教えかもしれません。しかし、「アレをするな、コレをするな」から、話し手が意図している「本当に禁止したいこと」を考え、それを回避する方法を考えること。それもひとつの教えではないでしょうか。

あるいは、「コレをしろ、アレをしろ」と、レールを敷いてその上を走ることだけを教えた場合、考えることをしなくなる可能性があります。自分が考えなくても、誰かが考えてくれるのですから。それって、とっても危険だと思います。