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

●どう考えてもおかしい

現在、当グループでは、グループ各社の運用・システムを統合するための
グループ統合システムを構築しています。
連日、システムの仕様を検討する会議が開かれています。

今朝の会議では、商品の形態についてベンダー側より提案がありました。
しかし、我が上司はその提案に賛成していませんでした。
我が上司もその提案を行いたいと発言はしていました。しかし

●修正を提言

私も、ベンダーの提案を全面的に支持しました。
なぜなら、当社のシステムはすでにそのようにしているからです。
この提案が受け入れられたら当社システムと新システムのインターフェースが楽だからです。

●上司の言葉

しかし、そうしたいと言っていた我が上司も、やっぱり出来ないと・・・
理由は、なんと
過去の遺物に引きずられてしまっているから

せっかく新システムを構築しているのに
過去の遺物に引きずられて、意味のない商品形態を継続しなければならないって

どうやら、新システムと関係する周辺システムとのインターフェースを変更せねばならず
その周辺システムはそのうちに廃止するから
廃止する予定の周辺システムを変更するような無駄な事が出来ないと

●未来永劫

ばっかじゃねーの？
そんな事言ってたら、未来永劫、過去の遺物まみれ

新って言葉は2022年に作ったって言う意味だけで
それ以外は従来通り

愛想が尽きた・・・

●新システムと現システムの接続

今、当グループでグループ統合システム（俗称新システム）の構築が進められており
来年一月に当社にも導入されることになっています。
先ほどもそれに向けた会議が行われていたところです。

●大詰めになって

ただ、この期に及んで、問題が出るわ出るわ
おかげで、ベンダーさんに仕様変更を要請しなければならない始末
いや、もう、２か月前を切ってるんですがね

これだけの大規模システムで
この時期で仕様変更って・・・

●なんでデグレのために

それと、土曜日も休暇を返上して資料作り
そして、それが問題を浮き彫りに・・・・

表題の絵の左側のように、左側みたいにすっきりしているのを
右側のような、ちぐはぐなシステムにするために

これって、効率、保守性、障害耐性が落ちます。
当然、運用面でも・・・
手間が増え、人手が必要に

なんで、こんなデグレのために頑張らなきゃならないの？
生産性が全くない仕事をなんでやらなきゃいけないの？

●間違えてた

いやいや、それは違う！
私の役目は、いかにしてグループ全体のグレードを上げて
当社に導入された場合のデグレ度合いを減少させる

それが目的だぁ〜
でも・・・まるで、しゃもじで耳掃除が出来るようにしろって言われているみたい・・・

●統合システム

現在、グループ統合システムを構築中です
でも、何を統合するかと言うと
グループ企業各社の運用を統合することです。

●聞こえは良い

これって、合併吸収などで、グループ企業間で運用が異なる場合
種々の非効率的な影響が出て
全体的な効率が理論値よりかなり低下するため、行われます。

なので、現在進めているグループ統合は
理想なのです。
しかし、現在、当グループで行っている統合は

名前大負けしています。

●親会社のプライドが邪魔している

親会社の運用と子会社の運用が
かなり異なっている場合
統合するためには、大抵親会社の運用を押し付ける格好になります。

当グループでも例にもれずそのような統合方法です。
ただ・・・・

●システム面から考えると

親会社のシステムは、数々のコンピュータシステムの複合体
そのデメリットは
　データベースの一元管理が出来ていない
　マスタの一元管理が出来ていない
　システム間連携の不備から、アナログ的運用が必須
　対障害機能が弱い
　障害発生時の原因追及、復旧時間が長くなる
　保守費用が高額となる
　自社開発が出来ない
　システム開発費用も高額となる
と、いいことありません。
逆に当社のシステムは単一のシステムです。
よって、上記に上げたデメリットは無いか、真逆です。
　データベースの一元管理
　マスタの一元管理
　システム間連携は不要。よってアナログ的運用は皆無
　対障害機能が高い
　障害発生時の原因追及、復旧時間が短い
　　そもそも障害発生が起きにくい。ハードウェアが少ないから
　保守費用がかなり抑えられる
　自社開発している
　システム開発費用はほぼゼロ
です。

●当社の終末

このような親会社の複雑怪奇なシステムを
当社に導入し、2023年1月から稼働させるべく
インターフェース作業を必死で行っています。

