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

ベトナムに視察に行って、日本からソフトウエア開発を請けている会社の方にお話を伺う機会がありましたが、「日本の会社は品質に非常にうるさい」ということでした。

「日本の」とおっしゃったのは、「欧州やアメリカに比べて」というような意味でした。

「品質」を英訳すると「Quality」であるとずっと思っていましたが、どうも、日本のビジネスにおいては、「品質」とは、ある部分のことが一定レベルに達していることを意味していて、一方で、「クオリティ」と言うと、全体としての目的や顧客要件にどれだけ合致しているかという意味で使用していることが多いようです。

そういった意味では、顧客の信頼を失うのは品質が悪いときですが、顧客の信頼を得るには品質が良いだけでは足らず、クオリティが高くなければならないというわけです。

システム全体として、顧客要件の合格レベルは、細かい部分の1箇所ずつの平均点や総合点ではなくて、もっと別の視点から見た、大きな基本思想といったものから発生するのではないかという気がします。

前々から、仕事の仕組みとして、建設業はシステム開発会社と似ていると思っていました。

実は、昨年、実家を新築しました。複数の人間（家族）のさまざまな思惑があり、まさに三谷幸喜監督の映画「みんなのいえ」を地でいくストーリーとなったわけですが、できあがった家を見たときの思いとして、システム設計と本当に近いものがある、と思ったのです。

施主にとっては、出来上がった家を見て、「まったく不満が無い」「全て思い通り」ということはほとんど無いことでしょう。

つまり、何かしら気になる箇所はあるものなのです。

しかし、幾つかの細かな不満点があったとしても、それを超える大きな満足感があるからこそ、施主は納得するのです。

そして、多少の不具合についても、すぐさま対処できることはすぐ対処し、相談に乗るといった姿勢、つまりフットワークが軽ければ、お客さまの不満が大きくなることは、それほどないのです。

一方、一番いけないことは、大きなことで満足感を与えられないような仕事をすることではないのでしょうか。

大きな満足があれば、多少の欠点は許されるのです。

しかし、その大きな満足を生み出す仕事の力、遂行能力というのは、細かなことの積み重ねからしか、実現できないことなのです。

手順、スケジュール管理、チェックといった作業は、どんなに細かく考えても、また行っても、やりすぎるということはないのです。

逆に、成果については、細かなことを全て実現しようとしてしまうと、コストや人間の時間さえもが些細なことだらけで奪われてしまい、「大きな満足という成果を、結果として達成できなくなるのではないか？」という気がします。

ちょっと抽象的だったでしょうか？

思想がある骨組みと細かな手順、クオリティをあげること、それらが、顧客満足を得るための重要事項です。

先週、東京ビックサイトで「ソフトウェア開発環境展」が開催されました。
毎年、情報収集のために訪問しているのですが、今年は、出展社数も多く、内容もずいぶん充実していたような気がします。

当社は、システムの受託開発が主な仕事となります。
システムにおいて、画面入力の作業は、非常に重要な部分を占めています。
自社の開発したシステムはいつも見ていますが、他社の仕事を見せていただいたり、操作したりする機会はそう多くはありません。
そういった意味もあって、展覧会に行って、他社が開発したシステムを見せていただくのは本当に楽しみです。

展示されている各社の画面設計を見せてもらい、簡単な質問をさせていただきます。

システムの機能もさることながら、
どんな画面設計をしているんだろうか？
デザインはどんな風に凝っているのか？
操作性は良いだろうか？
といったところが興味をもつ部分であるわけです。

当社には、専任のグラフィックデザイナがいることもあって、ソフトウェア開発会社としては、デザイン性が良いものを提供しているという自負が、多少、ありました。

しかし、今年のソフトウェア開発環境展へ行って、本当に驚きました。
各社、かなりデザイン性にも優れ、且つ、操作性も追及したものが出ていました。

