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

データベースの設計をするタイミングは、基本設計書が出来上がってから、と信じ込んでいる若いSEは多いようです。

実際に、システムの全体スケジュールでは、納品は、基本設計書と同じタイミングですしね。

しかし、打ち合わせの途中でも、頭の中に「データモデリング」のイメージは出来上がっており、大体このような設計になるんだろうなぁ、とどのSEも思っているようです。
そして、驚くべきことに、SE同士で話してみれば、このデータベースの設計は、ほとんど一致します。

これには、システム設計の基本パターンというものが存在するからというのが一つの大きな理由でしょう。

詳細なER図を書くまでもなく、テーブル（エンティティ）の名前や、そのエンティティに、どんな項目が登録されるかは、80％以上決まっているのです。

ソフトウェア工学で言えば、エンティティには2つの種類があります。
「マスタ」と「ジャーナル」です。

マスタとは、Master（主人）からきています。
システムを支える情報であり、頻繁に値が変わらないものがマスタとなります。
「社員マスタ」、「得意先マスタ」、「商品マスタ」といったものです。

ジャーナルは、Journal（日記、日誌）の意味で、日々の情報を記録するものです。
「売上ファイル」、「仕入ファイル」、「出勤ファイル」といったものです。
ジャーナルは、昔はトランザクションとも呼ばれていました。

トランザクションは、Transaction（処理、取引)であり、ジャーナルと同じように、日々の取引ファイルを意味していました。（COBOLの索引ファイルでシステムを作っていた頃）

ところが、現在ではRDBを使ったシステムがほとんどで、RDBMSのトランザクション処理と混乱しないように、私はジャーナルと言っています。

実際には、さらに細かく分けて、マスタに3つ、ジャーナルに3つ、種類があると思っています。
一般的な「販売管理　売上・仕入から請求まで」を例に挙げてみます。

●マスタの分類

1)業務で使用するメインマスタ

・社員
・役職
・営業所

この考え方は、どのシステム開発会社でも同じだと思います。

2)常に、どんなシステムにも（システム的理由で）存在するマスタ

・管理
そのシステム全体で、使用する値が1つである場合に、このマスタにセットする。プログラムのConfigと違い、マスタの値を変更するだけで、プログラムに何の影響もなく、システム全体の振る舞いを変えることができる。

例：現在の期、期首、期末日、会社名、代表者名、住所……、消費税率とその期間

・名称
RDBといえども、コードと名前さえあればいい、といったものが多い場合に、1つのテーブル上で、共有して設定しておく。本来のRDB設計の観点からいえば邪道かもしれないが、便利なことが多く、弊害は、ほぼない。

・メニュー
・プログラム名
・メッセージ

3)業務独自でシステム的に必要なマスタ

・帳票定義
・権限
・運用管理
・カレンダー

●ジャーナルの分類

1)業務で使用する主ジャーナル

画面入力、外部連動で最初に作られるジャーナル

・売上
・売上明細
・仕入
・在庫移動

2)システムの難易度を下げるためのジャーナル

・帳票のための駆動表
・月次などの印刷のレスポンスを上げ、過去照会を容易にするための実績集計

3)システムのログを取るためのジャーナル（また、システム的なバグを見える化するために使用する）

・バッチの中間ワーク
・バッチログ
・操作ログ

マスタ、ジャーナル共に 1）は、どのシステム開発会社でも、どのSEでも、考える基本のものとなります。
つまりこれがデータべースの基本です。
しかし、優れたSEは、自分の設計に 2) や 3)も当たり前のように基本パターンを持っているものです。

内容や考え方は、システム会社によって、そしてSEによって、様々なものがあるはずです。
特にジャーナルの 2)システムの難易度を下げるためのジャーナルは、若いSEには思いつかないものが多いはずです。

他の会社でも、同じ会社内でも、他人が設計したシステムでこういうものを見つけたときに「なぜ、何のために、このようなジャーナルを設計しているのか」を考え、真似することをお勧めします。

優れたSEの作るシステムは、データベース設計にそのヒントが隠されているのです。

RDBを使うシステム開発においては、レスポンス（応答時間）がかかることも、障害の一つにあげられます。

画面では、3秒ルールというものがよく言われていますが、どんな機能においても、3秒以内の応答を確保できるという保証はありません。

基本設計時には、どういう処理がどのくらい時間が掛かるかをSEが知っていて、お客さまに、その時間で許されることなのかを確認する作業が必要になります。

もちろん、ハードウエアの選択、ネットワーク、同時使用人数など、さまざまな条件において、レスポンスは変わってきてしまうわけですから、何を標準としてレスポンスを計るかの前提条件も重要になります。

実際、わたしなどは短気ですので、社内テストにおいても、画面の操作で、ボタンを押してから数秒間何も表示されない状態は、本当に嫌いなのです。
（そういう意味では、人よりも許せる範囲が少ないので、SEに向いているともいえるでしょう）

