SIerで優秀なPGの給料が低い=>OSS開発で評価UP??

ここ。会社から評価されるためにオープンソースをやろうと

書いているようにみえる、会社からの評価を目的にするのでは

志が低いし...長続きしない。朝から終電まで(場合に

よっては土日も)プログラムを書いている人間に、リフレッシュ

するための僅かな余暇を削ることになる、効果があるかわからない

行為を推奨するのはどうかと思う。

(三度の飯よりプログラミングが好きという人間はトライしてみても

いいとは思うが...)

オープンソースのプロジェクトを開始するにしても２番煎じ

(猿真似)では評価されない、新規性がないと駄目等、開始するに

あたって注意すべき事柄は多い。

会社から評価されるためにオープンソースをやろうと書くのなら、

作るプロダクトに関してのアドバイス等、自身の経験を踏まえて

の実践的な内容にしないと、リンクした文章のように中身のない

空っぽな文章になる。

SIで優秀なPGが評価されないのはSI業界の構造的な問題(顧客から

の受注時に採用されている人月による見積もり等)が関係している、

それは一朝一夕に解決する問題ではない。

「オープンソースプロダクトの開発が(SIで優秀なPGが評価されない)

現状を打破する銀の弾丸になる」というような主張には何の根拠もない。

「オープンソースプロダクトの開発が上司に認められて

会社からの評価が上がったSIerの社員がいた」というだけでは

根拠にはならないのである。

会社からの評価UPを望むのなら、「オープンソースプロダクトの開発で

会社から評価を勝ち取る」などという不確実で非効率な手段よりも、

確実で効率の良い手段を探したほうが良い。

SIerの行うシステム構築は

利益を生み出すモノではなく、コストを削減するモノでしかない。

基本的に事務作業等の恒常性のコストを削減するのみ。

つまり、顧客にとってSIerの行うシステム構築の価値とは基本的に

コスト削減に尽きる。

コスト削減にすぎない以上、顧客はその年度の社内システム整備に

割り当てた予算の範囲内で社内システム構築に投資する。

自分たちの行うシステム構築が顧客にとってどんな価値があるのか

理解している若いSE・PGは少ない。

[追記]

SIerの行うシステム構築とは社会システム等公共システム及び医療

システム等の一部を除くと結局、事務作業等の恒常性の作業に関して

人間が行う作業のうち機械化できる部分を機械化して人間の手間を

減らすことで作業を効率化し、人的コストを削減するだけ。

効率化によって生じる時間的余裕を別の作業に振り向けることで

顧客に利益が発生したとしても、それはSIerの行うシステム構築

の産物ではない。

SIerのしくみとは基本的に

営業がプロフィットセンタ、SE・PGはコストセンタ。

営業は収入(≒利益)を生み出し、SE・PGはコストを生み出す

と考えて経営されている組織。

SIerの経営とは結局、営業がとってきた案件を如何に安いコスト

で仕上げ、利益(≒収入-コスト)を最大化するかという点に

尽きる。

最初に案件の生み出す収入が確定する以上、SE・PG

の携わるシステム構築フェーズで発生するコストを最小化

するしかその案件での利益を最大化する方法はない。

再度繰り返すが、SE・PGは本質的には(専門技術を有すると

いう点を除けば)、SIerにおいて総務部門等と同じコストセンタ

に属する存在である。

この点を誤解しているSE・PGは多い。

SIerにおけるSE・PGはクリエイティブな仕事でそれに見合った

対価が支払われるべきだ等の幻想は今すぐ捨てたほうがいい。

(SIerにおいてSE・PGが経営陣にコストセンタだと思われている

以上、見合った対価が支払われることはありえない。)

SIerの経営陣がSE・PGをコストセンタからプロフィットセンタに

位置づけし直すことはありえない。

Perl6は何処にいった？

Perl6の登場がアナウンスされてから５年以上になるが、未だ実用に

足る実装が出ていない。

数年前、Ruby2.0(Rite)とPerl6、どちらが早くリリースされる？かは

未知数だった。

