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

コンピュータシステムにおいて、データベースを構築する場合、一元管理をすることが、シンプルで保守性が良いことは言うまでもありません。
もちろん、BCP(事業継続計画)の事を考えて、バックアップサイトを持つことはいいことです。


初期投資が少なくて済む・・・ということでクライアントサーバー型システムがもてはやされました。
ただ、TCOは意外にかかってしまいました。
機械物は保守対象が多くなればなるほど保守の機会が増えます。
なぜならば・・・って考えるまでもないですよね。

極端な話、1台のホストマシンで賄っていたものを10台のサーバーで置き換えた場合、故障率がホストマシンもサーバーも同じであれば、ある期間に故障する機会は、10台のサーバーの方が大いに決まっています。


こんなことを考えると、クラサバは初期投資は確かに低いですが、保守コストが馬鹿になりません。保守サービスを契約するにせよ、自社要員で対応するにせよ、保守料金もしくは人件費がかかります。


我がグループの他社は、クラサバに移行して久しく、また唯一残っているホストシステムをもクラサバに移行しようとしています。
えっ?
です。


自然の摂理は、水は高いところから低いところへ流れていきます。

と、いうことです。

現在、グループ企業全体で、依頼登録システムの刷新を行おうと、日夜仕様検討を行ってきています。
ただ、問題は、私の所属する当社と、グループ他社のシステム構成に違いがあり過ぎることです
グループ企業用に策定された仕様のシステムを当社に導入しようとした場合に、当社のシステムを細切れにしなければならず、どう対応すればいいか頭を抱えています

当社のシステムは、新依頼登録システムが目指している機能を実現出来ています
と、言うよりか、それよりも進んでいます
しかし、当社は子会社の立場であり、少数派なので、当社のシステムを全グループに展開するつもりは親会社のシステム部長にはさらさらありません
それどころか、新依頼登録システムを当社に導入するように迫ってきます
もちろん、グループ全社で統一したシステムを運用するメリットはあろうかと思います。
しかし、それならば、既に実現出来ている当社システムを水平展開した方がお得だと思うのですが・・・


そして、一番困るのが・・・・
※新システムを稼働させた場合に、様々なトラブルが発生する事が予想されます
※回避出来ないほどのトラブル（致命的と言った方が良いでしょうか）が発生した場合に、元のシステムに戻す事が必要でしょう
しかし、私の提案した新システム導入案は上司は受け入れず、上司が別の提案をしました
ちなみに、上司は親会社にいて、当社のシステムをあまりご存じありません
そして、上司の提案通りに変更してしまうと、後戻りができません
人海戦術で対応しようとすると、簡単に計算して、毎日50人時間（50人で1時間、もしくは10人で5時間）の作業量が余分に必要となります
そんな人数を失敗した時の為に雇用しておくわけにもいきません


しかし、私もサラリーマン・・・上司の指示に従うしかありません
失敗しない事を祈るしかありません
失敗する確率がかなり高いのですが・・・・

神様、助けてー

今、横浜で新しいシステムの仕様検討のための会議に参加しています



検索機能の話になりました。
マスターファイルから特定のレコードを検索するためにキーワードを指定する画面について話し合っていました。

そしたら、単一のワードで、前方一致か部分一致しかできないとのことでした。




普通にブラウザでネットを検索するとき、空白で複数の単語を入力したら、その複数の単語をすべて含むものを検索して表示してくれるのに・・・

新しいシステムではそれができない・・・と

えっ?　でしょー

しかも

単一ワードで、部分一致ならレスポンスが心配だとか・・・

これも、えっ?

なぜなら、わずか数千レコードのマスターファイルから検索するのに、心配になるほど遅いの???



以前、AS400のCPUがPower7からPower8に変わったとき、IBMの宣伝に　爆速　って言葉がありました

えっ?　言い過ぎやろ?

いえいえ、そんなことはありませんでした

とにかく早い　AS/400

みなさん、おはようございます

今日は、勤怠管理システムを複雑にしてしまった副作用・・・の最終回して、今まで具体的に話してこなかった【副作用】そのものをお話したいと思います


複雑なシステムに付きものの副作用とは・・・
・拡張性が無い（無いとは言えませんが、困難となります）
・マスター類の維持が大変

サクッと書くとこんな感じでしょうか？

私の開発した勤怠管理システムも、かなり複雑になってしまっているので、通常稼働している時はスムーズなのですが、今回のように訳のわからない変更要件が提示されると

【複雑で修正が困難なシステム】　×　【訳のわからない要件】

と言うダブルパンチの為、開発者の私でさえ１週間弱かかってしまう大ごとになってしまいました


複雑なシステムだけれども修正が簡単・・・てなものができるかどうか

