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

当社のシステムは IBM AS/400 を核として、単一のデータベース (IBM DB/400)を中心とし、サーバー上で動くアプリケーション群と、それらの結果を表示するパソコン上で動くエミュレーションソフトの組み合わせで構成しています。

これって三階層システムって言われる、
・運用効率が良い
・システム保守がしやすい
　→データベースの一元管理
　　→データベース間の同期の必要性がない(一個しかないから)
　　→マスターやデータの更新やログ管理が簡単
　→アプリケーションの変更がしやすい
っていうメリットがあるアーキテクチャ(組み立て方)です。

今日の話し合いは、当社のシステムと新しく作ろうとしているシステムをどのように融合させるか・・・なんですが、
これが偉く難航しそうで

それは、当社のシステムの依頼受付部分だけを新しい依頼受付機能に置換しようとするものですが、悪いことにこの新しい依頼受付機能に置き換えると、システム全体の効率が凡そ10〜20%はダウンしそうなんです。

それでは、何故そのようなことをするのか?
って話になりますよね。

それは・・・後編で

グループ全社の新しいシステムの仕様決めも大詰めになりつつあります。

今日も重要な仕様の一つについて話し合いました。

私の会社で行っている特殊な仕様について、それを取り入れるかどうかで、検討しましたが、私の会社ではその仕様があるために、年間で約150人日の手間が削減できています。
これは、一日平均で約半日分の仕事が削減できていることになります。

この仕様が採用されなければ、一日4時間のアルバイトを雇わなくてはなりません。

すると、時給千円としても、年間で120万円の人件費となります。



これが、アイデア一つで生み出されたんですから!

コンピュータプログラムは一度作れば、仕様変更がない限り使い続けられます。
しかし、これをアルバイトで行う場合は、未来永劫人件費がかかります。

どちらがお得でしょうか?

コンピュータプログラムを開発する費用がいくらかで、どちらがお得か変わってきますよね。
当社では、自社で開発しているので、会社から出ていく費用は￥0でした。

と、言うことで、コンピュータープログラムの方がお得ですよね。
毎年120万円の純利益をたたき出しているのですから。


あーーー採用された良かった

水曜日・・・闘いました(笑)


グループ統合システムの仕様検討会議で、当社にしかない機能が危うく削除されかけたんです。

しかし、その機能、削除された場合、一日に6人時間の作業量が増加するんです。
これって大きいですよね。

人件費に換算すると、年間で180万円にもなります。

しかし、費用だけではなくて、作業する人の精神力が必要とされますので、精神的負担もかなり大きいんです。

これを一生懸命主張したので、機能が標準仕様として採用されました

やったね

ちなみに、タイトルの『闘う者の歌が聞こえるか?』は現在、絶賛練習中の歌です

グループ統合のために、新しいシステムを当社に導入しようとしています。


当社のシステムは、
�@マスター登録
�A依頼入力
�B製造工程
�C製品確認
�D納品
�E請求
が単一のシステムで実現できています。

単一とは・・・まぁ・・・一つです

しかし、グループの他社では、これがそれぞれ別個のシステムになっています

なので、ある工程だけ挿げ替えることも他社では比較的容易です

だって、
�@マスター登録
�A依頼入力
�B製造工程
�C製品確認
�D納品
�E請求
このように、�Aだけ変えたらいいんですもんね

しかし、当社のシステムでは、�@〜�Eまで、同じコンピュータ上で、同じ記憶装置上のデータベースを参照していますので、グループ統一仕様の�Aに置き換えようとしても、�@と�Aの間、�Aと�B以降の間の連携が大変です。



はてさて、どうすんべー？

それは・・・・・



と、我が上司は思いこんでいたから



確かに物流系で使用するＩＴＦは１４桁・・・となっていました



私のグループは物流系ではありません

しかも、自社内でのみ使用するので、そんな制約にとらわれることは全くありません