特に目についたのが、Ajax(エイジャックス）※ を用いた画面プログラムでした。

-- ※Ajaxとは ------

Webブラウザに実装されているJavaScriptのHTTP通信機能を使って、Webページのリロードを伴わずにサーバとXML形式のデータのやり取りを行なって処理を進めていく対話型Webアプリケーションの実装形態。
（IT用語辞典より http://e-words.jp/w/Ajax.html）

--------------------

ご存知のように、Webブラウザ上で動くシステムにおいて、これまでは、クラサバのような画面操作性は求められていませんでした。
それは、Webプログラミングの標準といった考え方でもありました。

操作性を良くするために、FLASHを使用することを考えている会社もあるようでした。

ところが、近年、Ajaxが当たり前のように使われるようになりました。

確かにgoogleアプリケーションなどで、Ajaxに慣れてみれば、直感的に使える、操作に“ぶつ切り”の違和感がないといった良いことばかりが目につきます。

しかし、実際には、システム開発の現場、特にユーザーごとに独自のアプリケーションを開発しているような現場では、まだまだ、全面的にAjaxを使うというところには至っていません。

それは、当社においても、画面操作で、Ajaxは、一部のみ対応している、といったところだったのです。

ところがソフトウェア開発環境展に行ってみれば、右も左もAjaxだらけだったわけです。

世の中の主流が、もうそうなっているのだと、反省致しました。

結局、操作性を追及すると

・プログラム工数が掛かる
・バグが潜みやすい
・最初の画面デザインで、動きをより細かく固めておく必要がある
・どのようなことに、どの位の工数が掛かるのか、また、実現が可能なのか、分かる人が少ない

といった問題がどうしても出てきてしまうのです。

しかし、このIT業界。
そんなことを言っていられない業界でもあるわけです。

大変なことをやらずしてどうする。新しいことに挑戦せずしてどうする。

実際、最初は大変だと思っても、
経験・実績という慣れが助けてくれるのです。
そしてフレームワークをどう作っていくか、だけなんでしょう。
（簡単なことのように言いましたが・・・）

デザインの素晴らしさも同じです。

「こんなもので良いだろう」などと、ゆめゆめ思わず、常に、より良いものを追及していきたいと思うのです。
ただし、生産性は本当に大事です。
良いものであれば、どんな時間を掛けても良いということは決して有り得ません。

要するに、どうやったら無駄な時間、工数を使わずに良いものが出来るのか、です。

少なくとも、Ajaxや画面デザインは、インターネット上で、世界中の会社が作ったものを体験できるはずです。
下記に、Ajaxのデモサイトをいくつか挙げておきます。

・Ajaxのサンプルが山のようにある。サイト自体の作りもAjax。
http://Ajaxrain.com/

・ASP.NETとAjaxのサンプル集
http://jsAjax.com/SamplesByTreeView.aspx

受託開発において、画面のデザイン・操作性はどこまで追及すべきか？
それは、自社の開発レベルを上げていく挑戦でもあるのです。

ＮＨＫ土曜ドラマ「監査法人」とうとう、終わってしまいましたね。
弊社が、プレシャス・ドーナツの本社として撮影現場を提供していたのにはお気づきだったでしょうか。
ロケ場所提供者の役得として、わたしの机の上にはイケメン「塚本高史」さんのサインと自筆の似顔絵があります。

さて、このドラマ「会計士の監査は正しいことが求められる。
しかし、正しい監査は会社を再生させることが目的であるべきだ」といった結論で終幕を迎えました。

零細企業ですが、企業の経営を行っている者として心に残ることが多くあったドラマでした。
きっと再放送があると思いますので、ご覧になることをお勧めします。

さて、既に何度も語っていることですが当社の開発形態は、受託請負の形をとっています。
つまり、プログラミング、テストといった開発中は社内でずっと作業をすることになります。

これが原因で、開発環境と本番環境の違いに気づかないリスクが生まれてくるわけです。

お客さまの運用環境、つまり、

1）サーバーの性能、容量
2）クライアントPCの性能、容量、OS
3）ネットワークの速度
4）最大データ件数
5）同時使用人数
6）同時実行機能
7）バッチの許容時間

こういったものに関して、SEが最初に調査し、シミュレーションしておく必要があるわけです。

ところが

・SEが若く想定が不足している
・現場が遠い
・正しい情報の確認ができていない

このような場合に、「1+1=2」と動くように作ったのだがそれだけでは現場不適応が生じてしまう。
つまり、「遅すぎる」「動かない」といったことになってしまうんですね。

もちろん、遅すぎるのはバグと認識しています。
ただし、「何をもって」遅いというのか？という問題がつきまとうわけです。

上記に書いた 1）～ 7）の中で、何かこれまでの開発案件と違うものがあれば必ず、小さなテストを行って時間感覚の確認を行うことをお勧めします。

確認を行うのは要件定義終了後、基本設計の途中くらいまでがリミットでしょう。

基本設計終了後に「実は時間がかかりすぎます」といった発言はNGです。

時間がかかるという問題については、別途さまざまな解決策もありますのでまたいずれ紹介することにしましょう。

目指せバグ“ゼロ”！ということで、「bug-zero」という名前の、プログラム検収管理のツールを配っています。フリーですので是非、お使いください。

http://www.ilovex.co.jp/info/freeSoft/kenshu.html

さて、当社がバグゼロを宣言して長いのですが、それでもバグは無くなりません。
最近では、わたしの視点は、プログラマにではなくてシステムエンジニアに当たっています。

それは、ある考えに至ったからなのです。
「プログラマは生産性が良い人ほどバグが少ない」というものです。

昔の言葉でいいかえて、「コードが短い人ほどバグが少ない」でもいいと思います。

では、プログラマの生産性は、何が決めるのでしょうか。

プログラマの個人の技術、性格といった、プログラマの能力で決まると思っていないでしょうか。

一般的には、そう思われているようです。

しかし、そこは亀の甲より歳の功。
そうでは無いと言えるんです。（きっぱり）
その証拠には、出来るシステムエンジニアが率いているチームでは、
プログラムの生産性が高いのです。

システムエンジニアの仕事のやり方だけでもプログラマの生産性を上げ、バグを少なくすることができるのです。

それは、詳細設計のドキュメントとその引き継ぎ方法、つまりレビューにコツがあるのです。

プログラムを引き継ぐときに、プログラマがドキュメントを読む前にまず全体像をイメージできるような引き継ぎをするのです。

そして次に、プログラマが陥りやすい罠をどこまで予測して、フォローしてあげられるのかということなのです。

イメージの為には、具体的な例にそったストーリーが大事です。

「営業が会社に戻ってから報告するためのプログラムです。
毎日、営業先から疲れて帰って来てから、今日一日を思い出して、報告書を入力するのです。

少しでも早く、忘れないうちに入力したいんです。
帰宅する直前なので時間もあまりないですしね。

だから、操作性が良いことや、入力したものが途中で消えてしまったりしないことが非常に重要です。

本当に急いでいるときには、詳細は後で入力する場合もあります。
中途のままで登録することもできたほうがいいのです。
そこで「仮登録」と「本登録」という機能に分かれています」

このような現場で使う状況がわかるようなストーリーがいいでしょう。

次に、プログラマが陥りやすい罠というのは、以下のようなことがあります。

1）実際には1,000に一つも無いような余分なことを考えて、それに対処するようなコーディングをすることに時間を費やしてしまう。

2）既に似たような画面、機能を他のプロジェクト等で他人が作っていることを知らずに一人で全部作ってしまう。

3）前回やったシステムが頭に焼きついていて、今回も同じだと決めつけてしまう。

4）今回の仕事は、今までの仕事と違うと信じていて、システムエンジニアが指示したことを自分で曲解し、勝手な思いこみによって、意図と異なる方法で実現しようとしてしまう。

1）と 2）は、システムエンジニアが、細部まで気を配って情報を余すところなく伝える必要があります。

先に述べたように、システムエンジニア自身で、プログラマがどう考えるかまで含めてきちんと細かな絵とストーリーを描いておく必要があるのです。

次に、3）と 4）は、バランスの悪い話ですが、これは、経験が少ないプログラマには本当に良くある話なのです。

そこで、経験が少ないプログラマに引き継ぐ場合には、プログラマの直属の先輩なり上司を含めて引き継ぎを行うことも大事なポイントとなるのです。

先輩であれば、彼らを、性格や技術力を含めて理解し、うまく指導してくれるはずです。

ドキュメントをいかに正確にわかりやすく書くかだけでなくシステムエンジニアとしてどれだけプログラマを見守ってあげられるのか、これが、生産性を上げ、バグゼロを実現する道でもあるのです。

さて、システム開発ではテーブルを設計する場合、プログラムを設計する場合どんな場合でも連番なりコードを作り、付けることが重要です。

商品名や得意先名があれば、コードがなくても索引になると考えるかもしれません。
でもやはりプロならコードは必ず付けるでしょう。

メッセージにもメッセージ番号といった番号を付けますよね。

例えば“締処理が実行されていないため、この年月日を入力することはできません”といったメッセージを、画面でエラーとして表示したとします。

お客さまからの電話はたいてい、こんな感じです。

「エラーが出て年月日が入力できないんです」

「どんなエラーでしょうか？」

「なんか、“入力できません”っていうエラーです」

そこで、あなたは、

「申し訳ありませんがエラー内容を全文、書きとって教えていただけますか？」

と言うこともできますが、もし、エラーメッセージが“MSG:5284 締処理が実行されていないため、この年月日を入力することはできません”というエラーだとすれば

「申し訳ありませんがエラー内容の頭に表示されている“MSG”の後に続く4桁の数字を書きとって教えていただけますか？」

で済みますし、お客さまの手間も省けるというわけです。

この「何でも番号をつける」というのは、わたしのかつてのお気に入りでもありました。

帳票や画面の隅にすべて“TMS040”といったプログラム識別番号を振っていたのです。

実際、番号を付けなければ似たようなタイトルの画面、帳票が何十種類もあるシステムもあるのです。

しかし、見栄えもあるので、お客さまが「こんなところに番号を振ってくれたら困る」という場合はもちろん付けませんし、請求書、伝票といったお客さまがお客さまに送る帳票には付けていませんでした。

しかし、なぜ付けなかったのか？と、今は不思議に思うくらい、付けて悪いことはなかったと思うのです。

実際には、お客さま（システム担当者や管理者）に、「本システムを保守しやすくするために番号を振っているんです」と話せば、「振ってはいけない」と言われたことはなかったのです。

担当者の名前の横に担当者コード、取引先の名前の横に取引先コード、これらは、システムテストや何かあった場合のチェックにすぐ使えて思い違いもないので、絶対にすべからくコード印字（帳票）、コード表示（画面）すべきだと思ってきたのですが、どうも、そう思っていない人もたくさんいるようなのです。

確かにその分、項目は多くなります。（開発コストがかかる？）

しかし、明らかに思い違いやミスが無くなると信じています。

コードの重要性についてもう一度、考えてみてもらえないでしょうか。

「間違いだらけのネットワーク作り」（著者・松田次博）を読んで、至るところで感銘を受けました。

NTTデータのネットワークエンジニアのトップとして、今後の企業ネットワーク・IP電話のことだけでなく、提案・営業やプロジェクト管理まで縦横無尽に書かれているのですが、とても読みやすい本でもあります。

それで、最近のテーマである「コード」と何が結びついてくるかというと、こんな箇所がありました。

------------------
ルータで構成されるIPネットワークが、ルータ配下のセグメントでアドレスをどう割当てようが自由なのと同じで、PBXによる内線網は自律分散型ネットワークだということだ。

自律分散型の良いところはネットワーク管理者の運用負荷が少なく、各拠点が独自に、すばやくユーザーの要求に対応できることだ。

拠点で電話機を3台追加したいと思ったら、出入りのPBX業者に電話すればよい。

すぐ技術者がやって来て、PBXの設定も電話機の設置も1人ですばやく済ませてくれる。
-------------------

では、自律分散型の逆は何かというと「集中制御型」なのです。

コードを付けると考えると、すぐエンジニアは、連番で付けると考えます。

例えばDBサーバーが1台であれば全社で連番の番号を付けます。

しかし、DBサーバーが分散している場合は、そんな設計はしないでしょう。

例えば、大規模開発を行うとします。

サブシステムごとにシステム開発チームが分離した場所で開発を行っています。

こんな場合、画面に表示するエラーメッセージ番号を、連番や整理された番号で付ける必要があるでしょうか？

MSG10001からMSG10300までが共通メッセージとして共有して使うなどという設計方針がリーダーによって決められたとします。

それぞれのチームはメッセージ番号を自分勝手に付けることは許されないのです。

つまり、番号を決めるためにいちいちPMに問い合わせなければならないということだとしたら、どんなに無駄な「時間」が必要となるでしょうか。

これがMSG10000からMSG19999までがAチーム、MSG20000からMSG29999までがBチーム、といったように、それぞれ独自に自律分散型で番号管理ができるとしたら、生産性は確実に上がります。

実際のところ、そこまでしてエラーメッセージ番号を集中で管理する必要があるのでしょうか？

これは「NO」です。

大規模開発においては、自律分散型にできるものは、徹底してそうすべきだと考えます。

たかがコードの付け方のことですが、小さな積み重ね、無駄を産まない意識が生産性を上げるのではないでしょうか。

数回に渡って番号（コード）をシステムでどう扱うのかを考えてきました。

このようなことでも、常に選択肢はいくつもありますし、ひとつひとつをどういう視点で選択決定していくかもシステムエンジニアに求められる能力だと思っています。

これまでのシステム開発では、取引先ひとつをとっても主キーとなる取引先コードや、取引先分類のキーとなる分類コードをどう設定するかというのが非常に大事な要件でありました。

システムを設計する場合、そのシステムを稼働しようと見ている期間は5～6年くらいであり、5、6年は企業の組織やビジネスモデルがそこまで大きくは変わらないであろうということがありました。

もちろん、システムはハード・ソフト含めて非常に大きな投資になるのでリースとして扱われることも多く、そこから5年という期間がいつの間にか決められていたのかもしれません。

しかし、ハードを5年間使い続けるのは、時代の流れや要求と比べると限界に近くなっています。
アプリケーションも、5年同じ考え方のものを使っていけるのでしょうか？

実際には、かなり無理をして使っていらっしゃるところが多いのではないでしょうか。

特に組織替え、新しいビジネスへの参入が問題になるではないでしょうか。
得意先であろうと商品であろうと、新しい分類方法、集計方法が次々に生まれてくるのが企業の業務実態ではないでしょうか。

そうした新しい集計は、どのように実現されているのでしょうか。

それは、ローカルのExcelであり外部システムとしてのBIツールを使っているのに違いありません。

それはそれで一過性のものとして、また、ひとつの企業システムの成長プロセスとしては役に立つものだと信じます。

しかし、そのうち全社でできるだけリアルタイムに近い状態でデータを参照し、さまざまな形でデータを集計できるシステムがほしいと思いますよね。

ここで、これまでのデータモデリングとはちょっと考え方を変えたものが必要になってくるのではないでしょうか。

あくまでも、ひとつのアイデア、提案としてお聞きください。

1）全エンティティの主キーには、得意先コード、伝票番号といった現実に存在するコードを使わない。つまり連番にしてしまう。

2）得意先コードをソート順や意味があるコードとして使う場合は、別に得意先コード＋連番といったコードを紐付けるためだけのエンティティを持つ。

3）分類コードや集計コードも2）と同様なエンティティを作成する。
分類コード＋連番
集計コード＋連番

この3）を自由に登録できるようにします。

ただし、この考え方で設計する場合、ジャーナルの中に（集計レスポンスを高めるため、もしくはその時点の集計コードを保存するため）持っている分類コード、集計コードをどう考えるのかといったことが別の問題として出てきます。

特に、半期、期といった締期間とコードとの関係性は重要なポイントです。

また、得意先マスタ、商品マスタ、社員マスタといったマスタテーブルを修正・変更する運用条件を洗い出す必要があります。

もっと突っ込んでメリット・デメリットを考えることが必要でしょうが、マスタの主キー、集計コードについて固定観念を打ち破って考えてみることもたまには必要だと思っています。

今日は9月30日。

我がアイロベックスの期末日になります。

いつも夏になると必ずお客さまのところに「最後のお願い」をして回るのが通例になってしまっています。

来期こそは、余裕で決算を迎えたいと毎年思います。

何かと色々ありましたが、皆様のおかげで決算を迎えることができました。

本当に心よりお礼を申し上げます。

さて、システムでも「締め」の感覚は非常に大事なものです。

このところ、コードの話を長々と続けてまいりましたが、期首から期末、半期といった締期間とコードの関係を考えてみましょう。

取引先コードや商品コードといったものは、締期間とは密接には関係していません。

問題になるのは、部署コード、担当者コード、分類コードといったものでしょうか。

例えば、営業担当者別に受注実績月報を集計して出力するシステムがあったとします。

営業は部が2つで、課はそれぞれ3つずつあるとします。

営業担当者の実績明細が出て、課が変わるごとに課の合計を出力し、部が変わるときに部の合計を出力するとします。

また、営業担当者マスタの中に部署コードが登録されていると仮定し、年月、担当者コードが主キーとなる実績ファイルを使います。

ここで、このような営業担当者マスタを「A」とします。

営業担当者は帰社時間がまちまちで、直帰することもあったりするため、全員の情報を締めて集計表を出すのは、翌月の営業日3日目になるとします。

すると、3月31日の集計表を出すのは4月3日になります。

ここで、4月から新しい期がはじまり、営業担当者の異動があったとします。

営業担当者を課別に並べた場合、4月3日に印刷すると、新しい期の組織で印刷されてしまうことになります。

これは困ると思います。

考えられるのは、担当者マスタに登録されている課を、システムの締め処理を済ませてから修正する方法でしょうか。

しかし、新しい組織は3月の始めに決まっているのに、4月3日まで修正できないというのも良い方法とは思えません。

ましてや4月1日から4月3日までは、課別・担当者別といった帳票は、すべて前期のものでしか確認できないことになります。

そこで、現在のシステムでは、担当者マスタの中に部署コードを登録することはやめて、異動年月日および担当者を主キーにしたテーブルを持って、そこに部署コードを登録する方法をとるのです。

ここで、このようなテーブルを「B」とします。

そうすれば、Xさんが平成19年3月31日までは営業第一部A課であり、4月1日からは営業第二部B課となっても問題は無いのです。

どちらの日付締めの考え方で帳票を印刷するかをユーザーが指定すれば良いだけなのです。

この場合の問題は、データベース設計で回避できるわけです。

しかし、年月が主キーに含まれている実績ファイルが作成されておらず、売上明細を日付で集計して部署別・担当者別に集計表を出そうと思っている場合はどうでしょうか。

この場合、売上明細の中に含まれているのが担当者コードだけで、部署コードが含まれていないのであれば、そう問題はありません。

しかし、売上明細の中に担当者コードと部署コードが含まれてしまっている場合、つまり、「売上入力」のような、売上明細を作成登録するエントリプログラムが、入力時点の担当者マスタをチェックして、そこに含まれている部署コードを登録しているのです。

組織替えの日付に前もってテーブルBが新しい部署で登録されていれば問題無いのですが、登録すべき総務部が忙しさにかまけて登録し忘れていた、などといった場合、エントリでエラーが出てしまいます。

また、そうでなければ、新しい期の情報登録なのに、前期の部署情報で登録されるということが起こりがちです。

また、部と課の関係が複雑に分裂、異動するような場合には、過去の情報に遡ってコードを付け直すことも必要になってくるでしょう。

コードと一口で言いますが、集計分類に使うコードは、こういった締め期間ごとに登録できたり、付け替えたりすることができるようにも設計する必要があるのです。

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のユーザーに対する思いやりでもあるのです。

「機能的なデザイン」を作り、かつ無駄に時間を使うことなく設計するにはどうしたら良いのか？

それには、最初にとことん画面デザインで考えることに尽きます。

歳のせいなのか、それとも生まれつきなのか、一つの物事を繰り返し考えている杉山です・・・。

しかし、SEにはそんな性質が合っているのかもしれません。
また、それくらい画面周りは重要だと思っているのです。

今回は「画面が機能的であること」について追及してみます。

通常、画面デザインを行う場合は、画面の共通事項、設計の前提条件について決めるところから始めます。

1)画面解像度を決める

