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

●００１か０１１か

００１か０１１かどっちにしようと
一体いつまで話すんだろう

数字とかコードに意味を持たせようとするから
親会社のメイン拠点を００１にしたがるだけ
あほらしい・・・・

●その前に

もともと、００１を使っているのに
新しい拠点を００１にして、もとの００１を０１１にしたら

マスターデータベースとかを振替作業をしなければならない
まぁ、私がするわけではないからお好きにどうぞって感じだけど

いやいや、新しい拠点に新しいコードを振ったらいいだけ
それを何を・・・？

●頭がくらくらしてきた

こんなくだらない会議に参加して内容を聞いているだけで
頭がくらくらしてくる

まぁ、他の議題もあったけれど、００１か０１１かで３０分ぐらい費やしたかなぁ
会議に参加している人間が約３０人

まぁ、プロジェクト会議に出ている人たちだから人件費も相当なもの
安く見積もって一人当たり１時間２０００円としよう
すると、２０００円／時間　　０．５時間　　３０人　＝　３０，０００円

３０，０００円が無駄になったということだ

●昼休みだ

やっと、終わった！
昼休みだ！
気分を変えて、歌でも歌いに行ってこよう(笑)

●グループ統合システム

現在、当グループではグループ企業の運用を統合すべく
グループ統合システムなるものを開発中である
その新システムの名前は・・・恥ずかしくて言えない

新システムの一つの名前は、恥ずかしいけど
前回面白くて更改したので、もう一度公開
それは、Curious Online 以前の記事：キューリアス・オンライン　ぷぷぷっ！

●普通だけど特殊

当然、当社もこの新システムの恩恵に与かる・・・わけだけど
それには、当社が行っている全ての機能が代替されなければならない

でも、当社にとっては通常の機能なんだけど、新システムについては特殊

●新システムで対応

これらの特殊機能を新システムで対応するには
これらの特殊機能を開発ベンダーに知らせる必要がある
親会社のシステムの人間は分からない

必然的に・・・

●ベースから作らんと・・・無理

でも、新システムの構造を知ると
特殊機能を実装しようとしたら
データベースの基本から作らないと・・・

えっ？なぜ私が言わなかったかって？
それは、言っても聞いてくれなかったから
しかも、私が言ったことは議事録に書かれていない
もしくは、議事録を取らない会議で発言(笑)

●企業は何のために？

当グループは誰の為に活動しているのか？
社長の為？　役員の為？　従業員の為？
全てイエスですよね。

企業は利益を追求し、得た利益を社長以下、パートさんなどに至るまで分配する
しかし、その利益を得るために必要なのは？

お客様ですよね。
さて、最近、当グループの矛先があちらの方を向いている

当社はもともと、お客様が喜ぶように、お客様の利益が上がるように
そうして、その対価として当社に利益が得られるようにしてきました
それは、必要最低限のサービスでは無くて、最高のサービスです

●それを実行するには？

他社と同じことをしていては
単なるぼんくらです

他社より抜きんでた事をしないと、衰退がはじまります
お客様に最高のサービスを提供するにはどうすればいいか
それを考えずにシステムを作ると…

●どっちがいい？

こんな話があります。
あるお店で売り上げがなかなか上がらず困っていました
それは牛丼を提供する食堂です。

そこへ、あるコンサルタントが介入しました。
すると、そのお店の売り上げが倍増しました。

でも、特別な事をしているわけではありません。
お客様が喜ぶことをしたまでです

それは・・・・・
普通サイズの牛丼だけだったのに対し
コンサルタントは、ミニサイズをメニューに追加しただけ

それだけで何故？

ミニサイズを提供したために、普通サイズを敬遠していた
比較的小食の女性客が格段に増えました。

普通サイズでは女性客は無理して食べなくてはなりません
そこまでして牛丼を食べたいとは思わない女性
でも、ミニサイズなら丁度いい

要は、お客様が何を欲しておらせ
どうすれば、その要求を満たせるか？
それを考えて、実現したらいいだけです。

●これからどうなる？

当社はそれを実行してきました。
当社のサービスは情報を提供することですから
より良い品質の情報を、お客様が欲する情報を作り出せばいいのです。

そのためにはシステム開発が必要となります。
でも、当社では従来は自社で開発していたので、経費は殆どかかりません。
なので、顧客サービスやりたい放題でした

すると、当然、緊密な顧客連携が出来ます

でも、グループ統合システムでは・・・・
その統合システム開発リーダーの我が上司は
当社システムに対して、顧客サービスやり過ぎと言う発言をしました。

つまり、牛丼ショップでミニサイズを提供するのはやり過ぎだと言うのです。
結果はどうなりますか？
言わずもがなでしょ

●私の考えが異常なのか

グループ統合システムの開発が始まって以来
というより途中からだが
そのプロジェクトに参加させられて会議に拉致

しかし、参加させられたとしても言うべき時は言わないと
そう思って発言するのだが
理解してもらえない・・・なぜ？

●顧客サービスやりすぎ

ある時、これはこうしたほうがいいと思う。
現に当社では行っている
これは、このようでなければ現場が困るし手間が増える

