「オブジェクト指向」　　

基本概念と実際の適用法について教えてください。
完全初心者です。
オススメの入門書なども、ありましたら是非お願いします。

学生？何のために知りたいの？

どっちかというとプログラム板向きのスレだね。
こっちは削除依頼を出して、向こうで立てなおした方がいいかも。

>>1
あれこれ考えるより
本屋さんに行った方がいいよ。

分析などの上流と 実装技術(OOP)とでは異なってきます
言語寄りならばプログラム板向きでしょう

経験からは やはりOOPの1つや2つは修得して
オブジェクト指向のそれぞれの概念と
計算機上のデータ構造と振る舞いとを結びつけてください

概念の整理として大きな書店で実際手にとって選ぶといいと思います
1冊で これといったものはありませんから 数冊読み比べてみてください

書籍としては古典と最近のものを合わせ読むといいでしょう
言語としては Smalltalkがマニアックですが C++でもよいです
古典では Meyer、cox、Booch、ランボーなど
概念理解としては、春木良且先生の薄い本

実務指向で上流向きの本は・・・ほとんどありません
ただUML関連がdefactoですから目を通しておくといいです

みなさん、とくに>>5さん、丁寧なお答えありがとうございました。

ご迷惑をおかけしないように、さげにて失礼します。

5に賛成

で、ひとつふたつ簡単に概要を習得したくらいのレベルになったら
プログラマーに話し掛けてごらん
半分は手動かすことしか覚えてこなかった奴らだってのがわかるから
なんか聞いても議論にならないと思うよ

ということで、今プログラマー板にいくのは薦めない

>半分は手動かすことしか覚えてこなかった奴
これってつまりその言語の文法しか知らない奴とゆう
意味でしょうか。文法よりもOOPの概念のほうを学ぶのが
先って事ですか？

憂鬱なプログラマのためのオブジェクト指向開発講座
を読め！ｺﾞﾙｧ！

>8
言語理論を考えたこともなく、ただ漫然とプログラムを組んできた輩ばっかし
という意味じゃないの？

>>10
そうそう、言語理論を考えるだけのバカじゃないって意味ですよね♪

# 成果物のない輩は発言してもダメだよね♪

ooって結局_link_systemの事じゃないのかな . 違う ? .

`` 猫と洗濯機に同じ名前を付ける事ができる .
しかし猫と洗濯機わやっぱり別物 ''
って , つまり変数と関数とclass_なりを同列に扱える
って意味な気がする .
それらわ名前空間を共有していて
呼び出され方 ( 活動局面 ) も共通している .
他の板で書いたけど `` ln -s '' で
fileにも_directoryにも差別なく_linkを張れるのと同じで .

>>12
それは
OOって結局
を
現在のOOPって結局
に置き換えるのだったら可 でもってそれだとプログラム板でしょう
所詮ノイマン型コンピュータに写像実装されているのだから まあ気持ちわかるけど
(ちなみに Borlandにはオブジェクト指向アセンブラまである)
OOA、OOD、パラダイムシフト、モデル論、シームレスなどとは関係のない話では？

>>13
ふむふむ .

私わ非ノイマン型architecture_に詳しくないのが辛いな .

ただシームレスわどんなarchitecture_ででも
完全なlink_system_さえあれば実現する気がしたりしなかったり ( ? ) .
そうなるとパラダイムshift_も実現できそうな
( linkが自立して一人歩きを始める ) ( ? ) .

真の_object指向から見れば遊びみたいな程度なのかもしれんけど .

そうそう , 私わ `` OOA , OOD , モデル論 '' が何か
を分かってません .

>>14
補足 : ノイマン型architecture_においての `` 一人歩き '' わ
multi_threadにより確立する筈
( 但し_emulateと呼びたくない形でのemulate_によって ) .

ノイマン型云々を言い出すと、論理的に説明できるコード自動生成は
ノイマン型の守備範囲だと思います。

そのように考えると、非ノイマン型なるものは曖昧であり自立型であると定義することになり
現実的には開発ツールの範疇を超えてしまうはずなんです。

>>17 名無しさん＠１周年さん
>そのように考えると、非ノイマン型なるものは曖昧であり自立型であると定義することになり
>現実的には開発ツールの範疇を超えてしまうはずなんです。

そうですね . 生物の個体に薬物を投与する感覚とでも言うか .
またわ究極的にわ
そのsystem_自体を `` 一人の人間 ( 哲学的文脈での存在 ) '' として扱う
様なモノとでも言うか .

ただ , そうだとしても
programの `` 論理記述 '' わ相変わらず可能でしょうが .
小規模system
( 例えば将来の3D_video_game_のレンダリング等を
十分以上に小さい誤差範囲で超高速に近似するchip_等 )
ならばそのprogram_を一意に解釈させる事も
やり方次第で十分可能そうですし .

超大規模system_においても
一意解釈 ( またわ十分以上に小さい誤差範囲での解釈 )
の実現可能性わまだ捨て切れませんね .
これを実現できればかなりな事になりそうです .

おすすめの入門書：
所・松岡・垂水（編）
「オブジェクト指向コンピューティング」（岩波コンピュータサイエンス）
岩波書店，1993，ISBN 4-00-007706-6，4700円．

OOPSLAをECOOPの論文集読んでおけばOK

訂正：「を」→「と」

ここの奴らは、なぜ「は」と表記すべきところを、「わ」と
表記するのだ？
単なる馬鹿か？
ＯＯの前に、日本語習え。

こんにちわ。

>>22
あなたが一番の馬鹿です。

>>19-21
Thanx .

>>17
`` coding '' じゃなくて `` コード自動生成 '' だったんですか .
それわ `` 何らかのdata_を吐かせる '' という意味でしょうか ? .
もしかして `` 一意なdata_を吐かせる '' という意味 ? .
>>19-21で示されたdocument_を読めば理解できるのだろうか .

>>22
情報system_板に来ているのなら理解可能かと思いますが ,
例えば言語の設計なりをしてみれば謎わ解けますよ .
キャラ空間なり_ascii_codeとの整合性なり
unix_processとのシームレスな相互通信なりetc.
を考慮してみれば .

それに `` 「は」と表記すべき '' と言っても
それわ所詮現代仮名遣いstandard_です .

http://salad.2ch.net/test/read.cgi?bbs=future&key=982142704&st=39&to=40&nofirst=true

煽り野郎の肩を持つわけじゃないが、場所をわきまえずに方言をたれ流すのは
どうかと思う。誰だって仕事の書類で「逝ってよし」なんて２ちゃんの方言を
使ったりはしないでしょう。
このスレでやる分には良いけど、外に出たら、単なる電波者だよ。

スタンダードな処理に対応できないものを言語処理系として採用する。それ
だけならともかく、クレーム処理を「仕様です」だけで済まそうとしている
ような駄目システムと一緒だね。

プログラマの実態
　　　　　　 オマンコ、オマンコ、クリトリス〜♪
　　　　　　　　============彡川川川三三三ﾐ=============
　　　　　　＼============ |川｜川＼　　／｜==========　／
　=＼　　　　＼==========‖｜‖　◎---◎｜=========／　　　　／===
　===＼　　　　＼========川川‖　　　　3　　ヽ======／　　 　　／=====
　=====＼　　　　＼======川川　　　∴）∇（∴）=== ／　 　　　／=======
　=======＼　　　／＼===川川　 　　　　　　　　/=／＼　　　／=========
　=========＼／　　　＼川川‖　　　　　　　　/／　　　＼／===========
　==========＼　　　　　川川川川 　　　＿＿/　　　　　／=============
　============＼　　　　　　　　＼＿＿＿／　　　　　／==============
　===============＼;;;;;;;　　　　　　　　　　　　　　　／================
　================｜;;;;;;　　　　　　　　　　　　　　　ヽ================
　================｜;;;;;;　　　　　　　　　　　　　　　　ヽ==============
　================｜;;;;;;;;　　　　　　　　　　　　　　　　ヽ=============
　================｜;;;;;;;;　　　　　　　　　　　　　　　　｜============

>>18
> `` coding '' じゃなくて `` コード自動生成 '' だったんですか .
> それわ `` 何らかのdata_を吐かせる '' という意味でしょうか ? .
> もしかして `` 一意なdata_を吐かせる '' という意味 ? .
> >>19-21で示されたdocument_を読めば理解できるのだろうか .

コードの自動生成技術について特化したつもりです。
オブジェクト指向と一口にいっても、現状ではオブジェクト利用の範疇であり
コードの自動生成すら殆ど為されていないのが現状です。
勿論、インタープリタ型を自動生成と呼びたいのも理解出来るし、自動生成したコードを
自動翻訳し実行する形態が存在するのも理解出来ます。
しかし、上記の全ては論理指向の範囲でしかありません。

オブジェクト指向でもし、注意しなければいけない点があるとすれば、自製コードから出発
しないってことくらいですね。
自製コードも当該プログラムのパーツだという事を理解して置けば十分でしょう。

>>24
よみづらいので「は」きぼーん．

オブジェクト指向って、言葉はかっこいいけど、
ようは部品化でしょ。

>>29
http://www.bss-net.co.jp/
これ（↑）もそう？

>>23
いや〜馬鹿さ加減では君にはかなわないよ。
それとも、ＯＯは知らないが、知ったかぶり
したいだけで、ここにいるのか？
かわそう．．．

今GammaのDesign Patternsを読んでるんですが、読み終わっても
実践できる気がしません。ダメ人間でしょうか？

デザインパターンの本一冊よんで、いきなり実践で
パパッと使える方が不思議だと思う。
何か作ってるときに、「まてよ、このパターンを適用したら
いいような」と本を読み返して、それで使えるようになっていく。

こういうもんだと思っとるんですが

>>32
Javaのソースコード見て
「ぁ、ここはあのパターンだ！」
っての探していくと面白いよ。

名前知らなくても　singletonは誰でも使ってるんじゃない？

>>34
この辺はgamma本読む前からやってた。

FactoryMethod（インスタンスの生成方法を制限するってのはありがち）
Singleton（インスタンス数の上限を動的に決定するってのはやってました）
Command（リドゥアンドゥってこれ以外でどうやってやるの?）
Observer（コールバック関数を抽象関数一個持ってるインターフェイスで
くるんでインスタンスをvectorにしといて通知が掛かったら全部呼ぶって
やり方で自分で実装してた）
Facade（なにをいまさら）
Composite（データ構造とかでやってた）

>>32

あー言うの読んで
今まで書いたもの書きなおして見るのも面白い


…かも｡

とりあえず手を動かさなくては始まりませんね。
なんでもいいから、がしがし設計＆実装してみては？

オブジェクト指向開発に移行することを悩んでいる20名弱のソフトハウスの責任者です。
仲間の会社の方にも色々相談したのですが、２社ほど移行に挑戦したところがありまし
た。両者とも、有名どころの研修を受けコンサルをいれたけれども結果としては、オブ
ジェクト指向開発ができているといえるような成果はでておらず、オブジェクト指向を
学んだだけになってしまっているようです。
やるきのある社員の提案であるので、全面的にバックアップし、仕事に対する遣り甲斐
を与えてあげたいと思っているのですが、VB+ORACLEの開発をメインとした受託開発であ
り、しっかりとした設計は行っておらず、現在の所設計に関するスキルやセンスがかな
り不足していると私もその社員も客観的に認識しています。小さな会社でり、ビジネス
なのでお客さんに迷惑をかけることはできません。
ある知り合いの技術者に聞いたところ、受託開発でオブジェクト指向開発をうまくでき
ている所はとても少なく、うまくいっているところは一つの製品を拘りながら作りこん
でいく必要があるパッケージソフト開発をしているところであるということも聞きまし
た。なるほど、一つのものに向かい合うことで、深く学ぶ機会になると思いました。
受託開発だとリスクが高くて身に付けるのに多くの時間が必要であり、根気も続かなく
なるように思いました。
現在の所、オブジェクト指向開発を段階的に導入していこうかとか考えています。
とってくる案件も、オブジェクト指向言語を使う必要があるものにし、その言語になれ
ながらトピック的に色んなテーマを学べるような取り組みを考えています。
ただ、情報不足で踏み出す勇気または止める勇気をもてないでいます。
どうぞ、２ｃｈのみなさん。
わたしのところは、こういう風にしてうまくいったとか、こういう風にしてうまくいか
なかったとか、あきらめたとか、あきらめなくてよかったとかそういったお話を含めて
お話を聞かせていただければと思っています。
どんな情報でも構いませんので、よろしくお願いします。

VB + Oracle でオブジェクト指向ってうまくいくのかな？
オブジェクト指向の熟達者でもない限り、凄く中途半端なコードになるような
気もする。いきなりプロジェクトにオブジェクト指向を導入するのは凄い
危険だと思うなー。多分失敗してトラウマになる。

受託でオブジェクト指向バリバリって珍しくないと思うけど。
時間が足りないので使い慣れた従来の技法に頼ってしまうっていうだけじゃ
ないの？でもそれってパッケージでも一緒だよなあ。

よく言われるのは、凄い小規模のパイロットプロジェクト用意して、そこで
試験的にやってみるということ。このときに素人ばかりだと杉田玄白状態になって
絶対にスムーズに進まないので、バイトでもいいから優秀なやつを一人参加
させるといいんじゃない？

CRC カードとかでトレーニング受けれるといいんだけど、日本でそれやって
くれるところってどのくらいあるかな。ちなみに自分はオージス総研の研修を
受けたけど、凄くよかったよ。一応いろいろ要望を出せるから、CRC カード
使った体験的学習させてくれって言ってみるのも手かも。ただ 200 万かかるよ。

あ、200 万じゃなくて 160 万だった。これは講師派遣の場合ね。1999 年の
時点の値段だから変わっているかも。ちなみに受講者の総数は制限なし。

オージスで定期的にやってる研修参加なら 20 万くらい？

>>39
情報ありがとうございます。

> 受託でオブジェクト指向バリバリって珍しくないと思うけど。
anonymousさんの所ではすでに行われているようですが、研修を受けたあと
すぐにできるようになりましたか？ モデリングは熟練してこないと
なかなかうまくいかないように思うのですがそうではないのでしょうか？
すこしきもちが楽になりました。


あと、CRCカードを使った体験的学習は何日で１６０万ですか？
内容も興味があります。よかったらやってみようと思います。

>>41
もともと何人かは勝手に自己流でやっていたので、それなりにスムースに
できるようになりましたよ。誤解が一掃されたという感じかな。

なお、自分たちが受けたのは UML によるオブジェクト指向分析設計コースです。
だから純粋な意味でのオブジェクト指向の講習ではないです。CRC カードに
ついては若干触れただけです（誤解を招く書き方ですみません）。

ただ、講師派遣ならいろいろカスタマイズするよって言っていたので、CRC カードを
使った体験的学習をしたいといえば可能でしょう。ちなみに結構問題になるのが
時期です。現場でバリバリやっている人の手が空いたときに講師派遣になるので、
忙しい季節だと日程が合わない可能性があります。

160 万円は 4 日間のときの値段です。カリキュラム内容をカスタマイズした場合、
若干変動が出ると思います。

参考になれば幸いです。

なお、CRC カードについては
『オブジェクト指向プログラミング入門』Timothy Budd 著（アディソンウェスレイ）
　http://www.amazon.co.jp/exec/obidos/ASIN/4795297088
"The CRC Card Book" David Bellin ほか著 (Addison-Wesley)
　http://www.amazon.co.jp/exec/obidos/ASIN/0201895358
がよいと思います。

>>38
俺の会社は見事に失敗しました。
対外的にはオブジェクト指向開発をしているといっているけど、ただJavaを
使っているだけ。
設計とは画面設計とＤＢの設計だけだ。あとは、WebLogic上にゴリゴリと
作っている。Web系でオブジェクト指向開発は、時間ばかり掛かり、結局
やらなくなった。
Webアプリを開発している会社ってそんなもんじゃないでしょうか？
うちはちゃんとやっているゾ！という所があれば教えてください。
どの程度やっているのかとても知りたい。
大体すぐれたオブジェクト指向技術を持っている所は、教育を核にして
利用者を増やし、その利用者がつまずく所を見からってコンサルティング
を行うというモデルで業務をしているんじゃないかな。つまり、リスクを
背負った開発はやっていない。やっていても分析設計レベルだけ関わって
実装は他社に出したり下っ端にやらせるという形で優秀な人はどんどん
技術を付けていっているように思うゾ。
そういったモデルがとれない会社は、高いレベルでの技術取得は難しいと
思う。
どんどん本はでるけど、徹夜徹夜で本を読む時間も無いゾ、俺は。
みんなのところはどうよ？

このレスいつも続かないので、きっとオブジェクト開発やっている
人はすくないと思うな。
組織的に利用するには、ちょっと難しすぎると思う。
アプリケーションサーバやフレームワークを使った開発程度が限界
と思う。こういった開発でオブジェクト指向開発をしていると満足
しているところも多いかもしれない。

みなさんありがとうございました。
予想通りなかなか大変そうだなという感触を得ました。
リアルな世界でもあれこれ聞いているのですが、富士通やＮＥＣ、そして
ＩＢＭでさえもオブジェクト指向開発がまともにできているグループは一部
のようですね。それぐらい人を選ぶ開発方法論または考え方ということなの
かもしれません。
日本人は、抽象的に物事を捉えるのも苦手な人種なので難しいということを
いう人もいました。
これだけ、難しいものはそれほど長く続かないはずなのですがそれも続くと
いうことは、その代替になる考え方というのがないからかもしれません。
もう導入しやすい考え方というのが出てくることが望まれているということ
ではないでしょうか。
「自分はかなりオブジェクト指向をつかえている」という方に伺いたいの
ですが、貴殿の周りはどうでしょうか？同じレベルで使えているでしょうか？
組織の中で何名か優秀な人がいて、そういった人がどんどん新しいことをみに
つけツールとして使えるようになるのは珍しいことではありませんし、同様に
そういった人以外はかなり稚拙なレベルでしか使えないという状況も珍しく
ないように思います。
私の会社でも同じような状況が起きています。２：８の法則ではありませんが、
そういった割合で優秀な技術者とそうでない技術者にわかれてしまっています。
悲しい現実です。何とかし抜け出したい。そう思う今日この頃です。

例えば今日は UML Forum のような催しものがあったけど、そういうところへ
顔を出してる？ああいうところで講師をやっている人に直接話を聞いてみたら
いいと思うよ。割と正直に答えてくれるよ。オブジェクト指向を使ってはいけない
ケースとかね。
次の類似の催し物なら 5 月のオージスの ObjectDay がいいんじゃないかな。

あと自分のまわりは結構オブジェクト指向バリバリだよ。
つうか自分はやつらに比べれば厨房レベル。(^^;
でもここの流れを見る限り、珍しい環境みたいだね。

ところで何で OO って話なの？
社内でやってみたいって人がいるなら、比較的小さくて仕様が明確な案件を
使って実験的にやってみるってのでいいと思うけど？。全社的に OO を普及
させたいって意図がいまいちよく分からないなあ。

優秀な人間とそうでない人間に差がつくのは当然だし、つかないほうが
おかしいと思うから、それを心配しても意味がないと思う。

もし OO をマスターすれば技術者のレベルが上がるって期待しているなら、
それは明らかに幻想だよ。銀の弾丸じゃない。

優秀な人は構造化でも DOA でも、問題ドメインと解決ドメインに適した技法を
使って仕事をする。例えば分かりやすい例でいえば、レガシーシステム上の
COBOL アプリをどうこうするのに OO 使えって人は明らかに分かってない人。

しょせん道具にすぎない。車を自分で運転しなくてもタクシー
やあるいは電車に乗ればよい。気にしなくてヨシ！

OOA/OODって堅苦しく考えなくても、Unified Processの

ユースケースによる要件定義
リスクドリブンなプロジェクト運営
インクリメンタルな開発

といった要素は比較的素直に取り入れることができると思います。

で、特に「インクリメンタルな開発」を有効にすすめるためには、
OOベースでの開発がもっとも適していることがわかると思います。

>使って仕事をする。例えば分かりやすい例でいえば、レガシーシステム上の
COBOL アプリをどうこうするのに OO 使えって人は明らかに分かってない人。

それはどうですかね。Webベースのアプリからレガシーシステムの機能
を利用するなんて場合を想定すると、レガシーシステムをラッピング
してコンポーネント化するアプローチも有効ではないですか？

そういう場合は OO でもいいよね。
でも場合を考えずに一般解として主張する人を見てると痛い。

>>46

|オブジェクト指向バリバリ
とありますが、何がどうできるとバリバリになりますか？

anonymousさんの会社では、どういったシステムを開発していますか？
もし可能でしたら可能な限り具体的に教えてください。
どういった分野に向くのか生の声を聞きたいです。

> 何がどうできるとバリバリになりますか？
・説明を聞くとすぐにクラス図とコラボレーション図が出てくる。その後の修正も
　少ない。
・まずインターフェースから設計をはじめる。
・クラス設計が責務単位できちんとまとめられているので、カプセル化がきちんと
　できており、クラス間のコミュニケーションがそれほど複雑にならない。
　# OOSE 風に言えば、Boundary/Control/Entity の識別がきちんとできている。
・ちょっと難しそうな設計でも、デザインパターン駆使してすっきりと仕上げる。
・全体の見通しが悪くなってくると、リファクタリングで見通しよくする。
という感じかな？全部できるやつはさすがに一人しかいないけど、だいたい上記の
半分以上のスキルは持っている。

> どういったシステムを開発していますか？
今やっているやつだとグループウェアみたいなやつ。具体的に書くと身元が
ばれるので勘弁して。
あとは、某金融系企業のためのシミュレータとか、ネットワーク管理ツールとか
かな。あと某特定業種向け販売管理パッケージも。
Web ベースの進捗管理システムみたいなものも作ったけど、これはあまり OO 度が
高くなかったなあ・・。

というかさ、ここを購読して聞いてみれば？
みんな実名で親切に答えてくれるよ。
http://www.ogis-ri.co.jp/otc/hiroba/MailingList/index.html

ちなみに OO 入れたいけどまわりの意識が・・という相談が以前出ていたよ。
http://www.ogis-ri.co.jp/otc/hiroba/MailingList/digest/index.html
のダイジェストの 1589 から始まるスレッド参照。

自慢野郎
氏ね
うざい

>51,52
anonymousさんありがとうございます。
とても参考になりました。紹介してくださったMLにも入ってみます。
もしよかったら、「まずインターフェースからはじめる」というのは
どういうことなのか教えてください。
どういう段階で何のインターフェースからはじめるのですか？
また、それはなぜですか？ （インターフェースから入らない場合と
くらべて、どういったメリットがあるのですか？）

あと、「説明を聞くとクラス図やコラボレーション図がすぐ出てくる。
その後の修正も少ない」とありますが、説明とはなんの説明ですか？
＃なんにしろ、すぐに出てきて修正が少ないというのはすごいですね。

>47

比喩がうまく理解できないのですが、
・オブジェクト指向はツールである
・アカデミックなレベルの理解など必要がなく、そこそこフレームワークや
アプリケーションサーバが使えればそれでよい
ということですか？

これで最後ね。煽られちゃうから。

> インターフェース
要は継承に対するスタンスの問題。通常継承といえば実装継承で、これは実装も
含めて親クラスの性質を引き継ぐ。それに対して、仕様の継承というのが最近の
トレンドで、仕様（公開メソッドのシグネチャ）だけを共通にして実装はそれぞれ
独立に行う。なんで実装継承を嫌うかというと、実装継承は、親クラスの変更のコストが
大きくて、子クラスの拡張内容によっては親クラスの修正を事実上不可能にする場合も
出てくるから。さらに、公開メソッドが共通ならば、呼び出す側のコードを変更する
必要は一切無く、変更を局所化できる。要するに実装の自由度を高めたい、だけど変更を
局所化したいという要望を実現するのが目的。

インターフェース主導設計については
『UML による Java オブジェクト設計』P.Coad 著（翔泳社）
が一番いいと思う。自分はこれで開眼した（つもりになってる）。

> 説明
顧客の要望のこと。頭の中でユースケースとシナリオに変換して、サクっとクラス
候補を抽出するんだよね。
ちなみに今日の UML フォーラムで、クラスの発見の仕方について講師の一人が
「名詞抽出法とか動詞抽出法とかいろいろ言うけど、実際には使わない。
それより感覚的に決めることが多いなあ」と言っていたのが印象的だった。

ちなみに一番できるやつが実は一番変更が多かったりする。
それは何でかというと、とりあえず書いてみて動かして、ちょっと複雑に
なってきたらリファクタリングをして、また書き足して・・を繰り返すから。
だから修正は多分一番多いけど、最終的に出来上がったものはほれぼれする。
cf. 『リファクタリング』Martin Fowler 著（ピアソン・星雲社）

変更が少ないから良いってことではないと思う。
むしろ理想はどんなに変更が入ってもそれに対応できることだよね。
XP 的理想象だなあ。
# 修正が少ないのは仕様が割と最初から明確だったという要因もあるなあ。

>>56
とてもうまくさくさくやっているように書かれていますが、
要望から頭の中でユースケース図やユースケースシナリオを記述できる
ということから、とても単純なシステムしか関わられているのでは
ないかと想像します。
オブジェクト指向開発もまだ成熟しきれていないし、教育の仕方や
学び方も模索されている段階です。
真摯に向かい合っているならば、現在anonymousさんが抱えている
問題についても言及されるべきです。何も問題なくうまくできている
という認識レベルであるならば、次のステップに上がるチャンスと
思いますので、チームで内省されステップアップに繋げてみては
どうでしょうか。慢心するとろくなことにはなりません．世の中
上にはうえがいますよ。

>>58
> 上にはうえがいますよ
それはすごくわかってる。豆蔵の人とか、インアルカディアの人とかと話すと
自分らなんてまだまだだなーってよく分かる。SOP/AOP とか MPP とかまだまだ
学ぶべきことも非常に多い。MDA なんて新しい概念も出てきているし、コンポーネント
関連の技法はまだまだ発展途上でこれまら学ぶべきことが多い。

だけど、そもそもの質問って「オブジェクト指向で分析・設計・実装できている
会社って本当にあるの？」だと思うので「あるよ」って回答したんだけど、
それはまずかった？

ちなみに今抱えている問題点ねえ・・・・。

どちらかといえば、オブジェクト指向というより、要求分析だろうね。
つまり要求の変化に耐えるモデリングをどれだけきちんとできるかってこと。
この辺は結構まだまだ甘いよね。

あと RDBMS を使うときのインピーダンスミスマッチなんかは古くて新しい問題。
どうしても Object-RDBMS Wrapper かますと性能が悪くなるよね。
応答性能が重要なシステムだと泣く泣く非オブジェクト指向的な設計をする
こともあるなあ。

ああ、あとクラス群を適切な粒度のパッケージに分割するための方法がいまいち
分かってないなあ。うまく分担するには、システム全体を、一人が面倒見きれる
くらいの大きさのパッケージに分割して、パッケージ間のインターフェースだけ
決めてあとは好きにやらせるってのが経験則からは一番いいんだけど（創意
工夫できる人にはあまり決めてあげない方がやる気が出る）、これを適切に
行う一般的な方法がわからんなあ。

XP の Test First 的なコーディングもまだ身についてないのも問題だね。

Metrics の取り方が良く分からないってのも問題点に含めていいかな。

規模に関していえば、大きくても 200 クラス程度だから、小規模なのは
多分そうだろうと思う。

>「名詞抽出法とか動詞抽出法とかいろいろ言うけど、実際には使わない。
それより感覚的に決めることが多いなあ」と言っていたのが印象的だった。

慣れないうちは、名詞抽出法を使ってみるのも有効なアプローチだと思います。
もっとも業務知識のある人であれば、OOに精通していなくてもビジネスオブ
ジェクトの候補が思い浮かぶと思いますが...

OOで失敗する原因で多いのは、すぐにクラス図を書こうとすること。実際システム
の設計を考える場合、要求された機能をどのように実現するかを考えるべきで、
それを端的に表現できるのはイベントトレース図やコラボレーション図です。

>要望から頭の中でユースケース図やユースケースシナリオを記述できる
ということから、とても単純なシステムしか関わられているのでは
ないかと想像します。

ユースケースに関していえば、顧客の要望から考え付くのはそれほど難しいこと
ではないと思います。というか、従来の要求分析とやっていることはさほど変わ
らない、と私は感じるのですが...

それ以外にもいろいろ問題はあるけど、でも根本的に「オブジェクト指向分析・開発で
問題なし」って確信があって、問題があってもそれらはやがて解決されるって楽観的な
気持ちがあるからあんまり気にしてないってのが現状だね。

言い換えると、オブジェクト指向だからこんな苦労をする羽目に・・とか、
オブジェクト指向はワケがわからん、役立たずみたいな感情は今まで一度も
持ったことがない。だから OK! OK! みたいな書き込みになってしまう。

上には上があるのはよく分かっているけど、逆に上があることで今自分たちが
やっている方向性には間違いがないんだってことが分かるって側面も
あるのかも。

>>58
結構あなたのところでもやってるの？
大きな業務システムって手がけたことがないから（何せ小さいところだからね）、
その辺の経験聞かせてもらえるとありがたいなあ。

>>61
> 失敗する原因で多いのは、すぐにクラス図を書こうとすること
そうそう、そうだよね。クラスをどう定義するかなんてそれこそ無限のバリエーションが
あるわけで、コンテキストを常に考えて責務を定義しないと凄く危険だよね。その意味で
ユースケースとシーケンス・コラボレーション図をラフでもいいからスケッチすることは
非常に重要だと思う。煮詰まったら「それでシナリオは何だっけ？」と見返すことが
結構ブレークスルーになったりするし。

自分的にはクラス図は最後でいい、って感じだなあ。クラス図にしても、変更を局所化
するために実装継承でなく仕様継承を使うやり方だと、実はインターフェースだけ
きちんと書けてればいいよね。

ユースケースに関していえば、粒度をどうする？って問題もあるけど、多分 >>58 さんは
それこそ基幹系といった大規模（数百万ステップ）システムを考えているんじゃないかな？
そういう状況だと多分ユースケースも凄い数になるんじゃない？
そういう世界は見たことがないなあ。

>>63
いっている事矛盾してない？
「説明からすぐにクラス図が作れ、修正がすくない」といいながら、
クラス図は最後でよいといってみたり。それだけ現実ではリスキーなシステム
を扱っていないということだと思います。
どういったシステムを扱うかによってオブジェクト指向に対する関わり
や自分自身のなかにできるメンタルモデルは変わってくるので、もう少し
考えを整理されると、説得力がでてくるのではないかと思います。
がんばってください。

ううむ、確かに矛盾してますなあ。というか複数人の印象がごっちゃになって
いるのでいろいろおかしくなってきているよなあ。私のことを言えば、最初に
かなり時間をかけてモデリングするし、さくっと作ってリファクタリングの
人間もいるし、小規模や既に経験があるならさくっとモデリングしてそのまんま
ゴールというパターンもあるし・・・って感じだなあ。正確に書くと。

> 現実ではリスキーなシステムを扱っていないということだと思います。
そうかもしれないなあ、と思ってきた。できることだけやっているのかも
しれない。

いまいち整理しきれてないので、出直してきますわ。

1
オブジェクト指向？
死んだにきまっているじゃないか

これからはコンポーネント指向だろ
何を今更議論しているんだ

65
ハッカー気取りのガキは不要
板を汚すな

>>ハッカー気取りのガキは不要
うむ、きみがガキだな。

>>66
CBOP の関係者？

漏れがオブジェクト指向に出会ったのはもう１０数年前。
X−WindowV11R2にｻﾝﾌﾟﾙ的についてた「X　Tool　Kit」
68020のﾜｰｸｽﾃｰｼｮﾝがはやってた頃。PCはDOS、FDベース
80286だった頃。あるプロジェクトで、PG上がりbit愛読兄貴SEを
使ってＸ上でｸﾞﾙｰﾌﾟウェアもどきを作るという野心的ﾌﾟﾛｼﾞｪｸﾄ。

何しろWidget（Window　Object)についてのどーみてもｿｰｽから
起こしたようなわけわからん英語ﾄﾞｷｭﾒﾝﾄがたより。さんざん調べた
が、すぐX11R3が出る。ところが
・日本語ＦＥＰ（WindowsのIMEみたい出るなもの）がXTK対応のものがない。
・ﾒﾓﾘﾘｰｸなどバグ多し。メモリも食う、おしょいで×
このころUNIX　Magajinで連載が始まる。結局オムロンのｗｎｎ
（XjpLIb）を使い、ｲﾍﾞﾝﾄドリブンXlibでがりがりｺｰﾃﾞｨﾝｸ
したのでした。（続く）ﾞ

