日本のソフトウェ業界はアーキテクトが極端に少ない

0001仕様書無しさん2012/11/23(金) 11:20:11.21
ここのプログラマがてんでバラバラに
コードを書いているだけ。

全体の構成を考える人がいない。
全体の構成を考えながらコードを書ける人もいない。

まとまりがない、重複が多い、だからバグもなくならない。

だからアメリカに負ける。

0002仕様書無しさん2012/11/23(金) 11:50:37.51
外資が日本式の無能SE/PG大量生産してますし
IBMとかね

0003仕様書無しさん2012/11/23(金) 13:16:19.88
違法派遣(事前面接、偽装請負、多重派遣)の告訴状(刑事告訴)の受理後の示談交渉について

@会社への通達
会社には「告訴した犯罪者本人か犯罪者個人が雇った弁護士としか話はしない」と釘をさしましょう。

A話し合いを持ちたいと犯罪者個人から打診(示談交渉)
交渉は基本受身で、犯罪者を許す気はないが話だけは聞きましょうという姿勢で臨みましょう。
被害者からお金の額を提示するのは絶対しないようにしましょう。犯罪者側は
いくら欲しいですかと聞いてくるでしょうが、応えてはいけません。満足する金額を提示するまで、「話は分かりました、しかしまだあなたを
許す気にはなれません」と伝えましょう。※お金を要求しなければ恐喝の成立はありません。

犯罪者側も被害者を怒らせた場合は、最悪感情論から告訴を継続させるという
事態を危惧するでしょうから、犯罪者側の心理は不安な状態にあるはずです。
意に沿わぬ和解案には強い態度で自信を示して退けましょう。

B満足する和解案の提示
被害者の想定する、犯罪者の払える最大限の金額まで達したら、「そこまで反省するなら、許して告訴を取り下げ
てもよいです。入金が確認された後に取り下げます」といえばいいでしょう。

和解金の想定上限は犯罪者個人の年収の半分程度が良いでしょう。ユーザー、元請の社長や、
下請でも創業者の場合の年収÷2は、数千万〜数億円、外注・人事担当役員、
外注担当の部長やマネージャーであれば500〜1000万円、営業個人については
200〜500万円程度でしょう。

C和解時の念書(同意書)
和解時には該当事案について犯罪者・被害者双方が秘守契約を結ぶことになるでしょう。
犯罪者側が被害者について誹謗中傷をしたり、被害者の個人情報、告訴事案について第3者
(他社)と通謀するような事態が発覚した場合の、賠償金をあらかじめ念書に記入するよう
にしてください。賠償金額は和解金額の2倍程度に設定すると良いでしょう。犯罪者側も
和解金を払った事実と事案について第3者に通謀しないように求めてきますが、内容が社会通念に
著しく反するような性質でなければ応じましょう。和解金が支払われるということは
双方が「和解」することを指しますから、お互い後腐れないよう合意をする必要があります。

0004仕様書無しさん2012/11/23(金) 13:18:29.69
エクセルやコード書かない人は単価0円だもん。

0005仕様書無しさん2012/11/23(金) 13:22:37.52
まとめ役の下はプログラマ−しかいないからな。

0006仕様書無しさん2012/11/23(金) 14:34:18.91
アーキテクトの>>1さんが押えておくべきツボを実例を交えて講釈なさると聞いて

0007仕様書無しさん2012/11/23(金) 19:30:38.82
トップダウン設計したらレガシーや言うだろ

0008仕様書無しさん2012/11/23(金) 21:42:52.45
>>6
そうですね。自分の使っている言語の
有名なフレームワーク。これをよく調べることです。

ライブラリだとアークテキチャがない(ただの関数の集まり)
もしくはほんの少ししか無いみたいなものがたくさんありますが
フレームワークにアーキテクチャが存在しないことはまず無いですからね。

使ってみるのはもちろん、なぜそのような実装になっているのか
できればソースコードまで見て見ることをおすすめします。
それが無理でもファイルの置き場所、クラスの分け方を見てみるだけでも
十分参考になりますよ。

漠然と見るのではなく、なぜそのようになっているのか、
その理由を考えてみるといいでしょう。

0009仕様書無しさん2012/11/23(金) 21:44:57.46
以上、中身のない講釈でした。

0010仕様書無しさん2012/11/23(金) 21:47:10.70
>>9さんが中身がある講釈をなさると聞いてw

0011仕様書無しさん2012/11/24(土) 08:15:15.91
>>8
>漠然と見るのではなく、なぜそのようになっているのか、
>その理由を考えてみるといいでしょう。

設計意図が分かると良いんだけどね
コメント読んでも分からない事が多いよ

俺のお勧めはアップルのドキュメントを
「自分の作ったシステムで、同じように書けるか?」
と考えながら読んでみることだな
こんな構成になってる
・ガイドライン
・プログラミングガイド
・リファレンス

単なる関数の寄せ集めでもリファレンスは書けるがプログラミングガイドは難しい
ガイドラインまではまず書けない

0012仕様書無しさん2012/11/24(土) 12:09:54.62

0013仕様書無しさん2012/11/24(土) 15:13:26.56
独立すると、アーキテクトにならないと食っていけない。コーディング出来ないアーキテクトもしくは、アーキテクトになれないプログラマは淘汰されるだろう。

0014仕様書無しさん2012/11/24(土) 15:21:00.13
>>11
俺はコード見ればだいたい分かる。

でもそれはやっぱり20年以上もプログラミングやってるからだろうな。
(言っとくが10歳からやってるって意味だぞw)

仕事で見るコードはたいがい設計意図が
感じられないただの手続きの流れで疲れる。
確かにこれでうごいてる。でもそうじゃねーだろ。
そんなのばかり。

0015仕様書無しさん2012/11/24(土) 16:16:48.01
ネットにはかまってちゃんが多くて疲れる
>>1なのばっかり

0016仕様書無しさん2012/11/24(土) 16:34:44.66
で?

0017仕様書無しさん2012/11/24(土) 17:52:17.24
ここまでソフトウェに対するツッコミ無し

0018仕様書無しさん2012/11/24(土) 18:08:36.62
>>17
次スレでは直しておくよw

0019仕様書無しさん2012/11/24(土) 18:37:24.24
>>14
>確かにこれでうごいてる。でもそうじゃねーだろ。
>そんなのばかり。

あるある

凄いスパゲッティコードなあげくに
やってることは今時の開発環境に標準で入ってる機能とかね…

0020仕様書無しさん2012/11/24(土) 18:57:38.36
>>14
形の無いグズグズなコード、あるある

0021仕様書無しさん2012/11/24(土) 19:19:10.15
>>19
そういうのって、標準であるの知ってても、わざと自分で作ってるんだよ。
標準の機能って本当は作りやすいけど、難しいふりして2〜3日余分に工数掛けて
自分の給料を増やすのさ。

0022仕様書無しさん2012/11/24(土) 19:31:19.47
>>21
要領が悪いねw

標準のを使って時間を稼いで
相手時間で、さらに技術と知識を広げればいい。
俺はそうやってるよ。

だからどんどん差がつくんだろうな。

0023仕様書無しさん2012/11/24(土) 20:13:09.94
大手IT企業がプロジェクトマネージャのみを育成し続けた弊害では?

0024仕様書無しさん2012/11/24(土) 21:34:23.51
>>23
大手ITも>>21みたいなのを実は推奨してるんだろ。
工数増えれば売上げ増えるんでしょ?
しかも末端の数倍も。

0025仕様書無しさん2012/11/24(土) 22:42:49.88
>>24
大手IT企業は下請が出した見積にマージンを上乗せしてエンドユーザに提出するだけw

0026仕様書無しさん2012/11/24(土) 23:11:54.20
>>19
9時の納品まであと二時間しかないときに、仕様変更。
いままで一度も使ったことのない標準機能を使う方に賭けるか、
自前のコードに賭けるかとなると、俺は後者を選ぶね。

0027仕様書無しさん2012/11/24(土) 23:16:34.83
>>26
あぁ、俺にはそんな経験ないやw

後2時間で納品で、仕様変更来て
責任なんて取れないしな。

馬鹿のすることだ。

0028仕様書無しさん2012/11/24(土) 23:22:12.14
>>26はアーキテクトには向かないな。

対応するのが絶対だとして、自前のコードを書くにしても
俺なら正規のコードとしては書かない。

つまりだ。

FIXME このコードは時間がなくしかたなく書いたコードであり
品質も低い。あとで直すべきだし、この方法は使ってはならない。

とコメントを入れておくよ。

正しいコードとして選んだんじゃないということを
しっかり明記する。でないと糞コードを真似て書く奴が出る。
それで全体の品質が落ちてるってことともよくある話。

なんでこんなコード書いた? → 最初にそう書かれていたから。

こんなコードに何の理念も感じられない。

0029仕様書無しさん2012/11/24(土) 23:27:45.27
>>27
まぁ、客がバカだとそんなこともあるってこと。
そして、バカな客はそこら中にいる。

>>28
一応コメントは入れるけど、修正したことはないね。
バカな客とはそれっきりってのが多いから。

0030仕様書無しさん2012/11/24(土) 23:28:58.69
> 一応コメントは入れるけど
嘘つけw

言い訳すんな。

0031仕様書無しさん2012/11/24(土) 23:44:23.95
コードコードと連呼している時点でアーキテクトには不向きだなw

0032仕様書無しさん2012/11/25(日) 00:06:40.01
へ? アーキテクトの仕事ってコードの設計なんだけど?

