ReceiptLine レシート記述言語の可能性　＜ 標準化こそ次へ進むための第一歩 ＞

　今回お話する ReceiptLine は，小型ロール紙の出力イメージを表記する記述言語である。業務用小型プリンタによる紙レシートの印刷やPOSシステムやスマートフォンによる電子レシートの画面表示に対応している。業務用小型プリンタはレシートプリンタとして広く利用されているので、レシートプリンタと呼ばれることが多いが、応用範囲はもっと広い。ReceiptLine の仕様は OFSC（一般社団法人オープン フードサービス システム コンソーシアム）から標準として発表されており、また、この参照実装が同団体からオープンソースとして一般に公開されている。

                 https://www.ofsc.or.jp/

１． きっかけ
　LeceiptLine の開発計画がOFSCの店舗システム分科会で決定されたのは2017年9月。OFSC標準として発表されたのが2020年7月なので、調査検討の時間も含めると3年近くの時間が掛けられたことになる。この ReceiptLine がなぜ開発され、なにを目指していたのかを、簡単に振り返ってみようと思う。

１－１．業務用プリンタはどう使う
　なんでプリンタの制御などに今さらと思う方もいるかもしれない。だから、まず、業務用のプリンタと、良く我々の目に触れるＰＣプリンタとを比べてみる必要がある。ＰＣプリンタの使い方は既に出来上がったイメージを印刷するのが主な役割になっている。例えばWord で作成した文章を印刷する時のことを考えて欲しい。先に印刷すべき情報は完成していてそれを印刷する。それに比べ、レシートなどの業務用プリンタは業務システムがその時々の情報、商品名や金額、税金や合計金額をプログラム上で収集、計算、成形して印刷することになる。業務用の印刷処理では編集成形のプロセスと印刷のプロセスが分離されていないことが多いのだ。全ての印刷処理が、差し込み印刷と同じ様になっているわけだし、それもかなり複雑は条件分岐をともなう差し込み処理が必要とされていると考えれば分かり易いかもしれない。

　このような現状はＯＳ環境に関係しているとも言えるが、歴史的なことも考える必要がある。まず、業務用小型プリンタはメモリの制約が多かった金銭登録機やその他の店舗機器の周辺装置として発達し、またコストを落とすためにプリンタ側のメモリも少なかったのも理由だろう。歴史的な意味を終えた後も印刷要件の変化が多い業務システム開発環境下では、この考え方でデザインされたシステムの方が安定して動いた。たとえば、税制が変わる時や新しいサービスが始まった時など、全体を再構成するのではなく一行だけ、数行だけの追加で対応したほうが素早く対応でき、間違いも起きにくかった。この様な技術進化の過程は他にも多い、特にソフトウェア開発の現場はどうしても歴史的経緯の影響を大きく受ける。なかなか、一度に大ジャンプはできないものだ。

1-1-1. ソフトウェア開発
　　業務用の印刷処理の設計が複雑な上に、業務用プリンタはPCプリンタとマーケットの大きさが違うので、優れたツールが提供されていないのが現状だ。良いものがあっても、メーカーが提供するもので、対応するプリンタが限られていたり、制限が多かったりする。このような状況ではレシートプリンタなどを利用した業務システムの開発は「めんどくせえ！」と言うことで、あまり利用範囲が広がっていないのが現状だ。

1-1-2. 業務アプリケーションに求められる環境はどんどん変わる
　　その上、業務アプリケーションを取り巻く環境が目まぐるしく変わる。だいぶ前は、ハードウェアメーカーの呪縛の中でメーカー毎の仕様に合わせて開発せざるを得なかったが、それがオープン化の掛け声の中、ハードウェアからオペレーティングシステム：ＯＳの仕様に合わせて開発すれば良いことになった。それでも、その時に開発の進め方は随分変わってしまって、多くのソフトウェアが作りなおしになった。それでも、オープン化のキーワードで、ＯＳは普遍の環境だと信じて開発をしていた人達には可哀そうなことにＯＳは普遍ではなかった。結局、多くのＯＳが生まれては消滅してゆくばかりか、バージョンアップに対応するのも大変だった。そのような中で、業務用プリンタの抱える問題は、複雑さを増すばかりだった。ＯＳに対応したデバイスドライバーがプリンタメーカーから提供されていなかったり、結局、同じプログラムでは他のメーカーのプリンタは使えなかったり。この時代のオープン化はメーカーの壁を超える十分な力を持っていなかった。
「OSに対応したデバイスドライバー」が提供されないプリンタなど使わなければ良いと言う意見があるかもしれないが、それではユーザー企業はＯＳがバージョンアップするたびにソフトウエアの作り直しや周辺機器の入れ替えをしなければならず、いくらお金があっても追いつかなくなってしまう。

