アフィリエイト広告を利用しています
G-QVESCNWRVH

2023年04月15日

地球の滅亡まで あと364日

宇宙戦艦ヤマト.gif

●Youtube見てると

たまたま、ってか暇にあかして
Youtube 見てると、お勧めの中に
●宇宙戦艦ヤマト

が・・・懐かしいなぁって思ったけど
前に結構見ているから、あえてまた見直す気にはならんかった

でも、子供の頃見ていて、印象に残っているのが
予告編の最後に

ナレーションは「人類滅亡まであと???日」って書いてあって
字幕には地球滅亡まで あと???日とか

ガミラスっていう宇宙人が地球を遊星爆弾で攻撃し始めて
徐々に破壊され放射能がどんどんと溜まって行って
そのまま放置すると一年で地球が滅亡するって筋書き

そこで、海底に沈んでいる戦艦ヤマトを改造して
宇宙戦艦にして、イスカンダルからもたらされた波動エンジンで
29万光年離れたイスカンダルに赴き・・・ってストーリー

子供心に、
いや、それなら最初から浄化装置の設計図を渡してくれたらええやん!
って思ったりしたひねた子供でした(笑)

いやいや、そんなことはどうでも良くて、
この、地球滅亡まで あと???日って言うのが
思い出されて、現在の当グループの状況に重なって・・・・
●地球を吹替え

なので、
地球  当グループ
って吹き替えたら

タイトル通りかもー
●笑いごっちゃおまへん

いや、笑いごっちゃおまへん
滅亡したら、一家路頭に迷う(かな?)
周りの人たちも困っちゃう〜〜〜〜

そりゃ、手に職(技術)を持っている人は
転職とか簡単に出来るやろうけどね・・・

2023年04月09日

やっぱり、会社が大切にしなければいけないものは・・・

大きな勘違い.jpg

●企業にとって大切なもの

企業は利益を追求し、拡大することを目的としています
その目的は何もしなくて達成されることはありません。(一部を除いては)

その目的を達成するために、企業には創業者が居ます
そして、創業者の志に同調した者が集まり企業ができます

企業の最初はワンマンだったかも知れません
でも、それが一人二人と集まり、大勢で構成される企業になる事もあります
そして、それぞれの人はその役割ごとに部門に分かれます
・経営部門
・営業部門
・製造部門
・事務部門
・経理部門
・人事部門
・システム部門
などなど
●この中で

さて、企業にとってどの部門が一番大切でしょうか?
それを見誤ると、どこかの企業みたいになってしまいます

凋落の一途
●製造部門

当社が属する当グループは製造部門が一番力を持っているようです
ある日、製造部門の責任者が営業部門はバカって発言しているのを聞いたことがあります
営業は製造部門の言う通りにやっていればいいんだ!って

ある時、製造部門とシステム部門での新システム構築プロジェクトで
(今のではないですよ! 十年以上前のことです)
会議の最中、システム部門が開発概要を提示しました

すると、
製造部門の責任者:(さっきとは別の者です)期限までに出来なかった場合はどうするの?
システム部門の責任者:間に合わせます。
製造部門の責任者:もし、間に合わなかったらどうするの?
システム部門の責任者:死ぬ気で頑張ります。
製造部門の責任者:では、間に合わなかったら死ね

●いのち

これ・・・同じ会社の人間通しの会話ですよ
信じられますか?

もう、完全に信頼関係とか仲間意識とかが破綻していますよね

最初にも言いましたが、同じ志をもつ人間通しが
こんな会話をしているようではだめですよね

同じいのちを持つ人間
心臓が肝臓に、お前は要らないから死ね・・・とか
肝臓が肺臓に、俺が頑張るからお前は要らない・・・とか
言い出したらどうします?

2023年04月06日

システムエンジニアは経営者次第

経営者に必要なもの.jpg

●経営者の質

ほんと、常々思うんですが
システムエンジニアって
経営者の庇護のもとに仕事をしているんだなぁって

だって、経営者が交代した途端
それまでは、バラ色だったのが
今ではまっくろくろすけ
●生かすも殺すも