0033仕様書無しさん2012/11/25(日) 01:01:03.28
コードを書かずに絵?だけ書いて、ベストの設計に持っていけるのって
ワールドクラスのアーキテクトでも無理だと思うが?

0034仕様書無しさん2012/11/25(日) 01:08:37.30
>>33
特に最近はそうだよな。

全部自前で作るわけじゃなくて既存の何かを使うわけで、
最適な設計というのは、それらを実際に使わないとわからない。

最高のアーキテクトになるには、他人が作った物の”設計の考え”を
見抜く力がなければならない。

0035仕様書無しさん2012/11/25(日) 01:44:27.75
まあここで偉そうなこと書いてる奴が
口だけなのは明らかですがね

ちょっと問題出せば逃げ出していくよ
「コードは簡単なものすら書けないが設計はできる」と謎の発言を残して

0036仕様書無しさん2012/11/25(日) 01:46:59.92
>コードを書かずに絵だけ書いて
「プロジェクトの姿」を思い出した…。

0037仕様書無しさん2012/11/25(日) 01:54:48.39
>>35
じゃあ、お前に問題出していい?

0038仕様書無しさん2012/11/25(日) 02:05:39.61
1から100までの数を二つに分けて
それぞれのグループの数を掛け合わせたとき
両者が同値になる組み合わせの数は何個?

0039仕様書無しさん2012/11/25(日) 02:28:49.57
>>35
早く答えてね

0040仕様書無しさん2012/11/25(日) 02:31:06.12
>>38を見たときの反応

・さっそくIDEやエディタを立ち上げた or どんなコード書くか考えた => プログラマ
・「彼奴だったら10分で解けるな」と人の顔が浮かんだ => マネージャ
・ジッと問題を考えて、プログラム書くまでもなく0個だと分かった => アーキテクト
・問題が解けない言い訳を考えた => SE

さあ、君はどれだ!?

0041仕様書無しさん2012/11/25(日) 02:35:21.82
>>40を見た時の反応
のほうが興味があるなw

0042仕様書無しさん2012/11/25(日) 08:21:32.79
>>28
>なんでこんなコード書いた? → 最初にそう書かれていたから。

この手の事なかれ主義も困ったもんだよな
ま、あんまり偉そうなことは言えないが

>>40
まず「そいつはintか?doubleやcharじゃないだろな」と思った
完全にプログラマだなw
次に思ったのは「二つに分けて」や「グループの数」は曖昧だな、
「二つのグループに分けて」「グループの数(2つじゃん)」じゃないだろな?だった

0043仕様書無しさん2012/11/25(日) 08:43:28.50
>>38
「じゃあ」から始まったこの問題は何の意味があるのだろう?と思った
コードにして実行する必要性があるとは思えなかった
とりあえず誰かに解かせてみようか、とは思った

0044仕様書無しさん2012/11/25(日) 14:05:24.86
答え

>>38の問題は
アーキテクトの仕事とは無関係。

アルゴリズムの問題であり
解けるような人でも
アーキテクトとしては無能な人も多い。

0045仕様書無しさん2012/11/25(日) 15:21:33.21
>>38>>40がわけのわからんことを言い出したから
俺がアーキテクトというのが何かを教えてあげるよ。

あるオープンソースアプリがあって、その日本語化を
行うことになった。

★アーキテクトがいない場合

・SE
英語を日本語に置き換えるだけだから
英語ができれば難しい仕事じゃないな。
新人だけど英語ができるあいつにやらせよう

・プログラマ
ひたすらソースコードを見て
英語の所を日本語に置き換えていく

★結果
アプリがバージョンアップするたびに
差分をとってソースコードをマージする
作業に時間を取られるようになったのであった。

0046仕様書無しさん2012/11/25(日) 15:23:02.78
★アーキテクトがいる場合

・アーキテクト
このオープンソースアプリは日本語には対応していないが
多言語対応する仕組みが入っており、
最近もメンテナンスが入っているぞ。
ならそのやり方に合うように足りない部分を作ろう。

最初に少し時間がかかるかもしれないが、
あとは言語ファイル作るだけの単純作業だ。
プログラマじゃない人でもできる。

★結果
アプリがバージョンアップしてもコードがしっかり分離されていために
該当部分に修正が入ることは少なくメンテナンス時間も短い。
そして将来本家に足りない部分がマージされ
公式に日本語対応されたのであった。

0047仕様書無しさん2012/11/25(日) 15:40:22.34
>>46
それはアーキテクトの仕事じゃない。SEの仕事。

0048仕様書無しさん2012/11/25(日) 15:46:27.35
>>47
SE は プログラミングが出来ないので
それは無理な話です。

0049仕様書無しさん2012/11/25(日) 15:55:50.03
> このオープンソースアプリは日本語には対応していないが
> 多言語対応する仕組みが入っており、
> 最近もメンテナンスが入っているぞ。
> ならそのやり方に合うように足りない部分を作ろう。
>
> 最初に少し時間がかかるかもしれないが、
> あとは言語ファイル作るだけの単純作業だ。
> プログラマじゃない人でもできる。

このどこにプログラミングの要素が入ってくるのか。
単にオプソ関連のノウハウを知ってればできることだろ。

0050仕様書無しさん2012/11/25(日) 15:59:32.63
SEはプログラミングしないが
アーキテクトはプログラミングをするんだよ。

そしてアーキテクトの成果により、
他のプログラマの仕事の出来が左右される。

優秀なアーキテクトの元ではコードが統一され無駄がなく、
バグも少ないテストも簡単な仕組みが出来上がる。

無能SEはプログラマに「やれ」とだけ命令する。
そうするとプログラマごとにてんでバラバラな物が出来上がる。
でもソースコード読めないからその悪さを評価できない。

0051仕様書無しさん2012/11/25(日) 16:01:34.43
>>49
> このどこにプログラミングの要素が入ってくるのか。

ソースコードをみて、多言語対応の仕組みが
備わっていると判断できる。
足りないコードは何でそれを作る力を持っている。

明らかにプログラミングの要素じゃん

0052仕様書無しさん2012/11/25(日) 18:55:03.75
ドキュメントみれば分かるでしょ。
作らせればいいじゃん。

0053仕様書無しさん2012/11/25(日) 18:55:34.79
みなくてもいいかな。ノウハウさえあればいい。

0054仕様書無しさん2012/11/25(日) 19:12:42.31
アーキテクトの例として既存オープンソース製品のローカライズをあげる馬鹿w
全言語に対応したオープンソース製品を構想することを例にあげるならわかるが。

0055仕様書無しさん2012/11/25(日) 19:42:55.11
>>52
ほらなw

作らせるってことは、SEの仕事じゃないってことだろ
それすらもわからなかった。

0056仕様書無しさん2012/11/25(日) 20:02:56.40
>>54は馬鹿なのかな?

0057仕様書無しさん2012/11/25(日) 20:25:41.06
うむ。54もばかの一人だな。

もちろん、54だけがバカというわけじゃないよ。

0058仕様書無しさん2012/11/25(日) 20:31:41.01
>>55
プログラマ雇えば何もせずに勝手に日本語化すると思ってるバカですか。

0059仕様書無しさん2012/11/25(日) 20:32:07.26
アーキテクトがたずさわるレイヤー(粒度、レベル、立場、視点)が違う気がする。
ソフトウェア単体の開発をどうこうするよりももっと上流工程でなんかするものだと思うんだけど。

0060仕様書無しさん2012/11/25(日) 20:32:41.33
アーキテクトがいる場合と、いない場合で
どう違うかって話をしてるのに、
いきなり全言語に対応したオープンソース製品を作る話にする
>>54は仕事でも余計なものを作ってプロジェクトをダメにしそうw

0061仕様書無しさん2012/11/25(日) 20:32:44.75
つまり、>>55はアーキテクトなんていらないと。

0062仕様書無しさん2012/11/25(日) 20:35:22.47
>>59
それはアーキテクトの重要性をわかってない証拠だよ。

本来はアーキテクトという中間層が必要なのに、
その仕事をなくして、上と下に振り分けるから
めちゃくちゃなものが出来上がる

0063仕様書無しさん2012/11/25(日) 20:37:04.22
>>61
本当にお前は頭が悪いなw

プログラミングの要素を見つけられなかった
やつかお前?

0064仕様書無しさん2012/11/25(日) 20:42:34.02
>>59
プログラミングの質は、上流工程ではどうにも出来ないよ。
普通に考えればわかるでしょ?

プログラミングの質は、プログラミングを改良することでしか上げられない。
だから実際にプログラミングが出来ない人は改良は無理。

0065仕様書無しさん2012/11/25(日) 20:44:29.70
>>61
SEに指示してもらってプログラマがやった作業も、
プログラマの手柄にするのか?

ま、どうでもいいけど。

0066仕様書無しさん2012/11/25(日) 20:53:09.15
一人がプログラミング担当なら別だけど、
普通は複数人のプログラマがいる。

それぞれが勝手にコード書いてると
無駄がたくさん生まれる。だからまとめ役が必要。

ここでまとめ役がコード書かない人だと、
現場では使いづらいだけの意味不明なルールができる。
ルールだけならまだしも、変なオレオレライブラリを使えと強要したり
使うフレームワークだけ決めて、その使い方は個々に任せたり。
実際に自分がやらないからその悪さも理解できないだろうな。

だから実際にコードを書いてる現場の人間に近いレイヤーに
まとめ役が必要。それがアーキテクト。

アーキテクトが優秀だと開発の無駄が大きく削減される。
仕様の変更にも柔軟に対応できたり、バグが減ったり開発期間が減ったり。
システム開発で一番重要な仕事だよ。

