自分の考えを述べさせていただきます。

>素人レベルですから、とても読めたモノではない。
>これが混じると本当に保守できなくなるのですけどね……。

まずこれはさすがにないでしょうと。素人が作るものなら読めるハズ。

それから問題の本質を改善する考え方がずれている気がします。
（特にシスアド初級にこだわっても・・・）
自分だったら優秀なDBエンジニアを用意してもらいます。（できれば複数）
その人たちにシステムで使われるSQLの調査をしてもらい、
パフォーマンスに問題となる部分があれば作成者に意図を聞いた上で
改善案を出します。（継続的に調査できるシステム作りが大切）

問題が頻発するようなエンジニアがいて改善の余地がないなら
プロジェクトから外れてもらうか無難な部分の開発に従事してもらうだけです。

「神エンジニアを立てること」これが日本のIT業界に必要だと思うのですが
なかなか立てようとしない上に立てたとしても妙なプライドが邪魔して
従おうとしない人がいることが問題なのだと思います。
そこを従わせることがPMの役目だと思うのですが。。。

補足：
どこのプロジェクトに行ってもDBAが誰なのかわからなかったり
今まで起きた問題の共有が全く行われていなかったりすることが問題だと思います。

DBの神様が誰か事前にわかっていたらSQL作る前に相談したりして
スムーズに開発ができる気がします。
わからないのに作らせてしまうプロジェクトが悪いんですよ。

O/Rマッパーは神が認めた部分にだけ使えばいいんです。

・・・トップダウンかボトムアップかの違いですね。
まぁ両方できた方がいいですね。

やのさん、こんばんは。

> それから問題の本質を改善する考え方がずれている気がします。
> （特にシスアド初級にこだわっても・・・）

こだわるも何も、初級シスアドは共通の認識としての最低レベルの提示でしかないです。

わたしは何もできないですが、初級シスアドすら超えれない人間は、顧客の手で抹殺してくださいと言うことです。時給900円でももったいない。プロを名乗るなんてトンデモない！恥を知れ！！と言うことです。

わたしがプロゴルファーなら、石川遼選手に負けても、一週間ぐらい寝れないと思います。自分の飯のタネで普通の高校生に負けたら、恥ずかしくて生きてられないというか……。

>> 素人レベルですから、とても読めたモノではない。
>> これが混じると本当に保守できなくなるのですけどね……。
>
> まずこれはさすがにないでしょうと。素人が作るものなら読めるハズ。

話にならない。
素人の書いたSQLは本当に読めません。

http://www.g1sys.co.jp/seminar090515.html

SQLだけでできる人は少ないのでちょうどよい。
OO言語、SQL混在でよいから10人ぐらいに書かせてみたらいい。
本当にできない人のは読めません。

生島さん、こんばんは。
saki1208です。

>自分だったら優秀なDBエンジニアを用意してもらいます。（できれば複数）
>その人たちにシステムで使われるSQLの調査をしてもらい、
>パフォーマンスに問題となる部分があれば作成者に意図を聞いた上で
>改善案を出します。（継続的に調査できるシステム作りが大切）
こういった感覚がすでにズレていることを感じられないエンジニア?のなんと
多いことでしょう。
エンジニアではなく、ただのブローカーだ!これじゃぁ。
実に嘆かわしい...

自分でできないことを人に頼ってでもしてもらう姿勢は認められるべきでしょ
うが、はなからそんな気持ちでは...
訳の分からないプライドは持ち合わせてもプロとしての自覚が無いのでしょう
ね。

大体が素人のSQL(に限りませんが...)意図が伝わってこないので読めるはずも
無い。
なんでそんな風に書いてるのか気持ちが伝わってこないんですよね。
# ある程度の素地がある人のはSQLに限らず、何となく気持ちが伝わってくる
# んですよ。

>「神エンジニアを立てること」これが日本のIT業界に必要だと思うのですが
>なかなか立てようとしない上に立てたとしても妙なプライドが邪魔して
>従おうとしない人がいることが問題なのだと思います。
こんな風に考える人の気持ちがわからない。

「お前はもう、死んでいる」ってケンシロウなら言うでしょうね。

連投すみません。

手を動かせないエンジニアは、既にエンジニアではありません。
肩書き上はエンジニアだったとしても...

ご隠居ですよw

saki1208さん、こんばんは。

>> 自分だったら優秀なDBエンジニアを用意してもらいます。（できれば複数）
>> その人たちにシステムで使われるSQLの調査をしてもらい、
>> パフォーマンスに問題となる部分があれば作成者に意図を聞いた上で
>> 改善案を出します。（継続的に調査できるシステム作りが大切）
> こういった感覚がすでにズレていることを感じられないエンジニア?のなんと
> 多いことでしょう。
> エンジニアではなく、ただのブローカーだ!これじゃぁ。
> 実に嘆かわしい...

なんというか、本当に専門家が必要であるなら提案段階に必要ですね。
後からできる修正ってたかが知れているし、そこに至るまでに出した工数の損失ってどれぐらいか分かっているのだろうか……。

SQLができるようになるには、今なら、OOを水準以上にできないと、SQLに取り組んでいる暇はないしね。

結局、単純な話、顧客が気づいてスキルチェックして価格交渉しだしたら、業界は変わると思っています。
そうなれば、生き残るのは、技術力のある本物のプロパーか、泥をかぶってきたフリーランサーか、問題意識を持っている派遣ぐらいしか生き残れなくなるでしょう。

一旦、諦めた人も帰ってくるし、しがみついている人は他所にいくでしょう。
正常化、つまり技術力を評価する土壌につながると考えています。

ちなみに、わたしも、ご隠居ですけどね……。
わたしは指一本打法よりタイピングが遅いぐらいですから（苦笑）

最近は、ペアプロの早さにびっくりすることが多い。
ペアプロは良いぞ～。

少し、語弊があるようですw
敢えて突っ込みますが...
キーパンチのスピードではないです。

その後の保守作業やシステムの壊れ方まで気が回らないのでしょうね。
他人に頼んでもそこは自分達でなんとかしなければならないのに...
# できなくて外部の人間に無茶振りするのがミエミエ

ペアプロは良いですね。
立場上は新人または多少毛が生えたぐらいと組まされますが...
逆に新鮮な視点で改めて気付かされることも多いです。

あぁ、またまた連投すみません。

なんと言うか、飲み過ぎでしょうか...
ものすごく誤解を受けるような文章になってる気が...

>システムの壊れ方・・・
分けも分からずメンテして壊すってことで...

>他人に頼んでもそこは・・・
作るときはってことです。

今日はもうダメかな...

いつも楽しく拝見させて頂いております。
多忙のため、しばらく見ていなかったのですが・・・

見ていないうちに、こんな展開になっていたとは、驚きです。

技術的なお話で言うと、DBサーバ側の問い合わせ言語であるSQLと、
APサーバ側の「RDBとオブジェクトの橋渡し役」であるO/Rマッパーを
同系列で対決させてしまっていることに無理があると思います。

どちらも補完的な役割があるので、どちらが優秀かという議論は不毛な気がしてならないのです。

似たような話ですと、「DOA対OOA」「RDBMS対OODB」といったところになるのでしょうか？

ちなみに、私は今ほどSQLが主流になっていない時代からやっていますので、
SQLですら一過性のはしかのように思えます。
表の合成や集計処理などが一回のSQL文を流すだけで行えるのは
便利なのですが、多用しすぎて「副問い合わせの副問い合わせの副問い合わせの副問い合わせの副問い合わせ」
を行っているSQL文(本当にあるんですよ!!)を見たときはゲンナリしましたね。
COBOL時代でよく使われていた「コントロールブレイク処理」というのも、
意外と早いんですよ!SQLとストアドを組み合わせてループさせるよりよっぽど早かったりして。

それはそうと、毎回コメントご苦労様です。もしかして、全員に
コメントを書かれているのでしょうか？
コラムニストは、全員に返答を書くよう義務付けられているのでしょうか？
今回の件で、すっかりコメントや
新しい記事を書く気を失せてしまったのではないか？と
心配していましたが、また記事があったので一安心です。

こんばんわ。

>自分だったら優秀なDBエンジニアを用意してもらいます。（できれば複数）
>その人たちにシステムで使われるSQLの調査をしてもらい、
>パフォーマンスに問題となる部分があれば作成者に意図を聞いた上で
>改善案を出します。（継続的に調査できるシステム作りが大切）
>問題が頻発するようなエンジニアがいて改善の余地がないなら
>プロジェクトから外れてもらうか無難な部分の開発に従事してもらうだけです。

大炎上している開発なら時間的なことを考えると仕方が無いこともあるかも
しれないけど、本音は頼りたくないですね。
自分で解決したいし、そんな問題があるSQLなんて作りたくない。そのための
知識も欲しいし、ましてや、それが原因で外されるなんてそんな屈辱を
味わいたくないので、だからいろいろと勉強はしてます。

開発に携わっている人はどれだけの人が危機意識持って仕事や勉強してるん
だろうか？と最近よく思います。自分は、やっぱり危機意識持っていて
生島さんが書いてあるようなような淘汰に近いことがそう遠くない時期に
あるんじゃないか？と思うと今の経験や知識では、生き残るのが難しいん
じゃないかと思いいろいろと勉強してますが・・。

君は（自分は）生き残ることができるか？

こんばんは。

SQL を読みやすく書くには、それなりにコツは要りますね。

言語仕様はイマイチなんですよね。
数学臭を隠そうとして失敗した、みたいな印象です。
List comprehension にして欲しかったなあ．．．
http://en.wikipedia.org/wiki/List_comprehension

下手な人が書いた SQL は、
メモしながら整理しないと読めないです。
まあ、そうやって苦労して読んでも、大抵間違っているのですけどね。
理解していないから、わかりにくくなってしまう訳で。
（なんという時間の無駄）

まあ、でも RDBMS がなくなることは、当分はないでしょう。

こらからは、Key-Value ストアという声もありますけど。
あれって、単に RDBMS のインデックス（B+ 木）だけを取り出して、
単機能 DB にした訳で。

RDBMS のテーブル全列に複合インデックスを張ると、
Key-Value ストアが RDBMS 内に作成されるわけですよ（笑）。
結局、SQL モドキ を使うことになるんじゃないかなあ。

OODB、XML DB なんかは、ニッチで終わりそうだし。

ディスクにデータを格納する、という前提なら、
やっぱり、RDBMS のように、タプルで入れるのが、
ベストじゃないか、と思います。
なんせ、一度入れたら簡単には動かせないですから、
データ構造を事前にどれだけ柔軟に設計できるかが重要な点でしょう。

逆に、RDBMS の時代が終わるときが来るとしたら、
それは、ハードディスクが、
別の記憶装置に置き換わるときじゃないかと。SSD とか。

saki1208さん、おはようございます。

悲しいことに思考のスピードでタイピングできないことにイライラして、考えたことを忘れていくことが多いのです。
忘れたことで更にイライラして、手の速い子が横で打ってくれるとものすごく助かる。
歳は取りたくないものですね。

ひらさん、おはようございます。

O/Rマッパーを同列にしているつもりはないですが、O/RマッパーがあるからSQLがイランという人間がでるのでね。
O/Rマッパー云々ではなく、RDBMSに変わるものを作れと言ってるわけです。

>「副問い合わせの副問い合わせの副問い合わせの副問い合わせの副問い合わせ」

単にへたくそなだけじゃないでしょうか。そんなモノを書く人間をSQLができる人とは呼ばない。
特にテーブル設計がよくないのでは。
ないときはｘｘｘが、あちこちにありそうhttp://el.jibun.atmarkit.co.jp/g1sys/2009/08/post-adf3.html

士郎さん、おはようございます。

わたしが淘汰される方が早いとは思いますが（苦笑）、まぁ、何にせよリストラは起きるのですが、初級シスアド以下でもいいなんて考える人は真っ先に対象でしょうな。
せっかくだから既得権者含めてガラガラポンをやって欲しいな。

ronさん、おはようございます。

> OODB、XML DB なんかは、ニッチで終わりそうだし。

XMLなんかはもう少しインフラ、ハードがよくなったら考えれるかも知れませんが、まだ汎用機から固定長テキストを受け取ることも多いから……。
汎用機すらまだまだなくならないのに、RDBMSの需要は簡単にはなくならないでしょうから、素直にSQLの勉強をすりゃいいのに。
まぁ、わたしが何を言っても動かないけれど、都銀とか生保とかが「全員にオープン系はSQLのスキルチェックをします！」とか言ってくれたら、一瞬で業界全体に伝染しますけどね。

生島勘富さん

>わたしがプロゴルファーなら、石川遼選手に負けても、一週間ぐらい寝れないと思います。
>自分の飯のタネで普通の高校生に負けたら、恥ずかしくて生きてられないというか……。

彼、賞金王ですけど今年のプロゴルファー全員
寝たらダメってことですか・・・
技術が自分より上なのを認めて、彼から学ぶのがプロだと思いますが。

>話にならない。
>素人の書いたSQLは本当に読めません。
>
>http://www.g1sys.co.jp/seminar090515.html
例題を出してくる意図がわかりませんが
この問題に対して、普通の人が書かれたSQLがよくわからないものだった。
と言うことでしょうか？
結構、職人的なSQLになると思うので正答率は低いでしょうね。
あまり机上で出すレベルの問題じゃない気もします。

saki1208さん

>>自分だったら優秀なDBエンジニアを用意してもらいます。（できれば複数）
>>その人たちにシステムで使われるSQLの調査をしてもらい、
>>パフォーマンスに問題となる部分があれば作成者に意図を聞いた上で
>>改善案を出します。（継続的に調査できるシステム作りが大切）
>こういった感覚がすでにズレていることを感じられないエンジニア?のなんと
>多いことでしょう。
>エンジニアではなく、ただのブローカーだ!これじゃぁ。
>実に嘆かわしい...

問題解決のための提案に過ぎないのに。。。

プロ野球に例えるなら
SQL＝守備
だとしましょう。

別に守備が苦手でもDHやファースト、代打、代走、
あるいはピッチャーなど補ってあまりある能力があれば
活躍することは可能だと思います。

また守備に関しても先輩、後輩から学んだり
守備コーチから教わることもあると思います。

要は優秀な守備コーチを雇って責任を持って
面倒見てもらえってことです。

みんなプロなんだから守備は自分なりに学ぶと思いますが
守備コーチに従うのも必要でしょってことです。

やのさん、おはようございます。

どうでも良いことですが、石川遼選手が高校生のアマだったとき優勝してプロになったわけでしょう。
勝負の世界ですから、プロ同士で勝ち負けに年齢など関係ない。
高校生のアマに負けたほぼ全員が寝れないほど悔しい思いをしたのは事実です。
相手が100年に1人の天才であったとしても、私がプロゴルファだったら、耐えれなかったと思う。

> あまり机上で出すレベルの問題じゃない気もします。

机上じゃないから意味がある。
あなたはどんなのを思いつきましたか。混在型になったでしょう。

そんなものは読めん。（現実には読んでますけどね）

こんな複雑なSQLの方が読めないという人も出てくる。
そりゃレベルが低かったら読めんわな……。

お客様が「アレ？」って気づいてくれればOK。

ちょっと酷いなと思ったので。

saki1208さんのコメントですね。

>>自分だったら優秀なDBエンジニアを用意してもらいます。（できれば複数）
>>その人たちにシステムで使われるSQLの調査をしてもらい、
>>パフォーマンスに問題となる部分があれば作成者に意図を聞いた上で
>>改善案を出します。（継続的に調査できるシステム作りが大切）

>こういった感覚がすでにズレていることを感じられないエンジニア?のなんと
>多いことでしょう。

（将来的に）どうあるべきだ、とか
（本来）どうあるべきだ、という理想論は置いておいて、
とても現実、現状を踏まえている意見だと思いますが？
何が嘆かわしいのですか？

何がずれているのですか？
大人数が携わる開発において、
現状シスアド級知識を持つ要員が少ない状況において、
これ以上に取りうる方策があるのですか？

>パフォーマンスに問題となる部分があれば作成者に意図を聞いた上
こういう状況が発生するという時点で、シスアド級知識では解決できない問題が起きていると想像できませんか？

>問題が頻発するようなエンジニアがいて改善の余地がないなら
>プロジェクトから外れてもらうか無難な部分の開発に従事してもらうだけです。
この文章を無視していませんか？

>エンジニアではなく、ただのブローカーだ!これじゃぁ。
>実に嘆かわしい...

撤回するつもりはありませんか？
酔っていたのなら尚更・・

生島勘富さん

どうでも良いことはおいとくとして

>机上じゃないから意味がある。
>あなたはどんなのを思いつきましたか。混在型になったでしょう。

机上じゃないんですね。なるほど。
そして自分は確かに混在型を考えてしまいました。
いや勉強になりました。自分はそういうレベルですからね。感謝です。

>こんな複雑なSQLの方が読めないという人も出てくる。
>そりゃレベルが低かったら読めんわな……。

しかしデータベーススペシャリスト試験に合格していてもなかなか
読めないかも知れないって気がするのは自分だけでしょうか？
※自分は持ってませんけどね。

やのさん
oumiさん
生島さん
その他、御覧になられている皆様。

昨日の私の発言において行きすぎた発言がありましたことをお詫びいたします。
申し訳ございません。

以後、気をつけます。

こんにちは。しっぱと申します。

私自身は技術者の肩書を持った営業兼調整役みたいなものなのですが、ＳＱＬ自体確かに大切だと思います。

ハードウェアのパフォーマンスに依存はするものの、言語よりパフォーマンスチューニングがしやすいのが一番うれしいところです。

ＳＱＬの知識のある方の書かれたものはシンプルで読みやすいので保守する方も楽だったりします。

ただ、一方で監査面からみると資産管理がしづらく（クライアントは言語の部分しか見ていないことが多いです）、管理対象から外れてしまいトラブル時に問題になることがしばしばありますね。
（ＳＱＬの管理の仕方を早急に提案してこいとか・・・・・）

私自身の個人的な考えとしてはお客様の管理形態を踏まえた上で、
且つ「オレしかこれは高度過ぎて理解できねーだろ！」的なアーティスティックな（笑）作りにしなければ問題ないかと思っています。

エンジニアにありがちな落とし穴というか、プライドの様なものなのでしょうが、自分の作ったプログラムを「自分のアート作品」のように考えている人が多い様に思います。

「ＳＱＬでやらなきゃダメ」というのも「ロジックでやらなきゃダメ」っていうのもビジネスとして考えれば同じレベルだと思います。
本当にやりたいようにやるなら自分の人からお金をもらわず自分の中で完結すればいいだけです。

あくまでもクライアント様ありき、お客様がＳＱＬでといえばＳＱＬで作ればいいですし、ロジックでと言われればロジックでやればいい。
当然プロジェクト開始段階での調整や提案はなんでもアリで、先に方向性を決めておくべきですが、途中からの参画であれば我を通す必要もないかと思いますし、臨機応変に動けるのが本当のプロではないでしょうか？
この時点で保守性やパフォーマンスも議論すべきで、本当に自分の意見が正しいと思うのであれば、ここでお客様を口説けない時点でビジネススキルの不足ですね。
エンジニアが技術力だけあればいいという時代は終わってるように思います。
（余談ですが「ググるな」の件でもありましたが、情報が氾濫し、製造のスピードが上がっているご時世で技術だけでコミュニケーションが取れないことは致命的だと思います。）

つまり当然両方知っていなきゃいけないことで、システムの属性（バッチなのか画面ＰＧなのかＷＥＢシステムなのか等）によっても変わってくるかと。
もっと言えば、プロジェクトの置かれている状況や運用環境をしっかり理解して保守性の高い（保守が別の会社の場合もあるので注意が必要ですね）高パフォーマンスなモノづくりを目指すことがクライアントからお金を頂いている人間の使命なんじゃないかと思います。

お客様の意向に沿わない（管理や保守引き継ぎも含めて）モノづくりはプロの仕事ではなく、趣味の延長でありお金を頂くに値しない動きだと思っています。

まあ、あくまでも私自身の考えですが・・・・・
これは考えが甘いのでしょうか？？？？
やはり、「こうあるべき」というのを決めなければいけないのでしょうか？？

転職を考えている身として、「エンジニア」として生きていくのか「ＩＴ関係者」として生きていくのかこの辺で差がでるのかなーと思いました。

ちょっと純粋ではない技術者からの疑問でした。
長文失礼いたしました。

連投で申し訳ないです・・・・

読み直したら過激な発言がありましたこと先にお詫びさせていただきます。
仕事の合間に（この時点で駄目ですね＾＾；）書いていたもので見直しが中途半端でした。。。。

一個人としてふと感じた疑問をそのまま文章にしてしまいました。。。。

人前に出すべき文章では無かったですね。
大変申し訳ございませんでした。

しっぱさん、こんにちは。

いえいえ、別に問題ないと思いますよ。
おっしゃるとおりだと思います。

わたしが問題にしているのは、片方の選択肢が初級シスアドレベルにない人に合わせるために潰される。わたしは多数決で負け続けてきたけれど、そういう現実を、お客様はどう考えますか？

ってことなのですけどね。

現実としてできる人が揃わないからできない。というのは、プロとして業界としてあまりにおかしすぎないか？ということです。

生島様

お返事ありがとうございました。
お客様攻略は非常に難しいですよね・・・・

私の立ち会ったミーティングでもシステムサイドが考える必要性とお客様の考える必要性のラインが違うこと多く、水掛け論って言葉はこういうときに使うんだなとしみじみ思いましたｗ（現実逃避入ってますが・・・・）

説得力のある説明ができる方がいらっしゃるとこういう時に非常に頼もしいです。
（おそらく私がここの潤滑油になるべき立場かも・・・・と自己批判いたしました）

おそらくクライアントと話す際にエンジニアとして話すとご納得いただけず、「効率化」等「ビジネスとしてのメリット」を自信を持ってお話できる方が少ないのかなと認識しております。

生島様のお話もロジック派の方のお話もどちらも否定も肯定もできませんが、活発な議論は非常に有益だと思います。

自身の成長は自己否定するところから始まると考えています。
先程も書かせていただいた通り私自身はどちらの主張にも長所・短所あると思います。
それを知ることができて非常にありがたいです。

生島様のコラムに関しては炎上と書かれておりますが、「活発な議論の場」として拝見しておりまして、今後の自身のビジネスキャリアの糧とさせていただいております。

今後も活発な議論の場を提供頂けるとうれしく思います。
楽しみにしております。

生島さん、こんにちは。

　考え方の違い、と言ってしまえばそれまでですが、こういう話ってある程度経験しないとなかなか見えない問題なんでしょうね。私は生島さんのおっしゃる事は良くわかりますが、コメントを読んでいるとそう感じます。

　「誰のためのシステムか」「何のためのシステムか」それを置き去りにして設計しているエンジニアがたくさんいるような気がします。技術や工程、プロジェクトの行き先だけしか見えないのでは本末転倒です。1人で出来る事なんてたかが知れてます。その上で分担して作業するのは当然ですが、担当外だからと言って知らぬ存ぜぬではうまく行くはずもないですし、実際にプログラミングをしないからと言ってプログラムを知らなくても良いものではない（はず）ですが…

　ま、続きは自分のコラムで書きます（笑）

生島さん、こんにちは。

私は基本情報技術者、ソフトウェア開発技術者の資格を持っておりますが、
お恥ずかしながらリンクの問題は解けませんでした。
実際参考書を多く見ましたが、SQLの基本が載っていてもあれほど応用問題が出題された記憶はありません。

問題のアドレスに「seminar」とありますが、試験対策講座の演習問題か何かでしょうか。資格関係の演習問題を以前社内研修で受けましたが、
「実際はこれほど難しい問題は出題されない」との話を聞いたことがあります。

また、資格は持っているが実践できない新人もよく見かけます。
「資格を持っている = 解ける」が本当に成り立つか正直疑問です。

しかしSQLの必要性は私も実感しております。
今後精進して参りたいと思っております。

はじめまして。

非常に共感できます。

ある問題の解決方法が複数あるときに、それぞれについて「なぜ＊＊より○○のほうがいいのか」
をしっかり説明することすらできない人が「プロ」を名乗っている現状がおかしい。

プロならば「できる or できない」ではなくて「＊＊より○○のほうが△△というメリットがある。したがって○○を採用するべきだ」もしくは「その方法では□■というデメリットがある。○○ではそのデメリットはなく、さらに△△というメリットがあるので、○○を採用したほうがよい」という主張ができるべきです。

わたしも、アプリケーションの設計モデルの一つに MVC がありますが、
これを採用する利点 -- 責任範囲が明白になり開発・テストが楽になる、保守性が高くなる --
を主張するとダメダメプログラマに「いや、そんなものなくてもやってこれたんだ」と返されたことがあります。

MVC に沿って設計したとしても、「なんだこれは。まるで理解できない」と
その設計書を無視したコーディングをされることもあります。
( いうまでもなく保守性のかけらもないゴミが出来上がります )

そして、残念なことに現在の IT 業界では勤務年数が多いとかくだらない理由でその主張が通ってしまうのです。
詐欺師の淘汰。是非とも進んでほしいものです。

いろいろ気になる部分はあるのですが、とりあえず２点だけ。

> RDBMSを使うならばSQLを使わないと無駄が多い。
> スキルを身に付ければ最終的には、コーディング量 ＝ 工数（保守性）となっていくので、
> 少ないコーディング量ですむSQLの方が工数・保守性ともにメリットがある。

ここで言うSQL は、ストアドのことだと思うのですが、SQL の方が少ないコーディング量
で済むというのは、何かの調査結果のようなものがあるのでしょうか？
それとも、生島さんの実感でしょうか？

> O/Rマッパーのようなもので覆い隠すようなモノにまったく価値はない。

このように言われるからには、O/R マッパーを数多く使用、または調査された
と思うのですが、どのあたりを見てそう言われているのでしょうか？具体的な
製品名（またはオープンソース）を教えていただけないでしょうか。

生島社長

「SQLもできんくせに（初級シスアドにも達しないくせに）プロを名乗るな」に
反発する人は多いと思います。
門外漢の私もこれだけを言われるとへこみます。
# RDBMSを扱うならっていう前提があるのは理解してますけど
# それを読み取れない人が多いのも事実。

逆説的に、「DBスペシャリストを持たざる者は、
DB設計＆SQL（O/Rマッパー含む）に触れるべからず」なら
棘がないかと思いますがいかがでしょ？

> 現実としてできる人が揃わないからできない。というのは、
> プロとして業界としてあまりにおかしすぎないか？ということです。

これに関しても現実問題としてどうかなーと感じます。
私の業界の話で参考にならないかもしれませんが
ネットワーク設計ができてプログラミングもできるという人間は極めて稀な人材です。
さらに回路設計までできる人間なんて見たことありません。
DB設計ができてOO設計もできる人材もレアなんじゃないでしょうか？
# ここにコメントされる方々は何でもできる人々だと思いますが
# それを基準にして理想を述べても一般には適応できないように感じます。
以前、生島社長がコラムにも書かれてましたが、
DB屋と母言語屋の分業案が現実的かなーと思います。

しっぱさん、こんばんは。

両方を知った上で選ぶ分には何の問題もないですけどね。
「実行計画を見たことがない」というレベルの人でも、SQLでアレはできない、これは効率的でないとかいう人もいる。
判断するのは、最低でも初級シスアドレベルは超えてからにして欲しい。

にゃん太郎さん、こんばんは。

SQLもそれなりに知らなければ、顧客と話した瞬間にアルゴリズム考えていますからね、そのイメージは最後まで覆せません。せめて、フラットに判断できるレベルにはきて欲しい。
コラム期待しています。

forsetiさん、こんばんは。

> お恥ずかしながらリンクの問題は解けませんでした。

自作自演みたいな願ってもないコメントありがとうございます（笑）
多分、DBスペシャリストを取ってても解けません。そういう難易度にしています。
これは、弊社でやっているセミナーのお試しの演習問題です。
http://www.g1sys.co.jp/

2日間でこれが読み書きできるようにを目標にしています。
SQLにもコツがあって、文法から教えるからできない。
よろしければ、セミナーの方にご参加下さい。

実際に現場で使うことはないと思いますが、「これぐらいまではやったらできる」と思っていると設計段階で考えることが全く違ってくるのです。（これはできるようにならないと分からない）

Fomalhautさん、こんばんは。

> MVC に沿って設計したとしても、「なんだこれは。まるで理解できない」と
> その設計書を無視したコーディングをされることもあります。
> ( いうまでもなく保守性のかけらもないゴミが出来上がります )

何というか、そういうところもあるでしょうね。
ストアドプロシージャでやってくれってお願いしたら、引数がWHERE句Varchar(2000)とかだったこともあるし……。
ストアドプロシージャを使ったらワークテーブルがいるとか、そういう人も多いし……。

flatline さん、こんばんは。

最近の論文は知らないけれど、アメリカでいくつも出てると思いますよ。
探してくださいな。コーディング量は理論値で分かりますけれどね。
実感なら以下の問題を、SQLを極力使わないパターンと使うパターンで書いてみて下さい。
http://www.g1sys.co.jp/seminar090515.html

O/Rマッパーについては、http://el.jibun.atmarkit.co.jp/g1sys/2009/12/post-59d3.html をご覧下さい。

放浪者さん、こんばんは。

初級シスアドのネットワークの問題をちょっくらピックアップ。

　　　　TCP/IPネットワークでDNSが果たす役割はどれか。

　　　　ア　PCなどからのIPアドレス付与の要求に対し，サーバに登録してある
　　　　　　IPアドレスの中から使用されていないIPアドレスを割り当てる。
　　　　イ　サーバのIPアドレスを意識せず，プログラムの名前を指定するだけで
　　　　　　サーバのプログラムの呼出しを可能にする。
　　　　ウ　社内のプライベートIPアドレスをグローバルIPアドレスに変換し，
　　　　　　インターネットヘのアクセスを可能にする。
　　　　エ　ドメイン名やホスト名などとIPアドレスとを対応付ける。

　　　　インターネットのグローバルアドレスに関する記述として，適切なものはどれか。

　　　　ア　IP アドレスを，ネットワーク番号とホスト番号に分けるための
　　　　　　ビットパターンである。
　　　　イ　NIC （アドレス発行機関） が発行する，世界中で重複のない
　　　　　　アドレスである。
　　　　ウ　イントラネットなどの独立した IP ネットワークを構築するために
　　　　　　必要なアドレスである。
　　　　エ　電子メールを使用するために必要な電子メールアドレスである。

