ＩＢＭ　ＡＳ４００とパソコンを愛するＳＥのブログ

●印刷処理

今日の会議でまたまた上司がベンダーを困らせる一言
この印刷処理用のミドルウェアは使えない
つまり、要求することがこのミドルウェアでは実現できない・・・てこと

●使えない

なぜ使えないか・・・
上司によると全面フル印刷が出来ないからってことだ
しかし・・・もともと親会社では全面フル印刷なんかしていなかった

印刷業者に発注してプレプリントされた用紙に
プリンターで必要なところだけを印刷する方式だった
なので、そのような要件を提出していたから
ベンダーはそれに適したミドルウェア（但しベンダーの製品：商売上手）を選定
親会社に承認をもらったうえで、それを利用してシステム構築

●何故か

しかし、今頃になって
全面降フル印刷がひつようなのに、このミドルウェアでは対応できない
なので、使えない・・・って言いだした

もうね、ベンダーさんのうろたえようが、Zoomを通して
顔は移っていないけど、声の調子、言葉の間合いなどから
ずーーーんって伝わってきた

●どんな風の吹きまわし？

しかし、今更どんな風の吹きまわしか？

我が上司が全面フル印刷が必要だとする理由としては
　●プレ印刷用紙に文字だけ印刷すると、カット紙の場合は印字ずれが起こる
　●印字ずれが起こったら、チェックして再発行しなければならない・・・
　こんなことをしていると日が暮れる

●何を今更

はーーーーっ？
何を今更

今年の初めに私が言ってたことじゃん！
その時は我が上司
　●キチンとセットしたら印字ずれなんて起こらない
　●多少ずれるかも知れないが、チェックとか再発行にかかる手間は大したことない
って言ったいたのに

なんか、別人格になったような
もしかして、私の呪いが功を奏したか？

●ショッキングな事

昨日は・・・だって、涙が出ちゃう・・・真面目なシステムエンジニアだもん！・・・こんな事がありました。

でも、それ以外にも

• 超難解な特殊コード紐づけ作業が振り出しに戻る
• 息子と夕食を食べにロッテリアに行ったんですが・・・

な事がありました。

●超難解な特殊コード

これも、目が・・・でお伝えした通り、
とても複雑で神経がいる作業なんですが
昨日、その作業を手伝ってもらう専門家と話した結果
その専門家曰く

だって
いやいや、あなたの紐づけたのを元に一週間かかって
専門家でない私が一生懸命紐づけたのに・・・

って思いましたが、専門家の意見を優先すべきと考え
私が目を皿のようにして行った作業がご破算になりました

●息子との夕食

昨晩、大学から帰って来た息子を最寄りの駅で拾って、外食することにしました。
だって、精神的にへとへとで、夕食を作る元気も無かったんですから

さて、どこに行こうと考えていたところ、
屋根付きの駐車場があるところが良いと・・・
だって、雨が結構降っていましたから

そこで、イオンに行くことにしました。
イオンなら、店内に割と多種類の食べ物屋が入っているから・・・
で、イオンに行くと決まって・・・ロッテリア

●新しいもの好きが

災いしました・・・
店内入り口に、『モバイルオーダーはこちらから』ってチラシが貼ってあったので
やってみることに・・・
ＱＲが付いていたのですぐに登録できましたが

そこで、注文したのが 19:16
普通のカウンターでオーダーしたらものの5分で食べられるので、
それよりも早いか遅いか分からないけど
待ってみよーと

でもね・・・待てども待てども呼び出してもらえない
その間、別のお客さんは、注文して５分ほど待ってハンバーガーなどを受け取っています
これはさすがにおかしいかな？

しびれを切らして、20分ぐらい待った時
店員の若い女性に
『モバイルオーダーしたんですが、まだでしょうか？』と尋ねました。

すると『もうしばらくお待ちください』との返答
もうしばらく待つか・・・って待機継続しました。
でも・・・その女性店員、何をするわけでもなく・・・

もう20分が経ち、我慢の限界
カウンター内の若い男性にクレーム
『モバイルオーダーしてからもう40分経つのに料理を提供してもらっていない。』と
その店員『少々お待ちください』って言って中に引っ込む

レシートみたいなのを持ってきて、
『こちらでしょうか？』

オーダー、ちゃんと通ってるやん！
でも、40分経った今でも料理の準備が出来ていない

●ヘボな事故対応

これは明らかな契約違反
不文律ではあるものの、混んでいるのならいざ知らず
客もいない状態で40分待たすのはね・・・

