プログラマ35歳定年説を検証する part1 - TopCoder

気が付けばまたもやブログの更新がおろそかになっていたので近況がてら更新します。
ちなみに、スマートフォンはもういやだ！と思っていたのですが、業務命令でiPhone4S（ア・イ・フ・ォ・～・ン）を予約したのですが1ヶ月待ちとのことで今しばらくはX01Tとのお付き合いになります。まぁ手に入ったらまたレポートなんぞをしてみます。
ADP1周年記念やSQLのパフォーマンスについてのまとめページが進んでいませんし、ダジャレクラウドとか地味にその他に書くことがあるのですが、最近ちょっと関心を持った話題を書きます。

今から20年以上前にまことしやかに囁かれた『プログラマ35歳定年説』という仮説がありまして、まぁ『35歳ぐらいになったらプログラマとしては役に立たなくなる』という感じで使われたりします。まぁ一種の都市伝説のようなものですが、実際に信じている人も多いようで ぐぐる グーグル先生で検索すると未だに肯定するような記事も出てきます。
私は今年で40歳を超えるのですが、いまだに開発を行っていますし何よりこのブログが『俺は使える事を』証明しているとも思わなくもないですが、もっと客観的に証明する手段として、TopCoderというものがあると思いましたのでそのお話でもしてみます。

TopCoderというのは、プログラミングコンテストの一種で、競技プログラミングとも呼ばれており、制限時間内（75分）にお題にそったプログラムを組むというものです。
問題は、簡単・普通・難しいと３つ出題され、それぞれ難易度とプログラミング時間によってポイントが付き、そのポイントを競うというものです。
単純にプログラミングをして終了ではなく、プログラミング後、他のメンバーが作成したプログラムを参照できバグを発見したら（バグを現出させるテストケースを与えれば）、別途ポイントがもらえます（チャレンジという）。
そのようにやってポイントを稼ぐと、レーティング（通算ポイントのようなもの）が貰え、そのレーティングによって順位付けがされるというものです。

私の現在のレーティングは1391になりますが、これは9138人中の2047位（全世界）、766人中の141位（日本）らしいです。
この順位で私が使えることが証明されたかどうかは実はいまいちなのですが、私より順位が下の人には某一流大学の人たちもいますので、そういう意味では『まだまだ若いもんには負けていない』ということはいえるかと思います。もっとも私より上位にも某一流大学の方が居るので一概に某大学生に勝ったとはいえません。
レーティングが上位になると『レッドコーダー』と呼ばれるようになります。なぜレッドかと言いますとレーティングによってIDが上から、レッド、イエロー、ブルー、グリーン、グレイで色分けされる関係でそう呼ばれるようです。私の現在の色はブルーになります。参加しだして間が無いのでなれていない面もありますので、精進を重ねレッドコーダーになれば、晴れて私も使えるプログラマということが証明されるかと思います。

75分という極めて短い時間でプログラムを作成するので本当の実力の一部分しか計測できないでしょうが、問題自体は非常に良く出来ているとも思いますし、何より自分の実力が客観的に判るので腕に覚えのあるITエンジニアの方は是非挑戦してみては如何でしょうか？

JOINのパフォーマンスについての考察2（リレーションとの関係2）

ちょっと間があきましたが、JOINのパフォーマンス関連の続きになります。
前回、JOINのパフォーマンスについての考察（リレーションとの関係）でJOINを行った結果、データが非正規化するとその非正規化の度合いによってパフォーマンスが下がるという話をしました。
前回の記事では、1対ｎの結合ではJOINを外す（単純なSQLに分割してホスト言語側で結合させる）ということで、定性的な話しかしていませんでしたが、幾つか実験を通して、もう少し定量的な話をしてみます。
『たかがJOINで、なぜこねくり回すのか？』と思われるかもしれませんが、こういう実験＆考察というのは意外に行われていないかと思います。私自身定性的なことは理解していたつもりでしたが、実際に実験を行うと色々と発見がありますので、記事にしてみます。
大切なことは解った気になることではなく真実を追究する姿勢で、先入観を持たずにきちんと実験を行いパフォーマンスに対する感性をみがくことは大切かと思います。

