DQN = Dumbly Qualified Negligence

「愚かにも（正しいものと）認定されてしまった怠慢、あるいは失敗」。わはは。上手いこと言うなあ。YAMDAS現更新履歴経由でHal Tasaki's logWより。
駅のプラットフォームの柵の必要性は、確かに誰もが一度は考える話ですね。しかしすべてのシステムの初期設計が完璧であるべきと期待するのはどうかなあ。まず無理だろうと思う。と同時に、現在非常にDQNなシステムであっても、稼動当初はそれほどDQNでなかった可能性が高いとも思う。つまり多少DQNなシステムであっても、とにかく稼動させることの効用が当時としては大きかったのじゃなかろうか。
では何故、昔はちょっとしたDQNだったのが現在では許しがたいDQNになってしまうのかと言えば、これはシステムそのものが変化したというよりは、システムがおかれている環境が変化したからであるに相違ない。ほとんどのシステムはそのままほっておけばどんどんDQN化する、と言っても良いかもしれない。
となるとDQNなシステムを考える際にまず重要なのは、どの時点でそれが許しがたくDQNであると認識するか、ということになる。しかしこれだけだと単に既存のシステムをそのまま使うこととアップグレードすることとのトレードオフを（誰かがもう我慢ならなくなった時に）検討しましょうと言っているに過ぎないので、急いで次の注意点を挙げておく。つまり、今あるDQNなシステムは現状そうであるからということだけでその非効用が過小評価されるというバイアスが存在する。このバイアスを認識することがより重要なのだと。
ということで僕のこの勝手な解釈によると、DQNのN（Negligence）が指しているのは初期設計の不備ではなく、上に挙げたバイアスを認識していないこと、もしくはそのことによる判断の遅れということになる。要はゼロベースで物事を見ましょうね、というコンサルがよく言いそうな話なわけだけれど、それにDQN（なシステム）という認識タグが付いたことはとても喜ばしい。
って勝手に解釈しちゃってすいません。なんか違う話になっちゃった気もするし。今日割と暇だったもので。わはは。