ホント世の中クソだらけだと思うんだけど、ブラウザが高度なことをできるようになればなるほど、今までシンプルで良かったものが複雑化する、というのはその中でも最たるものだ。ついにスマホ広告もキャラが走り回ったりし始めてクソ邪魔な上に僕らのギガとmAhを奪っていく。何度も言っていることだが、僕は広告収益というものに一応肯定的である。広告のおかげで無料や低額でコンテンツを受容できるし、広告自体が有益な場合もまあまあある。だからこそ、無意味な広告が表示されているだけならともかく、僕のスマホ上を駆け回ることは許容しがたい。これはあんまりではないか？こっそりマイニングしているページはもちろんEvilだが、必要以上にCPUを消費するコンテンツを同意なく表示することはそれに匹敵するくらいEvilではないか。
リスクゼロを求めている人はそんなにいない
まあここに書いてあることはおおよそ正しいと思うんだけど、「リスクゼロ」という言葉は独り歩きしているように思える気が最近してきました。リスクマネジメントという考え方についても理解できない、理解していない、というより理解する気がないというのが真実なのではないか、もっというと、「俺に火の粉を振りかけるな」ということに過ぎないんじゃないかということなのではないか、と。つまり、世の中には無能が多いという身も蓋もない話です。
そういう眼鏡で世界を眺めていると、ゼロリスクやリスクゼロという言葉は単なる象徴に過ぎない、ということがよくわかります。とにかくリスクという気持ち悪いものを保有していたくない、という気持ちがそう言わせているだけですよね。生きているだけでリスクがあるというのにね。
そもそも実はリスクを気にせず好きにしたい、という欲求を大抵の人は持っていると思うんですよね。このあたりは普段は理性で抑える代わりに冒険者やらノワールやらヤンキーもののフィクションが幅広く許容されるわけです。リスクをガチガチに管理する人が大半の世界でリスクを取る人は結構な確率で成功者になるということもあり、「リスクを取らないからには徹底的に取らない」という心理も働きそうですよね。リスクを取らないことの理由付けが難しくなるから。この手のバイアスが働いている中でリスク管理をする、ということはリスク管理をしていない、お題目としてのリスクゼロ（実際のところ、ハイリスクを選択することが多くなりがちな）を求めている人たちに「そんなリスクを保有するなんてとんでもない」と言われがちなんだろうと思います。知らないリスクはリスクではない！ゼロリスク！であれば無知であればあるほどリスクが低減されます。これが新世代のリスクマネジメント…
かくして、リスクゼロという言葉とは裏腹にハイリスクの道を邁進することになります。これは容易には転換しづらい社会の摂理です。この手のパターンに一番有効なのは、その道を行く人が次々と地雷を踏み抜いて危険な道だということが明らかになることなので、安全な道に大して「この服を着ていれば地雷が回避できる。みんな着ているから爆発しないんだ」という商売の嘘を見抜くことができなくなります。行くも地獄、行かぬも地獄、リスクゼロの道は現金で舗装されています。
おかげさまで、金融業界などの人たちはITにたんまりお金を払ってくれます。じゃないとほら、PayPayみたいになりますよ、的な。最後に残るのがPayPayだとしても。
削除フラグは使ってはならない。絶対にだ
はい、炎上します（タイトル的に）
まあここに書かれていることにはいろいろ言いたいこともあるが、特に個人情報にまつわる仕様としてのべき論についてはみんながブコメしているのでよいです。
で、問題は削除フラグという考え方なんですが、僕が昔炎上プロジェクトで学んだいちばん大事なことは「RDBで履歴管理をしてはならない」ということですね。ちょっと言い方が悪いがここで言う履歴というのはログとか（まあログをRDBで持つのは大概だけど）、アクセス履歴的な履歴レコードの話ではなく、データレコード自体に履歴的な項目を入れて管理してはいけない、ということで、データレコードは現状の状態を正確に持つべきだし、削除されたレコードはそのテーブルに置いてはいけない（物理削除したら消えますので当たり前ですが）。すなわち以下の三原則を適用すべき（てきとーにでっち上げたのでジョークだと思って）。
削除フラグを用いないとユニークにならないテーブル設計をすべきではない
これ、よくあるんだけど、主キーのはずの項目がDBで履歴管理をした結果として削除フラグを持っている死にレコードと、生きている単一レコードが同居するという地獄が発生することがあります。うん、確定した変更データを前の情報に戻したいとかわかる。わかるがやめろ死ぬ。
削除フラグをオフにしてはならない
一個目の話とおんなじなんだけど、結局こういう管理になるのは何故かと言うと、削除フラグをオフにすれば元に戻るじゃん的発想が悪い。死ぬ。アカウントの復活みたいなのは全部フラグオフれば戻るじゃん、というのはそういうクソ機能のために設計変更を阻害するので死ぬ。別の手段を用意すべき
そもそも削除フラグを持つべきではない
削除フラグなんてものがあるからみんな期待するんだよ。なければ解決。
削除フラグに依存するシステムは相当な技術的負債を負うことになる。大抵のことはちゃんとしたデータ設計をすれば削除フラグなんてなくても実現可能だ。ユーザーマスタに退会フラグがあるみたいなのはまだ許せなくはない。これだって混乱の元だしフラグ見忘れる事故なんてすぐ起きると思うので正しいのは別のテーブルにぶっこむかログ吐くくらいにしとけと。
こういう、アーキテクチャのお作法的なものはもちろん流儀がたくさんあるし適用されるシステムによってだいぶ事情が異なるとは思うけど、少なくとも「削除フラグ」が有効に機能することを意図して作られたシステムはおおよそ苦労している経験しかない。誰か削除フラグのハッピーな使い方知ってたら教えて欲しい。