少し調べれば分かることです。
ITFは、0〜9までの数字しか表せません。
ITFは、2桁単位でバーコード化するので、データの桁数は偶数桁となります

我が上司の１３桁と言うのは、チェック用の１桁を１４桁から差っ引いた桁数だったのです

そして、当社に強要したのは

単なる認識違い

だったのです

ふざけてますよね



グループ全体を統括するシステム部長が、そんな・・・良く調べもしないで、バーコードの仕様を決定していたなんて・・・

誰が思えます？

まぁ、何はともあれ、誤解が解けて良かった(*´▽｀*)

しかし、この誤解に基づいた仕様変更を半年にわたって検討してきた私の労力は誰が責任取るの？

もちろん、これじゃありません



現在、グループのシステム統一を図ろうと、システムをどうすれば良いか、その設計を行っている段階です。
しかも、最終段階


当社ではグループ傘下に入る前、1995年当時から、バーコードによる管理を行ってきました。

バーコード体系が当社と他社で異なるのです・・・・
まぁ、当たり前と言えば当たり前ですよね。

元々は全く別の会社だったので


先見の明があったのです
当社は、管理する為のバーコードを工程の一番最初から使用していて、それで全ての対象物を一個一個特定できるようにしています。
対して、グループの他社は、対象物が戻ってきた時にバーコードを取り付けていきます。
しかも、そのバーコード内容は、戻ってきた順番なのです。
つまり、戻ってくるまではバーコードラベルは貼付出来ない・・・と言う事になります。

当社の様な管理方法に統一しようと言う事になっています。

