製造業社内ＳＥの行く末

質問

私は、製造業の社内にある情報部門のＳＥをしている４０代後半の男性です。今まではメインフレーム（Ｈｏｓｔ）を中心としたシステム開発・運用・保守がなされきました。しかし最近はＯＰＥＮ系の開発・運用・保守が中心となり、社内でも活躍する年代が３０代前半となってきました。４０代の社員は徐々に管理職に職種を変更しています。管理職のポストが限られているいるので、管理職になれなかった社員は、社内での仕事が極端に少なくなってきています。
(1)一般的に、製造業社内ＳＥで管理職にならなかった社員は、社内でどのような進路を進むケースが多いのでしょうか？
(2)又、その進路を見いだす為に皆さんはどのような活動・行動をしているのでしょうか？
ご伝授よろしくお願いします。

回答No.4

noname#147912 · ベストアンサー

この問題は100年前も100年後も消えない悩みであり、こればかりは技術系の人間がいずれ通る道であり、いまにHOSTとOPEN系に限ったことではないと思いますが。技術系であれば、もっと若いうちに考えておいた問題ではないでしょうか。

技術では到底若いやつらに勝てません、しかし質問者さんにはかけがえのない経験と業務知識があります、これを生かす道はないでしょうか。よくあるパターンが、40歳まで開発保守で、40歳くらいから営業・コンサルタントに転身する方が多いですが、どうでしょうか。教育指導係り、相談役などの職もあるようですが

でもやはり高年齢の技術系になると、頭がついて来れない上、給料が高いという理由で、リストラされる方が多いというのも事実で、研究職ではない技術系だけに、こればかりはどうしようもありません。

最近は外注・アウトソーシングが流行っているようで、20数年以来の経験・人脈をフル活用して、その外注部門を立ち上げて独占する、そして自分の立場を確保するというのはどうでしょうか。

参考にしていただければ幸いです。

補足

回答ありがとうございます。参考になります。
おっしゃる通りもっと早くから手を打っておくべきでした。
自分としては、４０歳頃に情報部門を離れるつもりでいましたが、２０００年対応ともう一つ大きなプロジェクトに参画委した為、機会を失ってしまいました。

外注部門の独占の話良くわかります。しかし先住者がいます。部門までは行かないのですが、システム運用とシステム保守の係にそれぞれ５０歳代の社員が牛耳っている状況です。そこもオープン化に向け活動を進めており入る隙が無い状況です。

回答No.3

qpi

(1)進路
そのままです。

(2)活動・行動
システム構築技術でのホストとオープン系の違いは、
開発言語だけでなく、業務システムのあり方や、開発手法が異なります。
それらを吸収するためには、教育・研修を受けると良いと思います。
ホスト系であっても、オープン系と接続する機会は多く、
その部分を作ったりすることで少しずつ勉強ができると思います。

また、ホストであっても
業務要件や必要な業務処理はオープン系でも変わりはありません。
それを武器に、指導的な立場につけばいいのです。
オープン系の技術の細かいことは若いのにまかせ、
プロジェクトマネジメント関連の知識を身につけていけば
また違う道が開けます。

補足

回答ありがとうございます。参考になりました。
今までは自己流でプロジェクトの推進を行ってきましたので、きちっとした知識を身につけていこうと思います。

それともう１つお聞きしてもよろしいでしょうか？
当社の基幹業務システムは、先輩達が築きあげ後継者に引き継がないまま引退してブラックボックス化しています。
なのでスクラップ＆ビルド的な方法で徐々にオープン化しています。そのオープン化及びホストとの連携も若手が担っている状況です。
こう言う状況なので指導的な立場につく事も難しく活路を見いだせない状況です。何か良い方法があるでしょうか？
自分としては、ブラックボックス化しているシステムを掘り起こす事で何らかの活路が開ける事を期待しているのですが。

回答No.2

lv4u

>>管理職のポストが限られているいるので、管理職になれなかった社員は、社内での仕事が極端に少なくなってきています。

時代の流れですね。いまだにOPEN系は、メインフレームやオフコン系の信頼性に及ばない気もするのですが、コスト差や開発スピードを考えると、OPEN系が増えてしまうのもしかたない気がしています。部屋の明かりが行灯から石油ランプになり、そして電球に変わってゆけば、古い技術にしがみついている人も同時に不要になってゆきますからね。

>>私の職場では、社内の業務の流れや要領、その業務で使用しているシステムの機能をドキュメント化したものが無く、完全なる属人化になっています。今後業務内容やシステム内容を掘り起こしながら改善活動を進めてみます。

業務のドキュメント化、それを受けての業務明確化は、かなりの工数、期間がかかりますね。まして、それを反映してシステム化までするとなれば、３ヵ年計画、５ヵ年計画、（１０ヵ年計画？）のようになる気がします。

ということで、「しばらくは、我々の仕事があるなあ、ほっと一息」っていう作業量が生まれると思います。
でも、

業務のドキュメント化　＝＞　自分で苦労して得たノウハウの公開

っていう部分もあると思いますから、「俺の業務がとられる。派遣に置き換えられてリストラされるかも？」っていう、ある意味で正当な疑問・反発も予想されるし、業務が忙しいって理由で、協力してももらえないかもしれませんね。経営者の理解・協力を得て、トップダウンの業務命令が必要だと思います。

ちなみに、私はパソコンの業務ソフトを初めて見たとき、その使いやすさや開発の容易さに惚れて、ＰＣ系の勉強に力を注いだのですが、「ＰＣ系をやっている限り、新人の大量抱き合わせ派遣などができず、会社の儲けが少ないので、君の評価は低いよ。昇進は難しいね。」という上司の一言で１０年あまり勤めたメインフレーム系の会社から退職を決意。まあ、「当社にきて」って誘いが事前にあったので決断は早かったといえますが・・・。

P.S.
昔、某大手自動車会社のシステム化企画書を見たとき、「本システムにより本社人員の５０～１００名に余裕ができる。なお、この部分は公表しないこと。」なんて意味の記載がありましたからね。

お礼

回答ありがとうございます。
ブラックボックス化されているシステムの内容を掘り起こすのは大変な苦労だと思っています。
それをして自分自身のスキルを向上させる事が肝要なのでしょうね。

回答No.1

m_inoue222

１．時代に付いていく
２．知識の吸収

社内のシステム開発をされていたのなら何が重要かはご存じだと思いますが？
社内の全業務を知らなければ有効なソフトも開発できないのでは？
プログラミングの能力よりも業務の把握の方が大切だと思います

わたしも８０年代からオフコンでの開発・運用・保守をしてきましたが今年から全基幹システムのＯＰＥＮ化に取り組んでいます

実務は若い者に任せていますが業務を知らなくては実際のシステムは組めません

４０－５０代は自分で社内の問題点を発見し、自分で自分の仕事を作るべきと思っています

自分で考えたシステムを若い人に作らす．．．それで良いのでは？

お礼

ご回答ありがとうございます。参考になります。
オフコンからＯＰＥＮ化への切り替え大変なご苦労をされてるのかとお察し致します。

私の職場では、社内の業務の流れや要領、その業務で使用しているシステムの機能をドキュメント化したものが無く、完全なる属人化になっています。今後業務内容やシステム内容を掘り起こしながら改善活動を進めてみます。