消費税率０％でレジのシステム改修が大変な、本当の理由は何だろう？

原稿執筆年月：２０２６年０６月

現在、消費税率の引き下げに関して、レジシステムが対応する手間の話もあります。

朝令暮改が大変なのは当然ですが、レジシステム側に着目し、面倒さを考察します。

○　ゼロは特殊な値（１）　……　ゼロ除算エラー

○　ゼロは特殊な値（２）　……　消費税率を使うのは、プログラムのいつ？

○　ゼロは特殊な値（３）　……　無いことを表すゼロ

○　その日から変わる面倒さ（１）　……　まずは休日カレンダー

○　その日から変わる面倒さ（２）　……　消費税率なら

○　天地がひっくり返っても

○　プログラムは公式のようなもの

○　担当者は異動しました（１）　……　マスタって、なに？

○　担当者は異動しました（２）　……　正しく稼働すればいい

○　そういうもんではない

○　後任者に優しいシステム

○　柔軟なシステム

この作品は、web小説サイト「小説を読もう（小説家になろう）」「カクヨム」に掲載しています。

---

　報道によれば、消費税の税率を変更すると、コンピュータによるレジシステムの変更に、大きなコストが掛かるそうです。

　本当でしょうか？

　所詮、外部の者ですので、現場を知らない情報で軽んじた考えをしています。だからこそ、「なぜだろう？」と知りたい気持ちです。

　以下、「大変な理由は、これなのかな」ということを、実例を用いて、あれこれと寄り道しながら推測してみます。

　システムの環境により、「本当に大変」のこともあれば、「そうでもない」場合もありそうです。

　レジシステムも、環境は様々でしょう。レジは単体で稼働するのではなく、経理システムとの連携なども環境ですし、プラットフォームの違い（( )ＰＣとスマホの違いのようなもの）も環境です。

　新しいシステムを作る際は、将来の変更に柔軟であることを考慮します。

　「このシステムは、そんな簡単なものではない」なのでしょうか。

　○　　ゼロは特殊な値（( )１）　……　ゼロ除算エラー

　報道にもあったように、コンピュータのプログラムにとって、ゼロは特殊な値です。プログラムは「ゼロの対応」をしていないものが、少なからずあるのでしょう。

　私がコンピュータのシステムを作成していた頃は、「もし、データが約束違反だったら」の対応も考慮していました。

　エクセルの関数で譬えれば、

　　Ａ１セル　÷　Ｂ１セル

　という関数で、Ｂ１がゼロなら、結果は「ゼロ除算エラー」になります。

　ゼロ除算エラーは、コンピュータの初期の頃からあり、答えが「無限大」になるので、本当に計算すると、コンピュータが「壊れる」「暴走する」といった、とんでもないことになります。

　現在は計算せずに「エラーだよ！」と、人間に知らせるようになっています。

　そこで、そのシステムの意味（( )用途）を確認し、関数を作ります。

　　例１：もしＢ１セルがゼロなら、答えをゼロにする、そうでなければ、普通に計算する

　　例２：もしＢ１セルがゼロなら、エラーを知らせる、そうでなければ、普通に計算する

　このように、システムの用途によって、どの関数にするべきかを考えるのが、プログラマです。

　プログラマは「回避できないエラー」と「把握できないエラー」の扱いを知っています。

　エラーを感知できずに、誤ったデータがレジシステムから経理システムに渡されると、被害が拡大します。

　○　　ゼロは特殊な値（( )２）　……　消費税率を使うのは、プログラムのいつ？

　消費税率がゼロなら困るのは、消費税率をどのように計算に用いているのでしょう？

　消費税率で割ることが、あるのでしょうか？　消費税率は、掛け算にだけ使うはずです。

　消費税率の変更だけなら、マスタの変更だけだと思うのですが、それ以外のどこが変更対象でしょうか？

　消費税マスタを使うのが、「税率変更前にレジで使う」「税率変更後に経理で使う」の場合、税率が異なるのが困るのでしょうか？

