5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

アーキテクト(笑)

1 :仕様書無しさん:2006/06/13(火) 14:22:44
SEになれないまま年とったプログラマの逃げ道
そう思わない?


2 :仕様書無しさん:2006/06/13(火) 15:01:20
そもそもSEってなんですか?
他の国にはそんな触手ありませんが。

3 :仕様書無しさん:2006/06/15(木) 10:18:09
SE出来なきゃアーキテクトはできないぞ。

4 :仕様書無しさん:2006/06/15(木) 13:10:06

はあ??
アーキテクト>SE??



5 :仕様書無しさん:2006/06/15(木) 20:34:47
アーキテクトだけじゃなくてエヴァンジェリストも気にしてほしい

6 :仕様書無しさん:2006/06/16(金) 14:55:48
>>4
アーキテクトのなかにSEが含まれるって感じ。
まあ要件定義や設計、ハード構成も「アーキテクチャ」なのだから
当たり前っちゃあ当たり前。
SEのやる仕事でアーキテクトの仕事に含まれないのは
見積もりや人員配置みたいなもの。
これをSEの仕事ととるかPMの仕事と取るかは会社によって違うんじゃない。


7 :仕様書無しさん:2006/06/16(金) 15:22:17
>>2
Sensee unko shitekite Eedesukaa


8 :仕様書無しさん:2006/06/16(金) 19:25:08
ゲーム制作者をクリエイターとか言っちゃうくらい寒いな

9 :仕様書無しさん:2006/06/20(火) 14:04:08


アーキテクト(藁)



10 :仕様書無しさん:2006/06/20(火) 22:35:19
アーキテクト委員会(笑)
http://www.atmarkit.co.jp/farc/rensai/lookingfor02/lookingfor02.html

11 :仕様書無しさん:2006/06/21(水) 12:13:02
>システム構築の“複雑性”がITアーキテクトの存在を必然としている

ワロス
複雑にしてんのはおめーらだろ

12 :仕様書無しさん:2006/06/21(水) 19:15:28
>>11
簡単に言うと使えるDBやツールの種類が増えたり
なんちゃら思考だのうんちゃら言語だの、選択肢がたくさん増えたから
どれを使うのがより最適か、選ぶ人が必要になってきた、てことでしょ。

頭悪いやつって文章も読めないから大変だな。

13 :仕様書無しさん:2006/06/22(木) 11:00:05

なんちゃら思考(笑)


14 :仕様書無しさん:2006/06/22(木) 11:04:22
選択肢なんて昔からいくらでもある。
どうもアーキテクトの存在ってこじつけっぽくて
本当に必要なのかどうか、前から疑問だった。
正直、プログラマに毛がはえたようなもんでしょ?


15 :仕様書無しさん:2006/06/22(木) 11:06:00
プログラマ(笑)

16 :仕様書無しさん:2006/06/22(木) 11:06:14
うちの会社にもITアーキテクトっているけど、技術オタクの別名だよ。
特徴は、知識はあるけど経験が無い、だから実際のプロジェクトに投入
されると泣き出しそうになる。使えない奴が多いね。プリセールスのと
きにウンチクたれるのが仕事です。


17 :仕様書無しさん:2006/06/22(木) 11:58:47
オレもそう思う

プログラマ→SE→PMっていう当然のキャリアパスを断念した人
つまりSEになるための条件、業務知識や
交渉能力とかが足りない人の逃げ道にしか思えない

18 :仕様書無しさん:2006/06/22(木) 12:23:52
まぁそうアーキテクトを毛嫌いするな。
技術だけでは仕事にならんよ。

19 :仕様書無しさん:2006/06/22(木) 12:33:24
アーキテクトの定義もおぼろげなウンコちゃん達が可哀想すぎwww
平和でいいね。おまえら

20 :仕様書無しさん:2006/06/22(木) 15:24:27

アーキテクトの定義(笑)


21 :仕様書無しさん:2006/06/22(木) 15:36:08
え??
アーキテクトって毎日何やってんの???

22 :仕様書無しさん:2006/06/22(木) 15:44:44

スレタイはデザパタのことを言っているのか?


23 :仕様書無しさん:2006/06/22(木) 15:52:01
アーキテクトはアーキテクチャを作り、説明し、調整し、改良する人のことですね。

24 :仕様書無しさん:2006/06/22(木) 15:57:38
アーキテクチャってどうつくんの?

25 :仕様書無しさん:2006/06/22(木) 15:58:21
SE>PG>>>>>テスター>>>>>>アーキテクト(笑)

こんなもんか。

26 :仕様書無しさん:2006/06/22(木) 16:10:06
>23
アーキテクトがいなくなると
システム開発する上でどういう点で困るの?

27 :仕様書無しさん:2006/06/22(木) 16:16:03
アーキテクト。
PG,SE,PMになっても薄給激務で幸せになれそうにない人々に
夢を与えるために作られた肩書きです。
優雅にお仕事高収入。
いつかたどり着ける約束の地、ノアの箱舟、ガンダーラ。


でもお布施を出すのは忘れずに。


28 :仕様書無しさん:2006/06/22(木) 16:17:01
お布施を払い続ける人だけが夢を見られます。


29 :仕様書無しさん:2006/06/22(木) 16:17:52
俺も、アーキテクト(笑)になりてぇ〜〜〜〜〜〜

30 :仕様書無しさん:2006/06/22(木) 16:22:11
>>26
とりあえず、だれか別の人がアーキテクチャを作るか、
アーキテクチャなしで開発をすることになりますね。

アーキテクチャなしで開発をするということは、
各プログラマが、担当の機能をそれぞれてんでばらばらな方法で実装し、テストするということです。

従って、以下のような点が問題となります。
 ・同じ技術的問題についてその都度、それぞれのプログラマが解決する、ということで工数の無駄。
 ・同じシステムでもほかのプログラマが担当した機能については、
  さっぱりわからないという、保守性ができない、あるいはそのためのコストが高くなる。
 ・性能、可用性の問題についての発見が遅れる。(結果、対策コストが増大する)

31 :仕様書無しさん:2006/06/22(木) 16:36:56
アーキテクチャなし(笑)

32 :仕様書無しさん:2006/06/22(木) 16:50:27
>・同じ技術的問題についてその都度、それぞれのプログラマが解決する、ということで工数の無駄。

話あったり、ライブラリ使ったりしないのか?
今時、技術的問題に工数かけたりするのかな、


33 :仕様書無しさん:2006/06/22(木) 16:51:00
>>30
優れたプログラマがいればそもそも発生しない問題ばっかりじゃん

34 :仕様書無しさん:2006/06/22(木) 16:54:00
俺のような天才はほとんどいないのが現実。

35 :仕様書無しさん:2006/06/22(木) 17:33:23
うんうん、そうだねそうだね

36 :仕様書無しさん:2006/06/22(木) 17:46:06

こ こ で た む ろ し て る 2 流 に な に を 言 っ て も 無 駄 

37 :仕様書無しさん:2006/06/22(木) 18:22:01
>>32
>話あったり、ライブラリ使ったりしないのか?
いや、それがまさにアーキテクチャを作るという作業ですよ。

>今時、技術的問題に工数かけたりするのかな、
そうですね、技術的な問題が小さいか、ほとんどない場合は、
大上段に「アーキテクチャ」というものを作らなくても、
担当者間の話し合いで(つまり、アーキテクチャをわざわざ明文化しなくても)、
なんとかなるでしょうし、専属のアーキテクトがいなくても、その役割を、
プログラマーなどが兼ねることで事足りるでしょう。

>>33
そのとおりですね。優れたプログラマが一人、あるいは、少人数で開発する場合は、
おそらく、専属のアーキテクトは必要ないでしょう。

38 :仕様書無しさん:2006/06/23(金) 03:11:28
スレタイはデザパタのことを言っているのか?

39 :仕様書無しさん:2006/06/23(金) 03:36:21
アーキテクトって、システムの全体設計ができる人のことと
思いますが、そんな人いないですね。アーキテクトって
名乗っている人の多くは、それぞれ得意分野があるようですね。
データベースが得意とか、セキュリティーが得意とか、障害対策
が得意とかね。でもこれは、アーキテクトではない。