今回、調査するアルゴリズムについて

今まで何回か実験してきましたが、実験で使用してきたアルゴリズムについて説明します。

１．SQLでJOINを行う。

SELECT Price.CODE, RDATE, OPEN, CLOSE, NAME
FROM Price INNER JOIN Company ON (Price.CODE = Company.CODE)

という風にSQLでJOINを行います。普通の処理になります。

２．ホスト言語側でJOINを行う（キャッシュ付のネステッドループJOINを行う）

　１．のSQLを以下のように分割します。

(1) SELECT CODE,RDATE,OPEN,CLOSE FROM Price
(2) SELECT NAME FROM Company WHERE CODE = ?

(1)のSQLを実行して結果を取得しますが、NAMEについては(2)のように再度SQLを発行します。
ここで、単純にPriceテーブルの全ての行に対して(2)SQLを発行するのではなく同じ結果をキャッシュして同じCODEの場合はキャッシュからデータを取得するようにします。
　

３．ホスト言語側でJOINを行う（ハッシュJOINを行う）

１．のSQLを以下のように分割します。

(１) SELECT CODE,NAME FROM Company
(２) SELECT CODE,RDATE,OPEN,CLOSE FROM Price

（２）のPriceテーブルからのデータの取得に先立ちまして、（１）でComapnyテーブルから全てのデータを取得しておきます。
多くのDBMSで行っているハッシュ結合を真似ています。

1対ｎの2つのテーブルのJOINにおけるパフォーマンスモデル式

続いて、各アルゴリズムのパフォーマンス（実行時間）のモデル式を示します。
ここで、
n ： Priceテーブルの行数
m ： Companyテーブルの行数
c10,c10,c20,c21,c22,c23,c30,c31,c32 ：　比例定数
になります。

１．SQLでJOINを行う

１．のパフォーマンスのモデル式は以下のようになります。

c11 * n + c10

　Priceテーブルの行数に比例した時間で結果を取得できます。ここでc11は比例定数であり、C10はオーバーヘッドにあたります。

２．　ホスト言語側でJOINを行う（キャッシュ付のネステッドループJOINを行う）

　２．のパフォーマンスのモデル式は以下のようになります。

c21 * n + c22 * m + c20

　Priceテーブルの行数に比例した時間と、Companyテーブルの行数に比例した時間およびオーバーヘッドの合計になります。
　『c22 * m は　c22 * n * m になるのでは？』と思われるかと思いますが、キャッシュのおかげでこのようになります。
また、「１．SQLでJOINを行う」と比べますと、c22 * m と余計な項が付いていますので、

SQLでJOINした方が速い

と早合点される方がいらっしゃるかと思いますが、JOINのパフォーマンスについての考察（リレーションとの関係）で述べたことは、c11とc22の定数値の差異となって現れてきます。

３．ホスト言語側でJOINを行う（ハッシュJOINを行う）

　３．のパフォーマンスのモデル式は以下のようになります。

c31 * n + c32 * m + c30

　面白いことですが、形式的には「２．　ホスト言語側でJOINを行う（キャッシュ付のネステッドループJOINを行う）」と同じになります。
ちなみに、[ADP開発日誌]SQL（JOIN）の実行パフォーマンスについて２０１１ にあります、「SQLの発行回数のオーバヘッドはどこにいったんや？」と思われるかもしれませんが、それはc32とc22の差異に出てくるということになります。

実験と結果

　今回の実験では、nの値を変えながら実行時間を計測することにより、各モデル式の定数を求めます。求めるといってもグラフを書いて状況を観測します。厳密には回帰分析とかを行うことになるでしょうが、グラフが直線になることと、ｎが増えたときの傾向をつかめればよろしいかと思います。
アルゴリズムの教科書ではオーダーという概念があり、オーダーでは定数を求めることは無意味とされています。つまり上記のアルゴリズムは論理的には違いがなくどれも一緒ということになります。
つまり、2倍や3倍の差はあまり意味がないということですが、もっとも、実際の現場ではこのような差にも敏感になるので、きちんと計測して値を出すことになります。
また、今回はｍは固定（約2000）で行っています。ｍが変動したときにどう変わるのかも興味深いですが今回は、m << n ということで結果にはあまり影響しません。

