社内の受発注システムの刷新

2016 年 4 月
社内の受発注システムの刷新
2016 年 3 月で、ようやく社内の受発注システムの刷新に区切りがついた。2013 年 11 月
に着手し、足掛け 2 年半程度かかった。たぶん私にとって最後の刷新となるので、これま
での経緯と反省を記録に残したいと思う。
刷新のきっかけ
発行年月を 2 桁のコードにしたものを発注伝票番号の一部にしていたが、これが 2015 年
12 月で桁溢れを起こしてしまう。これをどう対処するかが課題だった。
この仕様を決めたのは私だが、まさかこんなに永く、この仕様で運用される（又はでき
る）とは思ってもいなかった。ソースコードはあるので、改修で対処するのが順当なのだ
が、事情（後記）があって、今回、全ソースコードを書き換えて刷新することにした。
当社の受発注システムの歴史とコンピュータ言語
[黎明期]
当社の受発注システムの歴史は結構古い。初期はシャープの
MZ-80B を使っていた。その後、NEC の PC98 になり、
N88BASIC での開発に移行した。しばらくして、パソコン（当
時はマイコンと言っていた）の世界でも、ネットワーク（LAN）
やファイル共有（サーバー）という考え方が広まりつつあった。
当時はまだ、
「パソコン vs オフコン」という構図があった。当
社は社内でシステム開発を行っていたこともあり、オフコンには
興味が薄かった。将来、パソコンの性能も上がるだろうし、ネッ
トワークやファイル共有で、なんとかオフコンの代わりになるの
ではないかと考えてオフコンは導入しなかった。今になってみれ
ば、この予想は正しかったといえる。
[DOS 時代]
その当時、事務処理システムを構築する上で、
迷っていたことは、開発言語を何にするかという
ことだった。一般的には BASIC だが、事務用言
語の COBOL も試してみた。が、どうもピンと来
ない。C は文字列の扱いがやっかいすぎて事務処
理には向かない。そこで目をつけたのが、dBASE という商品（言語）だった。データベー
スを核とし、言語仕様も充実しており、ファイル共有もできた。BASIC で作るより効率的
であり、当時としては、ベストな選択だったと思う。
[Windos 時代]
その後、Windows の時代となり、dBASE for
Windows 版も発売されたが、不安定すぎて使え
なかった。その後、何度かバージョンアップが繰
り返されたが、不安定さは、ついに解消しなかっ
た。その頃には、Visual Basic(VB)も使っていた
が、インストール作業や保守を考えると、社内プ
ログラムとしてつかうには少々難があった。そこ
で注目したのが、Boland の Delphi だった。言語
が Pascal 系という点に目をつぶれば、exe ファイル 1 つで起動する明快さが魅力的だった。
とりあえず Network でファイルサーバーを構築し、ファイル共有で試しに作成してみた
が、遅すぎて使い物にならない。いろいろ調べるとファイル共有では限界があり、クライ
アント・サーバー方式のというのがあるらしい。そこで MS SQL サーバーを立て、Delphi
でクライアン版を作成することにした。
[.NET 時代]
Microsoft が Java に対抗して.NET というスキ
ームを発表した。これに伴い、Delphi も.NET 版
が発売されるが、それまでの Delphi のコンポー
ネントと互換性がなく、プログラムを全面的に書
き換える必要があった。実務的にはあまり意味が
ないため見送っていたところ、開発元の Borland
自体が無くなってしまった。その頃には事務以外
のプログラムは C#を使い始めていた。構文の簡
潔さ、ライブラリの充実度、ネットでの情報の多さなどから、今回の刷新では C#で作成す
ることにした。
開発言語の選択で思うこと
ざっと 30 数年間を振り返ってきたが、言語の選択は難しい。習得にも時間がかかるし、
それぞれ向き不向きがある。実際、前記以外にもかじった言語はいくつもある。特にスク
リプト言語は、SED,AWK,Perl,Ruby,JavaScript,PowerShell などきりがない。AutoCAD
では LISP が使われているので、しかたがなく幾つか書いてみたりしたが、結局、特定の用
途にしかつかえない言語は習熟度を維持するのが難しいことを感じた。
20 年前、検査装置の制御ソフトは C++で書いていたし、一部をアセンブラにしたりして
いた。数年前も、Arduino 用のプログラム（ライブラリ）は C++で書いたが、まさか、ま
た C++を使うなどとは思ってもいなかった。Android では Java も使ったが、ビット演算が
なく驚いた。よく Java vs C#の記事があるが、個人的には、言語としては C#の方が上だと
思う。
言語には、目的を絞らない汎用言語（例：C++,C#,VB 等）と、目的に特化した専用言語(例：
dBASE)がある。専用言語の方が、すくないステートメントで記述できるので便利そうだが、
廃れも多くリスクが高い。少々不便でも、汎用言語で開発をしたほうが無難だと思う。
社内プログラムの刷新は、今回 3 回目で、すべて言語が違う。過去の言語選びで撰択に
誤りがあったかと問われれば、その当時としてベストな撰択だったと思う。スキームが変
われば、言語も刷新され、アプリも刷新せざるを得えなくなる。これは致し方無いことだ。
これまでの教訓としては…
1. 過去のアプリが動く間は、性急に刷新しないこと
2. スキーム（OS 等）の定着を見極めること
3. 新しい言語に飛びつかないこと
情報収拾をするのはかまわないが、大規模なアプリを刷新するかは慎重に見極める必要
がある。
刷新の一番の理由とは
結論から言うと、Delphi(Pascal)ではなく C#で改修をおこないたかったからだ。あれだ
け多くのプログラムを Delphi で書いたのに、しばらく使わなくなると、簡単な構文すら思
い出せなくなっていたのには自分でも驚いた（逆に、20 年ぶりに書いた C++は、C#ライク
のためか書けることに驚いたが…）
。
他にも
1. 変更に関連する箇所が数か所あり、あちこち修正が必要なこと
2. Mail 関連仕様が古い（SMTP 認証に未対応）
3. Xp 環境（Hyper-V）でしかデバッグできない（新 Delphi を買えば別だが）
等々、問題があり、この時期に一新しておかないと、どんどん状況が厳しくなると予想
されたからだ。
システム開発の基本指針
1. 必要なデータはすべて入力すること
紙を介さず PC の上だけで作業を進められるように設計しなければならない。昔は予算
の関係で業務の一部コンピュータ化などということもよくあった。こういう中途半端な
システムだと、主（メイン）データは PC か紙なのか？となった場合に、”紙が主”とい
う場合もよくある。こうなると、省力化どころか、重複作業と照合で無駄な事務が増え
る。
2. 中途段階で保存できること
必要事項がすべて埋まらないと保存出来ないシステムが結構多い。こうシステムでは、
保留の案件は紙の状態で止まっているものがでてきてしまう。未決定のデータでも、と
りあえずオンラインに保存できる仕様が不可欠だ。
3. リンク構造
昔のプログラムは、木構造にシステムが作られており、関連する作業でも、管理してい
る対象が違うと、一旦トップメニューに戻って、必要なメニューまで辿っていかざるを
えないという設計が多かった。こういうシステムは、関連する作業がシステム全体のど
こにあるのかを把握していないと、作業が滞ってしまう。
今回の刷新ではこの点を強化し、必要な作業はリンクさせて、トップページに戻ること
なく、1 つのプログラム内で完結することができるように設計した。
システムのハード構成の変遷とスキルの重要性
20 数年前に、現在の社屋に移転してから、システムは何度も変更している。当初は、
Ethernet（イエローケーブル）を、社屋全体に敷設し、サーバーは Netware を導入して、
ネットワーク環境を整えた。その後 SBS サーバーに変更し、現在は、SQL Server Express
で稼働させている。金額的には、当時、数百万円かかったものが、今では数万円で済むよ
うになった。中小企業の場合、処理能力的にはたいした量はないので、スキルさえあれば、
ほとんどお金をかけずにシステムを構築できてしまう。しかし知識やスキルのある人材が
いないので、自転車で済むところが、トラックを買う羽目になっている。この 20 年間でス
キルの有用性は、飛躍的に拡大したと言える。
新アプリへの切り替え手順
最終的に、新アプリはプログラム数で 23 個、データテ
ーブルが 20 個になった。基幹プログラムの入れ替えとい
うのは、普通の人が思っている以上に、やっかいな作業
だ。今回、データベースはそのままで、アプリだけの入
れ替えだったため、徐々に移行を行うことにした。マス
ター関係の単純なプログラムから C#版を作成し、徐々に
プログラムを置き換えていった。プログラムがすべて置き換わった時点で、データベース
の整理を行い完了した。
実はデータベースの整理が意外にてこずった。一箇所変えると、影響があちこちに発生
する。うんざりしたのでデータベースとアプリ全体のビルド管理をおこなうための保守用
プログラムを作成した。このプログラムのおかげで、対処が格段にはやくなった。
旧ソースコードが必要か？
今回のアップグレードでは、元のソースコード（Delphi）は、ほとんど参照しなかった。
もう随分、構文を忘れてしまっていたというのが主な理由なのだが、C 言語ライクの構文に
慣れていると、Delphi にしろ、BASIC にしろ、脳内で syntax error が出まくるので、つ
らいというのが本音だ（しばらくすると慣れるが）
結論からいえば、基本的にソースコードは不要だとおもう。構文が同じでコピペできる
ようなケースでないかぎり、1 から作りなおした方が早いと思う。自身で作成したプログラ
ムですらこんな状態なのに、他人が作ったコードならなおさら参照しないと思う。
各 PC のプログラムを簡単に更新するには？
.NET のプログラムは、インストールなしで起動できるのが魅力だが、各 PC のアップグ
レードのしかたが問題だ。ClickOnce を使えば簡単なのだが、最初にインストール作業が必
要になるし、毎回、アップグレードの確認処理があるので起動が遅くなる。
サーバーにアプリをおいて起動させる方法もあるが、1 つの PC で 2 重起動ができなくな
る。また、誰かが起動していると、アップグレード版の保存ができない。
こういう問題に直面すると、Web アプリが羨ましくなるが、Web アプリは思ったことが
自由にできないのでどうも好きになれない。
最終的に、サーバーとローカルに両方にプログラムを置き、起動時に、サーバーに更新
されたプログラムがあれば、ローカルにコピーしてから起動するようにした。同一 PC 内な
ので、プロセス間メッセージ通信を利用した。こういうしくみが.NET 環境内で準備されて
いるのはありがたい。汎用言語ならではのメリットといえる。
これで、サーバーにアップグレードプログラムをコピーしておきさえすれば、各 PC で最
新バージョンが起動できるシステムになった。
メール送信の問題を克服
各プログラムでは、必要な時に自動的にメールが送
信されるしくみになっている。が、このメール送信で
時々トラブルが発生した。原因は送信メールサーバー
に起因するものだが、メールの送信が完了しないと、
一連の処理が滞ってしまう。メールサーバーを変える
ことも考えたが、100％トラブルがなくなるとは限らな
い（インターネット接続自体のトラブルもありうる）。
社内にメールサーバーを立てることも考えたが、そ
れはそれで面倒が増える。そこで考えたのが、社内のサーバーで、メール転送サーバーも
どきを動かす発想だ。しくみはこうだ。
1.
社内サーバーにメール・デーモン・サービスプログラム（自作）を動かす
2.
メールは送信せずに、送信内容をデータベースに保存し、メール・デーモンに対して
送信依頼を出す。すべて社内のサーバーなので、一瞬で処理は完了する。
3.
メール・デーモン・サービスは、送信依頼によりデータベースから送信内容を読み込
み、メールサーバーへ送信する。
4.
インターネット接続不可、メールサーバー不調の場合があるので、5 分おきに、未送
信のメールメッセージの再送信を試みる。
刷新の成果
今回は以前のシステムの焼き直しのため、実務上は、あまり大きな変化はない。しかし
プログラムの作成スキルとしては、多くのノウハウの蓄積ができた。
得た手法はエバーノートに逐次記録した。汎用性のあるものは、ライブラリ(dll)化して、
すでに他のアプリでも利用している。DB 保守に関しても、制約条件を張りめぐらせてデー
タが腐らないようにした。T-SQL でいくつかの保守用のバッチを作成した。SQL サーバー
へのスキルが向上して、保守が楽になった。
中小企業の IT 化で思うこと
今回の基幹システム刷新を、外注した場合、たぶん 800～1000 万円らいかかるのではな
いかと思う。大企業と比べ中小企業はでは、作業種類はそれほど変わらないが、扱うデー
タが少ない。だから中小企業の IT 化は費用対効果が悪い。極端に言えばやらない方がいい
くらいだ。
当社が、IT 化を行うのは、社内でできるからということもあるが、事務処理の品質を一
定水準に保ちたいからだ。中小企業の場合、一人が多種の事務処理をしているので、その
人の能力にだけ頼っていると、携わる人によって結果が大きくぶれてしまう。しかし IT を
介しておくと、入力だけきちんとしておけば、誰がやっても同じ結果が得られる。したが
って私は中小企業にも IT 化は必要だと思っている。
以上

Download Report