ましてや、操作しても応答までに数秒ではなくて10秒、ひいては1分もかかるということであれば、後から「何とか速くならないか」というクレームが入るのも、当たり前のことなのです。

こういった場合、後からSQL文を直すということで対処することが多いのですが、実際のところは、詳細設計中やその前のデータベース設計時、そしてその前の基本設計時に、レスポンスについてどれだけ考慮して打ち合わせしているか、設計しているかで、ほぼ決まってくる話なのです。

レスポンスについては、オラクル社やMicrosoft社の、DB製品に特化したチューニングの書籍に任せたいと思っています。
私は、これらの本を読むことで、さまざまな示唆やアイデアを得ることができました。

さて、今回、敢えて確認したいことは、プログラム単体のレスポンスではなく、データコンバートや、移行、テスト環境の構築といったものについての作業時間の話です。

日々のバッチや締めのバッチもそうですが、こういった処理は、決められた時間内に作業が終わることが、必須である処理なのです。

例えば、お客様が使用していない深夜0時から朝9時までに行う、などです。

こういう処理の予測時間を想定しないで実行することはあり得ません。
必ず、どの順番でどの処理を行い、どのくらい掛かるかを、シュミレーションして行うことが必要です。

そして、10時間余裕があるとしたら、リスクバッファと終了後のチェックを含めて、半分の5時間が最大使用時間だと思っています。

また、最初に必ず「バックアップ」を行い、どの段階で処理を中断しても、「元の状態に戻せる」、つまり、最低でも、作業を始めるときと同じ状態に戻せることが、最重要です。

1,000万件の処理を行う場合、可能であれば、テスト環境で、同じ件数でどのくらい時間が掛かるのかを、全て網羅してシュミレーションしておくことが必要です。

RDBの場合、処理によって件数が多くなればなるほど、遅くなるものが一般的です。
100件と1,000件と比べて10倍、10,000件は100倍といかないのです。

インデックスを付けて処理を行なうのか、削除して行うのか。
どんなデータを確認して、正常処理が行なわれたと判断すべきなのか。

処理の前にシュミレーションを行い、準備しておくことは、ここでも重要なのです。

そしてもちろん、どのような環境下において、どんな処理が、何時間掛かったのかを記録し報告することは、他の仕事にも役立つことなのです。

新卒採用の説明会で、必ずと言っていいほど出る質問があります。

「私は文系なんですが、ついていけるでしょうか？」

実際のところ、私自身が文系なので、「何の問題もありません」と答えることが多いのです。

しかし、文系としてこの業界に入って、SEになり、悩むことが何もなかったわけではありません。

まず、自分自身の「論理的な思考」というところで、一番悩みました。

どうすれば、論理的な思考ができるのか？

一つには、自分が女性であるという、ジェンダーの悩みがありました。
何かを判断するときに必ず、「好き」「嫌い」といった感情が出てしまうのです。

それも「なんとなく」、つまり理由もなく、その日の、その瞬間の気分次第ということがあるのです。

そんな私でも、プログラミングやシステム設計を何十年も（!!）続けてくることができたのは、何故でしょうか。

採用説明会では、何度も話したのですが、紙に書くことから、プログラミングを始めたことが、論理思考を育むのに、大きかったと思うのです。

紙に書いて、何度でも読み直す。

これが、作ってしまったプログラムを、違う視点で見直す力を作ってくれました。

コンパイルするよりも、動かすよりも何よりも、ソースを読むことが生産力アップの最短距離であることを理解したのです。

そして、プログラミングで身に付いた知恵は、システム設計でも役に立てることができました。

システム設計を始めた頃は、プログラマとしての感性が勝ってしまい、細かなことばかりを気にしてしまって、全体を見通す力にどうしても欠けていました。

30本から40本くらいの小さなシステム構築だったので、なんとかやっていたのだと思うのですが、システムテストの最後の最後になって、重大なデータの抜けに気が付くこともありました。

そんなときに、他社のエンジニアが書いたプロセスフローに出会ったのです。

実際はなんと呼ぶのかはわかりませんが、私はプロセスフローとか、システムフロー図と呼んでいます。

一つ一つのプログラムを、別の紙に描き表すのではなく、1枚の紙に描くのです。

そこでは、各プログラムが作り出すデータ（実際にはテーブルとして描きます）と参照するデータを細かく描いていきます。

1枚と言っても、A3横の紙に書くと1枚に20本くらいの機能しか描き切れませんので、実際には何枚にも渡ってしまいます。

それでも、サブシステム単位に区切れば、1枚に描くことは可能です。

ポイントは、全てを描き切るということです。これに尽きます。
とにかくシステムの全部を考える。

若手エンジニアには、この作業を打ち合わせの途中から始めることをお勧めします。
大きな全体図を見て、その中の部分としての機能を考える。
この視点が、実は一番大事なことなのです。

細かな操作性、凝った造りに終始してしまい、大事なことが抜けてしまう若手を何人も見てきました。