先ずは、結果から、

Priceテーブルから取得する行数を変えながらSQLを実行（単位ms）

	0行	373,740行	1,172,191行	2,002,749行	4,671,568行
１．SQLでJOIN	718	10,015	29,938	52,329	119,192
２．キャッシュ付のネステッドループJOINを行う	671	10,469	30,172	49,814	116,770
３．ハッシュJOINを行う	2,828	11,422	29,797	49,845	110,988

つづいて、グラフを以下に示します。

縦軸が時間で、横軸が行数（ｎ）になります。グラフをみますとPriceテーブルの行数（ｎ）が増えると「１．SQLでJOIN」より、「２．キャッシュ付のネステッドループJOINを行う」や「３．ハッシュJOINを行う」の方が速くなっていくことが解るかと思います。

パフォーマンスにシビアになる時は、往々にしてｎの行数が増えるような場合にあたるということになります。その場合は１より２や３を選択した方がよいということになります。

もっともグラフを見て解るとおり差はあまりないので、通常はやはり普通にSQLでJOINを行い、パフォーマンスを稼ぎたくなったら２や３を検討するということになるでしょう。

JOINのパフォーマンスについての考察（リレーションとの関係）

コメントを頂いたのですが、ちょっと返し方が悪かったのか音信普通になりましたので、改めてJOINのパフォーマンスについて考察してみます。

1対ｎ結合の場合、JOINとは正規化データから非正規化データを作り出す操作になる

RDBのテーブルは、きちんと設計されていれば、正規化されています。つまりデータに重複がなく容量の面で効率的になっています。ここで正規化データとはあくまでもRDBにとって効率的というだけでそれ以上のものではありません。一方で人間が理解しやすいデータ形式は必ずしも正規化データというわけではなく、往々にして非正規化されたデータの場合があります。
JOINを行うということは正規化されたデータを非正規化データに戻す操作ということに相当します。つまり、効率のよいデータから人間にとって理解しやすいデータ形式に戻す操作になります。JOINは正規化されたデータから非正規化という効率の悪いデータ形式に変換する操作になります。
SQLでJOINを行い、その結果を取得するということは何らかの非効率な行為が行われているということがわかるかと思います。
RDBのコピーを行おうと考えた場合、わざわざJOINなどせずに、テーブル毎にコピーを行おうとするでしょう。RDBからデータを取り出すとき同様に正規化された単位でデータを取得した方が有利な場合があるということは理解できるかと思います。

RDBでは正規化データから非正規化データを作り出す方が非正規化データから正規化データを取り出すより効率的

先ほど、JOINは非効率といいましたが、なぜRDBでは効率の悪いJOINが行われるのでしょうか？
理由は簡単で、RDBの理論では、
・非正規データ から 正規データ を作る
操作より
・正規データ から 非正規データ を作る
操作の方が効率的と考えられているからです。非正規データから正規データを得るにはグループ化を行います。つまりGROUP BYを行う必要がありますがこれはつまりソートを行った上に重複したデータを圧縮することに相当します。一方でJOINはデータの検索に相当します。例外はありますが検索の方がソート＆圧縮より効率的なのは理解できるでしょう。
さらに、正規化データは非正規化データより更新が容易ということもあります。
つまり、関係データベースの世界では正規化されたデータは非正規化されたデータより効率がよいと考えられています。ちなみに、この認識が間違って拡大解釈され、『SQLは効率がよい』という誤解が生まれたと想像されます。

1対ｎの結合で一方のレコードサイズが小さいとき、2つのテーブル間の単純なJOINは効率的、だがデータの出力が非効率