ところが、蓋を開けてみると、現状はこうだ。

Rubyは2.0(Rite)のリリース前に先鋭的な機能を見送りVM化に

重点を置いた1.9.0(開発版)が昨年末にリリースされ、今現在も

1.9.1(安定板)のリリースに向けたブラッシュアップが今年の

クリスマスに向けて行われている。

対して、Perl6はHaskellで実装されたPugs等の実装が登場した

ものの、その全機能を俯瞰できる実装は未だ出ていない。

リリース競争におけるRubyの勝因は先鋭的な機能を見送り

(機能を絞り)VM化に注力したこと、笹田氏がYARVを開発し、

VM化のキーパーソンとなったこと等が挙げられる。

RubyのVMであるYARVとPerl6のVMであるParrotのスタンスの違いも

開発速度に大きな差を生じさせている。

YARVがRuby専用のVMとしてポジショニングされているのに対し、

Parrotは最初から多言語用の汎用VMとしてポジショニングされている

点である。

長期的には汎用VMを指向するにしても、短期的には特定の言語に特化

したほうが実装コストを削減でき、早期リリースに繋がると思う。

汎用VMとして成功しているのは.NetのCLRくらい、これは大企業が

フルタイム開発者を動員して開発しているからできる芸当だろう。

M$はスクリプト言語用にDLRという汎用VMをリリース済み

(開発続行中)。

.NetのOSS実装Mono、SilverLightのOSS実装MoonLightは共にOSS

ではあるものの大企業(Novell)がフルタイム開発者を動員して開発

しているという点ではオリジナルと同じ。

大企業がかまないOSSで同規模のことをやるのは難しい。

DLRにしても、1.0ではJavaScriptのみに対応し、2.0でのRuby、

Python等対応予定となっている。

よもやま話を一つ。

汎用VMとして将来有望なのはLLVM(Low Level VM)、ネイティブ

言語に適用でき、動的最適化可能という変わり種。既に

Mac OS X TigerのCore Image等での採用実績がある。

RubyとPerlはそのリリース戦略に大きな違いがあった。

Rubyは先鋭的な機能を盛り込んだ2.0のリリースに注力するよりも、

Ruby1.8の機能をブラッシュアップしつつ、VM化した1.9をリリース

するという現実的な解を選んだ。

(Pythonも先鋭的な機能の投入を抑えた現実路線を選択している。)

Perlは先鋭的な機能を盛り込みつつ、OO言語として生まれ変わり

VMの入れ替えも行うという姿勢を崩していない。

Perlも先鋭的な機能の搭載を保留し、OO言語化に的を絞った

バージョンのリリースに専念した方がよいのではないかと思う。

Perlの現状のリリース戦略ではPerl6のリリース時期は不透明すぎる。

Perlの開発期間の長さも、Perl6のリリース時期を予測不能にしている。

現行安定板5.10の開発に5年以上が費やされている。

Perlの「1つのことをするのに複数の方法を用意する」という設計思想

が、実装を複雑にし、開発の進捗を遅らせている点も無視できない。

開発期間の長期化は現実のニーズとの乖離を引き起こす可能性がある。

スクリプト言語のトレンドやニーズの変化は見逃せない。

5年以上前に策定されたPerl6の仕様が現在のニーズにマッチしているか

甚だ疑問である。

...Perl6の仕様、昨年末にFixされる予定だった模様。Fixされたのだろう

か？Fixされていないとすれば、そのリリース時期は更に混沌としてくる。

Perl6のリリース時にその時点でのニーズにPerl6がマッチしている

とは考えにくい。

だからといって、新しいニーズをどんどん仕様に盛り込んでいると

何時までたってもPerl6はリリースされない。

Perl6の仕様を再考しないと何時までもリリースできないのではない

だろうか？

ここによると、今年のクリスマスまでにPerl6の最初のアルファ版が

リリースされるらしい、ホンマかいな。安定版が何時リリースされる

かは全くの未知数。

#Perl自体はPerl5.xで既にVM化されていたので、修正しました。