そりゃ、無理でしょ
だって、複雑かどうかを決めるのは人間の主観であって、全貌を理解できなければ複雑なんです理解できれば簡単なんです

いーじょうっ！

以前も申し上げましたが、私一般企業のシステム部門のＳＥとしてAS400の面倒を30年以上見てきました


しかし、その傍ら、京都市の北大路烏丸交差点の近くの『京都福音自由教会』と言う教会に通っています
クリスチャンだからですが

教会では、そのプロセス全てが奉仕で成り立っています
私は、法人格を持っている教会の会計担当として15年ぐらい担当してきています

そして、会計を担当することになった理由は、それまで全て帳面に記帳するタイプの会計処理から、それをコンピュータライズするという話になって、そこで、教会で唯一のＳＥだった私が名乗りをあげたのでした



それから15年、いろいろな資料や予算編成用の資料、決算資料までもが、ボタン一つで作成できるところまでなりました


そう、反応が鈍いのです

何故か？

それは
・ExcelのVBAを使用している。
・かなり長文のマクロとなっている。
・シートにもかなり多くの計算式を入力している。

一セル入力するごとに0.5秒くらいかかるのです

めっちゃ長いでしょー

これがイライラの原因となっています
よって、ただいま、この0.5秒をせめて0.2秒にすべく対策を検討しています

、今私の企業グループで構築している新システムの標準レスポンスタイムは3秒です

0.3秒ではありません

3秒です

どーですか？　私は発狂してしまいそうです

ともあれ、昨日朝より、無事に稼働し始めた有給休暇付与ロジック・・・

10月1日になれば付与された日数が、勤怠入力画面に計上されるため、4月1日にもともと割り振られていた20日を10日にしたとて、昨日(10月1日)には、再び元に戻ったかのように見えます。

しかしながら、本日付与された有給休暇は使用期限が来年3月末日までの6か月です。
来年4月になれは、使用していなければ、消滅します

かといって、業務の都合上、半年間で10日使えるかと言うとそうでもありません

と、すると消滅

はてさて！　経理部長は今回の措置をどのように従業員に説明するんでしょうか？？？？


まぁ、今回のシステム改訂で、完全自動化した勤怠管理システム、当然当社の運用形態に合わせたカスタマイズだらけなので、使用する方は何のストレスもなく使えるわけですが、
今回のような訳の分からないロジックにしろと言われると、さすがに勤怠管理システムの複雑さがあだとなって、その改修に時間がかかります。

今回のは4〜5日かかりましたけどね。

ただ、この類のソフトウェアを外注すると数か月待たされて数百万円ほど請求されるのですが、今回は私の人件費（微々たるものです）と4〜5日で済んでます
4〜5日でも私にとっては時間がかかった方です。　通常は1〜2日ですからね


百万円ほどでも良いから給料上がらんかな？

おはようございます
夜が明けました

昨晩お知らせした仕事がギリギリ完了しました

実は勤怠管理システムで、有給休暇の付与ロジックを変更していました

10月1日（つまり本日）には、10月に付与する為、本日の7:00までに完了する必要がありました

なんとか、3分前まで、プログラム改修、テスト環境の稼働、チェック、再改修・・・を繰り返し

ようやくテストにパスしましたー

で、その後は、テスト稼働中に作成していた改修結果報告用データ作成プログラムで報告用データを作成し、Excelでまとめて、担当部長に送付したところです

ここで、私の認識がおかしいのか（つまり私の誤解）か、そうでなければ経理部長の大きな誤解が存在する事についてお話します。

有給休暇が付与された場合には、従業員はその行使権が付与日から２年間あるとされています。（労働基準法第115条）

ただし、今回の改定で
従来は、例えば
　　付与日　　　付与日数　　行使可能期間
　2018年3月1日　20日　　2018/3/1〜2020/2/29
　2019年3月1日　20日　　2019/3/1〜2021/2/28
　2020年3月1日　20日　　2020/3/1〜2022/2/28
　2021年3月1日　20日　　2021/3/1〜2023/2/28
となっていましたが、2020年4月1日に発効した新就業規則では、『全従業員は2回目以降の付与は4月1日に行う』と規定されました。
すると、従来の付与方法を変更せざるを得ません。
ただ、この例に挙げた方では、
　　付与日　　　付与日数　　行使可能期間
　2018年3月1日　20日　　2018/3/1〜2020/2/29
　2019年3月1日　20日　　2019/3/1〜2021/2/28
　2020年3月1日　20日　　2020/3/1〜2022/2/28
　2020年4月1日　20日　　2020/4/1〜2022/3/31
　2021年4月1日　20日　　2021/4/1〜2023/3/31
と、赤字部分でかなりの重複付与（付与しすぎ）が発生します。そこで、我が経理部長は
　　付与日　　　付与日数　　行使可能期間
　2018年3月1日　20日　　2018/3/1〜2020/2/29
　2019年3月1日　20日　　2019/3/1〜2021/2/28
　2020年3月1日　20日　　2020/3/1〜2022/2/28
　2020年4月1日　10日　　2020/4/1〜2022/3/31
　2021年3月1日　10日　　2021/3/1〜2021/3/31 (行使権が1ヶ月のみ)
　2021年4月1日　20日　　2021/4/1〜2023/3/31
　2022年3月1日　10日　　2022/3/1〜2023/1/31 (行使権が11ヶ月のみ)
と、しました。
ここで、赤字部分は労基法115に抵触はしないか？と問いましたが、経理部長曰く『社労士がこれで労働者の不利益にならないからいいんだ』と言われていました。

