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 化は必要だと思っている。以上