FROM table_a INNOR JOIN table_b ON (table_a.table_b_ID = table_b.ID)
のSQLがあるときに、
table_aがマスターを参照するテーブルで、table_bがマスターテーブルと仮定します。つまりtalbe_aとtable_bが1対ｎで結合されており、さらにtable_bがメモリに入る場合、JOIN自体のコストはほとんどかかりません。
2011年現在、サーバーに搭載されるメモリ容量が数十GBのオーダーになります。一方でマスターテーブルの容量は多く見積もっても数百万件のオーダーになり、各データを多く見積もって１KBとしてもマスターテーブルのデータ容量は数GBのオーダーとなります。実際にはJOINに必要なデータのみメモリにおいた場合、必要なデータは1桁も2桁も減ることになります。結果として1対ｎの結合ではほどんどの場合、マスターテーブル側はメモリに乗ることになり、JOINにおいてマスター表の操作は高速に行えます。
しかし、1対ｎの結合では、結果を取得する場合に、結果データが非正規になる為に非効率になります。
この場合、JOINを分割して、呼び出し言語側でJOINした方が理論的には効率的になります。実際どこまで効率的になるかは分割による複数回のSQLの呼び出しのオーバヘッドと繰り返しデータの量に左右されます。

1対1結合の場合は、JOINは出力も含めて効率的になる

1対1結合の場合は、結果データも正規化しているのでJOINは効率的になります。JOIN自体が効率的に行えるかどうかはデータ量やデータ（または結合キーのインデックス）が整列されているかどうかによります。

結論

以上のように、扱うデータの性質によってSQLでJOINさせる方がよい場合とSQLではJOINさせない場合の方が理論的に速くなる例を示しました。
結合の種類が1対ｎの場合、JOINを行うとデータ非正規化し、容量が増えるので出来るだけJOINを遅らせるテクニックが有効になる場合があります。
実際にどのような状況のときにJOINを遅らせたほうがよいかですが、マシンのスペック、ネットワークの環境等に依存しますが、傾向として行数が増えた場合や1対ｎのJOINの数が増えるとJOINを遅らせる方が有利になります。このような場合でパフォーマンスに問題が発生した場合にJOINを遅らせるテクニックを検討されると上手くいく可能性が高まります。
一方で、結合の種類が1対1の場合、データは非正規化しないので、SQLの発行の段階でJOINを行えば有利になります（JOIN自体のコストはまた別の話になります）。

真のソフトウェアエンジニアに必要なモノ（SQLは銀の弾か？）

件の社長ですが、ブログで、まとめ記事を出しております。あれだけ口悪く私のことを煽っていたのにバツの悪い終わり方だと思いますが、まぁ、これ以上、『SQLはオブジェクト指向言語の数十倍の効率』の件を追求する必要もないのでその件は終わりにします。

ただ、私の方ですが、久しぶりに火がついたので気ままに書いてみます。もっとも粘着質といわれるのも嫌なので、件のブログ自体にはコメントしません。が別に書いていることが正しいとも思っていません。件のブログですが、コメント欄が消されていますので、疑問等ある人はこちらのコメント欄にでも書いて頂ければ『私に答えられること』でしたらコメントします。

素直さは如何に大切か、とか、騙されないようにする為に（適切な議論の方法）と記事を書いてきましたが、そもそも論として、ソフトウェア開発に関連した技術面で何か記事を書くのであれば、それは技術者を代表してという立場で発言することになるでしょう。ここでの技術者の代表とは、『ソフトウェア開発をリードし設計、開発、テスト、トラブルシュートを行い、単なる知識だけでなく頼れる技術を持った、顧客だけでなく共に働く人や競合他社からも一目置かれるような人』ということで話をします。お前はどうやねんとツッコミが来そうですが、私は僭越ながらその末席において頂いていると思っております。
というわけで、以下、真のソフトウェアエンジニアとって必要なモノについて語ってみましょう。

『銀の弾などない』ことを理解する