正直、今だに「800×600」は、ないでしょう。
「1024×768」でも小さいくらいです。

端末PCがノートブックばかりだとしても「1280×768」で良いのではないかと思います。

最近はワイドモニターの方が値段が安いってご存知でしょうか？とにかく、時代に合わせて考え方を変えていくことが重要です。

ユーザーがどの解像度で使用するかを想定することで、画面にどれだけの情報を表示できるかが決まるので、一番先に決めたいことですよね。

2)マウス操作だけでない操作手段を決める

F1からF12までのキーを意味付けて使うのかなどを決定します。

・忙しいときに慣れた人であれば両手を駆使してすばやく操作できること
・初心者がゆっくりと判断しながら操作できること

これはどちらも要求される機能です。

3)画面として共通に表示する項目の位置を決める

ログイン者情報、日付、時刻を表示するといったことですね。
こういった共通項目を後から追加するのは開発者に無駄な工数を負担させる元です。

4)どんな種類のボタンを作るのかを共通して決める

例えば、Webシステムでよく使われるボタンとして以下のようなものがあります。

「戻る」「クリア」「ログアウト」「閉じる」「次へ」「確定」「登録」「更新」

この中でも、「次へ」や「確定」といった表記はその後にどんな画面が表示されるのかが分かりにくく、かつ、システムで何が行われるのかも分かりません。

