2008年2月27日水曜日

達人に学ぶ SQL徹底指南書

この本の帯には「DBエンジニアに必要なSQLの
正しい書き方・考え方が身につく」とありますが、この本はDBエンジニア
のみならずプログラマにもお奨めです。

自分は外部結合くらいまでを理解してそれから先には踏み出してきません
でした、その必要も感じてきませんでいた。

ところが、この本で目から鱗が落ちました。

SQLの初級者を中級者に引き上げる教科書が今までありませんでした
、今はこの本があります、その教科書になりうる一冊です。

図を交えるなど文章が工夫されていて、集合論等のえてして小難しく
なりがちなテーマがかなり解りやすく説明されています。

SQLのライティングレベルを初級から中級に引き上げたい人は必読の
一冊です。

2008年2月17日日曜日

SI屋の語るミッション

「お客さまのため、お客様第一」は建前、本音は別。本音を建前でくるん
で誤魔化しているだけ。顧客の前では建前を本音のように語ることも必要、
それが駆け引きというかセールストーク。
SI屋が建前を前面に押し出すと苦労するのはそのSI屋の下についている
人間。本気で「お客さまのため、お客様第一」と思っているSI屋がもし
いれば、ついていくのは危険、そんなSI屋はまずいないが...。
「お客さまのため、お客様第一」を本音的に掲げるSI屋の下についた
人間はきっと土日出勤・徹夜当たり前の日々を(定期的に?)エンドレスに
送ることになる。数年(10年以内)でリプレースされるシステムにそこまで
自分の時間(人生)を捧げることに意味があるのか、甚だ疑問。そのSI屋へ
のそこまでのコミットに見合った対価を下についた人間が得られていれば、
それはそれでいいかもしれないが...そんなケースは稀。(断っておくが対価
は金銭だけを指しているわけではない、充足感・達成感・数年で陳腐化
するような技術知識は対価に当たらない。)

「お客さまのため、お客様第一」を本音的に掲げるSI屋はエンジニアの
不平不満を抑え込むためにエンジニアの前でも「お客さまのため、
お客様第一」を念仏のように唱え、エンジニアを納得させようとする。
対顧客向けのトークをエンジニアに対しても展開している時点でその
SI屋の底の浅さを感じる。

「お客さまのため、お客様第一」という言葉には水戸黄門の印籠のような
効果があるんだろうか?(いや、ない。)

SI屋は解らないが、エンジニアはクライアントのために働いているわけ
ではない。

[補足]
SI屋の手掛けるシステムはクライアント企業の業務と深く結びついている
ので、クライアントの業務手順に大きな変革があれば、システムは
リプレースされる。リプレースされない場合には原形を留めないほどの
大改造となる。SI屋の手掛けるシステムはクライアントの業務の小さな
変化には対応できるが変革と呼ばれるほどの大きな変化に対応できる
ほど柔軟には作られていない。クライアントの業務の小さな変化への
対応は無論、システムの小規模な改造。クライアント企業の業務変革の
スパンは数年(10年以内の)間隔でやってくる。

2008年2月9日土曜日

SIerでは何故ギーク志向エンジニアが評価されない(育たない)のか

SIerの身分制度と収益構造が密接に結びついているから。
SIerの身分制度は言わずもがなで、経営陣>コンサルタント>SE
>>プログラマ。
まず、収益構造からみてみる。
1つのプロジェクトに投入できる人数はコンサルタント<SE<<プログラマ。
つまり、プログラマの担当する製造の日数を契約時の工数で最大化すれば、
会社は儲かる。製造の人月を契約時の工数で最大化するためには単価の安い
平凡なプログラマを投入することで製造日数を多く見積もるのが一番、
その副次効果としてテストの日数も多く見積もれる。
この方法だと、プロジェクト単体から得られる利益がその規模に比例するよう
にできるので、SIerにとっては都合が良い。
優秀なプログラマを育てると、少ない人数で製造でき、バグも少ないので、
製造に掛かる日数とテストに掛かる日数が激減し、プロジェクト単体から
得られる利益が減少する。
プロジェクト単体から得られる利益がその規模に比例する状態を維持するには
プログラマを育てないで使い捨てにするのが一番なのである。
製造の日数を最大化する現状の方法ではプログラマを育てないことで
プログラマに払う報酬を安く抑えプロジェクト単体の人数の最も多い身分の
人件費を最小化するのがコスト削減に繋がっている。

