キカイに任せるイコールオペレータに任せるでしょ

客はね、業務効率化とかなんとかいって、コンピュータにやらせるところはぜんぶやらせたい。
そういう要件のもとに、システムはつくられる。

でもさ、客がコンピュータに押し付けたと思っていることは実はやっぱり運用のエンジニアが人手でやってるよね。
運用を「管理」してるんだから。

オープン化されてからますます運用エンジニアの負荷は高まってきている。
ということに客は気付いていないのだろう。だから、ランニングコストがたけーだのまけろだの言い出す。
運用の受託側も、極限までランニングを切り詰めるから、運用の品質が下がる。
品質が下がるとどうなるかというと。。
組織として、自律的なカイゼンができなくなるんだよ。

特に、安いからっつって安易にガイジン部隊を構成すると、そうなる。

システムなんざ安かろう悪かろうアタリマエじゃねーか。
ただ、こっちも弱いのは、前になんかに書いたけど、このギョーカイは未だに見積もりの精度が甘いんだよね。。

なぜ見積もりの精度が上がんないかというと、モジュールの部品化ができないからなんだろうなあ。
そのへん、正直詳しくないけど、人手の開発が入ると、要員によってあまりに生産性が違いすぎるから、カネにブレが出まくるんだよね。


ところでこの議論の前に、ランニングコストと同様にイニシャルだって極限まで削られてんだから、構築されるシステムの品質だって下がってんだよ、それを押し付けられる運用は大変だよなあ。

結合テストんときのバグだってさ、運用で回避できるとなりゃすぐ申し送り事項になってまって、運用引継ぎのときに「あとよろしく」になっちまう。
それに対して文句いったところで「もう時間がない」「工数がない」っていわれちまったら、結局どうにもならん。
そして、運用開始を見届けて、構築部隊は解散して逃走する。

そして運用部隊も品質が落ちてるから、ぐだぐだになってゆく。
そしてしばらくすると、どこからともなく「ITILで運用をカイゼンしましょう！」みたいなことを言い出す営業がやってくる。。
こういうのを「マッチポンプ」という。


勝手にやれよテメーらって感じ。その運用カイゼンも「構築」されて運用に押し付けられんだからさ。

だからオイラはこのギョーカイがキライなんだろうなあ。。


やっぱこれからは運用の要員のほうにスキルフルな人材を投入してったほうがいいと思うんだよね。

それをギョーカイ全体で実現させてゆくには、どこをつつけばいいのだろうか？