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

新請求システムについて
仕様を検討する会議が開かれました
ただ、先週木曜日から何も進んでいない

それは・・・

●開発ベンダーも分からない

各マスタのフラグ等の意味が良く分からない
当グループの渡した仕様書が多分ファイルレイアウトのみ

それだけでは開発ベンダー側も分かるわけがない
いつもの【こんな感じで作って】パターン

開発ベンダーはなりふり構わず
マスタ設定のマニュアルがあれば提供してもらいたい

●開発委託者（当グループ）側も分からない

でも、マニュアルを渡したとしても
マニュアルに書いていないことはこちらも分からないと

そして、分からないことは分からない
これって、喧嘩？

●マスタの設定の仕方も良く分からない

どんな運用にしているのか、現場の人に聞きたい・・・とベンダー
しかし、それに対し、マスタの設定の仕方も、コピーコピーだから
誰も完全には知らない

●四面楚歌

新請求システムをどのような仕様にするか
現行がどうかを分かっている者がいないから
どうにもならない

だーーーれも分からない
分からないなら考えて、こうするんだって何かしらの意見が出て来るやろ
それもしないで、分からないって

開発ベンダーさん、イライラしてるとは思いますが
何せ、開発したことが無い人たちばかりだから
ベンダーさんがどのような情報を欲しているか分からんのです・・・

ゆるしてつかぁさい

●今のところ？

またまた、システム要員らしからぬ回答
開発ベンダーの問に対して
今のところ〜〜〜〜〜と

●想定していない？

そして、それ以外の事は想定していないとも
またまた、逃げの回答をしている
開発ベンダーが聴きたいのはそんな事ではないのに

今がどうであるか伝えても仕方がないじゃない？
今、行っているのは新しいシステムの開発
それは単に現行動いているシステムの焼き直しではない

●では未来では？

つまり、現行運用は最低限出来て当たり前
そうでなければ、わざわざ手間暇かけて新システムを作る意味なんて無い
でも、我がグループの親会社の面々は

受注入力部分だけ新しくなったのだから
それ以外は今出来ている事が出来ればいい

●答えているようで答えていない

そんなことから、今のところはこうであり、それ以外の事は想定していない
って答えになるんですよね
これって、責任回避の最たるもんですよね

新システムを使うのは誰？
何の為に新システムを開発しているの？
目的がぶれすぎてへん？

●正しいかどうか？

このやり方が正しいかどうか
それは分からないが、現行ではそうである

もう、アカンわ・・・・
このプロジェクトは金食い虫の骨折り損のくたびれ儲けプロジェクトや
くたびれ儲けだけならいいけど

顧客ロストは必須やなー
もしかしたら、年間売上６億の顧客をロストする可能性あり
誰のクビが飛ぶんやろ？

責任をだれに擦り付けるんやろ？
あーー怖い怖い！
失敗しても、きっとリーダーは生き残るんやろうなぁ

たくさんあれば良いってもんじゃないよ

●単一のシステムで多くの機能

システムは、統一された単一のシステムで
いろいろな事が出来た方がいい

なぜなら

単一のシステムは単一のデータベース
データの有効利用が可能

統合されたデータペースを利用できる多くのサブシステム
全てのサブシステムが必要なすべてのデータにアクセス

●ちょっぴりの機能の小さなシステムが一杯

しかし、今開発しているグループ統合システムは
統合とは名ばかり

今まで開発してもらった小さなシステムを
それぞれグレードアップ（？）しているだけ

しかも、そのグレードアップは
受注処理機能の向上部分に適用するためだけ
それ以外には機能アップは殆どなし

だって、現場に意見を聞かないで開発しているから

●システムは少ない方がいい

システムの数は少ない方がいい
もちろん、少なくても、機能は豊富でなければ

そんな理想的な当社のシステム
グループ他社とは毛色が違うシステム
それが親会社のシステム責任者により蹂躙されようと

●複雑すぎて・・・ロスが多すぎ

良いものは良い
そんな道理が通用しないグループ企業間政治の世界

