前回につづいて、ゆうパックプリントR（以下、「ゆうプリR」）とネクストエンジン回りでいろいろ検討した知見を公開してお役立てていただこうという企画の2回目です。
1回目はこちら
今回のテーマはこちら
①ゆうプリRには、「SQL版」というものがある。
月間1万件を超える発送がある、ということを商談で伝えて数か月。日本郵便側からは誰もそんなことは教えてくれなかったのですが、ゆうプリRには、データベースに、マイクロソフトのSQL SERVER®を利用した「SQL SERVER版」というのがあります。これは、プロジェクト途中で知遇を得た(しかし協力は断られた）ゆうプリ対応経験者から、「ところで想定しているのは、SQL版ですよね？」と言われて「えっ、何それ？」と絶句した、というところで日本郵便の営業担当者に聞いたら、「ありますよ～」と軽く言われてライセンス供与してもらった、という出来事がありました。最初に教えてよ…それまで「ゆうプリ」での検索は何百回としていたのですが、SQL版の存在には全く行き当っていませんでした。
関連情報のリンクはこちら。日本郵便のwebサイト内にリンク等はありません。
https://www.post.japanpost.jp/yu-packprint-r/member/sql/index.html
では、通常版は何かというと、「MDB版」とSQL版と対比して通称するようですが、通常世の中でゆうプリRと言われているのは、このMDB版。
詳しくない方のために補足すると、MDBというのは、Microsoft Access®で使用されているデータベース形式を指していて、比較的少量のデータを扱うときによく使われています。対して、SQL Serverは、Oracleと並ぶ業界を代表するデータベースシステムで、大規模なデータを取り扱うときに多く用いられる製品です。大規模と言っても使い方には限度もコツもあるのですが…そこらへんは通常のECで用いるような規模や使い方ではほぼ関係ない(ということが後からだんだんわかってきた）です。通常版を購入すると非常に高価なのですが、会計システムや今回のような汎用システムの内部のデータベース用には、比較的安価にマイクロソフトが製品組込用としてライセンスしています。
そのデータアクセスがMDB版もどちらもADOなのか、とかも最初は気になったのですが、それは実際にはその後の構築や業務運用には何の関係もありませんでしたので、無視します。
で、技術の話はすっ飛ばして、この2つはどう使い分けるか、と言いますと、MDB版では、件数が多くなってくると、だんだんと検索して一覧表示するような一般的な動作が遅くなっていき、やがては運用が困難になり、データベース容量に２Gという制限があるが、SQL版では通常の使用範囲では、その制約がほぼない。ということです。これは、先の経験のあるエンジニアの方に教わったのですが(自分で試していません）、後述しますが、送り状を印刷して発送したデータは翌営業日以降いつ削除してもかまわない運用が多いですが、月1万件で一体型伝票用データ用のデータを収める、という想定だと、MDB版だと、月に2回以上データメンテナンス（バックアップして削除する、という動作を言っているらしい）が必要だが、SQL版だと年1ぐらいでいいんではないですか？…というお話でした。つまり、このケースでは、あまりパソコンに詳しくない、そして日常の出荷で忙しい現場を考えれば、MDB版では採用に足らない、ということです。
おいおい…
そして、あとから気づいたのですが、MDB版のあとに提供していただいたSQL版は、お客様コード（ゆうプリRはお客様コード＋端末コードが特定のPCに紐付けされていて、他のPCでそのライセンスを転用することができない。つまり、PCが不調だからと言って他のPCをセットアップして勝手にそれに移植することができない仕組みなのです。）がMDB版のまま対象ライセンスを変更する形で提供されていたので、MDB版の時に使用していた端末番号がロックされたままになっていた。これを解除するには、サポートセンターに電話かメールで理由を添えて申請が必要です。つまり、数時間～1日かかります。この構造には、あとあとまで悩まされ、運用形態を決める際にも悩まされます。
SQL版を採用すると何が違うのか？というと…(ここ、経営者の方にとって重要です）
SQL Serverということで、少し詳しい方はデータベース設計をして、リレーションを設定して…と思われるかもしれません。また、ゆうプリRの仕様書を見ると、商品データベース、顧客データベースに出荷明細のデータベースという大きく分けて3つのテーブルがあることがわかります。しかし、おそらくはほとんどのEC事業の出荷では、「出荷明細データベース」しか使いません。と言いますか、送り状や一体型伝票のピッキングリストや納品書で印刷できるのは、「出荷明細データベースの項目」だけで、実は商品データベースの項目は使えない(印刷できない）と思って計画して大きくはずれていません。
たしかに、データベースのSQL窓にSQL文を投げるとデータベース項目を見たり、レコードを挿入したりはできるのですが、そういう機能は使わないですし、データベースの知識もほとんど使いませんで、「たくさんのデータを安定的に運用できる箱」としてのSQL Serverという位置づけなのです。(適当なことを言っているようですが、一応私、Oracle8.0.x当時にOracle Silver持っていた程度のRDBの初歩的な知識はあります。）
②動作条件と運用条件
先ほどのSQL版の動作保証条件が、MS Windows Serverである、それに伴いサーバー機器とサーバー運用ノウハウが必要になり、これが中小企業にはハードルが高い、ということを申しましたが、そこにはさらにいくつか問題があります。
一つ目は、サーバー本体の問題、他のサーバーに同居できないかということです。中小企業の社内に同様のサーバーがあるとしたら、それは会計システムである可能性が高いでしょう。勘定奉行、スマイルαなど多くの中小企業向け会計システムは、SQLServerを利用していて、おそらくは、メーカーや大塚商会がハードとソフトをセットで保守してくれていると思います。しかし、そのシステムの動作条件として、「他のSQL Serverを用いるソフトウエアと同居不可」と書いてあることが多い(書いてなくても保守を行うには切り分けのため、業者はそう要求する）はずです。そして、ゆうプリR SQL版の動作条件も、「他のSQL Serverを用いるソフトウエアと同居不可」と記載があります。
別の場所にインストールすれば動作しそうな気もしますが、レジストリ周りのKEYまでは分からないし、会社の会計系に影響を及ぼすようなことをする勇気は私にもありません。干渉が不明な別のものが入っていたら今の保守会社に面倒を見てもらえないのは、保守会社側からしたら当然のことです。したがって、運用先を「別のハードウエア（PC）」にせざるを得ないのです。
もう一つの問題は、 ゆうプリRが入った状態のサーバーが障害が生じた時に、たとえば、RAIDを再構成して、OS周りの設定を確認して…とここまではお金と時間次第では何とかなります。しかし、ゆうプリRをオンサイトで再インストールして環境をセットアップして、そして、次回あたりにご説明するであろう荷物サイズ入力の仕組みをさらに再インストールしてセットアップして…というソフト部分の保守を引き受けてくれる会社がない、ということです。これは相当探してもなかったし、ゆうパックのサポートダイヤルに相談しても紹介等はおこなっていない（彼ら自身、実は開発会社の一部門なのだと思うのですが）と言われてしまい、障害時には最悪、SQL版のサーバー（つまり、先ほどなかなか難しいと言ったSQL Serverのインストール作業を含む）を自社でなんとかしなければならない、ということです。
ちなみに、「うちはゆうプリR SQL版 関係のオンサイト含む運用保守受けるよ」という会社がありましたら、info@kibow.bizまでお知らせください。こちらでご紹介するとともに、顧客にもご紹介します。
一方で、ECの出荷はSQL版を使うような会社ならば、少ない日でも100や200は発生し、セール時には、1000も2000も生じるわけで、「復旧に2日かかります。その間は出荷停止です。」というわけにはいきません。この仕組みは中小企業なりに、「止まっては困るシステム」なのです。ただ、いつかは、それもそんなに遠くないいつか、ディスク障害なり電源故障なりという物理破損は起きます。そして、中小企業が頑張ってサーバー保守を掛けても、すぐに駆け付けてくれて治るわけではありません。RAIDや電源冗長化を行っても、ソフトウエアに障害があった場合には復旧ができません。月々のお金ばかりかかってしまいいざというときには役立たない保守！、いったいどうすればよいのでしょう？
ここから先は、まともなIT会社ならば、こんな場で大っぴらに書くようなことではありません。また、何等かの仕様変更が起きた場合に使えなくなるし、サポート等で支障になる可能性もあります。そのように各社の「自己責任になる」という前提でまともではない弊社だからこそ、お話しします。ただ、今回の顧客がそうしている、ということを言っているのではなく、今回の対応を進める中でわかった逃げ道であるということをここで申し添えておきます。(ここで書くと塞がれるかもしれませんが）
実は、ゆうプリR SQL版の動作自体は、Windows10 Homeでも動作するのです。自分でテスト時に試したので間違いありません。それは、マイクロソフトが自社で販売しているSQLServerの動作条件が、Server OSを必須としておらず、Windows10 でも動作するとしていることからもわかります。では、なぜServer OSが動作条件としているか？というとそれは推測ですが、日本郵便がマイクロソフトからライセンスを受ける際に、Server OSでの動作を条件としてライセンスを受けているからであり、それだからこそ、日本郵便からはこれ以上の説明は一切できないし、動作保証外という回答しかできない、ということなのだろうと思います。
であるならば…立派な冗長化されたサーバーを購入して、でも障害が起きたらゆうプリR本体は復旧できない、という状況に置かれるならば、おそらくはゆうプリRを使う時間は、平日の9時から17時で、しかも四六時中動作しているわけではなく1日に何回かデータをインポート、印刷、エクスポートするだけのそこまで過酷な環境ではないはずなのですから、ノートPC2台にサーバーをインストールして、1台をコールドスタンバイ、という形で待機させておけばよい、という解が考えられます。ただし、同じ顧客番号と端末番号のゆうプリRを別のPCに2台インストールして、2台ともアクティベートされた状態にすることはできませんし、1台をアクティベートしていない状態で、障害が起きたときに切り替えるには、日本郵便側での登録消去作業が必要になり、すぐには復旧できない、ということになります。そのため、「違う顧客番号のサーバーを2系統用意する」ということを日本郵便と商談して了承を得て対応をする必要が生じます。
ゆうプリRはスタンドアローンで使っている会社も多いと思いますが、ただ印字するだけならばそれで全然問題がありません。ただし、今回のようにその日の出荷データを整理して日本郵便に送信する、という方法を取るためには少なくともその日の出荷データは一つのファイル（サーバー）にまとまっている必要があります。そのために、ゆうプリRは実はクライアント・サーバー型の構成をとることができます。このクライアント・サーバー型システムへの対応というのも、実に20年ぶりぐらいに今回行った20世紀の産物なわけですが…ゆうプリRの場合、クライアントも同じ顧客番号でサーバーと紐づいていて、しかも(当たり前ですが）サーバーは一つです。そして、クライアントもまた、違う顧客番号に対応するためには日本郵便側での紐づけ解除作業が必要です。
そのため、上のような「ノートPC2台でサーバー運用」を行った場合には、通常使っている主系統ではクライアントを紐づけしておくことが可能ですが、ダウン時に副サーバーに切り替えた時には、クライアントはすぐには接続できませんので、「サーバー機をスタンドアローン運用する」こととすれば対処可能、ということがわかりました。
ITの「専門家」からしたら、サーバーをノートパソコンで代用するとか、笑止千万かもしれません。しかし、こうすれば、ノートPC2倍×10万円＝20万円で対処が可能で、保守費は固定では0円で、しかもダウンタイムはほぼ０にできます。1台が動いている間、おそらくは数日間は大丈夫なはず…に何とかもう一台をセットアップすればよいのであれば復旧対策もセンドバック等で対処が検討可能です。月に1日ぐらい予備機で業務を行う日を作っておけばよい。ということです。
こんなことが可能なのも、ゆうプリRが、SQL Serverを内蔵していようが、どんなに立派なハードウエアに載っていようが、言ってしまえば、「送り状を印字する仕組み」であり、顧客や履歴を管理する仕組みではないからです。顧客への発送履歴は追跡番号含めて、ネクストエンジン(この顧客の場合）や、モールの提供する顧客管理の仕組みにあり、検索や対応はそこで行われます。そのため、「ゆうプリR上の1台で一貫性をもって長期保管し、そのデータを検索、加工する」という必要性がほとんどないのです。だから、印字した顧客データは、時々削除してしまっても大丈夫だし、ハードウエアが故障したら、別の機械に切り替えて使っても、データの一貫性に(その日のデータが1台にまとまってさえいれば)問題ないのです。
だとしたら、このサーバーOS限定、というのはそもそも顧客層のニーズを外している、ということが言えると思うのですが、そこは日本有数の巨大企業とマイクロソフトとの間でいろいろあったのでしょう。
協力してくれるエンジニアと毎晩0時過ぎまで、こんな検討を続ける日々が続きました。彼も本業の傍ら、家族もいるのに、本当に申し訳なかった…そして、その中で数々の制約やこうしたユーザーフレンドリーではない仕組みに行き当たる度に二人で、「20世紀少年」(の慣れの果て）と悪態をついてやる気を振り絞っていました。もちろん自分たちと、そしてこのシステム両方を指しています。
ただ…ゆうプリは安定しています。めったなことではとまらない。久しぶりにwebサービスからオンプレに移って触ってみると、安定という意味では「20世紀型」でもいいような気もしてきます。（運用や構築の制約はホント嫌になりましたが）実務担当者にとっては、メンテナンス性なんて関係なくて、止まらないで速度低下しないことの方がはるかに大事ですので。
もう少し実務対応の色々を書くつもりだったのですが、今回は、「ゆうプリR」、特にSQL版をどのようにとらえるか？ということで終わってしまいました。2回ぐらいで終わるつもりだったのですが、あと2回ぐらい書いてしまいそうです。(次回に続く）
