仕様書、設計書について

1 ：11/11/26 〜 最終レス ：12/05/04

外部だの内部だの基本だの詳細だの…
曖昧な基準で書かれた、いろいろな名前で呼ばれてて
「これってどうなの？」「意味あるの？」といった物に出くわす事も少なくない
しかし、純粋にプログラミングだけをして食べていくことは、昨今じゃ難しく
避けて通れない、否が応でも作る機会に出くわしてしまう、そんなドキュメントたち
設計書や仕様書についても、マ視点で語ろうぜ
・自分のなかでの仕様書/設計書の呼び方と分け方
・成功談、失敗談
・仕様書/設計書は何を使って作成する？(Word/Excel/HTML/手書き！)
・仕様書/設計書に含める図の作成方法や使っているツール紹介
・炎上プロジェクトでみた(よくない意味で)素晴らしい仕様書/設計書
・そもそも仕様書/設計書って本当に必要なの？
・こんな仕様書/設計書は、ぶっちゃけアリ？ナシ？
などなど、設計書にまつわる話題を募集

2 ：

関連スレ
【その２】Excelで仕様書を作る会社の奴の数→
http://hibari.2ch.net/test/read.cgi/prog/1177362668/
DBAがテーブルの仕様の説明資料作らんのだが
http://hibari.2ch.net/test/read.cgi/prog/1318690907/
仕様書の書き方
http://hibari.2ch.net/test/read.cgi/prog/1191806449/
仕様書とか意味あるの？
http://hibari.2ch.net/test/read.cgi/prog/1267241758/
(´･ω･｀)仕様書ぶち！
http://hibari.2ch.net/test/read.cgi/prog/1195826467/
設計書を作ってるせいで生産性落ちてないか？
http://hibari.2ch.net/test/read.cgi/prog/1169735232/
詳細設計をしても逆にコーディングしにくくなるだけ
http://hibari.2ch.net/test/read.cgi/prog/1280647235/

3 ：

投げっぱなしもあれなので
・俺の中の定義
外部設計==基本設計、内部設計==詳細設計
プログラム設計はソースコードで代用できるため不要
外部設計/基本設計
　UIやエンドユーザーが意識するレベルでのI/O、やりたい事などを纏めた資料
　理由があって意図的に制限する場合を除いて、実装方針の変更には影響のしないレベルの情報
内部設計/詳細設計
　入出力の詳細や分岐条件、メッセージ、処理順序など並べた
　フローチャートのような分岐やループなど、コーディング上で表現する方法が複数あるような
　意味のない情報は「明記してはいけない」
プログラム設計
　2重管理になるだけで無駄なので、ソースコードが全て
　javadocやXMLドキュメントコメント、コード内のコメントなど、コードでは表現できない情報
　クラス図などコードより抽出できる情報

4 ：

・実際の運用
外部設計/基本設計、内部設計/詳細設計
　箇条書きの要件定義、またはループや分岐を書いたフローチャート
　外部/基本設計が詳しい場合、内部/詳細は内容のコピペか焼き直し
　内部/詳細の修正でも必ず外部/基本設計が修正される
プログラム設計
　そんなの作ってる余裕なんてないです＞＜；
　コピペが何割かを占めるコードだけが絶対でありそれコメント(そもそもない)含めて他は不要
---
正直マ暦はあんまり長くはないのだけれど、これって普通のことなのかな…？

5 ：

ちなみに作るのに使うのは基本的にExcelです。
もちろん方眼紙です。
図はオブジェクトたち。
たまーにWordもありますが、終盤はファイルがいくつか見事にぶち壊されてます。
レビュアーが意図してる「仕様書」が何かを察することが、うまくやるコツなのかなって
最近思うようになってきました。書きたくない、じゃ通らないですし…。

6 ：

ソースコードは設計書だと考えるべし。
設計はなるべくコードとして書くべし。
コードから自動生成できるたぐいの情報は、
別にドキュメントにまとめる必要はない。
仕様書はソースコードにコメントとして書くべし。
またはテストとして書くべし。
Excel、他形式のドキュメントはたたき台としての意味はあるが、
最終的にはソースコードに全て記述するべし。
別の形式として見たければ、ソースコードから変換すべし。

