【社長日記】20年ぶりのリニューアル

今日のネタは、去年の話なのですが、お客さんのシステムを20年ぶりにリニューアルしたというお話です。

2003年に私が自分で設計してプログラムも書いたとあるシステムがございまして、昨年まで動いていたのですが、昨年2023年に20年の時を経てリプレースされたのです。生まれた赤ちゃんも立派に大人になる年月です。その20年ぶりの新システム導入イベントも無事に完了しました。その実情も含めて、システムを超長期稼働して感じたことなどをまとめてみたいと思います。


【背景】
当件のユーザーは市内に10店舗ほどの自転車店を展開している会社さんです。広島では自転車でお世話になっている人もきっと多いあのお店です。自転車というのは、何万車種もあるわけではないし、モノがわりと大きいので点数も大きくはありません。システム導入以前は紙と鉛筆で帳簿を付けていました。店舗に在庫がない場合は他の店舗に電話で在庫を確認しトラックで運ぶのですが、記入漏れなどもありますので、年に１度の棚卸が大変という状況でした。どこかのお店に古い在庫が残っているとしても、その情報をすぐに見ることもできません。店舗が増えるごとに問題が増えますので、システムが必要になったという経緯です。

2003年ごろはいわゆるクラサバアプリの時代でした。Visual Basicで作ったクライアントアプリをODBCでデータベースサーバーと連携したアプリが典型的なパターンのクラサバアプリでした。クライアント-サーバモデルで社内LANで動かすものです。複数拠点で利用する場合は当時まだそこそこコストのかかるVPNを通していました。

当時もパッケージ化された在庫管理アプリケーションはありましたが、複数ロケーションの在庫を管理できるアプリケーションは高額なものでした。かつ高機能なのですが、当件では求められていない機能がほとんどでした。それで機能は多いものの入力項目は多く画面は複雑で、現場で在庫を管理しているのは自転車の技術者にとっては難しいと考えました。

【2003年に導入したシステム】
結局スクラッチで開発することになったのですがブラウザを使うWEBアプリにはしませんでした。今でこそ当たり前のWEBアプリが業務アプリにおいて人気がなかったのは、クラサバのアプリに比べ操作性が悪かったからでした。通信速度が早くないのに全画面をリロードしながら動くアプリケーションは使い勝手に問題があります。現在ではajaxで非同期な通信を使うので使い勝手は改善可能ですが当時は限界がありました。かといってクラサバアプリも社屋でサーバを管理したり、全拠点にVPNを引くなどの運用負荷があります。

そこで当社は当時RIA(Rich Internet Apprication)と呼ばれ、その後、そこそこ流行する仕組を採用しました。RIAといえばFlashとActionScriptの組み合わせが多いのですが、その流行より少し前の時代でしたので、Java WEB Startという仕組みとSwingで作りました。SwingならばサーバもクライアントもJAVAで作れます。思い出話になってしまいますがJBuilderという統合環境が良くできていまして、Swing側もサーバサイドも一度に開発していました。とにかくJBuilderを始めBorland社のツールはいずれもすばらしくて、私はファンでした。


（当時のJAVA WEB START起動画面。マニュアルに貼ってあった画像だけど今となっては画素数が小さすぎる）

【20年の間に】
使い勝手はそのものは良かったのでお客様には好評でしたが、20年間には保守の面でどんどん問題が発生しました。

まず、J2SE1.4の時代から2014年のJava8くらいまでですが、Javaのバージョンは1.4→5→6→7→8と変わり、SUNからOralceになり、そのたびに互換性の心配をしましたが、Javaの後方互換性は素晴らしく、基本部分はほとんどそのままで稼働し続けました。それ以降はJavaの有償化やJava11ではそもそものJava WEB Startが廃止になってしまい、バージョンアップせずに運用せざるを得ませんでした。2015年ごろからはリプレースの検討を進めてはいましたが、機能的に満足ということもあり話は進みませんでした。

その他にも、Java WEB StartはJavaのモジュールをダウンロードしてクライアントで動かす仕組みなので、出所が怪しいものを動作させるわけにはいきません。それでコードサイニングがほぼ必須になり、それ以降は毎年証明書を買ってモジュールを作り直す必要がありました。