　　　　午後の問題ならこのぐらい
　　　　http://kakomon.at.webry.info/200903/article_17.html

例えDB担当者でも、これぐらいは分かって当たり前と思っていますけれど……。
ネットワークも初級シスアドレベルができない人いるかもね（笑）

違うところは、ネットワークは本当に専門家がやることが多くて、専門外の人は係わらないことが多いことです。

SQLは初級シスアドレベル（以下）の人が、実際にコードを書いたり、設計しますから、大問題なのです。（他のやり方でもできるからすぐに逃げて伸びないのです）

回答ありがとうございました。

そうか。何か違和感があると思っていましたが、たぶん生島さんと私とでは、O/Rマッパーに対して期待するものが違いますね。
私は、O/Rマッパーは、インピーダンスミスマッチ解決のためにしか使っていません。具体的にはRDBMS からの結果セットを、dto に格納する処理です。あ、言語はJava を想定してますが、まあ他の言語でも同じですよね。

これは純粋に好奇心から訊きたいのですが、O/Rマッパーを使わないと言われているので、この部分をどのようにコーディングされているのか知りたいところです。

ただ、O/Rマッパーを使うと、オプティマイザの恩恵が受けられないと一蹴されているようですが（違ったらごめんなさい）、O/Rマッパーでも実行するSQL を記述できたり、ストアドをコールできるものはあります。そういうプロダクトを使用されたことはあるでしょうか？

flatlineさん、こんばんは。

O/Rマッパーはマッパーとしての機能としては使いますよ。
自動生成するSQLは一切使わない。

単純UPDATEとか、単純INSERTなどは、メンバーの要望で押し切られるときがあるけれど、何にせよO/Rマッパーって先にテーブル定義がないと非常に使いにくい。スタブを作るのも相当コストが掛かる。（私の勘違い？）

私はDB設計を後回しにしたいから、http://el.jibun.atmarkit.co.jp/g1sys/2009/01/post-037e.html
全部ストアドプロシージャにしようよと言ってます。
スタブなんて一瞬で作れるし、命名法と引数のルールをしっかり決めていたら、OO言語側が完全に動くものを作った後にテーブル設計を始めることも可能です。

その先がO/Rマッパーだろうがなんだろうが大した問題ではないけれど、O/RマッパーはSQLなんて一切吐き出さないことになる。

生島さん、こんばんは。

> O/Rマッパーはマッパーとしての機能としては使いますよ。
> 自動生成するSQLは一切使わない。

これなら理解できました。

> 私はDB設計を後回しにしたいから、
> http://el.jibun.atmarkit.co.jp/g1sys/2009/01/post-037e.html
> 全部ストアドプロシージャにしようよと言ってます。

リンク先のコラムは、最初に書かれたときに読ませていただきましたが、動くものを先に作りたいだけであれば、それがストアドだろうが、適当な値を返す(Javaなどの言語で記述した)ロジックであっても、差がないんじゃないか？と思ったことを覚えています。それこそ、Excel からデータを読んで返すぐらいのものなら、簡単ですよね。
別の言い方をすると、先のコラム内の、「ストアドプロシージャ」の部分を、「言語で記述したダミーのロジック」または「インターフェースとダミーの実装」と置き換えても成立する気がします。

テーブル設計（ＤＢ設計）を後回しにしたい（または、他の実装と並行したい）という考えには賛成ですし、実際、やってます。ただ、ストアドにこだわる理由が、今ひとつ掴みきれないというのが率直なところです。ダミーデータ返すぐらいなら、コーディング量に大幅な差（１：１０ぐらいの）が出るとも思えないので。

読みが足らないということであれば、ご指摘ください。

flatlineさん、こんばんは。

> 別の言い方をすると、先のコラム内の、「ストアドプロシージャ」の部分を、
> 「言語で記述したダミーのロジック」または「インターフェースとダミーの実装」
> と置き換えても成立する気がします。

成り立つのですけれど、捨て去る部分はSQLでやった方が少ない（1:10はなくても、1:3ぐらいにはなる）インターフェースなどでは、最終的にSQLがどれぐらいOO側に入り込むかが曖昧でパフォーマンスの予測がつかない。

すると、結局、パフォーマンスが出ずにせっかく作った動くものもやり直すという「いつか見た景色」をまた見せられてしまいます。

ストアドプロシージャなら、限界レベルまでパフォーマンスを出せますから、後戻りを最小にできるわけです。

saki1208です。

まずは、改めて謝罪させてください。
不適切な発言により皆様に不愉快な思いをさせて
しまい、非常に申し訳ありませんでした。
今後はこのようなことが起こらないよう注意して
いきます。
本当に申し訳ありませんでした。

生島様、編集部のみね様、コラムとは関係ないコメント、
申し訳ありません。

ちょりぽんさん、saki1208さん、ともに
自分の非を素直に認め、謝れる人間は素晴らしいですね。
尊敬します。

生島社長、こんばんは

> 例えDB担当者でも、これぐらいは分かって当たり前と思っていますけれど……。
> ネットワークも初級シスアドレベルができない人いるかもね（笑）

いると思います。
以前、ファイアウォールの設定したとき、
「DBで使用してるポートは何番ですか？TCPのコネクションの向きは？」
って質問したら答えてくれなかったことがあります。
ネットワークにはそれほど興味の無い人なんだろうなー。
netstatで調べてそれらしく設定しときましたが、こわいこわい。

DBのインストールをインフラ屋さんにやってもらうこともあるそうだから、
設定ファイルをいじくることのないDB屋さんもいるのかもしれないですね。
知り合いのDB屋も、共有メモリサイズを初期値のままにしてる馬鹿がいるとぼやいてましたし。

こんばんは。

> 成り立つのですけれど、捨て去る部分はSQLでやった方が少ない（1:10はなくても、
> 1:3ぐらいにはなる）インターフェースなどでは、最終的にSQLがどれぐらいOO側に
> 入り込むかが曖昧でパフォーマンスの予測がつかない。

なるほど。
ただ、「動く物を先に作る」段階で、そこまで先のパフォーマンスまで考慮する必要があるのか、という疑問はありますが。というか、ストアドだろうが言語だろうが、そもそも、この段階でパフォーマンスの予測などできるんでしょうか？

こんばんは。
多忙な社長業の合間にコメントご苦労様です。

今回の白熱？炎上？につきまして、常識のラインを述べられていますが、
もっと単純で、『オブジェクト指向言語で処理したら保守性が悪い』と
言い切ったことに【ピクっ】と来た人が多かったからではないでしょうか？

[ピクっとの参照URL]
http://wiredvision.jp/news/200906/2009061721.html

ここには、O/R信者が多いので、反応せずにいられない方々が我も我もと
釣られてきたのだと思います。

例えるならば、石川遼のファンがたくさんいる場所で、
『あんなのは八百長だ』(←注:あくまでも例えですよ!!!)と言い切ってしまって
しまったのと同じようなものだと思います。

過激なタイトルと、丁寧でこまめな返答が生島さんのスタンスなので、
私はそんなに気にしてはいませんでしたが。

>O/Rマッパーを同列にしているつもりはないですが、O/RマッパーがあるからSQLがイランという人間がでるのでね。

それは良くないですね。
裏では、ものすごい勢いでSQLが自動生成されているんです。
しかし、こちらの意図とおりに動作しないことも多いので、
結局SQLを駆使してO/Rマッパーを自作することもありますね。

flatlineさんへ

DaoとO/Rマッパーは本来別物ですよ～
O/RマッパーがあたかもDaoのように使われてしまっているケースが多いんです
マッパーがあれば、Dao/Dtoに分ける必要はないはずなのですが。

こんばんは。

そんなに難しい問題ですかね？
http://www.g1sys.co.jp/seminar090515.html

# などといいつつ、私は、
# 誤差が明細の数を超えて、
# 一周する場合まで考慮した答えを作ってました。
# 解答を見てから、「ねーよ」と激しく自分に突っ込み。

5 分くらいですかね、考えたのは。
SQL のコーディングの細部まで考えたわけではなくて、
「こうすればできる」というアウトラインまでですけど。

> flatline さん

横入り失礼。

> ただ、「動く物を先に作る」段階で、そこまで先のパフォーマンスまで考慮する必要があるのか、という疑問はありますが。というか、ストアドだろうが言語だろうが、そもそも、この段階でパフォーマンスの予測などできるんでしょうか？

おおまかにはできますよ。
データ件数がある程度わかっていれば、ですが。

毎日 DB 触ってますので、
このくらいの件数にこのクエリだと、
このくらいのレスポンス・タイム、
という感覚は持ってますし。

基本的に、実行計画は log n と n の掛け算ですから、
データ件数から、概算してみても良いです。

少なくとも、
「遅くて使い物にならない」レベルは確実にわかります。

みなさま、こんばんは。

> ひらさん
> DaoとO/Rマッパーは本来別物ですよ～
> O/RマッパーがあたかもDaoのように使われてしまっているケースが多いんです

確かにそうですね。今、話題になって（？）いるのは、Dao の方ですね。

> ronさん
> 毎日 DB 触ってますので、
> このくらいの件数にこのクエリだと、
> このくらいのレスポンス・タイム、
> という感覚は持ってますし。

そりゃ件数とクエリが大体にでもわかっているなら、
レスポンスタイムの予測はできると思います。
しかし、私の読み違えでなければ、生島さんは、「DB設計を後回しにしたいから」、先に動くものを作るために、ダミーのストアドを作る、と言われてます。
当然、テーブルも主キーもインデックスも何もない状態なわけです。
この状態で、件数はともかく、クエリまで想定できるというのは、どういう意味でしょう？

ここからは、実際の業務ロジックの記述について。
ストアドで記述したロジックと、言語で記述したロジックを比較した場合、パフォーマンスの点では、ストアドが圧倒的に有利であることは疑いの余地はないと思います。
また、いわゆるO/R マッパーを使用するから、SQL知らなくていい、というのは、業務レベルのアプリケーションを作成する技術者には許されないと思います。

ただ、それでもなおかつ、「全ての業務ロジックをストアドで記述する」ことについては、利点を見いだすことができません。
理由はいろいろありますが、ストアドの最大の利点であるパフォーマンスに限っていうなら、次のような点です。Webアプリケーションを前提としています。

1. 主キー、またはインデックスで1レコード、または数レコードを取得するようなケースでは、体感できるほどの差はない。

2. 数10万レコードを更新するような処理の場合は、ストアド有利だが、そのような処理を画面からリクエストして、レスポンスを待つことは、まずない。夜間バッチで行うか、画面からリクエストする場合でも、別スレッドで実行させて、進行状況を画面に表示する。どちらの場合でも、処理速度の差は問題にならないし、このような処理は１つのシステムで、それほど数はない。

3. 業務ロジックはデータベースだけで完結するものばかりではなく、たとえばレコードを更新しながら、１レコード毎にメールを送信したり、http でどこかと通信したり、物理ファイルを作成してFTPでアップしたり、というようなロジックもある。そのような処理はストアドだけでは書けない。

といったところでしょうか。

2 の場合、処理時間に10時間の差があるようだと、さすがにどっちを使っても変わりはないとはいいませんが。ただ、未熟な技術者ならストアドだろうが言語だろうが、10時間かかるようなコーディングをする可能性はあるし、経験豊富な技術者なら、どちらを使おうが現実的な処理時間で終わるようなロジックを書くのではないでしょうか？

上記の意見は、私が通常行っている開発の範囲で書いているのであって、全てのケースにあてはまるわけではないことは言うまでもありません。また、業務ロジックをストアドで書くことを否定しているわけでもありません。

みなさまのご意見をきかせていただきたいと思います。

みなさん、おはようございます。

そもそも、外部からSQLを投げるというのは、実行時にコンパイルされる訳で、言語側からもDB側からも、実行時まで単なるSTRINGとして扱われているわけです。

それが良いということが、私には逆に全く理解できないのですけれど。

他にもメリットはありますけれど、何度も何度も書いているけれど、できる人に取っては、パフォーマンスも、開発工数も、保守工数もすべてにおいてメリットがあります。

それでも、なぜ、このような意見が出てくるかというと、『SQLは難しい』という前提があるからなんですね。なければ、すべてにおいて成り立たない。
『メリットが僅かだ』とか理解に苦しむ。

SQLは『高校生が取れる資格レベルでもプロができない』が許されているわけですから、業界の常識として『SQLは難しい』となっているはずです。

しかし、外から見たらおかしいでしょう？
『高校生が取れる資格レベル』であるならば『SQLは簡単である』とならないとおかしい。

もっとも、業界の常識ですから私にはどうもできないのですけれど、お客様どう思いますか？

ってことなんですね。

デメリットって『できない人がいる』以外になく、それはお客様には全く関係ないこちらサイドの問題ですからね。

お客様の前で音読できるか、一般常識でフラットに考えてみてください。

おはようございます。今日は寒いですね。

> そもそも、外部からSQLを投げるというのは、実行時にコンパイルされる訳で、
> 言語側からもDB側からも、実行時まで単なるSTRINGとして扱われているわけです。

すみません。これ、よく理解できませんでした。

> 他にもメリットはありますけれど、何度も何度も書いているけれど、
> できる人に取っては、パフォーマンスも、開発工数も、保守工数もすべてに
> おいてメリットがあります。

たぶんですが、私を含めて、生島さんの考えを理解できない人がいるのは、
「すべてにメリットがあります」という部分について、「ほんとなの？」
と思っているからではないでしょうか。

何度か生島さんが書かれている例題のレベルであれば、メリットがあるのも
わかりますが、「あくまで単純化した理論であって、実践的ではないのでは？」
というのが正直なところです。たとえば、先に私が書いたコメントの例3 の
ようなケースのとき、ストアドだけでどうやってやるのか？という実践的な
解が見えてこないのです。もし、過去のコラムにその解が書かれているので
あれば、私が深く読み込んでいないだけで、申しわけなく思いますが。

> SQLは『高校生が取れる資格レベルでもプロができない』が許されている
> わけですから、業界の常識として『SQLは難しい』となっているはずです。

個人的な意見ですが、「SQLが難しい」ことが問題なのではなく、
「SQLで全てができるわけではない」ことが問題なのではないでしょうか。

SQLの学習コストが、Java などに比べて低いというのは、よくわかります。
でも、SQL（ストアド）だけで何でもできるわけではないですよね。
どうせ勉強するなら、何でもできるJava などを勉強した方がつぶしが効く、
と考えるのではないでしょうか？で、余裕ができたときとか、どうしても
必要な場合にストアドを勉強して適用するとか。

flatlineさん、おはようございます。

何度も何度も書いている通り、DBサーバで出来ることはDBサーバで、前提を変えたら議論にならない。

> どうせ勉強するなら、何でもできるJava などを勉強した方がつぶしが効く、
> と考えるのではないでしょうか？で、余裕ができたときとか、どうしても
> 必要な場合にストアドを勉強して適用するとか。

つまりは、そこに顧客の都合は入ってないでしょう。
勉強するしないなんて、全部、技術者側の都合じゃないですか？
そんなものに何の価値もない。
考えるのは顧客の都合でよいと、何度も書いているわけです。

それでも、嫌がる人が多い以上、担当を分ければいいのですけどね。

分けたら、Javaなんて本当に価値がなくなりますよ。
ビジネスロジックの大半がDB側に入ったら、Java側ですることは入力チェックと見た目を変えることぐらいしかなくなります。
何度も書いている通り、優れたIDEや（Javaってテキストエディタで書いてたおじさんにとっては、本当に隔世の感があるよ）フレームワークが出てるし、SQLに比べ目で見える範囲が大きい（ほぼ全部目に見える）から本当に新人でも出来ます。

そちらはデザイナー系の仕事に近くなるでしょう。そちらが向く人はそちらを伸ばせばいい。しかし、明らかに向かない人もSQLはイヤだったりね……。
そんな既得権を守りたい人からの反発でつぶされるわけですが、不況ですからね……。
顧客が気づいたら全滅するしかない考え方ですよね。

つぶしが効くかどうかなんて……。
Rubyに変わるとか、.Net2010が出るとか、大騒ぎするけれど、私は十数年間そこそこ喰ってこれたのはSQLが人並み以上に出来たからです。
それこそその十数年間に、VB → Java（Applet） → Delphi → .Net → Java → PHP（などなど、他にもやってるけど）とやってきましたが、表面の技術って本当に一瞬で陳腐化してきました。

しかし、ずーとSQLは使っています。

多分、この先もそう簡単には変わらないですよ。

なんでみんなそっちしか見えないかな～。
本当に不思議。

「全てをSQL(RDBMS)でやる」ではなく、
「SQL(RDBMS)で出来る事は全てSQL(RDBMS)でやる」
SQLという専用言語は、DB上のオブジェクトを効率よく扱うために出現した言語なのだから、当然最適なはず。
その結果、パフォーマンス、コード、保守、等にメリットが出るという話のはず。

という前提に立ち考えて行くと

例えば、
「SQL(RDBMS)で出来る事」なのであるにもかかわらず、コードで複数回のループを回したり、低レベルSQLの発行によりネットワークに負荷をかけている。
リソース食い、工数食い、最良では無い(可能性の高い)パフォーマンス設定、つまり、ゆるゆるのキャパシティ設定などが、暗黙のうちにEUのビジネスメリットを損なっている（減らしている）。
例えば、実は２０分で終わる夜間バッチ処理が、朝５時まで４時間かかっていたとしよう。（極端だけど）
システム運用としては問題は無いかもしれない。設定されたキャパを満たしているかもしれない。
しかし、顧客のビジネスに対するデメリットはある。電気・人などである。サーバー台数にも影響が出ているかもしれない。
単にキャパシティを緩和させているだけにすぎない場合、顧客のビジネスコストとしては、確実に損なっている面があるのです。
残念ながら、ＥＵも厳しくこういった事を考えている現実が少ない。(判断できない)
SIerしかり。

そういった現状が問題だ。と言っているのでは？

「すべてにメリットがあります」が謎な人はおそらく、
・見ている対象を狭めている可能性。
・特定のパターンについてのみ考えている可能性。
・現在の許容設計(キャパシティ設計)は、すでに妥協の産物であり、顧客メリットが最大に考えられたものかを再考しなければならない可能性。
・最大・最良のシステムパフォーマンスを出す事の、難易度や一時的なお金は高い(ことが多い)。でもそれを理由に、単純機能の組み合わせで鈍牛なシステムを作る事はいかがなものか？
・今現在の状況についてだけ、考えている可能性。

という事について考えてみる必要があると言っているのではないでしょうか。

>> そもそも、外部からSQLを投げるというのは、実行時にコンパイルされる訳で、
>> 言語側からもDB側からも、実行時まで単なるSTRINGとして扱われているわけです。

>すみません。これ、よく理解できませんでした。

アプリケーションから投げたSQLステートメントは（どのようなものであれ）、RDMSによって、解析～コンパイル　まで複数のプロセスを経て実行されます。２回目が同じSQL文であればキャッシュされた物が再利用される事もありますが、そうでない場合、解析～コンパイルが走ります。
生SQLで、WHERE句の「ある数値」が毎回違う物を10000回発行すると１万回ビルドプロセスが動くわけです。
これを緩和させる仕組みは、いくつかRDBMSに備わっています。（RDBMSによって異なる）。ストプロやパラメタライズドクエリーもその１つです

生島さん、こんにちは。

一般の人が使う道具を作る人達が、その道具を作るための工具に振り回せているような・・・。

その工具を使えば道具は作れるが、その工具の特性を理解した上で作るのと、兎に角できたは違うのだよ、ですよね？。
で、今は「兎に角できた」でもいいけど、「兎に角できた」後は、ちゃんと理由を分析し、きちんと工具の特性を理解しようね、じゃだめですか？

「兎に角できた」で止まってる人は、ぶった切ってもいいと思いますが。

連投すみません。

oumiさん、それを考えることのできる人が本当の意味での「システムエンジニア」なんではないでしょうか？

いや、最近プログラマがいっぱいいたなぁと思って。

こんにちは。

> 何度も何度も書いている通り、DBサーバで出来ることはDBサーバで、

それは同感ですが、先にもコメントしたように、DBサーバだけ（ストアドだけ）では
できないような業務ロジックの場合は、どうするのでしょう？

> しかし、ずーとSQLは使っています。
> 多分、この先もそう簡単には変わらないですよ。

SQLがこの先10年や20年でなくなるとは思えないですが、
Google App Engine のBigtable などの案件が増えてくる可能性はあります。
KVS型はSQL(ストアド)のテクニックでは、対応できないですよね。
実行計画とか関係ないし。

oumiさん、こんにちは。

解説ありがとうございます。

ストアドプロシージャで固定のSQLで表現できていれば、コンパイルされてライブラリに入ってますから、RDBMSの種類によってはカラム単位で依存性の調査が可能ですね。
つまり、ビューのカラムを変更したら、どのストアドプロシージャに影響するか一発でわかります。

Grepかけて調査してて「これホンマに動いてるのか？」って思ったらコメントを読んでたとか（苦笑）今のIDEならそんなことはないでしょうが、昔は秀丸とかで調査してましたから、VBのころよく引っかかったな。

SQLとOO言語が混在したら、保守性は確実に下がると思うけれど（ここは感覚の問題になるのでなんとも言いがたい）

oumi さん、ありがとうございました。

> 「全てをSQL(RDBMS)でやる」ではなく、
> 「SQL(RDBMS)で出来る事は全てSQL(RDBMS)でやる」
> SQLという専用言語は、DB上のオブジェクトを効率よく扱うために出現した言語なのだから、当然最適なはず。
> その結果、パフォーマンス、コード、保守、等にメリットが出るという話のはず。

それはわかっています。というか、そんなことは常識だと思います。
ただ、言葉尻をとらえようとか言うつもりはないですが、生島さんが、

> 私はDB設計を後回しにしたいから、http://el.jibun.atmarkit.co.jp/g1sys/2009/01/post-037e.html
> 全部ストアドプロシージャにしようよと言ってます。

> ビジネスロジックの大半がDB側に入ったら、Java側ですることは入力チェックと
> 見た目を変えることぐらいしかなくなります。

のように言われています。
これは業務ロジックがＤＢだけで終わるのであれば、全く正しいと思いますが、
前にも書いた通り、業務ロジックってＤＢだけで完結するものでは
ないですよね。

もちろん対象の業務や規模などによっても異なるとは思いますが、Java側ですることが
入力チェックと見た目の変更だけで済むような業務ロジックって、そんなに
多いのでしょうか？

flatlineさん、こんにちは。

「DBサーバでできること」の意味が分からないのでしょうか？

個別の事案はご自身で判断されたらどうでしょう。
プロなんですから、判断できるでしょう。

こんにちは。

> 個別の事案はご自身で判断されたらどうでしょう。
> プロなんですから、判断できるでしょう。

もちろん判断しています。別に現在悩んでいることを生島さんに判断していただこうとは思っていません。

ただ、生島さんの主張されているご意見が、自分にとって今ひとつメリットが感じられないので、純粋な好奇心から質問させてもらっているだけです。

質問が分散してしまったようなので、まとめます。

・ＤＢ側の処理だけで完結しない業務ロジックは、どうやって記述するのでしょうか？

・Google App Engine のBigTable のようなKVS型の場合、ストアドではロジックを記述できません。ストアドだけで業務ロジックを書いていると、こういう案件のときに困りませんか？

理解力・読解力が足らないと言われればそれまでですが、お答えいただければ幸いです。

flatlineさん、こんにちは。

「DBサーバでできること」の意味が分からないのでしょうか？
これで終わりにしてください。

saki1208です。

多分…
業務ロジックとしての粒度の問題ですよね。

こんにちは。

> 「DBサーバでできること」の意味が分からないのでしょうか？

それはわかりますが、私の質問とどうつながるのかがわかりません。

推測してみると、

DBサーバでできることはDBに関することだけなので、それ以外のことは当然、Java などの言語で記述するに決まっている。わざわざ言うまでもない。

と言うことでしょうか？

終わりにしてくださいと言われてしまったにも関わらず、しつこく質問してしまってすみません。

補足です。

前者はということです。

後者はそれこそ、OO側で処理すれば問題にならないのでは?

saki1208さん、こんにちは。

> 業務ロジックとしての粒度の問題ですよね。

ロジックとしての粒度というと、具体的にどういう粒度でしょう？
たとえば、業務ロジックを
、
・ＤＢアクセスのための前処理
・ＤＢへアクセスする部分
・ＤＢからの結果を画面用に編集する部分

みたいに分類して、ＤＢへアクセスする部分だけは、ストアドで行うという意味でしょうか？

＞> 何度も何度も書いている通り、DBサーバで出来ることはDBサーバで、
＞
＞それは同感ですが、先にもコメントしたように、DBサーバだけ（ストアド
＞だけ）ではできないような業務ロジックの場合は、どうするのでしょう？

Java 側がシナリオプロセッサになっていればいいんじゃないですか？
現に当方のシステムは
「業務ロジックの全てをCOBOL/SQL 」で書き、
「Java側は予め作成済みの画面イベント対応シナリオと業務ロジック返却シナリオでもって動作する」ようになっています。

saki1208です。

えっと…

そうではなくて、先の例で言うと「複数の業務ロジックが一塊になっている」
と言ったところでしょうか。

あっ、遠回しに書いてる間に答えがでちゃったw

書いてるうちにコメントが・・・
でもあえてUPします・・・

CMPさん
>oumiさん、それを考えることのできる人が本当の意味での「システムエンジニア」なんではないでしょうか？

おっしゃる通り。

flatline さん

>> 私はDB設計を後回しにしたいから、http://el.jibun.atmarkit.co.jp/g1sys/2009/01/post-037e.html
>> 全部ストアドプロシージャにしようよと言ってます。

>> ビジネスロジックの大半がDB側に入ったら、Java側ですることは入力チェックと
>> 見た目を変えることぐらいしかなくなります。

>のように言われています。
>これは業務ロジックがＤＢだけで終わるのであれば、全く正しいと思いますが、
>前にも書いた通り、業務ロジックってＤＢだけで完結するものでは
>ないですよね。

>もちろん対象の業務や規模などによっても異なるとは思いますが、Java側ですることが
>入力チェックと見た目の変更だけで済むような業務ロジックって、そんなに
>多いのでしょうか？

「業務ロジックってＤＢだけで完結するものでは無い」その通りですね。
なので、「ビジネスロジックの大半がDB側に入ったら」という仮定であり理想の話になっているのだと思います。
（RDBSMを使う上では理想というより、本来あるべき姿ってことですね）

「Java側ですることが、入力チェックと見た目の変更だけで済むような業務ロジックって、そんなに多いのでしょうか？」

3層(5層)モデルについて改めて理屈を述べる必要はないと思いますが、
出来る限り、「Transactionを伴う業務処理」を１塊(１つのTransaction境界)にしようとすると思います。
そうすると「業務処理」がデータアクセス層で完結する事は多いと言ってよいのではないですか？
この業務処理とは、「ある手続き」の繋がりではありません。粒度を注意深く細分化した１つの小さなプロセスです。
たとえば、取引データを入力する場合の、「チェック」「エントリ」それぞれのプロセスといったようなイメージです。
つまり、多いと言えるのではないでしょうか。

とすれば、データアクセッサでへたくそなLoopを行ったりするのはもっての外と言えると思います。
また、データアクセスレイヤと上位レイヤの間は、単純なインタフェース（できれば単一のオブジェクト）にしたいですから、ビジネスロジックを構成するクラス群(層)でも、妙なI/Oは無い方が望ましいと言ってよいのではないでしょうか。

もうひとつ、「そんなに多いのでしょうか？」そうだとしても、そうでなくても、
例えば、「少なかった」としましょう。影響範囲は少ないので、公に論じる意味が減るかもしれませんが、その本質は変わりません。
顧客のシステムに不利益を仕込んでいる可能性があると言う事です。
また、「多かった」とすれば、これは言わずもがな。大いに論じる意味があります。
実際、RDBMSの普及率を考えれば、多いと言えるのではないでしょうか。

視点を、「現状」「開発サイド」という視点から、「顧客にとっての最大のメリット」に転じなければ、議論がすれ違って行く可能性があると思います。

>・ＤＢ側の処理だけで完結しない業務ロジックは、どうやって記述するのでしょうか？
当然その上位レイヤーで完結させようとします。Javaかもしれないし、.NET Frameworkかもしれない。PHPやRoRかもしれない。
ただし、DBが、当該業務に最適化された形であることという前提があります。（なので超上流からDB知ってる人をって事に…）
昔のISAMなどの考え方の延長でできたDBだとOUT。なんていうかキーがうまい事使える便利なデータストア…だとNGって事です。

>・Google App Engine のBigTable のようなKVS型の場合、ストアドではロジックを記述できません。ストアドだけで業務ロジックを書いていると、こういう案件のときに困りませんか？
RDBMSを使うという大前提を崩すと、議論にならなくなります。エンジンが違いますから。
KVS型DBに適している事をRDBMSでやれと言っているわけではないので、答えは「困らない」です。

ぴあちゃんさん、saki1208 さん、こんにちは。

> 「業務ロジックの全てをCOBOL/SQL 」で書き、
> 「Java側は予め作成済みの画面イベント対応シナリオと業務ロジック
> 返却シナリオでもって動作する」ようになっています。

COBOL/SQL を全く知らないのですが、業務ロジックが、全てCOBOL/SQL で
記述可能なんでしょうか？
業務ロジックの定義にもよるかもしれませんが。

> そうではなくて、先の例で言うと「複数の業務ロジックが一塊になっている」
> と言ったところでしょうか。

うーん、よくわからないです。すみません。
先に書いた、

> ＤＢ側の処理だけで完結しない業務ロジックは、どうやって記述するのでしょうか？

という質問に対して、saki1208 さんが回答するとしたら、どんなものになるでしょう？

お久しぶりです。
mayoです。

最近も炎上されてるようでなによりです。（笑）

＞flatlineさん
ここでの話しは、DBだけで業務ロジックが完結できるシステムを前提としないと、議論にならないですよ。

RDMSを使わないシステムだと、どうするんですかと話しをしても議論になりません。

ついでにですが、久しぶりに私の意見を書いてみます。

