現在就職活動中の情報系専攻のひいと申します。

大変勉強になる記事だと感じました。

情報系学部の卒業生に体験しておいてほしいものとして「チームによるシステム開発」
が多く見受けられたのが印象的です。

もし、「チームによるシステム開発のすすめ」なる書が書かれるのであれば、
マニュアル化されるのであれば、指針を持って進んで取り組む学生が増えるのではないかなとも感じました。

業界をオープンソース化すると良いかと思います。
そうすれば、学生にもこの仕事の楽しさや苦しさも伝わります。
新入社員を迎え入れるにあたって一番問題になるが、現実とのギャップですから、曖昧に入社させるのではなくて、現実を知ってもらって入社してもらう方がよいです。
こうすると、余計な経費も削減できます。
また、悪い意味でのサラリーマン感覚は害になりますので、自分の働きがどのように利益になって、見返りが幾らなのかを明確にすればいいかと思います。
日本はどちらかというとこういった事を隠蔽して、社員を妥協させて囲い込む戦法をとりますが、それでは3Kな本質は変わりません。
それよりも、全て可視化した方がこの業界の健全化と利益向上ににつながります。

チームでの開発は必ずしも体験可能なわけではないと思います。

特定の学生一人のみにやる気があっても、他の学生にやる気がなければ、
現実での開発体験は難しいとも思います。

あまりよいこととは言えませんが、例えばある種のシミュレーション（個人が仕様を把握して機能の一部を実装を担当するような状況での、開発を疑似体験できるゲームや、もしくはそのような環境を提供するe-learningサービス）などもひとつの手と思います。

技術力の向上に繋がらなくても、少なくとも、チーム開発は難しいということは理解できるのではないかなと思います。

以上、いち学生の稚拙な意見ではありますが、このような考え方もあるんだと思っていただけると幸いです。

> マニュアル化されるのであれば、指針を持って進んで取り組む学生が増えるので
> はないかなとも感じました。

最近、教育を任されることが多くなっているものです。
確かに、マニュアル化すれば楽なのかもしれません。。

しかし、多くの若い方を見てると自分で考えることをしない印象を強く受けていますので、マニュアルには頼りたくない、この頃です。

ものごとは必ず、決められた方向に進むものでないので、それぞれの状況で考えて行動をするのが社会人だと思います。それって経験してないから。。とか言い訳をされても困るのです。

教育担当をしている、一意見になりますが。。

ひいさん、

　コメントありがとうございます。
コラムニストの高橋です。

　いくつかの大学で客員として講義したことがありますが、学生があまりにもIT業界のことを知らないのに驚きました。一時ホリエモンが有名になったときは、M&Aや投資のイメージを持つ人が多かったのと、ゴリゴリとプログラムを書くことが仕事だと思っている人が圧倒的に多かったようです。
　そんな学生がIT企業に就職したときに、あまりのギャップに呆然とする―、という構図です。

　インターン制などを取っている企業に、体験入社できればラッキーですが、殆どの学生はその気があっても、実際を把握するための手段が少な過ぎるというのが現状ではないでしょうか。
　教える側も業界を知らず、ニッチな部分を掘り下げていくという傾向があったと思いますが、最近はコメントにあったようなチームで実際の開発プロジェクトを進め、実経験を積みながらスキルアップを図るという実践的なトレーニングが主流になってきています。読み物ではなく、擬似的に実体験するというもので、より実践的です。

　これは、PBL（Project Based Learning)と呼ばれていて一般的になっていますが、企業での実績を基にした授業をされている筑波大の駒谷氏が有名です。
http://www.cs.tsukuba.ac.jp/~komaya/profile.html

>しかし、多くの若い方を見てると自分で考えることをしない印象を強く受けていますの>で、マニュアルには頼りたくない、この頃です。

マニュアルの内容によっては頼るべきだと感じます。
どんな内容かが問題ではありますが。。

>ものごとは必ず、決められた方向に進むものでないので、それぞれの状況で考えて行動>をするのが社会人だと思います。それって経験してないから。。とか言い訳をされても>困るのです。

今回の資料にも技術者のキャリアアップの責任の企業側と社員側の互いへのなすりつけにつて調査が行われていました。企業側が技術力向上を軽視している風潮があるなか、成長の「責任」の所在を明確にすべきかもしれません。

こういった精神論はいつも不毛な議論を生むものかなとも思います。自重します。

インドリさん、

　コメントありがとうございます。
「IT業界のオープン化」、いいですね。
ある意味、それができているのが外資系のIT企業でしょうね。次世代リーダーまでもNamedして競わせます。当然脱落者も出るし、その人は留まっていられなくなります。

