2016年3月で、ようやく社内の受発注システムの刷新に区切りがついた。2013年11月に着手し、足掛け2年半かかった。たぶん私にとって最後の刷新となるので、これまでの経緯と反省を記録に残したいと思う。
刷新のきっかけ
発行年月を2桁のコードにしたものを発注伝票番号の一部にしていたが、これが2015年12月で桁溢れを起こしてしまう。これをどう対処するかが課題だった。
この仕様を決めたのは私だが、まさかこんなに永く、この仕様で運用される（又はできる）とは思ってもいなかった。ソースコードはあるので、改修で対処するのが順当なのだが、事情（後記）があって、今回、全ソースコードを書き換えて刷新することにした。
当社の受発注システムの歴史とコンピュータ言語
[黎明期]
当社の受発注システムの歴史は結構古い。初期はシャープのMZ-80K,Bを使っていた。その後、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回目で、すべて言語が違う。過去の言語選びで撰択に誤りがあったかと問われれば、その当時としてベストな撰択だったと思う。スキームが変われば、言語も刷新され、アプリも刷新せざるを得えなくなる。これは致し方無いことだ。これまでの教訓としては…
- 過去のアプリが動く間は、性急に刷新しないこと
- スキーム（OS等）の定着を見極めること
- 新しい言語に飛びつかないこと
情報収拾をするのはかまわないが、大規模なアプリを刷新するかは慎重に見極める必要がある。
刷新の一番の理由とは
結論から言うと、Delphi(Pascal)ではなくC#で改修をおこないたかったからだ。あれだけ多くのプログラムをDelphiで書いたのに、しばらく使わなくなると、簡単な構文すら思い出せなくなっていたのには自分でも驚いた（逆に、20年ぶりに書いたC++は、C#ライクのためか書けることに驚いたが…）。
他にも
- 変更に関連する箇所が数か所あり、あちこち修正が必要なこと
- Mail関連仕様が古い（SMTP認証に未対応）
- Xp環境（Hyper-V）でしかデバッグできない（新Delphiを買えば別だが）
等々、問題があり、この時期に一新しておかないと、どんどん状況が厳しくなると予想されたからだ。
システム開発の基本指針
- 必要なデータはすべて入力すること紙を介さずPCの上だけで作業を進められるように設計しなければならない。昔は予算の関係で業務の一部コンピュータ化などということもよくあった。こういう中途半端なシステムだと、主（メイン）データはPCか紙なのか？となった場合に、"紙が主"という場合もよくある。こうなると、省力化どころか、重複作業と照合で無駄な事務が増える。
- 中途段階で保存できること必要事項がすべて埋まらないと保存出来ないシステムが結構多い。こうシステムでは、保留の案件は紙の状態で止まっているものがでてきてしまう。未決定のデータでも、とりあえずオンラインに保存できる仕様が不可欠だ。
- リンク構造昔のプログラムは、木構造にシステムが作られており、関連する作業でも、管理している対象が違うと、一旦トップメニューに戻って、必要なメニューまで辿っていかざるをえないという設計が多かった。こういうシステムは、関連する作業がシステム全体のどこにあるのかを把握していないと、作業が滞ってしまう。今回の刷新ではこの点を強化し、必要な作業はリンクさせて、トップページに戻ることなく、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％トラブルがなくなるとは限らない（インターネット接続自体のトラブルもありうる）。
社内にメールサーバーを立てることも考えたが、それはそれで面倒が増える。そこで考えたのが、社内のサーバーで、メール転送サーバーもどきを動かす発想だ。しくみはこうだ。
- 社内サーバーにメール・デーモン・サービスプログラム（自作）を動かす
- メールは送信せずに、送信内容をデータベースに保存し、メール・デーモンに対して送信依頼を出す。すべて社内のサーバーなので、一瞬で処理は完了する。
- メール・デーモン・サービスは、送信依頼によりデータベースから送信内容を読み込み、メールサーバーへ送信する。
- インターネット接続不可、メールサーバー不調の場合があるので、5分おきに、未送信のメールメッセージの再送信を試みる。
刷新の成果
今回は以前のシステムの焼き直しのため、実務上は、あまり大きな変化はない。しかしプログラムの作成スキルとしては、多くのノウハウの蓄積ができた。
得た手法はエバーノートに逐次記録した。汎用性のあるものは、ライブラリ(dll)化して、すでに他のアプリでも利用している。DB保守に関しても、制約条件を張りめぐらせてデータが腐らないようにした。T-SQLでいくつかの保守用のバッチを作成した。SQLサーバーへのスキルが向上して、保守が楽になった。
中小企業のIT化で思うこと
今回の基幹システム刷新を、外注した場合、たぶん800～1000万円らいかかるのではないかと思う。大企業と比べ中小企業はでは、作業種類はそれほど変わらないが、扱うデータ量が少ない。だから中小企業のIT化は費用対効果が悪い。極端に言えばやらない方がいいくらいだ。
当社が、IT化を行うのは、社内でできるからということもあるが、事務処理の品質を一定水準に保ちたいからだ。中小企業の場合、一人が多種の事務処理をしているので、その人の能力にだけ頼っていると、携わる人によって結果が大きくぶれてしまう。しかしITを介しておくと、入力だけきちんとしておけば、誰がやっても同じ結果が得られる。したがって私は中小企業にもIT化は必要だと思っている。
以上