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

おはようございます。新しい集が始まりました。
実は、土曜日にこの記事を公開しようとしたのですが、意外とバタバタしてて・・・・

今日も土曜日がやってきました（当たり前）

普段は土曜日は休みなんですが、
ちょっと立て込んでいて出勤してきました。

そして、アプリケーションを一つ作ってきました。

そのため、朝から愛車 Note e-Power を運転しました
しかし、さすがに土曜日・・・多分ドラレコにいろいろと面白いものが写っているでしょう

あっ、そうそう！　無茶な歩行者や無茶な自転車も居りましたね。

やっぱり、土曜日はそれなりドライバーが出没していますね。
でも、今回は自転車・・・信号のない交差点に差し掛かり、左折しようとしたら、左手の脇道から車が出てこようとしていました。
そして、その車が出終わるのを待って、そろそろと左折を始めたら、右後方から我が車の前を自転車が通り過ぎていきました。
緊急停止
幸いにも接触しませんでしたが、私のたぐいまれな視界が無ければ衝突していたでしょう

おはようございます
気持ちの良い朝ですね

と、ウキウキのような出だしですが・・・
今日も午前中に会議が有ります。

昨日も午前中に会議がありました

昨日の会議も、会議中に訳のわからんことを言う輩がいて、議事進行がほとんど停止していました

会議とは、

• 議論する場であって
  
• 相談する場ではない
  
• 決める場であって
  
• 悩む場ではない
  
• 進めていく場であって
  
• 立ち止っている場ではない
  

と思っているんですが、間違っているでしょうか？
だれか、それは違うやろ―って言う人がいたらコメント欄にてお願いします

●そうはなっていないので

さて、話を元に戻して
昨日の会議も、相談して、悩んで、立ち止っている最低最悪の会議でした。
いつもは、三拍子揃っているわけではないので昨日ほどには・・・

はてさて、今日も会議が午前中あります。
昨日の様な三拍子そろっていないで欲しい
多く少なくとも一個で(笑)お願いします。

タグ：新システム開発 グループ統合 小田原評定 無駄な会議

今日の会議には、１０分遅れて参加しました。
参加した時、データベースの正規化についてベンダーが話していました。

あれっ？

ＩＴ教育してたっけ？

本物の会議でした
何々？
なんで今頃、こんな話をしてるのー？

でも、聞いていると真面目に話してはりました。
昨年末、新人女性社員に私が教えていたようなことを・・・


ほんとに、えっ？って感じです。
しかも、延々と一時間も話しています。

大丈夫でしょうか・・・・・・・・・・続きを読む...

現在、私の所属する会社が所属するグループで、グループ統合用の新システムを構築しています。
２月までで設計が終わり、3月からは製造工程に入る・・・はずなんですが
分化チームのいくつかは予定を消化できず、３月末までに設計完了
となっています。


昨年は、私はシステム構築会議に参加する為、毎週横浜に出張していました。
しかし、今年からはコロナの件もありフルリモート参加としました。

リモート参加なので、私が執務している部屋にいる、同僚みたいな年代の人にも参加してもらう事にしました。
強制的に

その方は、当然システム開発も、プロジェクトマネジメントもしてこられたので、会議に参加してもらっています。
僕はあまり我慢ができず、小出しにしている為、大爆発はして来ず、小爆発を何度かで済みました。

しかし、彼は我慢強く・・・・

そんな彼が・・・

とうとう吠えました

いや、こんなどころじゃありません









こんな感じですね

この眠れる獅子が吠えて、はてさて効果があるものかしら

現在、グループ全社を統合する為の新システムを構築中なんです。
現在は、吸収合併しながらも、独自システムを運用してきていて、
それぞれのシステム間インターフェースを行うのが大変なんです。

また、各社で運用が異なっていると、Ｊｏｂ　Ｒｏｔａｔｉｏｎがやりにくくなりますよね。

