「お客様の住所を変更したのに、請求書に古い住所が印字されてしまう」。ある製造業の担当者から届いた相談は、そんな一言から始まった。システムを導入して一年半、顧客マスタの住所を更新したはずなのに、見積書・請求書・配送伝票でそれぞれ表示される住所がバラバラになっていたという。調べてみると、顧客情報が「顧客マスタ」「見積システム」「配送管理」の三箇所に別々に保存されており、どこか一つを直しても他の二つには反映されない作りになっていた。
担当者は最初、単なる入力ミスだと思っていたそうだ。しかし原因を追っていくと、システムを開発した際に「とりあえず動くもの」を急いで作った結果、同じ情報を複数の場所に重複して持たせる設計になっていたことがわかった。修正には、三箇所のデータを突き合わせて統合し直す作業が必要になり、当初の見積もりの何倍もの工数がかかった。データベース設計という、発注者からは見えにくい部分の手抜きが、後になって重い代償として跳ね返ってきた例である。
なぜデータベース設計の手抜きが起きるのか
データベース設計とは、システムの中でどんな情報を、どんな形で、どこに保存するかを決める設計図のことだ。この部分の手抜きが起きる理由は主に三つある。
一つ目は、画面や機能と違って発注者の目に触れにくいことだ。見積書のレイアウトや入力フォームの使いやすさは発注者がすぐに確認できるが、データベースの中身を見ることはほとんどない。そのため、設計が雑でも納品時には気づかれにくい。
二つ目は、納期やコストの制約だ。丁寧な設計には検討の時間がかかるため、スケジュールが厳しい案件では「まず動くものを作ってから直せばいい」という判断がされがちになる。しかし後述するように、後から直すコストは最初に設計するコストよりもはるかに大きい。
三つ目は、開発会社と発注者の間で「どんな運用をするか」の情報共有が不十分なことだ。将来的に支店が増える、取引先の種類が増える、といった事業の広がりを開発側が把握していなければ、今の業務にだけ最適化した設計になってしまう。
放置するとどうなるか
設計の甘さを放置すると、主に三つの影響が現れる。
一つ目は、冒頭の例のようなデータの不整合だ。同じ情報が複数箇所に重複して保存されていると、更新の際にどこか一箇所を直し忘れるたびに、表示される情報がずれていく。これが積み重なると、どの情報が正しいのか誰にもわからなくなる。
二つ目は、変更の影響範囲が読めなくなることだ。一つの項目を追加したいだけなのに、関連する複数のテーブルや画面を調べて回らないと安全に変更できない、という状態に陥る。結果として、小さな修正でも見積もりの工数と金額が膨らみやすくなる。
三つ目は、システムの動作が徐々に重くなることだ。無駄な重複データや非効率な保存構造は、データ量が増えるほど検索や集計の処理に時間がかかるようになる。導入当初は問題がなくても、事業が成長してデータが増えた頃に表面化することが多い。
良いデータベース設計とは何か
同じ情報は一箇所にだけ持たせる
これは「正規化」と呼ばれる考え方の核心にあたる。顧客の住所であれば、顧客マスタという一箇所にだけ保存し、見積書や配送伝票はそこから情報を参照する形にする。こうしておけば、住所を直す作業は一箇所で済み、関係するすべての帳票に自動的に反映される。
情報同士のつながりを明確にしておく
「この注文はどの顧客のものか」「この商品はどの仕入先から仕入れているか」といった情報の関係性を、あいまいさなく定義しておくことが重要だ。つながりが曖昧だと、後から集計や検索を追加しようとしたときに、正しい結果が出せないことがある。
将来の変化を見込んだ余白を持たせる
完璧に将来を予測することはできないが、「支店が増えるかもしれない」「取引先の分類を増やすかもしれない」といった事業側の見通しを開発側に伝えておくことで、最低限の拡張余地を設計に織り込んでもらうことができる。
むやみに複雑にしすぎない
正規化を突き詰めすぎると、情報を取り出すたびに多くの箇所を参照する必要が生じ、かえって処理が重くなったり、開発が複雑になったりすることもある。業務の実態に合わせて、整理された設計と実用的な速さのバランスを取ることが大切だ。
発注時に確認すべきポイント
発注者がデータベース設計の細部まで理解する必要はないが、開発会社に対して次のような質問を投げかけることはできる。
まず「同じ情報を複数の場所に重複して持たせる設計になっていないか」を尋ねてみる。答えに詰まったり、曖昧な返事しか返ってこなかったりする場合は、設計の検討が不十分な可能性がある。
次に「将来、支店や取引先の種類、商品カテゴリなどが増えたときにどう対応できるか」を聞いておく。今後の事業展開の見通しを伝えた上で、それに耐えられる作りになっているかを確認することが望ましい。
また、設計内容を図で示してもらうことも有効だ。専門的な記法を理解できなくても、どんな情報の塊が存在し、それらがどうつながっているかを図で見せてもらえれば、重複や矛盾がないか感覚的に確認しやすくなる。
現実的な進め方
データベース設計を後から直すコストは、最初に丁寧に設計しておくコストよりもはるかに大きい。運用が始まった後の修正は、既存のデータを移行しながら関連するすべての機能を同時に直す必要があり、業務を止めずに進めるための調整も加わる。冒頭の例のように、当初の見積もりの何倍もの費用と時間がかかることは珍しくない。
だからこそ、開発の初期段階でこそ時間をかける価値がある。すべての要望を最初から詰め込む必要はないが、少なくとも「今の業務でどんな情報を扱っているか」「将来どんな広がりを見込んでいるか」を開発会社に丁寧に伝え、設計段階でのすり合わせに時間を割いてもらうことが、結果的に最も費用対効果の高い進め方になる。見積もりの安さだけで開発会社を選ぶのではなく、設計についてどれだけ具体的な質問を返してくれるかも、判断材料の一つにしてほしい。
見えない土台を支える、壁を越えて働く人たちへ
データベース設計は、完成したシステムの画面には映らない。それでも、その見えない土台がしっかりしているかどうかで、日々の業務がどれだけスムーズに回るかが決まってくる。派手な機能よりも地味な整合性にこだわり、目の前の納期と将来の拡張性という相反する要求の間で最適な線を探り続けるエンジニアたちがいる。
発注者もまた、専門外の領域に踏み込んで質問を重ね、開発会社と粘り強く対話しながら、自分たちの事業に本当に必要な仕組みを形にしていく。見えにくい部分にこそ手を抜かず、部門や専門の壁を越えて向き合う人たちの積み重ねが、長く使えるシステムをつくる。オルアナは、そうして壁を越えて働く人たちを支える立場でありたいと考えている。