会社を運営しようとすると、顧客、勤怠、売上など、様々な管理業務は避けられない。中小企業ではこの部分がきっちり効率化しておらず、手書きやExcelでの管理が散見される。僕はそれを最低限の規模のデータベースシステムに作り直して運用するサービスも行っている。

人が感覚的に作ったExcelファイル等をシステム化するとき、かならずやらなければならないのがデータベースの最適化だ。それをしなければ効率よく作ることができないし、きびきびと動いてもくれない。そしてなにより、あとで改良するとき膨大な分析と作業で手に負えなくなる。

データベースという総体の中に、いくつもの表(テーブル)をつくり、それぞれのテーブル内の行(レコード)が増えて蓄積されていく、行は必要に応じて作った項目(列)で構成される、という基本的な構造を踏まえて話を進める。

たとえぱ請求書を思い浮かべてほしい。1枚の紙に必要な情報が詰め込まれているので、人からの見た目ベースでは「データひとかたまり」すなわち「1テーブル1レコード」だ。しかし、これをパソコンのシステムベースにすると、「4テーブル8レコード」などという全く違うものになる。なぜか。

まず相手先の住所や会社名などは、以後の請求書でもたびたび呼び出すことになるから、これを請求書のデータとして持ってしまうと、新しい請求書が作られるごとにこれが複製され、システム内に大量に重複して存在することになる。あとで住所を修正しようものなら、すべての請求書のデータを直さなければならない。実際Excelで請求書を作っていたら、そうなることだろう。

意味のない重複をなくすことは、最適化の基本の一つだ。この場合、「請求書」とは別に「顧客」というテーブルを設けてデータを持ち、請求書から呼び出す方式を取るのが適切だ。結果、内部的には請求書内のデータは「株式会社〇〇」ではなく「15」という顧客レコード番号のみとなる。以後の請求書で同じ番号を呼び出せば、同じ相手先の情報が表示されるという具合だ。顧客レコードの住所を変えれば、この相手先宛の請求書の住所は一括で変わる。

自社の情報も当然に請求書に記載するが、これなどは相手先データよりさらに単純で、すべての請求書に同じく表示すべきものだ。これも同じ理由で、「基本情報」というような別途のテーブルに持たせるべきものだろう。

明細行はどうか。これは確かに請求書ごとに固有の情報だから請求書テーブルが持つべきと考えやすいが、問題は何行になるかわからない点だ。一番多い場合に備えて大量の列を作っておくというのもありだが、最大値を超えたとき処理できなくなるし、普段殆ど使われない空き列だらけになる恐れがあり、処理を遅くさせるかもしれない。

親と子でテーブルを分けるのも、最適化の定番メニューだ。「請求書」とは別に「請求明細」というようなテーブルを作り、個々の品名、単価、数量等のデータを持たせれば、明細行の増減に柔軟に対応できるようになる。

これでテーブルは「基本情報(自社の住所や屋号)」「顧客(相手先の住所や会社名)」「請求書(日付や合計金額)」「請求明細(個々の品名や数量)」の4テーブル、レコードは、明細が5レコードとすると、それ以外のテーブルは1づつ、計8レコードである。このように毛色の違うデータを別々のテーブルに分割する意義は、総じてそれぞれのテーブルの余計な列をなくし、同じデータの重複をなくすことだ。これにより、人間側の操作は減り、システムは軽快に動く。

難しい例示が続いたが、この話は抽象化したほうがわかりやすい。要するに、重複をなくせ、親子関係をはっきりさせろ、関係ないものを一緒くたにするな、ということだ。これはまさにデザインの鉄則そのものではないだろうか。

デザインというと、色をつける、飾り付ける、模様をあしらうといった「足し算」を想起しがちだが、本質的にはそれらを「必要なだけ」施すことであり、過剰なものを削ぎ落としていく「引き算」の度合いが強いと感じる。

学校でのノートテイクで、大事なところに赤線を引いていたら、いつのまにかページ全体が真っ赤になってしまうタイプの人がいる。過ぎたるは及ばざるが如し、結局なにも強調していないのと同じだ。どこを強調するか考えるより、どこを強調しないのかを考える方が速かったりする。また社会のノートで「三権分立」と「立法」以下を同じ左揃えで書くのではなく、後者を少し右にずらして書くと、親子関係がはっきりして記憶を促進させる。前者をタイトルらしく少し大きめに書くのもよい。そして、数学と英語を同じノートに混在させると困るということは、自然に身に着けた知恵だろう。

「データベース脳」になると、印刷物のデザインが洗練される程度にとどまらず、メールの文章、学生への指示伝達がすっきりし、その順序まで厳密になってくる。日常生活そのものがデザインなのだ。