7 ：

ケースバイケース
以上終了

8 ：

結局ある程度の実装経験がないと設計なんて出来ないよ
でも、設計から入れ実装は後だっていう微妙な風潮
しかも、つくる設計書の記述内容は、実装前に作るものとしてはイマイチな内容

9 ：

設計書とプログラムが食い違っていないか、機械的に検証する手段がないから、どんなに頑張って設計書作っても立派なプログラムが出来るわけじゃない。
結局設計書作るのって自己満足でしかないよね。

10 ：

設計書作ること自体が目的になるとページ数だけ多くなって誰も読まなくなるな
そして設計書があるのにまったく見ずにソース見ながら電話対応するようになる

11 ：

ソース見て判断できない人が見てるフリするための資料になってることが多いな

12 ：

大手だと品質保証のためとか言ってコーディング前に設計書を要求されるけど、
誰もまともにレビューしてなくて結局実コードのテストで
設計段階の間違いがボロボロ発見されるような現場ばかり。

13 ：

設計書なんて大枠だけきっちりしてればいいんだよ
あとインターフェイス部分とエラー処理と

14 ：

現状のドキュメントはバッチ処理にはソコソコ役に立つけど
オンラインだと矛盾が多い
新しい設計書の技法出来ないかな？
UMLに拡充する形でいいけど
あと、各社マチマチな工程名称も統一して情報処理試験でキッチリ記述と読み取りを出して欲しい
納品の為にしか存在価値のないものがおおすぎる

15 ：

>>12 想像力があっても実物の挙動は予想不可能なんだぜﾋｧｯﾊｰ

16 ：

文章での説明にしても図説（もちろんフローチャート()）にしても
例外をうまいこと表現できないから、なんか書いてて、ウアーってなる
他のとこだけコードよりの内容が要求されるのにｗｗ
でも他の人みると、そもそも例外なんてアウトオブ思考だったわ

17 ：

>>14
確かに、設計まわりの明確な名称はあるとかなり嬉しいな
とにかく何もかもが曖昧すぎるんだよな

18 ：

>>12
レビューしないだけマシだわ
設計書段階で馬鹿みたいレビュー繰り返してる内に
フローチャートを作ってた事あったし
挙げ句に設計書レビューに無駄に時間がかかった結果
実装はデスマーチになってるから本末転倒の極み

19 ：

設計段階で何するかは煮詰めたほうがいいよ。
実装者がアイディアマンになってしまうのは良くない。
俺が実装して痛い目見た経験から。

20 ：

>>19
詰めるべきは客先交えて決める外部仕様だろ
設計で内部ロジックなんか詰めてもしょうがねーよ

21 ：

DB設計と画面のモック作るだけ。

22 ：

マなんて信用してないから書かせる

23 ：

マはマで設計が信用ならないって言ってたりするからな
どっちであっても、出来る奴と出来ない奴の差が激しすぎるんだよな
なまじ形だけなら誰でも出来るもんだから、ひどい物でもなんとかなってしまうっていう

24 ：

つか、システム全体の設計はともかく詳細設計書はコード書く本人に書かせてレビューするだろ。
新人とかなら詳細設計書まで書いてやって渡すこともあるけど。

25 ：

>>24
新人じゃないならそれこそ実装したコードレビューした方が早いだろ

26 ：

こういうのみると、つくづく設計関連の用語の意味が統一されてないのが
諸悪の根源だって気がしてくるわ

27 ：

>>26
諸悪の根源は別のところにあります
本質を見抜く目を養わないと一緒ドカタですよ？

28 ：

建築業界って、大工が「俺の作ったもんが設計書だ！」って思う人いるんだろうか

29 ：

この前ブックオフで「仕様書の書き方」みたいな本があったんだけど、結局サンプルはオマケ程度で中身スカスカだった。
ちなみに俺が超参考になったのは、某大手の社員用サイトにある雛形だった。
しかしそれを下請に見せない理由がよく分からん。
その形式で納品すればそこそこな品質になるはずだが、社外秘なんだよ

