新人と就活

今年の新人達がプレゼンするのを聞いた。ものすごくうまい。本当に信じられないくらいうまい。最近は個人情報ということで、どの大学の何を専攻してきたのか、学卒か院卒かも公開されないからプロフィールがまるでわからないが、プレゼン慣れしているのは確かだと思う。

あまり人前であがらないというのは現代的な特徴かもしれないが、観客が自分をどのように見ているのかを客観的に把握できているように見える。

就活で鍛えたのだろうか？　最近の就職は非常に狭き門となっているらしく就職を控えた学生の諸君は大変だという話しをよく聞く。

『内定の出ない学生は何が間違っているのか～学生、企業、大学、親がすれ違う悲惨な現状』を読めば大変な現状が分かる。

しかし、日本の企業はどうして「新卒」にこだわるのだろうか。これまでずっと同じシステムでやってきたから、いまさら変えることに不都合があるのか。能力主義、成果主義に切り換えたといいながら、実は年功序列が実態なので新卒という枠を外すと問題が生じるのだろうか。

日本の企業は大学、新卒とう枠を設けることで、自分達が欲しい人材がどのような人間であって欲しいか考えることから逃れていると思う。

ようするに新卒であれば世代という観点では同じ評価指標で考えられる。その土俵で人選すれば選びやすい。ところが、新卒という条件を外したら、もっと評価指標が増えるし、また、どのような人材を求めているのかをもっと明確にしなければいけない。

その組織にあった人材ということだけではなく、今、不足している、これから始めようとする事業に有効な能力、ポテンシャルを持った人材を選らばなければいけなくなる。というよりは選べるようになるのだ。

キャリア採用と似ているが、キャリアは十分ではないだろうから、人材を必要とする事業やプロジェクトに投入する際にポテンシャルの高い人を探さなければいけない。今まで以上に人事部門が事業部門と情報を共有し、どんな人材が必要か常日頃からディスカッションしておかねければいけない。

新卒しか採用しないのは、人事部門が新卒という枠でしか技術者を評価できないからではなだろうか。

その組織に、その事業に、そのプロジェクトに必要な人材がどのような者か、どのようなポテンシャルを持っているべきかを考えられるようになれば、新卒にこだわる必要がない。

ちゃんとそのコンセプトを示し、いろいろな経験をした広い範囲から人材を選べるはずだろう。

プレゼンがうまいのがもしも就活のために訓練したのであれば、それもよいが、エンジニアとして組織が求めているポテンシャルが高いのかどうかはそれだけでは分からない。

就職する側の企業が変われば、大学の姿勢や受験も変わるのではないかと思う。現在の就職状況では、一芸に秀でた人材が埋もれてしまわないか、日本ではチャンスは新卒の一回しかないのかどうか心配になる。

練習が必要なのはオリンピック選手だけじゃない

バンクーバーオリンピックでは数々の名勝負が繰り広げられた。なかなか見応えがあったが、選手のみなさんがこれまでさぞたくさんのトレーニングを積んできたに違いない。

スポーツは練習しなければうまくならない。スポーツだけではない。人間がやるもの何でもそうだ。知識労働者だって知識だけ知っていれば仕事ができるとはいえない。特にソフトウェアエンジニアがスキルアップするに繰り返しの練習が必要だと思う。

そう考えるとソフトウェアエンジニアがスキルアップしていく様があるとすれば、それはスポーツ選手が技術を身につけていくのに似ているような感じではないかと思う。

どんなスポーツだって練習しなければうまくならない。そして才能のある選手には必ず優秀なコーチがつく。コーチは科学的な理論に基づいてどうやって選手を育てていけばいいのか考え、いろいろなトレーニングメニューを組み立てる。選手が出す成績にもとづいてトレーニングメニューを変えたりもする。

ソフトウェア技術者の教育も同じではないか。優秀なエンジニアに育て上げるには優秀なコーチが必要だ。また画一的なトレーニングではなく、選手一人一人に合わせたトレーニングが必要だと思う。

今、ソフトウェア技術者を取り巻く世界では選手とコーチと練習という環境ができていないのではないだろうか。

選手はいつだって自主練習のみ。自主練習どころか練習する時間も取れない。また、コーチは外部コーチで何人もの選手を一斉に面倒みるため、選手の個性に合わせたトレーニングメニューを用意することはできない。

よく、OJT(On the Job Training）が大事というが、OJTというよりは、スキルが身につくまで繰り返しの練習をさせる環境が必要なのではないかと思う。よい練習問題を用意して、繰り返し繰り返し練習するのだ。プログラミングでもモデリングでもよい。同じような問題を繰り返しながら自分の血となり肉となるまで鍛錬する。人間の脳は一回教えただけで修得できるようなしくみにはなっていないのだ。（これは精神も肉体も同じ）

繰り返し練習をする時間はないとあきらめてしまうか、いろいろとやりくりして時間を作るかは遠い将来にメダルを獲得した自分や自分が育てている選手の姿を思い浮かべることができるかどうかで決まる。

ソフトウェアエンジニアもスポーツ選手と同じでハングリーな選手と実戦経験を積んだよいトレーニングメニューを持ったコーチが出会って初めて優秀な成績が残せるような気がする。

就職氷河期をブレークスルーすための就活作戦

日経ビジネスオンラインの時事深層というコーナーに『6万人の「大学は出たけれど」』という記事が載っていた。

【日経ビジネスオンラインの時事深層　『6万人の「大学は出たけれど」より引用】

「誰でもいいから欲しい」終焉

　厚生労働省の調査によると、来春卒業予定の大学生の就職内定率は、10月1日時点で62.5％と昨年の同じ時期に比べて7.4ポイント低下。3人に1人の就職先が決まっていないことになる。

　ところが、リクルートワークス研究所が調べた大卒者の求人倍率は1.62倍。求職者を求人が上回る状況が続いている。求人倍率が1を切った2000年3月卒業生の採用時でも、同じ時期の内定率は63.6％と、今年よりわずかながらも高かった。

　求人はあるが内定率は低いーー。これは何を意味しているのか。

　日本企業が「質」による学生の選別を強めていることが背景にある。「企業を引っ張っていける優秀な人材しか採らない」ことを示している。

【引用終わり】

ようするに、不景気なので採用側の余裕がなくなり、長い間従業員を抱え込む日本の企業においては、どうせ採るならより後々組織に大きな貢献をする学生だけを採ろうと考えるようになったのだ。

そうなったら、もう競争だ。ここで学生のみなさんにアドバイスしたいのは競争は就活の期間だけではないということだ。

そこで、「もし、自分が超就職氷河期の時代にいる学生だったら、どんな作戦を取るか」について考えてみた。

まずは、企業がどんな人材を欲しているかである。日経ビジネスオンラインの記事を読むとどうも「即戦力」が欲しい訳ではなく、将来組織の幹部になってもおかしくないような人材を採ろうとしているということだ。技術者の場合は、少なくとも技術部長クラス、技術でその部門をリードしていけるような人材ということだろう。

ただし、ソフトウェアエンジニアの場合は技術的に修得しなければいけないことが満載だから、学生が就職試験を受ける時点でそれらの技術を身につけている可能性はほとんどない。

組織内で技術者教育を提供する立場から考えると、学んで欲しいスキルは山のようにある。

• プログラミング言語（C, C++, C#, Java)
• テスティング基礎
• 設計プロセス
• リアルタイムOS
• 状態遷移設計
• 構造化分析・設計
• UMLモデリング
• オブジェクト指向設計
• リファクタリング
• ネットワーク
• データベース
• セキュリティ
• プロジェクトマネジメント

などなど。これらを学生時代に修得しておいてくれというのは無理だし、これらの技術は実際の仕事でどんなフェーズで何をやっているのかをよく見極めながら、現状の問題解決に必要な技術を習得させていかないと身につかないと思っているので、実践に入ってから学習した方がいいものも多いと考えている。

このような状況を考えると採用する学生に求めるものは何かということになる。

ひとつは、その組織が対象としている市場・ドメインに対して強い興味、関心を持っているかどうか、ふたつめは技術をスポンジのようにどんどん吸い込むポテンシャルがあるかどうか、三つ目はそれらの技術を組織内に展開できるかどうかだと思う。

3つめは技術リーダーになれるかどうかという指標なので、まずは置いておいて、ドメインへの関心とポテンシャルがあるかどうかについて考えてみたい。

ドメインへの関心は面接の際に趣味や質問攻勢によってすぐに分かってしまうだろう。面接官は企業ドメインのことを裏事情も含めて学生の何十倍もしっているから、知ったかぶりしてもすぐにばれてしまう。2チャンネルなどで情報を収集しようとしてもそのような薄っぺらい情報でやり合おうとするとかえって墓穴を掘る。となると、学生時代は好きなものをとことん追求するのがいいと思う。自分が熱中したことと、就活先の企業ドメインとの関係性が何かについてだけ抑えておいて、そこを説明し、メインは自分が何に集中したのかについて語るという作戦だ。（何も熱中したことがないのはその時点で難しい）

２つめの技術を吸収するポテンシャルがあるかどうかの判断は、履歴書や面接ではなかなかわからないしアピールするのも難しいと思う。そこで、自分が考えたのは学生時代に自分の成長のブログを作るという作戦だ。

例えば4年制の大学生なら2年～3年になったころから、自分の興味があることに対してどんな取り組みをしてどんな成果があったのかをブログに綴ってみるのだ。毎日でなくても毎週、もしくは月に2～3回でも更新を続け、どんなことに取り組み、どんな成果があったのか、何を反省しつぎに活かしたのかを写真や動画を入れて書いていく。

それって卒論、修論と同じだというかもしれないが、大学の先生の指導が入っていないぶんブログの方がその学生の実力がわかるし、日々の記録だからごまかしやうそ、見栄が効かない。その人の人生や姿勢が見える。

そして、そのブログの URL を人事担当に送るのだ。人事担当は技術のことが分からないから、採用を希望している部門の技術部長クラスあたりに打診するのではないかと思う。自分なら、そのブログをざっと見ればその人がどんな人間でポテンシャルがあるかないかをだいたい判断できると思う。

文章がだんだんうまくなているかどうかも指標の一つになる。ようするに一夜漬けではごまかせないレポートだと思うのだ。

以上、自分の成果をブログに書いて就活に活かすという作戦いかがだろうか？

ちなみに、転職を考える技術者も内部情報を出さずに純粋にどんなスキルを獲得したかを綴るブログを書きためておくと自己アピールに効果があるかもしれない。

『問題解決能力（Problem Solving Skill)：自ら考え行動する力』の記事も参照されたし。

品質改善に役立つ注目のツール

2009年8月末に発売される 組込みプレス Vol.16 で『品質改善に役立つ注目のツール』 という特集記事をコーディネイトした。

この記事では ソフトウェア品質診断ツール eXquto と アーキテクチャ分析ツール Lattix の2つのツールを比較している。

記事をコーディネイトするにあたって一番気をつけたのは、ツールを使うユーザーの利益が最大になるように情報を提供するということだ。

ともすればツールの紹介記事は売り手側の都合のよい情報だけが一方的に伝えられツールの弱点や有効に使うためにユーザーサイドが負うべき責務は隠されてしまうことがある。

そこで、今回の記事では、何十万円もするツールの購入は組織に対する投資と位置づけ、なぜ、そのような投資が必要なのかという前提条件について、まず、解説し、次に2つのツールのベンダー及びパートナーに、ツールの特長を紹介してもらい、最終章でツールを現場で有効利用するためのヒントを書いた。

【記事をコーディネイトしようと思ったきっかけ】

eXquto はソフトウェア品質診断ツール、Lattix はアーキテクチャ分析ツールで、どちらも現在あるソフトウェアシステムをよりよくするための道具である。1980年台、1990年台、ソフトウェア工学はどのようにシステムを分析設計するのかに注力を注いできた。リファクタリングという取り組みはあったものの、リファクタリングはどちらかと言えば、プログラマが個人の範疇でソフトウェアを再構築することを指していたと思う。