　我々はつい忘れてしまうが、３０年くらい前までは、小売りの現場システムは汎用ＯＳの上で構築されていたのではなく、ＯＳと言う呼び名さえも与えられていない物も含め、各ハードウェアメーカーが開発した専用の基本ソフトウェアの上で開発されたものが多かった。この頃は、他メーカーの周辺機器を繋ぐことなどはありえないこと。その後、汎用ＯＳがベースに使われるようになったが、メーカーがオフコン用に開発したＯＳのサブセットや、やっと普及し始めたパソコン用のＯＳでデバイスドライバーの概念さえ明確になっておらず、スーパーバイザ経由でポートをアクセスしたり、デバイスに割り振られたメモリにデータを書き込んだりしたりしてデバイスを制御していた。その後、windows95の時代から日本では多くの金銭登録機やＰＯＳ、店舗端末がMicrosoftのＯＳ上で開発されるようになり、周辺装置の選択もある程度自由に出来るようになった。ただし、このデバイスドライバーも他メーカーの周辺装置と組み合わせて使うと巧く動作しなかったり、ＯＳのバージョンアップに対応できなかったりする可能性があり、厄介な物だった。

　ハードウェアメーカーも最新の機器のデバイスドライバーは最新ＯＳに対応させても、古いハードウェアの最新ＯＳ向けデバイスドライバーの提供はしたくない事情などがあった。これはマーケット上の戦略の問題もあるが、ＯＳのバージョンやハードウェア品種の増大により止むを得ないことでもあった。ただこれは、使っている機器がサポートされなくなると言う現象を生み、利用者側にとっては大変困った問題だった。現在はメジャーなＯＳはマイクロソフト製だけだと言えるだろうか。Linux を中心とするオープンソースのＯＳの占める重要度は増してきているし、スマートデバイスのＯＳもアップル（iPhon）とグーグル(android)と言う大きく二つの陣営に分かれて小売りの現場に入り込んで来ている。その上、バージョンのバラエティーもバージョンアップの頻度もかなり高い。周辺機器のハードウェアメーカーはこれら全てに使いやすいデバイスドライバーをきちんと提供し、適宜メンテナンスしてゆくことが出来るのだろうか。

　その上、最近は Webアプリケーション、スマホアプリ、クラウドへの対応が一番の課題になって来ている。個別の提案は幾つかあるものの、これらの環境から安定的に業務用プリンタを利用する方法は今のところない。ますますレシートプリンタなどを利用した業務システムの開発は「めんどくせえ！」。

1-1-3.業務用周辺装置を取り巻く今までの取り組み

　OSを提供する企業の取り組み
　　業務用プリンタなどの周辺装置標準化と言う意味で一番貢献してきたのがOPOS(Open Point of Service Technology Council) かもしれない。この団体を強力に支援するのは Microsoft である。この活動は多くのメーカーを巻き込み、メーカー毎の独自インターフェイスから独立した様々な実行環境で動くことを目指していて、素晴らしい物である。しかし、多機能で広範なインターフェイスは提案されているものの、反面、標準化の過程で多くの参加メーカーや参加ユーザー、システム企業の要求を取り込んでしまっために、重複があったり重要性の低い機能の対応が求められたり、必要以上に細かい設定が必要だったりするものになった。必然的に簡潔性に欠け、専門性を持った開発者にしか手に負えないものだった。

　Multics と UNIXの話をご存じだろうか。巨大企業のＡＴ＆Ｔが企業の総力を傾けて開発しようとしたのが Multics と言うＯＳだったが、Multicsそのものは普及しなかった。このプロジェクトは失敗したのだ。その後 Multics の開発プロジェクトのメンバーが Multics をシンプルにして作り上げたのが UNIX。マルチではなく、ユニなのだ。大プロジェクトは得てして最小公倍数的な仕組みになってしまい、幾つか不都合な部分を内包し勝ちだと言うこと。それに最も拙いのは、ＯＳに依存したソフトウエアやハードウエアには囲い込みのリスクが大きく、ＯＳメーカーのマーケット戦術に翻弄されることになる。ほら、やはりレシートプリンタなどを利用した業務システムの開発は「めんどくせえ！」。