30 ：

基本的にそこらの書店にあるような仕様書サンプルってプログラム素人向け、顧客が理解できる程度のものだからね。

31 ：

この業界自体土方だけどな
土方根性土方思想がはびこりすぎて個人でどうにかできる状況じゃねーよ(´･ω･｀)はあまじああ

32 ：

>>28
モジュールを指して設計書という奴は居ないだろう
ソースに該当するのはなんだろうな

33 ：

>>28
大工が建築物にコメント書くのが許されるんなら設計書にならなくもない
物置程度ならそれで充分なんじゃないかな、よくわからんけど

34 ：

>>33
建材に印ついてたりはするよな

35 ：

うちのポストにもたまに印がついてる

36 ：

書いてるとこ見つけたら器物損壊で訴えれるんだっけ、あれｗ
きっちりかっちりしすぎても、緩すぎても仕様書って成り立たないよな
降車は言うまでもなく、前者も全員が守れない無駄な仕組みになってることが多くて、破綻しやすい
いい仕様書の共通仕様でもできればいいのにな！！

37 ：

>>33
墨つぼが大工のコメント

38 ：

「昔、城を建てた無名の木工は、自分がその仕事に携わった証として、
屋根裏に自分の名を刻んだ工具を態と忘れたそうだ。そんな些細な思いすら、お前達は消し去るのか？」

39 ：

たまに外科手術で縫合終わった後にﾒｽが一本足りないことに気が付いたりとか？

40 ：

sierなんかで働くから悪い

41 ：

ドキュメントの枠だけ用意されて中身の書き方が決まっていない現場って
文章の語順や言い回しとか表現の仕方ばかり気にする人多いけど
正直馬鹿にしか見えないんだよな
共有鯖から過去の資料や既にＯＫ出てる仕様書を真似て作成しても
人によって作り方が違うからＮＧになるし
そもそも同じﾌﾞﾂ出して見る人によってＯＫ・ＮＧ別れる時点でおかしいが
本人たちは指摘して偉い気分にでもなってるのかね
「ここは太線で区切ろう」とか
「ここは�@、�Aを使おう」とか
「ここは図を入れよう」とか
「ここは→・↓・←・↑を使おう」とか
「ここはカッコ使おう」とか
「待てよ！〜が〜の〜を…うーむ」とか…
こんな指摘ばかり受けてる間に
５時間でコーディング終わるＰＧの仕様書に３日かかったし
完全に遅れが発生してこの指摘馬鹿と一緒に毎日２２時過ぎまで残業開始
結局終盤の方からはＰＧの仕様書は時間がないからと指摘馬鹿が作成
どれ程のもん作ってるのかとこっそり覗いたが１時間くらいあれば
作れるような普通の仕様書だった
要するにこいつの趣味の書き方というだけだった
指摘馬鹿は人に「こっちの方がいい」とか指摘する前に
本当にそれをする必要があるのかどうかを考えた方がいいわ
必要ないことに時間掛けてる奴多すぎ

42 ：

まったくだわ
うちの職場だと、能無しPLとか老害連中や口うるさいバカ女が
しょっちゅうどうでもいいことにばっか力注いでて、もうウンザリ
その決定を行わない無駄なボールの投げあいしてる時間で
解決してしまえる内容をぐだぐだやって、時間が浪費されてく
無駄に細かい仕様を早いうちから書こうとして要点はつめないまま、
後になって仕様変更のなみで外設あたりからいろいろ詰んでるし、頭痛いわ…

43 ：

>>41
それを顧客側が要求してくることもあるからな。
プログラムは正しくても、仕様書の記述ミスを理由に検収拒否してきたり、
些細な記述漏れを引き合いに、仕様が明確でないシステムは稼働させられないとか言い出して、稼働延期&稼働まで強制的に立会い延長になったり。

44 ：

>>43
それはお前のせいじゃ、ドアホ

45 ：