恐らくソフトウェアエンジニアだけでなく、顧客の情報システム部の方や、現代では企業経営者全ての人に教養としてお薦め本に『人月の神話』があります。私はざっと一読しまいたが、ソフトウェア開発の真実をみることができるでしょう。ちなみに訳本のせいか私にとっては少々読みにくい（というかくどい）です。
その中にある、『銀の弾などない』という章で著者のフレデリック・ブルックス氏は『ソフトウェア開発においては○○を使えば生産性や信頼性、安全性が著しく向上したりするという特効薬は存在しない』という趣旨のことを主張しています。この主張は約25年前になされましたが、今でも充分に通用するでしょう。つまり、「○○を使えば生産性がX倍向上します。」ということを耳にするかと思いますが、『そんなものはない』というのが氏の主張で、私も自身の体験からこの主張は現在のところ正しいと思っています。
ひょっとしたら経験は浅いが技術力のある方の中には「そんなことはない、銀の弾はある！」と思うかもしれません。一経験者から言わせてもらうと恐らくそれは思い込みです。
ただ、この主張が将来に渡っても正しいかどうかは解りません。なぜかというとこの主張は現在のソフトウェア開発の弱点とそれが将来に渡って解消されないという予測を行っているだけだからです。人間という生き物は欲深いものでこの弱点を克服しようと多くの人が日々努力しています。私がADPを開発しているのもまぁそういう努力の1つです（と言っておきましょう）。
当然ですがフレデリック・ブルックス氏もその点はきちんとフォローされており、約25年前に、銀の弾の候補の一つとしてオブジェクト指向プログラミング（OOP)を挙げておられます。ただ、その約10年後に出された『「銀の弾などない」再発射』ではオブジェクト指向が本来使われるべき領域（業務ロジックにオブジェクト指向の適用）ではなく低レベルな部品レベル（リストクラスやGUI等）にとどまっていると指摘しています。
現在ですが残念ながら状況はあまり変わっていないでしょう。オブジェクト指向はだいぶ浸透してきたかと思いますが、現在ではソフトウェア開発期間に求められる時間が短くなってきています。つまり顧客はカジュアルにサービスを立ち上げたがります。そうなるとじっくりと開発するというわけではなくありものでちょちょっと作ることになり、OOPといっても『ライブラリを使う』ということはあっても業務ロジックを作ることはそう多くはないでしょう。また何よりOOPを使った失敗プロジェクトも多かったのも事実です。

そして、件の社長ですが、『少なくともRDBを使う業務アプリの開発において、データを操作する部分に関してはSQLは銀の弾になりうるのではないか』と主張しているのかと想像します。

行間を読む

　ソフトウェアエンジニアは普段コンピュータばかりを相手にしているのでどうしても理屈っぽくなり、言葉を額面どおりに取る傾向にあります。がソフトウェアエンジニアたるものコンピュータばかりでなく人間も相手にしなければなりません。行間を読むことは人間同士のコミュニケーションで重要なことです。がもちろんですが相手に行間を読んでもらう前提で話をしてはいけません。コミュニケーション能力は技術者というより人間としての経験値が必要ですが、幸い今ではインターネットを使ったコミュニティが豊富にあります。行間を読む訓練は昔より遥かに簡単にできるでしょう。

SQLは銀の弾になりえるか？

という訳で、まとめ記事ありました、件の社長が本当に言いたかったことを推測してみますと、
『少なくともRDBを使う業務アプリの開発において、データを操作する部分に関してはSQLは銀の弾になりうるのではないか？ 銀の弾ではなかったとしてもオブジェクト指向プログラムより使える技術だろう』
ということが某社長が言いたかったのかと仮定します。
で『その根拠』について私の経験を元に考えてみましょう。ちなみに、『人月の神話』にはSQLは銀の弾の候補に上がっていませんでした（間違っていたらコメント欄にご指摘下さい）。

この点については社長自信、色々上げておられるのですが、私の経験上一番納得できるポイントは

・オブジェクト指向技術を使ったプロジェクトが失敗したときの被害
と
・SQLに頼ったプロジェクトが失敗したときの被害
とを比較した場合、どちらがより被害が大きくなるか？です。

件の社長が言いたいのは（というか過去の議論で私が理解できた社長の主張は）『OOPを使ったプロジェクトが破綻した場合の方がより被害が大きい。』ということでした。私の中では『どっちもどっち』と思う面もなくはないですが、確かに実際に聞く話は『OOPを使ったプロジェクトの破綻』が多いし深刻度が高いです。もっとも私の周り3メートルの範囲ですが。

この事実は、単純に『OOPが銀の弾候補』になり、それ以外にもオブジェクト指向がバズワードとして色々宣伝されたので、多くのチャレンジャーが集まり、壮大な実験の結果、失敗例が集まったということかと思われます。

