[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 10/16 11:50 / Filesize : 244 KB / Number-of Response : 935
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

仕様書、設計書について



1 名前:仕様書無しさん mailto:sage [2011/11/26(土) 11:26:56.24 ]
外部だの内部だの基本だの詳細だの…
曖昧な基準で書かれた、いろいろな名前で呼ばれてて
「これってどうなの?」「意味あるの?」といった物に出くわす事も少なくない

しかし、純粋にプログラミングだけをして食べていくことは、昨今じゃ難しく
避けて通れない、否が応でも作る機会に出くわしてしまう、そんなドキュメントたち
設計書や仕様書についても、マ視点で語ろうぜ

・自分のなかでの仕様書/設計書の呼び方と分け方
・成功談、失敗談
・仕様書/設計書は何を使って作成する?(Word/Excel/HTML/手書き!)
・仕様書/設計書に含める図の作成方法や使っているツール紹介
・炎上プロジェクトでみた(よくない意味で)素晴らしい仕様書/設計書
・そもそも仕様書/設計書って本当に必要なの?
・こんな仕様書/設計書は、ぶっちゃけアリ?ナシ?

などなど、設計書にまつわる話題を募集

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 ]
スパゲッティになるのは単純に知識不足だと思うな。興味が持てないから知識が増えないんだろうけど
好きこそ物の上手なれってやつ

よくある系のアルゴリズムについての知識だったり、言語仕様的な通例や制約をしっているかどうかだったり、
デザインパターンみたいなのを知ってるかどうかだったり、こういう差がスパゲッティを作らないうえで重要だと思う

経験から、どう書いてあると後から見るのが大変か、どうなってると後から修正とかしやすいか
なんかを学んでいくだけでもマシにはなるけど、職場が同じようなレベルのとこばっかだと
視野が狭いままで、そんなに学べることは多くない場合が多い

仕様書設計書の話題ではないけどなw

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 ]
> このため現実のウォーターフォール・モデルの開発プロジェクトでは、
> 前工程の完了要件(要件定義局面であれば、要件定義書などの成果物の完成)を
> 徹底して品質を高め、後戻りの発生率を可能な限り低下させるとともに、
> 後戻りが発生する場合は変更管理によって公式に決定し、
> 後戻りや横展開を確実にフォローする。
20年前ぐらいなら通用した考え方だね
今の情報量は半端じゃないからね

> 要件定義
って、うるさい文系院卒がいたけど
今のコンピュータのことが全然わかってなかった

今だに、非力なパソコンの流行りはじめの事例が通用するとか思ってるんかね
時代についていけてない人は...

紙の上で終わらせたいとか?



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 ]
安かろう悪かろうの需要がまだあるうちは何とかなるだろうけど、未来はないよね






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<244KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef