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

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

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の方法はほとんどお金を使わない自己投資の方法だが、セミナーに行ったり、組織のお金でコンサルタントを頼むなど、お金をかけることで高付加価値、高効率の自己投資は可能だし、そっちの方が成功する確率は高いと言える。

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

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