アホでもわかりやすいところは詳細に書いて、説明が面倒臭いところは適当にごまかす
初期処理と終了処理はソースコードレベルの細かいこと書いてるのに
肝心の主処理は「ファイル変換を行う」の一言だけ
コーダーのための詳細設計書なんて見たことないんで書き方もわかりません

46 ：

そうそう。
納品物件としての仕様書は誤りが書いてないこと、体裁が整ってることが最重要。
それを見てコーディングができるかどうかはまったく評価対象外。

47 ：

だから設計と製造は切り離したほうがある意味確実なんだよね…
保守さえ考えなければ

48 ：

わかってない奴がわかった気分になるための説明書であることが多いよな
実装を前提とした検討用の設計書になってるものを見たことがない

49 ：

わかってない奴に見せてわかった気分にさせるための説明書、か
そして出来ない奴ほど体裁に死ぬほどこだわる
まったくこだわらない奴も出来ない奴だけど
あと文体とかかき方にルールを設けるくせに
Excel方眼紙を卒業できない馬鹿も多いよな
自由度が高いツールを強制して、自由に出来ないように無駄なルールをつくりあげ、
仕事を増やすのが得意技！みたいな
Excelで方眼紙で糞ルールたくさん作られるくらいなら、まだ糞Word使ったほうがマシだわ

50 ：

個人的には、体裁が整ってることは大切であり、
納品物あるいは後々の保守を考えれば最低条件であると考える
問題は文書作成環境にある
Excel/Wordとも短いレポートを手軽に作成するのには最適なツール
ただし、これを数百ページにおよぶ技術系文書(仕様書/設計書/マニュアル等)に
利用する発想が、適材適所という言葉を知らぬ人が犯す基本的な間違い

51 ：

>>48
> 実装を前提とした検討用の設計書
うちはこういうのばかりだ。
おかげで、他人が見たら「どうコーディングするべきなのか」はわかっても
「どういう意図でそうなってるのか」がまったくわからない状態になってる。
> わかってない奴がわかった気分になるための説明書
メンテナンスする立場で言うと、わかってる奴にしかわからない設計書なんか
残されても、まったく嬉しくないんだ。

52 ：

>>51
どういう意図で、は要件定義から追えば分かるんじゃないの？
分からないと保守更改でる

53 ：

>>50
むかし社内で議論したけど、誰でも開けて編集できて、となると他に候補が無いんだよね。
でも開く環境が変わるとテキストがズレて崩れるけど（爆笑
Word使うなら箇条書きの範疇で済ます。
凝りたいならPowerPoint＋PDFかInDesignでごゆっくりどうぞ。
ということにしてる。

54 ：

「Excel方眼紙滅べ！それで仕様書つくるやつもぜんぶ滅んでしまえ！」
「Wordは糞だが選択肢が他にないんだよな」ってのが前提にある奴です
Wordを推したいわけではないけど、Excel方眼紙で設計書作るくらいならWordのほうがいい
>>50
使いやすいとか最適だとは一切思わんけど、Wordはそういう文書作成に使う物じゃね
もちろんExcelはない。使い捨てのレポートみたいなフリーフォーマットで使い捨てるものなら方眼紙は便利だと思うけど
>>51
言葉足りずで申し訳ない
48で言ってるのは、あくまでも「設計書」に書く内容の話な
そういうわかってない人への説明や方針決めの経緯は、
もっと上流の要件定義だったり、補足資料として別に纏めるものだと思う
そういうのがかかれてないドキュメントに恵まれてるのは、いい環境だと思うけどな
>>53
Wordの基本機能ですら、世間一般に「凝ってる」レベルだって捕らえられちゃうことが一番の原因だと思うわｗ
ドキュメント関連でWordを使う利点は、文章を書く以外のことに気を使わなくてよくなる、ってところと
体裁だけを全体纏めて修正でき、印刷のことも考えなくて済む、ってところ。このあたりが表計算ソフトのExcelにはない
ただ、それぞれの機能が使い難いし、理解しづらい
なにより、そういう基本機能ですら理解出来ない、しようとしない奴が多すぎて、まともに使われることが少なく、
仮にちゃんと作られてるドキュメントでも、そういう理解能力がない馬鹿が一人チームに混じってるだけで
簡単に設定されてる体裁の破壊が出来てしまうから、使えないツールになりがちなのよね

