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

●またまた

昨日の会議でも
またまた
おかしなことを言っていました

●くっつける？

システム間情報共有のためのインターフェースファイル
様式はｘｍｌなんです。

それはそれでいいんですが、
トランザクションを送付する前に
新たなインターフェースファイルが出来ると

送受信システムは、その出来上がったファイルを
くっつけるんです
単純に・・・

●おかしくなったって

で、昨日の会議では、くっつけたファイルを読み込もうとすると
エラーで読み込めないということを発言されていました。

●豆鉄砲

えっ？
それを聞いてて、私は豆鉄砲をポンポンポンと食らった鳩みたいになっていました。

なぜかと言うと、xmlファイルって、先頭にヘッダー情報があるんです。

上の例では、赤字の部分がヘッダー情報で、青字の部分がデータ本体です。

この例は、特定健診で使用しているxmlドキュメントで本体部分は折りたたんでいます。

さて、このファイルを単純にくっつけると・・・・

になっちゃいます。

赤字のヘッダーが２回出現しています。
これはｘｍｌの仕様に合致しないため、読み込むときにエラーとなります。

こんなことを普通に行って、エラーが出たーって会議で言ってます。

●ISO

ISOってご存じですか？
ご存じない方は、ネットで調べてみてください。
かなり重要な概念です。企業とかにとっては

トラックの車体に、ISO14001認証取得とか表示されているのを見たことがありますよね。
このISOとは
International Standarization Organizationの頭文字をとっています。
国際標準化機構
の略ですね。

私の会社でも、グループの各社でも、必要な認定や認証を取得しています。
ISO15001
ISO27001
はおそらく認証を受けている企業も多いでしょう。
ISO15001は個人情報保護マネジメントシステム
ISO27001は情報セキュリティーマネジメントシステム
についての規定です。

私のグループ各社では、ISO15189の認定を受けています。

●ISO要求事項を知らない

しかし、昨日の記事でも書きましたが、
グループ統合システムの仕様を決めていくうえで
明らかに、ISO要求事項に違反しているやろー！って事が決定されようとしている場合には
口を出さずにはいられません

もし、システムがそのまま構築されてしまって、毎年の審査（定期審査、更新審査、サーベイランスなど）で要求事項に適合していない事項があれば、適合するように是正を求められ、決められた期間内にそれが実施できなければ認証、もしくは認定を取り消されます。

●無視してどーすんの？

しかし、ISO要求事項にはこう書いてあるからって指摘したところ、２回目の指摘（午前中の会議だけでね）をしたときに、
上司から『馬鹿みたいにＩＳＯがどうのこうのっ言って』って言われて・・・

もう、ブチ切れたので、
Zoom会議だったから、チャットにて、『今後ISO要求事項については申し上げません。』と送りました。

●認定取り消し？

と、すると・・・
もし、ISO要求事項を満たさない仕組みが構築されちゃったら・・・
そして、ISO審査とかで、不適合（要求事項を満たしていないから改善しなさい）って指摘を受けたら・・・
それが実現できなかったら・・・

認定取り消し

みなさん、例えば、ある企業が個人情報保護をしていますって事で、プライバシーマークの認定を受けているとします。
みなさんは、そこから通信販売で日用品を買っているとします。
当然、通信販売ですから、名前や住所・電話番号・ひいてはクレジットカード情報などをその企業に預けているはずです。

その企業が、プライバシーマーク認定取り消しを受けたらどうでしょう？
その企業から続けて購入したいと思いますか？

馬鹿みたいにＩＳＯがどうのこうのっ言って・・・じゃなくて
馬鹿みたいにISO要求事項を知り、それに従うようにシステム構築しなければならないんです。

我が上司・・・大丈夫か？

しかし、認定取り消しされたら会社自体の存続が危ぶまれるから、そんなことにはしたくないですがね。

●進んでいない工程

今朝も会議がありました。
グループ統合システム開発に関する当社に絡む進捗会議です。

そこで出たのが以前にもこのブログで述べた商品コードの紐づけ

前から大変な事をしているのに、その意識が全くなかった上司・・・
今更ながら、来年3月末までに完了させなければならない・・・

として、私に丸投げ

今年の4月から急がなければいけないよって私は伝えてきたつもりなのに
聞く耳を持っていなかった我が上司・・・
細々と週に一回作業会議を開いて・・・

