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

今日、午前にもグループ統合システム構築に関連する会議がありました。

グループ統合システムの意義ってありますか？
これについては、大方の見方では次のような意義があると言うことに異論はないでしょう。

同じ業種の会社が買収や合併によって一つのグループ会社となり、
それぞれで異なったやり方を統一して、
グループ各社の様々なノウハウを集め、
良いとこ取りをして、最良の運用を決めて、
どこでも同じような運用にすることで、人材の流動的な運用を行い、
グループ企業全体の効率を上げ、利益を生み出す・・・ことでしょう。

では、今構築しているグループ統合システムって何でしょうか？

グループ統合システムとは・・・
グループの統合システム
グループ統合のシステム
どっちでしょうね？
意味が全然違いますもんね。

今、構築しているのは多分・・・・
グループの統合システムなんでしょうね。

つまり、グループ全体で効率的に使えるシステムを構築し、それを各社に導入することで、各社の効率を上げる・・・かつ各社の運用を統一する・・・ことにあるのでしょう。

しかし

私の会社では、一風変わったシステムを構築してきていました。
自社で１から１０まで開発してきたので、改善なんてお手のものです。
顧客からの要望なんて、スピード感たっぷりに実現してきました。

ある時、営業マンが、当社に任せていただければご要望のシステムを一週間で構築いたします。とか言って契約を取り付けてきたこともありました。
さすがに、言い過ぎだと思いましたが

なので、かなりいい線いっているんです。
進歩のスピードは５年ひと昔・・・みたいな感じですかね。

なので、
2000年：Ｇｒａｄｅ−Ａ
2005年：Ｇｒａｄｅ−Ｂ
2010年：Ｇｒａｄｅ−Ｃ
2015年：Ｇｒａｄｅ−Ｄ
2020年：Ｇｒａｄｅ−Ｅ
とすると、現在はＧｒａｄｅ−Ｅまで来ているんです。

でも・・・来年はＧｒａｄｅ−ＤかＧｒａｄｅ−Ｃになりそうです。

だって・・・他の会社はＧｒａｄｅ−Ｂ、良くてもＧｒａｄｅ−Ｃなんですから・・・

そして、統合システムの仕様は、ベンダーが親会社のＧｒａｄｅ−ＢかＣの運用を見て、Ｇｒａｄｅ−Ｄ程度の提案を出してきました。
親会社はそれをよしとして、統合システム構築を開始

途中で私の会社にも導入するからと、私に参画をさせて、統合システム仕様を検討してきました。
しかし、ほとんどＧｒａｄｅ−Ｄで土台ができ上っているのに、それを今更Ｅまで引き上げることもできません。

しかも、ベンダーはＧｒａｄｅ−Ｃのシステムで運用している現場［受注部門、カスタマーサービス部門、営業部門など］からも要望を聞いているため、Ｇｒａｄｅ−Ｄの頭になっていない現場はＧｒａｄｅ−Ｃで困っていることだけをベンダーに伝えているって感じです。

大抵は、システム部門が現場からの要望を吸い上げ、検討し、ベンダーに要件定義書を提示するはずなんですが・・・


昨年度のはじめ・・・
ベンダーのリーダー格が私の会社に見学に来ました。
ところが、ショッキングな言葉をマジマジと聞かされました。

【我々が計画したものが、ここで既に実現されている】

この言葉は私の会社に新しい統合システムを導入しても、変化なし・・・
つまりメリットはなく、デメリットだらけってことになります。

こんにちわー！
システムエンジニアの Yoshiochin でーす！

最近はめっきり弱体化して、対応できるボリュームもめっきり減りました・・・

もうね、システム構築ってのは、特に社内システムの構築は、
エンジニアの質によると言って過言ではありません。

なぜなら、社内にシステム部門があれば、現場の人たちは
・言いやすい
・相談しやすい
・頼みやすい
からです。

で、社内システムエンジニア（社内ＳＥ）は、
・相談に乗れる
・提案できる
・対応できる
事が求められます。

しかし、今ではどうでしょうか・・・

明らかに・・・・(;O;)

