「システム開発の依頼を受けた」「新しいサービスを開始しようと思う」。プログラミングを伴うシステムを作るときに寄せられる相談の中で多いものの中に「まずどうすればいいの？」という漠然とした質問があります。

そういう時は「がんばればいんだよ」と、また漠然とした回答をする場合がありますが、実際に手を付けなければいけないものというのは開発案件によって順序が異なってきます。
これからは「よし、やってみよう」でうまく行くものではなく、考えて動かないとどこかで行き詰ったり、無駄に右往左往することになったりします。

まずは要件定義を固めようとか、プロトタイプベースで進めようとか、アジャイル形式だから大丈夫とか（何が大丈夫なのか不明ですが）、いろいろな考えを持つ人がいます。
もちろん依頼主の要件が全く分からない状態で物事を進めることはできませんから、要件定義は重要です。
ただ、その要件定義もそのあとにくるフェーズをしっかりと描きながらやったほうがやりやすいものになるはずです。
ある程度データベースの設計を頭の中に構築できるようになると、ゼロから何かを作る際に一つの支柱として考えがまとめやすくなってきます。

データベース設計の失敗が破綻を招く

以前（だいぶ昔の話です）、私の同僚でデータベース設計を疎かにしてしまい、あとから大変なことになってしまったエンジニアのリーダーがいました。
最初の経緯は私も良く分からないのですが、案件が始まってある程度の日数が過ぎたのち、同僚のチームのメンバーから相談を受けました。
「どう考えてデータベース設計が出鱈目で、このままではプロジェクトが破綻してしまいます」
ちょっと大げさだな、とその時は思いました。
そのメンバーも経験が浅く、プログラマとして1年くらいだったので「リーダーにも考えがあると思うよ」と宥めました。
納品が終わっているわけではなく、開発期間もまだ半分以上は残っている。ある程度の修正とかデータ移行はできるから、多少の誤りは今から直せばいいのではないか、と。
私も案件内容は把握していたので、目算で余裕で間に合うレベルだと判断していました。
私自身抱えているプロジェクトがあったので、その件は頭に残りつつも慌ただしく一カ月ちょっとの日々が過ぎました。
ある日そのプロジェクトのメンバーから再び相談を受けました。
「まるで地獄のようだ」、と。
いやいや大げさだよ、と思いつつ話を聞くと、スケジュール的に間に合わないと判断して外部から人員を雇い、それでも間に合わずにかなりの残業をしているようでした。
今だから言えますがが表沙汰になると大問題になるくらいの時間です。軽く計算しただけで、残業代でプロジェクトの予算が尽きてしまうくらいの時間が費やされ、プロジェクトのメンバーを見に行くと全員悲壮感があふれる表情をしていました。
社員メンバーは一年前後の経験者で、受託でゼロから開発した経験がない者ばかりでした。外部のメンバーに話を聞くと「データベースがおかしくて、どこがおかしいか分からないくらいにプログラムが不整合を起こしてしまい手が付けられなくなっている」とのことでした。

データベース設計は土台

私のほうでデータベース設計とプログラムをヒアリングをしながら順番に確認すると

・データベース上にリレーション制約が存在しない
・リレーションはプログラムで強引につなげている
・物理削除をしている場所が多い
・ユニークキーはプログラムで重複判断をしている
・正規化がされていないのでテーブル間でデータの重複がある

という感じでした。
制約がない上にプログラムで重複チェックをしているので、データが物理削除されると、どこにもつながらない謎データができてしまう状態でした。
さらに、正規化をしていないので、あちこちに重複データが存在し、それをプログラムで更新してあげないと動かないという感じです。
会員登録をしたら、プログラムでいくつものテーブルに会員データを差し込んで、更新削除されたら関連するデータを検索して更新…。
途中で多少の仕様変更が入って、そのたびにプログラム側で帳尻を合わせる…。
そんなことをしていたらプログラムが破綻するのは当然で、データベースも信用できないデータの塊になっていました。

データベースはデータを記録するためのものですが、ただデータを入れておければ良いというものではありません。
正しくないデータは入れることができないという設計をすることで、システムの土台として信頼性のあるものでないとならないわけです。
結局、このプロジェクトのリーダーはゼロからシステムを立ち上げた経験がなく、データベースも「SQLは使える」くらいのレベルで設計はまったくやったことが無い人でした。

開発の土台がしっかりしていないと、プログラマがどんなに努力しても無駄に終わる場合があります。
中でもデータベースの設計は重要な位置を占める場合が多いです。

今後、メディア上で、具体的なデータベース設計についての記事も取り上げていきます。
実際に経験をすることも重要ですが、失敗を繰り返すとチャンスを失う場合もあります。なので、基本的な理屈は念頭に置いたうえでプロジェクトに臨むと良いかと思います。

Tetsuya Ikezawa (4 months ago)