　「マスタ」とは「一覧表」「値段表」「管理簿」のようなもので、「商品マスタ」なら、一覧表からバーコードの番号を探して、「商品名」「値段」などをレシートに印刷します。

　消費税率の変更は、消費税マスタを変更するので、ある日から突然「８％」が「０％」に書き換わります。レジの時に「８％」で、経理の時に「０％」なら、システム障害になります。

　システム障害といえば、「アクセス数が膨大で、コンピュータがパンクした」が知られていて、それ以外にも「データの齟齬（( )金額が違う）」もあります。

　レジを使った時、レジを使った記録（( )レジファイルのような呼び方をします）を作り、そのレジファイルを経理でも使います。

　ならば、レジファイルに「レジを使った日付」も記録すれば、その日付で消費税マスタから税率や税区分を取得できないのでしょうか？

　もっと簡単に、「この取り引きで使った消費税率」を、レジファイルに含めることもできます。

　「レジシステムは、そんな簡単なものではない」なら、それはなぜなのでしょうか？

　現場を知らない外部の者として、「なぜだろう？」と知りたい気持ちです。

　○　　ゼロは特殊な値（( )３）　……　無いことを表すゼロ

　消費税率は掛け算に使いますから、答えがゼロになることもあります。ビジネスに限らず「計算結果がゼロ」と「そもそもデータが無い」の区別は大切ですね。

　請求書を出す側は「ゼロ円の請求書はおかしい」と思っても、請求書を受け取る方は「請求額がゼロだと確認できた」になります。

　請求書を受け取る側は、支払い忘れを心配します。ゼロ円の請求書が届かなければ「請求書を紛失したのか？」と心配します。

　請求額がゼロ円なら、請求書の代わりに「お知らせ書類」を作成するといったことは、コンピュータの暴走とは別な話です。

　○　　その日から変わる面倒さ（( )１）　……　まずは休日カレンダー

　消費税率マスタの説明の前に、馴染みのある「カレンダー」で、説明しましょう。

　休日は、月日が決まっているもの（( )憲法記念日など）と、月日が決まっていないもの（( )春分の日など）があります。

　成人の日は、以前は１月１５日に決まっていましたが、西暦２０００年以降の現在は１月第２月曜日です。

　私の作る休日カレンダーには、「休日名」「月日」「開始年」「終了年」は、最低限あります。

　休日カレンダーには、成人の日がたくさんあります。１つは開始年が「０」で、終了年が「１９９９」で、月日は「１月１５日」です。

　西暦２０００年以降は、毎年１つの成人の日が設けられます。休日カレンダーで「成人の日」を探す時は、必ず「年」も用います。「年」が「開始年」と「終了年」の間のものを探して、「月日」を取得します。

　天皇誕生日も、期間限定です。現在の天皇誕生日の終了年は「９９９９」にしておきます。終了年が決まった時に、変更するのは、簡便です。

　春分の日は、月日が決まっていません。引き継いだ休日カレンダーでは、春分の日と秋分の日は、計算式が書いてありました。

　その計算式の意味が、私にはわからなかったので、「触らぬ神に祟りなし」として、不可触として扱いました。もし、この部分に変更の需要が生じたら、私は迷わず、成人の日と同じ扱いに変更します。

　○　　その日から変わる面倒さ（( )２）　……　消費税率なら

　消費税率に限らず、日付によって数値（( )金額、率、その他）が変わることがあります。「来月から値上げ」は、よくあることですね。

　私が作る消費税マスタには、「日付（( )開始日）」「日付（( )終了日）」「区分１」「区分２……」「税率」は、最低限あります。

　レジのシステムでは、「スキャンした日」「支払いボタンを押した日」など、どの日付を使うかは、決めの問題です。

　「区分」が複数あるのは、軽減税率などの種類が増える可能性を考慮しているためです。

　軽減税率が設けられた時は、今まで無用だった「区分１」を使うことになるので、プログラムの変更は大変です。

