ソフトウエア開発のどこまでを設計と呼ぶか？

仕様書に書いてないことは、ＰＧが自分で読み取ったり、
デザインなどもＰＧが考えるなど、ＰＧの力量にかかってるんじゃないか？

詳しくは >>2

私には，現役でソフトウエア開発をしていたころから抱いている疑問
がある。それは「ソフトウエア開発にとって，どこまでが設計なのか？」
ということだ。その疑問は，エンジニアから記者に転職し，さまざまなSE
やプログラマを取材するようになって，ますます深まるようになった。

　一般にビジネス・アプリケーションのソフトウエア開発は，設計工程と
製造（コーディング）工程に分かれる。ソフトウエア開発者は，設計者
（主にSE）とプログラマとに分類され，設計者が書いた「仕様書（設計書
）」にしたがってプログラマがコーディングする。仕様書にはさまざまな
様式がある。オリジナルなものから，DFD(data flow diagram)，ERD（ent
ity-relationship diagram），最近ではUML(unified modeling language)
を使う場合もあるだろう。つまり設計とは「設計者が仕様書を書き上げ，
プログラマに渡すまで」ということになる。

　確かに，複雑なソフトウエアの仕様を，できるだけ単純なモデルで表現
することの重要性は認める。しかし，本当に仕様書だけで，ソフトウエア
を作ることができるだろうか。少なくとも筆者は，「仕様書だけですべて
のコードが自動生成できた」という話を聞いたことがない。そんなことが
可能なCASE（computer aided software engineering）ツールもまだ開発
されてはいない。

　プログラマは仕様書を読んで，その“行間”を読みとり，設計工程では
予見できなかったコーディング上の問題を解決する必要がある。それが現
実だ。特に最近のように技術革新のスピードが速いと，自動コード生成技
術より人間のほうが変化に対応しやすい。しかしその分，仕様書がいい加
減だったり，あるいはプログラマの能力が未熟だったりすると，必要な機
能やパフォーマンスを備えていないソフトウエアができてしまう。

　これは，他のエンジニアリングの世界とソフトウエア開発が大きく違う
点だ。例えば工業製品であれば仕様書（設計図）は絶対であり，それさえ
あれば，同じような製造設備を持ったメーカーなら同じモノを作り上げる
ことができる（もちろん例外はある）。これに対しソフトウエア開発の製
造工程はプログラマの能力に依存する。仕様書の内容と完成したソフトウ
エアが違っている，ということも少なくない。つまり仕様書というのは，
設計図としての役割を果たしていない，ということになる。

　仕様書の完成度が低い原因はどこにあるのだろうか。たんに，ソフトウ
エア開発における要件定義や仕様書作成のノウハウがまだ成熟していない
ためなのだろうか。

　筆者は最近，問題は仕様書の中身ではなく，むしろ，設計工程の捉え方
そのものが間違っているせいではないか，と考え始めている。そのキッカ
ケになったのが，米国のソフトウエア技術者Martin Fowler氏の論文「The
New Methodology」だ。氏はこの中で「ソフトウエア開発はすべてがデザ
イン（設計）であり，製造工程に相当するのはコンパイラとリンカーを動
かしているときだけ」と述べている。また「ソースコードこそ仕様書（設
計図）。コーディング作業までを設計ととらえるべき」と主張している。

　この考え方は，従来の，設計者/プログラマという関係を根底から見直
す視点のように筆者には思える。というのも，多くのプログラマは単純労
働者として扱われ，どんなに苦労してコーディングしても正当な評価を受
けにくいからだ。実際，「プログラマより設計者のほうが優秀」というイ
メージが，ソフトウエア業界にはある。かつて筆者は上司に「上流設計だ
けやれ。もうプログラムは作るな」と言われたことがある。設計者になる
のがキャリアパスであり，プログラマは外注すればいいという発想からだ。

　プログラマが設計者になるための通過点に過ぎないのであれば，真剣に
仕事をする気にはなれない。優秀なプログラマは育ちにくいだろう。設計
者とプログラマの力関係もプログラマが不利なままだろう。モラルハザー
ドやソフトウエア品質の低下という最近話題にされる問題は，実はこのあ
たりにも原因があるように筆者には思える。

　

8ゲット

9ｹﾞｯﾂ!!

ｯｼﾞｬ10ｹﾞﾛ

まぁ、最近の言語はリアル言語に近くなってきてるから読もうと思えば読める。
けど、それは、コーディングスタイルが、高度に統制が取られている場合においてのみ、
言えることであって、そこらの3流プログラマが a だの b だのを多用する
アッセンブラライクなプログラムを組めば一気に破綻するので、必ずしも
真とは言えない。
UMLのような物が重宝されるのは、高度にスタイルが確立されていて、
それが汎用性があるからに他ならない。

コーディングまでを設計ととらえ直すことは，硬直した現在のソフトウ
エア開発を変えるキッカケになるかもしれない。ち密な仕様書を作ること
よりも，いかに優れたコードを作るかに視点が変わるからだ。

　プログラマが単純労働者なんてとんでもない。プログラマこそ，ソフト
ウエアを完成させる“真の設計者”と考えるべきだ。これからは，この視
点に立って，人材育成や開発スタイル，プロジェクト管理など，ソフトウ
エア開発のさまざまな問題に取り組むべきではないだろうか。

>>1
こんなお馬鹿さんが板とは、そもそも設計というモノはシステムの
設計図（どのようなシステムを作るかを決める）を書くのが
ＳＥの役目ですよ。

ＰＧの役目というのは、設計図に示してあるものを、いろいろな方法を
用いて実現するのが役目

まぁ、SEが言語の技術を持っていて、「あそこはこうコーディングすれば作れるな」
と思って仕様を決めてれば、問題はないね。
もし、そうではなくて、「最新のE言語は素晴らしいから出来ないわけがない」
という発想で仕様を決めれば、デスマ確実。というか、殆ど破綻。

SE→グランドデザイン(政治寄り)
PG→製図(実務寄り)

でどうか？

コンセプトも含めて、しっかりしたグランドデザインがあれば製図が楽しく
なりそうな気がする。

むしろ、
SE→製図
PG→加工
ではないかと。

SE→製図がダメダメ（寸法線がない、意味不明）
↓
PG→( ﾟДﾟ)ｺﾞﾗｧ!

SEが中途半端に製図に口出ししてくるからおかしくなる。SEはグランドデザインに
徹するべきだと思う。

グランドデザインはリサーチやコンセプトの確立だけでも多大な時間がかかる。
これと合わせて製図までこなすことは多分ムリ。
製図は実装技術を前提に行うものだから、実装技術がものすごい速さで革新されて
いく今日ではグランドデザインと製図を同時にこなすことは難しいと思う。

>>1
システム設計だのプログラム設計だの、の区別も付けられずに
よくそこまで語れますね。

というか。
プログラミングは余程の馬鹿じゃなければできる。
特別な機材もいらいない。
だから建築業に喩えると、設計事務所の人が
現場の土方の作業までやれてしまう。
あまりにもレベルの低い土方だと、いくら説明
してもできないから、建築家が自分でやった方が
早いと思ってしまう。
まぁ、ある意味正しいんだけど（汗

私の思う最近の構図は

営業　　　　　　　　仕事がないか足を使う
営業サポートＳＥ　　営業を技術的にサポートする

コンサルタント　　　業務改善が必要な時に入る
　　　　　　　　　　
上級設計　　　　　　グランドデザイン
　　　　　　　　　　機能仕様書を作成する

下流設計　　　　　　詳細設計

ＰＧ　　　　　　　　その他大勢
　　　　　　　　　　最近は海外の人

PGは職人だから、腕の差がはっきり出る。
知っている技の数で、成果物の出来が違う。

>>1
純粋に工業的な「製造」の概念をソフトウエア開発に当てはめると、

設計 <-> コーディング
図面 <-> ソース
製造 <-> バイナリ作成

となる事は元々明白。
今更何を言っているんだ？

という>>23はプログラミング以外の経験無しでしょ？

>>21
>プログラミングは余程の馬鹿じゃなければできる。

普通、工業の世界では、

「余程の馬鹿じゃなければできる＝機械化できる」

と解釈しますが・・・

「プログラミングの機械化」って正直、非現実的だとは思わんか？

馬鹿SEが書いてくる拙い設計書だけで物はできないよ。
１ページに矛盾したことを平気で書いてくるし。（W
なんとか辻褄があうように解釈するのはプログラマの仕事。

PGの腕の差で成果物にどのような差がでるのか詳細希望！
煽りじゃないよ。

>>27
例

１．顧客から営業に注文が来る。
    「会話能力を持つAIを作ってくれ」
営業はこの要求をそのままＳＥに垂れ流す。

２．ＳＥが分析・設計を行う。結果は以下の通り。
    「話を聞く」
    「話をする」
    「考える」
その後、適当に納期を決めて、各機能（？）をＰＧに垂れ流す。
勿論、実装の詳細には関わらない。「それはコーダのやる仕事」

３．各ＰＧが必死になって世界中の AI についての研究結果の調査を行い
（場合によっては自分で開発）、たまたま個人の能力が高ければ完成するが、
そうでなければ・・・

新聞用語では、ソースコードを「プログラムの設計図にあたるもの」と解説している
から、コーディングまでは設計工程に含めてよいのではないかと思われ。
(実装工程はリンクとコンパイルのみ)

>>28
俺なら、仕様書見た瞬間に挫折するわ

>>28
ＳＥの仕事はもーちょい奥まったところまでやるもんだと思ってますが、
最近は違うですか？（ドキドキちう）

いや、口開けて待っているだけのPGも多いぞ。その場合はSEが
営業とPGの間に挟まれることも。

まぁ、>>28に対する最適解は、人工無能のソースを手に入れて改造する何だろうな。
これ、PG SE関係ないね。
むしろ、PG以外、SE要らないって感じ？
営業、プロマネSE居れば良いみたいな。

>>31
「奥まった、奥まっていない」は、所詮程度の問題に過ぎない。
ポイントとなるのはＳＥが作成した仕様書に基づいて
「 "機械的に" 実装ができるかどうか」

この違い、計算機に携わっている者なら分かるだろ？

>>34
そこまでやれるＳＥは真にＳＥだね。
そういうＳＥと仕事したいなぁ。ｗ

視点を変えるとＳＥの腕の悪さはＰＧに降りかかる、ということでもあるね。

経験的に、本当にできるソフトハウスってのは、
・SEが居ない
という事なのかもね。

逆に、SEが居るという事は、いい加減な設計をやる可能性がある。

>>36
なんか誤解を生みそうな表現なので確認するけど、
それって言い換えれば「PG兼SEしかいない」ってことだよね？

