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

●ビジネスの根幹

基幹システムを構築してきたシステムエンジニアにとって
一番重要視しているのは・・・請求？
商品やサービスを提供して、その代価を頂く

その代価がいくらであるか、契約情報に基づいて計算します
この計算に誤りがあれば、とんでもないことになります
なので、必死こいて作りこみました

当然、自前で開発しているので
全ての運用・仕様は保持しています
ただ、自社開発のデメリットは

仕様が最新状態に維持されているわけではない

と言うことです。
顧客から急に要請や要望を受け、
それに緊急に対応しなければならないとき・・・など

●仕様作成

なので、既存の仕様書を確認し、
現在の運用・仕様と異なるところを抜き出して
最新の状態としています

しかし、私もシステムへの新規機能追加や変更を停止して早４年
なかなかに忘れていますねー(笑)

なので、データベース記述書やプログラムソースを読んで
記憶のリフレッシュ中です

当然のことながら、私は親会社の請求ロジックもある程度知っているため
今回、当社の請求の仕組みを思い出しながら

こんなこと、新システムで出来るんかいな―？
だって、いろいろな情報にアクセスしなければならないのに
新システムでは、それぞれの工程が独立したサブシステム

新請求システム（今から作ろうとするグループ統合請求システム）は
もらった情報を取り込んでため込んで請求処理をするから
全情報をもらっているわけではなく・・・

●考え方が根本的に異なる

しかも、請求額の決定方法については考え方が異なっています

当社のは、一か月ごとに確実な請求額を計算して請求書を出す
親会社のは、一か月ごとに請求額を計算して請求書を出す・・・けど
過不足があれば次月相殺する・・・んです

なので、当社では、請求締め日前後の請求対象が変更されれば
即座に反映するようにシステムを構築していますが
親会社のは、どうせ次月相殺できるだろって感じなんです

どっちがいいのか？
どっちも正解だと思います
ただ、処理方法は異なります

そこをどうやって合わせていくのか・・・
これは見ものです

●一から作り直し

で、当社の請求システムの仕様書を見直してみると
それはまぁまぁ９０点ぐらいの状態で維持されていました

でも・・・それを１００点にするだけではだめって事に気付きました

それは・・・

語句
同じ単語でも意味が違うことがあるんです。

たとえば
受付日
当社では、受注し、依頼をホストシステムに入力した日を指します。
でも、親会社では受注した日を依頼日、入力した日を受付日として運用しています

よって、このことに言及せずに仕様書を親会社に提示すると
必ず誤解します
誤解されれば一巻の終わりです

なので、この辺を注意して、変更（と、言うより翻訳）する必要がありますね

これって結構骨が折れます・・・
しかも今週中に仕上げなければ・・・大丈夫かな？

●やっばり分かってもらえない

今日も会議で、一生けん命にその必要性を説いたのに
我が上司は分かりませんでした
いや、分かろうとしませんでした

今までこんなことを何度か経験してきたのに
この件だけは、当社側に合わせてもらわないとロジックが成り立たないって
色々と説明したけども、徒労に終わった

●私の説明が下手？

いや、もう、私の説明が下手なのかも知れないっておもほど
伝わらない・・・
色々と、親会社に無くて、当社システムに存在する機能について
我が上司に説明するけども、一向に理解してもらえない

●もう、やってられません

なんで、ここまで行って分からないんだろう？
多分、システム開発をして来なかったからなんだろう

ベンダーに対して我が上司が話している内容を聞いても
そんな感じだ

なので、我が上司に理解してもらおうなんてのは土台無理

●他の事をしようっと

いやいや！　これじゃあ、どんなにかんばってもむりじゃね？
馬の耳に念仏
猫に小判

あ〜あ！　勿体ない！

●現場から質問が

新システムに入力したところ、【剝がして】って入力したのに
【？がして】って登録されていて困った
って現場の方から質問がありました

それについては、入力系システムを開発した担当者が
調査して回答してくれています

●開発者から回答が

その回答とは・・・
ですって

●対応策の提示

最後に対応策が示されています
これを、現場の方に直接回答しています。
確かに言っていることは正しいとは思います
その通りにしたら、『？』になってしまう問題は解消できるでしょう