　ただし、「区分１」を使うプログラムは、「日付（( )開始日）」までの期間に用意（( )テストを含む）しておけば、大丈夫です。「日付（( )開始日）」よりも前ならば、「せっかく書いたのに、まだ稼働しない」だけで済みますから。

　軽減税率が、現在の２種類（( )食べるのが、店内か、店外か）から、３種類なら、商品マスタとの連携をすれば、プログラムの変更は、ほぼ無しでしょう。

　コンビニなど、深夜営業の店舗もあります。夜中の０時に、営業中なのに、消費税率を変える必要があります。

　消費税マスタに有効期間の日付があれば、自動的に変わります。日付が無ければ、０時の区切りの瞬間に、「現在の旧マスタ」を「用意していた新マスタ」に交換する必要があります。

　プログラムに、直接「８％」「１０％」が書かれていれば、プログラムの新旧交換も必要です。

　インターネットで閲覧をした経験があれば、「再読み込み」をすると、表示内容が変わります。昨日の画面を開いたままでは昨日の情報ですから、今日の情報を表示するために「再読み込み」をします。

　システムでは、マスタやプログラムなど、あらゆるものを新旧交換する必要があります。インターネットの閲覧で「再読み込み」のようなものです。

　２つの連携したパソコンで、片方が昨日の情報、片方が今日の情報では、「システム障害」となります。

　インターネットの閲覧よりも面倒なのは「新旧交換する順番」もあります。そのため、０時の区切りの瞬間には、障害対応に備え、技術者が待機します。

　消費税マスタに日付があれば、０時の区切りの新旧交換は不要です。「再読み込み」は、いつものレジ操作という、日常業務ですから。

　○　　天地がひっくり返っても

　「天地がひっくり返っても、そんな変更は無い」とまで指示されていたことが、変更されたことは、何度もあります。

　私たちも既に、驚く変更の経験をしています。

　１つは「同じ商品でも、店内で食べるか、店を出てから食べるかで、税率が違う」という軽減税率。

　もう１つは「電車の運賃が、乗車券とＩＣカードで違いがある」です。

　「天地がひっくり返っても」と比較するのは意地悪ですが、消費税率がゼロになるのも、軽微ではない手間でしょうか。

　消費税マスタに「区分１」「区分２……」を設けるのは、「ゼロだから」と「ゼロになる」を区別するためです。

　「税額がゼロなのは、非課税商品に決まっている」というプログラムなら、消費税率をゼロにすると、全部の商品が非課税商品になってしまいます。これでは、経理システムでの仕訳がおかしくなります。

　「税額がゼロだから、非課税商品」と「税率がゼロだから、税額がゼロになる」は、区別が必要です。というより、「税額がゼロだから、非課税商品」は誤りで、「税額がゼロだから、税額を請求しない」なのです。

　古いプログラムでは、ほんの少しでもデータ量を減らすことも大切でしたので、「区分１」「区分２……」をケチって「税額がゼロだから、非課税商品」の判断に依存することもありました。

　実際に私が解析した、保険会社の古いプログラムでは、金額が、なぜか１円ずつ加算されていました。というのは、プログラムのその部分では、金額が不要、カウンターが必要であったので、金額をカウンターとして使っていたのです。

　カウンター用の項目を用意するのをケチケチする時代のプログラムでした。

　金額をカウンターとして使うのは、英和辞典をカップ麺の蓋押さえに使っているようです。

　ケチケチしない現在では、消費税マスタに「区分１」「区分２……」を設けるのが、人に優しいプログラムです。

　「税額がゼロなのに、非課税商品ではない。そんなことは、天地がひっくり返っても、あり得ない」ということが、税率がゼロになることで発生します。

　消費税が無かった頃、新たに消費税が導入されるのは、天地がひっくり返る程の大変さだったと推測します。

　レジシステムから経理システム、その次のシステムの、どこで消費税率をどう扱うのか、端数は切り捨てるのかといったプログラムを作るのは、大変だったと思います。

　しかし、プログラムを作った後、消費税率が変わる対応は、税率を書き換えれば良いと思います。