どうなんでしょうか？

こんばんわー

昨日、この仕事が終わったら『大きな誤解』とは何かをお話しようと言いました

しかし、まだ終わっていませーん

なので、気になる方は明日朝以降にお越しください


恐らく午前、丑三つ時に投稿します

さて、こうして付与日を変更するにあたって最低限保証しなければならないのは従業者の不利益とならないようにルールを変更することです

ところが、画一的に対応すると、今度は会社側の不利益が拡大します

そのちょうどいい妥協点を見つけ出し、それを実現できるようなロジックが必要となります

しかし、なぜこんなめんどくさいことをするのか・・・
最初は、グループ全体で統一する・・・のかと思っていましたが理由は意外なところに

もともと当社の総務部長だった者が数年前に親会社の経理部長になりました
一年で当社に戻る・・・という約束だったんですが、もうひと昔単位になっていますね

この経理部長が当社の就業規則を変更しました。2020年4月発効で

その時に有給休暇の付与日を全従業員4月1日とする・・・と謳われていたのです
なぜ、そうしたか？
当社も有給休暇の付与日は4月1日だったと勘違いしていたのです

これは、私がその経理部長から直接聞いたので事実です

たとえ、勘違いといえど、就業規則を変更し、監督官庁に提出したら、それが正です。

よって、AS400上の勤怠管理システムの有給休暇割振りロジックを変更しなければならなくなりました

まず、第一回改訂は4月1日直前に行いました。

各月割振月の方々の4月1日付与日数を何日にするか・・・？　これについて経理部長に何度となく尋ねましたが音沙汰がありませんでした

仕方なく、全員、付与日を単純に4月1日に変更するだけにしました。付与日数は変更せずに
（例えば、10月に付与している方については、毎年10月1日に付与しているのを4月1日、すなわち半年(=0.5年)前倒しで付与することになります。すると単純に考えて付与日数は半分でいいですよね。　しかし、このような場合、5月に付与している方はどうなるのか？　3月に付与している方はどうなるのか？　これは一朝一夕に決められるものでもありません。

なので、単純前倒し付与ロジックに切り替えました。

さて・・・この後、大きな誤解と、わけわからんロジックに振り回されました。

今から、わけわからんロジックに従い、システム変更します

私としては、大きな誤解を解くために、労基法115条の規定［請求権の時効］について説明し、わけわからんロジックがそれに抵触していると主張しましたが、経理部長は『社労士の先生が大丈夫だと言っている』の一点張りで、再検討にも至りませんでした

まぁ、私も一介のサラリーマン！　キチンと言うべきことは言って、その上で指示されたことを淡々とこなすだけです

大きな誤解とは何か？
それは、今からの仕事が終わってから投稿しますね

当社では、AS400により、従業員情報を管理し、勤怠状況を管理し、給与システムへの勤怠情報を出力しています

当社の業態上、シフトがきめ細かく設定され（凡そ30分おき）、月休、有給休暇などの休暇管理も全て行っています
当然、残業手当、深夜割増、休日手当、振替休暇、当直勤務なども就業規則通りに集計し、給与システムに情報を提供しています

ただ、従業員が勤怠入力を正しく行えるよう、入力時には厳密なチェックを行い、誤入力ができない仕組みとしています。

また、管理者が部下の勤怠管理を行うために必要なプロセス、経理部門が、各署から集められた情報を必要最低限のチェックで賃金計算ができるような仕組みも構築しています

当然、これだけの至れり尽くせりな仕組みを実現するためには、非常に複雑なロジックなどがそのシステムに組み込まれています

今年度、有給休暇の割り振り方法が変更されました
あくまで労基法に抵触しない格好ですが、親会社が勤怠管理を紙で行っているため、親会社は有給休暇の付与を全従業員一律で4月1日としています

当社では、ＡＳ４００上の勤怠管理システムが全て管理しているので、労基法通り、入社月の半年後に割り振り、その後1年後に割り振りを行ってきました。

次号に続く