DBだけで業務ロジックが完結できるシステムを前提としてですが
やはり全てをDBだけで行うと決めるのは、可読性、保守性から言っても
私はしません。

まあ、みなさんもそうだと思いますが・・

例えば、得意先ごとの売り上げデータを画面に出す時に、得意先が変わったら得意先毎の小計を出す。
最後に全計を出す画面があるとします。
印刷イメージですね。
（超一般的な話しなので普通に出てくると思いますが）

これをDBで処理をして返すのは可能なのですが
（ソートキーをうまく生成すれば可能です）

できたSQLは見にくくなります。

すなおに、明細データ、小計データ、全計データをもらって、Java側でキーブレイク時に小計データはめ込んで全計を最後にくっつけて返すほうが、みやすいと思います。

それぞれに得意な処理があるので、全てと言うと無理がでます。
DB側に多くをもたせるって開発方式は好きですがね。

MySQLはバージョンによってはストアド作れんけど（笑）

ちなみに、FTPをするなり、メールを出すなり、HTTP通信をするなりも、SQLServerなら可能です。

まあ、私はしませんが・・・

oumiさん、丁寧にありがとうございました。

誤解しているといけないので確認させてください。

> この業務処理とは、「ある手続き」の繋がりではありません。
> 粒度を注意深く細分化した１つの小さなプロセスです。
> たとえば、取引データを入力する場合の、「チェック」「エントリ」
> それぞれのプロセスといったようなイメージです。

その１つの小さなプロセスに対して、１つのストアドを作成するような
イメージでいいでしょうか？
あるプロセスは、言語側で行い、あるプロセスはストアドで行うという
意味であれば、十分納得です。

> 視点を、「現状」「開発サイド」という視点から、「顧客にとっての最大のメリット」
> に転じなければ、議論がすれ違って行く可能性があると思います。

正しくは、「顧客と開発者の両方にとって最大のメリット」でしょうね。
「顧客にとっての最大のメリット」だけだと、開発者が過労死してもいい、
ということになりかねないので。
で、ストアド中心で業務ロジックを構成することが、両方にとっての
メリットになるのかという疑問が、いまだに解消されていないわけです。

> RDBMSを使うという大前提を崩すと、議論にならなくなります。エンジンが違いますから。
> KVS型DBに適している事をRDBMSでやれと言っているわけではないので、答えは「困らない」です。

書き方が悪かったです。
ストアドだけでしか業務ロジックを書けないと、KVS型の案件を受注できなくなり、
機会損失になりませんか？と訊きたかったのです。

saki1208です。

システム全体が大きな一つのプログラムだと思ってみると
答えが出ませんか？
そうすると、一つ一つのプログラムが業務ロジックのイメ
ージになりますよね?

で、単体でしか動かないプログラムもありますが、他のプ
ログラムと連動する物もあると思うのですよ。

ここまではイメージできますか?

mayo さん、こんにちは。

> ここでの話しは、DBだけで業務ロジックが完結できるシステムを前提としないと、
> 議論にならないですよ。

まあそうかもしれませんが、「DBだけで業務ロジックが完結できるシステム」というのが、現実的に存在しうるのか、とても疑問だったので質問させてもらってます。

mayoさん、みなさんこんにちは。

ブレイクに対応しているツールを使うなら、表面処理と考えることも可能ですし、微妙なところですね。

ツールが対応してなかったら

SELECT
　　　　…
　　　　, 商品コード
　　　　, 商品名
　　　　, 単価
　　　　, 数量
　　　　, 単価 * 数量 AS 明細計
　　　　, SUM(数量 * 数量) OVER (PARTITION BY 伝票番号) AS 伝票計
　　　　, SUM(数量 * 数量) OVER (PARTITION BY 得意先コード) AS 得意先計
　　　　, SUM(数量 * 数量) OVER () AS 合計

かな。
全然、保守性も悪くないし、3回投げるよりは速い。

saki1208さん、こんにちは。

> ここまではイメージできますか?

やってみます。

たとえば、「経理システム」「人事システム」「勤怠システム」「掲示板システム」などがあります。
「掲示板システム」は単体で動作しますが、「経理」「人事」「勤怠」は互いに連動しています。

こんなイメージでよろしいでしょうか？

＞COBOL/SQL を全く知らないのですが、業務ロジックが、全てCOBOL/SQL で
＞記述可能なんでしょうか？

誰しも手抜きしたいと思います。Javaで業務ロジック書いてSQL発行
して取得した結果を画面に表示して・・・っていう部分を全自動化
するには・・・って考えません？ORマッパーってのは折半型の全自動化
ツールでしょうかね？

全自動化はいいけど、あとから別の仕様がでてきても柔軟に対応でき
るようにコアロジックは修正しないで表面実装だけで事を終わらせたい
って考えません？ここでいう表面実装てのは、Javaの実装機能だけを駆使
してことを終わらせることを言っています。但し、Java のコーディング
は行わない、というのがミソです。このシステムの作業従事者の１００％
がJavaなんか知りませんし知りたくもありません、って人たちですから。

COBOL/SQL部分がブラックボックスならば、全自動化の部分はWEBサーバー
側に限定されます。COBOL/SQL（PL/SQLでもいいのだけど）部分でWEB
サーバー側に指示出来れば全ての業務ロジックを書けるでしょう。
WEBサーバー上に、Javaで動く特殊なスクリプトを解釈するインタープリタ
が動いていて、画面側からのリクエストを待ち、DBサーバー側にリクエスト
を電文という形でパラメータとして送信し、返ってきた結果をインタープリタ
が解釈して画面に起こす、業務ロジックに必要な要求動作は全て組み込まれて
いなければなりませんが、当初の仕様を超越した仕様外対応は別途相談みたい
な形にはなりますが、仕様の範囲内であれば、ブラックボックス側の実装と
画面レイアウトを作る→自動生成ツールでレイアウトから、HTML, JavaScript,
Java 側のエンティティ,業務シナリオ（イベントマップ）が自動生成され、
残るはブラックボックス側の制御ロジックを書くだけになります。

Java 技術者不要ですね。Java で書くとこ無いもの。

＞生島さん

得意先計が取れますが、それだと結局java側での編集が入りますねー

一番右に合計がずっと出ている画面は普通ないはず。
キーブレイク時に明細の色を変えて出すってのが一般的（？）な仕様のはず。

私は、java側で対応したほうがいい場面もあるって事をお伝えしたいだけです。

スピードは３回投げても問題ないはずですし・・

>flatlineさん
おっと!一つ上まで行っちゃいましたねぇw
この場合、例えば「経理システム」で考えてみてください。

mayoさん、こんにちは。

表示に関する処理＝UI って言えますね。

もちろん、ブレイクのたびに小計を取に行ったら許さんけどね。
これ3回投げるのも、私は不可ですね。

現実には問題は起こらないけれど、明細と集計を取るタイミングが違う。
処理中にINSERTされたものは合計に入って、明細から漏れますよね（逆から取得したら逆になるけど）

さすがに明細をロックして取得するわけにはいかないだろうし気持ち悪いです。
瞬間的に気持ち悪いと思うかどうかは、結構、重要な資質と思う。

でっかいミッションクリティカルなシステムをやると、この感覚では予想しないことが起きそう。起きないかもしれませんが、起きたときは、再現も出来ないバグにつながる恐れがある。

怖い怖い。

saki1208 さん、こんにちは。

行き過ぎましたか(^^;

では、人事システムがあり、「社員情報登録」「契約更新」「雇用通知書」「社員一覧表作成」の各機能があるというイメージでどうでしょう？
「契約更新」と「雇用通知書」は連動しますが、他は単体で動作するということで。

生島さん、mayoさん

こんにちは、エントリーポートです。

>すなおに、明細データ、小計データ、全計データをもらって、Java側でキーブレイク時に小計データはめ込んで全計を最後にくっつけて返すほうが、みやすいと思います。

>スピードは３回投げても問題ないはずですし・・
→ ここは、ちょっと賛成できないです。
　 売上系って、データ数が多くなることが多いですし。

　で、生島さんが回答されてましたが、合計列が
　常に表示されるのが嫌なら、Rollupで回避できます。

select 得意先,
商品コード,
商品名,
単価,
数量,
SUM(単価 * 数量) AS 明細計
from ORDERTABLE a
GROUP BY ROLLUP(得意先, 商品コード, 商品名, 単価, 数量, 単価 * 数量)

>それぞれに得意な処理があるので、全てと言うと無理がでます。
>DB側に多くをもたせるって開発方式は好きですがね。

→ ここは大賛成です。

>ちなみに、FTPをするなり、メールを出すなり、HTTP通信をするなりも、SQLServerなら可能です。

→ Oracleでもできますよ。

saki1208です。

>flatlineさん
そうです。そんな感じです。

で、本来のプログラムを一つの業務ロジックだと思ってください。
この時、契約更新を行うと通知書が自動で出力されるとするときに
通知書自身も一つの業務ロジック(再発行などを考えると…)ですよね。

つまり、契約更新自体は別の業務ロジックを内包した業務ロジック
ですよね。一つだと分かりにくければ、更に社員証の発行なんかも
含まれると思っていただければ良いかもしれません。

saki1208 さん、こんにちは。

業務ロジックの中の業務ロジックの考えはわかりました。

私が出したのは一つの例ですので、あまり深く突っ込むのはなしとして下さい＾＾

私が言いたかったのは、DBで全てというキーワードがどこを示すのかという所です。

java 側で　画面の制御、input のチェックを行い後はDBで全てとなると、どうしても無理な事が出てくる。

全てという定義は以下じゃないのかな？という意見でした。

java　画面の制御、inputチェック、表示上の修正、FTP、メール送信、HTTPアクセス、非同期処理制御、ファイル入出力
DB 上記以外の業務ロジックの全て（検索、更新、削除）

まあ、当たり前の事なんですが、こういう事ですよねー

と、言いたかっただけです。

まあ、FTPとかをストアドでやらせるのが可能なんですが、エラーハンドリング等がめんどいのもありますし、何より負荷分散ができない！
I/OもDBにやらせるとDBがずーと大忙しになりますからね。

はじめまして、いつもコラムを読んで勉強しています。

>mayoさん
生島さんはずっとそう言い続けていると思うのですが。
生島さんが問題提起を続けているのは
>DB 上記以外の業務ロジックの全て（検索、更新、削除）
の部分で効率の悪いSQLを組んでやるのを止めろっていうことだと思います。

違っていたらどなたか指摘をお願いします。

>ヤスさん
そうですよ。

その定義がずれて来ている気がしたので
まとめただけです＾＾

ファイル作成とかもDBやるんですか？って言う
意見があったもので・・

>書き方が悪かったです。
>ストアドだけでしか業務ロジックを書けないと、KVS型の案件を受注できなくなり、
>機会損失になりませんか？と訊きたかったのです。

回答がされていないようなので、勝手に回答しちゃうと

「ここ10数年RDBMSで食っていけており、かつこの先かなりの間は
RDBMSは廃れない」と信じて疑わない方に、上記質問はナンセンス
でしょう。

前提をちゃんと認識していないとすぐ議論が違う方向に行っちゃいますね。

saki1208です。

>flatlineさん
ダラダラとまわりくどくなっている間にoumiさんのコメントで納得されていたよ
うで…

失礼しました。

というよりも、KVSの案件受注したいと思ったらそっちのプロにもなれ！両方やれ！やれないならプロじゃないんだから手を出すな！

ということだと思います。「出来る/出来ない」で語ること自体が"顧客視点で考えれば"ナンセンスなので。

mayoさん>

どうも、すいません。
SQLを見ると、どうしても、他のアクセス方法を検証したくなるたちでして^^

本題ですが、結論は、ほぼ同じになるのですが、
業務アプリの最終Output といえば、データになると思います。
したがって、画面よりも、登録されるデータのほうが、
後々、顧客の宝物になっていくのだと思います。
（画面は、その時々の流行りの形で作ればいいかと。）
そういう考えで切り分けしていくと、
DB側でするところ
　→ 登録、更新、削除は、絶対こっち。
　　 検索は、必要なものを言ってくれたらあげる。
　　 事前に言うてくれたらある程度の加工もしてあげる。

画面等でするところ。
　→ 取ってきたデータをどう表示しようか。
　　 その他もろもろ。

でいいのではないでしょうか？
※例え、RDBMSが廃れてKeyバリューとか、
　OODBとかに変わっても、この切り分けは変わらない気がします。

mayo さん、こんにちは。

> 全てという定義は以下じゃないのかな？という意見でした。
> java　画面の制御、inputチェック、表示上の修正、FTP、メール送信、
> HTTPアクセス、非同期処理制御、ファイル入出力
> DB 上記以外の業務ロジックの全て（検索、更新、削除）

そういうことであれば、全くおかしいとは思いません。
というか当然です。

私が理解できてなかったのは、生島さんが言われているビジネスロジックに

> java　画面の制御、inputチェック、表示上の修正、FTP、メール送信、
> HTTPアクセス、非同期処理制御、ファイル入出力

といった処理が含まれるのかどうかということでした。
ＤＢで上記の処理をやらせるとは思えなかったのですが、Java が用済みになるとか書いてあったりして、じゃあＤＢがやるのかな？と混乱してしまったわけです。

みなさん、こんにちは。

これも何度も書いている通り、前提ばかりの文章なんて書けません。
個別の事情は自分で判断してください。

必須というのは必要条件であって、十分条件ではありません。
どこまで行っても「できなくてはいけない」となっても、「できなくても良い」なんて理由にはなり得ないでしょう。
私が言いたいのはそれだけの話です。

OO言語側にロジックを入れるメリットは、できない人でも使えるという、何とも情けない理由しかないのですから。

>書き方が悪かったです。
>ストアドだけでしか業務ロジックを書けないと、KVS型の案件を受注できなくなり、
>機会損失になりませんか？と訊きたかったのです。

ストアドプロシージャに入れたら、それしかできなくなる応用力のない人は、どうしようもないでしょうね。
ベンダーが変わったらとか、いう人も出ますが応用力なさ過ぎでしょう。
そんな人はさっさと淘汰されるべきで、議論の対象じゃないのです。

エントリーポートさん、こんにちは。

> DB側でするところ
> 　→ 登録、更新、削除は、絶対こっち。
> 　　 検索は、必要なものを言ってくれたらあげる。
> 　　 事前に言うてくれたらある程度の加工もしてあげる。
>
> 画面等でするところ。
> 　→ 取ってきたデータをどう表示しようか。
> 　　 その他もろもろ。

おっしゃるとおりで、例えば日付の書式変換や、数値のカンマ区切りもSQLの関数で簡単に可能ですが、表示に関する処理はSQLでやるべきじゃない。
OODBだろうが、KVSだろうが、何だろうが、そこにあるデータは、極力その場所で処理すべきなのです。

エントリーポートさん、こんばんは。

> select 得意先,
> 商品コード,
> 商品名,
> 単価,
> 数量,
> SUM(単価 * 数量) AS 明細計
> from ORDERTABLE a
> GROUP BY ROLLUP(得意先, 商品コード, 商品名, 単価, 数量, 単価 * 数量)

GROUP BY ROLLUP(得意先コード, 伝票番号)

かな？
単価,数量までキーに入れるとマズイし、得意先, 商品コードはあまり見ないような。イヤ見るときもあるけど、日付の方が一般的かな……。

チャチャでした。

生島さん、こんばんは。

>GROUP BY ROLLUP(得意先コード, 伝票番号)
>単価,数量までキーに入れるとマズイし、得意先, 商品コードはあまり見ないような
確かに、要らないところまでくくってましたねー。
恥ずかし・・・。

こんばんは。

だいたい疑問点は解消できたと思うので、私の方の質問などは終了とさせていただきます。
親切に答えていただいた方、ありがとうございます。
個人的には、ストアドは、これまで通り、パフォーマンスが必要な部分で使って、それほどパフォーマンスが要求されない処理なら言語側で処理するというスタンスを変えようとは思いませんが。
ストアドは言語としてはきれいじゃないと思うし、面白みがないので。
（↑あくまでも個人的な意見です）

最後に１つ。

おそらく全く余計なことですが、

> ベンダーが変わったらとか、いう人も出ますが応用力なさ過ぎでしょう。
> そんな人はさっさと淘汰されるべきで、議論の対象じゃないのです。

業界を変えたいと思われるのであれば、こういう言い方はしない方が
いいのではないでしょうか？人がついてきません。
勉強したくても、勉強できない事情のエンジニアはたくさんいると思うので。
業界を変えるのであれば、一部の優秀な人だけが幸せになるのではなく、
全体がそれなりに幸せになれる方法を考えていただければと思います。

ひんばんわ。

>勉強したくても、勉強できない事情のエンジニアはたくさんいると思うので。

差し支えなければ具体例を挙げてもらえませんか？

こんばんは。

> 差し支えなければ具体例を挙げてもらえませんか？

１日16時間、巨大システムの保守をしなければいけないエンジニアとか。
会社の方針で新しいことが勉強できないとか。やめたくても妻と３人の子供がいるため、転職は危険すぎるとか。
いろいろあると思いますが。

なるほど・・。
あくまでも具体例ですが、私から見ればそんなことは理由にはならないですね。

いくら忙しいといっても、通勤時間や昼休みに30分ほどは時間は取れるはず
です。そういう時間を利用して毎日は無理でも少しずつでも書籍読むなりして
勉強はいくらでもできます。

積極的に新しいことを取り入れる必要性は無いとはいいませんが、頭硬い
というか柔軟性が無い会社は先があるようには思えないので、取り入れたい
技術の重要性や将来性などを自分なりにまとめて上司に掛け合っても
全く聞く耳持っていなければ、別の会社に行ったほうがいいでしょう。
ただ、今の時期は不況なので難しいでしょうが・・・。

妻や子供がいてる、そんな家庭の事情は会社や業界には全く関係ない話
ですね。勉強し無ければ、後でえらい目にあうのは自分ですからね。

> flatline さん

こんばんは。
たぶん、もう良いのでしょうけど、
ご指名ですので、蛇足ながら返答をいたします。

http://el.jibun.atmarkit.co.jp/g1sys/2009/12/post-eab5.html#c30957501

> そりゃ件数とクエリが大体にでもわかっているなら、
> レスポンスタイムの予測はできると思います。
> しかし、私の読み違えでなければ、生島さんは、「DB設計を後回しにしたいから」、先に動くものを作るために、ダミーのストアドを作る、と言われてます。

読み違いだと思います。
私が読むところ、「テーブル設計は実装の後に」というのは、
「実装の前にテーブル設計」を否定するためのレトリックです。

その意味は、
「（最悪の場合、）テーブル設計は実装の後に（でもできる）」
ということかと思います。
つまり、極端な場合はそうもできるけど普通はしない、
あくまで限界事例として挙げておられます。
----
さらに、ユーザーインターフェイスの実装の後に（並行して）テーブル設計をすることが可能になりますから、詳細設計をするために、アバウトな要件・基本設計でテーブル設計を無理に急いですることもなく、内部処理のために、最も効率的なテーブル設計を行うことが可能となります。
... 中略 ...
基本的にGUIはアジャイル開発が向きます。一方で、ストアドプロシージャはキャラクターベースのプログラムですから、ウォーターフォールの方がむしろ向くのです。最悪、そこからウォーターフォールでアルゴリズムを考えても、今までよりは工数は下がります。

「テーブル設計は実装の後に！」
http://el.jibun.atmarkit.co.jp/g1sys/2009/01/post-037e.html
----

> 当然、テーブルも主キーもインデックスも何もない状態なわけです。
> この状態で、件数はともかく、クエリまで想定できるというのは、どういう意味でしょう？

画面に表示すべきデータがわかっていれば、
テーブルも主キーもインデックスもその場で作れますし、
もちろん、クエリも想定できます。

これが出来なければ、そもそもテーブル設計なんて出来ませんよね。

ビガーです。こんばんは。

まりもさんではないですが、OSSのO/Rマッパーのよさがまったく議論されていないまま、以下のような結論に達しようとしているので、反論をします。

>O/Rマッパーのようなもので覆い隠すようなモノにまったく価値はない。
>O/Rマッパーなど、孫の手の開発でしかないと分かり、麻疹の時期は去っていきます。

私は、Hibernateが好きでソースの深いところまで読んでいて、メリット・デメリットを云いたいところだけど、あんまり議論にならなそうなのでスルーして、生産性という観点で素晴らしいと思う、SeasarのDBFlute(まだまだSQL生成のバグとか多いけど)についての有用性について、述べたいと思います。

DBFluteのいいところは、SQLベース(外だしSQLとかいうやつ)にしなければ、DBの物理設計に変更が生じてもデータアクセス層の修正が不要であること(自動生成してくれるので)。
もう一点は、ページングやソートなどの画面側で必要な制御(に必要なデータ構造の生成)を一括で担ってくれること。(レイヤ間の依存関係を考えるとほんとはイケテないんだけど、それはまぁ使う人のスキル次第やね)

小規模～中規模なシステムのデータアクセス層の管理は、DBFluteにまかせちゃえば、相当な生産性が得られる。もちろんストアドだって発行できるしね。

ページングソートつきの1画面なら2時間もあれば、テストまで終わる。

いろいろと特徴を捉えて、有用に使うべきだと思いますね。

まあ、振り込め詐欺みたいなことやってる業者は淘汰されるべきでしょうね。

プロジェクト炎上
=> 顧客に泣きついて入金だけしてもらう
=> そのままフェードアウト

みたいな光景は何度か見ました。

私はその後始末に入ったわけですけどね。

今までのレベルが低すぎるため、
当たり前のレベルのことでもお客様が感謝してくださいます。
やりやすいといえば、やりやすいわけですけど。
いたたまれない。

> ビガー さん

O/R マッパー も、SQL 生成部分以外は、別に否定されていないと思うのですが。
「（オブジェクトとクエリ結果の）マッパー として使う分には良い」と、
おっしゃっていたはず。

> ページングソートつきの1画面なら2時間もあれば、テストまで終わる。

うーん、そういう「便利機能」部分は持ち出しても仕方ないような。

Visual Studio ＋ ASP.NET だと、
Web フォームにグリッド・コントロール貼り付けて、
プロパティ設定したら終わりですよね。
（ページングもソートもプロパティ設定だけで出来る）

Java コード自動生成の話もコメント欄に出てましたけど、
画面デザインがある程度決まってるなら、
何を使っても、ほとんど自動でできてしまうでしょう。
（自作しても良し）

こんばんは。

> いくら忙しいといっても、通勤時間や昼休みに30分ほどは時間は取れるはず
> です。そういう時間を利用して毎日は無理でも少しずつでも書籍読むなりして
> 勉強はいくらでもできます。

本当にそう思いますか？
だとしたら、あまりにも現実を知らないか、超人的な体力と集中力を持っているかどちらかでしょうね。

たとえば……
朝８時に出勤（車通勤）。
終電関係ないから深夜２時まで仕事。
くたくたで帰宅して、食事して風呂入ってとやっていると、あっというまに
３時過ぎ。
泥のように眠って、７時には起きて朝食もそこそこに出勤。
昼休みは食事を取りながらキーボードを叩くか、仮眠。

という毎日の中、本当に30分であろうと、何か勉強しようという気になれますか？
そういう境遇のエンジニアに聞いたら、たぶん９割以上の人は、「そんな時間があれば休息にあてる」と言うと思いますよ。

> 妻や子供がいてる、そんな家庭の事情は会社や業界には全く関係ない話
> ですね。勉強し無ければ、後でえらい目にあうのは自分ですからね。

会社は業界には関係ないですよ、もちろん。
ただ、家庭を持つということは、経済的な責任が生じるということです。

自分の会社の方針に不満があっても、ある程度の給料が保証されていて、家庭を大切にしている人。
自分のやりたいことをやるために、収入の保証はないけど、転職する人。
どちらが正しいかなんて、誰にわかるでしょうか？

> flatline さん

> どちらが正しいかなんて、誰にわかるでしょうか？

どちらが正しいかは誰にもわかりませんが。
誰が生き残るかを決めるのはお客様ですね。

flatline さんだって、より安くて質の良いものを買おうとなさるでしょ？
従業員の生活を思って、高くて質の悪いものを買おうなどとはなさらないはず。

ron さん、回答をありがとうございます。

> 読み違いだと思います。
> 私が読むところ、「テーブル設計は実装の後に」というのは、
> 「実装の前にテーブル設計」を否定するためのレトリックです。

そういう意味だというのであれば、まあわかりますが。
ただ、

> 私はDB設計を後回しにしたいから、
> http://el.jibun.atmarkit.co.jp/g1sys/2009/01/post-037e.html
> 全部ストアドプロシージャにしようよと言ってます。

という文言から、「極端な場合はそうもできるけど普通はしない」
という意味を読み取ることができなかったので、あれこれ質問して
しまったわけですが。

> 画面に表示すべきデータがわかっていれば、
> テーブルも主キーもインデックスもその場で作れますし、
> もちろん、クエリも想定できます。

１つの画面に１つのテーブルが対応するという単純な状況ばかりとは
限らないので、全部のケースで「その場で作れる」とは思わないですが、
言わんとするところはわかります。

もっとも、この段階（デモ画面作成ぐらいの）なら、ストアド使う
必要はないし、もっと言うなら、テーブルとかインデックスとか
考える必要すらないですね。インターフェースとダミーの実装で
適当なデータを返すようにしておけば、１台のノートＰＣにＤＢとか
インストールする必要すらなく、動作する環境が作れますよね。
そのまま客先に持って行けばＯＫ。

という意味で、デモ画面作成のためのストアドにメリットが見出せないわけです。
ノートＰＣにＤＢなんかインストールしたくないので。

> ron さん

> 誰が生き残るかを決めるのはお客様ですね。

顧客の視点から見ればそうですね。もちろん顧客は、顧客の価値基準でエンジニアを選ぶ権利があります。
だから、エンジニアも技術の勉強を怠るべきではない、というのも正論です。

でも、世の中にはいろいろな理由で勉強したくても時間が取れないエンジニアも存在しますね。
ron さんは、そういうエンジニアの人たちはどうすればいいと思いますか？
「そういうエンジニアは淘汰されてしまえ」でしょうか？

flatline さん、

>全体がそれなりに幸せになれる方法を考えていただければと思います。

過去記事になりますが、随所にいくつかのアイデアは出ていますね。
それをここで、繰り返して言えというのも酷ですから、過去記事にもざっと目を通してみると良いと思いますよ。

後半消えたのでつけたしです。

>でも、世の中にはいろいろな理由で勉強したくても時間が取れないエンジニアも存在しますね。
>ron さんは、そういうエンジニアの人たちはどうすればいいと思いますか？
>「そういうエンジニアは淘汰されてしまえ」でしょうか？

論点のすり替えになっちゃってますので、まずいと思いますよ。

oumi さん、こんばんは。

> 過去記事になりますが、随所にいくつかのアイデアは出ていますね。

ありがとうございます。探してみます。
どうも生島さんのコラムやコメントには、

> 石に齧り付いてもスキルを身に付けるか、違う業界へ転職するかしろ！

> そんな人はさっさと淘汰されるべきで、議論の対象じゃないのです。

のような、ちょっと過激な言葉が多いようなので。
文字通り捉えると「勉強する時間が取れないようなエンジニアは切り捨てられて当然」と言われているようで、どうかな、と思ったので、

>全体がそれなりに幸せになれる方法を考えていただければと思います。

と書きました。

> 論点のすり替えになっちゃってますので、まずいと思いますよ。

すみません、どの部分がでしょうか？
どうも時間帯のせいか頭が働いていないようで。

こんばんは。
saki1208です。

どのような過ごし方をしようと、すべての人に"平等"に一日は24時間しか
ありません。意図しようとしなかろうと関係なくorz

時間は自分で作らないとできません。

ただ、現状を変えていきたいと思う気持ちがあってアンテナを高くしてい
るからこそのいろいろな質問、意見になっているのだと思います。

気持ちの持ちようだけだと思いますよ。

おはようございます。
SQL談義がなさりたかったんですね・・・。

>OO言語側にロジックを入れるメリットは、できない人でも使えるという、何とも情けない理由しかないのですから。

その他諸々でおっしゃっている事項について、【パラダイム】というもので
説明がつくと考えております。

突然ですが、ポケベルをお使いではありませんか？
携帯電話のちまちました画面で、メールなんか書いている輩は軟弱者だと
思いませんか？
携帯電話は、デジタルになってから電波の入りが悪くなりました。ちょっとでも
ビルの奥にいくと入らなくなってしまいます。
そんな不安定もの使っているより、ポケベルのほうが確実に届き、ビジネスで
使うならば携帯電話なんて信用ならないですよね！？

…そんなこと言っても、いまやポケベルの会社も倒産してしまいましたし、
入手したくてもできないのが現状です。

このように、支持される製品やサービスが時代とともに移行していく様子を
パラダイムシフトと言います。
これに逆らおうとしても、どうにもならない事です。

生島さん風の過激な書き方で言えば、「近頃○○が多くて疲れません？」
とでも言いたくなる気持ちもわかります。

しかし、20年前であれば、生島さんのおっしゃりたい事は諸手をあげて
大賛成です。10年前なら半分くらいかな？

OO言語で素人でもロジックを書けるようになったのは、プロの側からすると
なんとも情けない話です。しかし、素人でも書けるようになるというのは
時代の要請でもあるわけです。

この流れに逆らっても良いのですが、頑なに携帯を否定しつづけても
(SQLがポケベルほどシフトされているとは思いませんが)意味は無いと
思いませんか？伝統工芸ではないのですから…

みなさん、おはようございます。

よっぽど嫌な人もいるのだと思います。
例えば、合計小計を表示する例がありましたが、考える人によって、SQLを3回実行する人も、ブレイクのたびに集計SQLを実行する人も出るでしょう。
簡単だから、一気にやろうという人も出るでしょう。

判断の基準が、簡単だから、複雑だから、遅いから、速いから、では揃わないのです。

この程度でも混在型になっていては、複雑な処理ではどうなっているか想像もつかない。それが良いと考えるのは、「SQLではできない」という思いが出るから。
2、3段階ステップアップすれば、SQLの方が簡単となります。

何度も書いていますが、デメリットは「できない人」にしかない。
それはプロとしてはやってはならない言い訳でしょう。

皆様、おはようございます。

> flatline さん

> １つの画面に１つのテーブルが対応するという単純な状況ばかりとは
> 限らないので、全部のケースで「その場で作れる」とは思わないですが、
> 言わんとするところはわかります。

画面が増えていけば、都度調整していけばよいわけでして。
そのためにストアドで境界を分けておくわけでしょ？

また、基本設計レベルでおおまかな全体像くらいは見えている、
という前提はあるんじゃないですかね。
画面１つ分しかわからない、ということはないと思います。

例えば、

要件定義、基本設計 => テーブル設計 => 画面実装

という工程の流れがあったとして、これを、

要件定義、基本設計 => 画面実装＆テーブル設計（並行）

あるいは、

要件定義、基本設計＆画面実装＆テーブル設計 （並行）

にしよう、というのが生島さんの主張だと思います。

ものによっては、全部並行でやってもいけそうですね。
テーブル設計を事前に完成させる必要がないわけですから。

> インターフェースとダミーの実装で
> 適当なデータを返すようにしておけば、１台のノートＰＣにＤＢとか
> インストールする必要すらなく、動作する環境が作れますよね。
> そのまま客先に持って行けばＯＫ。

それだと、紙芝居レベルと大して変わらないわけで、
それこそ、基本設計段階で済ませておくものではないですかね。

工程短縮ができなきゃ、ビジネス上のメリットとしては弱いですよ。
どうも flatline さん には、
大幅な工程短縮を狙って、提案競争に勝とう、という視点がないですね。

> flatline さん

> ron さんは、そういうエンジニアの人たちはどうすればいいと思いますか？
> 「そういうエンジニアは淘汰されてしまえ」でしょうか？

コラムのテーマからは完全にはずれてしまいますので、手短に。

エンジニアが、お客様に対して相応の価値を提供できなくなれば、
淘汰されてしまうのは仕方のないことでしょう。
私だって、要りもしないものにお金を出そうとは思いませんから。
どうすればいいかなんて知りません。こっちが聞きたい^^)