　当時のことを知る人から聞いた話では、税率の「３」は、プログラム内に書いていたそうです。単に「３」もあれば、「０．０３」だったりします。

　これを、文字列一括置換をすることはできません。プログラム内には、消費税率ではない箇所で「３」の文字が使われているからです。

　私が「消費税率マスタは、使わなかったのですか？」と問うと、「税率が変わる頃には、このシステムは終わっている」という予測だったそうです。

　○　　プログラムは公式のようなもの

　三角形の面積を求める公式は「底辺　×　高さ　÷　２」です。

　プログラマは、この公式を作るのが仕事です。

　レジ店員などは、「底辺」と「高さ」を具体的な数値にします。これが、数学で言う「代入」で、レジ店員はバーコードを機械に読ませることで、代入ができるようになっています。

　簡単に、三角形の面積に譬えましたが、レジシステムではもう少しだけ仕掛けがあります。

　端数処理です。

　消費税では、１円未満の端数が日常的です。これの扱いをどうするか。

　端数を「切り捨て」「繰り上げ」のどちらにするか、コンビニで買い物をする時に「単品で処理」「合計額で処理」のどちらにするか。

　この端数の扱いは、消費税率がゼロになる話とは、別な話です。税率がゼロでも、計算式は変わりません。

　端数処理をどうするのかは、お店によって異なるようです。レシートを見ると、「税込み価格で合計」と「合計価格に税額が付加」といった、いくつかの種類があるようです。

　もしも、法律で「レジシステムでの会計は、単品繰り上げ計算すること」と決まったら、さあ大変です。プログラムの変更が必要ですから。

　経理システム内での端数処理は、ありません。というのは、レジで会計する際に、端数処理は終わっていて、レジシステムから経理システムに渡すデータは、「実際に会計した金額」ですから。

　必要なら、レジで「端数の按分（( )案分）」まで計算し、それを経理システムに渡します。

　これは、電子マネー決済などでも同様で、「実際に会計した金額」はレジシステムで完結し、それを電子マネーのシステムや経理システムが、どのように扱うかは、消費税率がゼロになる話とは違います。

　プログラムの譬えの「三角形の面積の公式」の変更が必要な時と、「代入してはいけない値」は、注意が必要です。

　これは、ゼロ除算のエラー回避だけではありません。

　ある小学校で、公開授業がありました。算数で「割引き」の授業を見学しました。

　そこで、違和感があったのが、「割引き」のことを、教師が「値引き」と言っていたことです。

　割引きは、「何パーセントの割引き」ということです。「セント」は「１００」、「パー」は「割合」で、「本体価格を１００で割って」などの計算をします。

　そこで、本体価格を長い長方形で表現し、パーセントで長方形の長さを短くします。

　授業では計算式を言葉で理解できるように工夫していました。私は秘かに「モノサシで説明してほしい」と思っていました。

　１０センチメートルのモノサシには、１ミリメートルの刻みが１００個あります。黒板の長方形を見ながら、モノサシを持ち、片目で見ながらモノサシの位置を調整する。３０％なら３０ミリメートル（( )３センチメートル）の位置です。

　なんてことを思いながら、「割引きと値引きは、違うぞ」と、違和感がありました。

　割引きは「３０％引き」というように、本体価格を基準とします。

　値引きは「３０円引き」というように、本体価格を基準にしません。

　３０円引きなら、１００円の商品は７０円で買えます。２０円の商品なら、１０円もらえます。……って、そんなことはありません。

　ここで、「値引きなら、本体価格よりも高い値引きはできない」という注意が必要です。これが「代入してはいけない値」です。「代入してはいけない値」は、プログラム（( )公式）の種類によって様々です。

　消費税率がゼロになると、「代入してはいけない値」が発生するのでしょうか？

　○　　担当者は異動しました（( )１）　……　マスタって、なに？

　コンピュータのシステムは、担当者が入れ替わると、後任者が困ることは、少なくありません。

　レジシステムも、これが変更が難しい理由でしょうか？