>>69
そういう人は多い。自慢するほどではない。
自分でオリジナルのWidgetを作ったことがある人は、オブジェクト
指向言語も実感できたはず。

>>69

誰もヘッポココーダの話なんか聞きたくねぇよ

＞Unix Magajin
うにっくす・まがぃぃん？（´д｀；

オブジェクト指向開発は

・クラス設計する人
・そのクラスを使う人

に分けて、クラス設計する人が優秀ならばうまくいく。
そんな人は、規模にもよるが数人でOK。
そんな人にはクラスを使う人の10倍くらいの給料あげてもいいんじゃないかな。
ヘタすりゃ使うだけの人の100倍以上の価値くらいあるし。（数字はテキトウ）

>>72
うまくいくとは限らないよ。
APチームは、フレームワークチームに対して劣等感を感じ
フレームワークチームは、APチームに優越感を持つ。
そういった気持ちが起きないように、取り計らうのはとても大変。
APチームとフレームワークチームできれいに2:8の法則が起きてしまう。
72さんは、オブジェクト指向開発のまともな実務経験ないのでは？

>>73
よいご経験をお持ちで。

実際は、フレームワークは上司、APは部下という関係がよかったり...
しないか...

>>73

確かに大規模なオブジェクト指向開発ってのは無いですね。
私がクラス設計して、後輩にはそれを使わせつつ勉強させてますけど、所詮数人って規模だからなぁ。
でもオブジェクト指向開発プログラマこそ2：8とか2：6：2が見事に当てはまるんじゃないかな。
もっともその2にあてはまる人こそがオブジェクト指向プログラマなのであって、あとはオブジェクトを
使うプログラマでしょう。なんつったりして。

>>73
要するに､バカのくせにプライドの高い奴が能力に不相応な
競争意識もって他人の足を引っ張るってことか。

…メンバーの心理のコントロールの方が、実装自体より100倍
難しいってことだな。自分をわきまえないバカは逝ってよし
という事でもあるが。

フレームワーク側が元バカCOBOLER上司でやってるよりは、
ちゃんとモノができるだけずっとマシ。今の仕事がちょうど
その状態。ヒー！

>>73
使う側使われる側の上下の問題ではないと思う。
手抜きの設計のものを使うときは設計者以上の能力を
必要とする。
またどれだけ丁寧なものを実装者にリリースしても、何も考えないで使われると宝のもちぐされとなりかねない
まあたいていは、
・設計-->ＡＰ　…　気を使う
・ＡＰ-->設計　…　気を使って質問
・設計-->ＡＰ　…　つかれててうまく答えられない
・ＡＰ-->設計　…　つかれててうまく聞けない
・開発効率が落ちる
　ってとこ

>>78
その通り。
ＡＰにはＡＰのドメイン知識に対する誇りがある。
私のところでは、ＡＰは割と年配がなった。顧客の所にもいかないと
いけないし、ドメイン知識を身に付けるのもオブジェクト指向同様に
難しい。
互いにプライドがあるから、プロダクトマネージャーがどれだけうまく
両者のコミュニケーションを促しよい関係を構築できるかが決め手と
なった。
チームで開発する場合、オブジェクト指向のスキルなんかよりも人間系
がとても重要。

>>77

そうではない。馬鹿とかアホとかそういう単純なことだけではなかった。
ただ、オブジェクト指向という考え方は、それがうまくできるとなぜか
優位に立ったような、開眼したようなそんな錯覚がおきやすい。
ＡＰチームはドメインにフォーカスしているので、なかなかそんな状態
にはならないが、フレームワークを開発しているメンバはその状態に
なりやすい。そして、そういう状態になると、互いの使う言語が変わって
くる。それにより、会話がうまくいかなくなり、ぎくしゃくしてくる。
数名でやるような開発の場合は、そこまで気にする必要はない、十名
を越えるような場合で、ＡＰと設計にわけるような場合は、
とにかくコミュニケーションを促す工夫をあれこれと開発プロセスに
織り込むことが大切という実感をもっている。

オブジェクト指向プログラマ：オブジェクト使用プログラマ
＝２：８

>>81
OMG/MDA による自動プログラミングが普及 -> 8 は死去
2:0 へ

>>82
そんな極端なことありえない。
XPだ！パターンだ！と踊らされていないで、どんどんプログラムを
書くべし。
日本人は、パターンだとか言わなくても良い建築物を作ったじゃないか。
とにかくこだわりながら作るということができない、この業界の現状が
今の米国になめられ、踊らされるはめになっている。
また、それを煽る外タレかぶれのインテリ技術者がいるのがまたまずい。
このインテリ達は、自分の頭のよさをひきらかせたいだけ。しかし、その
実態は英語が読めるただそれだけだ。
英語が読めずに不安な技術者よ、まずは英語が読めるようになるのじゃ。
そうすると、ぐっと外タレも外タレかぶれのインテリ技術者を拝むことも
なくなるはずだ！！
とにかくプログラムをこだわりながら書かないとだめだ。
プログラムが好きでこの仕事をはじめた人が多いはず。今それを思い出し、
今の会社でそれが無理ならば転職するのだ！！
楽しくない仕事はおかしい。おかしすぎる。そんな状態でよいシステム
なんてつくれない。楽しめる環境を探すことがなによりも大切だ。
がんばれ日本の技術者。

／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|　ワタクシハ　モウシ゛タ゛イオクレテ゛アルト・・・
＼
　 ￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　 　　　●　　　∧ ∧ ＜　　仕方ないでしょ！！
　　　＜■＞　(ﾟДﾟ；)　　＼＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣ （つ＿つ＿＿
￣￣￣日∇￣＼| BIBLO |＼
　　　 　 　￣　　　=======　　＼

>>82
建築技法と最近のソフトウェア開発技法を同一視するジジイは
引退しろ。あんたの時代は終わってます。

ソフトウェアはもっと金をかけずに！短期間に！より高度な！システム
を造る羽目にどんどんなる（勘弁して欲しいが、仕方ないこと）ので、
やり方を変えない限り適応は無理。20年前の、定型でなんか書いてりゃ
高い金取れた奴の感覚で語るな。

>>85
どのあたりが同一視しているか指摘してください。
日本人は、良い建築物を作れたので、ソフトも拘ればよいものが
作れるといっているだけです。
また、あなたは、パターンが建築家のアレクサンダーと関係する
ことをご存知ですか？ ものを作るということにおいて共通の
部分は存在します。
また、私は４３歳ですが、現役でオブジェクト指向開発をして
いますので、あなたがいくつかわかりませんが、気持ちもわかります。
私の言いたいのは、短期で高度なシステムを作らないいけない時代に
なっているが、そういった日々に終われると、海外からくる技術に
踊らされ日本らしいソフトやシステムを作る機会なく歳を取る
開発者がそこらじゅうにあふれることを悲観してのことです。
そのことをご理解いただきたいと思います。

>86さん
建築家のアレクサンダーさんとパターンの関係について
お話いただけませんか？すごく興味があります。

86さんはどうなのかわかりませんが、オブジェクト指向開発を
しているというのは、実はオブジェクト指向言語を用いた開発
であって、中身は手続きというのが実態であることが多いと
思います。

あと、日本らしいソフトやシステムって何ですか？

>>87
(↓）これを呼んでみてください。
http://www.kajima-publishing.co.jp/isbn/isbn4306043061.html

>86さんはどうなのかわかりませんが、オブジェクト指向開発を
>しているというのは、実はオブジェクト指向言語を用いた開発
>であって、中身は手続きというのが実態であることが多いと
>思います。
だからどうしたんですか？ そうかもしれないし、そうでないかも
しれない。

あなたにとって、日本らしい建築とはなんですか？
あなたにとって、日本らしい生活とはなんですか？
日本らしいこれらのものは、住みやすかったりすごしやすかったり
しませんか？
今あなたが使っている海外で作られてたソフトを使っていて
いきいきしていますか？
今あなたが作っているシステムは、顧客の仕事をいきいきさせ
ていますか？
もうし、いきいきさせていないのであれば、それが可能なよう
なものを考えていく価値はないでしょうか？
あるとすると、それが日本らしいソフトであったりシステムで
あったりと言いたいのです。そういう願いです。
技術者として、良いものを拘って作る環境が与えられないため
知的好奇心を満足させることに毎日時間を使ってはいないでしょうか？
システムに関わるひとをいきいきさせるために、システムを作る
ということを、上記の本を読むことで気がつくかもしれませんので
是非読んでみてください。ただ、読むのは苦労します。

>>83
すこしばかり言っていることわかる部分もある。
特に、オブジェクト系のMLは、権威者（グル）の発言の紹介で
終わっている場合が多い。
まあ、本を読んだり論文をWebサーフィンするだけで一日が
あっというまに終わってしまうので、自分の考えを構築する
時間がないのはわかる。俺も英語できないけど、読むだけで
できたら現状のMLに入っている価値はそれほどないな。
議論を徹底的にして高めていくという姿勢がないもの日本の
技術者（実務家）には。
OOスクエアもひどかったので辞めた。XPもやめた。ここは常連
の仲良しクラブで宗教的な感じが肌に合わない。
入っているのはSMLぐらいだ。SMLはいいよ。
いいといっても青木さんだけだけど。批判ばかりするやつが一人いる
のが気に入れない。（w

>>85
> 建築技法と最近のソフトウェア開発技法を同一視するジジイは
> 引退しろ。あんたの時代は終わってます。

最近ソフトウェアアーキテクチャなんてのが流行ってて、これが建築技術の
流用だなんてことは、85は全然知らないんだろうな…合掌。

>>
90
「最近」なんて書くところをみるとおまえもたいしたことないな。
しったかぶりするんじゃね。ガルゥ

>>91
流行ってんのは最近じゃん。
コンポーネントて概念だって60年代からあるけど、流行り始めたのは90年代
入ってからだよね。

>>92
あほ。逝ってよし。

>>93
へい。逝ってきます。

で、逝くついでになんであほ呼ばわりされたのか教えてｹﾛ。

94＝95≠93でした。マジで逝ってきます。

>>92
1960年代末にやっと、コンピューティング環境における重要な発明、
タイムシェアリングが出てきたわけで、共通認識としての
コンポーネントという概念がその当時一般化していたということは
ないと思いますよ。
アーキテクチャーというのは、オブジェクト指向とは別物で、
よいよいものを作りたいと考え出したあたりから意識され始めたもの
です。日本の受託開発においては、未だにC/Sといった大きな単位ぐら
でしかアーキテクチャーというのを意識した開発は行われていない場合が多いですが
パッケージシステムを開発しているSDやっていた当時から多い。
受託開発でそういったことができていないのは、拘るだけの時間がつくれ
ないことにつきると思う。日本人は本来はアーキテクチャーに拘ることに
長けている。
別の話では、IBMはアーキテクトという職種が1970年代から存在している。

>>89
Mr.Aokiのような「俺はプログラマーだ」いうかっこいいプログラマになりたいっす。Mr.Aokiの名刺には、プログラマーと書いているらしいが
本当ですか？ かっこよすぎる。
XPとかパターンとかいって騒いでいる人たちが哀れに見えるぐらい、かっこいいし、すごい魅力をかんじる。いかすなぁ

>>97
> 1960年代末にやっと、コンピューティング環境における重要な発明、
> タイムシェアリングが出てきたわけで、共通認識としての
> コンポーネントという概念がその当時一般化していたということは
> ないと思いますよ。

いえ、コンポーネント(ソフトウェア部品)が扱われている最古の論文は
1967年です。surveyしたとき、Referenceを追ってくとこれが最古でした。
さすがにオリジナルは入手できませんでしたが。確かアメリカの軍事関係
の研究所が出所だったと思います。(うろ覚え)

もちろん当時はコンポーネントとオブジェクト指向は縁もゆかりもない
概念でしたが。

> アーキテクチャーというのは、オブジェクト指向とは別物で、
> よいよいものを作りたいと考え出したあたりから意識され始めたもの

私はアーキテクチャとオブジェクト指向を絡めて話を展開したことは一度
ないですが…まぁ、「オブジェクト指向」スレだし、仕方ないですかね。
おっしゃる事は最もですが、近年では、アーキテクチャをコンポーネント
を構築する枠組みとして捉える向きが多いですよね。そうすると、現在の
ソフトウェア工学においては強ち無関係とも言い難いと思います。

> 別の話では、IBMはアーキテクトという職種が1970年代から存在している。

これはそうかもしれません。そう言う話は聞いたことあります。

>>98
まっ、XPとかパターンとか言っている会社とか、そういう人は、作りたいものが
あるわけではなく、作るというその行為自体に関心があるだけだからね。悪く言えば、ビジネス。
Mr.Aokiさんは、純粋にプログラミングが好きであり、よいものを作りたいという気持ち
が前面にでていて、そこが共感できたり、好感を持てるところではないだろか。

>>100
未だに、プログラミング修行中といっているね。かっこいいね。
日本のプログラマの地位をあげなくっちゃいけないね。
俺の会社は小さな会社だけど、プログラマからSEへの変な昇進というか
昇格はないよ。プログラマとして極めていける環境です。
入社して１年目とかにSEになる会社ってあるけど、だめだよねそんな
会社。俺は、就職の時にプログラマを大切にしていくれるところを探して
今のところにたどり着いたよ。社長は青木さんの知人だよ。

人に役立つものを作って、その喜んでいる姿をみることで、また作ろう
といういう気持ちになれるような会社であることがとても大切ですね。
IPOにより多額のお金を手に入れるための会社が増えているのはとても
問題と思います。
最近は、オブジェクト指向技術を持った技術者だけを集めた会社という
のがいくつか出てきていますが、これは面白い現象ですね。
大体組織の中でオブジェクト指向技術をマスターしてまともに使える
ひとというのは、このスレッドにあるように２：８の法則または1:9以下になってしまい、
その結果優秀な人が埋もれてしまったりやりがいを無くす。そういう人を
集めて会社を作ろうという考えはとても理にかなっている。
ただ、創造的な活動の中ではじめてやりがいをえられたり生き生きできたり
するので、その会社に入った人たちが生き生きできるかというとまた別だと
思います。当面は、IPOを目指してがんばれるけど、IPO後はまた、優秀な人
は別の道を歩き出すことになるのではないかと見ています。
社会へ貢献していると実感できない職場でないと、アカデミシャン以外は
やりがいをだんだんなくしていくものではないかと、今までの経験で思います。
技術者としてどこにやりがいを見出すかはそれぞれ違うと思いますが、
結局のところ創造的な作業の中で社会への貢献や表現ができるところに
落ち着いていくのではないかと思います。

>>100
青木さんが、XPはいいぞと発言したらXPをはじめましょう。
それまでは、XPerに翻弄されることなく、プログラミング技術の研鑚につとめるべし！ (w

>>102
優秀はシェアウェアやフリーソフト作家だけを集めた会社のほうが、もっといいかも。(w

>>102
2:8の法則だと、優秀な人を集めても、その中で再度2:8の割合で優秀な人とそうでない人が出来るので、ＯジスとかTiエスと同じような状況になったりして。
オブジェクト指向がうまくいっているような会社も蓋をあけると数名優秀な人がいるだけの会社っておおいよね。 >>104 はいいかもね。

>>102
そういえば、会社に入ってからプログラミング嫌になったなあ。
俺も転職しようかな。
>>104
まとめるのが大変そう。

俺にとって、オブジェクト指向って、つまんないサラリーマン生活の中
で唯一の自己アピールできる手段かもしれないな。優越感を得るために
雑誌やＭＬをむさぼるように読んでいる。その結果、仕事以外で
プログラム書かなくなった。だって、情報多すぎるじゃん。
やっぱやばいのかな。

>>106
言える。システム屋さんとの会話って、知識較べになるので疲れる。
ＭＬにはいって、芸能ネタ好きな人に情報集めてもらってそれをＲＯＭし適当な会話に
困らないようにしておき、
自分はプログラミングスキル向上に時間を作ればそれでよし。
Mr.AOKIに続こう！！！

>>98
青木さんの『Smalltalk イディオム』は名著だと思う。あれには感激した。
SE 集団の中で「私はプログラマーです」といえる人って、自分に凄く自信が
ある傾向があるのは凄く同意。結構 Smalltalker が多いよねえ。

>>100
んなこたあないぞ。結構好きでパターン作っている人はいないわけじゃあない。
ただ全体でみたら確かにとても少ないかもなあ・・・。
まあ反論するわけではなくて、それが全体じゃないってことで。

>>105
結局鶏口となるとも牛後となるなかれ、ってことだよね。

ん？ということは 2ch のへたれ板でリーダーになるのもいいってことか？（虐

>>107
そうだね、知識より能力だよね。
XP をいくら知ってたって、能力がないとあれは実践できないしなあ。
# でも Test First は確かに楽しかった。

>>108
レスありがとう。

＞そうだね、知識より能力だよね。
これ、本当に凄く感じるんです。
知識といってもその「情報」というレベルです。
「何々というオープンソースのバージョンあがった」といったレベルとか
「マーチンがこういった」とか、そういう記憶力命の人って、私の仕事を
している周りとても多いのです。情報を少し早く知っていることが優秀と
いう雰囲気ないですか？ こういう錯覚に陥ると、時間はいくらあっても
たりないとおもうんだよな。

>>102
それは同感なんだけど、じゃあなんで XP/Pattern がダメなの？なぜ日本的？
ナショナリズムですか？

なんか手段と目的を取り違えているような気がするなあ。
あなたが批判の対象としている人たちと同じでね。

XP にしろ Pattern Language にしろ、それは先人の知恵であり、いいものを
作るための手段でしょ。
先人の知恵だから、無視せずに一応知っておくのは有益なんじゃないの？
手段だから、あくまでツールキットであって、それを使うことが成功を保証する
わけじゃないし、目的になることもないでしょ。

それからこれらは宗教の教義じゃないから、全部言われているとおりにやる
必然性はない。「今作っているものを良くするのにどれだけ役に立つか？」という
基準で取捨選択するもの。いいものを作るのに xx のパターンがいいとか、
XP の xx なプラクティスが役に立つって使い方をするのがまさに本来の姿だと
思うけどなあ。さらに誰もが全部実践できるほど能力があるわけじゃないし。

以上が誤解で、XP/Pattern で思考停止せずに「もっといいツールキットはないか」って
考えろって意味なら大いに同意。そうでなくて単なるアンチなら、それは目的と手段を
勘違いして目的に関係ないこと、能力を超えたことをしているからだって思う。

>>99
そりはむしろアーキテクチャっていうよりフレームワークじゃないか？
アーキテクチャって設計方針とかそういう感じでしょ？
まあ言葉遊びの範疇かもしれないけど。

>>109
知識については大いに同意。賞味期限が 1 ヶ月もないようなことを覚えるのは
もったいないよね。所有欲が強いのかな？（身に覚えあり）

マーチンって Martin Fowler のことかな？
Fowler だったらそれはよく分かる。やっぱ凄く頭いいもの、あの人。
経験豊富だし、現場のことを分かっているし。
"Analysis Paterns" を読むと、これにかぶれる人が出てくるもの分かる。
あのモデリングを見てしまうと、自分が今まで作ったいかなるモデルも
ダメに見えてくるから。まあ精神的に奴隷になっちゃうんだろうね。

でもそれを他人に押し付けちゃダメだよねえ。そこからさらに前進しないと。

ちょっと >>88 の気持ちがわかった。奴隷になるくらいなら、知らない方が
いいかもね。

>>110
XP/Patterに対してアンチの立場をとっている訳ではありません。
おっしゃるように良いものは取り入れるのが良いと思っています。
問題にしているのは、そういったものに翻弄されるだけ終わっている
人が多いのではないかということです。
自分が拘っているなかで、良いものや良い考えに出会うことはとても
意義のあることであるし、よりよい形に高めて行く輪の中に入る事も
可能になると思います。
しかし、自分がものを作るという活動に対して拘っていないと、輪の
中に入ることもできず、その輪の中の情報を知ることで一生終わって
しまうような状況になってしまうのではないかと思っています。
スタンスの違いで、大きく将来が左右されます。私はかつてＩ社で
努めていて、米国からの情報を一番に知る立場にいました。そして
それを知る立場にいたというだけで、それなりの地位を得ました。
しかし、段々わびしくなり、退職し今にいたります。
そういった中でのお話をしたいと思っていたのですが、文章力が
十分でないこともあるし、大きなお節介な部分もあるかと思います。
しかし、何人かの人の心に響けばよいなと思っています。そう思う
のは、私の勤めている周りの会社にとても多くの翻弄されていたり
システム開発に遣り甲斐をなくし、精神的にも健康面でも不健康な
状態にある人が多いからです。
日本は、ソフトウェア技術力が低くなったといわれて久しいですが
本来は、ものを作るのがとてもうまい国民であると思っています。
先祖達の大業を振り返り、これからのシステム開発への関わりを
自信をもって関わって欲しいとそういった人たちいつも思います。
そういった気持ちをついついぶつけてしまいました。
失礼がありましたら、お詫びします。申し訳ありません。
ただ、若く頭の良い先端をいっている技術者の知識にあこがれるのでは
なく、ものを作れている人にあこがれて欲しいという気持ちはうそでは
ありませんし、そういった関わりの中で自分の生きがいになっていく
と思っています。まさしく今の私がそうだからです。
色々と偉そうに書いてしまってすみません。

>>113
すごく共感するよ。ただ、今の環境から飛び出す勇気がないし、そもそも
どこに飛び出せばよいかもわからない。そういう良い環境を提供してくれる
会社ってあるのかな。あれば変わりたいな。少しでも楽をするために、先端
の技術を身に付けているところ僕はあるな。知識や情報が豊富だと、良いはからいを
してもらえるんだもん。

>>111
このスレの空気からして受け売りだけの知識ヲタと言われそうだけど、手
元にあった本から抜粋。アカデミシャンなので許して。

The software architecture of a program or comupting system is the
structure or structures of the system, which comprise software
components, the externally visible properties of those components
and the relationship among them. (Bass et al, 1998)


個人的には、フレームワークはアーキテクチャの１つの実現形っちゅーか
なんちゅーか、そういうイメージで捉えてます。もちろん全てのアーキテ
クチャがフレームワークにできるわけじゃないだろうけど。

青木さんは、参考文献に「空海全集」を挙げたり釈迦の説法とか
出てくるのがびびった。
いろんな意味で只者ではないようですね。

＞好々爺さん
本の紹介ありがとうございます。
本音をいうと、このパターンは建築でいうこれにあたり、云々、、
ってのが聴きたかったのですが、それは本を読んで自分で掴むもの
なのだということですね。

ところで、「オブジェクト指向」教えてスレなのに、
この濃い展開は一体何なんでしょう。

行くところまで行ってくださいage

FowlerにかぶれるなとかXPにかぶれるなとか言ってる割に
青木にかぶれるなと言う人は全くいないね。

そんなやつ、周りにいないしね。

逆にかぶれて Smalltalk 使いになってみろ、って感じだな。

スーパープログラマーは、青木さん
スーパーアナリストは、羽生田さん
下町の若社長的エンジニア、平鍋さん

思うに、ＶＢやＶＣ＋＋がＯＯをくだらないものにしてしまった気がする。
ツールが悪いんじゃなく､使う方の問題だが。

>>122
意味不明

OOPLとIDEを混同している低脳が居るな...

>>124
どう混同していると、分析したのですか？
教えてみ。それができないとすると、あなたが間違いなく低脳です。

組織的にオブジェクト指向開発をしようと決めて、大体どれぐらいで
使い物になるように組織が育ちますか？ 経験された方教えてください。
また、どういった問題が起きましたか？ それは、どのように解決しましたか？

>>126
まず、社内にいる寄生虫をみんな駆逐する必要があります。
向上心の無いサラリーマンには新しいパラダイムの導入は
OOだろうがなんだろうが無理。

みんな駆除する必要があるなら、殆どの会社でＯＯの導入は、無理じゃない？

無理だろうね。
大学とかで OO を使った分析や実装が当然のように行われ、新人がみな
OO 使いという状態にならないと難しいだろうねえ。
# ちょうど UNIX がそうやって企業に普及していったように。

>>129 さんへ
どうして難しいんですか？何が問題になるんですか？

上司の理解が得られない。
既存の方法論になれた人が、今更 OO に鞍替えしようと思わない。

手取り足取り仕事のやり方を教えなければいけないのが今までの
パラダイム。やり方はチミにまかせるから適当にやってねというのが
ＯＯと言えば上司の理解も得られやすい。

>>132
意味不明。

>>132
その例えはOOを分かっていないと通用しないよ。
>>133
そういうこと。

任せるけれど、責任必ず果たせよなってのも付くね。

>>132
今月のＣマガに新人用のＯＯの解説が言葉の定義、
日本人の言葉の感覚で解説してたよ

>>131
同感です。上司にＯＯの重要性の理解を得られたその後も
どれぐらい大変で時間が掛かるかを説明するのも苦労しました。
その後一番苦労したのが、取り組みを続けていくことでした。
このスレにもありましたが、真剣に関わってくれる人が２割
ぐらいしかおらず、８割の人を引っ張るのに苦労しています。
現在進行形です。８割の人を捨てるべきか引っ張っていくべ
きかという事を何度も何度も悩む場面に遭遇し、自分自身か
なり疲れてきています。ＯＯを組織的にやっていくのは大変
だなと実感しています。教わるまで取り組もうとしようと
しない人が多いのが何より大変です。自分で本を読んだり、
色々設計したり実装したりできないような多くて、そういっ
た人は思うように伸びてくれません。
何か良い方法がありましたら、アドバイスください。

　大手のコンサルティング企業からコンサルタントを派遣してもらってプロジェクトを進めたことがあります。
　そのプロジェクトはなんとか稼動するシステムとして作り上げる事ができたのですが、コンサルタントにはかなり不満が残りました。
　一番の不満は、最初の導入教育は決まりきった事をするだけなのでスムーズに進められたのですが、実際のシステムの分析や設計に入った頃から関わりが薄くなり、問題に対するアドバイスぐらいしかしてくれなかったことです。
　これは恐らく後から問題が起きたときに責任はあくまでも自分達にはないという事にするためのリスクヘッジ策ではないかと考えていますが、高い金を払ってその程度しかしてくれなかったことはかなり不満です。
　コンサルティング企業は最初の段階からこの会社にはこの程度の技術者で良いだろうという風に後々の付き合いを考えて割り当てをしているように思います。
　私のところで満足できなかったらこういった見方をしてしまっているのかもしれません。
　そこで、コンサルタントを入れてうまくいったとか、うまくいかなかったといったお話をみなさん聞かせてください。よろしくお願いします。

>>138
もともと優れた開発ができていた所ぐらいしかＯＯを組織的にやっていく
のは難しいのではないかと周りをみると感じます。
俺の会社は大手ＳＥ企業なんだけど、その中でもＯＯをうまくやれたのは、
一部です。そこはもともと優秀な人が集まっていて研究職に近い所です。
それ以外のところは、ＤＢ設計と画面設計をして、あとはそれなりに動く
ようにJavaやC++で実装しているというぐらいのレベルです。VC++やVB
なんかで実装しているところは、本当にそういった感じです。
分析設計を出来ているところは、片手で数えられるぐらいですし、その
レベルもまだまだだと思います。
そういったことを考えると、コンサルタントを入れると分析設計がすぐ
にできるようになるということは考えにくく、そういったところに力を
入れて期限までにシステムが稼動しないという自体になるよりも、とに
かくそのプロジェクトのメンバーのレベルでごりごりやっている中で出
てくる問題で解決できないことをアドバイスするというスタンスという
のはある意味正しいのではないかと思います。もちろん、138さんの所
のプロジェクトがどういったものであったのかによってその在り方も
変わって来るとは思います。あくまでもプロトタイプレベルの話であれ
ば深いかかわりをして欲しいと思うと思います。しかし、分析設計まで
まともにできるようになるには数年のスパンで考えておく必要もあるん
じゃないかと今俺の現状をみると思います。１、２年でまともにできる
ようになるには、業務なんてしていられないと思います。
みなさんどう思います？

>>137 切りすてるしかないゾ。

まげ

ＯＯと見せかけて○○って言ってる奴がいるぞ。

>>142
どういう意味？ 教えて。

>>143
○○だなんてエロ過ぎてとても口に出せないってよ

http://www.tech-arts.co.jp/cgi-bin/uml-jp/imgboard.cgi
こういうのが、途中で終わっちゃうんだから、寂しい限りです。

メーリングリストは続いてるよ>>145

145>
UMLって仕様書にくっつけるイラストの記法みたいなもんでしょ。
標準目指してるようなものなのに、何でわらわら草の根
ディスカッションする必要があるんだろ??

>>145
やっていたメンバーがメンバーですからね。トホホ。

>>147
違う、違う。
俺も最初そうだと思ったんだけど、色々本読んでみたら違ったよ。

>>149
?

http://www.oreilly.co.jp/BOOK/uml/

age

『比喩と理解』東京大学出版会

age

age

age

唯物主義上げ

ただあげるのも芸がないけど。

30歳過ぎて英語圏の大学で情報システム専攻。
system analysis & designの授業でUMLならったんですけど、
日本の会社で雇ってくれるところありますかね？

C,C++,VB,Database,Application開発、Network構築、
CORBAとDCOMを使った分散Web Application開発など
ひととおり授業で習いましたけど。
実務経験だけがない。

オージス総研ってすごい？

ここは？
http://www.fitech.co.jp

159>> OTS以外すごくない

復活あげ！

あげ！！！！

>>158
それが本当の話ならということで。こんなのはどうでしょう。
コンピュータと関係の無い仕事に就くことを勧めます。
その中で、コンピュータでの応用可能なことを見つけだす。
その間、趣味的に、それを作ってみる。
それをヒントに、自分の会社を作り実践する。

少なくとも直接的なコンピュータ関連の仕事からは、新しい
ヒントは生まれません。なれてしまうと、今の技術では、
ダメダメダメ・・・だけが出てきてしまう。周りもそういうこと
が多いので感化されやすい。
期待してまっせ！！

このスレ興味深いので参加させて頂きます。
私は３０歳でフリーランスのSOHOプログラマーで今年の総売上は
1000万ほど。大学は某理系国立大学の情報科学系で、オートマトン
もブール代数もならったけど、自分のスタイルとしてはどっちかと
いうと「いきなりソースコード書き始めるタイプ」です。
フリーランスというのはある種芸者的な存在なので、発注担当ＳＥに
調子を合わせる必要があるわけですが、いまオシゴト頂いてる大手
ソフト会社のＳＥさんは、自分より年が上で、かつ「プログラムなんて
動けばいいんだ。設計がいくら立派でも実際動かなければ何にもならん。
仕様書はモノができた後でいいです」みたいなことをマジで言う人なので、
それに自分も合わせてとりあえず作るスタンスを取っています。
メイヤーの「オブジェクト指向入門」を読みましたが、これを読んで
感じたのは、「このオッサンほんとにプログラミングとかソフトウェア
エンジニアリングという人間の営みに対して愛があるんだろうなー」
ということです。けど、自分の仕事をそこまで愛せる幸福な人は世の中
少ないだろうな、と。
テキトウにやっつけ仕事やって、バグは笑ってごまかし、会議にはデカい
声で周囲を煙りにまきつつ、テキトウに働いてテキトウに遊んで
春は花見に行ったり、夏は海に行ったり、秋は子供の運動会に行ったり、
冬はスキー行ったり餅食ったり、飛行機がビルにつっこむのや、イチロー
がホームラン打つのをテレビで見て「すげー」とか言ってれば、ＯＯなんて
やる必要ないしね。
自分の話をすると、仕様書にUMLちっくなお絵かきを入れて、「オレはＯＯ
分かってるゼ！」的アピールをするぐらいのことはしてます。

人生なんて30で終わるのが一番適当。
おれ28歳、どうやって死んだらいいのでしょうか？

真鍮の弾丸age

age

>>167
おやっ、「人月の神話」を熟読された方とお見受けする

age

>>166
今はアフガンが旬

不思議だ。
なんで、そんなにOOをしなきゃならないのだろう？
「OOにあらずんば人にあらず」か？
機能という単位で認知していくのがそんなに悪いのか？

>>172
そんなことはない。
方法論も適材適所。

>1
取り敢えず、手続き型言語を習得しているのならば、
後はトリガーイベントによる呼び出しの仕組みを理解するだけで良いんじゃないのか？
まずは、データベースのトリガープロセジャとか読んでトリガーの意味を理解して下され。
その後、イベントドリブンや生成されるスレッドの仕組み等を覚えたら終いね♪

# 実装手段としてのクラス化に拘ると本質が見えてこなかったりするから注意してね。

>174
私も1さん同様にこれから本格的にオブジェクト指向に取り組もうと
してるほぼ初心者です。

出張32さんのおっしゃることが今ひとつ漠然としていて
理解できないのでできればもう少し噛み砕いて教えて頂けないでしょうか？
それから、もし他にご存知のことがあれば教えられる範囲で結構ですので
いろいろとオブジェクト指向についてのトピック等カキコして頂けませんか？
よろしくお願いします。

>>175
> ほぼ初心者です

素人さんならば、まずはここで勉強しましょう。

1)http://www1.u-netsurf.ne.jp/~kitada/3H/
2)http://www.tech-arts.co.jp/oo/oo.html
3)http://www.tcp-ip.or.jp/~ikken/cpp/

