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

●切替検証

土曜日の記事明日は、切替検証にてお話しした切替検証を昨日行われました。

●結果はどうだっただろう？

結果は・・・
まだ私の方には届いていません。
果たして、成功 or 失敗？

●成功か失敗か？

本日朝の会議で克明に報告されるでしょう。
成功である事を祈りたい続きを読む........

●とうとう

グループ統合システムのリリースも残り一か月を切りました。
そして、明日はグループで最小の拠点で切替検証が行われます。

●切替検証とは

切替検証とは・・・従来システムから新システムへの切替手順の検証と予行演習の意味があります。
もちろん、その手順実行時に発生した不具合や問題点の抽出も兼ねています。

新システムでの運用試験はこれまでやってきました。
●システム要員に依るシステムテスト（ＳＴ）
●現場担当者に依る運用テスト（ＯＴ）
まだ、テスト最中ですが

●うまく行くか

今回の切替検証で、うまく行けば・・・
まぁ、問題点は発生するでしょうから、その問題点を解決し、
⇒２回目の切替検証へ

●細工は流々仕上げを御覧じろ

まぁ、大規模なシステムなので、
しかも、エイヤッの入れ替えなので
相当の確認作業を行わないと・・・

グループで十年以上前に起こした大失敗
これを繰り返すわけにはいきませんからね

●朝早く

今日は、春休みが空けた大学に行く息子を駅に送るため
7時11分発の電車に間に合うように、家を7:00に出て
駅で下ろし、会社に向かいました。

●出勤したら

いつもより一時間半は早く会社に着き、
天気のいい日で気温も快適
事務室の気温も幸せを感じるほど

●気になった

8時出勤の者がもう一人いて、
2人で事務室の中にいたけれど
全く別々の仕事

●他人の口笛

ふと、口笛が聞こえてきました。
普段は事務室で口笛など聞くことが無かったので
どこから聞こえてくるんだろう？って思いましたが

発生源は特定できました。
そうです。8時出勤者でした。
私も良く口笛を吹きますが

自分のは気になりませんよね。
でも、他人の口笛ってこうも気になるもんなんだって
改めて思いました。

●以後気をつけよう

すると、当然私の口笛も他の人にとったら
耳のごみ

以後、気を付けます・・・

●勤怠管理システムの変更

今年４月より、勤怠管理システムをグループ全体で統一することになっていました。
今までは、当社のホストコンピューター上で稼働する勤怠管理システムを使用していました。
（今後も使用するつもりですが）

今まで（これからも）利用する勤怠管理システムでは
●出勤時・退勤時
タイムカードではなく、ＩＣカード社員証をＩＣカードリーダーにタッチするだけ
●様々なシフト業務
日ごとに出勤時間が変わる業種なので（部門によって違いはありますが）
勤務種別コードを入力
例えば、9:00出勤なら 090 とか

あと、休暇の場合は、取得権利のある休暇コードの中から選択して入力
有給休暇なら003とか
もちろん、有給休暇はキチンと管理するようにしてあり、取り過ぎないようにしてあります。

ところが、親会社の勤怠管理システムは
部門ごとのExcelブックに、各個人が出勤時刻や退勤時刻を手入力
全てが手入力

物理的なタイムレコーダーとかＩＣカードリーダーとか使用しません。
なかなか、先進的な・・・
悪いことをする人は全くいないことを前提に作られてるんですよね。

これでも、以前よりは良くなっているそうです。
以前は、全て紙ベース

●グループ親会社のシステムに合わせられる

グループ本社の経理部門で全て管理すると言うので、
私の会社でもこのExcel勤怠管理シートに全部入力しろと・・・
あ〜あ！　この辺りだけで考えると、３０年ぐらい過去に遡ることに

●残業・遅刻・早退・休憩時間の扱い

そして、親会社の運用で問題だなって思えるところが

• 残業時間
　14分までは残業申請できません。 15分から29分は15分に丸められます。　要するに 15分単位で切り捨て