全体を見る。

その為に、設計前に必ず、プロセスフロー図を完成させる。

文系の女性エンジニアでも、私が、システム設計をやってくることができたポイントは、これに尽きます。

全体の重みを知れば、お客様の細かな要望に対応すべきか、すべきでないかも判断できるはずです。

デジタルで文書を作成するのが常識になり、メールで即時納品も出来る世の中になりました。

しかし、それでも印刷したドキュメントは、必要なものです。

例えば、要件分析や基本設計のときに、ブレーンストーミングしたりする場合を除いては、顧客側も開発側も、互いに相手に説明するための資料（ドキュメント）を用意して会議に臨みます。

このドキュメントが、やがて要件定義書や基本設計書になるわけですが、ドキュメントの作成必須条件とは何でしょうか。

当たり前すぎるほど当たり前のことが幾つかあるのですが、どうも、「雛形」や「テンプレート」でドキュメントを作ることしか知らない人達には、必須事項として理解されていないことがあるようです。

1）どんな目的の資料かをはっきりさせ、意味なく余分な説明を入れない。

親切心から記入したとしても、その文章や説明が、逆に主な目的を曖昧にしてしまったりするのです。
複数の目的を兼ねた資料というのはマトリックスの表を除いては、むしろ良くないと思っています。

2）どんな場面で使われるのかを想定して作成する。

これに関しては、後で詳しく述べたいと思います。

3)タイトル、作成日付（更新日付）、ページ数・全ページ数をつける。

こんなことも知らない人がいるのか？とお思いでしょうか。
いえいえ、かなりいます。
一度、「雛型」無しで説明書きや報告書を作成されてみたらいかがでしょうか。

4）A4横または、A3横に統一する。

もちろんA4縦であっても良いとは思います。
要は印刷して閉じたときに、同じスタイルにできるように心がけるということです。
B4サイズの用紙は不適です。

5）図解やイラストを用いて一目で理解できたり、補足できるようにする。

6）1つの記号を複数の意味に使わない。

記号を使った図を描く場合には、丸やひし形、二重線で囲まれた四角などの意味を明確にするべきです。
さらに、記号の判例をつけなくてはなりません。

7）同じ注意書きをいたるところに書かない。

コピー＆ペーストはミスの元凶です。
複数個所に書かないで、符号化して一か所にまとめて、統一的に扱いましょう。

8）とにかく記号・番号をつける。

年月日だけでなく、文書番号、段落番号、項番といったものを付けて、分類することで、一意のものとして特定できるように心がけましょう。
できれば、大→中→小→詳細といった場合に、その親の分類がわかるようなつけ方が望ましいものです。
例：
大分類　1. 2. 3. 4.
中分類　1-1. 1-2. 2-1. 2-2
小分類　1-1-1. 1-2-1. 2-1-2
※数字はこの分類だけにして、他の図や説明には、「a b c d」「(1)(2)(3)(4)」といったように、違う意味で同じ数字（記号）を使わないようにする、といったことも考えます。

他にも、フォントを揃える、フォントを9ポイント未満の大きさにしない、印刷物のパンチ穴を意識して余白を作る、ホッチキスで留める位置は左斜め上とする、…等々、細かいことを言い出したらきりがありません。

しかし、ルールを部下や他の人に徹底させることも重要ですが、何より、そのルールは、どういう理由で(Why)そうなっているのかを考えさせて、納得した理解をさせることが最重要だと思っています。

2）で挙げたように、その文書が「会議で資料として使われるもの」なのか、「最終確認用で配る」ものなのかによって、記入しなければいけない内容の精密さが変わってくるのです。

もし会議で資料として使われるものであれば、口頭で説明して頭にすっと入ってくるものについて、いちいち文章で書いてはいけません。

会議資料をたとえ前日に配っておいたとしても、会議の時間になるまで資料を読まない人は多いものなのです。

その場で字を読むことに集中したら、会議の意味は薄れてしまいます。

だから、会議で使う資料は、図や簡単な分類だけにとどめ、各自が同じ資料の同じ場所を見ていることを確認し、それぞれの顔を見て理解度を測りながら、口頭で説明することが望ましいのです。
そういった意味でページ数の表記や章番号は絶対必要なのです。

会議の出席者全員に、「自分の頭で考えて理解させる」そのための資料であるべきなのです。

時々、プレゼンテーション資料や会議資料に文章をツラツラと書き綴り、そのまま読み通す人がいます。

この場合、判を押したように、声は小さく早口になっています。

文章を読みあげるというスタイルで、出席者全員が理解し、納得することは無いということを知るべきです。

ただし、会議で使った資料を最終確認資料とする場合には、参加者の共通理解のある用語を使った文章で、確認に至った流れに沿ってまとめることが必要になります。

とにかく、どんなドキュメントにも、「目的」や「使用する場」があるのです。

読み手を意識したドキュメントを、ルールを守って応用的に作ることができてこそ、真のSEなのです。