0067仕様書無しさん2012/11/25(日) 20:55:56.33
>>46の例があほらしすぎるんだな。

多言語に対応したシステムをスクラッチから構築するとか、英語のことしか考えて作られてない
システムを多言語化するってのならアーキテクトの出番がちょっとだけあるかもしれないけど。

0068仕様書無しさん2012/11/25(日) 21:02:35.88
>>67
お前なんで多言語化にこだわってるの?

文章よく読めば、もともと多言語化の仕組みが入っているが
日本語には対応できなくて、その部分を作る必要がある。
というのを見抜くって話になってるだろ。

文章もちゃんと読めないの?

0069仕様書無しさん2012/11/25(日) 21:05:46.94
>>66
その役割はITSSでいうところのアプリケーション共通基盤の技術者であって、アーキテクトではないだろw

0070仕様書無しさん2012/11/25(日) 21:12:23.56
>>68
そういう解釈だとしてもだな、そんなもんアーキテクトの仕事ではないわ。

0071仕様書無しさん2012/11/25(日) 21:34:13.92
>>68
プログラマにもできる仕事ですね。

0072仕様書無しさん2012/11/25(日) 21:40:44.16
>>69
ITSS(失笑w)

すまんな、日本独自の用語に興味はないよ

0073仕様書無しさん2012/11/25(日) 21:44:30.95
>>59 の内容が一番真っ当だな。

そもそもアーキテクトの定義や役割は何?

日本のITSSではこうなっているが、アメリカ等の他国での定義があれば是非貼ってくれ。

ITアーキテクトとは
ビジネス及びIT上の課題を分析し、ソリューションを構成する情報システム化要件として再構成する。
ハードウェア、ソフトウェア関連技術(アプリケーション関連技術、メソドロジ)を活用し、
顧客のビジネス戦略を実現するために情報システム全体の品質(整合性、一貫性等)を保った
ITアーキテクチャを設計する。設計したアーキテクチャが課題に対するソリューションを構成することを確認するとともに、
後続の開発、導入が可能であることを確認する。
また、ソリューションを構成するために情報システムが満たすべき基準を明らかにする。
さらに実現性に対する技術リスクについて事前に影響を評価する。
IT投資の局面においては、戦略的情報化企画(課題整理と分析(ビジネス及びIT)、ソリューション設計(構造とパターン))を
主な活動領域として以下を実施する。

0074仕様書無しさん2012/11/25(日) 21:47:17.72
>>72
ここは日本だから日本独自の用語が出ても問題ないだろ?
それなら世界ではどう定義されているのか説明してくれ。どうせ説明できないだろうがw

0075仕様書無しさん2012/11/25(日) 21:47:39.06
読めよ無能ども

http://www.atmarkit.co.jp/im/carc/serial/redge43/redge43b.html
IBMシニアITアーキテクト


■アーキテクトには技術知識が必要
■アーキテクトには設計スキルが必要
■アーキテクトにはプログラミングスキルが必要
■アーキテクトは優れた伝達者であれ
■アーキテクトには判断が必要
■アーキテクトには組織の政治的駆け引きに対する認識が必要
■アーキテクトは交渉人であれ

0076仕様書無しさん2012/11/25(日) 21:48:34.73
>>73
抽象的すぎて何が言いたいのかさっぱりわからんなw

だ〜か〜ら〜日本はダメなんだろうな

0077仕様書無しさん2012/11/25(日) 21:51:46.99
http://www.atmarkit.co.jp/im/carc/serial/redge41/redge41b.html

◆ アーキテクチャの定義

 こと「アーキテクチャ」に関しては十分定義され尽くしている。定義を集めたWebサイトまで存在する(注1)。
本稿で使う定義は、IEEE 1471.2と呼ばれる「IEEE Std 1472000, IEEE Recommended Practice for
Architectural Description of Software-Intensive Systems」から抜粋してきたものだ。
この定義は次のようになっており、重要な部分は括弧で囲んである。

アーキテクチャとは、「コンポーネント」、コンポーネント間および「環境」との「関係」、
またその設計と進化の指針となる原理に体現された「システム」の基本「構造」である(IEEE 1471)。注2

 アーキテクチャとは、ソフトウェアシステムの構造に関する「一連の重要な判断」「構造要素」の選択、
そしてシステムを構成するインターフェイスに加え、これらの要素間のコラボレーションで明記されたその
「動作」、徐々に大型化するサブシステムへのこれら要素の「組み込み」、そしてこの構造の指針となる
「アーキテクチャスタイル」である。つまり、これらの要素とインターフェイス、そのコラボレーション、
そして構成であるKruchten)。注4

 [アーキテクチャは]組織の構成であり、システムの関連動作だ。アーキテクチャは、
インターフェイス経由でやりとりするパーツ、パーツをつなぐ関係、そしてパーツを組み立てる制約に、
再帰的に分解することができる。インターフェイス経由でやりとりするパーツには、
クラス、コンポーネント、およびサブシステムなどがある(UML 1.5)。注6

0078仕様書無しさん2012/11/25(日) 21:53:53.81
話を戻すと、コードを見て(普通マニュアルは整備されてない)
そこから設計を読み解く能力。

それはアーキテクトの力であり、
アーキテクトが存在しないと、個々のプログラマが
そーじゃない的なコードを量産することになる。

0079仕様書無しさん2012/11/25(日) 21:54:13.84
>>75
必要スキルが羅列されているだけじゃん。
だから役割は何なの?って聞いているの。技術面のリーダーってことでいいの?

>>77
アーキテクチャとアーキテクトは違うでしょ。
アーキテクトはアーキテクチャを構想するってことでいいの?

0080仕様書無しさん2012/11/25(日) 21:56:37.16
まぁ設計ができる人がいないってのは>>1に同意する。
SEが仕様を決めて、PGがコーディングするだけというプロジェクトが
多々あるからな。

0081仕様書無しさん2012/11/25(日) 22:00:35.57
http://www.atmarkit.co.jp/im/carc/serial/redge45/redge45b.html

 アーキテクトはさらに、設計者や実装者の作業指針となる適切な手法、標準、
およびガイドラインも定義しなくてはならない。

アーキテクティングの目的の1つが、設計者や実装者側の不要な創造性の排除だ。
これは、自分にできることに対して必要な制約を課し、その制約から逸脱すると
アーキテクチャの破壊につながる可能性があると明言することで実現できる。

このような理由から、適切な審査および評価方法を採用することが、アーキテクチャの
整合性を保証するのに役立つことになる。これらの作業が重点を置いているのは、
設計者や実装者の作業を検討し、用意されたアーキテクチャ標準や
ガイドラインへの準拠の度合いを判断することだ。

◆ アーキテクティングは複雑性への対処に役立つ
◆ アーキテクティングは再利用のための基盤を実現する
◆ アーキテクティングは維持管理費用を削減する
◆ アーキテクティングは影響の分析をサポートする

0082仕様書無しさん2012/11/25(日) 22:02:03.58
>>79
http://www.atmarkit.co.jp/im/carc/serial/redge43/redge43a.html

IEEEでは「アーキテクト」を次のように定義している。

 [アーキテクトとは]システムアーキテクチャを統括する個人、
チーム、あるいは組織を指す(注1)。

■アーキテクトは技術リーダー

0083仕様書無しさん2012/11/25(日) 22:09:56.12
>>82
OK。アーキテクトは技術リーダーということだな。

0084仕様書無しさん2012/11/25(日) 22:17:07.02
念の為に言っとくが、技術リーダーってのは
技術をリード、引っ張っていく事ができる技術者であって

技術者に仕事を割り振ったりスケジュール管理をする
マネージャーじゃないからなw

0085仕様書無しさん2012/11/25(日) 22:21:22.37
アーキテクトの定義は、日本はビジネス寄り、世界は技術寄りで違うんだな。
こういうところでも日本は技術力を軽視していることがよくわかるね。
IEEEでのアーキテクトは日本ではITSSのITスペシャリストにあたるか。

>>84
> 技術者に仕事を割り振ったりスケジュール管理をするマネージャーじゃないからなw
わかっとるわ。それはプロジェクトマネージャだろw
技術リーダーではなくて、技術統括責任者のほうが適しているかもな。

