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