そう、いろいろ意見を言うが、
上司から・・・
　顧客サービスやり過ぎ
　従業員を遊ばせるわけにはいかない
とか、常に否定

●静観の立場

私も反骨精神は持っていたつもりだが
やっぱり出る杭は打たれる・・・というよりか
でても刈り取られて無視される感じが続いたので

今は静観の立場

だって、言っても言わなくても結果は同じ
それだったら言って説明して努力してもらえなくて落胆
そんな精神的疲労を受容する義務は全くない

そう思う、今日この頃

●それでうんと言うのか

そして、今日、いろいろな仕様検討を行うときに
周辺の旧システムの制約により
新システムもその制約を引き継ぐがいいかとベンダーから確認

それは、登録量が旧システムによって（例えば１００）だから
新システムで１００まで登録できるようにして良いかと
これに対して、我が上司は肯定する回答

ふーん！　良いんだ！　ほんとに？
何も考えてないのかいな？
もしかしたら、ベンダーとつるんどんのかいな？

システム開発をしてきた私からすると
そう思えて仕方ない

将来旧システムが亡くなったら
１００までという制限もなくなって
新システム本来の制限になる

その時に１００までと言う制限を撤廃するためにどうするのか？
また開発ベンダーに開発依頼をするのか？

私としては、システム変数を用意し、それに設定された数を制限として処理するようにしておけば
制限を１００から例えば３００に変更する際
そのシステム変数を変更するだけで対応できるのに・・・

どうやら我が上司はそれに気付かない・・・
いや、そんなことはないだろう
と、いうのがさっきの推論の根拠

●あり得ん

今朝の朝礼で報告がありました
第一拠点の新サブシステム稼働2日目であり得ん事故が
目の玉が落ちそうになりました・・・

●原因は

原因は調査中だそうです
ふーん！　調査中？
あほかー！　続けば屋台骨を揺るがすような事態になるのに

何を悠長なこと言ってんねん？

●早速

これは事故であり、事件ではない・・・とか声が聞こえてきそうだけど
どんなに気を付けていても起こることを防ぐことは出来ない

そんな声が聞こえてきそう・・・ならば
新システムでそんな事が怒らないように十分テストしろよ
テストできないのなら、その機能を使うときにワンステップずつ確認しろよ

●幸先が

良いとか言葉があります
でも、今の私のところは
お先真っ暗・・・

どう、楽観的に考えてもトンネルの出口が見えません・・・

●新サブシステム稼働

第一拠点で新たなカテゴリーの新サブシステムが稼働しました
満を持してお披露目となったわけですが
あにはからんや、散々な出だしとなったようです

●二度あることは三度ある

その新サブシステムは最終工程で使用するものです
なので、深夜からその工程が開始されます
従来は１時間ぐらいで完了していました

性能検証：シミュレーションでは５０分で完了していました
しかし、お昼過ぎを皮切りに不具合対策が何度も・・・
まぁ、ほんと、二度あることは三度ある・・・どころか

何度あんね〜ん？って感じでした。

●早く終わるはずが

結局、終了したのが朝の七時ごろでしたか・・・
さすが新サブシステム
普通は午前１時ごろには完了している処理が午前７時

対応する方々・・・余分に６時間も残業されてご苦労様です

●下手な考え休むに似たり

ってなことで、『二度あることは三度ある』って諺以外に
『下手な考え、休むに似たり』って諺も思い浮かびました。
もう、悲惨ですね。

本日の夜中までに、修正しておいてほしいですね
で、ないと働き方改革法案に真っ向から立ち向かうことになりそう

●本来なら６分

今日から動く新サブシステム
事前のテスト【性能検証】では５０分かかりました
本当の制限時間は６分でした

大幅な時間超過でした
でも、このテストが行われた拠点は最小拠点で
１時間と制限した拠点の１／１０の大きさ

なので、本当の制限時間は６分なんです

●実際には５０分

満を持して行われた性能検証でした
性能検証は、開発したシステムが要求通りの性能をだすか検証することです

要求を満たさなければ作り直し
要求を満たしたらそれはそれでＯｋ

要求は１時間でした
性能は５０分でした
ベンダー側はＯｋと思いました

でも、そこには大きな誤解が
そりゃ、グループの伝え方がまずいでしょ

どこどこでは何分って伝えなければならないのに
制限時間だけしか言ってなかった

ベンダー側はそりゃ、最初で性能検証する場所で一時間と思うでしょう

●５０分かかるところを６分以下で

そんな事を言っていても始まらないので
計画通り最小拠点でとりあえずは稼働させることに

しかし、本来６分で完了しなければならない処理工程が
５０分
これを６分以下で完了させられるように改良することが出来るのか？

●これって大変だね

昔、大阪から東京まで
　徒歩　　　　　　１６０時間
　ＪＲ在来線　　　　１０時間
　ＪＲ特急　　　　　　８時間
　新幹線　　　　　　　２時間
　リニア　　　　　　　１時間
でした

なので、５０分を６分にするのはおおよそ
在来線をリニアモーターにするぐらいの改革が必要です(笑)

私にはできません。
少なくとも鉄の車輪を使う限りはどんなに頑張っても・・・

