設計書を作ってるせいで生産性落ちてないか？

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

概要設計書、外部設計書、詳細設計書
クラス図、シーケンス図、状態遷移図、アクティビティ図
リファレンスマニュアル、レビュー管理記録、成果物リスト、・・・・・・・
アホか、、
外設した後はさっさとコーディングした方が
設計書なんかで妄想してるより何倍も多くのことが分かるっての。
で、実装とテストが終わったあとに
改めて補足のドキュメントまとめた方が明らかにソースと食い違いのないものができる。。
だいたい「ソフトウェア 設計書」でググったら
現状懐疑論ばっかじゃねーか。

2 ：

設計書よりも
デバッグ期間とか、発生数／対応数のグラフだけ毎日書くひとじゃねえの？

3 ：

>>2
そういう単純作業は派遣社員にでもやらせるのが勝ち組

4 ：

後から作るから問題なし。
つーか今時
＞概要設計書、外部設計書、詳細設計書
こりゃねーだろｗ

5 ：

製作を外注するならともかく意思疎通しやすい距離で作業するんなら、
全くもっていらないんじゃない？

6 ：

>1の会社はいまだにステップ数で見積もってるんだろうな…

7 ：

1は形式的手法も知らないDQN工員

8 ：

今は短納期が基本だから設計書なんて書かない。
仕様書はデータベースの定義だけあればいい

9 ：

1.概要設計書をでっちあげる
2.概要設計書をコピーして少し書き足す→外部設計書
3.外部設計書をコピーして少し書き足す→詳細設計書
4.1〜3の成果物を大切に保管
5.DB定義書と機能メモをもとに実装
なんてことを、ここ数年続けてる。

10 ：

実際には外部に発注する以外作った設計書の使い道がない。
ただ、ISO9001の審査を通すために毎回作ってる。

11 ：

ドキュメントは重要だが、たいていは客に提出するドキュメントを作った時点で
力尽きてしまい、開発用のドキュメントがおざなりになってしまう・・・

12 ：

各種ドキュメントを作成するのはいいとして、
ソースコードのほうだけ修正してドキュメントを修正しない
ということ。
コンピュータを使っているのに、
人間が手作業で対応関係を把握して、
まるで写経のようにドキュメントを更新するのは、
なんかもうアホらしい。
詳細仕様についてもJavaDocなんてアホらしかった。
書き写す元と先の距離がとても近いだけで、
結局は同じファイル上でコピペをすることになる。
ソースコード上でさえ情報を一元管理できない。

13 ：

俺のすごいところは何万行のプログラムでも
一度もコンパイルすることなく一気に書き上げる。
いちいち動作確認しながら作るやり方は素人

14 ：

>>13
天才

15 ：

>>1
その通りだが、本当にそんなたくさんドキュメント作ってるのけ？

16 ：

>>13
すごいなぁ。
自分は記憶力が足りないので何万行も頭の中に入りきらない。
きっちり把握できる分量で区切ってテストしてる。
書いてみて、コンパイルしてみて、動かしてみて
というのを数十行ごとにやっている人に、
「お前、ちゃんとわかってないで書いてるだろ?
そんなのは、たまたま動いているだけだぞ。」
なんて偉そうなことを言っている自分だけど・・・。

17 ：

だが、そうやって一気に書き上げられたプログラムに
何件バグが含まれているかについては一切言及されてない件について。

あれ、俺釣られた？

18 ：

>13
じゃあ次は cat 一発でのプログラミングに挑戦だな

19 ：

設計書がない方が自由にできると思われ

20 ：

お前等設計書が無い開発したら絶対こんな事言わなくなるぞ
現職がそうなんだが、口頭で仕様、機能追加、クライアントの言うがままを丸丸営業が持ってくる
コーディングルールすら無い
で、
「コーディングルールや要件定義書と仕様書（技術者側の）と設計書が無ければ開発しない様にしましょう。
品質管理の点からも、プロジェクトの進め方にしても開発にかかる負担を減らす事が出来ます。」
と、上に進言したら
上の人間に営業出身の奴しかいないせいか
「そんな窮屈にしたら開発の自由度が損なわれる（自分達がドキュメント書いた結果自分達の責任が露呈するのが嫌）」
「設計書のママに組んでも面白くないだろ？ウチの良い所がスポイルされてしまう（もう必死）」etc
要件定義書、設計書、仕様書は技術者の防御手段だと思っていいよ
時間掛けても書くべき、生産性云々よりも重要

