技術系の新人向けにC言語の研修を外部講師を頼んでやっているのだけれど、ふと、これって海外の企業なら「C言語でプログラムを書ける人」とか「○○のスキルを持っている人」といった採用条件で人材を募集するんだろうなと思った。プログラミングをほとんどやったことない人材を企業で教育してソフトウェア開発にアサインするなんてことやっているのは日本だけじゃないかと思う。自分のスキルや実績を書いておくと、たまに海外の会社のリクルーターからコンタクトがくる。海外の企業はリクルータと契約していて開発に必要なスキルを持つ人材を常に探しているように見える。実際,海外の企業ではクビになる可能性も高いから転職の市場もそこそこ大きいのだろう。日本の企業って、どうして商品開発に必要な知識やスキルがほとんどない状態の人材を採用して、自前で教育するスタイルをずっと昔から変えないのだろうと思う。これまでは専門的なスキルを持っていない新卒生を採用して,企業内で長い時間かけてOJTで育てるという育成方法がよい結果を生んできたのだろう。今となっては,また,特にソフトウェア技術者の採用としてはそのスタイルにはデメリットも出てきたと思う。日本の企業の人材採用に関する歴史的な背景としては,企業側は技術者教育に金がかかりしばらくは即戦力にはならないが、ある程度年月が経つと、会社の言うことをよく聞く汎用的で一定の給料で使い倒すことのできる技術者を確保できる点でメリットがあったし,日本の新卒生は勤勉で我慢強い気質を持ち、不足している技術、スキルはある程度自前で習得できるポテンシャルはあるので使い勝手はいいのだろう。企業内で技術者が成長する過程で、技術、スキルの差は出来てくる。日本では、そこに給与の差を付けることなく年功序列の給与体系で技術者を使えるので、製品開発における人件費の総額を技術的な実現可能性の難易度は無視しても,人月勘定で見積もることができる。不足する人的リソースはソフトウェア系の外部協力会社を使ってこれも人月勘定で補えばよい。このやり方はそろろそ無理が出てきたように思える。技術者サイドから見ると、日本の採用スタイルなら簡単にクビにされることはない(今の時代はどうなのかなあ)ので、安心して働けるが、その反面,技術やスキルが秀でていたとしても、その能力が平均的なサラリーの2倍とか3倍とかにはならない。古典的な日本の企業では技術的な優越がサラリーや待遇で評価されることはあまりない。(外資系とか最近のIT企業は違うのかもしれない)この日本的採用スタイルの最大の問題は、その組織に足らない技術やスキルがあったときに、それを自前の技術者が習得するには時間と費用がかかる、あるいは、外部からその技術やスキルを持ってくるのにコストがかかるということについて組織の上位の人達がピンと来ないことではないだろうか。足らない技術やスキルがあると、自前の技術者に「習得しろ」と命令すれば、何とかなるもしくは,足らない技術やスキルを外から「人を含めて外から買う」という概念はないのかもしれない。それは今の経営層が「自分はそうやって製品開発を成功させてきた」という成功体験があるからだろう。昔と今で、必要な技術やスキルの質や量の差を理解していない。これだけ製品のソフトウェアが大規模、複雑化し、機器がネットワークでつながるようになると、システムを実現するのに必要な技術、スキルは多様化し、それらを全部自前で習得するのは難しい。必要に応じて技術そのものを外部からパッケージで買ったり、技術やスキルを持った人材を「買う」必要がある。技術やスキルを「買う」ということに慣れていないし、そのための予算も取っていない。その代わり一人月いくらで何人月ぶんならこの開発に使ってもいいという、人月勘定の予算の取り方はする。技術やスキルによって、必要な予算が異なるという感覚は乏しい。その結果、製品開発を成功させるためには、不足するスキルを短期間に習得できるポテンシャルの高い人材がオーバーワークになりながら頑張るという状況に陥る。優秀な人材であればあるほど、抱える仕事量が多くなり疲弊し,職場のモチベーションが下がっていく。ものつくりのエンジニアにとって日本は社会主義国家のようだ。がんばっても、がんばらなくてもサラリーはあまり変わらない。日本で高度プロフェッショナル制度が広まるとさらに、日本のエンジニア社会主義がさらに加速するような気がする。エンジニア社会主義は安心して働けるし、企業が技術者を教育してくれるのでいい面もあったが、技術が多様化して分業しなければシステムを開発しきれなくなってきた現在では、デメリットの方が大きくなってきたように思う。簡単にクビにならない環境は確かに何者にも代えがたいメリットのように思える。ビズリーチのような企業が売り上げを伸ばしているのならば,人材がプールされあちこちの企業でスキルを買って不足を補うような市場は日本でも醸成されつつあるのだろう。一度採用した人材を使い続けるのが日本の企業のスタイルというのならば,これだけ製品開発に必要な技術が多様化した今日では,企業はその技術を習得させるための予算を通常の開発費とは別に予算計上する必要があると思う。見積りしにくいだろうが,その予算がないと結局は開発が遅延したり,失敗プロジェクトになったりする。日本の企業が技術者を雇用し続けるスタイルを貫くのならば,新しい技術を教えられる人材を確保し,その能力を評価するようにするべきだと思う。ようするに教えられる人材,特にその企業のコアコンピタンス(競合他社に真似できない核となる能力)を身につけさせることができる人材や,新しい技術を教える教育コンテンツや教えられる人材を積極的に確保し逃さないようにするべきだ。日本の企業は,何でもOTJで伝承するのが職人としての美徳のような感覚があるようだが,システマティックにトレーニングして,できるようになったかどうかをテストして,資格を与えるといったことを組織的にやっていかないと,必要なスキルが見えず,知らぬ間に企業の技術力がほとんどなくなっていたということになりかねない。エンジニアサイドからすれば,個人商店として自立できるくらいの技術力を身につけるようにし,組織サイドからすれば,製品開発に必要な技術やスキルを整理し,技術を身につけさせるスキームやトレーナーの人材を確保する。これをやらないと,次の世代の製品開発は立ちゆかないのではないか。ソフトウェアプロジェクトを組織するときに○○のスキルを持った人を何人、△△のスキルを持った人を何人といった集め方をするか,○○のスキルや△△のスキルを教育するのに□□万円の予算を確保するといった形にしないと作りたい物が作れない時代になってきたのではないだろうか。(Atom)組込みソフトウェア工房へようこそ本ブログサイトでは技術を磨き、組織を通じて顧客満足度を高めたいと考えるエンジニアを応援します。*注目の投稿ソフトウェアアーキテクチャとは何かを考える最近,協力会社に開発を任せていてソフトウェアの中身が分からず,意図した動きにならない(レスポンスが遅いとか,画面が思ったように遷移しないとか)という話を聞いた。,「ソフトウェアを継ぎ足し続けた結果,肥大化・複雑化して,原因を追及しにくい不具合が発生して困っている。「最初に読んで欲しいこと。英和対訳版が手元に届いた。こだわっている理由を書こうと思う。自分は医療機器ドメインのソフトウェアエンジニアとしてのキャリアが24年である。特集記事『クルマの電子安全始まる-ISO26262を越えて-』を必ず読んでほしい。26262の世の中の動きをウォッチしていくこと自体にいささか疲れてきた。言って、本当にユーザーのことを考えて安全や安心を実現したいのなら、自動車業界の規格適合に関する浮かれた熱が冷めるのを2~3年待った方がよいと考えるようになってきた。機能安全に群がる商魂...安全を売りにするな!安全を食いものにするな!最近、どうしてもペンを取りたいと思わせることが二つ起こった。ひとつは、マツダの安全装備の体感試乗会で起きた「CX-5」の事故で、もうひとつは2007年に起こったトヨタの急加速事故に関するトンデモ検証記事だ。』(渡辺健介著)という本を読んだ。いつものように、まえがきを紹介したいと思う。壁に直面したとき、自分の...レクサスのパワーステアリング不具合の原因分析についてトヨタ自動車は19日、ハンドルが一時的にタイヤと連動しなくなる不具合があるとして、レクサス4車種のリコールを決めた。今回もプリウスのときと同様にソフトウェアの複雑性が絡んだ問題のようだ。リスク分析、リスクアセスメントについての話題である。イントロダクションを読む自分は組織内で次の(2)の立ち位置にいる。プリウスのブレーキ制御問題について、これまでになく詳細な情報が掲載されており、問題がなぜ起こったのかを推察できるからだ。日経もの...自己紹介sakai1987年よりクリティカルデバイスのソフトウェア開発に従事する。16bitのワンチップマイコンを使った信号処理、リアルタイム組込みシステムの開発を行い、商品の仕様立案からソフトウェア開発のプロセス管理、プロジェクトマネージメント、安全性・信頼性の検証、保守、ソフトウェア技術者教育など組込みシステム開発に関する幅広い領域を経験する。オブジェクト指向設計やプロダクトライン戦略を商品開発に生かすことも試みる。商品開発を常にアーキテクトの視点から分析し、「具体から抽象へ」というアプローチにこだわる。)に、2011年より組込みソフトウェアギルドに参加している。