元スレ
1 :仕様書無しさん:2012/11/23(金) 11:20:11.21 .net
ここのプログラマがてんでバラバラに
コードを書いているだけ。
全体の構成を考える人がいない。
全体の構成を考えながらコードを書ける人もいない。
まとまりがない、重複が多い、だからバグもなくならない。
だからアメリカに負ける。
2 :仕様書無しさん:2012/11/23(金) 11:50:37.51 .net
外資が日本式の無能SE/PG大量生産してますし
IBMとかね
175 :仕様書無しさん:2012/12/10(月) 00:26:46.48 .net
整合性なんてどうでもいいよ。
というかわからん。
コードわからないんだから、見てもわからん。
俺が考えたもの通りのものができてることを
信じるしかない。
161 :仕様書無しさん:2012/12/01(土) 23:21:29.76 .net
>>159
> DSLを使うって書く = 設計
正しいよ。
DSL = ドメイン特化言語(Domain Specific Language)の略
DSLには二種類ある
・言語内DSL・・・プログラミング言語その物+書き方の規約。例 Rubyで構築されたDSLの文法はRubyである
・言語外DSL・・・プログラミング言語とは違う文法の言語。例 SQL
DSL = 特殊な用途に最適化されてるってだけで、プログラム言語の一種
よって
プログラム言語を使って書く = 設計
81 :仕様書無しさん:2012/11/25(日) 22:00:35.57 .net
http://www.atmarkit.co.jp/im/carc/serial/redge45/redge45b.html
アーキテクトはさらに、設計者や実装者の作業指針となる適切な手法、標準、
およびガイドラインも定義しなくてはならない。
アーキテクティングの目的の1つが、設計者や実装者側の不要な創造性の排除だ。
これは、自分にできることに対して必要な制約を課し、その制約から逸脱すると
アーキテクチャの破壊につながる可能性があると明言することで実現できる。
このような理由から、適切な審査および評価方法を採用することが、アーキテクチャの
整合性を保証するのに役立つことになる。これらの作業が重点を置いているのは、
設計者や実装者の作業を検討し、用意されたアーキテクチャ標準や
ガイドラインへの準拠の度合いを判断することだ。
◆ アーキテクティングは複雑性への対処に役立つ
◆ アーキテクティングは再利用のための基盤を実現する
◆ アーキテクティングは維持管理費用を削減する
◆ アーキテクティングは影響の分析をサポートする
31 :仕様書無しさん:2012/11/24(土) 23:44:23.95 .net
コードコードと連呼している時点でアーキテクトには不向きだなw
158 :仕様書無しさん:2012/12/01(土) 15:40:49.18 .net
※コピペ歓迎です。
違法派遣(偽装請負・多重派遣・偽装出向・事前面接等)についての刑事罰
【告訴権者=業務委託、準委任、共同受注、業務請負契約および特定派遣(契約・正規)、一般派遣、正規社員】
職業安定法第44条の労働者供給事業の禁止規定に違反(1年以下の懲役または20万円以下の罰金)
■偽装請負・多重派遣・偽装出向・多重出向
■事前面接(顔合わせ・面談・職場見学等)と履歴書・職務経歴書・スキルシート等提出による労働者の特定(※)
(音声録音で立証可能)
労働基準法第6条(中間搾取の禁止) (1年以下の懲役又は50万円以下の罰金)
■多重派遣・多重出向
※違法派遣(派遣労働者の特定)→派遣法で認められた派遣労働者ではない→労働者供給事業→職業安定法44条違反というの
が前提となる法解釈となります。派遣法における罰則が軽微なのは法律の不備や労働者軽視などが原因ではありません。
違法派遣は全て職業安定法44条で裁くことが可能なため、刑罰の重複を避けるために派遣法には軽微な罰則(主に裁量行政による)しかないのです。
使用者に有利な民事訴訟や労働関係諸局への通報等の対極にあるのが書面(告訴状)による刑事告訴(※告訴先は検察の直告班)です。
労働関係諸局への通報・斡旋による軽微な「適正化」や監督・指導に対して、法律に定められた刑事罰を問うことになり、
違法派遣業者にとって有罪は考えられる限り最大の処罰となります。同時に刑事罰を受けた
担当者が取引先に与える悪印象を考慮すれば、通常会社側は告訴が受理された時点で告訴取り下げに
動くのが妥当でしょう。懲役、前科がつく刑罰が下される可能性から、告訴取り下げの和解金は高額となることが多いのです。
告訴の流れとしては、
刑事告訴⇒告訴受理⇒告訴取下げ要請⇒取下げ和解金入金⇒告訴取下げ
となります。告訴の懲役刑適応は犯罪者個人に対してのみですので、告訴する対象は
派遣先・派遣元 社長
派遣先・派遣元 責任者・管理役員・取締役
派遣先・派遣元 人事管理担当者・人事管理役員・取締役
が妥当です。刑事告訴取り下げの和解金額は犯罪者個人と交渉するとよいでしょう。(告訴状は人数分提出する必要あり)
65 :仕様書無しさん:2012/11/25(日) 20:44:29.70 .net
>>61
SEに指示してもらってプログラマがやった作業も、
プログラマの手柄にするのか?
ま、どうでもいいけど。
164 :仕様書無しさん:2012/12/09(日) 21:21:25.90 .net
能力のあるなしと、作業するか否かを混同するなよ。
このスレで、アーキテクトに実装能力が不要と書いてる奴なんてレスは殆どないだろ。
でも、アーキテクトは実装作業はしないよ、ってことだよ。
215 :仕様書無しさん:2013/11/12(火) 20:36:57.68 .net
エンプラ系の案件のほとんどが
アーキテクチャを技術的要請からでなく
統括マネージャとかの好みのブランドとか
部長のお友達が始めた会社の無名パッケージ使えとかで決めるから
アーキテクトなんて必要ない。
198 :仕様書無しさん:2012/12/11(火) 02:22:14.27 .net
>>178
>そのプログラマ依存のシステムは、ちゃんとしたアーキテクチャになってるの?
これグサッと来る奴多そうだなw
69 :仕様書無しさん:2012/11/25(日) 21:05:46.94 .net
>>66
その役割はITSSでいうところのアプリケーション共通基盤の技術者であって、アーキテクトではないだろw
48 :仕様書無しさん:2012/11/25(日) 15:46:27.35 .net
>>47
SE は プログラミングが出来ないので
それは無理な話です。
201 :仕様書無しさん:2012/12/11(火) 08:43:21.35 .net
>>199
> ていうか、何度もいうけど役割分担でしかないし…
その重要な役割であるアーキテクトが
日本では極端に少ないって話でしょ?
217 :仕様書無しさん:2017/06/11(日) 16:04:02.30 .net
136 :仕様書無しさん:2012/11/30(金) 00:54:50.76 .net
この手の言葉遊びしても、実際の作業は変わらないのになー。
まぁ、自分のやってることは設計だと信じれば何かが救われるのならそれでもいいんじゃないかな。
105 :仕様書無しさん:2012/11/28(水) 03:09:29.78 .net
54 :仕様書無しさん:2012/11/25(日) 19:12:42.31 .net
アーキテクトの例として既存オープンソース製品のローカライズをあげる馬鹿w
全言語に対応したオープンソース製品を構想することを例にあげるならわかるが。
167 :仕様書無しさん:2012/12/09(日) 21:39:53.04 .net
71 :仕様書無しさん:2012/11/25(日) 21:34:13.92 .net
23 :仕様書無しさん:2012/11/24(土) 20:13:09.94 .net
大手IT企業がプロジェクトマネージャのみを育成し続けた弊害では?
62 :仕様書無しさん:2012/11/25(日) 20:35:22.47 .net
>>59
それはアーキテクトの重要性をわかってない証拠だよ。
本来はアーキテクトという中間層が必要なのに、
その仕事をなくして、上と下に振り分けるから
めちゃくちゃなものが出来上がる
139 :仕様書無しさん:2012/11/30(金) 01:30:29.25 .net
コーディング技術が高いというのは
タイピングスピードが速いとか
誤字脱字が少ないとか
そういう話ですよ。
166 :仕様書無しさん:2012/12/09(日) 21:36:32.60 .net
> 164
土台くらいは実際に動くものを提示しない限り設計が出来たとはいえないでしょ
机上だけで作った設計でほとんど問題が出ないなんてありえるか?
79 :仕様書無しさん:2012/11/25(日) 21:54:13.84 .net
>>75
必要スキルが羅列されているだけじゃん。
だから役割は何なの?って聞いているの。技術面のリーダーってことでいいの?
>>77
アーキテクチャとアーキテクトは違うでしょ。
アーキテクトはアーキテクチャを構想するってことでいいの?
121 :仕様書無しさん:2012/11/29(木) 00:12:24.93 .net
> フレームワークをどのように使えば効率的かというサンプルを作ったり、
> システム固有の実装を行なっている時に発生した問題点を解決するために
> プラグインを作ったり改造をしたり。
そんなことやってたらコーディングやってる暇ないわw
75 :仕様書無しさん:2012/11/25(日) 21:47:39.06 .net
78 :仕様書無しさん:2012/11/25(日) 21:53:53.81 .net
話を戻すと、コードを見て(普通マニュアルは整備されてない)
そこから設計を読み解く能力。
それはアーキテクトの力であり、
アーキテクトが存在しないと、個々のプログラマが
そーじゃない的なコードを量産することになる。
190 :仕様書無しさん:2012/12/10(月) 22:21:49.30 .net
わかってます。なんとかしなければいけないとわかってるんです。
しかし、わたしが何か技術的な問題と取り組んでいると、
阿呆なとんちきがやれ輸送の問題だ、やれ電話だなんだかだと、
つまらんことで私に決定を求めてくるんです。
21 :仕様書無しさん:2012/11/24(土) 19:19:10.15 .net
>>19
そういうのって、標準であるの知ってても、わざと自分で作ってるんだよ。
標準の機能って本当は作りやすいけど、難しいふりして2〜3日余分に工数掛けて
自分の給料を増やすのさ。
163 :仕様書無しさん:2012/12/09(日) 20:57:10.94 .net
この手のスレでは実装して形にする能力に関して不要
という極論を展開して粘着する奴が多い
実際にはモノが作れないから技術コンプレックス抱えてるんだろうなあ
技術者の肩書き外せば楽になれるのに
それとも何も出来ないからアーキテクトなんて肩書きが欲しいのかな
役職じゃなくて役割なんだから2ch来てまで社内政治すんなよ
186 :仕様書無しさん:2012/12/10(月) 20:33:43.14 .net
>>181
コードでしか書けないんだったら、アーキテクトやSEがコード書くことになるから、PG不要じゃない。
アホなの?
188 :仕様書無しさん:2012/12/10(月) 20:57:27.77 .net
>>186
職名がPGかSEかアーキテクトかは問題じゃない
プログラム書けないアホが不要ってことだ
お前のようにな
108 :仕様書無しさん:2012/11/28(水) 03:23:58.98 .net
> 設計書書いて、ミーティングで説明して、個々のプログラマのコードをレビューすればいい。
はい。だめ。「アーキテクト不在」というのはまさにこの状況。
個々のプログラマに任せても、まとまりのない無駄が多いものが出来上がるだけ。
コーディングルール、フレームワークの使い方、テストの仕組み。
モジュールの連携、デザインパターン。
それらを組み合わせて統一した基盤を作らないといけない。
考えるだけじゃダメ、選ぶだけじゃダメ。実用に耐えうるレベルの実装例を
作り上げないといけない。実用に耐えうるかどうかは作らないと判断できない。
個々のプログラマをレビューしてもダメ。統一した基準ができていないのなら
どうすべきかなんて判断できない。それにレビューには時間がかかる。
> 設計に関する責任を引き受けるんだから、
> コーディングしてる暇なんてそうそうないよ。夢をみるのはやめよう。
それはコーディングをするアーキテクト専任がいないってことだろ。
つまり「アーキテクト不在」ってことだろ。
だから日本は海外に負けてる。
そりゃそうだ。アーキテクトがないのだから
効率が良い開発ができるわけがない。
47 :仕様書無しさん:2012/11/25(日) 15:40:22.34 .net
>>46
それはアーキテクトの仕事じゃない。SEの仕事。
14 :仕様書無しさん:2012/11/24(土) 15:21:00.13 .net
>>11
俺はコード見ればだいたい分かる。
でもそれはやっぱり20年以上もプログラミングやってるからだろうな。
(言っとくが10歳からやってるって意味だぞw)
仕事で見るコードはたいがい設計意図が
感じられないただの手続きの流れで疲れる。
確かにこれでうごいてる。でもそうじゃねーだろ。
そんなのばかり。
12 :仕様書無しさん:2012/11/24(土) 12:09:54.62 .net
8 :仕様書無しさん:2012/11/23(金) 21:42:52.45 .net
>>6
そうですね。自分の使っている言語の
有名なフレームワーク。これをよく調べることです。
ライブラリだとアークテキチャがない(ただの関数の集まり)
もしくはほんの少ししか無いみたいなものがたくさんありますが
フレームワークにアーキテクチャが存在しないことはまず無いですからね。
使ってみるのはもちろん、なぜそのような実装になっているのか
できればソースコードまで見て見ることをおすすめします。
それが無理でもファイルの置き場所、クラスの分け方を見てみるだけでも
十分参考になりますよ。
漠然と見るのではなく、なぜそのようになっているのか、
その理由を考えてみるといいでしょう。
112 :仕様書無しさん:2012/11/28(水) 08:44:08.38 .net
>>110
> コーディングを個々のプログラマに任せなかったら、誰がコーディングするんだ?
> もしかして、アーキテクト(が全てコーディングするの?
あほかw
基盤をコーディングする人と、その基盤を使ってコーディングする人は
コーディングの内容が違う。
それがわからないから「アーキテクト不在」になるんだよ。
> で、そういうことやってたらコーディングしてる暇はないと言ってる。
だから設計書を書く人と別に
アーキテクトに分けるんじゃないかw
一人でやろうとするから、暇がなくなるんだよ?
153 :仕様書無しさん:2012/12/01(土) 09:23:42.51 .net
83 :仕様書無しさん:2012/11/25(日) 22:09:56.12 .net
>>82
OK。アーキテクトは技術リーダーということだな。
176 :仕様書無しさん:2012/12/10(月) 00:31:46.40 .net
>>175
その考えたことは実装したらちゃんと動くの?
それが問題の根本だろ?
118 :仕様書無しさん:2012/11/28(水) 15:54:53.32 .net
>>103 >>108
手持ちのプログラマーでコーディングできない時は、アーキテクト自らコーディングするさ。
でも通常は、自分ではコーディングせずに、プログラマーにコーディングさせてるよ。
特に>>108
前半に書いてることは正しいんだよ。
でも結論となる最後の5行が間違ってるよ。
アーキテクトは、他の人がコーディングできない場合で無い限りは、自分ではコーディングしないよ。
66 :仕様書無しさん:2012/11/25(日) 20:53:09.15 .net
一人がプログラミング担当なら別だけど、
普通は複数人のプログラマがいる。
それぞれが勝手にコード書いてると
無駄がたくさん生まれる。だからまとめ役が必要。
ここでまとめ役がコード書かない人だと、
現場では使いづらいだけの意味不明なルールができる。
ルールだけならまだしも、変なオレオレライブラリを使えと強要したり
使うフレームワークだけ決めて、その使い方は個々に任せたり。
実際に自分がやらないからその悪さも理解できないだろうな。
だから実際にコードを書いてる現場の人間に近いレイヤーに
まとめ役が必要。それがアーキテクト。
アーキテクトが優秀だと開発の無駄が大きく削減される。
仕様の変更にも柔軟に対応できたり、バグが減ったり開発期間が減ったり。
システム開発で一番重要な仕事だよ。
157 :仕様書無しさん:2012/12/01(土) 13:58:02.67 .net
アーキテクトの仕事だと主張してる内容は一般的なSEの仕事で、
さらにそれはPGが行うものだと言ってるからややこしくなってる。
33 :仕様書無しさん:2012/11/25(日) 01:01:03.28 .net
コードを書かずに絵?だけ書いて、ベストの設計に持っていけるのって
ワールドクラスのアーキテクトでも無理だと思うが?
204 :仕様書無しさん:2012/12/13(木) 02:01:32.80 .net
>>203
ゲームに限らずだけどある一定の規模を超えるアプリは一人では作れない。
ゲームのエンドユーザー視点で仕様 ”だけ” が決まっているとする。
つまりWorld of Warcraft のパクリを作ると考えればいい。
その時、10人の開発者に仕事を割り振るとしよう。
お前は○○のキャラクター、お前は○○のステージ。みたいに。
これだけで作れると思うだろうか?
作れるわけないね。個々のプログラマが自分の好きな方法で作ったとしても
それらを組み合わせることはできない。統一した開発方針が必要になる。
ゲーム用フレームワークを選べば組み合わせられるという人がいるかもしれないが
それはわかってない人。フレームワークは汎用的に作られているからいろんな使い方ができる。
だから使い方を決めないといけない。
フレームワークの使い方を決めるということは必然的にそのフレームワークが
搭載されている機能を実際に使って(コード書いて)判断しないといけない。
もちろんフレームワークの使い方だけじゃない。コーディング規約や社内ライブラリの管理や
テストなんかも統一した開発方針で決めるべきこと。実際の作業はプログラマにやらせるかもしれないが
最終的にレビューして決定するのはアーキテクト。だから上級プログラマとしての能力が必要になる。
6 :仕様書無しさん:2012/11/23(金) 14:34:18.91 .net
アーキテクトの>>1さんが押えておくべきツボを実例を交えて講釈なさると聞いて
3 :仕様書無しさん:2012/11/23(金) 13:16:19.88 .net
違法派遣(事前面接、偽装請負、多重派遣)の告訴状(刑事告訴)の受理後の示談交渉について
会社への通達
会社には「告訴した犯罪者本人か犯罪者個人が雇った弁護士としか話はしない」と釘をさしましょう。
話し合いを持ちたいと犯罪者個人から打診(示談交渉)
交渉は基本受身で、犯罪者を許す気はないが話だけは聞きましょうという姿勢で臨みましょう。
被害者からお金の額を提示するのは絶対しないようにしましょう。犯罪者側は
いくら欲しいですかと聞いてくるでしょうが、応えてはいけません。満足する金額を提示するまで、「話は分かりました、しかしまだあなたを
許す気にはなれません」と伝えましょう。※お金を要求しなければ恐喝の成立はありません。
犯罪者側も被害者を怒らせた場合は、最悪感情論から告訴を継続させるという
事態を危惧するでしょうから、犯罪者側の心理は不安な状態にあるはずです。
意に沿わぬ和解案には強い態度で自信を示して退けましょう。
満足する和解案の提示
被害者の想定する、犯罪者の払える最大限の金額まで達したら、「そこまで反省するなら、許して告訴を取り下げ
てもよいです。入金が確認された後に取り下げます」といえばいいでしょう。
和解金の想定上限は犯罪者個人の年収の半分程度が良いでしょう。ユーザー、元請の社長や、
下請でも創業者の場合の年収÷2は、数千万〜数億円、外注・人事担当役員、
外注担当の部長やマネージャーであれば500〜1000万円、営業個人については
200〜500万円程度でしょう。
和解時の念書(同意書)
和解時には該当事案について犯罪者・被害者双方が秘守契約を結ぶことになるでしょう。
犯罪者側が被害者について誹謗中傷をしたり、被害者の個人情報、告訴事案について第3者
(他社)と通謀するような事態が発覚した場合の、賠償金をあらかじめ念書に記入するよう
にしてください。賠償金額は和解金額の2倍程度に設定すると良いでしょう。犯罪者側も
和解金を払った事実と事案について第3者に通謀しないように求めてきますが、内容が社会通念に
著しく反するような性質でなければ応じましょう。和解金が支払われるということは
双方が「和解」することを指しますから、お互い後腐れないよう合意をする必要があります。
127 :仕様書無しさん:2012/11/29(木) 16:14:03.30 .net
>>120
サンプル作るのは、大きなプロジェクトだとそれ専用のプログラマが居るのよ。
もちろん、「アーキテクト」や上級SEがどんなサンプル作れ、ってその先行開発担当PGに指示するんだけどな。
その先行開発担当PGがフレームワークの問題とかを潰して、一般PGが簡単にプログラミングできるように道を作ってやるんだよ。
データベースの設計なんかは、アーキテクトは噛まないよ。
DBのチューナーがするよ。
たまにDBに造詣の深いアーキテクトが居たりすると、アーキテクト自ら手を出す場合もあるけれど、そういう場合でもアーキテクトとしての仕事、DBチューナーとしての仕事とは明確に区別されてるよ。
16 :仕様書無しさん:2012/11/24(土) 16:34:44.66 .net
レスを投稿する(名前省略可)