　というのは、残された資料は、システムを知っている担当者なら理解できて、システムを知らない後任者は理解できないものがあります。

　システム変更されても、資料は古いままということも、少なくありません。

　ということは、消費税率の変更対応をすると、「この変更が、未知のカラクリで、想定外の障害になるのではないか」という懸念があります。

　システムを作った人がいれば、聞いて確認することもできます。しかし、不全な資料が残っているだけでは、実際のプログラム変更よりも、確認作業だけで大きな手間です。

　このような、後任者に優しくないことも、大変な理由でしょう。

　実際、後任者に優しくない実例として、あるシステムの変更対応をした際、「恐怖の変更対応の傷跡」に出くわしたことがあります。

　それは、マスタを無視した変更対応でした。

　その前に、「マスタって、なに？」のお話し。

　マスタの説明には、「商品マスタ」を例にしましょう。

　商品のバーコードは、「商品の一覧表」を見るためのものです。商品の一覧表が、商品マスタです。

　レジでバーコードを読み取ると、機械が商品マスタを読んで（( )商品の一覧表から探して）、値段や名前などを、レシートに記入します。

　スナック菓子などのバーコードには、商品名も値段も含まれていません。

　書籍では２段のバーコード、スーパーマーケットでは店内製造の総菜用のバーコードがあり、値段が含まれているものもあります。

　ここでは商品マスタの説明ですので、スナック菓子のバーコードだと思ってください。

　商品マスタからは、軽減税率の区分も参照しますので、消費税マスタから税率（( )現在なら「８％」と「１０％」の、どちらか）を取得します。このように、マスタ同士を連携することもあります。

　店舗によって、レシートに印刷される値段と商品名が違うのは、「商品マスタはお店が作る」ためです。バーコードには商品名も値段もありません。

　○　　担当者は異動しました（( )２）　……　正しく稼働すればいい

　マスタを無視したプログラム変更に出逢いました。前述の「恐怖の変更対応の傷跡」です。

　システム作成者がこのプログラム変更を担当したのか、作成者と変更者が違うのかは不明です。「とにかく、今、正しく稼働すればいい」という変更がされていました。

　ここでは、わかりやすく商品マスタに譬えますが、実際はレジのシステムではありません。

　金額が変わるなら、商品マスタを変更します。ところが、そのプログラムは、商品マスタの金額をレシートに印刷する時に、「このバーコードは、特別に、この金額」という仕掛けをしていました。

　確かに、プログラムを動かせば「正しく変更された」と同じ結果になりますが、「システムなんて、わからん」という指示者（( )管理者）を騙しているようにも思えます。

　すると、後任者は、こんな例外的な箇所が他にもあるかもと、プログラム全体の確認が必要になります。なぜ、このような変更方法なのか。

　マスタ変更が不可能だったのか、極度に厄介だったのか、それとも、マスタ変更を知らなかったのか。担当者がいないので、確認もできません。

　調査したところ、例外的な対応にした理由は、見付かりませんでした。

　偶然、このような箇所を発見できましたが、受け継いだ資料には記されていません。

　消費税率の変更も、簡単にマスタを変更すれば良いかと思えば、実は厄介なものかも。

　○　　そういうもんではない

　システム改修で、よくあるのは「仕様変更の度に、ツギハギだらけ」となり、怖ろしくて改修できない状況です。

　ツギハギとは違う、「そういうもんではない」という困難もあります。

　軽微な新規プログラムの作成という仕事がありました。既存システムに、新たなプログラムを追加する仕事です。

　既存システムを、レジシステムに譬えれば、レジの機械の中にはレシート用のデータがあり、そのデータを使って経理システム用のデータを作り、そのデータを使って財務システム用のデータを作り……という、データのリレーがありました。

　これはまずい。これまでも、何度も似たようなシステムに出逢い、どれも悲惨な状況だったのです。

　話を聞くと、このまずいデータ連携の成り立ちは、他と同じ理由でした。

　元データＡがあり、それを使って、データＢを作るために、プログラムＢを作ったというのが、最初です。