その他、OOPが思ったほど実力がないということの例を挙げますと統合開発環境の存在があるでしょう。本当にOOPが銀の弾なら統合開発環境は要らないでしょう。皮肉な話ですが統合開発環境が高機能になればなるほどOOPがそれ程たいしたことではないという風に聞こえてしまいます。例えば、「統合開発環境のリファクタ機能を使えばそんなの簡単です。」という話を聞きますと、すごいのは統合開発環境であって言語ではないということでは？と疑問が出てきます。ちなみに「統合開発環境がないと開発できない」とか言われると『本末転倒やん』と嘆きたくなります。

さらに別の例ですが、私が関わったプロジェクトでC++を使ったものがあったのですが、バグ入りのものをリリースしたが、既に担当者がいなくなったので修正が出来ないということで私に助けを求めたものがありました。単純にOOPで作られたというだけでなく、マルチスレッドで動作していたのでバグの原因が不明で誰も手が付けられなかったということでした。OOPの思想の１つにカプセル化（隠蔽、ブラックボックス化）があります。確かにバグがないプログラムを再利用する場合はカプセル化は理想的です。しかし、そのカプセルの中にバグがある場合は否応なく内部を調べる必要があり、これにプラスして経済的な制約が加わると大変なことになることは想像できるでしょう（まぁ私は儲かるのですが・・・ちなみにこういうことでお困りの方がおられたら私ならなんとかできるかもしれません）。

ここまで言いますと『じゃなんでお前はC++を使っているんだ』とツッコまれそうですが、道具はあくまでも道具で、適切に使えば良いという話だけです。長所、短所を理解した上で使えばよいでしょう。ちなみに私が単独でプログラムを記述する場合はC++をメインで使いますが（もっとも最近はADPがメインですが）、誰かに引き継ぐ前提のプログラムの場合、関わるメンバを見て言語を選択します。そして、私の半径3メートル以内ではC++を使うことは残念ですがあまりなかったです。

一方でSQLに関してですが、さすがに長年の実績がある言語で、例えばパフォーマンス上で問題が発生した場合、様々な解決策（ノウハウ）があります。また私の半径3メール以内でも多くの人がSQLを使っています。SQLが出来ない人は少ないです。最近では、あるSQLが遅くて色々試行錯誤していましたら、一緒に働いている方から「何か知らんがこうすれば速くなった｣とアドバイスを受け実際に速くなったケースがあります。大人の事情で具体的な詳細は明かせませんが、そういうことは皆様の回りでも現実に多々あるでしょう。こういうことを言うと「実行プランをきちんと解析せいや」とかお叱りを受けますが当然そんなこともしております。
もちろん、SQLをどうこねくり回しても解決できないこともありますが、その場合でも案外ベタな解決方法（私のブログで紹介しているようにJOIN崩しとか、その他非正規化とか）があり、この辺りに関しては知る人ぞ知るという感じで、私の回りでは結構あるあるネタになっています。
このような言語自体の性質および実績から来る信頼性は追い込まれたエンジニアにとってはありがたい存在で、「SQLは良い」という意見については反対する気はないです。ただ、「SQLが効率的」といわれると普段から遅いSQLを速くするという作業も行っている身としては？と思うわけです。
またMDXという言語を知ってからは、JOINしながら集計することに関してはMDX（OLAP）の方がSQL（RDB）より強力という認識でおります。道具はやっぱり適材適所で過信はいけません。