各社の運用を統合すると、何が良いんでしょうか？

• Ａ社で覚えた業務で、Ｂ社で訓練なしに働ける！
  
• 各社で同じシステムを使用できる
  
• システム間インターフェースは最小数で済む
  

普通、システムを刷新すると、現行システムより

• 高機能
  
• 高性能
  
• 低価格
  

のはずですよね。
そうでなければ新システムを導入する意味が無い・・・

しかし、
その新システム・・・私の会社のシステムより

• 高機能
  
• 高性能
  
• 低価格
  

なんです・・・

新システム構築プロジェクトに参画していますが、
私の会社に導入された時に、出来るだけデグレ（デグレード＝グレードダウンのこと）しないように、仕様調整で頑張ってきました。

しかし、

プロジェクトリーダーは、新システムを私の会社のシステムの水準に合わせる事が出来ずに
私の会社だけは現行システムをそのまま運用し続ける事に・・・なるかも！

ハイレベルすぎて、周囲になじまない当社のシステム・・・・

ちょうどきの記事のタイトル画のように・・・

今日も、グループ全社用で使用する新システムの仕様検討会議です
会議内容は・・・・


３月からプログラム開発開始になるというのに、今この段階で・・・
本当に、今こんなことはなしていていいのかしら

グループ本社のシステム担当の方も・・・
『それは、現場の人間に聞かないとわからない・・・』
えーーーっ！

これは・・・ベンダーさんはギリギリ間に合わせてくるでしょうね。

でも、どうしても間に合わない場合は、間に合わせる手段を講じてくるでしょう

昨日は・・・お昼ごろに営業さんから、ある顧客の請求明細書がおかしい・・・と一報が入りました。
聴いてみると、本来出力されるべき件数よりかなり少ないと・・・


報告内容をきいて、実際に請求明細書を出力し、現象を確認しました。
過去の経験から、これの原因は『あの辺やな・・・』と推定して、電話を切りました。

しかし、これが過ちでした。
初動がよろしくなかった・・・


何故、初動がよろしくなかったか・・・
これは原因を見誤り、対応時間見積もりを低く見積もりすぎたからです。

実際には、その後オンラインミーティングが１７時まであり、それにも参加しなければなりません。
なので、オンラインミーティングの後から対応すれば１８時までには完了すると踏んだからです。

しかし、原因はそんな簡単なものではありませんでした。
2006年に請求システムを改修した時のバグが潜んでいて、それが原因で請求漏れが発生していました。

何故15年もの歳月を経て・・・？
と、思われるかも知れません。

今回トラブルが発生した顧客には、請求システムの仕様上ではきちんと処理されるはずの依頼登録内容で設定していました。
しかし、それが特殊過ぎて、その特殊な依頼パターンに請求システムが完全に対応しておらず、非常に特殊なバグが発現してしまいました。

このバグを修正するために、修正とテストを何度も繰り返しました。
請求システム関連アプリケーションのテストは非常に大変です。
１円たりとも間違ってはならないからです


１時間どころか、２時間・・・３時間と時間だけが過ぎていきました。
しかし、原因を追究することもできませんでした。
バグは複数存在しました。２つはつぶしましたが、それでも請求額が漏れていることには変わりありません。


そこで、特殊な依頼方法ではな、顧客要求を満たしつつ、依頼登録部門の運用も変更しないよう留意して、正しく請求できるような方策に切り替えました。
（何で最初からそれにしないんだ？って疑問に思われる方も居られるでしょうが・・・それには理由があるのです。　請求明細書に出力される商品の名称を適切に設定したかったからです。それは断念しました。）

とりあえず、きちんと請求できることを最優先に、商品名称の多少不適切な部分については、営業から顧客に説明してもらうことにしました。

現在、私の会社の所属しているグループでは、グループ全社のシステムを統合するため、新しいシステムを開発すべく、仕様策定の最終段階を実施しています。