しかし、組込みソフトウェア開発の現場では、試行錯誤を繰り返しすでに30万行を超え、100万行を超えるようなソフトウェアを作り込んでしまっていた。

経済産業省 2008年度版 組込みソフトウェア産業実態調査報告書によると、平均的な組込みソフト開発のモデルは次のようになる。

• 組込みソフト開発費：1200万円～3000万円
• 使用開発言語：C言語
• システム規模：20～50万行
• 新規開発行数規模：2～5万行

実際のソフトウェア開発では、新しい製品開発であっても20～50万行のソフトウェアをゼロから作ったりはしない。すでにある既存製品の大部分を使い、それらの10%程度のソフトウェアを新規に作成する。

それはかなり泥臭い世界であり、すでに作り込んでしまったぐちゃぐちゃのプログラムも嫌々ながら使い続けなければいけないのだ。形式手法を使って仕様とプログラムの関係の完全性を証明できるような取り組みができるのはほんのひとにぎりの開発に過ぎない。

情報工学の研究者達はこのようなすでに作り込んでしまった相当な規模のソフトウェアをきれいにするというエンジニアリングについて有効な方法論を考えるのが苦手だ。苦手かどうかのバロメータは彼らの研究が現場にどれだけ近いか、現場とともに問題の解決に取り組んでいるかどうかで分かる。

我々は、ソフトウェア開発の現場と研究者の距離が縮まることを待っているほど余裕はない。だから、2000年台は、ツールを使ってすでにあるシステムを分析し、捨てるのか、再構築するのかを判断する基準を作っていく必要がある。

【記事のメイキング】

今回はまず最初に組込みプレス編集部に企画案を提示し、了解を得て、eXquto の開発元である(株)エクスモーションさん販売もとの(株)東陽テクニカと、Lattix の販売元のテクマトリックス株と Lattix を使ったコンサルテーションを実施している イーソル/RCS の双方に記事の企画を打診した。幸い、双方からOKの返事をもらったので、イントロは酒井、eXquto の紹介記事はエクスモーションに、Lattix の紹介記事は テクマトリックスとイーソル/RCS に、まとめを酒井が書くようにした。

イントロでは経済産業省 2008年度版 組込みソフトウェア産業実態調査報告書のデータをもとに、どのような開発で今、何が求められているのか、ソフトウェア開発の効率化、品質向上にはどれくらいの投資がふさわしいのかを書いた。

ツールの紹介はそれぞれに同量のページ数ぶん書いてもらい、比較表は酒井が原案を作って双方に提示し、それぞれ修正を繰り返すことにした。比較表はツール屋さんに取ってはもっともシビアな部分であり結果的に延べ20回の修正を行った。

そしてまとめの部分は、酒井がユーザーの目線でツールを宝の持ち腐れにせず、有効利用するためにはどのような覚悟が必要か、どれくらいツールメーカー、ツールベンダーと真剣に対峙する必要があるのかを書いた。ツールに対する注文も書いたためツールベンダー、ツールメーカーとぎりぎりの調整も行った。

この特集記事の最後に「ツールを宝の持ち腐れにしないためには」について書いたので是非読んでいただきたい。

【品質改善に役立つ注目のツール 第4章 ツールを現場で有効利用するためのヒントより引用】

■ ツールを宝の持ち腐れにしないためには

　この特集記事を読んでいただいているソフトウェアエンジニアのみなさんによく考えて欲しいのはソフトウェア開発は基本的にはソフトウェアエンジニアの日々の活動の成果の積み重ねであり、ソフトウェアエンジニアの頭の中で考えたことが最終成果物になるということです。ソフトウェア開発で何か状態を変化させるということは、すなわちソフトウェアエンジニア自身（正確に言えばエンジニアの頭の中）がある状態から別の状態に変わるということなのです。したがって、自分自身が変わる気はさらさらなく、ツールが問題解決のソリューションを提供し、ツールを導入するだけで成果物がよい方向に変化してくれるはずだと考えているとたいてい失敗します。

　ソフトウェア開発を支援するツールには何らかのソリューションが隠蔽されているのは確かです。しかし、利用者はそのソリューションがどんな問題を解決するのに有効であるのか、どのようなケースの問題解決に向いていて、どのようなケースの問題解決は苦手であるのかを理解する必要があるし、場合によっては自組織や開発製品に合わせてツールの使い方をくふうしたり、ツール自体をツールメーカーやツールベンダーにカスタマイズしてもらったり、改善してもらわないといけないこともあります。

　品質改善に役立てる目的で販売されているツールは、そのツールを使うことで実システムの品質改善やアーキテクチャ改善ができなければ、導入してもまったく意味がありません。今回紹介したツールベンダー、ツールメーカー、コンサルテーション会社は筆者がみな個人的にも付き合いがある会社です。ユーザーサイドが自分のプロジェクトやソフトウェアシステムの改善を本気で取り組もうとしているのならば、彼らも途中で投げ出さずに付き合ってくれることは分かっています。ツールベンダー、ツールメーカーはすべての組込み開発の現場を知っているわけではありません。彼らのセールストークを信じてツールを購入し改善が進まないのなら、何が問題なのかを彼らに伝える義務がユーザーにはあると思います。そのようなユーザーの意見をフィードバックするからこそツールメーカー、ツールベンダー、ツール自体がよりよく進化していくのです。

　ツールを宝の持ち腐れにしないためには、ツールが持っている効果、効能を正確に判断し、長くつきあえる正直なツールメーカー、ツールベンダーを探し、壁にぶち当たっても簡単にあきらめずに、ツールとともに彼らと長くつきあう覚悟で改善を進めることです。それができないプロジェクトや組織はせっかく購入した高価なツールをいずれは放置し腐らせることになります。ツールを選ぶ確かな目を育てるには、失敗の経験を積むことも必要ですが、失敗の経験はできるだけ影響の小さい範囲で積み重ねて、百万円クラスのツール選択では失敗のないようにすることが大事です。