21 ：

>>20
その通り。俺はバカだったから経験として知ってる。

22 ：

>>20
技術者のっていうより受注側の防御手段だろ。

23 ：

そこでXPですよ

24 ：

>>22
馬鹿だな。敵は身内にも居るんだよ。

25 ：

>>24
何を信用したらいいのかな？
恐いよ

26 ：

>>25
信じられるのは自分の力のみ。
バカ営業や、なんちゃってSEが勝手に客の仕様変更要望を受け付けてしまうことはよくある話。
紙に残ってないと責任の所在が不明確になり、結局末端に押し付けられてしまう。

27 ：

>>20
>口頭で仕様、機能追加、クライアントの言うがままを丸丸営業が持ってくる
論外。だが、んなことぁこのｽﾚで語ることではない。

28 ：

後から書く書く詐欺にあったらちょっとは考えが変わるとおもう。
発注する側に回って身に染みた。

29 ：

で、数年たって保守とかやらされてみそ。
設計書？メモ残ってるから見て！
ソース？バグとか変更で使ってないとこ残ってるかも？
ビルド？どーやるんだっけ？Make残ってない？え、バッチ？
ご注文は？　　　 　 ∫　 　 ／⌒ヽ　　……　設計書一式。
　　　　　　　 　　　　　~━⊂(　^ω^)つ-、
　 ∧,,∧　　　　　　　　／／/　　 /_/:::::/
　(　´∀｀)　　　　　　　|:::|/⊂ヽノ|:::| ／」
　/　φ口o　　　　 ／￣￣旦￣￣￣／|
　しー-Ｊ　　　　／＿＿＿＿＿＿／ | |
　　　　　　　　　| |-----------| |

30 ：

悪の組織に連れ去られる直前に博士が孫娘に託し、奪いにやって来るあまたの敵とヒーローが闘う。
それは、設計図。

31 ：

>>15
結構本当なのであった

32 ：

http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html
ソフトウェア設計とは何か？
・プログラム・リスティングとはソフトウェア設計を表現したドキュメントです。
・多くの様々なソフトウェア設計記法は，有益なものとなる可能性を秘めています。
補助ドキュメントやツールも同様に，設計プロセスを円滑にする支援となります。しかし，
これらはソフトウェア設計ではありません。

33 ：

それは一部の意見だろ。
>>32には古代の暗号マクロに満ち満ちたアセンブラソースをたっぷりふりかけて煮込みたい。

34 ：

設計図もなしに大勢で一つの物を作れるわけが無い。

35 ：

>>34 それぞれがそれぞれの味付けしたソース持ち込んで闇なべ作ってたプロジェクト知ってるぞ。
無論破綻した。

36 ：

うちは大抵２〜３人でやるような規模の小さいプロジェクトしか受けないから
結構ドキュメント周りはいいかげんだし、それで何とかなってるなぁ

37 ：

>>36 まあ、自分で作ったの数年たってからみてみそ。
間違っても人に投げるなよ。

38 ：

>>37
あームリムリ、数年も留まってないだろうから
人が書いたソースの解読から始まるなんてザラ

39 ：

２〜３人程度のプロジェクトなら、機能分担とI/Fきっちり決めて、口頭とソースだけで済むよ。
疑問な点はその都度直接聞いて、分かったらソースに注釈で記述。

40 ：

だ・か・ら
そういう考え方が徹夜につながるんだよ。
割り増しもらえるからいいって？
や　な　こ　っ　た

41 ：

>>39
２〜３人程度なら必要ないね。

42 ：

>>39
技量（理論の勉強と経験からの学び）のある人間で集まったら
その通りだね。ものによっては、業務フローも欲しいね。
業務遂行の道具であるシステムの目的を忘れてしまったら本末転倒だしね。