当然、いろいろなことを考えていかなければならないんですが、
今、そんなことを話している場合じゃないやろー
ってなことにも話が逸れていってしまいます。
ほんとに間に合うのかなー

今日、有った面白い話・・・・

アプリケーションのウィンドウの話になって、コマンドボタンとして


ってのがありました。

しかし、あろうことかわが上司・・・このＦ２：検索を　Ｆ１に変更できないかと

対応しているベンダーのリーダー・・・困ったでしょうね


お兄さん、しどろもどろの回答・・・
『両方ともＦ１にすると、Ｆ１が押されたときにプログラムはどっちをすればいいのかわからなくなるので・・・』

もぉ、聞いててベンダーのお兄さんがかわいそうでかわいそうで

その他にもいろいろと無理難題レベルのことや、
えっ！そんなこと知らなかったの？
とか、ＬＯＬポイントいっぱいでした

きっと、ベンダーのお兄さん・・・
困っててしどろもどろでしたが、心の中では

なんでこんな質疑応答してるんだろ WWW

って思っているに違いない

『滅びへの序曲』

今、グループでグループ統合用の新システムの構築をしています。
現在は、詳細設計という段階で、この工程を過ぎれば、エンジニアがアプリケーションのプログラミングに入ります。
と、言うぐらい最終段階なんです。

しかし、ほぼ毎日開催される会議の内容は、

• 枝葉末節にこだわっている
  
• 現場の運用が決まっていない、わかっていない
  
• データベース設計がころころ変わる
  
• システム間情報授受用のファイルのレイアウトもころころ変わっている
  

みたいな感じで、到底詳細設計工程で話し合うような内容ではありません。

しかし、期限は定められています。
その期限から逆算すると、現在は詳細設計工程に入っていないとダメなんです。
でも・・・・

Failure
の文字しか浮かんできません。
来年5月に、グループ内の一番小さな拠点で稼働開始が決まっています。
ご愁傷様です・・・

昨日も、今構築中の新システムについて【詳細設計】工程の会議があり、京都からオンラインで横浜の会議に参加していました。


当社のシステムと新システムは当然仕様が異なります。
しかし、現行の運用が新システムになって運用変更だけで事足りればいいのですが、新システムが全く対応できないとなると話は別です。
新システム仕様を変更するか、新システムの導入を拒否するかしかありませんから

昨日の会議で、問題が１件発覚しました。

当社の現行システムのあるマスタ（レコード数が96,000程度）を新システムの仕様にて再生成すると、
約8億レコード、使用量はやく500Gバイトになることが分かりました。

もう、これは笑ってなしゃーないレベルの問題です。

まず、

• マスタアクセスパフォーマンスはどのくらいになるのか？
  アプリケーションがマスタから特定のレコードを検索し取得するために必要な時間はどれほどか？
  ⇒やってみなけりゃ分からない・・・
  
• マスタ保守はどうするのか
  この膨大なマスタレコードを変更する必要が発生する場合、どれだけの時間がかかるのか？
  ⇒試算してみました。　今、ある顧客のある商品セットの内容を変更するのに必要な時間は、約1分です。
  しかし、新システムで行うと、最大45日です
  45分じゃないですよ！　単位を見てくださいね。
  

これはもう冗談のレベルですね。
ある顧客の商品セットを10程変更しようとしたら、その顧客には、『承知いたしました。それでは１年後からご利用になれます。』とか言わなきゃなりませんね。


このマスタがオーダーをシステムに登録するために必要なものです。
無視して通れません。
運用でカバーできることでもありません。

新システムの導入は見合わせるしかないでしょう。
新システムの仕様を変更してもらわない限り。


しかし、最後の最後で理解はしてもらえました。
何とか検討します。と言ってもらえました。（と言うよりか言わせた）


そこに至るまで。　検討すると言ってもらうまで。
どれほどの時間がかかったことか・・・

あー！　雇われ人は辛いなぁ