【引用終わり】

貴重な情報ソースから見る「企業が学生に求める能力」

支援部門にいると組織に動いてもらわなければいけないときに提案書に相当するものを作る必要が出てくる。組織上位層と価値観を共有するためには、プレゼンテーションの資料に次のような内容を入れておくとよいというのもだんだんわかってきた。

1. お金の話し（○○をやらないと損失が大きい、△△をやると利益が上がる）
2. 他社、世の中のトレンドの話し（××社はこんなことやっている、世の中では＊＊が常識）
3. お客さんの話し（ユーザーがこのような不満を持っているから解決する必要がある）
4. 現場の話し（開発の現場では、○○のようなことが起こっており、△△をしないと開発期間が縮まらない）
5. 品質の話し（○○の指標でソフトウェアの品質が低下している。△△をして品質を向上する必要がある）

そんなこんなで、コンサルタントを生業にしている人たちが日頃どんな情報にアンテナを張り、上記のような話しをサッとプレゼン資料に盛り込めるようにしているのか何となく分かってきた。

人や組織を動かすとき、説得に使う情報はかなり重要だ。ソフトウェアのことを詳しく知らない人が財布と権限を握っているケースはハードウェアを扱う組込み系の企業には多い。この人たちを動かしていくには、ソフトウェアのことを相手が分かることばで説明し、かつ、相手の価値観に合わせて「それを今、実行することが必要である」と考えてもらわなければいけない。

そのために必要な情報ソースはいろいろあるが、今回は google でも引っかかりにくいが、かなり役に立ちそうなネタもとを見つけたので紹介しようと思う。

それは、社団法人 日本機械工業連合会（JMF: 日機連）のWEBサイトだ。ソフトウェアとは全く関係ないようでいて、実はそんなことはない。

日機連は、毎年度調査事業を行っており調査事情の報告はPDFで公開されている。工業会の調査報告など対した内容ではないだろうと思うかもしれないが、日機連の調査報告書は価値が高いことに最近気がついた。

その理由は、（推測によると）スポンサーに競輪とオートレースがあることが大きいと踏んでいる。要するに潤沢な資金を持つスポンサーが社会貢献のために日機連を通じて調査事業の費用を肩代わりしているのだ。そして、日機連が窓口になっていろいろなテーマについてさまざまな専門家を集めて200ページ以上の報告書を作成する。

報告書の作成にはその道のプロが仕事を請け負うことが多いが、調査をするのは各種の専門家であり、一般的な講演等では表に出てこない資料が報告書に載ったりすることもある。

試しに、日機連の調査報告書のページで平成15～18年度の報告書について「ソフトウェア」というキーワードで検索をかけてみた。

そこで、まずビビっときたのは『平成1 8 年度サービスロボット運用時の安全確保のためのガイドライン策定に関する調査研究報告書 』だ。普通企業は、ノウハウが少しでも含まれているような資料は一般にプレゼンテーションすることはあっても資料として公開することはめったにない。特許で権利が保護されているといっても、真似されたことを証明するのは困難だからである。

しかし、この報告書では National 屋外用自律走行型掃除ロボット SuiPPI の安全確保の構造について説明された資料がかなりくわしく掲載されている。さらに、滅多に資料が公開されることのない TOYOTA の資料「医療用介助ロボットのロボット運用に向けた安全確保に関するもの」も掲載されている。本業に関するものではなく、未来の事業について企業間を越えてディスカッションした内容だから公開OKとなっているのだろう。（その他 ALSOKのガードロボの情報も載っている）

今回、話題にしたいのは、この報告書のことではなく、『17高度化-13 ものづくり中核人材育成に関する調査研究報告書』のほうだ。ものづくり中核人材育成だから、その中に組込みソフトエンジニアも含まれている。

企業が求めるビジネス基本能力

項目/グループ	大学卒	大学院卒	短期大学卒	専修・専門学校卒
熱意・意欲	71.7	64.0	68.6	66.4
専門知識/研究内容	14.2	34.6	6.3	18.4
協調性	29.6	23.7	43.0	38.4
創造性	15.5	18.5	6.6	8.8
一般教養・教養	5.6	3.3	16.5	10.4
表現力・プレゼンテーション能力	21.5	17.1	14.0	13.6
実務能力	2.1	2.4	19.0	16.0
課題発見力	7.7	10.4	9.1	10.4
問題解決力	15.5	18.5	10.7	10.4
判断力	2.6	1.9	3.3	4.0
（学業以外の）社会体験	1.7	0.5	2.5	0.0
コンピュータ活用能力	1.3	0.9	4.1	4.8
論理的思考力	27.5	29.4	11.6	15.2
行動力・実行力	49.8	40.3	34.7	38.4
国際コミュニケーション能力	7.7	4.7	1.7	0.8
常に新しい知識・能力を学ぼうとする力	16.7	17.1	16.5	16.8
その他	6.9	7.1	10.7	9.6
回答(社数）	233社	211社	121社	125社

このデータ以外にも興味深い情報がたくさん載っているレポートなのだが、まずは是非これを見ていただきたい。企業が学生に求めているものは、「熱意・意欲」「行動力・実行力」「協調性」であり、次いで「論理的思考力」「表現力・プレゼンテーション能力」「常に新しい知識・能力を学ぼうとする力」「問題解決能力」「創造性」だということが分かる。

どこをどう見ても、小・中・高・大という長い14年の教育の中で子供がテストで評価されてきたものではない。本ブログサイト人気の記事『問題解決能力（Problem Solving Skill)：自ら考え行動する力』は、おそらく学校では授業で教えていないが、少なくともコンピュータ活用能力よりは期待されている。

先日、NHKのクローズアップ現代で超氷河期と呼ばれる就職最前線で、企業がどのように学生をテストしているのかを紹介していた。テストとか面接とかそんなもんではない。今や、学生は面接で聞かれたときにどう答えると印象がよくなるのかをあらかじめシミュレーションしている。自分に能力があってもなくても、上記のようなことを期待されているのは分かっているから、その期待に添うことができるという回答をきちんと用意している。

