建設とSI

建設とソフトウェアって何かと比較されることが多い気がするけれども、談合消滅後の建設業界で何が起きているかに書いてあることはそのままSI業界でも起きている気がするなぁ。

スーツとか

「誰が書いても同じコード」が大事なことなのかで

「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけない

といった人がいるらしいが、SIerが必要としているのは「誰が書いても同じコード」が必要なんじゃなく、彼らが求めているのは「担保」なのだ。

良い品質のものを、決められた価格で、決まった期日までに提供する。所謂QCDとか言われているあれを守るために、どうすればよいかという担保が必要なのだ。

良い品質というのが曲者で、何を持ってよい品質とするか？これが問題。出来上がったものと、客が求めてるものが違えば品質が悪い→作り直し→納期とコスト超過→マズーとなる悲しい商売だ。

品質が悪いといっても検収されれば良いが、最近の開発期間の短さや金額の少なさから、ゴールが明確に決まってないのに突っ走ることが多いため、仕様なのかバグなのかで揉めることが多い。最悪は訴訟沙汰。

一般的に受注側のほうが立場が弱いため、仕様が決まってなかったにもかかわらず、客の機嫌損ねて仕事こなくなるのが怖いので、バグということでごめんなさいしちゃってデスマーチと化すことが多いんだけども。

と、横道にそれたけれども、本題にもどすと、この曖昧な品質ってやつを明文化してこれはバグじゃなく仕様だと自分自身を守るためにドキュメント化という定量化する作業が重要になってる。

あらかじめ文言の一言一句、画面のフォントサイズの一つ一つ、ドラッグしたときに出てくる妙な反転一ついちいちコミットメントをとらないと品質が悪いと怒るお客さんが大手SIの対象にしている範囲だったりする。とかISOとかめんどくさい基準が必要だったり。。。

そんなわけで、誰が書いても同じコードになるぐらいのドキュメントを書いてお客さんにコミットメントをとる結果が、プログラマをアーティストじゃなくコーダにするわけで。

さらに大手SIerだと内製しない（内製の単金が折り合わないとか、配賦の関係で内省できないとか）ので、開発ベンダの進捗報告から定量的に報告しなきゃいけないわけで、定量化するためにも基準値が欲しいし、下請けが受託開発だと個々の開発者にアクセスできないし、PMがすごい人じゃない限り、中の人で判断はできないのです。

あと最悪コードを書き直せばいいといってるけど、そこで書き直すコストを誰がもつのよ?となる。

そこが求めている機能が実装されていれば、多少変な挙動してもそんなのカンケーネーと済ませる、というかなおせば良いじゃんっていうギークとスーツの違いなんじゃないかな。

ギークが考えている技術的な問題と、スーツの考えているビジネス的な問題がちょっと違っているんだと思う。というのはちょっと語弊があるな。ビジネス的に問題ないのに問題だとするクレーマースーツが多いのか。

たぶんそれぞれの立場でなんで担保がとれないんだと怒られて自己防衛に走りまくりなんだろうな。

あそこで必要なのは個々の生産性でも、お客さんが提供してユーザが満足するサービス内容でもなく、お客さん（の担当者）が自己満足するために必要な、ソフトを構築するために必要な担保をするためのドキュメントなのだ。

そこが日本の？SIerの悲劇なんだと思う。

本来はお客さんが展開するサービスがユーザを満足させて儲かることだったり便利になることが目的なはずなんだけど、プライマリじゃない限り一個上の親受けを満足させるのが目的になってたり、プライマリでもお客さんを説得できないと残念な結果になったり。

自分でサービスを展開して自分で責任を取ってなんとかしようってして欲しいけど、なかなかそういうふうにはならないみたい。

アジャイルで欲しいものを言いながらつくればいいんじゃね？って思うけど、そうはうまくいかない。SIって構造とか、商習慣的に難しい。予算だったり。バーターだったり。政治的あれこれだったり。