　給与も明確だし、対象エリアでの利益を配分するという方法も確立しています。
儲かっていれば厚遇となり、そうでなければ減給、場合によってはリストラの憂き目に合う可能性もあります。

　一方の日本企業は、儲かってもあまり社員には還元しないですが、そうでない場合も影響度は小さい―、とういのは今までの話で、儲からないときは結構ドラスティックな手段に出る企業も増えているようです。儲かってもあまり還元しないというのは、そのままですが。

　今日の日経新聞に、成果主義の企業より終身雇用のほうを望む学生が過半数を超えた、というアンケート結果が載っていました。考えさせられる内容です。その過半数に当たる方は、こういうコラムにコメントしないものなのでしょうか。

　私は、外資系と日本系の両方の企業にそれぞれ10年以上在籍しているので、よく分かっているつもりですが、好き嫌いは別にして、双方に利点と欠点があります。

　何事も明確なのが外資系で、儲かっているときは非常に居心地がいいですが、窮地に立ったときに逃げ場が無いとも言えます。

　日本系企業は、大手の場合は倒産する危険性も低く、環境にあまり左右されませんが、何かそこにいる価値が次第に薄れてくる感じがします。中小の場合は、昨今の景気の悪化で生き残りをかけた熾烈な競争にさらされていますが、優れたリーダーが引っ張っている場合は、仕事に対する大きな達成感が得られる場合が多いと思います。

　個人的には外資のほうが自分には合っていたと感じています。これは性格にもよるので、かなり個人差があると思います。

難しい言葉はよくわからないので、私なりの考え方で書きます。

企業側：どんな方向に向かい、どんなコンテンツを用意し、そのために必要とする技術は何か、はっきりさせた上で人材を探す。

技術者側：俺の技術はこれだ！という得意分野を持つ。そのうえで、その技術で実現させたいことの野望、というか方向性を持つ。

　で、この二つがベストマッチングすれば理想。

　実際のところだと、企業側の人材像もあいまい、技術者側も自分の像すら見えていない。結果、ベストなマッチングはしないし、企業優位の一方通行(つまり、「やらされる」という感覚)に見えます。これでは満足度も上がりません。

　これは、教育が受動的なものから来る弊害、オタクを排除しがちな文化による弊害でしょう。技術者側から自分をプレゼンし、「俺の知識を貸してやるぜ！」みたいな気概をもって活動しないと、変わっていかないのかもしれません。今はその変化が必要だと思います。

私の感じる「自分の将来についての不安」は
このまま40才50才になってもエンジニアでいられるか？です。

エンジニアとしての能力があっても年齢で切られるのではという
恐怖があります。

あなたの能力が低いから首ですって言われれば納得できますが
あなたは40才超えてるから首ですって言われるのは納得できません。

私個人は同一労働同一賃金のモデルの方が
年功序列や正社員優遇より理に適ってると思います。

でも、「成果主義の企業より終身雇用のほうを望む学生が過半数を超えた」ってことは
私は少数派なのかもしれません。

＞naomsa02さん
私は、教育はシステマチックに行うべきだと思います。
そのためにはマニュアル（教科書）は必ず必要です。
教育の目的は、経験知では時間がかかり過ぎるし無駄も多いとか
経験則ではない理論的な裏付けのある理解を得るためだと思います。

もし、マニュアルがなければ
教育レベルは教育者（先生）のレベルに左右されてしまいます。

教育者にも得意不得意があります。
得意分野ならなんでも答えられるかもしれませんが
苦手分野の質問に対し「分からない」ではなく
「ここを見ればヒントがあるかも」くらいは言いたいですし。

できる人から教われば幸せですが
そうでなければ、何も学べないかもしれません。

そんなとき基準や目標となるものがあれば、
本人のやる気次第でその基準に達することが可能だと思います。

やる気が無い場合は・・・
気長に芽が出るのを待つのでしょうか・・・

他の方のコメントに対してですみませんが、気になったのでコメントさせてください。

> 成果主義の企業より終身雇用のほうを望む学生が過半数を超えた

ただ安定を求めているだけでなく、成果を評価出来ない会社が多い中、リスクだけが高い成果主義に合わせる理由が無いと言う人も居るのではないでしょうか。

> 技術者側：俺の技術はこれだ！という得意分野を持つ。そのうえで、その技術で実現
させたいことの野望、というか方向性を持つ。

こういう人が増えれば企業側も求める人材をはっきりさせてくるかもしれませんね。
仮に苦手分野で分からなくても、「＊＊さんなら分かりそうだから聞きに行こうか」、「新人が面白い疑問を持ってきた。ちょっとミーティング開いて議論してみようか」で良いと思うのですよ。

業務量が減ってきている今だからこそ空き時間を如何に有効に活かすかも問われてきたと思います。
と、自分にも言い聞かせています。
長文失礼しました。

