アイロベックスメールマガジン　携帯版

SaaSがもてはやされるようになっています。

どんな素晴らしい仕組みかと思いますよね。実際、中身は私なんかには、想像もつかないくらい凄い技術の塊なのでしょうね。

ちなみにSalesforceを使ってみた感想は、「えっ、これがSaaSなの？」（失礼しました。）別に作ろうと思えば、わたしにも作ることができると思ったわけでした。

サイボウズが登場したときも、blogが登場したときも、常に後でそう思っている「情けない私」ですからねえ。
今回もその口なんでしょうかね。

もっとも、「もの好き」を売り文句にする私としては、当然、作りたくなってくるわけです。

で、早速、設計し始めてみました。

まず、メインのジャーナルテーブルを設計してみました。
・・・

ここで素晴らしいことに「今更ながら」気づきました。
データベースの項目は、大きく以下に分類されることにです。

1. 連番（とにかく順序を表すか、他とは違う番号を表すか）
2. コード（他マスタと関係する）
3. コードの名前（コードで参照される）
4. 区分
5. フラグ
6. 年月日
7. コメント
8. 数値（単価、金額、率・・・）
9. ファイルパス

これでたぶん、ほとんどの項目を網羅できます。

SQL Serverであれば、

1. 連番　→　int
2. コード　→　varchar(20)
3. 名前　→　varchar(256)
4. 区分　→　int
5. フラグ　→　char(1)
6. 年月日　→　datetime
7. コメント　→　varchar(512)
8. 数値　→　decimal(13,2)
9. ファイルパス　→　varchar(100)

これで基本設計終わりです。
なんて「ずぼら」なのでしょうか。

でも、実際、得意先コードはchar(8)、商品コードはchar(13)などと考えて確認して設計する必要あるんですかね。いまどき。

「大は小を兼ねる」

もし、成長するシステム、拡張性があるシステムを作るとしたらこんな風に割り切って、各項目の分類ごとに10とか15ずつのテーブルを作成しておいたほうが何でもできます。

もちろん、大容量の「パフォーマンスチューニング」が必要なシステムには向きません。

でも、中小企業ならほとんど、これでOKじゃないでしょうか。

だって、CPUが“Xeon”なら、CPUコアを4つ搭載した“Quad-Core CPU”、メモリが“2ギガバイト”なんていうスペックのサーバーですよ。

設計をこのくらいアバウトにしてもOKですよ。

でも「良い子はこれを鵜呑みにして真似しないでくださいね」（ちゃんと断っておかないとね！）

わたし的に忙しいので今回はこんなところで、オシマイ。

来週は、区分とフラグについての杉山的見解を話します。

前回お約束したように、「フラグ」と「区分」の違いについてお話したいと思います。

最近、話がとみに細かくなってきています。

私個人を知っている方は、「こんなに細かい人じゃないはず、もっとアバウトなはずなのに」と思っていらっしゃると想像しています。

しかし、細かければ細かく決めておいたほうが良いことも多いのです。

仕事をすることを考えた場合に、「作業」といったものに仕事を分解してしまうと、確かに、面白味は欠けますが、生産性が各段と向上することに気づくはずです。

何をどのようにするか、つまり「WHAT」「HOW」といったものが明確であればあるほど、悩んだり考えたりする時間が減って生産性は高まるのです。

そこで、この「フラグ」と「区分」の話になるわけです。

あくまでも、私が個人的に決めているものなので汎用的かどうかは一切保障しません。すみません。

まず「フラグ」ですが、YESかNOか、要するにビットとして扱うものを、私はフラグとして分類しています。

次に「区分」は、1が「売上」、2が「返品」、3が「値引き」、4が「無償」といったように、数個（多くてもせいぜい10～15個くらい）の区分けをするものに使っています。

「では、都道府県は？」と言われれば、47もあるのですし、今後、合併や分解があるかもしれないので、こういったものはコードとして分類します。

そしてデータ型は、フラグはchar(1)、区分はintを使います。
（参照：SQL Serverの場合）

フラグも区分も共に、nullを許さない項目です。

