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

1 ：2012/11/23 〜 最終レス ：2012/12/25

ここのプログラマがてんでバラバラに
コードを書いているだけ。
全体の構成を考える人がいない。
全体の構成を考えながらコードを書ける人もいない。
まとまりがない、重複が多い、だからバグもなくならない。
だからアメリカに負ける。

2 ：

外資が日本式の無能SE/PG大量生産してますし
IBMとかね

3 ：

違法派遣（事前面接、偽装請負、多重派遣）のR状（刑事R）の受理後の示談交渉について
�@会社への通達
会社には「Rした犯罪者本人か犯罪者個人が雇った弁護士としか話はしない」と釘をさしましょう。
�A話し合いを持ちたいと犯罪者個人から打診（示談交渉）
交渉は基本受身で、犯罪者を許す気はないが話だけは聞きましょうという姿勢で臨みましょう。
被害者からお金の額を提示するのは絶対しないようにしましょう。犯罪者側は
いくら欲しいですかと聞いてくるでしょうが、応えてはいけません。満足する金額を提示するまで、「話は分かりました、しかしまだあなたを
許す気にはなれません」と伝えましょう。※お金を要求しなければ恐喝の成立はありません。
犯罪者側も被害者を怒らせた場合は、最悪感情論からRを継続させるという
事態を危惧するでしょうから、犯罪者側の心理は不安な状態にあるはずです。
意に沿わぬ和解案には強い態度で自信を示して退けましょう。
�B満足する和解案の提示
被害者の想定する、犯罪者の払える最大限の金額まで達したら、「そこまで反省するなら、許してRを取り下げ
てもよいです。入金が確認された後に取り下げます」といえばいいでしょう。
和解金の想定上限は犯罪者個人の年収の半分程度が良いでしょう。ユーザー、元請の社長や、
下請でも創業者の場合の年収÷２は、数千万〜数億円、外注・人事担当役員、
外注担当の部長やマネージャーであれば500〜1000万円、営業個人については
200〜500万円程度でしょう。
�C和解時の念書（同意書）
和解時には該当事案について犯罪者・被害者双方が秘守契約を結ぶことになるでしょう。
犯罪者側が被害者について誹謗中傷をしたり、被害者の個人情報、R事案について第3者
（他社）と通謀するような事態が発覚した場合の、賠償金をあらかじめ念書に記入するよう
にしてください。賠償金額は和解金額の２倍程度に設定すると良いでしょう。犯罪者側も
和解金を払った事実と事案について第3者に通謀しないように求めてきますが、内容が社会通念に
著しく反するような性質でなければ応じましょう。和解金が支払われるということは
双方が「和解」することを指しますから、お互い後腐れないよう合意をする必要があります。

4 ：

エクセルやコード書かない人は単価０円だもん。

5 ：

まとめ役の下はプログラマ−しかいないからな。

6 ：

アーキテクトの>>1さんが押えておくべきツボを実例を交えて講釈なさると聞いて

7 ：

トップダウン設計したらレガシーや言うだろ

8 ：

>>6
そうですね。自分の使っている言語の
有名なフレームワーク。これをよく調べることです。
ライブラリだとアークテキチャがない（ただの関数の集まり）
もしくはほんの少ししか無いみたいなものがたくさんありますが
フレームワークにアーキテクチャが存在しないことはまず無いですからね。
使ってみるのはもちろん、なぜそのような実装になっているのか
できればソースコードまで見て見ることをおすすめします。
それが無理でもファイルの置き場所、クラスの分け方を見てみるだけでも
十分参考になりますよ。
漠然と見るのではなく、なぜそのようになっているのか、
その理由を考えてみるといいでしょう。

9 ：

以上、中身のない講釈でした。

10 ：

>>9さんが中身がある講釈をなさると聞いてｗ

11 ：

>>8
>漠然と見るのではなく、なぜそのようになっているのか、
>その理由を考えてみるといいでしょう。
設計意図が分かると良いんだけどね
コメント読んでも分からない事が多いよ
俺のお勧めはアップルのドキュメントを
「自分の作ったシステムで、同じように書けるか？」
と考えながら読んでみることだな
こんな構成になってる
・ガイドライン
・プログラミングガイド
・リファレンス
単なる関数の寄せ集めでもリファレンスは書けるがプログラミングガイドは難しい
ガイドラインまではまず書けない

12 ：

笑

13 ：

独立すると、アーキテクトにならないと食っていけない。コーディング出来ないアーキテクトもしくは、アーキテクトになれないプログラマは淘汰されるだろう。

14 ：

