ブログのタイトルを入力します。 -13ページ目

あるIT現場3 震えるほど暑い、熱い 偽装請負の査察らしきものが入ったようだ

あるIT現場3 震えるほど暑い、熱い 偽装請負の査察らしきものが入ったようだ

現場は空調がいまいちで、暑いのか寒いのか、温度変化が激しい。

気がつくと震えていることがあるが、そういう人は沢山いるようだ。

人が多いのに、トイレが少ないから、10数階から下とか上の
各階のトイレに行くがどこも満室だ。

仕方ないから、隣のビルとかに行って用を足す、こともあるが
苦しくてでない。

それで、体調を崩し、震えている人もいるだろう。

大きな建物を作るときは、トイレの数も多めにしてほしいな。
業種によって、体調不良の状態で労働している人が多い場合、
トイレは多めにないとこまるよ。

変わった事といえば、少し前に、偽装請負の査察らしきものが入った。
今の現場は、一応、請負の人達が多く、それぞれ、会社単位ごとに
分かれて座っている。

が、最近、私の島の周りの人達が、少なくなった。
というか、私以外いなくなったようだ。
どこかえ違う席へ移動した人もいる。
退場した人もいるのだろう。


毎日四六時中、色んなテストの経過とか故障情報が物凄い数で、やってくる。
これは、もう、リリース1年くらい延期しないとだめなんじゃなかという、雰囲気だ。

現場の空気は、重苦しい。



あるIT現場3 マスターはどするかな

あるIT現場3 マスターはどするかな

ほげ ->a
ほげ ->b
ほげ ->c
の場合、ほげ、a,c,b は、どういつとするのはいいけど、
a->ふが
ふが->ほげ
とか、循環する設定されると、つらいな。

どこまで、チェックするかな。

また、読みに行く、総勘定元帳の内容に、
部と科の従属属性の不一致がないといいんだけどな、
総勘定元帳に、属性不一致の発生があったとしたら、
とってきたものが、大丈夫か、とかも
チェックしないまずいかも知れない。

何しろ、パッケージとしては、部と科の従属属性がどうとか、こうとか、いう考えはない。

巨大グループだから、沢山の会社の統廃合、分割、消滅とか繰り返すから、
そこで、生み出された考え方かもしれない。

ある部の従属属性が、研究開発でも、
部の名称が、○○営業部
とか、なってるから、
部の名前からは、従属属性に、どんな、意味があるのかは、わからない。

その、○○営業部で発生するコストは、全て、研究開発費?
にでも、するつもりなんだろうかな。
その、○○営業部の売上高を研究開発関連に、割り振りたいのか。





あるIT現場3 横に並べて解決

あるIT現場3 横に並べて解決

担当分で発生していた、従属情報違いの故障は、
結局、横並びで抽出し、本物も抽出することで、
何とか、することになった。

A, B, (C, D, E, F, G), CDEFGの本物, SUM(DR-CR)
の形で、
その後、一発目の、仕訳で、B と CDEFGの本物
二発目の仕訳で、部を引いて、CDEFGの本物に対応する
ものを、(C, D, E, F, G)から、選択し、
(多分、適当に、順に見て、突合せして、
とおるなら、それだとでも、するのだろう)
なんとかすることになった。

しかも、誰か、調子の良さそうな、人を選んで、やってもらえるようだ。
よかったぁーーーーー。

でも、今、勢いのある、人が、いるんだろうかな。


あるIT現場3 うーむ 予想も期待もいつも反対だ

あるIT現場3 うーむ 予想も期待もいつも反対だ

故障と決定したら、どうするか。
同じような故障に、苦戦している、部隊が他にもある。

現行の、顧客が作る無理のある仕訳が、正であるとして、次期環境でも、その通りにするか。
それとも、顧客がやりたかったことを実現するのか。
とうことも一瞬浮かぶ。

顧客も非常に疲れているし、現場も、疲れ果てていて、調整がつかない。
顧客は、数人ではなく、関連会社とか、沢山ある、100社とか、200社あるのかな。

だから直すことになる可能性が高い。

あっという間に直すには、カーソルだけを大幅に修正し、その他は、少し程度になるようにしないとならい。
マスターの構造も直すことになっている。

普通に考えると、今は、大きなカーソルは1つだけだが、
素直に直すと、カーソルが、部と科の不一致な組み合わせの数だけ登場することになる。
物凄く沢山になっちまう。それでいて、あーでもない、こーでもない、とかいう、
カーソル外の集計と、分類が発生してしまうだろう。
パフォーマンスも気になる。