ストアドプロシージャは、そもそもトランザクションの正規化をするための技術だという点を忘れてはならないと思います。
パフォーマンスのためだけに開発された技術ではありません。

> ひら さん

> このように、支持される製品やサービスが時代とともに移行していく様子を
> パラダイムシフトと言います。

パラダイムはシフトしてないですから。
相変わらず、企業システムの中心には、RDBMS が鎮座してます。

生島さんは、O/R マッパー（SQL ジェネレータ）じゃなくて、
RDBMS に変わるものを作れ、
とおっしゃってますが、それこそが、パラダイムシフトでしょう。

この議論を見ていてずっと疑問に感じていたのですが、何故オブジェクト指向とSQLが対立していると考える人が居るのでしょうか？
単純に両方使えばいいのです。それぞれに使うべき領域があるだけです。
それに、理論的にもSQLとは対立していません。
オブジェクトもデータも集合として考えれば一緒ですし、そう考えないとオブジェクト分析＆設計なんて出来ません。
将来SQLが要らなくなると言う人が居ますが、それは将来考えればいいのです。
将来SQLが消えてUIO（適当な３文字熟語）の様な新技術が出ればまたそれを学習すればいいのです。
プロなんだから常に鍛錬するのは当然の行為なのです。
目の前の仕事をこなし、それと同時に将来に備えるだけの基礎技術力を鍛え続ける事が、プロとして求められている事でしょう。
両方学習すればいいだけの話しです。
職場環境の話しはまた別の話題ですので、一緒に論じない方が良いと思います。

>本当にそう思いますか？
>だとしたら、あまりにも現実を知らないか、超人的な体力と集中力を持っているか
>どちらかでしょうね。

私はあなたのようなそんなひどいデスマーチのpjへは参加したことが無いので
知りませんが、勉強するしないは個人の自由なのでしければ困るの自分なんだから。

みなさん、こんにちは。

技術者のスキルが高まれば、最終的にはコーディング量とコストが比例します。理論的にはSQLで書いた方がコーディング量は減りますから、数十％以上の効果が出ます。（教育コストは一時費用なので無視して良い）
現実的に10％下がるとしましょう。（もっと差が出ますが）

SIerの人件費＋外注費は、会社全体のコストの70～80％で、利益率は5％～20％です。

仮に10％生産性をあげれたら、全体の利益率が3.5％上がる計算です。経営者は5％～20％の利益率を必死で追いかけていますから、10％の生産性というのは、もう、のっぴきならない数字なのです。

仮に5％の利益が8.5％になったら、対前年比70％の伸び率で、経営者は喜色満面で決算発表できる数字です。上場してたら、余裕でストップ高にできるぐらいのインパクトがあります。

つまり、手法を変えて10％生産性を上げれるなら、経営者なら有無を言わさず飛びつく数字です。

それをグチグチ言う奴らというのは、結局、会社が何か分かってない。

トヨタのカイゼンなど0.01％の積み重ねですから、10％なんて数字はもうイノベーションと呼んでよい数字です。そこで技術者が抵抗しようモノなら即クビが飛びます。

コの業界はまだまだ若く、「イヤだから」って下らんガキンチョの意見が通ったりしますが、そんな人達がSIerとして、お客様の会社にどれだけ価値のあるモノを提供できているのか疑問です。

とはいえ、10％ぐらい、モチベーションで一瞬に変わる数字です。
それはどんな手法を用いても同じことで、常に考える必要がある。
現状では、「イヤならクビだ」はモチベーションを下げるのでできない。

けれど、お客が気づいたら簡単にできるのよね～。

次はそんなお話。

もちろん、人月でやっているところは、まぁ、生産性が上がる＝売上減となるからこの式にはあてはまらないけれど、技術者も、イヤだイヤだと言いながら、そっちに染まっていることのに気づいてないのかな～。

みなさま、おはようございます。

全然、別の話題でコメントが長くなっていくのも変ですが。

> ronさん
> 淘汰されてしまうのは仕方のないことでしょう。

なので、業界が変わるなら、勉強して技術力をつける時間のとれない技術者が淘汰されないように変わってほしいと思うわけです。
「できない人は業界から去ってね。残りの優秀な人でやるから」
という変わり方だと、私も含めて多くのエンジニアに支持されないのでは、と言いたかっただけです。
勉強する時間も環境もあるのに、向上心のないエンジニアは淘汰されてもいいと思いますが。

> 士郎さん
> 勉強するしないは個人の自由なのでしければ困るの自分なんだから。

そういう風にまとめられたら、具体例とか意味ないですね。
では、あくまでの仮定の話ですが、先に書いたような「ひどいデスマーチのpj」
に士郎さんが参加することになったとしたら、それでも勉強する時間取れると
思いますか？

ビガーです。こんにちは。

>ronさん

>「（オブジェクトとクエリ結果の）マッパー として使う分には良い」と、
>おっしゃっていたはず。

DB設計が変わるとそのマッパー部分に必ず改修が入るはずですよね。そのコストがほぼ０というのは相当なメリットだと思いますが。
皆さんはどうされているんですかね？具体的なツールを是非教えてほしいです。

>Visual Studio ＋ ASP.NET だと、
>Web フォームにグリッド・コントロール貼り付けて、
>プロパティ設定したら終わりですよね。
>（ページングもソートもプロパティ設定だけで出来る）

これ、UIとかプレゼン層の話ですよね。私の云っているのは、データアクセス層に関してです。上記の場合、データアクセス層はどうしているでしょうか？

しつこいですが、DBFluteのいいところは、DBの物理定義からデータアクセス層の部分をすべて自動生成します。生成されたエンティティをUIやプレゼンで使ってしまえば(レイヤがアレですが)、相当な生産性になる。ちなみに.net版もあります。

>Java コード自動生成の話もコメント欄に出てましたけど、
>画面デザインがある程度決まってるなら、
>何を使っても、ほとんど自動でできてしまうでしょう。

そうなんですか。中途半端な自動生成ツールなら山ほど見てきましたが、有用なツールがあるなら是非教えてもらいたいです。
多くの現場を見てきましたが、自動生成ツールでほぼすべてを開発しているところは見たこと無いです。

あと、画面デザインというより、「画面項目」が重要だと思います。その画面で何をしたいのか(目的)を明確にすることに役立ち、それがDBやオブジェクトの属性になりますから。

余談ですが、私が短時間でできまっせといった理由としては、Javaでもフロントローディングができる時代だといいたかったのです。RoRとかでサクっと作っても、合意得たら実装は捨てることが多かったから。

やっぱり実物見せながらお客様と話せるのはデカイ。

ronさん、こんにちは。

> ものによっては、全部並行でやってもいけそうですね。
> テーブル設計を事前に完成させる必要がないわけですから。

えーと、私は全部並行してやってますが、そういう方法に反対しているように聞こえましたか？だとしたら誤解させてすみません。

> それだと、紙芝居レベルと大して変わらないわけで、
> それこそ、基本設計段階で済ませておくものではないですかね。

ひとつ確認したいですが、ronさんの言う「紙芝居」ってどのような用途を想定されていますか？
顧客に画面イメージを確認するため「だけ」のもの？
それとも、そのまま実際の画面に使用するもの？

>では、あくまでの仮定の話ですが、先に書いたような「ひどいデスマーチのpj」
に士郎さんが参加することになったとしたら、それでも勉強する時間取れると
思いますか？

横やり失礼します。
私はデスマーチが当たり前の状態で暮らしてきたから断言できます。
それでも勉強をしなくてはなりません。
出来る／出来ないではありませ、やる／やらないなのです。
もし物理的に出来ない場であるならば、自分が環境を変えます。
私はそうやって生き抜いてきました。
仕事環境が劣悪なのは問題だと思いますが、だからといってやらない方に思考が進んではならないと私は考えております。
学習をするのを前提に、その劣悪な仕事環境を変えていかねばなりません。
※あんまり記事の主旨と関係の話しをしない方がいいですよ。

ビガーさんこんにちは。
›皆さんはどうされているんですかね？具体的なツールを是非教えてほしいです。

私の場合は自作ツールでやっていましたが、今はフルスクラッチです。
画面もデザイナを使用せずにフルスクラッチで行います。
そうした方が柔軟性が高いのでお勧めです。

ビガーです。連投ですみません。

本題とはちょっとズレますが、ご容赦を。

>インドリさん

>オブジェクトもデータも集合として考えれば一緒ですし、そう考えないと
>オブジェクト分析＆設計なんて出来ません。

インドリさんは、オブジェクト指向分析・設計ってどういう風に進めているんでしょうか？前々から気になっていました。
私は、オブジェクトの抽出の仕方とオブジェクトの関連のつけ方が重要と考えており、私のコラムで以前述べているコトが基本です。

今まで経験されたプロジェクトをベースに簡潔に教えてほしいです。ブログのココ見ろでもいいです。(私が云うのもなんですが、他人の意見ではなく)

なんか議論がぜんぜん違う方向に行ってますが・・

インドリさんと同じ意見です。最後はやる／やらないの世界だと思います。
別に毎日数時間確保しろといっているわけではありません。たとえ5分でも
10分でもいいのでそれが積み重なっていけば、分厚くなければ書籍も月に
1冊程度は読めるでしょう。
また、勉強できるように環境や努力もすべきですが、最悪なデスマーチだと
環境を変えるのは確かに難しいかもしれません。でもそれを理由に全く
やる気がでないという理由でしなかったら成長は難しいと思います。

> ビガー さん

なんか、コラムのテーマからずれていってますが。

私と ビガー さんだと、
前提となるアプリの構成が全く違うので、
あまり参考にならないかもしれません。

私のやり方だと、アプリ側にビジネスロジックは、
ほぼ入らないので、アプリは UI 層だけになるんですよね。

> DB設計が変わるとそのマッパー部分に必ず改修が入るはずですよね。

ほとんど入りません。
アプリに DB 使う業務ロジックが、
ほぼないからです。

もし必要になった場合は、
Ruby スクリプトでレイアウト変換やってます。

> これ、UIとかプレゼン層の話ですよね。私の云っているのは、データアクセス層に関してです。上記の場合、データアクセス層はどうしているでしょうか？

.NET の場合、DataSet クラスのインスタンスを、
コントロールに自動バインドする形になります。

DataAdapter（SQL 実行）
⇔ DataSet ⇔ DataSource ⇔ 各種コントロール

というのが、一般的パターン。
（上は全部 .NET Framework の組み込みクラス）

UI から入力された、
DataSet の各フィールド値を、
そのまま入力チェック＆クエリにして DB に投げる仕組みもあるので、
定型的な UI なら、BusinessObject を作る必要すらない。

DB 使うロジックは DB の中にストアドで存在する、
ということは、アプリでやるのは、
入力形式のチェック＆フォーマットくらいです。

> そうなんですか。中途半端な自動生成ツールなら山ほど見てきましたが、有用なツールがあるなら是非教えてもらいたいです。

これは、 ぴあちゃん さんのコメントですね。
http://el.jibun.atmarkit.co.jp/g1sys/2009/12/post-eab5.html#c30965417

汎用は無理だと、私も思いますよ。
出来るなら、Microsoft がとっくにやってるでしょうし。

特定のお客様に対して、そのお客様が欲しい画面のパターンが決まっていれば、
(Java ＋ 何かの既存のツール or .NET) ＋ 自作でできると思います。

どちらにせよ、定型画面なら、大した工数にはならないですし、
デザイン・スタジオが作るような、凝ったデザインの画面なら、
自動化は無理で手作りするしかないでしょうね。
（レイアウトが 1 ミリずれても、デザイナーさんに怒られる）

> やっぱり実物見せながらお客様と話せるのはデカイ。

もしかして、お客様と打ち合わせしながら、コーディングですかｗｗ

昔、 1 度やったことがあるけど、どうも落ち着かないのですよね。
見られながらやるのに慣れてないせいでしょうけど。

# このコメント欄、lt gt は消えるんですね。
# 矢印記号がマルチバイト文字になったのはそういう事情です。
# 読めない人はすみません。

> flatline さん

> えーと、私は全部並行してやってますが、そういう方法に反対しているように聞こえましたか？だとしたら誤解させてすみません。

DB 設計・実装も並行ですか？
DB 使わずにどう並行します？
実際に DB に実装せずに、設計だけ紙（Excel）でやるってことですか？

> 顧客に画面イメージを確認するため「だけ」のもの？
> それとも、そのまま実際の画面に使用するもの？

実際の画面に使用するものですね。
簡単な動きくらいはついてる。

けど、本番データを入力して、
その結果がどうなるかを確かめることはできない。

flatline さんは、データ入力＆結果確認まで、
スタブで作るんですか？
それこそ工期の無駄使いでは。。。

ビガーさんへ
›インドリさんは、オブジェクト指向分析・設計ってどういう風に進めているんでしょうか？前々から気になっていました。

簡潔に言います。
先ず、分析段階では概念の定義を行います。
ここではお客様に用語の確認をしたり、部門間の用語の差異を調べたり・・・
と、システム範囲内のでの物事の側面を決定します。
これは粒度を変えながら何段階も行います。
お客様とメンバー間で概念についての見解を統一出来たら終了です。
※私の場合、この時点で運用段階や保守段階も想定に含めて、
システムのライフサイクル全体について考えます。
脳内シュミレーションで大体わかります。
それで、仕様書のバグを詳細に潰します。

次に設計ですが、システムを実現するにあたってどの様にシステムで実現するのかを決定します。
この段階では「人も含めてシステムを設計」します。
システムとは何も全てプログラムである必要はなく、人がやれば効率がいいものは人で、コンピューターが得意な分野はプログラムで実現します。
そういった業務全体を考えたシステムを実現するにあたって、何の技術を採用するのかもここで決めます。
データベースを使用するか／否か、使うならばRDBかXMLDBかOODBか、
プログラム言語は何か？使うのであればどうするのか？
などを決めて、開発環境（アジャイルツールの準備、コーディングルールの決定など）もここで検討します。

本当はもっと複雑（DOAやPOA視点からも検証したりする）なのですが、大体のところはこんなところです。
私はERPの構築を任せられる事が多かったので全体を視野に入れて考える癖が付いています。
そんな私にとっては、データもオブジェクトも集合であり、脳内で自由に変更できます。

こんばんは。

> インドリさん
> もし物理的に出来ない場であるならば、自分が環境を変えます。
> 私はそうやって生き抜いてきました。

強いですね。でも、世の中には疲れ切ってそんな気力も持てず、毎日の仕事をこなすだけで精一杯の人もいるんですよ。みんながみんなインドリさんのような気概を持っているわけではないです。

> 学習をするのを前提に、その劣悪な仕事環境を変えていかねばなりません。

理想ですね。でも、変えられる力を持った人はごく少数だと思います。

> ※あんまり記事の主旨と関係の話しをしない方がいいですよ。

そうですね。たぶん、私が「勉強できない環境の人もいる」と現実を言ったところで、「そういう環境を変えていかなければならない」「勉強しない理由にはならない」と理想で返されるだけで、行き着き先はないので、もうやめにしましょう。

> 士郎さん
> 別に毎日数時間確保しろといっているわけではありません。
> たとえ5分でも10分でもいいのでそれが積み重なっていけば、
> 分厚くなければ書籍も月に1冊程度は読めるでしょう。

それすらできない人は、現実にいますよと言っているのですが、
理想で答えられても、「そうですか」としか言えないです。
デスマーチ環境でも勉強時間取れますか、？という質問にも
はっきり答えてもらっていないし。別に答えを強制するつもりはないですが。

とにかく言いたいことは、つまるところ一つです。
業界が変わるなら、優秀な人だけ生き残ればいい、という安物の優生学のような方向ではなく、顧客も開発者も、大手も下請けもみんなが幸せになれるような方向に変わってほしいと思います。
これが私の「理想」です。

ronさん、こんにちは。

> DB 設計・実装も並行ですか？
> DB 使わずにどう並行します？

全部ってのは語弊がありましたね。
イメージとしては、

> 要件定義、基本設計＆画面実装＆テーブル設計 （並行）

に近いですね。ただ、要件定義と基本設計が明確に分かれている
わけではないですが。
テーブル設計はしますが、項目名を定義するために設計する
だけで、実際にＤＢアクセスは必須じゃないですね。
画面項目、テーブルのカラムは、開発中、頻繁に変更するし。

> 実際の画面に使用するものですね。
> 簡単な動きくらいはついてる。

その前のコメントで、

> それだと、紙芝居レベルと大して変わらないわけで、
> それこそ、基本設計段階で済ませておくものではないですかね。

と言われていますが、基本設計段階で紙芝居作ったら、そのまま
変更せずに、実際の画面に使用するということですか？まさか、
今どきそんなウォーターフォールじゃないですよね？
顧客の承認印もらったら、それを絶対変えないとか。

客先にＰＣ持ち込んで画面（紙芝居）の変更とかしなければならない場合、
必ずしもＤＢがあるとは限らないので、ＤＢアクセスしなくても
いいように紙芝居作るだけです。インターフェースだけあれば、
実装は自社で誰かにやってもらってもいいですよね。
だから、インターフェース＋ダミーの実装にしてる。それだけです。

> flatline さんは、データ入力＆結果確認まで、
> スタブで作るんですか？

まさか。あくまでも、顧客に動きを見せて確認する段階ですよ。
実装部分を差し替えるのなんか簡単なので。

> どうも flatline さん には、
> 大幅な工程短縮を狙って、提案競争に勝とう、という視点がないですね。

こういうことを書くと、敏感な人なら過剰反応して炎上しますよ。
私は人間ができているので、別に怒りませんが。
だいたい、こんなコメントの数行の文章だけで、相手のビジネススタイル
を推測できると本気で思っているのなら、少し浅はかではないでしょうか？
私が顧客なら、そういう人に自社のシステム開発を依頼したいとは思いませんね。
（って書かれたら、ムッとしませんか？）

みなさん、こんばんは。

なんというか、勉強できない人に配慮しろとかわけが分かりませんな。
そんな訳の分からんことを考える連中は早いこと淘汰したいね～。

http://el.jibun.atmarkit.co.jp/g1sys/2009/10/post-e1e0.html
http://el.jibun.atmarkit.co.jp/g1sys/2009/04/post-9305.html

私は物理学者になりたかったから、大学には行きたかったな～。
仕事をしなくても食べれるようになったら、今でも、大学に行きたいと思っています。それは私のはかない、叶わぬ夢ですわ。

それでも、日本に生まれただけで十分恵まれています。

何十億という人間を平等にするなんて、1億数千万の人間を平等にする方法なんて、神も持ち合わせてないのです。

更にいうなら、結果を平等にするなんて、マルクスですら考えなかった、とてつもなく馬鹿げた考え方です。

誰しも、過去は変えることはできませんから、今いるところから努力するしかない。成人になって勉強できる環境にないとか……、そんなこと自己責任以外の何モノでもないでしょうが。笑い話にしてもふざけ過ぎですわ。

今、思うようなことができないということは、過去の自分のどこかが間違っていたので自己責任です。

「業界を変えてやる！」と「勉強できない環境の人に配慮が足りない」って全く噛み合わんな～、話にならんし、そういう人がこの不況を乗り切るのは……。
考え方を変えないと厳しいと思いますけどね。

酔ってるのでこれまで。

ビガーです。こんばんは。

>ronさん

O/Rマッパーに価値が無いと生島さんが主張されていることに対して、生産性が高まるO/Rマッパーもあり、「価値がある」というのが私の主張なので、ズレてはいないと考えています。

>アプリに DB 使う業務ロジックが、ほぼないからです。

なるほど、それではDBFluteはまったく関係ないですね。

敢えてDataSetの話をしていただきありがとうございます。

>DataSet の各フィールド値を、そのまま入力チェック＆クエリにして DB に
>投げる仕組みもあるので、定型的な UI なら、BusinessObject を作る必要すらない。
ここで気になるのは、DBトランザクションの単位ですね。失敗した場合のロールバック単位はどうなるのか、どこで定義するんでしょうか？
この部分は必然的にコーディングかアスペクトの定義がいると思いますが、どうやって関連付けしているんでしょうか。

>もしかして、お客様と打ち合わせしながら、コーディングですかｗｗ

そうですね、打合せ前に大枠のイメージを共有していることが多いので、誤差はその場で修正しちゃいます。
画面仕様書とかで担保取ろうとしている方もいますけど、こっちの方が断然効率的で、お互いにメリットが多いと思っています。

>インドリさん

ご回答ありがとうございます。

>ここではお客様に用語の確認をしたり、部門間の用語の差異を調べたり・・・
>と、システム範囲内のでの物事の側面を決定します。
>これは粒度を変えながら何段階も行います

このフェーズでは、具体的にどういうツールやモデルを使って表現しますか？
また、この段階をダラダラ続ける方が個人的に多いと思っていますが、どの程度の期間で実施されますか？

>この段階では「人も含めてシステムを設計」します。
>システムとは何も全てプログラムである必要はなく、人がやれば効率が
>いいものは人で、コンピューターが得意な分野はプログラムで実現します。

これについては、分析フェーズではなく、設計フェーズで実施する理由がわかりません。システム化検討(コンピュータで実現するべき)スコープは、設計の粒度では絶対にないはず。敢えて設計フェーズでやるメリットは何でしょうか？

それと設計フェーズでのモデリングもするはずですが、分析フェーズ同様具体的な手法を提示いただけると勉強になるのでお願いします。

あと、分析・設計フェーズには多くのコンサルやエンジニアが関わるはずですが、そういう方々との合意も重要だと思うのですが、どう折り合いをつけているのでしょうか？

こんばんは。

酔って書かれた文章にあれこれ言っても仕方がないのかもしれませんが。

> 更にいうなら、結果を平等にするなんて、マルクスですら考えなかった、
> とてつもなく馬鹿げた考え方です。

結果を平等にすべきだとは言っていませんが。

> 今、思うようなことができないということは、過去の自分のどこかが
> 間違っていたので自己責任です。

へえー、あまりにも短絡的に思えますね。
酔っているから仕方がないかもしれませんが。
勉強できる環境にないことが、そんなに罪ですかね。
これまでずっと勉強する機会がなくて、これからも状況は変わらないと思うけど、
でも、いつかきちんと勉強したい。そう思っている人も淘汰されるべきだと？

前にも書きましたが、本気で「業界を変えてやる！」と思っているのなら、
「一定のレベル以下のエンジニアは淘汰されるべき」という考えだと
たぶん失敗しますよ。
考え方を変えないと厳しいと思いますけどね。

ゆとりの影響でしょうね。
確かにどうしようもないカスが多いから、多数決が正しい世の中では、まぁ、私の方が先に滅びますけれど、どうにかしてカスを排除できる業界にしたいです。

生島さん
はじめまして、こんばんわ。

常識が合わないから炎上したと。
そこまでわかってらっしゃるならここらで生島さんの常識を
コラムのエントリで定義されてはどうでしょうか？
「ベンチャー社長で技術者での用語集」見たいな感じで。
それで無意味な炎上もいくらか収まるのでは？そこを読めと。
過去のエントリとコメントを全部読めはきついです。

１．対象はRDBMSを使うすべてのシステム
２．他システム連携が必要な業務ロジック除く
３．２があるから画面とストアドの間に1クッション入れるのはあり？
４．SQLとはPL/SQLを含む？PL/SQLでロジックを組んだらこれも混在型ですか？
とか

わざとでしょうけど、タイトルとかコラムの内容で風呂敷広げすぎてますよ。
で、「他システム連携はどうするんだ」とかつっこまれる。
そこは別だろ当然だろってまあ読んでれば分かりますけどね。
でもでかいこと言ってる人だからもしかしたらうまいことできるの？
と確認したくなるのも分かる。

最後に個人的な興味として2点ほど伺いたいです。
a.２相コミットをやる必要がある場合どうされるのでしょう？
　トランザクションだけ外だしとかですかね。
b.画面入力によってwhere句が動的に変わる場合（検索条件が部署だけだったり、部署と役職だったり）とかもSQLだけでやるんですか？

>デスマーチ環境でも勉強時間取れますか、？という質問にも

答えましょう。時間は取ります。
確かに疲れているから数時間取れるのは難しいも知れないし、毎日は無理かも
しれない。だけど、たとえ5分～10分でも勉強は可能です。
本人にやる気があるなら、たとえ苦しくて疲れていてもできます。
私は業界で生き残りたいし、まだまだ未熟なので勉強しなければならないことが
山のようにあります。そんなことで勉強しないなんてことは、考えられません。

生島さんこんばんは。

私も高校生くらいの頃、福祉なんてなくなっちまえばいいのに、なんて考えていた時期がありました。生島さんはそれを業界レベルで実現したいと考えてらっしゃるんですね(今更ですが)。

> 多数決が正しい世の中では、まぁ、私の方が先に滅びますけれど、
しかしご自身でおっしゃられているように、やはり自分の死後の世界を考えても詮無いことですよね。
ですので、私の場合は職場を変える事にしました。政治をやるつもりはないので、手の届く範囲で改善する予定です。そのためにO/Rマッパー(SQLジェネレータ)も、恥ずかしながら孫の手として使います。でなければうちの顧客は数百人の“初級シスアド以下”が作ったシステムに悩まされてしまいます。SQLのトレーニングなんて考えもしない上司は、目新しい“フレームワークとやら”には大金をはたきます。結局本質的には何も変わらないでしょう。

生島さんの意見でいけば、私も私の会社も同僚も、皆淘汰されるべきでしょう。私も、うちの会社の顧客であったならそう思います。それが当然です。
ですが、そうならない。それは生島さんも十分ご承知のことと思います。であれば、生島さんほどの方には今のように自棄的でなく、もっと建設的であってほしい。凡な私はそう願わざるをえないです。

ITアーキテクトというポストを広めればなんぼか良くなるのかな、まず横文字に弱い人たちを篭絡しないと、というのが月並みな私の今の考えです。

こんばんは。

> 確かにどうしようもないカスが多いから、多数決が正しい世の中では、
> まぁ、私の方が先に滅びますけれど、どうにかしてカスを排除できる
> 業界にしたいです。

カスって誰を指してるんでしょうね？
しばしば見られる過激な発言はわざとあおっているのか、本心なのか、
よくわかりませんが。

uz256 さんも書かれていますが、一度、生島さんのビジョンをまとめてみては
いかがでしょう？確かに「過去のコラムに書いたので読んでね」というのは
量も多いのでちょっと大変です。一部だけ読んで曲解されるのは心外だと
思うので。

生島さんが考えているほど、この業界はカスばかりではないので、
本当に優れたビジョンだとみんなが思えば、自然と広がっていくと思います。
そうでなければ、自然に「淘汰」されるでしょうし。

今のままだと残念ですが、単にSQLが得意な人（まあ生島さんは「得意」
なんてレベルを遙かに超えた達人なのかもしれませんが）が、自分の
優位性を確保しようとして、無理矢理「コンサルもマネージャーも、
もちろんプログラマも全員SQLの達人になれ」とぶちあげているだけにしか
聞こえないです。少なくとも私には。

あと、酔っていようが素面だろうが、特定の誰かにだろうが不特定多数に
だろうが、「カス」とか言わない方がいいですよ。技術的にどうのこうの
いうまえに、人間性疑ってしまいます。そういう先入観で、自分の話が
聞いてもらえないのは悔しいでしょ？

saki1208です。
なんか埋もれちゃったので、もう一回書きます。

>flatlineさん
どのような過ごし方をしようと、すべての人に"平等"に一日は24時間しか
ありません。意図しようとしなかろうと関係なくorz

時間は自分で作らないとできません。

ただ、現状を変えていきたいと思う気持ちがあってアンテナを高くしてい
るからこそのいろいろな質問、意見になっているのだと思います。

気持ちの持ちようだけだと思いますよ。

士郎さん、こんばんは。

> 答えましょう。時間は取ります。
> 確かに疲れているから数時間取れるのは難しいも知れないし、毎日は無理かも
> しれない。だけど、たとえ5分～10分でも勉強は可能です。
> 本人にやる気があるなら、たとえ苦しくて疲れていてもできます。

ありがとうございます。

まあ、士郎さんは実際にデスマーチを経験したことがないと明言されている
ので、「たとえ苦しくて疲れていてもできます」なんて言葉には全く
重みが感じられませんけどね。

言うだけならなんとでも言えますね。言うだけなら、実際にデスマーチに参加する
必要も、睡眠時間を削る必要も、鬱病寸前までコード書く必要もないのですから。

お気楽な立場から、理想を語っていただいてありがとうございました。

