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

1: 仕様書無しさん 2012/11/23(金) 11:20:11.21

ここのプログラマがてんでバラバラに
コードを書いているだけ。

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

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

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

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

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

8: 仕様書無しさん 2012/11/23(金) 21:42:52.45

>>6
そうですね。自分の使っている言語の
有名なフレームワーク。これをよく調べることです。

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

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

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

11: 仕様書無しさん 2012/11/24(土) 08:15:15.91

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

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

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

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

14: 仕様書無しさん 2012/11/24(土) 15:21:00.13

>>11
俺はコード見ればだいたい分かる。

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

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

19: 仕様書無しさん 2012/11/24(土) 18:37:24.24

>>14
>確かにこれでうごいてる。でもそうじゃねーだろ。
>そんなのばかり。

あるある

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

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

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

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

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

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

34: 仕様書無しさん 2012/11/25(日) 01:08:37.30

>>33
特に最近はそうだよな。

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

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

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

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

40: 仕様書無しさん 2012/11/25(日) 02:31:06.12

>>38を見たときの反応

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

さあ、君はどれだ!?

46: 仕様書無しさん 2012/11/25(日) 15:23:02.78

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

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

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

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

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

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

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

55: 仕様書無しさん 2012/11/25(日) 19:42:55.11

>>52
ほらなw

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

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

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

62: 仕様書無しさん 2012/11/25(日) 20:35:22.47

>>59
それはアーキテクトの重要性をわかってない証拠だよ。

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

64: 仕様書無しさん 2012/11/25(日) 20:42:34.02

>>59
プログラミングの質は、上流工程ではどうにも出来ないよ。
普通に考えればわかるでしょ?

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

66: 仕様書無しさん 2012/11/25(日) 20:53:09.15

一人がプログラミング担当なら別だけど、
普通は複数人のプログラマがいる。

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

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

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

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

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

78: 仕様書無しさん 2012/11/25(日) 21:53:53.81

話を戻すと、コードを見て(普通マニュアルは整備されてない)
そこから設計を読み解く能力。

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

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

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

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

123: 仕様書無しさん 2012/11/29(木) 00:30:42.22

おれさ、アーキテクトって業務設計する人だと思ってたんだが
そしてそれを実現させるのがデベロッパじゃないのか?

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

125: 仕様書無しさん 2012/11/29(木) 00:46:55.61

アーキテクトは顧客に向けてアーキテクチャについて説明しなければならない立場だけど。
アーキテクトはプログラマの延長ではないぞ。

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

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

137: 仕様書無しさん 2012/11/30(金) 01:23:57.92

>>135
より正確に言い方をするならば

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

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

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

163: 仕様書無しさん 2012/12/09(日) 20:57:10.94

この手のスレでは実装して形にする能力に関して不要
という極論を展開して粘着する奴が多い

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

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

165: 仕様書無しさん 2012/12/09(日) 21:29:07.94

実装作業はしないけど、プログラミングはする。
土台を設計するのが仕事だが、まともな土台を
プログラミングなしで作るのは無理だ。

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

174: 仕様書無しさん 2012/12/10(月) 00:22:36.15

アーキテクトが実装しないとしてさ
じゃあ設計と実装の間を整合性の取れたアーキテクチャとして繋ぐのは誰?

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

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

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

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

199: 仕様書無しさん 2012/12/11(火) 04:02:00.62

少なくとも、俺は理解してないフレームワークは使わないし、設計してから実装してるから、誰かが破壊しない限りはちゃんとしたものになってるよ。

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

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

201: 仕様書無しさん 2012/12/11(火) 08:43:21.35

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

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

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

206: 仕様書無しさん 2012/12/13(木) 08:44:42.20

できない人がやっても意味ない

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

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

引用元

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

管理人からひと言

SEの仕事です

スポンサーリンク
スポンサーリンク
スポンサーリンク

シェアする

フォローする

コメント

  1. ボンブの回し者 より:

    みんな、好きに俺俺アーキテクト像を語っているだけ