　OFSCの取り組み
　　2008年には、インターネットの時代に対応し、ＯＳから独立した、ネットワーク上のサービスを意識した接続標準として OFSC機器標準接続規格(OFSC Device Interface Standard)が、発表されていた。が、この規格のコアになっている PosLog と言う規格はARTS （現在は Object Management Group :OMG)と言うOPOSと関連の深い団体が作り上げたもので、やはり最大公約の呪縛から逃れられていなかった。その上、OFSCの知名度が低かったせいもあり、今一つ普及が進まなかった。やはりレシートプリンタなどを利用した業務システムの開発は「めんどくせえ！」ままだった。

1-1-4. 「めんどくせえ！」とアイデアは出てこない
　　アンケートを取ってみたことがある。「レシートプリンタを使ってみたい業務はありますか？」　多くの人が ノー だ。アンケートは同業者に出している物なので、その気持ちの半分は手間と効果を天秤にかけているはずである。これが、開発が容易だったら沢山アイデアが出る。切手もレシートプリンタから印刷できるのでは、駅の切符は、映画の入場券は、自販機のチケットは。電子化の時代にと言われるかもしれない、でも、一度、紙に置き換えたほうが情報を扱いやすい場合も多い。紙は“物”としての性質を持っているので、弱点もあるが、今までの常識によって管理しやすい一面があるのだ。

　幾つかの“情報を紙で伝える”アイデア例を並べてみよう。

　レシートプリンタで福引をもっと面白くできる。賞品の数と品揃えをとてつもなく多く、即興的に出来る。ご存知の通り福引は二つの目的を持ったプロモーションで一つは来店動機を増やす、もう一つは購買意欲を刺激するだ。これを射幸心を刺激することで実現する。昔はガラポンと言われる抽選機を置いて抽選券を集めた人に賞品を提供していた。この抽選券は一般的に、一定の購買金額ごとに発行されるもので、抽選券と抽選補助券とに分かれる。抽選券は一枚で福引に参加できるが、補助券は数枚集めることで抽選に参加できる仕組み。補助券をもらった人が福引に参加する資格を欲しくなって購買を増やしたり、福引に参加する為に再来店したりしてくれるのを見越して、福引は行われる。この福引、最近はガラポンを使わずにタブレットＰＣなどを利用するケースが増えているが、折角の機会を活かせていない。福引にあと幾つかの目的を追加することが出来る。一つは売れる商品の志向調査、もう一つが売れない商品のアッピールや、より大きな来店動機付けだ。大抵、賞品はガラポンの脇に置いてある。でも、賞品の引換券を即時印刷できるならデータで持っていれば十分。抽選の最後で欲しい商品を選んでもらいその賞品の引換券を印刷する。この印刷物を店に持って行けば、サービスが受けられたり、物が貰えたりする。最後にお客様に賞品を選んでもらうプロセスを挟めば志向調査に使え、お店側が適宜賞品を入れ替えられれば商品をお客様に知ってもらうチャンスに出来る。それも、即興的に。賞品が複雑になると引き渡しが混乱しがちだが、賞品のチケットを紙で印刷するなら福引掛かりの手間も省ける。