0086仕様書無しさん2012/11/25(日) 22:38:28.62
今はどうかは知らんが、
昔はSEでも業務SEと技術SEがあって、技術SEがアーキテクトの役割をしていたってことか。
日本のIT企業では、業務SE>技術SE であって、技術SEはコミュニケーションできずにお金を稼げない
お荷物とか言われていたから、現在アーキテクトが少ないのも仕方がないだろう。
そういえば、
「技術系は馬鹿でもできるが、業務系は馬鹿ではできません(キリッ」と言っていたPMや業務SEがいたな。
そいつらがいたプロジェクトはいつも火を噴いていたけどw

0087仕様書無しさん2012/11/25(日) 23:34:11.68
>>85
技術統括責任者だと、実際にプログラムしてるって感じじゃ無いじゃんw
アーキテクトでいいんだよ。

0088仕様書無しさん2012/11/26(月) 18:18:33.39
こんなに盛り上がるとは>>1は想像してなかっただろうな。

0089仕様書無しさん2012/11/27(火) 00:09:44.68
盛り上がるもなにも>>1自ら
書き込んでますからw

0090仕様書無しさん2012/11/27(火) 12:57:13.00
つまり、アーキテクトってのは組織の中で最も優れた技術力を持つ者に与えられる尊称だな
アーキテクトの技術力==組織の技術力(の最大値)

0091仕様書無しさん2012/11/28(水) 00:20:51.64
称号…?ただの役割だろ…

別に優れてなくてもいいし、社内に何人いてもいい。
仕事の規模上、設計と実装をすべて同じ人がやらない場合の役割分担に名前をつけただけでしか無いだろ。
小規模だとプログラマが兼任してるだけ。
変な定義広めないでくれ…

0092仕様書無しさん2012/11/28(水) 00:27:49.79
> 別に優れてなくてもいいし
優れてなかったらデスマになるよw

少なくとも他のプログラマと同等の仕事が
できないとアーキテクトにはなれないよ。

プログラム知りませんとか、いつもエクセルで
図ばっかり書いていますとかいう人には無理。
実際にプログラミングをするというのが大前提だから。

0093仕様書無しさん2012/11/28(水) 00:32:32.78
それも違う
最近のゆとりは人月の神話くらい読んだことないのかね

0094932012/11/28(水) 00:33:14.69
>>93>>91へのレス

0095仕様書無しさん2012/11/28(水) 00:53:00.39
>>92
役割をひとつしか担わないと言ってないんだけど。
チームの中でより優れた人がアーキやればいいわけで、社内一優秀な人である必要は無いと思うって話。
自分の設計を最後まで責任持つためにも、アーキが実装者の先頭やるべきだと思うよ。

さっきの話だと、アーキテクト様ーって崇められたい中二病にしか見えなくてさ。

>>93
古典くらい読んでるよ。

0096仕様書無しさん2012/11/28(水) 00:55:00.25
社内一優秀な人とは一言も言ってないよ
そもそもそんなのわかるわけないし、
向き、不向きがあるに決まってるじゃない。
そんな基本的なこといちいち言わせないでよね。

0097仕様書無しさん2012/11/28(水) 00:58:43.72
>>96
>>90読んで下さい。そんな基本的な(ry

0098仕様書無しさん2012/11/28(水) 02:27:34.26
>>92
> 少なくとも他のプログラマと同等の仕事が
> できないとアーキテクトにはなれないよ。
そんなことはない。
たとえば、一般のプログラマーに求められる、
ミス無く素早くコーディングができるという能力は必要ない。

0099仕様書無しさん2012/11/28(水) 02:49:55.15
ミスしない奴なんていないだろ。アホかw

0100仕様書無しさん2012/11/28(水) 02:58:32.87
んじゃ、ミスが少なくでいいや。

0101仕様書無しさん2012/11/28(水) 02:59:35.82
ミスが少ないことはだれにでも求められること。

0102仕様書無しさん2012/11/28(水) 03:01:20.22
コーディングしないのに、ミスが少なくコーディングできることが求められるの?

0103仕様書無しさん2012/11/28(水) 03:03:54.66
だからアーキテクトはコーディングするんだって。

コーディングなしでどうやって、コーディングの基盤を作るというのか。
常識で考えればいい。

コーディングなし基盤を作るのはムリ。ムリなものはムリ。
夢をみるのはやめよう。

0104仕様書無しさん2012/11/28(水) 03:08:25.23
どこの設計かが、それぞれズレてるな。

0105仕様書無しさん2012/11/28(水) 03:09:29.78
だからアーキテクトって言ってるだろ。

定義は上に書いてある

http://www.atmarkit.co.jp/im/carc/serial/redge43/redge43a.html

IEEEでは「アーキテクト」を次のように定義している。

 [アーキテクトとは]システムアーキテクチャを統括する個人、
チーム、あるいは組織を指す(注1)。

■アーキテクトは技術リーダー

0106仕様書無しさん2012/11/28(水) 03:11:38.55
> コーディングなしでどうやって、コーディングの基盤を作るというのか。
設計書書いて、ミーティングで説明して、個々のプログラマのコードをレビューすればいい。

設計に関する責任を引き受けるんだから、
コーディングしてる暇なんてそうそうないよ。夢をみるのはやめよう。

0107仕様書無しさん2012/11/28(水) 03:18:54.25
プロジェクト立ち上げ時に技術検証も兼ねて大まかなコードを書くことはあるけど、
プログラマが入ってきたらコード書きはそっちに任せたほうが安全確実で早いね。

0108仕様書無しさん2012/11/28(水) 03:23:58.98
> 設計書書いて、ミーティングで説明して、個々のプログラマのコードをレビューすればいい。

はい。だめ。「アーキテクト不在」というのはまさにこの状況。
個々のプログラマに任せても、まとまりのない無駄が多いものが出来上がるだけ。

コーディングルール、フレームワークの使い方、テストの仕組み。
モジュールの連携、デザインパターン。
それらを組み合わせて統一した基盤を作らないといけない。

考えるだけじゃダメ、選ぶだけじゃダメ。実用に耐えうるレベルの実装例を
作り上げないといけない。実用に耐えうるかどうかは作らないと判断できない。

個々のプログラマをレビューしてもダメ。統一した基準ができていないのなら
どうすべきかなんて判断できない。それにレビューには時間がかかる。

> 設計に関する責任を引き受けるんだから、
> コーディングしてる暇なんてそうそうないよ。夢をみるのはやめよう。

それはコーディングをするアーキテクト専任がいないってことだろ。
つまり「アーキテクト不在」ってことだろ。

だから日本は海外に負けてる。
そりゃそうだ。アーキテクトがないのだから
効率が良い開発ができるわけがない。

0109仕様書無しさん2012/11/28(水) 03:27:32.98
>>107
「技術検証」が個々の技術の検証で終わっているのなら
全然足りない。

アーキテクチャとは単体の技術ではない。
すべての技術を組み合わせたもの。

コードの書き方からテストやデプロイまで
すべてを統合した基盤を作るのがアーキテクトの仕事。

その基盤が良くできていれば、開発・テスト・修正
すべての面で効率の良い開発ができるようになる。
開発の基盤の重要性をわかってない奴が多すぎる。

0110仕様書無しさん2012/11/28(水) 03:35:25.43
>>108
コーディングを個々のプログラマに任せなかったら、誰がコーディングするんだ?
もしかして、アーキテクト(が全てコーディングするの?

> 個々のプログラマをレビューしてもダメ。統一した基準ができていないのなら
> どうすべきかなんて判断できない。それにレビューには時間がかかる。
統一した基準を適応するために、設計書も書いて、さらに設計責任者がレビュー
を行うんだけどね。
で、そういうことやってたらコーディングしてる暇はないと言ってる。

きみ、複数人数での開発したことないでしょ。

0111仕様書無しさん2012/11/28(水) 03:39:43.91
>>109
> コードの書き方からテストやデプロイまで
> すべてを統合した基盤を作るのがアーキテクトの仕事。
今まで出てきてなかった話だから書いてないけど、それくらいはやるよ。

0112仕様書無しさん2012/11/28(水) 08:44:08.38
>>110
> コーディングを個々のプログラマに任せなかったら、誰がコーディングするんだ?
> もしかして、アーキテクト(が全てコーディングするの?
あほかw
基盤をコーディングする人と、その基盤を使ってコーディングする人は
コーディングの内容が違う。

それがわからないから「アーキテクト不在」になるんだよ。

> で、そういうことやってたらコーディングしてる暇はないと言ってる。
だから設計書を書く人と別に
アーキテクトに分けるんじゃないかw
一人でやろうとするから、暇がなくなるんだよ?

0113仕様書無しさん2012/11/28(水) 10:35:38.30
アーキテクトは、正しくアーキテクチャが適用されたシステムが出来上がる事を保証しなければいけないよね。
フレームワークをつかってはいるけど、思想を無視した実装になってる事ってよくあるよね…
この正しく使われてるかどうかって、実装者のレベルの(使用するアーキテクチャへの理解)によって変わってしまうから、やっぱり、アーキテクトはコードレベルで見れなきゃいけないよね。

0114仕様書無しさん2012/11/28(水) 12:18:02.15
>>112
アーキテクト=基盤をコーディングする人?
つまり、OSとかフレームワークの作成者ってことでいいの?

このスレではアーキテクトって技術リーダってことになってるんじゃなかったっけ。
まぁどうでもいいけど、技術リーダやってるとコーディングまで手が回らないもんだよ。
逆に言えば、コーディングしてる暇があるんだったらリーダとしての仕事やれと言われる。
よっぽど暇かよっぽど小さなプロジェクトでもない限り。

0115仕様書無しさん2012/11/28(水) 12:28:50.86
世の中そんなでかい仕事ばかりじゃないよ
むしろ小さい仕事のほうが多い

0116仕様書無しさん2012/11/28(水) 13:15:33.25
アーキテクトはOSやフレームワークに対して実装レベルの深い知識を持つ必要があるが、作成者である必要はない
また、コードを書くのは実装者の仕事だが、実装例の一つくらいはいつでも示すことができなければならない

0117仕様書無しさん2012/11/28(水) 14:48:32.46
ここのプログラマって此処かと思った

スケジュールをね、10本5人だとしたら5人一斉に開始するように引く体質がおかしいんだよね。

0118仕様書無しさん2012/11/28(水) 15:54:53.32
>>103 >>108
手持ちのプログラマーでコーディングできない時は、アーキテクト自らコーディングするさ。
でも通常は、自分ではコーディングせずに、プログラマーにコーディングさせてるよ。

特に>>108
前半に書いてることは正しいんだよ。
でも結論となる最後の5行が間違ってるよ。
アーキテクトは、他の人がコーディングできない場合で無い限りは、自分ではコーディングしないよ。

0119仕様書無しさん2012/11/28(水) 23:36:30.90
>>114
> 逆に言えば、コーディングしてる暇があるんだったらリーダとしての仕事やれと言われる。
> よっぽど暇かよっぽど小さなプロジェクトでもない限り。

反対だろ。大きなプロジェクトなら人がいるはず。
リーダーの仕事はリーダーに任せればいい。

アーキテクトの仕事は重要で規模は大きい。
仕事の内容が違うならばそれは他人にやらせることができる。
「コーディングじゃなくてリーダーの仕事をやれ」という言葉から明らかなように、
(アーキテクチャの)コーディングとリーダーは別の仕事、だから他の人にやらせればいい。

>>118
> アーキテクトは、他の人がコーディングできない場合で無い限りは、自分ではコーディングしないよ。
コーディングって、アーキテクチャ部分のコーディングだってわかってる?
似たような画面を大量に生成するようなコーディングのことじゃないよ。

アーキテクトは考える必要がある。だが考えるだけじゃ既存の空論。
実装して試行錯誤を行なって検証する必要がある。

だけどここでアーキテクチャを考える人と、アーキテクチャをコーディングする人が
別になれば、コミュニケーションパスが増えることになる。

難しい内容なのにその部分のコミュニケーションパスを増やしてどうすんの?

アーキテクチャは難しい部分だからどうしても試行錯誤する必要がある。
そんな部分にいちいち資料作って他人がそれを解読して実装してレビューするとか
そんな無駄なことやってどうすんのさ。

0120仕様書無しさん2012/11/29(木) 00:09:12.85
昔は一つのシステムを個別のサブシステムに分けてそれぞれの担当が設計していた。
例えばUI部分、ロジック部分、データベース部分、テスト部分など。
このやり方は今は通用しない。

なぜなら使うフレームワークやインフラ(例Amazon AWSなど)である程度アプリ設計やUIや
データベース設計が左右されるから。ようは全体を見ないと最適な開発手法が見えてこない。

だからアーキテクトが必要になる。

それはさておき、専任のアーキテクトがやらないこと。
顧客との打ち合わせ、システム固有の画面設計、システム固有のデータベース設計
これらをしないで何の仕事をするんだと思った人もいるだろう。
それはアーキテクトというものをわかってない証拠。

>>114がフレームワークの開発者の話をしているが、それに近い。
フレームワーク(Rails、Spring等)の開発者は、顧客との打ち合わせをしているわけじゃないし、
システム固有の画面設計やデータベース設計もしていない。
だがそんなことをしなくてもフレームワークは作れるだろう?

システム固有の作業とは別にフレームワークのような基盤の仕事というのがあるんだ。
アーキテクトはオリジナルのフレームワークを作ることはまずないが、
汎用フレームワークをシステム固有の開発にうまく適合させる仕事をする。
(その為にシステム固有の話を参考にするが、固有のシステムを作るのは本職ではない)

フレームワークをどのように使えば効率的かというサンプルを作ったり、
システム固有の実装を行なっている時に発生した問題点を解決するために
プラグインを作ったり改造をしたり。

もちろんプログラム部分だけじゃない。性能を活かすためのデータベースの
(システム固有ではない)設計方法、サーバー構成、テスト方法、
ようするにシステムの基盤だ。これを作る(考えるだけじゃダメ)のがアーキテクトだ。

0121仕様書無しさん2012/11/29(木) 00:12:24.93
> フレームワークをどのように使えば効率的かというサンプルを作ったり、
> システム固有の実装を行なっている時に発生した問題点を解決するために
> プラグインを作ったり改造をしたり。
そんなことやってたらコーディングやってる暇ないわw

0122仕様書無しさん2012/11/29(木) 00:20:43.14
>>121
「そんなこと」=基盤のコーディングですが?
プラグイン作るのはコーディングではないと?

0123仕様書無しさん2012/11/29(木) 00:30:42.22
おれさ、アーキテクトって業務設計する人だと思ってたんだが
そしてそれを実現させるのがデベロッパじゃないのか?

コーディングを誰がするとか次元の低い話だと思うぞ

0124仕様書無しさん2012/11/29(木) 00:40:42.23
>>120
君の書き込みを見てると、
「コンピュータとだけ戯れていたいよー」
「客とお話するのなんて嫌だよー」
「個々のシステムを納期までに作るのなんて嫌だよー」
というわがままな新人君にしか見えないんだがw > アーキテクト

0125仕様書無しさん2012/11/29(木) 00:46:55.61
アーキテクトは顧客に向けてアーキテクチャについて説明しなければならない立場だけど。
アーキテクトはプログラマの延長ではないぞ。

>>123
日本では業務設計はシステムエンジニアやアプリケーションエンジニアが行う。

0126仕様書無しさん2012/11/29(木) 16:09:21.91
>>119
お前、他人を使って仕事したことないだろ。
アーキテクチャを考えるのがアーキテクトの仕事だよ。
それをコーディングするのはプログラマにさせればよい。
手持ちのプログラマが優秀なら、アーキテクトが考えてた以上のコーディングをしてくれるよ。
駄目な子しかいなくてどうしてもできないっていうなら、小1時間程かけてコードフラグメントだけ作ってあとは駄目なPGに完成させとけ、ってお願いするのがアーキテクトだよ。
建築家と大工の関係で考えりゃよくわかるだろ。
ちなみに建築家ってのは英語で「アーキテクト」な。

0127仕様書無しさん2012/11/29(木) 16:14:03.30
>>120
サンプル作るのは、大きなプロジェクトだとそれ専用のプログラマが居るのよ。
もちろん、「アーキテクト」や上級SEがどんなサンプル作れ、ってその先行開発担当PGに指示するんだけどな。
その先行開発担当PGがフレームワークの問題とかを潰して、一般PGが簡単にプログラミングできるように道を作ってやるんだよ。

データベースの設計なんかは、アーキテクトは噛まないよ。
DBのチューナーがするよ。
たまにDBに造詣の深いアーキテクトが居たりすると、アーキテクト自ら手を出す場合もあるけれど、そういう場合でもアーキテクトとしての仕事、DBチューナーとしての仕事とは明確に区別されてるよ。

0128仕様書無しさん2012/11/30(金) 00:05:56.15
>>126
設計=コーディングってことを理解しているのなら、
お前が言ってることが的外れってことがわかるだろう。

0129仕様書無しさん2012/11/30(金) 00:14:02.96
>>124
君の書き込みを見てると、
「コーディングしたくないよー」
ですね?

コーディングと言いたくないなら
設計と呼ぼうか。

コードは動く設計である。
だから設計をする=コードを書くことである。

ちなみに生産はコンパイラの仕事な。

0130仕様書無しさん2012/11/30(金) 00:17:34.15
、“設計”と“製造”という言葉の意味を明確に定義することから始めよう。

 ここで“製造”とは、既に設計が済んでいることを前提にして、
設計作業を通して明確にされたものの“実体を作る”ことを意味するものとする。
車とかコンピュータハードウェアとか建造物とか印刷機とかの製造とは、
設計図面で明確にされた何らかの物体を作ることであるし、ソフトウェアとか書籍とかの
製造とは原本のコピーが入ったフロッピーディスクとか CD-ROM とか綴じた紙の束を作ることに他ならない。

 そして“設計”とは、製造対象物を明確にすること、すなわち製造対象物に関する曖昧さを
一切なくすことを意味するものとする。 設計をするという行為によって、
もはや製造段階では何を作るのかという迷いが一切生じなくなり、創造性を発揮する
余地もなくなるのである。 言い換えると、製造対象物に関しては (詳細な製造方法を別にすると)
一かけらの創造性も必要としないようにすべてのお膳立てをすることが“設計”なのである。

 “設計”とは、小説を例にとると、構想を練って、取材をして、執筆して、推敲して、
装丁をデザインするというような作業である。 これに対して、“製造”とは、
活字を組んで原版をつくり、印刷機を回し、製本するというような作業である。

0131仕様書無しさん2012/11/30(金) 00:18:08.44
 ソフトウェアの開発は、ウォータフォールモデルに基づこうがスパイラルモデルに基づこうが、
計画/分析、概要設計、プログラミング、テストなどの作業が含まれている。 これらの中のプログラミングを
製造と呼ぶので誤解が生じるのであるが、少し考えれば分かるようにプログラミングは決して製造ではない。

製造工程とは、製造対象物が明確になった後に、ソフトウェア製品となるフロッピーディスクや CD-ROM などに
データを焼きつける工程のことである。 プログラミング作業は、ソフトウェアという製造対象を明確に
する作業に他ならないので、設計工程に含まれるものである。 いわば、設計図を仕上げる作業に相当すると考えるのが正しい。

 そもそも、ソフトウェア開発はそのほとんどすべてが設計作業である。 したがって、その生産性を向上させたければ、
設計作業の生産性向上策を練るべきなのである。 ソフトウェア開発を製造工程に無理にたとえて、
製造作業の生産性向上の成果にあやかりたいと思っても、それは単なる希望にしか過ぎない。

製造作業の生産性向上策を設計作業に適用するのは難しいのである。 ソフトウェア開発を
製造工程にたとえるのはご自由であるが、誤解を生み幻想を育てることになるだけなのでお勧めできない。

0132仕様書無しさん2012/11/30(金) 00:27:14.63
>>128
コーディングする人がいれば、設計する人はいらないという主張ってことでおk?

0133仕様書無しさん2012/11/30(金) 00:31:20.61
>>132
コーディング=設計なので

「設計する人がいれば、設計する人はいらないという主張ってことでおk? 」

という意味不明な文章になっていますよ。

0134仕様書無しさん2012/11/30(金) 00:48:48.64
>>130-131
これだけディジタルなプロダクトが日常的になったのに、
いまだにこの手の前時代的な主張を信じてる人がいるんだなぁ。

0135仕様書無しさん2012/11/30(金) 00:49:14.95
コーディングは設計じゃなくて実装だろ

0136仕様書無しさん2012/11/30(金) 00:54:50.76
この手の言葉遊びしても、実際の作業は変わらないのになー。
まぁ、自分のやってることは設計だと信じれば何かが救われるのならそれでもいいんじゃないかな。

0137仕様書無しさん2012/11/30(金) 01:23:57.92
>>135
より正確に言い方をするならば

プログラミングが設計(=ソースコード)であり
コーディングは設計(ソースコード)を
そっくりそのままパソコンに入力することです。

昔ははっきりと区別されていて、昔はコンピュータは
とても高価で一人一台どころか、時間を決めて交代で使っていた。
必然的にプログラミング=紙にソースコードを書くことであり、
コーダーという職種は、紙に書かれたソースコードを
そっくりそのままパソコンに入力するのが仕事だった。

0138仕様書無しさん2012/11/30(金) 01:25:34.89
>>136
言葉遊びはあんたじゃない。
自分のやってることは○○だと思いたいんでしょ?
○に入る言葉が違うだけじゃないか。

事実は事実。受け入れなさい。
プログラミングが設計であることは
多くの人が語っていることです。

0139仕様書無しさん2012/11/30(金) 01:30:29.25
コーディング技術が高いというのは
タイピングスピードが速いとか
誤字脱字が少ないとか
そういう話ですよ。

0140仕様書無しさん2012/11/30(金) 01:36:28.82
ソフトウェアアーキテクトが知るべき97のこと
http://www.oreilly.co.jp/books/9784873114293/

31 プログラミングは製造ではなく設計だ
アイナー・ランドル

アメリカでもよく製造と勘違いする奴が多いようだね。
こういう馬鹿は昔からいなくならない。

プログラミングは設計です。

「ソフトウェアは工業製品ではない」、Rubyのまつもと氏が講演
http://www.atmarkit.co.jp/news/200904/10/matz.html
 「世界に冠たる日本の製造業のノウハウを適用することで生産性を上げることができるに違いないと
いう発想がありますが、ソフトウェアは工業製品ではない。そうした誤解を正していきたい」。

0141仕様書無しさん2012/11/30(金) 01:37:20.53
またSEが暴れてるのか
本当にしょうもない連中だな
プログラミングを満足にできないSEはただの事務屋ですよ

0142仕様書無しさん2012/11/30(金) 01:59:00.52
最近は「プログラミングは製造ではない」という考えが主流らしいね。

ググった結果です。
https://www.google.co.jp/search?q=プログラミング+製造

0143仕様書無しさん2012/11/30(金) 02:29:02.19
どうでもいいよw
設計ができるんなら、やればいいじゃない。

0144仕様書無しさん2012/11/30(金) 04:26:48.58
伸びてるなと思ったら、かわいそうなSEが荒らしてるのね。

設計は頭でする事。
実装は体でする事。
プログラミングは設計して実装すること。

頭で設計して、それを紙に出して、紙を見ながら実装するのもプログラミング。(大企業風?)

頭で設計しながら手で実装して、後で紙に残すのもプログラミング。

0145仕様書無しさん2012/11/30(金) 04:38:26.20
誰かが出した紙を見ながら実装するのは?

0146仕様書無しさん2012/11/30(金) 05:13:23.52
一語一句、紙に書いてある文字をPCに書き写すならコーディング。
(誰が書いても全く同じ物出来る)

紙に書かれたよくわからん(笑)イメージ図や説明文を解読して
自分で考えて書くのであればプログラミング(=設計)

0147仕様書無しさん2012/11/30(金) 05:51:44.11
>>145
誰が読んでも同じコードになるのならコーディング。

0148仕様書無しさん2012/11/30(金) 07:23:44.66
うちの会社だと、C#のコードは自動生成だぜ。
自動生成ツールにプログラマーとしての給料を払わなくちゃならないな。

0149仕様書無しさん2012/11/30(金) 20:02:24.62
その自動生成ツールがDSLのコンパイラってだけの話だな

0150仕様書無しさん2012/11/30(金) 21:33:02.90
よくわかってるじゃないか。

>>120あたりの香しい奴は、最近のソフトウェア「製造」工程がそういう風になってきてるってこと知らないんだろうな。

0151仕様書無しさん2012/12/01(土) 04:39:50.55
>>150
お前、>>149の皮肉がわかってないんじゃないか?w

DSLって言語だよ?

0152仕様書無しさん2012/12/01(土) 08:13:44.80
どうでもいいよ
プログラムが設計だっていう主張は間違っていないが
実際には虐げたれるプログラマの歪んだプライドを満足させるために使われてる

0153仕様書無しさん2012/12/01(土) 09:23:42.51
プログラマとコーダーを区別してほしいね。

0154仕様書無しさん2012/12/01(土) 11:52:34.69
>>146
実務経験(wが、コンビニのバイトとか牛丼屋のバイトとか単純労働しか
ない大卒無職のゆとり世代は、キーパンチャーとか知らんのだろうな。

0155仕様書無しさん2012/12/01(土) 12:07:09.33
プログラムではなく、データを入力する人か。

http://ja.wikipedia.org/wiki/%E3%82%AD%E3%83%BC%E3%83%91%E3%83%B3%E3%83%81%E3%83%A3%E3%83%BC
> キーパンチャー(英文:Keypunch operator)は、ホストコンピュータあるいは汎用機などに用いるデータや文章を、キーパンチ機などで入力する職業。
> 現在では、キーパンチャーよりもデータエントリーという名称が一般的に通じやすい。

0156仕様書無しさん2012/12/01(土) 13:32:53.59
SEvsプログラマはこっちでやれよ
http://kohada.2ch.net/test/read.cgi/prog/1347264264/

ここはアーキテクトについて語るスレだろ
アホんだらどもが

0157仕様書無しさん2012/12/01(土) 13:58:02.67
アーキテクトの仕事だと主張してる内容は一般的なSEの仕事で、
さらにそれはPGが行うものだと言ってるからややこしくなってる。

0158仕様書無しさん2012/12/01(土) 15:40:49.18
※コピペ歓迎です。
違法派遣(偽装請負・多重派遣・偽装出向・事前面接等)についての刑事罰
【告訴権者=業務委託、準委任、共同受注、業務請負契約および特定派遣(契約・正規)、一般派遣、正規社員】

@職業安定法第44条の労働者供給事業の禁止規定に違反(1年以下の懲役または20万円以下の罰金)
 ■偽装請負・多重派遣・偽装出向・多重出向
 ■事前面接(顔合わせ・面談・職場見学等)と履歴書・職務経歴書・スキルシート等提出による労働者の特定(※)
(音声録音で立証可能)
A労働基準法第6条(中間搾取の禁止) (1年以下の懲役又は50万円以下の罰金)
 ■多重派遣・多重出向

※違法派遣(派遣労働者の特定)→派遣法で認められた派遣労働者ではない→労働者供給事業→職業安定法44条違反というの
が前提となる法解釈となります。派遣法における罰則が軽微なのは法律の不備や労働者軽視などが原因ではありません。
違法派遣は全て職業安定法44条で裁くことが可能なため、刑罰の重複を避けるために派遣法には軽微な罰則(主に裁量行政による)しかないのです。

使用者に有利な民事訴訟や労働関係諸局への通報等の対極にあるのが書面(告訴状)による刑事告訴(※告訴先は検察の直告班)です。
労働関係諸局への通報・斡旋による軽微な「適正化」や監督・指導に対して、法律に定められた刑事罰を問うことになり、
違法派遣業者にとって有罪は考えられる限り最大の処罰となります。同時に刑事罰を受けた
担当者が取引先に与える悪印象を考慮すれば、通常会社側は告訴が受理された時点で告訴取り下げに
動くのが妥当でしょう。懲役、前科がつく刑罰が下される可能性から、告訴取り下げの和解金は高額となることが多いのです。

告訴の流れとしては、

刑事告訴⇒告訴受理⇒告訴取下げ要請⇒取下げ和解金入金⇒告訴取下げ

となります。告訴の懲役刑適応は犯罪者個人に対してのみですので、告訴する対象は
派遣先・派遣元 社長
派遣先・派遣元 責任者・管理役員・取締役
派遣先・派遣元 人事管理担当者・人事管理役員・取締役

が妥当です。刑事告訴取り下げの和解金額は犯罪者個人と交渉するとよいでしょう。(告訴状は人数分提出する必要あり)

0159仕様書無しさん2012/12/01(土) 18:13:14.83
>>151
151の会社では、DSLでアプリの定義を作ることをコーディングって呼んでるのか?
うちの会社じゃ設計って呼んでるんだが。

0160仕様書無しさん2012/12/01(土) 21:44:18.08
工事進行基準

0161仕様書無しさん2012/12/01(土) 23:21:29.76
>>159
> DSLを使うって書く = 設計
正しいよ。

DSL = ドメイン特化言語(Domain Specific Language)の略

DSLには二種類ある
・言語内DSL・・・プログラミング言語その物+書き方の規約。例 Rubyで構築されたDSLの文法はRubyである
・言語外DSL・・・プログラミング言語とは違う文法の言語。例 SQL

DSL = 特殊な用途に最適化されてるってだけで、プログラム言語の一種
よって
プログラム言語を使って書く = 設計

0162仕様書無しさん2012/12/04(火) 18:53:55.39
刑事告訴によるパワハラ対策

刑事告訴の根拠となる法律: 刑法(傷害罪、脅迫罪、強要罪、威力業務妨害罪等)と職安法・労働基準法(違法派遣等)

刑事告訴の立証例(傷害罪の場合)

傷害がうつ病などの精神を起因とする病気である場合、裁判所がみるのはうつ病の医学的原因の特定ではなくプロセスです。
被害者がパワハラの一部始終を録音すれば有罪にするのは考えるよりは易いでしょう。加害者が暗に会社を辞めるよう仄め
かしたり、不条理な行動が認められればそれで犯罪として成立します。

刑事告訴の特徴

刑事告訴の場合は、民事訴訟と違って裁判による被害者への2次被害は特にありません。
検察庁が被害者に代わって訴えをおこすので、無料で、時間と手間も告訴状をかくことと、音声録音を残すだけです。

犯罪加害者(=パワハラ上司と犯罪教唆をした経営陣・人事部)は弁護料、他裁判諸経費の負担、
留置所生活(※警察が相当と認めた時)、強制捜査・現場立ち入り(職場、自宅等)などの犠牲がともないます。

容疑を否認し続けた場合、仕事どころでなく解雇などもありうる孤独で長い戦いが予想されます。ですので
決定的証拠がある場合は、多額の和解金(刑法なら犯罪者の年間収入、職安法なら半年の収入)で解決することができます。

違法派遣(事前面接・スキルシート・偽装請負・多重派遣)は経営陣にも責任が求められることと、法で加害者と定義されて
いる人数が十数名を越えることもあり、和解金額としては違法派遣のほうが最終的には高くなるかもしれません。

0163仕様書無しさん2012/12/09(日) 20:57:10.94
この手のスレでは実装して形にする能力に関して不要
という極論を展開して粘着する奴が多い

実際にはモノが作れないから技術コンプレックス抱えてるんだろうなあ
技術者の肩書き外せば楽になれるのに
それとも何も出来ないからアーキテクトなんて肩書きが欲しいのかな

役職じゃなくて役割なんだから2ch来てまで社内政治すんなよ

0164仕様書無しさん2012/12/09(日) 21:21:25.90
能力のあるなしと、作業するか否かを混同するなよ。
このスレで、アーキテクトに実装能力が不要と書いてる奴なんてレスは殆どないだろ。
でも、アーキテクトは実装作業はしないよ、ってことだよ。

0165仕様書無しさん2012/12/09(日) 21:29:07.94
実装作業はしないけど、プログラミングはする。
土台を設計するのが仕事だが、まともな土台を
プログラミングなしで作るのは無理だ。

理論と実証みたいなもん。
あーだーだいっても
実証されなきゃ使い物にはならん。

0166仕様書無しさん2012/12/09(日) 21:36:32.60
> 164
土台くらいは実際に動くものを提示しない限り設計が出来たとはいえないでしょ
机上だけで作った設計でほとんど問題が出ないなんてありえるか?

0167仕様書無しさん2012/12/09(日) 21:39:53.04
愚者は経験に学び、賢者は歴史に学ぶ。

0168仕様書無しさん2012/12/09(日) 21:42:48.12
>>167
その言葉は支配階級が労働者階級を馬鹿にするために発したものであるから有り難味が無いという記事をどこかで読んだ。

0169仕様書無しさん2012/12/09(日) 21:44:15.87
つまり問題は出ないと言いたいのか
今度仕事頼みたいから紹介してよ

0170仕様書無しさん2012/12/09(日) 21:47:17.88
今更ウォーターフォール開発ですか。

0171仕様書無しさん2012/12/09(日) 21:49:21.62
>>166
設計だけ提示するのも、設計と土台を提示するのも大して変わらんよ。

0172仕様書無しさん2012/12/09(日) 22:44:49.42
告訴の趣旨
 被告訴人は、以下に該当すると考えるので、被告訴人の厳重な処罰を求めるため告訴します。
 職務経歴書を提示した事前面接を実施
  労働者派遣法第26条(契約の内容等)、職業安定法第44条(労働者供給)に違反
 多重派遣・多重出向
  労働基準法第6条(中間搾取の禁止)に違反
疎明資料
 事前面接日時、場所、出席者、資料のコピー、音声記録
 就業場所・就業期間・就業時間
 指揮命令
  指示を誰が行っているかの記録、音声記録
 仕事で使う道具や、資材の負担(所有)のあり方
  業務で使用しているパソコンなどの所有者
 契約書
  雇用契約書など書面のコピー

告訴事案の第3社への情報漏れに対する対応
和解時に事案についての秘密保持契約を結ぶのが慣例となっています。
従って刑事告訴の成功例は当事者の秘密事項ということになります。

わかりやすい例としては、痴漢です。痴漢も民事でなく刑事事案ですが、裁判所が和解金を被害者に支払
わせて解決するのが絶対的過半数です。むしろ和解で解決しない事案、つまり公訴まで
いって、判例となる刑事裁判の事例を探すほうが難しいことでしょう。しかし痴漢等の犯罪と同様に刑事事案
で、犯罪者が容疑を否認する行為は検察=国家を敵にする行為であり、
民事とは違い、犯罪者側が長期の弁護士費用、留置所勾留、強制捜査に耐えなければなりません。
犯罪者から和解金を支払いたいと申し出るのが通常の流れとなります。

0173仕様書無しさん2012/12/09(日) 22:59:18.04
>>171
その理由は?

0174仕様書無しさん2012/12/10(月) 00:22:36.15
アーキテクトが実装しないとしてさ
じゃあ設計と実装の間を整合性の取れたアーキテクチャとして繋ぐのは誰?

その役割に何か命名したら、今度はその役割の人物は実装はしないとか言い出す訳?

最終的なシステムを実装する段階を軽視する限り、日本のITは実態とかけ離れる一方じゃないの?

0175仕様書無しさん2012/12/10(月) 00:26:46.48
整合性なんてどうでもいいよ。
というかわからん。

コードわからないんだから、見てもわからん。
俺が考えたもの通りのものができてることを
信じるしかない。

0176仕様書無しさん2012/12/10(月) 00:31:46.40
>>175
その考えたことは実装したらちゃんと動くの?
それが問題の根本だろ?

0177仕様書無しさん2012/12/10(月) 00:45:29.55
>>176
理論上は動く。そして実際にプログラマに
作らせて動いている、
ならば動くと実証されているということ。


もう少しバグが少なくて
短い時間で作れたらなおいいんだが。

0178仕様書無しさん2012/12/10(月) 00:58:38.84
>>177
バグが少なくて短い時間で作れるようにするのがアーキテクトの役割でしょ
そのプログラマ依存のシステムは、ちゃんとしたアーキテクチャになってるの?

整合性が取れたモノのなっていないなら、今後の保守性や拡張性に問題が残る
しっかりしたモノが出来上がっているなら、そのプログラマはアーキテクトとしての役割をこなしたことになる

>>177 が整合性があ取れているか分からないのなら、実態はプログラマが優秀なんだろう
もちろん、ちゃんとしたモノが出来上がっているのなら、>>177 は無能ではないよ
マネージメントを上手くやった結果だとは思う
ただ、アーキテクトとして上手くやった結果ではないよね

0179仕様書無しさん2012/12/10(月) 01:03:46.75
飲んでるから、文章に変なゴミや誤字が残りまくりw
まあ言いたいことはアーキテクトは管理者と同義では無いってことだ

0180仕様書無しさん2012/12/10(月) 02:22:52.51
>>174
設計に実装の方法まで書いてるだろ。
まぁ最近は関数内のフローチャートまで書くようなことは少なくなって
その辺はPGに任せることが多いけど。

0181仕様書無しさん2012/12/10(月) 02:44:27.25
実装の方法は、コードでしか書けないって
わかる?

0182仕様書無しさん2012/12/10(月) 02:51:00.67
頭悪くないからわからない。

0183仕様書無しさん2012/12/10(月) 03:50:49.34
半田ごてでなんとかかんとか

0184仕様書無しさん2012/12/10(月) 07:23:32.32
どっかの人売りIT業界じゃあ、プログラマってのは、分厚い仕様書を受け取って、それを1カ月かけてコーディングするのかもしれないけど、
アーキテクトがプログラマを使って先端的なプログラムを開発する時ってのは、
ものすごい短い周期で作業指示がでるんだよ。
作業自体、目に見える範囲でやってるし。
実装で問題が生じたら、すぐにアーキテクトのレベルまで問題点が上がってくる。

0185仕様書無しさん2012/12/10(月) 07:49:08.63
それなんてアニメ?

0186仕様書無しさん2012/12/10(月) 20:33:43.14
>>181
コードでしか書けないんだったら、アーキテクトやSEがコード書くことになるから、PG不要じゃない。
アホなの?

0187仕様書無しさん2012/12/10(月) 20:47:46.76
情報システムがプログラムだけで完結するのならPG,SEだけでも仕事できるかもな。

0188仕様書無しさん2012/12/10(月) 20:57:27.77
>>186
職名がPGかSEかアーキテクトかは問題じゃない

プログラム書けないアホが不要ってことだ
お前のようにな

0189仕様書無しさん2012/12/10(月) 21:24:29.68
>>188
>>180は、設計に実装方法まで書いてると書いてる。
アホな>>181は、実装の方法はコードでしか書けないと書いてる。
よって、設計者はコードを書いてるということになる。

ところで、どうして>>186がプログラム書けないって思ったんだ?

0190仕様書無しさん2012/12/10(月) 22:21:49.30
わかってます。なんとかしなければいけないとわかってるんです。
しかし、わたしが何か技術的な問題と取り組んでいると、
阿呆なとんちきがやれ輸送の問題だ、やれ電話だなんだかだと、
つまらんことで私に決定を求めてくるんです。

0191仕様書無しさん2012/12/11(火) 00:44:33.08
>>189
設計=コードというのは、コンパイルできて
実行可能なものだ。

名前に価値はない。やっていることに価値がある。
お前の言う「設計者」は「コンパイルできて実行可能なもの」を
作っているのか?

0192仕様書無しさん2012/12/11(火) 01:04:26.14
>>186
> コードでしか書けないんだったら、アーキテクトやSEがコード書くことになるから、PG不要じゃない。
> アホなの?

アホはお前だろう。

アーキテクトが書くコードと、PGが書くコードは
対象となるドメインが違う。

アーキテクトが書くコードは土台。
PGが書くコードは土台の上の部分。

0193仕様書無しさん2012/12/11(火) 01:20:23.64
プログラマとシステムエンジニアを分けようとするやつのせいでおかしくなる
だからアメリカに負ける。

0194仕様書無しさん2012/12/11(火) 01:24:27.00
いや、システムエンジニアなんてのはアメリカにはなく、
プログラマ(デベロッパー)とアーキテクト(上級デベロッパー)という
区別しかないんだよ。

0195仕様書無しさん2012/12/11(火) 01:25:31.35
だからそう言ってるんだよ

0196仕様書無しさん2012/12/11(火) 01:28:52.32
>>195
言ってないだろw

お前は、AとZを分けようとするヤツのせいでおかしくなると言ってる。
俺はZなんてものは要らない。不要なものと言ってる。
必要なのはAとB。BはZではない。

0197仕様書無しさん2012/12/11(火) 01:49:35.97
日本でシステムエンジニアと呼ばれる者がアメリカに存在しないという事ぐらい知ってるっつーの
馬鹿か?
それとも何、そういうものが存在しないという事を態々俺に教えてくれたの?
それとも言葉遊びのスタート?

0198仕様書無しさん2012/12/11(火) 02:22:14.27
>>178
>そのプログラマ依存のシステムは、ちゃんとしたアーキテクチャになってるの?
これグサッと来る奴多そうだなw

0199仕様書無しさん2012/12/11(火) 04:02:00.62
少なくとも、俺は理解してないフレームワークは使わないし、設計してから実装してるから、誰かが破壊しない限りはちゃんとしたものになってるよ。

実際、プログラマはピンキリだからね。
アーキテクト()もピンキリだけど。

ていうか、何度もいうけど役割分担でしかないし…

0200仕様書無しさん2012/12/11(火) 04:03:45.16
>>198
おお、ちゃんと読んでなかった。
アーキテクトに向けて言ってたのね…
寝よう…

0201仕様書無しさん2012/12/11(火) 08:43:21.35
>>199
> ていうか、何度もいうけど役割分担でしかないし…

その重要な役割であるアーキテクトが
日本では極端に少ないって話でしょ?

0202仕様書無しさん2012/12/12(水) 08:20:04.51
コード書けないSEの首切って
優秀なPGをアーキテクトにすれば解決
ゴミSIを除けば既にやり始めてる

0203仕様書無しさん2012/12/12(水) 23:37:16.20
例えば World of Warcraft を開発するとしたら、アーキテクトのスペックと仕事は何?

0204仕様書無しさん2012/12/13(木) 02:01:32.80
>>203
ゲームに限らずだけどある一定の規模を超えるアプリは一人では作れない。

ゲームのエンドユーザー視点で仕様 ”だけ” が決まっているとする。
つまりWorld of Warcraft のパクリを作ると考えればいい。
その時、10人の開発者に仕事を割り振るとしよう。
お前は○○のキャラクター、お前は○○のステージ。みたいに。

これだけで作れると思うだろうか?
作れるわけないね。個々のプログラマが自分の好きな方法で作ったとしても
それらを組み合わせることはできない。統一した開発方針が必要になる。

ゲーム用フレームワークを選べば組み合わせられるという人がいるかもしれないが
それはわかってない人。フレームワークは汎用的に作られているからいろんな使い方ができる。
だから使い方を決めないといけない。

フレームワークの使い方を決めるということは必然的にそのフレームワークが
搭載されている機能を実際に使って(コード書いて)判断しないといけない。

もちろんフレームワークの使い方だけじゃない。コーディング規約や社内ライブラリの管理や
テストなんかも統一した開発方針で決めるべきこと。実際の作業はプログラマにやらせるかもしれないが
最終的にレビューして決定するのはアーキテクト。だから上級プログラマとしての能力が必要になる。

0205仕様書無しさん2012/12/13(木) 08:28:30.68
実際の作業はSEがやってるけどね。

0206仕様書無しさん2012/12/13(木) 08:44:42.20
できない人がやっても意味ない

だから、クソSEが作った変なものを
プログラマがどうにか治すという構図が出来上がる。

0207仕様書無しさん2012/12/13(木) 09:13:43.46
派遣で全部お膳立てした環境でしか働いたこと無いPGにできるとおもってんの?w

0208仕様書無しさん2012/12/13(木) 09:49:21.80
派遣PGしか居ないレベルの職場にいるクズがなにいってんだ

0209仕様書無しさん2012/12/13(木) 13:23:45.62
SEとかPGとか関係ない
大学の学部で学ぶ程度のコンピュータサイエンスの基礎知識も持っていない奴はゴミだってこと
具体的には数学、アルゴリズム、プログラミング、情報理論、言語理論、OSの設計と実装、基礎電子工学など

0210仕様書無しさん2012/12/13(木) 20:06:32.19
文系でも歓迎()
文系・理系不問です()

0211仕様書無しさん2012/12/18(火) 00:08:03.46
【死刑】馬鹿にプログラムを書かせるな! その1【処刑】
名前: 仕様書無しさん
E-mail: sage
内容:
デバッグ・派生開発などまわりの全てが不幸になる
馬鹿プログラマのコーディング業務を禁止する法律を作るべき!

スレ立てられなかった
だれか建ててくれ

0212仕様書無しさん2012/12/18(火) 00:16:18.10
>>211
ほらよ。

馬鹿にプログラムや設計を書かせるな! その1
http://kohada.2ch.net/test/read.cgi/prog/1355757342/

0213仕様書無しさん2012/12/18(火) 00:39:01.75
>>212
クッソワロタ

0214仕様書無しさん2012/12/25(火) 15:14:19.71
※コピペ歓迎
違法派遣(事前面接、偽装請負、多重派遣)とパワハラの告訴状(刑事告訴)の受理後の示談交渉→示談外交渉について

@示談交渉 話し合いを持ちたいと犯罪者の弁護士から打診
被害者の精神的痛みや社会的・経済的損失を訴え厳罰を求めるようにしてください。
弁護士の提案する示談金は相場が低い法廷相場で提案が来ますが全てはねつけ厳罰の適用を主張してください。

A示談外交渉 話し合いを持ちたいと犯罪者個人から打診
交渉は基本受身で、犯罪者を一切許す気はないが話だけは聞きましょうという姿勢で臨みましょう。
被害者からお金の額を提示するのは絶対しないようにしましょう。犯罪者側は
いくら欲しいですかと聞いてくるでしょうが、応えてはいけません。満足する金額を提示するまで、「話は分かりました、しかしまだあなたを
許す気にはなれません」と伝えましょう。※お金を要求しなければ恐喝の成立はありません。
@と違い法的にねじ伏せるのをあきらめ、起訴された時の経済的・社会的地位の損失を計りにかけた民事上の交渉に移ります。※被害者も有罪後の民事訴訟は放棄します。

B満足する和解案の提示
被害者の想定する、犯罪者の払える最大限の金額まで達したら、「そこまで反省するなら、許して告訴を取り下げ
てもよいです。入金が確認された後に取り下げます」といえばいいでしょう。

和解金の想定上限は犯罪者個人の年収の半分程度が良いでしょう。事業会社、請負会社の社長や、
下請でも創業者の場合の年収÷2は、数千万〜1億円、外注・人事担当役員、
外注担当の部長やマネージャーであれば500〜1000万円、営業個人については200〜500万円程度でしょう。

C和解時の同意書(公正証書、即決和解)
和解時には該当事案について犯罪者・被害者双方が秘守契約を結ぶことになるでしょう。
犯罪者側が被害者について誹謗中傷をしたり、被害者の個人情報、告訴事案について第3者
(他社)と通謀するような事態が発覚した場合の、賠償金をあらかじめ公正証書・即決和解で合意してください。
賠償金額は双方が違反を考えられないぐらい大きな金額(最低5000万円〜)に設定すると良いでしょう。
和解金が支払われるということは双方が「和解」することを指しますから、お互い後腐れないよう合意をする必要があります

0215仕様書無しさん2013/11/12(火) 20:36:57.68
エンプラ系の案件のほとんどが
アーキテクチャを技術的要請からでなく
統括マネージャとかの好みのブランドとか
部長のお友達が始めた会社の無名パッケージ使えとかで決めるから
アーキテクトなんて必要ない。

0216仕様書無しさん2015/10/04(日) 22:41:29.18
受ける会社大丈夫?
下記の条件が全て当てはまる会社にご注意下さい。

・IT系
・「社名 労基」でググると過去の2chスレが出てくる
・転職会議で2.5点

0217仕様書無しさん2016/05/02(月) 18:07:43.29
ここで認めてもらえるアーキテクトになるにはどれほどの修行が必要でしょうか

新着レスの表示
レスを投稿する