生島勘富氏の最終コラム
【お知らせ】
＠IT自分戦略研究所 編集部です。
2010年5月28日、『ベンチャー社長で技術者で』を執筆する生島勘富氏を、エンジニアライフ コラムニストより除名いたしました。
今回の件について、多くの読者から問い合わせをいただきました。今回の処置について、生島氏には了承いただきましたが、「これまで行ってきた議論のまとめはしっかり行いたい」と、最終原稿掲載の依頼を受けました。
編集部で協議した結果、掲載すべきであると判断し、下記に生島氏より受領した最終原稿を掲載します。なお、この内容は＠IT自分戦略研究所の見解・意向を示すものではありません。
こちらで書いている文章は仕様書ではありません。過去をたどれる形で書かれていて、わたしの主張は常に一貫しています。ただでさえ長い文章に毎回毎回、前提条件は書けません。
が、とりあえずの前提は「業務系の仕事」です。SQLを他の言語と比べているのは、SQLでできることをSQLに任せているか、他の言語に任せているかということを書いています。
SQLで「できる」「できない」について。「できる」は一括処理できていることを指し、「できない」はループの中でSQLを実行していることを指しています。
◇ ◇ ◇ ◇
理論値について。
例えば、C言語とアセンブラ、どちらが効率的ですか？
工数であるならばC言語、パフォーマンスであるならばアセンブラ。
これは、「人間がコンパイラより賢い」という前提があります。アセンブラはできるけれどC言語はできない、またはその逆、という人が入ってくると議論が成りたたないでしょう。その前提を逐一書かないといけませんか？
しかし、どんなに同じ主張を繰り返しても、下記のような人が大勢現れるのです。
＞わたしは、過去にSQLが遅いのでSQLを崩しました。
＞そしてC言語でJOINをやらせて高速化しました。
一見、正しく見えるではないでしょうか？
逆に、「わたしは、アセンブラで書いたものをC言語で書いて、高速化しました」
「わたしは、C言語で書いたものをアセンブラで書いて、こちらの方が工数は少なかったです」
というのは、事実であっても議論の余地はないでしょう。それは単純にアセンブラ、もしくはC言語のスキルが足りなかっただけでしょう。
同様に、上の引用は「SQLでは理論値まで持っていけていないだけ」の話です。それなのに、わたしに根拠を求めながら堂々とこのように書いてくる人が出て、それがコメントの中では正論として通ってしまいます。ですがそれは、個別の事情として、SQLのスキルが足りなかったか、特に向かない処理であっただけです。
個別の事情は無限に存在し、それを持ち出されては議論は成り立たないと言っているのですが、なぜかわたしに対する反論としては、当然のことのように出てきてしまいます。
◇ ◇ ◇ ◇
世の中のあらゆるものには、理論通りにはいかない「例外」が存在します。業務系の中小企業の基幹システムで1～5％ぐらいは、どうしてもSQLでは一括処理できない（どうしても非効率な実行計画にしかならない）例外は存在します（弊社の例で、約400本中 5本でした）。しかし、いちいち、全部の例外を説明していては一般論としての議論はできませんし、システム全体を見渡せば「誤差」に落ち着きます。例外というのは個別の事情であって、個別でないと議論できません。
一括処理でできないものが基幹システム全体で1～5％というのは、例えば、
http://www.g1sys.co.jp/seminar090515.html
これぐらいのコーディングを30分ぐらいでできる人なら可能です。
特殊な例題として取り上げているのではなく、SQLが苦手とする（SQLに向かない）題材を敢えて選んでいます。単純なプログラムでは、お互いに短いから差は小さいけれど、SQLに向く複雑なプログラムを題材に選べば、もっと極端な差になるので避けています。
30分ぐらいでできれば、SQL文を書くのはかなり理論値に近い工数になっているはずです（理論値とは恥ずかしくていえない）。わたしが同じものをJavaでコーディングしましたところ、その量は、5倍の400％ぐらいでした。コーディングに要した時間は5倍以上（8倍ぐらいかな）でしたから、わたしはJavaに熟達しているともいえないわけです（同じ量のコーディングならJavaの方が早いと思っていましたので、逆になってびっくりしました）。
双方の技術に熟達していた場合、工数はコーディング量との比例の関係に近づきます。工数はスキル差という個別の事情が如実に出るので、理論値として比べられるのはコーディング量しかありません。コーディング量が増えれば、ドキュメントもドキュメント間の整合性を取ることも、テストも同時に増加するので、工数はコーディング量増加率のさらにウン倍になります。そのウン倍もまた、個別の事情ではっきりとはいえないけれど、必ず1以上になります。
オブジェクト指向言語で書いたコーディング量というのは、分割すればするほど、どうしても（SQLでやった場合に比べて）余分なマッピングが入るし、オブジェクト指向言語が発行するSQL文の要素は、効率的なSQL文で処理する場合の要素を最低限含み、それ以上になります。
アセンブラとC言語の関係は、
■ アセンブラ
アセンブラ ≒ マシン語
■ C言語
C言語 → コンパイラ → マシン語（≒アセンブラ）
となりますが、SQLとオブジェクト指向言語との関係は、
■ SQL
SQL → オプティマイザ → 実行
■ オブジェクト指向言語（に限らず）
オブジェクト指向言語 → プログラム
→ SQL → オプティマイザ → 実行
となり、無駄な処理を作っただけです。
理論値として考えるときは「アセンブラとC言語の関係では、人間はコンパイラよりも効率的にコーディングできる。C言語はアセンブラよりも短い記述になる」という前提があります。
同じように、理論値としては、オプティマイザが考え出す実行計画が、人間が考えるものと一致するまでチューニングが終わっていることにせざるを得ません（つまり、スキル不足でない前提です）。とすると、工数、パフォーマンスともに逆転することはあり得ません。逆転するとしたら、どこかに「個別の事情」が含まれていることになります。
理論値とは、つまり、理論上の限界値であって、人間がやる以上は理論値までできるとは限りません。しかし、それを認めてしまったら、「できない ≒ ∞」という人も議論の対象になりますから、水掛け論にしかならない。議論するには、理論値まで突き詰めて逆転するかどうかしかないのです。
経験則ですが、上のサンプルが30分で「できない」という人は、基幹システムを作ってSQLでできない例外が1～5％ぐらいというのが、10～50％ぐらいになります。ちなみにO/Rマッパーのはき出すSQLのまま利用すると100％です。
10～50％であるならば、確かにとても理論上の例外とは言い難い割合になるので一般論として語れるレベルにありませんが、例外が1～5％であれば、十分に一般論として語れるレベルにあると、わたしは考えます。
理論値では例外が1～5％ではなく0％になるから理論値です。つまり、理論上は、基幹システムを構築するのに、ループの中でSQLを使うのは（明細の更新以外）ゼロで、すべての実行計画が完璧になります。
しかし、上のサンプルが30分で「できない」という人が0％をイメージしているとは思えない。「できない」感覚で来られても困るのですが、みなさんの「スキル」という最も大きなファクタとなる前提はよく分からないし、できない人を排除してコメントを求めても意味がない。
「だから理論値で議論してね」ってことなのです。
それを、
「だから理論で議論してね」
「だから理論的に議論してね」
という表現では、「普段は皆さんが理論的でない」といっていることになります。それはわたしの思いとかけ離れているために「理論値として」と表現しているに過ぎません。
理論的でないとはいわないけれど、理論値（限界値）までを見た議論になっていないので、理論値まで見た議論にして欲しい、ということです。そうでなければ、個々に自由に設定できる証明しようのない「スキル」が、最も大きなファクタとなって議論にならないのです。
この辺の表現がまずかったのは謝罪します。申し訳ありません。
何度も同じことをいろいろな表現を用いて書いていますが、何度書いても伝わらないので、適切な表現があるなら教えて欲したかったです。
◇ ◇ ◇ ◇
どちらの手法が良いかと考えるとき、現実論としては、「できない人」を考慮しないわけにはいきません。しかし、「できない人」にフォーカスし続けると、いつまで経っても進歩はありません。
工数、パフォーマンスでトレードオフがないのに、違う方法を選ぶということは、トレードオフしているのは「できる人が少ない」という「技術者のスキル」に他なりません（いや、好き嫌いとかもあるかもしれませんが、すべて技術者の都合です）。それが許されるのは、よほどマイナーで世間的に知られていないものでない限り、あり得ないです。あってはならないことなのです。
「RDBMSの普及率で考えればあってはならないこと」だと、当たり前のことしか書いてないのです。
「オブジェクト指向言語ができない人の理屈である」というようなコメントも結構いただいたのですが、SQLができない人の理屈になってないか、できない人からできる人への批判になってないか、よく考えて欲しい。
もちろん、わたしが理論値ではなく、理論値はもっともっと高いところにあるのですけどね。
パフォーマンスはムーアの法則でハードの性能が良くなるので、それほど気にしなくてもいいかもしれません。しかし、いまだに自社のシステムが遅いと感じている方も多いのではないでしょうか。さらに、工数はシステムの価格とシステム会社の利益に直結する問題です。
理論値（限界値）までを見たとき、オブジェクト指向言語などと、SQLとどちらに力を入れるべきか、理論値の高い方を諦める（切り捨てる）根拠は何なのか、もう一度考えていただければと思います。
オブジェクト指向言語に掛ける皆さんの情熱が、半分でもSQLに向かえば、SQLに対する教育方法も、開発環境も、もっともっとブラッシュアップするはずです。
イノベーションは新しいものからだけ生まれるのではありません。NoSQLもクラウドも、古典的な考え方に戻っただけで、決して新しくはないのですから。
◇ ◇ ◇ ◇
コメント欄について。何度か炎上状態というものになっています。
わたしとしては、炎上を狙っているのではありません。何度も書いているように、わたし自身が非常に少数派の意見の持ち主であるため、反対意見が多いこともよく分かっていながら、衝突を恐れずに書いているだけです。
しかし、どうしても議論にならない水掛け論をふっかけて来る人がいます。それを解決すべく、これまで編集部に相談してきました。「炎上しても議論がしたい」と書いてきたとおり、もちろん目的は炎上ではなく議論ですから、わたしから下記のような提案を行いました。
炎上については責任を持つ。しかし、コメント欄で主旨に外れるものを長々と書く人が来てはまっとうな議論にならず、水掛け論になる（あまりにしつこいから罵ったのは事実です）。炎上見物が増えるのも本意ではない。後から見て、他の人にとっても意味のあるものになって欲しいので、主旨から外れるものが増えるのは、せっかく掛けた時間が無駄になるので、耐え難い。
そのため、これまでの謝罪とともに、「コメントには必ず連絡の付くメールアドレスを書いてください。主旨に外れると判断したものについては、コメントは削除させていただきますが、メールベースで個別に議論をしましょう。ダミーのメールアドレスで主旨に外れる書き込みをされる場合は、申し訳ないけれどスパムと判断させていただく」という内容のコラムをアップして、炎上の収拾を図るように依頼しました。
わたしは「コメント欄は意見交換の場」ととらえていたため、削除したとしてもメールで議論を継続するのであれば、コメントしてくれた人にとっても、後からコメントを読む人にとっても有用であると考えました。
「わたしの文章には前提が抜けている」とお叱りのコメントを受けましたが、本文の主旨を外れると、個々のコメントはどういう前提で書かれているのかまったく分からない。コメント欄で確認しようにも、途中で別の人の雑音が入るため、収拾が付かないと考えました。そのため、メールで確認したかったのです。これは、ダミーのメールアドレスで書き捨てていく人に憤りを感じていたためでもあります。
しかし、編集部は「守るべき『表現の自由』があり、それはコメント欄にも及ぶ」という考え方でした。
「削除権限をコラムニストに与えてしまうと、『コラムニストが気に入らないコメントは削除できる』ことになる。編集部としては、明らかな誹謗中傷といった問題があるコメントは削除するが、議論と無関係というだけの誹謗中傷にあたらないコメントはスルーしてほしい」
とのことでしたが、わたしにとっては非常に分かりにくい概念でした。「コメント欄を承認制にしてはどうか」という提案をいただきましたが、承認制では承認しなかったことが公にされません。わたしは、「わたしが消したことが公に見える方がフェアである」と考えました。
確かに、表現の自由は保障されるべきものでしょう。しかし、対立する意見の多いわたしのような少数派の意見は、「スルー」というやり方ではかき消されてしまいます。せっかく、エンジニアライフという現場の声を拾い上げる場を作ったのですから、少数派の意見がかき消されない配慮を、今後のために検討していただきたいと思います。
最後、コメント欄が汚れていくストレス、スルーするストレスに耐えきれず、暴言になってしまったことは反省しております（ストレスは、人格についてではないです）。不愉快になられた方々にはお詫び申し上げます。
非常に残念ですが、皆さまどうもありがとうございました。また、コメントについては反対意見を含めて大変ありがたかったです。
どうもありがとうございました。