　タイムカードはどうだ。タイムカードがなくなって、バイオメトリックやIDカードを使うケースも増えている。その時に、労働者が確認するための証拠はどうなったろう。スマートフォンが普及しているので、それで対応することも出来るけれど、欲しい人は印刷できる仕組みがタイムレコーダーに付いていたらどうだ。そこから今日の業務指示が一緒に印刷されたらどう。良くタイムカードにはポストイットで伝言が張ってあったりしなかったか。タイムカードの視認性を失いたくないからと、まだそこから離れられないシステムはもう無いのだろうか。勤務実績をスマホで確認したり、当日の業務指示をスマホに送ったりするのは実はそう簡単なことではない。特に、バカッター（馬鹿な投稿をしてしまうアルバイト）対策や情報漏洩対策で本人のスマートデバイスが職場に持ち込めない事情もある。また、労働者のデジタル化の状況はいろいろで、スマートデバイスを持たずにガラ携を持ち続ける人、ガラ携帯すらもたない人もかなりいる。特にシルバー人材については Line を使う人から未だにファクスもない人まで格差が広がっている。このような状況で企業の負担でスマートフォンを配るにしても管理と教育の問題があり、また、もしもスマートフォンで済んだとしてもデータを受け取るアプリの開発にはセキュリティー対策も必要な上、対象機器やバージョンが増えているためメンテナンスコストが馬鹿にならない。実は印刷物は未だにコスト的には悪くない選択なのだ。スマホを持っていない高齢者が多い職場やスマートフォンを持ち込めない職場では活用されるだろう。

　既に、航空機の搭乗券はバーコードの印刷で済んでいる。インターネットからの発券のためにはいろいろ工夫がされたので、その手法は業務用小型プリンタに応用できる。これを応用すれば、食券の自販機や入場券の自販機もローコストで開発でき、業務全体を効率化できる。

１－２．もう一つの動き
　小売業の業務システムについては、このレシートに関して全く別の視点を持つ人たちもいた。彼らはビッグデータになるのではないかと言う目でレシート情報に目を向けていた。

1-2-1. デジタルレシート標準化

　2015年の末からOFSCでもデジタルレシートの研究を始めている。これは、経済産業省が2018年の2月13日から28日に町田市で開催電子レシートの実証実験にもつながって行く。現在もOFSCではデジタルレシート規格の標準化作業を継続している。

1-2-2. デジタルレシートとは何か

　「これからはレシートのやり取りは面倒なのでデジタルレシートの時代になるよね。」と言えば、多くの人が何となく納得するはず。でも、この時、その人がどの様な仕組みを思い描くかはマチマチだろう。中には単純にペーパーレス化ができれば十分であると考える人もいるかもしれない。しかし、経済産業省やOFSCが思い描くデジタルレシートはそれぞれの項目の意味を明確にして規定することによって、いろいろなアプリケーションで情報交換ができることを目指してきた。例えば、家計簿アプリへのレシートデータの取り込みや、企業内経費管理システムへのレシートデータによるの取り込みなどである。

　多くの小売り流通業のＩＴ担当者はデジタルレシートの本質は、取引査証のＥＤＩ化にあると捉えていてＢtoＣ（消費にまつわる商取引）であっても、取引情報データが重要だと考えている。一度データ化されたものを出来るだけ有効に使いたいと言うのが、システム担当者の基本的な発想でもある。上記の家計簿ソフトに対する取り込みについて考えると分かり易い。スーパーなどでは各競争だけでは十分顧客の興味を引き付けられないので、いつも他企業との差別化を考えている。もし、家計簿付けのお手伝いをすることができれば商機を広げられと思っているＩＴ担当者もかなり多い。また、家計簿ソフトを使ってもらうことによってＷｅｂに支配されているリコメンデーションマーケティング（顧客の嗜好に合わせてお薦め商品をお知らせする）などに進出できる可能性も感じている。同様に、企業でも経理担当の手作業がこれらのデジタルレシートデーターによって改善される可能性がある。そのとき、経理担当者は仮払いをするときに何と言うだろうか。「同じものだったらデジタルレシート対応のところで購入をお願いします。」これがデジタルレシート対応の小売業が比較優位になる可能性を生む。

　また、経済産業省の構想では、デジタルレシートデーターをビッグデータのデータベースとして市場調査やマーケティングなどに活用すること迄見据えていた。日本の情報産業の将来を考える時に、GAFAや Alipay WeChat Payの存在は大きい。このままで行けば日本のマーケッティング情報は米国や中国に利用されるだけで、日本の国内の情報産業には収益源となりえない。これに対抗する一つの方法としてデジタルレシートデーターの活用を検討している人達がいるのだ。

　当然のことながら、システム間のデータ連携には齟齬があってはならない。これを考えれば、データ項目の詳細な定義がどうしても必要になるのだ。“ＥＤＩの一環としてのデジタルレシート”と“スマートデバイスでの表示に特化したデジタルレシート”との違いはここにある。