本当、システムエンジニアを
生かすも殺すも経営者次第ですよね

システムエンジニアを行かせなければ
どうなるかは火をみるよりも明らかです

経営者はシステムエンジニアに
方向性だけを示せ
それ以外の専門的な事については全て任せよ

その専門的なIT技術を駆使するために
システムエンジニアが居るのだから
●システムエンジニアの存在意義

システムエンジニアの存在意義とは
私はこう思います

業務運用に合わせて
システムを構築すること

その際に次の点に重視すること
・業務を効率よく運用できるようにすること
・業務を正確に行う事ができるようにすること
・業務を簡便に行うようにすること

これに尽きます
これが出来なければ、システムエンジニアは二流
いや三流以下です
●経営者の存在意義

当然、経営者にも存在意義はあります
経営者はまず
・腰を低くしなければならない
・他者の意見に耳を傾けなければならない
・自分の信念は貫かなければならない
そして一番重要なのは
・従業員を道具として扱わない事
・従業員に仕事を任せきる事
これが必要でしょう

これが出来なければ・・・衰退の一途をたどるでしょう

あれっ? どこかで見たような・・・・

2023年04月04日

今度こそ息の根を止める?

もうだめだ.jpg

●新請求サブシステム

月曜日は新請求(サブ)システムの仕様検討会議の日
4月3日にももちろんありました
そして、私は途中から参加しましたが

参加したところからさかのぼって決定していることを見ると
愕然としました
●請求起算日

親会社の請求ロジックそのままで、
当社の請求ロジックなんてつゆほども考慮されていない
そして、我が上司は、全顧客、この請求条件にあわさせる

すっごーい
そんな事ができるんだー!
我が上司が直接顧客に行って交渉するんだー

って訳ないから、交渉するのは営業の方々
でも・・・
請求条件の変更ってなかなか難しいはず
●請求額計算方法

請求は、一か月単位で行います
まぁ、良くあるのはその月一か月分の請求を
末日で締めて、翌月支払いとかですね

ただ、そのまとめる対象は何かと言うと
請求日が1日〜末日までのものを末日で締めて計算

すると、問題になるのが
請求起算日の決定方法です

これが、当社とグループ他社の大きな違いです

でも、上司は請求起算日の設定を全部統一し
当社の顧客については、それに合わさせる・・・そうです
●こりゃ・・・

まぁ、言うのは簡単ですがね・・・
言うに安く行うに難しって言葉通りの展開です
しかも、言ってるのはシステム部門の責任者

やらせようとしているのは営業の方々
こりゃ・・・営業の方々には過酷な試練が待ち受けてるでしょう
もしかしたら心が病んでしまうかもしれません

いままで、稼働している新サブシステムのおかげで
営業さんは謝罪行脚をしています
これにさらに・・・

2023年04月01日

2023年度だー

シーソー.gif

●まだ生きながらえている

4月1日・・・2023年度となりました
怖れていた「4月から来なくていいよ」って通告は
まだ無いみたいです・・・

頑張ってますね・・・
システムがしょぼい分、現場の人たちが_| ̄|○
とりあえず、契約を解除される事は無かったみたいで良かった良かった
●契約は年度ごと・・・

契約は基本的に年度ごとに行われるので
年度が替わって契約が継続していれば
とりあえずは来年3月末までは・・・
●重大なミスが無ければ

ただ、大きなトラブルがあれば
年度途中でも契約解除される事があるので
まだ安心はできません。

しかし、今年初めに新システムの一部が稼働し
私の耳に入って来るだけでも結構な頻度でミスが

昨年まではほとんど耳にしたことがないような
初歩的なミスとか・・・
●どちらが早いか

これは、退職者が続出し、
特にベテランがスピンアウト
そのため、残された人たちは

人手不足と経験不足のダブルパンチで
当然、ミスも起こりやすくなり
このような結果に・・・

はてさて、
ミスにより顧客からの取引契約解除が多くて・・・
退職者が続出し、業務継続が出来なくて・・・

どちらが早いかな〜?