子会社のシステムを全社展開するなんて
親会社のシステムにとったらプライド丸つぶれ

当社システムの良い所は単一システムであること
その開発ポリシーは失われようとしている
開発出来ない親会社のシステム部門によって

まぁ、多数のシステムを協調させて運用するメリットは
分かりません・・・・
デメリットは、新機能追加の為の労力がべらぼうに多い

つまり、顧客や現場から新たな要求が出されても
断る（断らざるを得ない）状況が多いと言う事
理由は、コストがかかり過ぎるから

なので、（複数のシステムで構成された）複雑なシステムは
メンテナンスしにくく、拡張しにくい
硬直化したシステムとなりやすい

現在、そんなシステムが出来つつある
営業さん・・・顧客対応大変だね
現場の方・・・問題解決大変だね
システム・・・断っておしまい（楽だね）

●声がほとんど聞こえない

オンライン会議が始まった
主催者のグループシステム部門責任者が遅れて入る
そして、声が聞こえない
かなり小さく（蚊の鳴くような声）聴きとれない

●立ち上げ直すとか

そこで、パソコンを立ち上げ直すと言う
暫くして、再び蚊が鳴くような声でした
そして、もう一度立ち上げ直すって

●結果は同じ

まぁ、立ち上げ直しても、原因が解消されていない限り、結果は同じでしょ
結局、立ち上げ直す時間がロスになっただけ
参加人数が１５人程度だから、ロス時間１０分で計算すると

２時間半分の無駄

しかも、開発ベンダーが参加していて、その人件費たるや１時間で１万円〜２万円
この辺の費用については目に見えないものだから湯水のように

たった１０分だけど、５万円ぐらいの損失を出している事
それに気づかない人たちだから、（開発ベンダーは分かってるはず）
作っているシステムがどんなものになるかは推して知るべし

●原因は何？

最終的に、声がはっきり聞こえるようになったけど
以前にも同じことがあって、同じようにタイムロス

その時の解決方法が学習できていないみたい

もう馬さんと鹿さんが、多数寄ってきて集まったみたいな感じ

また、この絵を使ってしまった＿|￣|○

●現行システムはこうだから

今日もまたまた訳の分からない会議だった
新しい請求システムを開発するためにその仕様を検討する会議

開発ベンダーがー提示してきたものを見ながらあーだこーだ議論する・・・はず
まず、開発ベンダーが現行システムはこんなだからと
画面イメージを提示

その中で、各オーダー中必ず１個しか存在しないものの商品明細
その修正画面に、必ず１が入力されている『数量』欄が示されています
で、開発ベンダーが『この数量って必要でしょうか？』

●現行がこうだから？

提案してきた開発ベンダーが『これは必要でしょうか？』ってなんだか奇妙ですが
開発ベンダー曰く『現行システムに存在しているから』だそうです

でも、開発ベンダーは当グループシステム部門より仕様書を受け取り
その仕様書を元に形にしただけ
その欄がどのように使われているのか現場には聞いていないんですね

●新システムはこうなんだ

本来なら、グループシステム側が
新しい請求システムはこうしたいんだ！って要求を開発ベンダーに提示して
開発ベンダーはそれにこたえるべく、現行システムを調査、差異を分析して

新請求システムの提案を持ってくるべきでしょう。

でも、当グループは自分とこで現行システムがどうなっているか分かってないから
まずは、開発ベンダーに調べさせて、それを理解して
そのうえで新しいのを作ろうと・・・そういうどぐされアプローチ

●で、新システムは何が新？

そんな事をするから・・・
本日、提示されたこの数量欄をどうするか？必要かどうか聞かれた時に
現場に確認しなければって大慌て(笑)

人にものを頼むとき
特に大規模なシステムを頼むときは
緻密な仕様書（設計書）を渡さないと・・・

適当な仕様書を（いや仕様書とは呼べないでしょうね）もらった開発ベンダーは
それを頼りに、想像を張り巡らせて新システム仕様を作り上げ
当グループ側に提示