43 ：

まあ、この業界自己厨が多いのは確かだな。
自分さえよければ、他はどうなっても別にいいっていう糞が
その後メンテをするって事はまったく考えていないと（笑

44 ：

仕様書は別見積もり

45 ：

で、ソース以外に何も無いってのを人に分投げる、と。

46 ：

http://pc11.2ch.net/test/read.cgi/prog/1104753899/

47 ：

既存システム関連の仕事で稼動中システムの書類やソースがもらえることが
殆ど無い。ソース貰ってもメイク通らないでやんの。
何にもよこさねえで作らせるんなら新規開発した方が早いわ。

48 ：

ごちゃぐちゃのソースもらって頭抱えるなら、設計書もらって再設計しろのほうが
なんぼかましなことか。

49 ：

プロジェクト管理がしっかりできていれば、突貫、残業はそんなにないはず。
PGも、GTD、TOC、CCPMを勉強して、残業しないで済むように頑張ろう！
人生は一度きり。
マジでプライベートを充実させる時間がなかったら、後悔するかもよ。
http://www.amazon.co.jp/dp/4806123315/
CD‐ROM付 目標を突破する 実践プロジェクトマネジメント
大手企業、各地方自治体で続々採用!
現場で使える「プロジェクトマネジメント」のノウハウが一冊に凝縮されました。
「納期が遅れる6つの理由」をはじめ、多くのプロジェクトに共通する問題点を提示、
独自の手法によってこれらの問題を解決に導くまでを、図やイラストを豊富に使ってオールカラーで解説しています。
徹夜、寝袋、乱雑な机、いつまでも終わらない仕事……。
「こんな毎日はもういやだ!」と思っているあなたに、本書と特別付録CD-ROM(30日限定・工程管理ソフト)をおすすめします。

50 ：

既に手遅れになってから仕事がくることもある

51 ：

設計書もかけないPGは、どんなにコーディングがすごくても
アマチュアレベルだな
仕事上、設計書は相手との契約書だからな

52 ：

大阪の堺筋にある株式会社●ィッツ。ここだけは就職やめとくべし。
Ｉ次長。こいつバカ。沸点30度くらいで、すぐ茹蛸みたいに切れる上に、
仕事もいい加減。自分を棚にあげて部下に八つ当たり。出向先の人も
やりにくそうだよ。自分もこいつとは仕事したくないｗ

53 ：

設計書の承認印をぶち破って仕様変更を押し付けてくるのは日常茶飯事ってのはおいておいて。
まぁ、ちっこいプロジェクトならフットワーク考えると無駄が多いかもしれん。
が、大きいプロジェクトだと責任分解点になるから凄く重要だと思う。
ただ、設計書もどきを作ってる作業が一番つらいな。
これ仕様どおりじゃないよね・・ってのを線表どおり工程進めたいがためだけに作成する無意味さ。
嘘の仕様書の誤字脱字指摘されて、「修正します」って・・ムナシス

54 ：

【IT】システム設計図の統一ガイドラインを発表…NTTデータなど開発会社9社［09/18］
http://news21.2ch.net/test/read.cgi/bizplus/1190124648/

55 ：

設計書通りに作ったら動きません

56 ：

内部仕様書に、せめて状態遷移表ぐらい無いと
ホワイトボックスのテスト項目が作りづらくてしょうがない

57 ：

>>56
ソースもなしにホワイトボックスのテスト書けるのか！？

58 ：

>>57
56の上司「書けるか、だと？ 書くんだ！お前の首の上に乗っかっているのは飾りか？」

59 ：

>>58
ねつ造するくらいは出来るだけの能力は有していますが、意味が無いかと。

60 ：

>>57
何が言いたいのか分からんが、お前のトコでは状態遷移表書いたらソースコード書かないのか？
なんで「ソースもなしに」とか出てくるのか意味分からん。

61 ：

>>59
56の上司「意味？そんなものは上が考える事だ。お前は結果を残せ。」

62 ：