saki1208さん、こんばんは。
すみません、見逃してしまってましたね。

> 時間は自分で作らないとできません。

何度か書いていますが、意欲があっても状況や環境で許されない立場の人もいますよね。
「１日わずかの時間も確保できないはずがない」なんて、過酷な現実を知らないお気楽な立場からの理想論に過ぎないです。

> 気持ちの持ちようだけだと思いますよ。

いかに高い気持ちがあっても、状況や環境によっては、全く生かせない場合だってありますね。
理想はなくしてはいけないと思いますが、理想だけでデスマーチは解決しないし、１日は３０時間になったりしません。

もう、この話題終わりにしませんか？
絶対、収束しないですよ。

flatlineさん、こんばんは。

saki1208です。

何の自慢にもなりはしませんが、私はデスマーチに参加したことはありますよ。
それこそ、月500時間弱、3、4ヶ月休みなしで働かされました。
# 複数回ありますが、どれも最初はヘルプで参加したプロジェクトです。
# 入ったその日に危険な香りを感じましたけどね...

考え方を変えてはどうでしょうか。

私は失敗プロジェクトでは、成功プロジェクトでは絶対に学べないものがある
と思います。

技術的な勉強は少し落ち着いて余裕ができてからやってもいいじゃないですか。

saki1208です。

flatlineさん、ごめんなさい。
>もう、この話題終わりにしませんか？
>絶対、収束しないですよ。

そうですね。もう終わりにしましょう。
私からは触れないことにします。

がるです。
軽く、ですが。

To 生島勘富さん
> 確かにどうしようもないカスが多いから、多数決が正しい世の中では、まぁ、私の方が先に滅びますけれど、どうにかしてカスを排除できる業界にしたいです。
本当の意味で「カス」な人っていうのは、いらっしゃるんでしょうか？
その人は、本当に「使い物にならない」んでしょうか？
「その人の持っている素晴らしいところが見えていないだけ」という可能性というのは、ないものなのでしょうか？

また。こんな書籍もありますね。
「みんなの意見」は案外正しい (単行本)
http://amazon.jp/dp/4047915068/

To flatlineさん
勉強について、興味があるので反応をしてみました。
> 何度か書いていますが、意欲があっても状況や環境で許されない立場の人もいますよね。
> 「１日わずかの時間も確保できないはずがない」なんて、過酷な現実を知らないお気楽な立場からの理想論に過ぎないです。
私は、基本的に「仕事中に教育をはさむ」ようにしていますね。
特に、デスマーチに近しい雰囲気以降になるときは、可能な限りかならず。
無論、理由の総てが「現場にある」とは思っていないのですが。とはいえ、現場のスキル不足が「デスマーチの一因である」事は、或いは「こういうスキルがあれば、回避はできないにしても軽減はできる」事は、多々あるので。
そんなときに「その瞬間に必要としている知識や技術とその基礎」を丁寧に教育することは、非常に有用だと思っています。
１日10分の講義を１～４回くらいやるとして…２週間～１ヶ月くらいで、大分と改善したり速度アップしたりします(過去の経験上)。

それ以外にもまぁ色々とメンタルケアとか必要かとは思うのですが。
合わせて、そこで「勉強」を重ねるのも「アリ」なのではないかと思うのですがいかがでしょうか？

がるさん、こんばんは。
もう寝ようと思ってたんですが(^^;

> 私は、基本的に「仕事中に教育をはさむ」ようにしていますね。

はい、そのように、業務の仕組み自体に勉強が組み込まれているのは
アリだと思います。というか、デスマーチ中に勉強できるとしたら、
その方法は非常に有効だと思います。

> それ以外にもまぁ色々とメンタルケアとか必要かとは思うのですが。

メンタルケアも非常に大切だと思いますが、実行されてないのが現状
ですね。
以前、某大手SI の下請けをやったとき、先方の担当ＳＥが「協力会社
（下請けとは言わない）の技術者の健康管理も注意してます」と最初に
言われたので、へえ、それはすごいと思ったのですが、実際は、
22:00過ぎに電話かけてきて「○○、明日までに仕上げてください。
あ、私は帰りますのでできたらメール入れといてください」なんて
平気で言う人でした。
そういえば、「私はSQL読めません」って平然と言ってる人でした。
名刺の肩書きはやたらと立派でしたが。「○○開発チーム主任」とか
なんとか。

> flatline さん

> 今どきそんなウォーターフォールじゃないですよね？
> 顧客の承認印もらったら、それを絶対変えないとか。

もちろん、違いますよ。
各段階で変更は随時入っていきます。

> インターフェースだけあれば、実装は自社で誰かにやってもらってもいいですよね。
> だから、インターフェース＋ダミーの実装にしてる。

これがよくわからないわけですよ。
結局、DB 側の実装ってどこで入るわけです？
本番データ使って動作を確認できるのは、どの時点になるんでしょう？

> 実装部分を差し替えるのなんか簡単なので。

パフォーマンスの予測がつかない、とおっしゃっている方が、
DB 側の実装を差し替えるのが簡単というのもよくわかりません。

> 私が顧客なら、そういう人に自社のシステム開発を依頼したいとは思いませんね。
> （って書かれたら、ムッとしませんか？）

いえ別にその程度では。
ご不快になられたことに対しては謝罪します。

「勉強する時間（暇）がない」とほざく新社会人はよく見るけど、５年、１０年とこの仕事してて、未だにそんなこという人はいないでしょ。
いるなら見てみたいなあ、いっしょに仕事はしたくないけど。

「勉強する」の意味を履き違えなければ、常に勉強していると思うんだけどなあ。

> ビガー さん

> ここで気になるのは、DBトランザクションの単位ですね。失敗した場合のロールバック単位はどうなるのか、どこで定義するんでしょうか？
> この部分は必然的にコーディングかアスペクトの定義がいると思いますが、どうやって関連付けしているんでしょうか

トランザクション単位の定義も、ストアドですね。
（ 1 回の呼び出しで 1 トランザクション完了 ）

複雑なデータ構造を、トランザクションの単位にしなければならない場合は、
一旦ワーク・テーブル（キュー）に入れてもらってから、
ストアド・コールです。

XML で渡してもらう、というのもやってます。
.NET ですと、オブジェクトを簡単に XML にシリアライズできますし、
Oracle も XMLType というのを持ってますから。

さすがにここまでやるなら、
BusinessObject も作ることになりますね。

その場合は、DataSet をコンポジションして、
コントロールに対しては、DataSet の Row、
ロジック（のラッパー）に対しては ValueObject に
見えるように作るのが良いと思ってます。

生島さんこんにちは。

>そんな人はさっさと淘汰されるべきで、議論の対象じゃないのです。

淘汰しようとすると、居なくなってしまうのは優秀な人たちなんですよね。。。
悲しいことに。

>言うだけならなんとでも言えますね。言うだけなら、実際にデスマーチに参加する
>必要も、睡眠時間を削る必要も、鬱病寸前までコード書く必要もないのですから。
>お気楽な立場から、理想を語っていただいてありがとうございました。

あなたが例に挙げたようなそんなひどいデスマーチは無いと書きましたが、
デスマーチへの参加は無いとは書いていません。
私の場合は高々300時間もいかない軽いものでしたし、もともとデスマーチとは
あまり縁が無いプロジェクトでの仕事が多かった（運がよすぎた？）。

この話は、これで書き込み止めたいですね。きりがないや・・・。

ronさん　こんにちは

>パラダイムはシフトしてないですから。
>相変わらず、企業システムの中心には、RDBMS が鎮座してます。

そりゃあ、今のこの瞬間を切り取っても、変化ちゅうもんは見えんですわ。
もうすぐ紅白がありますけど、相変わらず大御所は鎮座していますよね。
しかし若手の間では激しい入れ替わりがあって、中堅が「次の大御所」に
なろうとしています。そのことを、今年の紅白だけ見てもわかりませんよね？

前回は、パラダイムシフトという言葉の説明のつもりでしたが、ついでなので
RDBMSについても触れてみたいと思います。

例を、ポケベルから、ちょうどタイムリーな自動車業界に変えます。
長い間、レシプロエンジンの純粋なガソリン車が定番として支持されてきました。
ところが、昨今の環境問題によって、ハイブリッド車にとって主役が交代になろうと
しています。
そして、電気自動車や燃料電池車など次世代エネルギーを使用した
クルマが世の中に出ようとしています。

つまり、自動車業界パラダイムがシフトしようとしていますが、
今、道路を走っている車を交通調査員に調べさせて、
「電気自動車など走っていないからシフトしていない」というのは
違うと思いませんか？

>生島さんは、O/R マッパー（SQL ジェネレータ）じゃなくて、
>RDBMS に変わるものを作れ、

先述の自動車業界の話に置き換えますと、
私が自動車メーカーの社員、
RDBMSがガソリン車、
OODBやXMLDBが次世代エネルギー車、
O/Rマッパーがハイブリッド車だとします。
(O/RマッパーはRDBとOOのハイブリッドなので、ちょうど合いますね)

そうしますと、「ハイブリッド車ではなく、ガソリン車に変わるものを作れ」と
云うことになります。
もちろん作れたら格好良いのですが、それほど資金も技術力も
あるのなら、私が会社作ってします(笑)

パラダイムシフトは、社会現象を説明しているに過ぎません。
私が「これからは電気自動車が
主流になるでしょう」と言った
ところで、ただの偽評論家のたわごとと思いませんか？

ではRDBMSはこれから先もずっと大御所として鎮座し続けるのか？
というと、そんな保証はどこにもありません。
パラダイムシフトが起きない産業は存在しません。もしあるとすれば
それは斜陽の衰退産業か、伝統芸能です。
伝統芸能でパラダイムシフトが起きたら、そこで伝統は
終わってしまいますよね(笑)

DataSet クラスって、Table Modelですよね

全部メモリに溜め込むのは、なんとかならんのか！と思います

>それをグチグチ言う奴らというのは、結局、会社が何か分かってない。

以下は私の自論です。

よく「IT技術者は経営も理解しろ」という記事等を見かけますが、
(社員数人のところを除いて)
一介の技術者が経営を勉強するようになるということは、普通ではないと
思います。あるとすれば、経営者と技術者が対立して、経営上の不備を
さらけ出す必要があるときです。

いつも費用を念頭においていると、仕事に専念できませんからね…

モチベーションが影響するという点については同意します。

売上至上主義が蔓延していて、雇用・利益については無視され続けているのが問題だ
と、某会社の品質担当もおっしゃっていました。

ここまでの書き込み等で、よく

「顧客」

や、

「お客様」

という言葉が出てきています。

ところで、顧客って一体誰様なんですか！？

隣の弁当屋の店員の女の子？
年商1000億の会社の社長？

「オキャクサマ」という、超越した存在がいて、彼には絶対に逆らえない
ような書き込みを多く見かけるのですが、それは本当ですか？

(もちろん、色々な方々がここに参加されているのは承知していますし、
その顧客も様々であるのは理解しています。)

しかし、そのオキャクサマが絶対ネ申であるのならば、そのオキャクサマは
どのようなモノなのかをを想定しているのかということを名言しない限り、
顧客至上主義でのディスカッションは決して結束することはないと思うんですね。

まぁ尤も、私は顧客至上主義は淘汰されるべきだと思っていますけどね。

>ひらさん

顧客やお客様はシステム開発発注者（使う人たち）と想定しています。
だから、隣の弁当屋からシステム開発の依頼があれば、その会社（従業員）が
お客様になると思ってますが・・・。

ビガーさんへ
こんにちは。

›このフェーズでは、具体的にどういうツールやモデルを使って表現しますか？
また、この段階をダラダラ続ける方が個人的に多いと思っていますが、どの程度の期間で実施されますか？

主にUMLを使用（ここではユースケースが一番多い）します。
ツーにつきましては、今のところMS VisioとMicrosoft Officeを多用します。
本当はUML一本で生きたいのですが、そこまで普及していません。
ダラダラになる傾向は確かにあると思います。
私は経験上思うに、その原因は目標や意思統一がしっかりしていないからだと思います。
そこで、期間を決めて、アジャイルに分析を行い、徐々に粒度を細かくしていきます。
この時重要なのは、脳内でシステムがイメージできる事と、考える人々に何のために行うのかを明確にする事です。
終了段階は、お客様と作り手たちが「完成品についてイメージを持てる」事で、私が脳内シュミレーションを皆で共有できるレベルよりちょっと弱い程度（あまり先入観を持ちすぎるとまずいし後から変更は絶対に出るから）にしています。
つまり、ユースケースのウォーキングが出来る程度という事です。
感覚的には、各部門の人々が「仕事の全体像をイメージできる」のとシステムが提供するべき価値をはっきりさせるぐらいです。

›これについては、分析フェーズではなく、設計フェーズで実施する理由がわかりません。システム化検討(コンピュータで実現するべき)スコープは、設計の粒度では絶対にないはず。敢えて設計フェーズでやるメリットは何でしょうか？

分析段階は概念をはっきりさせる事であり、ここで言うシステム化検討とは「システム上でどうやって概念を実現するのか」であって、それは「コンピューターシステムの都合」なので設計段階の初期段階に含まれます。
この段階を設計と呼ぶのは、将来来るであろうシステム変更に備えて、概念とコンピューター上の都合を切り分けたいからです。
それと、ネットワーク構成なども併せて検討する必要がありますので、どうしても設計段階という事になります。
ネットワークは物理的なものですので分析に含めてしまうと混乱を生みます。
この時使用するツールは今のところMS製品です。
でもあんまり拘っていませんので、他の製品でも可能だと思います。
一番の武器は自分の思考法です。

›あと、分析・設計フェーズには多くのコンサルやエンジニアが関わるはずですが、そういう方々との合意も重要だと思うのですが、どう折り合いをつけているのでしょうか？

基本的には、どういうシステムを作るのかというイメージを共有する事で合意を形成しております。
他には、契約面の事柄である、責任範囲の決定、利益の分配率・・・などの生臭い事柄がありますが、それを言ってしまうとオブジェクト指向の範囲ではなくて、契約指向になりますので省略しました。

この2つの段階で私が使用している技法は、オブジェクト指向方法論OMTをベースにしたものとアジャイル開発のXPです。
それに加えて、ネットワーク柄見の知識、デバッグの知識、セキュリティの知識、データベースエンジニアリングなどを加えて、現場ごとに使い分けています。

›勉強について
勉強については本来管理者が時間をとるべきです。
というのも、情報処理技術は変化が早く、その技術の検討期間とメンバーのスキルを合わせる必要性があるからです。
しかしながら、日本では「管理者は知らなくてもいい」という世迷い事が通用し、知らないから本来するべき期間を設定していません。
これがデスマーチを生む要因でもあります。
テーマがズレるので、あまり言及しませんでしたが、この業界が早くまともな状態になってほしいものですね。
そのためにも、勉強しないのではなくて、勉強する必要があるからどの様に環境を整えるのかを考えていかねばなりません。

済みませんtypoです。

謝：ネットワーク柄見の知識
正：ネットワークの知識
※構成と書こうとしたけど、構成といってしまうと範囲が限定されるので削除。

ひらさん

自分も顧客至上主義は崩壊して欲しい。
ついでに言うと完璧主義も。

顧客は・・・大きく見ればシステムに関わる人全員だと思う。

そこに多くの人から理解をもらえるとはなかなか思えないけど。
「システムを作っているエンジニアもまた顧客なんだ」
と思えたらそれは一つステージが変わる気がする。

ひらさんへ

世界中の車の9割以上はガソリン車(エタノール車も含む)です。
これから確実にハイブリッド車や電気自動車にシフトしていく
とは思いますが、1、2年のうちにハイブリッド・電気自動車の比率が
ガソリン車を上回るとは思えません。
(＝RDBMSを使用する事が1、2年でなくなるとは思えませんし、
　私の主観ですが、3年後もRDBMSがDBの主流であり続けると思います)
そう考えると、車を開発、整備・保守するのがIT技術者
だとすると、現在9割以上を占めるガソリン車の開発・整備を
きちんとできるようにしようよ。しかもその技術を取得する事は
そんなに難しくないよ(シスアド試験レベル)。
というのが生島氏の主張だと思います。

ハイブリッド車や電気自動車が占める割合が増えてきた時に
それに見合う技術を勉強すれば良いと思いますし、それから
でも十分間に合うと思います(私の主観です)。
今、そこに時間をかけるよりか、まずはガソリン車の整備(＝SQLの習得)を
きちんとできるようにした方が良いと私は考えます。

> ひら さん

こんばんは。

パラダイムシフトと聞くと、
どうも、アインシュタインの相対性理論が思い浮かぶんですよね。
もともと、科学史分野の用語でしょ？

（ニュートン力学に対する）相対性理論に匹敵するほどのものか？
と思ってしまうわけです。

> RDBMSがガソリン車、
> OODBやXMLDBが次世代エネルギー車、
> O/Rマッパーがハイブリッド車だとします。

あくまでたとえなのでしょうけど。

O/Rマッパー て、RDBMS 以外のストレージに
対しても使うものなのでしょうか？
（Object/Relational ですよ）

そのたとえですと、RDBMS 以外のストレージにも使えないと、
「ハイブリッド」にならないですよね。

> ではRDBMSはこれから先もずっと大御所として鎮座し続けるのか？
というと、そんな保証はどこにもありません。

私もそんなことは思ってませんけどね。
が、まあ後 15年 - 20年くらいは確実に残りますね。
企業設備の減価償却の期間を考えれば。

もちろん、コスト面で 10 倍、100 倍の差が出るような、
革新的な技術であれば、償却を待たずに導入ってこともあるでしょうけど。
（メインフレーム から PC サーバ では、これが起きた）
OODB や XMLDB にそこまでのポテンシャルがあるようには見えないです。

> DataSet クラスって、Table Modelですよね

DataTable の方じゃなく？
タプル（クエリ結果）だと思ってましたが。

> 全部メモリに溜め込むのは、なんとかならんのか！

私は、あれで良い思ってますよ。
まあ、Web 系と Win 系、両方で使えるように折衷したのでしょうけどね。

昔の ADO のように、サーバ側のカーソル掴んだままでいるよりは、
メモリにデータ取ったら、さっさとコネクション返す方が良いです。

> ひら さん

> 「オキャクサマ」という、超越した存在がいて、彼には絶対に逆らえない
ような書き込みを多く見かけるのですが、それは本当ですか？

そんな書き込み多くありましたかね。

少なくとも、顧客のいいなりになるのは、プロではないと思ってます。
ま、意図的に、あるいは怠慢により、顧客に損害与えるのは犯罪ですがね。
（「背任」という）

ronさん、こんばんは。

>> インターフェースだけあれば、実装は自社で誰かにやってもらってもいいですよね。
>> だから、インターフェース＋ダミーの実装にしてる。
> これがよくわからないわけですよ。
> 結局、DB 側の実装ってどこで入るわけです？
> 本番データ使って動作を確認できるのは、どの時点になるんでしょう？

ケースバイケースじゃないですかね。
開発初期段階で必要があれば早めに実装作るでしょうし、
後回しでよければ、必要になった段階で実装作るでしょうし。

>> 実装部分を差し替えるのなんか簡単なので。
> パフォーマンスの予測がつかない、とおっしゃっている方が、
> DB 側の実装を差し替えるのが簡単というのもよくわかりません。

えーと、パフォーマンスの点と、実装差し替えの話と、どうつながる
のかよくわかりませんが。
実装部分を差し替えるのが簡単、と書いたのは、
たとえば、「紙芝居」として、インターフェースとダミーの実装作ったと
として、ある時点で実装を「ダミー」から「本番用」に差し替えるのは
簡単という意味です。

すみません。何か論点がずれているような気がするので、ron さんが
何を問題視しているのか、明記してもらえないでしょうか？

ビガーです。こんばんは。

>ronさん

ご回答ありがとうございます。

推測(今までの生島さんの論調を考えるとほぼ確実だと思いますが)ですが、ronさんと生島さんの手法は、ほぼ同じなんだろうな～と思いました。生産性重視、無駄を排除した実践的な手法だと思います。
拡張性に難がある気がしますが、そういう要件の場合は、オブジェクティブな設計にするイメージなんでしょうね。そういう案件が比率的に少ないから敢えて語らずといったところでしょうか。

ただ、オブジェクト指向分析や設計といったところとは、アプローチが異なると思っているので、拡張性や再利用性に、難はヤッパリ残るんじゃねぇ？と思っちゃうのは気のせいかな。

>インドリさん

ご回答ありがとうございます。
どんどん、本編とズレていますが、ご容赦下さい。そろそろ終わるかと＞生島さん

ユースケースは、厳密にはオブジェクト指向分析の対象に入らないと定義されていると思います。なぜなら、ユースケースモデルは、あるアクタが利用する機能に着目しており、これは個人的な考えですが、アクタ視点で処理を構造化したに過ぎないからと考えています。
しかし、一方で、あるオブジェクトの振る舞いであるとも云えると思っています。

このあたりの肝である、オブジェクトの抽出方法とユースケース定義をどうマッピングしているのか、ご教示お願いできますでしょうか？

>ダラダラになる傾向は確かにあると思います。
>私は経験上思うに、その原因は目標や意思統一がしっかりしていないからだと思います。

なるほど、一理あると思いますが、私はその前に実施するべきキーマンとの合意方法が曖昧になっているからであると思っています。
このあたりが一番難しいと思います。現場により人が変わるし、人間力が一番問われるから(一番私に欠落しているトコロですが、ちょっとはマシになってきたかとｗ)。理詰めじゃ話にならないからね。

>この2つの段階で私が使用している技法は、オブジェクト指向方法論OMTをベース

なるほど。現場目線で考えると、オブジェクト指向でインドリさんが云っているような手法が理解されるところは、少ないでしょうね。(とはいっても、私が経験してきたところでは、暗黙的に認知されていますが)
私が経験してきたような現場かインドリさんが経験してきた現場で一緒に仕事する機会があったら楽しそうですなぁ。

>それに加えて、ネットワーク柄見の知識、デバッグの知識、セキュリティの
>知識、データベースエンジニアリングなどを加えて、現場ごとに使い分けています。

このあたりは、ほとんどの現場共通の知識でよいでしょうね。

ビガーさんへ
›ユースケースについて
ユースケースはIvar Jacobsonが作成したもので、OOSEとObjectoryが土台に
なって出来たものであり、オブジェクト指向技術です。
ですから、アクターでの処理を構造化したものにすぎないと言うのはちょっと違うと思います。
確かにユースケースはシステム要求案件定義を目的としておりますが、そこに表されるシステムはブラックボックスなオブジェクトと看做せます。
なので、ここで定義される概念は、分析段階では殆どのもの（アクターやユースケース）が全て分析時のオブジェクトです。
ただ、システム設計でのオブジェクトは、オブジェクト指向プログラミングでのオブジェクトとは違います。
何故ならば、設計ではシステムの都合により分析にはないオブジェクトが増え、プログラミングではさらに言語の都合によりオブジェクトが増えるからです。
また、データベースを使用した場合、分析段階で発見されたオブジェクトはデータになる可能性もあります。
という事で、私は（オブジェクト指向プログラミング的な）オブジェクトとデータには拘らず、一つの集合として考えている次第です。
それで、オブジェクトのマッピング法とは言いますと、ユースケースや他の図で表れた要件を満たすべく設計を考えると自然と導出されます。
もし分析で表れるオブジェクトが実装されていないとなると、システム要件を満たさないと言う事になりますので絶対にマッピングされている状態に落ち着きます。
※ユースケースを多用していますが、それ以外の図も使用しますので注意。

›私はその前に実施するべきキーマンとの合意方法が曖昧になっているからであると思っています。

これはオブジェクト指向の話しではなく、契約面もしくは政治面の話しになるかと。
オブジェクト指向の範囲では、実現するシステムを定義する事で合意を形成するしかありません。
「お客様が言っているんだから」を武器にして、お客様の要求を全面的に押し通し、大人の事情で生じる不和などはもう人間力で何とかするしかありません。
私の場合は交渉が苦手なので、殆ど技術力で切り抜けています。
むろん全ての私の意見が通るわけではありませんが、技術的に私が居ないとシステムが実現しない状態にしてしまいます。

›私が経験してきたような現場かインドリさんが経験してきた現場で一緒に仕事する機会があったら楽しそうですなぁ。

私もそう思います。
ビガーさんは金融システム系だと言う事だから、大規模開発が得意そうなので私としても学習のために一緒に仕事がしたいです。

›このあたりは、ほとんどの現場共通の知識でよいでしょうね。

そこがまた難しいところです。
ネットワーク・データベース・デバッグ・セキュリティにも方法論があり、それら全てが設計時に必要とされているので、現場の人が知らない場合は私が積極的に介入して、足りない方法論を展開する必要があります。
その時オブジェクト指向の範疇にとどまらないので、他の方を説得するのが非常に困難です。
よく「それはオブジェクト指向じゃない」と言われます。
でも、現実問題必要だから仕方がない。
その辺の折り合いに何時も苦心しています。
オブジェクト指向で全ての方法論をマッピング出来ればいいのですが・・・
仕方がないので「経験で生み出したオリジナルのオブジェクト指向」だと主張する（オブジェクトで全てを説明する）もしくは、しないとどうなるかという理で説得しています。
政治的には各技術のキーマンたちと話しあって、プロジェクトに介入する方法が効果的です。
この時の心境は、おそらく生島さんのSQLに対する思いと同じものかと思います。

みなさんこんにちわ。

SQLの話しは収束したと思って除きにきたら
他の話しで炎上していてびっくりました。
さすが、生島さんのコラム。（ほめてますよ）

ついでに私の意見を投下しておきます。

＞業務ロジックはすべてDBに入れるべきか？
開発方式という意味であれば賛成です。
個々人の判断によって、あっちゃこっちゃにロジックがあるのはメンテできん。
上記が全て正しいとは、私も言い切れませんがプロジェクトの統一性という意味ではこのような考え方は必要だと思います。

＞SQLは全員が覚えるべきか
上記のやり方をするのであれば必須ですね。
SQLを軸として開発をするのであるんですから、SQLを知らないで設計をすると悲惨ですからね。
あと、結局パフォーマンスを出すのはSQL知らないとなんともならない事が多いのでその点でも必須ですかね。

＞勉強時間について
勉強時間がないと言う意見もありますが、確かにそのような人は多いと思います。
但し、勉強が本を読むことだけだという、前提であればです。
システムを構築しながら、積極的に先輩の技術を盗む、業務知識を自分の開発場所以外の事も興味を持って級数する意識があるだけで全然変わってくると思います。
そういう意味では勉強時間は全員取れます。気持ちの持ちようです。

＞設計方法について
基本的に弊社ではフレームワークを作成してシステムを構築（修正）します。
なので、Java、VB.NET、C#、Perl、Flexの自社フレームワークがあります。
開発者はこのフレームワークにのっとって開発します。
業務ロジックは基本的にストアドになります。

設計方法は悩み中です。
マインドマップで顧客の要望を書いてみるなど、なかなか答えでないです。
みなさん教えて下さい。（笑）

長文すいませんでした。

> flatline さん

こんばんは。

> 何を問題視しているのか、明記してもらえないでしょうか？

そうですね。すみません。

もともとは、「ストアドで境界を切って、画面実装・DB実装を並行して進める」という開発方式（ストアド方式）に対して、「インターフェースとダミーの実装で十分だ、ストアド（および DB ）なんて必要ない」（ダミー方式）と、flatline さんがおっしゃったわけですよね。

> ビガー さん

こんばんは。

> ただ、オブジェクト指向分析や設計といったところとは、アプローチが異なると思っているので、拡張性や再利用性に、難はヤッパリ残るんじゃねぇ？と思っちゃうのは気のせいかな。

気のせいではないでしょうね^^)

前提として、いち顧客企業からのスクラッチの受託案件、というのはあると思います。この場合、いわゆる「横展開」というのは、有りえないのですよね。

自社で横展開、というのは契約上ないですし（守秘義務、著作権譲渡、著作人格権不行使）、顧客企業が横展開（システム共同利用）するつもりなら、はじめから、発注主は複数いるはず（開発費用のシェア）。

つまり、拡張性・保守性といっても、必要なのは、いち企業内で閉じるレベルなわけです。

既にどなたか指摘しておられたと思いますが、前提がパッケージ・ソフト、あるいは、システム共同利用の場合は、また話が違ってくると思います。

たしかに、システム共同利用で、複数社が「うちはこうしたい」と違うことを言ってくるような状況を想像すると、分析段階からオブジェクト指向を使う意味が出てくると思います。要件が複雑すぎて整理するのが難しくなってくるでしょうから。

# そういうシステムをやったことはないので想像です。
# ビガー さんはそういうシステムをメインで手掛けてるのですかね。

オブジェクト指向分析設計で、最大の難点は、顧客に理解してもらうのが難しいことだと考えています。特に、顧客が 1 社 しかいない場合は、顧客が教育コストを負担するだけのメリットが思いつかないw

横やり失礼します。
面白い話題なので参加します。

› ただ、オブジェクト指向分析や設計といったところとは、アプローチが異なると思っているので、拡張性や再利用性に、難はヤッパリ残るんじゃねぇ？と思っちゃうのは気のせいかな。

拡張性はあります。何故ならばストアドはテーブル構造などを隠蔽する効果があるからです。
一種のカプセル化だという事が出来ます。
再利用性についてはあんまり要りません。
元となるデータの構造が変更されるような状況の場合、
再利用することに意味がありません。
というのも、その様な場合はプロジェクトの前提が変わっていると言えるからです。
ここで重要なのは、やはりストアド本来の目的であるトランザクションの正規化です。
複雑なトランザクションを正規化し、CRUDをシンプルにする為にはストアドが必要となります。
あと、ストアドは複数言語を使用した時強力ですよ。
.NETとJavaを混在させた時、ストアドでデータ周りを固めたら非常に楽でした。
他にも、既存ERPに機能を付け加える時、ストアドの後ろでテーブルを変更し、クライアント側の既存部分ほぼ修正なく動かす事が出来ました。
ストアドはこういう風な使い方が本職であり、パフォーマンス向上は副効果に過ぎません。
すなわち、ストアドはデータベース技術周辺に存在し、その方面では強く、他の場面では関係ない技術だと言う事です。
システムオブジェクトのどこがデータで何処がプロセスなのかを見極める事が大事なのです。