サーバは当初、当社の社屋にサーバルームを設けてそのラックの中に置いていましたが、預かるサーバが多くなったためデータセンターのラックに移しました。この物理サーバの時代には壊れたディスクを交換したり、UPS（無停電電源装置）のバッテリーを交換したりなどの物理インフラのメンテナンスが必要でした。AWSのTOKYOリージョンができてしばらくして、データセンターのサーバはすべてAWSに載せ替えてデータセンターからは撤収しました。

このような歴史がありまして、機能的には満足であっても、サーバやミドルウェアのライフサイクルに合わせて保守作業が随時必要とされました。

並行して、当社の技術的な方針も変わっていきました。2003年ごろは全言語対応で何でもやっていたのですが、言語や業務分野を絞っていかないと長期的にお客様の役に立つノウハウを身につけることが難しいと考えて、サーバサイドチームは業務はEC、言語はPHPに寄せていきました。結果として現在はJavaを使うことは激減しています。この20年ものシステムをメンテナンスしていたのは、20年もの間、当社で頑張ってくれているエンジニアがいるという幸運のおかげでした。


【リプレースにあたって】

長期稼働を通して、さまざまな外部環境への対応と、そのような対応をするためのサーバOSやミドルウェア等のバージョンアップなどの対応をコストとして考える必要があるということを痛感しました。

そのようなコストを低減するためには、たった１社のためだけに作ったスクラッチのアプリケーションは不利です。100社が使っているソフトウェアはバージョンアップのコストを100社で分割することができます。そういう意味では、利用者数が多く、継続の実績も長く、堅実な会社が運営しているサービスを利用するのが経済的にはベストだと思います。

そのような一般的なアプリケーションをカスタマイズ無しで利用できればそれが望ましのですが、カスタマイズが必要であれば費用が高額になるか、そもそもカスタマイズは出来ないケースも多いです。

今回ももちろんSaaSや有名どころのパッケージも検討したのですが、いわゆる販売管理と仕入管理とセットの在庫管理だと、ほとんどの機能を使わないのでフィットしそうにありませんでした。

在庫の場所をシンプルに管理したいというのであれば、ノーコード系でも行けるのではないかとも考えました。こちらもスクラッチにくらべればサーバやOSやミドルへの対応を自前で実施する必要がないという点が有利です。そういうわけで検討はしましたが、やや頑張って作らないといけないものになりそうなうえに、ユーザーが望んでいるモノそのものにはなりそうにないです。

これは私見ですが、ノーコード系は、長期安定稼働を目指すようなものには使いにくいなと思ってます。そもそもサービスの名前すら変わります。ユーザー向けにマニュアルを書いてもベースの部分が変わってしまいます。

結局、避けたいと思っていたスクラッチで開発することにしました。
今回はJavaではなくPHPを採用しフレームワークはSymfowareとしました。チームがEC-CUBEとDrupalをメインとしており、その2つは両方ともSymfowareベースなのです。EC-CUBEとDrupalは長期的にサポートできるチームを作ってきましたので、Symfowareであればチームでサポートを長期継続が可能だと考えました。とはいえ20年は難しそうだなと思っています。そういう長期と考えるとやはりJavaは優れていたと思います。

仕様については、今回はなるべく前回踏襲としました。
手前味噌になってしまいますが、前回、私が書いた仕様書が残っていたのですが今読んでも分かりやすかったです。仕様そのもの相当にシンプルですが書き方もシンプルです。メンテナンスに必要最低限という方針で書かれていたので読みやすかったのです。RIAアプリからWEBアプリに変更するといっても、仕様書ががほとんどそのまま利用できました。画面構成なども含めてなるべく現行に合わせたのでユーザーにとっても新システム導入による学習コストが小さくて済んだと思います。


【まとめ】

当件のようにソフトウェアも20年稼働させることは可能かといえば、一応は可能ということになると思います。自分でも「すごい」と私は思うのですが、世の中には20年もののアプリって、案外あるのではないでしょうか。動いていてもOSやミドルはサポート切れというケースが多いと思います。Windows7で動かしているけれど、そのPCが壊れたら終わり、といった状態で辛うじて稼働しているようなシステムもありますね。

ユーザーの方には、できれば保守担当会社と定期的にコミュニケーションを取って、稼働継続の上での問題がないかを確認するようお勧めしたいと思います。また、その対応のためにはコストがかかります。小規模対応でOSなどのバージョンアップに対応するタイミングと、リプレースするタイミングなどを戦略的に考えておかれることをお勧めしたいと思います。