●どうすりゃいいの？

でも、入力する時にこれは環境依存文字だとか、JIS第一水準・第二水準文字だとか
だれが意識しながら入力するんでしょうか？
確かに『はがして』と入れて候補を表示させたら

このように表示されます。

ただ、『はがして』と入力して変換させると『剝がして』になります。
良く変換しているとそうなります。

業務で使用しているＰＣなら、だれがどのように変換しているか
そんなの気にしませんよね。

今回も、そんな環境で、入力したらたまたま最初に変換されたのが
環境依存文字
それを知らずに入力したら、報告書には『？』
お客様に怒られちゃったって

誰が悪いの？
さすが、人間が正しく操作したらうまく動く新システム
今回は、入力した人が悪いんですね〜

気の毒に・・・・

●昔々

あるところにおじいさんとおばあさんが・・・
ではなくて

人類は火を発明しました
人類は、木の板に木の棒をこすりつけて
その摩擦熱で発火させることを覚えました

ただ、この方法は、発火にいたるまでのプロセスに
ある程度の熟練と、体力と、知恵が必要でした

それに至るまでには長い年月が必要でした
江戸時代には、金属に石を打ち付けて、その摩擦で生じる火花を

そして、明治自体のほんの少し前、マッチが発明されました
これで、だれもが安全に火を起こせるようになりました

その後、年月を経て、今日では
誰もが簡単に火を起こせるようになりました

ガスコンロで、ボタンを押すと火が起こります
これは多分幼稚園児でも可能です

●なんで？

こんな事を語り始めたんだろ？
このブログはＩＴ関連だったはず

そうそう！　今朝、面白い事を聞いたからです
それは・・・・計算方法について

計算するには、
●暗算　（紙と鉛筆が無ければ、脳みその勝負(笑)）
●筆算　（紙に書くことでより複雑な計算が誰でもできるように）
●算盤　（ご存じ、そろばんです）
●計算尺（掛け算・割り算なども簡単に・・・ただ近似値を求める科学技術で・・・）
●電卓　（今じゃ、スマホのアプリに代わってる？）
●表計算（昔 MultiPlanなんてのが有ったなぁ）
●システム（特定の計算には特定のシステムが作成され利用されました）

ってな具合に、進化してきました

●今朝、聞いたこととは？

出勤してきたとき
普段見かけない現場の人と会いました。

なぜ普段見かけないかと言うと
夜勤者だからです

で、私の出勤の時にまで残っているのは？

って簡単に聞くと、トラブルだったそうです
最近ではよくあることなので別に珍しくもなくなりましたが
しかし、衝撃的な事を聞きました

以前、当社システムだけで運用していた時は
計算が全て自動で行われていました。
しかし、今では電卓をたたいているそうです。

よかった、算盤でなくて

●電卓って・・・いつの時代？

ネットで調べたら・・・・１９６３年に初の電卓が出たそうです
約６０年前ですね
どっひゃー！　古くからあったんですねー(笑)

でも、最近でもあることはあるんですが
Windowsが世の中に出てきたとき
Calc.EXEって電卓アプリが標準でついていました

なので、わざわざ電卓を購入する必要がなくなってきた・・・わけです
最近では、スマホアプリに標準で添付されてます
なので、わざわざ購入することもないですよね

でも、総務課とか経理課では、電卓が机の上に置かれているのを見かけます
使用頻度の差ですよね

電卓が登場した時はすごく便利になったわけです
ちょうど、冒頭のマッチですよね。

しかし、既にコンロでボタン一つで火が起こせていたのに
マッチの時代に逆戻りすると
便利ですか？　そんなことはないですよね。

それが基幹システムで起こってるんです

●４分

今朝９時半から会議がありました。
終了は・・・１０時の予定で、約３０分です
しかし、会議が始まっても、何も話しません

プロジェクトリーダーが何もしゃべりません
すると・・・しばらくして？

今日は何を話そうか？
何か話すこと無いかな？

私のところのリーダーが
先週金曜日話したので、進捗は無いです

で、じゃあ、今日はこれまでって
４分で終わった！