それは、2019年の事でした。
親会社では、統合システムの構築にあたり、システムエンジニアを必要としていました。
しかし、親会社のシステム部門には［開発ができる］エンジニアがおらず、私の会社のシステム部門からの引き抜きを画策しました。
そして、2018年末、親会社のシステム部長が私の会社まで訪れて、私の会社のシステム部門員全員と面談し、親会社への転勤に応じられるか確認しました。

システム部長にとって残念なことに、全員が応じられないと答えたました。

ところが、2019年4月1日付で、3名に転勤命令が出されました。
その3名のうち、2名は家庭の事情により転勤はできません。
面談の時にもそのように伝えていました。

なのに、転勤命令が出され、その3名は退職となりました。

そして、火種はくすぶり続け、もう3名も、信用できないということで、退職しました。

11名いたシステム要員が 5名になりました。

しかも、その2名は、私が将来の幹部候補として目論んでいた人材です。
大きな痛手、悪夢です。

そして、今、統合システムの構築は進んでいますが、おそらく・・・・

成功するためには、仕様をもう少し現場寄りに考えてあげないとと思いますが・・・

現在、グループ統合システムの構築に携わっています。

ただ、グループの中で私の所属している会社だけが、ポリシーの異なるシステムを使用しており、統合システムといろいろな点で機能的に異なっているところがあります。

そして、私の会社のシステムが他社のシステムより進化しているので、グループ統合システムを私の会社に導入したときに、現行システムを使用し続ける必要があります。
そのため、新しい統合システムと現行のシステム間で情報のやり取りを行う仕組みを、私の会社で開発することとなっています。

グループ統合システムでは、インターフェースファイルの仕様として、現在世間でよく使われている xml 形式のファイル仕様としています。

私の会社の基幹コンピューターではその xml を扱うのが難しく（ってか、単に私が知らないだけかもしれませんが）インターフェースプログラムを開発するのにかなり時間がかかりそうだと感じました。

そこで、今年度初めに、Delphi/400というツールを導入しました。
このツールは、xmlの読み書きや、当社の基幹コンピューターである IBM AS/400 のデータベースを直接アクセスできる優れものなんです。
このツールを導入すれば、AS/400オリジナルのプログラミング言語に比べて数倍の速さで開発できることになります。

さて、このツール、やはり、基幹システム系の開発ツールだけあって数十万円のオーダーではありません。
必要なライセンスを購入しようとすると300万円以上になります。

でも、このツールなしで開発しようとすると、到底期限までに開発し終えることが出来そうもないので、このツールを導入して、開発期間を短縮しようと考えました。

そして、購入のために稟議起案を行いました。

2か月ぐらいでしたか？　親会社のプログラミングをほとんどしたことがない上司との問答でなぜ必要なのかとかいろいろとやり取りしました。

最終的に導入に至ったんですが、それだけで２か月を無駄にしています。

そして、先日進捗会議があり、xml ファイルを使用した情報授受のプログラミングについて進捗度合いを確認されました。

すると、現在、これこれかくかくしかじかの状況です。って報告したところ、とんでもないことを上司から言われました。

開発ツールを導入したんだから、もう出来ているんだろ？

えっ？
しばらく頭の中が真っ白になり、
上司が何を言っているのか？
その言葉が何を意味しているのか？
全然わかりませんでした。

まるで、頭を鈍器で殴られたかのような衝撃でした。

いわば、Microsoft Office を導入したら、研究論文が出来てるんだろ？って言われているようなもんです。

もう、絶句
信じられない上司の言葉に

だーめだこりゃ状態になってしまいました。

昨日の会議で・・・それはそれは酷かった


現在、グループ企業間で運用を統一するための、統合システムを構築中なんです。
もう、3年目かな？

すでに製造工程に入っています。
システムの製造工程と言うと、家の建築で言えば、
基礎作りから骨組みづくりが始まって、どんどんと壁が出来たり、窓が出来たりしていく段階です。

そんな中、進捗報告会で、
システム開発を請け負っているベンダーさんがある資料を提示しました。

それは・・・

グループから出された要望事項をまとめて、ベンダーさんが要望の一つ一つを必要か不要か判断したものでした。
それを見て、私たちのグループのシステム要員の一人が