2023年03月31日

新システム対応のために苦労する

Interface.png

●新システムで対応できない

当社のシステムには
色々な機能があり
それらの内でいくつかは新システムで対応不可
●しかし、受託入力は

全て新システムで賄うこととなっていて
そのような指示を上司から受けている
なので、やらざるを得ない

しかし、お相撲さんのご飯は
小児用茶碗に入れるのがとても難しい

それ以上に難しいことを
やれって言われている
それでも、出来なければ現場が困る
●そのためのインターフェース

先週は、その機能の内の一つを
先週中に開発しなければならなかった

それは、今週火曜日(4月4日)に
完全稼働させなければならないからだ

なので、本来なら2〜3か月はかかるところを
1週間足らずで仕上げろと言う
無茶な要求に応えるしかなかった

それが出来なかったら、現場の人が
全て手作業をしなければならなかったから
●緊急に

ほんと、緊急対応と言うべき開発だった
なんとか、完了直前まで持ってこれた

4月3日(月曜日)に
最終確認を行う予定
上手く行ってくれると確信している

上手く行くまで徹夜してでも仕上げるから・・・(;O;)

2023年03月30日

契約解除・・・その理由が(T_T)

もうお別れ.jpg

●既に通知済み

これまで長きにわたって取引していた
日本有数の大企業グループ
今日は、Zoomで会議

責任者から参加要請があり参加
もしかしたらのシステム関連質問対応の為
●最終会議

しかし、話を聞いていると
どうやら、取引のための契約解除を既に申し入れており
先方より、4月末での解除は急すぎる

そりゃそうでしょうね。
業務内容は継続して行われているので
あと、一か月でって言っても先方では対応がとりにくい

いや現実的に対応できないと言われました
そこで、1か月延期してほしいと
5月末での契約解除にしてほしいと頼まれました

ところが、当方の現場責任者が
退職者が続出するため
5月末まで業務を継続することは非常に困難だと
●メインを当社が

その業務に関するシステム
その大企業グループの品質管理部門の部長が
当社を含む同業他社を集めて、したい事を提案

各業者は、そんなことが出来るのかと否定意見ばかり
そんな中、私だけが、『なぜ出来ないの?』と肯定意見を出した
それが気に入られて、当社がその業務の半分を担当することに

そして、システムも私が開発し
各業者に管理システムを提供し
また、日本各地の主拠点にそのシステムをインストールする名目で
その部長と行脚

当然、沖縄にも拠点があり、そこを訪問
人生初の沖縄だった
その部長、気の毒がって、スケジュールの合間