ユーザーはボタンを押す場合に迷うだろうと思います。
このような押すのに躊躇するようなボタンはいただけないです。

・誰が見ても何の処理をするのかが推測できるアナウンスを付けること

5)横スクロールは出さない

できれば縦スクロールも使用したくないところですが、Webデザインの場合、縦スクロールは許容されているようです。

これらのことは、システム開発の仕事をしている人であれば常に考え、一定のルールの基で仕事をしていることでしょう。

しかし、わたしが一番大事にしていること、それは「無心で画面に向かって操作してみる」ということです。

「これはこういうルールなんだから、というような思いこみを捨てて操作できるか試してみる」

これです。

客観的に、時には主観的に、画面を見て操作しやすいかどうかを判断するのです。

Webサイトの制作では、こういうことが研究されていますが業務系のシステム開発でも同じです。

・人は間違えやすい
・人は細かく文字を読んで操作はしない

この気持ちを忘れずにデザインするのです。

さてこのところずっと、画面設計周りの話をしてまいりました。

さすがにネタが尽きてまいりましたので、これまでに出会った「ダメな画面設計」について話してみたいと思います。

実際、ダメな画面設計というのにも理由はいろいろあるのです。

一番悲しいなと思ったのは、「明らかに経験が少ないプログラマが考えもなく作ってしまったもの」でした。