デフォルトでフラグは'N' (NOの意味、0でも構いません）、区分は0です。

かつて、「フラグを'Y'と'N'にしているのは、いかがなものでしょう」とお叱りを受けたこともありますが、私の設計では、フラグはchar(1)で、'Y' と 'N'です。

名前は、「請求済フラグ」とか「未請求フラグ」とか、具体的に'Y'や'N'が何を意味しているかがはっきり分かるものを付けています。

しょうもない話かもしれませんが、細かいことでも決めておくと、生産性は確実に上がりますよ。

生産性を高めるコツは、どんなに小さなことでもルールを決めて迷わないようにすること。

全員が打ち合わせをしなくとも同じスタイルで作業に臨めることだと確信しています。

しかし、システム開発という仕事は、実際の現場では「生産性」のみを追い求めることが非常にし難い現場です。

特に「新しいものの考え方」や「新しい技法」を使おうと思えば、そこには「教育」「学習」にかかる時間が必ず必要になってくるわけです。

だからこそ、プログラムMakingやテストの現場では、そういったものを一切排除する必要があります。
「フレームワーク」や「CASEツール」といったものが、常に開発者やシステムの担当者の心を揺さぶるのもわかるでしょう。

さて、テーラーメード型開発の中で一番重要な場面はどこか？と聞かれると、それは、画面設計ではないかと思うことがあるのです。

もちろん、システムフローやデータベースモデリングも重要に違いありませんが、そこには、システムごとの差異、カスタマイズすべき発想は、そんなには無いように思えます。

ところが画面ときたら、その設計によってユーザビリティが大きく変わってくることは間違いないのです。

ちなみに、ユーザビリティという言葉ですが、ヤコブ・ニールセンが「ユーザビリティエンジニアリング原論」で定義した要素が5つあります。
それは、

「学習のしやすさ」
「効率性」
「記憶のしやすさ」
「主観的満足度」
「エラーへの対処」

です。

その後、ISO 13407、ISO 9241-11で「機能」と「パフォーマンス」を含めた広い概念となったようです。

画面設計のことを考えるとき、わたしは、つい台所のことを考えてしまいます。
（主婦的発想ですが・・・）

どこに鍋がしまってあって、どこに野菜や肉、調味料が保存されているか、という保存場所。
料理するときに、それらを悩まず素早く用意できて、そして動きに無駄がないように考える。

片付ける場合も同様です。

料理しながら順に片付けていくことがスムーズにできるのがポイントでしょう。

その為には、何をどのように料理するかという手順を頭に入れ込んでいること。
そして、使うツールが分類されていること。


・頻繁に使うもの
・めったに使わないもの


といった区分け、


食品でも


・冷蔵するもの
・冷凍してあるもの
・乾燥食品


・スパイス
・粉もの
・瓶もの


・鍋
・調理器具


といった置き場所は、非常に重要です。

結局、画面設計も同じではないかと思っているのです。

そのシステムに使うものが分類され整理されていること。
ツールが用意されていることも必要です。

そして、頻繁に使うもの、めったに使わないものといった分類と、機能による分類がうまくされいて使うときに迷いがないこと。

こう書いてくると、結局は、画面設計に一番必要なことは、ユーザーが何を考え、何をしたいかがわかっていることだということになります。

だからユーザビリティなんでしょう。

なるほど。

今週も、前回の「画面設計とユーザビリティ」の続きです。

ヤコブ・ニールセンが「ユーザビリティエンジニアリング原論」で定義した5つの要素の中で、私がどうも気になって仕方が無いものがあります。

それは、「主観的満足度」です。

「主観的」というのは当然、ユーザーの立場に立ってのことであり、もちろん、「我ながらよくできたわ・・・」という開発者側のことではありません。

ユーザーにとっての主観的満足度とは何か？

それは「感情」です。

例えば、感情のお話をするのに、「我が家を選ぶ」という場合について、お話したいと思います。

引っ越しを何度か経験したり、自宅を購入された方には分かっていただけるかと思うのですが、客観的に見て、その不動産が資産的に良いかどうかとは違ったところに沸く感情がそこにはあります。

例えば、「駅から遠いけど、その間の緑に心が癒される」とか、「多少、静かではないけれど、隣近所づき合いができている」といったことです。

我が家という物件を見たときに、「駅から○分、南向き、築○年、建設会社は○○」といった、客観的な評価条件だけでない主観的な満足度が入ってくるのです。

システムも実は、似たようなことがあるのではないかと思っています。

しかし、システムにおいてユーザーの感情に訴えるものを作りだすのは、難しいと思うのが普通でしょう。

そこで、「画面設計」です。

システム設計者のあなたは、ユーザーの方と画面設計をするときに、どれだけの時間を割いているでしょうか。

ユーザーがこうして欲しいという意見を、どれだけ取り入れているでしょうか。

画面デザインに気を入れているでしょうか。

正直、今のような「洒落たデザインが充ち溢れている時代」に、あり得ない不器用なデザインを作っていないでしょうか？

ユーザーの「こんな感じ」という意志を、「コストがかかる」「無駄」という意見で切り捨てていないでしょうか。

毎日毎日、同じ画面を眺めて操作するユーザーには、その画面に対する「感情」が生まれてきます。

癒される色、励まされる色。

そして、使いやすい、自分の意見が通っているデザイン。

少なくとも、意見は通っていなくても自分のことを分かってくれるSEが、良かれと思って作ってくれたデザイン。

それは、分かるものだと私は信じています。

画面デザインで主観的満足度を提供する。

それは、デザイナーのセンスだけでなく、SEのユーザーに対する思いやりでもあるのです。