補足と言うか、解説。


投稿者 KawKaw 日時 1999 年 5 月 13 日 12:19:39:

回答先: GW実機日付変更テスト(転載+α) 投稿者 KawKaw 日時 1999 年 4 月 28 日 23:44:43:

 私と、下(あと、上)の「IT 部門員 K」氏とのスタンスの違いはサンプルとして面白いと思うので、補足と言うか、解説してみます。

 私もk氏も企業内IT部門でメインフレーム上のシステムを担当しています。k氏はアプリケーションの開発維持をご担当されているものとお見受けします。対して、私は運用の担当者です。

 私は運用で日々トラブルに晒されている身の上のため、アプリ担当者をあまり信用していません。
 メインフレームの場合、24時間365日(に近い状態)オペレータが張り付きでオペレーションをしており、トラブルが起こると、まず運用管理の担当(つまりオレとか)に連絡が入ります。そんな訳で、私は、常日頃、夜中に叩き起こされたり、休日に呼び出されたりといった生活を送っています。

 で、トラブルを出した本人を問い詰めると、「テストしてません」なんてことを平気で言ったりするんだよねぇ。(あと、始末書の再発防止策に「きちんとテストを行う」とか。何それ?!!)
 まあ、アプリ担当者の労働実態を見ると、分かんないわけじゃないけど。つまり、人手もスケジュールも足りない中でやってると、現実問題として、じっくりテストなんか出来ゃしない。で、ロクにテストもせずにさっさとリリースだけして、トラブったらそれからなんとかすりゃいいという行動パターンになってしまう。(ヒドい担当者の例。でも中にはこんなのがいるのも事実。)

 しかし、こっちはそれで夜中に呼び出されたりする訳だから、勘弁して欲しい。Y2Kでそれをやられて、ボコボコにトラブったりされた日にゃ、もう、収拾不能でしょう。
 
 テストはちゃんとやって欲しいです。

 以上、運用の意見でした。

 ところが、アプリの側の事情も見えているだけに、心中複雑なものがあります。(以下、うちのアプリの事情。)

 通常業務ベースですら満足にテストもできない状況なのに、上乗せする形でY2Kのテストが降って来る。「適切なマネージメント」が行われないから、仕事の優先順位が示されない、スケジュール調整がなされない。結果、担当レベルで、締め切りが迫っている仕事から優先順位を割り当てていくことになる。すると、Y2Kのテストはいつまでたっても進捗しない。

 「IT 部門員 K」氏のところの事情とうちの事情とは違うんでしょうけど、うちはこんな感じです。

  K氏が仰る通り、Y2Kのテストをまともにやろうとすると物凄い工数を要します。当然、相応の体制とスケジュールが必要になります。体制とスケジュールの保証がない限り、テストは絶対無理。例えばうちのアプリの場合、絶対無理な状況下にありますから、テストが進捗しないのも当たり前でしょう。プログラム修正に自信があるなら、「テストなんかやるだけムダ」という判断もアリかもしれない。

 でも、運用としては、やっぱり、テストはして欲しい。

  --- * ---  --- * ---  --- * ---

[補足その2]
 うちの場合、急に実機テストなんかすることになってしまったもんだから、そっちの準備のため、通常のY2Kテストの進捗が(さらに)遅れてしまいましたとさ。(大笑い)



補足の補足。


投稿者 KawKaw 日時 1999 年 5 月 15 日 12:06:17:

> そうですね。マネジメントの影響は大きいでしょうね。逆に言えば、
> 担当者が必要だと報告しても、「こっちが忙しいから、やめとこう」
> という雰囲気(決して指示を出すワケじゃない。)になると、
> できませんしねぇ。

 一企業のシステム案件の優先順位付けってのは、経営判断なんですよね。本当は。

 IT部門執行部とかシステム担当役員にそれなりの問題意識があっても、システム担当はヨワいですから、役員会なんかで営業担当のコワモテに負けちゃうみたいです。で、どーでもいーよーな「戦略システム」とか、「他社対抗事案」が高プライオリティになる。

 それ以前にIT部門のエラい人達が、目先や、自分のポイント稼ぎに拘われていると、別に今やんなくてもいーよーな案件を推進したりします。Y2Kの方はテキトーにやって、テキトーな報告をしてたりする。

 どっちにしろ、代表取締役レベルが事態を理解して仕切り(あと、チェック)をしないと、Y2Kは進捗しません。
 Y2Kを「経営の重要課題として認識する」ってのは、詰まるところそういうことです。でも、今だにできてないねぇ。

 


[Back]