IT系の資格がイマイチ普及しない理由の考察

システム開発

＠ITにこんな記事があります・・・。

「他国にない特異な状況」
上位試験合格者はわずか167人、日本のITILは大丈夫か
http://www.atmarkit.co.jp/news/200804/23/itil.html

直接は関係ない話題ですが、IT系の資格はイマイチ普及してないと思います。勝手にその理由を考察・・・というか普段思っていることですが。
他の業界・・・たとえば建築や危険物、法律関係でもその系統の資格はあって、かなり普及してると思います。
それら業界の資格の多くは、取得に当たってはその業務を行うのに必要な専門知識・経験年数・実技を問われ、業務を良い品質で追行できる専門家に与えられているでしょう。取得は難しいでしょうが、持っていることが少なくとも専門家の証になるでしょう。
そして、それらの資格には見返りもあります。業務の独占です。ある条件の建物の構造計算は1級建築士しかしてはいけない（＝1級建築士だけが行うことを認められている＝1級建築士が独占している）でしょうし、特定の危険物は専門家しか扱うことが認められないでしょう。
逆に考えると、特定の業務を専門知識を持った専門家に独占させることにより、その業務は良好な品質を保ちえていると言えると思います。（もちろんその専門家が故意におかしなことをしなければですが）
そんなわけで、IT以外の他の業界では、業務を行うために資格が必要なので、専門の資格が普及していると思います。また、その仕組みが業務の品質の低下をある程度は防いでいると思います。なお、資格がなければ業務ができないので、企業内において資格を持つ専門家の待遇がそれなりに保障される傾向があるのではないでしょうか。
IT業界では、資格による業務の独占は・・・私の知る限りではありません。別に資格無くたってみんなプロジェクトマネージャしてるし、データベースだって構築・管理するし、設計とかもします。一見自由そうで良さそうですが、社会において役割が増したITまわりの仕事が、いつまでもこのままで良いかとも思います。
現状、IT関連の業務は、資格が無くても実施できるので、資格の取得は業務追行で必須になりません。当然普及しがたいでしょう。また、IT資格のほうもそれが前提のためか、資格があるから業務が十分にできるといえるほどしっかりとした品質の資格ではないようです。（IT系の資格があっても仕事できない技術者はいっぱいいる。逆に持って無くてもできるひともいる）
IT関連業務では、専門家が資格を持って業務を独占していないので、必然的に専門家以外が業務を行う機会が増え、結果的に品質が低下したり、時間が予定より多くかかったりしているような気がします。
この現状はさらに弊害を生んでいると考えます。専門家が持つ資格で業務独占できるメリットが無いため、IT関連ではあんまり専門家が大事にされていないようです。また、先にも述べたとおり専門家が必ずしも該当業務をするわけではないので、専門家以外がIT関連業務を行って品質の低下が起こります。
そんな状況があるので、IT業界では仕事を取ってくる営業やコミュニケーション力がある人が重宝がられ、たとえ良い品質で業務できる専門家でも人月工数単価が高いと、専門業務をする立場から追いやられ管理職になったりもします。
これはこのIT業界の悪しき構造の別な側面かもしれません。専門家の存在が仕事の受注と遂行の必須要件ではないため、営業力のある（場合によっては営業力だけある）１次受けが仕事を取って丸投げし、さらに丸投げし、丸投げし、丸投げし・・・最後に中国にだすとか。各階層で専門性にかかわらず安いところに投げる多重下請け構造が、専門家がそれなりの単価で仕事をする機会をうばい、それが業務の品質を下げることにつながっているのではないでしょうか。
他の業界の業務独占型の資格は、もに業務の品質が保たれないと生命を脅かす等の問題があるため、そのように専門家に独占させるように規制されていると思います。IT関連は確かに失敗しても直接は生命を脅かすスジのものではないかもしれません。しかし、失敗したら何十億もの損失をたたき出すシステムやプロジェクトもある現在、このままのIT関連資格の制度でいいのかなぁと思います。

＃現行のIT関連の資格もかなり問題ありですが・・・。国家資格のほうはもちょっと受験機会を増やして受けやすくして欲しいし、ベンダー資格は内容がころころ変わったりするし。
＃業務独占型のIT資格であれば、それを有する専門家はどこの企業でも役立つ必要な存在ですから、転職等も行いやすく人材の流動化も図れるのではないでしょうか。

学生は正直と思う

システム開発

魅力回復は道遠し？　ＩＴサービス業界、学生の人気が低迷
http://it.nikkei.co.jp/business/news/index.aspx?n=MMIT0z000021012008

上記でも取り上げられ、各所でも話題の経営者と学生のやり取りについての個人的感想。