それは、伝票入力の画面でした。

前回、画面の解像度のことをお話ししたと思うのですが、当時（10年くらい前でしょうか）解像度は1024×768で設計されていたとしましょう。

商品コードを入力するとシステムが商品名と単価を自動表示し、数量を入力すると、計算結果を自動表示するといったようなものでした。

数量を入力して、金額欄にカーソルが移る際に画面が左にスクロールするのです。

つまり、画面に横スクロールがあるということです。
画面の横のサイズがモニターの解像度を超えているために起こる動きです。

毎行の商品を入力するたびに、画面が右から左、左から右へとスクロールして動くのです。

気持ち悪い限りです。

その画面設計が、一番ダメだという理由は実はもっと深いのです。

今、これを読んだ印象では、項目が長かったり、項目数が多くて横に入りきらなかったのだろうと誰しもが思うはずなのです。

ところが、画面を見るとやたらに項目と項目の間が空いているのです。

つまり、項目の間隔を詰めればスクロールは必要ない。

何を言いたいかというと「ひどい」「笑える」ということではないのです。

「横スクロールしてはいけない」というルールがあった、無かっただけでなく、その画面を開発会社の先輩や上司が実際に見ていないのではないか、ということがひとつです。

よほど慣れた人でも画面設計は何度でも見直し、他人に指摘を受けてより良いものにするといったことが必要です。