>>35
>そこまでやれるＳＥは真にＳＥだね。
しかし、その仕様書に基づいて「"機械的に" 実装ができる」ならば、
その仕様書自体がプログラミング言語になり得る筈。

SEのしとが、PGのしとに「この機能は○○で実現できる？」と
確認を入れているのを見たことがない。

やばい？　やばい？

むしろそれは良い方ではないかと。

そのそもいつからソフトウェアの開発に「設計」なんて言葉
使うようになった？

ＳＥからの反論が全く無いな（ｗ

ソフトウェア開発における設計工程の位置づけって、
製造業における研究部門の商品開発の相当するのは
自明だろ。

>>25
私の言いたかったのは、詳細設計がきちんと
できてれば
「プログラミングだけなら誰でもできる。」
でふ。

しかし、日本だと分離が上手にできないから
いい加減な詳細設計がＰＧに渡される。
ＰＧは、実質的には詳細設計、最悪の場合は
機能設計までしないといけない。
土方が各々勝手に解釈をして物を作っているような
状態だから、現状の惨憺たる状況になっていると
思われ。

そのうちWeb画面の設計のように、ビジネス
ロジック側も詳細設計すれば自動的にプログラム
が作成されるようになるんじゃないかな。

>>44
馬鹿だな、全ては雇用対策なんだよ。

>>43
誰に対する反論だ？

これだけでは >>1 の意見に同意しているのか、反論しているのか
分からんぞ？

今の世の中、新規でプログラム作成するような
件案ってあんのかいね？
いつも、途中から参加するとか、バージョンアップとか
カスタマイズだから、結構ずるずるに・・・・。

新規でやったらやったで、プロトタイプモデルから作るから
やっぱずるずる・・・・。

>>45
藁。

それを言っちゃあ、おしまいだよ。

>>45
つまり、会社の経営者側が
実質の設計・開発の役割を担っている人に
「お前らは所詮土方の人間だ」と
思わせる為に「ＳＥ」「ＰＧ」の
区分けを作った、という事か？

>>45
なるほど！
目から鱗が落ちた気分です！（ヲイ

仕様書というより開発指示書だよ。
プログラマにとっての仕様書というのは。
開発指示書を書けるやつがエースプログラマというわけだ。

>>1は>>2以降で名前欄に1で書きこんでいる。
その内容は記事の転載で（私は読んだことがある）、転載元を書いていない。
>>2以降のを1が書いたと思っている人がいるのではないか？

まさか記事を書いた本人ではあるまいな。

>>45
ひとりできることをふたりでやる。これが重要なんだろ。

ペアプログラミングも雇用対策だったのか！ｗ

>>1の記事をまとめると、SEの仕事は用件定義まででいいってことだよな。
おれもすげーそう思うよ。わけわからん設計までするからSEの人数が無駄に多いんだよ。

ＰＧがＳＥやれ。

>>56

実際あんまりそれやると設計・コーディングあたりと時期的に重なる対顧客での説明、
あれこれの調整、調査、資料作成とかで酷いことになると思うよ。

うちの会社は、SEのうえにESE(エキスパートSE)ってのがいるけど。

SEは勇者。PGは戦士。

だいたいシステムエンジニアっていう名前が変だよ。
PGもシステムを作ってるんだから、システムエンジニアじゃないか。

営業屋
ドキュメント屋
フレームワーク屋
マネージメント屋
プログラミング屋
テスト屋

SEとPGだけに分けるから無理がある。

>>61
いいね。
普段は別な部署で専門知識を磨きながら、必要に応じて離合集散を行うわけだな。
ドリームチーム結成とか。

うちはＳＥの上にＳＳＥ（シニアＳＥ）つーのが居る。>>58

手抜き設計をしているSEは一度中国人PGに造らせて見ろ。

>>64
おいらはそれをしてぼろぼろになりました。
やっぱ仕様を理解していないとプログラムは作れませんな。

>58
うちの会社は、ESEの更にうえにSESE(スーパーエキスパートSE)ってのがいるけど。(嘘)

ハード屋がプログラム仕様決めるからｎ転ｓ転する。いつも。間にＳＥ置け
ってしょっちゅう言ってるが通じず、ＰＧの工数ｲﾊﾟｰｲかかる。
ま、俺が貰うんだからいいけど。

詳細設計から自動的にプログラムを生成…
今のコンパイラがやってくれてるじゃん。既に。

もちろん、出荷後のクレームまでが設計です。
仕事が切れないようにするのが仕事です。

明確なバグを作りこんで工程を確保するのも設計ですかやっぱり。

明確じゃバレちゃうじゃん。微妙に仕様らしく見えるように仕込まなきゃ。