>>11
俺はコード見ればだいたい分かる。
でもそれはやっぱり20年以上もプログラミングやってるからだろうな。
（言っとくが10歳からやってるって意味だぞｗ）
仕事で見るコードはたいがい設計意図が
感じられないただの手続きの流れで疲れる。
確かにこれでうごいてる。でもそうじゃねーだろ。
そんなのばかり。

15 ：

ネットにはかまってちゃんが多くて疲れる
>>1なのばっかり

16 ：

で？

17 ：

ここまでソフトウェに対するツッコミ無し

18 ：

>>17
次スレでは直しておくよｗ

19 ：

>>14
>確かにこれでうごいてる。でもそうじゃねーだろ。
>そんなのばかり。
あるある
凄いスパゲッティコードなあげくに
やってることは今時の開発環境に標準で入ってる機能とかね…

20 ：

>>14
形の無いグズグズなコード、あるある

21 ：

>>19
そういうのって、標準であるの知ってても、わざと自分で作ってるんだよ。
標準の機能って本当は作りやすいけど、難しいふりして２〜３日余分に工数掛けて
自分の給料を増やすのさ。

22 ：

>>21
要領が悪いねｗ
標準のを使って時間を稼いで
相手時間で、さらに技術と知識を広げればいい。
俺はそうやってるよ。
だからどんどん差がつくんだろうな。

23 ：

大手ＩＴ企業がプロジェクトマネージャのみを育成し続けた弊害では？

24 ：

>>23
大手ITも>>21みたいなのを実は推奨してるんだろ。
工数増えれば売上げ増えるんでしょ？
しかも末端の数倍も。

25 ：

>>24
大手IT企業は下請が出した見積にマージンを上乗せしてエンドユーザに提出するだけｗ

26 ：

>>19
9時の納品まであと二時間しかないときに、仕様変更。
いままで一度も使ったことのない標準機能を使う方に賭けるか、
自前のコードに賭けるかとなると、俺は後者を選ぶね。

27 ：

>>26
あぁ、俺にはそんな経験ないやｗ
後２時間で納品で、仕様変更来て
責任なんて取れないしな。
馬鹿のすることだ。

28 ：

>>26はアーキテクトには向かないな。
対応するのが絶対だとして、自前のコードを書くにしても
俺なら正規のコードとしては書かない。
つまりだ。
FIXME このコードは時間がなくしかたなく書いたコードであり
品質も低い。あとで直すべきだし、この方法は使ってはならない。
とコメントを入れておくよ。
正しいコードとして選んだんじゃないということを
しっかり明記する。でないと糞コードを真似て書く奴が出る。
それで全体の品質が落ちてるってことともよくある話。
なんでこんなコード書いた？ → 最初にそう書かれていたから。
こんなコードに何の理念も感じられない。

29 ：

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

30 ：

> 一応コメントは入れるけど
嘘つけｗ
言い訳すんな。

31 ：

コードコードと連呼している時点でアーキテクトには不向きだなｗ

32 ：

へ？ アーキテクトの仕事ってコードの設計なんだけど？

33 ：

コードを書かずに絵？だけ書いて、ベストの設計に持っていけるのって
ワールドクラスのアーキテクトでも無理だと思うが？

34 ：

>>33
特に最近はそうだよな。
全部自前で作るわけじゃなくて既存の何かを使うわけで、
最適な設計というのは、それらを実際に使わないとわからない。
最高のアーキテクトになるには、他人が作った物の”設計の考え”を
見抜く力がなければならない。

35 ：

まあここで偉そうなこと書いてる奴が
口だけなのは明らかですがね
ちょっと問題出せば逃げ出していくよ
「コードは簡単なものすら書けないが設計はできる」と謎の発言を残して

36 ：

>コードを書かずに絵だけ書いて
「プロジェクトの姿」を思い出した…。

37 ：

>>35
じゃあ、お前に問題出していい？

38 ：

1から100までの数を二つに分けて
それぞれのグループの数を掛け合わせたとき
両者が同値になる組み合わせの数は何個？

39 ：

>>35
早く答えてね

40 ：

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

41 ：

>>40を見た時の反応
のほうが興味があるなｗ

42 ：

>>28
>なんでこんなコード書いた？ → 最初にそう書かれていたから。
この手の事なかれ主義も困ったもんだよな
ま、あんまり偉そうなことは言えないが
>>40
まず「そいつはintか？doubleやcharじゃないだろな」と思った
完全にプログラマだなw
次に思ったのは「二つに分けて」や「グループの数」は曖昧だな、
「二つのグループに分けて」「グループの数（２つじゃん)」じゃないだろな？だった

43 ：