学生：：３Ｋといわれている現状の解決策をどのように考えていますか？
経営者：：３Ｋなどと言われているが、３Ｋの“帰れない”は、帰りたくない人が帰れないだけ。スケジュール管理の問題だ（学生はあっけに取られる）

自分のスケジュールを決定・調整できる立場の人間は、まぁ「スケジュール管理の問題」と言えなくもないかもしれません。事実、私の知るそういう立場の人間は、自分の時間を捻出するためにうまく立ちまわっていましたもの。客先との打ち合わせを朝の10時とか11時とかに設定して客先直行しますとか（自社の通常の始業は9:00で8:50集合）、16時に設定して「打ち合わせ終わったのでそのまま直帰します」とかやってましたもの。
でも、そういう立場じゃない人間も数多くいるわけで。てかいないと仕事回んないでしょ。競争上厳しめに設定されがちな納期に誰が間に合わせようとがんばっているのか。自分の時間でもいいはずの時刻帯まで働いているのか。

あと、スケジュールとは関係ない分野の人間もいます。障害が発生したら、スケジュール関係なく出動しなきゃいけない人間もいるわけで。私もDBのハードウェア障害でなんどとなく休日や深夜に出動してきましたよ。でも、人員に余裕ないから休めないわけで。

そういう環境面に対するケアは考えてますか？、という問いに対して、「スケジュールの問題」という回答はどうだったんでしょうか。

学生：：大学でどのような専門能力を身につけてきて欲しいですか？
経営者：：コミュニケーション能力に長けていると良い

学生：：それで、本当にヤフーやグーグルに勝てる産業になれるのですか？専門知識は要らないのでしょうか？

私も社会人になってからさんざん「コミュニケーション能力必要！」とか言われてきました。必要と思いますが、それは別にどの業種でも必要でしょう。人間社会そのものがコミュニケーションなんだし。

私は理系を歩んできました。受験してやっと工学系の大学に入ったら、一般教養の物理や数学もかなり難しくて、専門科目も難解。レポートもたくさん出るし、実験も時間かかるし結果まとめるのも大変。必修の課目ばかりで、あいてるスキマの時間に専門外の一般教養科目（社会学とか経済とか）をかろうじて受けれる程度でした。
文系の学生は、授業もずいぶん余裕があり、バイトやサークル活動に精をだし、ずいぶん楽しげにエンジョイしてるなぁ、と思ったものですが、なんと会社に入ったら、こういうバイトやサークル活動をエンジョイしてた学生のほうが「コミュニケーション能力ありますね！」って言われるんですもの。

その経営者がどういう人材を求めていたのか知りませんが、「コミュニケーション能力に長けていると良い」ばっかりですと、大学時代に学業に精を出してた学生は行きたくなくなっちゃいますよね。

そういう経営者の企業が人材に敬遠されて淘汰されるだけなら別に構わないんですが、私のいるこの業界全体がそういうふうに染まってしまっていること、思われていること、そして競争力を失ってることはずいぶん寂しいものです・・・。

手間賃と技術料の導入

システム開発

人月工数のひとつの問題は、スキルの高い人（生産性の高い人）が仕事すると、作業に必要な時間が減って（工数が減って）、SIerの儲けが減る、ということではなかろうか。（顧客にとっては品質の向上ものぞめるのに）。

大工の父が発行していた請求明細を見ていて思ったのだが、人月工数を「手間賃」と「技術料」に分割してはいかがだろうか。

「手間賃」：稼働時間（日数）に応じて請求する金額。一定条件をみたした労働者であれば、日雇い労働者であろうが、大工の名人であろうが同額。

「技術料」：難易度Ａの仕事を遂行するのに必要な技術力に応じて請求する金額。誰がやってもできるし、やってもいい仕事の場合は技術料は安い。特殊な人（その筋の名人だったり、特殊な資格を有していたり）しかできない場合や、特殊な人が施工して施工時間を短縮した場合は高くなる。

スキルの高い技術者が短期間で終わらせた仕事と、そこそこの人がそこそこの期間で終わらせた場合、手間賃と技術料の比率でもって、どちらでも同じくらいの請求金額にすべきではないでしょうか？（成果物が一緒である前提で）。

その場合、スキルの高い技術者のほうが、同じ値段でも高品質で期間が短くなることが期待されるので、技術料が高くても顧客は選んでくれると思う・・・。幻想か？

論理データベース論考

書籍 RDB モデリング

会社で前の部署におきっぱなしになってた荷物を整理したら、奥底から「論理データベース論考」を発見。
購入したころは難しかったが、今なら新刊とあわせて読めそうな気がします。

joinのコストは無になるか？

モデリング

モデリングの未来の道筋を感じさせる良い記事があった。

極北データモデリング　tgk氏
http://d.hatena.ne.jp/tgk/20061006#1160146375