SIerの身分制度については組織構造と収益構造が深く結びついている。
SIerでの人数分布は経営陣<<コンサルタント<SE<<プログラマ。
SIerの年間の売上が決まっている(プロジェクト単体では受注時に決まる)
中で、人数が少ない身分により多くの報酬を払うようにすれば、SIerは
儲かる。一番人数の少ない経営陣にとっては自分たちへの報酬が最大化し、
都合が良い。
SIerのピラミッド構造は今後も変わることはない。、
SIerの組織の中ではプログラマを評価しない仕組みが既に出来上がって
いるので、優秀なプログラマが行う行為が設計かどうかを議論する
ことに全く意味はない。

毎年毎年、大手・中堅のSIerには安い賃金で働かせることのできる
新入社員がわんさか入ってくるので、入社後数年の若手社員は
プログラマとして扱ってそれからSEにジョブチェンジさせている。
足りない分は外注・派遣で補い、単価を抑える。外注のほうも大手・中堅
のSIerに単価の安いエンジニアを薄利多売で投入して利益をあげる(外注の
場合は単価の高いエンジニア(SE)数名と単価の安いエンジニア(PG)の
セット売り、比率はSE<<PG)。外注・派遣業者のほとんどは自分たちの
利益を圧迫する人材育成にコストを掛けることはない。
専門学校や大学からの安くつかえるプログラマの供給は途絶えないので、
このSI業界の体制が変わることは当分ない。

そこにギーク志向エンジニアを育てる土壌はない。

[蛇足]
原価 + 利益 = 価格、クライアント向けと内向けでの原価が違うこともある。
クライアントの出せる金額は上限が決まっていることが多い。原価を低く
抑えることで利益の部分を大きくする。

2008年2月3日日曜日

何故SunはRubyを推すのか?

その理由の一端はRubyの型の扱いにあるように思う。
Rubyは全ての型をオブジェクトとして扱い、それらの型はRubyの
クラスライブラリとして外部に公開されている。
Rubyは変数への代入時にその型が決定され、変数は代入される度に
代入されるオブジェクトにより型が変化する。
Rubyは扱うオブジェクトの強い型付けが行われていながら、変数への代入時に
動的片付けを行う。Rubyは強い型付けと動的型付けの両方を採用している。

ちなみのPHP4は型が完全に実行環境の中に隠蔽されている、弱い
型付けの言語。

型の他にもJavaの将来の言語仕様にも取り込みやすい素地が揃っていて、
Javaにコミットしてきた企業にもその類似点から薦め易いLLだから
SunはRubyに熱心なのではないだろうか?

SI屋はRubyを勘違い?