そんなんで、できるわけないじゃん！

以前にこのブログで述べた商品コードの紐づけ関連の記事（絵をクリックしたも読めます）
記事(2021/11/20)：新たに追加されたタスク
記事(2021/11/17)：商品コードの持ち方が違うと致命的
記事(2021/11/15)：困難を極める･･･大ピンチやー！
記事(2021/10/17)：システム間インターフェース

●尻に火がついている

今朝の会議で、我が上司は
尻に火がついている状態
と述べたが・・・これについても何を今更
前々から警告していたのにね

いやいや、ずっと前から尻に火がついていたけど、それに気付かなかったのはあなたよ！　我が上司！

既に、尻からジェットを噴射して、大気圏から出て行っちゃうぐらいなのに

●ずっと前に

私はずっと前に同様の事を行い、専門部隊7〜8名の協力を得ながら６カ月かかった経験から

今年度のはじめにその事を伝えていたのに、7月までは全然動かず・・・
我が上司は、他部署の専門家に『してね』って要請しただけ。
どのように、いつまでにとか伝えていなかったから、それまで動かず・・・

●今は成層圏飛び越えて

ようやく、行い始めたのが今年の9月か10月
この時点では、期限は、11月末だった。
なので、上司は2〜3カ月で完了すると勘違いしていたようだ。

なので、今年の7月時点でお尻は丸焦げになっていて、
今では、大気圏を突き抜けて成層圏に達しようとしているかなー

●さすがに

土曜日はベンダーさんがお休みかも知れない！
たまに作業をしてはることもあるみたいだけど

●でも

私にとっては月曜から金曜まで一杯働いてもノルマが達成できないから
土曜日も働く羽目に・・・

あっ！　決して、仕事効率が人より劣ってるってわけではないので・・・念のため

●まっいっかー

でも、土曜日の仕事環境は、とっても静かだから
仕事のやりやすさから言ったら普段の１．５倍くらいかな〜！
なので、捗る捗る！

●しかし

やっぱり、世間並に
週に２日は休みたいなー

今日は体調不良で、午前の会議を欠席しました。

午後一時に出勤したのですが

午後の会議のオンラインアクセス用情報が見当たらなかったので
参加できませんでした。

どんなことが話し合わせたのか、めっちゃ心配です。

この先、どうなるんだろう？

●新たな問題

今日も朝からオンライン会議に参加しています。
グループ統合システムの構築プロジェクト会議

稼働（カットオーバー）の半年前を既にきったところで
またまた新たな問題が・・・

しかも、根幹の部分で・・・・

●今後、誰がやるんでしょ？

新しいシステムのマスターデータベースの基本的なコード体系を
人事管理ソフトの組織データベースを持ってきてるんですが

やしり人事管理上の組織と業務運用上の組織は微妙に異なります。
体系も異なります。

でも、人事管理上の組織マスターをメインとしてグループ統合システムを構築しちゃったので
各拠点に設置されているプリンターを特定するためのコードが他のコードと紐づかない・・・
と分けの分からない状態に陥りました。

そして、ベンダーさんが、このマスターをどのように適正に維持していくんでしょ？
って問いかけたら、我が上司は
誰がやるんでしょ？
って答えました。

●まる投げの功罪

まぁ、人事管理用のシステムは、今までは本業のとは目的が異なっていたので、そのマスターの構築も人事管理部門が独自に構築してきました。

なので、それをそのまま本業に適用することは出来なかったのです。
いろいろな点で異なりますから。

人事管理用のシステムもシステム部門は関知してきませんでした。
まったくの丸投げです。

そのために、本業に使用できないような体系になってしまっていたわけです。

●成るべくして成る

もう、どうなるんでしょうか？
成るように成る・・・としか言えません

神のみぞ知る・・・ですね。

●テスト開始

いよいよ結合テストが始まって
各システム間で情報のやり取りをしつつその情報の適切性を検証するステップに入りました。

しかし、始めたらいろいろと問題が・・・

●共通インターフェースはXML

ここで、共通インターフェースについて
様式は、XMLを採用しています。
それはそれで適切だと思いますが・・・

XMLって世界中で使われている汎用てきなインターフェースです。
カスタマイズも自由自在。
データ表現が自由に出来てほぼ制限がありません。

●解釈の相違

ただ、共通とはいってもそれは器の話
その中に情報を入れるとき、解釈の相違があって