>>38
「じゃあ」から始まったこの問題は何の意味があるのだろう？と思った
コードにして実行する必要性があるとは思えなかった
とりあえず誰かに解かせてみようか、とは思った

44 ：

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

45 ：

>>38、>>40がわけのわからんことを言い出したから
俺がアーキテクトというのが何かを教えてあげるよ。
あるオープンソースアプリがあって、その日本語化を
行うことになった。
★アーキテクトがいない場合
・SE
英語を日本語に置き換えるだけだから
英語ができれば難しい仕事じゃないな。
新人だけど英語ができるあいつにやらせよう
・プログラマ
ひたすらソースコードを見て
英語の所を日本語に置き換えていく
★結果
アプリがバージョンアップするたびに
差分をとってソースコードをマージする
作業に時間を取られるようになったのであった。

46 ：

★アーキテクトがいる場合
・アーキテクト
このオープンソースアプリは日本語には対応していないが
多言語対応する仕組みが入っており、
最近もメンテナンスが入っているぞ。
ならそのやり方に合うように足りない部分を作ろう。
最初に少し時間がかかるかもしれないが、
あとは言語ファイル作るだけの単純作業だ。
プログラマじゃない人でもできる。
★結果
アプリがバージョンアップしてもコードがしっかり分離されていために
該当部分に修正が入ることは少なくメンテナンス時間も短い。
そして将来本家に足りない部分がマージされ
公式に日本語対応されたのであった。

47 ：

>>46
それはアーキテクトの仕事じゃない。SEの仕事。

48 ：

>>47
SE は プログラミングが出来ないので
それは無理な話です。

49 ：

> このオープンソースアプリは日本語には対応していないが
> 多言語対応する仕組みが入っており、
> 最近もメンテナンスが入っているぞ。
> ならそのやり方に合うように足りない部分を作ろう。
>
> 最初に少し時間がかかるかもしれないが、
> あとは言語ファイル作るだけの単純作業だ。
> プログラマじゃない人でもできる。
このどこにプログラミングの要素が入ってくるのか。
単にオプソ関連のノウハウを知ってればできることだろ。

50 ：

SEはプログラミングしないが
アーキテクトはプログラミングをするんだよ。
そしてアーキテクトの成果により、
他のプログラマの仕事の出来が左右される。
優秀なアーキテクトの元ではコードが統一され無駄がなく、
バグも少ないテストも簡単な仕組みが出来上がる。
無能SEはプログラマに「やれ」とだけ命令する。
そうするとプログラマごとにてんでバラバラな物が出来上がる。
でもソースコード読めないからその悪さを評価できない。

51 ：

>>49
> このどこにプログラミングの要素が入ってくるのか。
ソースコードをみて、多言語対応の仕組みが
備わっていると判断できる。
足りないコードは何でそれを作る力を持っている。
明らかにプログラミングの要素じゃん

52 ：

ドキュメントみれば分かるでしょ。
作らせればいいじゃん。

53 ：

みなくてもいいかな。ノウハウさえあればいい。

54 ：

アーキテクトの例として既存オープンソース製品のローカライズをあげる馬鹿ｗ
全言語に対応したオープンソース製品を構想することを例にあげるならわかるが。

55 ：

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

56 ：

>>54は馬鹿なのかな？

57 ：

うむ。54もばかの一人だな。
もちろん、54だけがバカというわけじゃないよ。

58 ：

>>55
プログラマ雇えば何もせずに勝手に日本語化すると思ってるバカですか。

59 ：

アーキテクトがたずさわるレイヤー（粒度、レベル、立場、視点）が違う気がする。
ソフトウェア単体の開発をどうこうするよりももっと上流工程でなんかするものだと思うんだけど。

60 ：

アーキテクトがいる場合と、いない場合で
どう違うかって話をしてるのに、
いきなり全言語に対応したオープンソース製品を作る話にする
>>54は仕事でも余計なものを作ってプロジェクトをダメにしそうｗ

61 ：

つまり、>>55はアーキテクトなんていらないと。

62 ：

>>59
それはアーキテクトの重要性をわかってない証拠だよ。
本来はアーキテクトという中間層が必要なのに、
その仕事をなくして、上と下に振り分けるから
めちゃくちゃなものが出来上がる

63 ：

>>61
本当にお前は頭が悪いなｗ
プログラミングの要素を見つけられなかった
やつかお前？

64 ：

>>59
プログラミングの質は、上流工程ではどうにも出来ないよ。
普通に考えればわかるでしょ？
プログラミングの質は、プログラミングを改良することでしか上げられない。
だから実際にプログラミングが出来ない人は改良は無理。

