>RSSベンチャー社長で技術者で株式会社ジーワンシステムの代表取締役。新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。2010/05/20炎上したので、論点を整理しておく。業務系の職務では、「効率を求めること」がトレードオフしてはいけない必要条件です(十分条件ではない)。医者でいうならば、「命・健康」と同じ、トレードオフしてはいけない必要条件です。効率が必要条件にならない職業もあるけれど混同してはいけない。2.SQLはオブジェクト指向言語の数十倍の効率オブジェクト指向言語を使い切るのと、全部staticで宣言してしまうような使い方と比べても、効率は数十%も変わらない。SQLとオブジェクト指向言語を比べたら、数百~数千%の差が付く。言語や手法を考えるとき、慣れてない人はできないから無限大の工数が掛かる。できない人を対象に比べても意味がない。工数は最終的にはコーディング量比例するから、簡単に証明できるし、パフォーマンスも散々書いてきましたが、RDBMSを使う以上、SQLで処理することを超えることは基本的にない。3.SQLとオブジェクト指向言語は分業すべき本来的には、スキルギャップが大きい技術を同じ人が担当することに無理があるので分業にすべき。現状では分業できてないので、全員がSQLをやるべき。初級シスアドのレベルを考えれば、全員ができてあたりまえ。何が問題か分業化すれば互いに専門家として尊重しあえるけれど、残念ながら分業化できない。分業化できない最大の理由は、オブジェクト指向言語が好きな人たち(技術者とは到底呼べない)が既得権を離さないから。オブジェクト指向言語が気になって仕方がない。それは悪いことではないが、技術者側の都合でしかない。新しいモノの追求はしたらいいけれど、必要条件の効率にどれだけフィードバックできるかという観点がなければならない。SQLが古かろうと気に入らなかろうと、数百~数千%の差が付くなら、まずそれをきっちりやるべき。新技術を取り入れるかどうかは、数百~数千%以上の差が付くかどうかで検討すればいいけれど、残念ながらRDBMSを使うのに分業化していないうちは、そんなモノは存在しない。分業化できれば、SQLが比較対象から外れるので、更なる効率化の余地はいくらでもありますけどね。いうわけか、「わたしが好き嫌いで話している」となるのですけれど、わたしに絡んでくる人たちは、絶対にトレードオフしてはいけない効率をトレードオフして「個人的な好み」を取っている。それで、既得権にしがみついて、いっぱしの技術者気取りで批判してくるわけです。わたしは理論値で話している。技術者として理論値を簡単に無視されたら、議論なんて成りたたない。多数決で言えば、RDBMSは最も普及している。SQLは初級シスアドに必須で出題されるぐらい、本来であれば最も普及している言語です。それでも、できない人(技術者とは到底呼べない)が多いだけ。その状況では、できない人に合わすよりも分業化して、お互いを尊重し合えるようにした方が効率的でしょう。早く既得権を離すべきです。人間性について言いたければ言えばいい。そんなことは何も生まないので、ネチネチと絡まれても困る。2ちゃんねるでもチラシの裏でも、他所でやっていただければ。反論は1、2、3に対して、4を考慮しながら書いてください。申し訳ないし、大変残念なのですが、賛同していただける方にはコメントしません。コメントする価値がないと判断したものにもコメントしません。理由は、過去のエントリーのコメントをみれば分かると思います。あしからずご了承ください。※編集部注:2010年5月20日16時40分、一部の適切でない表現を削除いたしました。12:13>わたしに絡んでくる人たちは、絶対にトレードオフしてはいけない効率をトレードオフして、「個人的な好み」を取っている。ほとんどの人が生島、あんたの人間性を批判してるんだよ。逆に聞くが、誰が効率を否定してる?人間性に問題があると感じれば直接批判するのが大人の役目だろ。おまえのように、自分の反対意見を汚い言葉で罵倒し、ケーワイケー氏やAC/DC氏、小島氏のように論についてではなく、人間性を問題にしている人をカスとかクズ扱いしておきながら、自分がカスとかクズとか罵倒しているのは効率を無視している人間だけとか嘘八百を並べ立てる、その腐りきった人間性こそ、2ちゃんねるのような便所にふさわしい。12:241.反論ありません2.反論ありません3.反論ありませんその上で言いたいのですが、私は「オブジェクト指向言語が好きな人たち(技術者とは到底呼べない)が既得権を離さないから」に猛烈な違和感を覚えますね。◇」までは完全に蛇足だと思います。それこそ、余計な蛇足をつけたために本来の趣旨を伝えるための「効率」を落としています。無駄な喧嘩をしたいのであればそのまま続ければよいと思いますが、それを嫌うのであれば、不要なコメントへの返答を控えるべきです。私のこのコメントまで含めて、「反論になっていないのでコメントしません」と切って捨ててください。12:27>>ExtensionTsuさん違う。生島が本来の自分の場所、2ちゃんねるに戻れば良いだけの話だ。向こうもきっとお前を待ってるぞ。気になったことを、簡単に。オブジェクト指向言語を使い切るのと、全部staticで宣言してしまうような使い方と比べても効率は数十%も変わらない。SQLとオブジェクト指向言語を比べたら、数百~数千%の差が付く。「どんな観点で」「何をどのように数値化して」「どういうシチュエーション/条件下において」「どんな計測方法で」「どれ位の母数の調査があった上で」なのかがまったく書いていないので。「私の経験上の感覚で」とかいわれても、おそらく多くの読者はそれで「あぁそうなんだ~」とはなりにくいように思われます。工数は最終的にはコーディング量比例するから、簡単に証明できるし設計にかかる工数も、コーディング量に比例するんですかね?私は、時々「反比例する」ケースを見かけますが。パフォーマンスも散々書いてきましたが、RDBMSを使う以上、SQLで処理することを超えることは基本的にない。RDBMSを使わない、という選択肢も最近出てきたように思われます。オブジェクト指向言語が好きな人たち(技術者とは到底呼べない)が既得権を離さないから。オブジェクト指向言語が気になって仕方がない。SQLが古かろうとSQL、厳密にはSQL86(ANSIによって最初に発表された最初の規約)が出されたのが1986年。オブジェクト指向プログラミング言語として知られるSimulaが開発されたのが1962年(startが。オブジェクト指向プログラミング言語であるSmalltalkが出てきたのが1972年。多数決で言えば、RDBMSは最も普及しているどんな母数に対してどんな調査をした結果として、なのでしょうか?このあたりを明言されたいのであれば「統計学的に優位な調査結果」を出されたほうが、より信憑性が高いと思いますよ?基本、私は一般論には興味がないのですが(おおむね不要であるというより、状況によって有害になることすら少なからずありえるので)。いっても、一般論としてそも成り立っているのかどうか、が、私にはちょっと判じかねました。12:53がるさん、こんにちは。何度か来られてますね。私の記憶がただしければ、あなたはコンシューマ向けの仕事をされているのでは?分野が違えば不毛な水掛け論にしかならないので、他所でやっていただければ。13:09どうやら@itも汚い言葉賛同のようでwhttp://twitter.com/Sikushima>私が罵倒するのは、「効率だけじゃない」とか、「だってOO言語で統一したい」とか、技術者側の都合を一般論に持ち出したときだけなのですけど......。ここまで嘘つけるな~その面の皮の厚さにびっくり。代表的なので、オブジェクト指向言語って書いただけで、VB6だろうとCOBOLだろうと、RDBMSを永続化に使うなら同じです。全部staticにしたって、配列を禁止にしたって、結果的には大した差はないのです。13:25敬称無しの名指しは止めません?知り合いならともかく・・・せめて「さん」くらいつけましょうよ。主観なら主観で、「何パーセントだと断言」せずに、正確に書くのが筋かと。××のような規模の××のような環境で作った××に××ぐらいの人数・工期がかかったけれども、これを××で作ったら××ぐらいかかったと推測される、かな。上のようなことは今までに断片的に別々には書かれているとは思いますので、改めて書く価値がどれほどかは・・・ですが、そのように明記しておくと主張の妥当性はわかりやすいと思います。私も数値は出せないので主観・経験値のみですが、OO言語を使った場合に、社内業務システムに関しては、全部static(インスタンス化ゼロ)で作ったからといって、そうでない場合より生産性なり品質・保守性が著しく低くなったと感じたケースはあまり多くないです。#ただ、OO言語でインスタンス化を使ったからといって、#その性質を使いこなせているプロジェクトがじゃあそもそもどれだけ#あるのかが怪しいところでし、生かしていない故にOOの生産性優位を#生かしきれていない多々ケースもあるかとは思いますがそれは余談http://kmaebashi.com/この辺のページを見ると、あちこちに分散しているので敢えてポイントしませんが、「OO言語のメリットと呼ばれていることの多くはCでも出来る。その中にはCのテクニックであまり知られていないものも含む」ことが散見されます。純粋に技術で閉じて言えば「OO言語で全部staticがどれほど悪か」は、たったそれだけの短い命題ではほとんど議論不能で、善とも悪とも言えない様な。OO言語で、もちろんフレームワークの利用等でインスタンス化や継承が必要になってくれば、当然「それ以外は全部staticに」なことをするメリットは減ると思います。利用して開発したプロジェクトで(正しく組んだならともかく)今回の設計・実装するんだったらVBやCの方が良かった、と多数の人間が感じてしまうようなケースも。まともにデータがないなら数値的に優位云々言うな、という意見が出ることは私にも理解できますが、ケースバイケースで「OO言語でstaticがさほど悪くない」のは別によくあることかな、と。#ケースバイケースを言い出せば、SQL書かなくても、ともなりますが、#それを言えばRDBMSにする必要もあるの?まで、色々と。技術本位で言えばRDBMSにする必要のないシステムまで使ってないか?とかDB設計がまともにできてなければそりゃ生産性落ちるだろ、とかまぁ色々と。結論ありきじゃなくて世間の誤解に物申すというレベルでは生島さんはそんなに変なことを言われているとは思わないですね。生島さんはそれなりには自分の主張の対象になるシステムについて時々書かれてますし(単記事ずつだと見えにくいこともおおいような気もしますが)。#個別に異論があるとかないとかは別としてまた別の例で、DBサーバ(RDBMS)とAPサーバが別で、DBサーバは他システムとの併用等の都合でリソースが著しく制限されていて、なるべく処理はAP側でしなければいけない場合・・・なるべく処理は業務側で、になりました。思い切り特殊例ですね。数値云々は、誰か研究してほしいなぁ。いう研究をまともに出来る機関ってあんまりないような気がします。日本の大学がやるには一般論で言えば現場的すぎるし。あと、別の余談で、「例外ケースを思い切り切り捨てて断言した方が(炎上するかもしれないが)主張がよく伝わって目的が果たせる」場合もあったりしますね。生島さんが何を考えて書かれているのかわかりませんが。14:15ぴあちゃんさん(敬称付けにくい......)、こんにちは。私は敬称にはこだわらないです。小学生に「おっさん、こうちゃうの?」って言われても、それが正しいと感じたら聞くし。敬意を持ってないのに敬称を付けられても慇懃無礼ですよね。14:15私も純粋な好奇心から、既得権って何なのか知りたいです。14:20>それが正しいと感じたら聞くし。それが自分に都合がよければ聞くし。14:52いろいろ、雑感。いう文章を書いていると、「当たり前のことしか書いてない」という人が出る一方で、前提が抜けているとかいってくる人も出ます。技術者の猛烈な勘違いがあるの。コンピュータはあらゆる前提を書いて上げなければ正しく動きません。杓子定規に書かないといけない。場合によっては仕様書レベルで漏れがあっては困ります。人間に向かって書いている文章と、機械のために書く仕様書では性質は違うのです。私は、ここでは人間に向かって書いていますから、普通の人間なら理解できるはずと言う前提は無視しています。「当たり前のことしか書いてない」という人が出るというということは、理解できる人はいるのですから、それでよいのです。アラを探して突っ込んですっきりしたいというなら、まぁ、それはそれで結構な話ですけれど、そんな立派な技術者なら、一円の得にもならないここでやるよりも、実際の仕様書やプログラムの抜けを探して廻った方が建設的ではないですかね~。理論値で得をするはずのユーザーさえ説得できないから、こんなところに怒りをぶつけているのではありませんか?現実は、あなたが最低とかくずとかいう人たちに頭を下げて仕事をせざるおえないわけです。業務システムを作っている人は誰でも同じです。「本当はこんなのおかしい」そう思いながら、食べるために仕事をせざるおえない。OOP原理主義の人も同じジレンマを抱えているのだと思いますよ。理論だのスキルだのと考えているうちは何もかわらないでしょう。資本や政治にはかなわない。価値の大転換をしないと。「良心的に」「正直に」に商売していることが価値にならなければ、なにも変わらないと思いますよ。歴史的にみても、まず理想があって、それを実現する技術(科学技術だけではありません)を開発するからイノベーションが起こるのですよ。ビジネスなんかそのずっと後に生まれてくる話です。15:23Kentaさん生島さん私の前回の発言でややこしくなってしまっていたら申し訳ないです。私が言いたかった事は以下のような事です。生島さん及び皆さんにお聞きしますが必要十分なパフォーマンスが確保出来る場合に過剰な実行効率を追求せずにLLやORMを使って開発効率(これも効率ですよね?)を高めたり、OOPによる抽象化で可読性や保守性を求める事はいけない事なのでしょうか?生産性が上がる事でリリースも早くなりますし保守性が上がる事で拡張に対しても開けます。これも技術者側の都合でしょうか?過剰な効率重視も技術者側の都合では?生島さんが気にいらないとしても排他的になる必要は無いのではないでしょうか?私は過剰にパフォーマンスを追求するよりは生産性や保守性を重視するので効率第一主義の生島さんとは考え方は違いますが、生島さんの方針を否定もしませんし理解もできます。違うスタンスと言うだけです。私の場合は駆け出しの頃にスパゲッティコードのメンテが多かったのでこのような考え方になりましたがバッチ処理のパフォーマンスで苦労する事が多ければ生島さん寄りの考え方になっていたかもしれません。お互いに違う考えを尊重し合えば良いのではないでしょうか?また、新しい技術に対して懐疑的になれと言うのは同意します。16:27はじめまして。16:32初めまして。SQLが重要以外賛同できません。>>オブジェクト指向言語を使い切るのと、全部staticで宣言してしまうような使い方と比べても、効率は数十%も変わらない。オブジェクトはメモリの中にヒープ領域(クラスの実態の保持)とスタック領域(クラスの参照のアドレスポインタの保持)で成り立っています。使い切ったらシステムが止まります。効率どころではないです。>>本来的には、スキルギャップが大きい技術を同じ人が担当することに無理があるので分業にすべき。現状では分業できてないので、全員がSQLをやるべき。これは基本的に賛成です。SQLを重点的に学習すればオブジェクト指向を軽視して良いという判断には賛成しかねます。コラムの中に出てきてますが、SQL言語を下手に扱うと業務に支障が出る分野です。SQLを複雑に記述しシステムを制御してはいけないのです。基本的にシステムの制御は言語側で行います。そのために大規模システムではAPサーバー(SQL部門専門のサーバー)を立てたり、小規模ではフレームワークやツール(O/Rマッピング)等で制御します。これらを扱うにはオブジェクト指向への理解が必須です。17:32もうちょっとだけオブジェクトについて詳しく書きます。=10;と書くと、メモリ領域に以下の様に記述されます。Sugaku();i.SetA(10);を細かく解説します。Sugaku();と書くと、メモリ領域に以下の様に記述されます。※(ヒープ領域と言う)と値を確保する領域を確保します。00000000と値を格納します。Static変数はスタック領域に値を確保することを指示します。大量のアクセスがある箇所に使用したらシステムが落ちるのはそのためです。以下がJAVAではありますが一般的に言われていることです。・スタック領域クラスのポインタアドレスを確保します。プリミティブ型データ(基本型データ{int,long,double等})やStatic変数もこの領域に確保されます。・ヒープ領域クラスの実態を保持します。(なお、構造体は含まれません。構造体はスタック領域に確保されます。18:26皆さん、こんにちは。勘違いがあるようですが、効率というのは工数とパフォーマンス両方を指しています。本文でもそうなっていると思いますが。下手くそに書けばどんな言語でも無限大に無駄ですし、無限大に遅くなります。比較はできる人で比較しないと意味ないのです。RDBMSを使う以上、SQLをきっちり使い切った方が工数、パフォーマンスともに下がります。パフォーマンスはもういうのも馬鹿らしいので書かないけれど、RDBMSを使う以上、必ずSQLは必要です。その単純なSQLの要素は、複雑なSQLに必ず含まれることになります。複雑なSQLでは要素の重複はある程度避けれますが、単純なSQLではすべて書かざるを得ず、SQL文の合計だけでも、単純に書いた方が多くなります。そこにSQLで可能なロジックがOO言語に必要になる。分割すればするほどロジック内のマッピング要素が増えますから、工数が増えるのです。SQLができない人に合わせることが正しいか?正しいとしましょう。OO言語をできない人に合わせることも正しくなりますね。200~2000%となります。どちらかを諦めるとしたら、効果で選ぶべきでしょう。できない人がいるというのは技術者側の都合でしょう、技術者の都合で効果が大きい方をあきらめたらおかしいし、技術者の都合で効果が大きい方は見逃せても、効果の小さい方は滅多打ちにするって、どう考えてもおかしいのです。技術者としては効率で選ぶべき。会社としては、教育コストを考えて選択することはあろうかと思いますけれど......。19:08こんにちは。ふむふむ、非OO言語よりもOO言語の方がSQLと比較した場合の工数(効率?)の差が大きいものなのですね。ところですみませんが、私はOO言語がわからないので比較ができないのですが(A).OO言語大好き。SQLは単文程度(あるいはぐちゃぐちゃ)。(B).SQLは会話のペースでできて、OO言語もわかる。(A)の人は、このように作ってしまいがち」といった簡単な事例をご紹介いただくことはできますでしょうか?ソースまでとは言いませんが、見てみたいです。いままで、この比較はなかったような・・・。200~2000%ですね。19:48何にしても、誰でも「普通」という認識は持っているものです。得に宗教論争になりがちな好き嫌いが入るものは、誰もが「普通はこうする」というのを持っています。普通と思っていることは実際に普通かどうか分かりません。できない人の例をいくら出しても、下手くそは、無限大の下手くそを作れるから意味がないのです。技術者なら、MAXつまり理論値で測らないと、どこまで行っても水掛け論です。職務の目的、理論値が重要なわけです。19:56ああ、なるほど。「SQLとオブジェクト指向言語を比べたら、数百~数千%の差が付く。140~1000%の比率でしたか。20:52宝春さん、doさん、こんばんは。大概、OO言語が(本当に)ちゃんとできる人は、やっぱり、効率をちゃんと見ていますから、SQLもちゃんとできる人が多いです。いう問題は、結局、個別の問題になってしまいます。技術者としては、理論値で測るしかないわけです。繰り返しますが、非道い例(下手くその例)は無限に下手くそを作れるので、議論をするのは、理論値で議論しなければ技術者としてはおかしい。理論値で測って差が大きい方を無視するなら、医者が癌より水虫を優先するのと同じです。「理論値じゃない!」というのは技術者とは呼べない。21:06何というか、昔に書いたごく小さな例です。http://www.g1sys.co.jp/column/_sql_2006_227_1.htmlストアドプロシージャで分業するならば、最初に聞いた人のイメージを超えるチャンスは数ヶ月になりますが、5~10分の問題というよりも、読んだ瞬間にSQLでできると考えなかったら、最終結果は回答例1か2になりますね。21:26生島さんにしつもーん。22:27とりあえず知りたいことが2つあるね。何人かの人が書いてるけど、「SQLとオブジェクト指向言語を比べたら、数百~数千%の差が付く」とかの根拠はどこにあるのか知りたいね。それから、OO言語な人たちの既得権って何かな?どんな既得権があるんだか、さっぱりわからんのだけどね。具体的に理論値で教えてくれるとうれしいね。思うに、そのあたりが具体的な根拠も説明もなしに、いきなり飛び出してくるから、みんな戸惑うんじゃないかな。22:29あと、頼むから1日でコメント終了するのはやめようよ。22:39こんばんは。なりがちということですかね???私は80点でした。この設計を素直に書いてみたら3でした。自分で要件から外部設計をした場合は、違う解答になったかもしれません。いうか、私は技術者としておかしいのか・・・。言われると傷つくものですね。たしかに理論値よりも感覚的に計ることが多いし、おかしいのかも。23:26ごめんなさい。今回は最後にしますから許してください。えーと、私は特に本分を無視したコメントばかりしてしまってすみません。いや、このスタイルは変えませんけど(笑)ただ、ここはコメントがしやすくて、他の方とのコミュニケーション?も楽しんでいたのでやっぱり一日で閉じちゃうのは残念です。今までと比べるとかなり柔らかい表現になっていたので、そこまでばっさりとやらなくても良いのではないかと思いました。命題に対しては反論はありませんので、もう黙ります。23:35>RDBMSを使ってSQLより効率(工数・パフォーマンス)で超える手法はないいや、全くもってその通りです。それ(SQL)が真っ当な方法ですからね。後からつけたものの方がかゆい所に手が届かない事は多いです。>効率というのは工数とパフォーマンス両方を指していますなるほど。OOが力を発揮するのは再利用性と可読性と保守性だと私は思っているので、そもそも同じ土俵で争う二つでは無いと思うのですが、如何でしょう。23:38別に一日で閉じるとか意味ないです。コメント欄があっちこっちに行ってるから、整理してまとめるために閉じただけの話。結局、新しい方に来てるのですけれど、明後日のコメントが多いのは困るね~。23:45あれ、それ、おいらへの返答?質問に答えてもらえたのかな?なんかはぐらかされたような気がするんだけどね。答えられないってことで。00:44こんばんは。「RDBMSを用いたシステムの場合、アプリケーション側で処理をするよりも、RDBMS側で処理をした方が工数もパフォーマンスもいい」ということだと解釈しています。このことに関しては、私も賛成です。気になることが1つあります。200~2000%のことだと思うのですが、この値は理論値として最も重要なものが欠けています。それは「導出過程」です。理論値を技術的に検証することは、導出過程を検証することです。比べっこするものではありません。矛盾なく導出された理論値は、誰が何と言おうと正しいのです。この値には導出過程がないため、理論値とは言えません。「実験値」かというと、そうでもありません。それは「実験条件」がないからです。実験値の検証で重要なことは、再現性です。実験値と共に提示された実験条件で再実験し、同じ値が得られたならば、その値は技術的に有効なものですが、その実験条件がありません。理論値でも実験値でもないならば、残念ながら技術的にはあまり意味がある値ではありません。01:45回答ありがとうございます。>大概、OO言語が(本当に)ちゃんとできる人は、やっぱり、効率をちゃんと見ていますから、SQLもちゃんとできる人が多いです。いう問題は、結局、個別の問題になってしまいます。その認識でしたら特に違和感ないです。(それならなぜOOPに対してそれだけの敵意を持たれているのかはわかりませんが、きっと過去によほど酷い目に遭われたのでしょうと想像します)あとはgenekさんのおっしゃるように数値の導出過程でしょうかね。生島さんの体感上の数値であっても別に構わないのですが、その場合でも明記すべきことだと思います。01:52ああ、おいらが知りたいことが、genekさんが質問してることだよ。答えてもらいたいものだね。doさん、>生島さんの体感上の数値であっても別に構わないのですがこれは変だよ。生島さんは「理論値」で話をしてるそうだから。体感上の数値とか、経験からのカンってのは、理論値じゃないからね。生島さんがそんな答えを返すわけないよ。さあ、生島さん、みんなが答えを待ってるよ。できたら、既得権についても知りたいんだけどね。02:02@ITの担当殿へここも早く手を打たないと、みながわ氏より自己顕示欲が強い分、もっとひどいことになりますよ。ちなみにここの馬鹿社長さん、何で毎回炎上するのか、少しは考えてみれば分かると思うのですがね。彼の人間性に興味は無いが、少なくとも自分の技術力の身の程もわきまえた方がいい。口は立つが、幅は狭く、底は浅い。02:21AC/DCさん私としては論拠の裏づけさえ明確にしていただければいいのです。ことだと思うのですが、この値は理論値として最も重要ななぜ?意味が分からない。書いているのにそれ理論値と違うがな。06:14個別の例外を上げても意味がないし、できない人の理屈を出しても意味がない。何度も何度も書いているように、RDBMSを使う以上、SQLをきっちり使い切った方が工数、パフォーマンスともに下がります。パフォーマンスはもういうのも馬鹿らしいので書かないけれど、RDBMSを使う以上、必ずSQLは必要です。その単純なSQLの要素は、複雑なSQLに必ず含まれることになります。複雑なSQLでは要素の重複はある程度避けれますが、単純なSQLではすべて書かざるを得ず、SQL文の合計だけでも、単純に書いた方が多くなります。そこにSQLで可能なロジックがOO言語に必要になる。分割すればするほどロジック内のマッピング要素が増えますから、工数が増えるのです。最終的な効率は、システムの規模によって違う。理論値は極小のもので考えるしかない。極小のもので大きな差が付くものは、理論値では絶対にひっくり返らない。実際のシステムでは規模nのm乗(mは1以上)に比例するから、大きなシステムほど差が広がる。OO言語がダメとか言ってない。OO言語でstaticというのも、何度も何度も書いているけれど、理論値として確かに差が付くけれど、SQLから比べれば誤差でしかない。言語解説しに来る人が現れたりするけれど、誤差に気を配るのであれば、もっと大きな差が出る部分に気を配るべき。医者で言えば、水虫で癌の患者に、水虫から手を付けるのと同じ。OO言語でstaticっていうのは、水虫の治療が下手くそなだけ。癌の治療をほったらかしている連中が、「水虫の治療が下手くそ」って他人を攻めても意味がない。水虫の治療が上手いのは、それはそれで意味があるけれど、癌を前にしては意味がないと言ってる。分業制にすれば、OO言語の優れているところが存分に発揮され、OO言語の部分の再利用性は非常に上がるので、一部のエース級以外は要らなくなる。本当に再利用性は高くなるので、一部のエースも常時は要らなくなるかも知れないけれど。お互いに専門性を高めないといけないので、OO言語でstaticなんて話にならない。分業制ではなく、技術者がOO言語もSQLもやらねばならない現状ならば、まずは、全員がSQLに向かわないといけない。OO言語でstaticなんて誤差を気にしている場合じゃない。200~2000%この表現がよくわからないので確認させてください。これって工数の話ですよね。07:14us234さん、おはようございます。最初のはまちがってたね。