その努力たるや涙ぐましいものがあると思いますが
でも、出来上がったものは、その機能の何がどう新しくなったの？

そんな感じです
骨折り損のくたびれ儲け
そして、そんなシステムを作ろうとする小田原評定

ほんと、疲れる

●現新比較

現新比較と言う言葉をご存じでしょうか？
私はこの新システム開発プロジェクトにかかわって
初めて耳にする言葉が多く、この言葉もその一つです

これは、現在のシステムで作成している製品と（現）
新システムで作成した製品が（新）
同じであることを確認（比較）することです

お客様に提供する商品が、新システムになって変わってしまうと困るから・・・です

●今週、やっと

今週の半ば、やっとうずたかく積まれたタスクリスト
そのトップにやっと、この現新比較を行うタスクがやってきて
それに取り掛かる事が出来ました

●作ったら３分

最初、簡単に出来るかなって思ったら、
まず新システムを開発した開発ベンダーの理解度が
まぁ、説明していない当グループ側にもあろうかと思うんですが
ある程度の現新比較はベンダー側で行っているはず・・・・
なのにそれをしているとは思えないような差異が多数

まぁ、そんな差異を全部抜き出して、同じようなものが作れるようにしてね
って優しく厳しく伝えました(笑)

さて、その現新比較用に商品を作る時間・・・
５回作成させて、５回とも３分かかりました。

●比較用に造ったら２１秒

で、現新比較用にもう片方で作ると、２１秒で出来ました

この結果だけで、おぉースゴーイって思われた皆さん
私の罠にはまりましたね(笑)

新システムの作成時間が３分
当社現行システムの作成時間が２１秒
なんです

全く同じものを作成するために必要な時間が
従来までは２１秒かかっていたのが、
新システムでは３分、１８０秒かかるわけです

これはどういう事かと言うと、
親会社は、あなたが今まで頼みにしていた部下Ａをクビにして、部下Ｂを雇った
部下Ａは毎朝のルーチンチェックを２１秒で完了していたけど、
部下Ｂは３分経たないと完了しない

これが未来永劫ずっと続くと言う事です。

しかも、部下Ａレベル１万人をクビにして、部下Ｂレベルを１万人雇用しました
その影響はどうでしょうか？

●それはないやろ

新システムを構成するサブシステムの一つ
そのサブシステムの仕様を検討する会議の席上
開発ベンダーは仕様の一つ一つを決めて行かなければならないため質問します

開発ベンダー：工程Ａについては、処理αにしますか？処理βにしますか？
当グループ担当者：処理αで良いと思います。

●恥ずかしい

いやいや、ちょっと待てよー
思いますって何だよー？

システムの人間として、仕様をどうするか聞かれているんだから
　処理αにします
　処理βにします
　処理αで基本いいけど、α−１のところで、α’を追加してください
とか、確定的な回答をしてほしい

そんな事ができないシステム要員のいるグループに所属していることが
恥ずかしい

●どう思います

みなさんはどう思います？

例えば、１＋１はいくらですかって聞かれたら
迷わず　２ですって答えますよね
２だと思いますって答える人は居ませんよね

この２ですって答え方と、２だと思いますって答え方には大きな隔たりがあります。

でも、円周率の小数点第６位の数字は何ですかって聞かれたら
２ですって明確に答える人も居られるでしょうが
２だと思いますってうろ覚えの人は言うでしょぅ
まぁ、分かりませんって答える方も多いかも(笑)

このように、自信が無い時によく使うのが思いますです。

●しゃんとせーよー

ほんま、口には出して言いませんでしたが
しゃんとせーよーって心の中で叫んでいました
恥ずかしいったらありゃしない

まぁ、難しい問題だとは私も思いますが、それならば
処理αです。ただし、間違えている可能性もありますので、確認してから、本日１８時までにお答えします。
ぐらい言えたら、カッコいいんです。

知らないことを知らないと言えるところがカッコいいんですよー
知っていたらもっとカッコいいんですが(笑)
確実に知らないのに確実に知っているかのように言うのはダサいです

