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

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

【IT】PMな人達のスレ【管理者】

1 :仕様書無しさん:04/12/12 19:27:21
日頃、お客様/PGな人達の板ばさみで死にそうになってる人。
何故かコーディングまでやっちゃってる人。

日頃の不満を吐き出してください。

2 :仕様書無しさん:04/12/12 19:34:05
PrivateMessenger??

3 :仕様書無しさん:04/12/12 19:34:14
AMは?

4 :仕様書無しさん:04/12/12 19:38:06
>>3
朝弱いんで不許可

5 :仕様書無しさん:04/12/12 19:40:22
>>3
日本語も弱いな

却下(きゃっか)


6 :仕様書無しさん:04/12/12 19:41:36
×>>3
>>4




7 :仕様書無しさん:04/12/12 20:02:30
最近のPGは忍耐力がない。
不平不満だけは一人前で、仕事は半人前以下。
派遣や外注の人なら即刻で切るようにしてる。
問題は社員の場合・・・なかなか切れないんだよね。
他のプロジェクトに押し付けるようにしてるけど、
本当に・・・な奴は噂が広まってて押し付けもできない。

そんな時どうしてます?

8 :仕様書無しさん:04/12/12 20:05:03
自分で何もかも先にやっちゃう

9 :仕様書無しさん:04/12/13 00:20:57
自社の社員なら本当に・・・な奴でも育てろよ。
たとえ「うわぁこいつリアル馬鹿だ!」「しかも何この態度?」「でも彼女が可愛いorz」
な奴だったとしてもだ。

10 :仕様書無しさん:04/12/13 00:56:41
>>9
なんで?
君がもしかしてそれに該当するの?

馬鹿と話をするのは時間の無駄だから嫌だなぁ〜

11 :仕様書無しさん:04/12/13 01:42:43
>>10
相手がバカなのか自分がバカなのか。

難しい問題だな。

12 :仕様書無しさん:04/12/18 00:52:10
育てるか切るか悩みどころ。

13 :仕様書無しさん:04/12/18 03:15:49
>>7とか>>10とかがPMやってる会社って悲惨。w

14 :仕様書無しさん:04/12/18 09:10:41
>>12
どんどん切ればいい。最期には自分も切られて終ってしまうがな。

15 :仕様書無しさん:04/12/18 13:01:36
こんなスレがあるとは気づかなかったな。

自分も、昔は13と同じように思ってた。
だけど、自分がPMになってみると実は7の気持ちが
分かったりする。
自分がやれば3日で終わるのに・・とおもう仕事でも、
部下が「6日かかります」、といえば、自分が開発業務に入れない以上、
6日で見積を出さざるを得ない。
時間が倍かかるいうことは、500万で可能だと自分では思える仕事でも、
お客さんに1,000万要求しなければならないわけで、
自分の中で葛藤してしまいますね。


16 :仕様書無しさん:04/12/18 13:27:11
>>15
PMになって思ったこと。

1/4ぐらいのできる人が、人の2倍ぐらい仕事して。
1/2ぐらいの人が普通に仕事して。
1/4ぐらいの人が足を引っ張ってる。

最後に該当する人は、教育しようが改善される見込みは
一切ないと思われる。 こういうの押し付けられた時
最悪なんだよなぁ〜〜

17 :15:04/12/18 13:37:53
>16

これがまた、新人〜3年目くらいまでなら、仕方ないかとも思うんだけど、
君、もう7年以上やってるんでしょ、と思う子なのでやっかいです。
そこそこ経験があるので、あまりにも初心的な忠告は聞こうとしない。
頭が固いので、新しい技術は取り入れようとしない。
共通化すればあとあと効率がよくなるのに、
それを考えてる時間が無駄だからと似たようなプログラムや
試験を山ほどやってる。

自分がもっと設計&開発に踏み込むべきだったと反省半分。
じゃ、本当にそのとき、そこまで踏み込む時間があったのかと
自問自答半分。


18 :仕様書無しさん:04/12/18 13:43:28
>>15
自分でやれば3日でできるソフトウェアの見積もりを3日とするのはアフォ。
3日でできるとような仕事を6日として見積もる部下のほうが偉い。内心部下だって
3日でできると思っているに違いない。w

3日でできるものを2日でこなすのは大変だし、何らかの事故や都合で3日
であげられないことだってあり得る。そういう場合納期遅延が生じて×。
だから6日というのは営業的には正しい。納期というのは正味計算でなく、
様々なリスクを勘案した上で顧客に告げられなくてはならない。

もちろん、「そんなにかかるんですか?」と疑問を投げてくる顧客もいるに
違いない。あとはネゴシエーションの世界。50%offまで可能な見積もりなの
だから余裕。3日納期なら、ネゴも不能。つーことで、15のようなPMがいる
会社では部下が悲惨な目にあるのは必定。w

19 :仕様書無しさん:04/12/18 13:52:49
>18
違うがな。
余裕をもって3日だよ。