だから、カーソルの中に、カーソルをもつカーソルを作れば、1カーソルで済みそうだ。
それと、もし、部と科の組み合わせが、2つだけ考慮すれば、なんとかなるのなら、
今の、カーソルをほんの少しだけ、いじれば、何とか、なりそうなんだけど。

今まで、最大元請の考えも、凄腕の外注の人の考えも、私の考えも、通らない。

少し前に、現場を去った、最大元請の、
ロンだったか、アンだったか、が
顧客と、意志があっていた。




あるIT現場3 こりゃやばい

あるIT現場3 こりゃやばい


引きつづき、担当機能の調査を私ではない、凄腕の人が調査しだしたが、
・・・
嘘のような、ことが、ぽろぽろでてきて、収集がつかなくなりつつある。


カーソル直す程度じゃ、すまないだろう。

つらいな。

さて、どうするかな。


それと、何でもかんでも、連係系の機能の幾つかも、
あちこちで、連結障害をだしているらしい。

今、新しく、担当している、機能が、手間がかかって、かかって。
・・・
キーをフレキシブルなリストに物凄い数を登録し、
深い階層を作る必要があるのだが、
キーの長さが短すぎる。
機能の大分類のプレフィックスを入れただけで、
残り少ない。
それに、1機能で、10個くらいしかキーが登録できない。
何階層になるか、わらん。

もう、ベタに、たていれするしかないな。










あるIT現場3 ああーこんちくしょー

あるIT現場3 ああーこんちくしょー

しかしあれだな。
勘定科目の体系がつらい。
製造部門の現金の勘定科目コード 0000000100
開発部門の現金の勘定科目コード 0000001100
営業部門の現金の勘定科目コード 0000011100
総務部門の現金の勘定科目コード 0000111100
経理部門の現金の勘定科目コード 0001111100
販売部門の現金の勘定科目コード 0011111100
ほげほげの現金の勘定科目コード 0111111100
・・・
上記は、ほげほげの勘定科目コードを主とする。
但し、完全に主ではない。
ほげほげ、以外が、補助というわけではない。

なぜ、現金の勘定科目コードがおなじじゃないんだよ。
まだ、上記の場合は、尻が 100 だから、まとまりそうだが、

製造部門のほげの勘定科目コード 0000000800
開発部門のはげの勘定科目コード 0100000000
営業部門のげげの勘定科目コード 0003000000
総務部門のほほの勘定科目コード 0X00000000
経理部門のああの勘定科目コード 00000A0000
販売部門のいいの勘定科目コード 0330000000
ほげほげのううの勘定科目コード 1000000001
・・・

"ほげ","はげ","げげ","ほほ","ああ","いい", "うう"
が実は、意味が一緒で、
固めて合算するときは、"ああ"とする。
部門と勘定科目は、親と子を持つことは、パッケージに備わっている、
だから、それを深くすると、いくらでも、親と子が連鎖する。
が、
パッケージの機能をつかって、いない、
現行は、人間の目でみて、親と子、子、子、...
子同士は、兄弟?
とか、
手で、仕訳しているらしい、ことが、
今頃、わかってきた。

借りと貸し、相手、その他、
他段階振り分け、
そんなことw、人間がやっているらしい。

つらい。

よくまあ、人間が、仕訳切ることできているもんだな。




あるIT現場3 結局 修正するのか ガクッときたな

あるIT現場3 結局 修正するのか ガクッときたな

連結通し済みの、担当分の半分くらいの機能に影響しそうな、修正が入ることに、なっちまった。
もしかしたら、修正不要と顧客から回答が来るかもしれないけど。
可能性は低い。
修正を入れると物が、かなり深いところだから、影響が大きい。

今は、かなり面倒な、新規追加物を担当している。
細かいのいれいると、50種くらいの、DTDをDBに行列単位で持たせて、
それをパースして、DBなどから、抽出したものを割り付けるだけなんだけど、
設定するものが、かるく、1000を超えるんじゃなかな。
1 キーに10個くらいしか、割り当てられないから、キーとなるものがどうしても、
階層かしないとならない。


連結通し済みの修正もかなりの規模だが、
新規ものの方も、手間が、かなりかかる。


