- 1 名前：仕様書無しさん mailto:sage [2011/11/26(土) 11:26:56.24 ]
- 外部だの内部だの基本だの詳細だの…
曖昧な基準で書かれた、いろいろな名前で呼ばれてて
「これってどうなの？」「意味あるの？」といった物に出くわす事も少なくない
しかし、純粋にプログラミングだけをして食べていくことは、昨今じゃ難しく
避けて通れない、否が応でも作る機会に出くわしてしまう、そんなドキュメントたち
設計書や仕様書についても、マ視点で語ろうぜ
・自分のなかでの仕様書/設計書の呼び方と分け方
・成功談、失敗談
・仕様書/設計書は何を使って作成する？(Word/Excel/HTML/手書き！)
・仕様書/設計書に含める図の作成方法や使っているツール紹介
・炎上プロジェクトでみた(よくない意味で)素晴らしい仕様書/設計書
・そもそも仕様書/設計書って本当に必要なの？
・こんな仕様書/設計書は、ぶっちゃけアリ？ナシ？
などなど、設計書にまつわる話題を募集
- 603 名前：仕様書無しさん mailto:sage [2012/05/22(火) 22:05:14.12 ]
- >>589
それな
実際仕事の現場でもよく見るけど、XX仕様書のレベルが
職場というかもはや人単位ですら微妙に異なってるから、ちょっとしたことのすれ違い多くてめんどくさいわ
いいかげん共通規格が必要だと思うわｗ
- 604 名前：仕様書無しさん mailto:sage [2012/05/22(火) 23:08:05.36 ]
- >>603
2chはいつもここに気づくまで会話がかみ合わなくて、気づいたところで終わるんだよなw
そしてまた同じ会話をはじめるw
- 605 名前：仕様書無しさん mailto:sage [2012/05/24(木) 22:15:30.49 ]
- クラス図はいいけど
他はあんまり役に立たない気がする
- 606 名前：仕様書無しさん mailto:sage [2012/05/24(木) 22:59:28.59 ]
- 要件すら定義されてない機種のコードをどうやって書けばいいんだよ？
俺は最底辺なのに、なんで製品の動作の責任までとらされるのか
- 607 名前：仕様書無しさん mailto:sage [2012/05/24(木) 22:59:50.07 ]
- ステートチャートは捗るぞ
- 608 名前：仕様書無しさん mailto:sage [2012/05/25(金) 13:41:41.18 ]
- >>606
コード書けまではないけど要件定義前にステップ数出せってのはある
- 609 名前：仕様書無しさん mailto:sage [2012/05/25(金) 14:15:28.15 ]
- あるな…
- 610 名前：仕様書無しさん mailto:sage [2012/05/25(金) 15:06:07.34 ]
- で、2,000行1人月な、的な話もちょっと前まではたまにあった。
だから逆算して行数を出すことにしてた。
- 611 名前：仕様書無しさん mailto:sage [2012/05/26(土) 11:30:11.77 ]
- そもそも行数なんて今日日なんの意味もないことが明白だのに、いまだ使い続けてるあたりがアレだよなぁ
- 612 名前：仕様書無しさん mailto:sage [2012/05/26(土) 19:03:42.37 ]
- 俺が三角関数や微分方程式を駆使して数値を出す計算式を1ステップで書いたら、
何も仕事してねえとか言われたよ。
先輩は単純な放物線を求めるだけで50ステップ以上。
単純な数式をあんなスパゲティでピラミッド構造に作っていたら、修正とかとんでもないことになると思うんだが。
- 613 名前：仕様書無しさん mailto:sage [2012/05/26(土) 19:45:40.20 ]
- >>608
なんでそんなの出るんだよ
バッカじゃーんって出せって言った奴に言ってみればよくね？
- 614 名前：仕様書無しさん [2012/05/27(日) 00:28:17.84 ]
- 洋服に付いている洗濯方法の絵表示が全面変更される。経済産業省は、
日本国内だけで使われている日本工業規格（ＪＩＳ）表示を２０１４年にも改正し、
国際標準化機構（ＩＳＯ）が定めた国際規格にそろえる方針。
ＩＳＯ規格は欧州などで普及している記号がベース。大きな変更点は、洗いの表示から
「洗濯機」がなくなり、「たらい」に統一されること。手洗いは、たらいに手を浸した
絵で表す。
乾燥方法の表示は「服」や「手絞り」の絵が廃止され、「四角」に一本化。乾燥機使用
の表示は「四角の中に丸」。自然乾燥は「四角の中に棒」となる。
alp.jpn.org/up/s/9905.jpg
- 615 名前：仕様書無しさん mailto:sage [2012/05/27(日) 18:39:27.91 ]
- >>612
分解がめんどくさいコードは一長一短だけどなー
コスト差ないなら、馬鹿がコードに触る可能性がある場合はあえて崩して書くこともある
まぁその先輩()とやらがやってたのはクソコードなのはなんとなくわかるｗ
ステップ数が多い、ってのは、仕事してるんじゃなく大半はただ無駄が多いだけだからな
- 616 名前：仕様書無しさん mailto:sage [2012/06/17(日) 16:13:44.20 ]
- 公開メソッドの多いクラスなんかのコードだと、行数の1/3はコメントだったりするわ…
ステップ数で仕事量測るくらいなら、ツール使ったユニットテストのケース数とか数えたほうがまだ幾分かマシ
- 617 名前：仕様書無しさん [2012/06/18(月) 01:38:39.32 ]
- 無駄な仕様書を減らして、有用な情報だけを残すにはどうすればいいのか…
「既存」の呪いを解呪できるアイテムの実装が必要？(´・ω・｀)
- 618 名前：仕様書無しさん mailto:sage [2012/06/18(月) 09:39:09.74 ]
- デスマプロジェクトで、詳細設計書が顧客にボロクソに言われて全面修正してるのに
他所で作ってるそこのプログラムは完成して、客にも渡したみたいなんだけど、どういうことなの
- 619 名前：仕様書無しさん mailto:sage [2012/06/18(月) 10:50:08.03 ]
- コードに合わせて詳細設計書を修正しろってことだろ。
- 620 名前：仕様書無しさん mailto:sage [2012/06/18(月) 13:30:18.11 ]
- >>617
術者を○す
- 621 名前：仕様書無しさん [2012/06/18(月) 23:42:10.71 ]
- 世の中にはびこる負の遺産や呪いの術者を殲滅することが次の世代のマに託されてる…？
- 622 名前：仕様書無しさん mailto:sage [2012/06/19(火) 14:33:23.74 ]
- >>618
根回し重要
- 623 名前：仕様書無しさん [2012/06/19(火) 22:32:12.33 ]
- 物の品質よりそういうところが重要ってあたりが、土方くさくてやんなるな
- 624 名前：仕様書無しさん mailto:sage [2012/06/19(火) 22:54:27.82 ]
- とりあえず納品物に仕様書を要求するんじゃなくて読み安いコードを要求するようにしろや
品質に直結してウハウハだぞ
- 625 名前：仕様書無しさん mailto:sage [2012/06/21(木) 10:44:31.63 ]
- >>624
コードくれないところ多いよ
- 626 名前：仕様書無しさん mailto:sage [2012/06/22(金) 04:52:34.33 ]
- 要求が曖昧なら
どういう資料作っても無駄になるだけでしょ
- 627 名前：仕様書無しさん mailto:sage [2012/06/22(金) 04:57:00.54 ]
- プログラム読めない系の人が完成後に
資料、資料
って騒ぐみたいだよ
- 628 名前：仕様書無しさん mailto:sage [2012/06/22(金) 06:38:29.74 ]
- >>627
そういう人が欲しいのは、仕様書設計書じゃなくて、多分操作マニュアルが
欲しいんだろうね。
- 629 名前：仕様書無しさん mailto:sage [2012/06/22(金) 19:23:22.84 ]
- 大工さんに、家の作り方を一から書いてください的な、資料？
- 630 名前：仕様書無しさん mailto:sage [2012/06/22(金) 22:20:11.84 ]
- いいえ、他の大工さんが仕事を引き継げるような資料です。
- 631 名前：仕様書無しさん mailto:sage [2012/06/22(金) 22:43:08.90 ]
- それ、設計士が図面書いた時点で終わってるでしょ
図面通りじゃないところぐらいじゃ、必要なのは
- 632 名前：仕様書無しさん mailto:sage [2012/06/22(金) 23:06:34.32 ]
- 引き継ぎどころか、一緒にやってるメンバーでさえ見ない(見てもわけわからん)
資料を大金かけて作ってるわけだが。。
- 633 名前：仕様書無しさん mailto:sage [2012/06/22(金) 23:08:13.94 ]
- SEという人種が要求を噛み砕けんから、おかしくなるんじゃねえの？
客の太鼓道程度じゃ、そのうち...
- 634 名前：仕様書無しさん mailto:sage [2012/06/22(金) 23:08:42.06 ]
- >>631
一般的に設計士は、どういうものを作れという資料しか作らないので、
どうやって作ったかの資料が必要。
- 635 名前：仕様書無しさん mailto:sage [2012/06/22(金) 23:11:19.12 ]
- >どうやって作ったかの資料が必要。
はあああああああああああああああああああああああああああああああ
ソースが読めません系？
- 636 名前：仕様書無しさん mailto:sage [2012/06/23(土) 00:08:18.24 ]
- >>635
なんで資料残しとけば節約できた無駄な工数かけてまでソースを解読しないといけないんだよ。
趣味でやってるんならソース読めで済ませられるけど、職業人でそんな態度なら初心者だね。
- 637 名前：仕様書無しさん mailto:sage [2012/06/23(土) 00:14:10.78 ]
- ソースが読めないから工数がかかるって言ってるような
- 638 名前：仕様書無しさん mailto:sage [2012/06/23(土) 00:36:50.60 ]
- ソースしかないけどよろしくっていうプロジェクトの場合、
普通システム解析の工数を計上するだろ。
工数計上しなくて済むのは、数千行程度の極小さなプログラムのときくらい。
- 639 名前：仕様書無しさん mailto:sage [2012/06/23(土) 00:38:42.65 ]
- 読めないのに、ソースの間違い探しができるのかい？
- 640 名前：仕様書無しさん mailto:sage [2012/06/23(土) 00:42:17.75 ]
- うん、ソース読めるからソース読む工数を計上してるんだね。
- 641 名前：仕様書無しさん mailto:sage [2012/06/23(土) 02:22:41.06 ]
- 書けるのに読めません系が作る完成後の資料ってどういう内容なんだろうね？
読めません系が集団の職場って？
- 642 名前：仕様書無しさん mailto:sage [2012/06/23(土) 13:10:25.03 ]
- >>641
世の中には驚くほど文章を読めない人が多い。2chの3行以上のレスは
読まないってのがネタじゃなくてマジな奴が普通にいるし、Twitterの
140文字ですら読めてるか怪しい人が数多くいる。
- 643 名前：仕様書無しさん mailto:sage [2012/06/23(土) 16:20:17.99 ]
- 仕様書に明記してあれば数分で済むロジックの目的を、
ソースコード上から解析して文章としての仕様にデコードするのは、面倒なケースも多いぞ
ソースと実装が異なる可能性があるから最終的にはコードを見る必要はあるとしても
それがバグなのか仕様どおりの実装なのかは、コードでしか表現されてないと判断つかない
UTがちゃんと作成されているなら別だが、
日本の土方系プロジェクトでちゃんとしたテストコードを作れてるものなんてかなりレアだし
それが出来てるところはちゃんとした仕様書、設計書に値するドキュメントもある
- 644 名前：仕様書無しさん mailto:sage [2012/06/23(土) 16:27:15.12 ]
- >>643
仕様的に欲しいのは入力に対する結果であって経緯ではないから。
- 645 名前：仕様書無しさん [2012/06/23(土) 16:31:17.44 ]
- そもそも、有用なドキュメント残せないようなプロジェクトのコード自体信用できるわけねーしな。
何をやりたかったかっていう目的はにコードだけじゃ判別つかん。
コードが絶対だ、既存だからバグじゃないっていう、糞コーダーの言い訳と同じ。
- 646 名前：仕様書無しさん mailto:sage [2012/06/23(土) 17:24:21.80 ]
- なぜ、仕様書作成に時間を割きながらして、ソースコードはスパゲッティなのかが腑に落ちない。
設計からしてめちゃくちゃな可能性があるけど。
- 647 名前：仕様書無しさん mailto:sage [2012/06/23(土) 17:35:09.87 ]
- 単純な話で、何の意識合わせもなく多人数で手分けしてつくるからだよ。
- 648 名前：仕様書無しさん [2012/06/23(土) 18:03:33.39 ]
- スパゲッティになるのは単純に知識不足だと思うな。興味が持てないから知識が増えないんだろうけど
好きこそ物の上手なれってやつ
よくある系のアルゴリズムについての知識だったり、言語仕様的な通例や制約をしっているかどうかだったり、
デザインパターンみたいなのを知ってるかどうかだったり、こういう差がスパゲッティを作らないうえで重要だと思う
経験から、どう書いてあると後から見るのが大変か、どうなってると後から修正とかしやすいか
なんかを学んでいくだけでもマシにはなるけど、職場が同じようなレベルのとこばっかだと
視野が狭いままで、そんなに学べることは多くない場合が多い
仕様書設計書の話題ではないけどなｗ
- 649 名前：仕様書無しさん mailto:sage [2012/06/23(土) 18:13:52.30 ]
- スパゲッティになるのは仕様書作成に時間を掛けすぎて、
ソースコードを書く時間が足りないからだよ。
本来なら十分な時間を掛けて、
ソース設計→ソースコードを書く→リファクタリングをやらないといけないのに、
スキルに対して納期が短すぎて「ソースコードを書く」部分だけをするから
スパゲッティになるのは必然。
- 650 名前：仕様書無しさん mailto:sage [2012/06/23(土) 20:56:29.84 ]
- ソース設計ってより
何作るかわかってないから、ワケワカになるじゃね
問題に対する読解力が足りないと数学解けないのと同じ感じ？
- 651 名前：仕様書無しさん mailto:sage [2012/06/23(土) 23:02:28.11 ]
- 仕様書作りとコーディングが同時に動いてる現場って少なくないけど
そういうのに放り込まれると、本当このEXCEL方眼紙に書きなぐってるものは何なんだろうなって思う
- 652 名前：仕様書無しさん mailto:sage [2012/06/23(土) 23:39:07.55 ]
- クソ仕様書から正確な仕様書を書く作業から始まる
- 653 名前：仕様書無しさん mailto:sage [2012/06/24(日) 01:08:52.21 ]
- 昔からバグのまったく無いプログラムは作れないといわれているが、
実際には、バグのまったく無いプログラムは見たことあるが、
バグのまったく無い仕様書は見たこと無いw
- 654 名前：仕様書無しさん mailto:sage [2012/06/24(日) 01:23:50.99 ]
- >>652
地味にそういう事からやるほうがいいんじゃね
余裕があるならコーディングしながら矛盾点を洗い出していくとか
- 655 名前：仕様書無しさん mailto:sage [2012/06/24(日) 03:30:05.08 ]
- >>652
だいたいそれやってるけど、必ず既存のバグ見つかってアレ
- 656 名前：仕様書無しさん mailto:sage [2012/06/24(日) 10:19:20.59 ]
- >>655
たしかにそうだけど、それは仕様書再作成作業による机上バグ摘出という成果であると
前向きに考えているよ
- 657 名前：仕様書無しさん mailto:sage [2012/06/24(日) 14:32:24.06 ]
- >>656
コンパイラができること（エラーチェック）を脳内でヤルわけですね？
- 658 名前：仕様書無しさん mailto:sage [2012/06/24(日) 14:41:26.41 ]
- コンパイルできることと、バグが無いことは違うよ？
- 659 名前：仕様書無しさん mailto:sage [2012/06/24(日) 14:49:36.03 ]
- テストがあることと
バグがないことも違うよ。
- 660 名前：仕様書無しさん mailto:sage [2012/06/24(日) 15:39:55.23 ]
- >>657
何を言いたいのか意味不明なんだが、もしかすると>>657はコードと
一対一に対応するような設計書(仕様書???)を書いているのか？
それとも>>657のコンパイラとは、
Z/VDM/CSPのような形式的仕様記述言語の検証系を指しているのかな？
まさかコンパイラが(構文エラー以外の)論理的なバグまで検出できると本気で思っているの？
訳が分からんわwww
- 661 名前：仕様書無しさん mailto:sage [2012/06/24(日) 15:51:32.09 ]
- >>660
”コンパイラができること” ってちゃんと書いてますよね？
コンパイラができないことが、コンパイラできるなんて
どうしてそんな変なことを言い出してるの？
- 662 名前：仕様書無しさん mailto:sage [2012/06/24(日) 16:17:42.24 ]
- >>661
>”コンパイラができること” ってちゃんと書いてますよね？
>>657では、「ちゃんと」書いているつもりなのか？
自分は、”コンパイラができることを” とは構文エラー検査であり、
"脳内でヤル" とは(>>656の)仕様書再作成作業のことだと解釈し、
「構文エラー検査を仕様書作成作業内でヤル」という>>657の発想が意味不明だと>>660で書いた
もしもこの解釈が間違っていたのなら教えて下さいませ
あと、仕様書再作成作業の前に全コードをコンパイル通過させておくのは、常識だと考えているよ
- 663 名前：仕様書無しさん mailto:sage [2012/06/24(日) 19:37:25.95 ]
- コンパル時にエラー出ても読まない、わからない人が仕様書書くことがあるからね
- 664 名前：仕様書無しさん mailto:sage [2012/06/24(日) 19:38:10.50 ]
- ×コンパル時
○コンパイル時
- 665 名前：仕様書無しさん mailto:sage [2012/06/24(日) 20:25:56.27 ]
- こんぱそ時
- 666 名前：仕様書無しさん mailto:sage [2012/06/24(日) 23:39:28.20 ]
- >>663
それって>>657のことかしら？
- 667 名前：仕様書無しさん mailto:sage [2012/06/24(日) 23:46:19.00 ]
- リアル会社でそういう人がいたんですよ
コンパイルのエラーって何？
って、感じの人が
- 668 名前：仕様書無しさん mailto:sage [2012/06/25(月) 06:24:49.76 ]
- またまたご冗談を
- 669 名前：仕様書無しさん mailto:sage [2012/06/25(月) 06:43:59.74 ]
- PC触ったことない、持ってないようなのも
口がうまければ普通に入ってくる業界だからな
- 670 名前：仕様書無しさん mailto:sage [2012/06/25(月) 20:56:34.12 ]
- 20世紀末ごろのエラーメッセージが英語の頃はなにそれが普通だった
エラーメッセージが日本語化されてもなにそれは状態な人がいっぱいいそうだけど
- 671 名前：仕様書無しさん mailto:sage [2012/06/26(火) 02:43:52.29 ]
- エラー出た、で思考停止する馬鹿は結構いるぞ
まじ辞めればいいと思うわ…
- 672 名前：仕様書無しさん mailto:sage [2012/06/30(土) 03:05:17.20 ]
- 工数稼ぐためにそういう人達が完成図書みたいなの作ってるんかね
- 673 名前：仕様書無しさん mailto:sage [2012/06/30(土) 21:27:28.45 ]
- >>671
赤バッテンのアイコンでエラー表示するとパニクって思考停止するヤツが
後を絶たないので黄色の警告アイコンにしてやったwwww
- 674 名前：仕様書無しさん mailto:sage [2012/06/30(土) 21:32:56.59 ]
- シイタケ？
- 675 名前：仕様書無しさん mailto:sage [2012/07/03(火) 02:36:38.73 ]
- ｢我々は高い技術力を持っている｣｢業務ソフトを開発した経験がないとわからないだろ｣が口癖のガイキチは、
グローバル変数とローカル変数の違いもわからず、
それこそプログラマ1年目でも小学生でも簡単に作れるようなサンプルプログラムを作らせてみたら
思った通り一目で動作しないとわかるものを出して来やがった。
- 676 名前：仕様書無しさん mailto:sage [2012/07/03(火) 20:31:28.12 ]
- 資料だって言ってる割には、時代についていってないような書き方だけが伝承されてるだけだったりして
- 677 名前：仕様書無しさん mailto:sage [2012/07/13(金) 01:47:24.24 ]
- ＞仕様書再作成作業の前に全コードをコンパイル通過させておくのは、常識
何言ってんだこいつ。
- 678 名前：仕様書無しさん mailto:sage [2012/08/22(水) 00:52:30.02 ]
- メンテナンス出来ない/しにくい仕様書はいらんな〜
- 679 名前：仕様書無しさん [2012/08/23(木) 17:15:51.25 ]
- うちの画面仕様書びっくりするほど横長だった。UXGA×2枚、SXGA×1枚でおさまりきらない。
書くのも大変だけど見るというか読むのも大変そうだ。
- 680 名前：仕様書無しさん mailto:sage [2012/08/23(木) 19:05:10.57 ]
- まるでWindows8のスタート画面みたいだな。
- 681 名前：仕様書無しさん [2012/08/24(金) 00:27:36.99 ]
- 今日気がついた。仕様書を書いてるときってかなりコピペしてる。
似たような記述が仕様書にいっぱいちりばめられてる。
仕様変更時にこれを全部メンテする自信はまったくない。
- 682 名前：仕様書無しさん mailto:sage [2012/08/24(金) 13:14:29.14 ]
- ソースコードの解読が容易な案件は仕様書なくていい。
糞みたいなソースコードの案件は、仕様書も糞。
仕様書いらね。
- 683 名前：仕様書無しさん mailto:sage [2012/08/25(土) 00:01:23.36 ]
- >>682
ソースコードの解読が容易だが
バグが含まれているコードの場合はどうなるんだ？
- 684 名前：仕様書無しさん [2012/08/28(火) 18:59:19.16 ]
- >>678
メンテしやすい仕様書ってどうやったらできるんだろう？
- 685 名前：仕様書無しさん mailto:sage [2012/08/28(火) 19:46:59.05 ]
- 使うためのマニュアルをメンテとかならわかるんだけど
プログラムのプの字もわからんでもやれる虎の巻みたいなのが欲しいだけなのかな
- 686 名前：仕様書無しさん mailto:sage [2012/08/28(火) 20:12:03.95 ]
- 仕様書は上司と実際に作った俺の頭の中にしかなく、
しかも上司が実装可能と考えていた仕様はほとんど実装不可能で、大幅に改変せざるを得なかった。
にもかかわらず上司の初期構想の仕様書しかなく、俺にはそんな時間はなかったため
引き継いだ奴らが実装をわからずメンテナンスしたためにとんでもないスパゲティに。
コメント文で仕様書の実装は不可能なのでこう実装したと全て書いたんだけどなあ。
- 687 名前：仕様書無しさん [2012/08/30(木) 09:18:06.05 ]
- >>685
仕様変更あったときに楽に間違いなく書き直せる仕様書であってほしいってことじゃね？
- 688 名前：仕様書無しさん mailto:sage [2012/08/30(木) 16:05:00.50 ]
- >>687
仕様書直したら、ソースが直ると、思ってるとか？
- 689 名前：仕様書無しさん mailto:sage [2012/08/30(木) 16:07:07.41 ]
- 回路図方面の解説書とか見たことないなあ
見れるのは図面とやれることが書いてあるもんぐらい
- 690 名前：仕様書無しさん [2012/08/30(木) 16:12:05.41 ]
- ソース直してると仕様の漏れが山ほど見つかる。
フィードバックするのもめんどくさいぐらいに。
- 691 名前：仕様書無しさん mailto:sage [2012/08/30(木) 19:01:44.84 ]
- >>684
う〜ん、難しいんだよね。
いま社内で仕様書の標準/統一化を進めてるんだけど、一向に進まないし…
確実に統一できそうなものは目次、表紙だけだわw
そもそも仕様書って誰のためのもの？プログラマ？ユーザー？上司？
ここをまず明確にすべきだと思うな〜
それによって、どう書いていった方がメンテナンスしやすいかが定まってくると思う
けど、これも難しいんだよね〜。あぁ死にたい。
- 692 名前：仕様書無しさん mailto:sage [2012/08/30(木) 19:48:40.68 ]
- ソースの中身を検証できるようにするほうがよくねえか？
客、上司に媚びうる資料でもうけようってのならわかるけど
- 693 名前：仕様書無しさん mailto:sage [2012/08/30(木) 20:15:15.09 ]
- >>691
> そもそも仕様書って誰のためのもの？プログラマ？ユーザー？上司？
一つで済まそうとせずに、それぞれ書き分けたほうがいい。
- 694 名前：仕様書無しさん [2012/08/30(木) 20:49:05.16 ]
- 書き分けるとそれぞれの内容が整合しなくてどこかでモメることになりそうな悪寒
- 695 名前：仕様書無しさん mailto:sage [2012/08/30(木) 20:50:24.03 ]
- 分けるにしても
どう分けるか考えんと
- 696 名前：仕様書無しさん mailto:sage [2012/08/30(木) 22:25:35.19 ]
- >>691
＞そもそも仕様書って誰のためのもの？プログラマ？ユーザー？上司？
引き継ぎをする人のためのものだよ。 客側、開発側関係なく開発時に
いなかった人間に対して、5W1Hじゃないけどソースを読んだだけじゃ
分からない、ソースを読まなくても最低限のことが分かることが書いて
あればいい。 逆に言うと、ずっと生き字引並にシステムに精通したのが
面倒見てくれるなら仕様書なんていらない。
- 697 名前：仕様書無しさん mailto:sage [2012/08/30(木) 22:52:23.45 ]
- 受験の虎の巻みたいなのが欲しいだけでしょ
- 698 名前：仕様書無しさん mailto:sage [2012/08/31(金) 01:19:12.12 ]
- ソースの改定記録残したほうが下手な完成図書作るよりマシだろうに
- 699 名前：仕様書無しさん mailto:sage [2012/08/31(金) 02:06:46.95 ]
- >>697
受験の問題には正解があるけど
仕様書には正解はないからな。
他人の考えや決めたルールを知るには仕様書が必要。
- 700 名前：仕様書無しさん mailto:sage [2012/08/31(金) 02:47:08.70 ]
- >>698
残すも何も、普通はVSSやCVS、Gitなんかのソースコード管理を使うはずで、
よっぽどアホなことしない限りは履歴は残る。
まあ、そのアホなことをする企業は少なからずあるし、小さい企業より
日常的に使わない大企業のSヨさんとかがやらかしてくれるけどね。
なんでSCM使ってるのに紙で別出しで台帳管理をしようとするかな、、、
- 701 名前：仕様書無しさん mailto:sage [2012/08/31(金) 10:05:42.42 ]
- ソースコード管理すると言ってる人が
実はソース読めませんというオチが
- 702 名前：仕様書無しさん mailto:sage [2012/08/31(金) 12:25:05.09 ]
- > なんでSCM使ってるのに紙で別出しで台帳管理をしようとするかな、、、
台帳管理を仕事としてる人の仕事を奪っちゃいけません。
- 703 名前：仕様書無しさん mailto:sage [2012/08/31(金) 20:01:57.98 ]
- 紙で承認受けないと管理したことにならない社内標準があるんだよ。
勘弁してくれ。
- 704 名前：仕様書無しさん mailto:sage [2012/08/31(金) 20:32:11.37 ]
- 電子データになってるのを知らない老害がいるの？
- 705 名前：仕様書無しさん mailto:sage [2012/08/31(金) 21:31:51.33 ]
- もうボケが始まってて、現代でもパンチカードでプログラム書いてると思ってるんだよ
- 706 名前：仕様書無しさん mailto:sage [2012/09/01(土) 07:15:19.81 ]
- 電子データは見方が判らんし、変更しても判らない。
紙で自分のサインがある書類がなきゃ信用しない老害は多い。
そしてそんな老害は、紙の2ページ目以降が丸ごと差し代わっていることを知らない。
- 707 名前：仕様書名無しさん mailto:sage [2012/09/01(土) 11:33:55.42 ]
- >>691
仕様書の標準化をする上で必ず議題となるのは、
•設計情報の網羅性
•誰が書いても同じ物になる記述レベルの統一性
•ドキュメント間の整合性
•ドキュメントのメンテナンス性
•作成コストおよび作成時間
•納品物件としての仕様書要求レベル
•設計するためのドキュメント
•プログラマーのためのドキュメント
•保守のためのドキュメント
•読ませる奴の技術レベル
•ドキュメント作る奴の技術レベル
•実際ドキュメントがいい加減でもプログラムはちゃんと出来たりする。
これらを考えると、結局みんなが幸せになる標準化なんて不可能って早々に気づく•••
- 708 名前：仕様書無しさん mailto:sage [2012/09/01(土) 16:51:17.22 ]
- 盗撮して御用になる元IBM社長みたいな老害がいっぱいの世の中
- 709 名前：仕様書無しさん mailto:sage [2012/09/02(日) 03:17:23.15 ]
- 大手ほど無能も多いからなー
なまじ職場は同じなだけに、技術職との開発業務に対する温度差が激しい
結局、出来ること出来ないことを理解してない層は調整とかそういうのは無理なんよ
ノウハウがないなら勉強しないといけないけど、そういうのしないでもなーなーでやって桁利するから、余計に成長しない
ドキュメントが詳細に必要になるのは、客と開発の間に人が無駄に入りすぎるせいだわなー
- 710 名前：仕様書無しさん mailto:sage [2012/09/02(日) 03:18:44.51 ]
- なまじ職場は同じなだけに、同じような仕事に見られるけど
実際に作ってる技術職してる人と、客とのやり取りだったりドキュメント弄繰り回したりする人とだと、
開発業務って部分に対する興味の温度差が激しい
訂正しようとしてたら書き込み押してしまったよ('`)
- 711 名前：仕様書無しさん mailto:sage [2012/09/02(日) 06:27:16.93 ]
- ちょっとスレ違い気味になるけど、日本の役所はいい加減ウォーターフォールに固執するの止めて欲しい。
役所の仕様基準の元がMILなのは良いけど、そのMILは30年以上前に改訂されとっくに廃止されてる。
かなり前からプロトタイプ推奨に変わったし、今はアジャイルやスパイラル前提だ。
ウォーターフォールの失敗を認めて非推奨にしてる。
で、アジャイル以降の場合、ドキュメントの自動化が必須なんだ。
そんな細かな修正、いちいち直してらんないから。
なのにウォーターフォールと手で作ったドキュメント求め続ける役所。
見積りの精査も出来ず、高々100行程度の改修で億払うって、ほんとバカしか居ない。
- 712 名前：仕様書無しさん mailto:sage [2012/09/02(日) 06:38:20.92 ]
- > このため現実のウォーターフォール・モデルの開発プロジェクトでは、
> 前工程の完了要件（要件定義局面であれば、要件定義書などの成果物の完成）を
> 徹底して品質を高め、後戻りの発生率を可能な限り低下させるとともに、
> 後戻りが発生する場合は変更管理によって公式に決定し、
> 後戻りや横展開を確実にフォローする。
２０年前ぐらいなら通用した考え方だね
今の情報量は半端じゃないからね
> 要件定義
って、うるさい文系院卒がいたけど
今のコンピュータのことが全然わかってなかった
今だに、非力なパソコンの流行りはじめの事例が通用するとか思ってるんかね
時代についていけてない人は...
紙の上で終わらせたいとか？
- 713 名前：仕様書無しさん mailto:sage [2012/09/02(日) 07:12:36.41 ]
- 昔はのんびりと時間がかけられたからね。
例えば一年単位でプロジェクトを回しているところとかだと、
プログラマに仕事が回ってくるのは年度の後半(10月とか11月〜)だったり
したもんだ。SEはそれまでに半年かけて文書の作成をやってればよかった。
ところが、今みたいに同じ作業を3〜4ヶ月で終わらせないといけない状況だと、
文書化とコード作成を同時並行で動かさないといけないわ、期間が短い分
精度が落ちてるから手戻りが増えてるわ(しかも、ウォーターフォールだと
手戻りがやたら面倒くさい管理方法とってるから大変)で、破綻してるんだよね。
- 714 名前：仕様書無しさん mailto:sage [2012/09/02(日) 07:28:41.54 ]
- 無理に短納期にして、自分の首絞めてるだけでしょ
人月計算が時代に合わなくなってきてる？
- 715 名前：仕様書無しさん mailto:sage [2012/09/03(月) 02:37:04.18 ]
- 客と作り手の間に挟まる人数をもっと減らすしかない
- 716 名前：仕様書無しさん mailto:sage [2012/09/03(月) 03:02:52.38 ]
- 大手から下請けにっていう構図があれなんだよな
リスク回避のための保険という意味はわかるんだけど
無駄を無駄だって言える人がいればなぁ
- 717 名前：仕様書無しさん mailto:sage [2012/09/03(月) 03:05:20.03 ]
- 大手が下請けって思いたいだけなの、今や
下請けいじめとかTVで報道されて恥ずかしくないのかね、大手系
- 718 名前：仕様書無しさん mailto:sage [2012/09/03(月) 18:12:13.96 ]
- 大手とか関係なく、自社に人が確保出来ないってのは大きいよ。
常に人を確保出来るほどの仕事がある会社は少ないから、必要な時に集める。
実際、土方と同じ理由だよね。
- 719 名前：仕様書無しさん mailto:sage [2012/09/03(月) 20:22:23.42 ]
- 人海戦術が通用しなくなってきてるから、困ってんじゃないの？
短納期にこだわりすぎて
短期で仕様と設計まとめれる人いるんかい
- 720 名前：仕様書無しさん mailto:sage [2012/09/04(火) 06:48:07.12 ]
- 色々無理のある業界だよね。
本当に設計を纏められる人は一握り。
なのに短期間でのウォーターフォールだから、ドキュメントすら作るのに精一杯。
そこにレベルの下がる派遣かき集めても、OJTする時間すらない。
しかも見積りは人月の数字を舐めさえすれば安くなるから営業は無理な案件でも取ってくる。
せめて、プロトタイプ手法でも使えれば、少数精鋭でプロトタイプ作った後、レベルの下がる派遣に展開する手が使えるのに。
- 721 名前：仕様書無しさん [2012/09/05(水) 16:42:22.18 ]
- 人海戦術でのソフト開発は、映画作りに似てるね？
原作という要件書があっても
監督のアタマの中のイメージと絵コンテを頼りに
セット制作を指示し、本番突入で何とか試行錯誤で
作り上げる。
映画と違う点は、その後も山のようなバグ取りと運用サポートに忙殺される。
- 722 名前：仕様書無しさん mailto:sage [2012/09/05(水) 21:00:16.80 ]
- マとSEは時間少なすぎて、残業まみれでしまいに頭おかしくなって
客はバグまみれでちょっと動かすと落ちたり計算結果が狂うシステムにイライラして
携わった人間だけをみると、Lose-Loseな状態だよなあ。こんなITで誰か幸せになってんのか？
- 723 名前：仕様書無しさん mailto:sage [2012/09/05(水) 23:08:08.10 ]
- 余裕のない状況作って、実は喜んでる人がいたりするのがなんとも
- 724 名前：仕様書無しさん mailto:sage [2012/09/06(木) 00:42:28.17 ]
- 安かろう悪かろうの需要がまだあるうちは何とかなるだろうけど、未来はないよね
- 725 名前：仕様書無しさん mailto:sage [2012/09/06(木) 01:18:00.25 ]
- 今の状況がわかってない人達が、自分で自分の首を絞めてるだけ？
- 726 名前：仕様書無しさん [2012/09/06(木) 06:06:54.00 ]
- >>722
ろくな仕事もないのに仕事をした振りできる公益法人やら天下り団体の職員が喜ぶんですよね。
そういう予算だけはあるけど仕事がないところがなんでもかんでも発注するし、
使い勝手とか機能とかがでたらめな内容で発注しまくるものだから
システム開発する側もろくなものを作らず、
結果として無能の再生産をする。
- 727 名前：仕様書無しさん [2012/09/06(木) 08:08:29.54 ]
- 基本も詳細も設計書は顧客向けに出すものではなく、V字モデルのテスト設計資料として活用するもの
そうやれてる企業は存在しないけどｗ
顧客向けなんてマニュアルと営業パワポでいい
- 728 名前：仕様書無しさん [2012/09/08(土) 11:30:54.54 ]
- このスレダメすぎ。
仕様書、設計書、言ってる地点でアウトなんだよ。
いいかげん、ウォーターフォールを滅ぼさないと日本が滅びる。
- 729 名前：仕様書無しさん mailto:sage [2012/09/08(土) 11:50:04.08 ]
- 顧客
↓
マニュアル
↓
結合テスト
↓
単体テスト
↓
コーディング
↓
仕様書
どうしてもウォーターフォールやりたいなら、こういう順序がいいと思うよ、本気で。
- 730 名前：仕様書無しさん [2012/09/08(土) 12:11:47.34 ]
- 「コードもないのにどうやって結合テストするの？」
とか言ってんの、もうねアホかとバカかと。
これはソフトだけの話じゃないんだよ、ハードだって開発はそういうもんなんだよ。
車の開発をしようとしたら、まずテストコースを準備する。
開発チームごとニュルに行く。
そこから始まる。当たり前の話。
- 731 名前：仕様書無しさん mailto:sage [2012/09/08(土) 12:41:35.07 ]
- テストコースなんてどこにでもあるじゃん。
俺なんか公道でドリフトの練習しまくったよ。
字乞田けど。
- 732 名前：仕様書無しさん mailto:sage [2012/09/08(土) 13:52:16.21 ]
- ツーホー
- 733 名前：仕様書無しさん mailto:sage [2012/09/08(土) 13:52:42.14 ]
- 面白いと思って言ってるんだろうから、そっとしておいてあげような
- 734 名前：仕様書無しさん mailto:sage [2012/09/08(土) 15:11:28.44 ]
- 「どこにでもある」
つまり、顧客環境＝開発環境が当たり前の場合、
理論と実際の誤差が生じていてもなんとかなってるんだ。
逆に、特殊環境で動かさなければならないソフトの場合だ。
そのエミュレータを手前に準備しなければコーディングしにくい。
「当たり前にないテスト環境を整えることを先にやらなければならない」
この手順を突き詰めると、ウォーターフォールの誤謬に直面する。
そこから、テスト・ファーストという考えに辿りつく。
- 735 名前：仕様書無しさん mailto:sage [2012/09/08(土) 15:30:21.57 ]
- > そのエミュレータを手前に準備しなければコーディングしにくい。
そんな事情は考慮しない。設計どおりのコーディングをすれば、
問題なく動くコードが出きるはずだ。
- 736 名前：仕様書無しさん [2012/09/08(土) 15:50:09.51 ]
- >>735
それは、ベテランの人間が小規模なプロジェクトをクリアする場合には当てはまる。
それ以上にはならない。
普通レベルの人間に真似させられないだけでなく、
高品質なプログラムにならない。
結果、顧客のダメだし確率も上がり、開発期間短縮にもならない。
リスクが高いので、趣味の範囲にとどめるべき手法だといえる。
- 737 名前：仕様書無しさん mailto:sage [2012/09/08(土) 17:56:39.57 ]
- よく、アジャイルは、ウォーターフォールを細かく繰り返すことだと言うけれど、
その認識じゃー、うまくいかないに決まってる。
なぜなら、ウォーターフォールモデルの手順自体が真逆だから。
>>729が正しい順序なのである。
それで、アジャイルがうまくいかないと嘆くことになるんだが、
ウォーターフォールの根源的問題を繰り返したら、
もっとうまくいかなくなるのは当たり前。
- 738 名前：仕様書無しさん mailto:sage [2012/09/08(土) 18:38:52.54 ]
- ボトムアップ的なやり方だけじゃダメじゃね
ボトムアップとトップダウンを混ぜたようなやり方のほうが
- 739 名前：仕様書無しさん [2012/09/08(土) 20:07:59.54 ]
- 顧客←────┐
↓ │
マニュアル←─-┤
↓ │
結合テスト←─-┤
↓ │
単体テスト←─-┤
↓ │
コーディング─→┤
↓ │
詳細設計──→┤
↓ │
基本設計──→┤
↓ │
要求定義──→┘
トップダウンとボトムアップはそうなんだけど、
実際的な流れをより明確にするとこうなる。
テスト⇔コーディングが日常。
より大枠のところで、バージョンアップだ。
- 740 名前：仕様書無しさん mailto:sage [2012/09/08(土) 20:11:22.02 ]
- >>739
試行錯誤が抜けてる。
全く同じ物のパラメータ違いを
作るなら話は別だけど、
プログラムで同じものは作らない
（自動生成すればいいから）
となると、ほとんどが新しいものであり、
試行錯誤しないと実現可能であるかもわからないものがある。
やってみて（コーディングしてみて）、この方法はダメだから
違う方法にするというのはよくある話。
そういう試行錯誤コーディングで
いちいちテストなんてやっても無駄。
- 741 名前：仕様書無しさん [2012/09/08(土) 20:29:03.63 ]
- >>740
テスト⇔コーディングが試行錯誤だよ？
というか、試行錯誤のコーディングでテストをやらない？
なんて、嘆かわしい。
むしろ、そこはTDDを絶対オススメしたい。
- 742 名前：仕様書無しさん mailto:sage [2012/09/08(土) 20:47:43.94 ]
- 基本的にはテストケース考えながら、作り込む方だな、俺は
底辺部分はテストケースはわりと考えなくてもいいんだけど
中間部分はテストケースを考えながらやるし、単体テストもやりやすい
上位部分は流してみないとわからないから、ラフに作って
全体流すときに徹底的につぶすほうかな
要求が一般的なわりと知られてるやり方が出来るのは
先に設計書作れってうるさいみたいだね
- 743 名前：仕様書無しさん mailto:sage [2012/09/08(土) 21:32:23.97 ]
- >>742
「テストケース考えながら」って、リストをエクセルなんかで書きなぐりながらってこと？
実行しながらじゃなく？
- 744 名前：仕様書無しさん mailto:sage [2012/09/08(土) 21:43:20.95 ]
- え、分岐のないやつしかやったことないの？
- 745 名前：仕様書無しさん [2012/09/08(土) 21:56:30.34 ]
- テスト駆動の話なんだけど、テスト用プログラム、走らせてる？
慣れると楽だよ。ある程度使いまわせるし。
なにより、脳内シミュでは完璧だったのに、バグがはじき出される時ある。
焦るけどホッとする。
そして、性能テストも同時にやっちゃう。
劇的な速度増加手段がそこで発見できることもある。
絶対いい。
テスト用プログラムっていっても、うまく作る必要なんか全然なくてさ、
つーか、統合開発環境がすでにテストプログラムなわけだし、
誰でも無意識にやってるはずのものなんだよね。
それを意識的に、プロジェクトフォルダの中には必ずテストソース入れるフォルダも作る。
で、なれると、テストコードを先に作った方がいいことに気づく。
結合テスト←─-┤
↓ │
単体テスト←─-┤
↓ │
コーディング─→┤
結合テストから入るってのは、C言語なら最初main()作って動かす。
PHPならZAMPP入れて動かす。
ただ、それだけのもの。出力真っ白、それがバージョン0.01
それをやるべき。つーか誰でもやってる。当たり前の話。
- 746 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:08:12.21 ]
- >>739 続き
どうして要求定義が一番最後なのか？
顧客ヒアリングの段階でまとめなければいけないのではないか？
もうね、アホかとバカかと。
例えば、「wordのドキュメントをそのままwebページにしてくれ」と
顧客が言ってくるとする。
はいはいと言って、見積もって基本設計やって
そして、・・・その要求が不可能なことに「途中で」気づくのだ！
もちろん、これはごく単純な例で最初の段階で無理だと断れるパターンだが、
実際問題、コーディングをちょっとやってみないと、
どんな要求が実際消化できるかわからない！（そして正確な見積も！）
そういうときは、正直に一巡するまで待ってもらう。
もしくはその顧客はあきらめ、次のために研究しておくべきだ。
それを、顧客即要求定義みたいに書くから、それが可能であると
勘違いされてしまう。これは深刻なミステイクだ。
後から顧客に怒鳴られ減額されるのは本当に嫌なものだ！
- 747 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:08:27.74 ]
- > 当たり前の話
?
- 748 名前：仕様書無しさん [2012/09/08(土) 22:32:38.48 ]
- 当たり前の話！
ウォーターフォール滅びろ！
みんな迷惑してる！
- 749 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:37:38.90 ]
- その手の流れにもってくと、勘違いする人が出るような
当たり前だと思ってるだけで、実際にやってる人が...
- 750 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:43:31.84 ]
- テスト書く為に早出、退行テストとベンチマークの為にサー残するならやっていいよ。つまり時間外でやれ
みたいなのだから一向に流行らん
それでもやるのが何人かいるのだけがまだ救いか
- 751 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:45:38.41 ]
- 時間で働いてる人に効率化とか無いですから
- 752 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:50:00.81 ]
- >>741
> テスト⇔コーディングが試行錯誤だよ？
> というか、試行錯誤のコーディングでテストをやらない？
やらない。テストの工数ってのをちゃんと意識していれば、
とてもやろうとは思わない。
試行錯誤ってのは、何度も仕様に修正が入るということ。
つまり、テストもそれだけ修正が入るということ。
テストがあればリグレッションを防げるが
試行錯誤中はリグレッションを防げない。
なぜなら仕様が変わるからテストが失敗するのがほとんど。
だからそんな状態では人間が流行ったほうが早い。
- 753 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:52:41.52 ]
- 工数稼ぎのためにまともそうに書いてるだけですから
- 754 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:57:11.69 ]
- 一生懸命やってますアピールしても土方の保身には全く役に立たないからね
- 755 名前：仕様書無しさん [2012/09/08(土) 23:04:23.41 ]
- >>752
そこまでカオスな研究段階だったそうだろうか。
それでも、可能な限りテストプログラムの稼働、テスト環境の整備、
テストデータの自動生成など提案したいが・・・
テスト工数は多くなっても自動化すれば、トイレ行ってる間に終わるからな。
- 756 名前：仕様書無しさん mailto:sage [2012/09/08(土) 23:26:13.67 ]
- > テスト工数は多くなっても自動化すれば、トイレ行ってる間に終わるからな。
どんだけ少ないんだ？
極端な例を出せば、網羅テストなんかやると
数年単位の時間がかかって現実的ではない。
必要ないテストを省くなどして、
どうやってテスト時間を短くするか考えなきゃならないのに。
- 757 名前：仕様書無しさん mailto:sage [2012/09/08(土) 23:30:14.81 ]
- >>756
そこまでタイトな網羅テストが必要なプログラムかよ！
そんなの知らねーな、今は一般的な話しをしているのだ。
- 758 名前：仕様書無しさん mailto:sage [2012/09/08(土) 23:31:31.81 ]
- テストがテストになっているかをテストするためのテストで今忙しい
- 759 名前：仕様書無しさん mailto:sage [2012/09/08(土) 23:36:16.58 ]
- TDDのテストは品質保証が目的ではないいう流儀か
そういう類のテストを工数稼ぎと看做す場では受け入れられんだろうな
- 760 名前：仕様書無しさん mailto:sage [2012/09/08(土) 23:36:43.91 ]
- 自己採点が基本でしょ、プログラム系は
受験みたいに点数つけてくれる人はいない
書いて終わりじゃないところが、紙の試験とは違う
- 761 名前：仕様書無しさん mailto:sage [2012/09/08(土) 23:41:28.27 ]
- 自己採点でクビか契約更新かを決めれたらいいのにね
- 762 名前：仕様書無しさん mailto:sage [2012/09/08(土) 23:43:24.26 ]
- > クビか契約更新か
それは、人が人を判断してるってことでしょ
- 763 名前：仕様書無しさん mailto:sage [2012/09/08(土) 23:58:01.12 ]
- なぁんだ
なぁんだとはなんだ
なんだとはなんだとはなんだ
なんだとはなんだとはなんだとはなんだ
オペレーターズサイドもいっかいやってみようっと。あれ？マイクどこにしまったかなぁ・・・
- 764 名前：仕様書無しさん mailto:sage [2012/09/08(土) 23:59:02.33 ]
- >>756
テストしたことないでしょ。
- 765 名前：仕様書無しさん mailto:sage [2012/09/09(日) 00:01:40.83 ]
- 雇用側とかの認識がおかしいから、人集めるにしても、とんでもになってるとか
- 766 名前：仕様書無しさん mailto:sage [2012/09/09(日) 00:12:03.67 ]
- >>764
テストしたことないでしょ？
スローテストって言葉知ってる？
テストが短時間で終わるためには、
短時間で終わるように工夫しなきゃいけないんだよ。
自動化すればすぐに終わる？
アホだな。
銀の弾丸はない。
- 767 名前：仕様書無しさん mailto:sage [2012/09/09(日) 00:16:03.48 ]
- 自動化してもテストは際限なく増えていく。
増えていけば必ず時間がかかる。
自動テストに時間が掛かるって状況になっていないのなら
それはまだテストが少ない段階なんだなぁとしか思えない。
- 768 名前：仕様書無しさん mailto:sage [2012/09/09(日) 00:27:15.25 ]
- やってる内容によっては、いくら自動化しようがダメ出し食らうだけじゃね
テスト自動化したら終わりってわけじゃないような
- 769 名前：仕様書名無しさん mailto:sage [2012/09/09(日) 02:15:34.13 ]
- ウォーターフォール否定的なヤツが多いが、一時的に大量に人集めて、大規模システムを納期どおりに一定の完成させるにはウォーターフォールしかないのが現実。
小規模で最適な開発方式をそのまま大規模に適用させられると思ってるおバカさんが多すぎる。
- 770 名前：仕様書名無しさん mailto:sage [2012/09/09(日) 02:18:18.41 ]
- プロマネにも言えるが小規模PJを幾つも上手く回すスキルと、大規模PJを完遂させる能力は質が違う。
- 771 名前：仕様書無しさん mailto:sage [2012/09/09(日) 02:30:21.49 ]
- ちゃんとした体裁のドキュメントなんて完成に近づいてからやりゃいいけど、
ある程度決めないといけない内容を残す必要もあるから、そういう意味では先に造らないといけない部分はあるんだよなー
でも、ウォーターフォールはその残すためのものを最初から完璧に作ろうとしては
書き直して無駄な工数を裂くことがおおくて、その帳尻あわせにケツが縮まって燃える(´・ω・｀)
- 772 名前：仕様書無しさん mailto:sage [2012/09/09(日) 02:31:09.88 ]
- まともなとこは、人海戦術的なことはやらんでしょ
- 773 名前：仕様書無しさん mailto:sage [2012/09/09(日) 02:32:32.61 ]
- TDDはある程度コーディングの実力が伴わないと難しいと思うよ
試行錯誤して手探りしてるレベルの人だと、いきなり適切なテストケースを用意するのはかなり難しい
だって、はじめたばかりだったり知識が足りてない段階だと、
どういうテストを用意すればいいかわからないし、そもそも作るものがどういう実装になるかを想定できないからね
もちろん、要所を押さえれば知識が浅いうちでもそれなりにはできるようにはなるとは思うけれど
試行錯誤があまり必要ないくらいにすぐ目的のコーディングに入れるようになるまでは、いきなりテスト作成はきつい
自分も結構実装前段階でテスト準備はうまくやれないから、そういうのはなんとなくわかる
でも一通りやれる事や実装の見通しが実装に入らなくても想定できるようになってくると、
テスト作成から入るって意味もわかると思うけどなー
網羅テストのような(大して意味がないけどｗ)のがテストとして求められてるようなものなら、そういうわけには行かないけどさー
- 774 名前：仕様書無しさん mailto:sage [2012/09/09(日) 02:32:54.97 ]
- 今の要求は、人がいれば出来るような簡単なもんじゃないと思うけどね
簡単なの探すほうが大変じゃね
- 775 名前：仕様書無しさん mailto:sage [2012/09/09(日) 02:34:31.80 ]
- つかまずその大規模プロジェクトって物自体が否定されてるようなもんだからなｗ
頭とケツしか考えられないから、ウォーターフォールしか選択肢がない
仕様書とか設計書とかって、この無駄にピザってしまった縦割り開発の
伝言ゲームのためにあるようなもんだし、無駄だよやっぱ
- 776 名前：仕様書無しさん mailto:sage [2012/09/09(日) 02:38:21.62 ]
- 新規じゃないのは、枯れてくれば、少人数になっていくような
- 777 名前：仕様書無しさん mailto:sage [2012/09/09(日) 02:53:54.52 ]
- >>770
料理人とかでも同じだな、大規模宴会料理と小料理屋の料理じゃ全然違うと。
まあ、どの業種でも言えることだけどね。
- 778 名前：仕様書無しさん mailto:sage [2012/09/09(日) 02:59:07.84 ]
- 料理系とかは下積み長い人達が割と集まる（める）から成り立つんだよ
人がいればこなせるほど、甘い世界じゃないだろ、歴史があるところは
味抜きでやってるとこは、先ないだろうね、料理系
- 779 名前：仕様書無しさん mailto:sage [2012/09/09(日) 03:05:01.39 ]
- 好きこそ物の上手なれっつーか、興味をどれくらい持ってるかでのピンキリ差が激しいし、
実際の土方みたいに体動かしてりゃなんとかなるわけでもないから、数いりゃいいってもんでもないしな。
- 780 名前：仕様書無しさん mailto:sage [2012/09/09(日) 03:27:22.13 ]
- > 実際の土方
やってる人に経験値高い人達がいるから、成り立ってんじゃねえの？
- 781 名前：仕様書無しさん mailto:sage [2012/09/09(日) 03:57:35.35 ]
- >>778
> 人がいればこなせるほど、甘い世界じゃないだろ、歴史があるところは
そうでもない。
例えば皮むき。下ごしらえなんかは、時間がかかる上に
テクニックはそんなに必要ない。そういう所に人を入れれば
○人でできる量を増やすことが出来る。
うまく人を配置すれば、一流の料理人をたくさん集めなくても
同じ質で生産量を増やすことが出来る。
そして、現実問題に対応しないといけない。
現実問題というのは、団体さん100人が来た時に対応できないといけない。
できるかどうかではなく、要求が先にある。
機材を増やした所で生産量は増えない。
人を増やすことでしか対応できないこともある。
- 782 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:01:40.32 ]
- どっかが、やれば出来るって言って素人に刺身切らせてましたのと同じ発想なのがお笑い
- 783 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:04:10.22 ]
- >>781
逆読みすれば、
ど素人でも出来るようなことをやってる
っていってるような
- 784 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:04:18.37 ]
- 素人 と 刺身を切るスペシャリストの
違いがわかってないの？
一流の料理は作れなくても
刺身を切るのはうまいって人もいるだろう。
- 785 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:09:37.97 ]
- 料理自慢って言われてる人はいるだろうけど
自分からいう人は、あんまりいないんじゃね
- 786 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:14:56.89 ]
- >>783
だれもど素人がやるなんて言ってないしｗ
えとさ、ある作業があっとして、
それを一つスキルが低い人でも出来るようにしたら
その分、生産量は上がるよね。
お前も、この考え方のその恩恵に預かってるはずだが？
例えば音声合成をするための技術はないが、
ライブラリがあれば、スキルが低くても音声合成ができる。
- 787 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:35:32.42 ]
- >>786
その時点で開き直ってるような
ま、やらせる相手によるのかもしれんけど
- 788 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:41:04.15 ]
- >>787
日本語でお願いします
- 789 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:43:07.15 ]
- 一流でなければど素人って言うような人だからねぇ。
そいつにとっては、一流の野球選手じゃなければ
甲子園に行ったとしてもど素人なんっだろうねｗ
- 790 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:46:30.03 ]
- そういう例え方しかできんの？
- 791 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:48:48.86 ]
- 20年前のやり方が通用せん分野も出てきてるのにね
- 792 名前：仕様書無しさん mailto:sage [2012/09/09(日) 05:37:09.93 ]
- >>766
そうか。
お自動化して数年かかるようなテストやってるんだろ？
自動化しなかったら、もっと時間がかかるだろw
- 793 名前：仕様書無しさん mailto:sage [2012/09/09(日) 06:06:09.63 ]
- テストの実行にそんなに時間がかかるのだとしても、
それでもテストは繰り返すべき、だな。
基本、マシンスペックを上げる。放置プレイも重要。
そこまでの規模なら、テストの前にコンパイルで相当時間がかかるはず。
Googleはコンパイル時間が短い言語を独自開発してる。
Cでも満足できないらしい。
これはとどのつまり、テストの周期を短くするためだ。
場合によっては新言語開発さえ必要、ということ。
- 794 名前：仕様書無しさん mailto:sage [2012/09/09(日) 07:38:36.42 ]
- 料理人どうののたとえ話じゃなくて、普通にマの話で説明すべきだろう
マ板住人が料理人の仕事の詳細を例えに使えるほど理解してるわけないだろう
余計ややこしくなるだけ
- 795 名前：仕様書無しさん mailto:sage [2012/09/09(日) 12:36:01.37 ]
- >>793
> そこまでの規模なら、テストの前にコンパイルで相当時間がかかるはず。
ん？ なんでテストの時間と
コンパイル時間が関係あると思ってんの？
- 796 名前：仕様書無しさん mailto:sage [2012/09/09(日) 12:59:17.63 ]
- >>792
たとえば新しいOSが増えたら、テストがその分増えるわけ。
ウェブアプリだったら、テスト時間×ブラウザ数になるわけ。
自動化関係なく、テストは時間がかかるもの。
完璧なテストは数年かかるからやれない。
だから手抜きする。
自動化でそれが0になるわけじゃなく減らせるだけ。
自動化してもやっぱり手抜きは必要。
- 797 名前：仕様書無しさん mailto:sage [2012/09/09(日) 15:17:34.16 ]
- >>796
君が「自動化＝テスト項目の削減をしない」って勝手に定義してるだけだろ。
- 798 名前：仕様書無しさん [2012/09/09(日) 16:26:27.82 ]
- 自動化は時間の削減であって項目の削減ではないだろ
区別して考えろよ
- 799 名前：仕様書無しさん mailto:sage [2012/09/09(日) 16:28:24.71 ]
- 日本語化したら、コンピュータが勝手に動いてくれると思ってるのかしら、かしら
テスト自動化したら、問題が減っていくと思いたいのかしら、かしら
- 800 名前：仕様書無しさん [2012/09/09(日) 16:52:44.47 ]
- ランダムテストみたいに入力をランダムに振るテストを「自動化」とか呼んでそうだな
- 801 名前：仕様書無しさん mailto:sage [2012/09/09(日) 17:14:45.41 ]
- CI
- 802 名前：仕様書無しさん mailto:sage [2012/09/09(日) 17:19:29.48 ]
- 動かすより、テストすること考えて作るほうが難易度高いこともあるのにね
テストの自動化出来ましただけ言ってると誤解する人増えそう
- 803 名前：仕様書無しさん mailto:sage [2012/09/09(日) 19:05:42.06 ]
- 全自動になる前の麻雀で初心者がハマる状況に似てるな、この業界
- 804 名前：仕様書無しさん mailto:sage [2012/09/09(日) 20:17:35.37 ]
- 連チャンに耐えられる人達ってどんくらいいるんだろうね
- 805 名前：仕様書無しさん mailto:sage [2012/09/09(日) 21:34:54.77 ]
- 曖昧な書き方して逃げ道作ってる奴ばっかｗ
- 806 名前：仕様書無しさん mailto:sage [2012/09/09(日) 21:36:21.09 ]
- 保身に拘るのは最早職業病
- 807 名前：仕様書無しさん mailto:sage [2012/09/09(日) 21:44:46.40 ]
- 書いたら、終わりじゃないのにね
- 808 名前：仕様書無しさん mailto:sage [2012/09/09(日) 22:32:58.63 ]
- >>755
> テスト工数は多くなっても自動化すれば、トイレ行ってる間に終わるからな。
終わらねーよｗ
- 809 名前：仕様書無しさん mailto:sage [2012/09/09(日) 22:38:07.65 ]
- テストを自動化したって、時間がかかるものはかかる。
make testをしたらわかるだろ？
- 810 名前：仕様書名無しさん mailto:sage [2012/09/09(日) 23:44:51.16 ]
- 1.日本は新卒文化
2.経験不要、コミュ力重視で採用。
3.プログラムは下っ端の仕事
上記理由から、プログラマの大部分は
ド素人であることが昔からこの業界の常識。
ド素人集団でもシステムを作り上げられる唯一の開発手法がウォーターフォール。
- 811 名前：仕様書無しさん mailto:sage [2012/09/09(日) 23:53:34.93 ]
- 自動化はJenkinsみたいなCIサーバー使ってコミットされたらビルド→自動テストを
裏で動かせるのが肝だろ。CIサーバー使わなくてもビルドスクリプト使って
ある程度の自動化が出来てないと恩恵は少ないわな。
- 812 名前：仕様書無しさん mailto:sage [2012/09/10(月) 00:13:41.27 ]
- え、大規模でも統合環境じゃないの？
- 813 名前：仕様書無しさん mailto:sage [2012/09/10(月) 01:27:43.84 ]
- >>811
うん、コミットする前に自動テストやったら
コミットするまで時間かかるから
自動テストは、コミットが終わった後でやるんだよねｗ
- 814 名前：仕様書無しさん mailto:sage [2012/09/10(月) 01:49:17.50 ]
- >>813
普通に自分の環境でビルド通して、自分が書いた分の自動テストが通ったら
コミットするだろ。
ただプログラム書いたやつなら分かるが、自分の環境だと問題なくても
他人が修正してコミットしたモジュールと合わせるとビルド環境やデプロイ
環境でビルドが通らなかったりテストが通らなかったりするから、要所要所
でビルドと自動テストをして早い段階でエラーを検知する仕組みにする。
今はCIサーバーとかがあって、そういうのが自動で組み込める便利なツールが
あるからそれを使えるならそういうのを使えばいいだけ。
設計書だけしか書けない人はこういうツール類が昔に比べ遥かに便利で
高速化されてることを知らないのが多いね。 まあ、普通に開発してる
人間でもアンテナ張ってても引っかからないことが多いけどね。
- 815 名前：仕様書無しさん mailto:sage [2012/09/10(月) 07:08:33.88 ]
- 設計書だけしか書けない奴ってホントつかえねーよな
使えなすぎてガンガン首切られてる
スキル0のゴミだから転職もできない
- 816 名前：仕様書無しさん mailto:sage [2012/09/10(月) 15:26:31.58 ]
- 本日見つけた迷言
「フレームワークを使わないのがXXX(言語名)だ。」
「俺のOOPはフレームワークには負けない。」
- 817 名前：仕様書無しさん [2012/09/11(火) 09:48:33.01 ]
- すべてのプロジェクトに当てはまる万能な開発手法はない。
しかし、脱ウォーターフォールは万人にオススメできる。
日常のツール作りから原発まで脱ウォーターフォールを真剣に考えるべきだ。
あなたが、ウォーターフォールでうまくいっていると思っているなら、
実際は、ウォーターフォールが実践されていないからだ。
- 818 名前：仕様書無しさん mailto:sage [2012/09/11(火) 10:46:38.85 ]
- それは言えてる
- 819 名前：仕様書無しさん mailto:sage [2012/09/12(水) 06:48:45.39 ]
- ウォーターフォールでも何でもいいけど、下流の馬鹿マが内部設計すら出来ないのは勘弁してくれ。
概要設計から製造までお前んとこで請け負ってるのに、何でもいちいち聞いてくんな!!
「こんな内部変更が必要になるなんて聞いてない。」って、外部インターフェースのプロトコル変更は真っ先に挙げてるし、その対応見積り出したのあんただろ。
しかも、「じゃあ、そのプロトコルのサンプルソースくれ。」とか、知らないで見積ったのかよ!!
100歩譲って知らなかったとしても、今まで何も調べてないのかよ!!
- 820 名前：仕様書無しさん [2012/09/12(水) 06:54:58.89 ]
- 印刷設計書が書きにくいから計算結果もDBに書き込むようにしてほしいと言われた。
書きにくいから・・・・そこ書くのがてめぇらの仕事だろ。
- 821 名前：仕様書無しさん mailto:sage [2012/09/13(木) 00:39:01.05 ]
- >>755
お前、それただのデバッグなんだが。
デバッグのことをテストって言ってね？ｗ
- 822 名前：仕様書無しさん mailto:sage [2012/09/13(木) 01:45:54.74 ]
- 中抜きは下選べるだけマシじゃん
上は選べないんだぞ
- 823 名前：仕様書無しさん mailto:sage [2012/09/13(木) 01:50:06.87 ]
- >>819
その程度の会社と知らないで契約したのかよ!!
>>821
えっ
- 824 名前：仕様書無しさん mailto:sage [2012/09/13(木) 06:53:32.86 ]
- >>823
情報漏洩防止手続きとか、レートとかあって、選択肢無いんだよ!!
しかも、中のマはコロコロ変わるし、ハズレが多いんだよ!!
- 825 名前：仕様書無しさん mailto:sage [2012/09/13(木) 21:08:09.33 ]
- たまに聞くコーディングやインフラまったくできない人の書く仕様書ってどんななんだろう
もう設計以前に、客の要望をそのまま横流しにして見栄えのする紙を作るくらいしか
やれることなさそうなんだが・・・
- 826 名前：仕様書無しさん mailto:sage [2012/09/14(金) 01:54:19.87 ]
- >>824
ほんと、上も下も誰も幸せになれないお仕事だよなぁ…!!
- 827 名前：仕様書無しさん mailto:sage [2012/09/14(金) 04:18:00.46 ]
- 負の連鎖を断ち切られると困る人達がいるからでしょ
- 828 名前：仕様書無しさん mailto:sage [2012/09/14(金) 06:42:22.85 ]
- >>826
せめて、お国の仕事だけでもウォーターフォールで、設計審査してから製造って方式止めて欲しい。
某所の基準は30年以上前にMIL和訳して戦前からの基準に合わせただけで、以後ほとんど変わって無いぞ。
MILはウォーターフォールの失敗を認めて数年ごとに改訂を繰り返して、今はISOに移ったのに。
理系が多い某所でこれなんだから...
- 829 名前：仕様書無しさん mailto:sage [2012/09/14(金) 06:51:24.83 ]
- 日本語の説明書読んで、設計審査とかバカじゃねえの？
日本語しか読めない人がこの手分野やってるんだ
- 830 名前：仕様書無しさん mailto:sage [2012/09/14(金) 14:04:12.64 ]
- そこでドイツ軍採用のVモデルですよ。
- 831 名前：仕様書名無しさん mailto:sage [2012/09/15(土) 02:02:06.30 ]
- うまくいったプロジェクトの最大公約数をとるとウォーターフォールという開発方式が経験則的に導きだされる。
その結果ウォーターフォール適用プロジェクトが多くなるが、開発方式だけで成功するわけじゃないから、失敗プロジェクト担当者にアンチが増える。それがおまいら。
- 832 名前：仕様書名無しさん mailto:sage [2012/09/15(土) 02:09:13.53 ]
- >>828
お国の仕事は、プログラムが動くことよりも規則に則った手続きを踏むことの方が遥かに重視される。
まったく結果が伴わなくとも、定められたルール通りにやりさえすれば、官僚が成功のストーリーをでっち上げてくれる。
- 833 名前：仕様書無しさん mailto:sage [2012/09/15(土) 03:17:41.12 ]
- そのうち晒し者なるところが出そうな話？
- 834 名前：仕様書無しさん mailto:sage [2012/09/15(土) 03:43:02.77 ]
- > 経験則的
20年以上前に出来上がったもんのメンテかなんかしてるんか？
- 835 名前：仕様書名無しさん mailto:sage [2012/09/15(土) 14:02:34.94 ]
- 日本だと経営者がシステム開発に興味無い老人だから、大規模PJともなると組織の中間管理職10人以上が会議室で顔つきあわせて、あーでもないこーでもないって自分の立場優先の意見しか言わない。アジャイルなんてしてたら仕様が決まる前に予算が尽きるわw
欧米だと外部から来たCEOがまず大規模リストラして、捻出した金(自分が使って良い金)で自分の気にいるシステム導入するからうまく行くわけで。
- 836 名前：仕様書無しさん mailto:sage [2012/09/15(土) 14:42:46.11 ]
- >>835
> 欧米だと外部から来たCEOがまず大規模リストラして、捻出した金(自分が使って良い金)で自分の気にいるシステム導入するからうまく行くわけで。
その導入したシステムを作った会社の話をしてくれ。
- 837 名前：仕様書無しさん mailto:sage [2012/09/15(土) 14:46:43.87 ]
- 上司は上司で部下潰しに余念が無い
- 838 名前：仕様書名無しさん mailto:sage [2012/09/15(土) 16:24:08.76 ]
- 顧客内部での利害関係を解決しないままでも、なんとか落としどころを探して(同意したという証拠を残す)システムを成立させるのが、SIerの仕事。
イテレーションで、理想的な状態に近づけると考えるのは幻想でしかない。
関係者全員にとって理想的なシステムなんて存在しないことの方が多いから、やればやるほど迷走する。
- 839 名前：仕様書名無しさん mailto:sage [2012/09/15(土) 16:36:53.91 ]
- アジャイルの実情を見てもまだやろうとする奴いるのか？
ssff.hateblo.jp/touch/entry/2012/06/12/230847
- 840 名前：仕様書無しさん mailto:sage [2012/09/15(土) 16:48:32.49 ]
- ネゴシエーター
- 841 名前：仕様書無しさん mailto:sage [2012/09/15(土) 17:03:39.06 ]
- えらくレイアウトぶっ壊れたサイトだな
- 842 名前：仕様書無しさん [2012/09/16(日) 08:26:57.84 ]
- >>831
経験があって、たまたまで一気呵成でできたから、
それをすべてのプロジェクトで真似するのは違うよ。
ウォーターフォールというのは一息でやるってこと。
吐くだけで、吸わないわけで、
これはつまり、呼吸の手順が抜けてるってこと。
上手い歌手が、一息で長いフレーズを素晴らしく歌い上げたとする。
その素晴らしさを真似して、歌全体を一息で歌うのを目指すとか、狂ってるだろ？
そこには呼吸がないんだから、当然、酸欠で死亡することになる。
そういうアホで危険なことは今すぐやめるんだ。
- 843 名前：仕様書無しさん mailto:sage [2012/09/16(日) 08:38:01.44 ]
- うちの会社ではコーディング仕様とか実装仕様の話になると
すげー嫌な空気がでるんだがうちだけ？
他はそうでもないの？
いやもうなんつーかほんとやだって感じ。
- 844 名前：仕様書無しさん mailto:sage [2012/09/16(日) 13:27:56.64 ]
- コーディング仕様や実装仕様ってのがどういうのかがよくわからない
多くのところが、(名前なんかは違うと思うけど、)
だいたいこういう3段階+コーディング、みたいな事やってんじゃね
1. 要件定義 客の望むシステムを聞き出して仕様を起こすための情報を纏める
2. 基本設計、外部設計など UIや使用方法的な、外から見える部分の仕様、環境の仕様など
3. 詳細設計、内部設計など 業務ロジック的な仕様
4. プログラム設計、というか実装
頭の中でやる、もしくはソースコード自体をプログラム設計って呼んでいいと思う
この名前のドキュメント起こすプロジェクトも稀にあるけど、中身は詳細設計とかのレベルのものだし
それとも、コーディング規約(コーディングルール)とかの話なのかな？
- 845 名前：仕様書無しさん mailto:sage [2012/09/16(日) 15:44:16.74 ]
- >>843
そんな下流作業は外注に丸投げしとけって話だろ？
上司からは、そんな暇あるなら客の機嫌とって金巻き上げてこいって顔され、文系ゆとり部下からは泥臭い仕事はお断りって感じだろ？
- 846 名前：仕様書無しさん mailto:sage [2012/09/17(月) 08:06:53.09 ]
- >>843
うちは嫌って感じではないが、あからさまに逃げられる。
要するにコードも書けないし、設計も出来ないから判断出来ないんだよね。
うちは、お国のソースを長年メンテするけど、元がムチャクチャだから基準作ってもどうしようもないし。
- 847 名前：仕様書無しさん [2012/09/21(金) 07:14:11.14 ]
- 設計書の構成とかの標準が古くさすぎて困る。
標準ってだけだから融通きく筈なのに、頭硬い奴のせいで作業やりずれぇ。
- 848 名前：仕様書無しさん mailto:sage [2012/09/23(日) 12:20:02.92 ]
- SIerの設計書はCOBOLがメインターゲットだからな。
一時期UMLを標準ドキュメントにしようとする流れもあったが、顧客も下請ソフトハウスが読めないから完全に廃れた
- 849 名前：仕様書無しさん [2012/09/23(日) 16:07:16.65 ]
- UML読めるとこに仕事まわせばいいのに
- 850 名前：仕様書無しさん mailto:sage [2012/09/23(日) 16:58:38.42 ]
- UML読めない客もお断り！
UML以外の設計書を納品する必要があるなら、見積り2倍で出します！キリッ
- 851 名前：仕様書無しさん [2012/09/23(日) 17:37:55.58 ]
- 刑法第２４６条詐欺罪（十年以下の懲役)
虚偽のマージン率または派遣料金の明示により労働契約を締結する行為は詐欺罪の「人を欺いて財物を交付」にあたると見られる。
職業安定法第４４条の労働者供給事業の禁止規定違反
偽装請負、多重派遣と同様に、事前面接、履歴書の提出を行うと「派遣労働者を特定する行為」にあたり派遣会社の実態が労働者供給業と見なされるため、職業安定法第４４条の禁止規定違反となる。
罰則の適用には被害者による刑事告訴か関係諸局・内部関係者による刑事告発が必要となる。
・職業安定法第５章第六十四条、1年以下の懲役または100万円以下の罰金
処罰は派遣先、派遣元の両者に科される。職業紹介を行う紹介予定派遣では例外として事前面接が認められている。
労働基準法第１章第６条違反（中間搾取の禁止）
再派遣は労働基準法第６条の違反となる。罰則の適用には被害者による刑事告訴か関係諸局・内部関係者による刑事告発が必要となる。
・労働基準法第１３章第１１８条、1年以下の懲役又は50万円以下の罰金
両罰規定（労働基準法第１２１条）
労働基準法第１章第６条違反については両罰規定が設けられている。労働基準法第１２１条には
この法律の違反行為をした者が、当該事業の労働者に関する事項について、事業主のために行為した代理人、使用人その他の従業者である場合においては、事業主に対しても各本条の罰金刑を科する。
とあり、事業主（中間搾取行為をした事業者の経営担当者、労働者に関する事項について事業主の為に行為をするすべての者）と事業主の代理人についても処罰が科される。被害を受けた労働者は派遣先および派遣元の会社、従業員などに対して刑事告訴を行える。
- 852 名前：仕様書無しさん [2012/09/23(日) 18:22:46.39 ]
- ＞ UML読めるとこに仕事まわせばいいのに
UMLとプログラムは相性が悪いんだ。
UML読める奴に限ってプログラムが作れない。
もし作ってもむちゃくちゃで何やりたんだかわからない。
UMLでは大事な情報が抜け落ちてしまうから、
同じ仕事を５年も１０年もやるような大企業ならいいけど。
それ以外では使い物にならないんだ。
UMLがいいと言ってる奴に限ってぐちゃぐちゃの
ソースコードを書くのは、いまとなっては誰でも知ってることだ。
- 853 名前：仕様書無しさん mailto:sage [2012/09/23(日) 18:32:50.96 ]
- UMLで書けるような仕様なんて、大した仕様じゃないんだよ
それが何のためのシステムなのかを知っていれば、
誰でも類推できてしまう程度のことしか書けない
- 854 名前：仕様書無しさん mailto:sage [2012/09/23(日) 19:26:03.90 ]
- 勤勉な無能が一番厄介なのは知ってるだろ？
そういう無能にはUMLという名の落書きを書かせて
プログラマの仕事の邪魔をさせないようにするんだ
もちろん落書きだから後で使わない
- 855 名前：仕様書無しさん mailto:sage [2012/09/23(日) 21:49:40.04 ]
- UML読めないって、フローチャート読めないレベルじゃね？
- 856 名前：仕様書無しさん mailto:sage [2012/09/23(日) 21:54:41.67 ]
- UML、フローチャート読み書きできるのと、コード読み書きできるかは別なんだよ
- 857 名前：仕様書無しさん mailto:sage [2012/09/23(日) 22:02:22.62 ]
- フローチャート読めないほど頭が弱い奴に、
まともなコードを期待するのは間違ってる。
- 858 名前：仕様書無しさん mailto:sage [2012/09/23(日) 22:37:13.28 ]
- 両方求めるほうがおかしいの
高学歴パー系がそういう無茶なこと要求するからね
- 859 名前：仕様書無しさん [2012/09/24(月) 00:52:28.63 ]
- UMLはwordで書けないから使えない
- 860 名前：仕様書無しさん mailto:sage [2012/09/24(月) 01:51:21.29 ]
- 全部できる奴以外死ねって事だろ
- 861 名前：仕様書無しさん mailto:sage [2012/09/24(月) 03:17:05.67 ]
- 読めないからダメって言ってる人はさすがにアレだと思うわ
別にUMLを使いたいとは思わんけど、簡単だからかじるくらいには覚えたよ
読めないと困るときもあるし
つか、UMLの仕様すら頭に入らない人が、まともなコーディングできるわけないっしょ
- 862 名前：仕様書無しさん [2012/09/24(月) 06:51:03.86 ]
- UMLだから、駄目/完璧ってのは無いよな。
使える図は使う、要らない図は使わない。
まぁ、要らないけど要求されるから、無駄と判っていても作るってのは多いけど。
- 863 名前：仕様書無しさん [2012/09/24(月) 07:06:13.13 ]
- しかし、最近のマってデータ定義疎かにする奴増えた気がする。
どんな言語でも開発手法でも、データ定義決まらなきゃ内部設計出来ないだろ。
むしろデータ定義さえ正しく出来れば、よほど特殊な処理以外はイメージ出来るもの。
データも固めずに内部処理が判らん、って何言ってんだこいつ？
- 864 名前：仕様書無しさん mailto:sage [2012/09/24(月) 10:17:18.98 ]
- ドメインモデルはニホンザルには無理か
- 865 名前：仕様書無しさん mailto:sage [2012/09/24(月) 12:22:37.54 ]
- > どんな言語でも開発手法でも、データ定義決まらなきゃ内部設計出来ないだろ。
> むしろデータ定義さえ正しく出来れば、よほど特殊な処理以外はイメージ出来るもの。
そんなのは、ごく一部の領域だけ。
- 866 名前：仕様書無しさん mailto:sage [2012/09/24(月) 15:51:45.19 ]
- 元々、帳票系ベースだから、分野によっては使える使えない（ところ）があるのに
- 867 名前：仕様書無しさん mailto:sage [2012/09/24(月) 23:59:55.41 ]
- まー閉じた世界にいると、その中で優劣考えるようになって
「あれ、俺できる奴じゃね？」って思っちゃったりすることは、誰にでもあることだしね
- 868 名前：仕様書無しさん [2012/09/25(火) 06:31:59.18 ]
- >>867
おれにすらあることだな
- 869 名前：仕様書無しさん [2012/09/28(金) 00:12:11.73 ]
- 結局EXCEL方眼紙最強ってことだね
- 870 名前：仕様書無しさん mailto:sage [2012/09/29(土) 01:18:33.33 ]
- いいえ
最狂のうんこ
- 871 名前：仕様書無しさん mailto:sage [2012/09/29(土) 01:59:41.94 ]
- レビューの時に新たな仕様書の存在を聞かされた
あるあるwww
ワロタwww
ワロタ・・・
- 872 名前：仕様書無しさん [2012/09/30(日) 09:02:46.71 ]
- 「設計書」と「テストスクリプト」を一体化したいと漠然と思ってるんだが、何か問題ある？
最近はレビューばっかで自分で書かないからそこまで具体的に考えてる訳じゃないんだけど、
見てると「テストスクリプト」が「設計書」からのコピペと化していて
同じことを二度やっているようにか思えない
書いてある内容は、
＜設計書＞
これをやったら → こうなる
＜テストスクリプト＞
これをやったら → こうなる ＋ 必要なエビデンス ＋ OK/NG欄
の違いでしかない
「設計書」はWordで、何となく章立てや起承転結があるかのような装いをしていて
「テストスクリプト」はExcelで、表と言うか箇条書きと言うか、項目が１意に識別しやすい
というくらいの違いしかない
- 873 名前：仕様書無しさん mailto:sage [2012/09/30(日) 12:47:48.39 ]
- うちは設計書の右にチェック欄つけて、それをテスト仕様書として提出することにしてる
仕様に書ききれてない処理については別項目のテスト作る感じで
テストコードなんて誰も作ってないまま数年経過したアレプロジェクトだから、こうするしかないってのもある
- 874 名前：仕様書無しさん mailto:sage [2012/09/30(日) 12:49:20.91 ]
- あ、うんこExcel仕様書なので、一処理が一セルにかかれてるみたいなやつね
改定と仕様変更でちゃんとあってるかはだいぶ怪しくなってるけど、
ドキュメントはそれしかないからテストはそれでやってる感じ
- 875 名前：仕様書無しさん [2012/09/30(日) 16:09:26.66 ]
- ありがとう
出来はともかく、方法としてはそれでいいように思うんだよな
10年前はプログラム作るだけでよかったんだが、
業界の規制が厳しくなってきたのと、会社もISO9001取ったりで文書類作るようになって、
ノウハウの蓄積のない分野を力技でやってる感じで、無駄に時間ばかりくってるんだよね
いつか初めてのところに外注で出したときに
失敗させる訳にいかんかったので考えられる全分岐を書き出してURSを作ったことがあって
（要するにベンダーには何も考えてもらうことを期待しない）、
そんときも、それがそのまま設計になると同時にテストパターンになるなと思った
- 876 名前：仕様書無しさん mailto:sage [2012/09/30(日) 18:40:18.43 ]
- ISOで設計書の標準規格作ってくれよ
プロジェクト毎に設計書フォーマットが違う、取引先の気分や社内ルール次第で納品書式が変わるのはおかしいだろ。
- 877 名前：仕様書無しさん mailto:sage [2012/09/30(日) 19:11:36.45 ]
- >>876
UML
すべての仕様を書き切れるなら神
- 878 名前：仕様書無しさん [2012/09/30(日) 23:19:04.83 ]
- UMLでUIはどこに書くんだっけ？
- 879 名前：仕様書無しさん mailto:sage [2012/09/30(日) 23:25:46.46 ]
- ゆ、ユースケース図
- 880 名前：仕様書無しさん mailto:sage [2012/10/02(火) 00:44:26.80 ]
- ぶっちゃけUI周りはドキュメントに起こす意味のないものも多いけどな
そんなのしこしこ用意するより動くもの、モックなんかをドキュメントの変わりに使ったほうがいい
結局何か居ても客は理解しないから、触ってからはじめて違うっていい始めるわけだし
- 881 名前：仕様書無しさん mailto:sage [2012/10/02(火) 00:48:11.09 ]
- 結局何か居ても
→結局何書いても
そういや、ダンボールとか切り貼りして工作でWebUIのモックつくるようなの
前にどっかの企業の勉強会かなんかの記事でみたなｗ
>>876
変化についていけない層がへばりついてる会社が多いから、規格が定まっても難しそうな気がするけどなー
あると嬉しいけれど
- 882 名前：仕様書無しさん mailto:sage [2012/10/02(火) 09:01:30.61 ]
- 変化を制御しようって考えのない会社はおおいよな。
変化を抑圧しようって会社はおおいけどｗ
- 883 名前：仕様書無しさん mailto:sage [2012/10/02(火) 17:26:16.50 ]
- >>879
どうしても、ユースケ・サンタマリアを思い出す。
- 884 名前：仕様書無しさん mailto:sage [2012/10/03(水) 02:10:46.19 ]
- サタンマリアを思い出す
- 885 名前：仕様書無しさん mailto:sage [2012/10/06(土) 19:29:18.82 ]
- UMLがいまいち普及しないのは、保守的云々以前に
単純にExcel方眼紙と対等に戦える糞だからじゃね？
- 886 名前：仕様書無しさん mailto:sage [2012/10/07(日) 01:52:17.45 ]
- UMLで設計したら時間も労力も余分に必要だからだよ。
細部の設計も表現しづらいし。
- 887 名前：仕様書無しさん mailto:sage [2012/10/07(日) 02:28:43.71 ]
- UMLはモデリング言語の名前の通り、
設計したものを、UMLで記述するという風に使うものであって、
UMLで設計するという言い方はおかしいぞ。
- 888 名前：仕様書無しさん mailto:sage [2012/10/07(日) 04:14:36.37 ]
- 単純に、UMLだけで設計書が完結するわけじゃないからな。
ある程度書き方に自由度があるから、伝えやすいというのと誤解させやすいと
いうのがあるから、結局のところ短納期で毎回違う人とやり取りするには精度の
問題が今までと変わらんから。
実装側に厳密にするとコード書くのと変わらないし、設計側に厳密にすると
実装に支障をきたすし、学習しなければならないというところまできてないよな。
フローチャートレベルで授業のカリキュラムや情報処理技術者試験みたいな
公的な資格試験に組み込まれてれば違ってくるんだろうけどね。
- 889 名前：仕様書無しさん [2012/10/07(日) 11:16:50.29 ]
- >>887
じゃあどうやって設計すんだよ
論理的じゃない設計してそうだな〜〜お前
- 890 名前：仕様書無しさん mailto:sage [2012/10/07(日) 13:52:56.45 ]
- UMLで論理的な設計wwww
- 891 名前：仕様書無しさん [2012/10/07(日) 14:58:29.08 ]
- UMLはお客さんも理解できる（ﾄﾞﾔｧ
とか書いてあった時期あったけどそんな奴居た事無いよな
国のエロい人が色々決めてたけどあんなの揃えてたら金いくらあっても足らんし
- 892 名前：仕様書無しさん mailto:sage [2012/10/07(日) 17:18:57.20 ]
- そもそも、ちゃんとした設計とか学んだことなくてニュアンスでやってるひとは多いと思うわー
- 893 名前：仕様書無しさん [2012/10/07(日) 18:10:41.62 ]
- Excelで結合セルを駆使して設計する方法は完璧に学習した。
- 894 名前：仕様書無しさん mailto:sage [2012/10/07(日) 18:16:43.07 ]
- 途中から別のプロジェクトに入ってまず困るのは、全体を概観できる資料がないこと。
よくあるのが、全体構成図では、「営業サーバ」、「総務サーバ」とか書いてあるのに、
設計資料ではいきなり、「○○（パッケージソフト名）サーバ#1」とかになってて、
「○○#1」と「営業サーバ」の対応は、設定やってる運用グループに聞かないとわからないとか。
- 895 名前：仕様書無しさん mailto:sage [2012/10/08(月) 01:35:51.59 ]
- UMLってIT業界において、この十年間で最も衰退した技術だよな。
フレームワークや開発手法が成熟するのが早かったから、大部分が実際の開発には不要になってしまった。
本当にドキュメントが必要な部分は、UMLで記述しきれないような複雑な仕様やシステム外の業務的な背景。
- 896 名前：仕様書無しさん mailto:sage [2012/10/08(月) 01:40:26.22 ]
- いや、普通に書籍等に書いてある図は
UMLなんだが・・・
- 897 名前：仕様書無しさん mailto:sage [2012/10/08(月) 02:06:38.91 ]
- フレームワークもなぁ。
要件やメカニズムのどの部分が、どのフレームワークのどの機能で実現されてるのかが
分かる資料がつくられてなかったりすると悲惨。
DI多用してたりして、末端のPGのコードとDIしたコードがバッティングしてたりすると、
PGには原因がわからない(開発用と顧客用で切り替えとかをやってたりすると最悪）
それでもそのあたりを設計したアーキテクトがプロジェクトに残ってれば聞けばわかるが、
基本設計行程が終わったら別のプロジェクトに移るなんてやりかたしてたら、
プロジェクト内に問題解決できる人がいない（または解析しないとわからない）
状態になる。
- 898 名前：仕様書無しさん mailto:sage [2012/10/08(月) 08:03:32.57 ]
- >>895がフレームワークべったりな開発だけしか経験してないんだなとしか。
- 899 名前：仕様書無しさん mailto:sage [2012/10/08(月) 11:14:39.30 ]
- フレームワーク作る側がUMLを書いてると思ってるのかな？ww
あんなのドカタ専用ツールだと見なして無視してるけどね
- 900 名前：仕様書無しさん mailto:sage [2012/10/08(月) 11:58:23.35 ]
- とりあえず、本当にフレームワーク・・・というか、
その種のプロジェクトの中心人物は、社交的で、
不用意に他人をけなしたりしないけどね。
- 901 名前：仕様書無しさん mailto:sage [2012/10/08(月) 12:04:37.02 ]
- 社交的で人当たり良くても、内心で「こいつらアホだな〜、猿か？」と思ってます
- 902 名前：仕様書無しさん mailto:sage [2012/10/08(月) 12:11:50.57 ]
- いや、おまえにとってそう見える相手はフレームワーク製作者に限らないだろ。
- 903 名前：仕様書無しさん mailto:sage [2012/10/08(月) 12:19:55.89 ]
- アホに生まれた子って可哀想。
ただでさえアホだと馬鹿にされてるのに、
死ぬ程働いても給料1000万にも届かないし。
ほんと同じ立場に立ったら自殺するわ。
- 904 名前：仕様書無しさん mailto:sage [2012/10/08(月) 19:52:14.70 ]
- >>896
だいたい書籍書いてる奴なんて実際の大規開発現場知らない奴ばかりだろ
UMLだけで書くのに都合の悪い例を排除してるというか…そもそも実務経験がなさ過ぎて想像もできないんじゃないか？
- 905 名前：仕様書無しさん mailto:sage [2012/10/08(月) 20:06:20.83 ]
- UML知らない奴ほど、全部UMLで書こうとする。
- 906 名前：仕様書無しさん mailto:sage [2012/10/08(月) 23:54:32.38 ]
- ユースケース図は粒度の決め方がアナログ過ぎ、ロバスト図はある程度以上の複雑さを表現しようとすると、2次元じゃ無理ゲー。
- 907 名前：仕様書無しさん mailto:sage [2012/10/09(火) 00:02:11.70 ]
- ユースケース図の仕様に粒度は定められてない。
どう決めるかは使う側の問題。
ロバストネス図はそもそも、不必要な複雑さを省くために考えられたもので、
本当に複雑なものをわざわざモデリングしようとするのは本末転倒。
というか、批判するなら、規格書とか、発案者の書いた本ちゃんと読めよ。
- 908 名前：仕様書無しさん mailto:sage [2012/10/09(火) 02:15:14.11 ]
- UMLがない時代でもそれなりに設計なんかしてたんだし、特に必要という訳ではないかもしれんが、
あればより良いものだけど、要る派の言ってる事も要らない派の言ってる事も極端だよ。
- 909 名前：仕様書無しさん mailto:sage [2012/10/09(火) 03:24:36.52 ]
- まて、ここ最近のレスで要る派なんていたか？
- 910 名前：仕様書無しさん mailto:sage [2012/10/09(火) 03:31:45.51 ]
- 極端なのは、要る派と要らない派しかいない前提の >>908
の言ってることじゃね？
- 911 名前：仕様書無しさん mailto:sage [2012/10/09(火) 03:32:44.01 ]
- 利用価値0じゃないという意見はあったけど、
アンチからみるとちょっとでも使ってる人は要るよ派に見えてると思ってる
敵を作って戦わわないと気がすまない的な
- 912 名前：仕様書無しさん mailto:sage [2012/10/09(火) 10:09:17.74 ]
- じゃぁUMLの代わりに何つかう？っていう話になると、
結局UMLが無難ってことになる。
- 913 名前：仕様書無しさん [2012/10/09(火) 10:19:01.02 ]
- Excelのセルをちまちま埋めて仕様書を書いていく快感はUMLごときでは得られはせぬ。
- 914 名前：仕様書無しさん mailto:sage [2012/10/09(火) 12:34:17.78 ]
- それは仕様書だね。設計書とは違う。
- 915 名前：仕様書無しさん mailto:sage [2012/10/09(火) 20:20:14.25 ]
- UMLがどうのとかはぶっちゃけどうでもいいよ。求められれば使うだけ
だがな、ドキュメントとして文章めいたこと書くのにExcel使うのはいい加減やめにしてもらいたい
二度と修正を入れない使い捨てなら構わんが、保守を考えたらExcelドキュメントなんてうんこよりひどい
- 916 名前：仕様書無しさん mailto:sage [2012/10/09(火) 21:19:43.34 ]
- ワードで書くよ〜って言ったら嫌な顔するくせに
- 917 名前：仕様書無しさん [2012/10/09(火) 22:27:10.85 ]
- まともに変更履歴も残さないUMLは使い物にならない
設計書で重要なのは変更履歴と変更理由
現状はソース見れば誰でもわかる
- 918 名前：仕様書無しさん mailto:sage [2012/10/09(火) 23:41:24.45 ]
- それはバージョン管理システムの仕事だろ。
UMLでも、変更ごとにコミットしてコメントちゃんと入れれば無問題。
バージョン管理システム使わずにコメントだけで変更履歴残そうとして
しっちゃかめっちゃかになったソースだと、ろくに流れも追えなくなる。
- 919 名前：仕様書無しさん mailto:sage [2012/10/10(水) 07:15:32.32 ]
- たとえバージョン管理システム使ってても
diff取れないバイナリで書いてりゃ威力半減
- 920 名前：仕様書無しさん mailto:sage [2012/10/10(水) 07:40:25.34 ]
- そのあたりは使うツールによりけりだが・・・
とりあえず、diff が取れる代替え手段ってなんかあるの？
- 921 名前：仕様書無しさん mailto:sage [2012/10/10(水) 07:42:02.80 ]
- diff とか言い出すと、 word や Excel より TeX だよな。
- 922 名前：仕様書無しさん mailto:sage [2012/10/10(水) 17:36:08.65 ]
- TeXだと冗長になるし、なんかそれ用のエンジン使うのが賢いんだろうな。本当は。
- 923 名前：仕様書無しさん [2012/10/10(水) 20:40:25.74 ]
- >>920
エクセルに1文1セルで書いて、隣の列に
1列1バージョンで改変有無と理由を記載
フィルタを使えば瞬時に差分が見られる
- 924 名前：仕様書無しさん mailto:sage [2012/10/10(水) 20:54:09.99 ]
- >>923
それで事足りる案件なら、自分だって Diff もバージョン管理システムも、
UML も使わないよ。
- 925 名前：仕様書無しさん mailto:sage [2012/10/10(水) 23:46:17.39 ]
- そういうのは大抵が打ち消し線だらけだったりカラフルだったりになるから
いろいろ糞だけどね
場当たり対応をコード以外でも多用してるだけだし
- 926 名前：仕様書無しさん mailto:sage [2012/10/11(木) 06:43:08.22 ]
- 技術文章としての体裁を要求されたり、図表使ったら終わるだろ、それ。
- 927 名前：仕様書無しさん [2012/10/13(土) 13:18:12.48 ]
- 上流工程の資料の作成が凄いネックになってる気がしてならない。
開発者の視点で厳密に書くと「こんなんじゃユーザがわからん」といってハネられる。
ユーザにわかるように書くと表現があいまいになって、開発者には意味不明になる。
この矛盾に悩みつつ、ダメだしを回避する資料を完成させるのに絶望的に時間がかかって、
プロジェクトの予備工数がほとんど消える。
最後にはタイムオーバでダメ出しする人間が折れることになるが、
なんだかんだで、ユーザにも開発者にも3割方意味不明な資料ができあがる。
この3割方意味不明な資料を使って予備工数がない状態で開発がスタートする・・・。
- 928 名前：仕様書無しさん mailto:sage [2012/10/13(土) 15:51:58.47 ]
- ユーザー用と開発者用それぞれ別のドキュメント作ればいいだけでは？
むしろ作るべきでは？
- 929 名前：仕様書無しさん mailto:sage [2012/10/13(土) 16:10:43.54 ]
- まず、そのための工数がとられてるプロジェクトをみたことがない。
あと、開発スタート後に鬼のように湧いてくる仕様変更を、
二重化したドキュメントに反映してメンテナンスしていくコストも大変。
- 930 名前：仕様書無しさん mailto:sage [2012/10/14(日) 17:30:47.51 ]
- dfdとer(テーブルと多重度のみでOK。カラムは主キーのみでいい)意外不要。
- 931 名前：仕様書無しさん mailto:sage [2012/10/14(日) 17:43:10.49 ]
- 一人で作る程度のシステムで、クライアントがそれで納得してくれて、
その後の運用メンテも同じ担当者が続ける前提なら、それでなんとかなるかもしれん。
- 932 名前：仕様書無しさん mailto:sage [2012/10/15(月) 02:52:27.14 ]
- 成果物が糞じゃない前提なら、ドキュメントの必要性は減ると思うよ
webとかだったら画面遷移とかあると理解度は上がると思うけど、
マニュアルと動くものがあれば事足りるからなくてもいい
クラス図があると関連は理解しやすいけど
名前やパッケージ、IDEの機能で追っかけるのは簡単だからなくてもいい
まぁ作成や保守にかかるコストと教育にかけるコストと、教育対象者の質次第だな
劣悪なのはドキュメントがいくらあっても結局理解しないし、
できる奴は(ちゃんとしたシステムであれば)その場にあるので難なくこなせると思う
- 933 名前：仕様書無しさん mailto:sage [2012/10/15(月) 12:49:11.89 ]
- 技術的なドキュメントとして重要なのは基本設計と運用設計のほうだと思う。
基本設計資料がちゃんとしていれば、詳細設計は無くてもなんとかなる。
でも今、実際は、基本設計、運用設計、詳細設計で、ドキュメント量の比率としては、2:1:7 ぐらいじゃないか。
自分は、6:3:1 ぐらいでもいいと思う。
- 934 名前：仕様書無しさん mailto:sage [2012/10/15(月) 15:22:41.07 ]
- 詳細設計書 = ソースコードだからねぇ。
本当の必要な量で言えば、一番多い。
だけど、ソースコードを補足するものだけに
すれば、逆に少なくなる。
詳細設計の量が多いところは
ソースコードが詳細設計書だって
わかってない。
|
 |
