カテゴリー「スキル」の記事

2017年2月23日 (木)

ガラパゴス企業に勤めているとたくさん生息しているガラパゴス技術者

 ガラパゴス・エンジニア:101回死んだエンジニア:エンジニアライフは、大企業の技術者をずっとやっている技術者として、本当に耳の痛い話だ。実際に、こういう技術者をよく見る。いったい、何のためにエンジニアをやっているのだろうか?とも思う。

2017年2月 4日 (土)

文系エンジニア:学歴としての文系は問題ではないが、知識体系としての文系エ ンジニアは問題だ

 人月神話の弊害?:文系エンジニアはなぜ誕生したのか~日本の現実 (1/3) - @ITという記事を読んだ。結論は、コンピュテーショナルシンキングが重要ということらしい。コンピュテーショナルシンキングっていったいなんなのだろう?
 技術者にとって必要なのは、技術分野に関する知識体系と、その知識体系を実装するスキル、そして、それらを実務として遂行する業務遂行能力である。
 文系エンジニアというのは、大学で文系専攻でありながら、技術者である人のことのようだ。確かに、化学系や材料系で、文系専攻出身者はほとんどいないだろう。
 ところが、IT関連技術者の場合、文系専攻出身者が多いらしい。らしいというのは、私の周辺にはいないからだ。化学系だったとかの異分野の理系出身者はいても文系出身者はいない。
 私は、大学の専攻は、なんでもいいと思う。知識体系さえきっちりと理解できていれば、のことだが。開発の世界で必要な知識体系は、大学の専門と必ずしも一致しない。たとえば、組み込み技術は、情報工学、電子工学、通信工学あたりの知識体系を必要とする。コンピュテーショナルシンキングだけでは開発できない。オームの法則を理解していない組み込み技術者の開発した機器など、安全上の問題すら発生するだろう。

2016年12月 6日 (火)

技術者としての能力と管理職としての能力

 前回の続きである。この記事には、こんな記述もあった。「優秀なエンジニアほど早々と管理職になってしまうが、優秀な管理職になるとは限らない。」
 難しいところだ。私は、古い体質のメーカー勤務だったので、若い頃は、当然管理職を目指すものだと思っていた。そして、管理職になった。
 管理職として、出世はしなかった。優秀な管理職でなかったのだろう。では、技術者のままであったらどうだったのだろう?若い頃は、若い技術者としては優秀だった。でも、そのままベテラン技術者になったときに、ベテラン技術者というカテゴリーでも優秀だったかは、正直言ってわからない。

2016年12月 5日 (月)

技術者のキャリアの最大の課題:管理職にならないと給料は上がらない

 10人のIT部門が消滅~ひとり情シス顛末記 - [第7回]最大のリスクが顕在化、長期休養でIT担当者が不在に:ITproを読んで身につまされた。「管理職にならない限り、どんなにエンジニアとして努力し結果を出しても、評価されないのである。」
 最近では、IT系ベンチャー企業などでは、優秀な技術者を技術者のままで高給で優遇している場合もあるようだ。でも、普通の企業のIT担当者(いわゆる情シス担当)は、そうはいかないようだ。
 そして、それは、組み込み技術業界でも同じである。組み込み技術というのは、いわゆるメーカーの社員である場合が多い。メーカーというのは、古い体質という意味ではトップクラスである。ソフトウエアハウスの社員であっても、組み込み業界のソフトウエアハウスは、発注先であるメーカーと同じように、古い体質のところが多いように思う。
 組み込み技術というのは地味な技術なので、トップ技術者というのが育ちにくい分野だという側面もあるとは思う。しかし、給料が上がらない理由の第一は、管理職にならないと給料が頭打ちになる給与システムである。

2015年8月 3日 (月)

器用貧乏とセンス

 日本刀の名匠が語る「下手」の本質 - 技術経営 - 日経テクノロジーオンラインの冒頭の部分を少し引用する。

「うまいやつというのは、どうも危険やな」
 現代を代表する日本刀の刀匠、河内國平さんは言います。弟子の時代にうまかった人が将来、大成するとは限らない。むしろ、その方が少ないのだそうです。


 わかる気がする。もう少し引用する。