そして、企業側も学生がそんな準備をしてきていることを知っているので、面接の受け答えを最重要視はしない。何をやらせるのかというと、例えば営業職ならば、商品の売り込みのロールプレイングをやらせるのだ。「実際に売ってみろ」と突き放し、「現場で問題が起こったとらどう行動するのか」を見るのだ。企業は人材を育成する時間と費用をセーブしたいと考えており、すぐに使える即戦力を欲しがっている。需要より供給の方が大きいから、応募してきた学生の中から、上記の表の能力を潜在的に持っている学生を選ぼうとしているのだ。

学生の方はたまったものではないだろう。テストでよい成績を取り、偏差値で評価されてきた評価指標とはまったく異なる土俵で勝負させらるのだ。

上記の表が示しているのは、画一的に教えられている勉強とは別に、自分で好きなものを見つけ、熱意意欲を持って探求し、問題が起これば課題を発見し、論理的思考力を使って問題を解決し、プレゼンテーション能力を活かして、協調性を持って創造力を使う訓練をしておけということだ。

こんなことができるスーパースチューデントは滅多にいないから、会社に入ってからも、これができるように訓練しておく必要がある。

組織内ではだれもそれが必要なんだよと面と向かって教えてくれないが、全体を見渡せる人が潤沢な資金を使って調査すると、実は組織がどんな人材を求めているのかがわかったりするのだ。

エンジニアに投資しない組織にいて成長するには

エンジニアに投資しない、投資できない、投資する必要があると考えない組織はそこら中にある。技術者への投資がどのように組織にフィードバックされるのか、人材を育てることに金や労力を使わないと組織がどのようにやせ細ってしまうのかイメージできない人に技術者への投資を提案するとそれにかけた費用に対する効果を説明せよと言われる。そこで「分かってないな」と思うのは当然だが、だからといってエンジニアへの投資をあきらめてはいけない。

ソフトウェアエンジニアは100%知識労働者である。「プログラムコードを何行書いてなんぼ」などと考えていると、すぐに優秀なコンパイラやツールに仕事を奪われてしまう。新しく入っている若い世代のソフトウェアエンジニアが持っていないスキルを常に身につけていかなければいつの日か組織からいらないと言われる日がくる。

組織の中で誰からも計画的なスキルアップの道筋を提示されないエンジニアは辛いが、心配しなくてもいい。ほとんどの技術者がそんなものだ。小・中・高・大おまけに塾では手取足取り何を勉強すればいいのか、次は何に取り組めばいいのか、四六時中先生や親がかまってくれたが、社会人になるとそのようなケアは激減する。そのような環境に計16年もいれは、社会人になっても新人教育のアンケートで「もっと教育を提供してください」「まだまだ教育が足りません」と書いてくるのもうなづける。新入社員研修が終われば、ほとんどの組織では後はOJTで何とかしろと突き放される。ソフトウェアは周りから何やっているのか見えないから、自分で「ここが分かりません」とか「ここはどうやったらいいのでしょう」などと積極的に聞いていかないと、「どれどれ苦労しているようだね」と誰かが声をかけてくれる確率は低い。そして、どんなに未熟な技術者でも何百回も試行錯誤でプログラムをいじくり回していればいずれ動くようになる。実は、それが一番怖い。中身ぐちゃぐちゃで、すべてのテストケースを検証しておらず、爆弾入りのプログラムがひっそりとソフトウェアシステムの中にビルトインされてしまうのだ。

新人の時期を過ぎればソフトウェアエンジニアは教育という側面から見れば孤独だ。それまでの人生と比べてその突き放され感にショックを受ける者もいるだろう。

技術者教育を計画できない、実施できない自転車操業の組織にいて、それは自分が悪いのではなく組織が悪いのだと考えるのは簡単だが、残念ながらそのままほおっておいても何も変わらない。学校や塾のように成績が悪くなると家庭教師を付けてくれたり、「もっと勉強しろ」と尻を叩いてはくれない。ETSSというスキルのものさしでエンジニアのレベルを計測し、それによって弱いところをトレーニングするという取り組みは始まっているが、それができるのはエンジニアに投資できる組織であり、今回と前回の記事の対象外としている。（これを実行するには人・モノ・金がいるから大企業で儲かっていないと難しい）

技術者に投資しない、投資できない組織はたくさんある。そのような組織の中で技術者が何もしないでいると、ソフトウェアに依存する組織の業績はじりじりと下がり技術者に過度な負担がかかるようになる。このような状況でも組織が生きながらえていられるのは次のような原因があると考えられる。

1. ソフトウェアエンジニアの需要が供給を上回っている。（不景気な今もそうだろうか？）
   
2. その組織、そのプロジェクト、その技術者しか知らない、対応できないドメイン知識を持っているから切られる心配がない。（組込みの世界ではよくある話し）
3. 過度な負担（例えば残業月100時間以上とか）に対して技術者がまだ耐えられるレベルにある。

1と3は放っておけばいつかは破綻するときが来る。問題は2だ。2は実際かなりのアドバンテージであり、曖昧な仕様でしか仕事を出せない組織では特に特定の技術者に蓄積されたドメイン知識や経験は重要であり、このような人に頼った製品開発が行われことは多い。しかしながら、そのアドバンテージは永遠には続かない。

製品に使用されるハードウェアデバイスの使いこなし方や商品にまつわるドメイン知識だけで生きながらえているソフトウェアエンジニアは、大規模ソフトウェアシステムを効率的かつ品質高く開発する技術を持ち合わせていないから、いつの日か破綻するときがくる。ドメイン知識と試行錯誤のアプローチで開発できるソフトウェアシステムの規模はだいたい決まっている。自分の経験では実行コード行数で30万行を超えてくると、何かしらのソフトウェアエンジニアリングの技術を使わないと品質を確保できなくなってくる。