会議はどうやら開くことが目的らしい

●最長は５時間ぐらい

会議は会議でも、重要な（？）ことは長い事やるしなぁ
最長では５時間ぐらいも続いたこともあったなぁ
なんか、あーでもないこーでもないってぐだぐだと

小田原評定（おだわらひょうじょう）ってのがピッタリ


小田原評定って、

●会議好き？

もう、ほんと会議が好きなんかいってぐらい性懲りも無く会議するなぁ
でも、それも仕方ないかも
確固たる方針が無いから

行き当たりばったりでシステムを作るから
だからいろんなところで不具合が出て
そのたびにあーでもないこーでもない会議が行われる

●なんとも

これを何年も続けてきているのが凄い！
続けられるのが凄い！
ほんと・・・どうにかならないかしら？

●一連の工程

次の等式が成り立つとします
ＴＳ　＞　ＮＧＳ　＝　ＩＳ　＋　ＣＳ　＋　ＫＳ＋　ＲＳ　＋　ＤＳ

ちなみに、ＴＳ　＝　当社システムの略です

●一元管理の効果

当社では、単一のシステムで全ての事を行っています
いわゆる一元管理です
運用の隅から隅まで、単体のシステムで管理しています

ところが、グループの新システム（ＮＧＳ）は、各工程ごとに個々のシステムがあり
それらがお互いに情報連携を行って強調して動いています
といえば、聞こえはいいかも知れませんがメリットは少し

そのメリットもシステム部門にとってです・・・
いや、開発ベンダーにとってでしょうかね！
だって・・・・

●複数管理のデメリット

複数システムを管理しすていると、メリットは
・システム部門はシステム開発を他人任せにできる
・システム部門は開発遅延が起こると開発者（おそらくベンダー等）の責任にできる
・システム仕様が低いと、システム部門は要件定義者の責任に出来る
・システム間連携がうまく行かないとネットワークインフラの責任に出来る
とシステム部門にとってはかなりあります。

ただデメリットもわずかではありますが存在します
・出来上がったシステムが思い通りではない（要件定義がまずい）
・システム仕様が低い（要件定義がまずい）
・システム間連携がうまくいかない（要件定義がまずい、ネットワークインフラが酷い）
・システム開発費用が掛かる（多分、システム要員を１年間５００人ぐらい食わせるぐらい？）
・些細な変更でも費用がかかる（多分、システム要員を１年間数人食わせるぐらい？）
・そのたもろもろ（あまり書きすぎると、特定されるので）

●デメリット解消のために

今回は、上にあげた一連のデメリットの中で
３つ目のシステム連携の不備について、その解消方法を聞きました

ＫＳの完了を、システム部員が認識し、ＮＧＳ本部に知らせる
これは、サーバー停止日に行うべきものとして規定されました
ＫＳが終わる前にサーバーを停止すると、ＫＳが完了できないからです

通常は、サーバー停止前にＫＳが完了しますが
何らかの要因でＫＳが遅れていると・・・
先にサーバー停止されると更に酷いことになるからです

つまり、サーバー停止日（多分日曜日・祝日が多い）には
システム要員がだれか出勤して（または翌朝まで残って）
ＫＳ完了を確認して上で、ＮＧＳ本部に連絡するという作業

これが新規追加されました

今まではＴＳでは全自動だったのに・・・
ってか、そもそもＴＳはサーバー停止なんて
サーバー停止何て
サーバー停止？
そんなことあったっけ？

停電のとき？
いや自家発電機が自動的に稼働するようにしているし

そんなこと、ここ何年かであったかなー？

みたいな環境から
月数回のサーバー停止と、システム要員の日祝勤務が必須となりました(笑)
素晴らしき新システムに幸あれ

●重複機能

これからは、新システムについては
既存システムの仕様を少し改良して開発

当然、機能を拡張する場合
マスタデータベースの仕様拡張も必要になる

すると

●現行システムのマスタ
●新システムのマスタ（＝現行システム［＋α］マスタ）
の２種類が存在することとなる

●重複マスタ

これらの重複マスタについて
現行マスタは、新システムが稼働するまでは使う必要がある
ゆえに現行システム運用のためにメンテナンスする必要がある