›オブジェクト指向分析設計で、最大の難点は、顧客に理解してもらうのが難しいことだと考えています。

そんなことないですよ。
抽象化しているので、逆に他の分析法よりも伝わりやすいと思います。
ただ、開発側がもめるのはよくある事です。
抽象化している分、責任範囲や作業の分割で揉めます。

やのさん

それでは話になりませんね

と書いてしまっては、また炎上してしまいますので、もう少し細かく説明を。
ディベートでこじれると、原点に戻ると思います。
その原点はどこにあるのか？ということを求めています。

顧客やお客様といった言葉が出てきているときに、そこにすがろうと
している個所がいくつかありますので、原点をお客様に求めようと
していることに異論はないと思います。

ただ、そのお客様がどのような人物を想定しているのか、つまりはターゲット
は誰かといったことを明確にしないと、このディベートはいつまでも収束しない
ということを私は懸念しています。

たとえぱ「これからは1000ccのクルマが必要だ」という議題が出たときに、
若いファミリー層をターゲットにするのか、長距離の運送会社をターゲットにするのか
では全然話が違いますよね。
軽のメーカーなら良いかもしれませんが、大型トラックのメーカーならば
「はぁ？」と言われて終わりです。

そういった意味で、全人類が顧客になることはありえないという意味です。

ronさん、こんばんは。
丁寧にありがとうございました。

> ストアド方式では、画面設計実装・DB 設計実装が並行して進んでいきますから、
> DB 実装込みで、出来た部分から、顧客に見せることになると思うのですけど。
> ダミー方式ですと、顧客が見るのは、あくまで、ダミーのデータのままでの画面であって、
> DB 実装込みの画面を見るのは、開発工程のより後の方になるように思えるわけですよ。

おそらく、ronさんが想定されているのは、紙芝居レベルの段階では、
ダミーのデータを返すストアドを使い、
DB設計などが固まってきた段階では、実データ（テストデータ）を返すストアドを
使うということだと思いますが、あってますか？
だとすると、どちらにせよ、DB実装込みの画面を顧客が見るのは、開発後期になりませんか？

> そうしますと、ダミーデータ入りのソースと、DB 実装入りのソース、
> 2 つのバージョンのソースコードをメンテナンスすることになりますよね。
> これは、二度手間である上、両方のソースの同期をとるのが難しくなりそうですが。

同期は別に難しくないですね。というか、ダミー（モックと呼んだ方が適切かも）と
本番は、当然名前が違うので。
たとえば、
インターフェース：EnabledUserDataGetter
ダミー実装：EnabledUserDataGetterMockImpl
本番用実装：EnabledUserDataGetterImpl
とか。
インターフェースの設計がしっかりしてれば、ダミーの方をメンテすることはあまり
ないと思います。

二度手間については確かに発生しますが、全く無駄なソースを書かない開発というのは
ありえないと思います。
Unitテストするとき、テストコード書きますが、それと似たような手間でしかないですね。

> しかし、パフォーマンスの問題というのは、典型的には、数百万件のデータから、
> 数十件を抽出して、画面に表示させる、といった処理で起きると思います。

逆に言えば、DB設計が固まらないと問題が出ないということになりませんか？
DB設計を後回しにする以上、パフォーマンスの問題が出るのは、開発工程の後期に
なると思いますが。
最初（DB設計も固まらない段階）からストアドを使えば、パフォーマンスのよ
予測ができるというものでもないのでは？

> そうしますと、DB を使った入力チェックのような、以前の入力が今回の入力に影響するような
> 仕様は確認できないことになると思います。また、トランザクション制御であるとか、
> マルチユーザ処理のようなものは、DB がないとどうにもならないですよね。
> とすると、顧客が DB 実装入りのシステムを初めて見たときに、データ入力仕様の認識違いが発覚する、
> という事態が発生しそうに思えます。

これも同じですね。逆に言えば、DB設計が固まるまで、入力部分を顧客に確認することが
できないということになりませんか？
開発の初期段階ではダミー実装でイメージを確認してもらい、DB実装ができてきたら
その部分を確認してもらう、というステップにすれば問題ないと思いますが。
もちろん、DB実装の時点では、必要があればストアド使いますよ。

> 私は、一番信用できる「仕様書」は、顧客の DB に入っている、本番データだと思っています。
> ストアド方式ですと、DB 実装込みですから、本番データを顧客に入れてもらうことができます。
> ダミー方式ですとこれができない。

本番データを数百万件、顧客に入れてもらうのですか？開発のどの段階で？

> とすると、顧客が打ち合わせで、この項目は 1 と 2 しか入ってないよ、と言っていたのに、
> 本番データ見たら 3 も入っていた、みたいな問題、つまり、顧客の思い違いが早期に判らないと思うのですよね。

本番データに全部のパターンが入っているとは限らないですね。
たとえば、47カ月分の本番データがあったとしても、48カ月に一度しか発生しないパターンがあったと
したら、本番データだけを信じていると、４年目に問題が発生しますね。

顧客の思い違いはどうにもできないですね。まあ、それをうまく引き出すのが要件定義担当の
役目だとは思いますが、顧客もエンジニアも人間なので、どうしても思い違いは出てきますね。
むしろ、考えられるパターンを洗い出したダミーデータを使った方が、思い違いは減るのでは？

これはちょっと「ストアド」か「ダミー実装」かという論点からはずれていると思います。
分析・開発手法の問題でしょう。

一番信用できる「仕様書」はプログラムソースそのものです。
ロジックも、入力チェック仕様も、バグも全てが記述されています。私の言葉じゃないですが。

そもそも、これは、全く新しい新規システムをゼロベースで開発する場合、意味をなさないですね。

ひらさん

自分は漠然としたことを述べているので相手にされないと思います(^^;

「全人類が顧客になることはありえない」
もちろんです。結局は利益の奪い合いですからね。

自分は「システムに関わる人が顧客」と言ってるだけです。
（中抜きする人はいて欲しくないけど。。。）

ところでストアドとかで開発したらバグ発生率を下げる工夫って
どんなのがありますかね？
Javaだと環境非依存でTestCaseとか使えると思うのですが。。。

横槍スンマセン

＞これも同じですね。逆に言えば、DB設計が固まるまで、入力部分を顧客に確認することができないということになりませんか？
＞開発の初期段階ではダミー実装でイメージを確認してもらい、DB実装ができてきたら
＞その部分を確認してもらう、というステップにすれば問題ないと思いますが。

プログラムが手離れするタイミングが変わってくるのですよね。
ストアドの部分を境界にしてしまえば、アプリ側でやるべきことはやったんだから
入出力の仕様が変わらん限り、呼ばないでくれと言えます。
完了しないものを抱えっぱなしよりこちらは気楽ですし、
管理者の人もスケジュール管理が楽になります :-)

#設定ファイルなどを利用して、ダミー呼出と本番呼出分ける手も使ったことあるんですが
#その切替が正しいかというチェックの手間も省けるのでストアドを愛好してます自分。

choirさん、こんにちは。

> プログラムが手離れするタイミングが変わってくるのですよね。

なるほど、それは一理ありますね。
ただ、前にも書いた通り、ノートPCにプログラム一式入れて、客先でデモを頻繁にやらなければいけない場合などを考えると、やはりストアド（というかDB）使うのが面倒なときもあります。
私はだいたいOracle が多いですが、あれはメモリ512M程度のノートPCで動かすには重いですね。Express Edition とかでも重くて遅い。

> flatline さん

こんばんは。

> おそらく、ronさんが想定されているのは、紙芝居レベルの段階では、
> ダミーのデータを返すストアドを使い、
> DB設計などが固まってきた段階では、実データ（テストデータ）を返すストアドを
> 使うということだと思いますが、あってますか？

たぶん、違いますね。

そもそも、ダミーのソースコードと、DB 実装入りのソースコードを、2 本に分けてメンテナンスはしません。ソースコードはあくまで 1 本です。

つまり、開発初期段階（基本設計、全体の方向を決める段階）でこそ、紙芝居を使いますが、その紙芝居のソースコードに、そのまま画面実装・DB 実装を同時並行で入れていきます。

「DB設計などが固ま」るのは待ちません。画面側の設計実装と同じように、DB側の設計実装も、漸進的に進化させていきます。

従って、顧客と個別の画面の仕様を話し合う段階では、ダミーではなく、画面実装・DB実装の入った開発中の本物のシステムを、顧客に見せながら仕様検討を行ないます。

> インターフェースの設計がしっかりしてれば、ダミーの方をメンテすることはあまり
ないと思います。

そのインターフェイスの設計をしっかりやるのが難しいと思うのですが。開発初期で決まったインターフェイスが開発期間を通じて変わらない、などということが有りえますかね。

例えば、開発初期には、単票で表示されていた画面を、顧客がやはり表形式にしてくれ、いや、やっぱり 表 ＋ 単票にしてくれ、小計を付けてくれ、総計を付けてくれ、といった注文が相次いだ場合、それでもインターフェイスは変更（追加）されないのでしょうか。

> Unitテストするとき、テストコード書きますが、それと似たような手間でしかないですね。

Unit テストと違って、インターフェイスを介した、他チームの実装との結合がありますよね。

> DB設計を後回しにする以上、パフォーマンスの問題が出るのは、開発工程の後期になると思いますが。

最初にお答えしたとおり、DB 設計を後回しにはしません。

> これも同じですね。逆に言えば、DB設計が固まるまで、入力部分を顧客に確認することができないということになりませんか？

同じくなりません。

> 本番データを数百万件、顧客に入れてもらうのですか？開発のどの段階で？

もちろん、データを入れる作業自体はこちらでやりますよ。開発の早い段階で、顧客に本番データを提供してもらう、ということです。

ダミーではなく、実際に 画面実装・DB 実装の入ったシステムを顧客に見せている場合、顧客の方で開発の進捗は目にみえてわかりますよね。そうしますと、顧客の方でも、本番データを入れて確認したくなるはずなのですよ。

ダミーを顧客に見せている場合、顧客は開発の進捗を実感できませんから、その必要性を実感できないと思うのです。

顧客に本番データを提供してもらう、といっても、くださいといえば、すぐもらえるようなものではなく、顧客側でも社内手続き等、準備が必要になります。顧客が必要性を実感していないと、積極的には動いてもらえない。結果、本番データを提供してもらえるのが遅れると思います。

> 本番データだけを信じていると、４年目に問題が発生しますね。

本番データだけを信じるとは言ってません。本番データを入れて初めて判る問題もある、ということです。

> むしろ、考えられるパターンを洗い出したダミーデータを使った方が、思い違いは減るのでは？

もちろん、考えられるパターンは洗い出しますよ。それでも、すべてのパターンを網羅できるとは限りません。本番データを使えば、顧客とこちら、双方とも思いつかなかったパターンが見つかる可能性がある、ということです。

> これはちょっと「ストアド」か「ダミー実装」かという論点からはずれていると思います。分析・開発手法の問題でしょう。

ずっと、開発手法の話をしているつもりでしたがorz
このコラムのテーマも開発手法だと思います。

> 一番信用できる「仕様書」はプログラムソースそのものです。

既存システムのプログラムソースを読む、ということですか？
既存システムのソースコードが存在せず、バイナリしかない場合もありますよね。

また、顧客から受領したソースコードが最新版ではない可能性もあります。こういうのは、本番データと、ソースを読み込んだ結果を比べることで判明したりします。

> そもそも、これは、全く新しい新規システムをゼロベースで開発する場合、意味をなさないですね。

既存システムのデータを全く利用できない場合は、ダミーでやるしかないですね。しかし、その場合でも、トランザクションの量を予測した上で、少なくとも数百万件程度のデータは欲しいところです。

> インドリ さん

こんばんは。

> 抽象化しているので、逆に他の分析法よりも伝わりやすいと思います。

私は、オブジェクト指向分析に詳しくないので、よければ教えていただきたいのですが。

その「抽象化」がクセモノだと思うのですよ。

例が適切ではないかもしれませんが、例えば、「在庫」オブジェクトに「入庫」メソッドがあったとしますよね。そうしますと、顧客からは、「在庫が勝手に入庫したりしない」という突っ込みが入ると思うのですよ。あるいは、「売上が勝手に計上されたりしない」とか。

そこで、「いや、これはあくまで現実を抽象化したモデルで」などと説明を始めると、顧客の頭はクエスチョン・マークで満たされてしまって、話が進まなくなると思うのですよね。

こういうのって、どうするんでしょうか？

あくまで、抽象化したモデルであることを説明して、顧客に納得してもらうのか、あるいはそもそも、現実と直感的に異なるようなモデルは作らないのか。

> やの さん

こんばんは。

> Javaだと環境非依存でTestCaseとか使えると思うのですが。。。

私は、DbUnit + Ant を使ってます。
結局、Java かよ、という突っ込みはなしでお願いします^^)

ronさん、こんばんは。

すいません。確かに、開発手法の話をしているのでしたが、
もうちょっと狭い範囲の話をしているつもりでした。

自分でも忘れかけてきたので、コメントの流れを追ってみました。

flatline
> ただ、「動く物を先に作る」段階で、そこまで先のパフォーマンスまで考慮する必要があるのか、
> という疑問はありますが。というか、ストアドだろうが言語だろうが、そもそも、この段階で
> パフォーマンスの予測などできるんでしょうか？

ronさん
> おおまかにはできますよ。
> データ件数がある程度わかっていれば、ですが。

flatline
> しかし、私の読み違えでなければ、生島さんは、「DB設計を後回しにしたいから」、
> 先に動くものを作るために、ダミーのストアドを作る、と言われてます。
> 当然、テーブルも主キーもインデックスも何もない状態なわけです。
> この状態で、件数はともかく、クエリまで想定できるというのは、どういう意味でしょう？

ronさん
> 画面に表示すべきデータがわかっていれば、
> テーブルも主キーもインデックスもその場で作れますし、
> もちろん、クエリも想定できます。

flatline
> もっとも、この段階（デモ画面作成ぐらいの）なら、ストアド使う
> 必要はないし、もっと言うなら、テーブルとかインデックスとか
> 考える必要すらないですね。インターフェースとダミーの実装で
> 適当なデータを返すようにしておけば……（後略）

ronさん
> それだと、紙芝居レベルと大して変わらないわけで、
> それこそ、基本設計段階で済ませておくものではないですかね。

と、紙芝居レベルの話をしてきていたつもりが、いつのまにか
開発工程全体の話になってきていますね。

開発工程全体の話は、エンジニア個人や会社の方針などもあり
これが正解ってのはないので、議論しても仕方がないのでやめましょう。

顧客へのデモやテストや開発を本番データでやるのか、ダミーデータで
やるのか、という話も、たぶんかみ合わないのでやめましょう。
単に、ronさんが本番データを重視していて、私は重視していないという
だけなので。

で、最初の紙芝居レベルに話を戻して、１つ質問させてください。

> 従って、顧客と個別の画面の仕様を話し合う段階では、ダミーではなく
> 画面実装・DB実装の入った開発中の本物のシステムを、顧客に見せながら
> 仕様検討を行ないます。

「顧客と個別の画面の仕様を話し合う」ということは画面の仕様が決まっていない
段階だと思いますが、その時点で「DB実装の入った」ものって、
どんなものを作るのでしょう？ちょっとイメージが浮かばないです。

ron さんおはようございます。

›こういうのって、どうするんでしょうか？
›あくまで、抽象化したモデルであることを説明して、顧客に納得してもらうのか、
›あるいはそもそも、現実と直感的に異なるようなモデルは作らないのか。

はい。分析の段階では、現実と直感的に異なるモデルは作りません。
現実と異なってくるのは設計段階になります。

皆さん、おはようございます。

興味深い議論が続いていますが、参加できなくって申し訳ございません。

皆さんが十分に考え抜いて出した結論であれば、皆さんの環境において最高の結論になっているでしょう。

一般論で１つだけ、SQLでやった方が良いという人は、残念なことに現場ではほとんどOO言語でやっています。両方できないと食べてはいけません。
OO言語でやった方が良いという人は、SQLがイヤで、そんなプロジェクトには入ったことがないでしょう。

片方の知識が足りてないのです。

頑ななのはどちらなのでしょうね。

ビガーです、こんにちは。

>インドリさん

>ユースケースについて

ヤコブソンの真意は、本人に聞いてみないとわかりませんが、一般論ではユースケースは、オブジェクトと等価ではありません。ゆえにユースケースはオブジェクト指向技術ではありません。

http://ja.wikipedia.org/wiki/%E3%83%A6%E3%83%BC%E3%82%B9%E3%82%B1%E3%83%BC%E3%82%B9

例えば、「本を買う」というユースケースをオブジェクトで表現すると、書籍オブジェクトと購入オブジェクトで定義できます。この例だけでもユースケースとオブジェクトは等価でないことがわかると思います。

なぜ、ユースケースとオブジェクト指向がほとんどの場合、ほぼ同じフェーズで使われるのか。
それは、オブジェクトの抽出の困難さに起因すると思っています。
私は、アクタが望むユースケースを定義してからの方が、効率的にオブジェクトの抽出ができ、「楽だから」だと考えています。

>ただ、システム設計でのオブジェクトは、オブジェクト指向プログラミング
>でのオブジェクトとは違います。

これは、オブジェクトの粒度の問題です。例えば、購入オブジェクトは、注文オブジェクトと支払オブジェクトで表現されます。
真の意味でのドメインモデルが定義できていれば、設計と実装でのオブジェクトの差異は出ません。むしろドメインモデルで実装するならそうなってはダメです。
オブジェクト指向の最大のメリットは、要件定義～分析・設計～実装をストレートに落とせることにあります。コレをトレーサビリティを確保するといいます。

実際にそういうシステムを構築したことがありますが、最大のデメリットは、その良さが開発者に認知(理解)されにくいこと。
お客様には、直感的にユースケースとオブジェクトがどう関係しているのか、ドキュメントで示せているので好評なのですが、開発者にオブジェクト指向の啓蒙が必要だと個人的に感じています。

>何故ならば、設計ではシステムの都合により分析にはないオブジェクトが
>増え、プログラミングではさらに言語の都合によりオブジェクトが増えるからです。

これは、具体的にどういうオブジェクトでしょうか？
コンテキストやユーティリティなどを指しているのでしょうか。それは、オブジェクト指向とは関係ないです。

>むろん全ての私の意見が通るわけではありませんが、技術的に私が居ないとシステムが実現しない状態にしてしまいます。

これは、非常にマズイです。インドリさんが病気などになったとき、困るのはお客様です。常にオープンな仕様を心掛けるべきです。

>ネットワーク・データベース・デバッグ・セキュリティ

ネットワーク、セキュリティはオブジェクト指向とは概念が異なるので、別で考えるべきです。

デバッグについては、テストケースの粒度とオブジェクトの粒度が一致させると効率がいいので、
仰る通りと思いますが、工数の関係でそこまでのテストケースが作れるプロジェクトは稀であると考えています。

データベースについては、O/Rマッパーの話でしょうか。
インドリさんは、スクラッチでやるという話と思いますが、工数や品質を考えると、OSSの実装を使うべきだと思います。

生島さん

私はエンジニアではなく、製品企画の人間ですのでみなさんとは議論がかみ合わないと思いますが…ちょっと疑問に思ったことがあるので書き込ませてください。

世に居るエンジニアのSQL理解度がそんなに低いのなら技量/習熟を要するSQLを推すことは逆に保守作業の実施可能性を下げる　-　このSQL何言ってんだかわかんねーよ、ってSQLに不慣れな保守作業人員が言い出して保守作業が実施できなくなる可能性が多分にあるってことですか?

であれば、パフォーマンスは機械が安くなって居るのでそっちに吸い込んでもらうとして、SQLではなく誰もが出来る言語側になるべく寄せておいて、言語側で綺麗に書いておくのが、運用コストを負担する側からするとリスクが減るように思えるんです。

その場合の問題点などをご指摘いただければ、この議論についてより理解できると思いますのでご教示いただければ幸です。

ビガーです。連投ですみません。

>ronさん

>オブジェクト指向分析設計で、最大の難点は、顧客に理解してもらうのが難しい
>ことだと考えています。特に、顧客が 1 社 しかいない場合は、顧客が教育コストを
>負担するだけのメリットが思いつかないw

仰る取り、お客様がSIerだと今までのアプローチと異なるから取っ掛かりとしては、
受け入れられにくい部分はあると思います。
しかし、ER図と概念モデル(クラス図)、DFDと業務フロー(アクティビティ図)、
画面仕様書とユースケースのように既存のアプローチで使用しているものとマッピングして
説明すると、「なんだそんなことか」という感じで理解いただける場合が多いと感じています。

メリットは、トレーサビリティです。
理想的なドメインモデルだとドキュメントと実装の乖離がほぼないので、ITの知識が
あまりないお客様でも技術者と会話がしやすくなるというメリットがあります。

デメリットとしては、機能拡張などが発生した場合、技術者がどのように機能拡張するのが
最適なのか判断できず、ジョジョにスパゲッティ状態になってしまうことです。

>インドリさん

>拡張性はあります。何故ならばストアドはテーブル構造などを隠蔽する効果があるからです。
>一種のカプセル化だという事が出来ます。

拡張性とカプセル化に関係はありません。
拡張性があるとは、開閉原則に基づいて実装することで得られると考えています。
ストアドでどうやって実現するのでしょうか？

>元となるデータの構造が変更されるような状況の場合、
>再利用することに意味がありません。
>というのも、その様な場合はプロジェクトの前提が変わっていると言えるからです。
>ここで重要なのは、やはりストアド本来の目的であるトランザクションの正規化です。

ストアドの本来の目的なのかは知りませんが、トランザクションの正規化というのは
具体的にどのように実現しているのでしょうか？
仮にアトミックな単位(5層モデルのサービス層に近い)のストアドを定義したとして、
その中で複数のサブストアドをコールすると推測します。
そのサブストアドの再利用性とオブジェクトの再利用性は、本質的に等価になると
考えています。

再利用が必要ないという意味がわからないのでご教示お願いします。

> 開発工程全体の話は、エンジニア個人や会社の方針などもあり
> これが正解ってのはないので、議論しても仕方がないのでやめましょう。

そうですね。
私も、flatline さんとは仕事を行なう環境・立場が大分違う、という気はしてきました。

> 「顧客と個別の画面の仕様を話し合う」ということは画面の仕様が決まっていない
> 段階だと思いますが、その時点で「DB実装の入った」ものって、
> どんなものを作るのでしょう？ちょっとイメージが浮かばないです。

「紙芝居」段階にこだわる、という話であれば、既に紙芝居の話ではないですね。

紙芝居は一度顧客に見せて、全体のイメージについてはおおまかに決めた上、その上で、（こちらの考える）画面実装・DB実装を入れて、個別の画面について、細部の仕様を話合うわけです。

画面の仕様が決まっていないといっても、粒度の問題で、何も決まっていないわけではないわけです。おおまかには決まってるという前提ですね。

> インドリ さん

ご教示ありがとうございます。

> はい。分析の段階では、現実と直感的に異なるモデルは作りません。
> 現実と異なってくるのは設計段階になります。

んー。

そうなると、分析モデルが設計モデルとリンクしにくくなりませんか。
ビガー さんがおっしゃる、オブジェクト指向分析・設計の最大のメリットである、トレーサビリティが失われてしまいそうですが。

> ビガー さん

おはようございます。

> 仰る取り、お客様がSIerだと今までのアプローチと異なるから取っ掛かりとしては、受け入れられにくい部分はあると思います。
> しかし、ER図と概念モデル(クラス図)、DFDと業務フロー(アクティビティ図)、
画面仕様書とユースケースのように既存のアプローチで使用しているものとマッピングして説明すると、「なんだそんなことか」という感じで理解いただける場合が多いと感じています。

想定しているお客様は、基本、エンドユーザなんですよね。
SIer に説明するより厳しいです。

私がいつも使うのは：

・ユースケース / アクティビティ図 （業務フローの整理）
・ER 図 (UML Profile for Data Modeling)
・シーケンス図 （ストアド等のコールシーケンス）
・状態遷移図（表） （画面遷移、データの CRUD 遷移等）

といったもので、クラス図・オブジェクト図は使ってません。
使うと、話がややこしくなってしまいそうで。

後、やっぱり、前提にしている開発規模の違いもありますね。私が想定している開発規模は、長くて 一年程度、メインは 3ヶ月～半年程度で考えてますから。

分析設計段階で、あまり時間はかけられないわけです。

> メリットは、トレーサビリティです。
> 理想的なドメインモデルだとドキュメントと実装の乖離がほぼないので、ITの知識が
> あまりないお客様でも技術者と会話がしやすくなるというメリットがあります。

お客様にとっての具体的メリットとしては、やっぱり拡張性じゃないかと思うのですけどね。

「お客様でも技術者と会話がしやすくなる」は、オブジェクト指向分析設計（実装）ありきの話であって、それをお客様が選択する理由にはならないと思うのです。

例えば、複数社でシステム共同利用するような場合、業務ロジックの一部分の実装を、社によって差し替える、といった話が出てくると思うのです。

従来手法ですと、こうした要件では、それこそ、IF 文の嵐になってしまいます。オブジェクト指向であれば、一部だけ実装差し替えみたいのは、もともと得意ですから、やりやすくなると思うのですよ。

> デメリットとしては、機能拡張などが発生した場合、技術者がどのように機能拡張するのが最適なのか判断できず、ジョジョにスパゲッティ状態になってしまうことです。

これは、どの手法を使っても同じかもしれませんね。
30 年くらい運用された、汎用機システムの COBOL のソースコードなんて、凄まじいの一言ですから。

> つよし さん

横入りで失礼します。

> SQLに不慣れな保守作業人員が言い出して保守作業が実施できなくなる可能性が多分にあるってことですか?

「技量/習熟を要する」といっても、保守作業する分には、さほど大した話でもないわけでして、仕事で必要となれば覚えるでしょうね。マニュアル読めばすむレベルの話だと思います。

OO 言語の方が習熟は難しいでしょうし、そもそも、OO 言語使っている人間も、SQL の基本くらいは知っているわけです。そうでないと、RDBMS は使えませんからね。

> であれば、パフォーマンスは機械が安くなって居るのでそっちに吸い込んでもらうとして、

これは、前回コラムで議論のあった部分ですが、
（ 32 : 40億 の違い）
機械が安くなっても吸収はできません。そんなレベルのパフォーマンスの差ではないわけです。

むしろ、機械が安くなると、データ容量も増大していきますから、パフォーマンスの差はより拡大すると思います。パフォーマンスというのは、基本、データ件数の関数ですから。

パフォーマンス ＝ f ( データ件数 )

# 計算論では、 O（ビックオー）、Ω、θ、o （スモールオー）など。

皆様こんばんは。

ビガーさん
>拡張性とカプセル化に関係はありません。
いいえ、隠蔽するからカプセル化と似ていると表現しました。

>ストアドでどうやって実現するのでしょうか？
全てストアドを通じてデータを操作するようにプログラミングします。
そうすると、テーブルの構造が隠蔽されているので、
ストアドのパラメーターさえ変えなければ、テーブルの構造を変化させても修正する必要がなくなります。

>ストアドの本来の目的なのかは知りませんが、トランザクションの正規化という
>のは具体的にどのように実現しているのでしょうか？
普通にSQLを直接発行するようにプログラミングするとします。
そうすると、プログラム内にSQLが散らばってしまいます。
また、データ整合性をチェックするためには、複数のテーブルを操作するSQLを記述せねばなりませんし、一トランザクションで複数のテーブルを操作するSQLはざらにあります。
それらのトランザクションを正規化するのがストアドの役目です。

>仮にアトミックな単位(5層モデルのサービス層に近い)のストアドを定義し>たとして、
>その中で複数のサブストアドをコールすると推測します。
>そのサブストアドの再利用性とオブジェクトの再利用性は、本質的に等価に>なる
>と考えています。
オブジェクト指向で言うところの継承による再利用と等価とは言えないと思います。
私もストアドの階層化をする事はありますが、それはプロジェクトを超えた再利用性を実現するものではありません。

>再利用が必要ないという意味がわからないのでご教示お願いします。
ストアドはデータベースの技術です。
オブジェクト指向のようにシステム開発全体での再利用は念頭に置かれていません。
何故ならば、テーブル構造は基本的にプロジェクト毎に違いますので、再利用する事のメリットが極めて低くなるからです。
そうなると、毎回ストアドを作りなおした方が早いです。
ある程度出来ない事はありませんが、オブジェクト指向程の再利用性は不必要なものです。

ronさんへ

>そうなると、分析モデルが設計モデルとリンクしにくくなりませんか。
>ビガー さんがおっしゃる、オブジェクト指向分析・設計の最大のメリット>である、トレーサビリティが失われてしまいそうですが。

いいえ。UML図を見れば分かりますので失われません。
もし失うようなものであれば、それは分析結果を踏まえていないと言う事を意味し、そのプロジェクトの設計は失敗しているという事になります。
分析により概念を規定し、システムがどのように実現するのかまで踏み込まない所が、オブジェクト指向の強みなのです。
分析段階で概念を、設計段階でシステムでの実現方法を、実装段階プログラミングをというふうに3段階に分けるのがよいのです。
そうしないと、何処から何処までがお客様の要望なのか、何処からがシステム上の都合なのか分からなくなり、オブジェクト指向のメリットである再利用性が生かせません。
分ける事により、自由にシステム構成を変更できるようになります。

お二人と話しが出来て楽しいです。
オブジェクト指向は奥が深く、方法論が10個以上あったりするので、多分差異があるかと思います。
ですから、お二人のオブジェクト指向についても教えて頂けると幸いです。

質問1：分析・設計・実装をどのあたりで切り分けていますか？
質問2：設計段階では、ネットワーク・データベース・セキュリティ・テスト体制なども並行して設計しなくてはなりませんが、どの様にしてオブジェクト指向設計とマッピングしておりますか？
質問3：アジャイルしていますか？

ビガーです。こんばんは。

>ronさん

>想定しているお客様は、基本、エンドユーザなんですよね。SIer に説明するより厳しいです。

エンドユーザといっても、情報システム部門があるのが普通と思いますので、基本的にSIerと変わらないと考えています。
要は、そのお客様の今までの文化とオブジェクト指向の文化をマッピングすることで、理解を促進し、従来手法と比較して要件～設計と実装の乖離を解消することで、影響範囲調査の工数等の無駄なコストが削減(これはシステムが大きくなるほど、ものすごい工数となる)できるようになると。