65 ：

>>61
SEに指示してもらってプログラマがやった作業も、
プログラマの手柄にするのか？
ま、どうでもいいけど。

66 ：

一人がプログラミング担当なら別だけど、
普通は複数人のプログラマがいる。
それぞれが勝手にコード書いてると
無駄がたくさん生まれる。だからまとめ役が必要。
ここでまとめ役がコード書かない人だと、
現場では使いづらいだけの意味不明なルールができる。
ルールだけならまだしも、変なオレオレライブラリを使えと強要したり
使うフレームワークだけ決めて、その使い方は個々に任せたり。
実際に自分がやらないからその悪さも理解できないだろうな。
だから実際にコードを書いてる現場の人間に近いレイヤーに
まとめ役が必要。それがアーキテクト。
アーキテクトが優秀だと開発の無駄が大きく削減される。
仕様の変更にも柔軟に対応できたり、バグが減ったり開発期間が減ったり。
システム開発で一番重要な仕事だよ。

67 ：

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

68 ：

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

69 ：

>>66
その役割はITSSでいうところのアプリケーション共通基盤の技術者であって、アーキテクトではないだろｗ

70 ：

>>68
そういう解釈だとしてもだな、そんなもんアーキテクトの仕事ではないわ。

71 ：

>>68
プログラマにもできる仕事ですね。

72 ：

>>69
ITSS（失笑ｗ）
すまんな、日本独自の用語に興味はないよ

73 ：

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

74 ：

>>72
ここは日本だから日本独自の用語が出ても問題ないだろ？
それなら世界ではどう定義されているのか説明してくれ。どうせ説明できないだろうがｗ

75 ：

読めよ無能ども
http://www.atmarkit.co.jp/im/carc/serial/redge43/redge43b.html
IBMシニアITアーキテクト

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

76 ：

>>73
抽象的すぎて何が言いたいのかさっぱりわからんなｗ
だ〜か〜ら〜日本はダメなんだろうな

77 ：

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

78 ：

話を戻すと、コードを見て（普通マニュアルは整備されてない）
そこから設計を読み解く能力。
それはアーキテクトの力であり、
アーキテクトが存在しないと、個々のプログラマが
そーじゃない的なコードを量産することになる。

79 ：

>>75
必要スキルが羅列されているだけじゃん。
だから役割は何なの？って聞いているの。技術面のリーダーってことでいいの？
>>77
アーキテクチャとアーキテクトは違うでしょ。
アーキテクトはアーキテクチャを構想するってことでいいの？

80 ：

まぁ設計ができる人がいないってのは>>1に同意する。
SEが仕様を決めて、PGがコーディングするだけというプロジェクトが
多々あるからな。

81 ：

http://www.atmarkit.co.jp/im/carc/serial/redge45/redge45b.html
　アーキテクトはさらに、設計者や実装者の作業指針となる適切な手法、標準、
およびガイドラインも定義しなくてはならない。
アーキテクティングの目的の1つが、設計者や実装者側の不要な創造性の排除だ。
これは、自分にできることに対して必要な制約を課し、その制約から逸脱すると
アーキテクチャの破壊につながる可能性があると明言することで実現できる。
このような理由から、適切な審査および評価方法を採用することが、アーキテクチャの
整合性を保証するのに役立つことになる。これらの作業が重点を置いているのは、
設計者や実装者の作業を検討し、用意されたアーキテクチャ標準や
ガイドラインへの準拠の度合いを判断することだ。
◆ アーキテクティングは複雑性への対処に役立つ
◆ アーキテクティングは再利用のための基盤を実現する
◆ アーキテクティングは維持管理費用を削減する
◆ アーキテクティングは影響の分析をサポートする

82 ：

>>79
http://www.atmarkit.co.jp/im/carc/serial/redge43/redge43a.html
IEEEでは「アーキテクト」を次のように定義している。
　［アーキテクトとは］システムアーキテクチャを統括する個人、
チーム、あるいは組織を指す（注1）。
■アーキテクトは技術リーダー

83 ：

>>82
ＯＫ。アーキテクトは技術リーダーということだな。

84 ：

念の為に言っとくが、技術リーダーってのは
技術をリード、引っ張っていく事ができる技術者であって
技術者に仕事を割り振ったりスケジュール管理をする
マネージャーじゃないからなｗ

85 ：

アーキテクトの定義は、日本はビジネス寄り、世界は技術寄りで違うんだな。
こういうところでも日本は技術力を軽視していることがよくわかるね。
IEEEでのアーキテクトは日本ではITSSのITスペシャリストにあたるか。
>>84
> 技術者に仕事を割り振ったりスケジュール管理をするマネージャーじゃないからなｗ
わかっとるわ。それはプロジェクトマネージャだろｗ
技術リーダーではなくて、技術統括責任者のほうが適しているかもな。