「うまい人というのは、あまり努力せえへんのかもな。もしかしたら、一生懸命やっていても、何かが漏れてしまうのかもしれん」

 そうかもしれない。いわゆる器用貧乏というやつである。
 でも、一方で、どれだけ努力しても、大成しない場合がある。センスがない、という場合だ。
 センスがあって、技術の奥深さに対して、懸命に努力するというのが、理想なのだろうが、なかなか難しい。
 自分をふりかえると、センスとか、努力という次元ではなく、好きだから、というので続けられている部分がある。最先端の技術ではなく、民生機器の組み込みという地味な技術だから、それで通用してきたのかもしれない。

2015年6月26日 (金)

ヒアリングの際に「なぜ」は禁句:日経ITProの記事より

 (6/7)脱出! 暗闇プロジェクト - 情報は「質」より「量」、ヒアリングで「なぜ」は禁句:ITproの記事の、ヒアリングの際に「なぜ」は禁句は、意外な盲点である。要求分析の際に、担当者が現場に「なぜこの資料を作成するのですか」と質問したら、「F部門から作成指示が来たから」という言葉が返ってきたという。担当者は、その資料作成の目的を聞きたかったのに、そういう回答にはならなかたのである。これは、「なぜ」という言葉を使ったからだという。少し引用する。

 担当者が知りたかったのは「誰のために」「どのような目的のために」「どのような価値を生み出すために」その資料を作成する必要があるのか、である。ところが「なぜ」と尋ねたところ、相手の回答は「目的」ではなく、その作業の「原因」に関するものだった。


 こういう話はよくあることである。使う言葉を選ぶというのは重要なノウハウだ。これと同じようなことで思い出したのが、以前書いたどうして「質問形式」で叱ってはならないのか?:日経ビジネスオンライン記事である。叱るときに「なぜ」という言葉を使うことで、叱られる方が言い訳をしたくなるという。
 なぜ、という言葉は、自分が振り返る場合に使うのはいいが、人と話をするときには、曖昧な言葉なのかもしれない。

2015年6月23日 (火)

ソフトウエアが設計だけでは作れない理由:コンピュータの自由度の大きさが理由ではないだろうか?

 前回に引き続き、ソフトウエアの設計と実装の関係について、少し考えてみる。
 同じ記事の中で、「設計図と建物」はなぜ可能なのかについての発言を引用する。

 構造計算なんかは、もうノウハウとして、サイエンスとしてしっかりしている。構造計算をしっかりしておけば、実際に建ててみなくても建物の強度は分かる。そういう意味でいうと、ソフトウエアというのはある意味サイエンスにはまだなってない。作ってみなきゃいけないことがいっぱいある。

 この発言に続いて、ソフトウエアはサイエンスではなく、アートである、という話が出てくる。これは、昔から言われている話である。でも、なぜソフトウエアがサイエンスでないのだろうか?
 私が思うに、コンピュータの自由度の大きさが理由だ。コンピュータ上に仮想的に作られる対象は、あまりにも自由度が大きい。サイエンスで扱うには、対象の自由度が大きすぎるのである。
 建築の場合、現実世界の物理法則は変わらない。それが、建築という世界を貫く法則としてあり、それを基に設計することになる。これがサイエンスである。
 コンピュータでもハードウエア設計は、電気や熱などの物理法則に従って設計しなければならない。だからサイエンスだといえる。コンピュータサイエンスというのは、本来はハードウエアの世界で使う言葉だろう。
 では、ソフトウエアはどうなんだろう?仮想世界を貫く法則はない。仮想世界を記述する言語があるだけである。これは、確かに、サイエンスではなくアートに近い。
 つまり、本質的にソフトウエアは、サイエンスではないのである。サイエンスでない以上、設計と実装とを分離するという開発はあり得ない。

2015年6月22日 (月)