なので、その若い店員に対して
『なぜこのように40分でも待たされたのか、その理由を教えてほしい。今後どのように是正するのか？』と尋ねたところ、
『申し訳ありません。モバイルオーダーが始まったばかりなので』と
分けの分からない言い訳

これは理由ではないよね。

●もう来ない

と私は思いましたが、息子は『今度は受付で注文しよう』とプラス思考
とりあえず、ロッテリア本部に状況報告メールを送りました。

このような場合に店側に必要とされる対応は
�@まず、心から謝罪すること
�Aなぜ、そのような事が起こったか原因追及し、説明すること
　すぐに原因が分からない場合は、後日報告することを約束すること
�B同じような事が起こらないように是正すること
　どのように是正したかも報告すること

ここまで、すればかなりのお客さんは『もう来ない・・・』とは思わず、
より店の事を好きになってくれるでしょうね。

●今日も会議で

苦しかったり悲しかったりする場面がありました・・・
当社のシステムで顧客受けが非常に良い
（そのサービスが無ければ取引停止するとまで言わしめる）サービスを
新システム（グループ統合システム）で実装してもらうよう交渉してきました。

ただ、初期の（親会社のシステム部門で勝手に決めた）仕様では、対応できない機能があり
ベンダーのチームリーダーさんが申し訳なさそうに
『現在の納期では、この機能については対応できない』
と、言われていました。

もちろん、ベンダーさんが悪いわけではありません。
対応できないような狭い領域で初期仕様を提示した親会社のシステム部門
とりわけ、我が上司に最大の責任があります。

とはいえ、この機能を現在使用している４顧客について
営業から謝罪に行ってもらって代替サービス（があればですが）に
切り替えてもらうしかないでしょう。

もし、顧客が納得しなければ
可哀想な営業さんが、日々営業所で手作業を行わなければなりませんね

●数学のいろはを解さない上司

また、文字として記録されている数値（ややこしい表現で済みません）
プログラムテクニック上、これの大小判定を行う時に、〜〜〜未満が問題となります。

文字を私たちが見るだけなら大小判定は簡単に出来るでしょう。
例えば、　１０未満と、１０では、どちらが大きいか？と尋ねると
恐らく、100人が100人とも、１０の方が大きいと答えるでしょう。

しかし、コンピュータープログラミングで判定しようとすると
１０未満の未満をどのように扱おうかと・・・という話になります。
ちなみに、Excelとかで、試してみられたらいいかなって思います。

Excelに、" = 10 > 9 " と入力したら、即座に、 TRUE （あってるよ）って表示されます。
しかし、" = 10未満 > 10 "と入力したら、ボワーンという音とともに
この数式には問題があります
ってエラーダイアログが表示されます。

●説明するのに疲れた

このような場合、どうするかって言うと
10未満は、10より小さい中で一番大きい数字と解釈します。
ここから、実用数学の出番です。

数学的には、９．９９９９９９９９９９９９９９９９９９９９・・・・になるんですが、
コンピュータプログラムで扱える数字は有限の桁数です。
工夫しなければ Excel で 整数部 + 小数部 で 15〜16桁です。

その他のプログラミング言語でも大抵はそのぐらいです。
すると、１０より小さい中で一番大きい数字は
１０　−　０．００００００００００００００１　ぐらいです。

つまり、９．９９９９９９９９９９９９９９９ですね。
これと、１０を比較すると
１０未満　＞　１０　≒　９．９９９９９９９９９９９９９９９　＞　１０
なので、この式の値は、 FALSE となります。

めでたしめでたし！

しかし、この考え方を分かりやすくかみ砕いて説明しても
我が上司は、１０未満は　１引いて　９として比較したらいいじゃんって

いやいや、そうじゃないよって、あれやこれやで説明しても
自分が正しいと主張を曲げない我が上司

●後は野となれ山となれ

もう、さじを投げました



どうにでもなったらいいやん！
聴く耳を持たない上司に何を言っても無駄だから

●新システムのバーコード

先日、新システムから印刷出力されたバーコードの品質が悪いとお話ししました。
バーコードの仕様上、印刷品質が悪いと
誤読発生頻度が増加する　⇒　致命的
読み取りエラー発生可能性が増加する　⇒　やっぱり致命的
といいことありません。

●今日届いたバーコード

しかし、今日になってＰＤＦで送られてきたバーコードの品質は
文句がつけられないほど美しいものでした。
それ以上、良くできないと思われるほど高品質

●もしかして

ベンダーさんの誰かが、私のこのブログ記事に気づいて
改善したのかな？
とも思いましたが