それは、当社システムの一部を新システムで置換するからです。
一体型システムの一部の機能を置き換えるって
非常にリスキーな方針です。

しかも・・・・
性能的には新システムの方が・・・低いんです
あぁぁぁ

どうして、こうなってしまうのか？
親会社はなぜ、新システム構築の際に新アーキテクチャを模索しないのか
新システムでデータの一元化をしないのか？

それは・・・今までそんな大規模なプロジェクトマネジメントを
したことが無い人が、親会社のシステム部門の責任者だから

プロジェクトマネジメントを外部にも委託しているけど
特殊な業態の我々の業務の細かいところまで理解できていない事

私の上司が単一システムで全ての機能を包含している当社のシステムについて
やっぱり理解できていなかったこと
（金曜日の会議で露呈した）

トンネルの出口が見えない・・・のではなく
出口が無いんだ

●分業体制

会社組織では分業体制が普通です
　営業担当部門
　経理担当部門
　人事担当部門
　法務担当部門
　　　｜
　　　｜
などなど

大きな会社になればなるほど細分化されます。
そして、それぞれの部門は専門的になっていきます。
小さな会社では、総務部門で経理・人事・法務を一括で業務していることもあるでしょう。

でも、例外があります。
それはシステム部門です。

●システム要員の務め

システム部門の担当要員は
システム管理だけが出来れば良いって言うものでもありません。
システムを構築するのが仕事なので

構築対象の運用を知らなければなりません。
そして、専門分野の方と対等に話し合わなければ
良いシステムなんて出来るはずもありません。

●内製と外注

システムを構築するための方法として２つ
それは、

• 現場から要望を聞いて、外注する
• 現場から要望を聞いて、議論して、内製する

ですね。

内製か外注、どちらがいいか？　これは明らかです。
ただ、内製できるだけの人的資源を確保できていなければ
外注するしかありません。

●負担爆増

今まで内製してきた当社システム
今まで外注してきて複数のシステムの集合体の新システム
この新システムのサブシステムを一個ずつ当社に導入

全部入れ替えでなくて、少しずつ入れ替え
当社のシステムは比較してかなり高機能だけど
その部分ごとに入れ替えて、全ての機能が賄えているわけではない

しかも、それをするために当社システムにかなりの改造が必要
その改造は、プログラミングができる当社システム要員にのしかかる
当社システムの責任者は残業手当も付かない状態でボランティア

来年一月から新システムが稼働
稼働後のトラブルは相当数発生する予想
トラブル対応とシステム改修

私たちは生き残っているだろうか？

破綻への道 ・・・ Wrong Way

●新システム運用検討会議にて

新システムを当社に導入した時に
運用がどのように変更となるか
どのような運用にすれば業務が回るか

様々な課題が噴出し、それを一つ一つ確認しながら
対応策を検討していっています。

●どんどん手間が増えることが

ただ、今、単一システムで運用出来ていて
そのシステムでは情報連携がほぼ完ぺきなのに
その単一システムの個別機能を切り出して新システムに置換

そのために、情報連携がスムーズにいかず
そのスムーズにいかないところを人手でカバー
いままで、しなくて良かったことが新システム導入で必須作業に

●手間を増やさないように

あまりにもひどいのは、
当社システムに追加アプリを作成するとか

新システムって何のために作られたのか？
手間が減って、正確性が増して、スピードが速くなる
それが最低限の目的じゃないの？

●新システムで効率化

効率化？　手間がどんどん増やしていてどの口が言うてんねん？
正確化？　人の手間が増えて正確性をどうやって維持すんねん？
スピード？　新幹線がナメクジになる前の記事：破綻への道のに？

●あまりにも

昨日の記事破綻への道では
表現がまずく、その内容について意味がお分かりいただけなかっただろうと
反省していますm(__)m

昨日の会議で、我が上司が
当社の運用についてよく知らないで
独断と偏見で非常に重要なインターフェース情報を
不要
と断定したことで、仕様が固まりました。

もう、あまりにも当社システムについて関心が無いだけでなく
運用について全く知らないと言っていいほどで
それでいて、新システムを当社に導入して、効率を上げようと

●なので

私の脳が破綻し、ブログ記事が
新幹線と快速電車という、比喩だけになってしまいました。
申し訳ありません。

●その意味は

その意味は単純で
現行システムは情報を一元管理しています。
なので、Ａ部門からＥ部門への情報伝達は一瞬です。

でも、新システムではと言うと
それぞれの単独システムがネットワークで接続された形態です

ですから、Ａ部門サーバーからＥ部門サーバーへの情報伝達は
バケツリレーで行われます。
そして、各々のバケツリレーでは最長3分待たされます。

すると、
Ａ部門サーバー　
　⇒　Ｂ部門サーバー
　　⇒　Ｃ部門サーバー
　　　⇒　Ｄ部門サーバー
　　　　⇒　Ｅ部門サーバー
と、平均待ち時間が１．５分だとすると、１．５分　　⇒４つ分　≒
６分
となります。

それまで、一瞬だったのが、６分かかります。
最悪の場合、１２分になりますね。
実際には、１時間待たされても届いていないとか発生しています。

なので、
当社システム：新幹線で新大阪駅から駅まで２時間１０分　（乗り換えなし）
新システム：快速電車で、新大阪駅から東京駅まで９時間１３分　（乗り換え５回）

いや、これでもまだ早すぎるので
新システム（改）：普通電車で、新大阪駅から東京駅まで１１時間３９分　（乗り換え７回）

まだ、早すぎるなぁ・・・
現行システムなら、Ａ部門で登録した情報にＥ部門がアクセスできるのは、１０ｍｓぐらい・・かな？
そして、新システムが６分　＝　１８０秒　＝　１８０，０００ｍｓ

ってことは、１８，０００倍もかかるって事で
２時間１０分の１８，０００倍は・・・
計算できないので、ちょっとExcelで・・・お待ちを

３９，０００時間でしたー！
これって、約４年半です。
新幹線とナメクジぐらいですかー？

当社システムの新幹線が時速３００ km/h なら、
新システムの移動速度は、秒速 4.6 mm/s です。　ちなみに、0.01666 km/h です。

さて、新大阪から東京まで行くために
新幹線を選びますか？ナメクジの背中に乗っていきますか？

これからは、快速で
東京まで行こう！

そんな感じで新システムに切り替えです！

デグレばかりで吐きそう

今までは新幹線で行けたのに・・・
新大阪で乗って、東京に着いたら降りればよかったのに

快速で
　乗り継いで
　　乗り継いで
　　　乗り継いで

新システムでも東京に行けます。
ただ、とても大変なだけで・・・

もしかしたら、乗り継ぎで失敗して
気が付いたら新潟だったりして

●新システムではカナだけ

現在、構築中のグループ統合システム
当グループ内では、新システムと言われています
蓋を開けてみると・・・

お客様の名前としては、カナしか使用できない・・・

えっ？

●現在、顧客名がカナしか扱えないシステムって

なんだかすごい問題が浮上してきましたねー
カナしか使えないなんて・・・
ここは、日本ですよー

いつの時代のシステムなんですかー？

●探すの大変

日本で作られたシステムで
カナしか使えないのって
探しだすのはほぼ不可能ではないかと・・・

それがここにある！

●バックトゥザフューチャー

新システムの仕様は
現行システムの仕様をそのまま引き継いでいます。

親会社のシステムがお客様の名前にカナしか使えないシステム
なので、新システムもそのままカナしか使えない

もう、開いた口が塞がらないですよねー！
なんで、新しくシステムを作るときに
漢字も使えるようにしないでしょうかねー？

●良いものは良い

世の中にはいろいろな道具があります
そして、どの道具が良いか悪いか
それは使ってみないと分かりません

●分からない人には分からない

でも、使ってみても分からない人はいます
そのような人は、その道具を何のために使うのか
その目的自体が分かっていないんです

例えば
あなたは今、新大阪駅に居ます。
急いで東京駅に行かなければなりません。

どうします？

多くの人は迷わず新幹線と答えるでしょうね。
何故？

それは急いで行かなくてはならないからです。
目的は早く東京駅に到着することです。

大阪から東京なら飛行機がって言う人も若干いるかも知れません。
しかし、新大阪駅から伊丹空港、羽田空港から東京駅への移動時間
空港でのチェックインなどの時間を考えるとどうみても飛行機の分がわるいですよね

●プロなら分かってほしい