よって、どのようなソフトウェアを作っていたとしても、いずれはソフトウェアに関する設計、検証の技術は身につけなければソフトウェアエンジニアに明日はない。日本で今若い人たちがソフトウェア開発技術者に魅力を感じられないのは、自転車操業の組織で試行錯誤のアプローチでしか仕事をしておらずどんどん疲弊していく技術者の噂を耳にするからだろう。

前置きが長くたっぷりと危機感をあおってしまったので、ここからはエンジニアに投資しない組織いて、スキルアップの方策を組織に期待できない場合、どうやって自己投資すればいいのかを考えていきたい。

1. 仕事の中で鍛える

多くの組織がこれ（要するにOJT：On the Job Trainning)で技術者は成長すべきだと考えている。大工の棟梁が弟子を一人前にするという徒弟制度をイメージしてもらえばよい。20年前の組込み機器開発は、メカもエレキもソフトもそうやって技術者は成長してきたし、その経験をしたエンジニアが組織の中でプロジェクトリーダーやプロダクトマネージャや技術部長になっているのだから、そう考えるのは当然といえば当然だろう。

しかし、21世紀の組込み開発において、特にソフトウェア開発において、20年前の徒弟制度的な棟梁と弟子の関係が組織のあちこちで成り立っているだろうか。エンジニアに手取足取り技術を伝承する時間や機会を組織は先輩技術者に与えているだろうか。今ではかなりの割合を占める協力会社のソフトウェア技術者に仕事を丸投げし技術伝承の流れを切ってしまってはいないだろうか。

実際、組織内で伝承するソフトウェア技術が減っている感覚がある。ソフトウェアの世界ではいつの日か技術は伝承するものではなく、技術者が自分で修得するものになってしまったような気がする。

ただ、一部の技術者は自分の仕事の体験から、どうすればうまくいくか、どうすれば失敗しないかという法則を体系化している組織、プロジェクトもある。まったくのゼロからでなくても、書籍や雑誌、友人からのちょっとしたヒントにより有効な方法論を確立できる技術者がわずかながらいる。このように具体的な事象から抽象的な法則（例えば、設計の規範となるコーディングルールの策定や、ソフトウェアシステムをブロック図で表現することなど）を編み出すことのできる技術者はそんなに多くはないがいると思う。こういう改善の気質がある技術者はできるだけ組織の外にもアンテナを張っておいた方が効率がいい。

上記の例では、設計の規範なるコーディングルールのヒントはIPA SEC が副読本としてまとめたものがあるし、ソフトウェアシステムの概観を表す方法としては、構造化分析手法におけるDFDや、オブジェクト指向設計で利用するUMLなどの表記法、ツールがすでに存在している。これらの表記法や分析・設計の方法論は先人が自分たちの経験をもとに構築し、多くの技術者に支持されたものだから、それらに乗っかる、もしくは自組織向けにテーラリングすると、ゼロから構築するよりも早い。

自己投資の必要性を認識したソフトウェアエンジニアが、自己投資の結果をすぐに自分の仕事に結びつけることができればこれに超したことはない。すでにスキルを身につけている先輩や社員が近くにいるのならこれほどラッキーなことはない。スッポンのようにくっついていろいろ教えてもらい技術を盗めばよい。資金がなくても「ありがとうございます」の感謝のことばだけで自己投資できる。「あたたかい人間関係の中のやさしい一員」という特長を持つ日本人の中では、教えを請えば見返りを要求されることなく喜んでいろいろ教えてくれるはずだ。教えた相手がスキルアップしても給料に差が付くようなことはないから安心して技術を教えてくれる。

ちなみに、そのような学ぶべきスキルを持った技術者が近くに見あたらないときは、以降に書く2や3で知識を仕入れて、今の自分の開発に一番役立ちそうなものを上手にピックアップして試してみることが必要になる。このとき、何を持って試してみるかという選択の目がどれだけ肥えているかどうかが成功のカギとなる。ただ、どんなに優れた目利きでも失敗を繰り返して経験を重ねていくので、最初は小さい成功と失敗を積み重ねるように心がけるとよいと思う。いきなり大上段に構えて、高度なことに挑戦するのはやめた方がよいだろう。

2. 本

もっともポピュラーな自己投資の方法は、本や雑誌を読むことだ。ここでは2つだけアドバイスを書いておきたい。一つ目は、問題解決のために買う本や雑誌は同じ分野の違う視点の本を2冊以上用意するということ。ソフトウェア工学は自然科学とは違うので一つの方法が普遍的にどの開発にもどの時代でも効果があるとは限らない。そのことを忘れずに、実際の問題解決に適用する際の可能性の幅を広げる意味でも同じテーマに対して別々の視点があることを認識することは重要だと思う。一冊本命の本を買って、もう一冊は図書館で借りるというのもよいかもしれない。

二つ目は、本や雑誌に書いてあることを、どんな形でもいいから必ず自分の仕事の中で使ってみるということだ。これをしないのなら自己投資ではなく、単なる読書だと思った方がいい。問題解決のために本や雑誌を使わないのなら自己投資の意味がない。流行の手法が解説されている本や雑誌を読んだだけなら、それは単なる自己満足に過ぎない。「○○について書かれた本を読んているのはウチの中では自分くらいだろう」などと思っているだけでは何も解決しない。評論家くんにはなれても問題解決キッズにはなれない。（『問題解決能力（Problem Solving Skill)：自ら考え行動する力』の記事参照）

本や雑誌を買う行為を常日頃、自分が抱えている問題を解決するための自己投資だと考えているとだんだん目が肥えてきて、自分にとって使えない本や雑誌には手を出さなくなる。無駄な投資が減る。仮に購入した本を参考に自分の仕事に適用してうまくいかなかったら投資に失敗したと考えれば、次回は同じ失敗を繰り返さないようになる。本や雑誌の購入が自分に向けての大切な自己投資だと考えていると、投資に成功したときの本と失敗したときの本の違いが見えてくるはずだ。

本や雑誌の書き手側からすると、そういう読者が増えるとライター側もどんどん淘汰されてスキルが上がっていくので、読み手と書き手の両方が切磋琢磨して成長できるのだ。（消費者の目が厳しい市場では技術が成長する）