ronさんの仰る通り、その理由だけで、お客様の文化を変えるほどの理由にはならないという現実はあると思います。そういう意味で、従来手法と比較して機能の差し替えが容易になる(これは、オブジェクト指向でなくても設計次第で大差ないと思っていますけど)とか、お客様に納得してもらえるような動機付けは別途します。
ただ、それは、お客様の本質的なメリットにはなり得ないと思っています。
開発側としては、開発者に本当に理解されていれば、いくつもメリットはありますけど。

>インドリさん

>トランザクションを正規化
>プログラム内にSQLが散らばってしまいます。
>また、データ整合性をチェックするためには、複数のテーブルを操作するSQLを
>記述せねばなりませんし、一トランザクションで複数のテーブルを操作するSQL
>はざらにあります。

オブジェクト指向的な考えでは、O/Rマッパーが上記の役割を果たします。
複数テーブルをアトミックに更新する必要がある場合は、JTAなどでスコープを切れば済む話ですね。
このような事象をストアドに寄せることによる弊害は、以下があると思います。
１． トレーサビリティが失われること。
２． ２フェーズコミットが必要なシステムの場合、ACIDを担保できなくなってしまうこと
３． データ量が増えた場合にスケールアウトが困難なこと。

オブジェクト指向で実現するべきコトをストアドでわざわざ実現する必要はないと思っています。

>質問1：分析・設計・実装をどのあたりで切り分けていますか？

現実のプロジェクトでは、新規開発は少なく、既存システムの改修がメインです。
そういう前提だと、分析は影響範囲の調査になり、設計は調査を基にした工数の見積りと機能的制約を顕にすること。実装は、設計しながら進めます。
分析フェーズでは、最初からすべての調査スコープがきっちり出揃うことが少ないので、顕在化したところから設計・実装しつつ、分析に戻り。。。ということが多いように思います。
オブジェクト指向的に分析すると本質的な業務のあるべき姿が表現しやすいので、分析フェーズの精度が従来手法と比較して高まると考えています。

>質問2：設計段階では、ネットワーク・データベース・セキュリティ・テスト体制

オブジェクト指向とのマッピングはデータベース以外は意味が無いと思っています。

>質問3：アジャイルしていますか？

一般論として、アジャイルが具体的に何を指すのか曖昧だと思っています。ペアプロなどは、時間が無駄にかかる相手が多いので、邪魔くさいな～くらいですね。
質問1で回答したようなスタイルが基本なので、俊敏という意味のアジャイルは、独自のスタイルかもしれません。

返信有難うございます。ビガーさん。

>１． トレーサビリティが失われること。
これについては設計書次第だと思います。
ただ、オブジェクト指向と比べると弱いと思います。

>２． ２フェーズコミットが必要なシステムの場合、ACIDを担保できなくなってしまうこと

それは逆だと思います。
データベースエンジニアリングの産物であるストアドがその様な状態になる事はありません。
あるのであれば、それは開発者のミスです。
少なくとも、データに特化した技術がオブジェクト指向よりもデータ操作能力が劣るとは思えません。

>３． データ量が増えた場合にスケールアウトが困難なこと。

これも逆にデータベース側の方が処理が対応しやすいです。
この様な状況では、テーブル構成などをいじくる必要がありますが、その時ストアドによる隠蔽の方が影響範囲が少なくなります。
O/Rマッパーはメモリ上に展開するので、余計にデータ量の増加に弱いと思います。
Iテラバイトのデータ量をオブジェクトで正常に処理できると思えません。
データベースに特化した技術を捨て、オブジェクト指向言語で処理する必要はないと私は思います。

>オブジェクト指向とのマッピングはデータベース以外は意味が無いと思っています。

この意見についての質問なのですが、セキュリティ・ネットワーク・テスト体制などはシステム開発では必須要素です。
これらデータベース以外の要素についてどの様に設計を進められていますか？
私はこの辺で悩んでいるので教えて頂ければ幸いです。

> ビガー さん

ご教示ありがとうございます。

> ただ、それは、お客様の本質的なメリットにはなり得ないと思っています。
> 開発側としては、開発者に本当に理解されていれば、いくつもメリットはありますけど。

うーん、やっぱりそうなんですか。
わかりました。ありがとうございました。

> インドリ さん

こんばんは。
回答ありがとうございました。

> 質問1：分析・設計・実装をどのあたりで切り分けていますか？

私の定義ということなら、以下です。

分析：エンドユーザと、システム含めた業務の仕様を決めること。
設計：開発者チームがどのように開発・テストするべきかの仕様を決めること。
実装：個々の開発者がプログラミングとテストを行なうこと。

> 質問2：設計段階では、ネットワーク・データベース・セキュリティ・テスト体制なども並行して設計しなくてはなりませんが、どの様にしてオブジェクト指向設計とマッピングしておりますか？

私はオブジェクト指向設計ではやってませんからね。
別個に独自にやってます。

> 質問3：アジャイルしていますか？

アジャイル＝XP だとします。
やってません。
使っているのはユニット・テストくらいですね。

ronさん回答ありがとうございました。
また機会があればお話ししましょう。

ビガーです。こんばんは。連日ですみません。

>インドリさん

トレーサビリティに関しては、理解いただけていないようなので(テキストでの表現では限界があるみたい)何かの機会にまた。オブジェクト指向でもっとも重要な部分だと考えているんですけどね。
設計次第とかのレベルではないことは、確かです。

２フェーズコミットについては、規模が大きくなるとどうしても必要になるケース(複数のDBで原子性を保障する必要があるとき)があります。

>O/Rマッパーはメモリ上に展開するので、余計にデータ量の増加に弱いと思います。
>Iテラバイトのデータ量をオブジェクトで正常に処理できると思えません。

hibernateには、遅延ロードという仕組みがありますので、必要なときにメモリ上に展開されます。
バッチ処理などのオブジェクト指向と関係のないモノは、ストアドで実装するべきだと思います。

以下は、専門ではないので参考になるかはどうかと思いますが、

>セキュリティ

WEB開発の話に限定すると、XSSとかSQLインジェクションなどの基本的な対策は、プレゼン層でメタ文字のエスケープを実施します。
サービス層でも必ず想定されるパラメータデータであるかのバリデーションをかけます。
また、認証キーやセッションIDなどは、ハッシュなどを用いて特定されにくい独自の技術で実装すれば、まず解析されません。

>ネットワーク

帯域の話なのでしょうか。基本DTOを軽量にするよう設計するだけかと。
RESTやSOAPなどいろいろ選択肢はあると思いますが、その要件にあったものを選べばよいだけだと思います。

>テスト体制

テスト体制については、そもそもテストに対する意識が低いプロジェクトが多いというのは問題だと思っています。
業務システムでは、特にテスト計画自体がゆるく、機能要件に対するテストのみが重視され、非機能要件(セキュリティ、性能等々)に対するテストが効果的に実施されているプロジェクトが少ないと。
私が実装する場合は、このあたりをトータルに加味して実装するので、大したテスト計画がなくても問題は出ませんが、他のエンジニアが実装したものについては、コードレビュー等で対応することが多いです。

ronさん、こんばんは。

> 紙芝居は一度顧客に見せて、全体のイメージについてはおおまかに決めた上、
> その上で、（こちらの考える）画面実装・DB実装を入れて、
> 個別の画面について、細部の仕様を話合うわけです。

やっていることは、私と同じですね。
ただ、ここまで、ronさん以外の方も含めたコメントを読んでいても、
ストアド優位の絶対的な理由は見出せない、というのが実感です。

ストアドは部分的に使いますが、ビジネスロジックの中心はOO言語
でいきたいですね。

一番大きな理由は、PL/SQL などのストアド言語（と呼んでいいのか）は、
読みにくいし、書いていておもしろくないということですかね。
たとえばJava でコーディングしているときのような、楽しさがないというか。

こういうことを書くと、「顧客視点に立ってない」と言われる方もいるの
でしょうが、開発者が楽しく仕事をすることができれば、
結果的に顧客にいいシステムを提供できると思っているので。

おはようございます。ビガーさん。

>トレーサビリティ
オブジェクト指向よりかは弱いですけど、設計書類を充実させる事によりどうにかなると思います。
私はこれで困ったことがありません。
というのも、必ずデータベース周りの話しなので、オブジェクト指向設計のどの部分が実装されているのか分かるからです。
データベースが分かる人がいれば保守性も低くなりませんし、拡張性はいまいちですが、ストアドが変更される時は、テーブルが変更される時なので、テーブルに関する書類（CRUD表など）に合わせて記述すればOKです。
すなわち、トレーサビリティは弱いものの、オブジェクト指向設計時に、設計書に書けばどうにでもなる事だと思います。
※E-R図も一緒に書くといいです。
しかしながら、ストアドを乱用すると、データベース周りと決め打ち出来なくなるので、そこはオブジェクト指向言語で実装するべきだと思います。
あと、ストアドで起こる分析結果とどう結びつくのか分かりにくい問題ですが、そこは命名規則の出番です。
命名規則さえちゃんとすればいいと思います。
例えば、概念オブジェクトの名前_トランザクション名（商品発注など）_（CRUDのうちどれか）という風に名前をつけます。

ちなみに、トレーサビリティを上げるには、徐々に抽象度を下げていくのがよい方法です。
最終結果しか残さない人もいますが、それでは新規参入した開発メンバーが分からないなどといった問題が生じ、トレーサビリティが低くなると言えますので、全て残してなおかつバージョン管理ソフト下で管理させるのが良い方法です。

>２フェーズコミットについては、規模が大きくなるとどうしても必要になるケース(複数のDBで原子性を保障する必要があるとき)があります。

これについてなのですが、分散データベースでの話しですよね？
それについては3フェーズにするか、それを考慮した設計にすればいいと思います。
その時データ操作能力に特化したSQLを使わない手はありません。
分散データベースが出番の時は、運用形態（何時同期するかなど）と設計がからむ事なのでO/Rマッパーで解決する問題ではないと思います。

>その他の事について
回答頂き有難うございます。
参考になりました。

はじめまして。以前から生島さんのブログは拝読させて頂いております。
CNETブログのエントリーは読みますが、コメントはあまり見たことがなかったのですが、酷いことになるものですね。
そもそも「自称技術者」の方々は、RDBMSを使うというのは息をするようなものであって、それが「ありき」でプロジェクトを進めますから酷いものです。
プロジェクトのゴールを見極めず、いきなり開発言語やフレームワーク、方式を決めてしまう。それで進めてみて、「あ、まずい、ここの所でパフォーマンス出ないや。ストアドにしよう」って感じでしょうか。
いやー、15年前にやってた開発でも、それはだめな方の例として取り上げられる話でしたけどね（苦笑）
生島様が同じようなことをブログで主張される度に、思い出す次第です。
なかなか大変なこととお察し致しますが、頑張ってくださいませ。陰ながら応援いたしております。

初めてコメントつけます。
長いコメントチェーンを全て読み終わりましたので少しだけ。

以下の点だけ、大変気になりました。

●顧客とは誰か？
直接・間接的に我々ITエンジニアの構築したシステムを利用している方々でしょう。現場のオバチャンは直接お金を出していないかも知れないが、立派なユーザーです。
経営層はお金を出してシステム導入してくれ、現場の方々はシステムの使い勝手なんかに要望を出してくれる貴重な人です。
さーて、我々はいったい誰のために一生懸命システム構築やってんでしょうね。給料もらってるから？ユーザー企業の（決定権を持っている）部長さん？
ていうか、それが見えてなくて、ただプログラム書いてれば楽しい、とかなら、別の職業を見つけた方がいいかもね。

flatlineさんへ
＞一番大きな理由は、PL/SQL などのストアド言語（と呼んでいいのか）は、
＞読みにくいし、書いていておもしろくないということですかね。
＞たとえばJava でコーディングしているときのような、楽しさがないというか。
趣味でシステム組んでるなら、それにお金を出す方がかわいそうだから、サンデープログラマーでもやった方がいいと思いますね。

＞こういうことを書くと、「顧客視点に立ってない」と言われる方もいるの
＞でしょうが、開発者が楽しく仕事をすることができれば、
＞結果的に顧客にいいシステムを提供できると思っているので。
いいえ、「顧客視点に立ってない」のではなくて、「客の金を使ってマスターベーションしている」のです。
もっと自分を恥じてください。

以上です。
初コメントで失礼しました…

MR.CBRさん　こんばんは。

御意。

でもまぁ、ハイブリッドや電気自動車が普及しはじめてから渋々勉強会に行くのと、
先見性を持って早くから研究に取り組むこと、逆に頑なに俺はガソリン車の
技術者だからと言ってギリギリになるまで手をつけないのとはだいぶ違うと
思います。

「ガソリン車の技術」をまだまだ使うとして。
書き込みを見直してみても、どうも「こんな時期だから、改めてSQLを見直そう」
といったような前向きな感じは見られないんですね。期待はしていたのですが。

MIDDLE さん、こんばんは。

> ていうか、それが見えてなくて、ただプログラム書いてれば楽しい、
> とかなら、別の職業を見つけた方がいいかもね。

> 趣味でシステム組んでるなら、それにお金を出す方がかわいそうだから、
> サンデープログラマーでもやった方がいいと思いますね。

> いいえ、「顧客視点に立ってない」のではなくて、「客の金を使って
> マスターベーションしている」のです。
> もっと自分を恥じてください。

読んでいて笑ってしまいましたが、MIDDLEさんは楽しく仕事をすることが
きらいなんですかね。
それとも、エンジニアは顧客の利益になることなら、自分がやりたくない
ことでも何でもやって苦労を全部かぶるべきだとでも？

だとしたら、MIDDLEさんは気の毒な方ですね。
で、楽しく仕事をしているエンジニアを羨望しているわけですか？

３Ｋとか５Ｋとか７Ｋとか言われていても、エンジニアという職業が
おもしろいのは、ぶっちゃけて言ってしまえば、人（顧客）の金を使って
自分の知識を向上させられること、だと思います。
顧客の喜ぶ顔とか、他にもいろいろありますけどね。
もちろん仕事である以上、利益を出さなければいけない（顧客に満足して
もらえなければいけない）という前提条件はあります。しかし、その
前提条件を守っていれば、その過程を楽しんでいけないとは全く思いません。
むしろ楽しむべきであるとさえ思います。

で、その楽しみを味わえるのが、私の場合、OO言語だというだけです。
ストアドで十分楽しめるという方は、それでいいんじゃないですか？

自分の趣味を貫き通した挙げ句、顧客に迷惑をかけているならともかく、
どちらも満足しているのであれば、これ以上、何が必要ですか？

どこから「趣味」だの「マスターベーション」だの「自分を恥じて」だのが
出てくるのか不思議ですが。
仕事を楽しむことと、趣味とは全く違います。
その違いがわからないのだとしたら、それこそ自分を恥じるべきだと思いますが。

自分が幸せじゃない人が、他人を幸せにすることなんかできないですね。

MIDDLEさん　こんばんは。

それを言ってしまえば、たとえ幼稚園児がメガバンク級のシステムを
利用するのであれば、それでもお客様ということになってしまいます。
そんなことが現実に有りうるのか？ということです。

MIDDLEさんのおっしゃる事も、定義としてはごもっともですし
私の周りでも同様のことを言う先輩・同僚は多いです。
しかし、相手からお金や要望を一方的に頂いていて、何も考えてこなかったのが
今のSIerの現状ではないでしょうか？
このご時世、もっと戦略的にならなくてはいけないと自分に言い聞かせております。

これからは、趣味でシステム組むのもOKです。マスターベーションもOKです。
それが結果的に顧客の役に立つのならば。

皆さん、おはようございます。

何度も書いている通り、現在、使わなくてもできるモノではない。
高校生でもできるようなモノである。
それを、避ける、選ぶのに好き嫌いを持ち出すなら議論なんて要らない。
技術者（もちろん技術者とは認めないけど）のいうことじゃないでしょうが。

そんなカスのコメント欄汚しは全部消そかな。

結局、何度も何度も書いている通り、技術を選ぶための判断基準は、最終的に工数（開発、保守、教育）とパフォーマンスしかないのです。

ビガーです。おはようございます。

最後にこれだけ。

>インドリさん

トレーサビリティを確保することのメリットは、お客様に対するメリットです。
お客様自身が実現したいことをシステムの観点においても口出しでき、ある程度のコストについて理解をいただけることが大きいと思っている次第です。

開発者側は、どのような手法で設計実装されていようとも、自身の中でトレースできる状態にしている義務があると思っています(システム毎にものすごくダメなシステムも多くあるから、理想論ですが、その努力は続けるべき)

>２フェーズコミットについては
>O/Rマッパーで解決する問題ではないと思います。

O/Rマッパーの話は、トランザクションの正規化なる手法と等価になるという話で、２フェーズコミットとはまったく別の話です。

実際コレをやるとなると、実際問題DBだけ考えればよい話ではなくなることがほとんど
だと思います。
(そもそも開発対象のシステム内での問題ならDBを２フェーズに分けないように設計すればよいなど対処は容易だが、外部システムとの関連で、DB以外の要素を含めて原子性を担保するのは容易ではない)

おはようございます。ビガーさん。

>トレーサビリティを確保することのメリットは、お客様に対するメリットです。

同感です。
私はストアドでも確保できておりますので、やり方を説明しました。
お客様にデータベースで実現できる事を説明できないようでは、システム構築は出来ません。
そのためにも分析段階を概念を定義するものと明確に定めております。
データーベースを操るからには必ずストアドが必要になります。
その時トレーサビリティをどう確保するのかはシステム屋としての腕の見せ所です。
トレーサビリティを確保できないからオブジェクト指向言語を選ぶのではなく、ストアドでトレーサビリティを確保しなくてはなりません。
誤解されたら嫌なので念のために書いておきますが、私の手法が完璧だとは考えておりませんので、他者の手法を否定しているわけでもありません。
常に他の者の意見を取り入れつつ、より完璧に近づく事を目指しております。

>O/Rマッパーの話は、トランザクションの正規化なる手法と等価になるという話
>で、２フェーズコミットとはまったく別の話です。
済みません。読み違えました。

>実際コレをやるとなると、実際問題DBだけ考えればよい話ではなくなることがほ>とんどだと思います。
>(そもそも開発対象のシステム内での問題ならDBを２フェーズに分けないように設
>計すればよいなど対処は容易だが、外部システムとの関連で、DB以外の要素を含めて原子性を担保するのは容易ではない)

そうですよね。
運用・設計など全てを考えなくては分散環境は実現できません。
私もWAN系のシステムを開発した時に苦労しました。
ACID特性を100％保証するのは原理的に不可能なので、どの様に設計するのかが難しいところです。
間違いや予想もつかない例外をも考慮し、システム構築しなければならないですよね。

>この記事についての言及
これはこの記事のテーマにも通じていると思います。
システム屋をしていれば、SQLを習得しないなんて選択ありえません。
データベース・セキュリティ・ネットワーク・ソフトウェアエンジニアリング・テスト・プログラミング言語など情報処理技術全般を知っていないとシステム構築できません。
SQLが嫌いだから勉強しないのではなく、勉強してふさわしい局面で使用する事が肝心です。

>一番大きな理由は、PL/SQL などのストアド言語（と呼んでいいのか）は、
>読みにくいし、書いていておもしろくないということですかね。
>たとえばJava でコーディングしているときのような、楽しさがないというか。

気持ちは分からないわけではありません。
ちょっと違うかもしれませんが、興味がある言語やもっと経験積みたい言語
フレームワークを使ってみたいという欲求は私にもあります。

生島さんを持ち上げるつもりはないんですが、言語やフレームワークは所詮
顧客のシステムを実現する上での手段ですから、言語によって楽しいとか
楽しくないという感情は私は湧きません（私っておかしい？）。
システムを実現をする上でよいものを使うのが当然であって技術者の
好奇心や好き嫌いで選ぶのは論外と思ってます。
世の中には技術者の好き嫌いで言語やフレームワークが結構決められているの
でしょうかね・・・？

前回の書き込みは狙って極端な事を書いた部分があります。
お見苦しいところを見せてしまって申し訳ないです。
また、生島さんコメント汚し、更に申し訳ありません。
ただこの点だけははっきり書いておきましょう。

＞だとしたら、MIDDLEさんは気の毒な方ですね。
＞で、楽しく仕事をしているエンジニアを羨望しているわけですか？
いえ、仕事は楽しいですよ？
楽しい楽しくないというのは、flatlineさんとは違う部分を見ている以上、わかってもらえないとは思いますが、私は新しい技術を見るのも触るのも楽しいですが、それ以上に顧客のほしがっている、要望しているポイントを突くことができた時のほうが楽しいですね。
新しい技術を学ぶとか、そんなことは当然のことで、エンジニアとして生きている以上日常的にしている事です。それを、「客の金を使って」するのは、（私にとって）エンジニアであることの根幹が揺れ動くくらいに違和感のあることです。
いかにして顧客の仕事を楽にするか、便利にするか、それは当然のごとくシステムのパフォーマンスや保守性などと繋がってくるのですけどね。

＞ひらさん
特に顧客の言いなりになるつもりはありません。こちらもプロだからこそできる助言もあります。重要なのは顧客といい関係を築き、お互いにWin-Winの関係を作ることではないかと思うのですが。

生島さん

> そんなカスのコメント欄汚しは全部消そかな。

杞憂かもしれませんが、そのような発言を続けてしまっていては、
会社の信用に関わりませんでしょうか・・・？

これだけネット社会が発達しておりますと、関係者のほんの小さな発言が
凄い勢いで風評として広がっていきます。

もし社員や関係者が、ブログ等で不適切発言をしてしまい、炎上すると
処分の対象になったりします。

生島さんの会社の方針が、どのような方針かわからないのでなんとも
言えませんが、もし関係者が自分の社名を出した上でこのような
発言を繰り返していれば、お咎めなしではすまないと思うんです。

失礼ながら、まだネット上でのコミュニケーションにそんなに慣れて
いらっしゃらないのかな？という印象も受けました。
ピクミンみたいなヤツらがコメント書いていて、
ギャアギャア煩いから消してしまいたい。
そんな気持ちわかります。私も最初はそんな錯覚に陥っていましたから。

しかし、コメントを書いているのは生身の人間なんです。

もっと怖いのは、コメントすら書かない人たちです。
まさか、とお思いかもしれませんが、
懇意にしている大会社の取引先の人とか、講座の生徒たちが見ている
可能性だって大いにあるわけです。

私の杞憂であることを願わんばかりです。

ron さん

おっしゃる通り、パラダイムシフトは元々は科学分野の用語です。
それを社会分野に持ち込むのはどうよ？というのは議論の分かれるところではあります。

>そのたとえですと、RDBMS 以外のストレージにも使えないと、
>「ハイブリッド」にならないですよね。

たとえなのでご容赦ください。
しいていえば、O/Rマッパーは遊星歯車程度のものでしょうか？

私は、RDBMSは5年くらい後には半減すると思っています。
根拠は、高度に発達した仮想化にあります。
そもそも、データをストアする必要があるのは、
メモリ内に大量のデータを蓄えておくことができず、
電源を切ってしまうとデータが生えてしまうので、
HDDとメモリの間を行き来させて、双方の欠点を補っています。
仮想化が発展すれば、メモリもストアも関係なくなってしまうので
RDBMSも今ほど重要ではなくなってしまいます。

現在のOODBやXMLDBには、たしかにおっしゃる通りポテンシャルが
見えておりません。しかし、アプリ側との相性を見ますと、
テーブルの塊であるRDBMSよりはポテンシャルがあるのではないでしょうか？

>DataTable の方じゃなく？
正確にはDataTableでした。失礼しました。

私はWebでDataTableを使うことが多いです。
たとえば、郵便番号マスタを作ろうとしたとき、何も考えずに
DataTableを使用すると、全11万件を取得します。
これがWinのアプリならばまだ良いのですが、Webの場合
集中処理ですので、Webサーバに11万件のデータを蓄えてしまうのです。
郵便番号マスタ画面を開いているのが1大のクライアントならいざしらず、
2台、3台と増えてくると、メモリに蓄えられるデータも
単純に22万件、33万件と増えていきます。

マイクロソフトが「非接触型になるのでパフォーマンスが向上する」と
さかんに言っていましたが、詐欺だと思いましたね。。。

MIDDLEさん

>重要なのは顧客といい関係を築き、お互いにWin-Winの関係を作ることではないかと思うのですが

私が問うているのは、業者-顧客との関係(relationship)ではなく、
顧客はどのような属性をもったモノを想定しているのか(who,profile)です。

単に顧客といっても個人もあれば法人もあり、
中小企業から大企業もあり、医療も小売も銀行もありますよね？

ここに集う人は、それこそ様々で、いろいろな顧客を相手にしていると
想像できます。

個人を顧客に持つ技術者と、メガバンクを顧客にもつ技術者が、
同じ土俵で「お客様の発言」を根拠に議論しても、永遠に平行線の
ままである　という意味でした。

MIDDLEさん、こんばんは。

> 私は新しい技術を見るのも触るのも楽しいですが、それ以上に顧客の
> ほしがっている、要望しているポイントを突くことができた時のほうが
> 楽しいですね。

それには同意ですよ。先にも書いた通り、企業として利益を出すってのは
当然で、利益を出すということは、顧客に満足してもらうということなので。

> 新しい技術を学ぶとか、そんなことは当然のことで、
> エンジニアとして生きている以上日常的にしている事です。
> それを、「客の金を使って」するのは、（私にとって）エンジニアで
> あることの根幹が揺れ動くくらいに違和感のあることです。

その「日常的にしている」を、どうやってやっていらっしゃるのか
興味がありますが。
優秀なエンジニアでも、やっぱり1人でやれることって限界があります。
私は過去に何度か苦い思いがあるので、いわゆる大手SIer というのを
肯定的に見ることができないのですが、それでも彼らが出してくれる
お金は魅力的です。
たとえば、Sun とかの技術研修に一通り行こうとすると、ウン十万の
お金がかかるわけで、とても個人に出せるものではありません。
研修費用を出すのは自社かもしれませんが、そのお金だって最終的には
エンドユーザになるわけですよね。つまり、「客の金を使って」自分の
スキルを高めているわけです。

もちろんそれをシステム開発の形で、顧客や自社に還元しているので、
立派にwin-win だと思っています。

生島さん、こんばんは。

> それを、避ける、選ぶのに好き嫌いを持ち出すなら議論なんて要らない。
> 技術者（もちろん技術者とは認めないけど）のいうことじゃないでしょうが。

> そんなカスのコメント欄汚しは全部消そかな。

これを読んで思ったことを２点だけ書きます。

1. 子供の頃「バカって言うやつがバカだ」と教わったことを思い出した。
2. 確かに議論にはならない。自分に反対する発言は全部抹消してしまって、
　周りにイエスマンしか残さないんだとすれば。

ビガーです。最後の最後にこれだけ。

オブジェクト指向で考えるからトレーサビリティを確保しやすいと考えており、
業務システムを構築する上での今現在の私の最適解であると考えています。

オブジェクト指向言語で実装する理由は、オブジェクト指向の考え方を実現しやすいから
に他ならないと考えています。

そういう思想がない元に言語の優越を論じるから宗教論争になるのかと推察しています。

ひらさんへ

＞「ガソリン車の技術」をまだまだ使うとして。
＞書き込みを見直してみても、どうも「こんな時期だから、改めてSQLを見直そう」
＞といったような前向きな感じは見られないんですね。期待はしていたのですが。
→この部分が生島氏が主張するがなかなか実現できず、苦しんでいる部分ではない
　でしょうか？SIer、技術者が好き嫌いで判断している部分が多大にあると思います。
　(生島氏が言うように、技術者の意識が変わるのではなく、発注側が変わっていく
　しかないと私も感じます)
　弊社にもSEさんが多く来ますが、私も生島氏が唱える通り圧倒的にSQLのスキルが
　不足していると感じます。
　(弊社に来て3ヶ月ほどで、SQLをゴリゴリ組めるようになります)
　RDBMSを使うシステムを構築する立場の人間は、生島氏が提示するSQL例を、
　即興で出来れば最高ですが、出来なくてもやろうと思えばSQLで出来る
　という選択肢(判断)を持っている事が重要だと思います。
　最低限、そこまでSQLは習得してもらいたいと思います。

みなさん、おはようございます。

何度も何度も書いているとおり、好き嫌いの感情が入ると議論じゃないのです。
私が感情を持ち出しているのではない。
私は理論値で話をしているのですけれど、反対派は好き嫌いと多数決でくるので、そこからは議論じゃないから怒るわけです。

好き嫌いは理屈になってない、そんなとても技術者とは呼べない人とは、議論にはならないから来て欲しくないのです。

使うならSQLをできるようにならなければならない。
ハイブリッドエンジンの研究はやったらいいけれど、ガソリンエンジンなしにハイブリッドエンジンは動かない。ガソリンエンジンが十分に扱えてこそハイブリッドができる。
ハイブリッドが流行りだからガソリンエンジンは要らないなんていう自動車メーカーの技術者はいない。

EVにするからガソリンエンジンは要らないというのは正解。
つまり、何度も何度も書いているとおり、SQLが嫌ならRDBMSを使わなければいい。

ただ、それだけの話。

ビガーさん。おはようございます。

>オブジェクト指向言語で実装する理由は、オブジェクト指向の考え方を実現しやすいから
に他ならないと考えています。
>そういう思想がない元に言語の優越を論じるから宗教論争になるのかと推察しています。

何か誤解されている気がします。
実際問題データベースが必要で、それを操るにはSQLが必要です。
その中でトレーサビリティを如何にして確保するのかが大事なのです。
トレーサビリティを確保するためにオブジェクト指向言語ばかりを使って、
システムの品質を下げるのはおかしいかと思います。
それに、何度も言っているように、それ程トレーサビリティは下がりません。
データベースエンジニアリングを学べば自然とSQLが必須だと分かります。
その他にも、ネットワーク・セキュリティ・テスト・ソフトウェアエンジニアリングなど情報処理技術全般を学べば、オブジェクト指向言語を使えばいい問題ではないと分かると思います。
オブジェクト指向が解決できる問題は、情報処理技術全体の中では微々たるものです。
私は合理的に判断して、その中で技術を使っているだけです。
ビガーさんはオブジェクト指向言語に依存しすぎていませんか？
オブジェクト指向は万能ではありません。
一技術にしか過ぎないのです。
ビガーさんの回答を読んでいると、オブジェクト指向に傾向しすぎると感じます。
オブジェクト指向だけで考えても解決できない問題は山ほどありますよ。