　きめ細かなデータ定義をして行くと、簡単に見えるレシートのデータ項目数は200を超え、もっと増えてゆく可能性もある。そんなに多いわけがないと思う方は、一度、何枚かのレシートを引っ張り出して、どんな内容が記載されているかを数えて見られることをお勧めする。普段よく目にしているレシートに、実は多くの情報が記載されている。いくつかの企業の幾つかの業態の、そして数年分のレシートを集めてみればなおよい。まず、日付、時刻、元号、企業名、店名、店番号、住所、電話番号、商品名、商品の区分、税金の区分、金額であれば商品毎金額か単価か合計金額か、税抜きか税込みか、税込みならどの様な税込みか、税額や、端数の扱い、レジ操作の担当者名、販売担当者名、割引の内容、支払いの方法、ポイント還元関連、セールの情報、等々、多くの項目が見いだせるだろう。それらの項目にそれぞれ幾つものパタンが考えられて場合によっては別項目にする必要もある。OFSCデジタルレシート標準はJSON でインターフェイス定義しているが、このJSON のスキーマを作成すると、それにはそれぞれのデータが数字であるか文字であるか特別の意味があるかなどの属性も書かれているので、2,000行位にはなってしまい、かなりの量のドキュメントになっている。

1-2-3. 経済産業省の実証実験　成功したが　・・・　普及は？

　　経済産業省の実証実験は成功したと考えられているし、確かに成果はあったと思う。ただ、この時に利用された標準がその後普及してゆく動きはなかった。複雑さの壁は超えにくい。何か他の方法はないか。このデジタルレシート標準の複雑さとレシートプリンタを利用するアプリケーションの開発の複雑さ、この二つの課題が ReceiptLine の開発のきっかけになった。

２．今までの取り組みの問題点　　印刷物（パブリッシング）制御に関する取り組み。

２－１．代表的な例 PostScript

　英語のパブリッシングの方が考えを広げられそうだが、出版技術、印刷技術であれば、ReceiptLine の先輩格の取り組みはたくさんあった。Tex や PostScript が有名だろう。IT技術について少し勉強された方であれば、Tex や PostScriptはご存じだろう。これらはマークアップ言語と言われる構文を持っている。普通のテキストだけでは達成できない機能をマークアップとして注記する手法である。単純なところでは文章の中に数式を書き込んだり、書籍の編集などに応用されたりしている。しかし、得てして記述が長く複雑になりがちだった。

２－２．マークアップ言語の世界で起きた大ブレークの二つ

　　2-2-1.　　SGML　から　HTML 、意味から表現へ
　マークアップ言語の大ブレークは HTML だろう。今では小学生や家庭の主婦でも少しはHTMLタグを知っているのではないだろうか。このHTMLにはSGML（Standard Generalized Markup Language）という大先輩がいた。このSGMLは意味を伝えようと作られた規格だった。文章にマーク付けされるのは意味だったのだ。それから派生した HTML(HyperText Markup Language)は SGMLを単純化し、意味を伝えるのを諦めて表現だけを規定する方向へ進化した。現在、我々がインターネットから自由に情報を閲覧できるようになった重要な技術の一つがこれである。HTMLを見たことがない人はホームページ（シンプルなページがお勧め）を開いているブラウザで、「ページのソースを表示」機能を選んでみると良い。ホームページが HTML であなたのところに飛んで来ているのが分かる。

　　2-2-2.　　マークダウン記法の誕生

　　マークダウンはマークアップの一種だが、マークアップの表記をいかに読みやすく、簡潔にするかを追求したものだ。マークアップのタグを文章の中にはあまり出現しない記号文字に変えてしまうことで、表記を簡潔にするものである。マークダウン構文を持つものたちも多い。WikiPedia で有名になった Wiki は HTML をマークダウン化するものだし、POD(Plain Old Documentation)はPerl のプログラムコメントとして普及した。Ruby のコメントである Ruby Document formatmo もマークダウンだ。ReceiptLine の様にパブリシングのために作られた AsciiDoc も著名なマークダウン記法の言語だ。
　意味の定義を少し離れて、簡潔なマークダウン記法の言語で、小型業務用プリンタの象徴であるレシートプリンタ向けのパブリッシング機構を提案する。これが ReceiptLine の開発目標になった。