なぜ、それが不要と判断されているのですか？
なぜ、それが必要と判断されているのですか？

と質問を投げかけました。

まぁ、百歩譲って、このシステム要員はベンダーさんが勝手に決めたと大きな勘違いをして、質問しているんだろうと・・・

実は、ベンダーさんはシステム部門の責任者と調整したうえで、提示しているんですが・・・

その後も白熱し、
その必要なものが、すでに開発が始まってて、しかも初期仕様になかったから、追加費用になりますって、勝手に必要と判断し、勝手に開発を始めて、それで費用が掛かりますって、納得できない！

って、周囲が　って感じになりました。

なんと言うか・・・同じグループに所属しているシステムエンジニアとして、
穴があったら入りたい・・・よりか、穴を掘って隠れたい気分になりました。


だって、

家を建てる為には、設計書が必要。
その設計書はグループが作成し、ベンダーに提示

設計書を確認したベンダーはトイレがないことに気づいて、トイレを追加。
その追加したことをシステム責任者に確認し、承認を得た。

そして、会議にて、トイレが必要と判断し、追加し、すでに便器を発注した。

その恥ずかしいシステム要員は、
なんでトイレを勝手に追加して、勝手に発注した、その費用の支払いを求めるのか納得できない

って言っているわけです。

恥ずかしくないですか？

システム開発で、依頼した側が依頼された側に・・・

⇒　私たちわからないから・・・・

システム開発で、依頼された側が依頼した側に、このような感じで要求された機能が必要か不要かを分類しましたと・・・

それに対して

⇒　これが必要だとは思えない。　これが不要だと思えない。　とか
　　この不要なのが、もし必要だったらどう責任取ってくれるの？

って、あまりにも依頼された側に対してひどい

依頼された側は、与えられた要求と仕様から、依頼した側の運用を推測して、打倒的かつ合理的な判断から要不要を判断してきたのに、それに対してこの回答は・・・

それならば自分で要不要を判断すればええやんけー

月曜日・・・火曜日・・・水曜日・・・金曜日・・・
午前は会議でつぶれます。

火曜日・・・金曜日・・・
午後も会議でつぶれます。

会議で、有効な会話がなされるなら・・・それもオッケーでしょう。
しかし、低レベルなぐだぐだ言っている会議で、時間がどんどん過ぎ去ってしまっています。

私はシステムエンジニアとして、意味のない・・・って言ったら言い過ぎかもしれません。
しかし、同じことを何度も何度も蒸し返すような配慮のない方たちの発言を聞いているのは
苦痛
です。

新しいシステムを作ろうとしているのに、
既存のシステムを作り替えるだけ！

ちょうど、木造２階建て４ＬＤＫの家を壊して、見た目まったく同じ鉄骨鉄筋の家を作っているようなもの。
なんの意味があるの？
新しい家を建てるなら、鉄骨鉄筋５階建てで、３階はビジネスフロア、4階はリラックスフロア、５階は天体観測フロア（屋根がガラス張り）ぐらいにしたらいいのに！

なーんか、今朝も頭の中に、ナショナル住宅（現在パナホーム）のＣＭソングがグルグル回りましたー
このｃｍソングご存じですか？

家を作るなら〜♪
家を作るなら〜♪
草の燃える匂いのするカーペットにしたいと思うのであります♪

ってやつです。

何故この歌が頭の中にわいてくるかと言うと・・・

今朝も、システム仕様書が変わる・・・ということが発生したからです。

システム作るなら〜♪
システム作るなら〜♪
最初からきちんとした仕様書で作りたいと思うのであります〜♪
ってことなんです。

仕様書に従って、プログラムコードを書き、コンパイルし、仕様書に従ってテストを行います。
そして、システムは複数のプログラムから構成されるのが普通ですから、プログラム一つ一つをテストしたあと、連携させてキチンと動くかを結合テストをします。
もう、システムは１から１０まで仕様書通りに作り上げます。