次に、本人が作ったものを動かしたときに、なぜそれを不思議に思わなかったのか？
なぜ「まあこんなものだろう」といったことになってしまったのか？
その浅はかな考えが一番気になるところだったのです。

「ちょっと変」を放っておくと、他人にとっては「あり得ない」「とっても変」という事態に繋がるということなんです。

これって、何にでも応用できる考えですよね。

今回も、画面設計についてです。

よくこんなに題材があるなぁと御思いでしょうが、まだまだあります。
画面設計は、システムの使いやすさ、分かりやすさの肝ですよね。

さて、画面設計には、どんなパターンがあるでしょうか。

1)ポータル画面
2)マスタメンテナンス画面
3)一品一葉の伝票入力画面
4)明細型の伝票入力画面
5)検索から一覧照会画面
6)照会の個別画面
7)印刷やバッチ処理の指示画面

これらに分類されるのではないでしょうか。

この中で設計に一番頭を使うのは、1)の「ポータル画面」や、5)の「検索から一覧照会画面」ではないでしょうか。

なぜなら、部署や人によって、使い方が変わる可能性が高いからなのです。

例として「ポータル画面」を考えてみたいと思います。
「ポータル画面」とは、例えば、ログインしたら最初に表示されるページのことです。

メニューだけが並んでいるのはメニュー画面と呼びますので、「ポータル画面」とは違います。