バグってゆうより、後で機能追加したくなるような
仕様にしておくのがミソ(w

>>72
ほんとは１ステップで出来る処理をわざわざ遠回りにして３ステップぐらい
にしてみたりとか？(w

面接とか営業の連中の感覚ってどんなんだろ。
基本設計だ、詳細設計だ、顧客と交渉したことあるか、だの。
そんなものはっきりした線引きなんてねーよ。
作ってみせて「やっぱこうして」なんてのざらだし。

>>72
そしてその機能追加が容易な造りにしてくれるのが優秀な PG。

プログラムはソフトウェアの設計図ですから、プログラマはすべからく設計者です。
プログラム（設計図）をコンパイラがビルド（建築）するのです。
だからプログラマは土方ではないのです。

>>76
ところが、設計図を清書するだけのトレーサー風情が
設計者を名乗る事が多いという実情があります。

向上心の無い奴は馬鹿だ。by夏目そうせき＠こころ

ろっぽんぞー

1step-->3stepだと水増しがバレるが、1step-->関数１個ぐらいにすると
設計らしく見えてバレにくい。

（＾＾）

あぼーん

区別できん

>>82
ｶﾞｯ!!

設計と、コーディングを混同してる？

SEは歯医者だよ。
プログラマは歯科技工士だよ。

そもそもこの業界は設計書の定義が曖昧。本来、設計書とはそれさえあれば後は機械的な作業で
自動化できるくらいの厳密なものでなくてはならない。
でもソフトウェア業界の設計書とはそこまで厳密だろうか？そうでは無い筈だ。
そこまでいったらコードになってしまう。それなら最初からコーディングしたほうがいい。
従って私はプログラム仕様書など書いたことが無い。ゆえにコーディングまでが設計と私は
認識している。

>>87
素人ですか？

SEの書くのは設計書じゃないよ。だだの　指　示　書。
建築に例える人いるけど、建築の設計書見た事あるの？
SEの書いた指示書とは比較にならんほど詳しいよ。

俺の持論はソフトウェア開発とはレストンランでの注文料理

　客
　↓
ウエイター
　客の要望を聞いてそれをシェフに伝える。
　↓
シェフ
　ウエイターから得た情報を元にレシピを考える。
　料理を作る。

　客
　↓
　SE
　客の要望を聞いてそれをPGに伝える。
　↓
　PG
　SEから得た情報を元にコーディング。
　ソフトを作る。

業務系の(一応)ＳＥ(のつもり)です。
僕の場合、設計書にＳＱＬ文に書いちゃいますが、これは書きすぎ？
ジョイン一個で処理に大きな差がでてしまうようなことを、ＰＧのセンスに
任せられないし、下手な文章を書くより分かり易いと思っています。
でも設計書を書くより作っちゃった方が早いと思う事も良く在ります。

>>90
書きすぎだと思います。SQLはなるべく一発で+サブクエリは使うなと言っとけば
大概PGに伝わるでしょう。
あとはXPでも謳っている｢ペアプログラミング｣と｢共同所有権｣を実践していれば
細かい設計書なんて不要だと思いますよ。

>89 の書き方では「だからSEなんていらん」と言いたそうに感じるかもしれんが、そういうつもり
じゃないよ。

人数(規模)が少ない(小さい)ならウエイター(SE)の役割はそれ程無いかもしれん。
しかし、人数が増えた(規模が大きくなった)時、ウエイター(SE)は重要になってくる。

いかに客の要望を聞きだして、まとめて、シェフ(PG)に伝えるか。
必要なら図も書くし、シェフ(PG)に指示も出すだろう。
「この料理(機能)は後回しでいいから、先にこっちの料理(機能)を出して」とかね。

そもそもソフトウェア開発を流れ作業的に考えるのが間違いなんだよ。

コース料理作ってる時に、いきなり次の料理の肉が嫌いだから魚にしろ、
とか言われて、当惑しない料理人はいないよなぁ。
もう焼いてしまった魚を、煮直して出すはめになって、まずいと言われてしまうのは、
そりゃ客が悪いし料理人も悪いし、
でも一番悪いのはそういう客のわがままを許すウェイターだと思うな。

ウェイターには料理の知識が要るんだよ。
頼むよ、ちゃんと分かってくれよ、料理の実態を。

>>21
漏れの思う開発プロセス構造
まあ、なんて言うか常識なんですが…（w

1.コンサルテーション【コンサルタント】
顧客の要望を分析し文章化する。深い業務知識、コミュニケーション力を必要とする。

2.営業活動【営業】
商談をまとめ受注に結びつける、言わばプロデューサー。

3.工数・費用見積もり【プレSE】

4.プロジェクト管理【プロジェクト・マネージャー(PM、プロジェクトリーダー:PLとも言う)】
開発プロジェクトを全ての面において管理する。
プロジェクトの成否は、ここに懸かっていると言っても過言でない。

5.仕様書作成【SE】
案件定義から仕様書(外部・内部)を作成する。

6.SEサポート【テクニカルエンジニア（技術リーダー）】
実際にプログラムを担当する事が多い。
現場のSEをサポートする役。

7.プログラミング【プログラマ】
仕様書を実際にプログラムに翻訳する。
SEとの相性、技術力によって品質が変わる。

8.テスト【テスター】
プログラマ、SE(?)も動員して行う場合が多い。

9.ユーザ教育【インストラクター】
SEが行う場合がある。結構疲れる他、バグが出たら笑えない。

10.保守管理【保守管理SE】


どこが設計かは5-6辺りだと思う。
プロジェクトが小さいと役割を兼ねる場合が多いけどね。

あぼーん

中身はともかく　おもしろい

DB設計って、どこもクソなんですか？
まともに正規化されてるの見たことないんですが。

>99
まともなところは　ＥＲＤでバシッとやってある　そうでないところは
それなりに...

いちばん腹がつには　ＤＢ設計がくそなのを知らずに作るＳＥ
ちゃんとＤＢ設計すれば　最小限のコーデイングですむのに
それと　正規化以前に項目の名称が変なやつはこまる
仕様書みないとテーブルの結合の仕方がわからんのは
ＤＢ設計がＸ　

>101
Ｘ いちばん腹がつには　ＤＢ設計がくそなのを知らずに作るＳＥ
○ いちばん腹が立つのは　ＤＢ設計がくそなのを知らずに作るＳＥ

>>94
常識といいつつ　プレSE　とか　テクニカルエンジニア(技術リーダ)　とか俺用語使ってるけど、
あんた細かく分けすぎ(w

>>103
SE → テクエンジニア → PGの辺りを明確にしたかったのネ(w
>>1が「PGも設計をしている」、と言うのは>>1がテクエンジニア
とプログラマの同じ立場にいたからではないかと言う意味を含めて
細かくしたのよ。

あと、>>21のコン猿の役割の誤解を言いたかった。
俺用語でスマソ。しかし漏れの会社で「プレSE」は普通用語。
テクニカルエンジニアとは言わないけど(これが一般だとｵﾓﾀ)
技術リーダーは普通用語。技術リーダーの××さん…とか。

>>94

> 1.コンサルテーション【コンサルタント】
顧客の要望を分析し文章化する。深い業務知識、コミュニケーション力を必要とする。

これはSEだな。
コンサルは客の問題点や改善点を指導するもんだろ。
客の要望聞くのはSE。

> 3.工数・費用見積もり【プレSE】

なにこれ？プレSE？初めて聞いた

> 4プロジェクト管理【プロジェクト・マネージャー(PM、プロジェクトリーダー:PLとも言う)】
開発プロジェクトを全ての面において管理する。
プロジェクトの成否は、ここに懸かっていると言っても過言でない。

装飾しすぎ。わざわざ「全ての面において」とか「成否は、ここに懸かっている」ってつける程でもない。
メンバーの尻をたたくしか能の無いくそマネジャーでも、良いメンバーに恵まれたばかりにプロジェクト
が成功する場合もけっこうある。

つづき

> 5.仕様書作成【SE】
案件定義から仕様書(外部・内部)を作成する。

仕様書に外部とか内部とかあるんか？
例えばこんなの？
外部へは：「仕様では操作デバイスはキーボードのみです。」
内部へは：「キーボードとマウスでの操作を受ける事」
なんか外部設計(インタフェース設計)、詳細設計と勘違いして無い？

> 6 SEサポート【テクニカルエンジニア（技術リーダー）】
実際にプログラムを担当する事が多い。
現場のSEをサポートする役。

テクニカルエンジニア ＝ 技術リーダー？

現場のSEをサポートするってのは、要するに現場の人が働きやすくすることだな。
で、そういうのって普通プロジェクトマネージャ(リーダ)の仕事だぞ。
マネージャの仕事はいかにメンバーのやる気を引き出すか　だから。
デマルコ本とか読んでる？

更につづき(改行多いってERRORになるもんで)

> 7.プログラミング【プログラマ】
仕様書を実際にプログラムに翻訳する。

設計書じゃなくて仕様書を元に作業するわけ？


> どこが設計かは5-6辺りだと思う。

アウトプットが設計書じゃないのに(仕様書なのに)、設計してるってどういうこと？
なんか、設計書と仕様書がごっちゃになってるぞ。


長文スマソ

>>105 なにこれ？プレSE？初めて聞いた

プチSEとかもあるかもな(w

やっぱりどこの会社もほとんどがウォータフォールモデルから
抜け切れていないのか？

XPやRUP流開発がナカナカできないのか？

make 実行させている十数秒が製造工程で、それ以外は設計工程である。

上流とか下流とか意識しているようじゃダメだね。

設計はプログラマ全員が関わり、全員が全体像を理解してなきゃいけない。

>110
＞全員が全体像を理解してなきゃいけない。
ＤＢモデリングはそれがいえる　

>>110がいいこといった。
設計はSEのみでプログラマはコーダでもやっていればいい
とかいってるどこかの経営者はDQNということでよろしゅう？

>>105
指摘蟻が�d。
設計書・仕様書、確かにごっちゃになっていた。
仕様書＝設計書と同義にして下さい。(漏れは同義だと思うんだけど…意見求む)

>>コンサル
客の要望をSEが聞くのはヒヤリングと言うよ。
でもコンサルテーションとは別物。
中小規模のプロジェクトではSEがコンサルを兼ねるけど。

>>プレSE
プレSEは正式な名称っす。

>>PM・PL
プロジェクトの成否を分ける要因のトップにスケジュールがあるんで…。
でも確かに誇張ですた。

>>外・内
上流設計、下流設計に訂正します。

>>SEサポート
SEを”技術的に”サポートする役目と言う意味でした。
マネージャーの役割はメンバーのモチベーション管理もあるけど
それだけちゃうでしょ。
人・物・金・スケジュールを動かすのがマネージャーでしょ？

>>109
XP開発は大規模開発に向かないという特徴があるんで、WFモデルと
簡単に入れ替えるのは無理でつ。

>>114

大規模な場合はまたいろいろとテクニックが要るだろうが、（どんな agail プロセスだったとしても）

漏れのリアルな実感を言うと、まずそれを大規模にする必要があんのかと
考え直したほうがいいと思うことが多々あり。

>>115
そこは政治だと思うのネ…。
仕事が無きゃ、システム屋は飯が食えねぇから…(w

なんだよね。同意。

やっぱりRUPや反復型開発よりもXPのほうがとっつきやすいのか。
RUPや反復型開発実践しているところって少なそうだ。

ソフトウェア開発って工学っつうより、政治学、社会学なんだねぇ。

>110
＞全員が全体像を理解してなきゃいけない。

全体像を理解させるために、どんな文書書いていますか？

ソフトウェア開発っていうよりは、リーマンだからそうなんだってことで。

>>120 思い出したくもない

>>120
プロジェクト全員には無理だろうけど、
数人の「キーマン」には業務を理解して貰うように現場に行って貰う。

「百聞は一見にしかず」だよ。
現場の仕事をやるんじゃなくて、見て／聞いて／考える(提案する) な。

>>103-105
プレSEはたぶん日立方言。
受注活動までのSE。

>>113
>>プレSEは正式な名称っす。
方言だって！　情報処理の小論文で使わないように。

現実
―――SE――――＋――PG――――――――――――――――――――――――
要求定義→設計書→詳細設計→調査→詳細設計・・・→製造→テスト→ドキュメント
　　　　　　　　　　　　　（設計書の尻拭い）

>>124
プレSE=プレセールスSE
方言なのか？普通に使われてないか？
もう小論文を書く機会は無いかもな。アプリケーションエンジニア試験受けるぐらいか？

>>125
恐ろしくPGの守備範囲が広いな。
昔の受託の時を思い出す。

>126
> 恐ろしくPGの守備範囲が広いな。
そうだな　でも　javaの統合環境はこのぐらいサポートしている
ＵＭＬと　コーディングの連動　　　自動テストＵＮＩＴなど、など

>>127
+整備されたフレームワーク

よって開発スケジュールは短くなり、仕様変更は重なり
デスマ率は高くなると(w
UnitTestも限界はあるし。

〜SEってのは全部方言。
日本ではPG,SEしか一般的ではない。

要求定義→製造→テスト→ドキュメント→調査→設計書→詳細設計

クライアントとの打ち合わせ、要求定義、クライアントとの仕様書確認。
これが設計だ。

>>131

設計書を書かなくても設計なんだ。(´・∀・`)へー

あぼーん

>>130
反復型が無いぞ！


要求定義　→　製造　→　テスト
　　↑　　　　　　　　　　　　　↓
　　↑　　　　　　　　　　　　　ドキュメント
　　↑　　　　　　　　　　　　　↓
詳細設計　←　設計書　←　調査

俺の会社のSEはクライアントとの打ち合わせにプログラマも必ず同席させたあとに「全てはソースコードの中に真実が隠されてるから後は宜しく」といってそのまま消える。

http://monsan.zero-yen.com/File/ATHLETE2-04.jpg

おまえら、動作概念も考えずにいきなりコーディングですか？
デッドロックのセマフォ作ったりしないでね。

>>137
動作概念考えてもいなくてどうやってコーディングをせよ、小一時間(ry

紙におこすか否かってことなら、メモやアイディアのまとめたものとかは書く。
提出するきちんとした書類はある程度動いてからだな。

デッドロックについては、おまいの書く紙には *概念* 程度なのに共有リソースの排他制御までもいちいち書くの？
普通、概念程度じゃ共有リソースは排他制御されるものとして書くんじゃないか？

>138
リソース系に関しては　ＥＲ図渡せばＯＫの場合もある
それ見てわからんＰＧは　あほ　

脳内開発最強。

設計段階でもコード書いたりしない？
UML書くよりラクだし。

>141
書かない　新人ＰＧ向けならＳＱＬを記述したり　あとからチェツクいれる
時はある

なんつーか、とりあえず「ピープルウェア」↓を読めということでＦＡ？
http://www.amazon.co.jp/exec/obidos/ASIN/4822281108/qid=1053498727/br=3-1/br_lfncs_b_1/250-8256372-0857824

うちの会社では詳細設計はプログラマの役割になってる。
新人ならともかく2〜3年以上のキャリアを持つプログラマには
それくらいさせないと技術者として金をもらう資格ないと思う。

ちなみに漏れの上司は人によって仕事の範囲を調整してる。
漏れは職階的にはＰＧだけど機能設計に近いところまでさせてもらってる。
任せて不安な香具師にはある程度丁寧に仕様書を作ってやっている。

結局よいＳＥってのは自分がやる部分と他人に任せる部分をうまく調整できる
人間のことだと思う。ただ、その見極めをうまくやるためにはＳＥでもＰＧとして
の能力は当然必須。ＰＧの経験がなければよいＳＥにはなれないと上司は
力説している。

>>144

今時、SEとかPGとか分けて考えてるって(以下ry

あぼーん

>145
進め方では明確にわかれる　外注ー＞ＰＧ　それ以外ＳＥ　涙

現実
――営業――――+―――――――――漏れ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
「〜なやつ作れ」 要求定義→設計書→詳細設計→調査→詳細設計・・・→製造→テスト→ドキュメント→PCパーツ選定→組み立て→OSインスコ→セットアップ→現地設定→説明会→メンテナンス
　　　　　　　　　　　　　（設計書の尻拭い）

だめだった・・1024じゃ足らん・・。

結局、どっかの工程で全部吸収してくれる人材がいないとプロジェクトは成功しないんだよな。
それがプログラミングをする設計者だったり設計のわかるプログラマだったり。
生産性のある香具師ばかりのプロジェクトなんてのはありえん

>>148
ああ、漏れにも経験あるよソレ…案の定デスマになりますた。
もう思い出したくもないYO…

>147
最近の方がSEとPGの役割が明確に分かれるケースが多いと思う。

>148,151
ガンガレ

>149
俺もある。まさか一度も改行せずにデータを入れるなんて考えてなかったからな（w

>150
吸収している分には良いが、飽和してきたらデスマだな(経験あり)

うちの会社、営業とプログラマーしかいないんだけど・・・
SEなんかほんとに必要なのか?

昔メーカーに勤めていたからわかるけど
機械の図面は仕様書じゃなくてコードそのものの複雑さで
もちろん、部長クラスでも図面をつついて、
工場の現場、下請けの問題を解決しに行って製品作っていたよ
指示出すだけの人なんか100人規模のチームで一人いれば全然十分
ソフトに転職してホント驚いたよ

コードを書かないSEなんか紛い物以外の何物でもない

そもそもこの業界はまがい物によってソフトの需要を喚起している

あぼーん

>>153
その通りだねぇ・・・コードかけないＳＥに限って仕切りも下手なんだよな

>>153
プログラムが解ってないSEはDQNだが、プログラムを書ける(書く)必要はないと思う。
そもそもプログラム解らない香具師を見たこと無い。
しかし元々SEとPGは違う島だろ。
SEは設計のプロで、PGはプログラム言語のプロなんじゃねーの？

まあ、アホなSEが多いって点は同意。

ＰＧでも営業でもないＳＥは寄生虫。

言語特性の機微を知らずして設計のプロか。
脳内天気は晴れ模様だな。

>>120

理解させるのに文章は要らない。口頭での「コミュニケーション」が重要。
ホワイトボードも好まれる。（メモ代わりとして）

SEの議論って、まずSEとは何かってところから場所によって全然違うから成り立ちづらい。
さらに、場所によって要る能力が違うから善対悪の議論が難しい。

SE「俺、プログラムってわかんないから」

現実として、プロジェクトＸに出てくるようなものを作ってる奴は
３０，４０歳だろうが第一線で設計から実装、実験まで全部やってんだよね。

>>159
>言語特性の機微を知らずして
それプログラム解ってないって。
言語特性を知っていることはSEの基本だろ。

じゃあOOP分かってないのにJava案件の仕様書いてる低能は
＄ヨ未満ってことか。納得だ。

SEとPGを分野で分別したとき。
SEの仕事を知らないPG、PGの仕事を知らないSEが直接接点を持ってるのが問題。
SEが上流工程(全体に影響のある部分)をやるので当然、SEはPGの知識を持つ必要がある。
しかし、それが新卒無知でいきなりSEとして配属されてPGの仕事を知らずにSEをし続ける
もんだからロクな文書ができてこない。
んでこういうスレができあがる。ってことやね。

あぼーん

>>157=プログラムを書いたことのないＳＥ。
こういう奴の下で働くのって大変。
大手ＳＩやコンサルの若手ってこんなんだよね

日本で SE/PGの分類が必要な理由は　たった一つだ。

ソースが基本的に英語だから設計書の代わりにならない為だ。

>>169
ソースが設計書と言うやつとは仕事したくない。
こーゆーやつは、引継ぎの際、「わからないことはあとで聞いて」で済ましやがる。
引継ぎ直後にスグに問題に対応できないと「つかえない」って思われるのはこっちなのに。

詳細設計書とかプログラミング設計書とかいわれてる奴は不要だな。
ドキュメントの量だけ増えて意味がない。
ソースを日本語に一生懸命直して喜んでる馬鹿が多数いる

>>170
ああ、おれもそういう会社で仕事したことあるよ。

そこに残っていた過去のPGの食べ残しったらひどいものだった。
機械語コードに近いソースコード・・・

そこにいたSEどもは仕様が頭の中に入ってるせいかかなり脳天気。
途中で参加した人間の身になれ・・・
Ａ「仕様？このソースコード見てよ〜！」
漏「はい〜」
しばらくしたのち・・・
漏「あのぉ・・・ここってこれで良いんですか？まずくない？」
Ａ「ん〜・・・さぁ？このソースまだ中途半端だからね・・・」
漏（あ゛？）
Ａ「あのソース見てみてよ」
漏「あのソースって何？」
Ａ「あれ？知らないの？（笑」
漏（所在も分からんソースを知ってたまるか・・・）

>>171
はぁ。完全にプログラミングしかしたことねーやつだな。
客が読める仕様書を客に渡すってことは、「仕様書に書いてないことは実装されてません」
ってのを証明する道具になんだよ。
そのうえ、客（責任者）は仕様書を少なくとも一度は目を通すから少しは
話が通りやすいんだよ！

>>172
そうそう。
開発当初にいたやつはスグに溶け込めても、後続になればなるほど習得に
時間を要するようになっちまう。
開発初期段階からしっかり資料を残してくれないとホント悲惨。

>>171
小規模であれば詳細設計書は要らないかもしれないが、
システムの規模が、中、大規模になってくると、そうは問屋が卸さないよ

ソースが日本語なら、それだけは不要になってもよさそうに思うな

”ソフトウエア開発のどこまでを設計と呼ぶか”がスレタイだろ。
プログラムソースは、設計書也。ゆえにソースコードを書く行為は設計也。
又はプログラムソースは、設計書に有らず。ゆえにソースコードを書く行為は設計じゃ無い。
で終了じゃないか。設計書がいるか要らないか、なんて言ってないと思うが。

ここでの問題は>>2以降で指摘していることで、実行コード（機械語コードのことね）が製造物のときソースコードは原材料か、
それとも製造の設計書かってことで、それがどっちなのか考えると、俺は設計書だと思うね。
なぜならソースコードが原材料なら、別に設計書があるはずだが、それはどこにも無い。まさかコンパイルスイッチが設計書じゃ変だろ。
まったく同じコンパイルスイッチ＝設計書でも、無限の組み合わせの材料を入れると、異なる機能をもつ製造物が無限にできる。より
単純な材料と、無限の組み合わせの設計書＝ソースコードで、異なる機能をもつ製造物が無限にできる。の方が材料と設計の定義にあってる。
それならソースコードは製造の為の設計書で、それらを作ることを設計と呼ぶのは理にかなっている。
従って”プログラムソースは、設計書也。ゆえにソースコードを書く行為は設計也。”

但しソースコードはコンピュータ用の設計書だから、人間にわかりにくいかもしれない。しかし訓練でわかる人間も要るかもしれない。

そろそろ
　詳細設計書＝ソースコードで
　上位設計書は　指定した設計書様式通り書かないといけなくて
　詳細設計書との相互ハイパーテキストになっていて、どちらを修正しても修正が反映されるような

そういう高級言語が出てもよさそうなもんだな


それじゃ日本語COBOLか

>>170 引継ぎの際、「わからないことはあとで聞いて」で済ましやがる。

それを許してるおまいもDQN
許して無いならおまいは(・∀・)ｲｲ

>>173 客が読める仕様書を客に渡すってことは

おまい日本語読めないのか？
それともおまいの脳内では仕様書と設計書とごちゃまぜになってるのか？

きっと、本や雑誌に書いてること鵜呑みにして、
ソースコードを丸ごと日本語に翻訳したような物を一生懸命作って、
それを仕様書だと悦に浸ってる馬鹿が多数入るんだろうな。
インターフェースだけ書いてりゃ十分なのに。
自分のやってることを疑いもしないんだよな、そういう奴らって

ドキュメントをなんでも作ればいいと思ってる奴らって、
仕様変更があったときのドキュメントの修正コストのことまで考えが及ばないんだよな。
んで、プログラムとドキュメントの内容に喰い違いが出てきて混乱すると。
そういう現場がいっぱいあったけど、結局ソースコード追わないと安心できないことになる。
ほんと、アホかと思うよ

あぼーん

ソースプログラムとテストプログラム。
それに加え、上記2点だけではわかりえないものをドキュメント化したものを
まとめて設計書と呼ぶ、みたいな？

おまいら、　ミﾟДﾟ,,彡　←こんな奴に、「XP勉強しなさい」って言われまつよ。

# 最近、懐疑編を読んだ。

>>185

まぁ開発手法も適材適所。

客が短納期を求めてきたらXP。
納期・機能より体裁を求めてきたらウォータフォール　でええんでない。

>>186

なんでもいいからリファクタリングする権利だけは欲しい。（リファクタリングさせてもらえないとストレスマジ溜まる）

>リファクタリングさせてもらえないとストレスマジ溜まる
おれも作ってる最中はリファクタリングしてぇ〜なんて思ってるが、
納品しちゃったらケロっと忘れる（ｗ

ちょっとしたリファクタリングのために、何が今まで悪くてどう改善したのか詳細に *文章*
書かされるときのムカツキ具合はたまらんですね。

（こんなことやってたらいつまでたっても完成しない）

>>189
おいらは、自分の腕も修正対象のモジュールの他の部分も全く信用して
いないので、ソース変更したら変更履歴は記録する。
後々わかればいいだけなので、なるべく簡単に済ますけど。

CVSやVSSが便利ですな。上司が使い方理解していないと、やたら無駄な
文章かかされるよね。それはスゴイ嫌というなら胴衣です。

ムカツクことをムカツクと捉えていたらますますストレスになるので、
こういう場合は「何も考えず流す」というのが正攻法らしい。

（ムカツいててもしょうがないってときは）そりゃそうだろうが、考えずに
いると、（転職のタイミングとか世間的な良心とか常識とか）決定的な
ところで間違えそうで怖い。


そうこう悩んでるうちに互いの人格を尊重して仕事する XP 的な精神を持った組織にあこがれてしまうんだな。

>>179
あのさ、新規分野の引継ぎでは「引き継いだことが全部」と判断せざるおえんだろ。

>>180
明確にわけてみろ。でかいシステムほど客に渡す文書は外から中まで渡すよ。（もちろんドキュメント料金もらうが）
俺は、インターフェースや機能、実現方法まで全部仕様書として客に確認をとるぞ。
おまえらと違って数億の金もらってっからな。簡単なミス（認識の違い）で膨大な修正になんだよ。
ま、てめーみたいにゴミプログラムを量産してる人間にはわからんだろうな。

巨大システムに携わってる奴と、小規模プログラム群を作ってる奴では環境が違うんだよ。

というか、明らかに嫌がらせ受けてるんですが・・・

>>192

重大なもんならそりゃそうだ。何百行ものLinuxのカーネルのパッチを何の文章もつけず
commit してくれっていっても、そりゃいかん。

状況によるのはよくわかるが、Agile にやっているってところでのうのうとドキュメント管理に
精を出す人にはならないでください。

設計？

なんちゃって企画と文書作成じゃないの？

なんちゃって企画提案とただの事務作業

コンパイルの直前まで、頭の中でクラスの構造を設計しながら
コード書いてますが何か？

ムカツク感覚をほどほどに感じつつ（でないと今度はこっちが加害者になる可能性も無いとは言い切れない）
気持ちよく仕事できる組織を探してみようかなと思う。探せば多分あるでしょう。

俺も少し前まで、プログラミング作業は、
工場の流れ作業や、大工みたいな仕事だと思ってた。

プログラミング作業が研究開発であれば、他の研究開発のように、
作っては壊し、作っては壊しの繰り返しで完成するものだと思える。

最初から、ウォータフォールでは無理だったってことだな。

ウォータフォールで上手くいくのは、未知の部分がなく後戻りのない、
単純なものか、すでに経験があるものだけだ。

まあ、俺はPGやめちゃったので、もういいけどな。
滝を逆戻りするキツイ開発手法が改まっていくといいな。
まあがんばれや。

>>197
それだめじゃね？（ｗ

仕様書から直接コンパイルできる言語「仕様書」を開発することが先決だな。

>>192

あんたのやってる事は設計じゃなくてドキュメント作成じゃないの？

>おまえらと違って数億の金もらってっからな。

ぜひ日本経済に貢献してください。

>簡単なミス（認識の違い）で膨大な修正

毎回そんな事してるとしたらバカ？
いや別に、わざと効率悪い事してそれで客から金取ってるぜ！ってならいいのだが。
それだと客に対して誠実じゃないね。

だからおまいらよ、仕様書から直接コンパイルできる言語をつくれば、仕様書作成とプログラミングに分ける必要はないと言ってるだろ！！

>>202
大規模なシステムの場合、照準が少しでも狂うと大きな損害になりやすいのは確か。
小規模の方は取りあえず狙ってみて、（プロトタイプとか）
外しても、それで照準を合わせる方法もありだけどね。

あと、小規模で取りあえず作ってみて、それを大規模に拡張していく
という手があるが、これもプロトタイプの前提条件を誤っていると
手直しが多々入り、作り直しと同じような状況に陥る場合もある。

>>203
そうだな。VB代わりに使えるような難易度で作れば、今なら流行するかもしれないな。
プラットフォームは Win32 と Linuxと .NET の３つでお願いね。

>>203　出来のいいＣＡＳＥツール使うだけじゃじゃだめなんか？

LINUX/W32/.NETに対応出来るって事で一番楽そうなのはDelphiにラップした日本語仕様書コンパイラだな。
VCLのインターフェース名にそれぞれ日本語を１対１対応させる機能つけてさ

えすえるというすとりんぐりすとをあたらしくつくる
えすえるをでりーとする
えすえるにもじれつ「せれくと　あすたりすく　ふろうむ　しょうひんますた」をついかする

仕様書を直接コンパイルできるつーことは、仕様書自体にソースコード
と同レベルの内容を記載して無いとできないだろ。
それじゃコーディングとおなじだっつーのｗ

ソースコードがドキュメントっていうのは昔は嫌われたもんだが、
言語の表現力が増した今となっては説得力がある。

　 ∧,,∧　　XMLでコメント
　ミ,,ﾟДﾟ彡　打てるのがデフォルトの
　ミつ日(ﾐ　.NETは、ちょっとすごいと思うた。

>>210
どんな言語でもDQNが使えばDQNの表現になる。
まるで、翻訳ソフトみたいに

>>210
DQNなソースコードみたことないのか？

変数名が btn009, btn010, btn011, ... となんの脈略の無い数字が続いている。
名前付け替えようと s/btn009/btnOK/g とかすると 300個ぐらい該当する。

コメント部分には、btn009をクリック とだけ書いてある・・・

一つのテーブルの仕様書があるが、二つのデータベースに存在して、
スキーマが微妙に違う。だけならまだしも用途も違うし、同じにしちゃ＊逝けない＊らしい。

同じグローバル変数を複数の用途で使ったりしてるんだお。
下手に置き換えするとむしろわけわからなくなりかねないんだお。
最悪だお！

>>213-214
>>212をみろ。所詮言語はツールに過ぎん。

>>203
それだったらJavaが結構いけるぞ。

ソースコード内にJavadocコメントを書く。
/** 沢村を叩く
* @param item 叩くもの
* @param count 沢村を叩く回数
* @exception SawamuraException
* @return 叩かれた沢村ののステータスを返す
*/
public Status attackSawamura(Item item, java.math.BigInteger count){
　//実装
}
これに、各packageがあるディレクトリ毎にpackahe.htmlを置いてそこにその
packageの概要を書く。packageのトップにoverview.htmlを置きドキュメント全体の概要を書く。
あとは、UMLを使ってMDA(Model Driven Architecture)をうまく使うなり
ユースケース図を描くなりシーケンス図を描くなりすることだな。

つまり、いまどきSEとPGを分けるべきだと言い張る経営者は怠け者DQN。
設計書も仕様書を書く仕事も殆どがプログラマ様の仕事だ。馬鹿な経営者は邪魔をするな。

>>206
沢村レスの後にUMLという言葉が一つも出なかったことが不思議なくらいだ。
XPを知っておきながらあれほど有名なUMLを皆知らないのか？

>>214
Javaはグローバル変数やポインタ演算の使用を禁止し
コンパイラがC++よりも厳格に厳しくチェックしてくれるので
DQNが少しはまともになる。
XMLも併用してApache antを使ってうまく処理すればすこしはまともになる。

■ここまでのあらすじ■
沢村があらわれてスレが混乱。愛と情熱のバラードが繰り広げられる。
結論：Javaと業界標準技術(UML,ant,HTML)を使えば解決する。
問題：約半数の馬鹿社員は、OOPもUMLも、それどころかHTMLさえ理解しないため、足手まといに…。

>>217
ホンの少しな．．．
DQNはポインタの演算はそもそも使わないし、
グローバル変数は１クラスにpublic変数を使えば同等の処理が行える。
いくら言語を変えても、人間の意識を変えないと駄目

コーディングの見た目が、読める仕様書っぽくなる言語ってのはおもしろいかも。

外見はワードみたいな感じで、

1章　動作環境＜--これはプログラムとしては無視される。
2章　画面構成＜--ここでVBみたいに画面が作れる。
3章　処理詳細＜--画面から呼び出されたコードを書く部分。
4章　データベース＜--フィールドの定義とか。
・・・

と、ここまで考えて、そんな制約の多そうな言語誰が使うんかと。

電気製品の回路図や、建築の設計図を「読める文章」にするのは無理だし、
余計難しくなる。

プログラミング言語は、これからも判りやすく発展していくだろうが、
ソースは回路図みたいなもので、仕様書は概要でしょ。

大規模プロジェクトの場合、設計をしっかりやるとかよく言うけど、
実際は概要を小規模のときよりよく考え、
やり直しを「なるべく」少なくなるようにするだけだね。

設計（SE）
小説家にあらすじを渡す編集者
コーディング（PG）
作家

設計（SE）
画家にラフスケッチを渡す人
コーディング（PG）
画家

設計（SE）
学者に研究するテーマを与える人
コーディング（PG）
学者

>>220
> 電気製品の回路図や、建築の設計図を「読める文章」にするのは無理だし、
最終的にはプログラム言語は文章ではなく、図になると思ってるのだが、
UMLとかは既に言語というよりかは図に近い。

>>222
UMLはよく知らないんだけど・・・

現状のUMLでコンパイルは無理でしょう？
また、UMLが細かい部分まで書けたとして、複雑化したらどうする？

図での設計が最終形態とは思えない。

僕は電気製品も建築も知らないが、
これらが図になっているのは、仕方なくそうなっているだけだと思う。

たとえば回路図のみ渡されて、それですぐに理解できるだろうか？
概要や使用しているロジックが資料になければ、ちょっと大きいのはもうだめかと。

ソフトウエアが文で設計できるのは利点だとおもうんだけど、どうでしょう。

>>223
一次元的な文字を眺めるより２次元、あるいは３次元的な
図を眺めたほうが左脳の代わりに右脳が働き読みやすいんではないかと思う。

UMLではコンパイル無理でもクラス図からソースコードを生成、
逆にソースコードからクラス図を生成することはできる(リバースエンジニアリング)。

UMLは回路図よりもわかりやすいんではないかと。
UMLはJavaとよくマッチしているのでJavaやっている人にはわかりやすいと思う。
UMLが複雑化した問題は以前から語られているようで、UML2.0ではそれを改善しようという動きがあるらしい。
いずれにしても図があったほうがわかりやすい。
特にひとつのファイルにつきひとつのクラスを書く手法では
各クラス間の関係を理解するのに結局図式化(リバースエンジニアリングとか)する。

複雑化の問題は、UMLだけでは解決できないのは確か。デザインパターンとかを学ぶしかない。

個人ならデザパタ採用くらい朝飯前だが、企業がそれをするには
SE/PG問わずの大規模な社員教育が必要になるわけで……しかも1,2回じゃ済まないし……。

ちと勇気が要るような気がする。

なんか微笑ましいスレだな・・・若いって言うか青いって言うか

>>226
なぜそうおもうのか理由を書いてほしいのだが。

PGが成長したらSEにならなきゃな。とウチの会社では言われるんだけど、みなさんのところではどうですか？
僕はエキスパートなPGを目指しているのですが。

それが判らんから若いと言われる。

>>227
> 複雑化の問題は、UMLだけでは解決できないのは確か。デザインパターンとかを学ぶしかない。

とか

> 個人ならデザパタ採用くらい朝飯前だが、企業がそれをするには

とか、なんか気恥ずかしくなってこない？

>>192,202,204
192のは客から聞いた仕様の文書化じゃないのかな。
大規模≒⇒メインフレーム⇒COBOLでは、仕様がコードレベルに入り込むことが多数ある。
DB:Aのa，Bのb，Cのcを使って、顧客業務のローカルルールで判定を行い、
該当者を帳票に出力する、とか。

こういう仕事ばかりやってると、仕様の文書化＝「すべての」設計内容の文書化、
すべての設計内容は文書化すべき、ということになってしまう。

@ITでもまだマシな議論が聞けそうだな…

>複雑化の問題は、UMLだけでは解決できないのは確か。デザインパターンとかを学ぶしかない。
確かにこれはハズい。

>個人ならデザパタ採用くらい朝飯前だが
これは実は自分はスーパハカーだと言いたいのかも知れない。

>>216
これにつけ忘れがあるが、Javaキーワードの一つ、throws宣言を追加すると
さらに仕様書作成作業の手間が減る。
何か問題が発生しても、コンパイラまたは実行プログラムが知らせてくれる。

throwsを書かなかった場合、起こりうる例外をいちいちコメント内に列挙するか、
何をしてはいけないかと列挙しないといけない。
その点、throws宣言をなくしたことでバグ探しに苦労する羽目になるC#は失敗したといえる。

> public Status attackSawamura(Item item, java.math.BigInteger count)
　throws Exception, SawamuraException, InterruptedException, IOException, FileNotFoundException {

さらに、報告書を作成するならJUnitをApache antで使用するといい。
<junit>タスクでテストレポートファイルをXMLで出力した後、
<junitreport>タスクで出力したXMLファイルをもとにレポートをHTML化して
Javadocのドキュメントにようにユニットテストの棒グラフ表示の見事な報告書を自動作成できる。


>>230
あのな、「UMLだけで解決できない」といったのはUMLを知っただけでは自分でどのように
クラスを設計できるか初心者には理解できないといったんだよ。
付け加えると、デザインパターンのほかに「分割し、統治せよ」の法則やKISS、
XP RUPなども学んだほうがいいな。

>>232
具体的になにがよくないのか説明しなさい。

デザインパターンだけでやれとは言わない。
もっと広義にいうならばパターンも使えとでも言っておくか。

> デザインパターンだけでやれとは言わない。

うーん・・・

> もっと広義にいうならばパターンも使えとでも言っておくか。

うーーーーん・・・

>>231
192じゃないけど、環境がちがうんだよ。
キングファイル(いまはPDFなんだが)が十数冊もできてしまうほどの規模の
システム作らないといけない人間と、数十ページの仕様書で済んでしまう環境とは。
要求仕様書、内部仕様書、外部仕様書これらは、ほとんど読まれることなく
倉庫に眠るがたいていの客は要求してくる。金払ってでも。
口約束より公文書の取り決めの重要度は認知しておくべきだよ。

裁判所にソースプログラム持っていって、効力あるとおもう？

まぁ、スレ違いだな。

思ったんだけどさ、そんなに文章が必要だったら

SE PG
要求仕様、設計 -> コード

よりも

PG SE
コード -> 要求仕様、設計したフリ

の順番の方がまだうまくいくと思うのだが

>>239
営業から全部やってみろ。

>>240
つまりSEのやることは殆どは、営業(契約書作成を含む)なんだよな。

契約だから、大量の文書が必要になるわけ。

でもさ、そんな役に立たないことしてるよりは
客とよりよい方法を考えることはできないんか？

> 客とよりよい方法を考えることはできないんか？
コンサル？

設計？

はぁ？
ただの事務やろ。

>>242
ほんとプログラミングだけだなぁ。ソースが仕様書でいいから。
そのよりよい方法ってのをたとえばでいいからあげてみてよ。

ＰＧ？

はぁ？
ただの翻訳やろ。

>>236
>>口約束より公文書の取り決めの重要度は認知しておくべきだよ。

なにか勘違いしているようなので補足。私は
231>>大規模≒⇒メインフレーム⇒COBOLでは、仕様がコードレベルに入り込むことが多数ある。
っていうのを見てる。累積ドキュメントも両開きキャビネット２面分ぐらいある。

こういう仕事で仕様を文書化する作業を「設計してる」と勘違いしてはいけない
というのが私の意見。コードに対応する文言を書いても「仕様の書き写し」なる場合もある。

「仕様＝合意事項」を文書化するのは重要。

んで、補足。

231>>こういう仕事ばかりやってると、仕様の文書化
　のことを
231>>「すべての」設計内容の文書化、
　のことだと勘違いしてしまい、
231>>すべての設計内容は文書化すべき、
　と考えるようになってしまう。

クラス，モジュールの依存関係など図にした方が良いものや、
設計全体を貫く設計思想なんかは、文書化してあると実装しやすい。
逆に処理，手続きなんかは、ソースで十分。
（仕様がコードレベルに入り込んでる場合は別）

>>246
翻訳してるのは、コンパイラですが何か？

>>247 「仕様＝合意事項」を文書化するのは重要
烈しく同意

頭悪いだろ？
仕様書なんか残したって仕様変更なんか簡単にするじゃないか。
何度も何度も何度も何度も同じ失敗ばっかりしてて、また同じ方法で同じ失敗をするの？
いい方法を教えろ、だ？はぁ？
他の方法を考えたこともない馬鹿に話したって無駄だろ？
違うか？
だいたい、いいやり方を聞いたところで
自分のやり方を変えられる柔軟性なんて欠片も残ってないグズのくせして俺に何意見してんだ？

現実世界でも同じ事が言えればいいね・・・

変更に耐えられないような作り方しかできないアマチュアさんの集うスレはココですか？

>>250
単純にしか考えられないバカな開発の上司持つと大変だな。

仕様変更のための仕様書ってのがあるんだけどね。
普通は。

変化を抱擁セヨ

ふふふ、実はもうちょいでいい方法の提案と一緒に
いま仕様書を書いてる奴の無能さを曝け出す計画進行中なのだ。
まあ何も変わらないだろうけど、
それをみて誰かが何かを考えてくれればそれでいいと思ってる。

>>250
管理職になるとコーディングの手間も仕様書作成の手間も忘れちゃうから。

>>257
ｦﾀ開発者が管理職になったﾑﾉｰ上司・・・

>>仕様書なんか残したって仕様変更なんか簡単にするじゃないか。
「変更だと証明」＝「金をとる」ために仕様書がいる。
客が善人ばかりなら、仕様書はリリース後のみの引渡しで良いと思うが。

プロトタイプをつくってイテレーションをしたとしても、
途中の変更点ではない箇所について、リリース間際，後に
「こんなのを作れとは言ってない」となったらこまる。

> 客とよりよい方法を考えることはできないんか？
これこそPGがやるべきだと思うんだよね。
少なくともPGが同席している場でやるべき
そうでないと非現実的な提案がまかり通ったり
双方にとって不効率なものが出来上がる

営業とPGで十分

>>260
> 営業とPGで十分
PGが顧客に対してちゃんと説明できればいいんだけどね
会社の面子は守ってくれよな

>>261
ＰＧに人間とのコミュニケーション能力を求める事自体が無謀。

結局は客がアホで不誠実であればあるほど
詳細な仕様書が必要であると

PG全員で客先に行く必要は無いだろ
コミュニケーションできるPGだけで決めればいい

ってそれを本来はSEって言うんだよな
引きこもりPGが奴隷になるのはいたし方が無いし
コード書けないSEは足手まとい

詳細で誰がみてもわかる仕様書だ。
よく読まないと間違ってとらえてしまうような複雑に書いてあるものはゴミだ。
客もわかりにくい仕様書をわたされたら
本人の目の前でゴミ箱に放りこんでくれればいいのに。笑

>>265
貴様が書いた設計書、目の前でゴミ箱に放りこんでやろうか？

これは馬鹿には理解できない服です。
・・・じゃない、仕様書です。

結局、仕様書には客を納得させる力なんて無いと考えないと駄目だよ。
それがどういうことかも考えなきゃ。
だいたい普通に考えて上の人が仕様書なんて読むかい？
また、変更が起きてしまうとき、仕様書は実質役に立つのかい？
お客さん相手に戦争よりはいい道が有りそうでしょ。
変更は何故起こって、どうしてうちの製品に客は満足してくれなかったのか？
その根本的な理由を探すことが新しい方法の第一歩でしょ。

>>268
＞変更が起きてしまうとき、仕様書は実質役に立つのかい？
保守経験のある俺から言わせてみると、仕様書は参考程度にしかならないね。
変更するときは、結局ソース解析するし。

>>268
仕様変更は不満足から発生すると決め付けてる時点で環境依存の方法になってしまう。
司法、運用方法の根本的変更etcによって発生するときもある。
仕様書は納得(理解)させるための物品じゃないってこと。
薬買うとくっついてくる、服薬説明書だって同じでしょ。誰もよまん。まぁ設計書とは別物だけど。
世の中には、必要性がなくても必要なものってのがあるってことよ。
お客さん相手に仕事なんてしてないよ。お金と戦争してんの。

>>269
自分にはそれでいいんじゃない？

＞自分にはそれでいいんじゃない？
意味がわからん。

>>271
自分以外もみる。ってことだろーよ。

設計書はいらないから安く上げてくれていう注文もあるし、
一概に設計書ありきとは言えないと思う。

でも、作るからには、仕様を決めていないと作れない。
設計書は書かなくても作るのに必要な情報はどこかに
記憶されてないと駄目だよね。

１．設計書の読者対象はどういう人か？
　　自分一人しか絶対見ないのであれば・・・
２．そのシステムがどういう経緯で開発されたか？
　　仕様を知る人が周りに居ない場合とかは大変
３．システムに整合性がとれているか？
　　命名規則とか、UIガイドラインが統一されていれば楽。
４．システムの重要度はどれくらいか？
　 広く関係者が仕様を知るべき必要性が違う。
５．システムにかける事のできるコストはどれくらいか？
　重要でないシステムの設計書を作る理由は？

分業は効率的　-　果たしてこの業界にもこの論理は通用するのか？

SEとプログラマが分業すること、設計と実装が乖離する事がそもそも日本は
ナンセンスな気がするんだが。概要を知らないプログラマ、実装の詳細を知らない
SE。で、ろくなものが出来ない、と。

デマルコ本とか読んでると(翻訳だけど)、システムエンジニアって出て来ないんだよね。
だいたいがプログラマとか開発者。あとは客と管理者。

もしかして、SEって日本だけの固有のもの？

>>273
なにがいいたいのかわけわかんね。

>>274
分業の仕方が悪いんでない？
どう考えても分けなくていいところで分けるから変なことになっちゃうんじゃね。
分業自体はやってかないとそれはそれで大変だし。

>>275
向こうはみんなプログラム組めるとか。笑

ＳＥってほとんどがプログラム組めないＤＱＮなの？

とにかく、設計書と、ソースが常に一致するような、相互ハイパーテキストのような仕掛けが欲しいな

設計書に手続き名を書き足したら自動的にソースを作ってくれて
逆に、ソースに手続き追加したら自動的に設計書に反映されて、
定数名とか定数値も変更したらそのまま相互に反映される　ツール

>275
日本固有のものでしょう。
あちらさんではチーフエンジニアとかアーキテクトとか
そんな肩書きでしょう。

日本のSEPG分業はそもそもCKSの大川がシステム開発に
土建屋的な手法を取り入れたからだと聞きます

CSKだろ・・・まあどっちにしても、派遣屋の売価アップネタって事だろな

欝氏

ソースコードだけでなくデザイン・スペックももっと
オープンにするべきだね。会社文化の中で閉じこもっていては駄目だ。

まったくだな。
特許も取れないようなソースを会社の技術だと思ってる馬鹿がまだいるからな。
そんなものにいい加減なんの価値もないことに気づけっつの。
誰が読むんだよ、そんな設計方針もマニュアルもねぇソース。

いいかげんなソースだということが分からないように
公開していないんだと思う。（仕様を満たす動きはする）

すごいよ。COBOLerが書いたC。保守がたいへん。
つうか、当時ソースレビューしてないだろ・・・
いや、レビュアーがCOBOLerだったのか・・・。

>>285
COBOLerが書いたJava見て、全部作り直しを指示しましたが何か？

SEでつ。
下請け探してもDQNなPGしか居ないんですが、
そんなPGでも使わなきゃｲｹﾅｲ場合、どこまで設計必要でつか？
コード級まで押さえるんならPGｲﾗﾈｰ(ノ｀⌒´)ノ ┫:・'.::・┻┻:・'.::・

どうやって探しているのかと。そもそもお前に見る目があるのかと。

結局、コーダー→設計もできるPG→コミュニケーションもとれるPG=SEを業界全体がしっかりとやって
ればこんなスレもたたなくてすむってこった。

安易に「結局」と言う言葉を使う奴は低脳だ。

個人的な感覚では、言語仕様に依存しないアルゴリズム作成まで、でしょうか。
成果物はドキュメントのこともありますし、ソースコードのコメントのことも
あると思います。

>>287
・基本的な処理方法
・コーディング標準

を説明した上でサンプルやひな形を提供すれば
コードレベルまで提供する必要はないかと思います。

信用がおけないのであればモジュール分割の方針を決めたところで
殴り書きの設計メモでもいいから書かせて簡単なレビューをすればいいかと。
もちろん、殴り書きのメモなのでコーディングが終われば残す必要もないですし。

コーディング標準については依頼者間で相互チェックすればなんとかなるかと。

ソースを隠せば技術は漏れないと思い込んで、コンパイル言語を信仰する馬鹿が多いのだろうか。
（そもそも特許取ってなきゃ、仕様推測されたり逆コンパイルされたりして、いつかはパクられるのだろうか。

コードに近いレベルまでおとしてやったとしても、
単体テストはそいつに任せられるから、それなりに無駄にはならないと思う。

>>291
言語仕様に依存しないアルゴリズム作成までに「設計」という単語を当てはめる
という意味だよね？

このスレの主旨は、「どこからが単純書き写し作業になるか」
ということ。

>>292
オブジェクト指向の「オ」くらいしか解ってない奴から提示されたモジュール分割は
あっさりこっそり破ります。そんな漏れは「オブジェク」くらいしか解ってないが。。

>>295
はい、そう言う意味です。

設計図通りに作るといっても、機械であればどのような道具を使うかとか、
どんな順番で作って組み立てるかというのは考える余地があって、
大量生産の一部分担当でもない限り単純作業にはならないと思います。

また、工業製品のような、同じ部品を大量生産するケースがほとんどない
ソフトウェア開発の場合は、「単純書き写し作業」はほとんどないと思います。
あるとすればその部分はＣＡＳＥに置き換え可能だと思います。

>>296
現実には提示されているものが技術的に良くないことはあると思います。

そう言う話はコーディングに着手する前にやってしまえば
手戻りが最小限になりますし、（上に対しても）教育効果もあります。

こっそりやって「もうテストしたものを直すんですか？」といって押し切るのは
可能だし、やる人はやる手なんですけど・・・

オブジェクト指向で組むなら全部それらしく組まないと。
Ｃ＋＋らしくないコーディングでも、一貫性があればそれなりに
わかりやすいですし。

　どこまでが設計云々じゃなくてコーディングの指導のお話だね。
オレはコーディングも設計の一部だという認識なので、
末端のプログラマが行うコーディング（設計）をどのように指導すれば
いいか、という風にこの問題をとらえることになる。

まあ実際どうやるかといったら>>292が書いてることくらいなんだろうけど。

家だって設計図だけでは完成しないのでは?
大工が細かい仕様を修正してるんじゃないの?
ロボットは設計図が読めないだろうし。

>>299 コーディングも設計の一部

そう、コーディングまでが設計なんだよな。
だけど、上の人間やDQN Sヨはそう考えてない人間がけっこういるってところに問題あるよなぁ。

>>300 家だって設計図だけでは完成しないのでは?

規模の大きな建築物だと、ミニチュア模型をつくったりもするな。


> 大工が細かい仕様を修正してるんじゃないの?

仕様にないことやって不良建築作ったりはしてるようだけど。

元建築家の経験から。親父が大工。
「設計したものと１００％同じ物ができたためしなし。」
建築家ってのは、図面とか工学の知識だけ施工はしないししたこともない。
大工は、図面の読解と施工のみ、工学の知識はない(ある人もいる)。

建築家から言わせれば「建築工学わかんねーなら設計どおり作れ」
大工から言わせれば「設計は理想論。現実をみろ」

>>303
まぁ顧客が金払うわけだし。
顧客は理想を押し通してくるのは至極当然だし。

>>303
うーん、その構図がSE, PGにも当てはまる。

しかし、SE, PGの現実はもっと悲惨
・図面や工学の知識すら無いのに建築家面をする。
・図面を読解ができなくて、てきとーに施行し、
　バグだらけのプログラムを作ってしまう。

あぼーん

まともなＰＧにとってプログラム設計書ほど無意味なもんはないなー。

顧客にとってPGの言うことほど無意味なもんはないなー。

ＰＧの言う事は大事だろう

顧客にとってＰＧの職人意識ほど無意味なもんないなー。
動いて、やすけりゃーいい。

>>309
一人のPG能力の限界を越えた要求された程度で、
私の言っていることは、「大事です」って言っても説得力もないよ。

☆-(ノﾟДﾟ)八(ﾟДﾟ　)ノ突然男性機能が裏切りだす

http://www.kenmon.net/
↑
これってアリ？

それでも「大事」な時だってあるさ

それでも設計書が「大事」な時だってあるさ

>>311
日本語勉強しましょう。説得力ないよ

>>311

は？
おまいはそのPGの能力超えた要求出しておいて、それでもそのPGを使うの？
そりゃその部分の品質がダメダメになるに決まってるだろうが(w

ＰＧの能力というが、客にそんなものを識別する能力があるわけなし。

>>318

>310では「限界を越えた要求された程度で、 私の言っていることは、「大事です」って言っても」
と なんらかの否定的意見を匂わせてるんだから、それから判断できないならおとなしくPGの
言うこと聞いとけよ(藁

>>319
いや。ＳＥ＞ＰＧが世の中の一般人公式だから、ＳＥが言ってくれないといや。

ところでプロジェクトリーダってのは、SE・PGとはまた別のいるの？＞ALL

>>321
まぁ一般企業でゆう課長クラスでは?

>>322
ITでも課長は課長でいるでしょうに。

少なくとも全体を概観できるERD&DFDは欲しいところだ。それとテーブル
定義書はもう少し内容を詳しく書け。そしたら個々の処理の仕様書は
ざらっとでいいよ。

あとは定型処理をフレームワーク化して個々の処理のコードを可能な限り
最小化すれば詳細な設計書も不要になるんだがなあ。

文句言う前に、実践して見せてください

>>324
フレームワークの思想がわかるような設計書もきぼんぬ。
フレームワークの挙動をドキュメント化して欲しい。
これがないプロジェクトがどんなに多いことか・・。

ドキュメントもいいが、例示と実証の為のプロトタイプ
（サンプルアプリケーション）の方が重要だと思う。
それがあればドキュメントはリファレンス程度で済むと思うよ。

>324
同意　いまどき　ＥＲＤ使わないのは　あほです　（予算の都合もあるけどさ）

>>326 担当してた人と話するかコードを読もう。こういうときは質問する側の能力が問われるところ

C++ で、クラス定義書くまでが設計。

>>329
そんなわけあるか馬鹿。
ひとりでやってろ。

>>331
んだと、この野郎！ぶっ飛ばされてぇのか？

>>332
痛てて、チンコ蹴るなよ！

>>333
＿＿＿　　　　ﾋﾞｼ!
￣￣　 ∧＿∧　ﾋﾟｼ!!　 ∧＿∧
￣￣　<丶｀∀´>　☆　（#）´Д｀）
ー　　ノ⌒つ　ﾉ⌒て〕☆ﾉ　#　 ⌒つ
　　 （　´　／￣￣　　／#　　　ﾉ´
　／ )　　）＿＿　　/　／＼　く
　〆　レ '￣　　　 レ´　　　し´
そりゃそりゃ

おまいら、あんまりわらかすなw

SEが無能なら、逆に提案してあげましょう。
高速なDBとは？使いやすいDBとは？といった提案をしてあげてください。
（もちろん、納得してもらった上で採用してもらいましょう。
あとで「勝手に設計を変えた」などと言われないためにも）

以後は、DB設計の工数も計上したらいいんです。
そうしないと、ずっとプログラマをすることになっちゃいます。

DBって何？
デブ？
高速なデブ？

>>336
そして、「バカ殿につく爺や」が増えていくのかも・・・

そういや学生時代の後輩に俊敏なデブがいたな〜。
明らかにデブなんだが、100�bを12秒台で走ってた。デブをあなどっちゃあイカンよ。

結局さー、
DQNなSEとDQNなPGを連れてきて仕事させようとしてる
超DQNなPMが元凶。(_´Д｀)

【PC版】Ever17-the out of infinity【大失敗作】
http://www2.bbspink.com/test/read.cgi/erog/1053601941/

おまいらよ、量子PCというのはな、量子重ね合わせの状態を使って並列計算を行うことができるPCのことよ。わかるか？。
おまいらよ、量子重ね合わせの状態とは何かわかるか？
まあくだいていえば、一台の車が右向きに走っている状態と左向きに走っている状態が同時に成立しているということよ。
だが、おれらが実際見ると、車は右向きか左向きかに固定して走ってるだろ？それは観測することによって、重ね合わせの状態のうちのひとつが固定するからよ。
おまいらよ、重ね合わせの状態のうちのひとつがどれに固定するかは、重ね合わせの係数によって決まるのよ。おまいらよ、重ね合わせの係数は複素数よ。複素数の勉強をしてみろ？
おまいらよ、量子PCでいう演算とは、この量子重ね合わせの状態を担う物理系に対して、パルス電波を与えることよ。
いままでのPCでは4bitで表現できる16の状態のうち一つについて1回づつ演算を行い、合計16回計算して16通りの結果を出力してたが、量子PCでは4bitで表現できる16の状態を同時に実現している重ねあわされた量子状態に対して1回の演算を行い、結果を出力するんだよ。
当然処理bit数が増えるほど、量子PCの威力は大きくなるわな。だから並列処理よ。
だが、おまいらよ、その演算結果を見ようとすると、重なり合った状態のうちの一つしか見れないだろ？
この問題を解決するものとしてShorのアルゴリズムというのがあるよ。
Shorのアルゴリズムは量子PCの教科書には必ず出てくる有名なアルゴリズムだから、見てみろ？
おまいらよ、このようにこれからのプログラムは量子の時代よ。
おまいらも量子に取り組んだらどうだ？量子でないプログラミングなんて意味ねーよ！

>>342 http://pcweb.mycom.co.jp/news/2003/01/01/05.html
ｺﾋﾟﾍﾟですか
そうですか・・・

ｺﾋﾟﾍﾟｶｺｲｲ！

あぼーん

>>334
なんかそれ可愛いな（笑）

1の言いたい事は

http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

じゃないのかな

ソフトウェアはＳＥなんぞいなくてもプログラマがしっかりしてれば完成する。
逆はありえない。
プログラム知識のないＳＥは、どう引っくり返ったっていいＳＥになれないのは当たり前。
正直、設計もコーディングもプログラマーたちがやれば、無謀な設計も生まれずいいものが出来る。
世の中のＳＥは勘違いしてるのが多いから困る。

>>348
プログラムは個人技でどうにかなるが、システムはチーム力がものをいう。
お前もプログラマという役割を勘違いしているな。

デマルコの本でも読んでみれ。

ＳＥはチームワークを乱す要因にしかならない。ゴミだ。

糞くだらない中間搾取のための伝言ゲームでしかないのに、
システムを構築していると勘違いしている糞。それがＳＥ。

第一、名前がださいよ。システムエンジニア

age

>>350
３冊とも（ピープルウェア、ゆとりの法則、デッドライン）読みましたが何か？

「何か？」←無意味な自己主張

「354」←無意味な自己主張を黙ってスルーできない狭量な人間

↑切れやすい目立ちたがり屋

ケンカはいけないよ！

356に同意。
「354」は無意味な自己主張を黙ってスルーできない狭量な人間
かつ、切れやすい目立ちたがり屋（無意味にageてるし）

カルシウム採れよ

353が暴走中。

「357」←仕切りたがり屋
「358」←スレ違いに燃料を投下する暇人
「359」←脳内妄想
「360」←実況中継する暇人

353=358=360
(・∀・)ｼﾞｻｸｼﾞｴｰﾝ!!

自作自演ですが何か？

>348
SEとプログラマを変に分けたりしない方がより良い物ができる、のほうが・・・

>>353
「デッドライン-101の法則-」はまあまあの小説。

工業製品と著作物との間で揺れ動く微妙な存在が
各工程の不明解さを招くのだが、ソースコード記述を著作活動
という観点から言えば、設計工程はソースを書き下ろす為の
プランニング作業だろな。

hage

あぼーん

>>365

まぁそうなんだろう。プランニングとは中々いいこという。

プランニングが目的になってはならない。

あぼーん

　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

作るだけがしたいっていう、ＰＧオタクもいると思われる。

そういうＰＧにプランニングを渡してコードを書いて貰って、
それを原材料にして納得のゆくように書き直したらいいものができそう。

自分は開発者の記憶力や気遣いに頼った設計書はどうかと思う。
設計書をきっちり仕上げてそれにそってテストをするのが筋だと思う。
逆に設計書に書いていないことは実装されないし
テストもしなくてもいいとさえ思う。

個人的には以下の手順をとりたいけど。無理か・・・。
�@設計者から開発者へ一定のレベルで設計書を引き渡す。
�A開発者・設計者間でコミュニケーションし、
実装が完全に出来るレベルに設計書を仕上げる。
この内容にも一定の基準を設ける。
�B�Aの設計書に基づき、開発・テストを行う。

XPじゃん

テスト

ゲームプログラミングに関していえば、

概要設計、詳細設計、コーディング、テストまでモジュール担当者が一人でやってるけどね。

日本のIT業界のレベルが低いと言われるのは、やはりSEとPGを分けているからではないかと。

ほとんど全部だ。もっと書くと
設計書作成は設計の準備工程
製造工程はインストール作業ぐらい

形だけの仕様書、バグだらけのソース書いてコメントに名前入れて悦に入っている
低脳なら知っている。頼むからやめてもらいたい。迷惑だ。

＞376
ゲームといっても規模はピンきりだろ。

一人でやってる＝分業が困難＝規模が小さいじゃないかと思えるんだが？

大体、概要設計の段階でタスク分割が発生したら、やっぱり全部一人でやるのか？

>>379
ゲームの場合、

プレイヤー担当、敵担当、システム担当、描画担当、サウンド担当などなど、
各モジュールごとにリードプログラマ１人を立てて、規模が大きい場合は、その下に何人かつく。
モジュールの調停と統合はメインプログラマが統括する。

って感じかな。

>>380
ふぅん。勉強になりますた。
「チーフプログラマチーム」とか「外科医チーム」に似ているんだね。

要件定義は設計じゃないとして、それ以降、コードを打ち始めるまでが設計。
コーディングっつたら頭の中にあるものを具象化する段階なので設計ではない。
コーディングしながら思考する奴は、設計ってことになるが、
そのやり方では品質が望めない。

コーディングレベルでしかわからんことあるっぺ。
ＳＱＬの書き方をちょいと変えただけでパフォーマンスが段違いな
結果が出たことがあるなんて大体な人が経験してんじゃないの？

経験豊富なプログラマが入ればいいけどさ、そうじゃない場合は自分で
ＳＱＬのチューニングだってしなけりゃならんわけじゃん。コーディング
も時間かければかけるほど質があがるってことを広くしってもらわねば。

とにかくコーダーとパンチャーを分けてみろ

>>382にほぼ同意。
プログラム設計書(もしあれば)作成完までは設計。
それ以降は設計ではないと言いたいところだが、後にテスト工程がある。
PCL,MCLの作成もやはり設計の範疇に入るのではないか？

それに、テスト→デバッグ→テストのループの中にもモジュールのVer管理等のややこしい問題にぶつかる。
納期が迫ってる中でその現場固有の事情に依存するやり方で仕切らないといけない。
ソフトの設計ではないが、工程そのものの設計が必要。

もし、これを設計でないと言われると納得できないものを感じる。

「>>382にほぼ同意。」
と書いたが、結果として同意してなかったね。ｽﾏｿ

>>385
それは設計に含めちゃ駄目だと思う。

「開発プロセスをどうするか」という問題。
品質を確保するための取り組み。

>>383
だから、そのレベルまでが設計ってことだろ。
キーパンチャーやってるとき以外。

>>342
ショアのアルゴリズムって因数分解をするアルゴリズムなんじゃ…

>>389
沢村にﾏｼﾞﾚｽｶｺｲｲ！

ERDって、何スか？
ttp://www.itmedia.co.jp/dict/os/kind/windows/kind/nt/service/03505.html
とは違うようですが…

>設計者が書いた「仕様書（設計書）」にしたがってプログラマがコーディングする。

したがって？
おおまかな仕様書→コーディング&設計
だな。どっちかっつーと設計書は後で清書する

おれらはコンパイラにわかる仕様書を書いてるんだよ!!!

SEより設計書より、
モジュール機能定義書をくれ！
設計6ヶ月、コーディン＋テスト1ヶ月というスケジュールを改めろ！
人をまとめてちゃんと意思伝達できるまとめ役を置け！
(というかSEっていうのはまとめ役のはずなんだが、、、
スケジュール表を見てケツを叩くしかしないアホがいる)

>SEより設計書より、
>モジュール機能定義書をくれ！
いらん

>設計6ヶ月、コーディン＋テスト1ヶ月というスケジュールを改めろ！
7ヶ月もあるのか。十分だろ？

>人をまとめてちゃんと意思伝達できるまとめ役を置け！
これは同意

>(というかSEっていうのはまとめ役のはずなんだが、、、
>スケジュール表を見てケツを叩くしかしないアホがいる)
叩かれないとやらないからだろ(w

SEとPGを分けて考えてみるが
例えばオーケストラ
いくら個人個人の演奏者がスペシャリストであってもそれだけではダメだろ？
また例えばソロリサイタルができるようなプレーヤーがいてもそれだけではダメだろ？

SEは．．．何に例えれば良いんだ？ 指揮者か．．．違うな、なんだろ？

>>396
シンバルの人じゃない？

>>396
SEは、口うるさい批評家。

SE は舞台監督

＞395
6ヶ月間コーディングするな、という状態で拘束だよ
しかも、モジュール機能定義書を書くことも許されない
せっかく設計期間が設けてあるのにもったいない

>>396
オケに演奏会を斡旋して上がりをピンはねするロクデナシ。

>>400
興味だけなんだけど、、コーディングするな、モジュール機能定義書も書くな
と言われて、400は6ヶ月間は何をして過ごすの？

>400
ぢゃ、お前は「墨汁飲めと言われたら飲むのか？」

＞402
設計書を書くふりをしながら寝て過ごす
6ヶ月で適当な設計書を書いたら、コーディングは後の人にお任せ　これ最強




いや、おれはそこまではしないけど、そういう人もいる

なんだ
能力がなくて設計書がかけません
てことか

>>404
400って、PGじゃないのか？

教えてください。
　今まではコーディングばかりをやっていたのですが、最近単体テスト仕様書
を書くようになりました。
　単体テスト仕様書作成は「設計」でしょうか？？

ご意見お聞かせください。
よろしくお願いいたします。

>>407
なんのためにそれを知りたいのか不明ですが、それは設計です。

ついでにコーディングより先にテストを作ると良いぞ
ってゆーか自動実行するテストを作るのだぞ

コーヂング後ならデバッグのおまけじゃないの

長年プログラマやってるが
未だに設計と実装がどう違うのか区別できん。

どう実装したか説明しろって言われるのと
設計を説明しろって言われたとき同じ答えになる…

>>411
アフォ

「各工程をなんと呼ぶか」なんてどうでもいい。
設計書が設計工程の成果として定義されていて、
「設計書を書くこと」が設計だと考えられているがそれは間違いだ
設計書は設計の表明に過ぎない。
ただし自然言語で書けば設計の全てを表明することは不可能だ。
設計の全てを表明することが出来るのは「コード」しかない。
コードは設計情報である

>>411
この仕事には実装工程なんか存在しないよ

>>413
おまいさんが言ってる「コード」ってのは
プログラム言語のことだろ？
世の中に存在する全てのプログラム言語は
自然言語のサブセットにすぎないってことを
知らないのか？

>>414
違うね。
「言語」と同一名で呼ばれていたとしても、
自然言語とプログラム言語は、同一のカテゴリのなかに共に存在する事物では無い。
仮に「プログラム言語が自然言語のサブセットだ」という命題が正しいとしても、
コンパイルできる自然言語が存在しない以上、この命題はこの話題にとって何の意味もない

実装工程も存在するし、実装仕様も存在する。
実装仕様をとうとうと語られても、聞くほうはたまらないということだ。

設計ってさ、「why? what?」が記述の中心で
実装って、「how」だよね

>>417
「why? what?」は、分析。
技術知識要らない。

＞技術知識要らない

（ ´,_ゝ`）

モジュール分割までだろ

ユニット・テストにパスするまで。

リサイクルあげ