元請の人達は、新規物の方は、似たものが既にあるから、
あっというまに、終わると思っているのかも。
ところが、微妙にちがうものばかり。
階層が違いすぎる。

いや、まいっちゃったよ。





あるIT現場3 大きな故障が発生か

あるIT現場3 大きな故障が発生か

担当分の機能のあるものの振り分けで、部の属性と科の属性の不一致が問題になってきた。

直接は、私の担当だったのだが、元請は、私に何を言っても、意味がないともってか、
関係するものを作っていた、他の外注の人と、元請の若い人に、
しわ寄せが発生してしまいました。

もともとは、元請のサリーとアンそして、4種の顧客、それと私とその他の人々で、
長時間にわたり、レビューをしたのですが。

結局、落とし穴を掘られてしまったのかな。
もう、いなくなっちまった、アンの資料は、いったい、なんだったのか。

私が思うに、今、起きている、部と科の属性の不一致は、弾くという仕様がいまいちだとおもう。
顧客は、現行の手作業を、やめて、税務対策などを早くできることと、
現行では、足りないところを、もっと、詳しく細かくわけたいという、
そういう、要望だった。
のだから、
作っちまったもので、間違えは、ないと思う。

顧客の要望にそうているよ。

なのに、現行のその他の機能と少し、筋が違うからというだけで、
問題するのなら、
おかしい。

顧客の要望の振り分けは、どの環境にお存在しない。
あるのは、現行の考えで作ったデータだけだ。
そのデータが部と科の属性が一致しているとして、
それが、顧客のやりたかった要望といえるのか。












あるIT現場3 進歩なし 年寄り押すも 生産情報上がってこない 一糸乱れぬ長時間勤務

あるIT現場3 進歩なし 年寄り押すも 生産情報上がってこない 一糸乱れぬ長時間勤務

朝、メーラーを起動すると、意味不明のメールがじゃんじゃん、受信されてくる。
大体は、故障情報らしい。
プログラム暴走情報も沢山くる。

一括して、【???】へ移動する。


午後に、あれどうなった?
とか、問い合わせが来る。

最大元請の一等兵に、連絡していた。
表定義と実表が不一致、開発環境と尻1, 尻2, 外尻1, システムテスト環境, 特殊環境, 統合環境, ...
で不一致と連絡したら、
「お前が直せ」とか指示が来たりする。
そんなこと、いったって、なにをどう直すのか、わらんだろう。
何が、何時の、時点で、正しいのかが、わらんだろう。
何時の時点の、何に、何が、依存しているかもわからんし。
依存関係のある、プログラムとオブジェクトを調べると、
依存関係が沢山でてくるから、直したとして、動かなくなる、
ものが、沢山でてきちゃっうかもな。
それくらいで、動かなくらいように実装されているものは、少ない。
いくつかの、エビデンスを見ると、コード値とか、ありえない、値になっている。

これでは、連結できるわけがない。

エビデンスの作り間違えか、偽造ではないかと思われるのだが。


年寄りががんばっているらしい、生産計画系の部隊も故障多発らしい。
なんでも、いくつかある自動起動の仕組みを連係して、パッケージの
プログラム群を塊で動かすのだが、
自動起動A, 自動起動B, ... , ...
パッケージのセット起動P,
パッケージのセット起動Q,
...
プログラムX,
プログラムY,
...
...
その仕組みの中で、色んなものが動いているらしいが、
その仕組みの設計図が間違えている。
その仕組みの通りに、なっていない。
間違えているところが、絡み合って、一見正常に動いているように見える。
とか、
ある日は、間違って動いて、ある日は、上手く動いているように見える。

原因不明らしい。

で、生産情報が上がってこないから、
私が所属する部隊の、機能が空振りし続けているらしい。
が、
ときどき、ありえない、動きをした結果が作成されるらしい。
ありえない、組み合わせの機能が、起動され、絡み合って、
妙な、結果がでてくるらしい。

当分、システムテストは終わらないだろうな。
何しろ、日次、週次、月次のどの計画も、
予定された、機能の空振り起動さえ、確認できない。




あるIT現場3 進歩がない それは、yacc じゃだめなのか スケジュール外の計画が実行?

あるIT現場3 進歩がない それは、yacc じゃだめなのか スケジュール外の計画が実行?

担当分の機能は、連結テストまで終わっている。
システムテスト以降では、当分動く予定はない。