家を作るときは、
（１）どんな家を作るか構想を練る
（２）その構想に従って家を作った場合の問題点などを洗い出す。
（３）出された問題点の解決策を導き、構想を具現化する。
（４）具現化された構想に従って、建築設計書を作成する。
（５）建築設計書をチェックする。
（６）チェック後の建築設計書に従って建築する。
（７）建築中の各段階で設計者がチェックする。
（８）家が完成する。
（９）出来上がりを確認する。
（１０）必要な些細な調整をする。
（１１）引き渡し

てな感じですよね。
これに対してシステム構築では

（１）どんなシステムを作るか構想を練る
（２）その構想に従ってシステムを作った場合の問題点などを洗い出す。
（３）出された問題点の解決策を導き、構想を具現化する。
（４）具現化された構想に従って、システム仕様書を作成する。
（５）システム仕様書をチェックする。
（６）チェック後のシステム仕様書に従って開発する。
（７）開発中の各段階で設計者がチェックする。
（８）システムが完成する。
（９）出来上がりを確認する。
（１０）必要な些細な調整をする。
（１１）引き渡し
ってなります。

めっちゃ手を抜いて作りました。
まず、【家】⇒【システム】に変更し
【建築設計書】⇒【システム仕様書】に、また【建築】⇒【開発】に
変更しただけです。

そりゃ、工程が似ているからですよね。

でも、決定的な違いがあります。

改修の可能範囲の差ですね。
同列に論じるのはどうかと思いますが、家ができてから、二階建ては嫌だから三階建てに変更・・・ってのはかなり困難ですよね。
システムでは、結構いろんな変更ができちゃいます。
何故か？それは物理的に構築している部分が少ないからです。
殆どがデジタルの世界だからです。

開発をしたことが無い人・・・からすれば、

例えば、商品コードが最初４桁としていたけれど、２０年後には５桁が必要になるかもしれないので、今から５桁、いや６桁にしておきたいって注文をシステムが出来上がりかけの時に出してくるかもしれません。

開発側からすれば、今更そんなことを言われても・・・・って感じですが、そこが大きなギャップとなります。

そんな、仕様変更が次から次へと出てきているのが、今のグループ統合システムの開発です。

どうして最初から決めておかないの？って思うようなことがポロポロポロポロ出てきて・・・

今日も朝から会議です。
グループ統合システムの

なかなか、すすみませんねー
またまた、こんなイメージが



幸せは歩いてこない
だーから歩いてとかいう歌がありました。
その歌詞の中に
一日一歩三日で散歩
三歩進んで二歩下がる

会議にずっと参加してて、こんな歌が思い出されちゃいますが、
こんな感じとは言いません。

いままでの進歩速度に比べたら
１０歩進んで９．５歩下がる・・・みたいな

まあ、わざと遅らそうとしているわけではないので
牛歩ではないんですが・・・・

どうなるんでしょう？
神のみぞ知る・・・・ってことわざがありますが・・・
成功するのか失敗するのか？
成功するとしたら順風満帆か波乱万丈か？

企業買収では、買収された側が買収したほうのシステムに統合されることがよくあります。
私の会社では、ずっと独自路線を進んできました。

なぜなら・・・10年以上は進んでいたからです。

そして、その差は広がるばかり・・・・
なので、2019年に進歩禁止命令が出されました。

その状態でグループ統合システム構築が開始されました。

しかし、当社のシステムがかなり異なっているにも関わらず、１０年以上進んでいるにも関わらず、親会社のシステム部門はそれを無視して、自分たちのシステムを改良してグループ統合システムとして設計し、そこに当社独自の機能を追加すればいいと考えていました。

しかし、それがそもそも大きな間違いだったのです。

新幹線車両は在来線を走れません。
在来線を走る新幹線車両もありますが、それを実現するために在来線自体も改修する必要がありました。

そりゃそうですよね。
時速130 km/h 程（早くても 160 km/h)で走ることを前提に設計された線路で、時速300 km/h は出せませんものね。
（ちなみに、東海道新幹線区間では営業速度は 275 km/h に抑えられています。　これは開業当時、200 km/h で走行することを想定して線路を建設したので、カーブの半径が 275 km/h 以上で走ることはリスクが高い・・・もしくは快適性を損なうと判断されたためだそうです。　それに対して、山陽新幹線では 300 km/h、長野新幹線では 320 km/h だったと思います。）