55 ：

>>51
>おかげで、他人が見たら「どうコーディングするべきなのか」はわかっても
>「どういう意図でそうなってるのか」がまったくわからない状態になってる。
うちではわかってないヤツ向けの仕様書書いてるけど、そのわかってないヤツが
意図とか書くと余計なこと書くなって言ってくる
なもんで「どういう意図でそうなってるのか」は偉い人から口頭で聞いてソースのコメントに書いておく
> メンテナンスする立場で言うと、わかってる奴にしかわからない設計書なんか
> 残されても、まったく嬉しくないんだ。
わかってないヤツの想定が違う
OSって何ですかレベルのヤツを指してる
>>51の組織ならそのプロジェクトに参画してなくてもコーダーなら理解でできる仕様書を書きやすい気がするが
そういう組織に属したことないからよくわからんけど

56 ：

>>53
あ、あと、PowerPointとかinDesignで設計書はないわｗ
何のための設計書かがわからなくなる
それやるくらいならまだExcel方眼紙にオブジェクト張って済ませばいいと思う
そういや、ここじゃないどっかでみたけど、
Wikiを設計書に使うってのも結構面白い発想だなって思った
バックアップ含めて管理面での自動化できるし、差分や履歴も簡単に見れる
2拠点間での共有も楽で、一元管理もしやすい
図説みたいな自由度への制限とか、環境の構築が必要だとか、他に提出するときどうするの、とか
ドキュメントとレイアウトがどうしても混ざってしまうような欠点もいっぱいあるんだけど、
外に出ないものなら結構便利そうではある

57 ：

>>55
> わかってないヤツの想定が違う
そうそうｗ
文章を読むことすら出来ないような人とか、特にそういうこといってくるｗ
箇条書き、図説、表あたりしか理解してもらえない。
そういうのは設計書じゃないだろって思うけど、その思いは言葉にしても届かない！
結局本当の設計書は各担当の頭の中で作成されちゃうのよね
自分も他に書ける場所がないする事はできるだけコメントに残したりしちゃう派だけど、
ソース弄る奴にも、先にあげたようなのが混ざったりする事もあるから
保守されないコメントが、現状の実装と異なる状態になるかもしれなくて、コメントに残しすぎるのも怖いんだよな
マに免許とかそういうのはないし、コーダーのレベルもピンキリ激しい
あとコメントじゃレビューとかもないから、誤記ったりしてもそのまま残る可能性が怖い…

58 ：

はぁ？
設計書って言ったら図だろ。
お前車とか家とかの設計書見たことあるのか？

59 ：

あはっ♪
設計書って言ったら、ﾌﾂｰ「設計書がどうしたんや！何して欲しいんかちゃんと云いなはれ。そんなんで伝わると思うたらおお間違いや」
設計書是也設計書。
設計書見たことあったらどうなのか？ 無かったらどうなのか？ もったいぶってても大した話じゃないならとっとと話を進めなさい。

60 ：

つーか、設計書を曖昧に自然言語で書くなよ。

61 ：

たしかにマも土方だが、そういう方面の土方ではないぞ。

62 ：

理解能力がない人に見せる資料は設計書とは分けたほうがいいけど、理想どおりにはいかないしな。
結局頭の中が下の連中に合わせないといけなくなる。

63 ：

>>60
自然言語で表現できないかしづらい内容までドキュメント化しろなんては思ってないよ
シーケンス図とかクラス図で済むことならそっちでやるし
きっちりかっちり自然言語を使わず表現できる部分なら、それはもうコーディングしちゃえばいいんじゃね
>>62
まぁ結局そうなるんだよな

64 ：

> きっちりかっちり自然言語を使わず表現できる部分なら、それはもうコーディングしちゃえばいいんじゃね
うん。だから設計書＝コードなんだってば。
日本語は、コメントとして書けばいい。

65 ：

プログラム設計書は要らないと思うが、それより上の工程でのドキュメントは必要。

66 ：