3. コミュニティに参加する

1で自分の身の回りに高いスキルを持った人がいないときは、自分が抱える問題を共有しているであろう人が集まっているコミュニティを探して、そこに積極的に参加するのも手だ。その中に解決する手段を知っている、解決した実績を持っている人がいる確率が高い。

時間がなかな取れない上に余計な仕事をもらってしまうのがイヤとか、どんな人がいるのか分からないから恐いとか、自組織が認めてくれないという理由で尻込みしているのなら、コミュニティへの参加は自己投資だと考えればよい。2と同じで自己投資にならないと分かったら、あまり迷わずにコミュニティを去ればいい。コミュニティは無理に留まる義務はないところが会社組織とは異なる。

ただ、遊びの集まりではないから、何かしらのタスク、ミッションはこなす必要がある。それらが、自分自身の仕事や問題解決に少しでも役立つと思うのならポジティブにこなしていけば必ずスキルアップにつながる。

例えば、自分はSESSAMEで、WEBサイトの構築を買って出たり、ワークショップのレポートを書いたり、e-Learning コンテンツを開発したりして、結果的にそれらを訓練することになり技術が身についた。一見ソフトウェア開発にはまったく関係ないような事ばかりだが、自組織においてそれらの技術はとても役立っている。

座談会や講演を録音したテープを文字に起こすような作業は誰もがやりたくないと思うかもしれないが、その内容に興味があったり、自分の勉強のネタだったりすると繰り返し聞くことで話している内容が頭の中に刻みこまれていく。

下働きみたいな仕事でも、その中から何か役に立つものを盗んでやろうという目を持っていると、決してその時間は無駄にはならないのである。

さてこれまで紹介した1,2,3の方法はほとんどお金を使わない自己投資の方法だが、セミナーに行ったり、組織のお金でコンサルタントを頼むなど、お金をかけることで高付加価値、高効率の自己投資は可能だし、そっちの方が成功する確率は高いと言える。

でも少ない自己投資でスキルアップという効果を得る醍醐味を一度味わうことができると、問題解決のスキルはどんどん上がる。問題解決のスキルが上がると、自分の仕事を効率化したり、品質を高めたり、より評価の高い組織に移籍するなどいろいろな選択肢を選べるようになる。

自分に取ってどんな自己投資が効果的かこれを期に考えてみて欲しい。

　

組織はソフトウェアエンジニアに投資できるか

このブログで、日本のソフトウェア技術者は試行錯誤的アプローチで組込みシステムのソフトウェアを作ってきたと書いてきた。それでも組込み機器の品質が保たれているのは、日本人に特有の「あたたかい人間関係の中のやさしい一員」という性質と職人気質、そして品質を心配する強い意識があるからだとも書いてきた。

これらの日本人の特性プラス「何かあったらソフトウェアをすぐ修正」という行動によって、日本の組込みソフトウェアは今のところかろうじて高品質を維持していると思う。しかし、これらの状況は、ソフトウェアの規模が小さいことと、日本のソフトウェア技術者が劣悪な環境を我慢（高収入を求めずにオーバーワークに耐えるということ）しているからまだ破綻していないのであって、システムソフトウェアの規模が増大（例えば実行コード行数ベースで30万行を超えるような規模）し、技術者がその過酷な労働に耐えきれなくなってきたときには、組込みソフトウェアの品質と開発効率が著しく低下し始めるはずだ。

もしも、ソフトウェアに関してどうにもならなくなってしまったら、組織はこの状況を打開するためにソフトウェア開発に対して何らかの投資をするしかない。今回は組織がソフトウェア開発（実際にはソフトウェア技術者教育）に投資できるかできないかの境界について考えてみたい。ソフトウェア開発に関して悪循環が始まっているかどうかの指標は、組織がアウトプットしているソフトウェアが結果的に利益を生んでいるかどうかで簡易的に判断できる。どのプロジェクトも利益を出せていないのなら、悪循環のフェーズに入っていると考えられる。利益が出ている商品、製品、プロジェクトと利益がでていない商品、製品、プロジェクトが混在している場合は必ずしも悪循環のフェーズに入っているとは言えない。

何はともあれ、ソフトウェアエンジニアという末端の立場から離れて、自分が経営者になったつもりでこの後の記事を読んでいただきたい。

なお、ソフトウェアは毎日のソフトウェアの活動で構築される。ツールにノウハウを隠蔽することはできるが、ツールを使いこなせるようにするにはトレーニングが必要になるから、結局はソフトウェアエンジニアに対する教育やマネージメント、インフラに対して投資をしなければ、ソフトウェアの品質や開発効率は上がらない。そう考えると、よっぽどの裏技を使わない限り、ソフトウェア開発に対して何らかの投資をしない組織のソフトウェア品質と開発効率は上がらない。

そして、プロジェクトマネージャーより上の立場の者は、まずは、ソフトウェアエンジニアに対する投資を組織からどうやって引き出すかについて考え、それが無理だと分かったとき、もしくは自分自身がエンジニアに投資を進言する立場にない場合は、組織を見限るか、それとも組織に留まって、どれくらい自己投資できるかどうかという方向に考えを切り替えるべきだと思う。

【組織がソフトウェアエンジニアに投資できるかどうかの境界】

1. 儲かっている会社は投資できる

当たり前だが、潤沢に利益を出している会社はソフトウェア技術者教育やツール、インフラ整備、プロセス構築、技術コンサルの導入などに投資できる。人を動かすだけで一見投資が必要ないように見える社内コンサルのような支援部隊を組織するような場合でも、人材を外から引き抜くのにお金がかかったり、現場から人材を外すことで工数の穴埋めをしなければいけなかったりするから投資は必要だ。

儲かっている会社はいろいろな手を打つ選択肢がある。ただ、気をつけなければいけないのは、ソフトウェアに関する投資ははっきりとした効果が見えにくいから、投資が役に立たなかったとしても口先だけで継続的に組織からお金を引き出そうとする人たちもいるということだ。