もちろん「ポータル画面」には、メニューも含まれています。
ただし、一番最初に目につくのは、今日チェックしなければいけない掲示板、承認しなければいけない申請、本日のスケジュール、ToDoの期限だったりするものです。

そして、この「ポータル画面」に表示されるべき画面の部品というのは、実は「検索画面」と大きな関係を持つものです。

例えばToDoリストで明後日以前が締め切りのものを一覧で表示するとします。

社員別ToDo照会といった別の画面を想定してみると、検索条件は、どんな画面になるでしょうか。

・ToDoを登録した社員
・ToDoの期限
・登録日付
・重要度
・ToDoの分類
・未処理か処理済みか

と、ざっくり簡単に考えてみましょう。

もし、「ポータル画面」が無い場合には、この検索画面を呼び出して自分の社員コードを入力し、期限を明後日に指定して検索実行をすることになるのです。

「ポータル画面」では、指示する手間が省けてログインするや否や重要度順や締切日順で、未処理の案件が表示されます。

これは、毎日同じ処理をしなくても良いという点、検索画面で一人一人が検索条件を考える手間やミスが省けるという点で非常に意味のある画面になります。

そして、実際には、「ポータル画面」も「検索画面」も両方ともほぼ同一機能で実現できるのです。
ですから、「ポータル画面」用のデザインとテスト工程を追加するだけで済むのです。

もちろん「ポータル画面」を作らない場合には、検索画面に上記のような、一番よく使う検索条件を初期表示させるのです。

しかし「一番よく使う検索条件」は、部署や社員の仕事の内容によって変わることもあるのです。

結局は、個別対応を切り捨てて汎用的に作ることも多いのですが、画面設計は奥が深く、面白いものなのです。

次回は、汎用性と個別の設定をどうするかについて考えてみます。

今回はインターネットで一般消費者が情報を登録する
フォームについてのお話です。
ホームページ制作とセットになっていることが多いと思われるので、もはやこれは、システムと呼べるものではないのかもしれません。

フォームには個人情報を細かく登録するものや、中にはアンケートまで必須回答とするものも少なくありません。

こういったフォームを使っていると大体の形が決まっていることに気が付きます。

