ちょっと、これはいただけません。

>継承ぐらいの小さな問題は、

継承がないオブジェクト指向設計なんて問題外なので、決して小さな問題ではありません。
SQLが出来ないのも大問題ですが、継承が分からないということは、オブジェクト指向分析／設計が出来ないと宣言しているのと同じであり、設計できない設計者が上流技術者だと名乗っている事をあらわしていますので洒落になりません。

# 生島さん、勝手に他人へのレス入れをします。
# ごめんなさい

インドリさん

素晴らしく楽しい読み物をぶち壊す
ずば抜けた才能をお持ちですね。

# ええ、今酔っていますとも

指摘された文章の後方の内容を把握しているのだとしたら
恐らく生島さんの上流と、インドリさんの上流の定義が異なっているでしょう。

100%正しい人はいないと考えていますので
記事に対する反論と、その回答についても、
熟慮できるテーマ（酒のつまみ）として、とても楽しく読んでいますし
生島ファン（呼び捨てでごめんなさい）として
またひとつ発見があったりするのですが..

なんというか..インドリさんの毎回のコメントは、
残念なところに濁点や句読点が入る感じがして
台無しになっちゃうんです。

もう1回くらい読み返してから書き込んでいただけると、
酔っ払いのボクの幸せは倍増するのですヨ。

# 美味しくなるか不味くなるかは紙一重

ま、こんなコメントのほうがノイズになっちゃう訳ですが

インドリさんも感じられるような
酷いコメントのサンプルとして投稿してみます

生島さん、連投です

# 先ほどは失礼しました。
# お酒って怖いですね。

毎回の記事やコメントへの回答で、
1%ずつ生島さんの苦悩を理解できるような気がして、
勝手に楽しませていただいています。

ボクはSQLについては勘定系の業務をした事がないので、
いつも例題と解答をみても理解できない（深く追っていない）のですが

そろそろWeb系？ようやくボクの時代が来たかと（笑
# といいつつコメントはSQLについて

オフショアで詳細仕様を依頼する際に
重要なデータの抽出部分では

select A, B, C
where こういう条件 & ああいう条件・・・

# 冗談抜きで、途中は日本語文章が混じります

というエセSQLで説明していまして、
結果、言語に関係なくほぼ確実に理解していただいていますので
SQLの効能（伝達能力の高さ）だけは理解しています。

という短い餌で生島さんを釣れるでしょうか？

SQL至上主義ではないので、勉強不測できちんと説明できませんが
効率化や処理速度以外の部分で、メリットを感じています。

まぁ、経営に窮されているのはわかりますが。。
作り方はどうでもいいみたいな表現がされていますが、
あなたが取引されているであろうエセ上流と変わらない行動にしか見えません。

それにオブジェクト指向の有用性があまりお分かりとは思えませんね。
分析した概念モデルから如何にストレートに実装まで落とすか。それにより、
業務の変更に強いシステムが出来上がり、お客様に将来的にも喜ばれるシステムになると
考えます。

実装面でいうと、
・スレッドセーフにすべきコンポーネントは継承ベースから委譲ベースにした方が好ましい
・IOC(InversionOfControl)ベースの穴埋めしていく実装形態の場合は、継承ベースにするべき
などなど
使いどころで変わってきます。

また、SQL云々は永続化やデータ参照の1手段でしかない。
そろそろ時代(KeyValueStoreなど)に沿った話も混ぜないと現実味が薄い気がします。

ビガーさん

オブジェクト指向の有用性が～という話ではないと思いますがいかがでしょうか。
どんな言語や設計手法を用いようとも、さらに上流であるSQLを含むDB設計（を含む初期の打ち合わせの時点）でパフォーマンスはもちろんその後の作業の進め具合やら何やらが全て変わってくるので、もっとこっちも勉強しましょう、という話だと私は思っています。
スレッドセーフ云々は生島さんの記事と全く関係ないでしょう。
※打ち合わせの段階でUML等を用いて話をするのはとても私も有用だと思います。

時代に沿った話という件も生島さんの記事の本質と全く異なるものだと思います。
...関係はないですが、コンピュータを用いるシステムというものは、データがなければ何の役にも立たないのでKeyValueStoreなどは確かに非常に重要だと思いま
す。

生島さん