でも、儲かっている会社はある程度の無駄をしても原資があれば、何かしらの手を打ち続けることはできる。現在のように不況に陥ってしまうと、儲かっていた会社も利益が減ってしまい、ソフトウェア開発に対する投資を絞ってしまう傾向はあるだろう。

2. 儲かっていない組織でも技術者への評価に差を付けることで投資はできる。

利益がそれほどない組織でも、ソフトウェア開発に投資する意志とある程度の金（例えばソフトウェアエンジニア一人に対して年間最低10万円以上）を捻出できれば、新入社員や将来有望な技術者、今後、利益を生むアーキテクチャ（再利用資産を構築できるアーキテクチャ）を設計できるアーキテクトに対して集中的に投資するという方法はある。

アメリカではプログラム言語の書き方を知っている程度のスキルのエントリーレベルのソフトウェアエンジニアの年収は200万円以下だと聞いたことがある。そこから、スキルがアップするにつれて年収が上がっていく。日本も同じようにスキルがゼロに近い新入社員への報酬を減らしたら、優秀な技術者への投資分の数十万円/人くらいは出せるだろう。

しかし、このやり方は日本人にはなじまない。日本では長い間その組織、業務を経験させ、その時間の中で成長させるというところが多い。あえてこれを教育と呼ばないのは、組織的な戦略を持たずに現場に任せきりで、日々の業務をやらせているだけで技術を引き上げようという意志を持っているプロジェクトは多くないと感じているからだ。だから、組織が意識的に取り組む「投資」とOJTという名の実際には何もしていない状態は分けて考えている。

逆に、新入社員こそ組織として投資しやすい対象であるというのが日本の特徴だ。もっと、やってくれと言われることはあっても新入社員ばかり金をかけて不公平だという中堅、ベテランエンジニアはほとんどいない。

ソフトウェアエンジニアの中に年功序列ではなく、スキルの高さによって評価に差をつけて、実際にサラリーに差をつけて、そこから投資の費用を捻出するという方法は、よっぽど組織の上位層に強い意志と決断があって、目指すべきゴールがはっきりしていないとできるものではないと感じる。

なぜなら、日本人の「あたたかい人間関係の中のやさしい一員」という性質は人と人に差を付けるというのをいやがるからだ。自分もあまり好きではない。テストの点数で評価している訳ではないから、何をもって投資対象として選択されたのかについて技術者の中に疑念が生じると「あたたかい人間関係の中のやさしい一員」という性質を活かすことができない。

だから、技術者に格差を付けて集中的に投資する方法は日本の組織ではなじまない。

3. 自分で自分に投資する

組織がソフトウェアエンジニアに投資しない、選択的でも投資できないのなら、自分で自分に投資するしかない。お金をかけようとかけまいと冒頭のような状況でエンジニアに対して投資する気がないのなら悪循環からは決して抜けられない。（誰かがスキルアップするトレーニングを自分に提供してくれる筈だと考えるのは、そうならなかったときにスキルアップできないのは人のせいだと考え自己努力しなくなってしまうから危険だ）

自分自身の投資の仕方については次回の記事に回すとして、もしも、自己投資に成功してスキルアップした時に起きる問題について触れておこう。

何らかの投資の結果、自分のスキルが向上しソフトウェアの開発効率や品質をアップできるようになるとどうなるか。そもそも、組織が投資してくれないので自己投資しているのだから、スキルアップが成功したとしても、組織貢献を明確に示すことができないのなら、組織からの評価を期待することはできない。

自分のお金や時間でスキルアップして、組織貢献を実現できたのに評価されないかもしれないのだ。評価されないどころか、スキルアップして開発効率や品質向上を実現してできた余裕につけ込まれて他人の開発効率や品質の悪いソフトウェアを何とかする仕事を回されてしまう危険性さえある。

これはやりきれない。頑張ってスキルアップした技術者の努力が報われない社会、業界が発展する訳がない。

でも、現実はこんなもんだ。だから、頑張ってスキルアップできた技術者はその組織で報われないことが分かったとき、例えば組織を出てコンサルタントになり、1 の儲かって利益を出せている会社を助ける側に回ることになる。

そうなると、成長した技術者が去ってしまった組織が潤沢な利益を出せていなかった場合は、さらにソフトウェアの開発効率が悪くなり、品質も悪化し、残った技術者が残業することでしか対応できなくなる。

この論理だと、ソフトウェアエンジニアは自己投資でスキルアップしても報われないから、自己投資しないでじっとしていた方がいいのかということになってしまう。

そんな筈はないから、こう考えるしかないと思う。

組織がエンジニアに投資をしないのなら、エンジニアは自己投資してスキルを上げ、スキルアップしたことでソフトウェアの開発効率と品質を高め、顧客満足が高まったことに対して満足を感じるようにする。顧客満足を高めたことで自分のモチベーションを保ち、顧客満足を高めることに貢献したことを組織に示し評価を得、同じことを他の技術者もできるようにするには投資が必要であると説く。

4.  ソフトウェア開発やソフトウェアエンジニアに投資しないという選択

組織がソフトウェア開発に投資しない、技術者も自己投資しないとう選択肢はないのか。ないことはない。以下のようなケースが考えられる。

a) 投資せずに技術者に負担を強いる。

b) ソフトウェア部品を外から買い自組織では作らない。（サプライやにaを強いるか、逆にソフトウェア部品の価格をつり上げられるという問題あり）

c) 安い海外の労働力にシフトする。（「あたたかい人間関係の中のやさしい一員」という特性は使えない）

d) ソフトウェアでは勝負せず、真似できないハードウェア技術で勝負する。

以上、組織もエンジニアに投資を行い、エンジニアも自分自身に投資をし、投資の結果、ソフトウェアの開発効率と品質が上がり、顧客満足が高まり、それが自己満足につながって、組織にもその成果を認めエンジニアを評価し、投資の効果を確認するのが一番いい。それができないのならソフトウェアエンジニアは幸せにはなれないように思う。

次回は、お金をできるだけ使わないでソフトウェア技術者に対する投資をする方法について書こうと思う。