・郵便番号を入力したら住所の一部分が表示される。
・メールアドレスやパスワードは二重入力する。
・送信ボタンを押すとエラーチェックがされる。
・エラーメッセージは、画面の上部にまとめてわかりやすく表記される。
・確認画面から入力画面に戻ったときにも、
すでに入力した項目は、クリアされない。（パスワードは別）
といったお約束が、どのフォームにも共通で使われていると思います。

お約束が使われる理由として、1つ目は、入力する立場から見て「この方が便利」「この方がわかりやすい」といった総意なのかと思います。
2つ目は、誰もが良いと思うものをマネしていくためでしょう。
しかし、フォームの機能が落ち着いてきてしまったかと思う反面、進歩しているフォームもあるのです。

最近、「おっ」と思ったフォームは次のようなものでした。

入力する項目数が12～13項目と多かったのですが、入力した後で次に進もうとすると、エラーになってしまいました。

すると、OKとなった他の項目は表示されず、エラーになった1項目だけが画面に切り取られて表示されました。
この1項目を再入力してOKとなったわけですが、何かちょっといいなあ、という印象を持ちました。

再入力を促す場合に、文字で丁寧にメッセージを書いてもうっとうしい印象はどうしても拭い切れません。
理由は、入力する項目が表示されている画面に、エラー表示までもが追加されてあるからだと気付きました。

1つの画面を見たときに「人間が印象で理解できる大きさ」というものがあるのではないでしょうか。
1つの画面にありとあらゆる情報を詰め込んで表示しようと考えるのが常なのですが、人に入力を促すという視点から情報の見せ方を考えることも必要なのだと思いました。
画面の操作性といったものも「これで決まり」「これで十分」ということは無く、進化していくものなのです。

そして画面の操作性の進化とは「もっと良いものを作りたい」という気持ちがなければ出来ないことなのです。

明けましておめでとうございます。
すでに10日以上過ぎてしまいましたが、2009年初のメルマガとなります。
本年もよろしくお願い申し上げます。

多くの企業の方々からシステムのご相談を受けていると、「今あるシステムを直したい。拡張したい」という件をよく伺います。

そして、「現在使用しているシステムを作った会社がもう存在しない」「現在のシステムを作った会社と付き合いがない」会社が存在していても、「担当者が辞めたため、保守出来ないと言われた」というご相談が思いの外多いのです。

そこで、これから数回を「システムリフォーム」と題して、リフォームの視点からシステム開発を見直そうと思います。

これからシステム開発を依頼する方々も、システムのリフォームを行うときのことを考えて、知識として知っておくと良いかと思います。
システム開発に携わる方々には、非常に重要なテーマです。

現在システムを運用保守していらっしゃる方々に、何かヒントを掴んでいただくのも今回のテーマの狙いです。

また、このテーマを執筆することで、過去の経験や知識を整理して自分も何かを再発見してみたいという身勝手な考えもございます。

では早速ですが本題です。

システムをどこかの会社に依頼して作ってもらった、動いている、しかし修正や追加が出来ない。
どこの会社にどう頼んでいいのかわからない。
違う会社に頼んだら、とんでもない金額を請求された。

以上のような場合に、最低限必要なことは、以下の項目を確認することになります。

1)そのシステムが動く(動いている）オペレーティングシステム（OS）を確認する。

例:WindowsXP,WindowsServer2003,Linux など

2)プログラミング言語またはツールを確認する。

例:Java,VB,VB.NET,PHP,Perl など

3)データベース使用の有無とデータベース製品名を確認する。

例:使用無 テキストのみ、またはExcel など使用有 Oracle,SQLServer,MySQL など(出来れば細かくバージョンまで確認する。）

4)ミドルウエアと呼ばれる製品を使っているか、否か。使っていればその製品名とバージョンを確認する。

2)のプログラミング言語には2種類あります。
1つはソースがありコンパイルしてオブジェクトを作る形式のもの。
もう１つはインタプリタと呼ばれる、ソースがそのままで実行出来る形式のものです。

言語がコンパイル形式の場合、最新の（つまり、今動いているオブジェクトを作った）ソースがどこに保存されているのかということも非常に重要です。

ドキュメントがある、無いという前に、まず以上の情報をきちんと把握する必要があります。

そして、「2)プログラミング言語またはツールを確認する」がコンパイル形式の言語であり、ソースが無い、もしくは、どれが最新かわからないといった場合はシステムリフォーム出来る可能性は低くなってしまいます。

だからこそ、開発会社はソース管理をきちんとすることが、リフォームに向けての1番大事な仕事といえます。

最後にユーザーと開発者へ質問です。

ユーザーへの質問：開発会社任せではなく、きちんと1)から4)を書面で管理・保存していますか？

開発者への質問：ソースが現在のシステムにおける最新のものであると100%保証出来ますか？