読者です 読者をやめる 読者になる 読者になる

底辺過ぎてちょっとビビる

26歳からIT業界にいるエンジニアが、まったく成長できてないことを確認するブログ。備忘録的に使いたいとも考えています。

画面設計とDBと顧客レビュー

先日今やっている外部設計の顧客レビューが行われた。

 

画面のレイアウトと、画面の項目一覧、それと画面ごとの仕様についての確認を行った。レビュー前日と当日は緊張でどうしようもなかったが、なんとか終えることが出来た。

 

正直レビューとしての中身はグダグダだったと言わざるを得ない。

顧客にはシステム部が存在しないため、技術的な質問はなかったけれど

業務をいまいち把握できておらずトンチンカンな回答をしてしまうこともしばしば。

 

レビューをしていて気づいたのだけど、画面設計をしていく中であまりDBについて考慮できていなかった。

 

例えば、以下の様な画面があったとして

 

 

f:id:starscream1999:20130926004050j:plain

①会員№②氏名を検索キーとしているが

どこのマスタ(テーブル)から検索しようとしているか検討していただろうか?

 

また、①住所②電話③学歴④年齢を表示項目としているが、検索キーに一致する

どのマスタ(テーブル)の情報を表示するつもりなのか検討していただろうか。

 

「削除ボタン」なんてボタンを簡単に配置しているけれど、マスタからレコードを削除させるつもりなのかどうなのか?

その辺正直なんにも検討していないというか、何も考えていない。

 

この画面はサンプルで非常に簡単な作りになっているけど、実際はいくつもテーブルやマスタが存在していて、それぞれ複雑に絡み合っているわけで画面設計と言いながらもDBをどうするかというのも非常に大事な問題なのだ。

 

トータルで考えることが出来ないのが僕の悪い癖だけど、今回は画面があらかた出来上がっているわけで、いい加減DBの構成についてしっかりと考えていかないといけない。

 

レビューでは、顧客にシステム部がないというか技術者が一人もいないおかげ?で技術的なツッコミはなかったものの、ない故にこちら側で間違えている部分については対処しなくてはいけない。

 

今までの開発プロジェクトでは、DBがすでに出来上がっている状態で、

どの情報を抽出するか、更新するか、削除するか、といった操作する部分に重きをおいてきたけれど、今回の開発プロジェクトでは「どういったDB構成にするか」という部分をしっかり検討する必要がある。

 

今まで他人に任せきりにしていた部分だ。

本を読むだけでなく、実際に手を動かすというか具体的に考えないと・・・。