問題が発覚しました。
それは・・・・

XMLでは、最小単位の情報にタグをつけて、そのタグを単位としてまたまたタグをつけて・・・
と階層的な構造になります。

普通・・・・
最小単位の情報が空白ならば・・・送らなくていいですよね。
お互いにどんなタグで送受信するか共有しているわけですから。
送られてきたファイルにあるタグが存在していない場合
・そのタグに関する情報は空白であった　と解釈すればいいんです。


しかし、ここで解釈の相違が発生しました。
解釈Ａ：そのタグの内容が省略時値ならば、タグ自体をＸＭＬファイルに含めなくていい。
解釈Ｂ：そのタグの内容が空白ならば、タグ自体をＸＭＬファイルに含めなくていい。
と言うものです。

省略時値が空白なら、同じ意味合いになるのですが、
データベースの各種情報の省略時値は、その意味合いにより
例えば
・省略時値は　空白
・省略時値は　”１”
だったりします。

すると、省略時値が空白の場合に、解釈Ａと解釈Ｂでは、そのタグを
省略していいかどうかの判断が異なります。

丁度、関西人と関東人でのみに行ったとき、
関西人が冗談を言ったら、関東人がお前馬鹿やなぁって冗談のつもりで返したら、関西人が激怒！
みたいな勘違いからトラブルに発展します。

●リーダーの理解不足

この問題を発生させる原因は
プロジェクトリーダーのＸＭＬに対する理解不足です。
タグに空白を付けて送る　⇔　タグ自体を送らない
であることが理解できていないのです。

つまり、タグを送らないということは、タグに空白の値を入れて送るのと同じ意味
ですよねー

ところが、我がリーダーは
この情報は必ず送らなければならない。タグ自体を省略してはならない。
とベンダーに指示したため

情報が錯綜して
解釈Ａと解釈Ｂが生まれ

システム間で不整合が発生してしまったんです。

あ〜あ！

●精度1.5 mm

精度が 1.5 mm なんです。
って言われても何のこっちゃですよね。

これは、どこの会社にもあるであろう、複合機で印刷する時の
印刷位置精度の保証値です。

複合機でコピーする時も、パソコンなどから印刷する時も気にならない印刷位置
ところが、枠線などが印刷された用紙に、きっちり合わせて印刷しようとすると

なかなかこれが難しい！

●印字ずれは誰のせい？

そりゃそうですよね。
まず、用紙に合わせて印刷できるような原稿を作らないといけない・・・これも大変！
でも、用紙と全く同じサイズで印刷できる原稿を作ったとしても・・・

キチンとした位置で印刷できなければ・・・ダメ

当グループで使用している報告書は、情報量が多いこと
形式が昔のラインプリンターで印刷していた時代の1行が 1/6 インチで設計されている

この 1/6 インチがどのくらいの大きさか想像できます？

1 インチは、 25.4 mm なので、その 1/6 では、 4.23 mm
この 4.23 mm の範囲内に、印刷誤差が 1.5 mmもあるプリンターでキチンと収めるためには

文字を 3.73 mm 以内にしなければならない？

いやいや、プライマイナス 1.5 mm なので、振れ幅は 3 mm なので文字の大きさは 1.23 mm
あはははは
読めるかー

●キチンとセット

なので、私の会社では 2005 年から、フルカラーフルプリントを行っています。

用紙の枠なども一切合切まとめて印刷しちゃえ！
って単純な考えで実現しました。

これにより、見栄えがめちゃくちゃ改善しました。
当然です。
行のど真ん中に印刷されていますからねー

しかし、グループ他社では、プレ印刷された用紙に文字を印刷するんですが、
印字ずれの話になると、我が上司は

そうそうズレることはないだろう。
もしずれていたら、きちんとセットしないものが悪いんだ！

って発言していました。

よって、複合機が印刷ずれを起こしても、用紙をセットした人の責任だそうです。

印刷印字位置の誤差は、天候や気温・湿度に左右されます。
湿度で用紙が伸びたり、ローラーとの摩擦係数が変わったりしますから

そのような場合でも、ズレた原因は、セットの時にキチンとしなかった者が悪いって

私は、死んでもそんな業務に就きたくありませんね

●いくらなんでも

私の会社で、私が導入したソリューションは、コスト面も問題ないレベルにしています。
もちろん、複合機メーカーの多大な協力（いや努力）かあったのは言うまでもありませんが