例えば、包丁はどうでしょう。
プロの職人さんと、家庭の主婦・主夫では、包丁の選び方がまず違いますよね。

特にプロの職人さんは、単に切ると言う目的だけで選ぶのではなく
何をどのように切るか・・・って事で包丁を選びます。

話を本題に戻して
私はシステムエンジニアなので、
システムを構築するプロです

最も必要な道具はコンピューターです
なので、どのようなコンピューターが最適なのか
キチンと目的を持ったうえで選ぶと


となります。

目的は・・・

• 安定に稼働すること
• 再起動が必要無いこと
• 処理速度が速いこと
• コンピュータ操作しやすいOSであること


• プログラミングしやすいこと
• プログラミングの教育がしやすいこと
• プログラミング言語が覚えやすいこと
• ライセンス形態が管理しやすいこと
• 初期費用がやすいこと


• ランニングコストが安いこと

です。

●でも・・・

親会社のシステムの方たちは
プログラミングが出来ないから
そもそもこのような目的が分からないんです。

システムを社内で構築できたら、
こんなにDXがやりやすいことはないんですけどね。

DXが出来ない企業は衰退していくって言われてます
当グループは今まさにDXできない企業群になってしまいました。
遅かれ早かれ・・・・

●富士ゼロックス

昨日、当社のプリンティングソリューションを
2005年から支えてくださっている富士フィルムの営業さんが
訪ねてきてくださいました。

富士フィルム・・・契約当初は富士ゼロックス京都さんでした。

当然、ビジネスの話ですがね。

●いろいろな話

いろいろ、話したいことがありましたが
１時間と言う限り有る時間の中
できるだけ情報交換をしようと思い、矢継ぎ早に話しました。

●共感

その中で、我が上司から
当社（特に私）は『顧客サービスをやり過ぎている』と
言われたことについて、つい愚痴ってしまいました。

顧客にサービスをして何が悪いんだ？から
どこまでがやり過ぎじゃないんだろう？とか
その富士フィルムの営業さんに話しました。

すると、その営業さんが熱く語り始めました

顧客へのサービスにやり過ぎることは無い！　って
なんだか、二人で共感しあって、最終的な結論が出ました。

●やはりおかしい

そうです、我が上司は考え方がおかしいのです。
顧客サービスやり過ぎって私の事を評価するのは
判断基準が違い過ぎるんでしょう。

私の方では、顧客サービスの為にシステムプログラムを自分で作ります。
もちろん、外注なんてしません。なので、費用は私の人件費のみ
それで、営業さんは喜ぶし、顧客も喜びます。

そのようなサービスで、長年取引が続いていた顧客もあります。

過去形なのは、昨年の入札で、親会社の営業部長が
顧客質問：『今後も当方とパートナーとして協力してシステム開発をしてもらえますか？』
に対して、『いえ、本部に戻って確認します。』って答えたそうです。

すると・・・・契約が解消されました。
トップユーザーでした。

これが、顧客サービスやり過ぎっていうシステム責任者が居る会社の
営業さんの対応です。

●顧客サービスやり過ぎの基準

顧客サービスは、顧客にサービスを提供し、その対価を得るためのもの。
もしくは、提供には低コストだが、顧客には相当のメリットがあり、かつ顧客の信頼を得られるもの。
この顧客のメリットとは、価値のある情報であったり、商品への付加価値だったりします。

もちろん、それらのサービスを提供するために収支が赤字になるようなものはやり過ぎでしょう。

しかし、当社のサービスは情報提供がほとんどです。
情報を生み出すためのシステム開発は自社で行ってきました。
なので、かなり低コストで、しかも一度開発すれば

その後のコストはほぼ０です。

親会社のシステム部門は自分で開発できないので、
顧客にサービスを提供しようとすると開発を外注しなければならず
その外注費用が回収できそうもないから、サービスしないと言う判断になるわけです。

その判断は正しいんでしょうが、それを当社、
自社開発出来る拠点に適用するのは完全な誤り

親会社のシステム責任者は
親会社たるプライドからか、
当社のシステム要員を退職に追い込みました。

600人程度の従業員で、開発出来るシステム要員が
最盛期では 12人
それが今では 5人

当然、ノウハウも技術も流出してしまいました。
あ〜あ！　やってらんね〜！