教育について議論されているようなので、私からも一つ。

　教育してもらえるって、贅沢きわまりないことだと思います。

　中小企業だと、そんな余裕ありませんし、やる気が出るまで待っていると会社がつぶれます。また、技術屋が自分一人で「自分がわからなければ、会社がわからない」という立場に置かれることもあります。そんな中で教育なんてあり得ないし、知識がほしかったら自分で探しに行く、自腹・自作・自己責任で自宅でイロイロやってみる、それしかないのです。

　私が残念に思うのが「教育してもらって当たり前」の考え方が多すぎること。プロなら自分で情報集めて、自分の中で価値が出るように加工・生産し、その知識を会社に売って(雇ってもらって)金を稼ぐ。それくらいしないとダメですね。今はググれば情報があふれているので、それ以上の価値を出す努力が必要です。

>ノンビさん

>教育してもらえるって、贅沢きわまりないことだと思います。

教育しないってことは、その会社としてのノウハウや企業理念を引き継ぐ気が無い
ってことになりませんか？
もしくは引き継ぐべきノウハウすらない？？

個人の努力が必要なのは当たり前ですし、中小企業が厳しいのもわかりますが
それでは組織としての強みが活かせてない気がします。

例えば、私個人で勉強や情報収集できる量はしれてますが、
多数で行えばよりよい情報が多く得られるはずです。
それを水平展開できることこそ個人に対する組織の強みだと思うのですが。

個人の努力だけに依存することもありかもしれませんが、
それで国際競争に勝つのは難しいと思います。

結局、技術者が育ちにくい環境なんですね。

「教育してもらって当たり前」を技術者側が思ってしまってはおしまいですが、
「自主勉強が当たり前、我々は教育しないで当たり前」を教育担当者や経営陣が思ってしまうことも問題だと思います。

例をあげれば勉強会などでは、技術者側がその準備ができなければ、教育担当者や経営陣がその場を用意すべきです。
そんなものは仕事の時間以外で勝手にやるものだ、というものかもしれませんが、
それだったら、教育担当者や経営陣も業務時間以外で用意する姿勢を見せるべきです。
それこそ会社のための行動ですし、立派な社会人の行動ですし、なにより、プロの教育者や経営陣ならやって当たり前です。

技術者が自分で知識を得るために努力することと同じような精神論です。

たとえ中小企業でも、会社を思うプロの教育担当者や経営陣なら、勤務時間外も教育の努力に充てるべきですね。当然の話です。

日本では社畜になりきるか、精神論を唱えて何とか今まで乗り切れていたのかもしれません。

これからも本当にそれでやってけるのでしょうか。

皆さん、

積極的なコメント、ありがとうございます。
多忙だったこともあり、書き込みができずに失礼しました。
「人材育成」や「教育」について、皆さんの関心の高いことがよく分かりました。

　コメントいただいた内容は、エンジニア個人の視点、企業側の視点でそれぞれ異なる部分があると思います。どちらがいい、わるいではなく、違って当然のことだと思いますが、お互いにそれぞれの立場を、もう少し認識しておく必要もあると思いました。

　たとえば、私も実際に何度も経験した話ですが、どうしてもう少し突っ込んで対応しないのだろうと思い、尋ねると「教えてもらっていないからできない」という回答が返ってきます。これは、企業のサイズには関係なく、複雑な思いになりますが、こうすればもっとよくなるということを自分で考えてやってみる、ということにはならないようです。
　自分で何でもこなしてきた先輩や上司からすると、なんと気の利かない、役に立たないと思われるかもしれません。しかし、縦割りになっていて役割分担が明確なゆえに、逸脱したことをすることが許されない、というのも最近の傾向です。
　このような状況の中、理解できる人には説明が必要です。ツーカーで分かるような状況にはありません。言わなくても分かるだろう、一度言ったのだから分かるだろう、では通じない場面も多いと思います。くどいようですが指導する側は、そういう状況ではない、自分の過去の経験と比較してもあまり意味が無いということを認識しておく必要があると考えています。
　そして、むろん教育することが必要ですが、それでも、できない、もしくはそんな考えが無い人に、それ以上のことを求めてもむなしいだけかもしれませんね。

　企業としては、ビジネスのマキシマイズが目標ですから、それに貢献する人を育成したいわけです。
　ですから、育成する責任は企業にもあると考えています。ただし、エンジニアをスキルアップさせることが目的ではなく、あくまでビジネス目標達成が人材育成の目的です。
　これは、経営方針や戦略に直結した話で、これも企業サイズが大きいからできて小さいからできないとは、一概に言い切れません。2桁の人数の企業であっても、立派に方針を持って貫いているところも数多くあります。
　そういう企業は、和気合いあいとエンジニアが求める教育を施すのではなく、目的に合ったものを厳しく選定し、投資効果をウォッチしています。