まさか、そんなこともあるまいと

●種明かし

印刷する時は、プリンターの性質・解像度に応じて出力イメージを変更する必要があります。
それは、インク（もしくはトナー）が、白と黒の境界線が明確に仕様通りに印刷できるかと言うと
そうなりません
若干黒の方が膨張します。
インクジェットならなおさらです。

これを考えて、印刷イメージを作成する時には、黒と白のバーの幅は、黒の方を若干細めにすると
実際に印刷されたバーコードは美しく仕上がります。

今回の新システムからのバーコードはＰＤＦなので
全然滲みません
このため、美しく、白と黒の境界がはっきりと出力されていたわけです。

実際に紙の上に印刷すると、このように綺麗に印刷できるとは限りません・・・
その辺がノウハウの差でしょうか・・・

●本来、新システムに求めること

システムを新たに作るときには
どんなシステムにしたいかをまず決定します。
どんなシステムにしたいかは

• �@現行の運用は踏襲する
• �A現行の運用で悪い部分は改善する
• �Bこれまでシステムの都合で出来なかった昨日を追加する
• �C将来的に事業拡大する場合に対応できるようにしておく

だと思うんですよね。
しかし、今、当グループで進められているシステム構築プロジェクトでは

• �@現行の運用は踏襲する
• �A現行の運用で特に悪い部分は改善する

以上・・・みたいな感じです。

●実際に新システムを構築したら

ベース部分は親会社で勝手に決められていたので

• �@親会社の現行の運用は踏襲する
• �A親会社の現行の運用で特に悪い部分は改善する

となっており、先行して独自に発展した当社にとっては
看過できない不具合仕様が存在しています。

●修正できないひずみ

これは、�@現行の運用は踏襲するって言うのを勧めすぎたことが原因です。
親会社で50年前に構築されたシステムの不具合に対応するため
マスター設定で無理くり回避してきました。
今回新システムにマスター移行する時に、周辺システムとのインターフェース上の問題で
無理くり回避はそのまま
という方策がとられました。

このあまりにも美しくない運用が
新システムにそのまま引き継がれたために
新しい機能を実行するうえで

致命的な問題を内在することが今日分かりました。

●ひずみがひずみを呼ぶ

この致命的な問題を解決するために
マスター設定だけでは解決できず
結局、プログラムコードを変更することを余儀なくされます。

ただ、ち密に計算されたシステムの一部に
ハードコーディングを施すと
システム全体として、その各所に多少の影響が発生します。

いうなれば『ひずみがひずみを呼ぶ』わけです。
稼働後２ケ月も経過せずに
既にひずみが拡大しつつある

最初は全てマスターで全システムの設定が行えるようにとの設計思想でした。
それも僅か２ケ月も経たずに潰えた・・・

このシステムの寿命はいかほどか・・・

●商品バーコード

恥ずかしながら、新システム（グループ統合システム）で使用されているバーコードを
初めて見ました

今まで、ベンダーさんが、バーコードリーダーで読み取り確認をしているとの事を信じていたので
何ら疑うことなく、印刷されたバーコードの品質を検証することもありませんでした。

今朝、たまたま不具合の報告文章の中にバーコードが添付されていたので
初めて目にしたわけですが
見てビックリ！

品質が、松竹梅の梅以下でした
冒頭の写真は、当社で印刷しているバーコードを拡大したものと、新システムで印刷しているバーコードを拡大したものです。

台紙が異なるので、バーコードの背景の明るさ（暗さ）が異なりますが、これは多分品質には関係ないと思われます。

●バーコードの仕様

グループで使用しているバーコードの種類は
ＩＴＦ (Interleaved 2 of 5)
桁数は、10桁、12桁、14桁の3種類です。

さて、 ＩＴＦバーコードの仕様では
細いバーと太いバーの幅の比は
　USS-I2/5の規格では、 1:2.2〜1:3
　JIS-X-0502の規格では、1:2.5
と定められています。
また、細いバーの最小幅は
　USS-I2/5の規格では0.191mm
　JIS-X-0502の規格では、0.254 mm 〜 1.22 mm
となっています。

●バーコードリーダーについて

バーコードリーダーはいろいろなメーカーから製品として販売されています。
しかし、バーコードの仕様の解釈はまちまちで、
多少、上記の仕様から外れていても何の問題もなく読めたりするメーカーの製品もありますし、厳密に仕様通りに印刷されていないと読み取りエラーとなったり、誤読したりする製品もあります。