ところが、最近、何かの手違いで沢山の機能が、予定外に動いてしまって、故障が多発らしい。
本来、パッケージとしては、コンカレントで動いても何の差しさわりもない。
が、
作ったものが、いまいちなので、それを、許さない。

沢山ある、連係機能のうち、何でもかんでも連係とかいう、連係機能が、あちこちで、不評だ。
誰が、どう、直すのだろうか。
元請の、上等兵が、手下達に、どーすんだ、どーすんだ、と、あちこち、せわしなく、騒ぎまわっている。


私が所属している部隊の、最大の元請は、上等兵、一等兵、二等兵、見習いを投入している。
零細の元請のほうが、技術的には、かなり、すぐれている。
周りからは、先生と頼りにさている人もいる。
また、元請ではないが、下請けで、結構な人数の、人夫出ししている外注もある。
その外注の1つは、頗る、できる。
私も、何度も、助けてもらった。

一方、最大の元請は、たまに、見習いを最大投入してくることができるだけで、
技術的には、どーーーーーも、いまいちだ。

与信能力

それだけが、最大の元請の存在理由なんだろうな。


私は、しょっちゅう、最大の元請の、上等兵に、
「あーでもない、こーでもない」
・・・
いわれるのだが、
なぁーにを、いっとるのか分からん。

最近も、
「xxx を作ってくれ、2機能になる」
「xxx のレイアウトは、AAA ににている、
仕組みは、BBB だ」
「xxx のレイアウト自体は決定している」
「先ず、外部、内部、基本、詳細、・・・・の設計書の見積もりと、
見積もりの根拠、スケジュールを
今日中に、決めて、ほげほげ xls を作成してくれ」
「詳しいことは、一等兵から連絡する」
で、
しばらくすると、
その一等兵から
「xxx のレイアウトは、1週間後、位には、確定するらしいよ。
・・・
で、レイアウトは、
CCC に、似ている、
仕組みは、
DDD だ!
あと、よろしく

とか、いうメールが来た。

で、
何を、見たらよいのか、似たものが、沢山あるから、
A, AAA, AA,a, aa, B, BB, BbBB,
C, c, CC, Cc, c, ddddd, d, dD, DD
・・・
など多数見たが、どれも、これも、
どーも、違う。
それに、3機能になる。


で、3機能で、スケジュールを立て、報告したら。
元請の、上等兵から、「・・・なーに、やってんだ。・・・」
私は、「????????????」
元請の、一等兵からは、「EEEE だよ、今回のに、にてるのは、」
私は、「????????????」
・・・

しょうが、ないから、また、適当に、スケジュールの線を引いた。

数日後、
外部と内部設計書らしきものは、完成した。
で、レビュー依頼を、元請にだしたら。

一部レイアウトが顧客から出てきたらしく、その資料がとどいた。
みてみたが、サッパリわからん。
また、似ている、機能は、PPPP と QQQQ だよとか言い出してきた。

なんか、こー。
完成した、設計書と、まったく、仮定が違う。
はぁーーーーー。

しょうがないから、PPPPP と QQQQ を見てみたのだが。

なんだんだろな、この現場の人達は。

主に利用している、パッケージには、コード体系を、大分、フレキシブルに対応できるように、間接参照とかを利用できるように、なっている。
また、多言語化もデフォルトで備わっている。

が、
どうしてか、使い方を、どーして、こーーーーー、
そんな、使い方をするのだろうか。

最近やりだした機能は、
多分、yacc で 30行程度で、何とかなりそうな代物だと、思われるのだが。

似ているといわれた PPPP は、パッケージの、フレキシブル体系の間接参照とかを、深い階層で、
1000個、2000個登録して、
プログラムには、ほとんど、ベタ指定で、その、参照を利用している。

1000個、2000個もどーやって、手入力設定、しているんだろうか、ここ現場の人達は。
参照のインポート機能は、利用禁止の規約だったと思うし。

どーして、使い方をここまで、
フレキシブルな、機能を、ベタに使おうとするのだろうか。
コード体系がフレキシブルでも、その利用の仕方が、ベタに書いちゃってるんじゃ、
じぇんじぇん、フレキシブルになってないよな。

yacc なら、30行程度と思われるのだが。

でも、そんなこと、言ってもしょうがないから。
やるしか、ないのかな、
最近、現場で、ボーっと、
どーして、
こういう、現場が存在しているのだろうかとか、考え込む。
手が全く進まない。

表定義書と実表は、一致していないもの、沢山あるし。