●なんでもかんでも

グループ統合システムを
複数のサブシステムを組み合わせ
各拠点の既存のシステムの各部分を置換していく

その方法に問題はないけれど
そのサブシステムを置換する拠点と順序に難があるように感じられる

やってやれないことはないけれど
理想的な順番に置換していくことに比べたら
かなり効率が落ちる

それもそのはず
サブシステムを単純なブロックと考え
各々の開発ベンダーと置換する拠点と時期で

●素人が決定

したかのような
まぁ、素人とは、ＩＴの素人と言う意味で
決定する権力は持っている人たちだ

まぁ、この人たちは、言えば部下はその通りにすると思っているから
言うだけで良いんだけれど

●トータルシステム

そもそも、各サブシステムの複合体としてのグループ統合システム
これはトータルなシステムとして構築されなければならない

それなのに、その設計機序は
一つ目のブロックの仕様を策定し
それを作り始めて、作りながら２つ目のブロックの仕様策定

これの繰り返し
この積み重ねだが
これは・・・・いろいろな落とし穴が発生する

●スプーンは要らない

何度もシステム構築を建物を建てることで比喩してきたが、
今回もそれに倣うとしよう

先ほどの個々にブロックの仕様を決め、開発
それと同時に次のブロックの仕様の策定

これは、ビルディングを建てる時
�@１階部分の仕様（間取り等）を決める
�A１階部分の建築を始める、それと同時に２階部分の仕様を設計
�B２階部分の建築を始める、それと同時に３階部分の仕様を設計

はてさて、どうなるだろう
もちろん、結果は・・・

私は、既にスプーンは必要ではないと考えるようになった

小田原評定再び

●第一拠点でリリース

製品製造最終工程が来週リリースの運びとなった
性能検証結果が報告され、
５０分程度で、その工程が完了したとの事だった

●一時間以内に完了

開発ベンダー側は、一時間以内に完了する必要があると聞いていたので
今回の性能検証で合格したと考える
そこに、さすがの我が上司も食いついた

●誤解

第一拠点のような小さなところで５０分もかかっていたら
その十倍以上もあるグループ本社で１時間以内に完了できない
承認出来ない・・・と

開発ベンダーは、第一拠点で一時間以内だと
我が上司は、グループ本社で一時間以内だと
そこには大きな開きがある

大きな大きな誤解

●来週リリースなのに

どうするのかな？
どうすれば進捗できるかな？

１０分の１のボリュームでは６分以内で仕上げなければ
単純計算しても、グループ本社で一時間以内は無理
５０分かかる処理を６分以内で完了するように今から変更？

来週リリース予定なのに、１１倍以上の高速化？
もし、それが実現出来たら・・・
開発ベンダーに対する信頼は地に落ちるだろう

出来なかった方がまだまし・・・
延期すればいいだけだから

ただ、元々、当グループがシステム開発を委託した時
数年前だけど、その目的を理解していたら
最小の第一拠点で一時間以内に仕上げれば良しと判断するのはいささか

同情しきれないところがある

●請求金額の算出

請求金額・・・これは様々な情報が集まるホストで作成します
顧客ごとにあらゆる製品の請求価格とセット販売価格、割引などから計算します

当社では、大きく分けて１４種類のタイプの請求パターンがあり
各顧客は、どれかのパターンに分類される・・・だけではなく
さらに、オプション請求があります

この複雑な請求体系は
当然顧客と当社との力関係によります
当社は上場していませんので
顧客に株主は居ません
なので株主優待が無いのが救いです(笑)

もしそんなのがあれば、更に複雑怪奇になるでしょう

●経理に関する煩雑な作業

ただ、そのような複雑な請求処理をこなすホストシステムでも
経理処理についてはそれほど明るくありません
それは・・・開発者（私とか）が企業の経理などについて詳しくないからです

なので、良く使われているパッケージソフトを使用しています
ただ

●グループ統合

の為に、グループ全社で同じ会計ソフトを使用したほうがいい
そのような論拠が出されていますが、これには賛成です

しかし、昨日の会議では・・・・
私に対して、このソフトに変更して問題ないかと聞かれました

たとえば、当社で使用しているのがソフトＡ、親会社で使用しているのがソフトＢとします
私への質問は、
当社で会計処理はソフトＡで行っているが、それをソフトＢに変えて問題ないか？

●気持ちは分かる

そんな事を聞きたい気持ちは痛いほど分かります
私も彼の立場なら同じように聞くでしょう

ただ、聞く前にソフトＡとはどんなものでソフトＢはどうか
それらを調べて、違いを認識したうえで
質問するでしょう。

かれは、それをしないで私に聞きました。
多分、出来る／出来ないの返事が欲しいのでしょう。
でも、私には回答できませんでした。　なぜなら

ソフトＢとはどのようなものですか？
ソフトＡは大体知っていますが、ソフトＢは知りません。

なので、ソフトＡで行っていることをソフトＢで行うようにしても大丈夫かと問われても答えられません

そもそもソフトＢはどんなものですか？　と逆質問したら
分かりません・・・だって

だめだこりゃ