実装後に書く設計書は書くだけ時間の無駄。コード見た方が早い。
実装前に客の承認を得る意味での設計書なら必要。
>>61
おれの今の上司がそんな感じ。
人の上に立つ立場なら部下の意見に耳を傾けるぐらいの度量は持って欲しいね。

63 ：

>>62
実装前の客の承認を得る意味でない設計書はどうなんだ？

64 ：

>>63
ケースによる。
必要なときに最低限必要なものだけ書けばよい。
形式的に毎回全部を書く必要は無い。

65 ：

仕様確認のための設計書は書いたこと無いなぁ
ってゆーかそれならプログラマなおいらが書く時点で…
おいらが書くのは常に実装後だから
カスタマイズや保守、類似機能開発の為の仕様書だよ
うちのSEはプログラム組めないし仕様書かけないから
夢みたいなカスタマイズ受けてくるから
その指示で外注が直しちゃうと破綻すっから
日本語で読める現状ソースみたいな位置付けだ

66 ：

>>65
一級建築士みたいにある程度資格あってもいいのにねぇ・・
実装はできないかもしれんが、ファンタジーな絵本が上がってくる率は低くなるかと。

67 ：

日本のSEって存在すごくおもしろいんだな

68 ：

自分の漫画描いたりするもんな

69 ：

簡単にちゃちゃっと手を入れて作っちゃうのがいけない
簡単に出来るのね〜とか思われる

70 ：

>>1
俺も激しくそう思うｗ
馬鹿に限って教科書通りの開発スタイルにこだわる。
そんな奴に限ってスキルが無い。

71 ：

>>70
ドカタ乙

72 ：

プログラマ崩れのSEもどきな俺はドキュメントは『メンテナンスの資料です』と嘯いてる。
クライアントの受けは悪いがな。

73 ：

テスト中に見つけたバグを修正するのに、バグを出した理由から始まって、腐るほどのドキュメントを書かないと、修正できない。
・・・面倒くさすぎて、みんな、バグを隠すようになったよ！

74 ：

構造化で作るなら、設計書なしでも大丈夫だが
オブジェクト指向で作った場合、設計書がないと
ソースが追うのが大変
（もちろん、オブジェクト指向で正しく作ってある場合で、オブジェクト指向もどきの構造化は別）
オブジェクトは一種のグローバル変数でポインター型だ
これは構造化の時も同じだが、ソースを読みにくくする最大の源因の一つ
そのオブジェクトがどのように、他のオブジェクトとどのように関係しているか
設計書が有った方が良い

75 ：

>>74
スキルが低いだけだろーが。木瓜。
>>73
俺も結構隠蔽してるよ。
脅威のバグ発生率９９．９９％
テスト時にバグを見つけたらこっそり修正してからテストしなおして
るからねｗｗｗｗｗｗｗ

76 ：

バグ発生率99.99%は脅威ですよね

77 ：

>>75
>スキルが低いだけだろーが。木瓜。
オブジェクト指向知らないのか？
少なくとも一般レベルのスキルは持っているが、お前のスキルは？
（俺は、別スレッドで落ちたシステムモジュールを、マシン語レベルで解析して修正するぐらいなら出来るが）

78 ：

>>77
バイナリ方面は何とかcoreファイル読める程度のスキルしか持ってないが、
仕様書無しなら俺は、構造化よりもオブジェクト指向のソースの方がシステムを俯瞰し易い。

79 ：

>>74
>オブジェクトは一種のグローバル変数でポインター型だ
オブジェクト指向で正しく作ってある場合に当てはまらないよね？

80 ：

俺はcaseツールでクラス図書いてスケルトン吐かせてるから、クラス図『だけ』はいつも最新だな。
ソースしかないなら規模にもよるがoopな言語は追いかけにくい。

81 ：

>>77
赤の他人で悪いが、>>75はスキルの高い人間の書き方ではないなぁ。
人格レベルも。
スキル低いのはいいが、それを自覚していないのが痛いんだよな。
自分の書いたクソみたいなドキュメントは役に立たないんだろうが、
優秀な人の書いたドキュメントは、凄まじく助かるシロモノなんだが、
それが理解できていない。
底辺コーダーとはかくあるべき。

82 ：

