|
||||||||||||||||
| 1 2 3 次のページ | ||||||||||||||||
| IT要員は活用されているのか? | ||||||||||||||||
|
昨年、大滝令嗣氏の著作「理系思考エンジニアだからできること」が静かなブームとなった。 この本では、エンジニアだからこそできる発想や、論理的思考の重要性を解説し、これからは理系的発想こそが大切だと説く。 エンジニアはつぶしがきかず、頭が固い人間だと思われているが、実はそうではないという切り口が注目を集めるきっかけとなったようだ。これを読んで頭に浮かんだのは、はたして自社のIT部門はエンジニアと呼べるだけの感性と技術を蓄積し、駆使してきたかということだ。 本来、IT部員はITという専門知識を使って、社内の問題解決にあたる職であるはずだ。だが困ったことに、その専門知識の蓄積がなされていないと感じた。 例えば、ITコーディネータやCISA公認システム監査人には資格更新の都度、継続教育時間を満たすことが要求される。概ね3年間で累計百数十時間のOffJT(職場外研修)をこなすことが科されている。 職務内容に程度差があるとはいえ、同じITに携わる者として考えたとき、職場の同僚や部下、あるいは上司は自分の専門領域のキャッチアップと鍛錬に、彼らと同等の時間を費やすことができたであろうか。 世間では無料セミナーや有名ベンダーの資格試験にのみ、参加者が殺到する現状を見ていると、ほとんどのユーザ企業は「NO」と答えるのではないだろうか。 |
||||||||||||||||
| 3つの誤解がIT要員の育成を阻害 | ||||||||||||||||
|
なぜ、このようにユーザ企業は消極的なのかと考えたとき、一般企業に蔓延している、次の3つの課題が浮かび上がってくる(図1)。
表1:3つの課題 1、2は、社内のIT部員を技術者としてではなく、一般事務員として捉えているところに端を発している。 社内IT部員を「事務計算に特化した人」と考える人は多い。それもそのはず、経理伝票処理や給与計算のために大型(あるいは中型)電子計算機を導入した企業では、計算センターの要員は必然的に事務系社員が占めることが多いからだ。こうなると、自社の伝票の流れに詳しいとか、処理の方法に詳しいということが重視されるので、エンジニアリング要素は極めて薄くなる。 人事面でも一般の事務系社員と同様に見なされるためか、様々な部署を経験することでゼネラリストとして成長することが要求される。そして、じっくりとITを極めようという考えはユーザ企業ではなじまないものとされてきたのだ。 それが今では、IT要員は「ITを知っていて当然」という、社内の暗黙の認識にさらされる時代となった。加えて、さらなるIT化の期待と業務改革へのリード役まで期待されている。 だがその前に、企業はこれまでロクに「エンジニア」として、IT部員を育ててこなかったツケを払う時が来ていることに気づく必要がある。 技術力を蓄積できていないからこそ、次のような悪循環を繰り返しているわけだ。
表2:IT部門の悪循環 一方、費用対効果の面で考えると社外コンサルタントや技術者と契約すれば、月間数百万円のオーダーで経費は発生する。未知の分野ならいざ知らず、社内に類似機能があるなら、社内で育成するほうがはるかに安く、ノウハウも蓄積できるので何かと有利だ。 筆者の経験だが、研修費50万円をかけて実務をそれなりに経験させると、月額150万円のベンダー技術者とも同等に渡り合えるようになるものだ。 また、1回当たり数万から数十万円が相場となっているIT研修に、自費での参加を期待するというのもナンセンスだろう。 表1の3の効果的な育成方法がわからないのは、オープンシステム時代に特有の現象だ。 メインフレームやオフコン一辺倒の時代とは比較にならないほど、要素分野が広がり難易度が高まっている。 従来はちょっとした物知り部員(スーパーマン)が1人いて、部下を数人張り付けさえすれば、メインフレーム1台ぐらいは楽にハンドリングできた。だが、今はそう簡単にはいかない。 |
||||||||||||||||
|
1 2 3 次のページ |
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||