用紙に印刷から、フルカラーフルプリントは簡単に移行できるでしょうが
フルカラーフルプリントから、用紙への印刷に移行すると、担当者（現場）の方たちの
精神的負担、手間が大幅に増加するでしょうね。

あーあ！

またまた、だらだらだらだらぐだぐだぐだぐだとわけの分からない会議が続いています。

●したい事とできる事

現在、構築しているグループ統合システム
開発をお願いしているベンダーとの会議で
何やらわけの分からない議論を続けています。

したい事があっても、それをするかどうかは
そのしたい事が出来るのかどうか
出来るとしたら、どの程度の労力がひつようなのか？

その労力以上の有効性があるか？

を検討しなければならないでしょう。

●なまじ

餅は餅屋

したい事が出来るかどうかは、ベンダーさんにゆだねましょう。
ベンダーさんの力量によっては、本当は出来るのに出来ないと言われることもあるでしょう。

しかし、ベンダーさんは開発のプロです。
餅は餅屋に任せた方が話が早いです。

●何がしたいのか

なので、何がしたいのかを明確に正確に伝える必要があります。
私たちは私たちの業務については専門家です。
ベンダーさんは私たちの業務について詳しくは分かりません。

ベンダーさんはソフトウェア開発のプロです。
私たち（私の会社以外）ではソフトウェア開発の素人です。

なので、素敵なシステムを作ってもらおうとすれば、
私たちの業務について専門家である私たちが、したい事をベンダーさんが
私たちと同じような理解を得るまで説明をする必要があります。

でなければ、先週のような仕様上の事故が発生します。
現行仕様では対処できない問題が発生するわけです。
これは大きな後戻りですよね。

そして、なぜそうしたいのかと言う理由も明確に伝えておいた方が良いことは言うまでもありません。

●きちんと伝えれば

きちんと伝えればうまくいくんです。
当たり前のことです。

キチンと伝えるためには、
餅は餅屋に任せきることに徹底することです。

なまじ、知っているからと言って
自分たちの些少な知識で考えて、この通りしてくれと
餅屋に頼むのは愚の骨頂です。

このために、小田原評定になっちゃうのです。
疲れますよ・・・

●現行システムの機能

ある機能が当社のシステムにあります。
それは商品セットマスターの特定の商品コードを別のコードに置き換えたり削除したりする機能です。

でも、対象となるセットが３５万もあるので、このツールが無いと何カ月もかかります。

●グループ統合システムへの追加機能

そして、いま構築しているグループ統合システムにもその機能が無いため、
ベンダーさんにこんな機能が無いと困ると言いました。

すると、いろいろと考えてくれて、こんな風な機能でいいですかって聞いてくれて
最終的に今日の会議で提案してくれました。

それまでは、統合システムにも Excel にマスター情報を吐き出して、
Excel 上で編集して
それを読み込ませる
って機能はありました。

しかし、それでは数十万行のデータに対して、検索や置換を行わなければならず
また、確認なんかもしなけりゃならないので

２時間くらいはかかりそうだとの事でした。
（ちなみに、編集後の Excelファイルを統合システムに読み込ませる時間を含まず）

●上司判断

ただ、我が上司（システム部長）は
今日の会議で　却下
えーーーっ？
なんで？


理由を聞くと、 Excel で出来るんだからそれですればよろしい
機能追加するとコストがかかるから

●その結果

今後ずっと、 Excel でしこしこと編集しなけりゃならないことが決定しました。

ちなみに、当社のシステムの機能で実行した場合は 2秒 で完了です。
それが新システムでは、2時間です。

処理時間は、現在の 2 秒が 2 時間 となります。
新しいシステムが導入されたら、 2 秒が 2 時間です。

嬉しいですねー
今までは、玄関で靴を履く時間もかからないのに
映画が１本まるまる鑑賞できる時間になりますねー

ちなみに、冒頭の絵は、処理速度に比例する形で　線　で表そうとしました。
でも

現行システムを 1 mm で表したら
新システムは 3600 mm にもなるので

入りきらないから
180 mm 20本

現行システムのは 1 mm なので気づいてもらえないかなーって思って、矢印でありかを指し示しまた(笑)

●抗議

もちろん抗議はしましたよー！
でも、上司の言葉は

現場に楽をさせてはならない
という、有り難いお言葉をいただきました。