今は消失してしまった首里城に連れて行ってくれた
私の苦手なゴーヤチャンプルーを進めてくれて
(後で聞いたけど、その部長はゴーヤチャンプルーが嫌いだって
●悲しい

稼働し始めて数年後、個人情報保護法の制定に伴い
データ授受のために作成するファイルを暗号化してほしいと要求され
Blowfishと言う1024bit 秘密鍵による暗号モジュールを組み込んだ

当時としては最強部類の暗号であったが
秘密鍵の為、結構管理がめんどくさかったはずだが
それを簡単に素人でも管理できるように組んだので

またまた喜ばれた

その後も、何度か改定を繰り返して来た
でも、グループ統合の走りから
当社の対応が悪くなり、疎遠になってきてしまい

とうとう、二十数年の幕を閉じることに
悲しいです

今日も憂鬱な会議が

当グループと開発ベンダー.jpg

●週一回の定例

今日は木曜日なので
毎週一回、周辺システム定例会があります

何をするかと言うと、新システム構築に絡んで
いろいろいろいろいろいろいろいろいろいろいろ
周辺システムと連携しないといけないのです

ほんと、周辺システムがいっぱいあってね
●周辺システム開発ベンダー調整会議

単一のシステムなら、調整なんて必要ないのに
複数のシステムが混在しているから
一か所直すと関連する部分を芋づる式に直さなければなりません

その数や人間の能力の限界に挑戦!
いや、既に負けてると思いますが
それらをち密に間違いなく直していく

これって神業に近い(笑)

昨日は、それとは別に
運用調整会議がありましたが
その中で現場の人が

かくかくしかじかで、これこれどれどれって質問した時に

開発担当ベンダーのメインのF社のリーダーが―
その部分については(当社の名前)で改修してもらわないとダメです
って言いきりました!
●なぜか

私はその時すごく違和感を感じました
なぜなら、当社は開発を委託する側
すなわち開発ベンダーからしたらお客様の立場

つまり、言い方ってもんがあるやろ
●微妙な立場

親会社の我が上司が、
ベンダーで開発するか当社で開発するかの二択となる場合
決まって、当社に開発するよう指示します

まぁ、そりゃ当社でやればタダですから!
でも、その言い方をF社がするのはお門違い!

普通ならば、F社のリーダーは
この件については、当社(F社のこと)で行うか、(当社の名前)で行うかどちらかになります。当社で行う場合は追加仕様となりますので申し訳ありませんが追加費用が発生してしまいます。しかしながら(当社の名前)でして頂けるのでしたら弊社からの追加費用請求は行わなくて済みますので、どうか(当社の名前)で改修いただくようお願いできますでしょうか。
でしょう?
F社のリーダー、分かってるんでしょうかね?

まぁ、開発出来るか出来ないかという観点から見れば
当社は開発ベンダーの一員ですから
開発できないのは、親会社のシステム部門ですから

はーーーっ! 困ったもんだ!

2023年03月29日

やばい・・・請求システム仕様に

計算結果の違い.jpg

●グループ各社の仕様

現在、新しい請求システムの構築が始まっています
それは、受注部分、製造部分を統一したサブシステムが出来た(つもりみたい)からです
そして、納品処理部分は今年5月にリリースされる(つもり)予定です
●統合新請求サブシステムの仕様

その新請求サブシステムの仕様を検討しているところですが
グループ各社を例えば
A社(グループ本社)
B社(グループ子会社)
C社(   〃   )
D社(   〃   )
T社(   〃   :当社)
とします。

請求処理の方法で分類すると
A,B,C:Aタイプ
D:A+αタイプ
T:Tタイプ
と大きく分けて2種類になります

そこで、かれらは最初やりやすい方から仕様を決定していきました
A及びA+α ⇒ A’ に
これは簡単でしょうね

そして、私の方にT社の請求ついてどのような処理をしているか教えてほしいと
彼らは、T = A+α’ ぐらいに思っているんでしょう
でも、実は全然違うんですよね

T仕様は実は全く異なるんです
さらに機能的には(転換後A)+αβγδη ぐらいでしょうかね。
これらの Aタイプにない仕様をどのように実装するんでしょう

先週の月曜日でしたか
この件のプロジェクトリーダーが言った言葉
『(当社のU名前)の仕様で、新システムで対応できないものは、取り入れない』

えっ?
当社では、自社開発の強みを生かして
顧客要望の変化(当然、環境が変わると顧客の収益も変わり、値下げ要求が発生する)
世情動向の変化(客層、客筋の変化、経済要因の変化、行政の対応の変化、法令の変化)
に対応すべき、何度となく仕様変更(概ね機能追加)を行ってきました

このため、かなり複雑な請求処理になっています
しかし、複雑になってはいますが、私のポリシーにより
現場の作業工程は極力増加しないようにしています

下手したら作業工程が簡素化され、減少しているとも言えます
(この目的は[人的作業によるミス発生の低減][作業時間の低減]があります)

当然、現場の方には喜ばれ、かつミスも少なくなったので
営業の方、顧客にも喜ばれることはないでしょうが、怒られることは無くなっています
●細工は全然、仕上げはダメだろうなぁ

そのような複雑な機能のほとんどはカットされると思います
すると、10年以上前の仕様に戻ってしまい
暗黒時代が到来するわけです

経理部門・営業部門ともに人員が減少している中
新請求サブシステムの稼働により更に人員が必要となり

しかし、人員補充はなかなかできず、常時人手不足状態

新請求サブシステムについて細工は流々仕上げを御覧じろ・・・ではなく
細工はボチボチ仕上げは見ない方が良い・・・みたいな
●同じような請求額に?

請求と言うものは、お客様にお支払いいただく金額を提示するものです
提示した金額がお客様に納得して頂けるならば、引き続き取引をしていただけるでしょう
逆に言えば、納得して頂けない(たとえば同様のサービスを他社から安く提供されるとか)場合

お客様は当社から離れていくでしょう

なので、先も言った通り
●顧客が納得できる金額の計算
●当社が泣き寝入りしないで済む金額の計算

もう、この辺は企業秘密ともいうべきノウハウの部分です

単純に示すことが出来る点としたら
A社もT社も顧客が1000社 その顧客の代理店が各10000社とします。

A社では、顧客ごとに割引率が設定されています
まぁ、これは当社もです

請求額(ここで請求額は整数、割引率は千分率となります)計算は
A社:代理店ごとに請求額を計算し顧客ごとの割引率で計算、小数点第二位を切り捨て
   顧客ごとに代理店の総計を算出し、請求書額面額とします。
T社:代理店ごとに請求額を計算します
   顧客ごとに代理店の総計を算出し、総計に顧客ごと割引率で計算し、請求書額面額を算出します
この両者の違いによって、1000社請求額面額合計は理論値で、¥490,500になります

これは、経理をされていた方なら簡単に理解できると思います。
A社の請求額計算方法とT社のそれの違いは、割引率をどこでかけるか?です

ちなみに、我々と代理店の間には契約関係は全く存在しません。
なので、代理店の請求に対して割引率を乗じて計算する義務はないし
義理も人情もありません

でも、A社ではそれを行い、損失を発生させています

2023年03月25日

BA?Aに付ける薬はない・・・・か

杜撰な結果.jpg

●議事録確認

新システムが稼働してはや3か月弱
新システムと言っても、全行程の一部なので
新サブシステムと言った方がいい

で、次なる新サブシステムの仕様検討会議が毎週何度か開かれる
会議のたびにベンダーさんが議事録を送ってきてくれる
普段は流し読みしかしないのだが(参加しているから)

今回、先週金曜日(3月17日)についての議事録
当日、私は休暇を取っていたので(ちょっと沖縄
つぶさに確認してみた
●休むこともできないのか

もうね・・・
何を考えてこんなやり取りをしているんだろう
このまま、進めば

親会社の従来システム・・・つぎはぎだらけ
このシステムを新システムに置き換えるのに
変わったのは受注部分だけで他は

新しくなったのに、変わってるとこが無い
●改善する気が無い

親会社のシステム部門って
システムの専門家ではなくて
経営層からの下請けだけの部門

今回の新システム構築は、受注部門だけの改定?
せっかく全て新規に開発するのだったら
どうして、それぞれの部分で今まで困っていることを解決しないの?

どうしてしないかは、私は知っている・・・・
だって、どうしたらいいか分からないから
現場がどれだけ困っているか
何を望んでいるのか

全く知らないから
●馬鹿につける薬はない

それが、資本関係で親に当たる会社のシステム部門

基幹システムの再構築をするためには
@現在の問題が何であるかを特定する
A今までできなかったことですべき事はなんであるか特定する
B今までできなかったことで実現したい事は何であるかを特定する
C@は必須、Aも必須、Bは費用面で折り合えば実施 という観点で計画する

あとは開発するだけ
ただ、Cの計画の時にずさんな計画なら
当然のことながら出来上がったものもずさんになる

丁度・・・今のように
いや、ABを行っていないから、さらに杜撰であろう
ファン
検索
<< 2024年11月 >>
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
最新記事
写真ギャラリー
最新コメント
タグクラウド
カテゴリーアーカイブ
プロフィール
Y.Taki@AS400さんの画像
Y.Taki@AS400
IBM AS/400で稼働するシステムの開発・追加を担当して30年以上になります。使えば使うほどこの AS/400 が好きになりました。 こんなSEがいろいろな視点から様々な業務などについて語ります。
プロフィール