加えて新システムマスタについて
先日の会議で、これもメンテナンスする必要があるとのこと
これについては、誰も異論を唱えなかった・・・

と言うよりかは、そうしてくださいって命令だった

●二重登録

この事は、つまり

今後、現場の人たちはマスタ登録／変更申請するときは
現行システム用は今まで通り、加えて新システム用の
二重登録申請を行わなければならないことに

言う方は簡単でしょ！　言うだけ　やらせるだけだから
でも、やる方は大変でしょうね
作業が２倍＋αになるんだから

しかも、登録申請方法の説明はおざなりで、それだけでわかるわけも無いと思う
それでも、登録者側の担当者は
もし、旧フォーム（古い申請用紙）で提出された場合は、一律却下します・・・だって

新規顧客登録でも

そりゃ、営業さんもわざと旧フォームで提出することは無いでしょう
でも、明日から新フォームでって言われても
その会議の時に既に作成しているフォームは全て新フォームに書き換えろって？

普通、１週間後からとか来月からとか周知期間を設けるでしょ
しかも、並行期間も設けるでしょう

●その理由

二重登録させる理由は単純です
システム部門が何も考えていないから

新システム用のマスタ登録情報は
現行システムマスタ情報から作り出せばいいじゃん

新システム稼働前にね
機能拡張って言ったて
現行仕様より設定できる箇所が多くなっただけ

当初は変更できるわけも無く
＋α部分はデフォルトで運用しはじめなければ
現場も顧客も混乱をきたしますから

でも、二重登録を強要
これって、現場の作業量を全然考えに入れていないだけ


みたいな、意味不明の指示だと思います

先日の会議で私も初めて聞いて、しかも決定事項となっていたので
抗う事も反論することも出来ず・・・力不足に陥れられました

●機械にできることは

長年システムエンジニアをしてきて
人とコンピューターの役割分担について
考えてきました。

って言うよりかは、コンピューターは単なる機械だと
算盤や電卓の進化したものではあるけれど
それだけ

正確で、従順で、迅速だけど、それだけ

多くの人は、コンピューターを使いこなすのが出来ないで
コンピューターに使われているような感じがしているけど
そうではなくて、コンピューターを動作させている

Windows, iOS, Androidなどと、その上で動作するアプリの
作者の想いのままに動かされているだけ
結局は、高度な演算をこなすコンピュータを搭載した車と変わらない

●人しか出来ないことは

でも、人にしか出来ないことは確実にあります
でも、人でも機械でも出来ることはそれ以外ですね
コンピューターという機械を使えるならば、使おうよ

そういう想いで、システムエンジニアとして
システム開発をしてきました
入力された情報を覚える、処理する、いろいろな形式で出力する

形式的な作業は全てコンピューターにやらせれば良いんです
機械に出来ることは全部機械にやらせれば良いんです
人には人にしか出来ないことだけすれば良いんです

機械にどんなことをさせても文句は言いません
それならば・・・

●全自動を目指して

ある工程について、100%機械に行わせることができれば
その工程について、人が労力を払う必要はありません

もちろん、その工程を自動化したプログラミングに問題があったり
なんらかの外的要因で正しく完了しないことはあります

万一のために、工程が正しく実行されたかを確認することは人の役目です
いわば現場監督的な存在ですね

●新システムになって

これまで、そのようなポリシーでシステム開発を行ってきて
ほぼ全自動になるまで成熟させてきました

当システムと、情報を受け渡す顧客側システムとのインターフェースを作り
相手側にもメリットを与えつつ、当方にもメリットを受けるように

考えてください。
このインターフェースはもともとは手作業でした。
情報の授受は紙媒体から、フロッピーディスク、ＵＳＢメモリと変遷はありましたが

受け渡しには人が必要でした

それが今やシステム間インターフェースを通して
人の手を介さずに情報の授受ができるようになっています

ただ

新システムが稼働すると
人手が必要になります

なんででしょ？
私にはよくわかりません

我が上司は、現場の人たちに楽をさせたらだめだ
と、以前言っていました

私は、その言葉を聞いて、あまたがおかしいんじゃないか？
そう思いました。