毎回楽しく読ませていただいてます。
昔PHPを使ったWebアプリを構築していた際に、自称上級SEがあるSQL文を使っていいよといって差し出してきました。
複雑な抽出条件の付いたSQL文で、抽出処理に大体10秒ほどかかっていました。
バッチでもないのにこれはないだろうと思い修正しようと試行錯誤したのですが上手くいかず。(WebアプリでSELECTに10秒はありえない...）
最終的にシンプルなSELECT文に修正してPHP側で多次元連想配列を用いて0.5秒から0.9秒まで処理時間を短縮させました。
恐らく私のSQLのスキルが低かっただけだとは思うのですが...
パフォーマンスに関しては生島さんのおっしゃりたいことのほんの一部だとは思いますが、SQLで書くよりもプログラム側で対処したほうが影響範囲が少ないということもあります。

コメントの方は、オブジェクト指向分析／設計の大事さを分かっておられないですね。
SQLはDOA（データ中心アプローチ）の事をあらわしていると思うのですが、DOAだけでシステム開発は出来ません。
これらかの時代は並列なのにも関わらず、オブジェクト指向分析／設計も出来ず、SQL（DOA）も出来ず、ソフトウェア工学も知らず、では本当に何のための上流なのか分かりませんね。
ちなみに、上流から考えるべき事はまだまだあります。
セキュリティも上流から考えねばなりません。
デバッグも上流から考えねばなりません。
運用／保守問題も上流から考えねばなりません。
ソフトウェアライフサイクルも上流から考えねばなりません。
・・・・
こういった複雑な事柄を全て丸投げしているわけですね・・・・・・
さて、上流は一体何の仕事しているのでしょうか？
何度も私の元へ「全て丸投げ」されて一人でシステム構築した事あるのですが、その場合上流達は仕事をした事になるのでしょうか？

インドリさん、ども。

長文だったから読みにくかったかな～。
確かにくどい（苦笑）

くどいけど、主旨はブレてないと思うけど……。
タイトルは釣りですが、オブジェクト指向のことなど何も書いてないです。

toannaさん、ども。

私も、記事もコメントも半分ぐらいは酔っ払って書いてるので……。
（編集部が校正してくれるから、公開されている時間と書いた時間は違います）
朝読み直すと、直すのが面倒なぐらいクドくて……。
ちょっと直して編集部に渡してしまいます。

オフショア……。
オフショアのためにバラバラに分割しているところもありますよね。
目的と手段を間違っているような気がするのですけど。

そこまで書くなら、あとの単純作業を、学生アルバイトにやらせる方がいいんじゃないの？

って思いながら私は見ていますけど、思いません？
本当にオフショアで儲かります？

生島さんへ
継承はオブジェクト指向の継承ではないのですか？
VB6とVB.NETの関係を持ち出していますので、私はてっきりオブジェクト指向の継承かと・・・

ビガーさん

あれもこれも必要なのですけど、SQLのスキルは一般的に確実に足りてなくって、足りないことで影響が強くでる。

費用対効果が高いところに集中すべきってことで、他が不要って言ってるわけではないですよ。

ただ、オブジェクト指向（これはナンチャッテもいますけど）にしても、セキュリティにしても、ネットワークにしても、上流は足りてないことを認識しやすいし、認識していますから、ちゃんと専門家に振ります。

でも、COBOL上がりの営業＆上流がやっちゃってくれたりするんですよ。
ループしたときのイメージはかなり正しいだけに、滅茶苦茶迷惑なわけです。

彼らは、そこは専門家と思っていますからね……。

さばさん、ども。

WEBに表示するSELECTで10秒は困りますね。

WEBで表示するということは、答えは表示できるデータ量ということです。

連想配列に入れて処理すれば速くなるということであれば、単発のSQLでインデックスは当たってるということです。
ということは、複雑にする過程でインデックスをはずしているだけで、チューニングしたら1秒は絶対に切れますね。

PostgreSQLとかだと「何でこのインデックスを使わないんだよ！」ってこともたまにありますけどね。

インドリさん

タイトルは釣りです。
継承ができないって馬鹿げていると思うなら、もっと影響が大きいSQLを、その影響度と同じぐらい気にしたらどうか？という比喩的な表現のために「継承」を持ってきているわけです。

問題にしているのは、顧客と話すような段階のことで、顧客に継承するかどうかなんて関係ないので、顧客と話しているときに継承しないイメージを持って話しても、大部分は業務的なことを話しているわけですから、本質的なところではずすことはないのです。

しかし、たとえば必要のないバッチ処理をイメージしたとしたら、顧客に「次の打合せには、運用担当の社内SEを同席させてください」って言っちゃうわけですよ。
これで、ほぼ取り返しがつかなくなります。

継承するかどうかは、社に戻って下流の技術者も交えて検討する内容ですから、ボトムアップで提案することが十分可能でしょう。

本文の主旨と関係ないのです。

業務アプリケーションならっていう前提ですよね。

この記事より前の記事を見ないでの発言ですので、外れたこと言ってたらご指摘ください。

ビジネスロジックをSQL「だけ」で書くわけではないですよね？
適材適所でSQLで書いたほうがよいことはSQLで書き、オブジェクト指向で書いたほうがよいことはオブジェクト指向で書き、VB6でやったほうがよいことはVB6でやったほうがよいし、.NETを使ったほうがよいことは.NETでやればいいのでは？

GUIはオブジェクト指向の方が管理しやすいし、ビジネスロジックは言語なんて何でもいいと思います。おっしゃる通りインフラ考えたらビジネスロジックはRDBMSがいっちゃん適切だと思いますけどね。

この記事だけ読むと、「何でもかんでもSQLでやったほうがよい」っと取れてしまいました。

まぁ話の趣旨は、上流で正しい選択をするためにはSQL「も」覚えろよって事だと思いますがｗ

お客さんにとってオブジェクト指向どうたらはどうでもいいってのには同意。

ついでに。
ネトゲの上流では、SQLもオブジェクト指向も無いと死んでしまいますｗ

そんな餌に釣られないクマーーーーorz

seraphimさん、ども。

もちろん、業務システムの話です。

上流にも守備範囲があって、案件には100万から10億をはるかに超える規模もあるわけです。
1千万、2千万規模なら、上流もコーディングにも参加するぐらいでないといけないから、全部知っておく必要がありますけれど、億を超える規模を担当する上流には、言語は関係ないです（言語を担当する上流もいるけどね）。しかし、いずれの規模をやるにも、RDBMSを使うなら最上流にSQLは必須といってるわけです。
（必須いうのは必要条件で十分条件ではありません）

個人的には上流下流じゃなく、内部（SQLなど）外部（UIなど）に分けるべきと考えています。
最上流も内部、外部に分かれて専門性を持たせた方が良いと思うのですけれど。

本当に本文の内容が理解できれば、COBOLerにSQLという意味がわかると思うのですけれど。

興味深く読ませて頂きました。
私は一介のプログラマをやっておりますが、現場では一つの画面や帳票の項目をそのまま並べて削除フラグと更新日時を付けただけようなテーブル設計を頻繁に目にします。
むしろ、SQLが分からなくても良いから、せめて正規化ぐらいは考えようよって感じなレベルですねぇ。○|￣|＿

継承についていうと、見た目より扱うのが難しいですからね。その「継承なしでやってきた」という方では、(無理をして)継承を使っても、逆に乱用してかなりひどい事になりそうな気がします。
慣れないうちは、関数のインポートとは違うことが、(頭では分かっても感覚として)なかなか理解できないようですね。型を意識できる様になると違うのですが。

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

そのテーブル設計で動くとしたら、よほど小さなシステムでしょうね。
ウン億のシステムでもそれをやるところもあるけど（苦笑）

継承に限らず、便利なテクは「馬鹿の一つ覚え」で使ってしまうことがあって、そうならないためには幅広い知識が必要ですね。

生島さん、ご返事ありがとうございます。

> そのテーブル設計で動くとしたら、よほど小さなシステムでしょうね。

そうなんですよね。で、数万ステップ以下の場合は、コードの方でごまかして何とかなっていたものが、10万ステップを越える辺りで収拾が付かなくなってくると。
そういった案件の火消しにあたる事も多いです。私としては仕事が取れるので、ありがたい面も有りますが。(笑)

ただ、DOA的な開発をやっているところでも、正規化や関数従属などの基本的な概念を理解しているエンジニアは、かなり少ない印象が有ります。私の周りだけだったら良いのですが・・・。

Ikeさん、ども。

いろんなレベルの技術者がいるから難しいですよね。

私は、オブジェクト指向も、インフラも、セキュリティも、小さな問題と思いませんけれど、その影響度は20～30％のものですよ。そして上流の人は、オブジェクト指向も、インフラも、セキュリティも、自分はできてないことを知っていて、専門家に振りますけれど、SQLって業務の根幹にかかわることなんです。

彼らはそれだけは専門家だと思っているから、性質（たち）が悪い。
それを何とか正したいと思っています。

生島さんに質問があります。
前から不思議に思っていたのですが、

>彼らはそれだけは専門家だと思っているから、性質（たち）が悪い。

生島さんはこれらの人を観察しておられると思いますので御聞きするのですが、
こういった人達はどうして専門家だと思い込んでいるのですか？
誰しも自分が出来ない事は分かります。
それにも関わらず、こういった人達が専門家だと思い込んでいるのが不思議です。

さばさん

>上流であるSQLを含むDB設計
これってさばさんは具体的に何をされていますか？

私は、毎回ですが上流でSQLなど「どうでもよい」と主張しています。
上流で重要なのは、前述のオブジェクト指向的発想とトレーサビリティをどのように
(要件定義→実装へ如何に紐付けて)担保するかです。

>パフォーマンスはもちろんその後の作業の進め具合やら何やらが全て変わってくる
さばさんは具体的にどのように進めているのですか？

私の場合は、システム的な性能や開発効率を高める実装面での具体的施策として
スレッドセーフやIOCを取り上げました。
そのため、思いっきりテーマや内容とリンクするんですよ。

さばさんの考え方をお聞かせ下さい。

インドリ さん

> 彼らはそれだけは専門家だと思っているから、性質（たち）が悪い。

それとは業務分析・理解の部分ですね。
それすらできなかったら上流って何なのよ。

私の周りも、上流と呼ばれる技術者はそこの部分は完璧ですよ。
完璧だけに崩しにくいしのです。
もう一段上は見えないのです。

まぁ、たまにどうしようもない馬鹿たれもいますけどね。

ビガーさん、ども。

う～む～。

本当に初期の上流の時点で、最初は業務の話しかしないのに、そこでオブジェクト指向は関係ないですよ。COBOLしかイメージできてない人も、オブジェクト指向しか知らない人も、ほぼ同じことをしゃべっています。

変なことを口走るのは私ぐらいですね。

ただ、顧客との打ち合わせの最中に考えたイメージというのは、かなり覆しにくいことで、基本設計に落とし込むあたりでCOBOLの人とオブジェクト指向の人は極端な差が出ますけどね。

先にオブジェクト指向で考えると、実装時のクラス・メソッドを目指して、バラバラにばらすことを前提で考えますね。
この時点でSQLで処理するという芽はつぶされているわけです。← これが問題といってるのですけどね。

生島さん返信有難うございます。

それにしても何故日本は
「上流は○○が知らなくてもいい」だとか
「プロジェクトマネージャーは○○を知らなくてもいい」
・・・
などと逃げの理屈を並び立てて学習しないことが容認されるんでしょうか？
逃げ言葉を考えている暇があれば学習した方がいいのに・・・
それと、何故経営者は、そういった「利益を損なう」人を出世したり、高い報酬を支払ったりするのでしょうか？
私が万が一経営者になったら出来ない言い訳をしている人なんて要らないと思います。
会社は儲けてナンボ。
仲良しクラブじゃないのですから、出来ない人にはそれなりの待遇にするべきだと私は思います。
ちなみに、SQLから逃げるのはもちろん論外です。
SQLを知らない人がDOAなんて出来ません。

インドリさん、ども。

規模にもよりますけれど言語は必須じゃないですね。
2000万までならPMは全部知ってる必要があって、話しながらコーディングするぐらいのレベルがあってほしいけど、それ以上になってくると段々必要な部分がそれぞれ専門化していきます。
1億を超えたらメンバーの10～20％ぐらいは言語なんかまったく関係ない人が出てきます。もちろん、知ってた方がよいこともあるけれど……。

ただ、最上流（要件定義の前の営業段階～RFPぐらいね）で、顧客と話するときにベースがCOBOLだろうが、オブジェクト指向だろうが、ほんとに変わりないのです。それに上流が上流らしく分かれている規模（数億以上）の案件なら、このフェーズが長いのよ。下手したら1年以上かかっていることもあるわけ。

その1年掛けた話した内容が、SQLを知らないと、もう、違うんだな～。
グランドデザインはその辺で決まっているわけです。

さすがに金のない弊社では、億の案件では入れても要件定義であったり、基本設計ですが、この時点で変更の効かないのは、「SQLで考えられてない」ことと、「WEBシステムを選ぶか」になります。

それ以降のことは力業で変更させるけれど、この2つはどうしようもないわけです。

1年掛けてSQLをベースに話していると、その後の工程でSQLを使わない選択肢は残ってないけど、上流に指導できる能力があれば下流は嫌でも勝手に覚えるし……。

生島さん

オブジェクト指向をオブジェクト指向プログラミングと等価と解釈されているようなので
基本設計以前の整理方法に「オブジェクト中心」という名前を使います。

業務要件の詰め方は、人それぞれでしょうが、軸となる進め方は各人がもっていると思います。
私は、オブジェクト中心の整理方法を使用することのが(どんな規模のシステムでもベストだと考えています。
生島さんの場合はデータ中心(COBOLベース？)なのでしょうかね。

オブジェクト中心とデータ中心を比較するとおっしゃる通り、基本設計以降で差が大きくなる。
データ中心は業務自体どうあるべきかあいまいになりがちで、振舞いをどこに定義していいかの判断が難しいからと考えられます。
具体的にはオブジェクト中心は、静的(概念)モデル・動的モデル(業務フロー)・機能モデル(ユースケース)を軸に考えます。
データ中心は、ERモデル・DFDなどを軸に考えるんでしたっけ？

業務フロー(業務アクティビティ群)と概念モデルで定義する基幹データと振舞いがリンクし、
業務アクティビティとユースケースが基本的に1対1に紐付きます。
そのため、業務と実装する機能のトレースが容易なわけです。
また、業務が変わったらどの部分の機能に影響するという関連が把握しやすいので見積もりもしやすい。
これが私の云っているトレーサビリティが重要であると主張している理由です。

上記のようにそもそも進め方が生島さんと一般の方は違うので、基本設計以降で話がかみ合わないのでは？
そのあたりは高橋さんのコラムがとっても参考になると思いますよ。
http://el.jibun.atmarkit.co.jp/skillstandard/

生島さんへの返答とはいえ、コラムの主旨とかけ離れたことをお詫びします。

とりあえず、釣られに来ました。（笑）

生島さんはＳＱＬを知るべきとよく書いておられますが
対象はCOBOLerから上級SEになったかた（なったつもり？）に
対してのメッセージと受け取っていいのでしょうか？

さて、オブジェクト指向の話しが少し出ていますので
コラムと主旨が違うのかもしれませんが、私なりのオブジェクト指向論でも
ひとつ書いておきます。

まず、オブジェクト指向開発は私なりには失敗したと感じています。
また、現在、本当の意味でのオブジェクト指向開発は、ないんじゃないかな？とも
思っています。

まず、オブジェクト指向開発の失敗についてですが
・設計者がオブジェクト指向設計の手法できっちり設計できる人が皆無。
・開発者がオブジェクト指向言語を理解している人がほとんどいない。
・オブジェクト指向設計の成果物を元にオブジェクト指向言語で開発ができない。

の三点ですかね。

一つ目、二つ目は、そうだよなーと思われる方は多いと思いますが
三つ目は？が浮かぶ人が多いと思います。

オブジェクト指向設計で作成されるドキュメントはUMLとなるのが
一般的ですが、このUMLからコードを起こすのが非常に困難です。
なんせ、画面設計書がないですからね！ER図もないし！！
（DAOがそうかと言われるとそうかもしれませんが）

いやいや、画面設計書と画面繊維図とER図作ってるから大丈夫と
いうのであれば、それは、通常の構造化設計となんら変わりません。

構造化設計でできた成果物を元に、オブジェクト指向で開発するんだから
悲劇しかうまれません。

今の、オブジェクト指向開発ってほとんどフレームワークを使用しての
開発ですよね？
それって本当の意味でのオブジェクト指向ではないと思います。

面白いことになってますねー！

規模とかOOPだとかそんなことはどうでもよくて、
SQL(これタブンRDBMSでしょ)についての考察が必要な段階で、それについての知識が無いまま進んでしまうと、後になって(上流・下流を問わず)皺寄せが大変なので、有識者もSQL（RDBMS）の知識を覚えましょうよってことでしょ。演習問題は、その例として挙げただけで、別にSQLステートメントそのものだけに的を絞っているわけではなさそう。確か前に、上流が知るべきSQL（RDBMS）の知識は何っていう話ありましたからね。セミナでもパフォーマンスに触れるようですし。

オブジェクト指向に注力しすぎて設計されると、オブジェクト的データ保持から二次元的データ保持への変換という問題にぶつかりやすいし、従来のデータストア的な設計バリバリだとパフォーマンスや量で問題が発生しがち。なので、SQLを！？ってことなんでしょう、きっと。
XMLDBやオブジェクトDBの話題が出ないのは物足りないって思う人もいるかもしれませんけど、日本では、やっと実用段階に入った感じのもので、まだまだ広くミッションクリティカルなエンタープライズシステムでの利用といったことは、無いようですし。（米では結構利用実績あるようですね）なので現在の主流は、やはりRDBMSですからね。

「上流」ってのは特に定義されていない抽象的な概念ですから、これにひっかかったらだ～め。
（ここは、規模感が人によって異なるので注意）　数人で出来る開発と数千人で開発する現場のOOPの捉え方が異なるのと同じように（言語仕様ではないですよ、例えばOOP言語を運用するといったような意味ですよ）、上流・最上流・超上流　なんてのは変わりますからね。生島モデルを推測しながら読んでみよう。（自分モデルではなくてね）

見てる人も、ふ～ん、前とさほど言ってる事(真意は)かわらんね・・・くらいで、スルーすると逆に面白いんじゃないの！なんて（W）、生島さんが慌てちゃってさ！
ですから、部分部分の文章につられた人・・・・○○（○○のなかはご自由に、文字数制限もありません）

ぁぁぁあ、自分も釣られてる　orz

ぶっちゃけ、所謂、閉鎖的な基幹システム開発で、常時(数)千名従事規模ですとOOPだろうが他の何かだろうが同じ。だってたいがい、リソース持ち出せなくなります。使い回しできないんですよ・・・、そして、本当に使い回すのって５～１０年後以上先ですよ・・・、意味無いって（TT）、刹那的な知識が必要なのは間違いないですけどね。むしろ、言語を問わず新しい物でも素早く、そこそこのレベルになれる能力が必要かな

私のOOP論、
OOP? あんなもの宗教だろ！　全ては物であるぅ～、物には状態だとか属性だとか、なんかいろいろあるぅ～　おまえは陰陽師の子孫かぁ！　ひーひー(略)ひ～じ～さん、あべのせいめいだろ！ある意味、良い血筋だねきみ、ウン。

ともかく、データ中中心アプローチと、オブジェクト指向分析・オブジェクト指向設計・オブジェクト指向プログラミングは上流で是日覚えて欲しいですね。
オブジェクト指向とデータ中心は補完しあう関係です。
データに関してはデータ中心アプローチ、その他はオブジェクト指向○○、さらに、理想的には機能要件については構造化設計が便利です（機能要件の検証に威力を発揮する）。
これに昨今ではアスペクト指向が絡んでくるかもね。
これらを全部使えばいいのです。
※私がやっているときはアスペクト以外全て使います。
この記事にも書いています、上流がプロジェクトの基盤を固めてしまうので、使えるものは全て覚えて欲しいですね。
そうしてもらわないと、我々下流に流れてくる情報が全てごみの場合もありえます。

ビガーさん、ども。

基本設計の前の話をしてるのですけどね。
そこにいくまでにイメージが決まって超えれない壁ができているのです。

もちろん、最上流がSQLで考えたイメージを持って指揮棒を振ったら、その後ろで基本設計から入る上流も、実装する下流もSQLができなければ話にならない。基本設計が終わったら、それを書いた人がSQL書いた方が効率的で、そういう意味では現在の「上流」の定義で考えるとSQLは必須になる。

個人的には、内部と外部に分けるべき、内部はDOAが向くし、外部はOOAが向く、なぜごった煮にして片側でやろうとするのか私には分からない。インピーダンスミスマッチは確実に存在するのに、片方に寄せて考えると、どこかにしわ寄せがいくと思いますけど……。

私の場合、イメージを確定するまでは、インドリさんがおっしゃるとおり、POAやDOA、OOAをいきつ戻りつしながら考えてます。

で、基本設計になったら内部はDOA、外部はOOAって切り替えになりますね。

mayoさん、ども。

釣り師の面目躍如といったところでしょうか。
この長ったらしい（読みにくい）文章をまじめに読んで頂ける方が、これだけいるというのは、実にありがたいことだと思います。

> 今の、オブジェクト指向開発ってほとんどフレームワークを使用しての
> 開発ですよね？
> それって本当の意味でのオブジェクト指向ではないと思います。

フレームワークを作るところがオブジェクト指向開発ですね。

でも、再利用できるパーツを大量に持つことがひとつの理想でしたから、理想のところにきたから、逆に、OOAと離れてきているのかもしれません。

どえぇ～、おえぇ～、っときたら、ポアについても・・・

むしろ、POA的な発想のままOOP言語使おうとするからっていう問題もあるのではないだろうか・・・
良く出てくる、COBOLERな・・・って人は、POAを引きずっているくさいのですが・・

oumiさん、ども。

おっしゃるとおりで「OLAP関数ができるようになるべき」と受け取った向きもあったようですが、っんなことはどうでもいいのです。
そう言ってるのに、なかなか絡まれたりするけど、私が言ってることは10年変わってないから、毎度、同じ内容ですよ。
私がみなさんに釣られて派手に書いているだけで（苦笑）

上流でSQLができたら、2000万クラスの案件ならビジネスロジックの部分は上流だけでほとんど終わっちゃうし、最上流でも書いてきたとおり必要です。億を超えるクラスなら、営業もざっくりSQLがわかるようになるべき。

ところが、上流にいる人は「言語なんて……（ry」というでしょ。
ぶっちゃけ、優秀な人はCOBOLベースで見積もってもいい線でくるし、OOAで考えている人と、本当に話している内容に差はないです。
SQLは差が出るから「やれや～」って言ってるわけです。

> 所謂、閉鎖的な基幹システム開発で、常時(数)千名従事規模ですとOOPだろう
> が他の何かだろうが同じ。

たしかに、同じですね。
その規模は私は絶対に逃げる。
自分の色が出せないからな～。

余談ですが、その規模は大阪は大体1件ぐらいなんです。
それが止まっているから、もう、トンデモない人が市場に流れてしまって、普段絶対に廻ってこなかったタイプの技術者が、私の領域にも侵食してきて……。

oumiさん

POAのままOOPかそうなんですかね。
COBOLerは無理してOOPに行かなくても、プロジェクトにおけるSQLの重要度をあげてちょっと勉強してもらったら、本当に最強なんですけどね。

もちろん、オブジェクト指向に行ってもいいんですけどね、それこそ自分で成功ラインを下げて、できるようになったつもりの人が怖いですよね～。

>ともかく、データ中中心アプローチと、オブジェクト指向分析・オブジェクト指向設計・オブジェクト指向プログラミングは上流で是日覚えて欲しいですね。
オブジェクト指向とデータ中心は補完しあう関係です。

当然の事なんですけど、これ。
でも、なぜこれができないかというと、歴史的な背景もあるのでしょう。
コンピュータがビジネスの世界にのさばり始めたころは「事務プロセスの効率化=処理速度の向上」という事でしたから、POA的なアプローチがとられていましたね。
しかも誰にでも理解しやすいというポイントがあります。
このPOAゲノムを受け継いでしまった人たちは、どうしても理解しやすいPOAな世界を重視してしますのです。【30年もそんな状態だったのです。】
○○○伝票がオブジェクトだという事は理解できても、システムを考えるときにはPOAになっちゃうのです。
「だって、所詮コンピュータなんて処理（仕事を）を速くすることが得意なんだからさぁ・・・」なんて事しか言えない人達・・・
そしてそのゲノムを継承してる人達・・・
「システム全体を自立協調型で作りましょう！」なんて言っても「ぽか～ん」っとされるのです・・・

と同じように、
「RDBMSは、データストアじゃないんだ！」といっても「ぽか～ん」っとされる人たちは、SAM(ISAM,VSAM,DAM,etc)ゲノムを引き継いでいるので、ひじょーにきびしぃ。
上流でこそSQL!なんて言うのは、無（Ryu・・・もとい、非常に険しい道のりですね・・・

アスペクト指向なんて、へたすりゃ、ただの構造化の言いかえじゃないか、なんて言われちゃいそう(^^;

インドリさん、ども。

アスペクト指向ですか、新しいことすきですね～。

こういうのって考え方の問題だから、理論化するのはそれはそれでいいけれど、固定化したら宗教になってしまいますからね。

絶対的な解は存在しないと思うので、混ぜて考える方が自然だと思います。

> (ISAM,VSAM,DAM,etc)ゲノムを引き継いでいるので、ひじょーにきびしぃ。
> 上流でこそSQL!なんて言うのは、無（Ryu・・・もとい、非常に険しい道のりですね・・・

無理なのでしょうか……。
こんな単純なものはないのですけどね～。

私はユーザ企業が「あれ？」気づいてくれたら、あっさり変わる風が吹くような気がしてるのですけれど……、無理か。

> アスペクト指向なんて、へたすりゃ、ただの構造化の言いかえじゃないか

私もこれに一票。

今、セミナーの資料を作ってたら、当たり前だけど、再帰はエクセルでは説明がつかん。生産管理には再帰がなかったら困るしな～。

ちょっと話しはそれますが、調子に乗ってちょっと書きます。
今の所、アスペクト指向は実務では使いません。
これを実務で使うの難しいです。
アスペクト指向はオブジェクト指向に足りない部分を補完する働きをするのですが、実務で使うとなれば、横断的関心事を開発メンバーで合意する必要があるのですが、関心事って開発者ごとに差異が大きそうです。
それに、実装を知らない設計者がアスペクト指向したら、明後日の方向を関心事にしそうで怖いです。
この技術を簡単に言うと、散らばったコードを分離するための技術なのですが、アスペクト指向設計が出来ていないので使い辛いorz
まだまだアスペクト指向の考え方が自体が統一されていないし・・・
継承で足りない部分を補完できるからいい考え方だとは思うのですが、業務系システムよりも、フレームワークなどのコンポーネントを作る時に使用しそうな技術ですね。
とはいえ、アスペクト指向設計＆分析が登場したら実務でも活躍しそうです。
その時は、またこうやって「上流はアスペクト志向も使うべき」なんて言いそうです。
兎に角、上流は学習して欲しいなー。
物事の本質はこれに尽きるという気がします。

> アスペクト指向なんて、へたすりゃ、ただの構造化の言いかえじゃないか

これは違いますよ。
どちらかというとコードのDOAです。

現実としてはオブジェクト指向とＳＱＬは同じ位置取りなんでしょうね。
ＳＱＬがしょぼいとパフォーマンス（即興性）に影響が出ますが、オブジェクト指向の設計がしょぼいと保守性や次回以降の開発効率（遅延性）に同じくらい影響が出ます。
確かに、「そのプロジェクトだけ」で言えば、コピー設計でも同等のものは納品できます。即興では同じだから、といって上流が無視していいものとは思えません。

一方、上流の定義といったら、「業務分析のできる人」でしょう。
業務分析とプログラム技術力を両方持てる人というのは非常に稀なので、なかなか上流担当者に技術力を！　と要求するのは酷でしょう。
両方揃っていれば、恐ろしいほど効率があがることは事実ですが、そこまで人間はうまくできていません。

　そういう前提で、上流技術者がＵＩ（オブジェクト指向）とＳＱＬ（ビジネスロジック）のどちらを身に着けやすいか？　と言われたら、ビジネスロジックでしょう。
　そういう意味で敢えてＵＩ側を切る生島さんの意見は支持します。

　上流に「もっと技術力を！」と言う方は、頑張って業務分析力をつけましょう。
　そうすれば、業務分析力と技術力の両立が難しいことが理解できると思います。

　本当の問題は生島さんも言っていますが、上流と下流の待遇が違うことが問題で、ＵＩとロジックといった違いでしかないのです。
　若いうちは技術者で、年をとったら業務分析といったキャリアパスも良く無いと思います。ただ、このキャリアパスが合う人が一番の多数派だというのを否定はできないでしょう。

全てを極められる人は居ませんが、だからと言ってSQLとかの技術面から逃げるという姿勢が問題なのだと思います。
0（上流）か1（下流）かではなくて、逃げずに少しの技術を身につけるだけでも生産性は違うと思います。
でも現実は、下流は業務の分析能力が無くては実装できないので鍛えますが、上流は色々な言い訳をして技術を学ぼうとしません。
しかも日本の慣習はそれを許す・・・
技術を学ぶのがそんなに嫌ならば、この業界に居なければいいのに・・・
それに、業務知識だけを言うならば、その道のプロであるエンドユーザーには敵わないのですから、上流技術者の存在意義が薄いという気がしてなりません。
学習するのはいや、でも高額な報酬が欲しい。
そんな我儘を許して来た経営陣に問題があると思います。

マジメに応えるのが面倒になってきたのでこれで最後にします。

>私の場合、イメージを確定するまでは、インドリさんがおっしゃるとおり、POAやDOA、OOAをいきつ戻りつしながら考えてます。で、基本設計になったら内部はDOA、外部はOOAって切り替えになりますね。
まったく意味がわかりません。具体的にどう進めていてメリットは何ですか？
(まぁもう見ませんけど)
歴史的にもPOA→DOA->OOAと遷移してきており、これらは補完しあう関係ではなく、
左から右に問題点を解消するために開発されてきた方法論なんですよ。
要望があれば私のコラムで懇切丁寧にレクチャーしますよ。

また、アスペクトは実務でめちゃ使いますよ。
宣言的トランザクションや調査目的にログの差込とか。
アスペクトとユースケースが紐づけられれば、システムとしては最終形でしょうね。

おっと、誤解を招く表現でした。
バリバリと業務ロジックとしては使いませんが、

>宣言的トランザクションや調査目的にログの差込とか。

これは使いますね。
それに、xUnitにも使われているので、改めて考えるとかなり使っていますね。
この技術はデバッグの際にも役立ちますね。

でも、ビガーさんここは違います。

>歴史的にもPOA→DOA->OOAと遷移してきており、これらは補完しあう関係ではなく、左から右に問題点を解消するために開発されてきた方法論なんですよ。

歴史的経緯はそうなのですが、オブジェクト指向だけと考えない方がいいですよ。
システムにおけるデータの流れを把握するにはE-R図を使って、DOAの考えでデータベース設計をするには適しており、機能要件の検討のときはPOAも結構役立ちます。
オブジェクト指向は、データ＋振る舞いなのですから、データに着目する時はDOA、振る舞いに関しては一部POAと考えるとよい設計が出来ます。
骨格をオブジェクト指向で、特化部分をDOAとPOAでと考えるのが良いかと。

m2さん、ども。

まったくそのとおりです。
全部を理解するのは難しく、UIとビジネスロジックを両方するのは、ほとんどの人は無理なんです。

で、あれば、上流に多いCOBOLerはSQLを覚えた方がよいわけです。
COBOLerのときの栄光とたまたま得たヒエラルキーをひけらかすと老害以外の何者でもない。

>　上流に「もっと技術力を！」と言う方は、頑張って業務分析力をつけましょう。
>　そうすれば、業務分析力と技術力の両立が難しいことが理解できると思います。

どうなんでしょうね。こちらも玉石混淆で、実は業務分析力があってもヒエラルキーを超えられない人と、下流がピッタリの業務分析力やもろもろのスキルがまったくない人といるからね～。

まったくない人を例に、所詮PG的なことをいう人もあるし、プログラミングをしてるということで下に見るというステレオタイプが一番問題と思います。

ステレオタイプの馬鹿げた決め付けはよくないですよね。

アスペクト指向って、要するにOOAでカチカチに考えたら駄目なことがあるよ。
ってことじゃないの？

アスペクト指向言語は使ったことがないので、概念の話ですけど。

そんなの言われなくてもやるべきだと思っています。
POAにしても、DOAにしても、OOAにしても、それだけじゃダメで、今まで一種類でできたってプロジェクトは個人的にはない。

是々非々で考えてきたので、どれにも当てはまらない考え方もあるかもしれない。
それがアスペクト指向かもしれないし、それ以外のやり方もやってるような気もする。

その変にコリ始めると、宗教戦争になりそうで……。

アスペクト指向は.NETやJavaを使っていると殆どの人がお世話になっていると思います。
影ではかなり使われています。
ただ、今のところ、ログ・トランザクション・デバッグなどの狭い範囲にしか使われていなくて、オブジェクト指向の様に自由自在というわけではないんですよね。
アスペクト指向分析・アスペクト指向設計・アスペクト指向プログラミングとソフトウェア工学的にまで進化しているわけではないのです。
それに、アスペクト指向はこれがアスペクト指向というものがなくて、まだ色々存在するので、混迷期といえると思います。
例えば、.NETのアスペクトと、AspectJのアスペクト指向は別物です。
とはいえ、修得しておいて損の無い概念であり、開発者の思考の幅を広げる重要な概念だと私は思います。

誤解されそうな部分があるので補足。

>ただ、今のところ、ログ・トランザクション・デバッグなどの狭い範囲にしか使われていなくて、オブジェクト指向の様に自由自在というわけではないんですよね。

これは開発者のノウハウがオブジェクト指向ほどない事を示しています。
実際のプロジェクトで、横断的関心事をちゃんと定義した経験のある人は少ないと思います。
せいぜい、「ログ取得機能でアスペクト指向の機能を使おう。」程度のものであり、オブジェクト指向と同じレベルで本格的にプロジェクト内で採用した人は少ないかと思います。
アスペクト指向分析とアスペクト指向設計が確立されていないのがネックですね。

えと、なんかいろいろな議論があるようですが、全部まとめると
・立場にあった勉強をしてください
・上流の人が不勉強だと全員が不幸になります
でいいのでしょうか？
で、上流の人が勉強すべき内容としてSQLやら他のやらがあがっている、と。

アスペクト指向とか、たぶん消えるし……。
消えなかったときにやっても間に合うしね。

現実問題として、上流と呼ばれる人にSQLのスキルが足りてない。

非常に単純なシステム以外は、規模に関係なくRDBMSを使う限り必要なスキルなのに足りてないのです。
POAもDOAもOOAも関係なく、必須のスキルが足りてないから身につけましょうよ。

それが一番費用対効果が高いですよ。ってことです。

アスペクト指向って、その考え方自体は当たり前の事すぎて、声を大にして改めていうのもばかばかしい話なのでは？

「横断的関心事をちゃんと定義」

こういったことって、ちゃんとやらないとシステム動きませんから・・・
それこそ、アセンブラだけで実装していた時代からやってますし。
オブジェクト指向な「言語仕様」として存在していなかったというだけで、ことさら取り上げて言うほどの事じゃありません。
（もっともきちんとやらずに燃えるプロジェクトもありますけどね）

なんて思うのよね。

そもそも、言語仕様に乗せるような話でもないとおもうんだけどねぇ、将来どのような実装になるか楽しみではありますね。どんな仕様に一般化して固まるのかはまだ謎ですけどね。妙な特権クラスとかで実装するようになると、とんでもないことになりますね・・・なんていうか、メインフレームのスーパバイザかぁ！みたいな？（あほくさ）

もっとも、今のスタックマシン系のテクノロジって、みなメインフレームでは存在している機能の焼き直しが多いですからね・・・
まぁリファクタリングの機能がすごいなんていう、馬鹿げたこと言う人が多い時代ですからねぇ・・ちゃんと設計できてコードかけたらリファクタリングいらないんだけどねぇ・・・

なんかちょっと愚痴。。。m(_ _)m

>それこそ、アセンブラだけで実装していた時代からやってますし。

違う話をしているような・・・
オブジェクト指向プログラミングに熟達すると、コードの分散が非常に気になるわけです。
それをデザインパターンとか用いて一生懸命していたものを改良するのがアスペクト指向です。
オブジェクト指向プログラミングをしている際に気になるコードの分散問題を解決するのであって、アセンブラなんていったらもっとコードが分散しています。
従って全然違う話題だと思います。

>まぁリファクタリングの機能がすごいなんていう、馬鹿げたこと言う人が多い時代ですからねぇ・・ちゃんと設計できてコードかけたらリファクタリングいらないんだけどねぇ・・・

もしかしてリフレクション？
リフレクションならばメタプログラミングが出来るので非常に有意義です。
これも何か誤解しているよな・・・

それに、メインフレームと全然関係ないような・・・

インドリさん。

> オブジェクト指向プログラミングをしている際に気になるコードの分散問題を
> 解決するのであって、アセンブラなんていったらもっとコードが分散しています。

まぁ、どうでもいいのですけど誤読かな。
アセンブラでやってても、優れた技術者というのはコードが分散しないように努力するわけで、分散しないようにあらゆる手を考えます。それを後付で「アスペクト指向」って名前付けているだけにしか見えない。

とoumiさんは言ってるわけです。
私もそう思います。

たぶん、「アスペクト指向」というのは曖昧すぎて、何年か後には、言われなくなると思うし、すごい！って言われるようになったら、「もともとやってたよ！」って私はたぶん言うだろう（笑）

ってぐらい、どうでもいいことだと思う。

アスペクト指向プログラミングしてみれば分かりますが、アセンブラプログラミングの技法とは全然違いますよ。※私は両方やっています。
アセンブラプログラミングのあれは多分モジュールプログラミングです。
それにアスペクト指向はなくなる可能性が低いです。
既に色々な所で使われていますので消えることはないでしょう。
といっても、主流になるかどうかは分かりませんが・・・
兎に角、上流は色々な事を知ってもらわないとね。
上流の無知を理由に選択肢を決められたら腹が立ちます。

まぁ、半世紀も前から論理はあって、賢い先人達はとっくに取り入れてますからねぇ・・。プロセスやフロー、データは言うに及ばず。

OOPベースじゃないと違う！というアホな人がもしいるとしたら・・知らん(W)

オヤジ的に考えるとWEBシステムって「カラフルになったダム端」ですわな。

WEBシステムでJavaScriptガンガン、Ajaxバリバリって「もう一回C/Sに戻るの？」

それなら転送量を考えても、最初からクライアントにプログラム入れとけば……。

元のC/Sになりますわな。

赤とんぼのうたみたい。
http://www.uta-net.com/user/phplib/view_0.php?ID=11293

ちゃんとやってた人にとっては、昔から余り変わってないと思うのですけど、VB6と.NETで大騒ぎになるんだったら、変わりすぎの業界とも言えるし……。

大筋では振りすぎた振り子が元に戻るだけです。
振れる幅がある（例えば、オブジェクト指向か、DBか）ということは、どちらも正しく、どちらも間違っている。プロならたくさんの選択肢をもって、振り子がどちらにいってもその時点のベストを出せばよいということかな。

最適解は、EUCが行き届いてシステム屋がいなくなることなんで。
それが実現するまでは、いったりきたりするでしょう。

で、「選択肢を持ってない」というのは大問題！っていつもの話。

まさかOSのディスパッチャとかをアスペクト指向と呼んでいるのかな？
そうだとしたら凄い勘違いだと思う。
関心事の分離は昔から言われていたけど、横断的関心事はちょっと違うだよね。
それかSmalltalkのメタオブジェクト（MOP）かな？
あれもちょっと違うんだよね。

>大筋では振りすぎた振り子が元に戻るだけです。

そうですよね。
集中と分化を繰り返しているわけですね。
昔の技術を調べると、殆ど変っていません。
すべてはLISP帰るってね。
でも最近はちょっと怖い変化がありますよ。
それは並列化です。
これも上流が覚えてくれないと大変な悲劇を生みそうです。

説明するの面倒なので１つだけ、
「関心事の分離」に代表される考え方は、I,N2T-D,N,F,H,なんかが持っている開発標準なるものを、ある程度読み解いて行くと「関心事の分離」も「横断的関心事の分離」も随所に現れてきます。もちろんOOPな現代でも参考になる事が盛りだくさんです。
まぁ、そんな古いもの？的に一笑することは自由。だし、上に書いたSierと関係してない世界で開発に従事している方にとっては、何それ？だとは思いますが。

アスペクト指向の元になる概念は、先にもいったように半世紀も前からある考え方。誰がそもそも言ったかはわかるね？
プロセスだけの分離ではだめだったという歴史があり、データだけでもダメだった、処理とデータを合体させたオブジェクト？でもちょっとあやふやなった。で、オブジェクトをさらに「関心事の分離」といった観点から推し進めているのが、アスペクト指向だね。つまり、根幹にある論理は「関心事の分離」Separation Of Concernsってわけ。であってるよね？
という意味では、設計手法・開発手法・プログラミング技法、どれにも「関心事の分離」「横断的関心事」という概念は昔から埋まっていましたからね。その埋め込まれ方が、インドリさんに知覚できなかったとしても、それは知らん。
というか、人間の自然な営みとして、無駄を省き、効率化しようとすると、自然とそのような動きになるわけ。何も新しい【言語】だけがアスペクト指向ですってことじゃないのね。まぁ解ってらっしゃると思いますが。アスペクト指向を「横断的関心事」と捉えた場合の話ね。【言語】だけじゃないっていう意味説明しなくても大丈夫だよね？
アスペクト指向をOOPと密接に結びつけて考えてしまうと、ちょっと様相が変わってくる面もあるね、当然です。言語仕様に対する評価、それだけに「なりがち」だからね。

こっからオヤジ的な話、
そして、アスペクト指向って、なんだか昔の「構造化」を髣髴とさせる（細かい話はさておいて）人の動線というかそんなものが古臭いのです。もっとも新しいアスペクト指向プログラミング（とその言語）とはいっても、所詮「関心事の分離」の派生でしかない。と、古い臭いがするので、オヤジ的な発想の話もでてくるわけです（Ｗ）
で、見る人が見ると、大意は何もかわらんな・・・って見えるのです。
「人の動線」というたとえは難しかったかな？

WEBシステムって「カラフルになったダム端」てのはどうかなぁ・・
オヤジ発想にしても酷い気がするなぁ・・・

間違ってたら「文意を良く理解したうえでの」訂正をよろしく。
っちゅーか本筋と違うから、〆ってことでいんじゃないかな。

えぇーそれをいっちゃあおしまいよ。
情報処理技術は変化が早い早いと騒がれていますが、殆どのものが前世紀の産物だしね。
人間の発想はそう簡単に変わりません。
確かにアスペクト指向は関心事の派生だし、私ですら思いついた技術ですからそんなに斬新ではないですね。
プログラミング言語なんて、結局はLISPなどの時代にもう既にある概念ばかりですし・・・
実装技術については殆ど変わっていませんね。
という事は、それを知らない年配上流技術者って何なんだって事になりそう。
年長者なんだからアセンブラから最新言語まで使いこなせても不思議ではない。
だって、元からあるものですからね。
それにも関わらずSQLすらも出来ないなんて大問題だと思います。
経営者にこの事実を教えてあげる方が事は早いと思います。
きっと経営者や株主も怒るんじゃないかな？

SQLというかテーブル設計というか。
SQLが分かってないとテーブル設計ができない訳で。なんとなくの中途半端なテーブルをなんとなく(大丈夫だろうっていう考えで)設計して。テーブル設計とSQLとSQLに対応したプログラム構造を上流が押さえていないと、詳細設計以降どう頑張っても覆しようがなく、結果パフォーマンスが出なかったり、コーディング量が極端に増えたり。上流がSQLくらい押さえてないとってのは、テーブル設計含めて最低限それくらい出来てないと下流がひぃひぃ言うよって素直に読んじゃったんですけど。

そう捉えると生島さんの言っていることは至極真っ当だと思いました。

解釈間違ってたらスルーして下さい。