しかし、買収されたのは事実・・・買収されてから 20年経って、経営者の代も変わり考え方も変わったので、大きな波に飲み込まれるのは必定かも・・・

なので、グループ統合システムが導入されても、できるだけデグレ度が小さくなるように頑張るのが私の使命と考え、頑張ってきました。

しかし、当社のシステムについて、ベンダーも理解していないのが今日分かりました。

ベンダーだけはと信じていたんですが・・・

まぁ、仕方ないかも・・ベンダーにとっても親会社のシステム部門から来る情報の方が量が多いですからね。
質はともかく・・・

でも、このまま放っておいたら、本業で非常に重要な機能が削除されてしまうため、手間がかなり増え、ミス発生リスクも増大・・・かわいそうな現場の人たち・・・
神経すり減らして、ミスしたら叱られて、査定が悪くなって、ボーナス減らされて・・・

しかし、頑張るのもいい加減疲れてきた・・・

頑張っても頑張っても肩透かしを食わされる。
非常に重要だと思われることを発言しても、それを理解してもらえない人に『そんなことをいっていたずらに会議を送られることはやめてくれ』とか言われる。
多くの件数の処理（１日に数万件）をするため、１件当たり 0.1秒でも遅くなる可能性のあることは避けなければならないのに、それに言及したら・・・

１０年以上進んでいるノウハウは必要ないと言われたような気がして、その後は聞かれなければ答えなくなりました。

そして、知らない間に仕様が変更されたりしていたり、必要だと申請してきた情報が、まだベンダーから提示されていないと言われたのに、プロジェクト管理ツールでたまたま見つけた６月中旬のベンダーと上司のやり取り・・・すでに提供されている・・・

だれを何を信じていいのかわからない・・・
心が折れそうだ

システムづくりは失敗もするさ・・・
でも、考えに考えて起こる失敗は仕方ないよ
人間が作るもんだから・・・想定の範囲外は良くあるよね

でも、考えてんの？ほんまに？って感じで進めて、失敗・・・
これはいただけないよ

システム開発で、何らかの原因で失敗すれば、それがごくごく小さな失敗だったら・・・Ｏｋ
でも、事と次第によってはとんでもなく前に戻ってやり直さなければならないことがあります
この前に戻ってやり直すことを『手戻し』って言います。

私はグループの別会社のＳＥにこの『手戻し』って言葉を教えてもらったようなものです。

なぜか？
それまで、私の会社で私が手掛けてきたシステム開発や改修で手戻しに相当するようなものは起こらなかったからです。

単にラッキー
いやいや、違いますよ！
じっくり考えてきたからです

しかし、今進められているグループ統合システムは、ほころびが出始めてきました。
なぜなら、
トイレと玄関と浴室の位置を考えないで、家を建てて、壁を作ってしまったからです。
ふと、気づくと、玄関はどこ
こんなに建築してしまって今更どこに取り付けるんだよ？

システムを作るときは、システム全体を見て、今回作ろうとするのが例えばトイレなら、
・各部屋から均等に行ける場所にする。
・各階に一個はトイレを作る。
・水回りを固められるところにトイレを作る。
・バリアフリーにする。
・換気能力は必要量の１．５倍にする。
・便器は清掃しやすいものにする。
など考えてから、そのあとに
・和式にするか洋式にするか？
・洋式ならウォシュレットにするかしないか？
・トイレットペーパーホルダーの位置はどこにするか？
とかを考えるでしょう。

ところが、先に便器を決めてしまって、出来上がったトイレ部屋に入れようとしたら、水道蛇口の位置がめちゃくちゃ遠い、便座が大きすぎて、壁との距離が近く、座った時にかなり圧迫感がある。
とか
ぶっ壊して一から作り直した方が早いんじゃない？

なんとなく、イメージとしてこんな感じになりつつあります。
不安でいっぱいです。

もうすぐ、すごろくの『振り出しへ戻る』ますに止まりそうな気がします。

いままでにも、数億単位の損失を出すような失敗を何度かしてきたのに・・・

タイトル画の言葉が彼らには無いのかも