だって、１００人の従業員がいて
自動化することによって、５０人分の作業で済むようにしたら
５０人は遊んでしまう？　それとも１００人が半分ずつしか働かない？

そう考える上司って・・・

私は、今まで１００人が必要な作業を機械が行えるようにして
５０人で行えるようにしたら・・・・

作業量が２倍になって、人件費はそのまま
普段は作業量が２倍になると、人件費も原材料費も２倍
利益率は変わらない

でも、私の考えだと、
売上中の３０％が人件費だとして
２０％が利益だと仮定

すると、機械化（自動化）によって
５０％が原材料費などの変動費としたら
利益率は３５％になります

たんにコンピューターに仕事をさせるだけで
作業員人件費の倍増分が削減されて
純利益となって計上されます

これを新システムではしないんですよね
我が上司は、これを現場要員を楽にさせると考えるんですよね

ついていけませんよね

●システムエンジニアとして

この４０年近くシステムエンジニアをしてきました

入社した当時は、それまで稼働していた三菱製基幹システムから
ＩＢＭ　Ｓｙｓｔｅｍ／３８にリプレースすることを目指し
システム構築を行っていた最中でした

リプレースとマイグレーション自体は、当時のシステム要員が行いました
ただ、数年すると仕様の限界が来て、改定する必要が発生しました

その時には既に私が中核となってシステム部門を運営していました
なので、この改定作業も私がメインとなって行ってきました

ベースはある程度とどめておきました
設計思想は素晴らしいものがあったからです
ただ、ハードウェアの性能自体が設計思想に追いついておらず

妥協点でシステムを改訂しました。

●去り行く運命？

その後、数々の拡張を繰り返してきました
小さいものから大きいものまで数え上げると
いや、数えきれないぐらいの改定・改良を加えてきました

大きいものだけでも５０以上あります
その中には、ＩＳＯ対応や、プライバシーマーク対応もあります

しかし、数年前、グループ経営者が変わり
当社が子会社という立ち位置なので
親会社のシステムが主導で、新しいシステムを作ってきました

親会社のシステム部門が作ると
当然親会社の運用をメインに構築してきています

芸がないのは、親会社のシステムは、小さなシステムの集合体
だから、仕様変更が簡単に出来ないのがネックです

このため、変な（親会社の現場が）仕様がそのまま引き継がれています
恐らく５０年以上前の仕様です

ほんと、しようがないなぁ　って言葉通りです
そのような当社から見れば旧式な新システムを導入され
運用することを強要され、すでに２か月たちました

つぎつぎと新サブシステムを構築しようとしていますが
新とは名ばかりで、中身はほとんど変わっていません
いったい何がしたいのかよく分かりません

しかし、やっぱり資本が大きい方が強いので
旧式な新システムが当社にも導入され
当社の元々のシステムは徐々に追いやれて行きます

●どっちにしても

ただ、新システム稼働のおかげで
●顧客離れが多発
●現場要員離れが多発
となっている現状

赤字とーさんが早いか
ろーむとーさんが早いか

二者択一みたいな感じです。

●ねずみ

残された道は・・・どーなるのか？
良く分かりませんが、
当社のシステムの根幹となるシステム構築ポリシーは私の頭の中にあります。

なので、当社システムが全て追いやられた場合は
新システムの維持、保守などは、若い人たちに任せて
（もし当社が残っていた場合）

私は、またどこかで・・・

●今日は休暇

今日は、故あって休暇を頂きました。
用事があったからです
まぁ、やることが一杯あるので、真の休暇って年に何回か・・・

●さっき、のぞいてみると

まぁ、それでも会社を休んでいると
その日にどんな事が起こっているか気になってしまい
会社のネットワークに接続し、

自分が普段使っているパソコンに入って
どんな状況か確認してしまいます

●見なけりゃ良かった

でも、見る前は
今日はどんなことが有ったんだろうなぁって軽い気持ちでしたが
今は、とっても重い気持ち

●フラッシュしよーっと

まぁ、今日は休暇だし
今日起きたことは今日出勤している人が対処するやろう
そうしなければお客さんが怒っちゃいますからね