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

前回からですが、「番号・コード」シリーズに突入しています。

「毎週、何を書こうかと大変でしょう」と言われることが多いのですが、さすがに150回を超えている理由は、「悩まず書く」、これに尽きます。

ひょっとしたら何度か同じことを書いているかもしれませんが、きっとそれは、特別重要なことか、杉山がボケているかのどちらかなのでお許し下さい。

飲むと忘却度が各段に上がる杉山ですが、このメルマガを書いているときは常に素面（しらふ）です。

さて、今回は「伝票番号」もしくは「連番」といったものについて考えてみたいと思います。

データベースには「IDENTITY」という自動連番機能もありますが、これを実際に使うことはあまり無いのではと、私の経験から思います。

「ワークテーブル」と呼んでいる、何か処理する度に削除して作り直すというタイプのテーブルでは使うべきだと思うのですが、マスタやジャーナルといった、何年にも渡って存在するテーブルの項目に使うのは、開発テスト時や保守の事などを考えると、あまりお勧めできません。

伝票番号を画面から手入力するという場合はもちろん、システム機能として伝票番号を付加する必要はありません。

画面から手入力する場合というのは、番号がプレプリントされた伝票を使う場合ですね。

例えば、宅配の伝票番号や、チェーンストア統一伝票番号などです。

もちろん自社伝票を使って先にナンバリングしてあるところもあります。

一般には、伝票番号は自動でシステムから付ける場合が多いのではないでしょうか。

また、「伝票番号」というような運用の形態が無いとしても、入力した画面の登録処理ごとに連番を付けるのは常でしょう。

連番の取得方法として、だいたい以下の2つの処理に分けられます。

1) 売上伝票であれば、売上伝票ジャーナルの伝票番号の最大値をもってきて、それに1を加えて番号を獲得する

2) 伝票番号テーブルといったものを作っておいて、最終番号はテーブルに更新されているので、その番号に1を加えてから番号を獲得する

これら2つのうち、小さなシステムでデータも大容量でない場合は1)でも良いのですが、私は常に、2)を採用します。

これに関して言うと、1)を使っていたシステムではレスポンスに関する問題が起きることがあるのですが、2)で問題が起きるのは、排他処理の問題くらいです。

もちろん、SEとプログラマがどのようにリスクを考えるかで変わってきます。

データベースや言語といった開発環境のクセ、組み方、お客さまの運用を理解して吟味している場合には、どちらでも良いのかもしれません。

ただ、2)を選択していたことでラッキーだったことはいくつかあります。

例えば、現状で「357688番」まで番号が進んでいるシステムを新システムに移行する場合、新システム番号は、「1000001番」から採番するといったことが簡単に実現できます。

この場合、新システムで新規に登録した伝票と移行された伝票とが、一目で確認できるといったメリットがあります。

また、この伝票番号取得の部分は、各エントリでそれぞれコーディングされるのではなく、ストアドプロシージャとして共通に用意され、使われることが望ましいでしょう。

「頭に年度を付けた伝票番号」といった場合も同様に、伝票番号テーブルの主キーに年度を含むだけで同じ処理を行います。

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

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

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

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

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

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

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

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

そこで、あなたは、

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

と言うこともできますが、もし、エラーメッセージが“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が新しい部署で登録されていれば問題無いのですが、登録すべき総務部が忙しさにかまけて登録し忘れていた、などといった場合、エントリでエラーが出てしまいます。

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

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

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