業務アプリ限定で言いますと、SQLとOO言語を混ぜて使う必要があるために、SQLとOO言語のパラダイムの差を吸収する必要があるでしょう。いわゆるインピーダンスのミスマッチで、その解消策の1つとして『OO言語で統一する』という試みが昔から行われています。古くはオブジェクト指向DBなどで、今ではO/Rマッパーなんかですね。ここで某社長の思いの行間を読むと「OO言語に統一できるという考えがファンタジーだ！」ということで、その根拠にN+1問題をあげておられます。ちなみに「SQLはオブジェクト指向言語の数十倍の効率」自体は間違った主張ですが、その行間を言い直すとN+1問題ということになります。N+1問題はググれば出てきますし、私がSQLの実行パフォーマンスについて 2010で指摘した実験2は原理的にN+1問題と同じになります。
そして社長は「オブジェクト指向側に寄せるより混ぜて使うことを前提に上手く開発できるようなスタイルを確立すべし」ということが言いたいのでしょう。まぁ適材適所ですね。
ちなみに『OO言語とSQL（リレーショナルモデル）とのパラダイムの差を吸収することは難しいが、述語理論とSQL(リレーショナルモデル）との差はあまりないのでSQLを呼び出す言語を述語理論に基づいた言語にすれば上手くいくのでは』というのが私の仮説になります。
もう1つうんちく次いでに語りますと、「SQL系の言語で統一する」という試みもありました。4GLとか言っていたものです。これは早々に消えたかと思います。4GLが宣伝されていたとき、私はあまり関わっていませんでしたが「SQLでGUI」と言われても『どう組むんや!』ということは明白で、まぁやっぱり道具は適材適所なのでしょう。

「オブジェクト指向プログラミングが銀の弾かどうか？」というのはまだ結論が出ていないかと思いますが、最近では関数型の言語が一部ではクローズアップされています。ちなみにADPがベースにしているPrologという言語は述語理論を基礎においています。私は述語理論を押しているわけです。先のことはわかりませんが、オブジェクト指向プログラミングが昔の構造化プログラムと同じ道を行き、将来別のパラダイムがスタンダードになっているかもしれません。もちろんRDBが駆逐されているという世界もあるかもしれません。つまらない意見ですが、まぁ先のことはわかりません。

そして「SQLは銀の弾か？」と言われると『データを扱う上では候補ぐらいにはあげてもよいけどSQLはそもそもドメイン固有言語ではなかったですか？』。というのが私の意見になります。

以上、行間を読んで書いてみましたが、如何でしたでしょうか？ がんばりましたがさすがにSQLを持ち上げるのは厳しいです。つまらない結果ですがまぁ現実はこんなもんです。

最後に1つだけコメントしますと、このように書けば炎上はしませんが、多くの共感は得られるのではと思うのですが、まとめ記事では残念なことに主張すること自体を取り下げたようです。
いったい、彼は何が言いたかったのでしょうか？

騙されないようにする為に（適切な議論の方法）

素直さは如何に大切かという記事を書いたのですが、考えてみれば『それは私自身にも当てはまるのでは？』というツッコミがきそうですし、何よりこれはエンジニア向けに書いているので『判別つかない議論をどうすれば見極めれるのか？』とか『自身がどういう姿勢で臨めばよいのか？』という全うな質問もあるかと思います。
そこで、ITエンジニアが適切に議論（主張）を行う方法をメモしてみます。

１．自分の主張が正しことの裏を取る
もっとも大事なことは自分できちんと根拠を示すことです。では根拠となるのはどういったものでしょうか？
　(1) 実験する
　　例えば、『○○の方が速い』ということでしたら実際に実験してみればよいのです。実験というのは何より客観的ですのでその結果は事実として受け止める必要があるでしょう。ただ、実験では『たまたま自分のマシンでは速かった』ということもあるでしょう。したがってその実験が再現できるよう環境もあわせて提示しましょう。
SQLの実行パフォーマンスについて 2010ではこの方針にのっとって主張を行っています。

　(2) 論理的な考察
　　実験にプラスしてそれを補う理論的な考察も必要でしょう。ここで重要なことは、IT周りの議論が起こったとき理論的な考察というのに無理がある場合があることです。つまりITの世界は数学のように割り切れない面もあります。パフォーマンスという一見簡単な問題にしても純粋な数学からすれば充分に複雑です。いわゆる複雑系というやつです。それ以外でも例えば、工数が少なくなるというのはそもそも主観が入るでしょう。そのような場合は出来るだけ問題を簡単にして説明可能な実験に分割してそれぞれ実験を行えばよいでしょう。
[ADP開発日誌]SQL（JOIN）の実行パフォーマンスについて２０１１ではこの方針にのっとって主張を行っています。

　(3) 他のソースの引用
　　確からしい他のソースから引用するのももちろん良いでしょう。その場合引用元を開示すれば他の人が検証可能となります。この場合注意したいのはインターネットの情報はウソもあるということです。騙されないようにする必要があるでしょう。

２．騙されない為のテクニック
ITエンジニアたるもの技術的な論争についてはきちんと処理をしたいところです。口頭での議論だとついつい煙に巻かれることもありますが、ネット上ですと文章として残っていますので冷静に対応すればよろしいかと思います。
　(1) 発言者の過去の発言を検索し矛盾がないか検証する
　　残念ながら論理的に筋道が通った話ができない人がいます。また人というのは時間と共に考え方が変わります。相手の発言はそのようなことを考慮しているかどうかを検証する必要があります。その際にあらかじめ公開の場で質問をしておくと後々それが助けになります。

件の社長は、炎上したのでまとめ で、
　『SQLはオブジェクト指向言語の数十倍の効率』
という発言し、その根拠にコメント欄で、JOINの例を挙げたが、その一年後にツイッターで、
『JOINをなくすならAPサーバでキャッシュする。 集計関数をなくすなら、ORDER BYを禁止する。 SQLがイヤならRDBMSは使わないこと。 何度も書いているけれど、SQLで出来ることをAPサーバでやっても、【絶対に】DBサーバの負荷は減らない。 ただし、下手糞を除く。』
と発言しています。そしてそれを指摘すると今度は、シビアな設計で、
『JOINするしないでは、トレードオフの関係は、すべてのリソースに対して技術者の技量しかありません。』
といっています。発言に矛盾があることはもうお分かりでしょう。

　(2) 質問に答えない
　　少なくとも明らかな素人を除いて、質問に答えない（そして中傷してくる）相手はその質問自体に答えたくないのでしょう。
SQLの実行パフォーマンスについて 2010で私は件の社長本人に『SQLはオブジェクト指向言語の数十倍の効率』の考えは変わったのか質問しましたが、件の社長はそれには直接答えていません。逆に質問してきたり、独自の認定を行い、議論を終わらせたりします。少なくとも自己の主張が正しいとするならば質問には答えられるはずです。

　(3) 綺麗な図に惑わされない
　　これは一部の方に行われているが綺麗な図や表を用いてさも正しいという風に見せ付けることがあります。いくら綺麗にまとまっていても真のＩＴエンジニアたる者だまされてはいけません。よーく検証しましょう。

例えば、以下の図ですが、

一見綺麗にまとまっているでしょう。しかし、データ転送量の欄を見てみましょう。
『データ転送量　 トラフィックに影響 　JOINした方が少ない 』
とあります。これが成立しないことは、[ADP開発日誌]SQL（JOIN）の実行パフォーマンスについて２０１１で指摘しています。一見すると綺麗な表でまとめられているので気がつかないかもしれませんが、きちんとみれば分かります。また他の項目についてもきちんと説明せずに結果だけが表になっていることが分かります。

３．議論をする上での心構え
本来議論というのは、炎上をねらったり、闇雲に自己主張をするのではく、自己の見聞を広めたり、起こった事象に対して深い考察を行ったりするものであると考えます。

　(1) 議論は勝ち負けではない
　　これがぜんぜん解っていない人がいます。議論で相手を言い負かすとか論破するとかは少なくともITの分野では意味がありません。

　(2) 相手の主張に耳を傾ける
　　自己の主張に反論してくる人は、ある意味ありがたい人です。相手の主張を受け入れ真摯に答えましょう。私は、SQLの実行パフォーマンスについて 2010で、「OO言語側の最適化が不十分である可能性がある」と結論付けていますが、これはつまり一見すると『SQLはオブジェクト指向言語の数十倍の効率』ということが正しいと思える場面が存在することを認めています（その上でそれは視野の狭い経験にしか基づかないという指摘を行っています）。

　(3) 相手に感謝する、発言を憎んで人を憎まず
　　議論を行った後は相手に感謝の意を表する必要があります。私自身、SQLの実行パフォーマンスについて 2010という記事を書くにあたって再度勉強になりました。そういう意味では件の社長には感謝したいですが、それを『文盲のサル』と言われてしまっては腹も立ちますがそのような感情は捨てて、この場で感謝の意を表明しておきましょう。