SIを商売にする人たちはとかくRubyとJava(C#?)について自分たちの
閉じた世界での見解をあたかも全てであるかのように発信する。

RubyとJava(WEB限定)でできることに差がないならJavaを選択する
よね、というのがその最たるもの。そこに「自分たちの業界では」
という注釈が付くことは稀。

Javaは時間を掛けてかっちり組むのには向くけど、短期間(数日)で
アイデアを形にしてリリース・継続的変更のサイクルを数時間~
数日単位で行っていくのには向かない。Java自体がそもそもコード
量を減らして開発をスピーディに進めることを主眼にした言語では
ないし、EOD(Ease Of Development)、EODとJavaで騒いだところで
対LLではその生産性には埋まらない溝がある。
Javaの親であるSunが何故Rubyに投資しているのか、考えたほうが
いい。

変化が緩やかな業界では保守性等を考慮してJavaでシステムを組む
ことに意味があるが、日々急速に変化する業界では今日リリースした
サービスが近日中には陳腐化するので、保守性等を過大評価して生産
性の見劣りする言語で組むことに意味はない。

サービス(顧客にどんなサービスを提供できるか)に軸足をおいた場合、
Javaで開発することに意味はない。そのサービスで何ができるかが
問題であって、そのサービスが何で作られているかには何の意味も
ない。サービスの迅速な提供が重要になるので、サービスを短期間で
開発できる生産性の高いプログラミング言語が必須となる、
サービスの開発に時間をなるべく掛けないことが求められる。

SI屋の業界では状況が異なる。SI屋はクライアントに提供する
ソフトウェアで何ができるか(そのソフトウェアが顧客にどんなサービス
を提供できるか)ではなく、そのソフトウェアの構築に掛かった時間で
対価を受け取る。SI屋は構築したソフトウェアをクライアントが利用
しなくても別に損はしない。何故なら、仕様についてクライアントと
合意さえできていて、そのソフトウェアに仕様以外の深刻な問題が
なければ、クライアントとの契約を満たしているので、SI屋の構築
したソフトウェアが実用にたえなくても、クライアントは契約に応じた
対価をSI屋に支払わなくてはならないからである。何故支払わなくては
ならないかは自明、顧客と受注時にそのように契約を交わしているだけ。

ちなみにSI屋は変化が緩やかな業界をターゲットに商売をしているケース
が大半。短期間(数日)でアイデアを形にしてリリース・継続的変更の
サイクルを数時間~数日単位で行っていくことが要求される業界では
上記のようなSI屋のビジネスモデルは成立しない、だから、そのような
業界をSI屋は避けてとおる。

そして、SI屋は自分たちの構築するソフトウェアを高級そうに見せること
ができ、その構築により多くの時間を掛けることのできるプログラミング
言語を選択する。何故なら、短時間で構築できては商売にならないから。

そこでJavaの登場、LLとの比較では実行速度や保守性等を引き合いに
出して、クライアントを説得する。生産性よりも保守性・実行速度が
etc大事ですよとクライアントに...。

言語自体の実行速度ならJavaはRubyに勝てるが、Rubyでは実行速度が
要求される部分はCorC++で組まれて拡張モジュールとして言語に
アドインされるので、トータルとしてみた場合は言語自体の実行速度に
あまり意味はない。

(特定の)クライアントを相手にするせよ、(不特定の)カスタマーを相手に
するにせよ、サービス(顧客にどんなサービスを提供できるか)が大事で
そのサービスを支える技術には意味があるが、そのサービスを提供する
ソフトウェアの構築にどの技術を使うか、その優劣について議論すること
に意味はない。更にいえば、その時々で変化する技術のトレンドについて
本質ではなく、重箱の隅を議論することには何の意味もない。

<蛇足>
Java製フレームワークを作ってRails対抗を打ち出している人種は何故
そのコードを読む人間が作者界隈にしかいないのかも考えたほうがいい。
そのフレームワークは作者周辺にしかわからない、他の人間は容易には
解読できないようでは...読みやすい、理解し易いコードというのも生産性
の一端。作者界隈にしか解読できないフレームワークは商用プロダクト
と大差ない、OSSはお墨付きではない。タダで使って利用者が社内で付随
コストを負担するか、商用サポートを購入して付随コストを外部に支払う
か、ただ、それだけの違い。だから、学習コストだけで済む枯れた
フレームワークから利用者は中々新しいものに移行しない。

<蛇足>
エンジニアは自分がコミットした技術を他人に押し売りしたがる。
その最たるものが「狛犬もどき」、関東方面では何処にでも出没
して、自分たちのプロダクトはブレイクスルーだと喧伝する、
LL使いからは何処がブレークスルーだと白い目で見られている
模様、かのRuby設計者は「Javaの世界ではブレイクスルーなんだろうね」
のフィーリングで呆れかえっているらしい。
「狛犬もどき」は技術をこねくりまわして喜んでいる集団、それも
技術の本質ではなく重箱の隅を。
「狛犬もどき」が世界に通用しないのは技術の重箱の隅をこねくりまわ
しているから。Rubyが世界に通用した一端は本質的な技術に取り組んだ
から。