　その後、データＣを作る需要があり、発注者からの「既にデータＢがあるから、それをちょこっと工夫すれば、データＣが作れるだろう」という指示で、プログラムＣが作られた。

　次は、データＣからデータＤを作るための、プログラムＤが作られた。そんなデータ連携が、部署内で稼働する。

　これまでの経験から、途中のデータに仕様変更があれば、後続データの全体に影響し、ただごとではない面倒さになります。

　「ちょこっと工夫すれば」には、前述したような「税額ゼロは、非課税商品として扱う」という工夫もあり、システム全体に影響します。

　そもそも、発注者がコンピュータのシステムに詳しくないこともありますので、システム設計のプロとして、おかしな指示を受けたら「それは、お勧めしません」と提案すべきです。

　そんな発注した担当者が異動しており、受注者もいないので、真相は不明ですが、もしかすると予算や納期の都合から、「それは、お勧めしません」の提案が却下されたのかも。

　さて、私が受けた軽微なプログラム作成ですが、データＤからデータＥを作るための、プログラムＥです。

　軽微といえども、その部署で把握できるシステム全体のデータの流れを調べます。すると、受注したプログラムは「プログラムＥ」という位置付けだと判明しました。

　現状のシステムの調査で受け取ったのは、いくつものプログラムそのものと、７０ページ以上の手順書です。しかも、手順書は改定がされていないもので、改訂版は実作業をする人の頭の中にあります。

　当然ながら、「それは、お勧めしません」と提案しましたが、指示に従うように強要されました。私はプロの義務として提案しますが、軽微なプログラムは私物でもなく、私の芸術作品でもありません。

　納期までの日程中に、途中のプログラムＣでの不具合が発生しました。追加注文で、不具合の原因究明やデータ復旧なども依頼されました。

　現状システムの調査といっても、あらゆることの把握はできません。そのため、質問すると、返答は４時間後で、「フラグが立つはず」でした。

　「フラグ」とは「旗（( )フラッグ）」の意味で、目印のことです。電話番号では「スマホ番号フラグ」、レシートでは「軽減税率フラグ」のような目印です。

　プログラム内で、「フラグ」「フラッグ」「ＦＬＧ」「ＦＬＡＧ」「ＦＲＧ」「ＦＲＡＧ」など、フラグっぽい名前を、全角と半角、大文字と小文字で探しても、存在しません。

　仕方なく、翌日に再度の問い合わせをすると、「フラグが立つ」は「日付欄に記入がある」の意味でした。

　そういったこともあり、システム全体の作り直しを提言したのですが、そこでも、これまでと同様に、最初の返答が「そういうもんではない」でした。

　色々あったものの、依頼内容を終わらせて、手順書を返却しようとしました。社外秘であるので持ち帰りはできませんし、なにより、実作業をする人の頭の中の改訂版を反映したために、おびただしい手書きがあるからです。

　ところが、せっかくの手書き入りの手順書は、廃棄処分です。

　どうやら、消費税率がゼロになるのが大変なのは、「そういうもんではない」という文化のせいかも。

　○　　後任者に優しいシステム

　プログラムシステムの依頼があり、打ち合わせで、マスタの話になりました。

　電話での打ち合わせです。リモート会議でもなく、対面の会議でもありません。

　商品マスタの話で、「大分類」「中分類」「小分類」といった項目があります。大分類は「食品」「文具」「医薬品」など、中分類は食品なら「お菓子」「食料品」など、文具なら「用具」「消耗品」など。

　商品マスタの設計で、私は、エクセルの一覧表にするよう、提案しました。Ａ列に「食品」の行がたくさんあり、Ｂ列に「お菓子」の行がたくさんあるというような、無粋なものです。

　というのは、このシステムを扱うのは小さな部署で、コンピュータに詳しくない人ばかりだったためです。無粋なものですが、そのエクセルなら、見ればすぐに理解できて、商品の増減の対応も簡単だからです。

