データベース化提案への流れ_vol.4

データベース化提案への流れ_vol.3の続きです。

よく勘違いされるのですが、「（カタログやチラシなど印刷の）自動組みのためのデータベース」ではないです。

僕らの構想としてはまず「管理がバラバラになっているデータを管理整頓して扱いやすいものに」という構想があり、それを二次利用して制作物を作ろう、というものです。

確かに受注のきっかけは「カタログに掲載されている商品を自動組みで」とか「サイトに掲載する商品を自動生成で」といったものが多いので、「そのためのデータベース」となりがちですが、折角データベースを組むわけですから他の媒体にも使えるよう、提案させていただきます。

大体は印刷物（総合カタログ、チラシ、バリアブル使っての小冊子）、PDA、携帯サイト、WEB（サイト、EC、WEBカタログ）、営業ツール（商品提案用企画書）、PDFなどです。最近だとFlashなどの動画にも反映できるようになりました 。

そういった提案をおこない、「どんな使い方」をするのか？というのを決めて、また、今回は無理だけど、次回はこんな機能も、こんな媒体に反映できるよう、というのを計画しながら構築の話を進めます。

データベース構築に関して

僕は技術的なことはわからないので、そういった内容の説明はできませんが、商品/製品データベースを今まで作ってきてよくある事例が「項目数の追加」や「ルールの変更」。

これはPMの問題でもあるし、結局「Vol.2」が曖昧なまま進んだことで起きてしまうことが多い。

例えばエクセルのシートでデータの管理をしていた場合、エクセルの場合は右クリックで縦軸にしろ横軸にしろ「挿入」すればセル増えます。が、データベースのプログラム上ではそんな簡単にはいかない。ましてアウトプットするものなら尚更です（対応できるものもありますが、基本的には大変です）。

これは担当者レベルの話にもなりますけど「どこがゴールか？」というのが明確でない。担当者の気分ひとつでルールが変わると「どこまでが作業範囲で、どこからが追加作業か」というのが曖昧になってしまう（だから契約書とか検収書とか必要なんですよね）。

ここの説明がなかなか伝わらないようで、いつも「どんな説明したら伝わるかな？」と考えてます。「あとあと大変なことになりますよ」ということなんですが。構築始まる前はいいんですよ。むしろ構築始める前に「これでもか」というぐらいに打ち合わせをしないと（双方が同じゴールを向く、同じ成果物のイメージを抱くまで）いけないと思います。

いつもはデータベースを図書館で説明してるんですが、他に説明できる例えはないかな？ということで、

家族で使うタンス編

例えば、貴方が日曜大工でタンスを作るとします。
奥さんからそのタンスにしまいたい服や小物を聞いて、全部で何種類あるか（何カテゴリあるか）、しまいたい服はどのぐらいあるのか（入力するデータ量はどれぐらいあるのか）、といったことを聞いて、これから作るタンスの規模を考えます。

しまう服などの量があまりに多いと、家ないし部屋に置けないサイズのタンスになってしまう（サーバーに収まりきらないデータベース）可能性もありますが、そんなタンス作っても無意味ですし（実際にはサーバーを新規で用意していただくか拡張していただきます）、話が進まないのでここは家に置ける規模で済んだ、という仮定で話を進めます。

しまう服の量も決まり、引き出しごとにどういうふうに分けるかも決まりました。実際にタンスの設計を始めます。

タンスの引き出しは上から順に

です。設計書や制作順序を決めていざ制作です。

引き出しの奥行や幅、各引き出しがスムーズに動くか、底が抜けたりしないか等、機能的に問題ないかを作っていきます。またデザイン（データベースのインターフェイス等）の問題もありますよね。機能と連動したデザインでないといけないので、そのあたりも考慮しながら木材削ったりしてせっせと制作します。

外枠も完成し、各引き出しがちゃんと動くかチェックして（データベース動作チェック）、実際に服をしまって出し入れしたり（データ入力して一連の動作チェック）して問題は無さそうです。

ここで奥さんが一言

「ごめん、私のスカートとGパン分けて」

と言ってきました。

今まで必死に作ってきた貴方は「は？」って感じですよね。
引き出しの数を変えるのは無理ですよね（増設とか引出を半分に切ってとかはナシで）。イチから作りなおしです。もしくは「下着は下着で全部一緒にして中に仕切りをつけて分けて」なんて言われた日にはイチからの作りなおしではないですが、仕切りを作らなくてはいけませんし、綺麗に3等分なのかそれとも少しずらして仕切りを作るのか、それとも自由に動かせるように設計するのか、という問題も出てきます（実際のデータベースですとイチから構築しなおし、という可能性もあります。そうならないように代替案考えたりはしますけどね）。

タンスでは分かりにくい、という方。「棚」でもそうですよね。

おじいちゃんの盆栽を乗せる棚編

おじいちゃんに「盆栽を飾る棚を作ってくれ」と言われました。
盆栽の種類ごとに分けたいということで、何種類なのか、数はどれだけあるのか（実際に棚に飾る数）を聞いて制作に入ります。

ここでもデザインや使い勝手の良さ、庭の広さなどを考慮して設計書を見せて（構想を伝えて）、おじいちゃんからOKをもらい、棚を制作します。もうすぐ棚が完成という時に、おじいちゃんから「この植木鉢も乗せてくれ」とか「新しく買ってきたからこれも乗せてくれ」、「実はこれもあった」、「隣の田中さん家の棚みたいにしてくれ」、「隣町の鈴木さん家の棚は一部スライド式で便利だ」とか言われると「えーっ!?」ですよね。「おじいちゃん、○ケたか？」と言いたくなります。

どうですかね。「例え」としてわかりやすかったですかね？（却ってわかりにくいですか？）実際に「もし、自分が作る側に回ったとして」と考えられると、いろいろ見えてくるものがあるかと。

データベース構築の際にキチンと最初に決めておかないと後々、こういったいろんな問題を引き起こすことになります。それがタンスや棚のように個人間、家族間での問題ならまだしも企業間だった場合お互いに損をするだけです。最初にきっちりと打ち合わせを行い、しっかりと内容を決めて、ちゃんと理解してもらった上で契約書を交わすことが重要です。