ところで、ビガーさんはどのオブジェクト指向方法論を使用されているのですか？
それが分かれば話しが進むと思います。
ちなみに私は、OMTをベースにしてBooch法とObjectoryを少々加えたものです。
それと、トレーサビリティ以外には何も考慮しないのですか？
その点が非常に気になります。

＞flatlineさん
少しは「カス」と言われる理由をよく考えてみるべきです。
あなた自分で論理破綻しているの分かってますか？コメント全部読み直した方が良いですよ。
まあ、こっちが技術者としての研鑽の話をしてるのに、大金が必要なベンダー資格取得の話を持ち出してくるくらいだから、話が噛み合わなくて当然でしょうね。

＞ひらさん
ところで顧客の種類がいろいろだったら、技術者がやることが変わったりするんですか？
少なくとも「要件を満たすシステムを構築する＋α」という意味では全く同じだと思うんですが。
私が言っているのはそういう意味です。ひらさんが質問にあげていた「幼稚園児がメガバンクのシステムを使ったら？」ですけど、それで何が変わるのですか？
仮に幼稚園児が使うかもしれないシステムであれば、当然そういったことを考えて組み上げるでしょう。
多分これはひらさんの欲しがってる答えとは違うと思いますが、ひらさんの質問したいこととは一体何でしょう？

MIDDLE さん、こんにちは。

> まあ、こっちが技術者としての研鑽の話をしてるのに、
> 大金が必要なベンダー資格取得の話を持ち出してくるくらいだから、
> 話が噛み合わなくて当然でしょうね。

では、MIDDLEさんの言う、「技術者としての研鑽」って、
たとえばどういうことを指していますか？

MIDDLEはなんで資格の話だけに矮小化して叩いてるの？
flatlineは『たとえば』と、ことわった上で発言してるだけだし
そもそも、技術研修⊇資格研修じゃないの？

それとも、MIDDLEには別の意図とか結論があるから
わざとミスリードしてまで叩いたりしているのかな？

ビガーです。こんにちは。

>インドリさん

>ビガーさんはオブジェクト指向言語に依存しすぎていませんか？

どうしてこういう疑問が出るのか正直理解できませんが。。キャッシュの話とか非機能要件(セキュリティなど)の話とか今まである程度インドリさんに話したつもりでしたが、まるで伝わっていないみたいですね。

私は、オブジェクト指向言語に依存もしていないし、オブジェクト指向にも依存していません。
それとやっぱりトレーサビリティの意味が伝わっていないみたいですね。残念です。

ビガーさんこんばんは。

>私は、オブジェクト指向言語に依存もしていないし、オブジェクト指向にも依存していません。
>それとやっぱりトレーサビリティの意味が伝わっていないみたいですね。残念です。

うーん。ビガーさんが言っているトレーサビリティは私が考えているものと違うのですか？
とすると、ソフトウェアエンジニアリングにおけるトレーサビリティではないと言う事でしょうか？
そうなると、正直って難しいです。
ビガーさんは論拠となるオブジェクト指向方法論も明らかにしないし、
ただトレーサビリティがとしかいいませんので、それでビガーさんのトレーサビリティとは何かを考えるのは難しいです。
さらに、オブジェクト指向とも関係ないとなると何のトレーサビリティなにかのヒントがまったくありません。
まさか竜駐業界におけるトレーサビリティを言っているなんてことないでしょうし、計測機器などのトレーサビリティを言っているわけではないでしょうし。
ビガーさんは一体何のトレーサビリティを仰っているのでしょうか？
普通は、要求定義書や設計書ソースの履歴などの情報を関連付け、成果物への影響を追跡するものです。
それで私は設計書や命名規則などに言及していたのですが・・・
非常に気になりますのでヒントだけでも言って頂ければと思います。

おっと失礼。

誤：竜駐業界
正：流通業界

flatlineさん、初めましてこんばんは。

今回の炎上に際してまず、お考えを整理された方がいいかとおもいます。
決してflatlineさんのお考えに一方的なNoを突きつけるつもりはありませんが、
今回のテーマには似つかわしくないコメントが多く見受けられましたので。

というのも、flatlineさんのご意見には二つの要素が混ざり合っていると思うのです。
一つはテーマ通りの技術的な側面、もう一つは人の職業観、価値観です。
これらは現実的には決して不可分な問題ではありますが、
生島さんのお言葉から察するに今回の議論はその前者しか問題としていません。
(というよりも生島さんは後者は一人前のプロになってから言えという感じでしょうか？)
そもそも、その両方を同時に語ったのでは収拾もつかないでしょう。
このような理由から、一部のflatlineさんのご意見は今回のエントリに似つかわしくないと思うのです。
カス発言は置いておくとしても、コメント削除であればその論拠はあると感じます。

その一方、エンジニアライフというカテゴリで見れば十分アリだと思います。
ご自分でこの問題に関してエントリを書かれてはいかがでしょうか？
もちろん技術的な側面に限ればこちらでのコメントも可能かと思いますが…。

第三者が差し出がましいようですが、ご再考いただければ幸いです。

VoX さん、こんばんは。
丁寧にありがとうございました。

> 一つはテーマ通りの技術的な側面、もう一つは人の職業観、価値観です。
> これらは現実的には決して不可分な問題ではありますが、
> 生島さんのお言葉から察するに今回の議論はその前者しか問題としていません。

はい、それはわかっています。
わかっているからこそ、本気で業界を変えるつもりなら、後者の考えにも目を向けてほしいと思ったのですが。
いや、これは失礼か。勉強時間の点とかについて、どういうお考えか聞きたいと思ったというのが正しいですね。

まあ、確かに今回のエントリに限っていえばふさわしくない意見だったとは思います。@IT会議室に意見を書いた方がよかったのかもしれませんが、生島さんの意見を聞きたかったというのもあるので。
今、あっちの方で、まりもさんがこのコラムについてのトピックを立ててますが、生島さんはご覧になっていないようなので。もっとも、今現在は、本題とは関係ない不毛な論争になっているようなので、あまり見る価値はないかも。

flatlineさん、おはようございます。

理屈で考えられない技術者など不要だと考えています。
淘汰の対象です。
この時代、もっと救うべき技術者が大勢いますから、あなたがリストラされてどんな目に遭っても、良心の呵責は一切ないですね。

生島さん、おはようございます。

腹を立てるべきなのかもしれませんが、生島さんを気の毒な人だと思うだけです。

flatlineさんへ
その問題については、管理者や経営者は無知でいいという馬鹿げたことが通用しているこの業界の恥部だといえます。
変化が早いのが情報処理技術の特徴なので、普通はプロジェクトに学習＆調査期間が設定されていなければおかしい。
そうしないと、会社の競争力が失われます。
しかし、管理者や経営者は無知でもいいからそらすら知らない。
その一方で、その無知さから生じる様々な弊害を技術者だけに押し付けています。
しかしだからと言って、SQLの学習を怠ってもいいという事にはなりません。
自身は鍛錬を積みつつ、理論的に反論しないと「どっちもどっち」になってしまいます。
自身が技術者として恥ずかしくない生き方をして、会社の方を見限りましょう。
自分も一緒に怠惰になろうでは、何時の日にかお客様がこの業界のいい加減さに気付いた時、無知な経営者や管理者ともども葬られてしまいます。
結局は技術者が賢くなるしかないので、この話題についてはここで終わりにして、
業界の本質的問題についてはご自身のコラムで書く事をお勧めします。

インドリさん、こんにちは。

「その問題」というのは、たぶん勉強時間のことだと思うので、
一応、言っておくと、私自身は技術者は常に勉強し続けるべきだと思ってるし、
実践してるつもりですよ。別にSQL(ストアド) という意味じゃないですが。

ただ、前にも書いた通り、現実には勉強する意欲はあっても、状況や環境がそれを許さない技術者の人もたくさんいると思うのです。実際に知ってますし。
で、生島さんのコラムを読んでいると、「優秀な人だけ生き残ればいい。淘汰されたくなかったら勉強すべし」という主旨のことが書かれているので、じゃあ、勉強したくてもできない人はどうすべきと思っているのかが疑問だったので、質問させてもらったわけです。
で、「そんなやつら知らないよ」という答えをもらったので、そういう考えの人だということで、この問題に関しては解決だと思ってます。

まったくくだらないことに答えると、世の中は平等じゃないのです。
私は大学に行って学者になりたかったけれど働くしかなかった。
思った自分になれないのは、それは自分の責任ですわ。

自分で稼げる歳になって、時間がどうの言ってるって訳が分かりません。
すべて自分の選択、自己責任です。

不況の最中、困っている人はいるでしょう。私も困っています。
で、困っている人を助ける人もいます。
この人をつぶすのは惜しいと思う人には、誰かが手を差し伸べます。

手を差し伸べてもらえる人になるしかないでしょう。
自己責任というのは、助けてもらってはダメではなく、手を差し伸べてもらえる人になるまでが自己責任なのです。

生島さん、こんにちは。

生島さんのお考えは十分わかっていますので、わざわざくだらないことにお答えいただかなくてもいいですよ。

私には同調できない考えだというだけです。
社会人であっても、思った自分になれないのは、自己責任ばかりとは限らないのです。

flatlineさんへ
返信有難うございます。
flatlineさんはちゃんと鍛錬を忘れておらず、業界の問題点を挙げたというわけですね。
私もデスマーチが日常的だったのでその気持ち分かります。
勉強をさせてほしいというものではなくて、「生産性を上げるのを邪魔するな。」という感じですよね。
不思議な事に、日本のIT業界は利益を上げるための行為を邪魔しているとしか思えない会社が結構ありますよね。
不景気になるのは当たり前です。
生島さんが仰っているSQLも知らない素人レベルの人だって、それを雇用している会社があるわけですし、彼らも得するからそうしているのでしょう。
本来経営者が会社の利益を上げるための仕組みを考えなければならないはずです。
従業員の良心にまかせ、さぼれば得する環境を作れば会社の生産能力が落ちるのは至極当然です。
この業界の問題は根深いですよね。
なにはともあれ互いに頑張りましょう。

ビガーです。最後最後といいながらすみません。

>インドリさん

まず、トレーサビリティに関しては、コメント内で表現することはボリューム的に
難しいので、その内に私のコラムで書こうと思っています。
その軸としては、すでに私のコラムで書いている業務分析についてシリーズ(1～3)で
書いた内容になります。

で、オブジェクト指向方法論ですが、誰の思想が優れているかとか誰の考え方が
好きだとかは、どうでもいい話と考えているので敢えて回答しませんでした。

なぜなら、現在は、表記法はUML、開発プロセスは事実上RUPに標準化されています
(OMTとかOOSEをベースに)ので、「実務」という観点でいうと論じる余地はないと思います。

実務上最も重要なオブジェクトの抽出方法と抽出したオブジェクトの実装方法に
言及した実務向けの指標となる解や書籍は、私の知る限り見当たらず、さまざまな
業界でより多くの実務経験をベースに、各業界でより最適なモデルをブラッシュアップ
していくことの方が、エンジニアとしては、重要であると考えているためです。

トレーサビリティについて、ちょっと今後の展望をお話しますと、
今後クラウド指向が加速すると思いますが、その土台として
オブジェクトで考えることは必須となり、データ量増加状態でどのように性能を
担保できるか(開発者視点のトレーサビリティ確保)、お客様がIT投資をする際に
モデルとシステムがどうマッピングされているのか(お客様視点のトレーサビリティ確保)
を提供することで、お互い(開発側、お客様)に、よりスピーディな経営判断(開発側含)に
つながるモノ(実装)を提供していくことに価値が出ると考えています。

あくまで私の考えですけどね。

MIDDLEさん

>多分これはひらさんの欲しがってる答えとは違うと思いますが、ひらさんの質問したいこととは一体何でしょう？

「根拠」「論拠」「証拠」です。
(前回は「原点」と書きましたが、そのような言い方はしないようなので訂正します)

特に論拠に至っては、暗黙の仮定とされるので、これを明確にする必要があります。

「お客様なんとか変えてください」
「顧客の都合でよい」
「誰が生き残るかを決めるのはお客様ですね」

といった発言などから、お客様に拠り所を求めていることが窺い知れます。
お客様がYesといえばYesだし、Noと言えばNoという結論を出すだけの話です。

ところが、このお客様像がどこにも明示されていないのです。
ここの会議室で話をしている全員が、唯一の客(たとえば鈴木建設情報システム部)
だけを相手にしているのならば、『お客様を拠り所にする姿勢』からして
鈴木建設に問い合わせれば済んでしまうことの話です。
しかし、サイトの性格からして、広い意味でITに関わっているであろう方々が
参加しているこの会議室では、「お客様」がまちまちです。

適当な仮想の客を想定し、それに対して議論を進める(これをペルソナ法と
いいます)方法ならばあります。しかし、暗黙の了解が多すぎて、
仮想客さえ定義するのも困難です。

以下、引用の順番が前後します。

>ところで顧客の種類がいろいろだったら、技術者がやることが変わったりするんですか？

MIDDLEさんが、どのような会社のどのような技術者を想定していいらっしゃるのか
計りかねますが、日本で一番従事者の多いSI(システムインテグレータ)を
例にとりますと、
この業種は、オーダーメードでシステム(ソフト・ハード・インフラ等のセット)を
組み上げます。その会社固有の事情に合わせたシステムとなります。
洋服のオーダーメードでご存知だとは思いますが、一人ひとりの洋服の型が
違うように、システムも会社によってまちまちです。
その会社によってシステムの組み方は違っていますので、技術者のやることも
顧客によって変わるのが一般的です。

SI以外でも、パッケージソフト開発やショッピングサイト開発・運営など
ありますが、それでも「10代・女性」とか「30代男性・既婚」など
ターゲットを絞り、それに従った技術を導入するのは一般的です。

技術者が、全ての顧客に対して同じことをするのは、OSかブラウザの開発
くらいのものですかね。なかなかそのような仕事に携わることはできないと
想定しますので、今回はそれは外しました(MIDDLEさんが初めからOS開発
技術者を想定していたとしたらごめんなさい)。

>少なくとも「要件を満たすシステムを構築する＋α」という意味では全く同じだと思うんですが。

前述のSI業者では、それは当然のことなので議論の対象にならないだろう
ということで省略しました。考慮するしても、対象が広すぎてしまっているので
今回の議題には沿いえません。

>仮に幼稚園児が使うかもしれないシステムであれば、当然そういったことを考えて組み上げるでしょう。

メガバンクが幼稚園児を相手にしたシステムといえば、せいぜい、
はじめてのお買い物のFlashアニメでしょうか。それにしても
幼稚園児が発注するとも思えません。

前述のとおり、お客様に拠り所を求めるのであれば、その論拠となる
「お客様像をはっきりさせること」が必要です。
MIDDLEさんの勤務する会社での主な顧客のプロフィールを挙げて
いただいても宜しいですし、今回の議論のターゲットとなる顧客像を
挙げていただいても結構です。

もし、幼稚園児が顧客だとしたら、この幼稚園児に、SQLの是非について
お伺いをたてる必要があります。

はたして現実的でしょうか・・・？

MR.CBRさん

お恥かしながら、やっと事態を把握しました。結構深刻ですね・・・

なんで、お前んとこの技術者にカネ払いながら、ワシんとこで教育せな
あかんねん！

という心境なんでしょうね。

でもそれって、発注側の意識の問題ではなく、受注側(つまり呼んできたSE)が
まともに教育をやっていないからではないでしょうか？

それとも、発注側が、SQLも知らないような技術者も使え！と強要するのでしょうか？

flatlineさん

なんか若いなーーーー

独り言です。

ひらさん、こんばんは。

SQLは、実は高校生でもそこそこできるぐらい簡単なのに、SIerがえらく難しく喧伝するからか、顧客の方も難しいと思っている人もいて「避けて欲しい」と言ってくることもなくはないです。

この辺は難しい問題ですけれど、顧客側も最近は一律xx％カットとか、無茶な話をしてくるわけで、経費節減を本気で考えるのなら技術を見た方がいい。

単純に、高校生でも年間千人以上通るぐらいの国家試験の内容を焼き直しで質問するぐらいで分かるのですから、それを「避けるべき」なんて、馬鹿げた議論は必要ない。何とか顧客側に気づいて欲しいです。

こんばんは。

> インドリさん
> 本来経営者が会社の利益を上げるための仕組みを考えなければならないはずです。

思うに、いわゆる大手SIer って、ホストとかで叩き上げた技術者がトップにいるため、昔の感覚が抜けてないのかもしれません。某社はやたらとドキュメントの数だけ多くて、ステップ数で工数換算（Java案件で）してて啞然としました。

> ひらさん
> なんか若いなーーーー

いやあ、結構、年ですよ。SE35歳定年説が正しければ、とっくに引退です。

では、みなさまよいお年を。

ビガーさん回答有難うございます。
トレーサビリティについては、やはり私と同じ事を言っているとしか思えませんでした。
トレーサビリティも私は結構重要視していて、だからネットワーク・データベース・セキュリティ・テストなどの全行程をどうやってオブジェクト指向設計で結ぶか（トレーサビリティの確保）という事を考えていたのです。
私が今までやってきた事は、お客様の注文を聞いて、そのシステムを分析・設計・実装（全行程担当）する事だったので自然とトレーサビリティに注目していました。
詳しい事はコラムに書かれると言う事なので、楽しみにしています。
方法論については、RUPですか・・・
あれって結構曖昧で、個人差が結構あるので包合している開発論のうちどれを注目するのか知りたくて聞きました。
だって、ビガーさんはトレーサビリティが違うと言うので、違う方法論を取り入れているのかと思ってしまいました。
方法論は10個以上あり、役に立つものを自分で選択してなんぼですからね。
私はどんな技術でも優れた考えを取り入れて、自己流に使いこなすという姿勢です。
それで、ほぼ全ての情報処理技術を学習し、completeするために今は数学を学習しているところです。
なにはともあれ、ビガーさんのコラム楽しみにしております。

flatlineさん

>思うに、いわゆる大手SIer って、ホストとかで叩き上げた技術者がトップにいるため、昔の感覚が抜けてないのかもしれません。某社はやたらとドキュメントの数だけ多くて、ステップ数で工数換算（Java案件で）してて啞然としました。

なるほど。やはり学習不足ですね。経営者がボーとしているから未だにホスト時代になっているわけですね・・・
IT業界は人材不足とよく言われていますが、本当に不足しているのはまともな経営者なのかもしれませんね。

みなさま、良いお年を。

ひらさんへ

＞なんで、お前んとこの技術者にカネ払いながら、ワシんとこで教育せな
＞あかんねん！
＞
＞という心境なんでしょうね。
→逆に現役SEさん達に教えてもらう事も多々あるので、ある意味
　ギブアンドテイクだとは思いますが、ひらさんがおっしゃられる事を
　全く思わないか？と言うと嘘になります。
　(プロとは程遠い方も実際に多くいますので…)

　私は5年間小さなソフト会社に在籍し、製造業の社内SEになって10年が
　たちました。ソフト会社在籍時代、周りにDBを単なるデータストアとしか
　考えていない方々が多く、その時からデータ中心指向で考える自分との
　ギャップを感じていました。転職してから弊社にたくさんのSEさん達が
　来られましたが、私がソフト会社に在籍していた時に感じた印象と変わらず
　同じ印象を受けました。
　それが続いたので、ある意味それが当たり前という感じで私自身麻痺して
　いました。
　(2から3名ほどSQLにも精通しているSEがいて感動した記憶はあります)
　故に生島氏のコラムに共感共鳴した次第です。

　根底には、データが大事か？プログラムが大事か？どちらを優先するか
　という思想もあると感じます。我々現場(お客様)に近い部門では、圧倒的に
　データが大事になります(かといってプログラムを軽視している訳ではありません)。
　現在のSIerや技術者はプログラムを最優先に考える方が多いような気がします。
　(10年間SEさん達と接してきた私の主観です)

＞でもそれって、発注側の意識の問題ではなく、受注側(つまり呼んできたSE)が
＞まともに教育をやっていないからではないでしょうか？
＞
＞それとも、発注側が、SQLも知らないような技術者も使え！と強要するのでしょうか？
→これまで弊社では履歴書と面接で判断していましたが、Oracleを5年経験しているのに
　SQLは…な方々も実際におられるのです。SIerの教育方針にまで口を挟むつもりは
　ないですが、生島氏が唱える簡易テスト(SQL等)を実施する事も検討していこうと
　考えております。

最後に生島さん、来年は思いが届く事を私も祈っております。

生島さん　こんにちは。

MR.CBRさんの解説のおかげで、やっと生島さんの真意が理解できました。

以前、「炎上してでも議論がしたい」とおっしゃっていたので、その点では
成功だったのかもしれません。それにしても撒菱をまきすぎていて、論点が
なかなか掴めませんでした。私もその撒菱にひっかかった一人ですが。
高校生は今回のお話とは全く関係がありませんよね？前回のコラムで
オブジェクト指向言語について挙げていらっしゃいましたが、これも
真に主張したいこととの関連性はありませんよね。

【人の問題】
(A)
SQLが使える技術者

(B)
OO言語やO/Rマッピングなどに
うつつを抜かして、まともにSQLが
使えるようにならないエセ技術者

==========================|================================
【技術の問題】
(C)
DOA・SQL・ストアドなど
データ中心の考え方

(D)
OOA・O/Rマッピング・モデリング
などオブジェクト中心の考え方

世の中の動きとして、(C)→(D)へ移行しようとしています。
このことはどう変えようとしても変わりません。

一方、(B)のような自称技術者少なからずいるというのも本当です。
上図の、(B)と(D)を一緒くたにして議論しようとしているから
無理が出てきてしまっています。
失礼ながら、生島さんも意識していらっしゃらないと思いますが、
『(D)を推奨するような人間は全て(B)の味方とみなした上で』
議論を無理に進めようとしている個所が節々にあります。

時代に遅れまいと、(D)について必死に勉強している技術者も
たくさんいます。自分が信じていたことを根拠もなしに頭ごなしに
否定されると、とても寂しいものです。

もちろん、(B)については淘汰されるべきです。
おそらく、"(B)技術者"はオブジェクト指向を隠れ蓑として使って
いるだけであって、
もともと向上心がありません。試しに、PofEAAについて議論を
ふっかけてみてください。「そんなもの知らなくてもプログラムは
書ける」と開き直るのではないでしょうか。

生島さんがいままで担当なさった顧客も、よく理解しないまま
(A)ではなく(B)ばかり採用しようとしてしまう苦悩も理解できます。

SIerは、コンサルタントのような側面も持ち合わせています。
システム開発における原価は、ほとんどが工数で占められていますので
工数を削るしか原価を削減する方法を持ち合わせていません。
そこで、「SQLを極力使わない方法」と「SQLを使った方法」での
工数の違いやステップ数を実測し、顧客に提示してみるのです。
それで顧客に納得していただければSQLを使うほうに変わるでしょうし
もしそれでも納得されなかったら極力SQLを使わない方向で
(工数も費用も削減しない)作業を続けるしかないでしょう。
それが顧客のニーズなのですから。

実測をするにはもちろん時間も費用もかかります。そんな経費を
どこから出すんだ？という疑問もおありでしょう。
図書教育費または研究開発費ということになりますでしょうか。
そんな金など残っていないとお思いでしょうが、どちらにしても
これからは仕事は減っていく方向ですので、やらないで自滅する
よりも、実測・提示をやってしまったほうがまだ良いのではないでしょうか。

MR.CBRさん　こんにちは。

おかげで、やっとこの議論の真意が理解できました。ありがとうございます。

データが大事か？プログラムが大事か？ということですが、業務系のシステムで
あれば圧倒的にデータが大事です。

MR.CBRさんがどのようなシステムを開発なさっているかはわかりませんが、
OS開発や科学技術向けのシステムであれば、圧倒的にプログラムが大事です。
問題を解決するためのアルゴリズムが重要です。データは、そのための
パラメータでしかありません。
このように、プログラム中心の考え方を、DOAと対比して「POA」と言います。
(あまり言いませんが)

業務系のシステムであれば、データが大事です。
きちんとデータが格納され、呼び出され、それらに誤りがないこと、
集計が容易にできることが重要です。金銭を扱いますので
ストア前とストア後で1円でも狂えば大問題となります。
逆に、複雑なアルゴリズムを使うことは稀だと思います。
パターン分析や暗号化のアルゴリズムで悩むことはほとんどないと思います。

余談ですが、
さらに進めると「オブジェクトが大事」ということが出てきます。(OOA)
またプログラムに主体が戻ってきますが、今度は「データとプログラムを
一緒に扱う」ようになります。
オブジェクト指向では、『当たり前のことを当たり前のように扱って』
いるのですが、POAやDOAを経験してきた人にとっては、あまりの違いに
難しいものとして敬遠する人が多いですね。

オブジェクトは、簡単に言うとコレです。↓
http://www.youtube.com/watch?v=0zldvi6V0ms
現在位置と状態がデータとしてオブジェクト内に保持されていて(プロパティ)、
リモコンを押すと状態が変化します(メソッド)。右ボタンを押すと右に移動
しますし、Aボタンを押すとジャンプします。
それ以外に敵キャラのオブジェクトというのもあり、それぞれの関係によっても
オブジェクトに影響を与えます。マリオが敵に上から乗れば敵がやられますが
横・下からあたればマリオが死んでしまいますね。

これを、DOAで表現しようとすると冗長性が出てきます。
プログラムとデータが分離していますが、プログラミングの仕方によっては、
リモコンを押したときマリオとノコノコを同時に動かすことも可能です。
しかし、それは余計なことですよね？

これがPOAになりますと、もっと自由度が高いので、ノコノコが空を飛んだり
マリオが気まぐれに死んだりします。でも、そこまでの自由度は
とりあえずいらないですよね？

このマリオを「商品」や「材料」に置き換えたのがオブジェクト指向
でのアプローチです。「注文」や「在庫」など目に見えないものも
オブジェクトの対象となります。

ただ、残念なのは、オブジェクトが生成されたり動いている様子が
目にみえないということです。これらが「見える化」されれば
オブジェクト指向への理解が爆発的に広がると思うのですが。

余談が長くなってしまいましたが・・・。

さらにSOAというのもありますが、これはもっと大きな枠で捉えていますので
ちょっと話題から外れてしまいますね。

皆様、あけましておめでとうございます。
今年は良い年にしたいですね。

何度も書いてますけど……。

DBサーバをでっかいオブジェクトとして考えて設計する。
DBサーバでできることは（表示に関すること以外）すべてDBサーバで行う。
例えば、DBサーバが何種類も、何台も存在する場合もあるでしょう。
しかし、各DBサーバでできることは、各DBサーバで完結させる。

どこまで行っても同じことです。
ムーアの法則を超えて企業が成長して、予想できないDBサーバ（テーブル）の分割が必要になったとしたら、年率数百％の急成長しているのですから、システムの再開発費用ぐらい楽に出ます。ムーアの法則を超えてないのに、スケールアウトが必要になるとしたら、最初の見積が甘すぎるのです。
スケールアウト・スケールアウトという人は、最初の見積に余程自信がないのでしょうね。
スケールアウトが必要なシステムを有する会社なら、DBサーバのライセンス費など知れたモノですし。

DBサーバはオブジェクト指向はそもそも向かないので、内部的にDOA、全体＆クライアント側はOOA、顧客と話するときはPOA（プログラムじゃなく、プロセス中心アプローチ）顧客は基本的にプロセスしか考えてない。

それこそOODBにでもしない限り、インピーダンスミスマッチ必ず存在するのです。

それを、OO言語側でなんとか吸収しようとするから、結果的に無理が生じてSQLが混じり込んだりする。
そんな歪な設計になるのは、とにかくSQLが分からない人が多すぎる、高校生レベルにもない人が設計しているのですから、本当におかしいといってるのです。

あけましておめでとうございます。

生島さん、こんばんは。

　MR.CBRさん向けの返信ではありましたが、話題を広げすぎてしまいました。
私自身、ちょっと反省です。

> 何度も書いてますけど……。

　いえいえ……
「各DBサーバで完結させる」論や「高校生レベルにもない人」論は何度も
出てきているのでわかるのですが、

本当に言うべきことが言えていないのではありませんか？

ということに、僭越ながらも苦言を述べさせていただいております。

思うに、
・派遣で来る技術者が『高校生レベルにもない』くらいSQLを知らない
・顧客も「SQLは難しいので改修がしづらい。もっと簡単なものにしてほしい」
　と要望してくる。しかし、その割に開発料を値切ろうとする

という現状を、

技術者・顧客・自社の三位一体となって改善していきたい

ということを、コラムを通じて訴えていきたいという
ことではないのでしょうか？

ちなみに。
工数削減のためにSQLを使いたいと言っているのに、それでもSQLを
使うな！とゴリ押しするような顧客は、こちらから切ってしまっても
良いと思います。おそらく、顧客側担当者が淘汰されるでしょうから…

> 思うに、
> ・派遣で来る技術者が『高校生レベルにもない』くらいSQLを知らない
> ・顧客も「SQLは難しいので改修がしづらい。もっと簡単なものにしてほしい」
> 　と要望してくる。しかし、その割に開発料を値切ろうとする

どちらかというと、派遣でレベルが低いのは「ゴメンやけどスキル不足だから帰って」って言えば済むはなし。
顧客は、何にも分かってないから、何とでも口説けます。

問題は大手のSIerです。
まぁ、弊社も下請けをしないと生きていけないからね。
彼らは腐っていて、彼らに合わせて技術レベルを下げて作れと言われると、非常に困るわけです。

下請けと言っても、人月でなく、一括で請けているのでね。

ひらさん、こんばんは。
丁寧な解説、ありがとうございました。

生島さんこんばんは。

･･･ということは、論点はほぼ間違っていませんね。
大手SIerには困ったもんです。口も大きいですから。

MR.CBR さんこんばんは。
いえいえ、お礼を言わなくてはならないのは、こちらのほうです。
MR.CBRさんにご説明いただかなかったら、いつまでも誤解したままでした。