ユーザーの立場から言わせてもらえれば
・印刷が多少乱れていても読み取って欲しい
・誤読は出来るだけ少ない方がいい（理想的には誤読０）
と相反する要求をしてしまいます

バーコードリーダーとしては、どちらを優先するかによって
・仕様通りにしか読まない製品
・仕様を多少外れても読む製品
に分かれるのだと思います。

ただ、バーコードを印刷するアプリを開発する立場としては
仕様を確実に満たした印刷
を目指すべきでしょう。

当社では 2000年以前、ドットプリンターでバーコードを印刷していた時代からの印刷ノウハウがあります。

そこには、プログラムで設計した印刷イメージ通りにプリンターは印刷しない・・・
これがあるときは見た目が良く、ある時は弊害になるのです。
この点を良く認識して、印刷アプリを開発しないと
ユーザーの不満
を招いてしまいます。

●プリンターの限界

昔のプリンターはドットプリンターが主流で、ドット密度も良くて 180 dpi ぐらいでした。
180dpi とは 1 inch の長さに 180個の印刷ドットが並ぶって意味です。　解像度とも言い換えられます。
すると、 1ドットはどのくらいの大きさかと言うと、0.141 mm ぐらいです。

さっきのバーコード仕様の最小幅と微妙に異なりますよね。
アプリで、最小幅を 0.191 mm として設計したとします。
でも、1ドットが 0.141 mmでは１本の細バーには足りません。
2ドットで印刷すると、0.282 mm になってちょっと大きすぎます。

すると、印刷アプリ側で、 2ドット幅 0.282 mm を細バーの幅として設計する必要が出てきます。
これでは、バーコードの長さが少し長くなっちゃうますよね。
ユーザーの方から、バーコードが大きすぎるって文句を言われたらどうしましょ？

手詰まり
になります
しかし、往々にしてあります。

ただ、現代のプリンター、特にレーザープリンターでは
高解像で印刷できるものがほとんどです。
600 dpi ぐらいあれば 1ドットが 0.042 mm ぐらいですから、

最小幅のバーでも5ドットで 0.21 mm と、わずかに 0.02 mm の差にしかなりません。

●元に戻して

まぁ、バーコードに関するうんちくはこのぐらいにして、話を元に戻しましょう。

ITFを構成するバーは、
　白い細いバー
　黒い細いバー
　白い太いバー
　黒い太いバー
の４種類です。
そうです、黒いバーと黒いバーの間も情報を担う白いバーなんです。

これが曲者です
ドットプリンターでは堅調に表れるんですが
黒いドットと白いドット（印字しない）を交互に印刷するときっとこうなります。

ドット列の２番目にあたります。

なぜ、こうなるかは、ドットは正方形ではなく、丸に近い形をしているからです。
このイメージでは、真ん丸にしていますので、ドットを１列に並べて線にするときは、
ドット密度による１ドット分の直系の円では、線になりません。なので、多少大きめです。

この大きさで、１ドット置きに印刷すると点線にはなります。

しかし、この点線を縦方向につなげると、黒い細いバーと白い細いバーが出現しますが
黒い細いバーの方が白い細いバーより太くなります。
同じ１ドットなのにね。

これがプリンターでバーコードを印刷する時の落とし穴になります。
この落とし穴にはまったのが新システムのバーコード・・・です

冒頭の画像をクリックして、表示させてください。
そして拡大してみてください。
その印字品質の差が歴然とします。

●落とし穴にはまらない技

当社では、この印刷時の落とし穴にはまらない技を随分昔から使っています。
なので、ドットプリンターでもレーザープリンターでも
綺麗に印字出来ています

もちろん、新システムの要件定義時にこれらのノウハウは提供しています
でも・・・伝わってないんですね

●上司の指示通り

昨日の会議で上司から言われた事
難解な方の商品コードの紐づけを先にやっとけ
と、言うことで、その商品担当者と相談して

まずは、私の方で紐づけ作業をすることにしました。
だって、その担当者さん・・・夜勤ですもん
昼に打合せするわけにはいかないですもんね
それじゃ、夜中？
いや、それは私の生活が崩れるだけでなく、家族にも迷惑をかけるから

●超難解な紐づけ

そこで、超難解な特殊商品コードの紐づけをまずやろうかなって
やりはじめました
さすがに超難解・・・区分としては

Ａ：一般
Ｂ：特殊
Ｃ：超特殊
となります。

●朝からずっと

もう、朝からずーーーーーーっとしています。
Excelファイルに当社とグループのコードを並べて神経衰弱