順番に読み進むが良いでしょう。

# 結果的に、イベンドドリブンに行き着くのは言うまでも無いけどね。

>>176
3)はおすすめしません。OOというか、C++に対して、誤った先入観を抱く
可能性があります。（1は読んでないので評価できず）

C++をやりたいなら、『憂鬱なプログラマのためのオブジェクト指向開発講座』
http://www.shoeisha.com/book/Detail.asp?bid=740
をおすすめします。

というか、C++を視野に入れてOOを学びたいなら、端からこの本を読んだほうが
いいでしょう。

>>177
フォローThx.
ネットに落ちてるものって結構癖あるからね。
やはり素人にはお薦め出来ないかもね。

>>176
それを言うなら、イベントドリブンじゃなくてメッセージパッシングでしょう。
ただし、それが（それだけが）OOの本質じゃないですけど。
単なる言葉使いの違いだと侮るなかれ。

>>177
その本はどんなOO言語使いにも役に立つよ。

最近の人はOMTは読んだりしないのだろうか。
出版社潰れたけど(w

>>179
メッセージパッシングがOOの本質ではないという点は同意。
ではOOの本質とは？

>>182
真の意味での部品の独立性でしょうね。
その為に、メッセージパッシングが存在するのだしね。

メッセージパッシングってなんですか？
Windowsのメッセージループみたいなことの総称？

>>184
次からは自分で検索してね♪

メッセージパッシング方式は、メモリを分散して配置する並列処理マシンで広く使われています。
分散メモリ型の並列マシンでは、各プロセッサ上で並列に動作するプロセスが、
それぞれ独立したアドレス空間を持っています。各アドレス空間は、
分散して配置したメモリ上に展開されます。
一方、これが共有メモリ型の並列マシンでは、共有メモリ上に独立したアドレス空間を持つ
複数のプロセス間で互いに通信を行いながら、プログラムの実行を行います。
並列に動作するプロセスがそれぞれ独立したアドレス空間を持つ点はどちらの場合も共通しています。

メッセージパッシングは、プロセス間通信の一形態です。
メッセージは、データと制御情報から成っています。送信側のプロセスは、
送ろうとするデータを含むメッセージを作って、受信側のプロセスに渡します。
受信側のプロセスは受け取ったメッセージからデータを取り出してメモリに書き込みます。
つまりメッセージを送受信する時に、送信側または受信側のメモリを直接アクセスするようなことはありません。
メッセージパッシング方式による並列プログラムの記述が一般的になるにつれて、
移植性が高く、扱いやすい通信ソフトウェアへの要望が増加しました。
この要望を背景にMPI(Message Passing Interface)と呼ばれるメッセージパッシング方式
の標準インターフェースが考案されました。
PVM 2.4から3.1にバージョンが変わる時、大幅な仕様の変更があったPVMと異なり、
MPIは始めから標準インタフェースとなることを目的に開発され、
既存のメッセージ通信ソフトウェアの特徴をほとんど取り込んでいます。
(現在、主要なメッセージ通信ライブラリにはMPI/PVMの2つがありますが、
基本的な概念は共通しており、利用者から見た場合には、
通信ライブラリ名に差はあるもののプログラミングの手法はまったく同じです。)
MPIの策定には、並列処理マシンや、並列ソフトウェアの大手メーカ、大学や国立研究所の主要な研究者も参加しています。

>>185
どっかのページのコピペなんでしょ。
URLを示すか、自分の言葉で語ってちょ。

>>186
？
あんなに分り易い文書でも満足出来ないのですか？
じゃ、ポイントを絞りましょう。

1)メッセージパッシングは、プロセス間通信の一形態です。
2)メッセージを送受信する時に、送信側または受信側のメモリを直接アクセスするようなことはありません。
3)移植性が高く、扱いやすい。
4)並列処理が可能。

# これで良いですか？

>>187
彼は、Googleで「メッセージパッシング」で検索して引っかかった
ページを鵜呑みにしてるだけなんでしょう。

全く見当違いなことを言っているのに気づいてないようです。

完全無視で宜しく＞ALL

>>181
OMTはUML(＋RUP)に取り込まれた形になってるので・・・

>>184
MPIはオブジェクト指向とは関係ないし、オブジェクト指向のメッセージパッシ
ングは(並列性関係なく)オブジェクト間の通信一般を指すと思うのだが。
まぁ、出所はアクターモデルあたりの並列オブジェクト指向モデルかもしれない
けど。

>>189
出所＝オブジェクト間の通信を「メッセージパッシング」と呼ぶようになった謂
れ

情報システム板で、出張なんとかがほざいているだけで
一般的な用語とは程遠いような気がするが。>ﾒｾｼﾞﾊﾟｼｸﾞ

アホ草！
プロセス間通信以外に通信の手段は存在しないことを理解して下され。
まあ、Windowsが介入する点では確かに異なるけどね♪

>>185
ネタ元発見。
http://www.scl.kyoto-u.ac.jp/scl/appli/appli_manual/origin_workshop/docs/mpi_mm/mpi.html

>>192
ごめん、何を言いたいのかさっぱり理解でけん。なんでWindowsが出てくるの？

>>194
そうか？
理解出来ないのか？
そりゃ悲しかろうて．．．（笑

# 因みに、Windowsは例として挙げてみました。
# って、理解出来ないんじゃ挙げてもムダだよね♪

>>195
># 因みに、Windowsは例として挙げてみました。
># って、理解出来ないんじゃ挙げてもムダだよね♪

ちなみに、これは彼が

・説明できない個所に（どっかからのコピペだから）つっこまれた時の
・自分が間違った事を言ったと気づいた時の
・相手の発言が理解できない時の
・自分の発言が理解できない（コピペだから）時の

言い草です。

「何の例？」とか「どういう関係がある？」なんていう質問は無意味なので
やめましょう。

彼は、わからないか、知らないか、誤解してるかのどれかなのだから。

出張32さん以外のこのスレの住人の方へ

私は最近になってオブジェクト指向（正確に言えば、JAVAの学習)
を始めたＯＯ初心者です。ですから、ここであまり偉そうにＯＯの
話を論ずるのはおこがましいのですが、間違った知識を得ない為に
ちょっと確認させてください。

ここで他の皆さんが言っているメッセージパッシングとは
単一プロセス、分散（並列？）プロセスに関係なく、単に
「オブジェクト同士のメッセージの受け渡し」のことを示して
いるんですよね？ex．）イベント通知とイベントリスナの関係

どなたか、教えていただけませんか？

あ、それから出張32さんはこのカキコには絶対にレスつけないで
下さいね。（なんて書くと、「言われなくてもこんな駄スレは
相手にするつもりないけどね♪」とか音符記号つきで書かれそう
だけど（藁））

>>197
>ここで他の皆さんが言っているメッセージパッシングとは
>単一プロセス、分散（並列？）プロセスに関係なく、単に
>「オブジェクト同士のメッセージの受け渡し」のことを示して
>いるんですよね？ex．）イベント通知とイベントリスナの関係

その通りです。
また、その「メッセージ」はWindowsの”メッセージ”とは関係ありません。

なお、「イベントドリブン」はOOとはあまり関係ない概念です。
出張32がその言葉を使ったのは『罠』と考えられます。
あるいは、単に無知なだけか（藁

>>198
アホだぁ〜！
オブジェクト間での直接的な送受信を想定した時点で「オブジェクト指向」で一番大事な独立性を
失うことに気が付かないバカどもが如何に多いか判ったよ。


# まあ、君達のレベルでオママゴトしてて下され。

**注意**

こいつは「オブジェクト指向」について、なんの知識も無いし、
「オブジェクト指向」について、何かを語りたいなんて露ほども
思っちゃいないので、決して相手にしないように。

>>186
>どっかのページのコピペなんでしょ。
>URLを示すか、自分の言葉で語ってちょ。
ではなく、既存の資産をＯＯ化するにはどうするかと言うことを
悩んだ結果、そういう動きになってきていると言っているだけですね。
ＯＯを説明しているわけではありません。
しょうがなくそうなってると言うこと。すばらしいかどうかは別問題。

マジ質問で私も確認させていただきたいのですが

>>198さん
＞＞また、その「メッセージ」はWindowsの”メッセージ”とは関係ありません。
そうなんですか？
WindowsのメッセージはWinの部品をオブジェクトとしてみた場合
その、メッセージパッシングという手法をとっているような気がするのですが
違いますか？

>>197さんのおっしゃるような
>「オブジェクト同士のメッセージの受け渡し」のこと
というのは単にメソッド呼び出しとは
どのように違うのでしょうか。

すいません、Javaをよくわかっていないので
イベント通知とイベントリスナもあまりわからないのです...
C++Builderは使っているのですが。

>>202
>WindowsのメッセージはWinの部品をオブジェクトとしてみた場合
>その、メッセージパッシングという手法をとっているような気がするのですが
>違いますか？

構図としては似てますね。
ただ、Windowsのメッセージはオブジェクトに対するアクションでは無い、という所が
OOの「メッセージ」と違います。

>というのは単にメソッド呼び出しとは
>どのように違うのでしょうか。

プログラム言語からの視点では、ほぼ同じと考えてよいです。
Windowsのメッセージに戻りましょう。
Windowsのメッセージは、何かのメソッドを呼び出しているわけではありません。

「イベントドリブン」というのは、何もOOに限った話ではありません。
OOでは無い言語でも、イベントドリブンな処理は書けます。

>>203さん
なんかこのスレの流れからいって嵐と誤解されかねない
質問に答えていただきありがとうございます。

なるほど、OOのメッセージパッシングというのは
>>>というのは単にメソッド呼び出しとは
>プログラム言語からの視点では、ほぼ同じと考えてよいです。
ということで

>Windowsのメッセージは、何かのメソッドを呼び出しているわけではありません。
ということなのですね。

>「イベントドリブン」というのは、何もOOに限った話ではありません。
>OOでは無い言語でも、イベントドリブンな処理は書けます。
こちらは了解しております。

重ねてですが、ありがとうございます。

私の認識としては
イベントドリブンはWindowインターフェースと相性のよく
OOもWindowインターフェースと相性がよいと思うのですがどうでしょう。

>>176
>イベントドリブンに行き着く
これは、OOとは独立でしょう。
OOAで記述されるモデルに立脚したルールベースとかの議論と
しては了解できます。しかし、ルールベースについては、解決す
べき問題が多すぎるのも事実ですね（ルールスープ）。

>>199
これは、誤りでしょう。
インスタンス間で直接メッセージを送受信したとしても、それが
抽象化されていれば必ずしも直接的な依存関係は生みませんから。

さりとて、
>>203
> ただ、Windowsのメッセージはオブジェクトに対するアクションでは無い
は、「オブジェクト」とは何かという定義が脆弱です。
オブジェクトは必ずしもOOPのインスタンスとは対応しないので。
つまり、メッセージを授受する主体を「オブジェクト」として認知する
ことは十分に可能なことですから。

さりとて、さりとて、
>>203
は、>>1の問いかけに対しては良識的な答えだと思いますよ。
まずは、OOPのオブジェクトの概念よりはじめるのはよいことです。
理想的でない世界の些事を学ぶには、理想化された世界での訓練を
積んでからというのが望ましいでしょう。
はなから、初学者に対して現実の山のようにある些事を突きつけて
怯えさせるというのは、悪趣味というものです。

>>205
>>199
> これは、誤りでしょう。
> インスタンス間で直接メッセージを送受信したとしても、それが
> 抽象化されていれば必ずしも直接的な依存関係は生みませんから。

それって言葉の綾だと思うよ。
意味があれば結果的に必ず依存関係を生むことになるよ。
(処理不要なものを送信するって回答は止めて欲しい)

>>206
物理板で相手してもらえ。

>>206
>意味があれば結果的に必ず依存関係を生むことになるよ。
それは正しくもあり正しくもなしです。
どんなものも意味のネットワークの中におかれているので、
それこそ、現時点で直接対話していないものであっても、
あるとき依存関係を持つことはありますから。

しかし、どのような「やり方」を持ってきても、それは
防げないわけです。だから、次善の策としてどうするか
を考えるわけです。

その一つの方法として抽象化というのがあるわけですね。
さりとて、それは時に非常に効果的な場合があるわけです。
だから「よきもの」として受け入れられているわけですね。

まあ、Technicalに一つ気になるのは、
>(処理不要なものを送信するって回答は止めて欲しい)
の部分ですが、抽象化されたメソッドの戻り値に具体的
な型を使うことはまずない。というか、それを許す言語
系にはお目にかかったことがないので。

>>208
> それは正しくもあり正しくもなしです。
> どんなものも意味のネットワークの中におかれているので、
> それこそ、現時点で直接対話していないものであっても、
> あるとき依存関係を持つことはありますから。

そりゃそうです。
だからこそ間接的な依存関係にありたいわけです。
オブジェクト指向において直接的に従属関係は独立性を失うので避けたいわけですよ。

>>209
間接的な依存関係と、直接的な従属関係を例を挙げて説明してくれませんか。

なんだここでもこいつが荒してるのか。

>209
>オブジェクト指向において直接的に従属関係は独立性を失うので避けたいわけですよ。

そのためにどういう方法をとられてるんですか？
出張32さんの言うメッセージパッシングで対処できるのでしょうか？
教えてください。

>>209
> だからこそ間接的な依存関係にありたいわけです。
メソッドの抽象化は、間接化の一種ですね。
これによる依存関係の解消は、Templeteパターンのfooked methodに
みることができます。
＃実のところ、メソッドの抽象化を持ち出さずとも、メソッドがその
＃インタフェースとインプリメンテーションに分離されていることで
＃一種の間接性を有しているわけですが。まあ、間接性の分かりやすい
＃例ということで

> オブジェクト指向において直接的に従属関係は独立性を失うので避けたいわけですよ。
オブジェクト指向言語では、上述のメカニズムを用意しているので、
プログラム内の関数コール（メソッドコール）を直接発行しても
必ずしも依存関係を生むことにはなりません。

メッセージ通信メカニズムを使うかメソッドコールを使うかの議論は、
バインディングタイムの違いに過ぎず、どちらも間接性があるという点
で差があるものではありません。

なので、私は、>>199にて、>>198の発言に対し、
>直接的な送受信を想定した
と判断されたことは誤りであると>>205にて申し上げました。

>>213
> なので、私は、>>199にて、>>198の発言に対し、
> >直接的な送受信を想定した
> と判断されたことは誤りであると>>205にて申し上げました。

だからそれらは全て間接Callなんだって！（汗"
なんか議論が変だぞ。

>>213
>>214を見ても判るとおり、こいつは会話する気なんて全くありません。
出張３２は、技術的な知識は全く無いので、こいつのいうことは無視
してかまいません。

こいつは、バックボーンが無く、付け焼刃の聞きかじりの知識しかないので、
会話が噛み合うことは、将来に渡ってありえません。

無視が一番。

オブジェクト指向開発で、このスレッドで大口たたいたり、
輪を乱しているヤツのようなオブジェクトを定義するのは禁物です。
他のオブジェクトと強調動作できない、ただのスーパーオブジェクトなだけ。
XPで開発するなら、ユニットテストで確実に排除されます。
だって、テストしにくいし。テストしにくいってことは使えないヤツってことだから。
ヴェルディもエジムンド入れたらどうにかなるってもんじゃないでしょ？

結樹です.ついてに参加者が一人になりました.
呪います.

頭のおかしい人に“餌”を与えるのはやめましょう。

>>218 何を指しているの？

まあここでも読め

http://mentai.2ch.net/test/read.cgi/infosys/981101071/l50

>>220
すまん張るとこ間違えた。

居なくなっちゃったかもしれんけど

>>1
Java言語で学ぶデザインパターン入門がオススメ。

あがってんので最初から読み返したんだが、

出張32 が登場するやいなや、見事にスレッドが終了に向かっちゃうね。
おい、出張32、自分の発言が結果としてどんなものを持たらしているのか
自分で読み返して確認してみろ。

それとも成長しようとする連中を叩いて成長を抑えて、自分の
地位の保全を図るのがお前の日常的な行動原理なのか？

なんにせよお前がやっていることはお前以外の連中にとっては
「つまらない」ものに過ぎない。なんの躊躇もなく言おう、

出張32、逝ってヨシ！

ムム、私の書き込みのせいで随分、方向性がずれたようだ。
申し訳無い。>>all
簡潔に言えば、私の言いたかったメッセージパッシングは、
むろん、オブジェクト間のメッセージ送受信について述べたものだ。

煽りを覚悟で抽象的に書くが、私のOOに対する考え方(思い)は以下の通りである。

オブジェクトは人間だ。
産まれ、様々な体験をし、そして必ず死にゆく。
クラスはDNAであり、属性は環境であり、操作は命令である。
物理的事実は血縁関係のみに存在し、
その他の人間関係はすべて人の与えた意味に従うのみだ。
相手の心(データ)を知ることはできず、
許された行為はただメッセージを送ること、
メッセージを受け取ること、それだけ。
オブジェクトの独立性とは、すなわち人間の孤独なのだ。

さすがに、あまりに意味不明ｗなので、少し説明を加えます。

＞物理的事実は血縁関係のみに存在し、
＞その他の人間関係はすべて人の与えた意味に従うのみだ。
一般的に、OOPLで定められた文法において、
クラスの継承関係のみに主従関係が成り立つ。
サブクラスはそのスーパークラスのインターフェース（＋実装）を
必ず受け継がなくてはならない。
その点、いわゆる関連については、どのような関連でも、
その関係は開発者が後付けで意味を付加したものに過ぎない。
集約やコンポジションもその意味に従いプログラムするから、
集約やコンポジションなのであり、特別に文法的要素があるわけではない。

＞許された行為はただメッセージを送ること、
＞メッセージを受け取ること、それだけ。
＞オブジェクトの独立性とは、すなわち人間の孤独なのだ。
主に、カイジ第8巻参照ｗ。
究極な独立…究極な孤独…。
社会の歯車である人間は、独立性の高められたコンポーネントなのか？
カイジは人間こそが希望だと言った。
果たして、OOの希望はどこにあるのか？

>>225
簡単だよ。
オブジェクトは究極の表現系でもなんでもない。
歴史的にみれば、アドホックに「信じられている」系にすぎない。
そんなものに、人間を当てはめるのはどうかしてるよ。

人間ってそんなもんでしょ。

>>227
うん、そんなもん。

226は225の文を読み間違えてるな。

メッセージとは携帯電話のことだよＮＥ！>>227 >>228

オブジェクト指向ってそれまでの複数の手法
（データ抽象、代数的仕様記述、メッセージ・パッシング・モデル、レコード型、実装の隠蔽、etc.）
を組み合わせたものだから定義しようとするとバリエーションが色々あって大変だよね。

オブジェクト指向モデルを並列処理を理解・実現するためのモデルに使った例が並列オブジェクト。
けどまぁ、せっかくメッセージ・パッシングで抽象化したんだから、並列にしなければ意味がない、
むしろ並列性はオブジェクト指向の本質って言ってるヒトもいるしね。

（関数の定義と呼び出ししかない関数型言語にも自然な並列的な解釈があるんだから、
本質ってのはどうかと個人的には思うけど。）

OOの世界で「メッセージ」って言っているのは、もとはSmalltalk用語では？
メソッドを呼び出すに当たって、Smalltalkの処理系では「メッセージ
オブジェクト」（セレクタと引数の指定）が生成される仕組みだったと思った。
つまり、Smalltalkではメソッド呼び出しもオブジェクト。
（Smalltalkではたいていのものがオブジェクトとして取り扱える。）

Javaは俺の知る限りメッセージという用語は使っていないで、method invocation
（メソッド呼び出し）と言っていたと思う。イベントリスナーを介しての
やりとりのことをJavaではメッセージとは呼んでいないし、メソッド呼び出し
とイベント通信の共通の抽象概念の下においてもいない（つまり、イベント
リスナーを介したオブジェクト間通信をメソッド呼び出しと同列に位置づけて
いない）。

UMLはオブジェクトからオブジェクトへの要求の送付はメッセージと呼んでいる。
メッセージ送付＝メソッド呼び出し　とも言っていない。

C++ではメソッド呼び出しとはいわないで、関数呼び出しっていうのかな？

オブジェクト指向ってやたらめったら類義語が多くて、ちゃんと体系立ても
されてないんじゃないの？　それぞれの言語やら規格やらで勝手に用語定義
して使っているだけでしょう。

なにか代表的な本とか論文とか参照しながら「そこでいうメッセージパッシング
とは・・・」って言ってくれるならとにかく、そうでなければ話かみ合わない。
「おれは勝手にこう定義している」っていう主張に過ぎないのでは？

>>231
まー、Smalltalkとか最初に有名になった言語の用語が広まるのは
仕方ないかなという気がします。

「メンバー関数呼び出し」かな？＞C++

> オブジェクト指向ってやたらめったら類義語が多くて、
> ちゃんと体系立ても されてないんじゃないの？