86 ：

今はどうかは知らんが、
昔はＳＥでも業務ＳＥと技術ＳＥがあって、技術ＳＥがアーキテクトの役割をしていたってことか。
日本のＩＴ企業では、業務ＳＥ＞技術ＳＥ であって、技術ＳＥはコミュニケーションできずにお金を稼げない
お荷物とか言われていたから、現在アーキテクトが少ないのも仕方がないだろう。
そういえば、
「技術系は馬鹿でもできるが、業務系は馬鹿ではできません（キリッ」と言っていたＰＭや業務ＳＥがいたな。
そいつらがいたプロジェクトはいつも火を噴いていたけどｗ

87 ：

>>85
技術統括責任者だと、実際にプログラムしてるって感じじゃ無いじゃんｗ
アーキテクトでいいんだよ。

88 ：

こんなに盛り上がるとは>>1は想像してなかっただろうな。

89 ：

盛り上がるもなにも>>1自ら
書き込んでますからｗ

90 ：

つまり、アーキテクトってのは組織の中で最も優れた技術力を持つ者に与えられる尊称だな
アーキテクトの技術力==組織の技術力(の最大値)

91 ：

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

92 ：

> 別に優れてなくてもいいし
優れてなかったらデスマになるよｗ
少なくとも他のプログラマと同等の仕事が
できないとアーキテクトにはなれないよ。
プログラム知りませんとか、いつもエクセルで
図ばっかり書いていますとかいう人には無理。
実際にプログラミングをするというのが大前提だから。

93 ：

それも違う
最近のゆとりは人月の神話くらい読んだことないのかね

94 ：

>>93は>>91へのレス

95 ：

>>92
役割をひとつしか担わないと言ってないんだけど。
チームの中でより優れた人がアーキやればいいわけで、社内一優秀な人である必要は無いと思うって話。
自分の設計を最後まで責任持つためにも、アーキが実装者の先頭やるべきだと思うよ。
さっきの話だと、アーキテクト様ーって崇められたい中二病にしか見えなくてさ。
>>93
古典くらい読んでるよ。

96 ：

社内一優秀な人とは一言も言ってないよ
そもそもそんなのわかるわけないし、
向き、不向きがあるに決まってるじゃない。
そんな基本的なこといちいち言わせないでよね。

97 ：

>>96
>>90読んで下さい。そんな基本的な(ry

98 ：

>>92
> 少なくとも他のプログラマと同等の仕事が
> できないとアーキテクトにはなれないよ。
そんなことはない。
たとえば、一般のプログラマーに求められる、
ミス無く素早くコーディングができるという能力は必要ない。

99 ：

ミスしない奴なんていないだろ。アホかｗ

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

駄目なプログラマの特徴　２ (366)
この会社辞めようと思った腐れ上司の一言0x2D (793)
Sun認定Java資格 実用情報 2 【SJC-WC用】 (428)
偽装請負会社の社長は人格異常さ (457)
シェアウェア作者の愚痴 29 (818)
Sun認定Java資格 実用情報 2 【SJC-WC用】 (428)
--log9.info------------------
みんな筋トレどれぐらいやっちょる？ (527)
【伝統文化？】剣術・居合総合スレの7【実戦？】 (624)
●●●マイクタイソンvs八巻健二 (744)
レスリングのスレ (485)
【小太刀護身道】スポチャンっていいよね ７本目 (402)
少林寺ｖｓ極真空手 (206)
大山倍達 談 「日本人が勝つとクソーと思う」 (374)
京都の空手事情　その３ (254)
日本武道空手玄和会　其の４８ (368)
●●●　格闘技世界最弱決定戦 (435)
合気道18年やってるけど下手 (769)
【高体重】デブは喧嘩において最強だ！【高防御力】 (264)
【皆で語ろう】SDトルネード (431)
●●●　Rはフルコン警察は伝統空手 (786)
ロンドンオリンピック2012／柔道競技総合 (887)
剣道の昇段審査を語ろう (338)
--log55.com------------------
【偽装民専用】ポケモンGO フレンド募集スレ★1
【地方専用】ポケモンgoーレイドバトル座標vol.52
android専用 ポケモンGO 実機位置偽装スレ Part.3
ニンテンドークラシックミニ/NES･SNES mini 12
XIM総合スレ part34
PSVita 総合 Part36
PSVita 総合 Part37
【Nintendo Switch】総合スレ part4