メッセージ。 - diary

個人的には、ER図なんて意味がないと思っている。だって、そんなものはスキーマを見れば分かるんだから。スキーマの解読に労力なんてかからないので、それを図に落としただけのER図なんて技術上何の意味もない。
まぁ、その前の前提として、テーブル名やカラム名を見れば、それが何のためのものか分かる程度に綺麗な設計でなければならないけど。それができてないなら小学校からやりなおしてきてって話で。

むしろDBに関してドキュメントが必要なのは、テーブル名やカラム名を見ても使い方が自明でない部分だ。たとえば、あるリレーションを持つテーブルのレコードで削除フラグが立てられたとき、リレーションの繋がっている別のテーブルの値は表示すべきなのかどうなのか。

そもそも削除フラグは何のために使用するのか、実際にレコードを物理削除することはあるのか、ないのか。ユーザー系に表示するときと管理画面に表示するときとで削除フラグの扱いは異なるのか（削除フラグの立ったデータは管理画面にも完全に一切表示しないのか）。

また、一度削除フラグを立てたデータが復活した場合、各カラムに設定されていたデータは残るのか、完全にクリアされるべきなのか？クリアされるべきだとすれば、わざわざ削除フラグを立ててDB内にデータを残していた意味はどこにあるのか？

アプリケーションでの削除フラグの扱いは一貫させることができていたとして、手動でDBをいじらなければいけないとき、どのようなオペレーションが付随して必要になるのか？そもそもこれらの問いに明確に解を与えられるほどサービス要件は明確なのか？

まぁ、そもそも削除フラグが本当に必要なのか真剣に考えろってことだけど。そういった要件をドキュメント化したり実装したりするのが実際の仕事と考えると、ER図を作ることはそれは仕事にあらずという感じがするけど、ぼくは間違っているんだろうか。。

レディファーストは、女性差別か否か？

結局のところ、現実のサービス要件ってのはアナログで曖昧なんだよな。一方で、システムとか工業製品ってのはデジタルで、本質的には木で鼻をくくるようなことしかできない。で、そのデジタルなものでどうアナログな要件をカバーするか、できるだけ役に立つものを作るにはどうするかというのが一つのポイントになる。

そう考えると、システムや製品を作る際まず重要になるのは、なにを、どう作るか、ではなくて、なぜ作るのか、なにが問題なのかを明らかにすることだ。しかし実際の（日本の）現場ではその肝心なことがないがしろにされがちなように思う。

たまに英語圏の人が書いた文章を読んでいると、その知的さに驚かされることがある。日本人が書いたものに、どうしてそういった知性を見たことがないのかと不思議に思う。

それがなぜかというのは興味深い問題だが、とりあえずそれはいったん置いておくとして、そういった知的な筆者に見られる態度の一つとして、問題を評価するための尺度を明確に定めようとする姿勢があるような気がする。

ここで「たとえば…」と例を出せればいいのだけど、この着想を得たきっかけを忘れてしまった。

日本の社会設計は、現代の実状に沿ってなくて破綻してるんだよなぁ。

というのも、日本人は、知らない人とはできるだけコミュニケーションをとらないのがルールになっている。敵か味方か分からない人には情報を出さないという考え方だ。饅頭怖い理論、情報戦。

だから、知らない人同士の会話というのは基本的に禁忌されるか、少なくとも正規のプロトコルではないと見なされる。それが許されるのは、はみ出しものか、緊急時かであり、まったくの平常時に知らない人に声をかけることは、日本人の常識にはない。

健康と平和の、どちらがより大切か？