３． ReceiptLine 開発リーダー

中村英雄 氏

　ReceiptLine の開発は提案者でもあるOFSC店舗システム分科会の中村英雄が行うことになった。旧来の業務用プリンタの専門家であると共に、新しい技術を研究する興味も失わない稀有な人材である。ReceiptLine の仕様書の簡易バッカス・ナウア記法に基づく文法をレールロードダイヤグラムで分かり易く表現してくれた。また、現在の参照実装も彼の手によって書き起こされている。参照実装が多くの国内メーカーから低ky法されているレシートプリンタに対応できたのも彼の努力による。勿論、OFSCに参加しているレシートメーカーの協力があったおかげでもある。

　　　２０２０年６月には憲章、仕様、参照実装が揃い、ＯＦＳＣ会員に公開された。一ヶ月会員企業の評価を待ち、今回は公開に対して肯定的な意見しか上がってこなかったので、７月１３日に、会員の承認を受けた形で一般公開されることになった。

４． OFSCとは
　OFSCの正式名称は 一般社団法人オープン・フードサービス・システム・コンソーシアム(Open Foodservice System Consortium) で、2004年末に任意団体として発足し2010年に社団法人化した組織である。情報システム先進化を目指す外食企業の集まりであったが、彼らの考え方に賛同するITシステム・機器ベンダーも数多く入会している。外食企業が導入するシステムやハードウェアなどの相互接続性と高め、それにより外食企業が多様で先進的なシステムの構築や運用を行いやすくするのが主な目的である。そのためOFSCの立ち位置は標準化団体となっているが、外食企業の情報システム担当者が情報交換の場としても機能している。

　OFSCから既に発表されている二つの標準があり、それは以下の二つになる。OFSC 機器標準接続規格、OFSC OES 標準接続規格。それぞれ、POSの周辺機器、POSと店舗内オーダー受注システム:OESとのやりとりを規定している。両者はPOSやPOS外部からの要求にこたえるWebサービスとして定義されており、やり取りされるメッセージは、小売業外食業のデータディクショナリとして定義された POSLog がベースになっている。PosLog は、米国全米小売業協会（National Retail Federation：NRF)の下部組織 小売業技術標準協会（Association for Retail Technology Standards：ARTS）が制定したもので、このPosLogの外食部分についてはOFSCも大きく貢献している。なお、現在ARTSは業務をObject Management Group (OMG)に引き継いでいる。

５．ReceiptLine 標準規格と参照実装の関係

５－１．ドキュメント　憲章と定義書
　　　もう一度、ReceiptLine について整理しておきたい。ReceiptLine は言語仕様である。だから、OFSCが標準規格として提案しているのは言語の仕様でその定義書と ReceiptLine の憲章＝チャーターが作られている。憲章にはこう書かれている。チャーターとか憲章とか言うのはこの標準を発表することにより、目指す道を宣言するものだ。出来るだけ多くの人に標準を使ってもらいたいので、どうしても表現は抽象的になってしまう。しかし、なにを目指して作られたのかを知ってもらうのは重要だろう。

　　 史上最も簡単で便利なプリント中間言語である。
　　 プリンタの機種や紙幅の違いを吸収する。
　　 Web 開発者でも専門的な知識を必要なくソフトウェアを開発できる。
　　 紙と電子で同様の出力が可能で，媒体に依存しない。
　　 伝票・レシート・券等を発行するシステムの開発期間を短縮する。
　　 外食企業のシステム導入・変更・拡張を容易にする。

　既に書いたように、定義書はレールロードダイヤグラムで簡潔に書かれている。いくつかのページを拾い読みすれが、レシートプリンタを使うシステムの開発経験があるエンジニアの興味は引き付けられると思う。ReceiptLine は参照実装が公開されているので、誰でも評価してみることが出来る。目標がどこまで達成されているか、是非確認されることをお勧めする。

５－２．ReceiptLine の参照実装

5-2-1.　　参照実装とは仕様書だけでは説明出来ないことを補うものである。
　実際にReceiptLine に定義書を書き上げる時には仕様に矛盾がないかどうかを確認する道具としても活用された。それは同時に、今後の ReceiptLine の可能性の提示と、共同開発の呼びかけになっている。技術の世界に生きている人であれば、チャーターよりも定義書よりも、この参照実装に触れてみるのが一番早いのではないか。OFSCが何をしたいのかが凝縮されているはずだ。