上のサイトを見てて思うのは米してるのがギークだけで、スーツな視点の人がすくねぇなぁと。

つーわけでスーツな視点でビジネス的には問題ないですとお客さんを説得できなきゃSIerはやってらんないっていうかオマンマの種を自社で直接提供してない限り開発の幸せも来ないわけですよ。と嘆きながら最近スーツな俺が酒を飲みながら言ってみる。

MySQL

書かれちゃったら書くしかないじゃん。

法律屋じゃないあくまで個人的な考えなのであてにしないように。あとで訴えられてもしらないよ;p

個人的にMySQLとMySQLクライアント（Java屋なのでJDBCコネクタとしよう）は別物だと思ってる。

MySQLを利用するってのはMySQLをDBとして利用する。つまり、DBMSとしてデータを格納するプログラムとして実行する。これはこれで単体のプログラムとして完結している。

MySQLのソースを改変してYourSQLとかMeineSQLとか作ろうって場合は別だが、MySQLサーバ自体を取得し、配布、使用することはGPL的にはなんら問題ないはず。（こっからもう前提が違うのかねぇ）

問題はMySQLにレコードを追加するためのインターフェース、つまりMySQLクライアントを利用したプログラム、例えば一般的な受託開発のWebアプリとか（非GPL）（以下自プログラム）を開発・提供する際にGPLにする必要があるかということだ。

LinuxはカーネルはGPLだが、システムコールの部分はGPL対象外とされているらしく、そのためLinuxのシステムコールを呼び出すアプリケーションは非GPLでも問題ないらしい。ApacheとかASLだし。

MySQLはこのシステムコールに当たるクライアントがGPLだから、MySQLにアクセスするプログラムはGPLに従う必要があるように思える。

しかし、GPLに準拠しなければならないのは自プログラムがGPLの元プログラムの「派生物」である場合である。よってここで重要なのは、MySQLクライアントを利用したプログラムが「派生物」にあたるのかどうかだ。

自プログラムがMySQLクライアントの派生物でないならば、MySQLクライアントを利用する自プログラムはGPLである必要はなく、MySQLを(ライセンスを買わずに）GPLで利用しても問題ないはず。

「派生物」の定義がGPLでは明確にされてない。（LGPLではライブラリについて定義されているが。）一般的に「派生」と言ったときには、元の「翻案」を改変したものを指すらしい。つまりMySQLクライアントには一切手を加えず利用しているだけの（基礎としているのではなく一部として利用している）自プログラムはMySQLクライアントを利用しているだけで「派生」ではないと言えるのではないだろうか。

ということでMySQLをDBとして使う普通のWebアプリケーション開発・提供はライセンス買わなくてもいいんじゃねー？と思うんだけど、こことかこことか何が何でも商用ライセンス買えってなるんだよね。

結論としては、ぐだぐだめんどくせーから金で解決できることは金で解決しちゃえば良いんじゃねー。と思うわけです。１本５万らしいです。

きっとそれがMySQLのさぁーくせんなんだな。

法律屋の見解を聞いてみたい。

ところでMySQLの例外条項にはASLならOKみたいなことが書いてあるけど、コネクタをラップしたライブラリを(例えば独立なライブラリと見せかけるためにO/Rマッパとして作って）ASLライセンスで配布して、それを非GPLなプログラムが利用する場合はどうなるんだろね。あぁこれがPHPの組み込みMySQLドライバか。

それにしてもここでMySQLを利用したプログラムを公開・配布している場合ライセンス買えになるけど、オプションとしてMySQLを使えるよってのはどうなんだよ？と。ActiveRecordとか。

ホスティングサービスで提供してるMySQLを使ってサービス提供する場合はホスティングがかね払ってるからGPLじゃなくてもいいのか？とか。

結局よくわかりませんでしたorz

#ホントこういう文書の読みにくさは異常。

#俺の読解能力が足りなすぎるだけじゃないよね？