>>65
ISOなんとかのためなのかどうかは知らないけど、
プログラム設計書は求められる現場が多い。
それより上の工程のドキュメントは無くても。

67 ：

>>66
上の工程のドキュメントはどんなにわけわからんこと書いてても
我々に文句言う権利ないしね

68 ：

>>4
プログラム設計書は重要じゃないけど
プログラム設計は重要
この重要性が現場でも理解されてないからプログラマの地位は低い

69 ：

設計書くのは重要だと思うけど、最低限まともにレビューできる奴がいないと、作る意味がないんだよな
的外れな指摘しかされてない、半端な設計書なんて用意しても、結局糞の役にも立たないなんてことになるしなぁ

70 ：

レビューは、その場で見て思いつきで指摘して終わるからな
ちゃんと修正されたか再レビューしないことも多いし
儀式的なものになり果てている
担当を複数人にしてお互いにチェックするという仕組みにしたらいいと思うんだが

71 ：

>>70
それは単純に開発プロセスの問題な気がする。
プロセス監査とか無いの？
結局開発者自身が本当に改善したいと思ってるかどうかと、
さけるリソースがあるか、によるんだよなぁ。
実際真面目に取り組むとちょーメンドくてしんどい。
けど効果はある。

72 ：

開発プロセスの問題じゃなくて、
各々の文章チェック能力、設計力の問題だろ。

73 ：

そら有能な個人の力に頼るのが早いてのは分かるけどさ。
再レビューが無いのが問題だと感じてるなら、
再レビューしたかチェックする機構があるべきだし、
「指摘がその場の思い付き」「儀式的になってる」とか、
不具合流出の分析とそれによる対策がされて無いわけじゃん。
レビュー観点の整理とか、インスペクションの導入とか。
実際>>70自身言ってる「チェックの仕方」自体プロセスそのものだし。
低レベルでの開発プロセス定義なんて、最低以下の人間に
最低限の仕事させるためのもんだよ。
高生産性や高品質はその次の話。

74 ：

http://d.hatena.ne.jp/iad_otomamay/20111207/1323276264

75 ：

低レベルの人間に何回チェックさせても無駄。
プロセス重視することと、内容を軽視することは同義。

76 ：

＞プロセス重視することと、内容を軽視することは同義。
レベル低くて笑える。
それ素振りやっただけで上手くなった気分になって満足してる奴らの話だろ。
まぁ好きにしたらいいよ。

77 ：

プロセスを突き詰めて問題が解決するなら
docomoの障害は起きなかっただろう

78 ：

無駄なプロセスばかりが増えていく。
内部統制とかいい例。

79 ：

プロセスを突き詰めても
人間がある以上トラブルは発生する。
だがプロセスがなければ
もっと多くのトラブルが発生する。

80 ：

>>73が自分で言っているように
＞低レベルでの開発プロセス定義なんて、最低以下の人間に
＞最低限の仕事させるためのもんだよ。
こういうことなんだろう。
そもそも最低の人間を使わなければいいのに。

81 ：

自称上級者が簡単なことを
やらないからいけないんだろうな。

82 ：

低レベルの人間大量に投入してプロジェクト上手く回すのがプロマネの仕事です。
レベル高い人間を集めるられることを前提に計画建ててる時点で破綻してる。

83 ：

>低レベルの人間大量に投入してプロジェクト上手く回す
ってのは可能なのか？

84 ：

>>82
ソフトの世界は量ではなく質なので
その方法では一流になれません。

85 ：

質の良いソフトがビジネス的に成功した例は皆無だよ。
WindowsとかOracleとかのバグの多さを見れば明らかだろう。

86 ：

ビジネス的に成功　と　バグの多さ　にどういう関係が？

87 ：

>>85
低レベルの人間を大量に集めて
WindowsとかOracleを作れると思ってるなら
おめでたいな

88 ：

質より量を重視した結果バグだらけになっても、多機能を売りにビジネス的には成功するって話。

89 ：

>>87
本気で高レベルの人間が、少数精鋭で作ってると思ってるなら頭おめでたいですね。

90 ：