ソフトウエアの設計と実装は、料理のレシピと食べ物の関係:うまいたとえだ

 ソフトウエアの設計は、実装経験者でないとできないと思っている。でも、なぜなのか、を説明できない。なので、実装を知らないソフトウエア設計者が多くいる私の部署の中で、私は、実装が重要と言い続けている少数派になっている。
 なぜか、ということに対して、なるほどと思える記事が(7/7)激突対談! 「ITゼネコン」vs.「SIガラパゴス」 - (第1回)ここがヘンだよ! 日本のIT業界:ITproである。
 まず、この対談の質問の部分を引用する。

 ゼネコンの社員は別に現場でコンクリートを練るわけでもとび職をやるわけでもないけど、ちゃんとビルは建つじゃないかと。なのに、ITだとどうして、同じような構図なのに、ちゃんとしたシステムができないのかと思う人がいると思うのですが、それに対してはいかがですか。


 ソフトウエアの世界でプロジェクトマネジメントが重要視されている。同じくプロジェクトマネジメントが重要視されている建築の世界と似ているところがあるように思われていて、こういう比較がされる場合がある。また、ソフトウエアにおいてアーキテクチャという建築と同じ言葉を使っていることも、この傾向を助長している。
 だが、実際には、少し違うのではないか、という回答である。少し引用する。

 それから僕の直感でいうと、「設計図と建物」という関係よりも、「料理のレシピと食べ物」に近いかな。料理のレシピは作らずには絶対できないじゃないですか。
 <中略>
 料理を作ったことがない「なんちゃってシェフ」がレシピだけ書いている。下請の人たちは、下りてきたレシピ通り作るだけ。そこでは、おいしい、おいしくないは関係ない。

 料理を作ったことがないのにレシピだけ書いている「なんちゃってシェフ」が多数派をしめる部署にいる私には、実感としてよくわかる。

2015年4月 5日 (日)

脆弱性診断士-いろいろな資格を考え出すものだ:スキルマップは参考になる

 News & Trend - 世界初の資格化を目指す、「脆弱性診断士」の取り組みが始まる:ITproという記事によれば、脆弱性診断士なる資格を作ろうとしているらしい。確かに、これだけセキュリティ問題がさけばれているにもかかわらず、その基本となる脆弱性をあぶりだすスキルに関しては、よくわからないというのが実態だ。スキルマップを見ると、組み込み系の私には、名前すら知らないスキルがいっぱい掲載されている。これを見ながら、キーワードをネットで調べるだけでずいぶん参考になる。
 これだけ膨大な知識が必要となると、本格的に人材育成しなければいけないことがよくわかる。そのためには、こういう仕事には有資格者が必要ということにするのも良い考えだ。最初は、また新しい資格か、と思ったが、この資格に関して言えば、こういう仕組みは重要かもしれない。セキュリティの性質上、すべての領域で診断できる能力が必要になる。診断する側に、知らない分野があるというのでは、意味がないのである。
 資格の名前は診断という名前になっているが、一種の審査系の仕事ということだろう。審査系の仕事は、他社が顧客で、その顧客に入り込んで内情を審査するということになる。スキルだけでなく、その秘密を厳守するということも重要だ。特に、脆弱性などは、その情報を漏らせば、簡単に悪用されてしまう。スキルマップの冒頭に述べられているように、高い倫理性が必要とされる仕事である。残念なことに、スキルは試験である程度判断できるが、倫理性については、判断のしょうがない。
 今後の、こういう種類の仕事にとって、職業倫理というものを、どう教育するか(そもそも教育すら不可能なのかもしれないが)が大きな課題になる。

2015年3月10日 (火)

個人の業績評価を点数で評価する仕組みは会社を活性化するのだろうか:平凡な人材しか評価されない評価法

 年度末ということで、部下の業績評価をやっている。人事からの公式の業績評価方法によれば、いくつかの項目を点数評価してその合計点によって最終的には5段階評価にするという仕組みになっている。近年、会社というのはとがった人材を欲している。しかしこの評価方法は、それぞれの項目の満点が決まっている以上、いい評価を得るのは、すべての項目においてそこそこの評価を出せる人間である。一方、とがった人材というのはある項目では満点だが他の項目は非常に悪いというような人材のことを言うのだろう。こういう人材はすべての項目においてそこそこの評価を出せる人間には決して勝てない。
 つまり、会社というのは、先の見えない時代においてとがった人材が必要であるといいながら、結果的には業績評価を平均値で実施するという矛盾した話になっている。そもそも業績評価システムを作る人事部というのが、サラリーマン根性丸出しの人間の集まりに過ぎないことを考えれば、そうなるのはやむを得ないのだろう。

より以前の記事一覧

2017年9月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

公告

  • Google Adsense
無料ブログはココログ