それならば、当社のバーコードの仕様に全社が合わせたら良いのでは？
と、素直に考えるじゃないですか？
ところが、グループ本社が提示した仕様は
ITF(というバーコードの種類）で、14桁のバーコードを使用する

確かに、当社の12桁では桁数が少ないかもしれませんが・・・

全て14桁にするとなると、当社のシステムを殆ど作り替えないとダメじゃないですか〜〜
見積もってみると・・・５年くらいかかりそう(笑)


をしました。
すると、意外な事が判明しました。


次回に続く・・・・・

あっはっはー!

なんでやねーん!

いきなり関西弁になってしまいましたー



現在、グループ全体でシステムの統一を図ろうとしています。
が、バーコードを使用するシステムなので、バーコード自体も統一する必要があろうかとも思いますが、これからバーコードを使うグループ各社と、もう２０年以上バーコードを使用してきた当社の間で、問題が発生しました。

それは、当社は ITF 12桁のバーコードを使用してきましたが、グループ各社は 13桁 (チェックディジット込みでは14桁)の ITF を使用するというのです。

それは、それでいいでしょう。
当社が、その過渡期には、12桁でも 14桁でも運用できるようにシステムを改修したらいいだけなので。



過渡期でも12桁のバーコードを使用することを我が上司は認めてくれませんでした

なぜ?

と、ずっと思ってきましたが、ようやく、その理由がわかりました。



我が上司は、ITF バーコードは 14桁か 16桁しか使えない!

と、思っていました。

それが、ITF 12桁を使用しないとの判断根拠でした



昨日、話し合って、12 桁 ITF バーコードの使用許可が下りました

使っていいって(笑)

勤怠管理システムでの有給休暇付与ロジックが無理難題過ぎて困っていたことを前回お話ししました
しかし、ひらめきのお陰で、それまで一週間以上悩んでいたことが一瞬で解決しました

やっぱりひらめきは大切ですよね。


我々、SE(システムエンジニア)が、いろいろな問題を解決するときに、実生活ではあまり考えつかないような手法をよく使いますよね


皆さんはかの有名なガウスという大数学者をご存じでしょう
私たちが小学生のころ、友達が得意そうに『１から１０まで足したらいくつになるか?』とか問題を出してきて、僕らがうんうんと、１タス2は3で、それに3を足したら6で、それに・・・と計算しているときに、『なんだ、遅いなぁ(笑)　答えは５５じゃん!』って得意満面な顔で言ってたのが印象的でした。
しかし、このような計算を一瞬で答えを出す方法を、ガウスは自分で編み出したというのです。

１から１００ぐらいなら力業でなんとかなるでしょう。
１から１０００ぐらいなら、暇な人はやってみる気になるかもしれません。
しかし、１から１００００００００ぐらいなら、だれも見向きもしないでしょう。


手間暇がかかりすぎるのに、得られるものは何の価値もない結果だけ・・・だからですね
でも、ガウスの方法なら、１から１０だろうが、１００００００００までだろうがそんなに変わらない時間で計算結果が出せますよね


IT技術者の真骨頂がそこにあるのです

いかに少ない資源で、いかに大きなメリットを生み出すか?
なんです。
我々IT技術者はそれを実現するために色々なアルゴリズムを考え出します

それには、パズルを解く・・・みたいな

うんうん考えてもなかなか思いつかないけど、ある時一瞬のひらめきが極端に物事を簡単にするのですね

今回の難題、２週間かけて実現できなかったのが、
ひらめき
のお陰で、１日で正しい結果を得ることができました

困ったときは我々IT技術者にご相談を!

こんばんわー

無理難題で苦しめられている IBM AS400 をこよなく愛するＳＥです


こないだ、非常に難しい問題を突き付けられ、困窮しているとお話ししました

それは、有給休暇の付与ロジックに変則的な要求が加えられ、それを実装するのに２週間以上頭を悩ませても全然ロジックが浮かばなかったんです


そうこうしているうちに、昨日、総務課より、『私の有給休暇の日数が変なんです。どうなっているんですか？』とか、『私の有給休暇日数について正確な数字が知りたいんです。』とか、各署から問い合わせが入ってきており、大変なんです・・・って窮状を訴えてきました

しかし、私も窮状状態です
『どうしようもなく、正しいブログラムができないでいる。　正しい付与ロジックを提示してもらえればその通りプログラムを作るから・・・』と、私にしてはとても酷い言葉を浴びせてしまいました


自分の行いが恥ずかしくなり、訴えてきた総務課の女性（Ｋさん）に謝罪し、どうしたらいいか相談し始めました。
今回の変則的な有給休暇の付与について
Ｋさんの場合の有給休暇の付与日と付与日数について

これらを順を追って話していました。
当然、Ｋさんも答えが出せずにいました。

とりあえず、その後、『がんばります。』と伝えて、電話を置きました。


なんと、Ｋさんに説明している時に語った言葉から、新しいロジックがひらめきました
説明している事が自分の頭の整理を行っていたみたいです

それまで、複雑に考えていたことが、なーんだー！ と、必死に考えてもわからなかったなぞなぞの答えを聞いて なーんだー！そっかー！ と思った時のあの感じと同じでした

目鼻は立ちました！
Ｋさん、ありがとー

やっぱり複雑すぎるシステムはメンテナンスが大変だ―
特にイレギュラーな要求に対応するのは


いくらけったいな要求が来たとしてもそれは法律の範囲内やろーって考えて作っています

皆さんもそうじゃありません


(時効)

第百十五条　この法律の規定による賃金の請求権はこれを行使することができる時から五年間、この法律の規定による災害補償その他の請求権(賃金の請求権を除く。)はこれを行使することができる時から二年間行わない場合においては、時効によつて消滅する。

有給休暇が付与され、それを使用する権利（使用を請求できる権利）は、し利用する事が出来る時から２年間で時効消滅する・・・って書いてありますよね。

有給休暇は、労働基準法によって事業者が被雇用者に一定の基準を満たした場合に付与しなければならないと規定されていますので、この２年間の時効消滅までは請求できる・・・事になります



付与された日から短いものでは1ヶ月の有効期間しか無い有給休暇が今年10月から発生しました

これにシステム対応しなければならないのです



困窮しまくっています