人が大量にいないと作れんが
その人達は全員がある程度高レベルの人間でないと作れない
特に優秀な人が必要なのはプログラマレベルだろう
例えば日本のゼネコンシステム会社にMFCとか.NETライブラリとか作れるか?
上流工程(藁)SEには作れないし、寄せ集めプログラマ作れるものではない

91 ：

Microsoftはバグですらビジネスに利用して一流になったわけだし。
新しいバージョンではバクやセキュリティホールが治って価値が上がってる、だから新バージョンを買ってくれってね。

92 ：

残念ながらOS作ってる奴らの大半は、寄せ集めの短期契約プログラマーだよ。

93 ：

え、マジで？
デビッドカトラーとかは伝説なの？

94 ：

>>92
正社員か下請けか派遣かとかの所属のことを言ってるんじゃないよ

95 ：

著名な人間の間違いは指摘できないから、それが正式な仕様としてドキュメント化されるプロセスが定着してしまったんだろうね。
今のwindowsは糞仕様が多すぎる。

96 ：

「仕様がクソ」と多くの人が言うが、「どこがクソ」かを言う人は少ない

97 ：

>>96
そいつが、そういう仕様になってる理由を理解できる頭がなく
分かってないだけのことも多い
単に自分の分担分の作業が増えて面倒だというだけの理由の場合もあるな

98 ：

バグ報告のサイトで散々言ってるから。

99 ：

>>87 >>90
多人数大規模の開発ってのをなんか勘違いしてるでしょｗ
まず前提条件として、大規模っていうの数万、十数万人月という工数で
すごいプログラマが通常の10倍の生産性だったとしても
1000ヶ月、83年、そんなに時間かけられますかって話なんだよ。
WindowsとかOracleとかそんなのは難しいだけで工数はそんなに必要ない。
簡単だけど工数は大きいという仕事のほうが世の中には多いんだよ。
OSやDBMSなんて殆どの人は使うだけで作ったりしないでしょ？
そしてOSやDBMSを使うだけの仕事に、OSやDBMSを開発できる人間を
担当させるのは、どう考えても仕事の振り方間違ってるよね？
そして仕事である以上、納期とコストの事を考えないといけない。
工数から考えて、少数のすごいプログラマだけで作れる期間は与えられない。
なら、すごくないプログラマを投入するしかない。これは絶対条件。
じゃあどうするか。ここまで考えてものを言ってる？

100read 1read

1read 100read

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

もしキュゥべえがブラックITの営業だったら (529)
任天堂・富士通・NEC・日立、転職ならどれ？ (808)
求人数はJava、年収はC#がトップ (169)
どうでもいいことばかり報告するスレ (895)
SEの現実が知りたい (148)
【実演】使えない新人 0x1D (778)
--log9.info------------------
【遵法】猫対策を考える【ソフト路線】7 (963)
迷惑です！！！猫ヲタは出て行ってください＞＜ (838)
気付いたら体の上に百足が！体験者挙手 (183)
室内害虫総合質問スレ5【Gだけが害虫じゃないｿﾞ】 (119)
【法律で】　ネコ放飼い被害　【規制してくれ】 (955)
殺虫剤について語るスレ (693)
【未確認】新種の虫？発見 (409)
この板が今後人が集まって発展するとは思えない (163)
イノシシ (147)
真の強敵（とも）と呼べるのは蚊だけ (322)
虫による恐怖体験を報告するスレ (880)
お前は騙されてゴキ板にわけだが３度目の正直 (482)
ところでおまいらが一番嫌いな害虫って何だ？ (195)
マムシ・ハブ・ヤマカガシ【日本の毒蛇（ヘビ）】 (735)
◆ゴキブリの新しい名前を考えるスレ◆ (442)
トコジラミ（南京虫） (254)
--log55.com------------------
w3m その8
[test] 書きこみテスト 専用スレッド 12 [ﾃｽﾄ]
今Monterey Marriotに居るよ
シェルスクリプト総合 その26
Navi2ch for Emacs (Part 21)
正規表現
【ウホッ！】twmを語ろう！！【いいWM】
最強のWindow ManagerのWindow Makerを語れ。