• 遅刻時間
　1分遅刻しても、15分遅刻したって事になります。要するに15分未満は切り上げです。

• 早退時間
　遅刻時間と同じ計算方法です。

• 休憩時間
　遅刻時間と同じ計算方法です。

という計算方法なんです。
全て15分単位なんです。

いまどき、こんな計算方法をしているなんて

●よくこんなんで訴えられなかったな・・・

この計算方法って
めっちゃ 労働基準法を無視してますよね。
1分遅刻して、14分残業したら、13分余分に働いているにも関わらず、15分間分に当たる給与が減額されます。
つまり、この従業者から会社は 28分間の労働を搾取していることになります。
ノーワーク・ノーペイが労働基準法の精神です。
裏を返せば、ワークにはペイです
労働者が労働した対価はキッチリ払えと言うことです。
１分たりとも搾取してはならないと言うことです。
ネットで調べてもどの法律事務所でもこの見解ですね。
（もし違う見解を出しておられるところを見つけられたらコメントで教えてください。）

まぁ、思うに、今まで良く訴えられなかったなぁって思えます

●抜け道

Excelシートに手入力・・・なので、
9:00出勤の人が、9:01に出勤して遅刻となっても、Excelシートに9:00と入力すれば
遅刻にはなりませんー

逆に、上位者が、この部下は残業が多すぎるな！　少し削っておこうとExcelシートを改ざん

やりたい放題の勤怠管理システム・・・これはある意味すごい

今朝の会議でベンダー側プロジェクトリーダーの口から出てくる言葉
様々な不具合が出て、ベンダー側も都度都度対応してくれているので
不安材料はないと言えばうそになるんですが・・・

いや、あり過ぎて困ってるんですが・・・
私の会社に導入されたらどうなるんだろう？
上がってくる課題に、運用でカバーって対応も散見されます。

散見？
散見ってどのくらいの割合？
私の感じている散見という頻度が正しければ、散見どころでは・・・

なんだろう？
新しいシステムを導入したら、今まで自動的に実行されていた機能が
手作業

●新築マンション

皆さん、イメージしてみてください。
今住んでいるマンションが老朽化し
新築マンションに引っ越すことになりました。

今まで住んでいたところでは、お風呂のお湯張りは自動
スイッチ　ポンで、設定した湯量まで自動的に給湯してくれていた。

ところが、新築マンションでは、蛇口をひねってお湯を出し、適度なところで止めなければ
ジャバジャバジャバ

また、今まで住んでいたところでは、ウォシュレットのふたは近づけば自動的に開いた。

ところが、新築マンションのトイレは洋式ではあるものの、ウォシュレットがついていない

そして、今まで住んでいたところでは、ウォークスルークローゼットが付いていたけれど

新築マンションでは、押し入れがあるだけ

こーんな新築マンションに胸躍らせて尚且つ喜べますか？

まるで、トプ画のように、天国から地獄って気分ですよ

●切替検証とは？

今まで構築してきたグループ統合システム
今運用テストを絶賛実施中
まぁ、いろんな不具合がでているものの
先週金曜日の定例会では予定通り進んでいる・・・と

さて、残りは・・・

現行システムから新グループ統合システムへ切り替えを行う必要があります
その切替手順を計画して、
その計画通りに切替が出来るかどうか確認する工程

それが切替検証

●最小拠点で２回

最小拠点で新システムを稼働させるので
そこで、切替検証が行われます。

まず第一回は次の日曜日
第二回は、4月の第四日曜日だったか・・・

うまく行けば

●5月本番稼働

となります。
その後は、最小拠点で新システムが稼働し続けると言う事になります。
うまく・・・いけば・・・ですが

●いよいよ

あと一か月でリリース
そうです！　時間をかけて構築してきたグループ統合システム
リリース直前に行うべきことは

稼働判定

これは、新システムを稼働させて、従来の運用が全て滞りなく行えるかを確認すること
折角、稼働させても、あれができない、これができないでは
業務そのものが実行できないことになりますから