5-2-2.　　なぜ、javaScript なぜ、Node.js
　 開発言語に javaScript を採用したのは Webアプリケーション、ブラウザアプリケーションからの利用を意識したからだ。また、システム開発のマッスがWeb開発にシフトしつつあるなか、ReceiptLine の進化のためには Web開発者に親和性の高い言語が望ましいと思ったからでもある。彼らがソースに目を通してくれれば、きっと ReceiptLine は成長してゆくだろう。

　　OFSCは幾つかの接続標準を提案してきた。それらは全てサービスとしての標準である。正確性に欠けるかかも知れないが、少し違った言い方をすればリスナー側を定義してきた。アプリケーションが要求をあげ、それを解決すると言う機能、仕組みが接続標準としては優れている。これで実装時に論理的接続点を物理的接続点と同一に出来る。Node.js は優れた Webサーバで、多くのアクセスを一度にこなせるなどの特徴から、このところIOTのハブとしても活用されている。これはまさに ReceiptLine がチャーターにあげた目標通りに動く環境としては理想的だった。また、Node.js の動作環境はLinix,Windows,Raspberry Piなど多様で、ReceiptLineに、いろいろな局面で活躍するチャンスを用意してくれるはずだ。

5-2-3. SVG出力のサポート
　　ReceiptLine 参照実装は SVGへの出力もサポートしている。これにより、ペーパーレス化の対応の問題を解決している。デジタルレシートの縮退版は ReceiptLineだけで作れるだろう。事実、未発表のOFSCのデジタルレシート標準規格にも ReceiptLine のタグ（キーワード）があり、このタグはレシートの印刷イメージを残すための物になっている。また、参照実装にはReceiptLine のデザインツールが付いているが、ここで印刷イメージを表示するWYSIWYG ツールはReceiptLineのSVG出力機能で実現している。

5-2-4. 参照実装をApache ライセンスのオープンソースにした理由
　　標準規格の普及と言う意味で、OFSCには反省がある。これは、前掲のOFSC 機器標準接続規格の発表の時の事である。参照実装の扱いについて方針が固まらず、公開が遅れたため、折角のマーケットの追い風、Webアプリケーションの全盛期に対応システムや対応製品が揃わなかったことである。実は、このOFSC 機器標準接続規格の参照実装のオープンソース公開の時期と、ReceiptLine の開発が決定したのは同時期の 2017である。そこで、当初から ReceiptLine は仕様の公開と参照実装の公開を同時に行う予定であった。

　　近年は多くのIT技術がオープンソースの公開を契機として広まっている。OFSCも標準化団体として標準の策定だけでなく普及も重要な活動であるため、今後も参照実装はおーぷソースにして、多くのエンジニアに触れてもらいたいと思っている。

　　さて、オープンソースであるが、オープンソースには幾つものライセンスがあるのはご存じだろう。その中で、なぜ我々は Apache ライセンスを選んだかもお伝えしたい。オープンソースは幾つかの視点で分類できると思うが、コントリビューターを意識したライセンスと、そうでないライセンスに分けられる。

　では、コントリビューターとは何か。Contributor は、直訳では「寄稿者」となってしまうが、公開当初のオープンソースソフトウエアに手を入れて改良したり、より良いものを生み出したりする緩やかな共同開発者なのである。広く考えれば積極的な利用者であれば利用者もコントリビューターだと言える。業務用プリンタメーカーの技術者だけがコントリビューターになれるのではない。オープンソースのコミュニティのソフトウェア翻訳担当者のライトニングトーク（数分間の短いプレゼンテーション）で「英語が分からなくても良いから、翻訳に協力してください。」と話があった。何か不思議な話でビックリするでしょう。でも、これは翻訳がすんだソフトウェアを積極的に使ってほしいと言うことで、それにより日本語表現の未熟なところをチェックし下さいと言う意味だった。積極的に利用することもソフトウェアを良くして行くためには重要な活動になる。

　Apache ライセンスは強くコントリビューターを意識して、彼らの権利を保障するライセンスになっている。ReceiptLine は 今迄の業務システム開発のありかたに少し疑問を感じている、優れたコントリビューターを求めている。