IPA2007フォーラムの発言にもあったことですが、

やっぱり「企業側も技術者側もぬるま湯につかっている」状態なんですね。

これでは日本のITはだめですね・・

> 放浪者さん

>教育しないってことは、その会社としてのノウハウや企業理念を引き継ぐ気が無い
ってことになりませんか？
>もしくは引き継ぐべきノウハウすらない？？

　起業して1年もたたない、日本初のプロジェクト(WBSにも紹介された)、ノウハウ作るのは自らの力だけ。技術担当は私だけな上に、他の人は技術に疎い。とある極小企業での普通の話です。

　となると、歴史もないし、引き継ぐノウハウなんてあるわけもなく、私が作った技術ノウハウがすべて。教育なんかあるわけもなく、お客様の要求に応えるために全部自分で考えなくてはいけない。できる範囲を広めるためには、自ら知識を広め、自分でノウハウを築くしかない。これくらい、プロのエンジニアを名乗るなら、やってて当たり前だと思うのですが。

　起業したての会社を何社か経験していますが、教育などなく、私の知識と力を頼られる、そんな感じです。勉強会と呼ぶものもありませんし。教育を受けられるということは、それだけ余裕もあるし、幸せなんだと思います。

　皆さんは、システム開発系とかベンダーとかを基準に話をしているのかもしれません。ユーザー企業に勤める技術屋は、ベンダーさんとは違い、一匹狼で苦労することも多いです。

教育体制を整えるのにもマニュアルが必要。。なんて状況かもしてません。

＞ノンビさん

高橋さんが上でコメントされてることですが
「ビジネス目標達成のために人材育成」が必要かどうかですよね。

起業間もない時期だと、たしかに他に優先すべきことが多いと思います。
教育が重要になるのは事業が軌道に乗り出して増員したときなんだろうと思います。

＞教育が重要になるのは事業が軌道に乗り出して増員したときなんだろうと思います。

なるほど納得だけど、この業界で軌道に乗って増員する仕事がどれだけあるでしょうか。

終わった仕事は縮小の方向で新規の仕事ばかり。
開発が終わった仕事をサポートしつつ、新規案件を新人を使いながら進めなくちゃならない。

当然、新人教育も行き当たりばったり。
お手伝い程度の仕事をほぼ思いつきで強引に押し付けてます。
実際、仕事の内容とか意味は、ほとんど内容は理解できてないはず。
（これって教育じゃないですよね。）

このままではダメだとは確かに思います。
でも、私が新人のころから特に変わった話でもなく、お手伝いで満足できない社員が自発的に育っていくものだと思っていました。
この方法以外、時間も経験も無いのでできません。

仕様書の内容すら理解できるように教える時間が無いのに、何をマニュアルにできるの？

ほかの会社では違うのですか？

いきなり駄文で恐縮です。

IPAって業界の提灯持ちになってしまったんでしょうかね。
IT業界を敬遠しがちな優秀な学生を引き止める手段として作らされた資料のように思えました。

つらいのはIT業界に限った訳ではありませんが、下請け、孫請け、ひ孫受け、、、、

みたいな状況を見て見ぬ振りしている状況が改善されない限り、３Kと呼ばれる状況の改善も無理だと思っています。

人月80万と仮定して、１次請けに10％、２次請けに10％、３次請けに．．．
と単純に想像しただけでも単価が下がります。

最近は不況ですから、人月80万なんて依頼すらもあるかどうか。
搾取割合も減ってます。

T芝とかH立とかM下とかいろんな上場企業が、とりわけ有名な方でなくても、皆様の実力だけを判断して、中間搾取無く雇い入れる状況でもあるのであれば期待も持てましょうけど、そんな事は絶対に無いです。

十分な教育を受けずに技能を持たないまま現場に向かわされ、出来ずに時間だけが経過してゆく→
教える立場のはずの人間も、与えられた職務をこなしきれない状況が続くので、なかなか後輩の相談にも乗れない→
チームワークを維持し、全体のモチベーションを下げないように、つらい状況でも皆で付き合ってる→
依頼する方もそんな状況はわかってるけど、いろいろと“出来上がった時の”手配はしなきゃいけないから妥協点を下げる→
作りが甘くなるテストが甘くなる仕様が甘くなる取り組み意識が甘くなる→
うそやごまかしが見え隠れする→
そしてついには機会損失してしまい、開発費用が回収できない→
次の開発費用が削られるので単価が高い技術者からさよおなら→
．．．

このデフレスパイラルを何とかするためにIPAが設立されてたと思ったんですけど、それは期待し過ぎだったと思い知らされました。