40 :仕様書無しさん:2006/06/23(金) 09:43:41
簡単に言うと
今のSEがハード構成や仕様言語、ツール、ソフトウェア構成を
明確な根拠を持って決められない or 決める時間がない、ってことだろ?


41 :仕様書無しさん:2006/06/23(金) 10:10:45
というか、「アーキテクト」が出てくる文脈では、
「SE」って出てこないことが多いような気がする。
たとえばRUPに「SE」って役割はないし。

42 :仕様書無しさん:2006/06/23(金) 13:19:02
41 が秘密に触れた

43 :仕様書無しさん:2006/06/23(金) 15:16:31
あ〜もーテキトー

44 :仕様書無しさん:2006/06/23(金) 17:53:07
       ,、‐ " ̄:::゙:丶、
    ,r::::l3゙::::::::/ハヽ:ヽ::::、:ヽ
    {::://:::::::// ヽ\ト、:::::::!
    ヾ l:::::::/ 丶   `ヾ ィ、:::|
     |;:r::|  O`  'O ゙ハ|    アーキテクト?
      ヽハ :.:.    :.: レ
        ´\ r‐--‐、,ノ   いらんいらん(笑)
 r、     r、/ヾ ̄下ヘ
 ヽヾ 三 |:l1、_ヽ/__ .ィヽ
  \>ヽ/ |` }    n_n| |
   ヘ lノ `'ソ     l゚ω゚| |
    /´  /      ̄|. |
    \. ィ   ___ |  |
        | ノ     l |  |

45 :仕様書無しさん:2006/06/23(金) 20:36:08
うちでは、なぜかオブジェクト指向について詳しい人を
アーキテクトと呼んでいるようだ。でも、その人達は、
オブジェクト指向で実際のプロジェクトをやったこと
ないな。あくまで、理論的によく知っているだけだね。
やはり、ヲタの一種でしかないというのが結論。


46 :仕様書無しさん:2006/06/24(土) 04:18:42
姉歯と同じ立場だろ?

アーキテクトは設計者

システム全体の設計ができる人ぐらい世の中には結構いるもんだ。

用件について深い理解は必要だが用件定義は含まない

各種フレームワークの選定から使用方法を決めたりもする

もちろんPMに言われたコストを守るために偽装もする


47 :仕様書無しさん:2006/06/24(土) 04:44:35
>>41

http://pc8.2ch.net/test/read.cgi/prog/1150960513/3


48 :仕様書無しさん:2006/06/24(土) 11:19:45
>>47
これ?

>Q:アメリカにSEという職業ないってホント?
>A:一般的にコーディング専門な人はいない。
>  設計もコーディングも同じ人がやる。
>  SEという言葉自体使われてないぽいです。

実際、うちの職場もこんな感じだしなー。
SEがどうの、PGがどうのというこの板の話し方には
ついていけん(そんなの、本とか顧客向けのハッタリ肩書きだけの存在でねえの?)
と思ってた。

49 :仕様書無しさん:2006/06/24(土) 13:23:39
>>48
日本では受託(サービス業)が中心だからかね?
SE,アーキテクト,...変呼び方の役割が多いのは。

50 :仕様書無しさん:2006/06/24(土) 15:15:26
>>46
>>姉歯と同じ立場だろ?
でもアーキテクトは設計失敗してもタイーホされないよね。
よかったね!



51 :仕様書無しさん:2006/06/24(土) 15:33:18
失敗と偽装は違うと思われ。

52 :仕様書無しさん:2006/06/24(土) 15:38:15
つうかね、どうも、「役割」と「肩書き」ってのは違うと思うわけよ。

向こうの人間は、問題解決の方法を考え、そのために必要な「役割」を考え、
その能力を持った人にそれを割り振る、という考え方をする。
日本では、それがどういうわけか「肩書き」(≒身分)という考え方になってしまう。
「俺様はSE様だからPGより偉い」「俺様はSE様だからこんなことはやらなくてもいい」
とかいうわけのわからんことを言い出す。


53 :仕様書無しさん:2006/06/24(土) 17:01:33
SEとPGってふうに分けること自体が変だしな。

54 :仕様書無しさん:2006/06/24(土) 21:53:57
>>51
>失敗と偽装は違うと思われ。
でも、結局金を出した客が損害を被るのは同じと思われ。
偽装マンションの住人=システムのユーザ企業


55 :仕様書無しさん:2006/06/24(土) 22:27:04
>>54
なんかくだらない議論だな。
文句があるなら、詐欺と過失を区別してる日本の法自体に文句つければ?

56 :仕様書無しさん:2006/06/24(土) 23:00:54
>>55
>文句があるなら、詐欺と過失を区別してる日本の法自体に文句つければ?
失敗した人は過失とかいってすぐ誤魔化すんだよね。
挙句に、日本の法律とか持ち出してくる。
工数水増しとか、スキル無いのにできるように見せかけるのも偽装の一種だよ。


57 :!=55:2006/06/25(日) 06:47:09
>> 56
失敗や成功の定義を明確化でないから困るんだよ。
明確化できると思っているなら >>55 の意見は理解できない。


58 :57++:2006/06/25(日) 06:52:24
>>52
の意見に賛成。

アーキテクトの問題は、成果物を他者評価できないから無責任になれる事。
PG,SEは検証工程で評価が可能
PMは納期、リリース後障害報告件数、プロジェクト単位収益で評価が可能

アーキテクトの評価はなんだ?


59 :仕様書無しさん:2006/06/25(日) 11:25:24
>>58
その指摘は現状を良く表現している。
設計品質の定量的評価はその性質上存在しないし
定性的評価さえそれをなしうる人間は存在しない。
ソフトは建築物を違って目に見えないしなw

60 :仕様書無しさん:2006/06/25(日) 13:31:01
>>58
>アーキテクトの評価はなんだ?

RUP では、アーキテクチャの検証は重要なマイルストーン
(Lifecycle Architecture: LCA)になっています。
利害関係者によってアーキテクチャなどが安定していて、
要求を満たすことが可能で、開発が安定して継続でき、
納期を守ることが可能か、といったことが検証されます。

61 :仕様書無しさん:2006/06/25(日) 13:34:21

プロジェクトで鬱病患者や失踪者をどれだけ出したかとかで定量的に評価出来ませんかね


62 :58:2006/06/25(日) 15:12:25
>>60
RUPですか、ノーマークでした。
アーキテクチャを知る一つの道筋としてRUPは、抑えた方がいい?

教材は、これでOK?
http://www.amazon.co.jp/exec/obidos/ASIN/4434052349/qid=1151215860/sr=1-2/ref=sr_1_10_2/503-2024717-2541525

63 :仕様書無しさん:2006/06/25(日) 16:09:07
>>62
>アーキテクチャを知る一つの道筋としてRUPは、抑えた方がいい?
方法論によって、アーキテクチャ、アーキテクトの意味は変わってくると思うのですが、
私の知る限り、RUPが最も具体的な定義をしています。

>教材は、これでOK?
はい、それは良い本です。
最初の方にある、簡単なアプリケーションを一週間ぐらいで作って、
「これが俺流RUPだ」みたいな例は RUPの全体像を
理解するのに最適だと思います。

http://www.amazon.co.jp/exec/obidos/ASIN/475614554X/qid=1151219145/sr=1-1/ref=sr_1_10_1/503-5356838-9476707
こっちは「入門」という割にはちととっつきにくい。


64 :仕様書無しさん:2006/06/26(月) 00:13:25
国内のRUPの成功事例でオープンになっている情報は有りますか?
ある国内ベンダーさんから、「RUPは実績乏しくてリスクも高い」
と聞いているので、実際にRUPを経験した企業に評価を聞きたいと
思っています。

65 :仕様書無しさん:2006/06/26(月) 00:24:07
>64
IBM

66 :仕様書無しさん:2006/06/26(月) 01:25:18
>>65
I○Mの説明は何度も聞いています。でも、実体とのギャップが
感じられます。
RAPを使用したユーザ企業から話を聞きたいのですが。

67 :仕様書無しさん:2006/06/26(月) 03:15:51
セミナーなんかの説明では、「紹介」のために、
全部の項目を一通り説明している。

で、根本的な誤解があって、紹介された項目を、
全て忠実に行わなければならない、
と思ってしまうと、ぜんぜんうまくいかない。
(し、どうやってやったらいいのか、悩むことになる)

>>62 の本を読むとわかるんだけど、RUP は、
バイキング料理のようなもので、
必要に応じて必要なものだを取って使うためのもので、
書いてあることを忠実に逐一なぞるためのものじゃない。

それこそ、顧客と朝飯食いながら相談したことをまとめて
ナプキンに箇条書きにして LCO、昼飯食いながら、
実装方法を説明してノートPCでデモして LCA、
みたいなやりかたでもぜんぜんかまわない。

IBMのプレゼンはどうもここのところの説明が欠けてるので、
必要以上に難しい印象をあたえているような気がする。


68 :58:2006/06/26(月) 06:27:57
>>63
情報ありがとう。

>>67
どの技法についてもいえる事だね。
でも知識がないからこそ、最初は技法の全てを試すしかない。
技法が自らの意思を持たない限り、
僕達は、時間をかけて技法を習得する覚悟をしなければいけない。


69 :仕様書無しさん:2006/06/26(月) 12:31:17
もう一つ筆問させて欲しい。
某社の説明によるとRUPを採用すれば、生産性も向上する
という話だったが、その某社の見積が一番高かった。
これって矛盾だと思うがどうなんでしょう?
RUPで価格半分になるなら、本物だと思います。


70 :仕様書無しさん:2006/06/26(月) 12:39:56
東京から大阪へ特急を使うと2時間半で1万5千円
夜行バスだと7時間で8千円
時間短い方が高いのはなぜ?

71 :仕様書無しさん:2006/06/26(月) 13:34:02
>>70
なんか的外れなたとえ話でつね。
では、
東京から福岡へ新幹線で行くと乗車時間:5 時間 2 分 総額:22,120 円
東京から福岡へ飛行機で行くと乗車時間:2 時間 15 分 総額:15,370 円
時間短い方が安いのはなぜ?



72 :仕様書無しさん:2006/06/26(月) 14:06:37
もうこの話は、飽〜きてくっとw

73 :仕様書無しさん:2006/06/26(月) 14:09:36
時間短い方が安いのは普通じゃねーか
人件費も安いし、車両、航空機を占有する時間も短かかったら安い

74 :仕様書無しさん:2006/06/26(月) 14:22:27
見積りで示す時間というのはあくまでコストを計算するためのもので
実際にかかる時間ではない

見積りで示す時間と実際にかかる時間のギャップを埋めるということは
デスマを発生しにくくすることと等価である

その手法としてRUPが有効とゆうだけ

75 :仕様書無しさん:2006/06/26(月) 14:59:06
>>72
このスレでもっとも輝かしいレス

76 :仕様書無しさん:2006/06/26(月) 15:31:26
>>74
何が言いたいのか分かりません。
RUPのプレゼンした人も、こちらから質問したら、しどろもどろ
だったよ。アーキテクトの人達はRUPがなぜどのように有効なのか
説得力のある説明をしてくれ。品質とコストを同時に改善できなけれ
ば、それは偽者だよ。


77 :仕様書無しさん:2006/06/26(月) 16:51:04
>>76
高い品質を保証する代わりに見積が上がる、ってそんなにおかしい話かねえ。
生産性が向上するかどうかは>>69でいう「某社」の中の人の話であって、
実際に発注側であるお前は単純に対費用効果を考えればいんじゃねの?

RUPがそれこそオブジェクト指向並みに浸透してきたら
値段も落ち着くでしょ。

78 :仕様書無しさん:2006/06/26(月) 19:06:16
>>77
>実際に発注側であるお前は単純に対費用効果を考えればいんじゃねの?
だから、費用対効果を明らかにしたいんだよ。
RUPが優れているなら、単価のアップは問題ないよ。それとRUPによる
工数削減効果を同時に示せっていってるんだよ。そのトータルで費用対
効果を評価するんだよ。RUPで高い品質が保証されるわけじゃないぞ。
実際のSEやPGがRUPに精通しているわけじゃないだろ。



79 :仕様書無しさん:2006/06/26(月) 19:43:18
RUPというのは、改善のための方法論の集合であって、
一概に費用対効果を出せるものじゃないと思うけど。

適用する組織における従来の手法や知識レベル、
業務の種類、さまざまな要素にあわせてカスタマイズしていくものだし、
「RUPにすれば 「どんな組織でもどんな分野でも」 XX% 改善されます。」
とは一概にいえない。
おそらく、場合によってはまったく適用しても意味がない場合もあるだろう。

他の方法論と同様、RUPも「銀の弾丸」ではない。

80 :仕様書無しさん:2006/06/26(月) 21:26:05
>>78
RUPを知っているのなら、現状のプロジェクトにRUPをフル適用したら
工期がどうなるかは計算できるでしょ。
残った期間を品質改善やリファクタリングに当てられるのであれば
それはつまり同じ工期で高い品質が保証出来るってことじゃん。
示せ、というより示してるからこその見積なんだろ?

それからSEやPGがRUP開発に慣れていないのなら、フル適用は逆に危険だと思う。
そういう意味でもボールはお前の手元にあるんだよ。

81 :仕様書無しさん:2006/06/26(月) 23:32:58
おい、お前等マジでいってんのか?

システムを利用する前に費用対効果なんて出せるわけねーだろ。
費用対効果の見積りは、気持ちよく印を押させるための演出
ウソだと思うなら見積り内容を保証した契約にするよう依頼してみ。


82 :仕様書無しさん:2006/06/26(月) 23:50:08
>>78
ていうか、単純に考えて
>>69
>RUPで価格半分になるなら、本物だと思います。

わざわざ新しい方法論使って単価半分になるなら、誰も取り入れないと思うが。
作る側にとっては同じ値段を少ない工数で作れるから得、
発注する側にとっては同程度以上の品質のシステムがより短期間に出来上がる代わりに値段が高い。
でも、RUP開発がスタンダードになれば価格競争が始まる。

本物、偽物以前に商売として当たり前のことのような気がするのは俺だけか。

83 :仕様書無しさん:2006/06/27(火) 00:11:33
>>82
>わざわざ新しい方法論使って単価半分になるなら、誰も取り入れないと思うが。
単価じゃなくて、見積総額だね。
確実に安く作れるベンダーがあれば、多くの仕事を受注できるようになるよ。
そうなれば、利益率も確保して、ビジネスボリュームも増やせると思うが..


84 :仕様書無しさん:2006/06/27(火) 00:24:18
それって結局安い値段で馬車馬のように働けってこと?

85 :仕様書無しさん:2006/06/27(火) 02:00:42
結局バカな客って安いシステムを発注して使い物にならないもんを手に入れるんだろ?

86 :仕様書無しさん:2006/06/27(火) 15:56:38
>>85
もっとバカな客は、高いシステムを発注して使い物にならないもんを手に入れるんだろ?



87 :仕様書無しさん:2006/06/27(火) 20:30:51
>>84
アジャイルという言葉のかわりに
これからは

安ジャイル

というにわかには信じがたい言葉が日本のIT業界に流行るようになる。

88 :仕様書無しさん:2006/06/27(火) 20:54:10
日本のシステムは世界一高いといわれている。
なぜなら丸投げの連中がバカ高い年収貰ってるからね。
こんなバカほど儲かる仕組みは良くないね。


89 :仕様書無しさん:2006/06/27(火) 22:32:05
RUPをyo-
入れてもyo-
誰も知らんyo-

90 :仕様書無しさん:2006/06/27(火) 23:34:25
うちの会社はRationalさえ知っているかあやしい

91 :仕様書無しさん:2006/06/28(水) 00:27:25
>>87
それ、すげー現実味あって首吊りたい


92 :真・コンピュータ用語辞典:2006/06/28(水) 09:04:31
あーきてくと
アーキテクト
【人々】
・現場も業務も知らないけれど、金銭欲やら功名心やら名誉欲だけは人一倍強いが、
理念や信念、思想が欠落しているオコサマを相手に、
「問題意識を持つ」という美しい謳い文句を掲げながら、
毎月毎月、不安を煽り立てるオコサマ技術者向けの雑誌などで、
「目指すに値する素晴らしい職種」という風に崇め奉られている、謎の職種。



93 :仕様書無しさん:2006/06/28(水) 16:56:55
アメで働いてるけど、いわゆるSEってあんまり聞かないな。
コーディングも設計も全部やってる。で、肩書きはソフトウェアエンジニア。
超巨大な所は知らんけど、中小は皆こんな感じだと思う。
上司は本も書くし、大学でも教えてるし、コーディングもして
設計もしてる。正直あんなおっさんになりたい。

94 :仕様書無しさん:2006/06/28(水) 17:37:12
>>87 安ジョンイル
に見えたw
どこの韓国人ですかと。

95 :仕様書無しさん:2006/06/28(水) 18:10:50
>>92
>毎月毎月、不安を煽り立てるオコサマ技術者向けの雑誌などで、
>「目指すに値する素晴らしい職種」という風に崇め奉られている、謎の職種。
いいとこ突いてるね。アーキテクトの多くがオコサマ的に見えてしまうのは
知識だけの頭でっかちなのに、それに気付かずに知識ひけらかして自己満足
しているてんですね。そのため、アーキテクトとか名刺に書いてあったら
それだけで、マイナスイメージ膨らんでしまう。

どこかに、これぞアーキテクトといえる人はいるんですか?


96 :仕様書無しさん:2006/06/28(水) 19:44:46
なんなんだこの中学生のケンカは。。

97 :仕様書無しさん:2006/06/28(水) 22:53:38
安ジャイル
 ∧||∧  
(  ⌒ ヽ 
 ∪  ノ 
  ∪∪  

98 :仕様書無しさん:2006/06/28(水) 23:01:46
安正日
 ∧||∧  
(  ⌒ ヽ 
 ∪  ノ 
  ∪∪  


99 :仕様書無しさん:2006/06/29(木) 02:00:05
>> 96
中学生の喧嘩のようにみえるが、日経ナンタラや技術サイトで語られる
アーキテクトより真実を語っている。

既に「アーキテクト」は、業界構造の問題代名詞となっている。


100 :仕様書無しさん:2006/06/29(木) 02:28:26

自称SEが増えすぎたから差別化するために名乗ってるだけだろ


101 :仕様書無しさん:2006/06/29(木) 02:41:03

世間的に思われているアーキテクトは
SEじゃなくて、PGからの派生職種じゃね〜の?

102 :仕様書無しさん:2006/06/29(木) 02:50:31
そう思われているとすればある意味成功ですね

103 :仕様書無しさん:2006/06/29(木) 10:27:48
>>100
アーキテクトはクラス設計やツール策定、インターフェース設計など
プログラミングのおいしいところだけを持っていって、
実際に汗水たらして実装するのは下っ端PGである自分たち。

そういうアドバイザー的な立場を羨み、妬み、やっかんで
「口だけ」「頭でっかち」「自己満足」といった批判になる。

ここはとても2chらしい負け犬スレだよww

104 :仕様書無しさん:2006/06/29(木) 10:59:25
>>103
ユーザ企業のものですが、ITアーキテクトなる人物が設計したものが
使えなくて、再度現場の担当SEさん、PG担当者さんが設計しなおした
事例があります。これは、ITアーキテクトという人が、業務プロセス
の理解が不足していたためです。技術を吸収することには興味があっ
ても、泥臭いシステムを最後まで仕上げると言うことには興味ない
ようでした。
>アーキテクトはクラス設計やツール策定、インターフェース設計など
>プログラミングのおいしいところだけを持っていって、
確かにそうですね。でもユーザ企業にとっては、これでは困るんですよ。
美味しいとこだけじゃなくて、結果に責任を持ってもらえないと。
アーキテクトの尻拭いしているSEさんって多いんじゃないかと思います。
特に、うちに出入りしているベンダのアーキテクトはひどいですね。

105 :仕様書無しさん:2006/06/29(木) 12:31:07
>>104
アーキテクトは基本的にSEがクライアントから汲み取った
要件定義や概要設計を元に、予算、現場状況、開発人数、スキルなどを加味して
クラス設計やハード構成を考える仕事。

よってアーキテクトが設計したものをSEが現場で設計しなおす、ということはありえない。
業務プロセスを理解したSEと構築プロセスを理解したアーキテクトが話し合うことによって
クライアントが納得できる設計が出来上がる。

つまり、>>104はアーキテクトとSEの打ち合わせが足りないか
まるっと作り話かのどちらか。

106 :仕様書無しさん:2006/06/29(木) 18:06:30
>>105 は世間知らず

107 :仕様書無しさん:2006/06/29(木) 18:19:38
>>106はポインタが理解できずに挫折したニート

108 :仕様書無しさん:2006/06/29(木) 18:54:24
なんでそうなる?
つまりはおまいさんがそうなのか?

109 :仕様書無しさん:2006/06/29(木) 18:57:22
まあ、世間を知ってれば
よくわからん定義のカタカナ職業が出てきたら
とりあえず名乗るやつがたくさんいることくらいはわかるわな。

SEの仕事しているSEがどれだけいるか。
PGと名乗れるだけ知識のあるPGがどれだけいるか。

>>104の会った「アーキテクト」も同類だろ。

110 :仕様書無しさん:2006/06/29(木) 19:11:00
根本的な疑問として
>>104
ITアーキテクトが設計をするのなら、SEは何をしてるの?
なんで現場のPG担当者がSEと同じように設計を直しているの?
他の人が設計を直しているってことは、そのITアーキテクトは現場にいないんだよね。
現場に行かない人に会社によって多岐にわたる業務プロセスを理解させて設計させるつもりだったの?
で結果責任をPM、SEすっ飛ばしてアーキテクトに与えるの?


111 :104:2006/06/29(木) 20:31:20
お答えします。
>なんで現場のPG担当者がSEと同じように設計を直しているの?
>他の人が設計を直しているってことは、そのITアーキテクトは現場にいないんだよね。
そのアーキテクトを名乗る人は、商談サポート業務が忙しいそうです。
だから、すぐに次の商談へ向かってしまいました。残ったのは、設計したとは
とても言えない様な代物です。ITアーキテクトさんは、最後まで責任もって
システムを仕上げて欲しいのです。そうでないと、ただの飾り物です。
事実、知識だけで実戦には役に立たなそうだったので、呼び戻したりしません
でした。


112 :仕様書無しさん:2006/06/29(木) 20:53:58
>>111
ユーザ企業、ってことは、「ITアーキテクト」さんは、
(多分)ベンダさんの人なんだよね。
そもsも、あなたの会社とベンダさんとでは、どういう契約をしてたの?


113 :仕様書無しさん:2006/06/29(木) 23:56:14
そもそもアーキテクトって業務要件も把握した上で、システムに最適なアーキテクチャを決める人だろ
それに肉付けするのはSEでもアーキテクトになるんじゃね?(組織により変わるとは思う)

114 :仕様書無しさん:2006/06/30(金) 01:01:49
ウォータフォールと、スパイラルではかなり話が違うような。

スパイラルでは、早い段階の反復でアーキテクチャの問題
(業務に合わないとかパフォーマンスが出ないとか)を洗い出して、
洗練させていく(もちろん、これはアーキテクトが中心になって進める)。

最初にえいやで作ったアーキテクチャで全要件を一斉に作ったら、
提供段階で問題山盛りになるのは目に見えてる。

115 :仕様書無しさん:2006/06/30(金) 09:48:35
>>111
ていうか商談するのは営業じゃねの。

技術的な専門分野からシステムを見つめる必要があるから
アーキテクトなんつー分野が分かれてきたわけで
商談サポートはそれこそSEの仕事だろ。

それより>>110が突っ込みたかったのは
設計するのはアーキテクト、
それを直すのはPG担当者と一緒、て
どんだけSE使えねーんだよ、という所だと思うが。

116 :仕様書無しさん:2006/06/30(金) 11:40:44
>>111
>ITアーキテクトさんは、最後まで責任もってシステムを仕上げて欲しいのです。
お前はアーキテクトという職業を根本的に勘違いしている。

実装、デバッグ、テストの段階にアーキテクトがいても
お茶汲みくらいの役にしか立たん。

117 :仕様書無しさん:2006/06/30(金) 13:22:34
アーキテクトは「提案はした。あとはがんばってね」でいいんだよ。
アーキテクトにテストまで付き合ってもらうなんて思いもしない。

アーキテクトがプログラミングのおいしいところを
持って行くかどうかはともかく、
いいアーキテクチャは確かにみんなを幸せにするのは確かだ。

だからアーキテクトする以上、ベストな解を出してくれ。
常に出せとは言わないが、出せるよう努力をしてくれ。
アーキテクチャを受け取った人々のその後を己にフィードバックしてくれ。
>>104やその他のアーキテクトはそれをしているのだろうか。




118 :仕様書無しさん:2006/06/30(金) 13:39:47
僕は道を歩いていて、ときどきクスッと笑うことがある。
「ああ、自分は天下のアーキテクトなんだ」と思うと、嬉しさがこみ上げてくる。
激烈な入社試験を突破してから5年。
アーキテクトになったときのあの喜びがいまだに続いている。
「開発の源流 天下のアーキテクト」・・・・・
その言葉を聞くと、僕は自然と身が引き締まります。
アーキテクトの先輩方に恥じない自分であっただろうか・・・・。
しかし、先輩方は僕に語りかけます。
「いいかい?伝統というのは若手が作り上げていく物なのだよ」と。
僕は感動に打ち震えます。
「会社が何をしてくれるかを問うてはならない。
君が会社で何をなしうるかを問いたまえ」
僕は使命感に胸が熱くなり、武者震いを禁じえませんでした。
でもそれは日本の社会を根底で支える最高のエリートである僕たちを
鍛えるための天の配剤なのでしょう。
アーキテクトを作りあげてきた先輩はじめ先達の深い知恵なのでしょう。
アーキテクトになることにより、僕たち社員は伝統を日々紡いでゆくのです。
嗚呼なんてすばらしきアーキテクト哉。
知名度は世界的。人気、実力すべてにおいて並びなき王者。
素晴らしい実績。余計な説明は一切いらない。
ただ周りの人には「アーキテクトです」の一言で羨望の眼差しが。
合コンのたびに繰返される若い女性たちの側からの交際申し込み。
近所のマダム達からの熱いまなざし。
そして世界中の街を歩くたびに味わう圧倒的なアーキテクトパワーの威力。
アーキテクトになって本当によかった。

119 :仕様書無しさん:2006/06/30(金) 14:30:17
>>118
アーキテクトになると
札束の風呂に入るのも夢じゃなさそうだなw

120 :仕様書無しさん:2006/06/30(金) 14:42:30
>>118
真性バカでつね。


121 :仕様書無しさん:2006/06/30(金) 14:43:23
>>117
ベストな解を出すには機能要求よりもむしろ機能外要求の理解、把握が大切。
つまり>>104のいう「業務プロセスの理解が不足」というのは
セキュリティを重視しているのか、レスポンスを重視しているのか、
今後どの分野をどの程度拡張する可能性があるのか等
機能外要求が満たされていなかったのではないか。

結果、ど頭のヒアリングが充分じゃなかった、ということになる。
>>104がシステムのド素人と考えれば、顧客要求を引き出せなかった人間が悪い。
つまり、ヒアリング時にアーキテクトが同席していたのならアーキテクトが悪い。
同席していなかったのならSEが悪い。又はSEに突っ込めなかったアーキテクトが悪い。


122 :仕様書無しさん:2006/06/30(金) 15:23:38
>>118
最高にワロタ、

123 :仕様書無しさん:2006/06/30(金) 22:09:12
>>116
それは違うぞ。

まず第一にサンプル実装の一つもないアーキテクチャなんて、絵に描いた餅だということ。
第二に、デバッグやテストの方法もアーキテクチャの一部だ。

実装の問題を反映してアーキテクチャを洗練させていくのが
アーキテクトの仕事だ。


124 :仕様書無しさん:2006/06/30(金) 23:00:59
>>117

>いいアーキテクチャは確かにみんなを幸せにするのは確かだ。

みんなを幸せにするからいいアーキテクチャなんだよ。
定義が逆だよ。


125 :仕様書無しさん:2006/07/01(土) 16:40:22
ITアーキテクトという職種が発生したのは以下の理由です。
1.現場のSEが最新技術についていけなくなった
2.商談時などに顧客からの質問に対応できないケースがでてきた
3.しかたなく、最新技術を説明できる若手の要員を養成することにした
4.とりあえず、知識を詰め込んで受け売りの対応ができるようにした
5.SEと区別するためにアーキテクトという名前をつけた
6.顧客対応が苦手なSEや技術指向の強いエンジニアが割り当てられた
7.結局、アーキテクトの多くはウンチクたれるだけで、プロジェクトに深く関わらない
こんなところです。優秀なアーキテクトもいると思いますが、肩書きだけで
判断しないことです。SEが技術レベルをアップしてくれれば、アーキテクトは不要
になります。アーキテクトに頼っているベンダーは、「ウチのSEはアホです」と
暴露しているようなものです。


126 :仕様書無しさん:2006/07/01(土) 17:09:00
>1.現場のSEが最新技術についていけなくなった
 〜
>4.とりあえず、知識を詰め込んで受け売りの対応ができるようにした

これって顧客に説明したことを実現できる能力を持ってる奴は一人もいない、
ってことなんじゃあ・・・。

つうか「アーキテクト(設計者)」という本来の意味とはもうまったく関係ないな。

127 :仕様書無しさん:2006/07/01(土) 18:15:01
プログラムできないでテストだけやってる奴がSE名乗りまくってるから
本当にできるSEがそいつらと一緒にされたくなくて
アーキテクト自称してる、と解釈してたが

128 :仕様書無しさん:2006/07/01(土) 18:57:37
頭のいい欧米のエンジニア:新しいやりかたを考える → 実績を出す → 本を書く
  ↓
頭のいい日本のエンジニア:本を読む → やってみて実績を出す → 話題にする
  ↓
日×なんたら:「元の本は読まずに」 → 話題にしてるエンジニアの話だけ聞いて特集をぶち上げる
  ↓
頭の○○な日本のエンジニア:「記事本文は読まずに」 → 見出しを見て「これからは○○かー」
                   実績以前に実践する知識すらない状態で → 「はじめまして、○○の山田です。」


129 :仕様書無しさん:2006/07/02(日) 06:25:04
ITSSのアーキテクチャーは、アプリケーションEの作業開始時期より先行して
顧客要件を伺いシステムとプロジェクト構成を決めるらしいが、
それを実現する手法ってなんかあるんですか?

一番気になる事は、顧客要件からアーキテクト要件を引き出す事。


130 :仕様書無しさん:2006/07/02(日) 13:39:50
>>123
餅の絵を描いて、これと同じような餅をこう作ってくださいとレシピ表を置くのがアーキテクトの仕事。
デバッグやテストの方法を考えるのもアーキテクチャの一部だが、実際にデバッグやテストが始まったら用済み。
逆に始まってるのにアーキテクトに仕事があるということは、元々のアーキテクチャが未完成、ということ。
また、アーキテクチャを洗練させていくのはアーキテクト自身の問題。
アジャイルなら実装と同時進行で進んでいくが、
基本的に実装した結果、別の仕様や定義が出てくるだけの話で、実装の問題をアーキテクトが解決するということはない。

>>126
おまい、騙されやすいだろw

>>129
今までと同じ。ヒアリング。

131 :仕様書無しさん:2006/07/02(日) 14:47:11
>>130
>餅の絵を描いて、これと同じような餅をこう作ってくださいとレシピ表を置くのがアーキテクトの仕事。
実際に簡単な餅を作って検証するまではアーキテクトの仕事。

>逆に始まってるのにアーキテクトに仕事があるということは、元々のアーキテクチャが未完成、ということ。
逆に、それが普通だ、最初から完璧なアーキテクチャなんてない。
だから、アーキテクトは開発チームに入って実際の開発にも参加する。

>アジャイルなら実装と同時進行で進んでいくが、
>基本的に実装した結果、別の仕様や定義が出てくるだけの話で、実装の問題をアーキテクトが解決するということはない。
その「別の仕様や定義」って具体的に何の仕様や定義?要件?設計?実装?何の話?

実装の(技術的)問題を解決しないならアーキテクトの存在意義って無いような。
それ以外の他に何をするっての?


132 :仕様書無しさん:2006/07/02(日) 20:29:11
クライアントと世間話

133 :129:2006/07/03(月) 05:15:33
>>130
問いで”顧客要件を伺い”と聞いているにも関らず
その答えが”ヒアリング”とは、
さては君は、妄想で返答しているなぁ!

はい次の方、お答えお待ちしております。


134 :仕様書無しさん:2006/07/03(月) 10:25:02
>>131
実際に開発してみた結果アーキテクチャがおかしい、てのが普通だと思ってるならこれからも相当苦労すると思うよ。
ウォーターフォールで開発段階まで言ってアーキテクチャがおかしいので問題が出ました、なんてことになったら
最初っから全部やり直しだ。アーキテクチャってのはそういうもの。極端に言えばJavaで実装してたのをC#でやり直せって言ってるような物。
そういうことが無いようにSEとアーキテクトでどんな状況でも対応できるようなアーキテクチャを設計するんだよ。

>その「別の仕様や定義」って具体的に何の仕様や定義?要件?設計?実装?何の話?

アジャイルやったことある?
細かい物を一つ一つ実装段階まで進めて固めていく設計方針で問題が出るってことは、
つまりその前までに作り上げたプログラムの設計や仕様を覆す必要が出てきた、てこと。
そのために設計を作り直したり仕様を考えたりするのはアーキテクトの仕事。

>実装の(技術的)問題を解決しないならアーキテクトの存在意義って無いような。
概要設計をSEがして、システム設計をアーキテクトがして、実装の技術的問題を解決するのがアーキテクト?
じゃあPGって何するの。コーダー?キーパンチャー?

設計思想や構成に無理があって実装できない、てんならアーキテクトが責任もって直すべき。
でも実装の技術的問題ってんならそれはPGの専門分野じゃない。

>>133
今まで一度も顧客用件からアーキテクト要件を引き出したことないの?
顧客要件を伺ってシステムとプロジェクト構成を決めたことがないの?
今までと同じだって言ってんじゃん。

135 :仕様書無しさん:2006/07/03(月) 11:50:27
「最初から完璧なアーキテクチャなんてない」なんてただの言い訳でしょ。
PGからバグ発見されたときに
「最初から完璧なシステムなんてない」
なんて言われたらぶっ飛ばすなww

136 :仕様書無しさん:2006/07/03(月) 15:37:46
最初から完璧なシステムなんてない

137 :仕様書無しさん:2006/07/03(月) 16:23:22
最初どころか最後まで完璧なシステムなんて存在しない

138 :仕様書無しさん:2006/07/03(月) 16:33:54
途中には中途半端なシステムが存在する。

139 :仕様書無しさん:2006/07/03(月) 20:50:09
>>134
>実際に開発してみた結果アーキテクチャがおかしい、てのが普通だと思ってるならこれからも相当苦労すると思うよ。
>ウォーターフォールで開発段階まで言ってアーキテクチャがおかしいので問題が出ました、なんてことになったら
>最初っから全部やり直しだ。
まあ、リスクの大きい開発にウォーターフォールを使うことについての批判は、
だいたいそういう内容だね。
それがなにか?

>アーキテクチャってのはそういうもの。極端に言えばJavaで実装してたのをC#でやり直せって言ってるような物。
意味がわからん。前半の文章とどうつながるんだ?

>基本的に実装した結果、別の仕様や定義が出てくるだけの話で、実装の問題をアーキテクトが解決するということはない。
>そのために設計を作り直したり仕様を考えたりするのはアーキテクトの仕事。
言ってること一貫性が無いような気がするが。

>概要設計をSEがして、システム設計をアーキテクトがして、実装の技術的問題を解決するのがアーキテクト?
>じゃあPGって何するの。コーダー?キーパンチャー?
とりあえず、PGやSEがどういう「役割」なのかは知らない、アジャイルにもRUPにも、
SEやPGなんて役割は出てこない。

>設計思想や構成に無理があって実装できない、てんならアーキテクトが責任もって直すべき。
だから、「私は」最初からそう言ってるじゃん。

>でも実装の技術的問題ってんならそれはPGの専門分野じゃない。
君においてPGとやらがどういう役割を意味しているのか知らんが、
「プログラム作成者」という意味なら、だから、それは「アーキテクト」の役割だと、
私は言っているはずだが?


140 :129:2006/07/03(月) 23:32:14
>>134
>アーキテクトでどんな状況でも対応できるようなアーキテクチャを設計する

どんな状況でも対応できるようなアーキテクチャを設計し
公開したらアーキテクチャが対応する問題って無くなるんじゃないの?


141 :仕様書無しさん:2006/07/04(火) 09:09:20
>>139
「設計思想や構成に無理があって実装出来ない」というのと
「実装の技術的問題」というのは違うということだろ。

お前が言ってるのは全てアーキテクトの実力不足による問題。
流れは「アーキテクトは最後まで責任を持ってシステムを仕上げて欲しい」、つまりテストやデバッグ、導入、納品時にも
アーキテクトが関わるべきだ、という>>111から始まっていること。

「なぜ構成を使用する段階になってまで構成設計者が必要なのか」という話をしてるんだろ?
その理由が「開発し終わるまでその構成が正しいかどうかわからないから」って論点ずれてるよ。

自分のやったことに責任を持つのは当たり前のことでさ。
そういうことを言ってるんじゃなくてアーキテクトの役割として開発段階で関わる必要があるのか、て話をしてるんだよ>>134は。
「PGは設計段階で必要か」というのと同じ土俵の話。

142 :仕様書無しさん:2006/07/04(火) 09:12:23
>>139
すいません、アーキテクトがいるアジャイルの世界にはPGもSEもいないんですか。。。。
じゃ、誰がどうやってシステム作るんでしょうか。。。。

143 :仕様書無しさん:2006/07/04(火) 09:29:30
>>140
すいません、あなたは顧客要件からアーキテクト要件を引き出す方法がわかったのでしょうか。。。。
身近のSEかママンに聞いてみたのでしょうか。。。。

144 :仕様書無しさん:2006/07/04(火) 09:52:40
>>139
>とりあえず、PGやSEがどういう「役割」なのかは知らない、アジャイルにもRUPにも、
>SEやPGなんて役割は出てこない。

>「プログラム作成者」という意味なら、だから、それは「アーキテクト」の役割だ


SEやPGなんていない。プログラム作成者はアーキテクト。

つまりさ、>>139はいつも一人で作ってるんだよ。


145 :仕様書無しさん:2006/07/04(火) 09:55:43
長文を単文に区切って反論するやつは、要旨を理解できずに揚げ足を取りたいだけ。文句を言いたいだけ。

つまり>>134>>139>>140>>144もクソ。
アーキテクトを語るより日本語の勉強しろカス。

146 :仕様書無しさん:2006/07/04(火) 12:07:19
           i::::::::/'" ̄ ̄ヾi
           |:::::::| ,,,,,_  ,,,,,,| 
           |r-==( 。);( 。)   
           ( ヽ  :::__)..:: }
        ,____/ヽ  ー== ;  ほうほう
     r'"ヽ   t、   \___ !   それで?
    / 、、i    ヽ__,,/
    / ヽノ  j ,   j |ヽ 
    |⌒`'、__ / /   /r  |
    {     ̄''ー-、,,_,ヘ^ |
    ゝ-,,,_____)--、j
    /  \__       /
    |      "'ー‐‐---''


147 :仕様書無しさん:2006/07/04(火) 12:14:52
>>143

>>47
>>48


148 :仕様書無しさん:2006/07/04(火) 12:16:41
間違い

>>142

>>47
>>48


149 :仕様書無しさん:2006/07/04(火) 12:59:56
うぜーなここな日本だ。


150 :仕様書無しさん:2006/07/04(火) 13:27:33
日本(笑)

151 :仕様書無しさん:2006/07/04(火) 14:16:52
ここな日本(笑)

152 :仕様書無しさん:2006/07/04(火) 16:30:38
アーキテクトって言われる人の人物像ってどんなものよ?
みんな答えれ。

1.年齢は? ○○歳台
2.PGできるのは必須?できなくてもいい?
3.業務要件までキッチリシステム設計に落とす?大まかな概念設計だけ?
4.プロジェクトの最後までメンバーとして活動?最初だけ?
5.実際に開発せたら右に出るもの無し?単なる技術ヲタクのウンチクたれ?
6.プロジェクトが失敗したとき責任取る?SEやPGのせいにする?

さあどうだ。


153 :仕様書無しさん:2006/07/04(火) 17:37:54
> 1.年齢は? ○○歳台

30歳以上

> 2.PGできるのは必須?できなくてもいい?

むしろPGしか出来ない。

> 3.業務要件までキッチリシステム設計に落とす?大まかな概念設計だけ?

上流工程はしない。

> 4.プロジェクトの最後までメンバーとして活動?最初だけ?

途中から入って、途中で抜ける。

> 5.実際に開発せたら右に出るもの無し?単なる技術ヲタクのウンチクたれ?

YES

> 6.プロジェクトが失敗したとき責任取る?SEやPGのせいにする?

責任をとるほどの権限は最初から持ってない。


154 :仕様書無しさん:2006/07/04(火) 20:28:08
相変わらず肩書き好きよね、この業界(´・ω・`)
名前がないと仕事できないんだろか?
やることは何も変わってないんだが。

155 :仕様書無しさん:2006/07/04(火) 21:14:27
>>154
無駄にカテゴライズして記事を書く音楽雑誌に似てる。
別に音楽だけじゃないか、ファッションもなんでもそう。
肩書き作って、根拠の無い自慢して、人月単価増やしたいだけ。
「プログラマ」って肩書きすら邪魔だよ、もーマンドクサ。

156 :仕様書無しさん:2006/07/04(火) 21:26:56
>>153
>上流工程はしない。
これって業務分析ってこと?システム構成とアプリ構成だけするの?
アーキテクトはUMLを書くのでしょうか?



157 :仕様書無しさん:2006/07/04(火) 23:03:12
横レスですが

>アーキテクトはUMLを書くのでしょうか?

もちろん書くけど。
むしろ、プロファイル作ったり、OCLやQVT書いたりする。


158 :仕様書無しさん:2006/07/04(火) 23:31:59
>>145
主旨がずれているなら、そういえばいいじゃん。
アーキテクチャーを語る前に...


159 :仕様書無しさん:2006/07/05(水) 00:53:52
なんだかんだ言って、アーキテクトって曖昧な職種ですね。
自称でアーキテクトになれそうです。
私は、プロジェクトメンバーに属さないサポート要員をアーキテクトと
呼んでいると思っています。そんな大した者じゃないです。


160 :仕様書無しさん:2006/07/05(水) 01:05:03
エヴァンジェリストもそのうちバッシングに遭うのだろうか。

161 :仕様書無しさん:2006/07/05(水) 01:14:17
本来の意味を知らずに、調べるつもりもないけど、
知ったかぶりだけしたい奴が、
過剰に持ち上げたり、貶したりしている間に、

本来の意味がわかるぐらいに勉強してる奴は、
その知識を仕事に生かして、成果を挙げているだろう。

162 :仕様書無しさん:2006/07/05(水) 09:25:47
なんでこういうことに興味がある人ってUMLとかアジャイルとかに夢もつんだろう?

163 :仕様書無しさん:2006/07/05(水) 10:56:13
文系の人なんじゃない?

164 :仕様書無しさん:2006/07/05(水) 11:58:43
アーキテクト=文系(笑)


165 :仕様書無しさん:2006/07/05(水) 20:04:01
夢持つのは実際にやったことがないからじゃない。

166 :仕様書無しさん:2006/07/05(水) 22:16:37
実際にやったことがない(笑)

167 :仕様書無しさん:2006/07/05(水) 23:09:53
>> 161
本来の意味があると思っているの?
組織における役割定義の性質を知らんのかね。


168 :仕様書無しさん:2006/07/05(水) 23:35:04
>>167
まあ、意味の定義は恣意的だから、唯一の意味といえるものはないよね。
でもまあ、役に立つ方法論の中でその言葉がなんらかの意味で使われてて、
それなりの評価を受けているときに、そういう方法論自体を勉強しようとせずに、
「自分の組織におけるその言葉の定義」を、自分の組織の外で持ち出すのって、
無意味だよね。

169 :仕様書無しさん:2006/07/06(木) 12:05:07
>>168
でも役割について本来の意味が無かったら共通言語として会話が成立しないんじゃ。。。
プログラマーってこういうことをする人、ていうのが共通意識としてあるからマ板も成立するんだろ。

「うちではこういうのをプログラマーと呼ぶ」といって服屋や魚屋がマ板にこられても困るし。

170 :仕様書無しさん:2006/07/06(木) 20:35:52
>>169
会話が成立するためには、
会話の当事者で共通に了解されている意味があればいいのであって、
普遍的な「本来の意味」は必要ない、という話。

この世界だって、旧電電関係会社でしか通じない言葉とかあるし、
「プログラマ」の意味だって、業界関係者の認識と、
一般人の認識には結構違いがある。


171 :仕様書無しさん:2006/07/07(金) 12:05:37
>>170
つまりアーキテクトという職種の役割に関して共通に了解されているものがないから
このスレがおかしくなってるわけね。

172 :仕様書無しさん:2006/07/07(金) 12:21:03
虚業ってこと?

173 :仕様書無しさん:2006/07/07(金) 12:45:21

虚業になってるケースもあるし、
そうじゃないこともある。

ここで批判されているのは虚業だし、
絶賛されてるのは成功しているケース。

それくらい読めば分かるだろ。


174 :仕様書無しさん:2006/07/07(金) 13:43:25
成功しているケースでアーキテクトを定義すれば?

175 :仕様書無しさん:2006/07/07(金) 14:37:15

それ以外の虚業はアーキテクトではないとおっしゃりたいのですか?


176 :仕様書無しさん:2006/07/07(金) 21:35:51
ないかどうかはともかく、虚業における定義は役に立たない、というだけのこと。

177 :167:2006/07/07(金) 23:04:43
>>171
スレがおかしいのは自分の夢であるアーキテクチャーを
正当化しようとする行為にある。


178 :仕様書無しさん:2006/07/08(土) 00:34:23
漏れ?もちろん、名刺にもアーキテクチャーって書いてますが、何か?

179 :仕様書無しさん:2006/07/08(土) 08:52:40

アーキテクチャーっていうと世間的には建築士なんだよ


180 :仕様書無しさん:2006/07/08(土) 12:19:04
>>178
>名刺にもアーキテクチャーって書いてますが、何か?
おバカな会社だね。

181 :仕様書無しさん:2006/07/08(土) 13:07:32
×アーキテクチャー
○アーキテクチャ
◎アーキテクト

建築士
architect // authorized architect and builder // registered architect

182 :仕様書無しさん:2006/07/08(土) 14:45:43
>>178
アーキテクチャって…お前はアプリケーションモデルか何かか?
人間にあらず。

183 :仕様書無しさん:2006/07/08(土) 15:08:45
技術はあるけど、対人がダメなやつに、
高給を与えつつ技術の仕事を続けてもらう、
それがアーキテクト。

どこの国でもコンピュータが得意なやつは対人が苦手なやつが多いよね。

これがすべてだとは思ってないけど、結構本質ついてると思う。

184 :仕様書無しさん:2006/07/08(土) 15:21:38
最終的には、アーキテクトも相当なコミニュケーション能力が必要になるよ。
まず、コード書く人間やマネージャに、アーキテクチャを説明して、
納得してもらわなければならない。

コード書く人間には、どういうツールを使ってどういうスタイルで作るのか、
マネージャには、どういうソフトやツールを買う必要があって、
なぜそれが必要でどのくらいの効果があるのか、
なぜそういうアーキテクチャを選んだのか、どういう効果があるのか、
といったことをプレゼンして納得させなきゃならない。

対人がまったくダメで大丈夫なのはコードを書くだけの人間ぐらいじゃなかろうか。


185 :仕様書無しさん:2006/07/08(土) 15:28:02
アーキテクトに対人能力欠けてたら終わってる。

186 :仕様書無しさん:2006/07/09(日) 03:27:55
アーキテクトって研究職じゃないの?

187 :仕様書無しさん:2006/07/09(日) 04:56:24
オブジェクト指向プログラミングで内部構成定義の総括担当をするアーキテクト

プロジェクトマネージャーから内部工程管理部分を別職業にしたアーキテクト

各技術要素の技術担当者の技術要件をとりまとめる役のアーキテクト

世間で言われるいずれのアーキテクトも相当なコミュニケーション能力が求められる。
このスレで無闇にアーキテクト擁護している奴らは何れも似非アーキテクトだよ。


せいぜい
PGの職業問題を解決する事を期待されているアーキテクト職業物語
ぐらいだろコミュニケーション能力が要求されないアーキテクト像は。


188 :仕様書無しさん:2006/07/09(日) 08:37:42
>このスレで無闇にアーキテクト擁護している奴らは何れも似非アーキテクトだよ。
アーキテクトに批判的な文脈以外で、
コミニュケーション能力が要らないなんてこと言ってるレスあったっけ?


189 :仕様書無しさん:2006/07/09(日) 11:01:29
>>188

>>183

190 :仕様書無しさん:2006/07/09(日) 12:54:21
>>189
>アーキテクトに批判的な文脈以外で、

191 :仕様書無しさん:2006/07/09(日) 17:02:47
>>190

>>183 はアーキテクトを批判してるわけじゃないと思う

192 :仕様書無しさん:2006/07/09(日) 17:14:28
>>191
じゃあ、擁護してると思う?

こんな細かい話はかったるくてできればしたくないんだけど、

・「アーキテクトを批判する」
・「アーキテクトという言葉を批判的な文脈で使う」

この違い、わかる?
わかってるのにあえて無視してる?


193 :仕様書無しさん:2006/07/09(日) 17:18:35

じゃあ、批判してると思う?
こんな細かい話はかったるくてできればしたくないんだけど、

・「無闇にアーキテクト擁護している」
・「アーキテクトに批判的な文脈以外で」

この違い、わかる?
わかってるのにあえて無視してる?


194 :仕様書無しさん:2006/07/10(月) 11:45:30
>>193
そこまで細かい話をするくらいなら
まずは>>187に「奴ら」と書いてあるのだから
>>183以外の例をどんどん挙げていけばいいんじゃないの?

ついでに言うとこのスレのアーキテクトに対する批判的レスの要旨は
「アーキテクトはコミュニケーション能力のない技術ヲタPGが
SEやPMになれない代わりに知識のみを武器に設計に首を突っ込んでくる、
いわば虚業にすぎない」ということ。
>>183はその要旨から外れていない。つまりはアーキテクトを批判的に見ている。
それを「結構本質突いていると思う」の一言で「無闇にアーキテクト擁護している」と
捉えてしまうお前の文章読解力が問題になっているんだと思う。


195 :仕様書無しさん:2006/07/10(月) 12:01:16

おまえ頭固いんとちゃう?


196 :仕様書無しさん:2006/07/12(水) 00:12:32
アーキテクトっていう人は若い人が多いが、経験が無さすぎ。
その結果、技術論は語れてもシステム設計などの実務能力が無い。
営業用の見せ玉みたいなのが多いので気を付けれ!
そういうベンダーほど、実際のSEの技術力の落差が大きいもんだ。


197 :仕様書無しさん:2006/07/13(木) 20:50:34
ベンダーの30歳ITアーキテクトって年収どれくらい?


198 :仕様書無しさん:2006/07/13(木) 20:58:29
ABCだと400万くらい?

199 :仕様書無しさん:2006/07/14(金) 01:06:33
>>198
ABC?


200 :仕様書無しさん:2006/07/14(金) 05:34:03
最近、メディアでもITアーキテクトの話は下火になったな。
流行り廃りも日進月歩だな。


201 :仕様書無しさん:2006/07/14(金) 13:27:52
にっしん-げっぽ 5 【日進月歩】

日ごと月ごとに、たえず進歩すること。


三省堂提供「大辞林 第二版」より

202 :仕様書無しさん:2006/07/14(金) 23:30:57
俺達一生懸命エンジニアになってみたのはいいけどさ…

日本ってぶっちゃけ
エンジニアなんて不要じゃね?
まだ詐欺師にでもなった方が世の中の役にたたね?

余りの低待遇に発狂しそうになってきた

203 :仕様書無しさん:2006/07/14(金) 23:59:01
そうだな
(詐)技師の方が待遇は良さそうだ
世の中の役に立っているかは知らんが……

204 :仕様書無しさん:2006/07/15(土) 03:18:27
日本では、優秀でコストの高いエンジニアよりも、安い海外での開発
を選択してしまう。
仮にITアーキテクトとかが優れたシステム設計できたとしても、
開発が低スキルの人海戦術では無意味ですね。日本の技術者は、もっと
コストパフォーマンスをアピールできるようになることが必要です。


205 :仕様書無しさん:2006/07/15(土) 03:23:53
日本では、優秀でコストの高いエンジニアよりも、安い海外での開発
を選択してしまう。
仮にITアーキテクトとかが優れたシステム設計できたとしても、
開発が低スキルの人海戦術では無意味ですね。日本の技術者は、もっと
コストパフォーマンスをアピールできるようになることが必要です。


206 :仕様書無しさん:2006/07/15(土) 09:28:00
というかよ、コストというけどそれほんと?
アーキテクトが何人も必要なプロジェクトってないだろが
PG2人分の経費をひとりに当てるだけ
それでプロジェクトの効率がぐっと向上するならそのほうがいい
要はツール導入と同じ判断だよな

207 :仕様書無しさん:2006/07/15(土) 09:31:46
そもそも今のプロジェクトは人海戦術じゃ採算とれないでしょ

208 :仕様書無しさん:2006/07/15(土) 10:10:26
>>205
204のエンジニアとはPGのことと思われ。
うちの会社も中国のアウトソーシングを使えって上から言われて
ますが、理由はただ安いからですね。
経験者によると、そんなに甘いものじゃないようです。


209 :仕様書無しさん:2006/08/02(水) 15:56:13
ITアーキテクトなんて本も出てるね。
ITアーキテクト(笑)

210 :仕様書無しさん:2006/09/03(日) 02:45:47
I○Mのアーキテクト。まったく使えん。
知ったかぶりの鼻持ちならん椰子だ。



211 :仕様書無しさん:2006/10/07(土) 11:45:55
とりあえずこのスレの住人からは酷く負け犬臭がするな。
アーキテクトがダメ人間であるという話は十分過ぎるほど
伝わってくるが、ひがんでないか?
アーキテクトって、単語はただの値札だろ?

212 :仕様書無しさん:2006/10/07(土) 15:15:18
飽ーきてきた(笑)

213 :仕様書無しさん:2006/10/10(火) 16:46:09
ひがんでないか?
ひがんでないか?
ひがんでないか?


214 :仕様書無しさん:2006/11/20(月) 22:26:01
アーキテクトってけっきょく、
プログラマに毛がはえたようなもんってことでFA?

215 :仕様書無しさん:2006/11/20(月) 22:45:08
会社によって全然違うんじゃない?

216 :仕様書無しさん:2006/11/20(月) 22:51:53
なんだライブラリアンのことか

217 :仕様書無しさん:2006/11/20(月) 23:06:47
ITアーキテクトねえ...。
「建築士」に対して失礼じゃないのか。
IT構築基準法すらねーのに。自称でしょ?
業界内でその呼び方は改めるべきではないのか...。

っても建築基準法と建築士法を成立させたのは、かの田中角栄。尊敬。
日本の一級建築士登録第一号も、かの田中角栄。
これってなんか...「俺様が法律」ってこと?という気がしなくもない。







218 :仕様書無しさん:2007/02/09(金) 19:46:51
アーキテクトw

219 :仕様書無しさん:2007/02/10(土) 03:38:15
俺がアーキテクトとして関わるプロジェクトは片っ端から頓挫していくので、
社内の連中は俺様のことをこう呼んでいる。

「システムアナーキスト」


220 :仕様書無しさん:2007/02/10(土) 04:22:55
建築の連中が「アーキ」というのに違和感がある

221 :仕様書無しさん:2007/02/11(日) 19:41:48
アナーキー

222 :730:2007/02/12(月) 00:43:34
>>210
>知ったかぶりの鼻持ちならん椰子だ。

俺も今回ばかりはハッタリを見破られていると思う。
すみません。一生懸命やらせていただきます。m(__)m

64 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)