さて、joinのコストがただ同然になる日が来るのであろうか？。
私自身は来てほしいと思っているのだが、環境が許してくれないのではないか・・・という予感。

たしかにメモリもいっぱい積めるし、周波数は上がらなくなったとはいえ、コアのマルチ化が進むからまだCPUの性能は上がるだろう。それでも・・・。

どうもＤＢは統合化の流れにあるらしい。データを集積して、より価値の高い情報を生む方向のような。
データの粒度そのものが細かくなる方向のような。それまで商品コードと数量で管理してたものが、商品一個にID振られたり。ユビキタスなんて目の前に迫っているんじゃないかと。

ということを思うに、確実に起こっているはずのチープ革命の恩恵は、ＤＢサーバのも確かにあるはずなのに、負荷の増大がそれを上回るのではないか、と。すなわち、意外にjoinおコストはタダみたいにはならない・・・？

でも、それじゃぁI/Oのコストもjoinのコストより増大しそうだ・・・。

今のところ、モデリングの世界は当然ながら今知られているトランザクションに耐えられるように検討される。
が、上記のデータの粒度が変わる、みたいな現象によって起こされるトランザクション特性の変化には、即座に対応されないかもしれない・・・。

モデルがどのへんで折り合いをつけるのか、要チェックの時代の気がする・・・。

「正規化の実用的なルール」を考える

RDB モデリング

参考：

E．F．Codd の遺産−ECObjectsのDB設計ウラ話

http://www.class.co.jp/column/backnm07.html

↑の一番下に、ECOの設計指針が紹介されております。

◆正規化の実用的なルール
（1） 基本的には第 1正規形のままでよい
　それをViewを駆使してキーを１意にしたり、キーを抽出したりするデータモデルがフレシキブルでよい

（2） 第 1→第 2、第 2→第 3にする時には、そうしなくてはならない明確な理由が必要

（3） トランザクションデータは正規化しない

ぱっと見ると普通のデータモデリングしている身としてはショッキングなわけですが、これはデータ構造が安定しているという前提に立つ「正規化」の弱点を直視した結果ではないかと思います。その弱点とは・・・。


「関係従属、推移従属」が普遍ではない！。いつか変わるときが来る！


ということではないかと。たとえば、商品ひとつにIDを振って、「商品IDが決まれば単価が決まる」という従属性があった場合、それは商品マスタとなるのでしょう。が、ある日突然、「明日から単価変わるけど、過去に販売済みの商品価格データは変更しない！。履歴も管理する！」とかに変わると、その従属性は商品IDとある時刻（ある一定の期間）にも従属するように変わっちゃうわけです。

いつか変わるかもしれない「関係従属、推移従属」にもとずいて正規化すれば、その「関係従属、推移従属」が崩れたときに正規化してある構造が困ったことになるのは自明の理。そこで・・・。


「データとその関係従属、推移従属はデータを登録した時点でのみ正しいのであって、それ以上意味はない」


ということにすると、むしろ正規化しちゃいけないことになるわけです。だって正規化の前提となる「関係従属、推移従属」が変わるのですから・・・。未来永劫普遍な「関係従属、推移従属」なら正規化しても問題ないのですが、いやそれは言いすぎですか。システムのライフサイクル程度「関係従属、推移従属」が維持されれば正規化しても問題ないでしょう。


ん？。逆か？。「関係従属、推移従属」が崩れるときがシステム寿命の尽きるときなのか・・・。


プロセス中心アプローチから、データ中心アプローチに変わりました。しかしデータの永続化にRDBを選択した結果、どれだけシステムが安定してる期間が増えたのかというと・・・。

「ビジネスの処理内容（プロセス）」が変わる程度から、「関係従属、推移従属」が変わる程度までに長くなった程度ではないかなぁ、と思う次第です。そして現代は、意外に「関係従属、推移従属」も安定しない方向なのではないかと。

そういう認識に立てば、「正規化の実用的なルール」も納得がいくような・・・。

（1） 基本的には第 1正規形のままでよい
　　　「関係従属、推移従属」が普遍ではないというのが「基本的」なデータだから。「関係従属、推移従属」はわりと不安定。（という前提）

（2） 第 1→第 2、第 2→第 3にする時には、そうしなくてはならない明確な理由が必要
　　　「関係従属、推移従属」が普遍（またはシステムの寿命以上普遍）という明確な理由があるなら第2,3正規化OK。

（3） トランザクションデータは正規化しない
　　　トランザクションデータは、データエントリーした時点でしか「関係従属、推移従属」が成り立たないようなデータだから。（という前提）


真理は上記と思いますが、今はまだRDBの性能が足りないでしょう。ムーアの法則あと10年続けば、「正規化は第1正規化」が常識になるのかもしれません・・・。

＃マジ？(^^;