5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

仕事が遅いのが悩みの香具師

1 :せる ◆9gLessA9bA :05/02/20 01:51:23
なぜおそいのかわからない。

普通の人の3ばいかかる。

まえだおしになったことがない

2 :仕様書無しさん:05/02/20 01:54:42
作業内容の具体例出したほうがよくないか?


3 :(^ー')b ◆EoOYgmEaZE :05/02/20 02:12:05
人より仕事がn倍遅い人は大抵人よりn倍丁寧に作ってます。
SEなら人よりn倍システムのことを考えてます。
それはそれで才能だと俺は思うのです。

4 :仕様書無しさん:05/02/20 02:12:41
4様

5 :高卒アニオタ中年:05/02/20 08:07:48
>>1
仕事が極端に遅い奴は今まで何人も見てきたが・・・
一番が考えられることは、「作業の目的が見えていない」んじゃないか?

たとえば、バグの発見から対処・確認までを例にとってみるとだな。

・試験で「何かがおかしい」事には気がつく。
・発見に至るまでの手順が明確になっていないので再現に苦労する。
・仕方が無いのでそれらしいプログラムを色々変更してみる。
・うまくいった所で、そのコードをそのまま対処案として利用する。
・再現しないかどうか一通り試して対処完了。

なんて行動を「いつも」やってる香具師が実在するわけだ・・・・
本人から見れば、他の奴と同じ行動しているつもりなんだそうだが。

こんな事 繰り返していてもまともな仕事している奴らの速度に
かなうわけは無いのは理解できるよな? >>1
まずは、行動を細分化して、なるべく細かい単位に分けてみろ。
その単位で自分の行動と他人の行動の比較からやってみろ。
比較した行動の結果に開きがあるのなら、
他人がその行動を「何のために」やっているのか考えてみろ。
「次の行動に繋がる何か」が必ずあるんだから、それを探せ。
一連の作業における個々の目的をちゃんと理解している奴は
作業を効率的にこなせるようになるもんだ。

作業を前倒ししたかったら それなりの努力くらいしろよ?

6 :仕様書無しさん:05/02/20 09:55:22
良スレになる予感age

7 :仕様書無しさん:05/02/20 11:00:22
>>1
単純に普通の奴の3倍の仕事を抱えて無いかどうか確認してから
遅いと結論を出した方がいいな。

8 :仕様書無しさん:05/02/20 11:18:41
>>7


9 :仕様書無しさん:05/02/20 11:42:18
>>7
よくある話。


10 :仕様書無しさん:05/02/20 12:07:40
納入までのトータルで早ければ問題ないのでは、

11 :仕様書無しさん:05/02/20 12:36:31
遅い事を悩んでるだけでも素晴らしいよ。

人より少ない作業量で人より仕事遅いクセに全然平気な顔してる奴のなんと多い事か・・・。
そいつらの残業は全部生活残業に思えてならない。

12 :◆ItkaRMAJ7. :05/02/20 14:01:30
( ゚д゚)ノシ 俺も仕事が遅くて困ってます。
       どうやったら、複数のプログラムを並列に開発するのが効率よくなりますか?

13 :仕様書無しさん:05/02/20 14:20:26
>>12
意味解らん


14 :せる ◆9gLessA9bA :05/02/20 16:04:37
>>5
なるほど。僕もそんなことをやっています。
めんどくさがりやなんで、とりあえず動かしています。

>>7
仕事の量は、ほかの人とおなじだったりします。
それでも3倍かかっています。
スケジュールが開発4日、テスト4日でなのに
12,12ぐらいかかる (´;ェ;`)

15 :仕様書無しさん:05/02/20 16:32:24
ソープであんまり遅いと嫌がられるよ

16 :仕様書無しさん:05/02/20 21:12:10
ダメだっ!こんなコードは美しくない!!
で、捨てて書き直し。

17 :仕様書無しさん:05/02/20 21:48:26
>>7
頑張れ!

18 :仕様書無しさん:05/02/20 23:34:35
>>7
ガンガレ

19 :せる ◆9gLessA9bA :05/02/20 23:51:45
ありがとうございます。

みなさんの応援に答えられるようがんばりたいとおもいます。

今週から4日間テストになります。いまケースを自宅で考えてます。

むずかしい。。。(´;ェ;`)

20 :仕様書無しさん:05/02/21 19:59:22
なんとか、テストデータ作成までこぎつけました。(テストケースレビューはとおってませんが・・・)
じっくりやろうと、鉛筆で表をかいて作戦を練っていたら、となりのかたが、笑って
エクセルじゃだめなの?とご助言くださいました。

エクセルだと、入力は速いんですが、間違いがおおくなるきがします。
どっちがいいんだろう???などと考え込んでいます。

みなさん、インフルエンザがはやっているので気をつけてくださいね

21 :せる ◆9gLessA9bA :05/02/21 20:00:44
すいません >>20はわたしでした。
名前をいれわすれました。

22 :仕様書無しさん:05/02/21 21:08:23
>>1
これはネタのつもりなのかも知れないが、
普通にかな漢字変換を使っていれば漢字になっている筈の単語が、
ひらがなのままなのは、書いていて気持ち悪くならないか?

俺は、まるで「アルジャーノンに花束を」を
読んでいる気分になったよ。


23 :せる ◆9gLessA9bA :05/02/21 21:57:12
>>22
よみやすくしてみました。

24 :仕様書無しさん:05/02/21 22:29:38
気持ち悪くないだろ。神経質な野郎だ
ore ha ro-mazi demo zennzenn kamawanaize

25 :仕様書無しさん:05/02/21 22:35:47
>>24はコボラー

26 :仕様書無しさん:05/02/21 22:57:23
pupu, kobora- no wake naidaro. narereba ro-mazi nannte raku ni yomerumonda

27 :せる ◆9gLessA9bA :05/02/22 00:04:16
>>26
のほほ

28 :仕様書無しさん:05/02/23 11:26:38
自分が読めれば良いという理由で、
一般的には読みにくい文章を平気で垂れ流す香具師は
糞コード量産型PG。

29 :仕様書無しさん:05/02/25 00:53:43
私は業務系PGですが、仕様の理解力が低くて困ってます。

小さい案件ならまだ大丈夫なのですが、
大きな案件になると自分の作った機能はわかっても
本当に仕様として大丈夫なのか、など思ってしまい、
考えたり、見直したり、修正したりと時間が掛かってしまい
残業につながってます。

仕様を理解するコツってあるんでしょうか。

30 :仕様書無しさん:05/02/25 02:25:18
>>29
理解というよりも、読んだ仕様書の内容をすぐに忘れてしまうタイプなんじゃない?
俺も以前そうだったからわかるよ。
原因としては能動的に仕事に取り組んでなかったっつうのがデカいなあ。
自分がプロジェクトを引っ張るんだというくらいの気持ちでやれば
自然と仕様とかにも興味が出てきて頭に入るようになるよ。
その方が楽しいし。評価されるし。

他にも、理解した仕様はなるべく人に説明してアウトプットすることで
記憶に残るようにしてみる、なんて工夫をしてみたらどうでしょ。
鋭い人に理解不十分な所をツッコまれて、悔しくてさらに調べることで
理解度が増したりするし。

31 :仕様書無しさん:05/02/25 11:05:28
1.会社に着いたら、今日一日でやることを書き出す。
2.書いた内容ごとに所要時間を決める
3.ひとつの項目をこなすごとに消していく
・・・と、これだけでも随分違うぞ。まずはやってみれ。

あと、納期が迫らないと仕事しないタイプの奴にオススメなのが、
「定時後に無理やり個人的な(ずらせない)予定を入れる」ってのはオススメだな。
これを終わらせないとヤバイ!という「俺納期」な状況を人為的に作ることで集中できる場合が多い。

俺の場合、子供が出来て保育園の送り迎えをせにゃならんので、ほぼ毎日定時上がり。
おかげで毎日納期間際ですよ・・・orz
まぁ、逆に今まで自分がどれ程ダラダラ仕事していたか解ってよかったんだけどね。

32 :仕様書無しさん:05/02/25 13:11:00
>>1
体を赤く塗ったら±0かも

33 :仕様書無しさん:05/02/25 16:52:57
角が足りないから結局ダメだと思われ?

34 :仕様書無しさん:05/02/26 00:30:43
今日は1メソッド書いた!充実!

35 :29:05/02/26 01:33:24
>>30
レスありがとうございます。

言われて見ると確かにすぐに忘れる、というか明確には覚えていないですね。
上司から「ここって今どういう仕様だっけ」と聞かれたときにも
コードを見てからでないと正確に答えられません…。

しっかと記憶していないと全体では漠然としか
つながらないですね。指摘されて納得しました。
作ったところなど一度理解したところは記憶するようにがんばってみます。

ただ、仕様をしってそうな人はみんな忙しそうで
なかなか話しかけずらいのでとりあえずはノートに
自分なりにまとめて書いてみることをやってみようと思います。


あ、ふと思ったのですが普段から仕様を設計しているSEの人たちは
他の人が作った仕様書を読んであっさりと仕様を理解したりできるんでしょうか?
できるのなら私も設計の練習とかをしてみようと思うのですが。

36 :仕様書無しさん:05/02/26 13:53:55
どうなんだろ。実務の仕様を解析する前に、
DBとネットワークの基本的な理論を頭に叩き込むのが先では。
そうでないと欠陥のある設計も欠陥のあるとの認識さへもできないでただの丸覚えですぜ。

もしくは、ずうずうしく質問しまくれ。経験1〜2年のやつが一月考えても答えの出ない問題が、
理論&実績 十分の人ならその日のうちに回答が出るっつうことがあり得るでしょ。
はっきりした回答でなくても、一般論だけでも聞く。答えてくれた人に責任取らせるようなこと
はしない(あくまで最終判断は自分)を心がければいいのでは。

自身も勉強しながら礼儀を持って質問もしまくる。
トラぶっても自分の責任。こんな感じの認識かな。俺は。

37 :似非E:05/02/26 14:41:28
>>35
>あ、ふと思ったのですが普段から仕様を設計しているSEの人たちは
>他の人が作った仕様書を読んであっさりと仕様を理解したりできるんでしょうか?

仕様書を作成した人に拠る。
読み易く綺麗な仕様書はすんなり頭に入る。

仕様を覚えるコツはシステムの全容を漠然とでも良いから理解すること。
そしてその中で自分が作成する物は、どの位置なのか知ること。
それがイメージ出来れば、自分の成果物に興味が出てくるから中々忘れないようになる。


38 :仕様書無しさん:05/02/26 14:47:48
俺もトロ臭くて困っているYo....

深く考えすぎでなかなか上手くいかないのもあるけどなぁ・・OTL

39 :仕様書無しさん:05/02/26 14:55:09
>>1
みらいすさんのお知り合いですか?

>>3
ちょっと救われた

40 :似非E:05/02/26 14:58:18
仕様書を渡されたら、まずは斜め読みをすること。
そうするとシステムの大まかな流れが理解できる。
次に改めて仕様書を精読する。

例えばある目的地に行く時に、まずは縮尺が大きめな地図を見て、
現在地と目的地の位置関係を把握するだろ?
システム開発作業も同じ事が言えるんだよ。

まず全容が解る資料から目を通し、段々と細かい機能へと入っていく。
設計作業はそれをしているし、プログラム開発作業もそれを取り入れるべき。



41 :仕様書無しさん:05/02/26 15:11:04
ソフトウェアのメンテナンスに終わりはない。
止め時を知らないと台無しになる。

42 :仕様書無しさん:05/02/27 00:04:49
俺的には仕様理解のキモはいかに頭の中で映像的にイメージできるか、だな。
文章や数値でいくら考えても眠くなるだけで全くダメ。

とにかく落書きでも良いから
「ここがあーなって、こうなって、こいつと連携して・・・」
と図に描いてみることをオススメする。
UMLとか形式ばったものでなくて、自分がわかればOK。

43 :似非E:05/02/27 00:07:47
そうだな。
左脳よりも右脳で仕様を理解した方が良いな。


44 :せる ◆9gLessA9bA :05/02/27 02:05:32
はじめての前倒し(1日)になりました。
うれしいです。

しかし、次のPGMは、テーブルの内容をほぼファイルに出力するというだけの
プログラムなんですが、項目設定数が300こえてます。これを3日で開発してといわれました。
csv形式ではないので、全角、半角で文字数をあわせなきゃならないし、、、(´;ェ;`)ウゥ・・・
マクロつかったことないし、どうすればいいのでしょうか

とりあえず、月曜日にスペシャリストの方にきいてみることにします;::

45 :せる ◆9gLessA9bA :05/02/27 02:08:03
>>29
僕も業務系です。

あまり難しいプログラムをやらせてもらったことはないです。
将来、僕が対面しそうな悩みですね。
参考にさせていただきます

46 :仕様書無しさん:05/02/27 18:54:22
db表を通常ファイルに出力するのなら
「なぜdbを使っているのか」
という意義が激しく不明だw

47 :仕様書無しさん:05/02/27 20:45:25
まぁ客がアフォなんだろう。(w

48 :29:05/02/28 00:32:47
みなさんレスありがとうございます。

私の場合、皆さんのアドバイスと逆なことやってたみたいです。
漠然としたなかとりあえず要件を満たすコーディングして
担当した箇所を手がかりに全体を把握していくというやり方をしてました。
答えから問題を導くみたいなやりかたになっていたのかな?

なんで私がそのようなやり方をしていたかっていうと
実装と仕様の架け橋みたいなものがないとなんかイメージが
わかなかったからなんです。仕様書を読んでもふーんで終わってしまったりで。

>仕様の全体を意識して読んで、
>個々の機能の位置というか役割を把握する。
>そのイメージ化には簡単な絵を書いてみたりする。
レスを読んでて地図の話とかなるほどと思いました。
参考になります。実践してみます。

>>45
、私もまだまだ未熟者なので一緒にここでのアドバイスを参考に
仕事を早く終わらせることが出来るようにがんばって行きましょう。

49 :仕様書無しさん:05/02/28 00:44:57
>>1
ツールを上手に使いこなせば速くなるぞ。
それとあせるな。

それから上司に進捗報告するインターバルをもっと
長くしてもらえるように頼め。
一時間おきに進捗を監視されては落ち着いて仕事もできないだろ。
開発環境をインストールし、設定したり
仕様書をよんだれ既存のコードを解読するだけで一時間しかたっていないのに
「もうできたか?」なんてせっかちで非現実的なこといってくる上司はウザイだろ。

備えあれば憂いなしだ。
作業をなんとかして自動化しろ。Makefileを書く、build.xmlを書く、IDEを使うなり
工夫が必要だ。バグ取りに関してもテストファースト、テスト駆動開発をよく実践して
バグ取りになる恐れを減らして仕事の能率を高めるべきだ。
テストファーストのことをよくわからない上司の中には
そんなことは時間の無駄だと怒ってくるバカ上司がいるかもしれない。

そういうときこそ頭を使って知恵を絞って上司に進言する勇気が必要だ。
説得するんだ。実際に実例をあげてみる、やって上司に見せることで説得できる。
テストファーストを実践すれば潜在的なバグが増えることを証明するんだ!







50 :仕様書無しさん:05/02/28 00:48:08
> 仕事の量は、ほかの人とおなじだったりします。
> それでも3倍かかっています。
> スケジュールが開発4日、テスト4日でなのに
> 12,12ぐらいかかる (´;ェ;`)

ほんとeXtreme Programmingをやってみたほうがよさそうだな。
開発環境はどうなっている?
バグを順に追っているか?
デバッグ方法は?
IDEは使っているか?
ビルドツールは使っているか?
テスト駆動開発またはテストファーストは行っているか?

51 :仕様書無しさん:05/02/28 00:53:09
>>16
> ダメだっ!こんなコードは美しくない!!
> で、捨てて書き直し。

おいおい、本当に捨てているのか?
過去のコードはちゃんと残しているか?
自分のコードに自身がないのはまさにテストファースト、テスト駆動開発を
怠っている証拠だな。

書き直す前のコードはCVSやSubversionなどのバージョン管理システムを使えば
簡単に残すことも、簡単に以前の状態に戻すことも容易だ。
是非とも導入することをお勧めする。チームで導入すれば
断然開発効率が上がる。超おすすめ、としか言いようがない。

それからコードの最適化は基本的に後回しだ。

最初のうちはコードは遅くてもかまわないから開発効率を高めるような
コーディングをするべきだ。とにかく、クラスを作れ。デザインパターンを使って
コードの修正を容易にしろ。

そのコードのテストもうまく通ったところでそのコードを残しつつ、バージョン管理システムにアップしておき
それから最適化をする。デザインパターンを使ったせいで重たくなったとしても
あるていどできかがってからデザインパターンを破棄してしまえばバグは大幅に減る。

52 :仕様書無しさん:05/02/28 00:56:15
>>20
> なんとか、テストデータ作成までこぎつけました。(テストケースレビューはとおってませんが・・・)
> じっくりやろうと、鉛筆で表をかいて作戦を練っていたら、となりのかたが、笑って
> エクセルじゃだめなの?とご助言くださいました。

Excelの代わりにOpenOffice Calcにすれば経費を削減でき会社も潤うかもなw


> エクセルだと、入力は速いんですが、間違いがおおくなるきがします。
> どっちがいいんだろう???などと考え込んでいます。

Excelが嫌ならテキストエディタでもいいから書いてみな。
UMLツールもお勧めだぞ。
UMLツールで図を描くんだ。
VisioとかIIOSSとかOmondo EclipseUMLとか、JudeとかRational RoseやRational XDEとか
使ってな。




53 :仕様書無しさん:05/02/28 00:57:42
>>29
> 私は業務系PGですが、仕様の理解力が低くて困ってます。
>
> 小さい案件ならまだ大丈夫なのですが、
> 大きな案件になると自分の作った機能はわかっても
> 本当に仕様として大丈夫なのか、など思ってしまい、
> 考えたり、見直したり、修正したりと時間が掛かってしまい
> 残業につながってます。
>
> 仕様を理解するコツってあるんでしょうか。

何度もいうけど、これもテスト駆動開発、テストファーストをすれば
そんな不安も大分減るよ。
マジでeXtreme Programmingを実践してみな。とにかくXPの本やサイトを読んでみ。
コツがわかってくるぞ。

54 :仕様書無しさん:05/02/28 00:58:21
とても職業プログラマとは思えない発言だ

55 :仕様書無しさん:05/02/28 00:58:25
顧客との交渉も怠るなよ。
顧客に質問したいことはしっかりと質問すべきだからな。
わからないことはわからないとはっきりいわないとトラブルの元だからな。

56 :仕様書無しさん:05/02/28 00:58:45
>>54
職人プログラマの間違いじゃないのか?

57 :仕様書無しさん:05/02/28 01:00:36
>>30
仕様を忘れてしまいがちなのは
理解したこと、疑問に思ったことなどのメモをただ怠っているだけじゃないのか?
それから質問も怠っていると。
理解したつもりでも理解していないことてのはよくある。
念のために質問することも重要だ。



58 :仕様書無しさん:05/02/28 01:02:59
>>31
> 1.会社に着いたら、今日一日でやることを書き出す。
> 2.書いた内容ごとに所要時間を決める
> 3.ひとつの項目をこなすごとに消していく
> ・・・と、これだけでも随分違うぞ。まずはやってみれ。
>
> あと、納期が迫らないと仕事しないタイプの奴にオススメなのが、
> 「定時後に無理やり個人的な(ずらせない)予定を入れる」ってのはオススメだな。
> これを終わらせないとヤバイ!という「俺納期」な状況を人為的に作ることで集中できる場合が多い。

それなら、「超」整理法に載っているようなテクニックも通用するな。
万が一のことを考えて予備日を設定するとかな。
ちゃんとスケジュール管理も怠らないように手帳に予定を書くのも忘れずにな。
スケジュールソフトを使うもよしだな。会社ではスケジュールを共有するソフトが
使われていると思うが




59 :54:05/02/28 01:06:01
>>56
いや。
職人なら「仕事を飛躍的に速くする方法」なぞ存在しないことを
骨身に染みて理解しているのでなおさらありえない。
#ちなみに>54が、どのレスにあてたレスかはあえて書かない。
#職業PGでない人間が「自分のことを言われた」とわかればそれでいいのだ

60 :仕様書無しさん:05/02/28 01:10:23

>>35
> >>30
> レスありがとうございます。
>
> 言われて見ると確かにすぐに忘れる、というか明確には覚えていないですね。
> 上司から「ここって今どういう仕様だっけ」と聞かれたときにも
> コードを見てからでないと正確に答えられません…。

それはだな。もしかするとこういうケースも考えられる。
そのコードが非常に汚くてコメントがほとんどない。
メソッド/クラス分け分類がちゃんとできていない。
パッケージ(名前空間)管理もちゃんとできていない。
パッケージ(namespace),クラス、メソッドの名前が非常にわかりにくく、
何をするコードがわからなくなっている。

ちゃんとバージョン管理を使え。
自分のバージョン管理システムにログインユーザアカウントを持てば
だれが、いつどのコードの何行目を更新したのかがすぐにわかる。
上司に報告するときも、サーバにコミット(チェックイン)してから報告すれば
上司は更新された新しいコードをサーバからダウンロード(チェックアウト、アップデート)することで
更新状況を確認できる。

それからコードコメントには自分の名前、日付もちゃんといれろ。
それが面倒ならそれもまさにバージョン管理システムを使えばいい。
コード内に自動的に自分の名前、日付を簡単にいれることができる。

UMLをつかってクラス図とか書いてみな。
何がしたいか、何をすべきか、今の設計が良いのか悪いのかがよくわかってくる。

ソースコードを書いたのが自分でなかったらそれはあんたのせいではない。
そのときはコードを書いた奴が悪い。どうにかして汚いコードを書いた奴をバッシングしろ。

61 :仕様書無しさん:05/02/28 01:11:29
>>59
ようするにおまえさんはただの釣り氏ってことか。
と釣られてみる

62 :仕様書無しさん:05/02/28 01:16:40
> しっかと記憶していないと全体では漠然としか
> つながらないですね。指摘されて納得しました。
> 作ったところなど一度理解したところは記憶するようにがんばってみます。

頭だけに記憶するんだったらメモしろ。大事なところがコードの何行目なのかもちゃんとメモしろ。
上司にも何行目なのか聞け。上司と対話するときもメモを怠るな。
それから、ソースコードを持って上司と対話しろ。
印刷代がもったいない?
だったら上司とお前とが一緒にディスプレイに向かって対話しろ。

それができない?
だったらノートPCをもって上司と対話しろ。

> ただ、仕様をしってそうな人はみんな忙しそうで
> なかなか話しかけずらいのでとりあえずはノートに
> 自分なりにまとめて書いてみることをやってみようと思います。

それはいかん!
忙しそうだから話しかけられない?
本当に忙しそうなのかまずは聞いてみろ。

本当に忙しいといわれた?
だったらメールを使え。メールで送りたいと伝えろ。
質問リストも作れ。

63 :仕様書無しさん:05/02/28 01:16:51
> あ、ふと思ったのですが普段から仕様を設計しているSEの人たちは
> 他の人が作った仕様書を読んであっさりと仕様を理解したりできるんでしょうか?
> できるのなら私も設計の練習とかをしてみようと思うのですが。

XPだな。SEとしてのスキルも必要だな。たとえSEと呼ばれなくてもな。


64 :仕様書無しさん:05/02/28 01:20:12
>>59
あのな、>>1のさまざまな発言を見ているとどうみたって
以前よりも効率化できるほうほうがいくらでもありそうだと
思えるんだよ。それでアドバイスしただkでネガティブな発言をするのはどうかと。
何もしないで今のままでいるよりかは断然よくなるなら
やったほうがいいことにこしたことはないし
やって損をすることではない基本的なことをアドバイスしているだけだ。

むしろXPすらできない人間こそが職業プログラマとは認めがたいものだぞ。




65 :54:05/02/28 01:20:37
>>61
釣っているつもりも荒しているつもりも無い。
ここは匿名掲示板だからね、
どれが正しい発言なのかは読んでいる人間が判断する事だ

66 :仕様書無しさん:05/02/28 01:24:34
>>44
三日か。まだいいほうだな。
Perlとか正規表現をしっていればすぐできるからな。
それを30分でやれというとあせってバグがでて結局10時間もかかってしまうこともある。

どんなやりかたがお勧めか依頼人や周りに聞いてみたか?


67 :仕様書無しさん:05/02/28 01:25:06
>>65
んじゃ、喪前はXP否定派か?

68 :仕様書無しさん:05/02/28 01:27:07
>>44
テーブルの数がたった一つならたったの短い一行のコマンドですんでしまいそうだが。
MySQLやPostgreSQLのテーブルをCSVに変換するのかそんな感じだったからな

69 :54:05/02/28 01:37:06
>>64
>何もしないで今のままでいるよりかは断然よくなるなら
>やったほうがいいことにこしたことはないし
>やって損をすることではない基本的なことをアドバイスしているだけだ。
違う。
特にここ「やったほうがいいことにこしたことはないし」。
方法論には絶対正しいものは存在しない。そして全ての場合に有効なツールなぞ無い。
双方が開発局面に左右される要素だ。

>むしろXPすらできない人間こそが職業プログラマとは認めがたいものだぞ。
こういう発言が「職業プログラマとは思えない」という判断の根拠なのだが。
XP開発方法論は脚光を浴びているのは事実だが、実施をしている開発現場は、
(断言しても良いが)到底、過半数には達していない。

70 :仕様書無しさん:05/02/28 01:49:32
もう嫌だよ

71 :仕様書無しさん:05/02/28 02:23:32
>>69
> >>64
> >何もしないで今のままでいるよりかは断然よくなるなら
> >やったほうがいいことにこしたことはないし
> >やって損をすることではない基本的なことをアドバイスしているだけだ。
> 違う。
> 特にここ「やったほうがいいことにこしたことはないし」。
> 方法論には絶対正しいものは存在しない。そして全ての場合に有効なツールなぞ無い。

なあ、あんた、誰が「絶対正しいものがある」なんて言ったんだ?
「絶対」なんてどこにも書いてないだろう。
何もやらないよりはましだってことだ。
XPのプラクティスは実践しなくても
基本的でシンプルでわかりやすいことだし知っておいて損はしないことばかりだろう。
XPを知ったからといって大きな実害が出たといえるか?
ウォータフォールを知ったからといって大きな実害は出ないんだし。

72 :仕様書無しさん:05/02/28 02:24:26
> 双方が開発局面に左右される要素だ。
> >むしろXPすらできない人間こそが職業プログラマとは認めがたいものだぞ。
> こういう発言が「職業プログラマとは思えない」という判断の根拠なのだが。
> XP開発方法論は脚光を浴びているのは事実だが、実施をしている開発現場は、
> (断言しても良いが)到底、過半数には達していない。

実践している現場が少ないからといってXPは良くないと言い切るのか?
それは詭弁じゃないのか?
なれない手法に移行するのに手間取っているだけだろう。
頭でっかちの多い職場であればあるぼど移行しづらいだろうし。
よくわからないものは様子見をするということもありうるだろう。
それに、テストファーストはXPだけの専売特許ではない。
アジャイル開発はXP以外にもたくさんある。
あんたのようなそんな詭弁を言うなら
ウォータフォールを実地している現場がどれだけあるか
のデータのほうが重要なんじゃないのか?
悪魔の証明なんて卑怯だぜ。



73 :仕様書無しさん:05/02/28 02:24:38
それにオブジェクト指向が普及したのも随分と時間がかかったじゃないか。
20年前から存在するものがやっと実用化されるまで大変な道のりだったわけだ。
そこでXPを否定するのはどういうことか。
実際にXPを試したことがあるのかい? XPのことを本当によくわかっているのかい?

まさかとは思うが、あんたはごまかしたいがためにわざとXPの普及を妨げている
んじゃないかと疑ってしまうんだよ。
世の中には、「難しいからあの人のコードは読めない。
彼はすごくスキルがあるからコードが難しいんだろう。」

と思われたいがためにわざと汚いコードを書いて、読みにくくしている輩がいるらしいからな。
あまりにも自己保身でまったく陰湿なものだよ。あんたもそんな陰湿な人間の一人じゃないかと
疑ってしまうんだよ。
XPが普及してしまうと、あんたの書いたスパゲティコードの正体がばれて
仕事が失われるんじゃないかと。それを恐れてわざとアジャイル開発の普及を妨げているんじゃないかと。
アジャイル開発否定派ってのはそういう陰険なのが多そうだと邪推してしまうよ。

74 :仕様書無しさん:05/02/28 02:42:05
XP実践してるの想像しただけでキモすぎる
リアルで「観鈴ちん萌え〜」とか叫ぶオタを見る程キモすぎる

75 :仕様書無しさん:05/02/28 02:44:49
そもそもリアルでのプログラマの会話が痛いのは何故だろう
ちょっと一般人の前では参加したくないね

76 :仕様書無しさん:05/02/28 03:02:49
>>74
実践している現場を見たことがないんだろう。
やってみろ。
最低三つのプラクティスを実践するだけでも実践したことになる。

77 :仕様書無しさん:05/02/28 03:04:00
>>74-75
実践したこともないくせに
そうやって叩くのは良くないぞ。
食わず嫌いは本当に良くないぞ。
文句は実際にやってみてから言え。
そのほうが説得力があるからな。



78 :仕様書無しさん:05/02/28 03:06:03
>>75
どう痛いんだかね。
専門用語を連発するのが痛いかね。

「このクラスは〜」
「ここでStrategyパターンを適用すると〜」
「ここにはクヌースモーリスブラットのアルゴリズムを〜」
というのがそんなにキモかね。

79 :仕様書無しさん:05/02/28 03:19:37
ちょっとキモイね

80 :仕様書無しさん:05/02/28 03:24:38
>>79
正直、そういうあんたが一番キモイんです。


81 :54:05/02/28 03:27:15
>>71
「XPは一個人でやるものではない」という前提を忘れていないか?だから
>何もやらないよりはましだってことだ。
を否定しているのさ。
「何も知らないよりはましだってことだ」という発言なら>71と整合しているけど

>>72
曲解しているな。>>69をもう一度読め。
「職業プログラマとは思えない」という判断の背景となる事実を書いただけであって
どこに「XPの否定」が書いてある?

>>73
論旨不明瞭だ。
>あんたもそんな陰湿な人間の一人じゃないかと 疑ってしまうんだよ。
どうぞご勝手にw

XPに対する認識/理解の深さを競うつもりはないが、「XPは一個人でやるものではない」ということ位の意見の一致はあるか?
XPという開発方法論の是非は別にして、ここは「個人の仕事の方法のスレ」だろう。
少なくとも「XPという言葉を出すのははスレ違い」だという事くらい理解してもらいたいものだ。

・・・まあいい。何が正しいかを判断するのはあくまで読む人だ。私が「陰湿な人間」であるかどうかの判断も含めてね。
「匿名掲示板には正しいことばかりが書かれるわけではない」という前提を思い起こして欲しかったから>>54を書いたまで。
あなたと議論しようと思って書いたわけではない。

82 :仕様書無しさん:05/02/28 03:56:34
仕事が遅いのは職場に女の子がいないからだ

83 :仕様書無しさん:05/02/28 03:57:48
女がいると気が散る

84 :仕様書無しさん:05/02/28 04:13:51
仕事が遅いのは職場に女の子がいないからだ

85 :仕様書無しさん:05/02/28 04:52:24
仕事が遅いのは職場に女の子がいるからだ
気が散る!

86 :仕様書無しさん:05/02/28 17:18:43
仕事が遅いのは職場に、場の雰囲気の読める可愛い女の子が居ないからだ

87 :せる ◆9gLessA9bA :05/03/01 23:21:54
やばい 終わらない・・・
現在5日たっていますが、まったく動きません・・・

88 :せる ◆9gLessA9bA :05/03/01 23:26:40
>>58
目標を紙に書いて実践するようにしました。

ただ、目標通りにいかないのですが、これでいいのでしょうか???
今日は、机上デバッグを3時間とみて、目標たてたんですが、
けっっ局5時間もかかってしまった。
しかもうごかねーーーー

死にたい

89 :仕様書無しさん:05/03/01 23:41:14
焦りはバグを生む。
焦りはバグを見落とす。
焦りは・・(ry

まぁ、焦ってもしょうがないさ

90 :せる ◆9gLessA9bA :05/03/01 23:50:00
調子が出ない時は、首・・・・

んもー!!

91 :仕様書無しさん:05/03/02 05:15:21
見積もりが正確になったら、実力が付いてきた証拠。
自分には何ができて何ができないのかを理解できているか、
目の前の仕事が確実に分析できているか、
その辺が見積もり時間の正確さになって出てくる。

見積もり通りにいかないなら、まだまだってことだ。
実際に目の前の問題を解決するのに自分が要する時間はどんなもんなのか。
それを把握できているっていうことは、目の前の問題を理解しているってことだ。


バグの修正もにたようなもんなんだがな。
目の前のコードの動きを、本当に理解しているか?
変数の動きを逐一頭の中でトレースできるか?
それができなきゃ、本当にソースが読めているとはとても言えないし、
バグをさくさく取るのも難しいだろうな。

本当に理解できていれば、コードに起因するバグは必ず取れる。
まぁガンガレ。

92 :仕様書無しさん:05/03/02 08:18:10
>>91
前半:問題を理解するための方法を教えてクレ
後半:ソースを読む方法を教えてクレ

なにが言いたいかというと、
これらの記述が無ければ内容が空虚だ
と言いたいのだ

93 :仕様書無しさん:05/03/02 14:25:25
色々やってみればいいじゃん。で、だめだったら別のやり方を考えて試す。日々これの繰り返しだろ。

「これをやるだけで劇的に効率が上がる!」なんてのは無い。
そんなのは20年も前にブルックス先生がおっしゃってる事だし、ベテランは骨身にしみている。

このやり方がいいと言うのは勝手だが、それを押し付けるのはイクナイ。誰とは言わんがw

94 :仕様書無しさん:05/03/02 14:38:50
納品1日前。重大なバグを発見。
開発担当は俺の同期だったのだが、バグ修正をしている途中で発狂し、
そのまま会社を出て道路に飛び出して車に引かれて死亡しました。
彼が使っていたマシンに遺書らしきメッセージが残されていました。
「僕にはできません。ごめんなさい。」と。
まじめな奴だったんだが、相当なやんでいたらしい。

95 :せる:05/03/02 14:45:18
ソースレビューで大幅修正キター
これでまちがいなくおくれたことになります

うわあああああ

96 :せる ◆9gLessA9bA :05/03/03 00:04:57
>>94
ひどいはなしですね・・・

97 :仕様書無しさん:05/03/03 04:41:04
人道的に見れば「酷い話」だが、
できないと思ったらそれをはっきりと言うべきなので、
それができなかった香具師にも問題がある。
ただし、はっきり言っているのに何も対応しなかったために起きたことなら、
対応しなかった管理職に問題がある。

>>92
王道はない。
自分なりのアプローチでやってみて、
理解できているかをこまめに周囲とやりあうのが無難ではあると思うが。

ソースを読めるようになる方法もしかり。
俺は消防の頃からコード書いてるから、読めて当然・書けて当然。
たぶん俺に聞いても参考にはならんよ。

98 :仕様書無しさん:05/03/03 06:31:08
納期1日前のバグ修正中に引き継ぎもせずに死ぬなんて、
本当にひどい話だな。発狂は納品してからにしてくれ。

99 :仕様書無しさん:05/03/03 11:50:33
>>94
よく似た話なんですが、俺の先輩も開発中にいきなり「何で動かねぇ〜んだ!」
と叫び出し、自分のパソコンをぶっ壊した人がいます。
その先輩は精神がいかれてしまい、今も精神患者として牢獄のようなところに
入れられています。
「殺してやる」と毎日言っているらしいです。

100 :仕様書無しさん:05/03/03 13:44:34
100

101 :仕様書無しさん:05/03/03 21:56:22
>>81
> 「XPは一個人でやるものではない」という前提を忘れていないか?だから
> >何もやらないよりはましだってことだ。
> を否定しているのさ。
> 「何も知らないよりはましだってことだ」という発言なら>71と整合しているけど

また負けず嫌い小僧の発言か。
無理矢理話を強引にこじつけようとしていることが見え見えだぞ。
XPは個人でやるものではないという前提をつけて勝手に話を進めているのは
お前だけだ。お前の脳内だけで完結しているだろう。
XPの考え方は個人でも役に立つ。XPの考え方を全く知らずに
いるよりは知っていた方がバグを減らす方法を理解することができるので
考え方を理解する上ではXPは役に立つ。

>>71の発言の何が何行目がそいつと整合しているんだか意味が不明だな。
お前は正論を言っているように見せかけて曖昧に言って煙に巻こうとしているだけだ。
まさに詭弁だな。

> >>72
> 曲解しているな。>>69をもう一度読め。
曲解しているのはお前だ。
>>69をもう一度読んだって
お前は勝手に「やったほうがいいことにこしたことはない」を
「絶対に正しいもの」だと勝手に解釈して
「方法論には絶対正しいものは存在しない。」と
こじつけで話をつけようとしていないか。


102 :仕様書無しさん:05/03/03 21:56:35

> 「職業プログラマとは思えない」という判断の背景となる事実を書いただけであって
それが事実だというならちゃんとソースを出してみるんだな。
脳内事実ばかりならべる馬鹿どもにはウンザリするんだよ。

> どこに「XPの否定」が書いてある?
書いてあるんだよ。お前の頭にだよ。

> >>73
> 論旨不明瞭だ。
自分のことを棚上げにして偉そうなことを言わないように。


> >あんたもそんな陰湿な人間の一人じゃないかと 疑ってしまうんだよ。
> どうぞご勝手にw
そうか、XPの普及を阻害するお前は陰湿な人間だったのか。
かつて、インターネットの普及を阻害しようとした連中みたいだな。
クリフォードストールみたいな連中のようにな。


103 :仕様書無しさん:05/03/03 21:56:44


> XPに対する認識/理解の深さを競うつもりはないが、「XPは一個人でやるものではない」ということ位の意見の一致はあるか?
そんな決めつけはお前の脳内だけでやってろ。
一人で開発されたものが他社に引き継がれることがある。
そのときも一人だからといって、XPをやらんでは、テストプログラミングを怠った結果
複数人数の開発チームを持つ引き継ぎ人が多大な迷惑を受ける。

> XPという開発方法論の是非は別にして、ここは「個人の仕事の方法のスレ」だろう。
> 少なくとも「XPという言葉を出すのははスレ違い」だという事くらい理解してもらいたいものだ。

でたらめなことばかり言う小僧だな。
お前はただXPが気に入らないだけだろう。
気に入らないことを言われたくないだけの我が儘な餓鬼だ。

仕事を速くする方法の一つでXPを実践してみるのはどうか、という意見が
出されても不思議はないだろう。
XPが気に入らならRUPでも出すか? クリスタルクリアでも出すか?


> ・・・まあいい。何が正しいかを判断するのはあくまで読む人だ。私が「陰湿な人間」であるかどうかの判断も含めてね。
> 「匿名掲示板には正しいことばかりが書かれるわけではない」という前提を思い起こして欲しかったから>>54を書いたまで。

まったく>>54とつながりがない発言だな。
自分の発言こそが正しいとほざいているかのようで厚かましい。

とにかく詭弁を並べてXPを知らない初心者に嘘を並べ立てて
ネガティブな発言によって
XPの印象を悪くしようとし困惑させようという魂胆が見え見えだ。


104 :仕様書無しさん:05/03/03 21:58:08
>>88
目標通りにいかないと
気が済まない奴のことを原理主義者という

105 :仕様書無しさん:05/03/03 22:01:48
>>88
TODOボードというものを知っているか?

達成した目標には印をつけろ。
達成しないなら繰り越す。
優先順位もつけろ。
順位はもちろん変動するので
大雑把につけろ。

新しい目標が出たら、
それがすぐに解決できなさそうな
ものだったらすぐにメモする。

うごかないパターンをメモしてみろ。
消去法で答えを見つけ出しやすくしろ。

コメントもかけ。
目標やメモなどは紙だけでなく
エディタに書くもよしだ。
そのファイルをSubversionで管理するもよし。



106 :仕様書無しさん:05/03/03 22:11:45
>>99
> >>94
> よく似た話なんですが、俺の先輩も開発中にいきなり「何で動かねぇ〜んだ!」
> と叫び出し、自分のパソコンをぶっ壊した人がいます。

オブジェクト指向とデザインパターンを駆使し、
テスト駆動開発をしてみれば
そのような事態になることを軽減できるわけだが。

動かない理由はテストを怠らなければ殆どの場合即座に理解できる。

動かない理由が理解できるかどうかは、
使用言語やスキルにも依存する。
とくに型の概念が曖昧なスクリプト言語はやっかいだ。
大規模化するとバグを探すのは容易ではない。
なんで動かないんだという原因を探るには
とにかくテストコードを書いてみることだ。
このコードはこのような動作をするはずである、
かつ、このような動作はさせるべきではない、
というテストコードをassertで書くことだ。

スキルは、その言語の仕組み、
クラス、メソッドの挙動をよくしらずに
使っていた、staticの意味を知らずにいたために
とんでもないことになったという事態。


107 :仕様書無しさん:05/03/03 22:11:54

コーディング規約を守り
オブジェクト指向を上手に利用して開発すれば
動かない原因を探り当てるのが容易になり、
バグとりも追加修正も容易になる。

動かない原因をやっとみつけた。
動かない原因になっているコードを
下手に修正したことでかえって
逆にひどいことになり動かないヶ所が増え、
もっと最悪な事態に陥ることがある。

オブジェクト指向を理解し、デザインパターンを使いこなせば、
既存のソースコードを修正せずに、
追加するだけでやるべきことが達成しやすくなる。

オブジェクト指向を理解し使いこなせば
既存のコードを削除、修正せずに追加するだけで
コードを拡張、バグを取ることが非常に容易になる。
それを怠ったからなんで動かないのだ、という話になる。




108 :せる ◆9gLessA9bA :05/03/03 22:13:50
テストケース作成に入りました。

1日おくれになってしまいました。
土日は、家でテストデータづくりかなあ。。。

>>88
原理主義者について調べてみたら、その気が少しあると思いました。
うまくいかないと、やる気がすごくなくなります。

109 :仕様書無しさん:05/03/03 22:44:33
http://ex9.2ch.net/test/read.cgi/accuse/1109766760/l50

110 :仕様書無しさん:05/03/03 22:49:56
>>108
とりあえず深呼吸しろ。
モティベーションを高めろ。

自分のできること、やりたいことを紙にかいてみろ。
わからないことも書いてみろ。


てすとなら

テスト駆動開発入門が
お勧めだ。

http://www.amazon.co.jp/exec/obidos/ASIN/4894717115/249-4868660-7656331

初心者でも気軽に理解できる。



111 :仕様書無しさん:05/03/03 23:08:08

TDD信者、猛烈にウザい。バカの一つ覚えみたいに言うんじゃねーよ。チンコ野郎が。

オレ様もTDDでかなりラクさせてもらってるよ。文句あっか、コラ。

112 :仕様書無しさん:05/03/03 23:13:11
>>101
>>102
>>103
はいはい結構ですヨ。どうぞ叩き続けてくださいね。
なんども言うけど、
何が正しいかを決めるのは私や貴方ではないよ。
#議論にもならん。感情を匿名掲示板にぶつけて何がしたいんだか判らんな

113 :仕様書無しさん:05/03/03 23:22:47
>>112
> >>101
> >>102
> >>103
> はいはい結構ですヨ。どうぞ叩き続けてくださいね。
> なんども言うけど、
> 何が正しいかを決めるのは私や貴方ではないよ。
> #議論にもならん。感情を匿名掲示板にぶつけて何がしたいんだか判らんな
はいはい
結構ですヨ。どうぞ勝手に感情をぶつけたと思いこんでくださいねオジサンは。
なんどもいうけどこのスレは何が正しいかを決めるスレではないよ。
>>54はこれこそが正しいという妄想を抱いているみたいだけど。




114 :仕様書無しさん:05/03/03 23:23:36
>>111
> TDD信者、猛烈にウザい。バカの一つ覚えみたいに言うんじゃねーよ。チンコ野郎が。
TDK信者? TDKネタはスレ違いですよ
>
> オレ様もTDDでかなりラクさせてもらってるよ。文句あっか、コラ。

口先だけですかw

115 :仕様書無しさん:05/03/03 23:30:50
>>113
ありがとう。勝手に思いこませてもらうよw
「何が正しいかを決めるスレではない」と思うのは一致しているよ
職業PGとは思えない人間が、若い職業PGに適当なことを言って迷わすスレ
だとも思わないけどね。


116 :仕様書無しさん:05/03/03 23:48:45
職業プログラマの定義もわかってない坊主が暴れとるな。
奴にはケントベックの爪の垢でも飲ませてやりたいくらいだな。


117 :◆ItkaRMAJ7. :05/03/04 01:26:18
っていうか、>1はどこいった?

118 :仕様書無しさん:05/03/04 02:43:00
>>106-107
>オブジェクト指向とデザインパターンを駆使し、テスト駆動開発をしてみればそのような事態になることを軽減できるわけだが。
>コーディング規約を守りオブジェクト指向を上手に利用して開発すれば
>オブジェクト指向を理解し、デザインパターンを使いこなせば、
>オブジェクト指向を理解し使いこなせば
はいはい。「れば」ニラ炒めの食べすぎでお腹いっぱいですよw

オブジェクト指向を理解し駆使すれば幸せな結果が待っていると言いたいのは良くわかった。
デザインパターンを使いこなせばソースの修正は発生せず追加だけで仕事が終わるというのも、まぁそういう風に組めば可能だな。
XPやテスト駆動開発を銀の弾丸のように崇めるのもまぁいいだろう。リファクタリングやテストをする事は有効だしな

・・・で、そろそろどうやったらそうなれるのか具体的な方法を示してくれないか?

119 :仕様書無しさん:05/03/04 15:39:15
OOPにせよ、XPにせよ、TDDにせよ、
周囲の状況が許さないとかいろいろあるとおもうんだけどなぁ。

確かに「実践できれば」意味があるんだが。
最低でもチームのリーダーか、それに準ずる位置にはならないとやれないだろ?
リーダーが言葉を聞き入れてくれれば別かもしれんが、
聞いてもらうには、当然相応の信頼とかが必要なわけで。
で、そんな位置に居る人間が今更
「仕事が遅いのが悩みです」なんて言うのはあり得ないわけだ。w

一人で開発してるわけじゃないんだから、
リーダーに理解がなければ、テストもまともに書けないし、
そう言う状況を無視して「銀の弾丸」ででもあるかのように勧めるのは、
「信者乙」とされても当然だと思うんだが。

まとめるなら「もまいらもちつけ」

120 :54:05/03/04 22:27:46
>>119
わざわざどうも有難う。
全面的に同意しますよ。
興奮したり慌てたりしたつもりはないのだけれど。
そう見えたとしたら私の不徳のいたすところです。
失礼しました。

121 :仕様書無しさん:05/03/05 02:08:17
弾丸の前に銃が必要だと、何故みな気がつかないのだろうか。
銃は既に手にあり、弾もこめられていて、尚それが効かない
不死の化け物を相手に日々戦いを続ける鉄血の戦士が、
この世界にどれほどいるというのだろうか。

最近、漏れの手の中には、銃はおろか、バールの様なものすら
無いことに、やっとこさ気がつきましたよ。
そりゃ仕事も遅いわけさー。

122 :せる ◆9gLessA9bA :05/03/05 02:16:48
>>121
TDDの本をあしたかおうとおもいます。

123 :仕様書無しさん:05/03/05 08:49:31
徒手空拳にて参られよ。

124 :仕様書無しさん:05/03/06 06:37:11
>>122 その前に「達人プログラマ」「人月の神話」あたりから読んどけ。


125 :せる ◆9gLessA9bA :05/03/06 15:22:59
>>124
バグがないプログラムの作り方を買ってみました。
http://www.amazon.co.jp/exec/obidos/ASIN/479810714X/250-1758792-8129067

でも、XPって設計フェーズからはじめていかないとだめなんですかね・・・
開発段階からやっても、効率がいいものなんでしょうか

126 :仕様書無しさん:05/03/07 12:01:01
まずはXPについては忘れろ。
他に出来ることが山ほどあるだろ?

127 :仕様書無しさん:05/03/07 13:31:37
仕事が遅いってのは、目標云々よりも目標から実作業への
ブレークダウンがうまくできてないんだろ?目標達成のために
何をやったら良いかがわらかんから、仕事が進まないんだろう。
先輩とか同僚がどうやってるかを良く見るんだな。

XP厨は無視で良いと俺も思うぞ。XPなんてのは方法論の一つ
でしかないし、お前がそれやっても仕事が早くはならんよ。

128 :仕様書無しさん:05/03/07 22:28:31
XPは関係がない周りのやつにとってはうざったくてしょうがないな。


129 :仕様書無しさん:05/03/08 12:49:25
>>118
センスのわるいオヤジギャグだな
「銀の弾丸」という言葉が大好きなオッサンだなほんとに。

オブジェクト指向を使うのが当たり前なプロジェクトでの
実務経験が無い奴に限ってこう「銀の弾丸」を何度も連呼する。
そんなもんは存在しないってことはこいつ以外
誰でもわかってるいのに解ってないと思いこんで
厚かましく銀の弾丸銀の弾丸をなんどもオウム返しする。
ホント、厨みたいなオッサンだ。


130 :仕様書無しさん:05/03/08 12:53:45
>>119
> OOPにせよ、XPにせよ、TDDにせよ、
> 周囲の状況が許さないとかいろいろあるとおもうんだけどなぁ。
>
> 確かに「実践できれば」意味があるんだが。
> 最低でもチームのリーダーか、それに準ずる位置にはならないとやれないだろ?

やれるよ。
頭が堅いマネージャじゃなければやりやすもんだよ。
本人も新しいものをすべて理解してないってことは自覚してれば。
『無知の知』をしっかり理解したマネージャのもとであれば
新しい手法を導入しやすい。
「試しにやってみろ」、という形で新しい手法をやらせてくれるもんだ。

実際にそのやり方がうまくいくかどうか上司やマネージャにみせびらかせればいい。
それで実際にうまくいけばそれだけでもかなりの説得力がある。
そこから新しいものが導入しやすくなる。


131 :仕様書無しさん:05/03/08 12:58:54
>>121
> 弾丸の前に銃が必要だと、何故みな気がつかないのだろうか。
テスト駆動開発にもアジャイル開発にも、
弾丸も銃もいらない。
プロジェクトを成功させることができれれば
そんなものはいらない。

ついでにネガティブで『銀の弾丸』がなんたるかと
例え話にして新しいものを頭ごなしに否定してばかりいるだけで
肯定的な意見も一切言わない人間はこの業界にはいらない。

必要なのは、従来よりもいかに効率よく開発できる手法を実現できる能力だ。
新しいものを実際に試し、その過程を示してそれを人に勧める能力だ。
徹夜残業を減らせる方法を常に考えることだ。

132 :仕様書無しさん:05/03/08 13:01:03
>>125
> >>124
> バグがないプログラムの作り方を買ってみました。
> http://www.amazon.co.jp/exec/obidos/ASIN/479810714X/250-1758792-8129067
>
> でも、XPって設計フェーズからはじめていかないとだめなんですかね・・・
> 開発段階からやっても、効率がいいものなんでしょうか

そもそも余計なことを考えすぎだ。
設計を複雑に考えすぎ。
XPのプラクティスすべてを実践する必要はない。



133 :仕様書無しさん:05/03/08 13:03:48
>>127
XPは知っておいて損はない。
だかせるの今のやり方ではXPのアドバイスをうけようと
XP以外のアドバイスをうけようとも
とてもうまくいくかどうかはわかりにくいところだが。

単調で繰り返しの多い作業を効率化するツールを
使うことも開発効率を高めることに繋がる。
テンプレートエンジンや自動化ツールを上手に使ってな。

134 :仕様書無しさん:05/03/08 13:36:03
「どう考えるべきか」と「何をするべきか」が混じっているな

135 :仕様書無しさん:05/03/08 14:37:30
>>133
お前ってホントに低能な。XPの知識が要らんなんて誰も言ってない
わけだが。>>1の問題に関する限り、XPは何の役にも立たないと言って
いるわけだ。頭悪すぎ。お前って道具をまともに使えない技術者だな。

136 :仕様書無しさん:05/03/08 14:43:26
>>131
否定されているのはお前がバカだからでは?(笑)
ま、自分がマヌケなことを言っているという自覚くらい持てよな。

137 :仕様書無しさん:05/03/08 15:15:25
>>136
自覚が無いからああいう発言が出来るのでは?w

138 :仕様書無しさん:05/03/08 21:20:26
>>129-131は同一人物か?
>頭が堅いマネージャじゃ「なければ」やりやすもんだよ。
>本人も新しいものをすべて理解してないってことは自覚「してれば」。
>それで実際に「うまくいけば」それだけでもかなりの説得力がある。
>プロジェクトを成功させることが「できれれば」そんなものはいらない。
ほらな。また「れば」だw
お前のは全てXPが上手く適用「できれば」という前提に基づいた仮定の話なんだよ。
だから説得力が無いし、空虚な信者論調としかとられない。

確かにXPを正しく活用すればうまくいくだろう。
しかし、それはウォーターフォールを正しく活用してもうまくいくし、古典的な構造化手法で正しく設計する事でも可能だろう。
なぜならそれらは単なる手段に過ぎないからだ。
たとえ銃があって鉛の弾丸がこめられていても、銃を撃つための手順、どうやって狙いを定めるか。自分の爪先を吹っ飛ばさないで済む為に気をつけることはなにか。
そういう基本的な事を身に付けないとせっかくの武器をもてあます結果になる。

ここで>>1が議論したい事ってのはそういう基本的な事、「どうやれば仕事が速く出来るようになるか」という開発手法以前の仕事への取り組み方の話だろ?

XPの素晴らしさを伝えたいのなら、自分がどうやってXPを職場に浸透させたかを語ってくれ。
実際の開発現場で活用されている事例なら俺も興味がある。

139 :仕様書無しさん:05/03/08 21:32:58
XPの話は>>1とは何の関係もないんだから別スレッドでやってくれ。

140 :仕様書無しさん:05/03/08 21:52:27
なんだかんだいってXPの哲学が役に立つ場面は多く
>>1にとってもプラスだと思いますな。

会社でいやなことでもあったか頭が固いのか
XPが嫌いな人はXPの話をしたくないので
どうしてもけなさないと気が済まない傾向がある様子ですな。


141 :仕様書無しさん:05/03/08 22:11:01
XPによって仕事が速くなる可能性もある。
その認識を持つことも良いことです。
かといって知らないほうが仕事が速くなる
とも限りません。

142 :仕様書無しさん:05/03/08 22:35:42
低能XP厨がまた来たよ。

143 :仕様書無しさん:05/03/08 23:38:40
>>135
> >>133
> お前ってホントに低能な。XPの知識が要らんなんて誰も言ってない
> わけだが。
おまえさんのほうが低脳じゃないか?
XPなんか要らないっていってる奴が約一名いるぜw

>>1の問題に関する限り、XPは何の役にも立たないと言って
> いるわけだ。頭悪すぎ。お前って道具をまともに使えない技術者だな。
何の役にも立たないなんて断言するお前も頭悪すぎ。
お前って読解力がまともにない技術者だなw

144 :仕様書無しさん:05/03/08 23:39:06
低脳アンチXP厨も同類だからいいや

145 :仕様書無しさん:05/03/08 23:40:25
XPが地球を救う!!


146 :仕様書無しさん:05/03/09 00:08:16
さて、XPと聞いて「M$のWindowsXP」ってのしか浮かばない漏れに

何の事か、どの様な手法か、導入するにはどうしたら良いか、使う事によって得られる利益は何か を分かり易く教えてくれないか?

147 :仕様書無しさん:05/03/09 00:08:47
>>140
確かにプラスだな。
アンチXP信奉するよりもな


148 :仕様書無しさん:05/03/09 00:09:16
テスト駆動開発がXPの一種だと思ってるヴァカがいるだろ
このスレ


149 :仕様書無しさん:05/03/09 00:10:53
>>136
間抜けなこといってるのはおまいじゃないか。
>>131の意見がマヌケだとおもうなら
お前なりにその根拠を述べてみな

150 :仕様書無しさん:05/03/09 00:11:38
>>139
若干関係会ったりしてな。
むしろアンチXPの話は>>1とは何の関係もないんだから別スレッドでやってくれ。
といったほうが説得力があるw

151 :仕様書無しさん:05/03/09 00:17:46
>>146
俺漏れも

152 :仕様書無しさん:05/03/09 00:31:08
>>138

> ほらな。また「れば」だw
こういう奴の話し方って60年代生まれの奴に多いな。
鬼の首を取ったかのように喜んで楽しそうだな。
それくらいしか楽しみがないみたいだから
よほど心が貧しいんだろうな。


> お前のは全てXPが上手く適用「できれば」という前提に基づいた仮定の話なんだよ。

どこに「全て」とでも書いてあるのかね。
読解力も無い奴よ。脳みそが溶けちまったか?
仮定の話だとよくいえたもんだな。

お前はなんでもかんでも「れば」といったらすべて単なる仮定の話だと
思いこむほど知能が低いのか。
言葉の断片だけを掴んですべてを悟ったと勘違いする奴の典型だな。
お前は実体験に基づいた話でもすべてお前は脳内変換にとって勝手に仮定とみなすほど
頭が悪いみたいだな。
もうちょっと日本語を勉強してこい。

お前は良きマネージャに恵まれてないようだから
職場でXPを適用することもできないんだろうな。ご愁傷様。
実際にXPを試してみてそれをマネージャに見せることで
マネージャを説得することができるんだよ。
マネージャがよほど馬鹿じゃない限りは
新しいものを見もせずに使いもせずに否定することはまず無い。
お前んところのマネージャは馬鹿だから仕方が無いんだろうな。


153 :仕様書無しさん:05/03/09 00:31:35

> だから説得力が無いし、空虚な信者論調としかとられない。

お前の否定論も説得力が無いし、空虚な信者論調としかとられない。
いやむしろただの腹いせとしたとられないのが関の山。


> 確かにXPを正しく活用すればうまくいくだろう。
> しかし、それはウォーターフォールを正しく活用してもうまくいくし、古典的な構造化手法で正しく設計する事でも可能だろう。

ウォーターフォール信者か。ウォーターフォールを正しく活用して
うまくいった事例を挙げてみるんだな。
「古典的な構造化手法で正しく設計する事でも可能だろう。 」
何が可能なんだ? 日本語をちゃんと使えよ(笑)

お前は何を言っても、詭弁にしては下手くそな論調だな。
だれもが解ってることをいかにも解ってないかのように言って
アンチXP信者としての自分の威厳を必死に保とうとしている。
まさに「変化ヲ擁護」できない奴の典型だな。

お前っていう奴は、PCが徐々に職場に浸透したとき
使い方がわからず「パソコンなんてない方がいい。コストの無駄だ」
と言っていた連中と変わらないレベルなんたよ。


154 :仕様書無しさん:05/03/09 00:44:19

> なぜならそれらは単なる手段に過ぎないからだ。
> たとえ銃があって鉛の弾丸がこめられていても、銃を撃つための手順、どうやって狙いを定めるか。自分の爪先を吹っ飛ばさないで済む為に気をつけることはなにか。

だれもが解っていることをそうやって何度もしつこく言ってるからお前は無知だって言われるんだよ。
XPの哲学はほとんどが極一般的なことでシンプルだ。Unified Processと比べれば非常に簡単なことで
即座に実践できる者が多く、すべてを実践する必要がない。
例えばリファクタリング、テストファーストは
とりあえずやってみてもそれで支障を来すことはほとんどない。
リファクタリングのためだけに銃の撃ち方をいちいち学ぶ必要があるか?
もしあるとしたらそれはXPを適用する以前の問題だ。XP以前にプログラミングの基礎を理解していないだけだろう。


155 :仕様書無しさん:05/03/09 00:44:49

はっきりいおう。
プログラミングができる時点では銃の使い方はすでに覚えている。
その上でXPは銀の弾丸でも鉛の弾丸でもない。
XPは「習慣」だ。

XPはだれでもできる。なのに「できない」奴が多いのはなぜか?
面倒くさがってできないと思いこんでいる馬鹿が多いだけだ。

XPを実行するために必要なツールなんて要らない。
金もかからない。既存の環境で実践できるものだ。ただの生活習慣を変えるだけに過ぎない。

XPができないと叫んでいる奴は
乗ったこともない癖に怖くて自転車に乗りたがらない子供と同じだ。
それでいつまでも補助付き自転車に乗っている馬鹿だ。


156 :仕様書無しさん:05/03/09 00:46:00
そりゃ2chの合い間に仕事やってるようじゃ遅いに決まってるだろうがよ。

157 :仕様書無しさん:05/03/09 00:46:13

ジョギングに喩えることもできる。XPができない奴は
運動もろくにせず痩せたいと叫んでいる奴と同じだ。
XPができないと言ってる奴は痩せたかったら毎朝早く
起きてジョギングなりフィットネスクラブに通うなり
食事量を制限すればいいのに痩せないと叫んでいる情けない馬鹿どもと同じだ。
一度運動すれば疲労もたまりにくくなるしスタイルも良くなる。
運動すればそれだけ魅力的になれるし健康維持にもつながり
頭も冴えて仕事の能率があがる。
それを忙しいからできない、なんてブーブー文句ばかり垂れているデブ。
それで仕事の能率が上がらず中肉中背でデブ呼ばわりされて女にもモテず
愚痴ばかり零している。

それがXP否定論者の態度だ。

XPの考え方は幼稚園のときにすでに教わったことにそっくりだ。
幼稚園の時に教わった基本的な琴ができない奴は世の中に腐るほどいる。
XPができない奴ってのは幼稚園で教わったことを理解できていない奴と同じだ。
今日できることは今日のうちにやる。朝は速く起きる。そういう基本的なことができない奴が
XPを否定する。このことは>>1の生活習慣にも当てはまる。できるのにできないと思いこんでいる
からいつまでたってもできないのだ。ようするにやる気のない引き篭もりやNEETと同類だ。


158 :仕様書無しさん:05/03/09 00:50:19
>朝は速く起きる。
なぜか「布団がふっ飛んだ」が頭をよぎりコーヒー噴いた。謝罪と賠償を・・・

159 :仕様書無しさん:05/03/09 01:00:00
>>146 >>151
http://www.google.co.jp/search?q=eXtreme+Programming&start=0&start=0&hl=ja&lr=lang_ja&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:ja-JP:official

160 :仕様書無しさん:05/03/09 01:00:31
>>158
おまえは中国人か

161 :仕様書無しさん:05/03/09 01:13:25
XP否定論者のつもりはない人間だが。
XPを一つでも沢山のプロジェクトに適用したいのなら、相手を攻撃するより説得するべきだろう。
真面目なXP支持者ならいかにしてXPを導入可能かを真剣に考え、模索し、議論している。
XPに限らず、いままでの新たな方法論は「他者の考え方や行動を変える」という必然性に直面する。
そして今まで生き残っている方法論が使った手法は「論理的な説得」だ。
感情的なパッシングでは議論にもならないし、XPそのものをあまり知らない人を
XP否定論者に変えてしまうこともありうる。
例えば>>157を読んだ人からは「XP以前には基本的なことは無かったのか?」
という当然の反論も起こる。

個人的な感想だが「XP否定論者を叩くものは、本当はXP否定論者なのかも知れない」
との邪推も

162 :仕様書無しさん:05/03/09 01:16:38
>>160
何を言ってるんだ?

韓国人だろうが。


163 :仕様書無しさん:05/03/09 01:26:19
>>159
>XPは開発初期段階の設計よりも、コーディングとテストを重視する。

この部分が支持できるね。
設計部分は詳細設計までをきちんと行い、
プログラム設計よりもコーディングを優先した方が良いと考えているからなぁ。

小さなシステム開発であれば、こういうタイプの方が利に適ってると思うわ。


164 :仕様書無しさん:05/03/09 01:30:24
>>161
攻撃するのは2chだから。
ここでの例は否定論者に攻撃されたから反撃するという口実?


165 :仕様書無しさん:05/03/09 01:58:38
XPって、WindowsXPのことでつか?

166 :仕様書無しさん:05/03/09 03:59:06
偽装派遣された孫受けの底辺PGがXP導入を提案して許可されるためには何をすればよいでつか?

167 :仕様書無しさん:05/03/09 04:31:06
>>162

中国の属国だから没問題

168 :仕様書無しさん:05/03/09 07:16:29
>>165
>>159

169 :仕様書無しさん:05/03/09 11:33:46
XP信者が、問題点の把握と適切な対処のできない低能であることが
良く分かるスレッドですね。>>1の問題とXPには全く何の関係もなし。
>>1の問題はXP以前の問題。低能XP信者君(職場での嫌われ者)には、
その程度のことも理解できないようだが(笑)

170 :仕様書無しさん:05/03/09 11:47:04
アンチXPな奴などどこにもいない。アンチ「XP厨」ならいっぱいいる。
XP厨は例外なく馬鹿だから、その程度のことが理解できない。

171 :せる ◆9gLessA9bA :05/03/09 14:52:41
エクセルの画面を見ていると何も考えられなくなってしまいます。
もうだめかも・・・

172 :仕様書無しさん:05/03/09 17:56:32
セルの数を数えてみよう

173 :せる ◆9gLessA9bA :05/03/09 18:59:48
週末、病院いってみます。
睡眠薬とかもらえるのかな

174 :仕様書無しさん:05/03/09 22:02:03
Excelで文書を作ってる馬鹿は氏ね。

175 :仕様書無しさん:05/03/09 23:24:54
何で作ればいいんですか先生

176 :仕様書無しさん:05/03/09 23:26:07
Word

177 :仕様書無しさん:05/03/09 23:26:30
おれ、仕事超速い。
ものすご適当だけどなー。
でも仕事はたくさんくるでー

178 :仕様書無しさん:05/03/09 23:27:24
適当だけど何が大事で何が手抜きで良いかを
良く理解しているからだろうな。

179 :仕様書無しさん:05/03/10 00:33:40
>>169
お前の方が低脳だ。
自作自演して
2chごときで「問題点の把握と適切な対処」
だなんだと偉そうに言っていることがアホ臭い。
このスレでXPが出たのはただの提案だろう。
関係なさそうに見えるからと言ってXPの話題を
阻止させようとしているお前の方が低脳だ。
お前のレスはどう見ても子供っぽくておかしい。
自分の意見を正当化しようとして現実から逃げようとしているだけだ。
お前こそ問題点の把握と適切な対処をしてみたらどうだ?
オマエサンは。、脳内で嫌われ者扱いしてXPの普及を必死に妨害しようとしている
という腹黒い態度が見え見えだ。
そんな集団オルグてきな卑怯な戦術は今どき通じないことをよく覚えておくんだな。


そもそもこの世にXP信者という者もXP信者という用語も存在しない。
すべてお前の脳内で完結しているものだ。


180 :仕様書無しさん:05/03/10 00:34:40
>>170
むしろ
XPな奴やXP信者などどこにもいない。「アンチXP」厨ならいっぱいいる。
「アンチXP」厨は例外なく馬鹿だから、その程度のことが理解できない。

が現実解だな。


181 :仕様書無しさん:05/03/10 00:41:58
>>171
じっと見ていただけでは何も考えられないぞ。
とにかくいろんな本を読んでスキルアップしてみろ。
2chでXPを否定している馬鹿共の意見に耳を傾けるな。
「デマには惑わされるな」とよく言うだろう。
デマに惑わされると
何か災害が起きたとき、お前は真っ先に人が多いほうに集まって
集団で巻き添えを食らって人混みの中で死んでしまうだろう。
太平洋戦争で東京大空襲で焼夷弾で隅田川の橋の上で
死んでしまった人々のように。
彼らは橋の上に集まれば安全だと思いこんで焼け死んでしまった。

彼らは愚かにも、人が沢山いる方に逃げれば安全だと
思いこんで橋に向かって死んでしまった。
橋は非常に目立つ存在であり敵にとっては恰好の餌食だと言うことを
愚かにも彼らは理解できなかった。

空襲が収まった跡に残ったのは黒焦げた死体だ。川も浮いた死体の山となった。

「せる」もそんな愚かな人間になって死ぬことがないようにすることだ。



182 :仕様書無しさん:05/03/10 10:31:17
何だかよく分からないけど、>138に賛成しますね。(´・ω・`)

XP否定しないけど、開発漏れ一人だからさ・・・
漏れがする/しないじゃなくて、会社の偉いさん次第なのよね。
現場以外の人間に対して如何に説得力を持たせるかが大事なんじゃないの?
要は精神論や中身の話じゃなくて、導入事例が手っ取り早い。

流れを読んでいない気が満々なのでスマソ。帰る。

183 :仕様書無しさん:05/03/10 11:07:01
「デマには惑わされるな」というのはとても正しいな
まあ「なにがデマなのか」を判断するのは、「せる」さんたちが自分でしなければならないのだけど

184 :仕様書無しさん:05/03/10 11:19:38
>>1 へのレスを装って本当の目的は個人攻撃

185 :仕様書無しさん:05/03/10 11:30:53
>>179 >>181
だから誰も「XPを否定」なんてしてないっての・・・
ここで叩かれてるのは「XPがあれば問題を解決できる」という主張であり、
そういう主張をしている香具師を「XP信者」や「XP厨」と読んでバカにしているだけの話。
なんで厨信者をバカにするかというと、
奴らは「自分の話し方や批判のしかたを否定されているだけなのに、XPを否定されていると思い込んでいる」から。
つまり、「文章読解力に低いバカな奴だ」と認識されている。しかもそれに気づかない。
そういう奴がいると話題が進まないから「XPの話はやめようぜ」ってことになっているだけのことだ。

いくらなんでも、ここまで丁寧に説明してあげれば解るだろ?(´・ω・`)

186 :仕様書無しさん:05/03/10 11:34:25
179=181はバカ。

>>185
たぶんバカだから理解できないと思います。

>>180
どこが現実解なんだよ(笑)。ほんとに低能だな。

187 :54:05/03/10 11:46:59
>>185
なんて親切な。すばらしい

188 :>>185を一言で表現:05/03/10 11:55:32
うはwwwwwwXP厨wwキモスwwwwwwwwwwwうぇうぇwww


189 :仕様書無しさん:05/03/10 12:01:15
179=180=181は会社じゃ嫌われ者なんだろうな。他人の言っていることを
理解できない無能だからだね。まともに話のできない奴と思われて無視されて
いるんだろう。

190 :仕様書無しさん:05/03/14 11:59:17
保守age

191 :仕様書無しさん:05/03/18 01:48:44
XPの話やSEの話は出ていたようですが、Meや初代98や95や2000は蚊帳の外ですかそうですか。

192 :仕様書無しさん:05/03/19 19:59:27
俺、仕事早いときと遅いときの差が激しい。
・早いとき
お互い自由にコーディングさせてくれる同僚だと、
「ここ、ひとまずこれでいーよね。あとでリファクタリングするし」
つって、ガンガン書きまくって後でガンガンリファクタリング。
人の書いたクソコードもガンガンリファクタリング。
同僚がTDDじゃなくても俺だけTDDで突っ走る。

・遅いとき
「最初に共通認識を固めておこう。問題点はエクセルの表に書いて共有しよう。
 書いたコードの書いた人が修正する責任があるからバグを見つけても修正依頼の連絡に留めよう」
とか言う同僚だともう、モチベーションから何から下がりまくって、フルスピードの1/4ぐらいまで効率が落ちる。
結局、無駄な書類作成や情報共有する作業が苦手なんよね。
CVSのCommitログ&Diffで適宜自分で判断しろっつーの。
つーかCommitログ書けよ!そうすりゃDiffの手間もいらねーんだよ。

193 :仕様書無しさん:05/03/21 00:27:57
>>192
>最初に共通認識を固めておこう。

ここは問題まったくないし

>問題点はエクセルの表に書いて共有しよう。

これもまあ、それはそれでいいじゃねーか。
全体の効率考えるなら。

個人の裁量の大きさや、CVSの諸機能からそれを行使する範囲を見定めるのは
完全に別の話だろ。
言ってることが子供の我が侭みたいだぞ。

75 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)