では、A THEORY OF OBJECTSの$\varsigma$-Calculus準拠で(w。
（この本ではfield selection / method invocationになってますね。）

>>232

> では、A THEORY OF OBJECTSの$\varsigma$-Calculus準拠で(w。

ぬぅ、そう来ますか（w。型理論やら形式的検証やらの話は難しくてわからんす(w。

オブジェクト指向の世界だと、残念ながらフォーマルな研究者とソフトウェアエンジニアリングの立場の隔たりが大きい。

>>233
まー、それは会計学と整数論の隔たりが大きいようなもんかと。

あるいは、車を運転するヒトと車を作るヒトの知識が
（重なりはあるにせよ）違うのと似たようなもんですかねぇ。
プロドライバー達（レーシングカー、タクシー、トラック）は
各々高度な技術やノウハウを持っているだろうけれど、
車を作るための理論には必ずしも詳しくはないだろうし。

型理論等はソフトウェアを作る人のための道具
（言語処理系やその周辺のツール類）作りの知識っすからねぇ。

その本、４〜５年前に本屋で見かけましたが、
どこかのゼミで使われたのでしょうか？

豆蔵のＵＭＬ関連のトレーニングを受けてみようと思っているのですが、
受けた方いらっしゃいますか？
感想などが聞きたいです。

>>236 私自身は受けてませんが(笑、
　染まっていない1〜2年目SEとかには
　効果的みたいです。

>>235 灯台でしょ。

>>237 投稿大の間違い。

>>230 オブジェクト指向の概念ソースとして、代数的仕様記述は適切でしょうか？

代数的仕様記述のすべての側面が取り込まれたわけではないと思いますが、
理論的背景の1つとして影響は与えていると思います。

具体的にどの部分がと突っ込まれるとちょっと即答はできないですが。

>>237-238
両方で使われたことがあると思います。

>237
へっぽこSEの再入門としてはどうでしょうか？

>>236 あと、OO導入やOO教育は、組織的なバックアップなしでは、
　茨の道が待っている事を申し伝えておきましょう。

　私は、OOﾏｽﾞｰ関数言語ﾏﾝｾｰ、サイエンス系専攻で会社に入って、
　何の因果かOOに関わりあって、茨の道を歩んでおります。

　OOに拘りないから、豆蔵とかに逝きたいとも思わんし、
　かといって、義務感でフレームワークとかパターンとかやっても、
　理解していただける奴がいないのよね。
　

> あと、OO導入やOO教育は、組織的なバックアップなしでは、
>　茨の道が待っている事を申し伝えておきましょう。

すいません。組織的なバックアップとはどういうものでしょうか？

ﾑｽﾞｶｼｰのでﾁｮﾄ待ってね。

>>231
Smalltalk用語とかって言い出したらそもそもOOがSmalltalk用語でしょが。
なんでもObjectだからオブジェクト指向。
Smalltalkのプログラム環境を解説するために作られたtermなんだから、
あとでコトバだけ借りてきた世界で用語が混乱するのは当たり前。

>>246
そこで、当たり前で終わらせても得るものは少ないので、
アイディアは生かしつつ整理して
より普遍的なものにして行こうと言う営みがあるわけで……。

ラショナルに研修に行ったら、オブジェクト指向の特徴として以下の4つをあげていた。
抽象概念、カプセル化、モジュール性、階層構造
しかしどうにも以下の疑問が湧いて困っています。

�@抽象概念
具体的なもの（オブジェクト）の概念などのモデルのこと。ただし実世界の物体がコンピュータの中に入るわけではないので、実世界の事物を定義情報などに抽象化するのはシステム化ではあたりまえである。
ただし具体的な情報はコンピュータシステム内では、“情報それ自身は具体物”なので、その分析・設計ではそのまた抽象概念でモデル化する。実世界から見れば抽象化は２段階先とはなる。
しかしシステム分析・設計とは、そもそもそういうものなのではないか？
�Aカプセル化
情報や手順を隠蔽すること。あるシステム（大きさは問わない）が別のシステムと連携するときに、直接的な依存関係を排除しインターフェースに依存するようにすること。
しかし伝統的なバッチの各タスクも、直接お互いの内部メモリを見ているわけではない。
�Bモジュール性
複雑なものを管理可能な断片に分解すること。複雑性の管理方法であり構成部分の集合に分解すること。構成部分の間の相互作用がはっきりわかっている場合は、構成部分を独立して開発することができる。
しかしこれこそ構造化設計そのものではないのか？（モジュール強度・結合度とか）
�C階層構造
抽象度の同じレベルの構成要素を、何らかの抽象度の順位や順序を元にツリー場の構造に分類した構造。
しかし”構造”に言及しだしたら、”構造化設計”になってしまうのではないか？

どう思います？

……それ、モジュールの特徴じゃないの？>>248

モジュールとクラスに共通点が無いわけじゃない。

モジュール＝手続抽象
クラス＝データ抽象＋手続抽象

>>250
そらそうだけど。
モジュールの特徴をオブジェクト指向（全般の）の特徴として語られるのはどうかと。
デレゲーション・ベースでクラスのないオブジェクト指向言語もあるしね（マイナーだけど）。

>>248
ただ、オブジェクト指向は、ある意味では構造化設計のアイディアも包含してるからね。
それで全てを片付けようとはしてないってだけで。
だから2番、3番の説明に対する>>248さんの疑問は正当なもの。
オブジェクト指向の新味の一部は従来の技術を組み合わせた所にある。

けれども>>248さんが受けた説明の1番、4番はさすがに無理がある。
あまりにも指す範囲が広すぎるというか、曖昧というか･･････。

248は“T146-3608 /オブジェクト・テクノロジー辞典”
の一部とのことで、
�@抽象概念
あるもののもっと重要な面、本質的な面、または特徴的な面を含み、重要でない面、些細な面、または注意をそらされる細部などは隠蔽または無視して表現したモデル。共通性が強調されるように相違を除去した結果。
�Aカプセル化
機能（プロパティや振る舞いなど）の物理的な局所化。実装（及びそれに関連する設計の決定事項）をパブリックなインターフェースの背後に隠蔽する単一ブラックボックスのような抽象化ではない。
�Bモジュール性
事物（責任やソフトウェアなど）を小さくて単純なものの集合（それぞれ、要求やクラスなど）に論理的または物理的に分解すること。
�C階層構造
何らかの抽象度の順位や順序をツリー場の構造で表したもの。種類：集約階層、クラス階層、抱合階層、汎化階層、継承階層、分割階層、特化階層、タイプ階層。

がその説明でした。わしへたれだし頭いてよー。

つづき
へたれの自分が個人的にオブジェクト指向分析・設計と
構造化設計をするとき、どうアプローチを変えるかというと、
まー問題分割手順を変えるところかな。

構造化設計の時。
まずデータと機能を分離します。
データは独立してDBの正規化作業を開始します。
機能は機能の詳細化と分割をしていきます。
細分化後、機能で共通なものは共通手続きにまとめようとします。
このとき機能はあるパラメータを渡すと応答をひとつ返す形になるべくします。

オブジェクト指向の時
ユーザ作業をなるべく一般的な言い回しで説明しながら、言い換えて不自然でない
名詞句を考えます。例えば
丁稚ドンは大福帳に書いた。とか蔵の米を船に積んで大川にこきだすと...。
見たいな感じてす。丁稚ドン=社員とかでつじつまが合えば、分析クラス（クラスの候補）
になるかなって感じですね。
平行してユースケース（シナリオ）・コラボレーション分析しながら、上記のクラスの候補のすわりの良さを考えます。
クラスの候補に”状態”があれば（グレーの案件とか臭い取引先とか）クラスにしちゃいます。
あとは個別”機能”をそこに割り付けていくかな。
分割だけでなく再統合する感覚が構造化設計と違うとこかな。
DB設計が結構あとになるのも違うととこですね。

突っ込み歓迎。

>>248
その四つすげい納得。その通りと思う。というか思ってた。

”もの”を中心に世界を認識するらしいが、
経理システムのように業務自体が数字という抽象概念を
あつかうシステムのプログラムをどう設計するのだろう。
経理伝票とかをいくらにらんでも仕様はでてこない。
伝票にあるデータ項目とその計算式、計算条件が全てだと
思うが、どんなクラス図が書けるのか。そして、そのクラス図
はプログラムを書くのに役に立つのか？？？？？？？

>>255
データを中心に考えるのだから
経理伝票にある項目が、データメンバで、その計算がメソッド。
見た目と、設計が同じという点で、設計書を軽減できるメリットがあると思う。
どうだろうか？
ちなみにクラス図はいらないと思う。
伝票というデータメンバがすでにあり、業務という
操作が存在するのだから、それ以上の仕様書はないと思う。
結局、設計書を部分的なものに押さえることができる分、
納期も短くて済むし。あれ？
ごめん、ことばが遊んでた。

とにかく、抽象概念じゃないよ。伝票が目の前にあるんだから。
と思う。

>>255
たとえば、伝票の種類が複数あって、伝票の内容の出力方法も複数あるとする。
手続き型だと、

伝票の種類の判別　→　種類にあった出力

といちいち書かないといけないけど、オブジェクト指向なら、
きちんとクラス設計してあれば、ポリモーフィズムを利用して
直感的に記述できる。そして読みやすく保守しやすいプログラムになる。

ような気がする。経理伝票なんて見たこともない学生なので
適当に聞き流してくらはい。

それでクラスの中味はどう書く？
if　then　else　と手順を書くのでしょ。
つまるところソフトウェア工学発祥から
３０年間何も変わってないんだよ。

かかないって(ﾜﾗ

>>258
if then else か、、、
なかなか面白いアイデアだね。

>>255-257
データの個別事象をそのままクラス化することはお薦め出来ない。
何故ならば「クラス化」メリットが乏しくなるからです。
汎用的要素に特化する方向でクラス化を図ることに意味を持つと考えれば
判り易く、それ以上を期待するにはお粗末な概念です。

例えば、「伝票」と言うキーワードに着目し汎用要素を
日付、伝票No、取引先コード(経理の場合は内部振替含む)、明細行、
科目(品目)、金額程度を管理項目として取り扱うのが宜しい。

POAで帳票系システムが組まれている場合、
帳票のデータフロー分析するDOAが有効かも、
って話を聞いた事があります。

数値計算関係だとOOPLを
型＆演算子の拡張が可能な言語として扱いたい気がする。
んでも、数式処理絡みとか、CERNみたいなソフトウェア開発組織
持ってる所では、C++でオブジェクト指向の数値計算フレームワーク
作ってるみたいだけどね。

>261はわざとわかり難く書いてるのか？それとも酔っ払い？

>>263 酔っ払いに１００ペソ

数値計算でOOPL使う人ってどれくらい居るんだろーね？

数値計算でも使うんでは‥。事象を構成するオブジェクトを設計するでしょう。やはり。

アナパタって使える？

ＪＳＤ法に既に名詞抽出法とかあるんですね。
アッ！フー！

ここですかオブジェクト嗜好なヤシの集まるところは

UMLやりましょう！

オブジェクト指向で開発を行う場合に、いわゆるドキュメントの類はどうしてます?
要件定義書、基本設計書、詳細設計書、…等々
まあ要件定義書はあるにしても、基本設計書とかは思いっきり
書く内容(設計内容)が変わってくると思うのですが、
このあたりを説明した本やHPなどはないでしょうか？

ＲＵＰを勉強しる
ＲＵＰ関連の書籍だったら
ttp://www.pearsoned.co.jp/washo/object/wa_obj19-j.html

１年くらい前に流して読んだけど、まだ残ってたんですね。
為になる、いいこと書いてありますね。（好々爺がナイス）

自分、あらたな情報提供できないけど、だまされたと思って
みんな一回読んでミソ。（うっとおしかったらゴメン）

個人的にオブジェクト指向が難しいと思われているのはオブジェクト指向で
推奨されている概念の話と､それを実現するためにjavaやc++が用意した機能の
話がゴチャゴチャになっていることが原因だと思うのですけど。

工学じゃなく哲学として語る有名人とその信者が多いからね。

なんか久々にあがってるな。
懐かしいな、このスレで私は出張32が真正なるバカであることを実感したんです。
分散オブジェクトの話でもないのに急にプロセス間通信ってなんだよw

>>274
ごちゃごちゃになるのは無理も無い話です。
結果的に手法やツールを含めて会話となるのが自然ですからね。
オブジェクト指向そのものは普遍的であっても現実問題としてそれを使った開発は
プロジェクト毎に特徴をもつ為、普遍的とは言えなくなる。
このことがオブジェクト指向を難解にしている主要因と考えます。

# 特徴そのものが長所であり欠陥であると考えるけどみなさんの意見は？

>>275
工学と哲学とみると違いがありそうだが、
数学と哲学を比べてみると共通点があったりする。
どっちも主張が一貫していればそれで正しいというところだ。

情報工学も成長して結構な複雑さをもつようになってきてるが、
こういう世界で何よりも大切なのは確実ななにかを見出すこと
つまり自己矛盾の回避だ。

不満はあるだろうけど、実は数学も現在のように複雑化したの
は１９世紀あたりからで、その頃にはいろんな混乱があって
世紀末に至ってドイツのヒルベルトという数学者が公理主義
という今の科学の根本にある思想を提唱したわけです。
今となっては当然のものだが、当時は哲学というより宗教じみ
た雰囲気があったようで、後に、教祖となったヒルベルトの予想
に反する不完全性定理を示したゲーデルは殺されるかもと
怯えたそうな。

某企業でC++を使って働くプログラマです。
ほかにオブジェクト指向を習得している人もないせいか、せっかくリユースが使えて開発時間を短縮できたのですが、
「楽な仕事」と映ったらしく上司に評価を下げられました。
私から言わせれば、機関銃の時代に槍を使って仕事してるから回りが遅いといいたいところなんですが・・・。
復讐の意味で落とし穴をしのばせて転職しようと思っているのですが、どんな方法が有効だと思いますか？
メンテしにくいプログラムというのでもかまいません。
・１つのマクロ定義を複数のオブジェクトで使用する。(当然値が同じだけで、使用用途は異なる)
・マクロ定義した値をさらにマクロ定義で使用する。
・多重継承を多様する。
などなど。よろしくお願いします。

279 > 項目の多い、インクルードファイルを削除する。

>>280
どうもです。でもコンパイルエラーでちゃいませんか？
変更がよく入るところにしのばせて、結合テストあたりで出るようにしたんですが。

>>279
あまりにも幼い物言いですな（笑
君自身が思っている以上に評価を下げられるのも無理ないと感じました。

これ以上恥を晒さなくても良かろうに．．．（汗
と考えるしだいです。

# 身を引くときは大人しくが基本ですよ。

>>279
面罵変数にint iとか作っておけ。

>>282
確かに。そうしたいところ。ただ上司も子供っぽいので、子供レベルで接してあげたいのです。
(なんたってコーディング規約や作法もないし、レビューはあるけどまわりは寝てるし)
ふと思いつきましたが、何も技術的なものを残さないっていうのもいいですね。
鉄砲言語の中のヤリだけを使ったコーディングに書き換えます。
サンクス。
>>283
ありがとうございます。こんな感じだとgrepしにくいし・・・。
クラスデータ名を、"int i", "int ia", "int iab", "int iabc"みたくする。
もちろん良く使うほうに右がわの方にする。
ローカルで普通にソース作って、この手にコード変換する。(フリーのツールが使える)

ｐｓ：こんなのも思いつきました。
■その１
a.cpp
#define A 1

b.cpp
#define B (A + 1) <--- よく変更される

c.cpp
#define C (B + 1) <---- = A + 2でないといけない

とてもいい置き土産ができそうです。

C言語のプログラミング作法の本が薬ではなく毒としても使えます。

国内電気メーカに内定しています。ｆではありません。
これからオブジェクト志向技術を身につけようとして
martin fowlerさんの本を読んでいたら教授から一言
「○君は営業向きだからそっちでがんばりなよ。
どーせあの会社は仕事を丸投げだしさ。
たまに見積もりまで投げちゃってね。ははは。」
こんな私はオブジェクト志向の概念を学ぶのは無駄でしょうか？
プロのみなさん教えてください。
ちなみにオージスそうけんのブロンズレベルをクリアして
これからシルバーを取ろうとしてたのですが、
あの資格も無駄でしょうか？
マジレスお願いいたします。
ちなみに研究ではｖｒｍｌをｊａｖａで動かしてます。

>>285
オブジェクト指向は大切だけど、その前にDFDやらER図やらは
大丈夫なのかい？　資格は情報処理技術者試験を優先したほうが
いいよ。　オブジェクト指向はそれだけを本を読んで身につけられる
ような技術じゃないです。木を知らない人間が森を理解しようとする
ようなもんです。

営業中心の会社なら、入社と同時に割り切って会計士の勉強でも
始めたほうが良いかと思います。SW程度の能力があれば仕事は
回せると思うし、それ以上は要求されないんじゃないでしょうか。
もちろん高度情報処理技術者を持ってたら尊敬されると思いますが、
同時にフラストレーションが溜まるかもしれませんね。

>研究ではｖｒｍｌをｊａｖａで動かしてます。
少なくとも今のVRMLは消えていく技術なわけですが、
なんか変わったデータの資格かでもやっておられたんでしょうか？
（まさか院で純粋に vrml と Java のコーディングのお勉強じゃ
ないと信じてます。^^;）
院まで出て純粋SEとは、ほんとにｷﾋﾞｼｨ世の中ですね。
根性があるならプログラミングのスキルを磨いて、将来独立という
道もあるかと思います。　何もしない人生というのは無用に長い
ものです、死なない程度の冒険を１つや２つすれば男も上がるでしょう。

>>286
同意。勉強だけでも身につかないっていうのが私の考え。
オブジェクト指向の目的として「再利用」というのがあります。
機能追加や仕様変更をするときに変更量とテスト量を減らし、開発期間を短縮することが求められます。
当然、他の共同開発者にもわかり易いことが求められるわけです。

これは経験が非常にものを言う世界です。
新規開発では全くといっていいほどノウハウはたまりません。
機能追加と変更を最低でも２，３回繰り返すと行き詰まる部分がでてきます。
下手をするとモデルを考え直す部分まで出戻ることもあります。

また、部署によって仕様変更や追加の内容は様々です。
アーキテクトに関してはオブジェクト指向は、その職場で培ったノウハウはさほど他の部署ではすぐに
役立つものではなくて、また１から経験をつまねばならないということです。
アーキテクト次第で今後の全てが決まると言っても過言ではないです。

ですから仕様の追加や変更を数多く経験することが大事だと思います。
ノウハウ本も数多く出ていますが、やはり概論に関する部分が多く、実践的な書籍は皆無と言っていいでしょう。

とえらそうなことを言っている私ですが、まだオブジェクト指向７年目で、良くわからないことが多々あります。

>>286
どうもありがとうございます。オブジェクト指向の勉強は気長に
やろうと思います。会計士などの資格も視野に入れていこうと思います。

研究は医療関係についてｖｒｍｌを使っています。
これ以上書くと身元が分かってしまう可能性があるので
これぐらいでお願いします。

DFDやERはちょっとあやふやなところがあります。
もう一回構造化手法も復習しておきます。
冒険できるようにがんばります。

オブジェクトちんこ

これはマジなのか？
>>279
> 私から言わせれば、機関銃の時代に槍を使って仕事してるから
> 回りが遅いといいたいところなんですが・・・。
言いなさいよ。はっきり言ってやれ。それで辞めればよい。
そもそもなぜそこで
「圧倒的に高度なソースを見せつけて見返してやる」
とか思わんのだ？

>>290
4,8ﾋﾞｯﾄのｱｾﾝﾌﾞﾗしかﾛｸにできない上司には理解不能かと。

ユースケースって使ってる?
やっていてもいまいち良さがわかんないんだよね。
使っていて便利だなと思うところって、どんなところがある?

（＾＾）

（＾＾）

age

ユースケース、ほんとに活用している例があるのかどうか、
ワシも知りたい。ほんとに役にたつのか、あの幼稚な図面が。

>>296
便利かどうかは別として
共通言語として考えれば役に立つ

>>297
「共通言語だから」って根拠は聞き飽きた。
実務上の有効性の話をあいまいにしたまま、
けっきょくいつも「まあ、いろいろ問題は
あるが、共通言語ってところに意義がある」
って話ばっかり。

そもそもUMLって共通言語として作られたわけで。

>>298
Rationalはユースケースドリブンで分析/設計を進めるじょ。
お客さんの理解と最終的な成果の乖離が少なくてすむと思うじょ。

小難しくて、関係者の何割かにとっては理解できないような高尚
な理論は、仕様策定作業にとっては煙幕にしかならないじょ。
ハナから詐欺コンサルが目的でお客さんに近づいてるなら、煙幕
は便利だけどねー。

>>298
禿

>>300
「乖離が少なくてすむと思う」ってんじゃなくて、
「乖離がじっさい少なくてすんでいますが、何か」
というコメントがほしいんだけどなあ。

それも、ＷＥＢ受注程度のしょぼいんじゃなくて、
受発注も在庫も会計も含めたバリバリの基幹システム
開発での事例。それもRATIONAL社やそのとりまき
のような「会社の方針上それを使わなければいけない」
ような立場ではないチームによる事例。

使ってやってみた感想だけど、ユースケースには、
標準化以上のメリットはないとおもうよ。
ユースケースの本質は、機能面からとらえた外部仕様書だと思う。
オブジェクト指向はもともとの発想がデータを中心にした
モデルを作ることに主眼をおいているから、
逆にシステムがやらなきゃいけない機能要求を漏らしやすい。
それを補うために、機能を中心とした手法を組み合わせて
用いる必要があるのね。
だから、機能要求さえとらえられれば、必ずしも
ユースケースにこだわる必要はないと思う。
もし、会社できちんと標準化された外部仕様書が定まっているなら、
それを代替で使っても問題ない。
でも、ほとんどの会社ってそんなことやってないでしょ?
だから、もしも外部仕様書を標準化したいならユースケースを
導入するメリットはあると思う。標準化するのは結構な労力だから、
もともとあるものを利用する方が合理的だよね。
以上が俺の考えなんだけど、どうかな?反論求ム。

>>296
あなたのおつむが幼稚なだけかと。

あの。。。ＩＩＯＳＳ
http://www.iioss.org/index-j.html
を試してみた方いらっしゃいますでしょうか？
使い勝手等々感想をおきかせください。
よろしく御願い致します。

『オブジェクト指向』
宗教・哲学・認識論のたぐい。
個性が出すぎるモデル。

>>306
必死だな(ｗ

>>306が正解

オブジェクト嗜好age

（＾＾）

agee

最近、偉そうなSヨが増えてます。
特にたかがUMLができたくらいで調子にのってるバカです。

プログラミングってのは業務要件を満たす事に
意味があるのにもかかわらず、
クラス設計とUML記述に誇りを持っちゃってるかわいそうな
人達がいます。
数学しかできないバカや理系には業務設計は無理です。
しかしながら、そういう人達がいないと困ります。
スターエンジニアの間では、そのような人達を
使い捨てOO厨と呼ぶのが一般的ですが、
その人達につまらないクラス設計やUML図作成を
安い賃金で任せる事ができるので非常に便利です。
でも、最近は使い捨てOOドカタは中国から輸入する事が
多くなりました。
そういうわけで、うちの会社では
使い捨てOO厨は粗大ゴミとして捨てました。

ちゃんちゃん

>プログラミングってのは業務要件を満たす事に
>意味があるのにもかかわらず、
>クラス設計とUML記述に誇りを持っちゃってるかわいそうな
>人達がいます。

論理的な整合性がないです。文章かく練習したほうが
いいよ。

（＾＾）

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

UML認定試験のゴールドって取った人、業界的にどのくらいの評価があるんだろ？

>>316
OMGがもう直ぐじきじきに認定資格をつくるので、価値がなくなるかもな。

>>312
たかだかUMLもマトモに扱えないあんたよりはマシかもな。
あんたがいなくても、そこそこのインタビュアーがいれば
モノは出来るだろ。

勘違いピンはね営業こそ氏んでくれ。

オージスとOMGの新資格との互換性とかってあるんでしょうか？

オブジェクト指向のおすすめは
JavaとUMLで学ぶオブジェクト指向の考え方―オブジェクト指向分析・設計入門
javaとumlが少し出てきますが、分かりやすかったです。

PHPというと安っぽく聞こえるけど、オブジェクト指向の初歩を
学ぶなら練習用に使える。

仕様がシンプルな上コンパイル不要。関数も豊富だから面白いＹＯ！

オブジェクト指向Ｃ＋＋は中途半端。手続き型とごちゃごちゃになりやすい。
オブジェクト指向でプログラムするには３２１のようにオブジェクト指向分析・設計入門
を勉強しないとむり。
情報構造を決め、そのクラスの役割を明確にしないと。いわゆるカプセル化がムズイ。
でも、きれいに書けたときは気持ちイーけど・・・

>312
現場を知らない奴が設計できるのかと聞きたい。

UML技術者ってもってると役に立つんですか？

あぼーん

>>325
というか、ＵＭＬできない技術者っていまどきいるんですか？

>>327
出来ない香具師たくさん。
オブジェクト指向設計と構造化設計をごっちゃにしてる香具師たくさん。
UML設計できると思っていて、実際に設計書見ると読めない（間違っている）香具師さらにたくさん。

>>312
燃料投下ご苦労様でつ。

>>328
UML設計って何よ？

>>330
ＵＭＬ準拠の設計とおもはれ

構造化設計は、ＤＦＤやらＤＤやらのことでしょ？

>>331
それはオブジェクト指向設計とは別物？
UML準拠の設計とはUMLで表記されたオブジェクト指向設計じゃないの？

ＵＭＬ関係の資格ってあります？

オージス総研のUML技術者認定試験
あとは、
IBMの資格の中にもあったかも。

>>333
今秋にはOMG認定の資格ができるよ。

>>332
まぁ、ＵＭＬはオブジェクト指向設計に使うのが常だから、オブジェクト指向
設計ということになるけど、ＵＭＬは独立したモデリング言語（そのなのとおり）
だから、ＵＭＬ準拠ってことでよろしいのでは？

ひょっとして、漏れ間違ってる？

ウルトラマニアックランゲージ

UMLはドキュメント好きな顧客を騙す道具として使われる場合がほとんどだ

あぼーん

あぼーん

全然盛り上がってないね。

とにかく胡散臭いよね。

>>342

おまえがうさんくさい。

>>343

でたなUML信者。おまえみたいなのがえー書いただけで
わかったようなこというんだよ。

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

ＤＯＡのＥＲ図で概念をうまく整理できない先輩にも
オブジェクト指向なら簡単にできるものでしょうか？

>>346

クラス設計がスラスラできるくらい才能があるなら、
データモデリングなんて簡単でしょう。
ゆえに、データモデリングができないなら
クラス設計なんてとうてい無理だね。

>>347
データに＋振る舞いだから、データだけより複雑だよね。

胡散臭いんだよｗ

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

途中から入ったプロジェクトの話。
シーケンス図の矢印の意味がわかってなくて、
状態遷移図とごっちゃになったような奇天烈なドキュメントが出来上がってしまっていたのだが、
すでにユーザーの検品済みでなんのチェックも入らず、
開発のほうでもそのドキュメントを全然見ていない。

見方もわかんないようなドキュメントを要求するなといいたい・・・

オブジェクト指向って何でつか？

>>351
ドキュメントには意味はない。
ドキュメント化することに意味がある。
・・・トム・デマルコ

　　　　「オブジェクト至高 vs オブジェクト究極」

＼＿＿＿＿＿＿＿＿　＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／
　　　　　　　　　　　　　O ﾓﾜﾓﾜ
　　　　　　　　　　　　o

　　　　　＿＿＿＿,,,,,,,,,,,,,,,,､､､
　　　 ／　　　　　　　　　　　　）））
　　　/　　　　＿＿＿＿＿＿,,,ノ
　　　/　　　 ｌ　/　　　 ＼＼ヽ|）
　　　| 　　　|　''''''''''　　 　''''''''|
　　　| 　　　| ( 　･ )　　　( ･ )l
　　　| 　 　 ｌ　 　　　　　 ｌ　　|
　　　| 　（ ~　 　　 　　　 _)　 |
　　　 | 　 |　 　 　 ,―――.　ｌ　　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　ｌ　.|ヽ　 　　ー――' / 　　＜　という夢をみたんだ。。。
　　　　ヾ |　 ＼＿＿＿＿ノ　　　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿

いくらJavaや.NETやRDBやっているといっても、
作業報告やスキル報告の書式が
　POA(プロセス中心分析)＆ウォーターフォール
になっているようだと、一発で勤労意欲を削がれる。

いくら最新の開発技術を使ってより良い成果を出しても、
管理と評価が旧態然としたままじゃぁー、評価のされようもないし、
評価されるためには、無理のあるマッピングをでっちあげなきゃならんし。
(鉄筋コンクリ建築の工程を、木造建て増し建築の工程で管理しよう、というのと同じ)

いい加減、POAベースのプロジェクト管理を止めろ！

あと、プロジェクトの規模を単に何人月と表現したり、
開発実績をプログラム何本、ステップ数いくつ、
とか表現するのも、激しく痛い。
ステップ数ですよステップ数。今時 LOCじゃなくFPくらい使えってんだよ

元請会社でそーゆーネジの外れた管理してる所見ると、
　しょーがねぇなー、管理方法を更新する人材の余地がない程忙しいのか
とかせせら藁ってしまえば済むのだが(本当はかなり嫌だ)、
下請け会社でそれやってる所を見てしまうと、
　かわいそうに搾取しまくられだぜ、きっとこいつら
と痛々しい気分になってしまう・・・合掌

ここに関わるのだけはやめとけ
http://www.tech-arts.co.jp/
絶対に後悔する＿|￣|○

>>358
風評コピペうざい。氏ね

>>355-357
あるよな、現場の動向に管理部門が付いて行っていない会社（ｗ

Javaの開発が立ち上がりつつあった1995-1996年頃、
この分野に関わったら、自分とこの問題解決に手間取るだけならまだしも、
社内普及やら標準化やらで、5年や10年は無駄になるとふんだ。
そして今時の標準動向ってのは、当時問題解決してたテーマとほとんど大差がない。

その間、管理部門の連中は無駄飯食い散らかして、
骨董品的な概念を振り回し続けるだけ。。。
お前ら現場の稼ぎで飯食ってる間接部門の癖に、
現場の最新動向フォローできないようなら、会社辞めちまえ・・・

とか言うと、アフォアフォ管理部門の仕事を現場の人間が肩代わりする必要が出てくるんだろうな。
まったく、係わり合いになりたくないぜ

こっちのスレは終了ですか（ｗ

　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

　　　　　　　　　　　　　　　　　　 ／＿　　　　　　|
　 　　　　　　　　　　　　　　　 　 /.　＼￣￣￣￣|
　 　　　　　　　　　　　　　　　　/　　／　 ―　― |
　　　　　　　　　　　　　　　　　|　 /　　 　-　　- |
　 　　　　　　　　　.. 　　　　　||| (6　　　　　　>　|
　　　　　　　　　　　　　　　　| | |　　　　 ┏━┓|　　
　　　　　　　　　　　　　　　| | | | 　　　　┃─┃|　
　　　　　　　　　　　　　　　|| | | |人＼　┃　 ┃/　 　
　　　　　　　　　　　　　　　　　　　r;::;;;;;:::（##）::::ヽ
　　　　　　　　　　　　　　　　　　/::;;;;;;;;;;:::::::}三 ヽ:::ヽ
　　　　　　　　　　　　　　　　　/::::::::;;;;;;;::::::::}ﾆ､　 ｀ｒ:）
　　　　　　　　　　　　　　　　/:::::::::::::::::::::::甘ｰ〈ノノヽ::ｌ
　 　　　　　　　　　　　　　　/:::::::::ｲ::::::o::::::::;;::::::::::ヽ:::::::ﾄ
　　　　　　　　　　　　　　　/::::::::ﾉ |::::::::::::::::::;:::::::::::::＼:::/
　　　　　　　　　　　　　　 〈::::::::{　 |::::;;;;;;;;;;;;;::::::::;;;;;;;:::::ヽ|
　　　　　　　　　　　　　　　 ヽ:::ヽ　|::::::::::::::::::::::::::::::::::| 　
　　　　　　　　　　　　　　　　 ヽ::::ヽ|::::::::::::;;::::::;;::::::::|
　　　 　　　　　　　　　　　　　　 ヽ::ｒ|::::::::::::::::::::;;::::::::|
　　　　　　　　　　　　　　　　　　　ヽ「. ﾖ::::::::r-ｰ-､:::::|
　　　　　　　　　　　　　　　　　　　　ゝ､ﾖ（ (☆) ）ニll |

　　　　　　　　　　　　　　　　　　　 ／＿　　　　　　|
　 　　　　　　　　　　　　　　　　 　 /.　＼￣￣￣￣|
　 　　　　　　　　　　　　　　　　　/　　／　 ―　― |
　　　　　　　　　　　　　　　　　　|　 /　　 　-　　- |
　 　　　　　　　　　.. 　　　　　　||| (6　　　　　　>　|
　　　　　　　　　　　　　　　　　| | |　　　　 ┏━┓|　　
　　　　　　　　　　　　　　　　| | | | 　　　　┃─┃|　
　　　　　　　　　　　　　　　　|| | | |人＼　┃　 ┃/　 　
　　　　　　　　　　　　　　　　　　　　r;::;;;;;:::（##）::::ヽ
　　　　　　　　　　　　　　　　　　　/::;;;;;;;;;;:::::::}三 ヽ:::ヽ
　　　　　　　　　　　　　　　　　　/::::::::;;;;;;;::::::::}ﾆ､　 ｀ｒ:）
　..　　　　　　　　　　　　　　　　/::::::::::::::::::::甘ｰ〈ノヽ::ｌ
　 　　　　　　　　　　　　　　　/::::::ｲ::::::o::::::::;;::::::::::ヽ:::::::ﾄ
　　　　　　　　　　　　　　　　/:::::ﾉ |::::::::::::::::::;:::::::::::::＼:::/
　　　　　　　　　　　　　　　 〈:::::{　 |::::;;;;;;;;;;;;;::::::::;;;;;;;:::::ヽ
　　　　　　　　　　　　　　　 ヽ:::ヽ　|::::::::::::::::::::::::::::::::| 　
　　　　　　　　　　　　　　　　 ヽ::::ヽ|::::::::::::;;::::::;;::::::::|
　　　 　　　　　　　　　　　　　　 ヽ::ｒ|::::::::::::::::::::;;::::::::|
　　　　　　　　　　　　　　　　　　　ヽ「. ﾖ::::::::r-ｰ-､:::|
　　　　　　　　　　　　　　　　　　　　ゝ､ﾖ（ (☆) ）ニll |

age

えらそうなこと逝ってても、所詮会社の飼い犬。

age

www.umlcert.org
持つもの＝アーキテクト、持たざるもの＝プログラマ、所詮はコンサルタント志望。

オブジェクト指向開発の勉強方法を教えて下さい。
分析から設計までの一通りの流れを勉強したいと思っています。
「かんたんUML(翔泳社)」を読んで何となくイメージは掴めたのですが、
所詮本を読んだレベルなので、実務にはほとんど役に立たないのが現状です。
そこで、実際に手を動かして自分で考えたいと思うのですが、
一連の流れを勉強できる問題集的な本はありますでしょうか。

書店で探してみましたが、ＵＭＬの表記方法の本はあるのですが、
自分のイメージに合うような本は見つかりませんでした。
＃サンプルのシステム化案件があって、それに対して、
＃ユースケース図→シナリオ→シーケンス図→・・・
＃と流れにそって勉強できるような本を探しています。

よろしくお願いします。

>>369
実践UML
ttp://www.amazon.co.jp/exec/obidos/ASIN/4894713861/249-4600732-3328358

>>369
追伸
かんたんＵＭＬで掴んだことは忘れた方がイイ

>>370
ありがとうございます。
明日出掛ける用があるので、早速見てみます！
＃かんたんＵＭＬで掴んだことは忘れた方がイイのですか。。。

ＵＭＬモデリング技能試験の試験対策本を見たんだけど、なんか変な感じ。
これがいわゆるオブジェクト指向なの？

ちなみにざっと評価したのをココにあげときました。
http://49.dip.jp/~up/up/img/49up32014.zip

>>373
みれません

>>373
見たけど、どうしろというのだ。
問がないのに。

>>375

>>375
問をつけると著作権の侵害になっちゃうんです。ハイ

これ「はじめて学ぶＵＭＬ 実践問題集」って本です。
（そういえば書名もわすれてますね。失礼）

この本を見た人は特に違和感、感じないんでしょうか？

わたしの知識が足りないせいかもしれないんですが
簡単な表記の問題以外、なかなか正解にならないんです。

で、つたない英語でＵＭＬの仕様を読んだんですが、
ドーモ、解説で言ってることと違うようなんです。
（問題ごとに調べた結果もまとめてみました）
本当のところドーなんですかね？

そういえばもうあげといたファイルにはアクセスできないです。
要望があるようでしたら、またどっかにあげます。

UMTP受けないと会社で干されます

思考と間違ったよ。。。

↑なんであげ荒らしばかり繰り返すの？
他人に迷惑だとは思わないの？
一行レスばかり繰り返して。
あなたの人間性を疑います。

あらら。このスレで言うと>>380-381で１セットの荒しなのね。。。
>>381は、ミイラ採りがミイラになる、つう類いかと勘違いしてーたよ。

学術age

age

オブジェクト脳って本、内容良いですか？

学術揚げ

>>386

体育会系向き本。理系向きの本じゃない。

>>386
なんか放置されてるなw
OOを教える人にとっては良いかも。
これからって人にとっては良くない。

脳味噌が筋肉なﾔｼ向きなのね

MVC

サブジェクト指向ってないの？

このままじゃヤバイ

ぼくは〜Ｃの人間なんで〜ＪＡＶＡはわかんないスから〜

↑ならオマイはなぜＪＡＶＡ現場にいる？クビにして欲しいのか？こんなヤツ結構多くて困るのだが…

hahaha

ＪＡＶＡシステムなのにＵＭＬのカケラもない
設計者が誰もシーケンス図やクラス図を書いた事がない
雛型をつくれない様子を見ると書き方も知らないらしい
こんなシステムからは早く足洗って見捨ててやるぞ

オブジェクトが難しいと思われる理由は何だと思いますか？

で、どうよ？

定期age

.　　　　　　　　　＿＿_
　　　　　　　　ヽ|・∀・|ゝ　
. 　　　　　 　　　|虫唾|　　=三
　　　　　　　　　＜　＼　　　　 ﾀﾀﾀﾀﾀ・・・・

物事と関係の抽象化でつ

それとすでにアクセプト指向だし

Aspect?

>>402

ネタかな？

アクセプト指向（Accept oriented）・・・

age

おまいらアクセプト指向なんて聞いたこと無いですよ。アスペクト指向ですよ。
占星術で使うあのアスペクトですよ。

学術揚げ

つぎの患者さん、どうぞ

>>http://science3.2ch.net/test/read.cgi/infosys/1042967631/954

　>>http://science3.2ch.net/test/read.cgi/infosys/1042967631/912 よく嫁

クラス図描くじゃん、で、よく見てると、作るべきインターフェース
が浮かび上がってくるじゃん、で、インターフェース定義して、また、
クラス図描くじゃん、こんなこと１０回くらい繰り返しているうちに、
あのデザインパターン使えるな、なんてことになるじゃん、で、そん
なこと１０回くらいやってるうちに、シーケンス図描き始めちゃうじゃん。
こんな感じだよね。

10回もかかるのか・・・・・

>> 961
そんなの書かなくても瞬時に頭の中だけで構成が描けないと現実では使えない人なのだが・・・
結局、幹の選び方だけなんだよ。

思考が幅広く鋭くなれば、幹と枝の分別にそのような手間はかからない。
もちろん、常に広く深く思考する資質を持った人でないと到達不可能な世界ではある。

要するに、自分はそういう人だって言いたい？
優れた人であれば、悩んでる人を先導していって欲しいわけだが
　
OOが流行らないのって、こういうところにも問題があると思うな
言ってることはなんか正しそうなんだけど、聞いてるとムカつくっていうか

具体性がない精神論が多いからな、
OO技術者はは叩かれすぎて人格障害者が多いのも事実。

>>3
どっちかちゅーと腐れ企業スレの方が板違いなんだけど…

元豆の人、「オブジェクト指向『だけ』できても・・・」とか言い出して、
ずいぶんテンパってると思ったら、とうとうOOやめちゃったのね。

俺はもう５年ほど、ポストオブジェクト指向の立場なんだが（笑

>>416
いや、元豆の人ご本人ではなくて、
元豆の人にとりついてる業務系ハイエナが
負け惜しみ言ってるだけだと思うよ。

OOだけできてもだめなのは確かだがな。

希望的観測で妄想語るのはやめとけって。

２ちゃんでＯＯ執拗に叩くキチガイは、
頭の中がＯＯの妄想でイッパイイッパイなんだろうがな

アンチＯＯ厨は、ＯＯ周辺で発生してる微妙な見解の相違を、すべて単純なアンチに還元しちまう知恵遅れだな。

微妙な話を理解できない池沼は
クチバシ突っ込まずにＲＯＭってろって

OOの話にだけナイーブなのも困ったもんだ。

最新技術から取り残され、業務スキルも大して身に付かず、
他業務分野への転職もままならない事でとみに有名な
某分野の業務ＳＥにそーゆー事いわれても、苦笑いするしかない

そりゃOOだけやってりゃ最新技術から取り残されるわな

次の患者さん、どうぞ。

なんだ、>>423　やっぱり単純バカか

見苦しいやつだな、どこのエンジニアだ

>>426の上司です

誰かOOの構造と80年代の人工知能の知識表現の構造の関係について語れるやつはいないか？

酷似しているんだが。

1. 阪大の溝口理一郎せんせい＠人工知能学会が「オントロジー工学」というのをやっていて、
　それが近いと思う。
　　http://www.google.com/search?hl=ja&lr=lang_ja&ie=UTF-8&oe=UTF-8&q=%E3%82%AA%E3%83%B3%E3%83%88%E3%83%AD%E3%82%B8%E3%83%BC%E5%B7%A5%E5%AD%A6&num=50

　最近「オントロジー工学」の書籍を出されている。
　TOVEをはじめとするエンタープライズ・オントロジーの研究も紹介されていて、
　なかなか面白い本だ。
　　http://www.amazon.co.jp/exec/obidos/ASIN/4274200175/

　他にも参考になる書籍があったら、下の本棚に追加してくれ。
　　http://www.hondana.org/SemanticWebA1F5Ontology/

2. OMG Japan の鈴木純一氏 (たぶんお知り合い？)が、
　 Computer Today誌あたりに、分散オブジェクトとオントロジーに関する記事を連載していた。
　 バックナンバーは、編集部に問い合わせるか、八重洲ブックセンター/書泉(神田)/紀伊国屋
　 あたりで立ち読みできると思う。

3. SRA先端研の青木さん、ODIの河合さん
　 言葉は違えども、似た概念を語っているのではないだろうか(推測)

4. 共立出版のbit別冊「協調プログラミング例題集」
　 中島秀行せんせ、松原仁せんせ、本位田せんせ、が編集した本に、
　 英国留学したバカが名詞句抽出法によるオブジェクト設計の論文を書いている。
　 これが、俺のオントロジーの原点。当時は、デムパっぽいと思った。

個人的には、
数理論理学により基礎付けがなされた
・カテゴリー文法
・タイプ理論(型理論)
ってあたりから追っかけていくのが正道だと思う。
ただ、上記分野は既に色々研究されているから、
新しい要素を付け加えないと、(いろいろな意味で)難しいと思う。

ルールベース・システムや数式処理の知識表現について、
カテゴリー論、特に圏と関手のアイデアが重要だという人も居る。

　http://science3.2ch.net/test/read.cgi/sim/1011102458/520
　

「80年代の人工知能の知識表現」としては、
　・述語論理
　・意味ネットワーク
　・Minskyのフレーム
が有名である。

これらは同じような知識表現力を持つ。
中でもフレームはその判りやすさ、扱いやすさ、
そしてオブジェクト指向との類似性から、盛んに活用された。
　　例） 知識ベース、エキスパートシステム等

しかし、現在ではフレームという単語を聞く事は滅多になく、
また上記のフレーム応用アプリも、(ごく一部を除き)滅多に見かけなくなった。

一体、フレームにはどんな問題点があったのだろうか？
そして、知識表現はどのような進化を遂げたのだろうか？

・・・オブジェクト指向は類似の一言で片付いちまった　orz

>>432
述語論理って、属性がたくさんついたオブジェクトにそっくりだよな。

意味ネットワークって、概念と概念の関係を表現するものだから、
RDBのリレーションや、UMLの関連とクリソツだな

論理とオブジェクトって、一体どんな関係があるんだろうね。

とりあえず、オブジェクト＝OO言語の型と限定すると、
型理論と論理体系の対応を示す、カリーハワード同形対応ってのがあるけどｗ

うへ。間違えた。

とりあえず、オブジェクト指向のクラス＝型、と限定すると、
型理論と論理体系の対応を示す、カリーハワード同形対応ってのがあるけどｗ

>>437
それって、
直観主義論理と、型付きラムダ計算(例えばML等の関数型言語)の対応関係でそ。

　　命題 　　　　　　⇔ 型
　　証明 　　　　　　⇔ コード
　　証明正規化　　⇔ コードの実行
　　証明の正規形 ⇔ 値

例えばプログラム抽出やプログラム検証の世界では、有用だと聞いている。
だけど、述語論理とオブジェクト指向を語るには、ちょいと抽象的過ぎるような・・・

手続き的な計算には、λ計算という良くできた理論がある。それを拡張して、
オブジェクト指向のための、オブジェクト計算(Object calculi)を提唱する人達がいる (Abadi & Cardelli)

と、ここまでは、何度か２ちゃんで説明した話ですね。

>>438
要するに、ラムダ計算の話を、オブジェクト計算に置き換えればええんでないか、という・・・

ようやく >>232 当時の話題に復旧したね

>>429
そこまでムキにならなくとも・・・
彼の同窓にはオントロジー工学のせんせも居ることだし・・・

>>432
知識表現として、>>431に書かれてる
　・プロダクション・システム (ルールベース・システム)
が抜けてるぞ

プロダクション・システムは、
階層構造なし、追加削除の可能な
単なる if〜thenの羅列だからなぁ〜。

人間の判断の、シンプルな第一近似解だと思う。
知識表現として議論すべき事はあまりないんじゃないかなぁ〜。

ちょっと読みにくくなっちまったな・・・

プロダクション・システムとは
人間の「判断」の判断に関わる知識処理を、
シンプルにモデル化したものに過ぎない。

短期記憶と長期記憶のモデルは持っているが、
知識を階層化したり、適用可否を判断したり、優先順位を与える機構は、
含んでいない。だから、いろいろ拡張して遊ぶ材料にはなったんだろうけどｗ

× 人間の「判断」の判断に関わる知識処理
○ 人間の判断に関わる知識処理

相変わらずｓ好きくんは、２ちゃんのスレも仕事も中途半端だなｗ

>>428
おーい、某スレでおまいさんに呼び出しかかったぞ。
こい

>>448
どこのスレのどの批判だよ。明示してくれ。ﾏﾝﾄﾞｸｾ。('A`)

ん？おまいさんが２月まで役員やってて、３月から顧問になった会社

漏れはそんなにえらくないよ。人違いだな。ｽｷｰﾘ

工エエェェ(´д｀)ェェエエ工
ありえん

偽者はほっとくとして。

>>428は研究進んだのか？

漏れが>>428だったんだが、特にあれに関して今は研究はしてないぞ。学生時代はやってたが。
前から抱いてた疑問をぶつけただけだ。

暇あればオントロジー工学とやらを追いかけたいがもう歳ってのもあるしきついなー。

でさ、おまさんの粘着、いい加減にしてくれないかな。
はっきりいって迷惑なんだけど。

仲間由紀恵って異常にかわいいよな

前スレで出てきた話題

388 名前： 非決定性名無しさん 投稿日： 05/02/01 01:03:41
　オブジェクト指向の問題点は、静的な状態を強く求める事だと思う。
　
　例えば時間的の経過や周囲の状況変化の発生があっても
　オブジェクトの外郭を守らねばならん。
　これが結果的にオブジェクトがオブジェクトとして存在しえる為に
　静的な状態を強く求めてしまう本末転倒な状況に陥る。
　
　って思っている私は、まだまだ未熟ですか？

これ(前スレ388　http://science3.2ch.net/test/read.cgi/infosys/1042967631/388)について、
実は前スレ389-396 (http://science3.2ch.net/test/read.cgi/infosys/1042967631/389-396)で書いた以外に
案があって、それは中島秀之先生著 Prolog/KRに載っている多重世界機構だったりする。

今日、Web上に良い要約が見つかったので、ここにも書いておこう。。。

　-------------------------------------------------------------------------------
　知識表現システムUranus と多重世界機構　
　http://www.techno-qanda.net/dsweb/Get/Document-7403/443b.pdf

　(前略)
　述語論理の限界
　Prolog は論理型プログラミング言語の代表的なものであるが，知識表現言語としてはい
　くつかの欠点がある。主なものとしては
　　・状態の変化が素直に表せない。
　　・概念の階層構造が素直に表せない。
　　・不確実な知識や，例外が扱えない。
　などがある。これらはそのベースとなる一階述語論理の欠点をそのまま引き継いだものである。
　Uranus ではこの欠点を取り除き，自然な知識表現を許すように多重世界機構を導入した。
　(後略)
　-------------------------------------------------------------------------------

当時学生やってた俺は、「え？これが博士論文の核心なの？トンチみたいな話だなぁ」
と思ったりもしたが、問題提起の２番目はオントロジー工学、３番目は様相理論あたりに発展した。

その後就職して、
・時間発展するオブジェクトという課題を考えた当時(前スレ389に説明)も、
・HaskellのMonadicプログラミングの話を聞いた時も、
中島先生の多重世界機構の話が頭にこぶり付いていて、なんかスッキリしない感じがした。

そして昨日、後者(Monadicプログラミング)は関数言語プログラミングでこれまでも繰り返し使われてきた
イディオム(or デザパタ)に過ぎない、という説を読んだ。言われてみるとその通りだ。
つまり、多重世界機構のある側面は、きっと圏論のmonadと同じようなものなんだ。
これで一つスッキリした。

それでは中島先生の問題提起の一番目、漏れの直面した課題の一番目、
に対する解はどのような形になるのだろうか？

もう、オブジェクト指向なんて時代後れだし,
学者の興味くらいしか惹かなくなったな。

以前はその解は、プロトタイプベース言語や、リフレクションあたりだと思っていた。
しかし上記の解は、前提としている問題設定が不充分な気もする。
単にメモリー上のオブジェクトが動的にデータ構造やコード構成を変えるだけでは不充分で、
「変化するオブジェクト」を強く必要とする分野、ニーズとの結びつきが足りないんだ。

そして今、その「ニーズ」というのは、
・一つは開発プロセスや開発分担に沿ったオブジェクトの作成/変更、
・もう一つは、プログラムの複数段階にわたる評価/変更
なのだろうと考えている。例えばAOPとか、Attribute/Annotationとか。よくまとまんねぇ〜

>>460　馬鹿はうせろ

元豆蔵のｓ好きさんは、
・オブジェクト指向のアーキテクチャー面の進歩はもう停滞した
・オブジェクト指向はもう流行の峠を過ぎたから売れない
と主張する事で、何かから逃げ出そうとしている模様です。。。
実際は中身のないオブジェクト指向技術者が淘汰されただけなのにねｗ

おっ、盛り上がってきました。
将軍様バンザイの論理ばかりだ。

結局、空約束をぶち上げて、場を盛り上げるだけ盛り上げるだけで、
その後の責任＝「約束の実現」のための地道な努力を放棄しちまう程度のタマなのね

>>464 ボケナスはすっこんでろ。馬鹿が一人前に発言すんな

北朝鮮の論理とこのスレのオブジェクト指向の論理は似てるよな。

>>460,>>463,>>467 レス削除依頼済み。
ここは言論の自由の国だから、おまえさんの妄言にも発言権はあるが、
スレ違いな発言で議論の妨害をするな。
北朝鮮と中国と島耕作について騙りたいなら、適切な板に言ってヤレ。

>>461で二つの項目に分けて書いたけど、結局今持ってるイメージは一つだな。

(1)開発プロセスの各段階[設計/開発/テスト/配布/デプロイ/運用]に沿った、
　　ソフトウェアの修正やカスタマイズを、ソフトウェア自体が支援する機能
(2)プリプロセスやポストプロセスに代表される、多段階方式のプログラム実行

これらの課題を、「状態変化するオブジェクト」でどのように解決できるか？
・・・荒らし対応してたらモチベーション萎えちゃった。
出張３２は絶対アクセス禁止にしないと駄目だな

>>468
そもそも2chでしか議論できない内容だからな。
将軍様に逆らう奴らは処刑だ。

>>470 レス削除依頼済み

>>461で二つの項目に分けて書いたけど、結局今持ってるイメージは一つだな。

(1)開発プロセスの各段階[設計/開発/テスト/配布/デプロイ/運用]に沿った、
　　ソフトウェアの修正やカスタマイズを、ソフトウェア自体が支援する機能
(2)プリプロセスやポストプロセスに代表される、複数レイヤ/複数段階に跨るプログラム評価/実行
　　・・・ML系言語でMetaMLとかMetaOCamlつうmulti-stageプログラミング言語を見て、これかな？と思った(藁
　　　　 少し勉強して違うようだったら方向修正する（爆
　　

オブジェクト指向の次に来るのはなんだろうねえ
MDAか？あれはまだオブジェクト指向か

こんな時間に荒らすなよクズ

CLPだろう。

「上位クラスの変数に格納した場合，下位クラスのメソッドは（そのままでは）呼び出せない．」
という理由を教えてください。

みんなごめんね☆

何か寂しくなっちゃって全然関係ないこと書き込みしちゃいました。

反省したので明日ボウズにしてきます。

（；＿；）

>>476
上位クラスのprivate変数は下位クラスであろうとそのままではアクセスできないってことじゃない？
私のプログラムではprotectedが多いけどな…正直自由度あげると無限にprotectedが大きくなる…

>>457
未熟ですね
役割分担ができてないってことですから
もう一回最初からモデリングしてみれば？

>>477
あんたいつも坊主頭ですから。

>>479
GRASPパターンが万能だと勘違いしてる？
動的な(時間領域の)問題に、(静的な)役割分担を言い出しても埒が明かんでしょ。
例えば電気回路の過渡現象とか制御理論で、
役割分担が云々と言い出すくらい、場違いな発言に見えてしまう。

>>475
所詮マイナー。BFPがいい。

国内オブジェクト指向業界には、あまりパッとしたのが居ない事が判明したので、
しばらく本業を自然言語処理方面に移す事に致します。

10年前、オブジェクト指向を本業の核に据えた時、
本音としては「オブジェクト指向は擬似サイエンスの臭いがするから嫌」と思ってました。
この10年で随分進歩と普及が進み、海外のコンサルタントにはなかなか興味深い人物が居る事を知りました。
また国内各所で、フレームワークや方法論、その他、を本格的にやって、
世界に存在感を示している人が居る事も知りました。
でも、ずばぬけて凄いって感じじゃないんだよね。大体言ってる事は、こっちも同時期に同じように考えてる。

現在の企業システムをコアとしたオブジェクト指向のあり方は、
おまんま食うという観点では合目的なんだけど、
優れた人々と刺激を与え合いながら、すばらしい仕事を成し遂げるには、あまりに場違いな気がする。

ってなわけでしばらくの間、オブジェクト指向およびその企業システム応用に関する活動のプライオリティを下げる事にする。
まぁ実際５年前から軸足を移す算段してたんだが

BFP: Business and Facility Planning　 http://www.techgroupintl.com/Enterprise_BFP_Full_Brochure.pdf
　　Technology Group Internationalが提唱する新手のERP概念

CLP: Corporate Leaders Program　　　　http://www.clpgroup.com/
　　CLP group が提唱するCorporate Governanceのためのベストプラクティス

ってなとこか。
企業システムにしがみついてて本当に嬉しいのか？
それしかできない人には酷な意見かもしれんが。

>>483
どっちもオブジェクト指向と直接的な関係がない所が、どーしよーもねぇーな

ポストオブジェクト指向の潮流をうまく汲み取れない、敗残者の戯言なのさ。
俺は、ポストオブジェクト指向のコアとなる基礎分野として
自然言語処理に取り組む。
そしてそれは、5年程前に設定したポストオブジェクト指向技術確立プランの一つに過ぎない。

昨日の私と今の私は関係があるかどうかわからない。
さっきの私とも。
これは、結構自然な人間観だと思いますが、オブジェクト指向では
どう捌きますか。

>>486
　>>457へのコメントかな？

近代的な人間観では、成人した社会人には自我同一性が求められる。
これは個人と神が一対一の契約を行うキリスト教圏における個人主義の発達、個の確立に拠る所が大きい。

他方、アジアをはじめとする農耕民族は、農業を協同作業で進める中で、
集団自我とアニミズム的多神教が自然に溶け合う、
協調と阿吽の呼吸を旨とする人格形成が求められた。
そこでは、個人の自我の一貫性は、協調を崩す我侭としてとらえられ、
状況に応じた風見鶏的な行動/考え方こそが、成人の証と考えられている。

やべ。ぼろぼろ。後で書き直そう。
要するに「無責任な人格」って、
農耕民族が自然の変化に対して集団で臨機応変に対応するためには必要だと思うけど、
今の日本人は農耕民族じゃねぇよな？だから、あんまそーゆー人格が役立つ事はない、と勝手に思う。

いや、第二の戦後 (経済の空白の10年〜巨大な国債残高)と呼ばれる現代日本では、
いつもギラギラしてて野心的な70年代日本商社マンみたいなのが是非必要な気もする

>>487 まあ、そこら辺からの展開をふまえて、ということで。

オブジェクト指向が今ほどメジャーではなかった1986-7年頃にPSIの
ESPでプログラミングをしていた。まだ、うぶだったから、人間クラスに
ついて、議論した。
人間クラスにname属性を設定するという人がほとんどだった。
私は人間はそのときそのとき違うのだから、それを重層できないと
いけない。だから、「何の某」クラスを設けるべきだと主張した。

実際には、死刑囚を調べると人格を問うことが無意味なことが
ほとんど、というところに>>486の源泉、いやヒントがあるのですが。
じつは私も何のかわりもないのではないかと。

なんで静的なものでくくるか分からん。

内部で委譲しちまえば、状態なんてどうにでもなると思うんだが…

> ttp://homepage3.nifty.com/satoshis/oo/memo.html

委譲は便利だか・・・

>>492-493
何の話？例によって話が見えないなぁ。

とりあえず>>457の話と仮定すると、問題の本質は次の点にあると思う。
OOのオブジェクトは、現実世界の事象特定の文脈や状態で抽象したものであり、
OOオブジェクトと、現実世界事象は、多対一の関係にある。
従って、オブジェクトの特徴の一つ「Identifibility(識別可能性)」について、
現実世界事象との間で明らかなギャップがある。

>>492の提案はおそらく、内部状態をStateパターンで表し、それにFacadeをつけてカプセル化して、
Facadeレベルで上記の「Identifibilityのギャップ」を解決しよう、という話だと思う。

しかし上記方法では、抽象度や状態による外部ｲﾝﾀｰﾌｪｰｽの変化を、うまく扱いきれない。

　例：蝶の変態
　　　　　　　　　　　　　　　　　　　　　　「蝶」Facade
　　　　　　　　　　　　　　　　　　　　　　ﾒｿｯﾄﾞ: ？
　　　　　　　┌───────┬───┴──┬───────┐
　　　　　　　│　　　　　　　　　　　│　　　　　　　　　│　　　　　　　　　　　│
(産卵)　　　　　　　　孵化　　　　　　　　　　　　　　　　　　　　　 羽化　　　　　　　　　　(死亡)
…→　 「卵」状態　　→　　「青虫」状態　→　「サナギ」状態　→　「蝶」状態　　　　 →
　　　　　属性:　　　　　　　　属性:　　　　　　　　属性:　　　　　　　　 属性:羽の模様
　　　　　ﾒｿｯﾄﾞ:孵化する 　 ﾒｿｯﾄﾞ:ｻﾅｷﾞになるﾒｿｯﾄﾞ:羽化する　　ﾒｿｯﾄﾞ: 飛ぶ

だいたい「状態」という概念はふつー、本来動的な事象を、
静的な状態とその間の遷移として表すものでしょ？

20世紀、小説の世界では神様が私になったり、三人称をどこかから
操っている、そういう世界は揺らいだ。
ソフトウェアの世界では、全知全能であるプログラマの地位は
今のところ安泰だが、それでよいのか。そんなものなのか。

70年代の公共経済学で「人間が暗闇で他者に出会う」。
相手を問い、調べ、知りながら経済的にどんな行動をとるかを
研究する学派があった。全知全能なエコノミックマンへの
アンチテーゼであったのかもしれない。

暗闇で人に出会い、相手を探り、自分に問いかける、
何の前提もなしに。こんなプログラミングはないのか。
こんなことは、30年も前にこの世界以外では当たり前の
ことだったじゃないか。

ない。そして懐古の中にも解はない。

Google万能主義が闊歩する昨今、
Googleでほとんど何も出てこない「自称すごい人」の評価には、
まさに「暗闇で人に出会い、相手を探り、自分に問いかける」が必要だ。

特に求人市場/求職市場ではマーケットプレースモデルが普及しているので、
そんな場面に多々出会う。
世の中必ずしも有能の人が信頼に足る啓蒙ページ/宣伝ページをやってるとは限らないのね、なんちて、てへ(＾＾;

某氏の会社を退職してから、めっきり独立系ｺﾝｻﾙﾃｨﾝｸﾞ会社からのお誘い(注:転職サイト経由)が増えた。
ブランド力を駆使する人と、駆使せずに真剣勝負をする人。世の中Web万能じゃないのねぇ〜なんちて。

ちなみに次はGoogle転職したくて、今はまず実績作り＆名前売りを狙ってる漏れは、
きっとたぶんぜったい「みーはー」(注：おじさん用語。要するに自分ではセンス良いと思っているが
実はマスコミやムーブメントに踊らされやすいひと)でつ。。。。。。
将来は作務衣が似合って手打ち蕎麦を打つnice middleになりたいな（自嘲

>>494
…サナギになるとかなんとかかんとか　言ってる事わからん
だいたいモデリングは簡略化を中心に考えることであって、
複雑化させるものじゃない

卵　幼虫　さなぎ　蝶　あてはまるものは「動く」というメソッドだろう。
状態変化は状態変化を起こさせるものに任せるべきだろう。

難しい言葉や理論をいっても
実際に実装できるのは単純化されたものだけだろうが

まぁ元偽装派遣の使いっぱしりが
こんなこと言っても説得力ないなぁ〜

現在無職だから一日50万で教えてあげるよ。
転職活動つらいなぁ　元偽装派遣会社だと
新卒のとき技術命にならなければよかったorz（大手さよならして中小逝ってしまった…）

現実の事象とOOモデリングのセマンティックギャップを論じている。
もともと対応などしていないし、対応させるのも無理だ、
などという空理空論は、現実的に全然役に立たないんで、
この流れではお呼びじゃない。つうこと。

問題意識の有無が問われているのだよ

>>500
はあ。ｶﾜｲｿだな。

俺って結構引く手あまた。
最近OO/DOAのコンサル２社と、名門SIer数社の担当者からスカウトメールが送られてきた(転職サイト経由だけどｗ)
まぁ俺は業務系は一回こっきりでコリゴリなんで、さっさと研究開発ベンチャーに舞い戻った所。

・・・まぁどこのベンチャのセンセにも「おまぃの職歴、やってる事バラバラだな」という
狭い了見のツッコミ受けるのがちょっと痛いがw　
まあ一般人にはこっちの仕事の連続性なんて理解もできないんだろうな、と開き直ったり。

ボーナス込み/扶養手当て無しで年収100万up、でも自分では大安売りしてると思ってる。
SIerでこっそり企業戦略の中核担ってた(形にしてもらってた)俺としては。

>>501
理学系的お話だなぁ
工学系な私は実現可能を中心に考えてるよ。
宇宙の最果てや生命活動と部室の違いなんて論じたこともないなぁ
疑問はあるがね。

>>502
もう弄らないでください
or2''ﾍｺﾍｺ

>>503
たしかに
根がサイエンス系の人間と、
根がエンジニアリング系の人間では、
ずいぶん意識が違うね。

俺はOOに手を染めた時点で、随分エンジニアリングに妥協してやってるつもり。
普遍的な規則や構造を得るための戦略って、エンジニアの人は弱いね。

>>505
普遍的な規則になんか会ったことないな〜
派遣先でやれる女とやれない女の公式なんて
考えたことないし。
やることは誘う-OKだったら->いれる-うざくなってきた->携帯切る

自分の仕事を一生懸命やらない奴はクズだが、
「鬱病」と称して仕事サボりたくなるほど仕事にのめり込むのは、
責任の限界をわきまえない、自己管理ができないバカだと思う。

・・・つか安易に偽鬱病レッテル張ったり/偽統合失調カルテを出したりする
職場/産業医がクズなんだけどな。

ってお医者やってる知り合いがゆってた

で、結局OOをまともに取り入れてる会社ってどこよ？

>>505
理学屋が構築したジェネリックなルール体系を、
現場要求のさまざまなアスペクトに合わせてカスタマイズするのが、
工学屋の仕事だからな。
理学屋：例外は外出し
工学屋：例外対応
つうヒエラルキー。まるでSEみたい（藁

>>508
IとかFとかTとかガス屋の下請けとか。
おっと、まともに、だったか。
こりゃ失敬。

利楽屋：業務用件なんて糞くらえ、まぁ理想な形だしこれ使え
好学屋：業務用件にあったものを…　理想じゃなくて実用的なものを…ぉぅぃぇ〜♪

>>510
T ？

>>511
漏れはこの10年強で、約三つの(ソフト以外の)工学〜サイエンスに関わったんだが、
結局どこ逝ってもやってる事いっしょ。
理学その他の専門分野でこれまで蓄積されてきた理論に、
観測データの統計処理を加えて
　・確率学習→確率的ルール構築とか、
　・特異値分解でランク下げて多変量解析で内部パラメータ推定
とか、そればっか。

結局エンジニアリングって、一つ良い方法が発見されたら、
あとはそれが陳腐化するまで徹底して使い倒して、新しい手法の誕生を待つやり方なのね。
ってな感じでエンジニアリングの憂鬱を感じている。

そしてもっと憂鬱なのは、サイエンス〜エンジニアリングで成功している確率・統計的手法は、
ソフトウェア工学ではほとんど影響力を持って居ないってゆーこと。(品質周りくらいかな、統計扱うのは)
ソフトウェア・コンポーネントの問題を場の理論で云々なんつうアレな事を言ってる人を約二名見て、
ほとんど与太話に近いと感じたが、そーゆー話をしたがる気持ちが良く判る。
今居る所はコンポーネントじゃないけど、やっぱ場の理論の比喩で実践理論を構築するらすぃ（呆

ねえ、俺が力を発揮できる場所って一体どこにあるの？

〜ステップでバグいくつないと品質管理できんから
バグ報告（捏造）して…







2年くらい前実際に言われた…
正直殴りたくなるような統計はもう勘弁してくれよ…

ああ、10年以上前からSW-CMM推進してる事になってるあそこか。
あそこは半導体とかハードウェアの基礎技術は凄いし、
ソフトもそんなにセンス悪くないと思うけど、やっぱ業界がマズいんじゃねぇの？
COBOLもどきの大規模プロジェクトとか（笑

akon氏のblog更新が2005/7/9でバッタリ止まってしまった件

＃何かつらい事でもあったのか

「くーす」の一件か？

所詮、変人同士の喧嘩。

で、結局まともにOO出来る会社ってどこですか？

>>517
今んとこみたこと…な…い…かも
小規模案件で自動化とOOを組み合わせてうまくいったことはあるけど会社全体では…
大規模だと、仕事してる人のレベルが上で均一にならないかぎり無理なのと
分析・解析、コンサルで業務の流れをうまく描けないとオブジェクト多すぎて死亡する…

>>518
結局上流次第ってことですかな。
元請が出来て、それなりのアーキテクトが居る会社。
さがさにゃならんなあ。。。

それ無理
大規模だとOOは不可能。
大規模だと分析工程も含め、仕様作成まで相当数の人員を必要とする。
これらの人員は各受持ち単位に分けられ作業する事となるが各セクション毎に手直しや見直しも相当数
発生するのは必死。
最初に必要オブジェクトを決める手法は取れないのが実情。
統一性より、開発スピードと1処理当りの安易性を要求され開発ボリュームが膨れ上がることは容認される。
メンテナンス性も安易性を要求されるのであってコストではない。

>>520
> 大規模だと分析工程も含め、仕様作成まで相当数の人員を必要とする。
> これらの人員は各受持ち単位に分けられ作業する事となるが各セクション毎に手直しや見直しも相当数
> 発生するのは必死。

それはOOじゃなくても同じことでは？
必死なのはよく分かった。


> 最初に必要オブジェクトを決める手法は取れないのが実情。

要求分析時にクラス図を書く必要性はないんだが。
ユースケースと、簡単なシーケンス図、必要に応じてアクティビティ図があれば十分でしょ？

> 統一性より、開発スピードと1処理当りの安易性を要求され開発ボリュームが膨れ上がることは容認される。
> メンテナンス性も安易性を要求されるのであってコストではない。

日本語が意味不明なんだが。
これもOO固有の問題点なのか疑問。

話は変わるが、XP手法発祥のプロジェクトは
そもそもユーザ側情報システム部が企画したOO実践のプロトタイプ・プロジェクトだったそうだな。
しかも最初のOOチームの成果は芳しくなくて、
後からKent Beck他が参加してXP手法でなんとか完成に導いたって。
挙句、ユーザ側現場部門としては、OO開発の拡大展開にゴーサイン出せなくて、
結局全部COBOLに戻したって・・・。国内某所で聞いたような話だな（藁

やっぱ、企業システムにしがみつくのはマズイと思う。俺はもう離脱済みなわけだが（藁

>>522
ステップ数が、、、とか言い出すとCOBOLが堅実なんだよねえ。実績も十分にあるわけだし。
でも、OOの大規模案件も幾つか成功事例が出てきて、これからって感じかな。

>>521
> これもOO固有の問題点なのか疑問。
なんの為のOO？

>>523
> OOの大規模案件も幾つか成功事例が出てきて
ひとつも無いでしょ？
聞いたこと無いよ、中規模ですら混迷しているのが実情。

>>524
> >>521
> > これもOO固有の問題点なのか疑問。
> なんの為のOO？
>

日本語読めよ。OOだから開発スピードが落ちたり、メンテナンス性が損なわれたり、意味不明だが安易性とやらが損なわれたりすることはないと言っている。
別に「OOとはこうあるべき」とか、大上段に構えた話してねえよ。

> >>523
> > OOの大規模案件も幾つか成功事例が出てきて
> ひとつも無いでしょ？
> 聞いたこと無いよ、中規模ですら混迷しているのが実情。
>

99年に、誰でも知ってるエアコン屋さんで300人月規模のOO案件成功させましたが？
他にも車屋やら飛行機屋で大規模案件動いてるよ？
あんたの情報収集能力が乏しいだけ。

>>525
それのどこが成功例なのかな？
単に動いているだけ、中身はガタガタ
単にＯＯ使ったよってだけの話で、開発コストもムダに高くなり失敗事例と考えているが。

>>526
> >>525
> それのどこが成功例なのかな？
> 単に動いているだけ、中身はガタガタ

じゃあ、成功例って何よ？
コーディングの１行まで監視しないと納得しないとでも？
中身のどの部分を指してガタガタと言ってるのか、具体例を示せよ。

> 単にＯＯ使ったよってだけの話で、開発コストもムダに高くなり失敗事例と考えているが。

成功か失敗かはユーザが決めること。コストも同じく。
あんたがユーザなら、OO選ばなければいいじゃん。
別に俺は「OOは素晴しい！みんなOOで開発しよう！」などと言った覚えはないが。

もし、開発サイドの人間ならさ、プロジェクト回したことあるの？
従来手法がお好きなら、「単に」従来手法使えば？

従来手法を「使う」だって？
猿SEが従来手法をよく知ってるとでも思ってるのか（ぷ
そんなの、旧世代の品質・生産管理部門の連中が後生大事にしているだけで、
現場の猿SEはそんなのもよくわかってないよ。
猿SEができるのは
(1)上から引き継いだやり方を尊重し
(2)現場で発生している問題に直感と思いつきで対処し、
(3)報告は上が気に入りそうなのを適当に書いて出す
だけだよ。

現場経験少ないヤシはそんな現実も知らないのだろうけど。

>>528
めっさスレ違い

>>528
あんたが猿さってことはよく分かった。

>>528
さ、お前さんの現場経験が豊富だと言うことはよく分かった。
以後のレスはこちらへどうぞ。
http://science3.2ch.net/test/read.cgi/infosys/981101071/l50

間違えた。こっちだった。
http://science3.2ch.net/test/read.cgi/infosys/1093664987/l50
お猿さんには最適なスレですよ＾−＾

>>528
ほれ、もうお終いか？無職くん。

517 名前： 非決定性名無しさん [sage] 投稿日： 2005/07/20(水) 00:10:22
518 名前： 非決定性名無しさん [sage] 投稿日： 2005/07/20(水) 01:04:56
519 名前： 非決定性名無しさん [sage] 投稿日： 2005/07/20(水) 04:04:21
520 名前： 非決定性名無しさん [sage] 投稿日： 2005/07/20(水) 06:28:26
521 名前： 非決定性名無しさん [sage] 投稿日： 2005/07/20(水) 13:51:49
522 名前： 非決定性名無しさん [sage] 投稿日： 2005/07/20(水) 22:14:15
523 名前： 非決定性名無しさん [sage] 投稿日： 2005/07/20(水) 23:51:45

524 名前： 非決定性名無しさん [sage] 投稿日： 2005/07/21(木) 13:06:46
525 名前： 非決定性名無しさん [sage] 投稿日： 2005/07/21(木) 15:24:00
526 名前： 非決定性名無しさん [sage] 投稿日： 2005/07/21(木) 22:27:28
527 名前： 非決定性名無しさん [sage] 投稿日： 2005/07/21(木) 23:08:58

528 名前： 非決定性名無しさん [sage] 投稿日： 2005/07/21(木) 23:19:36
529 名前： 非決定性名無しさん [sage] 投稿日： 2005/07/21(木) 23:26:45
530 名前： 非決定性名無しさん [sage] 投稿日： 2005/07/21(木) 23:30:29
531 名前： 非決定性名無しさん [sage] 投稿日： 2005/07/22(金) 05:50:50
532 名前： 非決定性名無しさん [sage] 投稿日： 2005/07/22(金) 05:52:38
533 名前： 非決定性名無しさん [sage] 投稿日： 2005/07/22(金) 21:27:42

(ﾌﾟ・・・もしかして暇なの？

最近、昼飯〜晩飯がむちゃくちゃ豪華になった。
昼はオフィス宅配特製弁当、
夜は六本木〜赤坂で呑ペリ。

・・・こんな生活が長く続くとは思えないが、
長い間苦労しすぎて「ジャパニーズ・ドリーム」の方向性を見失ってしまった漏れには、
とっても素晴らしい「つかの間の夢」だ。

・・・つか俺の師匠もコレで民間にデューダしちまったんだよな、剣呑剣呑

どこもかしこも、JavaJava言ってるけど、結局まともなOO使いは居ないってことで決定？

いや、まともなOO使いは結構居るし、またそのように教育環境も整備されつつある。
問題の本質はそこではなく、思考統一が難しい現実を無視した適用範囲を主張するバカが多いのが本質。
所詮、個人プレーでしかないことに早く気付いてくださいな。

大規模開発に埋没して、個人ﾌﾟﾚｰをうまく生かせないアンタが哀れ。
つかこんな話題やってると、また>>529-533が暴れるんじゃねぇの？
業界外のバカは、「OO」という単語入って無いとスレ違いと「感じる」らしいし（嘲笑

>>537
要するに、まともなOO使いに対して個人プレーを許さないorなんでもかんでもOO使えYO！ってな無茶な体制でプロジェクトが動いていることが悪いと？
OOに限らず、優秀なPMが仕切ってる案件の成功率が当然高いってことかな。
フレームワーカー、アーキテクト、その他メンバー的な役割分担がきっちり出来れば現実的になってくるのかもね。

ま、猿SEがどうこうってのは、漏れもどうかと思うが。

>>536-539
お早う。ニートの諸君。
深夜に書き込みご苦労さん。
業界人になったつもりで妄想ですか（藁

>>539
あい、そんなところですね。

俺が今まで知ってる中で一番出来の良い出来る系SEのオヤジがいた。
目の前の現象・問題点をたった一人で独自の視点で整理整頓する天才だった。

・わかりやすいイラスト入りの文章で企業業務を含めた問題点を表現し、
・企業の業務・生データを言葉の定義の明確化・ルール化のコードブックを作り
・現状システムのデータ一覧を独自分析ツールで解析し新システムとの整合性の問題点を明確化し
・新システムの概要を速攻でプロトタイプシステムを作り、エンドユーザを巻き込み見える形でモデル化し
・システムそのものの仕様・考え方・イメージ・用語が上流工程が実に整理整頓されていた。

要は誰でもわかる視角化・言葉で問題点を整理できる達人だった・

その後の開発もスムースに行き、周りのデスマーチプロジェクトに比較したら遙かに現場から
高い評価を得て、低コスト、短納期で収束できていた。部下の一人として、その仕切を見てて
見事だな〜と思った。今、この手の本物系の職人SEは少なくなった。

それに引き替え、このオブジェクト指向とやらの言葉を振り回す人間は現実には
デスマーチプロジェクトのオンパレード化してたような気がする。
所詮、手段としての開発手法が頭でっかち君の机上の、エンドユーザ不在の、
非実用の言葉遊びの世界止まり?

一部の天才が作ったDELPHI、VB、C#といった現実的な開発ツールの大進化は素晴らしい。
これはCOBOL、FORTRANで育った我々年配者でも感動した。ちょっと勉強すればすぐに使えた。

一時、鳴り物入りで今は跡形もない第五世代AIプロジェクトやシグマプロジェクトのような
難解用語オンパレード文化の臭いを感じるのは俺だけ。
　　　　　　　　　　　　　　　　　　　　　　　　　隠居リタイア者の戯言許してね。

> 要は誰でもわかる視角化・言葉で問題点を整理できる達人だった・

はい、ご名答。
一番大事な視点はそこにこそある。
ＯＯによる抽象化でも、階層構造でもない。

概念を正しく伝えることこそが最も大事であり、目的を明確にすること。
そしてそれ等を具現化する為の方策を説明できること。
方策を読むべき人に必要なのは、それを理解出来るだけの経験と知識だけ。

これこそが多くの人を自立的に意思統一する為の手段となりえる。

>>542 同意。

オープン世代の一部のVisual開発ツールは劇的な生産性向上に寄与したと思う。
それに比べたら基本的な問題解決技法はむしろ日本の学力と同様に低下している事は確実。
若い世代が促成栽培のシェフよろしく基本を長年の時間をかけて身につける環境に無い事が原因。
要はジャガイモの皮むきや魚の基本的な卸方を教わらずにレトルト商品を組み合わせた飾り付け料理の
ような仕事ばかりやってるからだろう。

客先の運用現場で修行する経験もないから、お客様との基本的なコミュニケーションや業務知識を
感覚で身につける経験もさせてもらってない。　
表面上の技術進化は一部の天才がつくったインフラ面だけだ。

現状を見ると実務の開発は多重派遣の下請けに丸投げの"なんちゃってシェフ"みたいな自称高技術者
が蔓延っている。個人差はあるが、特にSIerや大手メーカにその傾向が強い。

ビンハネ、やらされ仕事に甘んじている薄給・派遣エンジニアをこき使うスキルだけでは悲しすぎる。

ははは、同感だな。
オブジェクト指向って言う上澄みしか飲みたくない若者ばっかりだからな。

抽象化による伝達は、伝達精度の向上に寄与することは確かなんだけど
それはあくまで、伝達する側の方策の詳細でしかない。
結局、本来の概念や目的の伝達ではないから、その情報から本来の概念や目的を
読み取るのはかえって難しくなるし、その表現に業務上の重点や基本事項は含まれない。
つまり、その伝達で動けるのは抽象化手法を身に付けたロボットだけであり兵隊でしかない。
自立的に意思統一する必要が無く、言われたままの作業を繰り返すには適しているが、
規模が大きくなると、指示する分量が圧倒的に膨れ上がる為個人でその指示を行なうのは
不可能となる。
ここに大きな落とし穴が待ち受けている訳で、受け手がいかに優秀であってもそれを補うこと
はできない仕組みであり、強引に補うと複数の抽象化した情報が飛び交うこととなり歪になる。
よくよく考えてみれば、抽象化で業務知識の不足と経験の浅さを補うことなど不可能な訳で
それ等を必要としない兵隊だけに使える手法でしかないことに気付く。
たった一人で、数千本〜数万本の仕様を短期間で固めることなどどんなに優秀でも不可能。
大規模システムにＯＯが使えないのはそんな理由だ。

>>546
> 抽象化による伝達は、伝達精度の向上に寄与することは確かなんだけど
> それはあくまで、伝達する側の方策の詳細でしかない。

激しく同意。抽象化することによって不可逆性のみが膨らみ、結果要件の本質を抽出するコスト？てのも変な言い方だが、回り道をしてしまう感がある。
思想だけ立派で、ユーザに取って意味のないゴミシステムが出来上がるってわけだ。

> たった一人で、数千本〜数万本の仕様を短期間で固めることなどどんなに優秀でも不可能。
> 大規模システムにＯＯが使えないのはそんな理由だ。

実務屋は、ここをどう考えてるんだろうな。理想論としてユーザ側＆開発側のコラボレーションってのはよく聞く話だが、実現した例ってあるのかな。なんか日本式システム文化では絵に描いた餅でしかない気がする。
各論的にOOを適用している例があるのは分かるが、それは単にJavaJava踊らされている一過性の流行に過ぎないのではないか。
俺もOOの達人は何人か知ってるが、彼らが同時に業務屋としてのプロであるとは到底思えない。学術的にOOが美しいことを主張されてもな。
ここいらで、UMTP関係者の登場を期待したいんだが。

>>547
大規模システムを開発する場合、最上流では少数者による、実情分析と目的の明確化であり
詳細機能は適用範囲で実現可能か否かの判断を下す程度にとどめる。
（もちろん分析者が優秀であれば、その適用範囲の見極め精度が増す）

これらを要件定義としてまとめ、それを各サブシステム担当者へ伝達することになる。
各サブシステム設計者はそれらの要件を踏まえた上で開発に必要な方策を考え決定する訳で
経験と知識が必要となるが、自立的に意思統一が巧く機能する要件を揃えることでスムーズな開発となる。

結局、最初に方策ありきって思考に落とし穴が待ち受けていただけのこと。
まぁ、結論から言わせて貰うと方策なんてもっと下流で決定すれば良い。（所詮その程度のものでしかない）

さてと、これらを踏まえて大規模システムにＯＯを適用するとすれば、最上流は元々不可能であり、
各サブシステムからの導入が精々であることが読める。
もちろん、不便的概念項目も存在するからそれらのみに絞り最上流への適用は可能だが多くを期待すべきではない。
更に、各サブシステムと言えど巨大であったりするから適用フェーズがばらけるのはやむなしってところだろう。
そうすると、本来の一貫性はある程度犠牲にすべきでありそのこと明確にすれば良いだけ。

ただ、残念なのは一貫性の喪失＝ＯＯの売りの殆どを捨て去るイメージが濃い為、それに反発するバカが多く
中々巧くいかぬ。

>>548
分かるなあ。大規模で最初から書ける図なんてたかが知れてる。
それよか542の言うように、業務屋として優秀なＳＥが上流に立ち、サブシステム辺りからOO的な分析・開発を導入すればスムーズにプロジェクトが進む。
実際に大規模案件の例を見ても、そのスタイルが採られてるね。
まあ、大規模の場合１社で受けられる体力のある会社がそもそもないと言ってもいいと思うので、サブシステム単位で各社受注ってな感じになるわけだ。
ずっと下流に行ってから、「ああ、あんたのとこも（笑）？」ってな光景をよく見た。
そのくらいで満足してくれないかね？＞OO屋さん達

抽象化がダメという議論を、
具体性の乏しい抽象議論で展開しているあたりに、
本質的なダメさ加減を感じた。

また、議論があちこち蛇行している割に、
アレがダメ、コレがダメって逝ってるだけで、
自分自身の確固たる信念が垣間見えないあたり、
なんでも適当が大事という中庸なSEの姿が垣間見えた。

>>550
人はそれを「メタメタ議論」という。

こういうときに「メタメタ」って言うのか
勉強になるなぁ。

システム開発は客を取り巻く"現場・現物・現状・現実"を正確に把握し、金・時間・人という
制約条件の中でいかにバランスをとって着地するかが腕の見せ所。

「オブジェクト指向大好き屋さん」は自分の理想とする方法論に執着する割には
上流工程、お客さんのドロドロの業務に入る姿勢・能力が弱い。
設計・プログラミングその物も部品化・再利用を意識しすぎる為に結果的に解析しずらい
こねくり回した解析しずらい形になり、結果的にバグを産む気がする。

業務に強い現場感のあるプログラマは誰が呼んでもわかりやすい業務密着なシンプルなコードを書く。
この離職率の高い業界では他人が簡単に保守できるシステムは最重要要件。

開発手法が何であれ、結局優秀なSEの仕事って実態は泥臭い作業の積み重ねだよ。
551は中庸と言うが、＝554の言うバランス。
中庸の得と言う言葉もあるから、誉め言葉と取っていいのかな。

俺は実際OOも使うが、今はPMの立場に立っている。
重要なのは要件定義の部分でいかに良い提案が出来るかと、安全にプロジェクトを完了まで導くか。
泥臭い作業をきちんと積み重ねれば、デスマにもならんしお客さんにも喜ばれる。

幸い優秀なメンバーに囲まれているので、大過なく過ごせている。
ここで批判されてるOO屋ってのは、結局は実務に不向きって欠点を指摘されているだけじゃないの？

じゃあ、はっきり言うわよ。
あんたの話題はスレ違い。
OOにコンプレックス持って、
OOじゃプロジェクト管理できないと主張するなら、
別のスレ立てて議論したらどうなのよ？

わざわざオブジェクト指向スレで議論すべき内容ではないと思う。

所詮一匹狼ってのは、荒野で一匹で生きる能力もなく、
集団のまわりをウロチョロして「俺様の生き方の方が正しいんだもんね」
とか負け惜しみを言うだけの存在なんだね。

>>556〜 "はっきり言うわよ"と来たもんだ......

婚期を逃したヒステリックＯＯオバサンのご登場か。それともネカマ香具師か?
盛り上がりの予感。しかし論点が飛ぶ、飛ぶ。
細木数子くらいの気合いが無いと実務指向のカキコを論破できんぞ。

ガンガレ

一匹狼ガンガレ（藁

>>556
ＯＯの問題点を挙げるとスレ違いと言われてしまうのは心外なんだけど・・・
抽象化の良さが全ての場面に適している訳ではないし、複雑化すればするほど
正しく伝える良さはあるけど、間違いもそのまま伝達されてしまうし、なにより間違いであることに気付けない
問題を内包している。

世の技術者の多くは、別に複雑な事を言いたくて複雑な事を逝ってる訳ではなく、
自分の頭の中にある明確なイメージを、相手が想像可能な形で伝える為に、
言葉を尽くし表現を尽くして説明をする。
時には自分の中で解答が出ておらず、自分の理解している範囲を相手と共有して、共同で問題解決にあたることもある。

ところがP2Pな会話(自分と相手の間でのみ成立するような問題共有)は
自分と相手のコンテキストに強く依存するため、えてして第三者には理解しにくいものになる。

このようなコンテキスト非共有に起因する判りにくさを解決するには、既知の共通概念との関係を説明したり、問題領域の記述方法の統一を図ったり、議論や問題解決の手順(プロセス)について同意を取ることが重要である。

そしてシステム開発のうち、ソリューション側(情報システム側)の同意を形にしたものがSA/SD, DOA, OOなのである。

上のレスで抽象化にケチを付けている人物は、業務側の問題とシステム側の問題を味噌糞一緒にしている点が「頭悪そう」に見える。

↑と間違いである事に気付けない視野狭窄で業務コンプレックスのＯＯが叫いております（藁

相変わらず会話が成立しない人だな。
まぁ土方系業務屋の存在自体、忘れておいた方がシヤワセだから、どーでもいいか（ﾜﾗ

まぁ、世の中には
・情報システムで解決したい問題領域(業務領域)
と
・情報システムによる解決方法領域(ソリューション領域)
があること、
更に、前者にも
・スッキリ問題定義できる領域と、
・そもそも関係者が問題提起できていないためにドロドロになっている領域
がある事くらい認識しておいた方がいい。

そして、業務領域のうちドロドロな部分に拘泥したい人は、
きっと物事を曖昧にして玉虫色解決するのが大好きなんだろ？図星☆

業務側の問題とシステム側の問題に区分けできないと言っているのが何故理解されないのか・・・
分けて考えれるのはもっと下流の話であり、業務知識等を必要としない単純労働者クラスへの伝達。

> 物事を曖昧にして玉虫色解決するのが大好きなんだろ

玉虫色解決に結果としてなってしまうのは単純思考での結果。
つまり、ＯＯに頼った開発を行なうと基幹部位程度しか整理されていないケースが殆ど。
結果的に下流工程で問題多発し、その場対応だけの玉虫色解決になっているのが現実の情勢ではないかな？

つまるところ、何でもかんでもOOの一点張りじゃアフォってことだろ？
対象ごとに柔軟に方法論を変えられるやつじゃないといけないと。

>>566
だからそれを分けないのが、非合理な考え方だと言っている。
情報システムには、業務面とシステム面がある。
もし業務面とシステム面を密接不可分なものと考えるなら、
別にJ2EEだCOBOLだと言わず、業務改善のための半導体物性でもやればいい（禿ﾜﾗ

まるでイデオロギーのための科学・芸術アカデミーのように
う　さ　ん　臭　い

科学の基本は要素分割と局所最適化。
要素還元主義の限界とか、全体最適化とか言い出すのは、
80年代に流行ったニューサイエンス〜複雑系の影響と思われるが、
その分野でこれといった成果などまだまだ出ていないのが現実。

>>565
> ・そもそも関係者が問題提起できていないためにドロドロになっている領域
> がある事くらい認識しておいた方がいい。
>

そこを整理して見える形にするのが、まともなSEの仕事ですがな。
ユーザが示した問題しか解決できないなら、方法論以前の問題だな。

> そして、業務領域のうちドロドロな部分に拘泥したい人は、
> きっと物事を曖昧にして玉虫色解決するのが大好きなんだろ？図星☆

ドロドロな部分を放置プレイするのがお好きなのかな。
結論は、567で書かれている通りじゃん。

なんというか。まず、日本語から勉強しようよ。
煽りたいのかどうかも分からん。

被害妄想？マゾ？煽られたいの？
ｶﾜｲｿ

これだけいろいろ書いてやっても(>>561-562, >>564-565, >>569-571)
議論に大切な「共感と相互理解」の姿勢を示さず、
相手を否定する事に血道を上げるとは、なんて不毛な議論だろう。

こんなんで「業務系が大切」とか言っても、全然説得力がない。
所詮お客さんに上から物言って、お客さんをコントロールする形でしか仕事できないんだろ？おまえさん（ﾜﾗ

否定的な議論相手には、
とことん肯定的な同意を示す。
それでもなお否定的ならば、
それはその人物が
相手を否定する形でしか仕事をできないのだと思う。
ｶﾜｲｿ

>>575
それって、２ちゃんの煽り専従者 (なんとかいうコテハン)と被るな。

・板やスレの主旨を無視して、板違い/スレ違いの意見を延々書き続けるが、議論に一貫した主張がない。
・思い余って意見すると、「自分の全人格が全否定された」という被害妄想でもって、
　相手をしつこく否定する。

所詮、妄想上のオブジェクト指向開発に根拠を置いたOO否定論者と、
土方業務系を毛嫌いする数理科学分野のエンジニア、
お互い議論がかみ合うわけがない。

>>577
なんでそうなるの？
>>548にも書いてあるとおりＯＯを巧く使えと言っている筈なんだが・・・
無茶な適用範囲を主張してしまうことに問題があるのでありOO自体に欠陥があるわけではない。

>>578
脳内OO論者の特徴を顕著に現してるだけかと。
ていうか、粘着してるの一人だけだから、もうスルーしようよ。

他人と会話のできないつくづく可哀想なヤシだな。

>>548のような考え方は、

現在企業で導入されつつある別の手法
--すなわち、企業が経営戦略〜IT戦略〜情報システム戦略〜開発・運用方法まで、
各利害関係者の役割分担の概略を決め、
それを以って企業情報システム〜企業全体をも統治しようとするやり方

--と比較して、ごくごく狭い領域しかカバーしておらず、
さらに悪い事には、開発をウマく進める方法の具体的説明ではなくて、
ウマくいっている状況を別の言葉で表現しただけに過ぎないため、
説得力をまるで持たない。

まぁ企業システムの末端で上流工程をいくらやっても、
この程度の知見しか得られないのかもね。俺は中心に居たので、ね（ﾜﾗ

そうそう。
第一に企業情報システムのキーパーソンは、必ずしも現在の経営者、投資家だけではなく、
・情報システムを通じて未来の企業掌握を狙う情報システム担当者、
・生産システムや流通システム、営業支援システムの改善を通じて
　各部門での実効的な発言力を行使し、ゆくゆくは未来の企業掌握の布石としようとする
　各部門担当者
・それらの権力者の下で、実際に情報システムを使う従業員
等々、様々な思惑を持った利害関係者が居るという認識こそ、重要だ。

第二に情報システム構築は、各利害関係者が各々の視点で主張する「我侭」をうまく調整し、
システム実現を通じて企業の経営への寄与を実現するという、
情報システム担当者の影響力行使の場である、という認識こそ重要だ。

上記二点を認め、企業情報システムの主要登場人物が出揃ってから、
はじめて「開発」に焦点が当たり、脇役としてSIerや協力会社が登場する。
>>548の話は、それ以降の話に過ぎない。

>>581-582
なんか必死に反論しようとしているようだけど、私にしてみれば君の意見は無価値だよ。
私はスーパーでもなく単なる設計者でしかないから興味ある範囲は狭い。
自身の守備範囲をこれ以上広げるつもりの全く無い。

まぁ、一言でいわせて貰えば「そんなのどうでもいいな」ってことです。

盛り上がってますね。

>583 は >577が見抜いたような
"土方業務系を毛嫌いする数理科学分野の机上エンジニア"とお見受け。

システム開発で一番困るのは自分の守備範囲だけしか興味が無く(業務に激弱)
自分のやり方に固執するコミュニケーション力の無い香具師。

まあ、変動要素の少ない楽な事しかしたくない気持ちは分かるけど企業の中で
しか使い物にならないリストラコースになりそうなタイプではあるな。

>>576
ﾋﾟﾝﾎﾟｰﾝ！
大正解だったな(ﾜﾗ

>>584
盛り上がってるように見えて、参加者は３人。
・537
・ヒステリックOOネカマ
・煽り粘着無職君

現実ってそんなもんだよ(´-ω-`)

> システム開発で一番困るのは自分の守備範囲だけしか興味が無く(業務に激弱)
そうなんだろうか？
そこ等に転がっている会計士や似非コンサルより私のほうがずーと知識豊富だったりするけど・・・
SEの守備範囲は君が考えているより遥かに広いよ。
っというか、>>582で挙げられているそれ以外の職種より遥かに守備範囲は広いということを伝えておくよ。

もはやOOの話ではないな。

ＯＯに付いては既に決着済みかと・・・

では・・・

＝＝＝＝＝＝＝＝ 終 了 ＝＝＝＝＝＝＝＝

なんだ、やっぱ>>537はあきめくらだな。
>>582の情報システム部門ってのはユーザー企業SEの巣窟なわけだが（ぷぷぷ

1000億円クラスSI企業の技術戦略担ってた漏れ様があえて相手すべきタマじゃなかったな

俺は100000000000000億円クラス☆

(　 ﾟДﾟ)⊃旦 < 茶飲め

と丸投げ屋さんが叫いております

なんとかいうコテハンが、唯一このスレなら皆に相手してもらえてると錯覚して、
見当違いなレスを連発する痛いスレ。

> ユーザー企業SE

はっきり言わせてもらうが、ＳＥとしては落ちこぼれじゃないかな？
たった1企業で長期に渡り何を習得しようというのかな？
精々、不毛なメンテナンスと不合理な要求を無意味に押し付けられ綻びを緊急処置
しつつボロ布を被せて不合理要求に答える日常だろう？

まぁ、その分はマシンパワーで対応というところか？
2年も居れば飽きてしまう環境だぜ。

もっと多彩な案件を多くこなせる職場に早々に移る事をお奨めするよ。

と多重派遣の下層SEが叫いております

>>537 相変わらず文章読解力が低いな。
しかも根拠のない自信で相手をたたく文章しか書けねぇし。
あんたの精神生活の荒み具合がにじみ出ているな。

>>598
いや、根拠無いと言われてもねぇ。
現実に今まで打ち合わせをして来た100名を超える企業SEの全てが
経験不足であり能力不足な人達ばかりでしたし、そもそも1企業だと業務要件も
その企業の特色に限定され多くの手法や手段に触れる機会すら無くなるから
バランスのとれた設計など不可能なんだよな。

根本的に発注側も明確なシステムイメージが無い。
業務の問題点も整理されていない。
そもそも彼らは企業全体からみたら業務知識・経験の無い非主流の二流社員。
当然、権限も経営的な視点も無い。

受ける側のSIerも業務知識欠如。
具体的なプログラミングも人任せ・丸投げ文化で育っているので根本的な技術力無し。
設計とか手法と称して机上の玉虫色のドキュメントや難解用語を量産するしか能が無い。

　　明確なのは限られた予算と納期とデスマの結末だけ。

こういう状況の中では、>>542 で書いてあるようなバランスの取れたリーダが
不可欠。

土方業務系を毛嫌いする数理科学分野の自称高級OOエンジニア様は変動要素の少ない
小規模の自己完結型の仕事を探すしかないと思う。

↑これが現実。また一度できあがったシステムは世の中の変動と相まって
グチャグチャに変化対応が生じる。新しいDB項目追加やらIF文のNESTのような
例外対応のオンバレード。そのコードをいじるのが中途半端なスキルの下請けプログラマ。

システム想定外のデータも本番稼働後に怒濤のように発生する。

この中で唯一の救いは本当の天才系が作ったVisual系のoo指向の開発ツール。
これは開発案件の中の、とりわけ分析系に使うと非常に高い生産性を発揮してくれる。
誰でも保守できるデータ特性に対応する、優しい、素直な書き方なら貢献度は大。

ヘドロまみれのどぶ川の世界に「汚いの嫌い」と言わんばかりの清流好きのカジカやイワナが
数理科学分野を愛する自称高級OOエンジニア様。あいもかわらず自分独自の清流の世界で
自分だけわかったつもりの中途半端な高級概念、言葉を振り回すだけの浮いた存在になる。

おれは不幸にも、中途半端なOOエンジニアしか見たことが無い。
実務能力に溢れ、上流工程から仕切れる本物系の高級OOエンジニア様に
一度でも出会えば考え方が変わるかもしれないが。

>>601
> おれは不幸にも、中途半端なOOエンジニアしか見たことが無い。
> 実務能力に溢れ、上流工程から仕切れる本物系の高級OOエンジニア様に
> 一度でも出会えば考え方が変わるかもしれないが。
>
まあ、なんというか昼夜問わずお盛んなグチャグチャスレになってしまったが、この部分に関しては同意できるな。
業務屋としてのプロが正しくOOを学ぶチャンスが増えれば、高級OOエンジニアが生まれる可能性はあるのだろうが。
現実には、有能なエンジニアほど日々忙殺されるだけ。

逆のパターンはほぼ考えられないね。OOエンジニア⇒業務のプロに成長する可能性は限りなく０に近い。

業務屋反吐吐きスレ

>>599
で、100名超の企業の中に売り上げ1000億クラスは何割あったの？（ﾜﾗ

なんとかいうコテハンが、まともな回答などできるわけないだろ？
お前は何を期待してるんだ？

主張に一貫性の無いバカが、
負けず嫌いの妄想を吐き散らして、
議論だけじゃなくリアルにも破綻していくのを
眺めているだけ。

確かに「事務系業務SE」以外はクズだと言わんばかりのﾌｧﾋﾞｮり具合、
傍で見てて笑えるな。
受託開発・開発支援・業務請負しか出来ない人って、本当に可哀想だと思う。

>>604
大規模だと凄いとかの妄想でも持ってるのか？
実務経験が乏しいか全くない人は、勘違い多いんだよね？

でまぁ、お答えすると８社だね。

注目ｽﾚになってきたな。
とりあえず、ｱﾘｴﾅｲ時間帯にﾚｽしてる奴をこっそり見守ろうっと。

それ、上から何番目の下請け業者として入ったの？（藁

>>609
はぁ？貧乏な人は発想も貧しいな。
今日は赤坂でチャイニーズVikingつう予定だったんだけど、
スポンサーにすっぽかされて早引けした所だが何か？

今一番興味と関心を持っているのは、研究開発集約型ベンチャーでどこまで逝けるか、という事。
10年前の計画では、金じゃぶじゃぶ持ってる運用系SIerを資金源にして企業内で基礎科学の研究をする筈だったが、
J2EEの先走りやってやってもピクリとも反応しない不感症っぷりじゃぁ、ねぇー。
いくら俺達グループの為に売り上げ300億の企業買収してもらっても、先が思いやられるってな次第で。
やっぱ人間として生まれたからには、身軽なフットワークで知性を発揮しなくちゃ、ね？

今日のミーティングはKolmogorovっぽい話だったが、Kolmogorovの名前は出てこなかったんで、今その関係を調査中。
10年前に某分野で扱ってて、後で聞いたら同時期に随分なブレークスルーと応用が花開いたという、なかなか面白い分野だ。
つい二、三日前まで、もう一生その分野には近づけないと思っていたから、ちょっと感動している。

>>611
(・∀・)ﾆﾔﾆﾔ
分かった分かった。1000億円売り上げた企業に昔居て、赤坂でVikingをすっぽかされたんだな。
うんうん。

>>611
お前のことなんか言ってねえよｗｗｗｗｗｗｗｗ
明らかに、夜中３時とか日中に丁寧にレスしてる無職のことを言ってる。
自意識過剰？

まぁ、売り上げ1000億クラスのユーザ企業SEと、
売り上げ1000億クラスのSI企業で技術戦略仕切っちゃうヤシとじゃ、
全然スキルも経験値も活動領域の幅も別物ですよってこった（藁

>>615
> まぁ、売り上げ1000億クラスのユーザ企業SEと、

平凡な中堅メーカーあたりの社内SE

> 売り上げ1000億クラスのSI企業で技術戦略仕切っちゃうヤシとじゃ、

丸投げ屋

まあ、確かに別物だな。

・SI屋や紺猿の作ったxxx戦略とかいう玉虫色のもったいぶった書類に大金を払って幸せになった客の数
・絶滅したと言われている日本オオカミの数

さて、どちらの数が多いのでしょうか?

オオカミの悪寒

なんだ、ここはホントに下っ端ばっかだな（藁
ユーザ企業のための戦略立案？そんなの下っ端の仕事だろ。
俺が言ってるのは、SI企業自分自身の技術戦略っすよ。
じゃあね。

>>619
下っ端どころか、
　　　業界外のキ○○○が
空気読めずに煽ってるだけですから。

ここって何のスレだっけ（藁

>>620
妄想を書きなぐるスレに決まってるじゃん（ﾜﾗ
閣下も毎日下っ端の監視ご苦労さまｗｗｗｗ

>>619の言う SI企業の技術戦略

デスマーチ寸前にしぶとい下請けに責任ごと丸投げせよ。
以上。

あれだな。よくSI企業にある窓際部署。
社内開発とか、儲けにならん仕事をちまちまやってるとこな。
一生懸命フレームワークとか作って、誰も使ってくれないパターンと見た。

>>600
表現が少し歪んでいるけどまぁそんなところかな？
でもさぁ、そんな現状だからこそ我々SEのお仕事が成立しているわけで・・・
ちなみに私がこれまでに設計（概要設計）したシステム数はおよそ80、
この実績が私に多くの活きた業務知識とシステムデザインのバランス感覚を与えてくれている。
それらの背景があるからこそ普通だと気にもとめない実業務者からのほんの小さな囁きから
改善点や現状の問題点を見出すことが可能なわけでそれが緻密な現状分析の材料となる。

>>610-623
ＯＯ関連でもなければ設計者としての発言でない空虚な争いは愚かにしか見えない。
設計者であること、設計者に必要な能力と君達が言い争っている趣旨は全くべつものだ。
SEは所詮職人でしかなく、職人であることに誇りが持てないのなら別の職種を探したほうがよいのではないかな？

↑というふうに営業でもなければ技術力・プログラミングのできる職人でも無い中途半端な企業リーマンが
自慢しております。

そうそうSEって日本のサラリーマンのことなんだよな。

下っ端ガンガレ。
俺は下っ端が何やってるのか知らんが（ｗ

>>625-626
サラリーマンであるか否かも全く関係ない。

>>537
今ナニやってるの？

>>629
ヒント：妄想

>>629
ヒント：この業界では到底通用しない駄法螺の数々

ヒント：発言ﾀｲﾐﾝｸﾞ＝22:30±60分

早くクソスレ埋めちまおうよ

537を含めて、実務屋達の言うことも、まあ一理あるだろう。
実際、論破したヤシも居るわけではないしな。

OO、OOって言うけど、そんなに難しい命題なんかねえ。
C#だってVBだって、「OO的に」アプローチすることはさして難易度の高いことでもなかろう。
その「OO的」ってのが、OO屋に取って気に食わないのかもしれん。
その手の人って、SmallTalkあたりがお似合いなのかもね。
近年はOOと言えばJava的な雰囲気が漂ってるが、純粋な意味でのOO言語なのかと問われると、ちょっと疑問。

設計時に書くクラス図にしたって、ER図そのまんま。
うちでは、アクティビティ図も書かせてるっぽいが、書いたところで実際役に立つのか？

上流工程になると、OO使って何が得なの？って疑問が当然生じると思うが、必要な情報は要件定義で作られるドキュメントに集約すべきであり、
OO様の登場は、そこから下流の話であればいいと思うが。

さらに、企業の経営戦略となると、「ほたら、なんぼ儲かるねん」と言うところに焦点が当たると思うが、
OO屋の多くは、型にはまった答えしか出せないでしょ。部品の再利用性がどうたらとか。
その辺りを柔軟にコントロール出来る、営業系SEが居れば簡単なことなんだろうが、残念ながらお目にかかったことがない。

結局パッケージを導入することと比較して、OOを使ってシステムを手作りするメリットをきっちり主張できないなら、机上の空論でしかないのでは。
そもそも学問板のスレな訳だから、学術的な議論したいヤシが集まればいいんじゃね？
実務屋が嘆こうが、1000億円プレイヤーが自慢気に登場しようが、スレ汚しでしかねえじゃん。

ま、俺は両方満たしてるから生暖かく見守ることにするが。
じゃあね。

クラス図とER図が一緒っていうのはデータ部のみだよな・・・

UMLってただの道具だから
うまく使わないと設計は無理ですよ
分かりやすいイメージであるならUMLなんて使わなくても良いと私は思ってますが…
そこらへんの決まりごとを決めて、かつ学習させるような期間をもつプロジェクトが稀なのが
現状ですな

設計で必要なのは…まぁ言わなくていいか…

なんぼ儲かるっていうのはコンサル系の仕事になるかなぁ？
ビジネスモデルとユーザビリティとかもコンサル系が考えるべきかな？
ここらへんはよくわからないが、すべて設計・実装に任せるのは
○投げに近い業務だな。

コンサルと顧客で多くの時間と費用を使って取り決めた要件は念仏に近いものが
殆どなんで此方は苦労させられる。
なんで再調査から始めねばならないのかと思うのは何時ものことなのだが・・・
まぁ、コンサルが頑張って新システム導入を働きかけたのだからよしとしておこう。

実装経験・技術を持たない者だけで上流を仕切ろうとするから一番大事な実装開発フォーズ
への時間やお金が無くなって行く。しまいには実装フォーズは丸投げで責任回避をしようと
する動きになる。
　
最近、お利口なお客は上流工程から実装技術・業務分析技術・コミュニケーションスキルのある
出来のよいSEを交えた少数精鋭チームを作り、大手SIerにイニシアチブを渡そうとしない
傾向が出てきている。下流工程のプログラムでさえ、成果物で査定をし、生産性の悪い香具師は
ベテラン、若手に関係なく返品してくる。　返品リストの中には当然、中身のないOO屋さんも入る。

悲しいかな、このような体制のほうがはるかに低価格・高品質のシステムが出来上がる。

出来るユーザはシビアだよね。大手SIerの技術力の無い口だけ管理職よりも
はるかにSEやプログラマの実力を短期間に見抜いちゃう。

業務知識、実装技術の両方を持っているユーザ実務者は強いよ。
OO屋さんも最初は物珍しく相手してくれるが、内容が無いと見抜くとすぐに派遣の
返品対象にしちゃう。
対象に

>>635
もちろん、データ部のみです。
うちでは、Strutsベースのフレームワークを標準として使っているので、結果データ部のみのクラス図が出来上がってますね。
下手に下流にコントローラーを自由に実装させないので、リスクは低いが下流の人はつまらんでしょうなあ。

コンサル＆営業が無知なのは、どこの会社でも一緒なのかな。
まあ、案件取ってきてくれるから良しとしないとしょうがない。
と、言いつつも、今はコンサルもする立場に立ってるので、その苦労も分からなくはないですが。

でね、俺が出した結論は、>>637で言われてる、お利口なお客の立場へ転職するのが正解なのかなって。
ということで、転職活動中ですよ。

>>639
DBデザインの話をしている段階で、それは間違いなく下流工程であることを理解してくださいな。
実装方法は幾らでも存在する。
ＯＯを上流工程で使わぬ最大の理由が「概念と目的の伝達には適さぬ」からです。
「抽象化する」ということは「抽象化軸」が必要であり、この軸こそが実装手法です。
「概念と目的の伝達」に実装手法や実装方法は不要であり、この段階で1つの方法論に
まとめてしまうのは思考制限をしているようなもので、伝達すべき情報を制限しているに等しい。
「概念と目的はそのまま伝達し、それを正しく理解するだけの知識と技量を有する人のみ間で思考統一する」というのが
正解なのですよ。

つぎに、「お利口な顧客」はある意味存在しない。
設計経験が乏しいのがその最大の理由です。
ユーザーSEになってしまうとどんな大きな企業であれ、その企業の業態内でしか設計を行なえなくなる。
そのため、他企業の業態を知る機会がなくなり結果的に設計者に必要となるバランス感覚が低下する。

>>637-638
ユーザーSEによる設計が、質の悪いなんちゃってSEの設計よりマシであるのは当然のことだと思うが
その比較はあまりにも低俗であり、本来比較すべきものではない。

実装に付いて内容の査定の話が出てきたことは好ましい。
ここで現実に適したことを言わせてもらうのなら、作り手が作るべきソフトがどのように使われ利用されるかを理解しているか否かで
その成果物であるソフトの品質が決定する。
もちろん、十分にテストしバグ取りした後の話です。

ＯＯでの抽象化は「ソフトがどのように使われ利用されるかを理解さす」ことを目的とせず「設計者の意図に沿った開発」を伝達することとなる。
設計者が優秀であり十分に精度の高い抽象化が出来ておれば作り手が開発すべきソフトの利用方法と存在価値を知らなくても
開発出来るというメリットを生みます。
まぁ、業務知識のない素人でもなんとか開発出来るのでそれなりに品質は維持できますと言っているに等しい。

↑上流だの下流だのと古くさいウオーターフォール時代の発想に聞こえる。
腕の良い一級建築士やプロジェクトリーダは現場や実務にも強く、曖昧なお客の要望
を目に見えるモデル化するのが実に美味い。スビードも変化対応も早い。

建築でもシステム開発でもいろんなジャンルがある。
高級な庭園付きの日本式平屋建築、ファミリー向け住宅、低コスト・頑丈なアパート、
中小ビル、インテリジェンスビル、大規模商用ビル、都市計画デザイン、....
と千差万別。目的・予算によって工法や設計も千差万別。

設計は●●●であるべき・・・などというご高説も結構だけど↑君はオツムの硬い
メーカ系やSIerの古株リーマンてところかな。

Final Answer?

>>641
もう一度>>640を読み直しましょう。

>>640
> DBデザインの話をしている段階で、それは間違いなく下流工程であることを理解してくださいな。
> 実装方法は幾らでも存在する。

そこは同意。アーキテクトの立場からすると、その幾らでも存在する実装方法から如何なるアプローチで下流に実装させるかを選択するかに妙味がある。
一例としてDBデザインを挙げたけども、下流は即ち上流のコントロール次第で光もするし曇りもする。
さて、そこで、どうシステム化を料理しようかと考えた時に、ステロタイプ的なOOの安易な適用に疑問が残るね、って言いたかった。

> 「概念と目的はそのまま伝達し、それを正しく理解するだけの知識と技量を有する人のみ間で思考統一する」というのが
> 正解なのですよ。
>

ここは一貫して537が主張してる、「OOは大規模案件に適さない」って話なんだが。
「知識と技量を有する人」が不足してるのが実態ですな。
居るには居るのかもしれんが、彼らのみで思考統一していただくのは結構なんだが、肝心の伝達が出来ない人がほとんど。
それは、正解なんだろうとは思うが、業務スキル・OOスキル・対人スキルを併せ持ったスーパーマンの登場を待たねばならん。
で、続きは後で。

> つぎに、「お利口な顧客」はある意味存在しない。
> 設計経験が乏しいのがその最大の理由です。
> ユーザーSEになってしまうとどんな大きな企業であれ、その企業の業態内でしか設計を行なえなくなる。
> そのため、他企業の業態を知る機会がなくなり結果的に設計者に必要となるバランス感覚が低下する。
>

でね、さあ自分自身がスーパーマンになろうと考えた場合の選択肢がユーザSEな訳ですよ。
SIerの立場で居る限り、やはり短期的なスパンで案件を相当数こなす必要があるので、消化不良を起こしてるのが実態。
他企業の実態は、１ｘ年のSI経験で学んだ。
後は、１企業に没頭し、自分のスキルが本物であるか見極め、のし上がって行けばいいと考えてる。

板違いになるので、これ以上は書かないが、まあ、そんなとこです。

↑　地に足のついたお方だ。こういう見識のある人は少ない。
　 　PRICELESS!!!

>>643
> 正解なんだろうとは思うが、業務スキル・OOスキル・対人スキルを併せ持ったスーパーマンの登場を待たねばならん。
スーパーマンではなく、必要とされる技量を持つ人物ってだけです。
現在の技術者構成ではおよそ5%と言われている。

> SIerの立場で居る限り、やはり短期的なスパンで案件を相当数こなす必要があるので、消化不良を起こしてるのが実態。
消化不良になるか否かは貴方の技量次第であり、貴方のポテンシャルが問われることです。
量をこなしても成長しない人は成長しません。
開発物件にどれだけ真摯に取り組むかが問われているだけですし、十分な技量を持っている人はその技量を有するだけの
機会とその機会を有用に活用する術を知っているのです。

> 後は、１企業に没頭し、自分のスキルが本物であるか見極め、のし上がって行けばいいと考えてる。
腰を据えて取り組むと言うように聞けばそれなりに聞こえるのだが・・・
それは逃げでしかないと思う。
長時間を費やし、己の成長能力に見合ったスピードで消化吸収すると言えば聞こえは良いが、そのテンポだと
本来必要とされる技量が身に付いたとしても、対外的にそれが有用な武器となり得るのかは疑問です。
有用な武器とするのなら、相対評価で判断する必要があり、貴方よりずっと早いテンポで消化吸収し己の技量としている集団には
付いていけませんからね。

覗いてみたら・・・

ObujectOrientedの話は今やゴルフ談義かオーディオ談義のような
腐れオヤジ趣味ネタになりきってしまったよだな。

>>646
というか、ＯＯ自体、程度の低い技術者を程度の低いままの状態で如何にロボットとして有用に使うか？
ってことでしかないのが本当のところだよ。
ＯＯを使って抽象化する側と抽象化されたものを使って作業する側に分けて考えれば理解できると思う。
私が、ＯＯは所詮個人プレーでしかないと言った意図はそこにある。

>>645
> 現在の技術者構成ではおよそ5%と言われている。

これを、5%も居ると捕らえるか、5%しか居ないと捕らえるか。
俺は後者だと思う。故に、スーパーマンと表現した。
さらに言うと、その5%が各SI企業に均等に分配されているわけではないしね。

> 消化不良になるか否かは貴方の技量次第であり、貴方のポテンシャルが問われることです。
> 量をこなしても成長しない人は成長しません。
> 開発物件にどれだけ真摯に取り組むかが問われているだけですし、十分な技量を持っている人はその技量を有するだけの
> 機会とその機会を有用に活用する術を知っているのです。

一見ごもっともに聞こえるけども、それは理想論ではないか。
十分な技量を持った技術者が埋没している例もあれば、ﾊｯﾀﾘだけのSEが美味しいところをさらっていったりもする。
消化不良と言うのは、個人の力量を発揮した結果ではなく、SIの現場がそれだけ混沌としていますよ、って意味でね。
チームとして成功を収めたとしても、各要員が下痢ピー状態じゃあ、マネジメントとして果たして成功なんだろうか。
特に、規模が大きくなればなるほど、このジレンマに悩むケースが増える気がする。
まあ、悩まず丸投げのマネジメントがまかり通ってますがね。

> 長時間を費やし、己の成長能力に見合ったスピードで消化吸収すると言えば聞こえは良いが、そのテンポだと
> 本来必要とされる技量が身に付いたとしても、対外的にそれが有用な武器となり得るのかは疑問です。
> 有用な武器とするのなら、相対評価で判断する必要があり、貴方よりずっと早いテンポで消化吸収し己の技量としている集団には
> 付いていけませんからね。

時間を費やすと言うより、システムのライフサイクルをも見据えて、今のスキルをいかに１企業に対して転移できるか。
多くの企業を渡り歩き技量を身に付けるのもひとつ。１企業内で経営論まで影響を与えようとするのもひとつ。
5%の技術者になり得るかも興味深いが、相手が5%の技術者であるか否かを見抜く目もスキルではないか。
なので、SIerを見る側に立ち、適切にディスパッチが出来れば１サラリーマン人生としては成功と考えてもいいのではないかな。

>>647
決定的に意見が異なるのはここ。
OOが個人プレーか否かではなく、程度の低い技術者をロボットとして使う気は毛頭ない。
どうしても程度が低ければ切る。そうでなければ、育てる。
チームプレイとしてOOが成り立たないのならば、もはやOOには固執する気はない。
一匹狼OO使いがどんどん淘汰された現実を知らない訳ではあるまい。

＞ チームプレイとしてOOが成り立たないのならば、もはやOOには固執する気はない。

誰もがレーニンの役になりたくて分裂・内下馬に走った左翼セクトか、
誰もが国士を称したくて一人一党にしかならない右翼団体か、
そんなとこが関の山だろうなー。

相変わらずバカが粘着してるな。

Pricelessって何だよ？CMじゃねぇんだよ
普通 EeeeeeeeeeExcelent！つうんだよタコ

>>649
それこそ屁理屈なんだと思うよ。
ＯＯで抽象化されたものを使って作業のみに専念することで物は確かに開発可能だ。
しかし、そんな環境下で人は育つのかね？
教育をすると言われるが、どんな教育をするのか疑問だ。
折角、活きた材料（開発ソフト）があるというのに・・

>>652
ねぇいつまで続けるの？もう眠くなっちゃった

>>649
> 一匹狼OO使いがどんどん淘汰された現実

詳細キボンヌ（ﾌﾟｹﾞﾗ

やっぱ事務処理業務系の仕事には関わらないのが正解だと思う（藁

>>652
お早う。
書き方が悪かったかな。
人が育たんなら、OOは使わんと言っている。
一部の識者のみで分かったつもりになってOO開発を行って、結果デスマを招くパターンを何度も目にしているのでね。
OO全てを否定するのではなく、OOで抽象化されたもの「のみ」を使って、下流に作業をさせるつもりがない。
OO大好きおじさん達が、自分達がスーパーマンになったと勘違いして、マネジメントスキルも対人スキルもないのに、
プロジェクトを仕切ろうとするのがおかしいと思う。

ま、反面教師になりましたからね。こちらとしては成長の機会だったのが皮肉だね。

活きた材料と言うが、下手糞な伝達で作られたソフトから何を学べと？

> 活きた材料と言うが、下手糞な伝達で作られたソフトから何を学べと？

1）情報伝達が一番重要であることを学べる。
2）情報が不正確であることを仕様から読み取れるようになる。
3）間違いだらけの仕様であったり手抜き仕様であることが読み取れれば問題点を指摘して
　 正しい情報に直すことが可能だ。（有能な新人はこれで技量を身に付けているのが実情だよ。
　 教わるのではなく、自身で磨くことこそ重要かと。

＞ やっぱ事務処理業務系の仕事には関わらないのが正解だと思う（藁

それに尽きる。関わらんで呉。

相変わらずスレタイも読めないアフォが
業務系プロを自称する展開か。
ネガティブで抽象的な発言が悲惨さを加速させているな。

とりあえずどれか業務分野絞って話題振ったらどうよ？
分野絞り込んだ具体的な話が無いからキチガイが闊歩するわけで。

あとさぁ、こっちもよろしくな（ｹﾞﾗｹﾞﾗ

　　　　　>>649
　　　　　> 一匹狼OO使いがどんどん淘汰された現実

　　　　　詳細キボンヌ（ﾌﾟｹﾞﾗ

>>655
> 3）間違いだらけの仕様であったり手抜き仕様であることが読み取れれば問題点を指摘して
> 　 正しい情報に直すことが可能だ。（有能な新人はこれで技量を身に付けているのが実情だよ。
> 　 教わるのではなく、自身で磨くことこそ重要かと。

自分で磨くことはそりゃ重要かもしらん。
しかし、腐ったものばっか食ってると食あたりを起こすんだよ。
それを正しい方向に導くのがマネジメントと言う仕事。
有能な奴だけ生き残ればいいと言うのは一見ｶｯｺｲｲ台詞に聞こえるかもしれんが、
単に放置プレイを屁理屈で正当化してるだけ。
それが出来ないなら、単なる１作業員として人生を全うすればいい。

俺はチームプレイとは、チームの全体幸福だと考えているから、その方針でマネジメントをしてる。
その中で、OOと言うエッセンスを振り掛けると楽になる作業もあるよ、と教えている。
頭からガチでOO使いなさいと主張することもない。
幾つかあるベターな選択肢から、下流にやりやすい方法を選ばせればそれでいい。

5%の技術者がいつまでも5%のままだから、IT土方とか揶揄されるんだよ。

>>659
いや、有能になる奴は最初から決まっていると言う事なのだが・・・
置かれている立場や環境はあまり関係ないと言うか、自身で必要な環境を生み出す。

あと、無能者をそれなりに戦力として使うというのは同意するよ。
もちろん醒めた目でしか見ていないけど、戦力ともなればそれなりに達成感もあるだろうから
まぁ良いのだろう。

> IT土方とか揶揄されるんだよ。
揶揄されても構わないだろう？

ふう。ただいま。月曜日は体がダルいわ。

>>660
> いや、有能になる奴は最初から決まっていると言う事なのだが・・・
> 置かれている立場や環境はあまり関係ないと言うか、自身で必要な環境を生み出す。
>

超有能な奴はそうかもしれん。
学ぶべきものがないと判断した職場なら離れれば済む話だから。
その他８割を占める「普通の」「環境に影響を受けてしまう」連中を、いかに戦力としてその能力を引き出すか。
朱に交われば紅くもなるし、活躍の場があれば開花もする。
537の言うことは、有能な奴らだけで支配してしまえばいい、ってな考え方に聞こえる。
それならば、同意できないね。

> あと、無能者をそれなりに戦力として使うというのは同意するよ。
> もちろん醒めた目でしか見ていないけど、戦力ともなればそれなりに達成感もあるだろうから
> まぁ良いのだろう。
>

んー。突っ込みどころは色々あるが、ひとつだけにしよう。
あんたみたいな考え方の人と一緒に仕事はしたくない。
よく居る、自分がニュータイプと思い込んでるｶﾞﾉﾀの臭いがする。

>>661
やれやれ、嫌われてしまったな。
無能者は無能者でしかないと言ったことがしゃくに障ったかな？

まぁ、自分で喋って居てもむかつく発言ではある。
しかしね、何故無能者であるのかをもう少し真剣に考えて欲しいのだよ。
何の努力もせず、他人に教わりスマートに有能になる？
笑わせるんじゃない、お前等一体全体何を見てるよ。

有能な奴が無能者より優秀なのは、それだけ努力していることに何故気付けない。
そこが腹立たしくてね。

>>1-662 チームプレ ﾑﾘﾎﾟ

>>662
> 有能な奴が無能者より優秀なのは、それだけ努力していることに何故気付けない。
> そこが腹立たしくてね。

言いたいことは良く分かるよ。俺もそう思ってた時期もあった。
逆に言えば、相応の努力をしたから今の年齢でマネジメント任される立場にも立てた。

でもね、人の上に立つ立場であるからこそ、醒めた目だけじゃあダメなんだ。
どんな教育をするのか？って聞かれたことがあったけど、そりゃ、懇切丁寧に教えるだけじゃないよ。
時には突き放すし、下流の責任で設計させて、レビューで徹底的に叩いたりもする。
そうやって芽が出てくるヤシも少なくはないわけだ。

反発したのは、無能者って表現ですな。
磨かなければ光らない石もある。ならば、無能者ってレッテル貼る前に磨くのも仕事のひとつだと思う。
全ては伝えきれないけど、少しでも光るところのある奴は、少なくとも無能者ではない。

どんどんスレ違いの方向に走ってるので、この辺で。

> レビューで徹底的に叩いたりもする。
ムダだな。
どんなに叩こうが、どんなに教えようが全くのムダ。
そんなので人が育たたない。

というより、本人様自身が育つ気がない。
技能を本気で磨こうと思っている奴なら、分らなくても自分なりの意見
を出してくるし疑問点は聞いてくる。
己の考えを率直にぶつけて何処に問題があったのかを探す訳だ、そうすることで理解したとき
本人なりに消化吸収できるんだよ。

単に教わったことや、怒られた事など何の役にもたちやしない。
そんな思考の浅い出来事で本質を知ることなど不可能なんだよ。

なんか粘着オヤジ二人のバトルになってしまったな。
机上ＯＯ屋さんはスレ乗っ取られて可愛そうだ。

>>665
分からん人だな。
考えさせるチャンスを与えると言ってるんだよ。
自分を磨きたいと言う意欲を育もうと言ってるんだよ。
その為には、客観的に自身を知るチャンスが必要だろ？
叩く＝怒るみたいな単純な図式の話ではない。

ハナから、「こいつはダメ」みたいなレッテル貼る、楽チン作業なら誰でもする罠。
本当にダメな奴は論外としても、潜在的戦力を引き出していかなければ、世代交代も進まない。
だから俺は、下の奴にフレームワークの作り方も示すし、OOと言うふりかけをかけて、ご飯を美味しく食べる方法も示す。
教えるんじゃなくて、示す。

あんたの言ってることは、２歳児に無理矢理英語を教えるザーマスママと同じレベルだ。

>>666
漏れは若い！

>>OO屋さん
OO的プロジェクト管理としてはどうよ？

>>666
× 粘着オヤジ二人のバトル
○ (自称若い)粘着オヤジのスレ違いネタ自作自演

いつものパターン。無職暇人の相手する暇ねぇ〜よ

> 考えさせるチャンスを与えると言ってるんだよ。
> 自分を磨きたいと言う意欲を育もうと言ってるんだよ。
> その為には、客観的に自身を知るチャンスが必要だろ？

ムダだよ。
そんな歳ではない、チャンスを生かせる人物なら自身で成長する。

> ハナから、「こいつはダメ」みたいなレッテル貼る、楽チン作業なら誰でもする罠。
いいや、全然楽ではないその逆だ。
無能者を無能者として使うのだから大変だ。

> 潜在的戦力を引き出していかなければ、世代交代も進まない。
おいおい、世代交代は放っておいても進むぞ。
もちろん、過去も未来も有能者は5%程度で大きな変化はないけどな。

> ２歳児に無理矢理英語を教えるザーマスママと同じレベルだ。
対象者は最低でも高卒なんだよ。

>>669
> ムダだよ。
> そんな歳ではない、チャンスを生かせる人物なら自身で成長する。

だ・か・ら、そういう奴の話をしてるのではなくて、その他大勢はどうすんねんって話。

> > ハナから、「こいつはダメ」みたいなレッテル貼る、楽チン作業なら誰でもする罠。
> いいや、全然楽ではないその逆だ。
> 無能者を無能者として使うのだから大変だ。

>>674で言ってることと矛盾してないかい？
おまいさんは、OOを使って無能者をロボットとして有用に使うと主張してるが。
それが実践出来てないってことかな。

> > 潜在的戦力を引き出していかなければ、世代交代も進まない。
> おいおい、世代交代は放っておいても進むぞ。
> もちろん、過去も未来も有能者は5%程度で大きな変化はないけどな。

>>648>>659で回答済み
業界全体ではなく、１企業としてのあり方を問うてる。

> > ２歳児に無理矢理英語を教えるザーマスママと同じレベルだ。
> 対象者は最低でも高卒なんだよ。

比喩をそのまま受け止められてもなあ。高卒なんか、所詮ひよっ子じゃないか。大卒にしたってね。白くも染まれば黒くも染まる。

てか、もうお互い水と油だって分かってるんだから、もう閉めようや。
続けたければ、こちらへどうぞ。漏れが立てたスレで人も来てないし、こっちでやるより、まだスレに合ってると思う。
http://science3.2ch.net/test/read.cgi/infosys/1121843301/l50
いじょ。
暇人は消えるので、残りの皆さんごゆるりとお楽しみください。

> その他大勢はどうすんねんって話。
無能者を無能者として使えばよいだけ。
作業は幾らでもあるよ。

> おまいさんは、OOを使って無能者をロボットとして有用に使うと主張してるが。
> それが実践出来てないってことかな
そういうこと。
中途半端だと使われる側もどうして良いのか分らなくなる。
技量を身に付けるのは己の為である、そんなのを手と足取り教えるバカもいまい。
貴方のマネジメント能力を疑うしかない、貴方の手法だと仕事を無能者に渡せていない。
多分やばくなると貴方が引き受けるのだろうが、それでは管理者失格だ。

貴方の仕事は管理することであり、無能者の世話を焼くことではない。
無能者を無能者として扱うからこそ、仕事を渡せるのだよ。
もちろん、渡した仕事について無能者であろうが無かろうが責任を負って頂く。
この厳しさこそが無能者を無能者としての自覚と、有能者になるのであればそれだけの腹積もりをして頂くってことだ。

お前ら両方たいしたことねーよ。
本当に有能な人間は、周囲に無能な人間がいない環境に行く。
周囲が無能だから自分が優秀だと錯覚しているだけよん。

とりあえず>>537は管理者には向いてないことは無能な漏れにでもわかった。

無能者でも人件費原価はかなり高いはずだから、それを預かって何か生み出せという使命を与えられている、という自覚が大事だと思う。
>>537の場合、無能者を無能者として扱うより、そいつの首切ったほうがいいんじゃないか？

せっかくオヤジ自ら誘導してんだから、素直にそっち移動して議論すれば？ﾜﾗ

他にネタがあるわけでもなし、なんでもやれば？嫌ならネタ振ってくれ

正直に出来の良い奴だけで少数精鋭のプロジェクトやったほうが効率も良いし
客も喜ぶと思うが、今更、味噌・糞一緒の人月見積り文化を変えるのは容易じゃ
無いかもね。無能者は転職してもらった方が良いのでは?

>>672
そうだと思う。
周りに無能者が多く存在することで私としては気楽に人生を謳歌しているからね。

>>673
貴方の勘違いは見ていて楽しい。
無能者を無能者として巧く使うことこそ貴方の使命なんだよ。
もちろん、それが管理者としてすべきことです。
人を育てる等と傲慢過ぎますよ。
貴方が単に教師で、教えることを本業にしているのならそれでも良い。
しかし、現実は違う。
結論から言わせて貰うと、貴方では無能者が腐るだけ。
出来もしないことを要求し、結果尻拭いと称して貴方が後始末。
これでは無能者は堪ったものではない。
やる気も失せてしまい、ドロップアウトするのは当り前だ。

>>676
小数精鋭が効率よいのは当然。
しかし、それだと短時間により多くの作業はこなせない。
そこで必要なのが無能者集団。
巧く使うのがコツですね。

>>677
ごめん俺はマジであの人とは別人だ。(^^;
敵は一人と思い込む現象かな？切羽詰ってるように見えてしまった。

まぁ、見ていて楽しかったなら、きっちり礼ぐらいしろや。

>>678
別のお人かぁ。
そうすると管理者云々は無関係ですな。

しかし、無能者を巧く使うこつは無能者として扱うことにかわりないよ。

>>679

＞しかし、無能者を巧く使うこつは無能者として扱うことにかわりないよ。

ひょっとして、あなたと彼のやっていることは同じことではないか？
あなたは、その後成長した部下を依然として無能者と呼んでいる。
彼は、その後成長した部下をここまでは成長したと評価している。

違う？

>>680
成長し、有能者として扱うレベルに達したものは有能者として扱うのは当然だよ。

>>681
このスレで俺の目に映ったあなた像は、
・有能な部下が功績をあげたら自分の指導の賜物と主張する
・無能な部下が配下に来たらあいつが無能なのは自分の責任ではないと主張する
・有能な人材を探して引き抜いてくるという自部門の効率化しか考えられない
だよ。

技術者としては有能だが管理者としては無能な人間が成り行きで管理者におさまった、の典型に見える。
マネジメントとテクニカルはまったく別物のスキルだからね。

その辺、上の誘導スレに出向いて、一度彼と話してきたら？

誘導スレでレスしてみてるけど、来てくれないようなので。出向きました。
結局ね、やってることは漏れも537も大差ないんだと思う。

ただ、例えて言うなら性善説と性悪説みたいに、根本の発想が違うんだと思う。
漏れ的管理ってのは、まあ、管理工数なんて0.2人月もあれば出来るから、
3案件抱えてたとしても、0.6人月。残りをどう有効に使うか。
漏れの主張は、有能者予備軍を有能者に引き上げることだと思ってる。
ボーナス査定でも、部下の教育・訓練の実績は問われるわけで。
分布としては、有能者5％、無能者5％、グレーゾーン90％なのかな、って思ってる。

それから、今の企業って年齢層別の人数分布割合がバラバラだから、ある人は自分の職責を越えた仕事をしなきゃダメだし、
ある人は、自分の職責に満たない仕事をしてるってのも現状かな。

話題がぶっ飛ぶけど、漏れはやっぱり人対人として仕事をしたいだけなんだよ。
無能者を無能者扱いしていれば、無能者と言えども自分がどういう目で見られてるかは気付くわけでね。
教えられる側にとって、越えられそうなハードルを与えてみるのがベターかと。もちろん、同時に責任は与えるよ。
でも、管理者は＝責任者なんだから、やっぱり尻拭いは必要悪なんだと思うよ。
後ろ盾があるからこそ、そいつも間違ってもいいから全力でぶつかれるんだと思う。

逆説的になるけども、管理者に取って必要なのは、有能な右腕。
PMって、ともすれば孤独な存在になるからこそ、信頼できる部下が欲しいでしょ？
となると、人対人として、時にぶつかり、時に喜びを分かち合えた存在が不可欠だと思う。
これは、決して人対ロボットとしての関係からは生まれ得ないのではないだろうか。

後ね、追伸しておくと、漏れ教育学部出身ですわ。
素で教育論言い出すと、申し訳ないが、IT関係の人相手ならいくらでも論破できる。
教育論的にはね、教育って言葉は使わない。支援って言う。
あくまで、自己で成長していく補助を行うスタンスね。

で、まあ漏れは紆余曲折してテクニカルの道へ走ってきて、今PMへ収まってる。
様々な立場での経験と、反面教師・見習うべき上司を見てきて、
さて、これからテクニカル・マネジメントどっちを極めるのが自分にとって幸せなのか考えてる。
なので、転職云々言い出したわけでね。

その見習うべき上司って人が、テクニカル・マネジメント・折衝能力全てにおいて秀でた、いわゆる有能者。
若くして部長の座に就き、上司・部下ともに信頼が厚い。

部長が守ってくれるから、下の子たちにすれば、安心して自分の能力を発揮する機会を得られるわけ。
甘えと言われればそれまでなのかもしれないけども、管理者に取って必要なスキルのひとつは求心力だと思う。
ただ、１案件を成功に導くだけでなく、継続して多くの案件を着地まで導いている。
むしろ537のやり方の方が、ドロップアウトを多く出してしまう結果になってないかい？

ヒント：継続は力なり

537の脳内でどういう思考回路が働いているのかは知らんが、こっちは事実実績を出してますよ。
２年目、３年目辺りの若手でも、立派にマネジメントこなしてる奴も多い。
どこの会社と問われれば、IT業界じゃなくても大抵みんな知ってる会社だとだけ答えておこう。
自社で実績出している以上、537に漏れの管理能力を云々されるいわれはない。

>>683-684
あのさぁ、貴方の発言って極々一般的で得るべきところが１つとしてないんだよ。
人ってさぁ、貴方が思っている程愚かではない、欺くこと出来ないんだよ。
無能者へ動機付けを行なうのは決して間違いではないし人が人である以上必要だ。
しかしねぇ、嘘も方便だけど限度があるのよ。
無能者に、お前は本気を出せば有能者に直ぐなれると言ってみても無理なのよ。
現実を把握し、置かれている立場を詳らかにしてあげることが重要なんだよ。
もちろん、人の可能性を否定してはいけない。
貴方が勘違いしている個所は、私が無能者の可能性を否定していると思っているところ。
可能性を否定しないが現実を直視して頂き、技能を伸ばす為にどれだけ多くの努力をしないとダメなのかを
しっかりと理解して頂く、その努力を怠りお気軽にスマートに成長することは不可能であることを理解して頂く。

これだけのことです。

今日は徹夜かな？

>>685
> あのさぁ、貴方の発言って極々一般的で得るべきところが１つとしてないんだよ。
反論に詰まるとそうきますか。レスのうち都合の悪い部分は全部スルーしてますよね。
仕事なんざ、当たり前のことの積み重ね。ＩＴだってそう。システム開発者に何か特殊技能が必要ですか？
むしろあんたの発言の方が極論で得るべきところがない。

> 人ってさぁ、貴方が思っている程愚かではない、欺くこと出来ないんだよ。
> 無能者へ動機付けを行なうのは決して間違いではないし人が人である以上必要だ。
> 無能者に、お前は本気を出せば有能者に直ぐなれると言ってみても無理なのよ。
どの部分を読んでそう答えてるのか謎。
「ちょっとがんばれば越えられそうなハードルを与える」と書いたはずなんだが。
「後ろ盾があれば、そいつは間違ってるかもしれないけれども、安心して全力が出せる」
とも書いてますが。どこを読んだら、＝有能者に直ぐなれる、と解釈できるのかな。他人を愚か者扱いしているのは、あんたの方としか思えないんだが。

> もちろん、人の可能性を否定してはいけない。
> 貴方が勘違いしている個所は、私が無能者の可能性を否定していると思っているところ。
無能者なんて言葉を使ってる時点で、否定と受け止められても仕方がないのでは？
あんたのボキャブラリーの少なさがそうさせているのか、としか思えない。
今までのレスで、散々無能者をこき下ろしておきながら、突然方針変更ですか？

> 可能性を否定しないが現実を直視して頂き、技能を伸ばす為にどれだけ多くの努力をしないとダメなのかを
> しっかりと理解して頂く、その努力を怠りお気軽にスマートに成長することは不可能であることを理解して頂く。
その部分は同意見だね。
ただ、あなたは無能者を無能者として使うと主張しているはず。
こちらは、有能者予備軍を有能者へと導くと主張している。「泥臭い」作業の積み重ねでね。
これまた方針変更ですか？

> 今日は徹夜かな？
このくらいの時間でいちいち徹夜するほど暇ではないよ。

> 「ちょっとがんばれば越えられそうなハードルを与える」と書いたはずなんだが。
それだと、無能者を無能者として扱っていることになるのではないかな？

> 無能者なんて言葉を使ってる時点で、否定と受け止められても仕方がないのでは？
言葉の綾をとやかく言われてもなぁ。

> こちらは、有能者予備軍を有能者へと導くと主張している。「泥臭い」作業の積み重ねでね。
無理だね。

>>687

ほら。来た来た。そろそろ反撃の手も限界かな。相変わらず反論出来ない部分に関してはスルーだな。

> > 「ちょっとがんばれば越えられそうなハードルを与える」と書いたはずなんだが。
> それだと、無能者を無能者として扱っていることになるのではないかな？

繰り返すんだよ。グレーゾーンと言う言葉を使ってるだろう？
あんたの単純な「有能」「無能」式分類には賛同しかねると言っている。

> > 無能者なんて言葉を使ってる時点で、否定と受け止められても仕方がないのでは？
> 言葉の綾をとやかく言われてもなぁ。

じゃあ、実際職場で部下に「無能者」って言葉吐いてみな。
言葉の綾だなんて、逃げ口上も苦しすぎるよ。

> > こちらは、有能者予備軍を有能者へと導くと主張している。「泥臭い」作業の積み重ねでね。
> 無理だね。

あんたのやり方じゃ確かに無理だね。
無能者に単純作業を与えて無能者として働かせていれば、成長するはずもない。
>>680>>682で指摘されてるだろう？
それとも、人類の進化を根本から否定するつもりかい？
競走馬だって、犬だって、教えれば成長するんだよ。

もうちょっとマシな答えを期待してたんだが。
まあ、精々現場作業に勤しんでくださいな。

> もちろん、人の可能性を否定してはいけない。
> 貴方が勘違いしている個所は、私が無能者の可能性を否定していると思っているところ。

> 可能性を否定しないが現実を直視して頂き、技能を伸ばす為にどれだけ多くの努力をしないとダメなのかを
> しっかりと理解して頂く、その努力を怠りお気軽にスマートに成長することは不可能であることを理解して頂く。

ここと

> > こちらは、有能者予備軍を有能者へと導くと主張している。「泥臭い」作業の積み重ねでね。
> 無理だね。

ここの、明らかな論理的矛盾も説明してね。
無理ならギブアップしてもいいんだよ。黙って出て行ってくれればね。

> 競走馬だって、犬だって、教えれば成長するんだよ。

まるで子供だな。
まず、貴方が言う成長とは何かな？
貴方は貴方のマメジメント力で無能者を有能者に出来るという。
しかも、ほんの僅かな努力で良いらしい。
だが、有能者の割合は過去も現在も未来も5%未満でしかない。

貴方の言い分が正しいのなら、この世の中有能者で溢れていると思うぞ。
つまり、貴方は言い分は所詮戯言に過ぎず、欺瞞でしかなく仮に運良く貴方の部下が成長したとしても
それは君の指導の賜物ではなく単に部下自身の能力に過ぎない。

がんばって考えたね。その粘着力は評価に値するわ。
> まず、貴方が言う成長とは何かな？
> 貴方は貴方のマメジメント力で無能者を有能者に出来るという。

具体的に、どこでそう言ったか引用してみ。支援する、としか言ってないよ。
それも、有能者予備軍を有能者へ、と言ってる筈。

> しかも、ほんの僅かな努力で良いらしい。
どこを解釈したら、そう読み取れるのかな。
繰り返しハードルを与えることで、より高みを目指すと書いてる筈だが。

> だが、有能者の割合は過去も現在も未来も5%未満でしかない。
そこまで言い切る根拠は？
誰が誰を有能、無能と評価するのか答えてみろよ。

> 貴方の言い分が正しいのなら、この世の中有能者で溢れていると思うぞ。
居るところへ行けばいくらでも居る。あんたがその事実を知らない現場に居るだけ。

> つまり、貴方は言い分は所詮戯言に過ぎず、欺瞞でしかなく仮に運良く貴方の部下が成長したとしても
> それは君の指導の賜物ではなく単に部下自身の能力に過ぎない。
それでいいんだよ。部下の潜在的な能力を引き出し、開花させるチャンスを与えるのが上司の仕事。
チャンスをものにするのは、もちろん当事者。
いつ、どこで、俺が俺自身の力で部下を成長させるって言ったよ？

オッサンもう無理だって。子どもみたいな屁理屈止めて終わりにしようや。

>>691
いや、まともなレスが無くなって来て残念。
もう少し貴方なりの意見なり考え方が伺えるのかと期待してたのだが・・・

屁理屈言ってるのは貴方。
何一つ有用なことを言っていないのも貴方。

単に無能者をおだてて使っているに過ぎず、管理者としての厳しさがまるで無い。

>>692
> いや、まともなレスが無くなって来て残念。
> もう少し貴方なりの意見なり考え方が伺えるのかと期待してたのだが・・・

一貫して同じことを主張してるだけ。１〜２発のレスで終わるところを、あんたがしつこく食いついてくるからだろ。

> 屁理屈言ってるのは貴方。
> 何一つ有用なことを言っていないのも貴方。

だからね、それは、こっちの質問に全て答えてから言えば？
都合の悪い質問には、一切答えてないでしょ？あんた。

> 単に無能者をおだてて使っているに過ぎず、管理者としての厳しさがまるで無い。

だからね、それを指し示す発言を引用してくれよ。それとも、俺の働いてる現場見たわけ？
無能のオッサンが何を言っても虚しいだけだよ。

俺が優秀とは言わん。ただ、あんたが俺より無能なのは明らか。
論破したければ、それなりの根拠を持って反論してくれよ。

大体が、おまえが俺のことを管理者としての資質を疑うだの欺瞞だの戯言だの喧嘩売ってきてんだろうが。
やれ、無能者は無能者のままだと言ってみたり、それは誤解だと言ってみたり、意見をころころ変えやがって。
んで、ユーザSEはお利口ではない？
分かったつもりでてめえの脳内で物語作ってんじゃねえよ。

ヘルスでも逝って１００発ほど抜いて来い。ヴぉけが！

>>694はどこのエキストラだ？

>>694
誰やねん・・・・漏れの偽者は・・・
まあ、オッサン二人で盛り上がってるよかマシだけども・・・

> 俺が優秀とは言わん。ただ、あんたが俺より無能なのは明らか。
> 論破したければ、それなりの根拠を持って反論してくれよ。

あらら、論拠は全て出尽くしているのだが全然理解していない？
それじゃ整理しとくぞ。

1）無能者は無能者として扱う。
2）多少の動機付けは必要だが、無能者であることを自覚して頂く。
3）成長するもしないも本人様次第。
4)過去も現在も未来も有能者の割合は5%未満。

これだけ出揃えば十分だろうよ。
貴方は上記に対してまともな反論は行なえていない。

>>697
> 1）無能者は無能者として扱う。

Noと答えてる筈。最初からレッテルを貼る単純作業は管理とは言わないと主張している。
誰が誰を有能、無能と決めるのか、と言う問いにあんたは答えていない。
しかも、無能者として扱うとする一方で、あんたは無能者の可能性を否定しているわけではないと、矛盾したレスを書いてる。

> 2）多少の動機付けは必要だが、無能者であることを自覚して頂く。

動機付けの件は、同意してる筈。
しかし、あんたが「多少の動機付け」などと書いたレスはない。
しかも、あんたは、いちいち部下に、「お前無能者な」と言って回ってるのか。
そもそも、あんたの管理者としての資質の方が否定的に受け止められてるレスの方が多い。

１、２共通して、無能・有能とオセロみたいに白黒はっきり分ける手法を解説せよ。

> 3）成長するもしないも本人様次第。

本人次第だが、潜在的な有能者が相当数居ると主張してる筈。
また、それを開花させるチャンスを与えるのが上司の仕事と言ってる筈。

> 4)過去も現在も未来も有能者の割合は5%未満。

それは、あんたが主張してるんだから、根拠を示せと言ってる筈。

全てまともに答えてますよ。自分の首絞めて楽しいですか？
整理していただくのは結構ですが、日本語から勉強されたら如何かな。
そもそも、あんたがマネジメントの立場に居るのかすらも明らかにしていないのでは？

>>697
さらに言うと、>>689の問いにあんたは答えていない。
もう一度、スレを最初から読み直してみては如何かな。

逆に
１）俺の管理能力を疑問視する根拠を述べよ
２）あんたが有能者であると言う根拠を述べよ。
３）無能者をロボットとして使うと主張しながら、無能者の可能性を否定していない矛盾を説明せよ。
４）そもそも、事の発端となった、ＯＯが所詮個人プレーでしかないと言う限定が事実であることを、具体的案件内容を挙げて立証せよ。

もっとあるけどね。
話を聞く限り、１現場ＳＥでしかないあんたが、さも全てを知っているかのように振舞ってるのは、見ていて痛い。
あんたの主張は、あんたが有能であることを指し示しているが、果たしてその自信がどこから沸いてくるのか一切不明。

まともに論理立てて意見を主張していないのは、あんたの方だと早く気づけ。

>>697
あんたは、ただ一方的に相手の意見を否定しているだけ。
その根拠は一切示していない。

悪いけど、全ての問いにあんたなりの答えを書いてもらおう。
都合の悪い部分をスルーするならば、もう勝敗は明らかだろう。

　　有能無能って議論してるけど、

　　スレ違いのスレで平日これだけダラダラ長文書き綴るのは、

　　まるっきり暇な閑職の人か、引退／引き篭もり系か、どっちかだと思う。

　　井の中の蛙くん、いいかげんスレ違い議論はどっか別のスレでやったらどうよ（爆笑

> Noと答えてる筈。最初からレッテルを貼る単純作業は管理とは言わないと主張している。
レッテルではなく、相手の能力を正しく把握しているだけです。管理者として必須です。

> 誰が誰を有能、無能と決めるのか、と言う問いにあんたは答えていない。
言葉の綾でしかなく答える必要なし。

> しかも、無能者として扱うとする一方で、あんたは無能者の可能性を否定しているわけではないと、矛盾したレスを書いてる。
矛盾しない。
無能者だから成長しないと考えているのは間違い。

> １、２共通して、無能・有能とオセロみたいに白黒はっきり分ける手法を解説せよ。
必要なし、有能者と無能者では技量差は大きくその中間に位置する人の数そのものが極小。
その理由は中間に位置する人の殆どが有能者となる。
これは、有能者になるために必要な技量の習得方法を知っていることと、その努力を行なう能力を持っているからであり
必要な技量を有すことは本人にとって有益であるからだ。

> 潜在的な有能者が相当数居ると主張してる筈。
いない、潜在的な有能者も5%に過ぎない。

>>702
はい。分かりました。
あんたには、高校レベルの国語の試験に答える能力がないとういことが。
全ての問いに答えろと言ってる筈。意味が分かりませんか？
まあ、赤点ですな。

>>703
反論出来ないのならレスしないことをお奨めするよ。

レスされたら困るもんねぇ。
俺ももう呆れたからどうでもいいわ。

　　　　スレタイ読めない奴に常識や国語力を期待するなって（ﾌﾟｹﾞﾗ

ここで自作自演してるのは
例のなんとかいうコテハンだろ。

読む価値なし。

あー、2chでそんなに論理展開するなよ。
ここに書くくらいなら雑誌に寄稿しろって。

さてと、結構長い論争であったな。
そろそろ終了というところかな？

幻想・妄想は現実を大きく歪めてしまう。
良い方向に歪むのなら許容もするのだが、安易な方向への歪みが良い方向である筈もなしだな。

ＯＯが一定のルールに沿った抽象化で様々な利便性はある、しかしそれだけだ。
それ以上でも以下でもない、それが無意味に誇張され銀の弾の如く吹聴される。
知識のあるものはそれが吹聴であることを理解できるが、そうでない者は騙される。

結局、無知が故のこと。
正しく評価し、正しく扱う。
こんな当り前のことすら出来ずにどうする？

確かに、相手を煽てるのは気が楽だろうが、それは逃げでしかない。
ちゃんと正面から向き合うことは人として最低限度の礼儀だ。
それすら出来ずに、嘘と欺瞞で人を欺く手法が通用する筈も無い。

　　　　スレタイ読めない奴に常識や国語力や論理的な議論展開を期待すんなって（ﾌﾟｹﾞﾗ

>>710
お前もスレ違いな香具師だな。OO以下。

はいはいわろすわろす。

>>704

>>689
>>699
まずは、この問いに答えてもらおう。
答えられないなら、無駄なレスをしないことをお勧めするよ。

それに答えられたら>>702にきちんと反論してあげよう。

まあ、今までの傾向を見ると、あんたは複数のレスに一度に答えるのは無理みたいだからね。

それから、いい加減ここいらで、あんたの立場くらい明らかにしてみてはどうかな。
俺は、PM（あんたの言う「管理者」とは≠）だと、はっきり宣言してるわけだし。

>>705
>>706
>>707
>>708

うーん。ごもっとも。
漏れはずっと釣られ続けてるのかな。
客観的に見ても馬鹿馬鹿しい議論だろうしな。
誘導もしてみたが、ノーリアクションだし。

売られた喧嘩だから買ってみたのだが。ペルー人に日本語を教育するような難しさを感じる。
まあ、盆休みの暇つぶしとしては楽しげ。
盆踊りでも踊ってくらあ。thx

>>713
どうでも良い程度のこと（貴方の解釈ミス）だから無視しているだけなのだが、
無理なのは「君が導く」と言う個所。
君が居ても居なくても結果は同じ、というか君が居るほうが逆に足枷になるのじゃないかな？

そんなことも分らずに奢った発言は見苦しいだけです。

>>715
要するに答えられないと解釈します。
解釈ミスなら、解釈ミスだと分かるように指摘すれば済む話。
あんたの発言の矛盾点を指摘してるんだから、どうでも良いなどと逃げ口上打たずに発言に責任を持てば？
どう客観的に見ても、奢った発言を繰り返してるのはあんたですね。

無理と言うなら、何故無理なのか根拠を示していただきたい。
あんたの特徴は、答えに窮すると逃げるところ。
問題のすり替えも得意技ですね。

いい加減、「有能者５％論」の根拠も示してはどうですか。
過去・現在がそうである点に関しては、極端な否定は示していない筈。
ただ、未来もそうであると主張するからには根拠が必要でしょ？

あんたが無能者の可能性を否定していない以上、統計学的には５％を越える可能性は否定し切れていない。
それとも、増えた有能者の分、現存する有能者が去るとでも言いたいのかな。

あんたみたいな、古い石頭しか持っていないSEに担当される顧客が不憫でならない。

>>716
> 解釈ミスなら、解釈ミスだと分かるように指摘すれば済む話。

指摘しているし説明済み。
あれ以上になんの説明が要るのか疑問だぞ。

ついでに補足しておく。
ＳＥに有能者が少ない最大の理由は、守備範囲が広過ぎることが挙げられる。
ピンキリと言えばそれまでだが、有能者と言えるレベルなら会計士と同等に渡り合える程度の知識と技量位は必須だよ。
しかも相手は会計士だけではなく、その道のスペシャリスト達ばかり。
システムデザインを行なうということはそういうことです。


このレベルになるとＯＯ等は何の役にも立たない。