本当に神経が衰弱しそう

●頭が

というよりか、目を皿のようにして見比べているので
やっぱり目の疲れが、肩こりとか頭痛に変換されちゃいますよね
なので、頭痛をほとんど感じたことのない私に頭痛が襲い掛かってきています。

労災でるかな？

●昨日の会議にて

商品コードの紐づけ作業　再始動キックオフミーティングが有りました。
そこで、我が上司から
『一週間に一度、一時間で、作業を行ってきたが、簡単な商品についてだけしか出来ていません。』
『今年10月末までにすべてを完了させなければなりません。』
『これからは本気モードで作業していきます。』
と発言していました。

●本気モード

これからは本気モードだそうです。
かなり切羽詰まっているんですね。
しかも、7月末までは上司は商品コード紐づけ作業に参加できないとのこと

●通常領域は

上司は8月から参加
その時から通常領域の商品のコード紐づけ作業を行う
それまでは

私に、複雑な領域の商品コード紐づけを行っておくようにと
えっ？
それって、どーいうこと？

●言葉だけ・・・かも

これから本気モードで行くって言っているのに
7月末までは全然？
今までは本気じゃなかったん

どんどん信じられなくなっていく

●属人化を避けるために

ずっと前・・・
新システムを構築する前に聞いたこと
属人化を避けなければならない

確かに、属人化が進むと、
・その人が休むと、その時は業務が進まない
・その人が退職すると、致命的　⇒　確実な引継ぎが必要
なので、業務は属人化を避ける事が重要だと

●システム構築の属人化

システム構築についても
属人化を避ける必要がある
このために、システム構築は外注する

ってグループ会社と統合する前、グループ会社の総務部長が言っていました。

●平常業務の属人化

平常業務については、
ある業務が、特定の人だけしか出来ないような事が有ったら
これは、企業にとって大きなアキレス腱になります。

この意味ならば属人化を避けるのは非常に重要だと言えます。

●混同してたんだ

しかし、システム構築については特殊技能に当たります。
システム構築を全ての人が出来るなら
私みたいなシステムエンジニアって言う職種は存在しないわけです。

なので、システム構築について属人化を避ける・・・なんてことは
出来ない
わけですよね。

属人化しないシステム構築って
しょぼいものしか出来ないんでしょうね

混同してたんだー！
グループ親会社の総務部長
でも、その流れで現在のグループ統合システムを作ろうとしているんですよね。

なので、グループ統合システムは〇〇いんだー

●焚きつけ

今日も会議がありました。
その中でいろいろな事が議題として挙がってくるんですが
私に関係のあるもののうち、商品コードの紐づけ問題があがりました。

元も、我が上司が中心となって、週に一回一時間ずつ作業を行ってきました。
しかし、１年たっても作業率は１割程度。
我が上司、今日の会議で、週に一回一時間ずつやったから７００品目出来ている。

はーーーーーーーーーーっ！
バッカジャネーノ？
あと６３００品目について紐づけを完了させなけりゃならないのに
簡単な方の７００を１年もかけて、７００も出来ているだとー！

残りの６３００品目分については、１０月末までの４カ月半
つまり、今までの２４倍のスピードで作業しなければならないわけです。
週に１時間ずつやってたら、２０３０年が到来しちゃう
つまり、週に２４時間は最低行わなければならないということです。

週労４０時間の昨今、半分以上を紐づけ作業に費やさなければならないわけです

●動かないお尻にロケット

２週間前に我が上司が切羽詰まってると宣っていました。
切羽詰まっているって言葉の意味わかっとんのかー？
って思うほど、全然動かない！

なので、今日の会議で
〇〇部長は、紐づけなんて低レベルの作業を行わずに、私らのような部下への指示と、関係部署への協力要請を行って、報告だけ受けたら良いんです。
って言ってあげました。

私にとっては最大限のやさしさです

●はてさて、どうなることやら

なんで、上司にこんなことまで言わなければならないんでしょう。
これまで疲れさせてこられましたが、
ほんと、今日はとことん疲れました。

会社でストレスチェックを行いましたが、
強制的に医師の相談を受けさせられるかも

●リーダーに必要なこと

我が上司、週一回一時間の紐づけ作業で
自分がExcelのシートを開き、両社の商品コード表を見比べて
有っていると思われるところにコピペ

しかも、ショートカットキーを使わずに
私は、どれだけイライラしていたことか・・・
なので、その意味でも事務作業なんかは事務作業に長けた部下に任せろって

その方がどんだけ早いか