●稼働判定

稼働判定をどのようにするかということを検討する会議
今日行われました。
その中でめっちゃ不安を煽る言葉が

●いろいろなこと

稼働判定を行うためには
全ての運用を把握し、
それらの一つ一つが、
１．新システムで実現できていなければならない
２．新システムで一部出来ていない場合、出来ていない機能が運用でカバーできること
３．実現できていなくても問題ない
のどれに当たるかということと
出来ているというのは、どのように判定するか
を決定しなければなりません。

でも、ここで、上司から耳を疑う言葉が・・・
何がわからないのか分からない
えっ？うそっ？

●あれれ

この段階で・・・その言葉
大丈夫だろうか？
チェックポイントが特定できていないなんて・・・

●いよいよ来月

昨年１月に、大丈夫？　新システム・・・＿|￣|○で投稿したんですが・・・
コメントが一件・・・えらく微妙な内容でドキッとしました

●稼働判定会議

はてさて、残すところあと一か月となった今
稼働判定会議が本日開かれます。
第二回だそうです。

えっ？
第一回目が有ったの？
知らされていないけど・・・

まっ！私のような下っ端には通知する必要もないということね
知らないところで、運用の細部を知らない人たちが判定する・・・

新幹線の新型車両が出来て、初回の試運転をして
200 km/h で走行して
何の問題も無かったから

300 km/h で営業運転しよっか

みたいなイメージが沸き上がります。
（もちろん、比喩として挙げた例はあくまで創作であり、実際には新幹線車両の試験は途方もない試験を繰り返しておられることは言うまでもありません）

●稼働判定結果

Go or Stop
どちらでしょうか？
何となく、Goと判定される気が大です。
現時点の試験結果がいかようでも・・・

何故なら、Stopとなれば誰かが責任を取らなければなりません。
そして、Goが出来るようにするために全精力を傾けなければなりません。
そんな責任を取る責任感のある人が見まわしてみても・・・居ません

●犠牲？

Goと判定された結果
グループで一番小さい拠点で
来月にリリースとなります。

上手く稼働すればいいのですが・・・
私が、そこの拠点の責任者であったなら、
本番テストを休業日に行い、そこの拠点の部門責任者全員がＯｋを出したら

Goですよね。

●一日停止

今日、朝の会議で、ベンダーさんから重大な報告がありました。
開発環境及びテストで使用していた環境と
本番環境で一部異なる設定があったと・・・・

●テスト期間中だから

本番環境でテストを始めて約一か月
そこで分かったらしい
何が違うかと言うと

文字コード体系
まぁ、些細な違いみたいですが
開発環境で使えていた ~ (チルダ) が

本番環境では使用できない・・・
これが同問題かというと
テスト環境でデータ中に 【~】が格納されていた場合に
画面に表示はできる
でも、入力しようとしたときにエラーではじかれる

えっ？入力できない？
いやいや、【~】が使用されている時だけ

●なぜこのような事が

なぜ、一流のベンダーさんがこのようなケアレスミスをしたのか？
それはやはりあの一点に尽きるだろう・・・と私は思う

リリース期限は決まっているのに仕様決定がめちゃくちゃ遅い

そりゃ、だれでもミスるわなー
私としてはベンダーさんに同情

●一抹の不安

しかし、開発環境の設定を本番環境に引き継ぐのは、常識的な線・・・・
その処理を行うときにチェックリストなどを作って実行するはずなのに
文字コード体系を違えて設定しちゃうとは

一事が万事

すこーし不安が・・・

本日の会議で、ベンダーさんがボソッと

報告書を出力する方式で、帳票サーバーを何台設置して、
報告書印刷用データをどのように振り分けるかで、
ベンダーさんと我々グループで意見がバッティングしちゃって

ベンダーさんの今日のリーダーが
【どのように進めたらいいのか分からなくなっちゃった・・・】

こっわー