>>78
>バイナリ方面は何とかcoreファイル読める程度のスキルしか持ってないが、
「バイナリ方面」って何、バイナリを直接扱うのか？逆アセンブラじゃなくて？
「coreファイル」は何のために読むの？

83 ：

OOもどきよりもOOの方が可読性が低いと主張する
輩の集まるスレはここですか？

84 ：

>>82
＞「バイナリ方面」って何、バイナリを直接扱うのか？逆アセンブラじゃなくて？
>>77で「マシン語レベル」って書いてあるから、実行バイナリやらオブジェクトファイルやら
バイナリのまま解析したり編集したりするのかな、と。
＞「coreファイル」は何のために読むの？
coreファイルって、LINUXとかでセグメンテーションフォルトしたときに
メモリの内容をダンプしたファイルで、デバッグのために読むよ。
落ちた時のアドレス、コールスタックとか簡単に拾える。
まぁcoreファイルをgdbに食わす速い方が多いけどな・・・

85 ：

>>77
>（俺は、別スレッドで落ちたシステムモジュールを、マシン語レベルで解析して修正するぐらいなら出来るが）
>>78
>バイナリ方面は何とかcoreファイル読める程度のスキルしか持ってないが
>>78は、ダンプファイルが読める程度、これはアセンブラが出来れば普通出来る
>>77は、マルチスレッドのデバッグだから、>>78より高度かな
>>78は、後出しなんだから、嘘でも少しは高い技術を書けるだろう？

86 ：

よくわかんねぇけど、そこで嘘ついて高い技術書いて何になるんだ？
まぁ仕様書が皆無なら、構造化の方がというか機能分割されてる方が取っ掛かり易いだろ。
どんな機能があるかはシステムを動かしてみればはっきり分かるけど、
どんなオブジェクトがあるかは動き見ても想像までしか出来ないからな。
ある程度分かったあとならモジュール間の関係が薄いオブジェクト指向の方が詳細を理解するのは楽かね。

87 ：

>>86
>よくわかんねぇけど、そこで嘘ついて高い技術書いて何になるんだ？
これは>>75で、
>スキルが低いだけだろーが。木瓜。
と書いてる本人が、その相手より、後出しでスキルの無い事を書いてたから
不思議に思っただけだ
（普通、スキルが無いとバカにしたんだから、スキルが有るように書くと思っただけ）

88 ：

つーかさ、
一文だけでスキル判るって天才ってレベルじゃねーだろ・・・
この業界スキルあっても対人スキル持ってない奴なんて腐るほどいるだろ・・・

89 ：

>>75と>>78は別人

90 ：

なるほど！！分った。あんがと

91 ：

俺は自分のRを30秒でイかせるくらいのスキルはある。

92 ：

しょうがきせいの頃は10秒くらいでいってたな
今考えるとありえんわ

93 ：

しょうがきせいの頃から白いもん出てた訳でもねえだろ。

94 ：

確かに、おまいらには仕様書はいらないな
書いても、その紙を別の事に使うだろうしｗ

95 ：

そもそも体裁だけ整えようとするから設計書の存在自体に疑問を感じるんだろ？
まあドキュメント自体、後回しかほったらかしにならざるを得ない状況じゃどうしょうもないかｗ

96 ：

設計書とソースの修正だけなら問題ないけど、
障害表、障害報告書、修正前後の画面帳票等の出力結果、横展開確認書、
さらに確認会議、とか。
こういったことに無駄が多く、生産性がすばらしく落ちる。

97 ：

>>96
そういうのに限って、設計はおろか
何のシステムかすらよく分かっていないような方にまで
提出しなきゃいけないんだよな…。
説明も一からだし
かなり噛み砕いた資料も添付せんといかんし…。

98 ：

ホワイトボックステストって、コードから起こすだろ・・・

99 ：

>>55
あるあるｗ

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 削除依頼 ▲
・　次のスレ
【煙】　なぜプログラマに喫煙者が多いのか　【煙】
スティーブンス本ってやっぱりいいぜ！
日立製作所で上手くやっていくには？V.2
いかに派遣をうまく使うかを考えるスレ