　発注者は「もっと、格好よく、システマティックに」の要望を出したので、その場で３つのシステム例を話しました。すると、発注者は混乱したようです。

　私は言いました。「電話口では、混乱しながらも、ご理解できたと思いますが、今ここで、誰かに説明することはできないでしょう」

　発注者は「難しいです」と返答しました。

　「説明が難しいので、商品マスタを保守（( )商品の増減対応）するための手順書が必要です。後任者が手順書を読んで、中途半端な理解のままで作業すると、誤りを誘発します。後任者が、コンピュータに詳しいとは限りません」と説明しました。

　格好いいマスタなら、リレーショナル（( )関係データベース）といって、「大分類の表」「中分類の表」など、いくつもの表を作って連携するなどの方法があります。いくつもの表というのは、エクセルでは隣のワークシートということです。

　これなら、冗長に「Ａ列に食品がたくさん」といったものではなく、格好いい。けれど、いくつもの表があるので、うっかりミス（( )ヒューマンエラー）を起こさないように慎重にする必要があり、コンピュータに詳しくない人は尻込みします。

　商品マスタの保守のために、「保守用の画面（( )フォーム）」を作る方法なども、システム例として話しましたが、後任者に優しいシステムとしては、無粋なシステムの方が優れています。

　システム設計では「誰が使うのか」「誰が保守するのか」も考慮します。人に優しいシステムとは「使う人に優しい」「保守担当の後任者に優しい」です。

　レジシステムは、消費税率の変更もプロが行うので、無粋ではなく、格好いいシステマティックでしょう。けれど、プロでも難しいのは、それなりの理由があるのでしょうか？

　○　　柔軟なシステム

　新しいシステムを作る際は、将来の変更に柔軟であることを考慮します。

　わかりやすく、「エクセルで、レシートのようなものを印刷する」というプログラムを作るとします。

　レシートのレイアウト（( )デザイン、配置）が変わり、「営業時間」と「電話番号」の位置を変える、新たに「ＵＲＬ」を追加する変更が発生しました。

　日常でＰＣ操作をする人は、エクセル操作はできますが、プログラムを知りません。ワークシート関数も、ちょっと知っている程度です。

　この場合、プログラマに変更依頼をすることが多いのですが、コストが掛かります。

　将来の変更に柔軟ならば、ＰＣ操作をする人が、自由にレイアウトを変更できます。プログラムは変更しません。

　資料には、レイアウト変更の方法も書いてあるのですが、せっかく担当者が近くにいるのだからと、資料は読まないようです。

　資料を一緒に読みながら、一緒に変更すると、「こんなに簡単に、レイアウト変更ができるのか！」と、一様に驚かれます。

　エクセルのプログラムどころか、関数も知らない人でも、レイアウト変更が簡単だからです。

　あちこちの発注元のオフィス内で仕事をしますが、元ＳＥ（( )システムエンジニア）という部長が、離れた席からわざわざ私の席に来て、延々と驚嘆の言葉を言ったのは、こちらも驚きました。

　というのは、素人が変更できる柔軟性でありながら、事故にはならないカラクリですから。

　レジシステムの変更は簡単だが、技術者（( )プログラマ、エンジニア）が少ないのが、対応に長期間を要する理由とも考えられます。

　レジのデータは、後に経理で使われるので、「素人が変えるだけではなく、専門家の確認が必要」という、重大なものであるのは、理解できます。

　「柔軟システム」「硬質システム」とは、この文書での造語です。

　レジシステムは、このような「将来の変更に柔軟なシステム」ではない、硬質なシステムなのでしょうか？

　柔軟なシステムのための軽微な面倒を回避し、「どうせ、変更する頃には、自分は異動している」という先送りをされているのが多いのでしょうか？

　できれば、「硬質システムだから」という理由では、ありませんように。

　【終わり】

---

◆　ご感想を頂けると嬉しく思います。ログイン不要ですので、お気楽に一言をお願いします。

◆　「評価」はログイン必要ですが、「感想」はログインせずに、どなたでも書けます。