20 :仕様書無しさん:04/12/18 13:58:42
いまどき>>18みたいな香ばしい奴がいるんだな。(w
マ板の質が低下してるのがよくわかるよ。

21 :仕様書無しさん:04/12/18 14:30:06
>>19
製造だけで済むと思ってるの?
たまに、PMのくせに、テスト時間を無視したスケジュールを組む奴がいるんで困るんだよな

そりゃ、組むだけなら短期でいけるだろうさw


22 :仕様書無しさん:04/12/18 14:33:48
>21
いちいち重箱の隅つつくなよ。
テストはテストで別。
工数も作業内容も例えで言ってるだけだって。

23 :仕様書無しさん:04/12/18 15:25:14
>>18
今時、2倍にした見積もりが通ると思っているバブル期入社の
30過ぎの使えない君ですね?

まぁ、こうい人は6日としてあげても、結局はなんやかんやの
理由をつけて倍の12日になる。まぁ、12日で終わるほうが
マシだけどね。

24 :仕様書無しさん:04/12/18 15:28:15
>>23
誤 まぁ、12日で終わるほうがマシだけどね。
正 まぁ、12日で終わればマシなほうだけどね。


25 :仕様書無しさん:04/12/18 15:54:24
>>7
うちの会社には、姥捨て山がありますよ。
品質管理とか新人教育とか。
頭のイタイ人を切って、変な噂を流されるよりかマシかなといった感じで。


26 :仕様書無しさん:04/12/18 15:59:12
>>23-24
そうですな。
時間はかかってもいいから、最低限、成果はあげていただきたい所ですな。


27 :仕様書無しさん:04/12/18 16:57:03
>25

問題児に新人教育させるのか?
嫌な会社ですね

28 :仕様書無しさん:04/12/18 17:12:37
>>25
うちの場合は、設計で箸にも棒にもかからなかった奴の末路は
教育、品質保証、営業かな。

でも、その温情措置が自分達の首を〆ることに・・・
特に勘違いしちゃった営業さんがとってきた仕事が回ってきた
日にゃ・・・

29 :仕様書無しさん:04/12/18 19:23:43
>28
うちの会社は弱小なんで、間接費にお金をかけられない。
従って、教育や品質保証は必要だと誰しもがわかっているけど、
現場で全て対処しているのが現状。

社員も能力によって単価が分かれてればいいのにな。

30 :仕様書無しさん:04/12/18 21:41:41
>>28は、適材適所という言葉も知らないと見える。
設計でアウトでも他なら行ける可能性は充分にあると思うのだがな。


31 :仕様書無しさん:04/12/18 21:48:17
>>27
使えない奴でも理窟だけは意外に解ってたりするもんだ。というか、連中、暇なせいか、知識だけはあんだよな。

実行に移せないから、所詮はクズなんだが。

使える奴は知識はそこそこでも、実行にちゃんと移してるから、まだ良い。


32 :仕様書無しさん:04/12/18 21:51:36
>>31
クズって?w

33 :仕様書無しさん:04/12/18 23:12:51
>>16
PMになって思ったこと。

1/10ぐらいの超できる人が、人の10倍ぐらい仕事して。
1/5ぐらいの出来る人が、人の2倍ぐらい仕事して。
1/2ぐらいの人が足を引っ張ってる。
本格的に改善の余地が無いのは1/10くらいかなぁ。
ちゃんと話聞いてあげれば本格的な馬鹿なんてそうそう居ないからねぇ。
問題はそこまでそいつにコスト割けるかだけの話で。

34 :25:04/12/18 23:21:00
>>27
あれですよ、反面教師ってやつですよ。
やばいとは思うんですが、言語とかはテキストさえあれば最低限教えられますから。
社会人研修は、その手のコンサルで、仕事の進め方はOJTで教えますから、そんなに
問題ないと思ってます。
最近の新人さんは、優秀な方が多いですし、大丈夫じゃないかなあ。

35 :仕様書無しさん:04/12/18 23:24:07
>33
いいこといった!
本当の馬鹿は確かにそうそういない。

けど、PMの立場だとコストが重要になってくるんで、
自分を犠牲にして、部下の分をカバーするか、
そんなお金は絶対貰えないと知りつつ、口八丁でなんとか
顧客にお金を出してもらうかのどちらかになりますな。


36 :33:04/12/18 23:40:11
>>35
そう。だから如何に「普通の人計算」で見積もり通せるかが勝負だね。
起こり得るリスクを徹底的に洗い出して徹底的に説明するのが王道かなぁ。
んでもってやっぱり育ててかないと目の前のプロジェクトすら楽にならんよね。

37 :仕様書無しさん:04/12/19 01:36:54
>>36
でも育ってくれるのも、また全体の一分でしか無いんだよネ。
結局、ガチガチに監理してどなりまくるしかないかとあきらめてる。

まぁ、どなるのは当人の前だけと決めてるけどね。

手を出さずに大勢の前ではどならずに、当人にしか聞こえない状況ではどなってでもやらせることにしている。


38 :仕様書無しさん:04/12/19 01:37:53
所詮は手駒。もっとも手駒以下の方が多いのが悩み

39 :仕様書無しさん:04/12/19 01:47:44
>37
自分が甘いのかもしれないが、怒鳴ってしまうと結局
「やればいいんでしょ、やれば」
みたいになって、自分の頭で考えて作業をやらなくなる。
納得いかないけど、言われたとおりにしました、みたいな。
だから、結局相手の機嫌をうかがいながら仕事を頼んでいるみたいで
自分でもこんなんじゃだめだなぁ、と思う今日この頃。

40 :仕様書無しさん:04/12/19 01:51:25
・・・みなさん大変ですね。仕事は楽しいですか?

41 :仕様書無しさん:04/12/19 01:55:52
>>39
どなられる方も、どこが悪いのかは認識はしてるみたいなんですよね。ただ、認識はしてても、解決はできないようで(苦笑)

大勢の前では何も言わないのは、せめてもの温情だと思ってますヨ。

個人的には考えるのは自分、動くのは相手の方と、割り切って考えるようにしてますね。考えるのも相手の方だと、なお良いんですが、それだと放任にしかならんので。


42 :仕様書無しさん:04/12/19 02:00:25
「監理」と打ち込んじまってる自分が哀しいな(^^;

ま、やってることは、「管理」よりも「監理」に近いのは確かだが。

新人の頃に放任されて、納品後にバグを出すなんて失態をやらかしたんで、今でも部下をあまり信じないことにはしてる。


43 :仕様書無しさん:04/12/19 02:33:43
腹を立てるのは自分が未熟な証拠だよ。
いつから君らは、そんな僅かな時間で欠陥人間を見分ける力を持ったんだ?

誰だってプロジェクト以外にも色々な人生を生きているんだよ。
集中力を欠いている人が居れば、集中力を欠くだけの理由があるもんさ。
それは君の態度かもしれないし、君には決して知り得ない幸せの為かもしれない。

「人」見てますか?

44 :仕様書無しさん:04/12/19 03:21:56
>>43
ま、そなんだが、所詮2ちゃねるに集いしPMだからね。人物は居らんよ。w

45 :仕様書無しさん:04/12/19 04:11:13
管理「される」側の人間なんだけど
こういう管理「する」立場の人間で
思い上がった発言をする人の多いこと多いこと

仕事という視点で見たら自分だって歯車のひとつであることを
忘れてませんか?自分ひとりで仕事が形になるとでも?

自分の立場が上であることを徹底するために
自分の誤りを認めない、逆切れする、等の品性下劣な性質が
沁み込んでしまった人たちが集まる場所はここですか?

自分が賢くて人の上に立つに値する人間であるかの
ように錯覚している人たちが集まる場所はここですか?
ただそういう役回りが回ってきただけのことですよ
人を都合のいいように操ろうなんて賢いのではなく
品性が下劣なだけなのです

下にいる人間だってね、上の人間の「人間性」を見てますよ

46 :仕様書無しさん:04/12/19 07:59:18
>>45
お前はもう少し仕事覚えろ

47 :sage:04/12/19 09:22:34
>>45
ま、そのうち管理する側になったら分かるって。
会社で働いている以上、誰だって歯車の1つだし、
管理する側になるとはじめて、管理される側がどんなに
楽だったか思い知るもんだ。
人を使うって難しいことだし、できれば自分1人でできる
仕事があればいいのにって、世の中のPMは1度や2度は
そう思ってると思うよ。

48 :仕様書無しさん:04/12/19 09:23:52
間違った。あげちった

49 :仕様書無しさん:04/12/19 10:38:58
>>45
人間性に問題あっても、成果物に問題がないのなら、何も問題は無し。

職場の人間関係を友だち関係か何かとまちがえてねーか?

50 :仕様書無しさん:04/12/19 11:35:53
会社とは人生そのものなのだ。
まさか「会社の良否が社員定着率とは無関係」とは言わんよな?

51 :仕様書無しさん:04/12/19 11:46:54
>>50
会社が人世とか言ってる寄生虫には辞めて欲しいと思う、今日このごろ。

ま、ワシ自身、寄生虫だけどさw


52 :仕様書無しさん:04/12/19 12:25:06
PMなら年収1000万オーバーだよな!

53 :仕様書無しさん:04/12/19 17:03:19
>>52
そだよ。

54 :仕様書無しさん:04/12/19 18:03:05
>>49
人間性に問題があったら仕事がうまくいくわけないしね
こういう人間性を否定する香具師に限って
成果をごまかす、責任をなすりつける等の傾向があるような・・

俺の経験ではね、仕事なんざ結局は人柄ですよ
人柄が良いからしっかりやろうとするし
人柄が良いから人が付いてくる
口が悪くてもなぜか慕われる人っているでしょ

55 :仕様書無しさん:04/12/19 18:03:41
それだけもらえるなら愚痴はいわない。

56 :仕様書無しさん:04/12/19 18:17:35
人間性は大切だと思う。
あとは、やっぱり相性とかもあるよね。
自分は、どちらかというと好きにやっていいからちゃんとモノを
あげてねっていうタイプなんだけど、中にはいちいち細かいことまで
決めてくれないと自分じゃ決められませんっていう人もいる。
自分はこういうタイプだと、ちょっと面倒だなぁと思うけど、
全部をPM自身がが決めるつもりでいる人だったら、こういう人のほうが
ありがたいんじゃないかな。
放任主義だよそんなのって言われればそれまでだけど、
要所要所で話し合うようにはしてるつもりなんだけどね。


57 :仕様書無しさん:04/12/19 21:08:23
>>54
こういう意見を言う香具師に限って、自分自身はちゃんと
コミュニケーションがとれない三流技術者だったりする。

悪いのは自分じゃない〜 PMが悪いんだ〜

58 :仕様書無しさん:04/12/19 23:38:08
>>57

  ∧_∧  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 ( ‘∀‘)<  オマエモ三流モナー
 (    )  \____________
 | | |
 (__)_)



59 :仕様書無しさん:04/12/20 23:22:00
集まる人の質でプロジェクト失敗させてるようじゃまだまだ。

60 :仕様書無しさん:04/12/21 00:07:53
>>57
>悪いのは自分じゃない〜 PMが悪いんだ〜
尊敬するPMにそんなこと言わないし。むしろ自分の未熟さを
恥じて一生懸命頑張る。
ひょっとして日頃そういうこと言われてるんですか?

61 :仕様書無しさん:04/12/21 08:02:59
お前ら、まだITの仕事してんのか?
アホばっかりだな。

62 :仕様書無しさん:04/12/21 10:27:08
なんだか、日々のPMの苦労そのままな感じのスレですね(苦笑

63 :仕様書無しさん:04/12/21 13:31:46
勉強になるなあ

64 :仕様書無しさん:04/12/21 19:21:50
プログラムが好きなPMと
プログラムのできないPGが同じプロジェクトになりました。

一ヵ月経過したらPMがPGを作り
PGがPMをしてた。でもプロジェクトは大成功!

俺にプログラマは向いてないな

65 :仕様書無しさん:04/12/21 22:10:16
PMという役割を与えられただけの人と
周りに認められて気が付けばPMになっていた人と・・・

現実はきびしいね?

66 :仕様書無しさん:04/12/21 22:26:12
プログラムが好きで嫌々PM → わりと上手くいく
理由:自惚れがない。変な計算をしない。
PMがやりたくてなったやつ→ 空気最悪
理由:単なる目立ちたがり屋。口だけ君が多い。

67 :仕様書無しさん:04/12/21 22:28:22
どうしても、PGとSEの階級闘争になるな。

68 :仕様書無しさん:04/12/21 23:16:42
>>66
PMがやりたくてなったやつ → おだてりゃラクショー
おだてて、要求ガンガン投げればOKですよ。
まあ、いいPMはおだてなくても働きやすい環境を提供してくれるがな。

69 :仕様書無しさん:04/12/22 00:32:05
俺、今27歳。入社5年目。
入社以来ずっと品質管理部にいて、3日前になぜかいきなりPMになった。
もともと継続案件で俺もテスターとしてお客さんと打ち合わせしていたし
システム要件、仕様も把握している。メンバーは俺も含めて最大で4人。
他の3人は新人1人と2年目1人と4年目が1人。

さっそくプロジェクトの発足祝いの飲み会の申請を
上司に申請したら却下された・・・・PMってつらいね。
板ばさみ。俺のお金で飲みにいったよ。

「プロジェクトが上手く行って利益良かったら
会社の金でソープに行こう!」を合言葉にした。
こんなPMじゃ嫌か?


70 :仕様書無しさん:04/12/22 04:21:20
嫌ヨ。


71 :仕様書無しさん:04/12/22 08:36:41
>>67
良いPMと悪いPMの話だと思うんだが

72 :仕様書無しさん:04/12/22 08:54:35
マジおすすめ。

73 :仕様書無しさん:04/12/22 09:05:05
>>69最悪だな。

74 :仕様書無しさん:04/12/22 10:08:58
>>69
うーん。ごめん。ちょっと嫌。

75 :仕様書無しさん:04/12/23 01:07:25
ソープ言われたら流石に引くな。

76 :仕様書無しさん:04/12/23 17:12:10
>>69
メンバーの意見を聞いた上で決定した場合は、OKだと思う。
しかし、意見も聞かずに、そんな合言葉を掲げたなら、ダメダメだと思う。

77 :仕様書無しさん:04/12/23 19:10:20
>>69

ってゆーか、この話だけきいて良いPMか悪いPMかは分からんな。
それでプロジェクトが成功したんなら良いPMなんじゃないか?
けど、プロジェクトが成功して、会社の金で本当にソープに行ったのなら
会社の立場からすると悪いPMなのでは?

78 :仕様書無しさん:04/12/23 19:16:50
会社の金だと言って自腹でソープ連れてったら漢。

79 :仕様書無しさん:04/12/23 20:09:43
ソープの話しをしたのが69だというのが絶妙だという
つっこみはないんだな

80 :仕様書無しさん:04/12/23 21:06:08
何をもって「プロジェクトの成功」であるかと定義するか?

81 :仕様書無しさん:04/12/23 21:55:48
>>80
無論、プロジェクトメンバー以外が『プロジェクトが成功した』と勘違いしたら成功。
プロジェクトメンバーも『プロジェクトが成功した』と勘違いしたら大成功。

それ以外があるか?

82 :仕様書無しさん:04/12/23 22:27:36
>>79
ソープの価値は本番だからね。

83 :仕様書無しさん:04/12/23 22:38:29
>>81


84 :仕様書無しさん:04/12/24 00:23:32
高級ソプ逝っても20マソの予算だな。安い!!


85 :仕様書無しさん:04/12/24 07:11:22
今までPMした中で予算の最高額と期間を教えてください。

ちなみに俺は7000万円、8ヵ月の仕事だった。

86 :仕様書無しさん:04/12/24 20:44:02
正直 会社の金で何かしてくれるってなら臨時でボーナス出してくれたほうがいい。
しかもソープなんて結局一緒にいくが単独のものだし、いきたいときに個人で言ったほうが楽。
それぞれ好みも違うしね。
会社の金でやるなら、何か集団でやる意味があって(一人じゃできない、あるいは大人数のほうがいい)
さらに、それをやりたいってことじゃないと。
ただこれは難しいよね。
過半数の人間を満足させたら上出来じゃないのかな。

ちなみに俺はソープつれてくって上司は嫌いじゃない。
個人的にそのノリは好きだけど、あくまで上は一般論として。


87 :仕様書無しさん:04/12/24 22:39:39
泣き言なんか聞きたくないね
なんとかしな!



名言だねぇ

88 :仕様書無しさん:04/12/24 22:43:46
今日は「ドーラに学ぶPMのありかた」だな

89 :仕様書無しさん:04/12/24 22:46:45
的確な配置と業務の割り振り、観察するPlan-Do-See-Action
統率力も危機管理能力も見事だ
シータみたいなション弁くさい小娘とは価値が違う

90 :仕様書無しさん:04/12/24 23:36:29
よし、ドーラの行動をPM的観点で評価してみようじゃないか

ラピュタの位置に関してシータから聞けるだけのことを聞いてしまうと、
成功の可能性とリスク、リターンを冷静に計算している。

プロジェクトの短期目標を設定し、メンバー全員に対し明確に伝えている。
インセンティブを示してモチベーション向上を図っている。

たったこれだけのことすら出来ていないPMがなんと多いことか!

91 :仕様書無しさん:04/12/24 23:42:54
ブルックスの法則に従い、経験の浅い二人をチームに参加させることは
本来危険であった。

ドーラがとった戦術は、シータを間接業務に回すことで主力の業務負荷を軽減し、
同時に主力に「持ち場を離れるな」と伝えることであった。

プロジェクトの生産性は向上し、さらに「若い女」で釣ることでメンバーの
モチベーションコントロールも狙ったのである。
見事なマネジメントであると言える。

しかしパズーの扱いにはドーラも躊躇したのではないか。
このガキはまったくの役立たずに終わるどころか、足を引っ張る危険もあった。
さっさと突き落としたいのが本音だったろう。

92 :仕様書無しさん:04/12/24 23:51:25
もう一つ見逃せないのは、ドーラの枕元に設定された伝声管の束である
これは、ドーラが「観察」の重要性を強く意識し
それをシステム的に支援する装置を整えていたことを意味する。

マネジメントの本質を理解し、周到な用意を張り巡らせるマネージャ。
「勝つべくして勝つ」
ドーラに率いられているからこそ、部下はいつまでも子供(馬鹿)でいられるのである。

いや、勉強になったなぁ

93 :仕様書無しさん:04/12/25 10:59:39
どうでもいいけどブルックスの法則とは全然状況が違うよ。

94 :仕様書無しさん:04/12/25 11:12:38
ブルックスの法則って「遅れているプロジェクトに増員するとますます遅れる」ってやつ?

95 :仕様書無しさん:04/12/25 12:56:35
人増えて遅れるわけないじゃん。
要は使い方だよ。

96 :仕様書無しさん:04/12/25 13:25:42
>>95
引き継ぎだの何だのと迎える用意だけに時間を割いて遅れないわけないじゃん

97 :仕様書無しさん:04/12/25 13:53:43
>>95
はぁ?

98 :仕様書無しさん:04/12/25 15:53:41
>95は単なるネジとか歯車だから、
コミュニケーションコストの増大とか考える必要がないんだよ

99 :95:04/12/25 17:43:29
お前等作業手順書も作れないのかよw
プロジェクトの開発ルールは脳内とか?

高度な作業なんて全体の3割くらいの人間が出来ればいいんだから、
後の人間を簡単なコーディングやテスト要員として単純作業化すればいいんだよ。
お前等大きいプロジェクトやった事無いんですか?

100 :仕様書無しさん:04/12/25 18:05:10
>>99
どうせ、大規模案件で下流のコーディング要員か何かの経験者なんだろうけど。

人手が足らない=大きい案件とは限らないんだよ、坊や。

複数案件を同時に走らせてる場合は、小規模案件でも人手不足になるとお分かりかね?

残念だけど、小規模案件を複数走らせてる状態で、

>高度な作業なんて全体の3割くらいの人間が出来ればいいんだから、
>後の人間を簡単なコーディングやテスト要員として単純作業化すればいいんだよ。

そんな戯言は通じねえんだよ。


101 :仕様書無しさん:04/12/25 20:51:43
人手が足らないってのは猫の手も借りたいってのとは違うよね。

ttp://www.mars.dti.ne.jp/~hirok/xp/col/031.html

102 :仕様書無しさん:04/12/25 21:23:50
猫の手を借りる程度の作業にしても
人間様は高くつくからな

103 :仕様書無しさん:04/12/26 00:21:48
>>99
>後の人間を簡単なコーディングやテスト要員として単純作業化すればいいんだよ。

そういうワーカーの不足なんて大した事じゃないんだよ。

>高度な作業なんて全体の3割くらいの人間が出来ればいいんだから、

こういう人間が足りないの。
君みたいな類猿人じゃなくて、人間がね。

本当に仕事した事あるのか?

104 :仕様書無しさん:04/12/26 01:37:35
>>103
「人」の手が足りないとはうまい話だな。
「人」を集めるのは、とっても大変だからな。
最近、ほんと面談とか辛くなってきたよ。

105 :仕様書無しさん:04/12/26 11:58:04
>>103
出来る人間が1割も居れば御の字だな。


106 :仕様書無しさん:04/12/26 14:44:46
>103
そうなんだよね。
知恵をもって動いてくれる人がいないと烏合の衆に
なっちゃうんだよね。
小規模プロジェクトで、自分だけで何とかなるうちは
それでいいけど、いくつも掛け持っていたり、大規模に
なってくると、自分で「考えて動ける」人が必要なんだよね。


107 :仕様書無しさん:04/12/26 14:59:23
俺の会社の上司はメチャクチャデジタル的な考え方で困る。
あるプロジェクトが顧客との話がまとまらずに仕様段階で
停滞していた。それを上司に相談すると今の遅れは20日程度だろ?
それなら新人1人つけるようにするからそれで対応できるだろ。

・・・はぁ?新人に何させるんだ?大体今の仕様を教えるだけでも
俺の工数取られるだろ!ってマジに言いたかった。

でもシステム開発部の部長なんだよな・・・

108 :仕様書無しさん:04/12/26 15:28:43
>>107
そりゃ、この業界、上に行ったら単純な人数計算しかしなくていいんだもん。

自然と馬鹿になるように作られちゃってるんだヨ。


109 :石黒 ◆GqbV7Dy5fI :04/12/26 16:08:58
>>107
なぜ言わなかったんですか?

110 :仕様書無しさん:04/12/26 16:33:38
俺:プログラマも人心掌握術が必要だな
糞:え?ちんちん掌握術!?

111 :仕様書無しさん:04/12/26 22:36:13
>>107
でも、新人を育てるのも割り切ってやらないと。
将来の戦力と思って。
いつかリターンがあると夢見ています;;

112 :仕様書無しさん:04/12/26 22:57:32
新人ならまだいいよ。
糞使えない先輩回されてどうすりゃいいんだよ。雰囲気的に
「この先輩だと新人レベルの生産性しか上がらないですよ」
とか言えないから、結局雑用適当に振って無視してるけどいつまで持つやら・・・

113 :仕様書無しさん:04/12/27 00:41:10
自分が一番つかいにくいのは、常に後ろ向きな人かな。
調べもせずに
「そんなこと、できるわけないと思います」
「本当にやるのかどうか、お客さんに聞いてもらえますか」

そりゃ、工数と見合わないいうことが分かった時点で
やる/やらないの相談は客とするけど、初めから何の根拠もなしに
できませんって言われると、こっちだって客との調整ができないんだよ。

結局ソース見て自分で調べてたりして、まだまだだなぁ、と思う今日この頃。


114 :仕様書無しさん:04/12/27 03:04:20
>>113
できない理由を聞いたらいいんじゃない。
それに、この手のものは、自分で調べてから下に振れば解決する話だと思うが。
なんか、仕事の進め方が逆じゃないかな。

115 :仕様書無しさん:04/12/27 08:11:22
>>114
はいはい。

あなたはちっぽけなプロジェクトしか担当したことないんだよ。
全部PMがコードレベルの実現性まで調べてたら、いくら時間があっても
足らないんだよ。
サブとなる信頼できる人を何人最初に確保できるかがポイントだな。


116 :仕様書無しさん:04/12/27 08:43:56
>>115
できない理由を聞けばいいじゃん。

人間小さいな。下ついてこないでしょ?

117 :仕様書無しさん:04/12/27 09:00:52
コードレベルの実現性って・・・。

118 :仕様書無しさん:04/12/27 10:23:08
ようするに上流設計がなってないっていう。。。

119 :仕様書無しさん:04/12/27 10:27:42
ところで、どれくらいが大規模なプロジェクトなんだ?

コードの行数が100万行?

プロジェクトのメンバーが100人?

デービーに1000万件登録されている?

120 :仕様書無しさん:04/12/27 11:27:18
少なくとも1000万件ってのは関係ないような・・。


121 :仕様書無しさん:04/12/27 11:34:41
>>120
PMから足を洗ってください。

122 :仕様書無しさん:04/12/27 11:45:31
>>120

121 のように言われてもしょうがないよーな。
とりあえず、120 はちっちゃいプロジェクトしかやったことがないな。

123 :仕様書無しさん:04/12/27 11:59:47
1000万件登録すれば大規模ですかそうですか。


124 :仕様書無しさん:04/12/27 12:03:57
ということで、部下に糞データ1000万件でーたべーすに入れる指示。
今日から大規模プロジェクトのPMだ!!

125 :仕様書無しさん:04/12/27 12:06:15
>>123
否定されたのは「関係ない」の部分。
データの多さが規模の大きさを生む事は多々ある。つまり関係ある。

論理的な議論が出来ないところもPMとして失格。

126 :仕様書無しさん:04/12/27 12:07:29
>>124
よかったね。

127 :仕様書無しさん:04/12/27 13:02:11
俺の感覚だと受注金額かな。10億円越えたら大規模かな。
ちなみに一日500万明細越えの
インタフェースが発生する受発注システム開発は受注金額1500万円だった。

128 :仕様書無しさん:04/12/27 13:20:27
標準プログラマの一年の単価1000マソだとして、100人x12ヶ月
の案件ということ?

129 :仕様書無しさん:04/12/27 13:27:54
私的大規模の定義・・・稼動後止めたら、日経新聞そこまでいかなくても日経コンピュータに出れる程度。


130 :仕様書無しさん:04/12/27 14:08:46
世の中いろんな人がいるのね・・・・

131 :仕様書無しさん:04/12/27 14:18:05
プログラムできない奴が押し出される形で
PMになっちゃうのが一番最悪。


132 :仕様書無しさん:04/12/27 14:21:11
>>131
その程度の規模のものなら、別にPMを無視しても仕事になるから大丈夫。
それとも、それでもPMの言うことを聞く旧陸軍のような腐れ組織の一員なんでしょうか?


133 :仕様書無しさん:04/12/27 14:23:14
>>132
プログラムできないPMが脊髄反射レスですか?

134 :仕様書無しさん:04/12/27 14:33:55
>>133
あのさ、プログラマからPMが選出される程度のプロジェクトなんて小規模ですよ。
サブシステムのグループマネージャならわかるけど、PMをそこから選ぶ時点でシステムの規模は知れる。
そうじゃなければ、あんたのいる組織がおかしいだけ。

そもそもプログラムと管理じゃ求められる技術が違うんだから。
優秀なプログラマも別にPMとして優秀とは限らないし。

135 :仕様書無しさん:04/12/27 14:58:07
●132の主張

・小規模プロジェクトはPMの存在など無視しても仕事ができる
・ゆえに小規模プロジェクトにおけるPMの重要度は低い
・逆説的にいえばPGから選出されたPMがいるプロジェクトは小規模である
・結果、PG上がりのPMは重要度が低く、小規模プロジェクトが関の山

・大規模プロジェクトにおけるPMはPG経験などない
・ゆえに大規模プロジェクトにおけるPMの重要度は高い
・逆説的にいえばPG経験のないPMがいるプロジェクトは大規模である
・結果、PG経験なしのPMは重要度が高く、大規模プロジェクトを任される


●逃げ口上
「プログラムができないPMって・・・・」

・プログラムと管理は求められる技術が違う
・プログラマとして有能であってもPMとして有能とは限らない

136 :仕様書無しさん:04/12/27 15:01:49
>>135
まとめて頂いたのはなんだけど・・・で?

137 :仕様書無しさん:04/12/27 15:08:18
まあ、実際小規模案件で>>131みたいなことできないけどね、私には。
そんな余裕はない。
大体、小規模案件ならPM兼メインプログラマ兼コーディネータだな。
見積から設計デザインから技術まで全て自分がそのグループじゃNo1。

逆にある程度以上の規模だと、管理者は細かいことやっちゃいかん。
あんたの役目は旗振りだ、交通整理だと自覚してくれ!って。
コード書くのが楽しいのは判るけど、あんたがそれやってたら他が遊んでしまう。


138 :仕様書無しさん:04/12/27 16:11:46
小規模だと、ドラマ「白い巨塔」で財前役のひとの役割がPM。
なんでも自分でやっちゃう。

139 :仕様書無しさん:04/12/27 16:17:53
で、大規模プロジェクトはどこからPMが選ばれるんでしょう?

コンサルとか?

140 :仕様書無しさん:04/12/27 17:45:56
>>127
どんなシステムか知らんが1500万じゃサーバ揃えるのもキツいんじゃね?
週40時間稼動で良いならPCで適当にクラスタリングすれば余裕だけど。

141 :仕様書無しさん:04/12/27 17:53:52
大規模って免罪符なのか?

142 :仕様書無しさん:04/12/27 17:58:42
>>141
免罪符じゃないが、個人の才覚に依存する割合は低くはなるよね。
最終的にはリーダーの才覚だけど、それを選ぶ過程とか、全体体勢は小規模に比べてシステマチック。

143 :仕様書無しさん:04/12/27 18:00:45
PMとPL勘違いしてる奴居ないか?

144 :仕様書無しさん:04/12/27 19:14:54
PMとPLの違いを述べョ

145 :仕様書無しさん:04/12/27 19:16:30
>>144
PM:パニックメーカー
PL:パルプンテリーダー

146 :仕様書無しさん:04/12/27 20:07:14
>>144
PM:午後
PL:高校野球で強いとこ

147 :仕様書無しさん:04/12/27 22:04:44
>>139
うちは大企業で世界レベルでの商品開発だけど
PMは全員プログラム経験者だよ。
ソフトのPMという意味でだけど。


148 :仕様書無しさん:04/12/27 23:10:05
おもしろいね、ここ。

>>147
>PMは全員プログラム経験者だよ。
「プログラム経験者」という言い方がダウト。
プログラムって経験するもの?

149 :仕様書無しさん:04/12/27 23:13:29
>>148
プログラマ経験者とかってことか?
別に通じるだろ。普通に。


言葉尻にこだわるPGが一番ダウトな存在だよ

150 :仕様書無しさん:04/12/27 23:15:18
「プログラム経験者」「プログラマ経験者」



151 :仕様書無しさん:04/12/27 23:17:28
>>149
言葉尻以前だろ
小学生以下の日本語力でよく働いてるよな


152 :仕様書無しさん:04/12/27 23:23:43
なんか前もあったな、この手の話題。
毎度、何人かが熱くなってスレを乱す。


153 :仕様書無しさん:04/12/27 23:24:23
>>134が言ってる通り、マネージメントは違う技術だな
その技術に必要な基礎知識としてプログラミング技術があるかも。

でも「有能なプログラマであることは、有能なマネージャになるにはむしろ不利な条件」
ていう意見もあるね。

154 :148:04/12/27 23:25:41
いや、言葉尻とかじゃなくてね。なんとなーくね。
「コンピュータ経験者」みたいな違和感?

>>147が言ってることがほんとならとてもいい事だと思うよ。
いや、希望が持てるね。外資かな?

155 :148:04/12/27 23:28:45
>>153
「優秀な選手が優秀なコーチ・監督になるわけではない。むしろよくない」みたいな?
でも、プログラミングを知らない人がPGの上に立つのはやめてほしいよ。
優秀なコーチは、元優秀な選手でなかったとしても、普通、「選手」だったはずだよね。

156 :仕様書無しさん:04/12/27 23:29:59
>>150

プログラム経験者
→ 陶芸経験者を「つぼ経験者」というようなもの

プログラマ経験者
→ 野球経験者を「野球選手経験者」というようなもの

ってことか?

157 :仕様書無しさん:04/12/27 23:31:26
おれがPMしてるメンバー全員12月23日から1月12日まで休み取らせた。
まあ会社来たいヤツは来てもいいとつたえてある。

デスマーチにならないように注意しないと。
社会復帰のリハビリがんばれよw


158 :石黒 ◆GqbV7Dy5fI :04/12/27 23:32:00
この場合はプログラミング経験者と呼ぶべきですよ。

159 :仕様書無しさん:04/12/27 23:35:09
>>157

GOD!

160 :148:04/12/27 23:37:57
俺がくだらんことを書いたためスマンかった。
もう忘れてくれ。
ところで、マ板ひさしぶりなんだけど、石黒さんて、
昔の八千代市民みたいなキャラの人?

161 :仕様書無しさん:04/12/27 23:41:32
>>155
う〜ん、はっきり覚えてなくて悪いんだけど
「プログラマとマネージャでは必要とされる資質が違う」
「有能なプログラマには、マネージャとして必要な能力を磨いたり知識を学ぶ機会がほとんどない」
みたいな話だった。

162 :仕様書無しさん:04/12/27 23:44:03
>>160
どうでもいいこというただのオタクかと思って
放置していたがまともな人だったようだな。

163 :148:04/12/27 23:45:38
>>161
ありゃ、レスありがとう。マ板ってこんなに雰囲気いいところだったっけ...。
>「有能なプログラマには、マネージャとして必要な能力を磨いたり知識を学ぶ機会がほとんどない」
それならわかる。賛成。
でも、それなら、PMと有能なPGの金銭的な待遇は同じであるべきだよね。
もちろん無能なPGはあれだけど。(w

164 :石黒 ◆GqbV7Dy5fI :04/12/27 23:48:22
>>160
八千代市民って誰ですか?

165 :仕様書無しさん:04/12/27 23:48:58
> でも、それなら、PMと有能なPGの金銭的な待遇は同じであるべきだよね。
「金銭を求めるなら管理など勉強せずに技術に没頭しスーパーハッカーを目指すべき」
だそうな。
アメリカだとそうなのかね〜うらやましい。
元ネタはワインバーグのどれかです。

166 :148:04/12/27 23:52:04
>>162
ヲタクではあるよ。ミニスカスレにもずいぶん書き込んだし。

>>164
失礼。

>>165
なるほど。「アメリカではPGの大リストラが」みたいな記事が目に付くけど、
有能であればいいんだよね。きっと。

眠いのでお休み。続きは明日読むよ。148ってHNはもうやめる。

167 :114:04/12/27 23:54:52
>>115
客の話聞いてきて、担当に実装上どうかなって聞いたんだろ?
だったら聞く時に、コードレベルの実現性まで調べてから判断してねって言えばいいんじゃない。

設計も実装もできなくてもいい(誰かにやらせればいいから)が、マネージャーなら、せめて仕事を
振ることぐらいやらないと、後どんな仕事するんだ?

168 :仕様書無しさん:04/12/27 23:58:30
PMで自分のプロジェクトの損益分岐点がマイナスになりそうな場合どうします?
俺は自分の残業はサービス残業で茶を濁す・・

169 :仕様書無しさん:04/12/27 23:58:45
ところで当たり前の要に語られてるけど、
PGからPMに抜擢されるって規模に関わらずあり得ないでしょ。
小規模であれば仕事取った営業orSEがPMするか、
そもそもPM専門の管理者が複数プロジェクト兼任してるのが普通。
大規模になるとPM経験者の中から抜擢される。

持ち上がりで上に立つのはサブリーダーくらいまで。じゃね?

170 :仕様書無しさん:04/12/27 23:59:24
>>167

>137
>あんたの役目は旗振りだ、交通整理だと自覚してくれ!って。

171 :仕様書無しさん:04/12/28 00:02:23
>>169
嫌、それはあるでしょ。>PGからPMに抜擢

零細または小企業でそのステップ踏まないで
どやって中企業になるんだ?
所詮、中小なんて・・・ってレスは禁止。

172 :仕様書無しさん:04/12/28 00:03:20
>>168
そんな事自分で抱え込むなんて何様だ?
まずは利害関係者に状況説明しろよ。

173 :171:04/12/28 00:05:19
ちなみに俺んとこは5年で社員10倍になった。
会社規模的にも外注に振る身分にまでおっきくなったよ。
おかげでPGスルーした自称SEも増えてきた。


174 :仕様書無しさん:04/12/28 00:06:08
>>172
そだね。で、自分で抱え込んどいて、内心ヒーローきどりで、
あとは全部PGに尻ふかすとかね。

175 :仕様書無しさん:04/12/28 00:07:29
>>173
>PGスルーした自称SE
とは、PGを経験したSE?PGをしなかったSE?

176 :仕様書無しさん:04/12/28 00:08:53
>>171
仕事取った営業orSEがそのままPMやって経験積みます。

だから元々顧客とお金のやり取りしてるPGならなってもいいけど、
昨日までJava組んでました〜みたいなPGがシフトするのは無いと・・・思ってた。あるの?

177 :仕様書無しさん:04/12/28 00:08:55
>>175
PGをしなかったSEです。

マ板的にはSヨだったな

178 :仕様書無しさん:04/12/28 00:11:28
>>173
大量の偽装派遣に彩られた典型的な違法ビジネスモデルですね。

179 :仕様書無しさん:04/12/28 00:17:29
>>176
>昨日までJava組んでました〜みたいなPGがシフトするのは無いと・・・思ってた。あるの?

さすがにそれはない。
新人(SE)が行き成り客の前に躍り出るぐらいありえない。

ステップとしては
・PGが電話またはメールで直接顧客と
(ささいなこと)の仕様調整(→追って社内MTG)
・顧客とのMTGに顔出し(居るだけ)
・見積もり、設計、スケジュールの試算(練習として)
・部下(後輩)への指示出し、割り振り
・その他色々

ま、普通の新人SEと同じだね。
できるPGで且つSE(またはPM)特性あると
設計、スケジュールに関しては多少安心できる。
ついでに、出来るか出来ないかの
判断でも差がでる。

>178
パッケージが売れちゃたんだよ。あとWeb系も
早くからやってから、そこそこの案件が
元クライアントと仲いい会社から直接来るようになった。


180 :仕様書無しさん:04/12/28 00:29:04
MTGって何だ?

181 :仕様書無しさん:04/12/28 00:31:39
>>179
パッケージって売れるとそんなに人数増やすのか?
つーか10倍って何人?そのうち何人が派遣か把握してる?

182 :仕様書無しさん:04/12/28 01:00:36
>>181

179じゃないけど、パッケージは売れると人増やすよ。
売れないと一挙に保守モードで人数減るけど。

まぁ、私の場合は業務用のパッケージだから、店に並ぶようなのとは
違うけど。

183 :仕様書無しさん:04/12/28 01:05:55
>>181
一人でやってたのが十人に増えた。ただそれだけ。

184 :仕様書無しさん:04/12/28 01:08:11
>>183
最小人数かよ・・・
最初の表現がおかしいよ・・・

185 :仕様書無しさん:04/12/28 01:14:13
>>180
ミーティング。略語使いこなす出来るPMになれ!

186 :仕様書無しさん:04/12/28 01:18:12
>>185
略語の前に日本語使いこなそうな。

187 :仕様書無しさん:04/12/28 01:22:05
>>186
漏れもプルグラム経験者といっしょか?詩悩!!煎ってくる!

188 :仕様書無しさん:04/12/28 01:24:44
Magic The Gathering かと思った。

189 :仕様書無しさん:04/12/28 01:30:05
受け手のレベルを度外視して、意志の疎通を妨げるような
略語を発するのは出来るPMとは言いませんよ。

190 :仕様書無しさん:04/12/28 01:47:43
>>185
    ,ィィr--  ..__、j
   ル! {       `ヽ,       ∧
  N { l `    ,、   i _|\/ ∨ ∨
  ゝヽ   _,,ィjjハ、   | \ 俺たちはだまされていたんだ。
  `ニr‐tミ-rr‐tュ<≧rヘ   > 
     {___,リ ヽ二´ノ  }ソ ∠ MTGとは、ギャザの事だったんだよ!!
    '、 `,-_-ュ  u /|   ∠
      ヽ`┴ ' //l\  |/\∧  /
--─‐ァ'| `ニ--‐'´ /  |`ー ..__   `´
    く__レ1;';';';>、  / __ |  ,=、 ___
   「 ∧ 7;';';'| ヽ/ _,|‐、|」 |L..! {L..l ))
   |  |::.V;';';';'| /.:.|トl`´.! l _,,,l | _,,|  , -,
    ! |:.:.:l;;';';';'|/.:.:.:||=|=; | |   | | .l / 〃 ))
    l |:.:.:.:l;';';'/.:.:.:.:| ! ヽ \!‐=:l/ `:lj  7
    | |:.:.:.:.l;'/.:.:.:.:.:.! ヽ:::\::  ::::|  ::l /

191 :仕様書無しさん:04/12/28 06:39:40
ストレスを溜めない秘訣は
人に期待しないことだと知りました

192 :仕様書無しさん:04/12/28 08:11:14
ミーティングをMTGって略す意味あるのか?
字面半分だけど読んでみるとかえって長くね?


193 :仕様書無しさん:04/12/28 08:21:44
MTGとか発想がアホ女子高生並
若くて未来がある分、女子高生の方がましだな

194 :仕様書無しさん:04/12/28 09:50:26
おれの会社略語ばっかり・・・・
MTG・・・ミーティング
ML・・・ミーティングルーム
部長・・・B
課長・・・C


195 :仕様書無しさん:04/12/28 09:56:53
MLはメーリングリストだボケ!
あと、課長はK、係長はC。
アホっぽいから口に出して言うな、議事録に書け!

196 :仕様書無しさん:04/12/28 10:02:50
>>194
うちの会社だと「B」ってのはバカの略

「あいつBだからさぁ・・」みたいな

197 :仕様書無しさん:04/12/28 10:09:44
ML=みーちんぐるーむ・・・”L”はどこからきたのでしょうか?

198 :仕様書無しさん:04/12/28 10:30:21
>>197
ねたに混じレスかっこ悪い

199 :仕様書無しさん:04/12/28 10:40:31
ガチ間違いした奴ほどネタにしたがる罠

200 :仕様書無しさん:04/12/28 10:42:18
>>199
ネタにまじれすかっこ悪い罠

201 :仕様書無しさん:04/12/28 17:29:43
日本を代表する電機メーカーのPMだかSE崩れが漏れの会社に流れてきて
重役やってんだけど、最悪だよ。なんだか「俺仕様」でがっちり書類作るんだけど、
読む気もおきんよーなもん。自分も、規則表やら進行表作っただけで満足らしく、
もう自分でも読んでないようだけど。でも、たまーに、地雷のように、「あいつは、
すでに発効している規則○○に従っていないから昇給は見送りだ」とか言ってる
らしい。これは、自分の作った規則表が守られているか見てるんじゃなくて、
気に入らない奴にムリヤリあてはめてる様子。
現場の士気が下がりまくり。最近はあんなのを採用した社長への憎しみにもなってる。

202 :仕様書無しさん:04/12/28 17:48:47
>>201
憎しむ前に社長に状況説明しろよ

203 :201:04/12/28 22:49:11
>>202
小さな会社なんだけど、社長は「雲の上の人」でね。
人事関係の進言をことのほか嫌う。
「あなたが抜擢したあれバカですよ」と言ってもこっちが憎まれる。
つーか、俺はそのバカに嫌われて、したがって社長にもにらまれてるんだと思う。
社長自身、二代目さんで、仕事できない人なので、どの部下がほんとに仕事できるか
わからんらしい。で、人事権だけが拠り所だから、その手の批判は許さんらしい。

204 :仕様書無しさん:04/12/28 23:35:02
辞めるのが得策だね。

205 :仕様書無しさん:04/12/29 00:10:20
自分に対する不満を耳にした時、ふと孤独感にさいなまれる事がある。
精神的に安定したい・・・。

206 :仕様書無しさん:04/12/29 00:11:48
不安になること多いよな。
作業少なくても時間はまちまちだし、評価ってダイレクトに得られないし。
中間管理職の辛さと経営の重圧を両方背負って一人で労働している気分wwwwww

207 :113:04/12/29 02:11:57
>>167

もういまさらなんだが・・・。

できない理由が聞いたのだが、既存のプログラムの改修作業で
調査するソースが多くて調べるのが大変だから
そんなことはできません(やりたくありません)という回答だったので困った、
ということを言いたかっただけ。

調べるのにどのくらいかかるのかと聞いたら、それを見積もるだけでもっと時間が
かかりますと言われ、ちょっと急ぎだったから自分でソースを見て時間を見積もった
ということだよ。
自分でソースを見たことが良かったとは決して言わないが、
やりたくないからできません的な回答をされると、ちょっとね、ということを言おうと
思ったのだけど、言葉が足りなかったね。



208 :仕様書無しさん:04/12/29 08:01:44
困る前に叱れ

209 :仕様書無しさん:04/12/29 08:46:46
>>204とか>>208みたいなレスってつまんねーよ。

210 :仕様書無しさん:04/12/29 09:37:56
>>209
なんで?

211 :仕様書無しさん:04/12/29 11:35:42
>>211
自演乙

212 :仕様書無しさん:04/12/29 12:48:27
>>211
まさに自演乙ですね。

213 :仕様書無しさん:04/12/29 16:52:48
「というわけでお前等3日から出勤な。」
と決断した俺は嫌われたんだろうなぁ。鬱だなぁ。

214 :仕様書無しさん:04/12/29 16:53:25
>>212
釣られんなよw

215 :仕様書無しさん:04/12/29 17:44:41
>213
なぜそういう決断に至ったかが問題では?
そうならない様に最大限努力した?

結局、PMとしてマネージメントして要員が働き易い環境を整えたかどうかに因ると思う
# その苦労を分かってくれないんだよねぇ、上も下も┐(´ー`)┌

216 :仕様書無しさん:04/12/30 01:19:51
>>207
そりゃあれだな。
まず、お前に説明・説得するのが面倒でそんな言葉使ってるんだと思うぞ。
お前のアプローチの仕方も悪いな。
俺がそいつでもお前の言ってることは「とりあえずやれ」に聞こえる。
要するにそいつってそのプログラムがよくわかってねぇんだろ。
それはお前も理解してるだろ?
そいつの状態としては「このプログラムがよくわかって無い」状態なわけだ。
それなのにお前はよくわかって無い人間にたいして
「調べるのにどれくらいかかるのか?」とかきいてしまっている。
わかるわけないだろ。
こんな会話してるとそのうち部下に逃げられちゃうぞ。

217 :デフォルトの名無しさん:04/12/31 06:14:11
PMじゃないんですがPLについてお尋ねします。

今のプロジェクトのPLなんですが、成果物を一切見ようとしなくて
メンバに出来たかどうかを聞くだけでPMに報告してるんですが、それって
普通なんですか?

私は新人なんですが、おかしいのではないかなと思うんですよ。


218 :仕様書無しさん:04/12/31 08:18:39
>>217
えーと、まあどっちにしても不満は出ると思うが・・・。

新人とはいえ大人だから成果物には責任を持たせるべきって考えと、
まあ単なる無責任の可能性と。

といいつつ、いちいち見られてもそれはそれでうざいんだけど。


219 :仕様書無しさん:04/12/31 08:50:28
成果物チェックは
何回も同じプロジェクトを経験して
信頼できるPGならほぼノーチェックだな。
初めてプロジェクトが同じになる場合は
時間をかけて誤字、脱字チェックから入るな。

まぁ大体、使える、使えないという
評価は噂で聞いてるから、
使える新人と思われているんじゃないのか。

220 :仕様書無しさん:04/12/31 09:51:27
>>217
ノートラブルで回っている内はいいけど、1つでも納品後に問題起きたら、信頼が地に落ちるヨ。そんなことしてるとね。

レビューしたって見逃す障害要因ってのは多いけどさ。形式的にでもやっとけば、何か起きたときの予防線くらいにはなる。

1人のPGを切る程度で済めばいいけど、体制そのものがまずいと判断されたら、全員の評価に影響するんだよね(苦笑)


221 :仕様書無しさん:04/12/31 09:58:48
>>217
PM、PL、PGと何でもやっていますが、
PLをやる時には、単体レベルでの「できました」については
あまりというか、殆どチェックしません。
人に応じてヤバそうな人のはチェックするけど。

平行して実施している結合テストで機能面から
チェックしているから、あんまり問題も無いけどね。

個人的な感想としては、テストが下手な奴が
PLやってるプロジェクトは発火している気がする。

222 :仕様書無しさん:04/12/31 12:26:43
最終的なチェックはPLがするもんだと思ってるんだけど漏れの勘違い?
つーか、漏れが工程管理から実装までしているだから、最後のチェック位しろよというのは贅沢?
どーせ、最初と最後しかこねーで、メールの進捗報告でごまかしているんだから、
最後のケツ位もてよと思うのは間違いか?

・・・あんたがちょこっと受け持ったとこだけバグでてんだよ。
あんた何やってんの?で、今までの所業、全部客からばらされてやガンの・・・。
・・・いや、最終で全チェックしたの漏れだけど、あんたん所だけはやってないよ?
全部自分でかかえこんでて、当日渡されてチェックできるかっていうの。


という事態がありました。
漏れの意見的にはPLには無理にでもチェックさせましょう。
つーか、最近は客にも無理にチェックしてもらってます。
本当に痛い目にあうと、客も良い意味でも悪い意味でも学習する。

223 :仕様書無しさん:04/12/31 12:30:45
プロジェクトの規模によってPMかPLか、サブのリーダかは変わるけど、
成果物については必ず作成者以外の誰かが一度はチェックするのが普通です。

どれだけスキルの高い人間にだってミスや認識違いはあるし、
「PGへの信頼」を理由にチェックを怠るのは、
「PGからの信頼」を裏切る怠慢行為です。

>>221結合テスト段階からのチェックでは機能面、品質面で手遅れだと思うんですが・・・

224 :仕様書無しさん:04/12/31 12:35:23
「チェック」が「良い物作る為の共同作業」なプロジェクトは成功するし、
「チェック」が「私利を守る為の交渉作業」なプロジェクトは失敗する。

225 :仕様書無しさん:04/12/31 13:48:32
>>223
コーディング→単体テスト→結合テスト
という順番でやる結合テストなら、確かに手遅れだよね。
経験上、痛い目にたくさん遭ってる。
アサインの問題で、結合テスト時には作った人が
いなくて、結局、自分で直した事もやっぱりあるよ。

「平行して実施している」と書いたのは、
コーディングの初期時点から、結合テストも実施しているのですよ。
なので、理想的にいけば、単体テスト、結合テストまで
同時に終わるのです。
いわば、ロジックレベルでの単体テストと、
システムの仕様、機能、品質面からの結合テストとの
はさみうちを日々、やる感じですね。

なので、ヤバそうな人というのは、単にその人のスキルだけの
問題ではなく、仕様、機能、品質面から、重要かつ難易度が高い箇所から
優先的に早い段階で潰して行ってます。

長文、失礼しました。
けど、他にもこんな感じでお仕事してる人っているかしら?
という興味から、書いてみました。

226 :仕様書無しさん:04/12/31 13:54:19
>>225
ちゃんとモジュール単位で分割できる構造でなきゃ、その手法にも意味がないけどねw

下手すると、モジュールが信用できないのに、なんで結合の方はOKなんだ?と叩かれることになりがち。

Notesなんか、モジュール単位もへったくれもなくて、モジュール単位がOKにならないと結合なんかできない場合も多いよw

その意味では、ソースがテキストファイルで成り立つ開発現場がうらやましいね。


227 :仕様書無しさん:04/12/31 14:11:35
>>226
そうね。確かに開発環境というか、言語の特性に依存する面も多いかもね。
あと、大規模なシステムだと、上手く行くのかな?という気もしてます。

まぁ、偉そうに書いたけど、担当しているのが基本的に小規模な
プロジェクトが多いので、こんな感じが良いのかなと改善しながらやってます。

228 :仕様書無しさん:04/12/31 21:34:57
>>217
そのPLは、成果物の責任をとらないって事じゃない。
とりあえずは、レビューしてくれって頼んでみては。
だめなら、最低でも他のメンバーとのレビュー等の工数をもらっとくの。
無責任な人間は、部下が勝手に動くと、過剰な反応をするから要注意ですよ。

229 :ヒデ:04/12/31 23:12:57
最近、まで火ダルマプロジェクトのリーダーやってましたよ
年末にようやく目処がついて年明けにはカットオーバーできそうなんだけど

うちの失敗は、立ち上げに失敗したことに尽きると思うのですよ
プログラマーやSEがドウコウよりも
そもそも何を作るのかさっぱりわかんない
マネージャーはスケジュールだけ決めてきたんだけど
期間短縮の為に要件定義は詳細設計やりながらっって・・・
突っ込みどころおおすぎて・・・
概設は省略とか言ってるし

どこかで聞きかじってきた新しい開発手法らしいが
メンバーがついていけるかどうかを考慮せず勝手に顧客と盛り上がって決めてくるのはいかがなものかと

おかげでデスマのうえに五億の赤字
サブマネージャーは失踪するし
実験的なことは、もっと小さい案件でやってくれ
というか早く会社に報告してくれ、俺は知らんぞ、どうなっても

つうわけで、部長にチクって逃げました



230 :仕様書無しさん:05/01/01 14:08:17
新年から出勤しているPMあげ

231 : 【ぴょん吉】 :05/01/01 18:39:44
PMは名前欄に「!omikuji」と入れてみろ。
次のプロジェクトが順調かデスマるかを占えるぞ。

232 : 【大吉】 :05/01/01 19:04:05
成功しますように

233 : 【ぴょん吉】 Yura ◆yMz13RbUJs :05/01/01 19:53:06
テスト

234 :仕様書無しさん:05/01/01 22:23:55
>>225
単体テスト=モジュール(クラス?)に対するテストと考えて、
2つ以上のモジュールが絡むテストは結合テストと置いてるわけですか?
つまり 単体テスト完了→他と結合テスト みたいな流れって事で合ってる?

であれば、単体テストと同程度行う結合テストの
チェックが出来てるみたいなので問題は少なそうですね。

ただ、ソースコードレベルの品質はその段階では見えないですよね?
バグは出なくても品質の低いコードが増えて後で問題になったりしませんか?

235 :!omikuji:05/01/02 11:40:06
orz

236 :「!omikuji」:05/01/02 11:41:08
orz

237 :!omikuji:05/01/02 15:07:30
ほえー

238 :!omikuji:05/01/02 15:08:07
orz

239 :仕様書無しさん:05/01/04 00:59:32
PMの人たちに聞きたいのですが、ソースレビューってやってますでしょうか?
経験上、どうも単体テストとか徹底してやることよりも、
しっかりソースレビューやった方が効率的のような気がしていて・・・。
>234 にあるように、ソースの品質って、単体で場当たり的な対応してると
あるクラスがダメになっていって、で、クラス間のインターフェースとかがまた
ダメになって、もうダメダメシステムになってしまう危険性があると思います。
Cでソースレビューしたことあって、HarberCとか使って一覧できて
すごく効果的にできた経験あるんだけど、
JAVAとかになるとソースの構成上かなり一覧しずらくて
やりづらい部分があるような気がします。
JAVAでソースレビューやっている人はいますでしょうか?

240 :仕様書無しさん:05/01/04 03:14:59
>>239
ソースレビューは、新人のOJTの一環か、パフォーマンスのチューニングでしか行わないよ。
ソースレベルで、設計の妥当性を判定してるように伺えるが、それってまじめにやると大変でしょ。
とてもじゃないが、実装方針をUMLや文章で提示してもらわないと、時間が掛かってしょうがないのよ。
だから、うちは設計書と単体テストの項目レビューに力を入れているよ。

241 :仕様書無しさん:05/01/04 08:15:12
<240
いやあね、普通そういうやり方だと思うけれど
単体テストで全ケースの入力系を試すのが理想だけど、どこまで完璧にやるかって
のがあって、ある程度テストパターンをしぼってでも
ソースレベルの品質を上げることの方が重要かな?ってことなのね。
また設計書から見た視点とソースから見る視点とが違う場合は、
そこから、必要なテストパターンが見えてくることもあると思うし。
プログラマの訓練にもなるしね。

たまにソース見てケチつけたりすると、
ひどくこだわりを持ったPGがいたりしてキレたりするのね。
そういうPGの個性というか柔軟性とか将来性を見抜くためにも良い気がする。
信頼できるPGの場合は、ソースレビューはやらなくて大丈夫だけど・・・。

242 :仕様書無しさん:05/01/04 10:49:22
実装方法に関するドキュメント見て設計品質が上がると思うのは初心者だろ。
大抵のプログラマにとって、プログラム設計書は単なる体裁なんだから。

243 :仕様書無しさん:05/01/04 10:52:31
>>241
>ひどくこだわりを持ったPGがいたりしてキレたりするのね。

そうそう。そんでこういう人が比較的高スキル(として認められてきた人)だと、
逆にこっちが攻められたりして、許容するとシステムがボロボロになっていくと。
何か上手いやり方が欲しい・・・

244 :仕様書無しさん:05/01/04 11:35:40
ソース見て、不要なコードが多かったので
「ここは、こう記述した方が良いと思うん」
と指摘すると、
「そんなレベルの低い形式で進めて良いんですか?」
とか言ってきて、
「このプロジェクトでは、これこれこういう理由でこういうやり方でやっているわけで・・・。」
って説明すると、キレて
「ここのプロジェクトは、レベルが低すぎてやってられねえよ」
となって、もうまったくやる気の無い感じになるのですね。

視点がもうはじめから、実際の運用から外れちゃってるのね。
こういった人種は、どう対処するのが適切なのでしょうか?
首にすることはできないので・・・。

245 :仕様書無しさん:05/01/04 11:53:46
>>244
飼い殺し

246 :仕様書無しさん:05/01/04 13:00:41
知識だけが多くて経験の浅い人は、要求に対して実装するという根本的な事を忘れがちだね。
一つ共通機能をお願いしたら、過剰なくらいのライブラリを作って、
ただしシンプルに要求を満たすものが一つも無いとか。

こういうの見ると「いや〜頑張りましたね。価値無いけどね。」
とか吐き捨てたいけどそうもいかず、やんわり説明してるとキレられる。

俺はプロジェクトから外したよ・・・

247 :仕様書無しさん:05/01/04 13:19:29
>>246
だいたいそういう場合って要求自体があいまいで
作ってから要求したかったものがはっきり見えてくるってパターンだろ?

細かくいうと、そいつ自身、経験が浅いもんだから期限ギリギリまで実装時間にあてちゃってて
いざ提出したときには「はじめの要求をみたしてはいるんだけどなんかもの足りない」って
感じになっちゃって、できたもの見て要求したいものがわかった依頼側が調子にのって
そこから足りない仕様を指摘して「あいつつかえませんね」とかのたまうパターンだろ?

ふざけろ。
使えないのはどっちなのかわからせてやりたい。

248 :仕様書無しさん:05/01/04 13:20:37
で、「どんな仕事でもコミュニケーションが大事」とかいっちゃって
実際はPMの仕事放棄してるだけ。
一生貧乏でいてくださいな♪

249 :仕様書無しさん:05/01/04 13:26:16
タイピングしか出来ない奴はこなくていいよ

250 :仕様書無しさん:05/01/04 14:11:03
>>245
なるほど。たしかにそうしていれば辞めてくれそうな感じ。
でも軌道を修正できれば良いところありそうなんだが・・・。

言わなきゃ何もやらなくて、言ってもしばらく経って
どこまでできた?って聞くと
全然進んでない、で何もアラーム投げない人よりは遥かにマシなのでね。


251 :仕様書無しさん:05/01/04 15:21:51
とにかくインタフェース仕様だけしっかり見ておいてあげれば、
システムが崩壊してしまう事態には至らないと思うわけだが。
ヤバそうな香具師に担当させる部分は隔離しておくが吉。

ソースレビューで一番効果が期待出来るのは、
ヤバそうな香具師の実装(内部設計)に関する部分ではないかと。

252 :仕様書無しさん:05/01/04 16:14:13
>>250
つーか、開発現場で"1を教えたら10を知れ"式なことやってると、問題が起きたとき、
開発体制自体が疑われると思ってた方がいいよ。
インターフェース仕様だけしっかりとねというのは、そういうことね。

「聞けよ」と怒ってる奴ほど、伝えるべき事を何も伝えてない場合が多いのよね。

ただ、要求仕様を全部充たしてても、案外足りないものは多かったりもするのも、また事実。
そういうのはほとんどの場合、SE側やPM側も見落してるものなんだが、おこりっぽい奴ほど、
下っ端のPGのせいにする。そして、例のごとく、「聞けよ」もしくは「考えろ」とか言いだす。

個人的に開発現場の連中って(オレもそうなんだけどさ)、客がどうのこうのという視点が
欠けてるよね。ほんとに大事なのは、製品の質と要求仕様を充たしてるかどうかなんだけど
(もち、運用可能なものをってことで)、不思議と自分のイライラ解消に重点を置く奴が多い。
そういう連中って大抵の場合、話しかけ難いし、やりにくい。

アナタもそうなってる可能性は無いかい?


253 :仕様書無しさん:05/01/04 16:28:42
そもそもPMってのは責任を被るのが仕事みたいなもんなんだからな。
問題がおきちゃった時点でPMのせいなんだよ(本当はね)。
それがおきないようにするのがそもそもの仕事なんだから。

ここで、じゃあどうすればいいのさ。ってのを考えないとね。
少なくとも、スケジュールギリギリまでまって最後の日に
「できないじゃないか!?」なんて怒り出すよりやっとくべきことあったよね?って話ですよ。

254 :仕様書無しさん:05/01/04 16:46:30
> 少なくとも、スケジュールギリギリまでまって最後の日に
>「できないじゃないか!?」なんて怒り出す

過去に数人ほど、そういうのを目撃してます。

もちろん、最終日に仕様変更を容認したバカPMのせいなんですが。実際に責任
取らされたのは、外注のPGでしたなぁ。徹夜を1人でやらされたあげく、完成
したら、切られてましたね。可哀相に。

かと思えば、納品後、2週間も経過して、一度も聞いていない(実は担当SEが握ってた)
仕様を告げられて、ものの見事に障害発生とか。その時は私がメインのPGだったんで、
ひどい目に遭いましたね。信用するんじゃなかったと自己嫌悪に(^^;

基本的に、自分の仕事をやらずに下に垂れ流す傾向のある人物に、取り仕切られるのは
怖いですな。でも、そういうSEやPMって山ほどいますがねぃ。

機会があったら彼らの仕事を後から見てると笑えますよ。実働時間がどれだけ短いか
分りますから。まぁ、仕事の優先度の考え方の差なんでしょうが、下手すると、放置
どころか無視される場合も多くて、何を依頼しても。そういうSEも結構いますなぁ。


255 :仕様書無しさん:05/01/04 16:50:30
そもそもソフトウェアなんて作りながら
仕様が変わっていってしまうものなんですよ。
だから、とにかくまってちゃ駄目なんですよ。
実装する機能の順番を下に決めさせてちゃ手遅れなんですよ。
まあ、保身に走って自分の位置さえ確保しときゃいいとかいう根性ならそれもアリですけどね。

256 :仕様書無しさん:05/01/04 16:52:38
あ、>>255>>253のつづき。
気にしないでくださいw

257 :仕様書無しさん:05/01/04 17:22:51
まぁ、聞くと怒る。握りしめる人ほどそうなんですよねぃ。
で、こういう人はこちらで、その人物が暇なタイミングを計ってあげないと
簡単にキレちゃうんですよネ。

メールの確認程度でも、途中のインタラプトに弱いみたいでね。
内心、「お前はシングルタスクの糞コードか」と思うんですが。

「聞け」は一見、正しいですけどね。もちろん、「考えろ」もね。ただ、それは
当人だけが頑張ったところで、無意味なんですよねぃ。ほんとだったら、PMとか
が配慮して、開発環境を改善すべきであって、1人のPGをどうのこうの言うべき
問題じゃないんすよ。

下っ端から見れば、「聞いたって答えてくれないじゃん」、こう思われたらアウト
っすね。もちろん、下っ端のそれがいつも正しいわけじゃないんですが。

「気が利かない」とか思ってるPMやSEなら要改善だと思いますネィ。


258 :仕様書無しさん:05/01/04 18:06:02
なんだか、PMを愚痴るスレに変わってきてるな

259 :仕様書無しさん:05/01/04 18:29:02
そういうのは上司スレに逝ってほしいね。

260 :仕様書無しさん:05/01/04 18:41:10
>>258
マ板の本質だからな。
実際、PMになっちまったらすでにプログラマじゃねぇよ。
こんな板にいること自体おかしい。

261 :仕様書無しさん:05/01/04 22:31:10
>>258-259?
何?俺は>>257はいいこと言ってると思うが。まじで。
ただ、実際、>>260の言うように、ここにPMがいるのは不思議な希ガス。

262 :仕様書無しさん:05/01/04 23:41:42
「現役PG」だけでなく「元PG」がいても不思議ではあるまい。
想像力の欠如した香具師の設計は危なくて見てられない。

それ以前にここはPMな人達を隔離しているスレだ。
日本語を読み解けない香具師の仕様書は見るに耐えない。

263 :仕様書無しさん:05/01/04 23:53:28
マ板って開発に携わってる人全員の雑談板って事でいいんじゃないの?
そもそもPGだってPM視点は必要なわけだし、
小さいプロジェクトなら兼任してる人も多いでしょ?

264 :240:05/01/05 00:40:22
>>241
アナライザの結果を基にやる分ならいいけど、設計内容まで加味して結果を
出すものって無いし。
ソースレベルで見たら、単体で全パス通すのと変わらんような気がするが。
だから、効率を考えると、ソースレビューは採用できないのよ。

>>242
設計書のレビューしないのか、それとも、設計書とか書かないトコなのかな。
クラス図(モジュール関連図)とシーケンス図(正常系)だけは必ず書いて
もらってるが、この二つだけでもレビューしたら、十分効果があるんだが。
単体テストが終わるまでに一度レビューするくらいだし、全部で10枚越すよ
うなことは無いし、これぐらいなら、みんな書いてくれるよ。


265 :仕様書無しさん:05/01/05 00:53:41
実装に関する設計書作成 → レビュー
してる間に
実装 → ソースレビュー
を沢山出来る。かも。

266 :仕様書無しさん:05/01/05 06:35:19
ソースレビューってする意味わかんね。
>>244みたいなのって何か明確な基準があって指摘するわけ?
例えば>>244>>244の言う変な奴がたまたま逆の立場だったら
>>244>>244の言う変な奴から指摘をうけるわけだよね?
こういうのどっちがいいかってのは、2ちゃんでだって十分論争になりうる話題だ。

仕様さえ満たしていれば、とりあえず深く突っ込むのは止めたほうがいいと思うんだけど。
その部分に問題が出てから「じゃあ〜」ってんで対策を考えるならまだしも
記述が変だから、こう記述した方がいいから(いいって?どういいの?)とか
実際の運用で特に問題が出てるわけじゃないのにわざわざひっかきまわして
うまくいかないと思うな。

267 :仕様書無しさん:05/01/05 08:06:19
>記述が変だから、こう記述した方がいいから(いいって?どういいの?)とか
>実際の運用で特に問題が出てるわけじゃないのにわざわざひっかきまわして
>うまくいかないと思うな。

保守しないつもりですね?:-)

サンプルチェックはぼくわ必要だと思うなぁ〜
今まで一緒に仕事した人ならともかく、お初の人相手なら。
PMがやるかPLがやるか、信頼のおける片腕達がやるかは話は別だけど。

268 :仕様書無しさん:05/01/05 09:19:42
>>266
正式にはソースコードレビューで、コードレビューの方が一般的な用語かもね。

で、コードレビューが一方的だと考えるならそれは間違ってる。
指摘された点について間違ってると思うならPGだって説明するのは当然だし、
論理的な話の中で意見がぶつかるなら、メリットデメリットを擦り合わせて
お互い納得するような答を導けばいいわけだし。

問題なのは経験や勘を盾に論理的な議論をしない人なわけで。

269 :仕様書無しさん:05/01/05 09:49:49
>>266
>仕様さえ満たしていれば、とりあえず深く突っ込むのは止めたほうがいいと思うんだけど。
そう思うなら、きっと良いプログラマに囲まれてるんだろうね。
俺の周りではちょっと見ればコードが半分以下になるような人とか、
パフォーマンス的にあり得ないコード書く人が溢れてるから、
仕様以外でも見所満載なんだよね。

>その部分に問題が出てから「じゃあ〜」ってんで対策を考えるならまだしも
コード品質レベル指摘だとすると、問題とは保守性の低さによるスケジュールの遅れ、
パフォーマンスの悪さにより性能要件が満たされない、とかだよね。もっとあるかな。
どっちも問題出てから「じゃあ〜」だとコストが掛かりすぎる。

どちらにせよ、理由無く引っかき回すレビュアーを前提に要らない、
はコードレビューへの言及じゃなくて、特定の人に対する愚痴かと。

270 :仕様書無しさん:05/01/05 19:13:19
>>267-269
いや、その意見ってさ、
「やったほうがいいか悪いかなら、やったほうがいいに決まってる」
的な安易な考えにしか聞こえないんだよね。
実際は>>244みたいな論争になるよ。
2ちゃんみてりゃわかると思うけど、STL(標準ライブラリ、標準だよ、標準、何を踏み切れないのか・・・)を
使うか否かでスレ埋めるぐらいの論争になるじゃん。
出だしのアプローチの話題からいって危険だよ。
誰を正しいとおいて、何を目標とするの?って部分に定義がない。
で、俺も長いことプログラマやってるけど、ソースの記述の良し悪しって
はっきりいってよくわかんね。
大規模であるほど迂闊にさわれなくなるし、中身がどうなっていようと
長いこと正しいとされる動作で動いてくれるAPIにはやっぱり安心感があるよ。
ソースレビューやったからって運用実績の少なさは変わらないんだし。
第一、1日に1人で1000行も2000行も書くときもあるのに、
ソースレビューなんてのんびりやってられない。

271 :仕様書無しさん:05/01/05 19:16:18
>266
明確な基準と言えば、第一に保守ですね。
そのパーツが仕様を満たしていとしても、
後に仕様変更とかあったときに
その担当してた人がいないケースのことも考えなくちゃいけないわけ。
そんなとき、無駄が多くて理解しずらいソースじゃたいへんでしょ?
そういう意味じゃ、たとえパーツが独立してたって、
ある程度システム全体を見てもらわないとね。
余計な処理とか、理解しずらい書き方は避けてほしいね。
いういう意見に癖のあるPGは噛み付くのね。
少しは分かれよって思うけど。

272 :仕様書無しさん:05/01/05 20:01:29
>>271
わかってないなぁ。
その「余計な処理」とか「無駄な処理」とか「理解しずらい」「システム全体を見て」
ってのは誰の視点が基準なわけ?
ここがあいまいだと話にならない。
みんな自分の視点で勝手なこといいだすから喧嘩になるんでしょう。
あなたからみた「余計な処理」と
わたしからみた「余計な処理」は当然ちがうんですよ。
ソースレビューの必要性1つとったって私とあなたで違うんです。

神の目は誰ですか?

273 :仕様書無しさん:05/01/05 21:46:50
>>270
>「やったほうがいいか悪いかなら、やったほうがいいに決まってる」
って
>ソースレビューってする意味わかんね。
へのレスとしては十分かと思うけど。

で、長いことプログラマやってる>>270の知ってる通り、ソースの良し悪しって
>長いこと正しいとされる動作で動いてくれるAPIにはやっぱり安心感があるよ。
っていうのも一つの基準だよね。長いこと動いてるAPIを修正するのはかなりハイリスク。
だけど全員が同じ認識を持ってるとは限らない訳で。こういう時ベストの選択するために、
ソースレビューのコストを割くという選択があっても良いかと思うわけです。

今思ったけどレビューでぶつかるのはレビューの意義に対する説明不足なのかも。

274 :仕様書無しさん:05/01/05 22:09:17
>>272
おれが神の目だ、てなイタイ人多いよね。
そーゆ人って、ダメな点を指摘しちゃうと、顔真っ赤にして、次の日から来なく
なっちゃったりするから、扱いには細心の注意が必要ですよ。
でも、おもしろいから、時々やっちゃいます。

275 :仕様書無しさん:05/01/05 23:36:27
このスレに居る人は全員神の目を持っているみたいですね。

276 :仕様書無しさん:05/01/05 23:50:51
管理者(PM)にはプログラマから何年目でなれますか?
現在プログラマ暦2年です。

277 :仕様書無しさん:05/01/05 23:51:41
>>276
年功序列じゃないこの業界では無意味な質問だな。

278 :仕様書無しさん:05/01/05 23:52:24
君のなりたいと思った気持ちが心からあふれたら







ハァ?

279 :仕様書無しさん:05/01/05 23:56:52
では、どうすれば良いのでしょうか?
プロマネの資格を取得すれば良いのですか?

280 :仕様書無しさん:05/01/06 00:03:10
>>272

神の目でなくてもいいのでは?

コーディング規則通りに作ってないとか、例外処理を
一切入れてないとか。
あとで蓋をあけて残された人達が困るよりは、なるべく
統一したコードを残したほうがいいと思うんだけどね。

というか。
なんで、喧嘩になるほどコーディングに拘ってる
のかわけわからん。

281 :仕様書無しさん:05/01/06 00:16:45
>>279
君のなりたいプロマネって何かね。

282 :仕様書無しさん:05/01/06 00:17:58
>>279
デスマスレで同じ質問してるの君か?

283 :仕様書無しさん:05/01/06 00:24:32
正直このスレでそんな事を質問するようではPMは無理ポ

284 :仕様書無しさん:05/01/06 00:25:12
>>282
違います。
プログラマとしての労働に危機を感じている新人です。

285 :仕様書無しさん:05/01/06 00:37:49
>>284
あれ?さっき2年目って書いたじゃん。
偽装派遣癖か?

286 :仕様書無しさん:05/01/06 01:00:57
>>285
2年目=まだ新人
ってことで。
個人的な感想。

287 :仕様書無しさん:05/01/06 01:15:21
>>284
ある程度経験したプログラマはみんな君のように危機を感じている。
そこでプログラム以外に何か得意技をみつけていくわけだ。
それは顧客との折衝であったり、DBのスペシャリストであったり、
アーキテクトであったり、英語であったり、いろいろだけど。
そしてさまざまなプロジェクトの失敗を乗り越えて、
やる気が残っている人はようやくプロマネになれる
と思う。

288 :仕様書無しさん:05/01/06 15:35:30
PMってバカに対する許容量が高いか、もしくは自分がバカか
どっちかじゃなきゃ出来ないな。あと体力な。それとPMって
かっこいいっていう妄想な。これ重要だわな。


289 :仕様書無しさん:05/01/06 19:33:56
つか、プログラミングが得意なほど、PMやSEにはなりにくいけどねw

むしろ、下手糞で、営業スキルに秀でている方がなりやすいと言える。

としか思えん。今までに結構な数のSEやPMを見てるけど、プログラムが好きという奴に会ったこと無いぞ。


290 :仕様書無しさん:05/01/06 22:39:57
コードレビューやってる所って、後でバグや仕様変更でコードを修正した時も、また
レビューやるのかなあ。
暇なプロジェクトなんだろうなあ。

それに、コードレビューまでやってバグが出たりしたら、どう言い訳をするのだろう。
聞いてみたいなあ。

291 :仕様書無しさん:05/01/06 22:51:39
PMって、だいたい2〜6名くらいのPGの管理がメインで、後はお客さんと打ち合わせしたり、
契約したりといった業務する人で場合によっては営業専門の人も上につく場合もあるって
思うんだけど、
これは下請け派遣専門会社(子会社に多い)とか下請け管理専門会社(大手に多い)で
認識は人それぞれだろうねえ。
上記をPMとするなら、プログラム好きじゃなくちゃできないと思うけど。

292 :仕様書無しさん:05/01/06 22:56:00
>>289
おれおれ。最近PMばっかりで仕事としてのプログラミングは殆ど無くなったけど、
一番楽しくて一番得意なのは今でもプログラミングだよ。

分かれ道があったとすれば、技術的にベストな物を作りたいという欲求が、
顧客にとってベストな物を作りたいという欲求に置き換わった事かも。

前者の価値観を身を削ってでも大事にしたいと思ってるような人だと、
山の頂を前に下山するようなプロジェクトばっかりで気が狂うんじゃないかな。

293 :仕様書無しさん:05/01/06 23:13:09
>>290
やる必要があると判断したプロジェクトなら、例外無く全てやるよ。
ちなみにレビューって言っても形式張るのが目的じゃないから、
簡単な修正で良い事が分かっていれば開発者のPC見て10秒くらいで終わる事もあるし、
逆に15分以上掛かるようなレビューなんて開発初期にポツポツあるくらい。
例外として、低スキル者を教育目的でバシバシ叩く事はあるかな。

>暇なプロジェクトなんだろうなあ。
レビューしない暇が無いからやるんだよ。

>コードレビューまでやってバグが出たりしたら、どう言い訳をするのだろう。
バグって悪じゃなくて、当然の開発過程でしょ?何で言い訳が必要なの?

294 :仕様書無しさん:05/01/06 23:55:16
>>290
って、お前マジでいってんの?

下の奴がいるんだったら、コードレビューは当たり前。
(レベルにもよるが)
コードレビューでバグが潰れるんだから、やるのは
当たり前。

いまだに、バグ=悪だと思っている馬鹿がいるんだね。
普通、1kあたりにバグが?件というのが基準にあって、
その基準を守れたかによって、品質が保たれるのが常識。
(無さ杉は、バグがまだ埋っていると思われる)

PGはカワイソウダネ、こんなことも知らないなんて。

295 :仕様書無しさん:05/01/07 00:02:05
>>293
つーか、コードレビューっていちいちソースコードおっかけてってみるの?
とりあえず俺のいるプロジェクトがここ3ヶ月間で組んだ1人当りのプログラムの
行数5000行(納期3ヶ月(ありえないw)の超ハイスピードモードw)ぐらいなんだけど
こんなのもみんなでながめてくの?w

296 :仕様書無しさん:05/01/07 00:04:53
まてまてまて3ヶ月で5Kって全然多く無いぞ。

297 :仕様書無しさん:05/01/07 00:10:49
>>293
俺も、客や上司に向かって
>バグって悪じゃなくて、当然の開発過程でしょ?
て言ってみたいよ。

…脳内プロジェクトか?

298 :仕様書無しさん:05/01/07 00:13:12
>>296
1人あたりの平均だと多分ありえないかな?
おそらくはじめの1ヶ月で80%ぐらい組み上げるとみると
納期まで3ヶ月で1人5kは多い。と、みるけど。

299 :仕様書無しさん:05/01/07 00:14:55
>>295
へー。言語何かは知らんけど、超ハイスピードで組んでるようなコードなら、
俺入れてコードレビューし続けてれば3000行割ったんじゃないかなぁ。
もちろん普通スピードモードで。

300 :仕様書無しさん:05/01/07 00:18:35
そもそも行数の多さで規模を表すのは間違ってるけどな。
高スキル者は複雑な仕様を「なんだこんなもんか」ってくらい簡単に書くし。
低スキル者はシンプルなコード書けないから当然行数増える。

301 :仕様書無しさん:05/01/07 00:19:08
>>299
仕様変更無しならそうかもね。

302 :仕様書無しさん:05/01/07 00:19:14
>>297
お客に言うのは馬鹿だな。情死はその人の人柄と関係によりけり。

バグを悪と思っている奴は、十中八九無責任な奴が多く、管理能力が無く、
無駄な作業が多く、その癖に定型作業を嫌う。






303 :仕様書無しさん:05/01/07 00:22:36
で、1人5000行のソースのコードレビューを
全員分(仮に5人ぐらいだと)するとどれくらいかかるの?

304 :仕様書無しさん:05/01/07 00:25:50
>>295
納品後のバグはありませんか?
開発・運用コストは計画通りに収まっていますか?

305 :仕様書無しさん:05/01/07 00:30:07
>>303
円滑に納品可能なくらいの時間がかかるよ。

306 :仕様書無しさん:05/01/07 00:33:09
おおい、バグって客に隠したり言い訳したりするもんなのか?
テスト期間中普通に出て普通に減って必要なら件数報告して、
何もやましい事なんて無いと思うけど、お前等の客はそれを咎めるの?

307 :仕様書無しさん:05/01/07 00:35:15
>>300

そっか?
下手に凝って行数減らすよりも、シンプルで一直線な
コーディングのほうが僕は好きだなぁ。
保守性高くなるし。

私の口癖は、中学生にもわかるコーディングにしろ。だし。


308 :仕様書無しさん:05/01/07 00:38:41
>>301
コード品質に関するコミュニケーション無しに進めたプログラムが
仕様変更に強いとは到底思えないんだけど何か秘策があるの?

309 :仕様書無しさん:05/01/07 00:40:03
>>307
「なんだこんなもんか」っていうのは中学生でも分かるコーディングって事だよ。

310 :仕様書無しさん:05/01/07 00:45:31
>>308
ん?
変更するんじゃなくて該当箇所をまるまる切り捨てるの。

311 :仕様書無しさん:05/01/07 00:47:03
>>307
凝っていないから短いのだ。

312 :仕様書無しさん:05/01/07 00:51:28
>>310
ああなるほど。
5000行の中には使ってないコードが山とあるわけだ。納得。

313 :仕様書無しさん:05/01/07 01:05:09
>>312
いや、使ってないコードは仕様変更といっしょにとにかく捨てちゃうから
5000行ってのは残ったコード。
3ヶ月の延べ行数は5000行以上になる。

314 :仕様書無しさん:05/01/07 04:39:34
コードレビューって、確かに品質は確保されるが、効率悪いよね。
どういった見積もりをだしてるのかな?

うちは、バグトレースを集計してみた結果、テストの自動化に力を入れたほうが
おいしいって結果がでちゃったため、ほぼ、工数はとれないんだな。
もし、やるなら、なんらかの優位性を示さなくてはならないんだが
・後工程でも取れないバグの発見(とっても少ない)
・後工程で取れるバグの発見(早期のバグ検出)
この2点に、そんだけの魅力はないのかなって思うんだが。

315 :仕様書無しさん:05/01/07 09:42:01
未だにステップ数当りのバグ数で品質測ってる文化圏があるんだ。
納品書面上に残ってるのはあるけど、あんなの偽造するのみ。

大体、本当に仕事が速くて優秀な奴がやると、この測り方じゃ品質悪いことになるんだよね。w
バグがないーって。w


316 :仕様書無しさん:05/01/07 21:04:28
PMな人たちの観点だとコードレビューって結構評判わるいみたいね。
プログラマーな俺としては、是非ともコードレビューは開発工程に取り入れてほしいと思っている。
バグの発見っていうメリットもなくはないけど、どっちかっていうとそれ以外の副次的な
メリットを感じたことの方が多いように思う。
・他人のコードを見ることで、自分が思いつきもしなかったような良いやり方を学ぶことができる。
・コードをネタにして色々な話をすることで、考え方に幅ができる。
・レビュアーに説明しやすいように、意図が明確になるようなコードを書くことを心がけるようになる。
などなどね。PMな方々には、数字だけみないでそういうトコも意識してもらえると
うれしいな、などと思っております。


317 :仕様書無しさん:05/01/07 21:09:03
>>316
やだよ。
だってその分、納期が延びるわけじゃねぇんだろ。
あきらかに無駄なことじゃん。
ぜってぇはやんねぇ。
だいたいしょっぱなの納期さえ守れば後から来るクレームや仕変になんて
期限ないし適当に対応してりゃなんとかなるし。
レビューなんてやるよか、動かしてみりゃ一目瞭然なんだよ。
動かして見るまで誰にもバグはバグと認識できゃしねぇ。
客にとっても俺等にとっても都合がいいんだよ。

318 :仕様書無しさん:05/01/07 21:30:00
>>317
納期がものすごく厳しい状況でコードレビューをやれ、なんて風には俺も思ってないよ。
妥当な期限と人数で、比較的落ち着いたプロジェクトなら、コードレビューの工程を
いれることにはメリットが大きいと思っているだけ。
というか、そういう状況を作り出すのがPMの仕事と違うの?って気もするけど。

319 :仕様書無しさん:05/01/07 21:34:49
>>318
>妥当な期限と人数で、比較的落ち着いたプロジェクトなら
なら、誰もバグなんてださねぇよw

320 :仕様書無しさん:05/01/07 21:41:17
>>319
バグの数だけが品質じゃないでしょ。
動けばいいってだけじゃなくて、それ以外のものを求めてくるお客さんだって
いっぱいいるわけで。



321 :仕様書無しさん:05/01/07 21:43:20
>>320
初耳。
それ以外のものってなぁに?

322 :仕様書無しさん:05/01/07 21:51:16
>>321
保守性とか、パフォーマンスとか。ほんとに言われたことないの?
君らがいなくなった後でも保守ができるように、わかりやすいコードに
しといてくれ、って言われることよくあるよ。


323 :仕様書無しさん:05/01/07 21:54:21
>>322
ない。
マジレスだけど。
そんなことは一度として無かった。
保守性やパフォーマンスなんて求められたこと無いよ。

324 :仕様書無しさん:05/01/07 21:54:30
>>318は正しいと思う。
ただ、プロジェクトリーダーよりは組織管理者の仕事かもね。

325 :仕様書無しさん:05/01/07 21:58:17
>>323
ああ、そうなんだ。
短期間で動くものを納品することが至上命題のプロジェクトばっかりってことね。
それじゃ意見が食い違うわけだな。

326 :仕様書無しさん:05/01/07 22:18:15
>>325
ゲ会社だったときもあったけどそんときの開発期間は
1年〜2年ぐらいだったけど年中暇無し休み無し。
バグ無し、設計ミス無しのフルスピードで組んでも
何故か間に合わない過酷過ぎる環境。(最近のゲームってバグ少ないでしょ?評価してよw)
レビューなんか当然無理。

業務系に移ってからは3ヶ月とか半年の仕事がまわってくるけど
レビューやるほどに暇はない。

ってこんな感じだけど。

327 :仕様書無しさん:05/01/07 22:28:33
オレもコードレビューなんてやったことない。
しかも2週間で5000行くらいが普通かと思ってた。

328 :仕様書無しさん:05/01/07 22:32:32
>>326
1、2年の間年中暇無し休み無か。
しかも過酷なゲ系より比較的易しい業務系に移っても暇無しって・・・
管理面では完全に失敗して来てるんだよね?

何も疑問に思わないの?なぜ遅れるか考えた事無いのか?
何故もっと良いやり方を模索しようとしない?

329 :仕様書無しさん:05/01/07 22:33:31
行自慢する奴は多分品質の意味を理解してない。

330 :仕様書無しさん:05/01/07 22:38:59
>>326
なるほど、ゲームとかだとそんな気がする。
俺がいままでやったのはほとんど金融機関向けシステムで、
お客はとても長い期間そのシステムを使い続けるんだそうだ。
期間が長いとどんどん後の変更でプログラムがスパゲッティになって、
保守のコストが積もり積もっていくので、
(わけのわからんコードでいやと言うほど痛い目にあっているらしい)
開発スタイルはじっくり、堅実にって感じ。


331 :仕様書無しさん:05/01/07 22:40:48
コードレビューしない暇があるなんて羨ましいな。

332 :仕様書無しさん:05/01/07 22:45:31
その分野に実績のある会社に納期で負けないために無茶をして仕事取ってる弱小会社は、
遅れるとか遅れないじゃなくて、プロジェクト発足時点からヤバイんですよ。

333 :仕様書無しさん:05/01/07 22:49:44
>>332
ああ、それは言えてる。
なんせ、ノウハウもねえのに、あるって嘘付いてやらせるから、全てにおいて見様見真似だし、
一度トラブルと、まず間違いなくデスマになるし、客のシステムはダウンする。


334 :仕様書無しさん:05/01/07 23:05:15
PMな人達がレビューが必要ないなんて言うかな?
経験不足なPGとか、PG経験ないPMとかだと言いそうだけど

335 :仕様書無しさん:05/01/07 23:07:14
>>332
開発はじまった時点で納期一ヶ月過ぎってあったw
仕様決めるのに客と揉めたらしいw

336 :仕様書無しさん:05/01/07 23:12:48
>>334
昨年、一緒に仕事してたPMが、いらねえと言ってたぞ。
年末にトラブって、今年からはマジメにやることにしたらしいがの。


337 :仕様書無しさん:05/01/07 23:20:18
だいたいレビューやったからってうまくいく根拠がねぇよ。
誰のナニを期待してレビューやるのさ。
まさか、「おれにみせりゃ安心だろうが!」とはいいださないよねw

338 :仕様書無しさん:05/01/07 23:23:38
他人が見ないと思って例外処理を全くしないコードを書いたり、
イースターエッグを勝手に仕込んだりされないためにやる。

339 :仕様書無しさん:05/01/07 23:25:22
あなたのプロジェクトの最もスキルの低い人のコードについてどう思われますか?

340 :仕様書無しさん:05/01/07 23:29:36
レビューいらないって言ってる奴はプロジェクト失敗してるんだろ?
初めから駄目?誰が決めたの?自分で計画立てた上で正確に判断出来てるの?
何故人のせいにする?何故自分を疑わない?

何故レビューの意義について考えない?

341 :仕様書無しさん:05/01/07 23:30:19
>>315
ステップ数当りのバグ数やバグの収束性以外に、定量的な数値を出せてるのか疑問だ。
何をもって品質が良いと判断してる?

分からないから、誤魔化してるだけなのか、それとも、自分では優秀と思っていたのに、
数値であなたはダメダメですと真実を突きつけられて悔しかったのか。
優秀な人は、きちんと数値に反映されるよ。

342 :仕様書無しさん:05/01/07 23:40:12
少なくともレビューが全くいらない、っていうのはあり得ないな。
コードレビューが必須かどうかっていうのは微妙なところだが。
仕様のレビュー:必須、設計レビュー:重要なところはやる
テストケースレビュー:必須、コードレビュー:時間があれば・・・
ってところか。


343 :仕様書無しさん:05/01/07 23:46:13
>>342
その微妙なコードレビューの話だったと思うぞ

344 :仕様書無しさん:05/01/07 23:52:53
ステップ数以外の規模見積もりって沢山あるよね。
あとバグなんて最終的に全部回収するのが前提だし、
バグの出方は事前のチェックやテストのやり方、
集計方法によっても全く変わってくるから、
使えるとすればプロジェクトに閉じた進捗管理くらいだね。

品質について唯一の基準があるとすれば、
全体として計画をどれだけ上回ったかだな。
コストとか性能とかユーザビリティとか。客が大満足とか。

345 :仕様書無しさん:05/01/07 23:53:23
>>342
>少なくともレビューが全くいらない、っていうのはあり得ないな。
>コードレビューが必須かどうかっていうのは微妙なところだが。
1行目と2行目は矛盾しているわけだが、
彼の身に一体何があったというのだろうか?

346 :仕様書無しさん:05/01/07 23:55:22
レビュー∋コードレビュー

347 :仕様書無しさん:05/01/07 23:57:51
>>346
レビューってなにやんだ?
仕様はきまっちまってるし、バグはテスト環境整えてくれよ。
で、なにやんの?
大したことしてねぇのにおせぇよ!とかそんなん?

348 :仕様書無しさん:05/01/08 00:02:27
>>347
プログラムだけしかかかない人ならコードレビューしかないかもしれないけど、
テストケースを書いたり、仕様書を書いたりすることもあるだろう。
それぞれの成果物が問題ないかチェックするんだよ。

349 :仕様書無しさん:05/01/08 00:03:13
ただゴネたいのかリアルで理解してないのか・・・

350 :仕様書無しさん:05/01/08 00:08:24
>>348
そんなのレビューなんてやらなくても適当にみりゃわかるし
担当者いるならそいつにまかせりゃいいじゃん。
仕様は決まってんだから。

351 :仕様書無しさん:05/01/08 00:10:58
仕様は決まってるのか。なら仕様書レビューどころか仕様書要らないね。

352 :仕様書無しさん:05/01/08 00:13:13
コードレビューは効率が悪いと思うオレだけど、
さすがに仕様くらいは皆で検討してくれと思うぞ。

353 :仕様書無しさん:05/01/08 00:19:39
色々な人に守られてなんとか生きてる事に気づいて無い人が居るね。

354 :仕様書無しさん:05/01/08 00:21:56
>>350
釣りか?
仕様書は成果物じゃないのか?、お前んとこの職場じゃ。


355 :341:05/01/08 01:08:53
>>344
俺が言ってるのは、品質の話だぞ。
QCDは、それぞれ関連はあるとおもうけど、別物だぞ。
大丈夫か?

356 :仕様書無しさん:05/01/08 01:51:18
コードレビューは、良いことと思うけど、確かにやったところで
納品物に入らない。顧客に見えないところで品質を上げる効果はあるわけだけど
それによってバグが0件って結果になるとまたちょっとね・・・。
顧客から見ると、ソースコードのボリュームとか、テスト行ったときのバグの発生件数とか
の方が絶対基準になるし、評価対象に入ってしまう・・・。
以前、単体テスト仕様書も単体テスト結果も納品するようなプロジェクトやったけど
当時、ソースレビューでバグをつぶして、テストしてバグが実際は1件も出なかった
のに わざとバグを出したように見せかけて、修正したみたいな結果に偽装したこと
あった・・・。
ソースレビューは効果的だけど、時間に余裕が無いプロジェクトだと、
現状ではたしかにちょっとキツい場合が多いと思う。

357 :仕様書無しさん:05/01/08 03:20:58
私もね。
コードレビューがまったく不要とは言わないけど現実的にはやらないね。
新人のコードなら見ることもあるかもしれないけど
保守性が高いコードとか、美しいコードとか、
PMの立場からいうと重要性はあまり高くない。
(繰り返すが、やる意味がまったくないとは言わない)

どちらかというと、仕様書のレビューはもちろんのこと、
テストケースがどの程度洗い出されているかの方が重要と思う。
例外処理のテストケースが含まれていなければ、それを
テストするように指示するのは必要でしょ。
例外処理を10ステップで書こうが1000ステップで書こうが
仕様が満たされていればいいかな。
もちろん、10ステップで実現可能な処理を1000ステップで書こうと
する人は、その分コストはかかるわけだから、なぜその処理に時間が
そこまでかかるのか、という意味でコードレビューに至ることは
あるかもしれないけどね。


358 :仕様書無しさん:05/01/08 09:44:59
おいおい、企業がPMと位置付けてもらった位でPMを語らんで暮れ。
PMを目指している人へコードレビューが不要と言う人はPMじゃ無いから。

まず設計書ベース・レビューで済むと言う人は、設計工程と実装工程で決断・対処すべき事の違いが判っていない。
もし逆に違いがないなら工程別の成果物に意味の重複性が存在している筈だ。
その見分けが出来ない人間がPMな訳無いだろ。

次に、管理の基本として語られるPlan-Do-Seeサイクルは全てが揃って事を成す。
つまりプログラム構造を無視して変更性や品質を語るのは 検証意義としても片手落ちだ。
こう言う奴に限ってバグ0に意義を見出そうとして、
検証の費用対効果を考えずに、お客に検証の費用対効果を説明出来無い為、
効果的なプロジェクト運営が出来ずズタズタになる。

コードレビューが不要と言う人は、PM技能のある人では無く、名刺にPMと付けられた人だ。


359 :仕様書無しさん:05/01/08 09:50:50
>>358
理屈は良いから、ちゃんとプロジェクト完了させろや。


360 :仕様書無しさん:05/01/08 13:30:21
>>359
は?非難の文書がどこの文書を見て言ってんのか不明だが?
図星だったか?ゴメン、ゴメン気にするな。
ボケはボケなりに飯が食える業界だ。恥を知らずに生きてけ寄生オヤジ




361 :仕様書無しさん:05/01/08 13:54:49
>>358
こういう現状がまったく見えていないPMってどうして減らないんだろうね。
プロジェクト全体で残業しまくりなのにコードレビューもくそもねぇだろ。
スケジュール表からみなおせ馬鹿。
すでに駄目なんだよ、そんなプロジェクト。
さっさと帰らせてくれよ。

362 :仕様書無しさん:05/01/08 15:14:50
コードレビューは品質もさることながら
教育としての意義が大きいと思う

あれ?コードレビュー不必要と言ってる人達って
要員の教育とか全く考慮してない?
だめだよ、近視眼的なものの見方してちゃ
だからいつもプロジェクト失敗しちゃうんだよ(w

363 :仕様書無しさん:05/01/08 16:17:54
>>362
>要員の教育とか全く考慮してない?
どうせすぐ辞めるし、会社もそのつもりだからこれ以上の脱力感は無いと思うぞ。

364 :仕様書無しさん:05/01/08 17:30:24
>>358
工数(お金)を管理しないPMっているんだ。
品質よければ、時間やお金は気にしないプロジェクトってあるのかな。
PMならば、コストと納期も考えろと、会社から言われるはずだが。

まあ、PGが品質を追求することは悪くない。
それよりか、褒めてあげるべき事柄だからな。
分からなくても、OKですよ。
コストや納期を考えて、品質に一線を引いて苦しむのがPMの仕事ですから。

365 :仕様書無しさん:05/01/08 17:56:07
>>362
あれ?362ってスレの流れとか全く考慮してない?
だめだよ、ちょいと前に教育ぐらいしかコードレビューはしないって
書いてあったのに。
だからいつも恥ずかしい書き込みしちゃうんだよ(w

366 :358:05/01/08 22:14:44
世にはPM本だけ読んで自己都合で管理で語る人が増えましたね。

Prjの定義は出来ていますか?

納期ってなんですか?何によって決まるんですか?Prj中に納期の規定は一つしかないの?
それを過ぎるとどうなるの?Prjは強制終了するの?

馬鹿ですね。

品質ってなんですか?どうやって定義するんですか?Prj進捗中に品質定義は変わらないの?
品質が定義以下の場合どおなるんですか?

馬鹿ですね。

費用ってなんですか?誰からみた費用ですか?どうやって予算が決まるんですか?
費用って金の事ですよね、その金の算出方式は理解していますか?
まさか会計思想だけの費用算出だけで考えて無いですよね?
費用が予算を超えたらどうなるんですか?

馬鹿ですね。

3大要素は要素であって全てでは無いよ。

馬鹿ですね。

PMを依頼主の云う事を満たしてくれる魔法と勘違いしている様ですね。
そりゃ、話にならんは。現状じゃ無く現実を見てくれ。


367 :仕様書無しさん:05/01/08 22:23:05
>>366
で?(何がいいたいのかわかんねぇよ)

368 :仕様書無しさん:05/01/08 22:24:32
>>366
釣りか?
ここで釣ったって釣り人がバカだと思われてお終いなんだけど?


369 :358:05/01/08 22:25:26
>>367
ちっ!これ↓をみろ!
http://sylphys.ddo.jp/upld2nd/niji7/src/1105190051262.gif

370 :仕様書無しさん:05/01/08 22:28:33
>>369
グロを貼るな、ヴォケが!

371 :仕様書無しさん:05/01/08 22:30:57
>>369
グロ注意!(生首が転がる動画)

372 :358:05/01/08 23:41:08
>>367,368
学生が多いな、しゃ〜ない実務経験が無いもんな。お兄さんが教えてやるよ。

ソースレビューをしないとするのは問題ではないが、不要と云うのは問題。

期間と費用対効果、そして管理状態、人材評価を加味してソースレビューをしないと決断する事は良い事。

決断意識も無く、自分の正当性の為にソースレビューが不要といっているのは管理がわかっていない。

一からソースを書き上げるプロジェクトにてソースレビューが不要といえるのか?

もし既存コードを多用してソースレビューが不要と見なしたなら、「既存コードの多用」を理由としてソースレビューが不要と決断した。という意識が大切だ。

上記の決断意識が無い場合は管理をしたので無く、管理定義に従って動いているだけと云う事だ。

管理を知らない、管理をする気もない、管理が出来ない、そんな奴らがPMを語っている事に注意しろよ。


373 :仕様書無しさん:05/01/09 01:35:11
コードレビューは後工程のコストを劇的に減少させるよ。
残業しまくりな人は一度試してみると良いよ。

374 :仕様書無しさん:05/01/09 01:47:48
>>373
減少しないよ。
だいたいバグでそんなに苦労したことないし。
仕様変更が多すぎることの方が問題。

375 :仕様書無しさん:05/01/09 01:51:26
>>374
仕様変更のコストも劇的に減少するよ。
残業しまくりな人は一度試してみると良いよ。

376 :仕様書無しさん:05/01/09 02:05:07
>>375
仕様変更なんかしたらどの道残業するのは変わらないじゃん。
この時点でコストなんてもうどうでもいいよ。
あとはどんだけ遅れようと誰も文句言わないもん。

377 :仕様書無しさん:05/01/09 02:07:14
もう仕様変更がきた時点で主旨がかわっちゃうんだよね。
できたものがどうとかってより、残業をどのくらいやったかって
評価されるから製品の質なんてどうでもいいよ。

378 :仕様書無しさん:05/01/09 02:08:07
なんかレビュー云々以前に、普通にリスク管理が出来てない奴が居るな。

379 :仕様書無しさん:05/01/09 02:12:43
はっきりいってコードレビュー薦めてる奴の行動は
現在の作業にさらにコードレビューという名の作業を上乗せしてるだけ。
これでレビューで出た意見とそれに対しての結果とかをレポートで出せとかいわれたら最悪。
もうやる気無くす。
コードレビューを作業に追加したいなら現在やってる作業の何かを消してから追加しろ。
何が消せるんだ。

380 :仕様書無しさん:05/01/09 02:33:56
>>379
個人的な思い込みを全面に押し出すな。レポートなんて誰も書いてない。
作業の上乗せについては、>>293で書いたように数%の時間だけだ。
これにより後工程のリスクが激減する。
各テスト、仕変、パフォチュー、システム障害・・・、
例外無く数〜十割のコストが削減出来る。

こういうトレードオフを普通に検討してるだけ。

381 :仕様書無しさん:05/01/09 02:49:46
>>380
具体的に頼むよ。
どのくらいの実力持った奴が、どの程度、誰にレビューをすれば何のコストがどう削減されるの?

ここまで言えなきゃコードレビューなんてする意味ないでしょ?
とりあえずやればよくなるんじゃないかなーなんてちょっと考えただけの冬厨決定。

そもそもリスクリスクって俺はバグなんてほとんど出さないし、設計ミスもしないし。
プロジェクト開始から終わりまでひたすら組み続けてまだ間に合わないぐらいの
プロジェクトばっかりだぞ。

382 :仕様書無しさん:05/01/09 05:48:07
>>381
293の状況って事だから、仕様を把握した人間(PM自身?)が、一人で、ぱっと見るんだよ。
俺たちが想像しているものより、もっと適当なもだと思うよ。
だから、具体的な基準やその効果を求めてはだめです。

あと、380は脳内だと思うがな。

383 :仕様書無しさん:05/01/09 06:59:57
>>372
期間と費用対効果、そして管理状態、人材評価を加味した結果、一からソースを書き上げる
プロジェクトでソースレビューが不要ってなること多いと思うがな。

レビューは人に頼るところが大きいため、基準があいまいで質がぶれる。
コードレビューのバグって、単体テスト・結合テストで十分回収できる。
と思うのだが、お兄さんのプロジェクトでは、そうでないの?

384 :仕様書無しさん:05/01/09 10:04:46
>>383
>単体テスト・結合テスト

も十二分に人に頼る所が大きいと思うのですが

>単体テスト

レベルならそれこそ質がぶれると思うんだけど。
テストマンセー主義らしいけど、簡単な業務プログラムならもしかしたら
通用するかもしれないね。
でも、ちょっとしたシステムになると、とある人の作成した部分で
問題が発生。で、後に残った人達で作りなおしと。
そういうことができるプロジェクトっていいですね。

あっ。テスト万能主義だから問題ないんですね。
例外もテスト汁!って言って、その人達はしっかりと全てのケース
をテストしてくれるんですから。
羨ましいですね。
うちなんかほっておくと、結合テストレベルで機能の漏れが
発生したり、動いてもメモリーリークしまくりで1日も連続
稼動できない状態になっちゃうなぁ。

あと、PMならば当然しってると思うけど、工程(フェーズ)が
後になればなるほど是正のコストがかかるんだけど。
この辺りはどう思ってるのかなぁ。
サンプルでチェックして横展開させてほうが、テスト段階になって
また作り直しってことにならないと思うんだけどなぁ〜
きっと違う世界の人なのですね羨ましい。

385 :384:05/01/09 10:07:53
(続き)
ちなみに言っておくけど、コーディングのサンプルチェックでバグが
全てなくなるとは言ってないよ。テストでバグが全てなくならないのと
思じで。
それこそ、顧客とシステムが求める品質レベルがどのぐらい
なのかを開発計画のフェーズでしっかり定義するもんだと思うんだけどな。
なんでこんな極論になっちゃうのかな。不思議。

>>381
>そもそもリスクリスクって俺はバグなんてほとんど出さないし、設計ミスもしないし。

他の人も出さないんですね。
凄いプロジェクトですねぇ〜 羨ましい。

もしかして一人プロジェクトでもPMって名前になるのか?
Personal Manager
とか・・・



386 :仕様書無しさん:05/01/09 10:10:38
バグも設計ミスも無しでデスマって何が原因なんだろうね。

387 :仕様書無しさん:05/01/09 10:13:25
>>384
例外も含めてテストって、PMが指示しないと誰もやらんの?

レビューが不要とは思わんが、PMが言わなきゃやらんメンバーも
問題だらけですなぁ。

アンタんとこの場合、レビュー以前にメンバーの質が低過ぎないか?


388 :仕様書無しさん:05/01/09 10:16:27
>>387
プロジェクトメンバーは何人ですか?
その中で最もスキルの低い人のコードをどう思いますか?

389 :仕様書無しさん:05/01/09 10:17:20
>>386
単純に仕様の詰めが甘いんでしょ?

実際問題、バグ無し、仕様通りの設計なのに、SEやPMが仕様の一部を
握りつぶしてて、下流に流してなかったっていう最悪のミスのせいで、
納期直前で徹夜続きになりましたぜ。
(もちろん、PG連中が聞き逃してたことにされたが。上流の連中が、
ミスを認めるわけも無いし。)

バグでも無けりゃ設計ミスでもないんだったら、もっと上流のミスの
可能性が高いと思うね。


390 :仕様書無しさん:05/01/09 10:20:15
>>386
はじめから最後までひたすら仕様を満たすために
プログラムを組みつづけるのだがそれでも終わらない。

391 :仕様書無しさん:05/01/09 10:21:18
>>388
オレを攻撃するのは間違ってるよ。オレ、レビューは必要と思ってるしさ。

まぁ、バグがそれでゼロになるとは思ってねえが、リスクを軽減する効果は
あるしね。品質の問題もあるが、それ以前に何らかのミスで障害多発なんて
時に、レビュー無しでは、開発体制そのものが疑われる羽目になりかねんのよ。

でも、レビューしてもらえるからといって、メンバーが手を抜くような体制
はレビュー以前に、もっとやるべきことが多くねえか?と思いますな。


392 :仕様書無しさん:05/01/09 10:26:14
>>391
やる気でバグが潰れたら苦労しないよ。
例えば全ての例外を洗い出してテスト対象を的確に取捨選択出来る人が何割居るか。
半分居たら御の字だと思うのはやっぱりメンバーに恵まれてないからですか?

393 :仕様書無しさん:05/01/09 10:31:23
>>389
PMじゃない人ですか?
なんか可愛そうなプロジェクトですね。
それであなたのPMやSEはどうすれば良いと思いますか?

394 :仕様書無しさん:05/01/09 10:36:54
>>392
やる気でどうにかなるわけないじゃん。

別に気合でどうにかしろだなんて書いてないし、そんなつもりもない。
精神論でどうにかなるんだったら、管理いらねえ(笑)

ただなぁ、「例外も洗い出してやんな」なんてのは、やる気以前に
基本じゃないの?、それすら思いつかない連中って何?という気が。

ま、半分も居ればマシなんでない?

ついでに言うと、オレ、レビュー要らないなんて書いてねーから。

教えることをちゃんとやってないのに、メンバーの質が低いと嘆くの
は、常日頃のPMの手抜きのせいだろと思ってるだけッスよ。


395 :仕様書無しさん:05/01/09 10:39:32
だから教育目的とも書いてるわけで。

396 :仕様書無しさん:05/01/09 10:40:10
>>393
別に。それにオレ、SE、PG兼任だし。

ま、上流、下流の関係を人間性の上下や立場の上下と混同してるアホ
が多いだけと思っているよ。

握りつぶしなんてのは、上流のミスだし、知ったことじゃない。
オレがその立場なら素直に詫びますがネ。少なくとも、先に帰る事は
ねーよ。手抜かれたら怖いもんね。


397 :仕様書無しさん:05/01/09 10:45:12
特定のプロジェクトの特定人物に対する愚痴としか読めない

398 :仕様書無しさん:05/01/09 12:12:28
>>387
2CHだからね

399 :仕様書無しさん:05/01/09 12:17:00
>>398
さすが、ネット界の掃溜

400 :仕様書無しさん:05/01/09 12:18:41
>>393,396
要件定義や外部設計で、詰めが甘いとか矛盾があるのは常識。
下流担当者なら、愚痴らず前向きに、それをどう対応するかがプロだろう。

まずは問題・課題の一覧を作り、欠陥発生局面(外部設計とか)を明確化する。
客観的資料が無いと「設計が悪い」「PGのせいだ」の水掛け論で終わるし、
最初の設計より、現実に沿った妥当な形で解決できる事も多い。

必要ならマネージャやユーザーとも協議しながら、
代案、暫定対応、恒久対応などを次々打ち出して行く、てのが普通だろう。

それができる立場にないとか、うちの会社じゃできない、て話なら、
それは気の毒だと同情するけど、愚痴の領域になっちゃうね。



401 :仕様書無しさん:05/01/09 12:23:39
>>400
つか、外部設計はPGの領分なんで、文句は言わんよ。
ただ、要件定義はアンタらの領分だろ?と思うだけ。

設計変更が必要ならもちろん、上には言うが、上がミスってて、
下に流れてこないのは、どうしようもないんだよね。

上流過程の客ってのは、ユーザー以外にもPGもそうだという
認識はもって欲しいですな。


402 :仕様書無しさん:05/01/09 12:30:43
コードレビューなんかいらないよ君の反論まだぁ〜〜

403 :仕様書無しさん:05/01/09 12:33:29
>>402
反論も何も肯定側になんの意見もでてないじゃん。

404 :仕様書無しさん:05/01/09 12:35:30
>>401
んん?

「外部設計」の示す範囲は、会社やプロジェクトによって違うが、
普通はPGではなくユーザーやシステム部の領分でないか?
画面や帳票やDBに格納するデータ項目(論理)を決めるのも外部でしょ。

内部(クラス分けとかINDEXとか)は、SE/PGレベルでいいと思うが。

405 :仕様書無しさん:05/01/09 12:38:52
>>402,403
まともな欠陥除去工程論では、単体・結合・システムなどの各局面テストに加え、
少なくともサンプリング的なソースレビューを早期に行うことは常識。

実際、大きな勘違いで量産してる事が多いし。

406 :仕様書無しさん:05/01/09 12:43:13
>>404
随分、楽なとこで仕事してんのね。

ほんとに中身の設計だけでいいなんて、コーダーでも済むじゃん


407 :仕様書無しさん:05/01/09 12:45:05
そもそも領分とか言ってる時点でズレまくってるよ。
もっと皆で協力しようよ。

408 :仕様書無しさん:05/01/09 12:46:29
>>407
それはSEやPMに言えよ。PGの場合、嫌でもSEや客に連絡とってやってんだよ。


409 :358:05/01/09 13:30:16
>>402
俺が否定派の管理無能さを晒してやったから。
そんな馬鹿はいないと思うけどな。

仕様変更の話は、確かに仕様変更によってレビュー効果が打ち消さされるが、
それは仕様変更の問題だ、問題をごっちゃにしてレビューを安易に否定するのは
管理能力が無いし、管理するつもりが無い証拠。

言わば、強盗が貧乏が悪いと言っているのと同レベルなんだよ。


ここまで言えば解ったかな。現在存在する多くのPMやユーザ代表は、
自己都合や利権の為に「管理」を歪めている。気をつけろ!


410 :仕様書無しさん:05/01/09 13:41:42
>>409
違うね。
その理論じゃレビューのためにレビューをやるといっているようなもの。
全体をみてその中でレビューにどれくらいの効果があるのかということを
示せないならなんにも意味が無いPMのオナニーといって過言でもない。
まあ、PMなんて仕事真面目にやろうとしなけりゃ仕事なんてないもんね。
たまに一生懸命プログラムいじってるPGにちょっかい出してみたい気持ちも
わかるけどはっきり言って邪魔だからほどほどにねw

411 :仕様書無しさん:05/01/09 14:05:34
>>レビューにどれくらいの効果があるのかということを
>>示せないならなんにも意味が無い

お前大丈夫か?相当墓穴掘っているぞ。
頼むから、無能な奴は高慢な態度は止めてくれ。

どれくらいの効果があるのか事前に示し保証出来ならば管理はいらない。
どれくらいの効果があるのか予想は出来るレベルだから管理がいる。
いや実際には予想出来無い事の方が多い。


コードレビューの性質を知りたいならば、コードレビューは事前確認だ。

つまり文書定義しない事、テスト行為で立証し難い事、認識合わせの早期対処である。

コードレビューの重要性が解らない人はまず、テスト技法を徹底的に勉強すると良い。
簡単に言えばテスト技法はOUTPUT出来ない事に対して検証が出来ない問題性質を持つ。
そして行為が事後確認になる問題性質も合わせ持つ。

その性質と状況の噛合わせ結果を想定し、決断を下すのだ。

PGの実務経験があるならば、性質理解だけで行動が無し得ず、効果提示が出来無い事くらいはわかるよね?


412 :仕様書無しさん:05/01/09 14:22:52
>>411
で、ずーっとコードレビューの効果とかってあいまいなままだよね?
俺はさ、効果の示せないことは必要不必要以前にするべきじゃないと思ってるんだけど。
だって、効果がよくわからないんだよ。

はじめのうちはその効能がよくわかってる人間でうまく使えてる状態や環境があるかもしれないけど。
そのうち「これってやる意味あるの?」ってなるよ。
現にここでいくらコードレビューについて「どれくらいの効果があるの?」ってきいたって
返ってくるレスは「わからない奴は駄目な奴だ」とか「そのくらいわからないの?」とか
ほんとに効果あるんだかなんだかよくわからないレスばっかりじゃん。

はっきりいって俺がクライアントだったら、この工程にお金は出せない。
説得力皆無だもん。効果もよくわかんないし。
PMだってこの作業が必要かどうかを客に説得することできんの?

413 :411:05/01/09 14:41:32
>>412
性質と状況の想定をして効能を決めるのが解らないのかな?
もし意味がわからないならば何かの技法や技術について一つ効果を論理的に提示して下さい。

そしたら貴方が言っている事に矛盾があり、その矛盾が間違いを呼び出していると気付くよ。

>PMだってこの作業が必要かどうかを客に説得することできんの?

君は管理した事ないでしょ?人は理論では動かないのだよ。
人を動かす場合、目的達成する場合に行う説明の為の理論は後付けでいいんだよ。

管理経験の無い妄想君達は反論でなく、質問で問い掛けてくれ。

414 :仕様書無しさん:05/01/09 14:45:47
>>413
>人を動かす場合、目的達成する場合に行う説明の為の理論は後付けでいいんだよ。
なんだよじゃあコードレビューも実用的かどうかってのは怪しいんだ?
役に立つかどうかじゃなくてお前がやりたいだけかよ。
まあ、そんなところだと思ったけど。
つまるところPMが仕事してるように見えるからやるんだ。
はぁ・・・アホくさ。

415 :仕様書無しさん:05/01/09 14:49:09
>>412
えっと、悪いけどさ、このスレで何を求めているの?
こんな全国区無料匿名掲示板で、雑談やヒント以上のレスを期待するなら甘すぎ。

そんな定量的に「何%の工数を投入すれば何%の欠陥が除去できる」てな
「効果」が出るわけもない。ただ、個々のプロジェクトでの実績や、
PMに関わる手法としての統計は色々ある。

曖昧だから「しない、できない」、というより、
個々に適用して効果を見て反復したり、不要なら減らしたりする工程が重要だろう。
何故なら、要件も環境も開発者も毎回違うから、簡単な法則にはならない。

スポーツでも開発でも経営でも、実は同じ。日々是実践って奴だ。

まじめに知りたければプロジェクト学会とかで山と資料があるよ。

416 :仕様書無しさん:05/01/09 14:52:34
>>406
プロジェクトやシステム規模が違うからだと思うけど、
仮にPGが内部設計だけをやれば良い場合でも、それが楽だと思うのは、
これまた世間知らずじゃないかな。

内部設計をやるには要件定義・外部設計の把握と、その行間にあるような目的、
それとシステム的な性能・拡張性・生産性・障害対策などを、
多少とも理解してないとできないんだが...

417 :仕様書無しさん:05/01/09 14:53:27
>>415
人は理論では動かないのだよ

418 :仕様書無しさん:05/01/09 14:54:19
>>416
じゃあ、仕様から即プログラムを組める俺は天才だな。

419 :仕様書無しさん:05/01/09 15:00:36
>>415
参考資料

高度情報処理技術者試験の論文集  PM−プロジェクトマネージャ−過去問題&論文例
http://ww5.tiki.ne.jp/~nmura/js/kako/pm.html

組込みソフトウェア技術者・管理者向けセミナー
http://www.sessame.jp/seminar/Seminar2004_09/Seminar2004_09_Report.htm

これらが妥当かどうか、つー話以前に、システム開発の品質向上の考え方や技法は
1つの学問になるくらいあって、それをツールとして取捨選択して適用して
試行錯誤してるのが現実だ、というところは最低限理解しよう。

そうでないと、いきなり「必要か、不要か」の極論になるだけ。

420 :仕様書無しさん:05/01/09 15:03:24
>>417
理論で動くかどうかは、その人による。
リーダーは両面でチームを率いることが求められる。

理論だけで仕事はできんが、理論が無くて上司や客など、人を説得する事は難しい。

421 :仕様書無しさん:05/01/09 15:05:47
>>412

じゃあ、あなたの大好きなテストがどれぐらい効果あるのか
定量的に示してみてください(-:

422 :仕様書無しさん:05/01/09 15:07:22
これ、読みやすいよ

ソフトウェアプロセスのトピック情報
http://www.cam.hi-ho.ne.jp/adamosute/process/processarea.htm

423 :仕様書無しさん:05/01/09 15:08:14
>>419
じゃあ、君にはこれだね。
http://www.shos.info/develop/oo/dscsnptn.html

424 :仕様書無しさん:05/01/09 15:12:00
人が理論で動かないとすれば、多分使った理論が正しく無いんだよ。

425 :仕様書無しさん:05/01/09 15:14:49
ソフトウェア開発の品質向上プロセスなら、今はCMMを知ることも避けられない
USでは政府や大企業からの発注の前提に、求められているのが現状。

日本もPM学会や政府で推進しとる。中身は、徹底的なドキュメント化など、
ISO9001同様に形骸化(外見だけアメリカ流にする)の恐れも大きいが、
かといって無視できないから、ツールとして活用するのが妥当だろうね。

http://www.atmarkit.co.jp/aig/04biz/cmm.html

426 :仕様書無しさん:05/01/09 15:15:12
>>424
例え論理的に正しかったとしても、
自分に不利益になるならうごけねぇだろ。チンチン。

427 :仕様書無しさん:05/01/09 15:17:44
>>425
むしろ時代遅れでしょ

428 :仕様書無しさん:05/01/09 15:18:43
>>426
それは多分論理的に正しくないんだよ。

429 :仕様書無しさん:05/01/09 15:22:12
プロジェクトマネジメント学会
http://www.spm-japan.jp/index-j.html

430 :仕様書無しさん:05/01/09 15:26:14
>>428
そうでもねぇだろ?
どう考えても自分が悪い状況になっちまって
その責任をとることになってしまったら、
人生終了ムード全開の場面じゃ誰だって感情論に走るだろ。チンチン。

431 :仕様書無しさん:05/01/09 15:28:01
単に酒のんで愚痴を書き続けてる人が1名いるスレですね
スレタイとも関係ないじゃん。

432 :仕様書無しさん:05/01/09 16:54:37
パンツマン!?

433 :仕様書無しさん:05/01/09 19:02:39
>>430
それは多分感情論に走る事を論理に組み込んでないんだよ。

434 :仕様書無しさん:05/01/09 19:04:40
>>433
すでに屁理屈だなw

435 :仕様書無しさん:05/01/09 19:10:50
>>434
屁理屈と煽り以外、ここにあるの?

436 :仕様書無しさん:05/01/09 19:14:39
>>435
>>413
>君は管理した事ないでしょ?人は理論では動かないのだよ。
>人を動かす場合、目的達成する場合に行う説明の為の理論は後付けでいいんだよ。
がこんなこと言う前は一応のルールはあったけど
さすがに理論は後付けのPMがきちゃあ俺もお手上げだねぇ(激藁失笑核爆)

437 :仕様書無しさん:05/01/09 19:39:15
>>434
超マジレスなんだけど。
人が感情論に走ったくらいで動かなくなるような程度の低いPMを想定するなよ。

438 :仕様書無しさん:05/01/09 20:05:54
>>437
さらっといいますけど、それ相当なもんですよ。
例えば、そうだね。

>>437
うざいから死んでw

439 :仕様書無しさん:05/01/09 22:09:32
>>438
???

440 :仕様書無しさん:05/01/10 01:55:39
>>414
ちょっと残念な結果だな。
413は、やらば出来る子だと思ってたのに。

効果やコストは不明です。
根拠もありませんが、コードレビューを行うことにより、品質の向上・トータルコストの
減少が実現できます。

てな、熱い主張が通るイカシタ会社にお勤めって事だ。
うらやましい限りだな。

441 :仕様書無しさん:05/01/10 02:14:15
>>436
人を動かす場合に関しての話だ。管理全般じゃない。

理論で人動かす場合は理論の内容は然程重要ではない。
話す内容の内、理論の重要性はたった数行の話で事が足りる。
後は演出の為の話が相当割合を占める。

例えば、ビジョンを示し共感させる方法を考えれば解るよ。

>>440
おいおい、実状があれば想定効果や予想コストは出せるが、
仮想の状況提示しても意味が無い事位は理解出来るよな?

掲示板でいえる技法の性質だけって理解出来ない?
これ管理技法だけに留まらないよ?

反論があるんらば、何か一つ技法に関するコストや効果を提示してみろ。学生君。

煽りが無能や無知を晒す結果になると恥ずかしいな。
そして指摘が図星な為に、自分の正当化を補正する為、更なる無知さを晒す。

それが2chのパターンか。ここにも議論相手はいないな。残念!

442 :仕様書無しさん:05/01/10 02:31:49
2chでは、議論なんかしてませんから〜!! PM斬り!あげ

443 :仕様書無しさん:05/01/10 02:33:29
>>441
はぁ?つーか今まさに人を動かせるかどうかのことをいってんじゃん。
俺はコードレビューは必要ないっていってるのに対して、
君はコードレビューは必要だっていってるんだよ?
現場で俺と君があったらどっちかの主張が通ってどっちかの主張は通らないんだよ。
これが人を動かすことじゃなくてなんだっていうの?
で「理論は後付けでいいんだよ」とか言い出すし、馬鹿かひっこんでろ。
もうこなくていいよw

444 :440:05/01/10 04:12:07
>>441
コードレビューの優位性を証明するには、何らかの計算をするわけでしょ。
その計算式を提示してくれればいいのよ。
実状ってのは入力パラメータに過ぎないわけなんだから。
ただ、どんなパラメータがあって、どう判断してるの聞いてるだけだよ。
まあ、難しかったら、実例でもいいよ。

445 :コードレビューの計算(1/2):05/01/10 11:57:26
例えば5人プロジェクトで各メンバーのスキル(=品質としとく)をこう置く。
A:10skl B:8skl C:6skl D:4skl E:2skl
ここで、生成済みコードに対する作業の生産性は作成者のスキル比率で表すとする。
つまり同じ程度の仕様変更を組み込む場合、
Aのコードを直すよりEのコードを直す方が10/2=5倍かかるとする。
バグ発生〜回収も同様。要は後工程の作業比率全部に影響すると考える。
ここで、コードレビューを行うと、レビュアーに対して品質が平均化するとする。
つまりAがEをレビューすればEのコードは(10+2)/2=6sklになるとする。

446 :コードレビューの計算(2/2):05/01/10 11:58:19
さて、全員が1ks(キロステップ)ずつ実装した場合、
全部で5ks、品質の平均は6skl/ks。
全てAがレビューした場合は8skl/ks。
つまり製造後のコストが75%に減ると考えられる。

ここで設計完了から2ヶ月のプロジェクトを想定し、
1ヶ月実装1ヶ月テストとすると、テスト期間の25%、
つまり1週間以内でコードレビューを行えるならコストが下がる。
つまり製造工程の20%をコードレビューが占めない限りは意義がある。

あくまで例えばね。

447 :仕様書無しさん:05/01/10 17:03:03
どのレベルをコードレビューって言ってるの?
単体テストが終わっていて、パッと見モジュール化されてるか程度のチェックで十分じゃないのか?
1000ステップでも数分見ればメンテ性は判ると思うんだが。

448 :仕様書無しさん:05/01/10 19:02:17
>>447
なんで単体テストの後?

もしそれで修正になったら、関連する単体テストをもう一度
やりなおすことになるんだけど。
デグレードのこととか考えてないでしょ?

個人的には、コードレビューはサンプルチェックを行い、
コーダーの力量及び問題点の横展開を早期段階で行う物だと
思うんだけどなぁ。

449 :仕様書無しさん:05/01/10 19:08:45
誰もソース見て処理内容が解るレベルまでレビューしないだろ...

ソースレビューはプログラム構造の目視検査が目的だから、
1実行モジュール分のソースでも10分もあれも充分、普通は1分で終わらせる。

時間がかかるのは、指摘と改善方法の指定を教える事だけど...

まさか、、処理内容が解るレベルのレビューを想定して話をしていたのか?????
であれば、否定者の意見もうなずけるけど、逆にソースレビューは何をするか知らないのは痛いネ。


450 :仕様書無しさん:05/01/10 19:11:19
>>449
うわ、やべぇ、こいつ、程度問題で上げ足とりはじめたぞ。

451 :仕様書無しさん:05/01/10 19:19:00
>>449
> 誰もソース見て処理内容が解るレベルまでレビューしないだろ...

簡単に断言しますね。

しかし1分で終わらせるソースレビューって一般的なの?
「この人の1実行モジュール」が分からないと何も言えないけど。

452 :仕様書無しさん:05/01/10 19:39:00
ソースレビューやるとしたら、初期段階でしょ?
こんな感じで作成していきましょうってノリで。
その後は、やってもたいへんだから、大体、経験ある人がエディタ上で確認することは
あってもプリントアウトしてレビューなんてよほどのことがないとやらないね。

単体テスト後とか1分なんて言っているのは、板が間違ってるんじゃないかな?


453 :仕様書無しさん:05/01/10 19:56:20
>>452
いたいた、いちいちコード全部印刷する奴w
もー紙ねーってお前w

454 :仕様書無しさん:05/01/10 20:10:33
印刷強要される人は自分が低スキルで問題視されてる事に気付いた方がいいな。

455 :仕様書無しさん:05/01/10 20:20:47
>>454
印刷強要されるんじゃなくてそいつが
ソースみようとするとき必ず印刷するんだよw

456 :仕様書無しさん:05/01/10 20:28:18
昔の人はしゃーないね。

457 :仕様書無しさん:05/01/10 20:45:37
皆ソースレビューって二人で話あってやってんの?
後ツールとか活用してないの?


458 :仕様書無しさん:05/01/10 20:47:09
>>450
程度じゃない定義だろ。

459 :仕様書無しさん:05/01/10 21:04:26
つうかさ、ソースレビューってPMの話じゃないだろ?
チームリーダーとかその手の仕事。

460 :仕様書無しさん:05/01/10 21:21:16
PM = リーダーの場合も多いけどな

461 :仕様書無しさん:05/01/10 22:14:17
>>459
作業者と指示者がごちゃ混ぜになってる。
PMはシステム開発の実務に殆ど携わらない。


462 :仕様書無しさん:05/01/10 22:31:05
だからソースレビューの話はここでもう不要でしょ?

【テスト】品質管理について語ろう【QA】
http://pc5.2ch.net/test/read.cgi/prog/1088135300/l50

こっちでやってくれ。うざい。

463 :仕様書無しさん:05/01/10 22:37:45
なんか熱い2〜3名が同じことの繰り返ししてるように見えるけどな。
全然進歩無いじゃん。

どの業界でも品質確保は、全量へのテストに加えて、抜き取りの
インスペクションを併用する。これは常識。

結合テストや性能テストで同じ問題が各モジュールに発生したら、
手戻りが大きく、品質・コスト・納期を達成できないから。

効果を定量化できない、というのは事実だが、それは全てのテストにも言える。

インスペクションは本来はPMの作業では無いが、
各種の品質確保手法は、PMが効果を見ながら旗振りすべきではある。
(効果が無いなら止める、別の手法を適用する、とかの判断が重要。形式主義はいかん。)

464 :仕様書無しさん:05/01/10 22:44:11
>>462
取捨選択の議論だから問題無いでしょ。

465 :仕様書無しさん:05/01/10 23:24:23
>>462
次のネタ振り頼む!

466 :仕様書無しさん:05/01/10 23:27:11
客の要求は、営業の話と違うから、PM降りるって言ったら
会社、辞めてくれって言われたけど。(遠まわしにだが)
そういうもんか?

467 :仕様書無しさん:05/01/10 23:29:20
比較的低スキルな人ってどう扱ってる?
2、3ヶ月のプロジェクトで教育しても意味無いし、
契約上辞めさせる事も出来ないし。

468 :仕様書無しさん:05/01/10 23:32:58
>>466
客騙してでも仕事取るのが営業の仕事
どんな状況でも利益出すのがPMの仕事

と思ってる営業が多いからね。

469 :仕様書無しさん:05/01/10 23:37:11
>>466
1行目がいまいち日本語になってないような。


470 :仕様書無しさん:05/01/10 23:38:16
>客の要求は、営業の話と違うから、PM降りる

試験問題が、模擬試験と違うから、受験やめる
...こちらがお願いします。辞めろ

471 :仕様書無しさん:05/01/10 23:39:09
>>467
アサインの問題。
誰でもできる作業を振って、他の人の仕事を楽にするとか、
グループ作業にしてそのグループ内でヘルプしてもらうとか。

何かさせてれば、意外な面で役に立ったりもするし。
技術が無くても几帳面なら資料整理とか。

472 :仕様書無しさん:05/01/10 23:46:56
>>466
程度の問題じゃないか?
どの会社でも、話が同じなんて幸福な場合はほとんど無い。
ただ、実現性がゼロで、引き受けた場合は客にも迷惑がかかるような
場合は、上層部へ主張して履歴は残すべきだろう。
(結果がどうなるかは別として)

473 :仕様書無しさん:05/01/10 23:51:11
会社にもよるけど、営業の話とか客の話なんて最初から正しいなんてことはない。
客だって業務はわかっていても実現方法がわかってないなんて当然。
営業なんてそれ以下。

それをどうにかするのがPMというかSEの仕事の楽しい部分だと思うんだが。
相手の予算とかこっちの事情を考えて、いろいろ調整するのがおもしろいわけで。

474 :仕様書無しさん:05/01/10 23:51:33
>>449
プログラム構造の目視検査で保障される物って何なんだろう。
これが分からんのよ。
俺は、処理内容が解るレベルまでレビューしないと、後工程の工数削減に寄与する
事はできんと思うのだが。

また、プログラマの能力把握の為の切り抜きインスペクション(カコイイ言い方だ
な、頂きます)てのも一理あるが、コーディングを始めた段階では手遅れっぽい。
能力の把握はリスク管理に対する投資になるが、能力が劣っていたからといって、
この段階では打つ手があまりない。(ただ、自分の目の節穴ぷりを嘆くだけ)
仕様追加でもあれば、担当選択では役に立つと思うのだが。

475 :仕様書無しさん:05/01/11 00:12:57
>>474
>プログラム構造の目視検査で保障される物って何なんだろう。

だから、誰も保証する話なんてしてないのでは?

>俺は、処理内容が解るレベルまでレビューしないと、後工程の工数削減に寄与する
>事はできんと思うのだが。

処理内容というよりは、機能は把握した上でレビューするのでは?
ここはhogehoge処理です。って具合で。
・コーディング規則にあっているか。
・必要な機能は実装されているか。
・エラー処理はちゃんとやってるか。
問題があるようなら、別のモジュール(&人)も同じような
ことやってる可能性があるから、展開する。
これがソースレビューってもんだと思うけど。

>また、プログラマの能力把握の為の切り抜きインスペクション(カコイイ言い方だ
>な、頂きます)てのも一理あるが、コーディングを始めた段階では手遅れっぽい。

手遅れかどうかなら、手遅れではないのでは?
先にやれという意見も、それはそれで理想的だけど、業務(開発)と
関係ないコーディングを前もってさせて力量を把握というのは
現実的じゃないような気が。
それこそ、それが今回の業務(開発)とマッチしてるか、その内容が
ベンチマークに利用できるかは怪しいと思う。
まぁ、開発計画の段階で、過去の要因のスキルをフィードバックできる
のならば、適材適所を考えるのは基本だけど。
PMBOKでいう所の要因手配と過去の情報ってとこ。
少なくても、完璧じゃないから後工程に回すって考え方は、問題の後回し
だと思うなぁ〜

476 :仕様書無しさん:05/01/11 00:28:24
>>475
>・コーディング規則にあっているか。
>・必要な機能は実装されているか。
>・エラー処理はちゃんとやってるか。
この程度だったらレビューなんぞ開かんで
そいつがサーバーにソース上げたときにこっちでパパっとみちゃうけどね。
おーガンバッとるね○○君。って感じでちょいちょいっと
なってなけりゃ、即注意(ただしやんわりと)。
おーい○○君。ここなっとらんけどどうよ?って感じでちょいちょいっと。

って普通のコミュニケーションじゃねぇかよ!
自分の部下のソースぐらいその日その日で確認しろよ!

477 :仕様書無しさん:05/01/11 00:41:15
>自分の部下のソースぐらいその日その日で確認

それ、PMの仕事ではないな

478 :仕様書無しさん:05/01/11 00:50:36
>>470
>試験問題が、模擬試験と違うから、受験やめる
こんなのことするヤツいないよ。たとえが悪すぎる。


分かりやすく言えば、客の要求は100人月、営業が受けた
と主張する作業範囲と金額は50人月分。で、おれが登場して客と
話し合うにつれてやっぱ100人月じゃん。100人月を50人月
分の金額でやれだぞ。
契約後付の仕事にありがちだけど、こう開きが大きいとな。
営業が強い会社だからこのままやらされんだぜ。
降りる宣言したくなるよ、ご同輩たちさよッ。

479 :仕様書無しさん:05/01/11 00:56:35
>478
>100人月を50人月分の金額でやれ

となるのがおかしいだろ
a.受けたのは50人月分だからそれに見合う分をやるように進める
b.どうしても100人月分必要なら契約変更
ってのがPMの仕事だろ?


480 :仕様書無しさん:05/01/11 01:13:18
>>479
そりゃ〜、営業の仕事だぞ。
その営業が、今のまま(50人月分)で100人月やれ、っていうから、
ジ・エンドよ。
オーライ、オーライ。やめりゃーいいんだ。議論の相手じゃいんよ。
うちの営業たちは。
就職活動に頭使うわ。
付き合ってくれて、サンクス。

481 :仕様書無しさん:05/01/11 01:19:47
>480
>そりゃ〜、営業の仕事
へ〜、そこはそんな事までも営業がやるんだ...

どうりでいわゆる「デスマ」になるわけだw

482 :仕様書無しさん:05/01/11 01:35:10
>>478
悪いが、その程度なら良くある話だよ。工数が倍くらいなら。
それにそれが引き受ける前に明確になったなら、かなりハッピーだ。

仮に辞めないなら、「それでは実現できないから、こういう要件・仕様に
してください。これならできるし、業務もそれなりに回る筈です」と対案するしか無いね。

まずは現場同士で。次に相手の上司と、こちらの営業と一緒に。

483 :474:05/01/11 01:45:39
>>475
>・コーディング規則にあっているか。
>・必要な機能は実装されているか。
>・エラー処理はちゃんとやってるか。
っていうのを保障するのが目的って事を知りたかったわけ。
そういう意味での保障ですよ。

で、必要な機能が実装されているか、エラー処理はちゃんとやってるかという判定を、
コードレビューという形をとると、どの精度まで行えたのかって説明できないと思うの。
頭の中の話だから。
機能を把握しているなら、きちんと文書として提示してあげれば、このコードは、
こういう動作(機能と例外処理)が保障されてますとはっきり言えると思う。
だから、単体テストだけでいいんじゃないと思うわけ。
あとコーディング規約は、フィルタ通せばいいんじゃない。

>手遅れかどうかなら、手遅れではないのでは?
えーとこれはね、仕事をふっちゃた後に、能力を把握しても手遅れって事なの。
ずば抜けてダメダメでない限り、チェンジとか言えないじゃん。
もうコーディングが済んでるんだもん。
能力の把握・判定は、納品完了後ぐらいでいいんじゃないってくらいの意味ね。

484 :仕様書無しさん:05/01/11 01:56:07
どうでもいいが

ほ‐しょう【保証】
[名](スル)

間違いがない、大丈夫であると認め、責任をもつこと。
「品質を―する」「彼の人柄については―する」

[大辞泉]

485 :仕様書無しさん:05/01/11 02:03:28
>>483
>っていうのを保障するのが目的って事を知りたかったわけ。
>そういう意味での保障ですよ。

それは、テストでその項目が保証できるのかと同じだと思うんだけど。
結局は水掛け論になっちゃうと思うんだけど如何?
例えば、
レビューアーの能力がダメならコーディングレビューの意味がない
 → テスト項目作成者の能力がダメならテストの意味がない
 → テスト実施者の能力がダメならテストの意味がない

テストやレビューの方式は、結局は方式論。
別のスレ立てて議論(ごっこ?)してみますか?

>機能を把握しているなら、きちんと文書として提示してあげれば、このコードは、
>こういう動作(機能と例外処理)が保障されてますとはっきり言えると思う。
>だから、単体テストだけでいいんじゃないと思うわけ。

色々な人が書いてると思うけど、詳細レベルの仕様書が個々の例外
ケースまで明記されていて(例えばメモリ確保失敗時の処理、
極論だとprintfでエラーが発生した時の処理)、
テストが全ケースを網羅できればその話は通用する。
しかし、実際はそこまで設計書が細かく書かれてることは
ないのではと思います。
(私の経験上、スパコンOSのドライバならそのレベルで
 書かれてるの見たことあるけど)
でも、そのようなケースだと、サンプルチェックだけではなく
全ソースのソースレビューなんかもやりましたけど・・・

486 :485:05/01/11 02:04:37
(続き)
>えーとこれはね、仕事をふっちゃた後に、能力を把握しても手遅れって事なの。
>ずば抜けてダメダメでない限り、チェンジとか言えないじゃん。
>もうコーディングが済んでるんだもん。

全コーディングが終わるまで、コーディングレビューをやらなければね。
でも、サンプルチェックなら、1モージュールができた時点でやればいいので、
コーディングの初期段階でチェックアウトできるけど。

設計書のレビューも全部終わるまで見ないわけではないでしょ?
それと同じです。

487 :仕様書無しさん:05/01/11 03:09:18

ttp://www.muzi-k.com/



488 :仕様書無しさん:05/01/11 06:30:06
マ板なのに全角が当たり前のスレはここですか?

489 :仕様書無しさん:05/01/11 16:44:44
>>488
そんなことに一々こだわんなや。ちっさい人間やのう。

490 :仕様書無しさん:05/01/11 19:54:16
>>488
この種の情報交換のスレで言うことじゃない。

>>488は、木を見て森を見ない、ていうか
木しか見えない、森なんかとても見えないアホPROグラグラPAー

491 :仕様書無しさん:05/01/11 21:34:13
低スキル者のリスク軽減するなら早い方が良いと思う。

492 :仕様書無しさん:05/01/11 21:44:53
>>447
同意。

阿呆な奴はまだコンパイルも通っていないもんをレビューしたがる。
そんなもんレビューしてどーすんの?w

493 :仕様書無しさん:05/01/11 21:52:56
コードを見るのはコードレビューだよ。
わざわざ製造と単体テスト分離する意味は無いし。
タイミングは単体テスト終了時で良いはず。

494 :仕様書無しさん:05/01/11 21:57:45
>>480が実は正しいのだ。
しかし、競争社会が現実はそんなに甘くないと主張するので
皆さん右ならいしてデスマに堕ちる。


495 :仕様書無しさん:05/01/11 21:57:54
>>493
同意です。
もしコード書いた人間がプログラム設計もやってるならプログラム設計
書をレビューした方が確実。
もし別の人間ならまだ必要かもしれんが。



496 :仕様書無しさん:05/01/11 22:01:25
>>494
スコープ管理はPMの仕事ですが?

497 :仕様書無しさん:05/01/11 22:20:23
レビューが不要と思う人はもう少し質問の仕方を変えた方が良いんじゃない。
話のズレは前提条件とか、作業や言葉の定義、目的意思がズレている事が大半なんだから。

例えば、
非オブジェクト指向言語での開発時は設計書で構造定義(関数の列挙)を記述する事は殆ど無い為、
レビューで構造確認する事は品質予想判断で非常に重要な訳です。

それに対しオブジェクト指向言語ではUML(クラス図)とUMLツール、そして統合開発環境の発展により、
構造定義しないと逆に開発(オブジェクト指向に成らない)が出来ない為、
構造定義をする事が当たり前になり、レビュー意義が薄くなっている側面がある。

と、まあ〜この様な話す前提認識の違いを原因として意見が食い違っているかもしれない。
そういう事を認識するスレで行きましょうよ。

管理について話てんだからさ。技法と結果の方程式で御話する様な事じゃ無いでしょ。


498 :仕様書無しさん:05/01/11 22:22:20
前提満たせない奴大勢居るけどね。

499 :仕様書無しさん:05/01/11 22:32:31
突然だけどプログラム設計書書いた人間と
プログラム組む人間が別って辞めねぇ?

プログラム設計書書いた人間の
抜けとか全部こっちで吸収しなくちゃならないじゃん。
しかも、完成したあとで改めてみるとはじめの設計書の原型留めてないのが大半だし。
どう考えても書いた人間が責任を放棄してしまうのはずるい。

500 :仕様書無しさん:05/01/11 22:39:18
プログラム設計書書くのが馬鹿だろ。

501 :仕様書無しさん:05/01/11 22:47:28
>>499
PGさんかな?ちょっと職場環境や開発道具によって話が異なるけど、
業務系を前提に話をするとですね

確かにプログラム設計書と実装者が別なのはオープン系では不適切。
昔は、データ加工するにも大変だった。それが今じゃSQL文でポンと終わる。

つまりプログラム設計行為と実装行為の目的が被っている訳で、相当近い距離にある。

こう記述すれば「だったら、工程の見直しが必要なんじゃね〜の?」と普通は思うんだけど。
ただ、話に在るように人間が別だから、その様な問題意識が働かない。

また、流石のベンダーも実装やプログラム設計の2艘跳びで基本設計担当を
させる訳に行かないから、設計鍛錬、実装知識の両兎狙いで
プログラム設計は手放さないでしょね。

つまり業界の構造問題が潜んでいるから、その問題は解決し難い。

崩れるならば、開発最適を意図した所からでは無いと思われ。

502 :仕様書無しさん:05/01/11 23:08:52
>>499
意思疎通程度には必要。
相手のレベルに合わせる必要があるが。
納品物として定義されている場合、ソースから逆生成するのが
この業界の標準仕様です。

503 :仕様書無しさん:05/01/11 23:32:27
>>492
>阿呆な奴はまだコンパイルも通っていないもんをレビューしたがる。

コンパイル通ってからやればいいのでは?
もしかして、リンケージとコンパイルをごっちゃにしてない?

>>493
変なソースで単体テストするのって無駄だと思わない?

>>496
スコープ管理は立派なPMの仕事です。
PMBOKだとね。

実際のところも、PMがスコープ管理しなきゃ誰がするの?
って思うけど。




504 :仕様書無しさん:05/01/11 23:37:38
>495
世の中、単体テスト終了時にコードレビューなんて言ってるPGが結構いるのね。
それって、単体テスト仕様書作ってるんだよね?
レビューで問題発覚したら、またやり直すのかなあ?

プログラム仕様書って2度手間だよね。
ソース逆生成してそのまま納品して許されるならいいけど。

505 :仕様書無しさん:05/01/12 01:12:08
コンパイル前にソースを見直すというのは、PSP等でも推奨されている品質向上策だが、
フォーマルなレビューまでやるのかい。

っていうかプロジェクトマネジメントと全然関係ないだろ。
ソフトウェア開発手法とプロジェクト管理手法をごっちゃにしてる。

506 :仕様書無しさん:05/01/12 01:28:14
>>505
味不明。

プロジェクト管理手法にレビューがないとでも?
PMBOKって嘘が書いてあるんですね(-:

507 :仕様書無しさん:05/01/12 01:46:21
いやプロジェクトマネジメントは、品質、コスト、リリースの三つの側面があり、全てが重要だ。

508 :仕様書無しさん:05/01/12 02:01:42
>>507
その3つどれも重要な事は、皆知っているだろう。
問題なのはその3つしか考えない奴だ。


509 :仕様書無しさん:05/01/12 08:52:31
>>508

先生!
じゃあ、他に何を考えればいいのですか!

510 :仕様書無しさん:05/01/12 09:58:34
>>499
詳細設計とプログラミングを同一の人が行うなら、正直詳細設計書はいらないと思う。
大まかなメモ書いて、考えまとめて自分で作ってくれと。
最終的にソースから詳細設計書に類するものをジェネレートしてくれるJAVADOCなりHotDocなりで作ればいい。
そうじゃなく、詳細設計書を作るなら、作ったものは他人が見て理解できるものをきちんと作るべき。
それと関連する文書を見れば、誰が見てもコードが完成するもの。

>>504
もう、その話は平行線になるからクローズでしょ。そもそもPMの領域じゃないし。
実施するしないはPMの判断としても方法論はミクロすぎ。


511 :仕様書無しさん:05/01/12 10:31:28
「プロジェクトは千差万別」には同意だけど
PMだからこそ結論に置いてしまうべきではないね。

512 :仕様書無しさん:05/01/12 11:02:36
作ることしか考えてない人もいるようだけど、
保守用の詳細設計書は、まともな仕事なら必須でしょ。

客にとっては、使い続けてなんぼだから、保守を考えないシステムは、
手抜き突貫工事と同じだよ。

513 :仕様書無しさん:05/01/12 11:06:05
保守用の詳細設計書よりも保守性の高いソースコードだろ。
どうせ詳細設計所なんて保守出来ないんだから。

514 :仕様書無しさん:05/01/12 11:09:18
コンパイルの前でもソースレビューは有効だよ。

目的は、細かい記述ミスのレビューじゃなくて、
記述の流れ、例外処理の考慮範囲、コメント量の適正さ、標準化などなど。
特に新人君とか。逆に馴れてる人ばかりなら、減らしていい。

これをコンパイラー通過後に直すと、すごい作業量になって、
記述ミスも出てコンパイルエラーも出て、結局二度手間。

ただ、全量を早期ソースレビューするかは判断が必要。
各担当者とか各機能単位で、1〜3ソースやるだけで、
後々の品質や手戻りが格段に違うよ。

515 :仕様書無しさん:05/01/12 11:09:29
>>513
貴方の見解が現実的だと思う。
そして形骸化した詳細設計書の納品作業だけが残る

516 :仕様書無しさん:05/01/12 11:12:04
>>513
両方にきまってんだろ。こんな奴がいるから皆、保守で苦労するんだよ。

仮に継続保守できないとしても、当初のドキュメントがまともなら、
後から追う事もできるが、最初からまともに作る気が無いんじゃ処置なし。


517 :仕様書無しさん:05/01/12 11:12:59
>>515
あんたも作る事しか考えてない、手抜き工事要員だね

518 :仕様書無しさん:05/01/12 11:13:16
Eclipse使ってる奴にコンパイル前とか言うと馬鹿にされるぞ。

519 :仕様書無しさん:05/01/12 11:14:45
>>518
そりゃ、ツールが内部的にどう動いてるかだけの話

520 :仕様書無しさん:05/01/12 11:14:57
詳細設計書にコーディングと同じ期間掛ける意義は薄い。

521 :仕様書無しさん:05/01/12 11:18:23
ちゃんと設計してからコーディングしないから、
後から「考慮漏れ」で修正しまくりになるんだが...

反省しないPGが多いこと。

522 :仕様書無しさん:05/01/12 11:18:33
>>514
二度手間ねぇ。・・・それは、各担当者の技能が、
「コンパイルエラーを除去する工数が無視出来るほど少ない」か否かに依存しているのでは?
新人君にはその種の配慮が必要かも知れないけど、私の場合はベテランに面倒をみさせているぞ。
#「コンパイルも通らない落書きを読みたくない」という個人的な希望もw

523 :仕様書無しさん:05/01/12 11:18:45
>>519
まーつまりコードレビューのタイミングなんて千差万別って事だよ。
コンパイルに10分かかるならコンパイル前だろうし、
テスティングフレームワークでテストファーストしてたら単体テスト後だろうし。

ツールは使いこなせば開発工程を変化させる力がある。

524 :仕様書無しさん:05/01/12 11:26:30
まーでも、話が互いに堂々巡りしてるみたいだけど、
結局は「何を主眼にレビューやインスペクションするか」に尽きるのでは。

1.「コンパイルエラーを事前に発見する」は、ツールが便利な現代では必要性薄い。
2.標準化・拡張性の事前チェックは重要だが、ベテランばかりなら必要性薄い
3.ツールで簡単に発生できないケース(大量とか基盤障害系)は、重点的にソースレビューが必要

「コンパイルも通って動く」のと「標準化・性能・拡張性を含めて品質が高い」のは違うからね。

525 :仕様書無しさん:05/01/12 11:49:10
>>516
なぜ「詳細設計書」が保守時に必要なのか?なんの役にも立たないが。
正しい地図があれば役にたつが、残っている地図が本当に正しかった例なぞ知らないぞ

526 :仕様書無しさん:05/01/12 11:52:10
「できました。テストも通りました」といってプロジェクトを去り、
・システムテストで大量データでは性能が出ない
・例外処理は運用に即さない
・設計書はメンテしてない

こういうのを撲滅するのがPMの地道な仕事。
でもPGは楽をして「一丁あがり〜」で去りたがる。
だからPMはPGに嫌われる面があるのも仕方ない。
使えるシステムを作るのがPMの目標だから。

527 :仕様書無しさん:05/01/12 11:53:01
>>525
あんたの周囲がひどいからって、世間全部を同じと思ってはいけないよ。

528 :仕様書無しさん:05/01/12 12:21:31
>>526
PMの仕事はプロジェクトを成功させる事だよ。
PG抑えて満足することじゃないよ。

529 :仕様書無しさん:05/01/12 13:02:01
>>527
フーン。経験は必然性を教えないってやつか。
「ひどい」だなんて思ってはいないよ。「それが普通なのだ」と思っているだけだよ。
貴方の周囲は、貴方の言う「ひどい」では無いのだろうね。
#個人的には単なる「貴方の脳内現実に過ぎない」と思うけどね。
よかったら「どの様にしたらそれを実現可能か」を披露してみて欲しいが

530 :仕様書無しさん:05/01/12 13:50:57
業務時間中に2ちゃんに書き込むPM達のスレか・・・

531 :定時になったぞ:05/01/12 18:56:41
>>530
時間で管理される仕事では無いからね

532 :仕様書無しさん:05/01/12 19:12:02
集中力が求められる仕事でもなさそうだな

533 :デフォルトの名無しさん:05/01/13 00:42:31
新人PGです。
明日コードレビューなのですが、
コードレビューではいったい何が審査されるのでしょうか?
設計ならUMLのクラス図やシーケンス図を使うと思うのですが、
ソースになると規約ぐらいしか見るとこないような気がします。

>>522
エラーコードをレビューすることとかってあるんですか・・・?
マジッすか?それって意味がないような・・・

534 :仕様書無しさん:05/01/13 00:46:26
>>533
随分粗末な釣りだな。

535 :仕様書無しさん:05/01/13 06:48:59
馬鹿ばっかだな。

昔はコンパイルに数十分〜数時間かかり、端末を共有していた。そう言う時代はソースレビューする事は当り前だった。

しかし、時代の移り代わりでここの判断は難しい。だから無条件に、ソースレビューが必要と云うのは現状認識が出来ていない。

ただ、この昔の人達はある法則をしっている。コンパイルのリトライ回数が多く懸かったモジュールは、やっつけで作成されている為、テスト工程回す事は非効率的である。
実際、今でも各基本機能が動く所まで即時デバッグしてから、テスト項目の消化に取り掛かるだろ。

ツールに依存している所で、誇っても仕方が無い。コンパイルのリトライ回数が少ないと言うのは、ソース全体が見渡せていると云う事であり基本的な設計技術が身についていると云う事だ。
基本的な設計技術が身についていない人は、自分の判断で記述したソースに対する検証が出来ないつう事だ。

その行為の意義、その裏に存在する非意図的な意義を考えねばならん。それが管理者だ。






536 :仕様書無しさん:05/01/13 07:35:41
またぬるぽ?

537 :仕様書無しさん:05/01/13 22:31:28
>>535
コードレビューの必要性に時代の移り変わりは関係無いでしょ。
例えばXPは全ソースコードのレビューがプラクティスに組み込まれているし。

あと君の後半の文章意味がわからん。

538 :仕様書無しさん:05/01/13 22:49:35
最近はコンパイル気にせず掛けまくる。
ばーとエラーが出たら2,3個つぶしてコンパイル、疲れてるときは
1個つぶしてコンパイル。ものによって、1個つぶすとガクンと減るしね。
あと、テスト時にgoodなツールが無い場合は、コメントとか、手作りの
スナップショットとかあちこち入れて、消して、入れて、消して、入れて・・・・
で、コンパイル。
めんどーくさいPGのとき、200回コンパイルやったら、PMにけちょん、ケチョン
言われた。でも、開発マシン余裕あるしオレ的には問題なし。
かなり落とし穴的なバグつぶせたからいいんでないの、って感じよ。

539 :仕様書無しさん:05/01/13 23:12:49
>>537
>コードレビューの必要性に時代の移り変わりは関係無い
あなたのコードレビューの目的は何ですか?

>例えばXPは全ソースコードのレビューがプラクティスに組み込まれているし。
初耳。ペアプログラミングの効果としての話では無く?




540 :仕様書無しさん:05/01/13 23:26:06
>>539
>あなたのコードレビューの目的は何ですか?
コードの品質を高め、品質の低いコードに関するリスクを軽減する事です。

>>例えばXPは全ソースコードのレビューがプラクティスに組み込まれているし。
>初耳。ペアプログラミングの効果としての話では無く?
そうだよ。効果っていうか手段そのものだけどね。初耳じゃないじゃん。

541 :仕様書無しさん:05/01/14 00:08:39
しぇんしぇい!
XPのプラクティスとして全ソースコードのレビューを定義している
その間抜けな本やサイトを教えて下さい。


542 :仕様書無しさん:05/01/14 00:11:42
コードレビューを否定してる僕ちゃん達って
恥ずかしがり屋さんなのかな?

それとも、自分の作るウンコなプログラムが余程自信がないのかなw

543 :仕様書無しさん:05/01/14 00:15:39
>>541
間抜けな君は一度くらい本やサイトを眺めて下さい。

544 :仕様書無しさん:05/01/14 00:40:24
ちゃんとしたレビュアーがいるならいいが。Fの仕事だとこれが.....以下略。

545 :仕様書無しさん:05/01/14 00:46:55
プロジェクトメンバーの最高スキル者が大した事無いなら、
どっちみち大した仕事出来ないんだから諦めて泥沼のように頑張れ。

546 :仕様書無しさん:05/01/14 00:47:20
>>543
ソースコードのレビューをプラクティスとして定義しているのは聞いた事が無いぞ。あ、>>540を相手にしている事が間抜けって事ね、
>>540は釣りか。釣られた...

547 :仕様書無しさん:05/01/14 02:57:46
コードレビューは、コードの品質(メンテナンス性)を確保するのが目的。(※)
 →バグの回収や保守、派生開発を行う人に対して

テストは、実装した機能や動作を保障するのが目的。
 →顧客やプログラムを利用する人に対して

だと思うんだが、どうでしょう。
方向性(目的)が違うと思う。
だから、テストがんばるから、コードレビューしないってのは的外れかなあ。

ただ、コードレビューだけがコードの品質を確保する唯一の方法ではないと思うし
(コーディング規約の提示だけでも、メンバーによれば十分の時もある)、プロジ
ェクトによっては、メンテナンス性をあまり考慮する必要がない場合もあると思う
ので、コードレビューを導入しないって選択はありだと思う。

(※)
まあ、コードレビューでも、実装した機能や動作を保障ができないわけではな
いが、それは単体テストで確認したほうが確実で早いと思う。

548 :仕様書無しさん:05/01/14 21:14:06
レビューの過程で「自分で」ミスに気づいたり
仕様への誤解が解けたり、逆に理解が深まったり
そういったことはないのかね?

549 :仕様書無しさん:05/01/14 21:22:16
>>548
普通は、上司やリーダー格に罵られて終りなんでないの?


550 :仕様書無しさん:05/01/14 21:52:25
レビューの目的は個人攻撃では無い

551 :仕様書無しさん:05/01/14 21:54:19
>>550
承知してるけど、実態と理想とは大きく違うもんだからね

552 :仕様書無しさん:05/01/14 22:40:55
>>551
君の意識だけの問題だよ。


553 :仕様書無しさん:05/01/14 22:42:47
>>546
プラクティスに「ソースコードのレビュー」って書いてあるわけじゃないよ。
一覧を音読したくらいで分かった気になっちゃダメだよ。

554 :仕様書無しさん:05/01/14 23:42:35
XPの話は、537が個人解釈をXPの定義として語っているのは問題ですね

レビューの話は、繰返処理の脱出条件が前か後ろかでテストケースが変動しますよね
その様な構造に即したテストケースの必要性を考える事もありでは。


555 :仕様書無しさん:05/01/14 23:57:43
>>554
どちらかと言えばXP作った人の解釈かも。

556 :仕様書無しさん:05/01/15 00:26:52
レビューは「みんなが承認した」と後で開きなおるためのものですよ。

…書いてて悲しくなってきた。

557 :仕様書無しさん:05/01/15 13:25:28
>>555
であれば、その引用元を提示してあればいいんじゃない?

発言元を明確にしないのは管理者として最低だ。
よく「それでは皆が納得しない」「会社が了承せんよ」と云う奴いるだろ、これは無責任の現れ。
管理責務を考えているならば、
「それではxxxさんが納得しない」(エスカレーション先の明確化)
「xxxの規則に一致しない」(問題箇所の明確化)
「周囲から反論があった場合、私にはその意見では抑える事が出来ない」(予測課題の明確化)
を行う必要がる。

それと君達は同じ事をしているのは?

仮にXPにて、全ソースのレビューをしろと明言されていなくても、そう個人が受止める事は間違いじゃ無い。
しかし、それがXPだからと云って自己の考えや責務を放棄する姿勢は問題があるんじゃないの?

ま、掲示板だからいいけどさ、そう言う管理者が現実に多くてね...








558 :仕様書無しさん:05/01/15 13:54:40
このスレでずっと続いてる会話

ただのPGの愚痴「レビューは不要」「ツールで十分」「俺はそうやってきた」
「ドキュメントはメンテしない」「どうせ他だって同じだろう」...

こんなの相手にしても仕方ないね :-P

まともなPGは自分のソースの説明も、人のソースのレビューやコメントもできるって
事を知らないで「管理者の陰謀だ」と思ってるだけみたい。

559 :仕様書無しさん:05/01/15 13:59:43
>>558
逆も似たようなもん。

「コードレビューは必要」「その理由はよくわからない」
「コードレビューの必要性がわからない奴は馬鹿」
「でもそれを人に説明することはできないの」

やっぱりPMなんてアホなんだなw

560 :仕様書無しさん:05/01/15 14:47:24
>>559
コーダー君は引っ込んでろってことだ

561 :仕様書無しさん:05/01/15 14:55:52
>>560
結局、自分1人でソフトを完成させたことのない人が多いからじゃないのかな。
いっつも何かの修正作業とか追加作業ばっかりで工程の全体がまったく見えていない奴が多いんだろ。

562 :仕様書無しさん:05/01/15 16:32:15
>>561
1人で全工程?
ほとんどありえないと思うがの
言っておくが、要件定義からテスト完了、納品までが全工程じゃないんだよ、お分かり?


563 :仕様書無しさん:05/01/15 16:47:17
>>562
来ました新要素。
用語「全工程」を定義してください。

564 :仕様書無しさん:05/01/15 16:55:36
>>562
そうだぜ!
家につくまでが遠足だぜ!
遠足の帰り道。俺の幼馴染の菜穂ちゃんが「お腹痛い・・・」とかいいだして
くさむらでウンコしたのは俺と菜穂ちゃんだけの秘密だ。
まあ、いまでは結婚もして旦那もいるらしいがな!

565 :仕様書無しさん:05/01/15 19:11:22
>>563
まぁ、なんだ。
コーダー君が一生懸命背伸びしてるんだから許してやれ。
微笑ましい光景じゃないか。


566 :仕様書無しさん:05/01/15 19:13:03
とあるサイトを見てみました。(^◇^)

プログラマーらしいホムペの仕上がり。
雑誌なども出版していてネット販売もしています。
素晴らしい人です。中で疑問がわいてきました。
IPだのアクセスポイントだのと言うわりには独自ドメイン取ればいいのにと思います。
ネットを利用している人って、商用や会社、団体以外ドメインって取らないの?
素朴な疑問ですので中傷はいけません。素晴らしいプログラマーに失礼ですから。
http://wanichan.way-nifty.com/blog/2004/02/ip.html


567 :仕様書無しさん:05/01/15 19:36:02
>>566
俺、大阪人、嫌い、2度と貼るな。
マジ腹が立つ。

568 :仕様書無しさん:05/01/15 19:39:52
話題とずれてすみません。質問。とあるサイトを見てみました。(^◇^)

プログラマーらしいホムペの仕上がり。
雑誌なども出版していてネット販売もしています。
素晴らしい人です。中で疑問がわいてきました。
IPだのアクセスポイントだのと言うわりには独自ドメイン取ればいいのにと思います。
ネットを利用している人って、商用や会社、団体以外ドメインって取らないの?
素朴な疑問ですので中傷はいけません。素晴らしいプログラマーに失礼ですから。
http://wanichan.way-nifty.com/blog/2004/02/ip.html
プロが発言!!自分の地域に自信を持ちましょうと言ってました。
素晴らしい。けど何で独自ドメイン取らないの?


569 :仕様書無しさん:05/01/15 22:48:25
そうだね、コーダ君に解り易く云えばPG脳でPM概念を理解しようとする事が
根本的間違いだという事に早く気付いて欲しいね。

これからは、コーダ君無視って事で。

570 :仕様書無しさん:05/01/15 22:50:40
>>569
PMだけで開発できると思ってるバカですか?、キミ

571 :仕様書無しさん:05/01/15 23:10:34
>> 570

確かにPMだけじゃ開発できないね。
569が言うとおり、PGとPMじゃ立場が違うから
「無能なPG」とか「PMは使えない」とか、お互いを
罵り合ってるようじゃ、話はずっと平行線なんだろうね。

でも、ここはPMのスレだから、例えPGでもPMの立場で話ができる人に
きてもらいたいね。

572 :仕様書無しさん:05/01/15 23:14:06
>>557
君はXPについて学んだ事が無いんだよねw
それだけハッキリすれば引用元貼るのは何ら問題無いよ。

http://www.objectclub.jp/community/XP-jp/xp_relate/whatisxp-j#pair
例えば↑に「すべての製品コードが少なくとも1人の他のプログラマによってレビューされ」
とあるけど、こんなもんXPについて書かれた、ありとあるあらゆるサイト・書籍に
当たり前のように名言されている事だよ。Kent Beckの本にも書いてあるよ。

ちなみに俺は君の管理者じゃなくて、ここは無責任な掲示板だから、
「質問する時は自分である程度調べてから」というネットの質問マナーを優先しただけ。
プロジェクトメンバーは保護するよ。その為に高いお金貰ってるんだから。

今回は2行目に”w”を書く事が目的だったので特別。
感謝しつつ自分を見直して下さい。

573 :仕様書無しさん:05/01/15 23:15:58
PG経験無いPMは殆ど居ないからね。
PM、PG分かってるPM
PG分かってるPG

どっちの見識広いかは一目瞭然・・・

574 :仕様書無しさん:05/01/15 23:18:37
>>573
相応の実力があったらの話ねw

575 :仕様書無しさん:05/01/15 23:23:05
少なくともPMの仕事が見えてないPGは例外無く視野が狭い。

576 :仕様書無しさん:05/01/15 23:25:55
>>575
上司がアホだからだなw

577 :仕様書無しさん:05/01/16 00:10:19
PGに成り下がった人とその成れの果てが罵り合ってるインターネッツはここでつか?

578 :仕様書無しさん:05/01/16 00:11:29
>>561
リリース後に仕様変更(法律変更などで)がある様なシステム
をやっていた人がレビュー必要と言っていて、リリース後には
仕様変更がない(ゲームなどのパッケージ)をやっていた人
たちがレビューは不要と言っているだけじゃないかな?

そもそもプロジェクトの前提が違うから話がかみ合っていない気が。

あと、良く知っている同じ会社の仲間だけで作り上げるなら
メンバによってはレビューは不要とかも思ったりする場合も
あるが、外注に出すとき(オフショアだとなおさら)レビューは
不可欠だと個人的に思っている。

579 :仕様書無しさん:05/01/16 00:36:57
>>576
やだやだ。
自分の無能さを他人のせいにしたいのですね。

有能な人はどんな環境に居ても自力でなんとかするし、
本当にしょうもない所なら、とっとと出ていきます。
それすらもしないで自分の無能さを他人のせいにしてる人。
きっと精神的に大人になれないのですね。
いつまでもママンのおっぱいでも吸っててください。

580 :仕様書無しさん:05/01/16 00:39:46
PMが野心家でなおかつヒステリックだとたまらないよなあ。

581 :仕様書無しさん:05/01/16 00:46:55
>>580
たまらないのはPMでもPGでも同じでは?

もう、こういう話の展開はやめにしません?

582 :仕様書無しさん:05/01/16 00:49:29
>>581
PGを人間的にも見下してるPMとかSEって多いからね

583 :仕様書無しさん:05/01/16 00:52:12
>>582

そりゃ、あなたのような・・・な人はねぇ。

584 :仕様書無しさん:05/01/16 00:56:50
>>581
ま、ここは2chだからね。互いに9割は便所の落書きてな前提で書かないと。
在日叩き、高卒叩き、COBOLer叩き、紺猿叩きと同様、
PM叩きやPG叩きを続けたい人も永遠にいるだけ。

諭しても酒飲みの発散と同じで繰り返しだし。

それでもこのスレ、この板では珍しくまともだと思うよ。

585 :仕様書無しさん:05/01/16 01:34:02
違うな、誰もPGを馬鹿にしていない。
偶々PGという職種についている無能者がPMから的確な指摘を受けた結果、
自己防衛本能で、自分では無くPG職種が攻撃された自動判断をしたのだ。

つまり、「お前ってアホだからあっちいけ!」と云われて
「日本人を馬鹿にしましたね!」とイチャモンを付けているだけだ。

上記が理解出来ない奴、投稿するな。
PMにとってPGが気持ち良く働いてもらう環境を整備する事は重要課題だ。


586 :仕様書無しさん:05/01/16 01:43:47
>>585
で?、なんでキミが仕切ろうとするのかな?、ここはキミの職場でも無ければ、
キミのプロジェクトでも無いんだけどな。

>偶々PGという職種についている無能者がPMから的確な指摘を受けた結果、
>自己防衛本能で、自分では無くPG職種が攻撃された自動判断をしたのだ。

根拠は?( ´_ゝ`)

そう思いこんでる時点で、キミに見下してる感情が欠片も無いと証明できる?


587 :仕様書無しさん:05/01/16 06:41:29
>>579
なんだよ、学生かよw
困っちゃうなホントw

588 :仕様書無しさん:05/01/16 10:41:36
実は最初っから非PMerの脳内議論だったりするw

589 :仕様書無しさん:05/01/16 10:46:47
>>588
中にはそういう奴も混じってるだろうな

590 :仕様書無しさん:05/01/16 11:57:12
>>588
やだやだ
余程自分のせいにしたくないんですね。
相手が学生だと思い込んで自己防衛ですか?

コーダー君。
早く、ママンから乳離れしたほうがいいですよ。

591 :仕様書無しさん:05/01/16 13:44:01
>>590
アンカー間違えてるのか頭が悪いのかどっちなの!?

592 :仕様書無しさん:05/01/16 22:34:02
なんか、変な人達集まってきちゃったよね。

PMのスレなんだから、関係ない人たちは荒らさないで欲しい

593 :仕様書無しさん:05/01/16 22:51:35
>>592
その前にプログラマじゃないんだから
この板から出てってよ。

594 :仕様書無しさん:05/01/16 22:55:48
......なんか、また2〜3名だけで燃えてるな。自作かもそれんが。
どっちも低レベルな荒らし。

595 :仕様書無しさん:05/01/16 22:58:47
>>594
絶妙な煽りだなw

596 :仕様書無しさん:05/01/16 23:06:13
>>593
コーダーもプログラマじゃないよ。
土木・建築板あたりに行ってくれ。

597 :仕様書無しさん:05/01/16 23:53:10
>>596
学生かよw

598 :仕様書無しさん:05/01/17 09:58:00
週末だったのでちょっと前の話を蒸し返すが、1人で全工程って勉強になるよ。
ツールとか10画面程度の仕事がたまにあるところだと、そんなの1人で全部ってことになる。
客先逝って要件聞いて、マシン構成から何から調整して、作って、テストして、納品する。
人月で5人月未満のあたりでたまにやっていた。
正直、こういう仕事をやると責任がずっしり来るし、全体を見渡す基本的な部分はできると思う。

ただ、それと同時に自分1人の力じゃどうしようもないような大きい案件(数十人以上の開発規模)もやっておきべき。
そういうところで、組織内での振舞い、分業制の意味も勉強する。

599 :なぎさっち ◆Nagi/FmYMM :05/01/17 10:47:34
いいからオマエラageんな。

600 :仕様書無しさん:05/01/17 15:46:04
【質問】

契約にもよるけど、受託開発時の
納品物に「ソースコード一式」ってのが入ってる場合
請負価格どのくらいアップさせますか?

技術のコアであるかどうかってのもあると思うけど
その算定根拠はなんにしてますか?
(1から作った場合の人月とか、それプラス技術の付加価値とか)

601 :仕様書無しさん:05/01/17 16:05:42
>>600
そもそも何故アップさせる必要があるのでしょうか?
大体において、受託開発はソース提示が前提だろ。契約上著作権を放棄しているはず。

なので、もしアップするのであれば、アップしない場合のあなたが得ると思う利益分を単純に乗せればいいんじゃないの?
隠すことによるメンテが来るとか、そういう文化圏ってあるのかな?
(ソース開示してそれらのメンテが来ないという”メリット”もあるんだけどね。w)

602 :仕様書無しさん:05/01/17 16:16:23
>>601
ということは、いわゆる業務系では
ソース提供ってむしろ一般的なんですか・・

いや、いままで受託でwin用のパッケージ作ったり
ゲーム系の請負なんかをしてたんですが
ソース納品ってなかったんで・・
以前、他の部署で社内独自のライブラリ使ったwinアプリの
カスタマイズ版を請け負ったときに
ソース提供でもめたりしてんのは聞いたことありましたが・・

なんだろ文化圏の違いなのかな


603 :仕様書無しさん:05/01/17 16:22:22
>>602
業務系の場合、開発者、開発元会社がなくなっても、システムメンテナンスできないと
困るのは発注元側ですからね。

一般アプリの場合でも、サポート切れとかのリスクはあるけど、
業務系の場合、それが許されない場合がある、というかそんなの当然だわな。
開発元がなくなったから、明日からうちの工場なりは動きませんなんてありえん。

なので、ソースを開示するのは当然といえば当然・・・だと思ってた。
そういう場合、既存ライブラリ等に関しても開示は必要です。
そのソース含めてお客様のものになるわけですから。

604 :仕様書無しさん:05/01/17 18:17:39
>>600-603
ソースを開示するか、開示した場合のは契約や著作権による。

パッケージ販売はオブジェクトのみの提供が多い。
Windows本体、Solaris本体、大半の市販アプリ...
ほとんどの場合、所有権は開発元にあり、使用許諾契約を販売しているだけ。
だから、転売禁止とか逆アセ禁止とかの制約の反面、サポート契約がある。

大半のシステム開発は、支援契約(法律上は準委任)などで、
「作業を手伝ってる」だけで、所有権は発注側にある場合が多い。
ただ、業務固有というより汎用的ツールなどは、開発側が使いまわせる契約に
なってる場合もある。

SIなどの請負契約だと、ここらの契約はかなり慎重に個々違う。

...とかかな? 正確にはPM試験以来、忘れちゃったぜ。

605 :仕様書無しさん:05/01/17 19:44:23 ,
>>602
違う業界でも同じだよ。

注文住宅建てる時は、設計図とか使って打ち合わせして、渡す。

自動車を買うときは、説明書がある程度。

606 :仕様書無しさん:05/01/17 19:51:27 ,
ソースを公開してしまうと、それを他の会社のヒトにみられてしまうので、技術が盗まれてしまう。

と、深刻に悩んでいるPMを見たことがある。
目を覆いたくなるようなソースを書くヒトでも、羞恥心ってのがあるんだなぁて思た。

607 :仕様書無しさん:05/01/17 23:01:21
心配しなくても受託開発じゃ青色発光ダイオードなんて永久に生まれないのにね。

608 :仕様書無しさん:05/01/17 23:07:04
著作権は著作者に自動的に発生する。つまり基本的にベンダーが著作権を持つ。
あと著作権と所有権は別の権利は別だぞ!!!

609 :仕様書無しさん:05/01/17 23:09:39
まー客に不利な法律があれば契約書に書いて逃げてるだろうけど。

610 :仕様書無しさん:05/01/18 01:06:06
>>604
PM試験キタァ〜

って、何の試験よ。それ。
そんなのはPMPじゃ範囲外だしね。
自社のインチキPM試験の話持ち出して何したいんだかw

611 :仕様書無しさん:05/01/18 22:35:36
情報処理技術者試験のプロジェクトマネージャ試験ってみんな取ってるの?

612 :仕様書無しさん:05/01/18 22:50:03
>>611
私はPMPだけ。

情報処理のってどんな感じなの?

613 :仕様書無しさん:05/01/18 23:32:41
>>612
PMPってどんなの?

614 :仕様書無しさん:05/01/19 01:53:06
モダンPMを実践してるのはどのくらい?

615 :仕様書無しさん:05/01/19 10:42:29
>>614
モダンPMってどんなの?

616 :仕様書無しさん:05/01/19 10:46:47
>>615
大正浪漫のかほりがするPMじゃないか?

617 :仕様書無しさん:05/01/19 12:09:04
プロジェクト管理とは肚でするものだ
by Tom DeMarco

618 :仕様書無しさん:05/01/19 23:42:56
>>613
あまり美味しくないです。

619 :仕様書無しさん:05/01/22 15:48:20
 

620 :仕様書無しさん:05/01/25 15:09:15
ソフトウェアの品質向上は今日のシステム開発ではごくあたりまえの要求と
なっており、その実現には効果的なテストプロセスの確立が重要です。
プロジェクトの成熟度によって実践レベルはさまざまですが、あらゆるシーンで
常に中心的な役割を担うのは開発者でしょう。
そこで、開発者を軸にしたテストプロセスの実践方法として、
優れた機能と高い実績を持つテストツールの使い勝手のよさが
システムの品質向上や短期開発にインパクトをもたらしていきます。



621 :仕様書無しさん:05/01/25 16:03:48
【テスト】品質管理について語ろう【QA】@プログラマー
http://pc5.2ch.net/test/read.cgi/prog/1088135300/168

時刻、文体からみて同一人物だと思うが・・・テキスト写して嬉しい?


622 :仕様書無しさん:05/01/27 02:36:29
「年々厳しさは増すばかり。でも、今さら別の仕事もできないし」とあきらめ顔

623 :仕様書無しさん:05/01/28 01:14:32
日本に来て働くのは、税金を納めながら
意見を言ってはならない『ロボット』になるということです

624 :仕様書無しさん:05/01/28 15:27:22
>>623
(有能な人間は除く)

625 :仕様書無しさん:05/01/29 01:41:48
「これが、私が考えた職場だ。労働環境についていろいろ言う人も
いるかもしれない。それはシステムをつくるプログラマやSEが、
この仕様に合わせてもらうしかない」

「労働時間はこれ以上小さくしたくないし、残業手当もこれ以上
大きくしたくなかった。過労で倒れるのも狙ったもの、それが仕様。これは僕が
作ったもので、そういう仕様にしている。
明確な意思をもっているのであって、間違ったものではない。世界で一番
美しいものを作ったと思う。著名建築家が書いた図面に対して門の位置が
おかしいと難癖をつける人はいない。それと同じこと」


626 :仕様書無しさん:05/01/30 18:15:33
コードレビューの話が落ち着いたら
急にスレに勢いがなくなっちゃってるね。


627 :仕様書無しさん:05/02/02 14:32:30
最近、仕事は順調なんだけど、ハイペース&結構仕事も正確な開発会社に
合わせて、仕事が早朝になってるよ・・・・4時に起きて、昨晩までの設計&開
発の進捗を整理して、クライアントに投げて寝、12時に起きてクライアントと
電話で打ち合わせ、夕刻できるだけ早いうちに開発会社に仕様書投げてまた
寝て・・・・

あまりハイペースだと苦労の割りに工数安くなりそうで怖い。困ったもの。

628 :仕様書無しさん:05/03/03 00:36:10
生活時間をズラすのは得策とは言えない。

629 :仕様書無しさん:05/03/03 23:22:36
ちょっと質問していいですか?
私は研究室で管理者やっています。クライアントの皆さんが音楽聞き
ながら研究してたんですが、最近容量がいっぱいになってきたんで
(HDDの共有容量が80GBしかないので)音楽ファイルすら置けない
状況なんですね。貧乏研究室なんで安いバルクのHDDを購入して
/junkという名前でジャンクなデータ専用領域を作成したんです。
そしたら他の管理者に”管理がダルい”とか言われたんですよ。
管理って/etc/fstabを書き直すだけなのに orz

管理者やってる皆さんどう思います?ユーザの希望を実現した
だけなのに...


630 :629:05/03/03 23:24:59
スレタイの管理者とはちょっと意味合いが違ってましたね。スマソ orz
PMな方でもいいんですが、ユーザの意見を聞いたら管理者に
ケチつけられる。こんな状況の時どうしますか?

631 :仕様書無しさん:05/03/04 01:19:28
、『在庫』『経費』『スループット』の3つの指標がある。マネジメントの手段は明らかだ。『在庫を減らし、経費を減らし、スループットを増やす』。これが、マネジメントの全て

632 :仕様書無しさん:05/03/05 07:50:58
>>630
管理者ボコって追い出す

633 :仕様書無しさん:05/03/05 11:24:44
>>631
それは所謂、製造業の場合だね。
ソフトウエア開発/保守業の場合、『在庫』『経費』『スループット』の3つの指標が
それぞれ何に該当するのかを書かなければわからない人には全然わからないのでは?

634 :仕様書無しさん:05/03/05 18:07:37
俺はPMもPGもどちらもこなせてしかも一流。
人間性も抜群で言うことなし。
なのでこのスレの住人のような悩みはない。









...と、そう思いこめば、何があっても乗り越えられる。

635 :仕様書無しさん:05/03/05 18:41:21
>>634
ユーザーがいつも裏切ってくれるだろ?(苦笑)


636 :仕様書無しさん:05/03/06 10:22:47
裏切られる前に裏切れ、これ鉄則。

637 :仕様書無しさん:05/03/06 14:34:42
>>633
YukiWikiのページのコピペの模様
ソースぐらいかけ >>631

638 :仕様書無しさん:05/03/06 17:03:09
PM勃起

639 :仕様書無しさん:05/03/06 17:09:43
PM、PGと言う前に、まず一人のサラリーマンであることを忘れるな。
by ウチの会社の上司

640 :仕様書無しさん:05/03/11 01:47:08
>>639
> PM、PGと言う前に、まず.....

真意はわからないが忘れるやつはいないだろう。
自分がリーマンであることを。

続けてPCやらPBやらPKやらもいたら楽しいな。
あとPP。

641 :仕様書無しさん:05/03/12 11:32:01
PS


642 :仕様書無しさん:05/03/12 11:41:27
>>641
IBMには昔、マジにPSが職種としてあった。

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

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

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