●ユーザーマスタ検索

システムに関する問題点一覧表
そこに入力された方の名前はあるけれど、部署が入力されていない
なので、その問題がどこの部署で発生したかを調べる必要がありました

普通なら、ユーザーマスターをその方の名前で検索したら一発ですよね
でも、

●全部表示して目で検索

ユーザーマスターに検索機能が無かったみたいで
ユーザーマスターを全件表示して、目で探してはりました
えっ？　何してるんですか？　あなたは・・・

●システムの方ですよね

なんで、そんなアホな事をされてるんですか？
検索機能が無かったら・・・後日作ってもらうとして
ＣＳＶでダウロードする機能はついているのだから

ＣＳＶでダウンロードして、Ｅｘｃｅｌに読み込んで
検索したら一発ですよ

なんで、そんな事も思いつかないんですか？
みんな、あなたが一画面一画面開いて見つけるのをずっと待ってる

●そりゃ、遅いわけだ

それが許される環境だから
処理が遅いシステムができるわけですよ

一時間以内で完了したらいいってことで
５０分で完了したらいい
そんな中途半端な事をしているから

あとから（あとから言う方も言う方ですが）
実際には３７倍も速度アップしなきゃならなくなるんですよ

これは、完全にデータベースの構造から変更しなければ
対応できないでしょうね
いくら、並行稼働させたとしても限度があります

デッドロックが発生したらどう対応するんでしょうか？
データベースの同時更新をすると排他制御問題が浮上します
これはなかなかに解決しにくい問題です

３７倍の高速化・・・どうやって実現するのか・・・

●２個のチェック欄

依頼書に２個のチェック欄があります。
☐あり　と　☐なし
受注側としてはどちらかにチェックか欲しいんです

で、ここで小田原評定が勃発

無しならば０　有ならば１　両方ならば２
では、どちらもチェックされていなければどうしましょうって

●どちらか１個にチェックが必要

この依頼書の記入方法としては、☐あり　か　☐なし　のどちらかにチェックが必要なんです
つまり、両方にチェックされている場合と、どちらにもチェックされていない場合はエラーなんです
ただ、この二つのエラー状態をどのように渡そうかって事であーだこーだ

●ステートは４種類、インターフェースは３種類

２つのチェックボックスで、それぞれがオン／オフの２種類
つまり、２つのチェックボックス全体では４種類のステートを持ちます
これを０，１，２でどのように表そうかと議論が白熱

●仕様検討でしょ

あほらしい

で、現場の責任者が、
両方ともチェックが無かった場合は、顧客に確認しなければならないので
その情報も欲しい

ならば、両方ともチェックが無かったら　空白をインターフェースとすればいいのでは？と
この方、システムの責任者（我が上司）より論理的で賢いですね

●高速化

新システムのサブシステムの内の一つ
このサブシステムの処理速度が遅すぎて問題になっています
このサブシステムが完了しないと、一日の仕事が終わった事にはなりません

●４４．４５倍に

６月当社に行われた性能検証によると
開発ベンダーの勘違いもあり（当グループが正確に伝えてなかったことも原因ですが）
必要な速度の４４．４５分の１という速度でした

と、計算していましたが・・・実は計算間違いしていました
今、計算し直してみると・・・
３７．３３倍でした

でも、ホッとできませんよね

●比較すると

これって、皆さんが良くしっている乗り物で比較すると
　処理速度が遅すぎサブシステム　：　自転車
　必要な処理速度のサブシステム　：　ジェット機
ぐらいの差があります。

これが実現可能ならば、一つの疑問が湧いてきます
開発ベンダーは何故このように処理速度が遅いサブシステムを構築したのか？

●可能かな？

まさか、そんなことは無いでしょう。
すると、現在の自転車の速度が精いっぱい

これをジェット機の速度まで引き上げるなんて
果たして可能なんでしょうか？

可能だとしたら・・・開発ベンダーは・・・
不可能だとしたら・・プロジェクト自体は失敗

どっちにしても不愉快な結果になります

あーーーーあほらしい