【IT】ＰＭな人達のスレ【管理者】
87 ：仕様書無しさん：
泣き言なんか聞きたくないね
なんとかしな！
名言だねぇ
なんとかしな！
名言だねぇ
|
|
|
今日は「ドーラに学ぶPMのありかた」だな
89 ：仕様書無しさん：04/12/24 22:46:45
的確な配置と業務の割り振り、観察するPlan-Do-See-Action
統率力も危機管理能力も見事だ
シータみたいなション弁くさい小娘とは価値が違う
統率力も危機管理能力も見事だ
シータみたいなション弁くさい小娘とは価値が違う
よし、ドーラの行動をPM的観点で評価してみようじゃないか
ラピュタの位置に関してシータから聞けるだけのことを聞いてしまうと、
成功の可能性とリスク、リターンを冷静に計算している。
プロジェクトの短期目標を設定し、メンバー全員に対し明確に伝えている。
インセンティブを示してモチベーション向上を図っている。
たったこれだけのことすら出来ていないPMがなんと多いことか！
ラピュタの位置に関してシータから聞けるだけのことを聞いてしまうと、
成功の可能性とリスク、リターンを冷静に計算している。
プロジェクトの短期目標を設定し、メンバー全員に対し明確に伝えている。
インセンティブを示してモチベーション向上を図っている。
たったこれだけのことすら出来ていないPMがなんと多いことか！
ブルックスの法則に従い、経験の浅い二人をチームに参加させることは
本来危険であった。
ドーラがとった戦術は、シータを間接業務に回すことで主力の業務負荷を軽減し、
同時に主力に「持ち場を離れるな」と伝えることであった。
プロジェクトの生産性は向上し、さらに「若い女」で釣ることでメンバーの
モチベーションコントロールも狙ったのである。
見事なマネジメントであると言える。
しかしパズーの扱いにはドーラも躊躇したのではないか。
このガキはまったくの役立たずに終わるどころか、足を引っ張る危険もあった。
さっさと突き落としたいのが本音だったろう。
本来危険であった。
ドーラがとった戦術は、シータを間接業務に回すことで主力の業務負荷を軽減し、
同時に主力に「持ち場を離れるな」と伝えることであった。
プロジェクトの生産性は向上し、さらに「若い女」で釣ることでメンバーの
モチベーションコントロールも狙ったのである。
見事なマネジメントであると言える。
しかしパズーの扱いにはドーラも躊躇したのではないか。
このガキはまったくの役立たずに終わるどころか、足を引っ張る危険もあった。
さっさと突き落としたいのが本音だったろう。
もう一つ見逃せないのは、ドーラの枕元に設定された伝声管の束である
これは、ドーラが「観察」の重要性を強く意識し
それをシステム的に支援する装置を整えていたことを意味する。
マネジメントの本質を理解し、周到な用意を張り巡らせるマネージャ。
「勝つべくして勝つ」
ドーラに率いられているからこそ、部下はいつまでも子供（馬鹿）でいられるのである。
いや、勉強になったなぁ
これは、ドーラが「観察」の重要性を強く意識し
それをシステム的に支援する装置を整えていたことを意味する。
マネジメントの本質を理解し、周到な用意を張り巡らせるマネージャ。
「勝つべくして勝つ」
ドーラに率いられているからこそ、部下はいつまでも子供（馬鹿）でいられるのである。
いや、勉強になったなぁ
どうでもいいけどブルックスの法則とは全然状況が違うよ。
ブルックスの法則って「遅れているプロジェクトに増員するとますます遅れる」ってやつ？
人増えて遅れるわけないじゃん。
要は使い方だよ。
要は使い方だよ。
>>95
引き継ぎだの何だのと迎える用意だけに時間を割いて遅れないわけないじゃん
引き継ぎだの何だのと迎える用意だけに時間を割いて遅れないわけないじゃん
>>95
はぁ？
はぁ？
>95は単なるネジとか歯車だから、
コミュニケーションコストの増大とか考える必要がないんだよ
コミュニケーションコストの増大とか考える必要がないんだよ
お前等作業手順書も作れないのかよｗ
プロジェクトの開発ルールは脳内とか？
高度な作業なんて全体の３割くらいの人間が出来ればいいんだから、
後の人間を簡単なコーディングやテスト要員として単純作業化すればいいんだよ。
お前等大きいプロジェクトやった事無いんですか？
プロジェクトの開発ルールは脳内とか？
高度な作業なんて全体の３割くらいの人間が出来ればいいんだから、
後の人間を簡単なコーディングやテスト要員として単純作業化すればいいんだよ。
お前等大きいプロジェクトやった事無いんですか？
>>99
どうせ、大規模案件で下流のコーディング要員か何かの経験者なんだろうけど。
人手が足らない＝大きい案件とは限らないんだよ、坊や。
複数案件を同時に走らせてる場合は、小規模案件でも人手不足になるとお分かりかね?
残念だけど、小規模案件を複数走らせてる状態で、
>高度な作業なんて全体の３割くらいの人間が出来ればいいんだから、
>後の人間を簡単なコーディングやテスト要員として単純作業化すればいいんだよ。
そんな戯言は通じねえんだよ。
どうせ、大規模案件で下流のコーディング要員か何かの経験者なんだろうけど。
人手が足らない＝大きい案件とは限らないんだよ、坊や。
複数案件を同時に走らせてる場合は、小規模案件でも人手不足になるとお分かりかね?
残念だけど、小規模案件を複数走らせてる状態で、
>高度な作業なんて全体の３割くらいの人間が出来ればいいんだから、
>後の人間を簡単なコーディングやテスト要員として単純作業化すればいいんだよ。
そんな戯言は通じねえんだよ。
猫の手を借りる程度の作業にしても
人間様は高くつくからな
人間様は高くつくからな
>>99
>後の人間を簡単なコーディングやテスト要員として単純作業化すればいいんだよ。
そういうワーカーの不足なんて大した事じゃないんだよ。
>高度な作業なんて全体の３割くらいの人間が出来ればいいんだから、
こういう人間が足りないの。
君みたいな類猿人じゃなくて、人間がね。
本当に仕事した事あるのか?
>後の人間を簡単なコーディングやテスト要員として単純作業化すればいいんだよ。
そういうワーカーの不足なんて大した事じゃないんだよ。
>高度な作業なんて全体の３割くらいの人間が出来ればいいんだから、
こういう人間が足りないの。
君みたいな類猿人じゃなくて、人間がね。
本当に仕事した事あるのか?
106 ：仕様書無しさん：04/12/26 14:44:46
>103
そうなんだよね。
知恵をもって動いてくれる人がいないと烏合の衆に
なっちゃうんだよね。
小規模プロジェクトで、自分だけで何とかなるうちは
それでいいけど、いくつも掛け持っていたり、大規模に
なってくると、自分で「考えて動ける」人が必要なんだよね。
そうなんだよね。
知恵をもって動いてくれる人がいないと烏合の衆に
なっちゃうんだよね。
小規模プロジェクトで、自分だけで何とかなるうちは
それでいいけど、いくつも掛け持っていたり、大規模に
なってくると、自分で「考えて動ける」人が必要なんだよね。
107 ：仕様書無しさん：04/12/26 14:59:23
俺の会社の上司はメチャクチャデジタル的な考え方で困る。
あるプロジェクトが顧客との話がまとまらずに仕様段階で
停滞していた。それを上司に相談すると今の遅れは２０日程度だろ？
それなら新人１人つけるようにするからそれで対応できるだろ。
・・・はぁ？新人に何させるんだ？大体今の仕様を教えるだけでも
俺の工数取られるだろ！ってマジに言いたかった。
でもシステム開発部の部長なんだよな・・・
あるプロジェクトが顧客との話がまとまらずに仕様段階で
停滞していた。それを上司に相談すると今の遅れは２０日程度だろ？
それなら新人１人つけるようにするからそれで対応できるだろ。
・・・はぁ？新人に何させるんだ？大体今の仕様を教えるだけでも
俺の工数取られるだろ！ってマジに言いたかった。
でもシステム開発部の部長なんだよな・・・
109 ：石黒 ◆GqbV7Dy5fI ：04/12/26 16:08:58
>>107
なぜ言わなかったんですか？
なぜ言わなかったんですか？
110 ：仕様書無しさん：04/12/26 16:33:38
俺：プログラマも人心掌握術が必要だな
糞：え？ちんちん掌握術！？
糞：え？ちんちん掌握術！？
新人ならまだいいよ。
糞使えない先輩回されてどうすりゃいいんだよ。雰囲気的に
「この先輩だと新人レベルの生産性しか上がらないですよ」
とか言えないから、結局雑用適当に振って無視してるけどいつまで持つやら・・・
糞使えない先輩回されてどうすりゃいいんだよ。雰囲気的に
「この先輩だと新人レベルの生産性しか上がらないですよ」
とか言えないから、結局雑用適当に振って無視してるけどいつまで持つやら・・・
113 ：仕様書無しさん：04/12/27 00:41:10
自分が一番つかいにくいのは、常に後ろ向きな人かな。
調べもせずに
「そんなこと、できるわけないと思います」
「本当にやるのかどうか、お客さんに聞いてもらえますか」
そりゃ、工数と見合わないいうことが分かった時点で
やる／やらないの相談は客とするけど、初めから何の根拠もなしに
できませんって言われると、こっちだって客との調整ができないんだよ。
結局ソース見て自分で調べてたりして、まだまだだなぁ、と思う今日この頃。
調べもせずに
「そんなこと、できるわけないと思います」
「本当にやるのかどうか、お客さんに聞いてもらえますか」
そりゃ、工数と見合わないいうことが分かった時点で
やる／やらないの相談は客とするけど、初めから何の根拠もなしに
できませんって言われると、こっちだって客との調整ができないんだよ。
結局ソース見て自分で調べてたりして、まだまだだなぁ、と思う今日この頃。
>>114
はいはい。
あなたはちっぽけなプロジェクトしか担当したことないんだよ。
全部PMがコードレベルの実現性まで調べてたら、いくら時間があっても
足らないんだよ。
サブとなる信頼できる人を何人最初に確保できるかがポイントだな。
はいはい。
あなたはちっぽけなプロジェクトしか担当したことないんだよ。
全部PMがコードレベルの実現性まで調べてたら、いくら時間があっても
足らないんだよ。
サブとなる信頼できる人を何人最初に確保できるかがポイントだな。
116 ：仕様書無しさん：04/12/27 08:43:56
117 ：仕様書無しさん：04/12/27 09:00:52
コードレベルの実現性って・・・。
ようするに上流設計がなってないっていう。。。
ところで、どれくらいが大規模なプロジェクトなんだ？
コードの行数が１００万行？
プロジェクトのメンバーが１００人？
デービーに１０００万件登録されている？
コードの行数が１００万行？
プロジェクトのメンバーが１００人？
デービーに１０００万件登録されている？
少なくとも１０００万件ってのは関係ないような・・。
>>120
PMから足を洗ってください。
PMから足を洗ってください。
122 ：仕様書無しさん：04/12/27 11:45:31
1000万件登録すれば大規模ですかそうですか。
ということで、部下に糞データ１０００万件でーたべーすに入れる指示。
今日から大規模プロジェクトのＰＭだ！！
今日から大規模プロジェクトのＰＭだ！！
>>124
よかったね。
よかったね。
127 ：仕様書無しさん：04/12/27 13:02:11
俺の感覚だと受注金額かな。10億円越えたら大規模かな。
ちなみに一日500万明細越えの
インタフェースが発生する受発注システム開発は受注金額1500万円だった。
ちなみに一日500万明細越えの
インタフェースが発生する受発注システム開発は受注金額1500万円だった。
128 ：仕様書無しさん：04/12/27 13:20:27
標準プログラマの一年の単価１０００マソだとして、１００人ｘ１２ヶ月
の案件ということ？
の案件ということ？
私的大規模の定義・・・稼動後止めたら、日経新聞そこまでいかなくても日経コンピュータに出れる程度。
世の中いろんな人がいるのね・・・・
131 ：仕様書無しさん：04/12/27 14:18:05
プログラムできない奴が押し出される形で
ＰＭになっちゃうのが一番最悪。
ＰＭになっちゃうのが一番最悪。
>>132
プログラムできないＰＭが脊髄反射レスですか？
プログラムできないＰＭが脊髄反射レスですか？
>>133
あのさ、プログラマからPMが選出される程度のプロジェクトなんて小規模ですよ。
サブシステムのグループマネージャならわかるけど、PMをそこから選ぶ時点でシステムの規模は知れる。
そうじゃなければ、あんたのいる組織がおかしいだけ。
そもそもプログラムと管理じゃ求められる技術が違うんだから。
優秀なプログラマも別にPMとして優秀とは限らないし。
あのさ、プログラマから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の存在など無視しても仕事ができる
・ゆえに小規模プロジェクトにおけるPMの重要度は低い
・逆説的にいえばPGから選出されたPMがいるプロジェクトは小規模である
・結果、PG上がりのPMは重要度が低く、小規模プロジェクトが関の山
・大規模プロジェクトにおけるPMはPG経験などない
・ゆえに大規模プロジェクトにおけるPMの重要度は高い
・逆説的にいえばPG経験のないPMがいるプロジェクトは大規模である
・結果、PG経験なしのPMは重要度が高く、大規模プロジェクトを任される
●逃げ口上
「プログラムができないＰＭって・・・・」
・プログラムと管理は求められる技術が違う
・プログラマとして有能であってもPMとして有能とは限らない
>>135
まとめて頂いたのはなんだけど・・・で？
まとめて頂いたのはなんだけど・・・で？
まあ、実際小規模案件で>>131みたいなことできないけどね、私には。
そんな余裕はない。
大体、小規模案件ならPM兼メインプログラマ兼コーディネータだな。
見積から設計デザインから技術まで全て自分がそのグループじゃNo1。
逆にある程度以上の規模だと、管理者は細かいことやっちゃいかん。
あんたの役目は旗振りだ、交通整理だと自覚してくれ！って。
コード書くのが楽しいのは判るけど、あんたがそれやってたら他が遊んでしまう。
そんな余裕はない。
大体、小規模案件ならPM兼メインプログラマ兼コーディネータだな。
見積から設計デザインから技術まで全て自分がそのグループじゃNo1。
逆にある程度以上の規模だと、管理者は細かいことやっちゃいかん。
あんたの役目は旗振りだ、交通整理だと自覚してくれ！って。
コード書くのが楽しいのは判るけど、あんたがそれやってたら他が遊んでしまう。
138 ：仕様書無しさん：04/12/27 16:11:46
小規模だと、ドラマ「白い巨塔」で財前役のひとの役割がＰＭ。
なんでも自分でやっちゃう。
なんでも自分でやっちゃう。
139 ：仕様書無しさん：04/12/27 16:17:53
で、大規模プロジェクトはどこからＰＭが選ばれるんでしょう？
コンサルとか？
コンサルとか？
大規模って免罪符なのか？
PMとPL勘違いしてる奴居ないか？
144 ：仕様書無しさん：04/12/27 19:14:54
ＰＭとＰＬの違いを述べョ
147 ：仕様書無しさん：04/12/27 22:04:44
149 ：仕様書無しさん：04/12/27 23:13:29
「プログラム経験者」「プログラマ経験者」
笑
笑
なんか前もあったな、この手の話題。
毎度、何人かが熱くなってスレを乱す。
毎度、何人かが熱くなってスレを乱す。
>>134が言ってる通り、マネージメントは違う技術だな
その技術に必要な基礎知識としてプログラミング技術があるかも。
でも「有能なプログラマであることは、有能なマネージャになるにはむしろ不利な条件」
ていう意見もあるね。
その技術に必要な基礎知識としてプログラミング技術があるかも。
でも「有能なプログラマであることは、有能なマネージャになるにはむしろ不利な条件」
ていう意見もあるね。
>>153
「優秀な選手が優秀なコーチ・監督になるわけではない。むしろよくない」みたいな？
でも、プログラミングを知らない人がPGの上に立つのはやめてほしいよ。
優秀なコーチは、元優秀な選手でなかったとしても、普通、「選手」だったはずだよね。
「優秀な選手が優秀なコーチ・監督になるわけではない。むしろよくない」みたいな？
でも、プログラミングを知らない人がPGの上に立つのはやめてほしいよ。
優秀なコーチは、元優秀な選手でなかったとしても、普通、「選手」だったはずだよね。
156 ：仕様書無しさん：04/12/27 23:29:59
157 ：仕様書無しさん：04/12/27 23:31:26
おれがＰＭしてるメンバー全員１２月２３日から１月１２日まで休み取らせた。
まあ会社来たいヤツは来てもいいとつたえてある。
デスマーチにならないように注意しないと。
社会復帰のリハビリがんばれよｗ
まあ会社来たいヤツは来てもいいとつたえてある。
デスマーチにならないように注意しないと。
社会復帰のリハビリがんばれよｗ
158 ：石黒 ◆GqbV7Dy5fI ：04/12/27 23:32:00
この場合はプログラミング経験者と呼ぶべきですよ。
俺がくだらんことを書いたためスマンかった。
もう忘れてくれ。
ところで、マ板ひさしぶりなんだけど、石黒さんて、
昔の八千代市民みたいなキャラの人？
もう忘れてくれ。
ところで、マ板ひさしぶりなんだけど、石黒さんて、
昔の八千代市民みたいなキャラの人？
>>155
う〜ん、はっきり覚えてなくて悪いんだけど
「プログラマとマネージャでは必要とされる資質が違う」
「有能なプログラマには、マネージャとして必要な能力を磨いたり知識を学ぶ機会がほとんどない」
みたいな話だった。
う〜ん、はっきり覚えてなくて悪いんだけど
「プログラマとマネージャでは必要とされる資質が違う」
「有能なプログラマには、マネージャとして必要な能力を磨いたり知識を学ぶ機会がほとんどない」
みたいな話だった。
162 ：仕様書無しさん：04/12/27 23:44:03
>>161
ありゃ、レスありがとう。マ板ってこんなに雰囲気いいところだったっけ．．．。
>「有能なプログラマには、マネージャとして必要な能力を磨いたり知識を学ぶ機会がほとんどない」
それならわかる。賛成。
でも、それなら、PMと有能なPGの金銭的な待遇は同じであるべきだよね。
もちろん無能なPGはあれだけど。（ｗ
ありゃ、レスありがとう。マ板ってこんなに雰囲気いいところだったっけ．．．。
>「有能なプログラマには、マネージャとして必要な能力を磨いたり知識を学ぶ機会がほとんどない」
それならわかる。賛成。
でも、それなら、PMと有能なPGの金銭的な待遇は同じであるべきだよね。
もちろん無能なPGはあれだけど。（ｗ
164 ：石黒 ◆GqbV7Dy5fI ：04/12/27 23:48:22
>>160
八千代市民って誰ですか？
八千代市民って誰ですか？
> でも、それなら、PMと有能なPGの金銭的な待遇は同じであるべきだよね。
「金銭を求めるなら管理など勉強せずに技術に没頭しスーパーハッカーを目指すべき」
だそうな。
アメリカだとそうなのかね〜うらやましい。
元ネタはワインバーグのどれかです。
「金銭を求めるなら管理など勉強せずに技術に没頭しスーパーハッカーを目指すべき」
だそうな。
アメリカだとそうなのかね〜うらやましい。
元ネタはワインバーグのどれかです。
>>162
ヲタクではあるよ。ミニスカスレにもずいぶん書き込んだし。
>>164
失礼。
>>165
なるほど。「アメリカではPGの大リストラが」みたいな記事が目に付くけど、
有能であればいいんだよね。きっと。
眠いのでお休み。続きは明日読むよ。148ってHNはもうやめる。
ヲタクではあるよ。ミニスカスレにもずいぶん書き込んだし。
>>164
失礼。
>>165
なるほど。「アメリカではPGの大リストラが」みたいな記事が目に付くけど、
有能であればいいんだよね。きっと。
眠いのでお休み。続きは明日読むよ。148ってHNはもうやめる。
>>115
客の話聞いてきて、担当に実装上どうかなって聞いたんだろ？
だったら聞く時に、コードレベルの実現性まで調べてから判断してねって言えばいいんじゃない。
設計も実装もできなくてもいい（誰かにやらせればいいから）が、マネージャーなら、せめて仕事を
振ることぐらいやらないと、後どんな仕事するんだ？
客の話聞いてきて、担当に実装上どうかなって聞いたんだろ？
だったら聞く時に、コードレベルの実現性まで調べてから判断してねって言えばいいんじゃない。
設計も実装もできなくてもいい（誰かにやらせればいいから）が、マネージャーなら、せめて仕事を
振ることぐらいやらないと、後どんな仕事するんだ？
ＰＭで自分のプロジェクトの損益分岐点がマイナスになりそうな場合どうします？
俺は自分の残業はサービス残業で茶を濁す・・
俺は自分の残業はサービス残業で茶を濁す・・
ところで当たり前の要に語られてるけど、
PGからPMに抜擢されるって規模に関わらずあり得ないでしょ。
小規模であれば仕事取った営業orSEがPMするか、
そもそもPM専門の管理者が複数プロジェクト兼任してるのが普通。
大規模になるとPM経験者の中から抜擢される。
持ち上がりで上に立つのはサブリーダーくらいまで。じゃね？
PGからPMに抜擢されるって規模に関わらずあり得ないでしょ。
小規模であれば仕事取った営業orSEがPMするか、
そもそもPM専門の管理者が複数プロジェクト兼任してるのが普通。
大規模になるとPM経験者の中から抜擢される。
持ち上がりで上に立つのはサブリーダーくらいまで。じゃね？
ちなみに俺んとこは５年で社員１０倍になった。
会社規模的にも外注に振る身分にまでおっきくなったよ。
おかげでＰＧスルーした自称ＳＥも増えてきた。
会社規模的にも外注に振る身分にまでおっきくなったよ。
おかげでＰＧスルーした自称ＳＥも増えてきた。
>>171
仕事取った営業orSEがそのままPMやって経験積みます。
だから元々顧客とお金のやり取りしてるPGならなってもいいけど、
昨日までJava組んでました〜みたいなPGがシフトするのは無いと・・・思ってた。あるの？
仕事取った営業orSEがそのままPMやって経験積みます。
だから元々顧客とお金のやり取りしてるPGならなってもいいけど、
昨日までJava組んでました〜みたいなPGがシフトするのは無いと・・・思ってた。あるの？
>>173
大量の偽装派遣に彩られた典型的な違法ビジネスモデルですね。
大量の偽装派遣に彩られた典型的な違法ビジネスモデルですね。
>>176
>昨日までJava組んでました〜みたいなPGがシフトするのは無いと・・・思ってた。あるの？
さすがにそれはない。
新人（ＳＥ）が行き成り客の前に躍り出るぐらいありえない。
ステップとしては
・ＰＧが電話またはメールで直接顧客と
（ささいなこと）の仕様調整（→追って社内ＭＴＧ）
・顧客とのＭＴＧに顔出し（居るだけ）
・見積もり、設計、スケジュールの試算（練習として）
・部下（後輩）への指示出し、割り振り
・その他色々
ま、普通の新人ＳＥと同じだね。
できるＰＧで且つＳＥ（またはＰＭ）特性あると
設計、スケジュールに関しては多少安心できる。
ついでに、出来るか出来ないかの
判断でも差がでる。
>178
パッケージが売れちゃたんだよ。あとWeb系も
早くからやってから、そこそこの案件が
元クライアントと仲いい会社から直接来るようになった。
>昨日までJava組んでました〜みたいなPGがシフトするのは無いと・・・思ってた。あるの？
さすがにそれはない。
新人（ＳＥ）が行き成り客の前に躍り出るぐらいありえない。
ステップとしては
・ＰＧが電話またはメールで直接顧客と
（ささいなこと）の仕様調整（→追って社内ＭＴＧ）
・顧客とのＭＴＧに顔出し（居るだけ）
・見積もり、設計、スケジュールの試算（練習として）
・部下（後輩）への指示出し、割り振り
・その他色々
ま、普通の新人ＳＥと同じだね。
できるＰＧで且つＳＥ（またはＰＭ）特性あると
設計、スケジュールに関しては多少安心できる。
ついでに、出来るか出来ないかの
判断でも差がでる。
>178
パッケージが売れちゃたんだよ。あとWeb系も
早くからやってから、そこそこの案件が
元クライアントと仲いい会社から直接来るようになった。
MTGって何だ？
>>181
一人でやってたのが十人に増えた。ただそれだけ。
一人でやってたのが十人に増えた。ただそれだけ。
185 ：仕様書無しさん：04/12/28 01:14:13
>>180
ミーティング。略語使いこなす出来るＰＭになれ！
ミーティング。略語使いこなす出来るＰＭになれ！
>>185
略語の前に日本語使いこなそうな。
略語の前に日本語使いこなそうな。
187 ：仕様書無しさん：04/12/28 01:22:05
>>186
漏れもプルグラム経験者といっしょか？詩悩！！煎ってくる！
漏れもプルグラム経験者といっしょか？詩悩！！煎ってくる！
Magic The Gathering かと思った。
受け手のレベルを度外視して、意志の疎通を妨げるような
略語を発するのは出来るPMとは言いませんよ。
略語を発するのは出来るPMとは言いませんよ。
>>185
,ｨｨr-- ..__､j
ﾙ! { ｀ヽ, ∧
N { l ` ,、 i ＿|＼/ ∨ ∨
ゝヽ _,,ｨjjハ、 | ＼ 俺たちはだまされていたんだ。
`ニr‐tﾐ-rr‐ｔｭ<≧rﾍ >
{___,ﾘ ヽ二´ﾉ }ｿ ∠ ＭＴＧとは、ギャザの事だったんだよ！！
'､ `,-_-ｭ u /| ∠
ヽ`┴ ' ／／l＼ |／＼∧ /
--─‐ｧ'| ｀ニ--‐'´ / |`ｰ ..__ `´
く__レ1;';';';>､ / __ | ,=､ ___
「 ∧ 7;';';'| ヽ/ _,|‐､|」 |Ｌ..! {L..l ))
| |::.V;';';';'| /.:.|トl｀´.! l _,,,ｌ | _,,| , -,
! |:.:.:l;;';';';'|/.:.:.:||=|=; | | | | .l / 〃 ))
l |:.:.:.:l;';';'/.:.:.:.:| ! ヽ ＼!‐=:l/ `:lj 7
| |:.:.:.:.l;'/.:.:.:.:.:.! ヽ:::＼:: ::::| ::l /
,ｨｨr-- ..__､j
ﾙ! { ｀ヽ, ∧
N { l ` ,、 i ＿|＼/ ∨ ∨
ゝヽ _,,ｨjjハ、 | ＼ 俺たちはだまされていたんだ。
`ニr‐tﾐ-rr‐ｔｭ<≧rﾍ >
{___,ﾘ ヽ二´ﾉ }ｿ ∠ ＭＴＧとは、ギャザの事だったんだよ！！
'､ `,-_-ｭ u /| ∠
ヽ`┴ ' ／／l＼ |／＼∧ /
--─‐ｧ'| ｀ニ--‐'´ / |`ｰ ..__ `´
く__レ1;';';';>､ / __ | ,=､ ___
「 ∧ 7;';';'| ヽ/ _,|‐､|」 |Ｌ..! {L..l ))
| |::.V;';';';'| /.:.|トl｀´.! l _,,,ｌ | _,,| , -,
! |:.:.:l;;';';';'|/.:.:.:||=|=; | | | | .l / 〃 ))
l |:.:.:.:l;';';'/.:.:.:.:| ! ヽ ＼!‐=:l/ `:lj 7
| |:.:.:.:.l;'/.:.:.:.:.:.! ヽ:::＼:: ::::| ::l /
191 ：仕様書無しさん：04/12/28 06:39:40
ストレスを溜めない秘訣は
人に期待しないことだと知りました
人に期待しないことだと知りました
ミーティングをMTGって略す意味あるのか？
字面半分だけど読んでみるとかえって長くね？
字面半分だけど読んでみるとかえって長くね？
MTGとか発想がアホ女子高生並
若くて未来がある分、女子高生の方がましだな
若くて未来がある分、女子高生の方がましだな
おれの会社略語ばっかり・・・・
ＭＴＧ・・・ミーティング
ＭＬ・・・ミーティングルーム
部長・・・Ｂ
課長・・・Ｃ
ＭＴＧ・・・ミーティング
ＭＬ・・・ミーティングルーム
部長・・・Ｂ
課長・・・Ｃ
195 ：仕様書無しさん：04/12/28 09:56:53
ＭＬはメーリングリストだボケ！
あと、課長はＫ、係長はＣ。
アホっぽいから口に出して言うな、議事録に書け！
あと、課長はＫ、係長はＣ。
アホっぽいから口に出して言うな、議事録に書け！
ML＝みーちんぐるーむ・・・”Ｌ”はどこからきたのでしょうか？
198 ：仕様書無しさん：04/12/28 10:30:21
>>197
ねたに混じレスかっこ悪い
ねたに混じレスかっこ悪い
ガチ間違いした奴ほどネタにしたがる罠
200 ：仕様書無しさん：04/12/28 10:42:18
>>199
ネタにまじれすかっこ悪い罠
ネタにまじれすかっこ悪い罠
日本を代表する電機メーカーのPMだかSE崩れが漏れの会社に流れてきて
重役やってんだけど、最悪だよ。なんだか「俺仕様」でがっちり書類作るんだけど、
読む気もおきんよーなもん。自分も、規則表やら進行表作っただけで満足らしく、
もう自分でも読んでないようだけど。でも、たまーに、地雷のように、「あいつは、
すでに発効している規則○○に従っていないから昇給は見送りだ」とか言ってる
らしい。これは、自分の作った規則表が守られているか見てるんじゃなくて、
気に入らない奴にムリヤリあてはめてる様子。
現場の士気が下がりまくり。最近はあんなのを採用した社長への憎しみにもなってる。
重役やってんだけど、最悪だよ。なんだか「俺仕様」でがっちり書類作るんだけど、
読む気もおきんよーなもん。自分も、規則表やら進行表作っただけで満足らしく、
もう自分でも読んでないようだけど。でも、たまーに、地雷のように、「あいつは、
すでに発効している規則○○に従っていないから昇給は見送りだ」とか言ってる
らしい。これは、自分の作った規則表が守られているか見てるんじゃなくて、
気に入らない奴にムリヤリあてはめてる様子。
現場の士気が下がりまくり。最近はあんなのを採用した社長への憎しみにもなってる。
>>201
憎しむ前に社長に状況説明しろよ
憎しむ前に社長に状況説明しろよ
>>202
小さな会社なんだけど、社長は「雲の上の人」でね。
人事関係の進言をことのほか嫌う。
「あなたが抜擢したあれバカですよ」と言ってもこっちが憎まれる。
つーか、俺はそのバカに嫌われて、したがって社長にもにらまれてるんだと思う。
社長自身、二代目さんで、仕事できない人なので、どの部下がほんとに仕事できるか
わからんらしい。で、人事権だけが拠り所だから、その手の批判は許さんらしい。
小さな会社なんだけど、社長は「雲の上の人」でね。
人事関係の進言をことのほか嫌う。
「あなたが抜擢したあれバカですよ」と言ってもこっちが憎まれる。
つーか、俺はそのバカに嫌われて、したがって社長にもにらまれてるんだと思う。
社長自身、二代目さんで、仕事できない人なので、どの部下がほんとに仕事できるか
わからんらしい。で、人事権だけが拠り所だから、その手の批判は許さんらしい。
辞めるのが得策だね。
205 ：仕様書無しさん：04/12/29 00:10:20
自分に対する不満を耳にした時、ふと孤独感にさいなまれる事がある。
精神的に安定したい・・・。
精神的に安定したい・・・。
不安になること多いよな。
作業少なくても時間はまちまちだし、評価ってダイレクトに得られないし。
中間管理職の辛さと経営の重圧を両方背負って一人で労働している気分wwwwww
作業少なくても時間はまちまちだし、評価ってダイレクトに得られないし。
中間管理職の辛さと経営の重圧を両方背負って一人で労働している気分wwwwww
>>167
もういまさらなんだが・・・。
できない理由が聞いたのだが、既存のプログラムの改修作業で
調査するソースが多くて調べるのが大変だから
そんなことはできません（やりたくありません）という回答だったので困った、
ということを言いたかっただけ。
調べるのにどのくらいかかるのかと聞いたら、それを見積もるだけでもっと時間が
かかりますと言われ、ちょっと急ぎだったから自分でソースを見て時間を見積もった
ということだよ。
自分でソースを見たことが良かったとは決して言わないが、
やりたくないからできません的な回答をされると、ちょっとね、ということを言おうと
思ったのだけど、言葉が足りなかったね。
もういまさらなんだが・・・。
できない理由が聞いたのだが、既存のプログラムの改修作業で
調査するソースが多くて調べるのが大変だから
そんなことはできません（やりたくありません）という回答だったので困った、
ということを言いたかっただけ。
調べるのにどのくらいかかるのかと聞いたら、それを見積もるだけでもっと時間が
かかりますと言われ、ちょっと急ぎだったから自分でソースを見て時間を見積もった
ということだよ。
自分でソースを見たことが良かったとは決して言わないが、
やりたくないからできません的な回答をされると、ちょっとね、ということを言おうと
思ったのだけど、言葉が足りなかったね。
困る前に叱れ
>>209
なんで？
なんで？
>>211
自演乙
自演乙
>>211
まさに自演乙ですね。
まさに自演乙ですね。
「というわけでお前等３日から出勤な。」
と決断した俺は嫌われたんだろうなぁ。鬱だなぁ。
と決断した俺は嫌われたんだろうなぁ。鬱だなぁ。
>>212
釣られんなよｗ
釣られんなよｗ
>213
なぜそういう決断に至ったかが問題では？
そうならない様に最大限努力した？
結局、PMとしてマネージメントして要員が働き易い環境を整えたかどうかに因ると思う
# その苦労を分かってくれないんだよねぇ、上も下も┐(´ー｀)┌
なぜそういう決断に至ったかが問題では？
そうならない様に最大限努力した？
結局、PMとしてマネージメントして要員が働き易い環境を整えたかどうかに因ると思う
# その苦労を分かってくれないんだよねぇ、上も下も┐(´ー｀)┌
>>207
そりゃあれだな。
まず、お前に説明・説得するのが面倒でそんな言葉使ってるんだと思うぞ。
お前のアプローチの仕方も悪いな。
俺がそいつでもお前の言ってることは「とりあえずやれ」に聞こえる。
要するにそいつってそのプログラムがよくわかってねぇんだろ。
それはお前も理解してるだろ？
そいつの状態としては「このプログラムがよくわかって無い」状態なわけだ。
それなのにお前はよくわかって無い人間にたいして
「調べるのにどれくらいかかるのか？」とかきいてしまっている。
わかるわけないだろ。
こんな会話してるとそのうち部下に逃げられちゃうぞ。
そりゃあれだな。
まず、お前に説明・説得するのが面倒でそんな言葉使ってるんだと思うぞ。
お前のアプローチの仕方も悪いな。
俺がそいつでもお前の言ってることは「とりあえずやれ」に聞こえる。
要するにそいつってそのプログラムがよくわかってねぇんだろ。
それはお前も理解してるだろ？
そいつの状態としては「このプログラムがよくわかって無い」状態なわけだ。
それなのにお前はよくわかって無い人間にたいして
「調べるのにどれくらいかかるのか？」とかきいてしまっている。
わかるわけないだろ。
こんな会話してるとそのうち部下に逃げられちゃうぞ。
217 ：デフォルトの名無しさん：04/12/31 06:14:11
PMじゃないんですがPLについてお尋ねします。
今のプロジェクトのPLなんですが、成果物を一切見ようとしなくて
メンバに出来たかどうかを聞くだけでPMに報告してるんですが、それって
普通なんですか？
私は新人なんですが、おかしいのではないかなと思うんですよ。
今のプロジェクトのPLなんですが、成果物を一切見ようとしなくて
メンバに出来たかどうかを聞くだけでPMに報告してるんですが、それって
普通なんですか？
私は新人なんですが、おかしいのではないかなと思うんですよ。
>>217
えーと、まあどっちにしても不満は出ると思うが・・・。
新人とはいえ大人だから成果物には責任を持たせるべきって考えと、
まあ単なる無責任の可能性と。
といいつつ、いちいち見られてもそれはそれでうざいんだけど。
えーと、まあどっちにしても不満は出ると思うが・・・。
新人とはいえ大人だから成果物には責任を持たせるべきって考えと、
まあ単なる無責任の可能性と。
といいつつ、いちいち見られてもそれはそれでうざいんだけど。
219 ：仕様書無しさん：04/12/31 08:50:28
成果物チェックは
何回も同じプロジェクトを経験して
信頼できるPGならほぼノーチェックだな。
初めてプロジェクトが同じになる場合は
時間をかけて誤字、脱字チェックから入るな。
まぁ大体、使える、使えないという
評価は噂で聞いてるから、
使える新人と思われているんじゃないのか。
何回も同じプロジェクトを経験して
信頼できるPGならほぼノーチェックだな。
初めてプロジェクトが同じになる場合は
時間をかけて誤字、脱字チェックから入るな。
まぁ大体、使える、使えないという
評価は噂で聞いてるから、
使える新人と思われているんじゃないのか。
>>217
ノートラブルで回っている内はいいけど、１つでも納品後に問題起きたら、信頼が地に落ちるヨ。そんなことしてるとね。
レビューしたって見逃す障害要因ってのは多いけどさ。形式的にでもやっとけば、何か起きたときの予防線くらいにはなる。
１人のPGを切る程度で済めばいいけど、体制そのものがまずいと判断されたら、全員の評価に影響するんだよね（苦笑）
ノートラブルで回っている内はいいけど、１つでも納品後に問題起きたら、信頼が地に落ちるヨ。そんなことしてるとね。
レビューしたって見逃す障害要因ってのは多いけどさ。形式的にでもやっとけば、何か起きたときの予防線くらいにはなる。
１人のPGを切る程度で済めばいいけど、体制そのものがまずいと判断されたら、全員の評価に影響するんだよね（苦笑）
>>217
ＰＭ、ＰＬ、ＰＧと何でもやっていますが、
ＰＬをやる時には、単体レベルでの「できました」については
あまりというか、殆どチェックしません。
人に応じてヤバそうな人のはチェックするけど。
平行して実施している結合テストで機能面から
チェックしているから、あんまり問題も無いけどね。
個人的な感想としては、テストが下手な奴が
ＰＬやってるプロジェクトは発火している気がする。
ＰＭ、ＰＬ、ＰＧと何でもやっていますが、
ＰＬをやる時には、単体レベルでの「できました」については
あまりというか、殆どチェックしません。
人に応じてヤバそうな人のはチェックするけど。
平行して実施している結合テストで機能面から
チェックしているから、あんまり問題も無いけどね。
個人的な感想としては、テストが下手な奴が
ＰＬやってるプロジェクトは発火している気がする。
最終的なチェックはPLがするもんだと思ってるんだけど漏れの勘違い？
つーか、漏れが工程管理から実装までしているだから、最後のチェック位しろよというのは贅沢？
どーせ、最初と最後しかこねーで、メールの進捗報告でごまかしているんだから、
最後のケツ位もてよと思うのは間違いか？
・・・あんたがちょこっと受け持ったとこだけバグでてんだよ。
あんた何やってんの？で、今までの所業、全部客からばらされてやガンの・・・。
・・・いや、最終で全チェックしたの漏れだけど、あんたん所だけはやってないよ？
全部自分でかかえこんでて、当日渡されてチェックできるかっていうの。
という事態がありました。
漏れの意見的にはPLには無理にでもチェックさせましょう。
つーか、最近は客にも無理にチェックしてもらってます。
本当に痛い目にあうと、客も良い意味でも悪い意味でも学習する。
つーか、漏れが工程管理から実装までしているだから、最後のチェック位しろよというのは贅沢？
どーせ、最初と最後しかこねーで、メールの進捗報告でごまかしているんだから、
最後のケツ位もてよと思うのは間違いか？
・・・あんたがちょこっと受け持ったとこだけバグでてんだよ。
あんた何やってんの？で、今までの所業、全部客からばらされてやガンの・・・。
・・・いや、最終で全チェックしたの漏れだけど、あんたん所だけはやってないよ？
全部自分でかかえこんでて、当日渡されてチェックできるかっていうの。
という事態がありました。
漏れの意見的にはPLには無理にでもチェックさせましょう。
つーか、最近は客にも無理にチェックしてもらってます。
本当に痛い目にあうと、客も良い意味でも悪い意味でも学習する。
プロジェクトの規模によってPMかPLか、サブのリーダかは変わるけど、
成果物については必ず作成者以外の誰かが一度はチェックするのが普通です。
どれだけスキルの高い人間にだってミスや認識違いはあるし、
「PGへの信頼」を理由にチェックを怠るのは、
「PGからの信頼」を裏切る怠慢行為です。
>>221結合テスト段階からのチェックでは機能面、品質面で手遅れだと思うんですが・・・
成果物については必ず作成者以外の誰かが一度はチェックするのが普通です。
どれだけスキルの高い人間にだってミスや認識違いはあるし、
「PGへの信頼」を理由にチェックを怠るのは、
「PGからの信頼」を裏切る怠慢行為です。
>>221結合テスト段階からのチェックでは機能面、品質面で手遅れだと思うんですが・・・
「チェック」が「良い物作る為の共同作業」なプロジェクトは成功するし、
「チェック」が「私利を守る為の交渉作業」なプロジェクトは失敗する。
「チェック」が「私利を守る為の交渉作業」なプロジェクトは失敗する。
>>223
コーディング→単体テスト→結合テスト
という順番でやる結合テストなら、確かに手遅れだよね。
経験上、痛い目にたくさん遭ってる。
アサインの問題で、結合テスト時には作った人が
いなくて、結局、自分で直した事もやっぱりあるよ。
「平行して実施している」と書いたのは、
コーディングの初期時点から、結合テストも実施しているのですよ。
なので、理想的にいけば、単体テスト、結合テストまで
同時に終わるのです。
いわば、ロジックレベルでの単体テストと、
システムの仕様、機能、品質面からの結合テストとの
はさみうちを日々、やる感じですね。
なので、ヤバそうな人というのは、単にその人のスキルだけの
問題ではなく、仕様、機能、品質面から、重要かつ難易度が高い箇所から
優先的に早い段階で潰して行ってます。
長文、失礼しました。
けど、他にもこんな感じでお仕事してる人っているかしら？
という興味から、書いてみました。
コーディング→単体テスト→結合テスト
という順番でやる結合テストなら、確かに手遅れだよね。
経験上、痛い目にたくさん遭ってる。
アサインの問題で、結合テスト時には作った人が
いなくて、結局、自分で直した事もやっぱりあるよ。
「平行して実施している」と書いたのは、
コーディングの初期時点から、結合テストも実施しているのですよ。
なので、理想的にいけば、単体テスト、結合テストまで
同時に終わるのです。
いわば、ロジックレベルでの単体テストと、
システムの仕様、機能、品質面からの結合テストとの
はさみうちを日々、やる感じですね。
なので、ヤバそうな人というのは、単にその人のスキルだけの
問題ではなく、仕様、機能、品質面から、重要かつ難易度が高い箇所から
優先的に早い段階で潰して行ってます。
長文、失礼しました。
けど、他にもこんな感じでお仕事してる人っているかしら？
という興味から、書いてみました。
>>225
ちゃんとモジュール単位で分割できる構造でなきゃ、その手法にも意味がないけどねw
下手すると、モジュールが信用できないのに、なんで結合の方はOKなんだ?と叩かれることになりがち。
Notesなんか、モジュール単位もへったくれもなくて、モジュール単位がOKにならないと結合なんかできない場合も多いよw
その意味では、ソースがテキストファイルで成り立つ開発現場がうらやましいね。
ちゃんとモジュール単位で分割できる構造でなきゃ、その手法にも意味がないけどねw
下手すると、モジュールが信用できないのに、なんで結合の方はOKなんだ?と叩かれることになりがち。
Notesなんか、モジュール単位もへったくれもなくて、モジュール単位がOKにならないと結合なんかできない場合も多いよw
その意味では、ソースがテキストファイルで成り立つ開発現場がうらやましいね。
>>226
そうね。確かに開発環境というか、言語の特性に依存する面も多いかもね。
あと、大規模なシステムだと、上手く行くのかな？という気もしてます。
まぁ、偉そうに書いたけど、担当しているのが基本的に小規模な
プロジェクトが多いので、こんな感じが良いのかなと改善しながらやってます。
そうね。確かに開発環境というか、言語の特性に依存する面も多いかもね。
あと、大規模なシステムだと、上手く行くのかな？という気もしてます。
まぁ、偉そうに書いたけど、担当しているのが基本的に小規模な
プロジェクトが多いので、こんな感じが良いのかなと改善しながらやってます。
>>217
そのPLは、成果物の責任をとらないって事じゃない。
とりあえずは、レビューしてくれって頼んでみては。
だめなら、最低でも他のメンバーとのレビュー等の工数をもらっとくの。
無責任な人間は、部下が勝手に動くと、過剰な反応をするから要注意ですよ。
そのPLは、成果物の責任をとらないって事じゃない。
とりあえずは、レビューしてくれって頼んでみては。
だめなら、最低でも他のメンバーとのレビュー等の工数をもらっとくの。
無責任な人間は、部下が勝手に動くと、過剰な反応をするから要注意ですよ。
最近、まで火ダルマプロジェクトのリーダーやってましたよ
年末にようやく目処がついて年明けにはカットオーバーできそうなんだけど
うちの失敗は、立ち上げに失敗したことに尽きると思うのですよ
プログラマーやSEがドウコウよりも
そもそも何を作るのかさっぱりわかんない
マネージャーはスケジュールだけ決めてきたんだけど
期間短縮の為に要件定義は詳細設計やりながらっって・・・
突っ込みどころおおすぎて・・・
概設は省略とか言ってるし
どこかで聞きかじってきた新しい開発手法らしいが
メンバーがついていけるかどうかを考慮せず勝手に顧客と盛り上がって決めてくるのはいかがなものかと
おかげでデスマのうえに五億の赤字
サブマネージャーは失踪するし
実験的なことは、もっと小さい案件でやってくれ
というか早く会社に報告してくれ、俺は知らんぞ、どうなっても
つうわけで、部長にチクって逃げました
年末にようやく目処がついて年明けにはカットオーバーできそうなんだけど
うちの失敗は、立ち上げに失敗したことに尽きると思うのですよ
プログラマーやSEがドウコウよりも
そもそも何を作るのかさっぱりわかんない
マネージャーはスケジュールだけ決めてきたんだけど
期間短縮の為に要件定義は詳細設計やりながらっって・・・
突っ込みどころおおすぎて・・・
概設は省略とか言ってるし
どこかで聞きかじってきた新しい開発手法らしいが
メンバーがついていけるかどうかを考慮せず勝手に顧客と盛り上がって決めてくるのはいかがなものかと
おかげでデスマのうえに五億の赤字
サブマネージャーは失踪するし
実験的なことは、もっと小さい案件でやってくれ
というか早く会社に報告してくれ、俺は知らんぞ、どうなっても
つうわけで、部長にチクって逃げました
新年から出勤しているＰＭあげ
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
テスト
>>225
単体テスト＝モジュール（クラス？）に対するテストと考えて、
２つ以上のモジュールが絡むテストは結合テストと置いてるわけですか？
つまり 単体テスト完了→他と結合テスト みたいな流れって事で合ってる？
であれば、単体テストと同程度行う結合テストの
チェックが出来てるみたいなので問題は少なそうですね。
ただ、ソースコードレベルの品質はその段階では見えないですよね？
バグは出なくても品質の低いコードが増えて後で問題になったりしませんか？
単体テスト＝モジュール（クラス？）に対するテストと考えて、
２つ以上のモジュールが絡むテストは結合テストと置いてるわけですか？
つまり 単体テスト完了→他と結合テスト みたいな流れって事で合ってる？
であれば、単体テストと同程度行う結合テストの
チェックが出来てるみたいなので問題は少なそうですね。
ただ、ソースコードレベルの品質はその段階では見えないですよね？
バグは出なくても品質の低いコードが増えて後で問題になったりしませんか？
orz
236 ：「!omikuji」：05/01/02 11:41:08
orz
ほえー
orz
PMの人たちに聞きたいのですが、ソースレビューってやってますでしょうか？
経験上、どうも単体テストとか徹底してやることよりも、
しっかりソースレビューやった方が効率的のような気がしていて・・・。
>234 にあるように、ソースの品質って、単体で場当たり的な対応してると
あるクラスがダメになっていって、で、クラス間のインターフェースとかがまた
ダメになって、もうダメダメシステムになってしまう危険性があると思います。
Cでソースレビューしたことあって、HarberCとか使って一覧できて
すごく効果的にできた経験あるんだけど、
JAVAとかになるとソースの構成上かなり一覧しずらくて
やりづらい部分があるような気がします。
JAVAでソースレビューやっている人はいますでしょうか？
経験上、どうも単体テストとか徹底してやることよりも、
しっかりソースレビューやった方が効率的のような気がしていて・・・。
>234 にあるように、ソースの品質って、単体で場当たり的な対応してると
あるクラスがダメになっていって、で、クラス間のインターフェースとかがまた
ダメになって、もうダメダメシステムになってしまう危険性があると思います。
Cでソースレビューしたことあって、HarberCとか使って一覧できて
すごく効果的にできた経験あるんだけど、
JAVAとかになるとソースの構成上かなり一覧しずらくて
やりづらい部分があるような気がします。
JAVAでソースレビューやっている人はいますでしょうか？
>>239
ソースレビューは、新人のＯＪＴの一環か、パフォーマンスのチューニングでしか行わないよ。
ソースレベルで、設計の妥当性を判定してるように伺えるが、それってまじめにやると大変でしょ。
とてもじゃないが、実装方針をＵＭＬや文章で提示してもらわないと、時間が掛かってしょうがないのよ。
だから、うちは設計書と単体テストの項目レビューに力を入れているよ。
ソースレビューは、新人のＯＪＴの一環か、パフォーマンスのチューニングでしか行わないよ。
ソースレベルで、設計の妥当性を判定してるように伺えるが、それってまじめにやると大変でしょ。
とてもじゃないが、実装方針をＵＭＬや文章で提示してもらわないと、時間が掛かってしょうがないのよ。
だから、うちは設計書と単体テストの項目レビューに力を入れているよ。
<240
いやあね、普通そういうやり方だと思うけれど
単体テストで全ケースの入力系を試すのが理想だけど、どこまで完璧にやるかって
のがあって、ある程度テストパターンをしぼってでも
ソースレベルの品質を上げることの方が重要かな？ってことなのね。
また設計書から見た視点とソースから見る視点とが違う場合は、
そこから、必要なテストパターンが見えてくることもあると思うし。
プログラマの訓練にもなるしね。
たまにソース見てケチつけたりすると、
ひどくこだわりを持ったPGがいたりしてキレたりするのね。
そういうPGの個性というか柔軟性とか将来性を見抜くためにも良い気がする。
信頼できるPGの場合は、ソースレビューはやらなくて大丈夫だけど・・・。
いやあね、普通そういうやり方だと思うけれど
単体テストで全ケースの入力系を試すのが理想だけど、どこまで完璧にやるかって
のがあって、ある程度テストパターンをしぼってでも
ソースレベルの品質を上げることの方が重要かな？ってことなのね。
また設計書から見た視点とソースから見る視点とが違う場合は、
そこから、必要なテストパターンが見えてくることもあると思うし。
プログラマの訓練にもなるしね。
たまにソース見てケチつけたりすると、
ひどくこだわりを持ったPGがいたりしてキレたりするのね。
そういうPGの個性というか柔軟性とか将来性を見抜くためにも良い気がする。
信頼できるPGの場合は、ソースレビューはやらなくて大丈夫だけど・・・。
実装方法に関するドキュメント見て設計品質が上がると思うのは初心者だろ。
大抵のプログラマにとって、プログラム設計書は単なる体裁なんだから。
大抵のプログラマにとって、プログラム設計書は単なる体裁なんだから。
>>241
＞ひどくこだわりを持ったPGがいたりしてキレたりするのね。
そうそう。そんでこういう人が比較的高スキル（として認められてきた人）だと、
逆にこっちが攻められたりして、許容するとシステムがボロボロになっていくと。
何か上手いやり方が欲しい・・・
＞ひどくこだわりを持ったPGがいたりしてキレたりするのね。
そうそう。そんでこういう人が比較的高スキル（として認められてきた人）だと、
逆にこっちが攻められたりして、許容するとシステムがボロボロになっていくと。
何か上手いやり方が欲しい・・・
ソース見て、不要なコードが多かったので
「ここは、こう記述した方が良いと思うん」
と指摘すると、
「そんなレベルの低い形式で進めて良いんですか？」
とか言ってきて、
「このプロジェクトでは、これこれこういう理由でこういうやり方でやっているわけで・・・。」
って説明すると、キレて
「ここのプロジェクトは、レベルが低すぎてやってられねえよ」
となって、もうまったくやる気の無い感じになるのですね。
視点がもうはじめから、実際の運用から外れちゃってるのね。
こういった人種は、どう対処するのが適切なのでしょうか？
首にすることはできないので・・・。
「ここは、こう記述した方が良いと思うん」
と指摘すると、
「そんなレベルの低い形式で進めて良いんですか？」
とか言ってきて、
「このプロジェクトでは、これこれこういう理由でこういうやり方でやっているわけで・・・。」
って説明すると、キレて
「ここのプロジェクトは、レベルが低すぎてやってられねえよ」
となって、もうまったくやる気の無い感じになるのですね。
視点がもうはじめから、実際の運用から外れちゃってるのね。
こういった人種は、どう対処するのが適切なのでしょうか？
首にすることはできないので・・・。
>>244
飼い殺し
飼い殺し
知識だけが多くて経験の浅い人は、要求に対して実装するという根本的な事を忘れがちだね。
一つ共通機能をお願いしたら、過剰なくらいのライブラリを作って、
ただしシンプルに要求を満たすものが一つも無いとか。
こういうの見ると「いや〜頑張りましたね。価値無いけどね。」
とか吐き捨てたいけどそうもいかず、やんわり説明してるとキレられる。
俺はプロジェクトから外したよ・・・
一つ共通機能をお願いしたら、過剰なくらいのライブラリを作って、
ただしシンプルに要求を満たすものが一つも無いとか。
こういうの見ると「いや〜頑張りましたね。価値無いけどね。」
とか吐き捨てたいけどそうもいかず、やんわり説明してるとキレられる。
俺はプロジェクトから外したよ・・・
247 ：仕様書無しさん：05/01/04 13:19:29
>>246
だいたいそういう場合って要求自体があいまいで
作ってから要求したかったものがはっきり見えてくるってパターンだろ？
細かくいうと、そいつ自身、経験が浅いもんだから期限ギリギリまで実装時間にあてちゃってて
いざ提出したときには「はじめの要求をみたしてはいるんだけどなんかもの足りない」って
感じになっちゃって、できたもの見て要求したいものがわかった依頼側が調子にのって
そこから足りない仕様を指摘して「あいつつかえませんね」とかのたまうパターンだろ？
ふざけろ。
使えないのはどっちなのかわからせてやりたい。
だいたいそういう場合って要求自体があいまいで
作ってから要求したかったものがはっきり見えてくるってパターンだろ？
細かくいうと、そいつ自身、経験が浅いもんだから期限ギリギリまで実装時間にあてちゃってて
いざ提出したときには「はじめの要求をみたしてはいるんだけどなんかもの足りない」って
感じになっちゃって、できたもの見て要求したいものがわかった依頼側が調子にのって
そこから足りない仕様を指摘して「あいつつかえませんね」とかのたまうパターンだろ？
ふざけろ。
使えないのはどっちなのかわからせてやりたい。
248 ：仕様書無しさん：05/01/04 13:20:37
で、「どんな仕事でもコミュニケーションが大事」とかいっちゃって
実際はＰＭの仕事放棄してるだけ。
一生貧乏でいてくださいな♪
実際はＰＭの仕事放棄してるだけ。
一生貧乏でいてくださいな♪
タイピングしか出来ない奴はこなくていいよ
>>245
なるほど。たしかにそうしていれば辞めてくれそうな感じ。
でも軌道を修正できれば良いところありそうなんだが・・・。
言わなきゃ何もやらなくて、言ってもしばらく経って
どこまでできた？って聞くと
全然進んでない、で何もアラーム投げない人よりは遥かにマシなのでね。
なるほど。たしかにそうしていれば辞めてくれそうな感じ。
でも軌道を修正できれば良いところありそうなんだが・・・。
言わなきゃ何もやらなくて、言ってもしばらく経って
どこまでできた？って聞くと
全然進んでない、で何もアラーム投げない人よりは遥かにマシなのでね。
とにかくインタフェース仕様だけしっかり見ておいてあげれば、
システムが崩壊してしまう事態には至らないと思うわけだが。
ヤバそうな香具師に担当させる部分は隔離しておくが吉。
ソースレビューで一番効果が期待出来るのは、
ヤバそうな香具師の実装(内部設計)に関する部分ではないかと。
システムが崩壊してしまう事態には至らないと思うわけだが。
ヤバそうな香具師に担当させる部分は隔離しておくが吉。
ソースレビューで一番効果が期待出来るのは、
ヤバそうな香具師の実装(内部設計)に関する部分ではないかと。
>>250
つーか、開発現場で"1を教えたら10を知れ"式なことやってると、問題が起きたとき、
開発体制自体が疑われると思ってた方がいいよ。
インターフェース仕様だけしっかりとねというのは、そういうことね。
「聞けよ」と怒ってる奴ほど、伝えるべき事を何も伝えてない場合が多いのよね。
ただ、要求仕様を全部充たしてても、案外足りないものは多かったりもするのも、また事実。
そういうのはほとんどの場合、SE側やPM側も見落してるものなんだが、おこりっぽい奴ほど、
下っ端のPGのせいにする。そして、例のごとく、「聞けよ」もしくは「考えろ」とか言いだす。
個人的に開発現場の連中って（オレもそうなんだけどさ)、客がどうのこうのという視点が
欠けてるよね。ほんとに大事なのは、製品の質と要求仕様を充たしてるかどうかなんだけど
(もち、運用可能なものをってことで)、不思議と自分のイライラ解消に重点を置く奴が多い。
そういう連中って大抵の場合、話しかけ難いし、やりにくい。
アナタもそうなってる可能性は無いかい?
つーか、開発現場で"1を教えたら10を知れ"式なことやってると、問題が起きたとき、
開発体制自体が疑われると思ってた方がいいよ。
インターフェース仕様だけしっかりとねというのは、そういうことね。
「聞けよ」と怒ってる奴ほど、伝えるべき事を何も伝えてない場合が多いのよね。
ただ、要求仕様を全部充たしてても、案外足りないものは多かったりもするのも、また事実。
そういうのはほとんどの場合、SE側やPM側も見落してるものなんだが、おこりっぽい奴ほど、
下っ端のPGのせいにする。そして、例のごとく、「聞けよ」もしくは「考えろ」とか言いだす。
個人的に開発現場の連中って（オレもそうなんだけどさ)、客がどうのこうのという視点が
欠けてるよね。ほんとに大事なのは、製品の質と要求仕様を充たしてるかどうかなんだけど
(もち、運用可能なものをってことで)、不思議と自分のイライラ解消に重点を置く奴が多い。
そういう連中って大抵の場合、話しかけ難いし、やりにくい。
アナタもそうなってる可能性は無いかい?
そもそもＰＭってのは責任を被るのが仕事みたいなもんなんだからな。
問題がおきちゃった時点でＰＭのせいなんだよ（本当はね）。
それがおきないようにするのがそもそもの仕事なんだから。
ここで、じゃあどうすればいいのさ。ってのを考えないとね。
少なくとも、スケジュールギリギリまでまって最後の日に
「できないじゃないか！？」なんて怒り出すよりやっとくべきことあったよね？って話ですよ。
問題がおきちゃった時点でＰＭのせいなんだよ（本当はね）。
それがおきないようにするのがそもそもの仕事なんだから。
ここで、じゃあどうすればいいのさ。ってのを考えないとね。
少なくとも、スケジュールギリギリまでまって最後の日に
「できないじゃないか！？」なんて怒り出すよりやっとくべきことあったよね？って話ですよ。
> 少なくとも、スケジュールギリギリまでまって最後の日に
>「できないじゃないか！？」なんて怒り出す
過去に数人ほど、そういうのを目撃してます。
もちろん、最終日に仕様変更を容認したバカPMのせいなんですが。実際に責任
取らされたのは、外注のPGでしたなぁ。徹夜を１人でやらされたあげく、完成
したら、切られてましたね。可哀相に。
かと思えば、納品後、2週間も経過して、一度も聞いていない（実は担当SEが握ってた)
仕様を告げられて、ものの見事に障害発生とか。その時は私がメインのPGだったんで、
ひどい目に遭いましたね。信用するんじゃなかったと自己嫌悪に(＾＾；
基本的に、自分の仕事をやらずに下に垂れ流す傾向のある人物に、取り仕切られるのは
怖いですな。でも、そういうSEやPMって山ほどいますがねぃ。
機会があったら彼らの仕事を後から見てると笑えますよ。実働時間がどれだけ短いか
分りますから。まぁ、仕事の優先度の考え方の差なんでしょうが、下手すると、放置
どころか無視される場合も多くて、何を依頼しても。そういうSEも結構いますなぁ。
>「できないじゃないか！？」なんて怒り出す
過去に数人ほど、そういうのを目撃してます。
もちろん、最終日に仕様変更を容認したバカPMのせいなんですが。実際に責任
取らされたのは、外注のPGでしたなぁ。徹夜を１人でやらされたあげく、完成
したら、切られてましたね。可哀相に。
かと思えば、納品後、2週間も経過して、一度も聞いていない（実は担当SEが握ってた)
仕様を告げられて、ものの見事に障害発生とか。その時は私がメインのPGだったんで、
ひどい目に遭いましたね。信用するんじゃなかったと自己嫌悪に(＾＾；
基本的に、自分の仕事をやらずに下に垂れ流す傾向のある人物に、取り仕切られるのは
怖いですな。でも、そういうSEやPMって山ほどいますがねぃ。
機会があったら彼らの仕事を後から見てると笑えますよ。実働時間がどれだけ短いか
分りますから。まぁ、仕事の優先度の考え方の差なんでしょうが、下手すると、放置
どころか無視される場合も多くて、何を依頼しても。そういうSEも結構いますなぁ。
そもそもソフトウェアなんて作りながら
仕様が変わっていってしまうものなんですよ。
だから、とにかくまってちゃ駄目なんですよ。
実装する機能の順番を下に決めさせてちゃ手遅れなんですよ。
まあ、保身に走って自分の位置さえ確保しときゃいいとかいう根性ならそれもアリですけどね。
仕様が変わっていってしまうものなんですよ。
だから、とにかくまってちゃ駄目なんですよ。
実装する機能の順番を下に決めさせてちゃ手遅れなんですよ。
まあ、保身に走って自分の位置さえ確保しときゃいいとかいう根性ならそれもアリですけどね。
まぁ、聞くと怒る。握りしめる人ほどそうなんですよねぃ。
で、こういう人はこちらで、その人物が暇なタイミングを計ってあげないと
簡単にキレちゃうんですよネ。
メールの確認程度でも、途中のインタラプトに弱いみたいでね。
内心、「お前はシングルタスクの糞コードか」と思うんですが。
「聞け」は一見、正しいですけどね。もちろん、「考えろ」もね。ただ、それは
当人だけが頑張ったところで、無意味なんですよねぃ。ほんとだったら、PMとか
が配慮して、開発環境を改善すべきであって、１人のPGをどうのこうの言うべき
問題じゃないんすよ。
下っ端から見れば、「聞いたって答えてくれないじゃん」、こう思われたらアウト
っすね。もちろん、下っ端のそれがいつも正しいわけじゃないんですが。
「気が利かない」とか思ってるPMやSEなら要改善だと思いますネィ。
で、こういう人はこちらで、その人物が暇なタイミングを計ってあげないと
簡単にキレちゃうんですよネ。
メールの確認程度でも、途中のインタラプトに弱いみたいでね。
内心、「お前はシングルタスクの糞コードか」と思うんですが。
「聞け」は一見、正しいですけどね。もちろん、「考えろ」もね。ただ、それは
当人だけが頑張ったところで、無意味なんですよねぃ。ほんとだったら、PMとか
が配慮して、開発環境を改善すべきであって、１人のPGをどうのこうの言うべき
問題じゃないんすよ。
下っ端から見れば、「聞いたって答えてくれないじゃん」、こう思われたらアウト
っすね。もちろん、下っ端のそれがいつも正しいわけじゃないんですが。
「気が利かない」とか思ってるPMやSEなら要改善だと思いますネィ。
なんだか、PMを愚痴るスレに変わってきてるな
そういうのは上司スレに逝ってほしいね。
262 ：仕様書無しさん：05/01/04 23:41:42
「現役PG」だけでなく「元PG」がいても不思議ではあるまい。
想像力の欠如した香具師の設計は危なくて見てられない。
それ以前にここはPMな人達を隔離しているスレだ。
日本語を読み解けない香具師の仕様書は見るに耐えない。
想像力の欠如した香具師の設計は危なくて見てられない。
それ以前にここはPMな人達を隔離しているスレだ。
日本語を読み解けない香具師の仕様書は見るに耐えない。
マ板って開発に携わってる人全員の雑談板って事でいいんじゃないの？
そもそもPGだってPM視点は必要なわけだし、
小さいプロジェクトなら兼任してる人も多いでしょ？
そもそもPGだってPM視点は必要なわけだし、
小さいプロジェクトなら兼任してる人も多いでしょ？
>>241
アナライザの結果を基にやる分ならいいけど、設計内容まで加味して結果を
出すものって無いし。
ソースレベルで見たら、単体で全パス通すのと変わらんような気がするが。
だから、効率を考えると、ソースレビューは採用できないのよ。
>>242
設計書のレビューしないのか、それとも、設計書とか書かないトコなのかな。
クラス図（モジュール関連図）とシーケンス図（正常系）だけは必ず書いて
もらってるが、この二つだけでもレビューしたら、十分効果があるんだが。
単体テストが終わるまでに一度レビューするくらいだし、全部で10枚越すよ
うなことは無いし、これぐらいなら、みんな書いてくれるよ。
アナライザの結果を基にやる分ならいいけど、設計内容まで加味して結果を
出すものって無いし。
ソースレベルで見たら、単体で全パス通すのと変わらんような気がするが。
だから、効率を考えると、ソースレビューは採用できないのよ。
>>242
設計書のレビューしないのか、それとも、設計書とか書かないトコなのかな。
クラス図（モジュール関連図）とシーケンス図（正常系）だけは必ず書いて
もらってるが、この二つだけでもレビューしたら、十分効果があるんだが。
単体テストが終わるまでに一度レビューするくらいだし、全部で10枚越すよ
うなことは無いし、これぐらいなら、みんな書いてくれるよ。
実装に関する設計書作成 → レビュー
してる間に
実装 → ソースレビュー
を沢山出来る。かも。
してる間に
実装 → ソースレビュー
を沢山出来る。かも。
ソースレビューってする意味わかんね。
>>244みたいなのって何か明確な基準があって指摘するわけ？
例えば>>244と>>244の言う変な奴がたまたま逆の立場だったら
>>244が>>244の言う変な奴から指摘をうけるわけだよね？
こういうのどっちがいいかってのは、２ちゃんでだって十分論争になりうる話題だ。
仕様さえ満たしていれば、とりあえず深く突っ込むのは止めたほうがいいと思うんだけど。
その部分に問題が出てから「じゃあ〜」ってんで対策を考えるならまだしも
記述が変だから、こう記述した方がいいから（いいって？どういいの？）とか
実際の運用で特に問題が出てるわけじゃないのにわざわざひっかきまわして
うまくいかないと思うな。
>>244みたいなのって何か明確な基準があって指摘するわけ？
例えば>>244と>>244の言う変な奴がたまたま逆の立場だったら
>>244が>>244の言う変な奴から指摘をうけるわけだよね？
こういうのどっちがいいかってのは、２ちゃんでだって十分論争になりうる話題だ。
仕様さえ満たしていれば、とりあえず深く突っ込むのは止めたほうがいいと思うんだけど。
その部分に問題が出てから「じゃあ〜」ってんで対策を考えるならまだしも
記述が変だから、こう記述した方がいいから（いいって？どういいの？）とか
実際の運用で特に問題が出てるわけじゃないのにわざわざひっかきまわして
うまくいかないと思うな。
>記述が変だから、こう記述した方がいいから（いいって？どういいの？）とか
>実際の運用で特に問題が出てるわけじゃないのにわざわざひっかきまわして
>うまくいかないと思うな。
保守しないつもりですね？:-)
サンプルチェックはぼくわ必要だと思うなぁ〜
今まで一緒に仕事した人ならともかく、お初の人相手なら。
PMがやるかPLがやるか、信頼のおける片腕達がやるかは話は別だけど。
>実際の運用で特に問題が出てるわけじゃないのにわざわざひっかきまわして
>うまくいかないと思うな。
保守しないつもりですね？:-)
サンプルチェックはぼくわ必要だと思うなぁ〜
今まで一緒に仕事した人ならともかく、お初の人相手なら。
PMがやるかPLがやるか、信頼のおける片腕達がやるかは話は別だけど。
>>266
正式にはソースコードレビューで、コードレビューの方が一般的な用語かもね。
で、コードレビューが一方的だと考えるならそれは間違ってる。
指摘された点について間違ってると思うならPGだって説明するのは当然だし、
論理的な話の中で意見がぶつかるなら、メリットデメリットを擦り合わせて
お互い納得するような答を導けばいいわけだし。
問題なのは経験や勘を盾に論理的な議論をしない人なわけで。
正式にはソースコードレビューで、コードレビューの方が一般的な用語かもね。
で、コードレビューが一方的だと考えるならそれは間違ってる。
指摘された点について間違ってると思うならPGだって説明するのは当然だし、
論理的な話の中で意見がぶつかるなら、メリットデメリットを擦り合わせて
お互い納得するような答を導けばいいわけだし。
問題なのは経験や勘を盾に論理的な議論をしない人なわけで。
>>266
＞仕様さえ満たしていれば、とりあえず深く突っ込むのは止めたほうがいいと思うんだけど。
そう思うなら、きっと良いプログラマに囲まれてるんだろうね。
俺の周りではちょっと見ればコードが半分以下になるような人とか、
パフォーマンス的にあり得ないコード書く人が溢れてるから、
仕様以外でも見所満載なんだよね。
＞その部分に問題が出てから「じゃあ〜」ってんで対策を考えるならまだしも
コード品質レベル指摘だとすると、問題とは保守性の低さによるスケジュールの遅れ、
パフォーマンスの悪さにより性能要件が満たされない、とかだよね。もっとあるかな。
どっちも問題出てから「じゃあ〜」だとコストが掛かりすぎる。
どちらにせよ、理由無く引っかき回すレビュアーを前提に要らない、
はコードレビューへの言及じゃなくて、特定の人に対する愚痴かと。
＞仕様さえ満たしていれば、とりあえず深く突っ込むのは止めたほうがいいと思うんだけど。
そう思うなら、きっと良いプログラマに囲まれてるんだろうね。
俺の周りではちょっと見ればコードが半分以下になるような人とか、
パフォーマンス的にあり得ないコード書く人が溢れてるから、
仕様以外でも見所満載なんだよね。
＞その部分に問題が出てから「じゃあ〜」ってんで対策を考えるならまだしも
コード品質レベル指摘だとすると、問題とは保守性の低さによるスケジュールの遅れ、
パフォーマンスの悪さにより性能要件が満たされない、とかだよね。もっとあるかな。
どっちも問題出てから「じゃあ〜」だとコストが掛かりすぎる。
どちらにせよ、理由無く引っかき回すレビュアーを前提に要らない、
はコードレビューへの言及じゃなくて、特定の人に対する愚痴かと。
>>267-269
いや、その意見ってさ、
「やったほうがいいか悪いかなら、やったほうがいいに決まってる」
的な安易な考えにしか聞こえないんだよね。
実際は>>244みたいな論争になるよ。
２ちゃんみてりゃわかると思うけど、STL（標準ライブラリ、標準だよ、標準、何を踏み切れないのか・・・）を
使うか否かでスレ埋めるぐらいの論争になるじゃん。
出だしのアプローチの話題からいって危険だよ。
誰を正しいとおいて、何を目標とするの？って部分に定義がない。
で、俺も長いことプログラマやってるけど、ソースの記述の良し悪しって
はっきりいってよくわかんね。
大規模であるほど迂闊にさわれなくなるし、中身がどうなっていようと
長いこと正しいとされる動作で動いてくれるＡＰＩにはやっぱり安心感があるよ。
ソースレビューやったからって運用実績の少なさは変わらないんだし。
第一、１日に１人で１０００行も２０００行も書くときもあるのに、
ソースレビューなんてのんびりやってられない。
いや、その意見ってさ、
「やったほうがいいか悪いかなら、やったほうがいいに決まってる」
的な安易な考えにしか聞こえないんだよね。
実際は>>244みたいな論争になるよ。
２ちゃんみてりゃわかると思うけど、STL（標準ライブラリ、標準だよ、標準、何を踏み切れないのか・・・）を
使うか否かでスレ埋めるぐらいの論争になるじゃん。
出だしのアプローチの話題からいって危険だよ。
誰を正しいとおいて、何を目標とするの？って部分に定義がない。
で、俺も長いことプログラマやってるけど、ソースの記述の良し悪しって
はっきりいってよくわかんね。
大規模であるほど迂闊にさわれなくなるし、中身がどうなっていようと
長いこと正しいとされる動作で動いてくれるＡＰＩにはやっぱり安心感があるよ。
ソースレビューやったからって運用実績の少なさは変わらないんだし。
第一、１日に１人で１０００行も２０００行も書くときもあるのに、
ソースレビューなんてのんびりやってられない。
>266
明確な基準と言えば、第一に保守ですね。
そのパーツが仕様を満たしていとしても、
後に仕様変更とかあったときに
その担当してた人がいないケースのことも考えなくちゃいけないわけ。
そんなとき、無駄が多くて理解しずらいソースじゃたいへんでしょ？
そういう意味じゃ、たとえパーツが独立してたって、
ある程度システム全体を見てもらわないとね。
余計な処理とか、理解しずらい書き方は避けてほしいね。
いういう意見に癖のあるPGは噛み付くのね。
少しは分かれよって思うけど。
明確な基準と言えば、第一に保守ですね。
そのパーツが仕様を満たしていとしても、
後に仕様変更とかあったときに
その担当してた人がいないケースのことも考えなくちゃいけないわけ。
そんなとき、無駄が多くて理解しずらいソースじゃたいへんでしょ？
そういう意味じゃ、たとえパーツが独立してたって、
ある程度システム全体を見てもらわないとね。
余計な処理とか、理解しずらい書き方は避けてほしいね。
いういう意見に癖のあるPGは噛み付くのね。
少しは分かれよって思うけど。
>>271
わかってないなぁ。
その「余計な処理」とか「無駄な処理」とか「理解しずらい」「システム全体を見て」
ってのは誰の視点が基準なわけ？
ここがあいまいだと話にならない。
みんな自分の視点で勝手なこといいだすから喧嘩になるんでしょう。
あなたからみた「余計な処理」と
わたしからみた「余計な処理」は当然ちがうんですよ。
ソースレビューの必要性１つとったって私とあなたで違うんです。
神の目は誰ですか？
わかってないなぁ。
その「余計な処理」とか「無駄な処理」とか「理解しずらい」「システム全体を見て」
ってのは誰の視点が基準なわけ？
ここがあいまいだと話にならない。
みんな自分の視点で勝手なこといいだすから喧嘩になるんでしょう。
あなたからみた「余計な処理」と
わたしからみた「余計な処理」は当然ちがうんですよ。
ソースレビューの必要性１つとったって私とあなたで違うんです。
神の目は誰ですか？
>>270
＞「やったほうがいいか悪いかなら、やったほうがいいに決まってる」
って
＞ソースレビューってする意味わかんね。
へのレスとしては十分かと思うけど。
で、長いことプログラマやってる>>270の知ってる通り、ソースの良し悪しって
＞長いこと正しいとされる動作で動いてくれるＡＰＩにはやっぱり安心感があるよ。
っていうのも一つの基準だよね。長いこと動いてるAPIを修正するのはかなりハイリスク。
だけど全員が同じ認識を持ってるとは限らない訳で。こういう時ベストの選択するために、
ソースレビューのコストを割くという選択があっても良いかと思うわけです。
今思ったけどレビューでぶつかるのはレビューの意義に対する説明不足なのかも。
＞「やったほうがいいか悪いかなら、やったほうがいいに決まってる」
って
＞ソースレビューってする意味わかんね。
へのレスとしては十分かと思うけど。
で、長いことプログラマやってる>>270の知ってる通り、ソースの良し悪しって
＞長いこと正しいとされる動作で動いてくれるＡＰＩにはやっぱり安心感があるよ。
っていうのも一つの基準だよね。長いこと動いてるAPIを修正するのはかなりハイリスク。
だけど全員が同じ認識を持ってるとは限らない訳で。こういう時ベストの選択するために、
ソースレビューのコストを割くという選択があっても良いかと思うわけです。
今思ったけどレビューでぶつかるのはレビューの意義に対する説明不足なのかも。
>>272
おれが神の目だ、てなイタイ人多いよね。
そーゆ人って、ダメな点を指摘しちゃうと、顔真っ赤にして、次の日から来なく
なっちゃったりするから、扱いには細心の注意が必要ですよ。
でも、おもしろいから、時々やっちゃいます。
おれが神の目だ、てなイタイ人多いよね。
そーゆ人って、ダメな点を指摘しちゃうと、顔真っ赤にして、次の日から来なく
なっちゃったりするから、扱いには細心の注意が必要ですよ。
でも、おもしろいから、時々やっちゃいます。
このスレに居る人は全員神の目を持っているみたいですね。
276 ：仕様書無しさん：05/01/05 23:50:51
管理者（PM)にはプログラマから何年目でなれますか？
現在プログラマ暦２年です。
現在プログラマ暦２年です。
>>276
年功序列じゃないこの業界では無意味な質問だな。
年功序列じゃないこの業界では無意味な質問だな。
君のなりたいと思った気持ちが心からあふれたら
ﾊｧ？
ﾊｧ？
279 ：仕様書無しさん：05/01/05 23:56:52
では、どうすれば良いのでしょうか？
プロマネの資格を取得すれば良いのですか？
プロマネの資格を取得すれば良いのですか？
>>272
神の目でなくてもいいのでは？
コーディング規則通りに作ってないとか、例外処理を
一切入れてないとか。
あとで蓋をあけて残された人達が困るよりは、なるべく
統一したコードを残したほうがいいと思うんだけどね。
というか。
なんで、喧嘩になるほどコーディングに拘ってる
のかわけわからん。
神の目でなくてもいいのでは？
コーディング規則通りに作ってないとか、例外処理を
一切入れてないとか。
あとで蓋をあけて残された人達が困るよりは、なるべく
統一したコードを残したほうがいいと思うんだけどね。
というか。
なんで、喧嘩になるほどコーディングに拘ってる
のかわけわからん。
>>279
君のなりたいプロマネって何かね。
君のなりたいプロマネって何かね。
>>279
デスマスレで同じ質問してるの君か？
デスマスレで同じ質問してるの君か？
正直このスレでそんな事を質問するようではＰＭは無理ポ
284 ：仕様書無しさん：05/01/06 00:25:12
286 ：仕様書無しさん：05/01/06 01:00:57
>>284
ある程度経験したプログラマはみんな君のように危機を感じている。
そこでプログラム以外に何か得意技をみつけていくわけだ。
それは顧客との折衝であったり、ＤＢのスペシャリストであったり、
アーキテクトであったり、英語であったり、いろいろだけど。
そしてさまざまなプロジェクトの失敗を乗り越えて、
やる気が残っている人はようやくプロマネになれる
と思う。
ある程度経験したプログラマはみんな君のように危機を感じている。
そこでプログラム以外に何か得意技をみつけていくわけだ。
それは顧客との折衝であったり、ＤＢのスペシャリストであったり、
アーキテクトであったり、英語であったり、いろいろだけど。
そしてさまざまなプロジェクトの失敗を乗り越えて、
やる気が残っている人はようやくプロマネになれる
と思う。
PMってバカに対する許容量が高いか、もしくは自分がバカか
どっちかじゃなきゃ出来ないな。あと体力な。それとPMって
かっこいいっていう妄想な。これ重要だわな。
どっちかじゃなきゃ出来ないな。あと体力な。それとPMって
かっこいいっていう妄想な。これ重要だわな。
つか、プログラミングが得意なほど、PMやSEにはなりにくいけどねw
むしろ、下手糞で、営業スキルに秀でている方がなりやすいと言える。
としか思えん。今までに結構な数のSEやPMを見てるけど、プログラムが好きという奴に会ったこと無いぞ。
むしろ、下手糞で、営業スキルに秀でている方がなりやすいと言える。
としか思えん。今までに結構な数のSEやPMを見てるけど、プログラムが好きという奴に会ったこと無いぞ。
コードレビューやってる所って、後でバグや仕様変更でコードを修正した時も、また
レビューやるのかなあ。
暇なプロジェクトなんだろうなあ。
それに、コードレビューまでやってバグが出たりしたら、どう言い訳をするのだろう。
聞いてみたいなあ。
レビューやるのかなあ。
暇なプロジェクトなんだろうなあ。
それに、コードレビューまでやってバグが出たりしたら、どう言い訳をするのだろう。
聞いてみたいなあ。
PMって、だいたい2〜6名くらいのPGの管理がメインで、後はお客さんと打ち合わせしたり、
契約したりといった業務する人で場合によっては営業専門の人も上につく場合もあるって
思うんだけど、
これは下請け派遣専門会社（子会社に多い）とか下請け管理専門会社（大手に多い）で
認識は人それぞれだろうねえ。
上記をPMとするなら、プログラム好きじゃなくちゃできないと思うけど。
契約したりといった業務する人で場合によっては営業専門の人も上につく場合もあるって
思うんだけど、
これは下請け派遣専門会社（子会社に多い）とか下請け管理専門会社（大手に多い）で
認識は人それぞれだろうねえ。
上記をPMとするなら、プログラム好きじゃなくちゃできないと思うけど。
>>289
おれおれ。最近PMばっかりで仕事としてのプログラミングは殆ど無くなったけど、
一番楽しくて一番得意なのは今でもプログラミングだよ。
分かれ道があったとすれば、技術的にベストな物を作りたいという欲求が、
顧客にとってベストな物を作りたいという欲求に置き換わった事かも。
前者の価値観を身を削ってでも大事にしたいと思ってるような人だと、
山の頂を前に下山するようなプロジェクトばっかりで気が狂うんじゃないかな。
おれおれ。最近PMばっかりで仕事としてのプログラミングは殆ど無くなったけど、
一番楽しくて一番得意なのは今でもプログラミングだよ。
分かれ道があったとすれば、技術的にベストな物を作りたいという欲求が、
顧客にとってベストな物を作りたいという欲求に置き換わった事かも。
前者の価値観を身を削ってでも大事にしたいと思ってるような人だと、
山の頂を前に下山するようなプロジェクトばっかりで気が狂うんじゃないかな。
>>290
やる必要があると判断したプロジェクトなら、例外無く全てやるよ。
ちなみにレビューって言っても形式張るのが目的じゃないから、
簡単な修正で良い事が分かっていれば開発者のPC見て10秒くらいで終わる事もあるし、
逆に15分以上掛かるようなレビューなんて開発初期にポツポツあるくらい。
例外として、低スキル者を教育目的でバシバシ叩く事はあるかな。
＞暇なプロジェクトなんだろうなあ。
レビューしない暇が無いからやるんだよ。
＞コードレビューまでやってバグが出たりしたら、どう言い訳をするのだろう。
バグって悪じゃなくて、当然の開発過程でしょ？何で言い訳が必要なの？
やる必要があると判断したプロジェクトなら、例外無く全てやるよ。
ちなみにレビューって言っても形式張るのが目的じゃないから、
簡単な修正で良い事が分かっていれば開発者のPC見て10秒くらいで終わる事もあるし、
逆に15分以上掛かるようなレビューなんて開発初期にポツポツあるくらい。
例外として、低スキル者を教育目的でバシバシ叩く事はあるかな。
＞暇なプロジェクトなんだろうなあ。
レビューしない暇が無いからやるんだよ。
＞コードレビューまでやってバグが出たりしたら、どう言い訳をするのだろう。
バグって悪じゃなくて、当然の開発過程でしょ？何で言い訳が必要なの？
>>290
って、お前マジでいってんの？
下の奴がいるんだったら、コードレビューは当たり前。
（レベルにもよるが）
コードレビューでバグが潰れるんだから、やるのは
当たり前。
いまだに、バグ=悪だと思っている馬鹿がいるんだね。
普通、1kあたりにバグが？件というのが基準にあって、
その基準を守れたかによって、品質が保たれるのが常識。
（無さ杉は、バグがまだ埋っていると思われる）
PGはカワイソウダネ、こんなことも知らないなんて。
って、お前マジでいってんの？
下の奴がいるんだったら、コードレビューは当たり前。
（レベルにもよるが）
コードレビューでバグが潰れるんだから、やるのは
当たり前。
いまだに、バグ=悪だと思っている馬鹿がいるんだね。
普通、1kあたりにバグが？件というのが基準にあって、
その基準を守れたかによって、品質が保たれるのが常識。
（無さ杉は、バグがまだ埋っていると思われる）
PGはカワイソウダネ、こんなことも知らないなんて。
>>293
つーか、コードレビューっていちいちソースコードおっかけてってみるの？
とりあえず俺のいるプロジェクトがここ３ヶ月間で組んだ１人当りのプログラムの
行数５０００行（納期３ヶ月（ありえないｗ）の超ハイスピードモードｗ）ぐらいなんだけど
こんなのもみんなでながめてくの？ｗ
つーか、コードレビューっていちいちソースコードおっかけてってみるの？
とりあえず俺のいるプロジェクトがここ３ヶ月間で組んだ１人当りのプログラムの
行数５０００行（納期３ヶ月（ありえないｗ）の超ハイスピードモードｗ）ぐらいなんだけど
こんなのもみんなでながめてくの？ｗ
まてまてまて３ヶ月で5Kって全然多く無いぞ。
297 ：仕様書無しさん：05/01/07 00:10:49
そもそも行数の多さで規模を表すのは間違ってるけどな。
高スキル者は複雑な仕様を「なんだこんなもんか」ってくらい簡単に書くし。
低スキル者はシンプルなコード書けないから当然行数増える。
高スキル者は複雑な仕様を「なんだこんなもんか」ってくらい簡単に書くし。
低スキル者はシンプルなコード書けないから当然行数増える。
>>299
仕様変更無しならそうかもね。
仕様変更無しならそうかもね。
302 ：仕様書無しさん：05/01/07 00:19:14
で、1人5000行のソースのコードレビューを
全員分（仮に5人ぐらいだと）するとどれくらいかかるの？
全員分（仮に5人ぐらいだと）するとどれくらいかかるの？
>>303
円滑に納品可能なくらいの時間がかかるよ。
円滑に納品可能なくらいの時間がかかるよ。
おおい、バグって客に隠したり言い訳したりするもんなのか？
テスト期間中普通に出て普通に減って必要なら件数報告して、
何もやましい事なんて無いと思うけど、お前等の客はそれを咎めるの？
テスト期間中普通に出て普通に減って必要なら件数報告して、
何もやましい事なんて無いと思うけど、お前等の客はそれを咎めるの？
307 ：仕様書無しさん：05/01/07 00:35:15
>>307
「なんだこんなもんか」っていうのは中学生でも分かるコーディングって事だよ。
「なんだこんなもんか」っていうのは中学生でも分かるコーディングって事だよ。
>>307
凝っていないから短いのだ。
凝っていないから短いのだ。
コードレビューって、確かに品質は確保されるが、効率悪いよね。
どういった見積もりをだしてるのかな？
うちは、バグトレースを集計してみた結果、テストの自動化に力を入れたほうが
おいしいって結果がでちゃったため、ほぼ、工数はとれないんだな。
もし、やるなら、なんらかの優位性を示さなくてはならないんだが
・後工程でも取れないバグの発見（とっても少ない）
・後工程で取れるバグの発見（早期のバグ検出）
この２点に、そんだけの魅力はないのかなって思うんだが。
どういった見積もりをだしてるのかな？
うちは、バグトレースを集計してみた結果、テストの自動化に力を入れたほうが
おいしいって結果がでちゃったため、ほぼ、工数はとれないんだな。
もし、やるなら、なんらかの優位性を示さなくてはならないんだが
・後工程でも取れないバグの発見（とっても少ない）
・後工程で取れるバグの発見（早期のバグ検出）
この２点に、そんだけの魅力はないのかなって思うんだが。
未だにステップ数当りのバグ数で品質測ってる文化圏があるんだ。
納品書面上に残ってるのはあるけど、あんなの偽造するのみ。
大体、本当に仕事が速くて優秀な奴がやると、この測り方じゃ品質悪いことになるんだよね。ｗ
バグがないーって。ｗ
納品書面上に残ってるのはあるけど、あんなの偽造するのみ。
大体、本当に仕事が速くて優秀な奴がやると、この測り方じゃ品質悪いことになるんだよね。ｗ
バグがないーって。ｗ
316 ：仕様書無しさん：05/01/07 21:04:28
PMな人たちの観点だとコードレビューって結構評判わるいみたいね。
プログラマーな俺としては、是非ともコードレビューは開発工程に取り入れてほしいと思っている。
バグの発見っていうメリットもなくはないけど、どっちかっていうとそれ以外の副次的な
メリットを感じたことの方が多いように思う。
・他人のコードを見ることで、自分が思いつきもしなかったような良いやり方を学ぶことができる。
・コードをネタにして色々な話をすることで、考え方に幅ができる。
・レビュアーに説明しやすいように、意図が明確になるようなコードを書くことを心がけるようになる。
などなどね。PMな方々には、数字だけみないでそういうトコも意識してもらえると
うれしいな、などと思っております。
プログラマーな俺としては、是非ともコードレビューは開発工程に取り入れてほしいと思っている。
バグの発見っていうメリットもなくはないけど、どっちかっていうとそれ以外の副次的な
メリットを感じたことの方が多いように思う。
・他人のコードを見ることで、自分が思いつきもしなかったような良いやり方を学ぶことができる。
・コードをネタにして色々な話をすることで、考え方に幅ができる。
・レビュアーに説明しやすいように、意図が明確になるようなコードを書くことを心がけるようになる。
などなどね。PMな方々には、数字だけみないでそういうトコも意識してもらえると
うれしいな、などと思っております。
317 ：仕様書無しさん：05/01/07 21:09:03
>>316
やだよ。
だってその分、納期が延びるわけじゃねぇんだろ。
あきらかに無駄なことじゃん。
ぜってぇはやんねぇ。
だいたいしょっぱなの納期さえ守れば後から来るクレームや仕変になんて
期限ないし適当に対応してりゃなんとかなるし。
レビューなんてやるよか、動かしてみりゃ一目瞭然なんだよ。
動かして見るまで誰にもバグはバグと認識できゃしねぇ。
客にとっても俺等にとっても都合がいいんだよ。
やだよ。
だってその分、納期が延びるわけじゃねぇんだろ。
あきらかに無駄なことじゃん。
ぜってぇはやんねぇ。
だいたいしょっぱなの納期さえ守れば後から来るクレームや仕変になんて
期限ないし適当に対応してりゃなんとかなるし。
レビューなんてやるよか、動かしてみりゃ一目瞭然なんだよ。
動かして見るまで誰にもバグはバグと認識できゃしねぇ。
客にとっても俺等にとっても都合がいいんだよ。
>>317
納期がものすごく厳しい状況でコードレビューをやれ、なんて風には俺も思ってないよ。
妥当な期限と人数で、比較的落ち着いたプロジェクトなら、コードレビューの工程を
いれることにはメリットが大きいと思っているだけ。
というか、そういう状況を作り出すのがPMの仕事と違うの？って気もするけど。
納期がものすごく厳しい状況でコードレビューをやれ、なんて風には俺も思ってないよ。
妥当な期限と人数で、比較的落ち着いたプロジェクトなら、コードレビューの工程を
いれることにはメリットが大きいと思っているだけ。
というか、そういう状況を作り出すのがPMの仕事と違うの？って気もするけど。
320 ：仕様書無しさん：05/01/07 21:41:17
>>318は正しいと思う。
ただ、プロジェクトリーダーよりは組織管理者の仕事かもね。
ただ、プロジェクトリーダーよりは組織管理者の仕事かもね。
>>325
ゲ会社だったときもあったけどそんときの開発期間は
１年〜２年ぐらいだったけど年中暇無し休み無し。
バグ無し、設計ミス無しのフルスピードで組んでも
何故か間に合わない過酷過ぎる環境。（最近のゲームってバグ少ないでしょ？評価してよｗ）
レビューなんか当然無理。
業務系に移ってからは３ヶ月とか半年の仕事がまわってくるけど
レビューやるほどに暇はない。
ってこんな感じだけど。
ゲ会社だったときもあったけどそんときの開発期間は
１年〜２年ぐらいだったけど年中暇無し休み無し。
バグ無し、設計ミス無しのフルスピードで組んでも
何故か間に合わない過酷過ぎる環境。（最近のゲームってバグ少ないでしょ？評価してよｗ）
レビューなんか当然無理。
業務系に移ってからは３ヶ月とか半年の仕事がまわってくるけど
レビューやるほどに暇はない。
ってこんな感じだけど。
オレもコードレビューなんてやったことない。
しかも2週間で5000行くらいが普通かと思ってた。
しかも2週間で5000行くらいが普通かと思ってた。
>>326
１、２年の間年中暇無し休み無か。
しかも過酷なゲ系より比較的易しい業務系に移っても暇無しって・・・
管理面では完全に失敗して来てるんだよね？
何も疑問に思わないの？なぜ遅れるか考えた事無いのか？
何故もっと良いやり方を模索しようとしない？
１、２年の間年中暇無し休み無か。
しかも過酷なゲ系より比較的易しい業務系に移っても暇無しって・・・
管理面では完全に失敗して来てるんだよね？
何も疑問に思わないの？なぜ遅れるか考えた事無いのか？
何故もっと良いやり方を模索しようとしない？
行自慢する奴は多分品質の意味を理解してない。
>>326
なるほど、ゲームとかだとそんな気がする。
俺がいままでやったのはほとんど金融機関向けシステムで、
お客はとても長い期間そのシステムを使い続けるんだそうだ。
期間が長いとどんどん後の変更でプログラムがスパゲッティになって、
保守のコストが積もり積もっていくので、
（わけのわからんコードでいやと言うほど痛い目にあっているらしい）
開発スタイルはじっくり、堅実にって感じ。
なるほど、ゲームとかだとそんな気がする。
俺がいままでやったのはほとんど金融機関向けシステムで、
お客はとても長い期間そのシステムを使い続けるんだそうだ。
期間が長いとどんどん後の変更でプログラムがスパゲッティになって、
保守のコストが積もり積もっていくので、
（わけのわからんコードでいやと言うほど痛い目にあっているらしい）
開発スタイルはじっくり、堅実にって感じ。
コードレビューしない暇があるなんて羨ましいな。
その分野に実績のある会社に納期で負けないために無茶をして仕事取ってる弱小会社は、
遅れるとか遅れないじゃなくて、プロジェクト発足時点からヤバイんですよ。
遅れるとか遅れないじゃなくて、プロジェクト発足時点からヤバイんですよ。
PMな人達がレビューが必要ないなんて言うかな？
経験不足なPGとか、PG経験ないPMとかだと言いそうだけど
経験不足なPGとか、PG経験ないPMとかだと言いそうだけど
だいたいレビューやったからってうまくいく根拠がねぇよ。
誰のナニを期待してレビューやるのさ。
まさか、「おれにみせりゃ安心だろうが！」とはいいださないよねｗ
誰のナニを期待してレビューやるのさ。
まさか、「おれにみせりゃ安心だろうが！」とはいいださないよねｗ
他人が見ないと思って例外処理を全くしないコードを書いたり、
イースターエッグを勝手に仕込んだりされないためにやる。
イースターエッグを勝手に仕込んだりされないためにやる。
あなたのプロジェクトの最もスキルの低い人のコードについてどう思われますか？
レビューいらないって言ってる奴はプロジェクト失敗してるんだろ？
初めから駄目？誰が決めたの？自分で計画立てた上で正確に判断出来てるの？
何故人のせいにする？何故自分を疑わない？
何故レビューの意義について考えない？
初めから駄目？誰が決めたの？自分で計画立てた上で正確に判断出来てるの？
何故人のせいにする？何故自分を疑わない？
何故レビューの意義について考えない？
>>315
ステップ数当りのバグ数やバグの収束性以外に、定量的な数値を出せてるのか疑問だ。
何をもって品質が良いと判断してる？
分からないから、誤魔化してるだけなのか、それとも、自分では優秀と思っていたのに、
数値であなたはダメダメですと真実を突きつけられて悔しかったのか。
優秀な人は、きちんと数値に反映されるよ。
ステップ数当りのバグ数やバグの収束性以外に、定量的な数値を出せてるのか疑問だ。
何をもって品質が良いと判断してる？
分からないから、誤魔化してるだけなのか、それとも、自分では優秀と思っていたのに、
数値であなたはダメダメですと真実を突きつけられて悔しかったのか。
優秀な人は、きちんと数値に反映されるよ。
少なくともレビューが全くいらない、っていうのはあり得ないな。
コードレビューが必須かどうかっていうのは微妙なところだが。
仕様のレビュー：必須、設計レビュー：重要なところはやる
テストケースレビュー：必須、コードレビュー：時間があれば・・・
ってところか。
コードレビューが必須かどうかっていうのは微妙なところだが。
仕様のレビュー：必須、設計レビュー：重要なところはやる
テストケースレビュー：必須、コードレビュー：時間があれば・・・
ってところか。
>>342
その微妙なコードレビューの話だったと思うぞ
その微妙なコードレビューの話だったと思うぞ
ステップ数以外の規模見積もりって沢山あるよね。
あとバグなんて最終的に全部回収するのが前提だし、
バグの出方は事前のチェックやテストのやり方、
集計方法によっても全く変わってくるから、
使えるとすればプロジェクトに閉じた進捗管理くらいだね。
品質について唯一の基準があるとすれば、
全体として計画をどれだけ上回ったかだな。
コストとか性能とかユーザビリティとか。客が大満足とか。
あとバグなんて最終的に全部回収するのが前提だし、
バグの出方は事前のチェックやテストのやり方、
集計方法によっても全く変わってくるから、
使えるとすればプロジェクトに閉じた進捗管理くらいだね。
品質について唯一の基準があるとすれば、
全体として計画をどれだけ上回ったかだな。
コストとか性能とかユーザビリティとか。客が大満足とか。
>>342
>少なくともレビューが全くいらない、っていうのはあり得ないな。
>コードレビューが必須かどうかっていうのは微妙なところだが。
１行目と２行目は矛盾しているわけだが、
彼の身に一体何があったというのだろうか？
>少なくともレビューが全くいらない、っていうのはあり得ないな。
>コードレビューが必須かどうかっていうのは微妙なところだが。
１行目と２行目は矛盾しているわけだが、
彼の身に一体何があったというのだろうか？
レビュー∋コードレビュー
ただゴネたいのかリアルで理解してないのか・・・
仕様は決まってるのか。なら仕様書レビューどころか仕様書要らないね。
352 ：仕様書無しさん：05/01/08 00:13:13
コードレビューは効率が悪いと思うオレだけど、
さすがに仕様くらいは皆で検討してくれと思うぞ。
さすがに仕様くらいは皆で検討してくれと思うぞ。
色々な人に守られてなんとか生きてる事に気づいて無い人が居るね。
コードレビューは、良いことと思うけど、確かにやったところで
納品物に入らない。顧客に見えないところで品質を上げる効果はあるわけだけど
それによってバグが０件って結果になるとまたちょっとね・・・。
顧客から見ると、ソースコードのボリュームとか、テスト行ったときのバグの発生件数とか
の方が絶対基準になるし、評価対象に入ってしまう・・・。
以前、単体テスト仕様書も単体テスト結果も納品するようなプロジェクトやったけど
当時、ソースレビューでバグをつぶして、テストしてバグが実際は１件も出なかった
のに わざとバグを出したように見せかけて、修正したみたいな結果に偽装したこと
あった・・・。
ソースレビューは効果的だけど、時間に余裕が無いプロジェクトだと、
現状ではたしかにちょっとキツい場合が多いと思う。
納品物に入らない。顧客に見えないところで品質を上げる効果はあるわけだけど
それによってバグが０件って結果になるとまたちょっとね・・・。
顧客から見ると、ソースコードのボリュームとか、テスト行ったときのバグの発生件数とか
の方が絶対基準になるし、評価対象に入ってしまう・・・。
以前、単体テスト仕様書も単体テスト結果も納品するようなプロジェクトやったけど
当時、ソースレビューでバグをつぶして、テストしてバグが実際は１件も出なかった
のに わざとバグを出したように見せかけて、修正したみたいな結果に偽装したこと
あった・・・。
ソースレビューは効果的だけど、時間に余裕が無いプロジェクトだと、
現状ではたしかにちょっとキツい場合が多いと思う。
私もね。
コードレビューがまったく不要とは言わないけど現実的にはやらないね。
新人のコードなら見ることもあるかもしれないけど
保守性が高いコードとか、美しいコードとか、
PMの立場からいうと重要性はあまり高くない。
（繰り返すが、やる意味がまったくないとは言わない）
どちらかというと、仕様書のレビューはもちろんのこと、
テストケースがどの程度洗い出されているかの方が重要と思う。
例外処理のテストケースが含まれていなければ、それを
テストするように指示するのは必要でしょ。
例外処理を10ステップで書こうが1000ステップで書こうが
仕様が満たされていればいいかな。
もちろん、10ステップで実現可能な処理を1000ステップで書こうと
する人は、その分コストはかかるわけだから、なぜその処理に時間が
そこまでかかるのか、という意味でコードレビューに至ることは
あるかもしれないけどね。
コードレビューがまったく不要とは言わないけど現実的にはやらないね。
新人のコードなら見ることもあるかもしれないけど
保守性が高いコードとか、美しいコードとか、
PMの立場からいうと重要性はあまり高くない。
（繰り返すが、やる意味がまったくないとは言わない）
どちらかというと、仕様書のレビューはもちろんのこと、
テストケースがどの程度洗い出されているかの方が重要と思う。
例外処理のテストケースが含まれていなければ、それを
テストするように指示するのは必要でしょ。
例外処理を10ステップで書こうが1000ステップで書こうが
仕様が満たされていればいいかな。
もちろん、10ステップで実現可能な処理を1000ステップで書こうと
する人は、その分コストはかかるわけだから、なぜその処理に時間が
そこまでかかるのか、という意味でコードレビューに至ることは
あるかもしれないけどね。
358 ：仕様書無しさん：05/01/08 09:44:59
おいおい、企業がPMと位置付けてもらった位でPMを語らんで暮れ。
PMを目指している人へコードレビューが不要と言う人はPMじゃ無いから。
まず設計書ベース・レビューで済むと言う人は、設計工程と実装工程で決断・対処すべき事の違いが判っていない。
もし逆に違いがないなら工程別の成果物に意味の重複性が存在している筈だ。
その見分けが出来ない人間がPMな訳無いだろ。
次に、管理の基本として語られるPlan-Do-Seeサイクルは全てが揃って事を成す。
つまりプログラム構造を無視して変更性や品質を語るのは 検証意義としても片手落ちだ。
こう言う奴に限ってバグ０に意義を見出そうとして、
検証の費用対効果を考えずに、お客に検証の費用対効果を説明出来無い為、
効果的なプロジェクト運営が出来ずズタズタになる。
コードレビューが不要と言う人は、PM技能のある人では無く、名刺にPMと付けられた人だ。
PMを目指している人へコードレビューが不要と言う人はPMじゃ無いから。
まず設計書ベース・レビューで済むと言う人は、設計工程と実装工程で決断・対処すべき事の違いが判っていない。
もし逆に違いがないなら工程別の成果物に意味の重複性が存在している筈だ。
その見分けが出来ない人間がPMな訳無いだろ。
次に、管理の基本として語られるPlan-Do-Seeサイクルは全てが揃って事を成す。
つまりプログラム構造を無視して変更性や品質を語るのは 検証意義としても片手落ちだ。
こう言う奴に限ってバグ０に意義を見出そうとして、
検証の費用対効果を考えずに、お客に検証の費用対効果を説明出来無い為、
効果的なプロジェクト運営が出来ずズタズタになる。
コードレビューが不要と言う人は、PM技能のある人では無く、名刺にPMと付けられた人だ。
360 ：仕様書無しさん：05/01/08 13:30:21
>>358
こういう現状がまったく見えていないＰＭってどうして減らないんだろうね。
プロジェクト全体で残業しまくりなのにコードレビューもくそもねぇだろ。
スケジュール表からみなおせ馬鹿。
すでに駄目なんだよ、そんなプロジェクト。
さっさと帰らせてくれよ。
こういう現状がまったく見えていないＰＭってどうして減らないんだろうね。
プロジェクト全体で残業しまくりなのにコードレビューもくそもねぇだろ。
スケジュール表からみなおせ馬鹿。
すでに駄目なんだよ、そんなプロジェクト。
さっさと帰らせてくれよ。
コードレビューは品質もさることながら
教育としての意義が大きいと思う
あれ？コードレビュー不必要と言ってる人達って
要員の教育とか全く考慮してない？
だめだよ、近視眼的なものの見方してちゃ
だからいつもプロジェクト失敗しちゃうんだよ(w
教育としての意義が大きいと思う
あれ？コードレビュー不必要と言ってる人達って
要員の教育とか全く考慮してない？
だめだよ、近視眼的なものの見方してちゃ
だからいつもプロジェクト失敗しちゃうんだよ(w
>>358
工数（お金）を管理しないＰＭっているんだ。
品質よければ、時間やお金は気にしないプロジェクトってあるのかな。
ＰＭならば、コストと納期も考えろと、会社から言われるはずだが。
まあ、ＰＧが品質を追求することは悪くない。
それよりか、褒めてあげるべき事柄だからな。
分からなくても、ＯＫですよ。
コストや納期を考えて、品質に一線を引いて苦しむのがＰＭの仕事ですから。
工数（お金）を管理しないＰＭっているんだ。
品質よければ、時間やお金は気にしないプロジェクトってあるのかな。
ＰＭならば、コストと納期も考えろと、会社から言われるはずだが。
まあ、ＰＧが品質を追求することは悪くない。
それよりか、褒めてあげるべき事柄だからな。
分からなくても、ＯＫですよ。
コストや納期を考えて、品質に一線を引いて苦しむのがＰＭの仕事ですから。
366 ：358：05/01/08 22:14:44
世にはPM本だけ読んで自己都合で管理で語る人が増えましたね。
Prjの定義は出来ていますか？
納期ってなんですか？何によって決まるんですか？Prj中に納期の規定は一つしかないの？
それを過ぎるとどうなるの？Prjは強制終了するの？
馬鹿ですね。
品質ってなんですか？どうやって定義するんですか？Prj進捗中に品質定義は変わらないの？
品質が定義以下の場合どおなるんですか？
馬鹿ですね。
費用ってなんですか？誰からみた費用ですか？どうやって予算が決まるんですか？
費用って金の事ですよね、その金の算出方式は理解していますか？
まさか会計思想だけの費用算出だけで考えて無いですよね？
費用が予算を超えたらどうなるんですか？
馬鹿ですね。
３大要素は要素であって全てでは無いよ。
馬鹿ですね。
PMを依頼主の云う事を満たしてくれる魔法と勘違いしている様ですね。
そりゃ、話にならんは。現状じゃ無く現実を見てくれ。
Prjの定義は出来ていますか？
納期ってなんですか？何によって決まるんですか？Prj中に納期の規定は一つしかないの？
それを過ぎるとどうなるの？Prjは強制終了するの？
馬鹿ですね。
品質ってなんですか？どうやって定義するんですか？Prj進捗中に品質定義は変わらないの？
品質が定義以下の場合どおなるんですか？
馬鹿ですね。
費用ってなんですか？誰からみた費用ですか？どうやって予算が決まるんですか？
費用って金の事ですよね、その金の算出方式は理解していますか？
まさか会計思想だけの費用算出だけで考えて無いですよね？
費用が予算を超えたらどうなるんですか？
馬鹿ですね。
３大要素は要素であって全てでは無いよ。
馬鹿ですね。
PMを依頼主の云う事を満たしてくれる魔法と勘違いしている様ですね。
そりゃ、話にならんは。現状じゃ無く現実を見てくれ。
367 ：仕様書無しさん：05/01/08 22:23:05
>>366
で？（何がいいたいのかわかんねぇよ）
で？（何がいいたいのかわかんねぇよ）
369 ：358：05/01/08 22:25:26
>>369
グロを貼るな、ヴォケが!
グロを貼るな、ヴォケが!
>>369
グロ注意！（生首が転がる動画）
グロ注意！（生首が転がる動画）
372 ：358：05/01/08 23:41:08
>>367,368
学生が多いな、しゃ〜ない実務経験が無いもんな。お兄さんが教えてやるよ。
ソースレビューをしないとするのは問題ではないが、不要と云うのは問題。
期間と費用対効果、そして管理状態、人材評価を加味してソースレビューをしないと決断する事は良い事。
決断意識も無く、自分の正当性の為にソースレビューが不要といっているのは管理がわかっていない。
一からソースを書き上げるプロジェクトにてソースレビューが不要といえるのか？
もし既存コードを多用してソースレビューが不要と見なしたなら、「既存コードの多用」を理由としてソースレビューが不要と決断した。という意識が大切だ。
上記の決断意識が無い場合は管理をしたので無く、管理定義に従って動いているだけと云う事だ。
管理を知らない、管理をする気もない、管理が出来ない、そんな奴らがPMを語っている事に注意しろよ。
学生が多いな、しゃ〜ない実務経験が無いもんな。お兄さんが教えてやるよ。
ソースレビューをしないとするのは問題ではないが、不要と云うのは問題。
期間と費用対効果、そして管理状態、人材評価を加味してソースレビューをしないと決断する事は良い事。
決断意識も無く、自分の正当性の為にソースレビューが不要といっているのは管理がわかっていない。
一からソースを書き上げるプロジェクトにてソースレビューが不要といえるのか？
もし既存コードを多用してソースレビューが不要と見なしたなら、「既存コードの多用」を理由としてソースレビューが不要と決断した。という意識が大切だ。
上記の決断意識が無い場合は管理をしたので無く、管理定義に従って動いているだけと云う事だ。
管理を知らない、管理をする気もない、管理が出来ない、そんな奴らがPMを語っている事に注意しろよ。
コードレビューは後工程のコストを劇的に減少させるよ。
残業しまくりな人は一度試してみると良いよ。
残業しまくりな人は一度試してみると良いよ。
もう仕様変更がきた時点で主旨がかわっちゃうんだよね。
できたものがどうとかってより、残業をどのくらいやったかって
評価されるから製品の質なんてどうでもいいよ。
できたものがどうとかってより、残業をどのくらいやったかって
評価されるから製品の質なんてどうでもいいよ。
なんかレビュー云々以前に、普通にリスク管理が出来てない奴が居るな。
はっきりいってコードレビュー薦めてる奴の行動は
現在の作業にさらにコードレビューという名の作業を上乗せしてるだけ。
これでレビューで出た意見とそれに対しての結果とかをレポートで出せとかいわれたら最悪。
もうやる気無くす。
コードレビューを作業に追加したいなら現在やってる作業の何かを消してから追加しろ。
何が消せるんだ。
現在の作業にさらにコードレビューという名の作業を上乗せしてるだけ。
これでレビューで出た意見とそれに対しての結果とかをレポートで出せとかいわれたら最悪。
もうやる気無くす。
コードレビューを作業に追加したいなら現在やってる作業の何かを消してから追加しろ。
何が消せるんだ。
>>379
個人的な思い込みを全面に押し出すな。レポートなんて誰も書いてない。
作業の上乗せについては、>>293で書いたように数%の時間だけだ。
これにより後工程のリスクが激減する。
各テスト、仕変、パフォチュー、システム障害・・・、
例外無く数〜十割のコストが削減出来る。
こういうトレードオフを普通に検討してるだけ。
個人的な思い込みを全面に押し出すな。レポートなんて誰も書いてない。
作業の上乗せについては、>>293で書いたように数%の時間だけだ。
これにより後工程のリスクが激減する。
各テスト、仕変、パフォチュー、システム障害・・・、
例外無く数〜十割のコストが削減出来る。
こういうトレードオフを普通に検討してるだけ。
>>380
具体的に頼むよ。
どのくらいの実力持った奴が、どの程度、誰にレビューをすれば何のコストがどう削減されるの？
ここまで言えなきゃコードレビューなんてする意味ないでしょ？
とりあえずやればよくなるんじゃないかなーなんてちょっと考えただけの冬厨決定。
そもそもリスクリスクって俺はバグなんてほとんど出さないし、設計ミスもしないし。
プロジェクト開始から終わりまでひたすら組み続けてまだ間に合わないぐらいの
プロジェクトばっかりだぞ。
具体的に頼むよ。
どのくらいの実力持った奴が、どの程度、誰にレビューをすれば何のコストがどう削減されるの？
ここまで言えなきゃコードレビューなんてする意味ないでしょ？
とりあえずやればよくなるんじゃないかなーなんてちょっと考えただけの冬厨決定。
そもそもリスクリスクって俺はバグなんてほとんど出さないし、設計ミスもしないし。
プロジェクト開始から終わりまでひたすら組み続けてまだ間に合わないぐらいの
プロジェクトばっかりだぞ。
>>381
293の状況って事だから、仕様を把握した人間（ＰＭ自身？）が、一人で、ぱっと見るんだよ。
俺たちが想像しているものより、もっと適当なもだと思うよ。
だから、具体的な基準やその効果を求めてはだめです。
あと、380は脳内だと思うがな。
293の状況って事だから、仕様を把握した人間（ＰＭ自身？）が、一人で、ぱっと見るんだよ。
俺たちが想像しているものより、もっと適当なもだと思うよ。
だから、具体的な基準やその効果を求めてはだめです。
あと、380は脳内だと思うがな。
>>372
期間と費用対効果、そして管理状態、人材評価を加味した結果、一からソースを書き上げる
プロジェクトでソースレビューが不要ってなること多いと思うがな。
レビューは人に頼るところが大きいため、基準があいまいで質がぶれる。
コードレビューのバグって、単体テスト・結合テストで十分回収できる。
と思うのだが、お兄さんのプロジェクトでは、そうでないの？
期間と費用対効果、そして管理状態、人材評価を加味した結果、一からソースを書き上げる
プロジェクトでソースレビューが不要ってなること多いと思うがな。
レビューは人に頼るところが大きいため、基準があいまいで質がぶれる。
コードレビューのバグって、単体テスト・結合テストで十分回収できる。
と思うのだが、お兄さんのプロジェクトでは、そうでないの？
384 ：仕様書無しさん：05/01/09 10:04:46
>>383
>単体テスト・結合テスト
も十二分に人に頼る所が大きいと思うのですが
>単体テスト
レベルならそれこそ質がぶれると思うんだけど。
テストマンセー主義らしいけど、簡単な業務プログラムならもしかしたら
通用するかもしれないね。
でも、ちょっとしたシステムになると、とある人の作成した部分で
問題が発生。で、後に残った人達で作りなおしと。
そういうことができるプロジェクトっていいですね。
あっ。テスト万能主義だから問題ないんですね。
例外もテスト汁！って言って、その人達はしっかりと全てのケース
をテストしてくれるんですから。
羨ましいですね。
うちなんかほっておくと、結合テストレベルで機能の漏れが
発生したり、動いてもメモリーリークしまくりで1日も連続
稼動できない状態になっちゃうなぁ。
あと、ＰＭならば当然しってると思うけど、工程（フェーズ）が
後になればなるほど是正のコストがかかるんだけど。
この辺りはどう思ってるのかなぁ。
サンプルでチェックして横展開させてほうが、テスト段階になって
また作り直しってことにならないと思うんだけどなぁ〜
きっと違う世界の人なのですね羨ましい。
>単体テスト・結合テスト
も十二分に人に頼る所が大きいと思うのですが
>単体テスト
レベルならそれこそ質がぶれると思うんだけど。
テストマンセー主義らしいけど、簡単な業務プログラムならもしかしたら
通用するかもしれないね。
でも、ちょっとしたシステムになると、とある人の作成した部分で
問題が発生。で、後に残った人達で作りなおしと。
そういうことができるプロジェクトっていいですね。
あっ。テスト万能主義だから問題ないんですね。
例外もテスト汁！って言って、その人達はしっかりと全てのケース
をテストしてくれるんですから。
羨ましいですね。
うちなんかほっておくと、結合テストレベルで機能の漏れが
発生したり、動いてもメモリーリークしまくりで1日も連続
稼動できない状態になっちゃうなぁ。
あと、ＰＭならば当然しってると思うけど、工程（フェーズ）が
後になればなるほど是正のコストがかかるんだけど。
この辺りはどう思ってるのかなぁ。
サンプルでチェックして横展開させてほうが、テスト段階になって
また作り直しってことにならないと思うんだけどなぁ〜
きっと違う世界の人なのですね羨ましい。
385 ：384：05/01/09 10:07:53
（続き）
ちなみに言っておくけど、コーディングのサンプルチェックでバグが
全てなくなるとは言ってないよ。テストでバグが全てなくならないのと
思じで。
それこそ、顧客とシステムが求める品質レベルがどのぐらい
なのかを開発計画のフェーズでしっかり定義するもんだと思うんだけどな。
なんでこんな極論になっちゃうのかな。不思議。
>>381
>そもそもリスクリスクって俺はバグなんてほとんど出さないし、設計ミスもしないし。
他の人も出さないんですね。
凄いプロジェクトですねぇ〜 羨ましい。
もしかして一人プロジェクトでもＰＭって名前になるのか？
Personal Manager
とか・・・
ちなみに言っておくけど、コーディングのサンプルチェックでバグが
全てなくなるとは言ってないよ。テストでバグが全てなくならないのと
思じで。
それこそ、顧客とシステムが求める品質レベルがどのぐらい
なのかを開発計画のフェーズでしっかり定義するもんだと思うんだけどな。
なんでこんな極論になっちゃうのかな。不思議。
>>381
>そもそもリスクリスクって俺はバグなんてほとんど出さないし、設計ミスもしないし。
他の人も出さないんですね。
凄いプロジェクトですねぇ〜 羨ましい。
もしかして一人プロジェクトでもＰＭって名前になるのか？
Personal Manager
とか・・・
バグも設計ミスも無しでデスマって何が原因なんだろうね。
>>384
例外も含めてテストって、PMが指示しないと誰もやらんの?
レビューが不要とは思わんが、PMが言わなきゃやらんメンバーも
問題だらけですなぁ。
アンタんとこの場合、レビュー以前にメンバーの質が低過ぎないか?
例外も含めてテストって、PMが指示しないと誰もやらんの?
レビューが不要とは思わんが、PMが言わなきゃやらんメンバーも
問題だらけですなぁ。
アンタんとこの場合、レビュー以前にメンバーの質が低過ぎないか?
>>386
単純に仕様の詰めが甘いんでしょ?
実際問題、バグ無し、仕様通りの設計なのに、SEやPMが仕様の一部を
握りつぶしてて、下流に流してなかったっていう最悪のミスのせいで、
納期直前で徹夜続きになりましたぜ。
(もちろん、PG連中が聞き逃してたことにされたが。上流の連中が、
ミスを認めるわけも無いし。)
バグでも無けりゃ設計ミスでもないんだったら、もっと上流のミスの
可能性が高いと思うね。
単純に仕様の詰めが甘いんでしょ?
実際問題、バグ無し、仕様通りの設計なのに、SEやPMが仕様の一部を
握りつぶしてて、下流に流してなかったっていう最悪のミスのせいで、
納期直前で徹夜続きになりましたぜ。
(もちろん、PG連中が聞き逃してたことにされたが。上流の連中が、
ミスを認めるわけも無いし。)
バグでも無けりゃ設計ミスでもないんだったら、もっと上流のミスの
可能性が高いと思うね。
>>388
オレを攻撃するのは間違ってるよ。オレ、レビューは必要と思ってるしさ。
まぁ、バグがそれでゼロになるとは思ってねえが、リスクを軽減する効果は
あるしね。品質の問題もあるが、それ以前に何らかのミスで障害多発なんて
時に、レビュー無しでは、開発体制そのものが疑われる羽目になりかねんのよ。
でも、レビューしてもらえるからといって、メンバーが手を抜くような体制
はレビュー以前に、もっとやるべきことが多くねえか?と思いますな。
オレを攻撃するのは間違ってるよ。オレ、レビューは必要と思ってるしさ。
まぁ、バグがそれでゼロになるとは思ってねえが、リスクを軽減する効果は
あるしね。品質の問題もあるが、それ以前に何らかのミスで障害多発なんて
時に、レビュー無しでは、開発体制そのものが疑われる羽目になりかねんのよ。
でも、レビューしてもらえるからといって、メンバーが手を抜くような体制
はレビュー以前に、もっとやるべきことが多くねえか?と思いますな。
>>392
やる気でどうにかなるわけないじゃん。
別に気合でどうにかしろだなんて書いてないし、そんなつもりもない。
精神論でどうにかなるんだったら、管理いらねえ（笑)
ただなぁ、「例外も洗い出してやんな」なんてのは、やる気以前に
基本じゃないの?、それすら思いつかない連中って何?という気が。
ま、半分も居ればマシなんでない?
ついでに言うと、オレ、レビュー要らないなんて書いてねーから。
教えることをちゃんとやってないのに、メンバーの質が低いと嘆くの
は、常日頃のPMの手抜きのせいだろと思ってるだけッスよ。
やる気でどうにかなるわけないじゃん。
別に気合でどうにかしろだなんて書いてないし、そんなつもりもない。
精神論でどうにかなるんだったら、管理いらねえ（笑)
ただなぁ、「例外も洗い出してやんな」なんてのは、やる気以前に
基本じゃないの?、それすら思いつかない連中って何?という気が。
ま、半分も居ればマシなんでない?
ついでに言うと、オレ、レビュー要らないなんて書いてねーから。
教えることをちゃんとやってないのに、メンバーの質が低いと嘆くの
は、常日頃のPMの手抜きのせいだろと思ってるだけッスよ。
だから教育目的とも書いてるわけで。
>>393
別に。それにオレ、SE、PG兼任だし。
ま、上流、下流の関係を人間性の上下や立場の上下と混同してるアホ
が多いだけと思っているよ。
握りつぶしなんてのは、上流のミスだし、知ったことじゃない。
オレがその立場なら素直に詫びますがネ。少なくとも、先に帰る事は
ねーよ。手抜かれたら怖いもんね。
別に。それにオレ、SE、PG兼任だし。
ま、上流、下流の関係を人間性の上下や立場の上下と混同してるアホ
が多いだけと思っているよ。
握りつぶしなんてのは、上流のミスだし、知ったことじゃない。
オレがその立場なら素直に詫びますがネ。少なくとも、先に帰る事は
ねーよ。手抜かれたら怖いもんね。
特定のプロジェクトの特定人物に対する愚痴としか読めない
398 ：仕様書無しさん：05/01/09 12:12:28
>>387
2CHだからね
2CHだからね
>>398
さすが、ネット界の掃溜
さすが、ネット界の掃溜
400 ：仕様書無しさん：05/01/09 12:18:41
>>393,396
要件定義や外部設計で、詰めが甘いとか矛盾があるのは常識。
下流担当者なら、愚痴らず前向きに、それをどう対応するかがプロだろう。
まずは問題・課題の一覧を作り、欠陥発生局面(外部設計とか)を明確化する。
客観的資料が無いと「設計が悪い」「PGのせいだ」の水掛け論で終わるし、
最初の設計より、現実に沿った妥当な形で解決できる事も多い。
必要ならマネージャやユーザーとも協議しながら、
代案、暫定対応、恒久対応などを次々打ち出して行く、てのが普通だろう。
それができる立場にないとか、うちの会社じゃできない、て話なら、
それは気の毒だと同情するけど、愚痴の領域になっちゃうね。
要件定義や外部設計で、詰めが甘いとか矛盾があるのは常識。
下流担当者なら、愚痴らず前向きに、それをどう対応するかがプロだろう。
まずは問題・課題の一覧を作り、欠陥発生局面(外部設計とか)を明確化する。
客観的資料が無いと「設計が悪い」「PGのせいだ」の水掛け論で終わるし、
最初の設計より、現実に沿った妥当な形で解決できる事も多い。
必要ならマネージャやユーザーとも協議しながら、
代案、暫定対応、恒久対応などを次々打ち出して行く、てのが普通だろう。
それができる立場にないとか、うちの会社じゃできない、て話なら、
それは気の毒だと同情するけど、愚痴の領域になっちゃうね。
>>400
つか、外部設計はPGの領分なんで、文句は言わんよ。
ただ、要件定義はアンタらの領分だろ?と思うだけ。
設計変更が必要ならもちろん、上には言うが、上がミスってて、
下に流れてこないのは、どうしようもないんだよね。
上流過程の客ってのは、ユーザー以外にもPGもそうだという
認識はもって欲しいですな。
つか、外部設計はPGの領分なんで、文句は言わんよ。
ただ、要件定義はアンタらの領分だろ?と思うだけ。
設計変更が必要ならもちろん、上には言うが、上がミスってて、
下に流れてこないのは、どうしようもないんだよね。
上流過程の客ってのは、ユーザー以外にもPGもそうだという
認識はもって欲しいですな。
402 ：仕様書無しさん：05/01/09 12:30:43
コードレビューなんかいらないよ君の反論まだぁ〜〜
>>402
反論も何も肯定側になんの意見もでてないじゃん。
反論も何も肯定側になんの意見もでてないじゃん。
404 ：仕様書無しさん：05/01/09 12:35:30
>>401
んん？
「外部設計」の示す範囲は、会社やプロジェクトによって違うが、
普通はPGではなくユーザーやシステム部の領分でないか？
画面や帳票やDBに格納するデータ項目(論理)を決めるのも外部でしょ。
内部(クラス分けとかINDEXとか)は、SE/PGレベルでいいと思うが。
んん？
「外部設計」の示す範囲は、会社やプロジェクトによって違うが、
普通はPGではなくユーザーやシステム部の領分でないか？
画面や帳票やDBに格納するデータ項目(論理)を決めるのも外部でしょ。
内部(クラス分けとかINDEXとか)は、SE/PGレベルでいいと思うが。
405 ：仕様書無しさん：05/01/09 12:38:52
>>402,403
まともな欠陥除去工程論では、単体・結合・システムなどの各局面テストに加え、
少なくともサンプリング的なソースレビューを早期に行うことは常識。
実際、大きな勘違いで量産してる事が多いし。
まともな欠陥除去工程論では、単体・結合・システムなどの各局面テストに加え、
少なくともサンプリング的なソースレビューを早期に行うことは常識。
実際、大きな勘違いで量産してる事が多いし。
そもそも領分とか言ってる時点でズレまくってるよ。
もっと皆で協力しようよ。
もっと皆で協力しようよ。
409 ：358：05/01/09 13:30:16
>>402
俺が否定派の管理無能さを晒してやったから。
そんな馬鹿はいないと思うけどな。
仕様変更の話は、確かに仕様変更によってレビュー効果が打ち消さされるが、
それは仕様変更の問題だ、問題をごっちゃにしてレビューを安易に否定するのは
管理能力が無いし、管理するつもりが無い証拠。
言わば、強盗が貧乏が悪いと言っているのと同レベルなんだよ。
ここまで言えば解ったかな。現在存在する多くのPMやユーザ代表は、
自己都合や利権の為に「管理」を歪めている。気をつけろ！
俺が否定派の管理無能さを晒してやったから。
そんな馬鹿はいないと思うけどな。
仕様変更の話は、確かに仕様変更によってレビュー効果が打ち消さされるが、
それは仕様変更の問題だ、問題をごっちゃにしてレビューを安易に否定するのは
管理能力が無いし、管理するつもりが無い証拠。
言わば、強盗が貧乏が悪いと言っているのと同レベルなんだよ。
ここまで言えば解ったかな。現在存在する多くのPMやユーザ代表は、
自己都合や利権の為に「管理」を歪めている。気をつけろ！
410 ：仕様書無しさん：05/01/09 13:41:42
>>409
違うね。
その理論じゃレビューのためにレビューをやるといっているようなもの。
全体をみてその中でレビューにどれくらいの効果があるのかということを
示せないならなんにも意味が無いＰＭのオナニーといって過言でもない。
まあ、ＰＭなんて仕事真面目にやろうとしなけりゃ仕事なんてないもんね。
たまに一生懸命プログラムいじってるＰＧにちょっかい出してみたい気持ちも
わかるけどはっきり言って邪魔だからほどほどにねｗ
違うね。
その理論じゃレビューのためにレビューをやるといっているようなもの。
全体をみてその中でレビューにどれくらいの効果があるのかということを
示せないならなんにも意味が無いＰＭのオナニーといって過言でもない。
まあ、ＰＭなんて仕事真面目にやろうとしなけりゃ仕事なんてないもんね。
たまに一生懸命プログラムいじってるＰＧにちょっかい出してみたい気持ちも
わかるけどはっきり言って邪魔だからほどほどにねｗ
411 ：仕様書無しさん：05/01/09 14:05:34
>>レビューにどれくらいの効果があるのかということを
>>示せないならなんにも意味が無い
お前大丈夫か？相当墓穴掘っているぞ。
頼むから、無能な奴は高慢な態度は止めてくれ。
どれくらいの効果があるのか事前に示し保証出来ならば管理はいらない。
どれくらいの効果があるのか予想は出来るレベルだから管理がいる。
いや実際には予想出来無い事の方が多い。
コードレビューの性質を知りたいならば、コードレビューは事前確認だ。
つまり文書定義しない事、テスト行為で立証し難い事、認識合わせの早期対処である。
コードレビューの重要性が解らない人はまず、テスト技法を徹底的に勉強すると良い。
簡単に言えばテスト技法はOUTPUT出来ない事に対して検証が出来ない問題性質を持つ。
そして行為が事後確認になる問題性質も合わせ持つ。
その性質と状況の噛合わせ結果を想定し、決断を下すのだ。
PGの実務経験があるならば、性質理解だけで行動が無し得ず、効果提示が出来無い事くらいはわかるよね？
>>示せないならなんにも意味が無い
お前大丈夫か？相当墓穴掘っているぞ。
頼むから、無能な奴は高慢な態度は止めてくれ。
どれくらいの効果があるのか事前に示し保証出来ならば管理はいらない。
どれくらいの効果があるのか予想は出来るレベルだから管理がいる。
いや実際には予想出来無い事の方が多い。
コードレビューの性質を知りたいならば、コードレビューは事前確認だ。
つまり文書定義しない事、テスト行為で立証し難い事、認識合わせの早期対処である。
コードレビューの重要性が解らない人はまず、テスト技法を徹底的に勉強すると良い。
簡単に言えばテスト技法はOUTPUT出来ない事に対して検証が出来ない問題性質を持つ。
そして行為が事後確認になる問題性質も合わせ持つ。
その性質と状況の噛合わせ結果を想定し、決断を下すのだ。
PGの実務経験があるならば、性質理解だけで行動が無し得ず、効果提示が出来無い事くらいはわかるよね？
412 ：仕様書無しさん：05/01/09 14:22:52
>>411
で、ずーっとコードレビューの効果とかってあいまいなままだよね？
俺はさ、効果の示せないことは必要不必要以前にするべきじゃないと思ってるんだけど。
だって、効果がよくわからないんだよ。
はじめのうちはその効能がよくわかってる人間でうまく使えてる状態や環境があるかもしれないけど。
そのうち「これってやる意味あるの？」ってなるよ。
現にここでいくらコードレビューについて「どれくらいの効果があるの？」ってきいたって
返ってくるレスは「わからない奴は駄目な奴だ」とか「そのくらいわからないの？」とか
ほんとに効果あるんだかなんだかよくわからないレスばっかりじゃん。
はっきりいって俺がクライアントだったら、この工程にお金は出せない。
説得力皆無だもん。効果もよくわかんないし。
ＰＭだってこの作業が必要かどうかを客に説得することできんの？
で、ずーっとコードレビューの効果とかってあいまいなままだよね？
俺はさ、効果の示せないことは必要不必要以前にするべきじゃないと思ってるんだけど。
だって、効果がよくわからないんだよ。
はじめのうちはその効能がよくわかってる人間でうまく使えてる状態や環境があるかもしれないけど。
そのうち「これってやる意味あるの？」ってなるよ。
現にここでいくらコードレビューについて「どれくらいの効果があるの？」ってきいたって
返ってくるレスは「わからない奴は駄目な奴だ」とか「そのくらいわからないの？」とか
ほんとに効果あるんだかなんだかよくわからないレスばっかりじゃん。
はっきりいって俺がクライアントだったら、この工程にお金は出せない。
説得力皆無だもん。効果もよくわかんないし。
ＰＭだってこの作業が必要かどうかを客に説得することできんの？
413 ：411：05/01/09 14:41:32
>>412
性質と状況の想定をして効能を決めるのが解らないのかな？
もし意味がわからないならば何かの技法や技術について一つ効果を論理的に提示して下さい。
そしたら貴方が言っている事に矛盾があり、その矛盾が間違いを呼び出していると気付くよ。
>ＰＭだってこの作業が必要かどうかを客に説得することできんの？
君は管理した事ないでしょ？人は理論では動かないのだよ。
人を動かす場合、目的達成する場合に行う説明の為の理論は後付けでいいんだよ。
管理経験の無い妄想君達は反論でなく、質問で問い掛けてくれ。
性質と状況の想定をして効能を決めるのが解らないのかな？
もし意味がわからないならば何かの技法や技術について一つ効果を論理的に提示して下さい。
そしたら貴方が言っている事に矛盾があり、その矛盾が間違いを呼び出していると気付くよ。
>ＰＭだってこの作業が必要かどうかを客に説得することできんの？
君は管理した事ないでしょ？人は理論では動かないのだよ。
人を動かす場合、目的達成する場合に行う説明の為の理論は後付けでいいんだよ。
管理経験の無い妄想君達は反論でなく、質問で問い掛けてくれ。
>>413
>人を動かす場合、目的達成する場合に行う説明の為の理論は後付けでいいんだよ。
なんだよじゃあコードレビューも実用的かどうかってのは怪しいんだ？
役に立つかどうかじゃなくてお前がやりたいだけかよ。
まあ、そんなところだと思ったけど。
つまるところＰＭが仕事してるように見えるからやるんだ。
はぁ・・・アホくさ。
>人を動かす場合、目的達成する場合に行う説明の為の理論は後付けでいいんだよ。
なんだよじゃあコードレビューも実用的かどうかってのは怪しいんだ？
役に立つかどうかじゃなくてお前がやりたいだけかよ。
まあ、そんなところだと思ったけど。
つまるところＰＭが仕事してるように見えるからやるんだ。
はぁ・・・アホくさ。
415 ：仕様書無しさん：05/01/09 14:49:09
>>412
えっと、悪いけどさ、このスレで何を求めているの？
こんな全国区無料匿名掲示板で、雑談やヒント以上のレスを期待するなら甘すぎ。
そんな定量的に「何％の工数を投入すれば何％の欠陥が除去できる」てな
「効果」が出るわけもない。ただ、個々のプロジェクトでの実績や、
ＰＭに関わる手法としての統計は色々ある。
曖昧だから「しない、できない」、というより、
個々に適用して効果を見て反復したり、不要なら減らしたりする工程が重要だろう。
何故なら、要件も環境も開発者も毎回違うから、簡単な法則にはならない。
スポーツでも開発でも経営でも、実は同じ。日々是実践って奴だ。
まじめに知りたければプロジェクト学会とかで山と資料があるよ。
えっと、悪いけどさ、このスレで何を求めているの？
こんな全国区無料匿名掲示板で、雑談やヒント以上のレスを期待するなら甘すぎ。
そんな定量的に「何％の工数を投入すれば何％の欠陥が除去できる」てな
「効果」が出るわけもない。ただ、個々のプロジェクトでの実績や、
ＰＭに関わる手法としての統計は色々ある。
曖昧だから「しない、できない」、というより、
個々に適用して効果を見て反復したり、不要なら減らしたりする工程が重要だろう。
何故なら、要件も環境も開発者も毎回違うから、簡単な法則にはならない。
スポーツでも開発でも経営でも、実は同じ。日々是実践って奴だ。
まじめに知りたければプロジェクト学会とかで山と資料があるよ。
416 ：仕様書無しさん：05/01/09 14:52:34
>>406
プロジェクトやシステム規模が違うからだと思うけど、
仮にPGが内部設計だけをやれば良い場合でも、それが楽だと思うのは、
これまた世間知らずじゃないかな。
内部設計をやるには要件定義・外部設計の把握と、その行間にあるような目的、
それとシステム的な性能・拡張性・生産性・障害対策などを、
多少とも理解してないとできないんだが．．．
プロジェクトやシステム規模が違うからだと思うけど、
仮にPGが内部設計だけをやれば良い場合でも、それが楽だと思うのは、
これまた世間知らずじゃないかな。
内部設計をやるには要件定義・外部設計の把握と、その行間にあるような目的、
それとシステム的な性能・拡張性・生産性・障害対策などを、
多少とも理解してないとできないんだが．．．
>>415
人は理論では動かないのだよ
人は理論では動かないのだよ
>>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
これらが妥当かどうか、つー話以前に、システム開発の品質向上の考え方や技法は
１つの学問になるくらいあって、それをツールとして取捨選択して適用して
試行錯誤してるのが現実だ、というところは最低限理解しよう。
そうでないと、いきなり「必要か、不要か」の極論になるだけ。
参考資料
高度情報処理技術者試験の論文集 PM−プロジェクトマネージャ−過去問題＆論文例
http://ww5.tiki.ne.jp/~nmura/js/kako/pm.html
組込みソフトウェア技術者・管理者向けセミナー
http://www.sessame.jp/seminar/Seminar2004_09/Seminar2004_09_Report.htm
これらが妥当かどうか、つー話以前に、システム開発の品質向上の考え方や技法は
１つの学問になるくらいあって、それをツールとして取捨選択して適用して
試行錯誤してるのが現実だ、というところは最低限理解しよう。
そうでないと、いきなり「必要か、不要か」の極論になるだけ。
420 ：仕様書無しさん：05/01/09 15:03:24
421 ：仕様書無しさん：05/01/09 15:05:47
422 ：仕様書無しさん：05/01/09 15:07:22
423 ：仕様書無しさん：05/01/09 15:08:14
人が理論で動かないとすれば、多分使った理論が正しく無いんだよ。
425 ：仕様書無しさん：05/01/09 15:14:49
ソフトウェア開発の品質向上プロセスなら、今はCMMを知ることも避けられない
USでは政府や大企業からの発注の前提に、求められているのが現状。
日本もPM学会や政府で推進しとる。中身は、徹底的なドキュメント化など、
ISO9001同様に形骸化(外見だけアメリカ流にする)の恐れも大きいが、
かといって無視できないから、ツールとして活用するのが妥当だろうね。
http://www.atmarkit.co.jp/aig/04biz/cmm.html
USでは政府や大企業からの発注の前提に、求められているのが現状。
日本もPM学会や政府で推進しとる。中身は、徹底的なドキュメント化など、
ISO9001同様に形骸化(外見だけアメリカ流にする)の恐れも大きいが、
かといって無視できないから、ツールとして活用するのが妥当だろうね。
http://www.atmarkit.co.jp/aig/04biz/cmm.html
>>425
むしろ時代遅れでしょ
むしろ時代遅れでしょ
>>426
それは多分論理的に正しくないんだよ。
それは多分論理的に正しくないんだよ。
429 ：仕様書無しさん：05/01/09 15:22:12
プロジェクトマネジメント学会
http://www.spm-japan.jp/index-j.html
http://www.spm-japan.jp/index-j.html
431 ：仕様書無しさん：05/01/09 15:28:01
単に酒のんで愚痴を書き続けてる人が１名いるスレですね
スレタイとも関係ないじゃん。
スレタイとも関係ないじゃん。
パンツマン！？
>>430
それは多分感情論に走る事を論理に組み込んでないんだよ。
それは多分感情論に走る事を論理に組み込んでないんだよ。
>>433
すでに屁理屈だなｗ
すでに屁理屈だなｗ
>>434
屁理屈と煽り以外、ここにあるの?
屁理屈と煽り以外、ここにあるの?
>>435
>>413
>君は管理した事ないでしょ？人は理論では動かないのだよ。
>人を動かす場合、目的達成する場合に行う説明の為の理論は後付けでいいんだよ。
がこんなこと言う前は一応のルールはあったけど
さすがに理論は後付けのＰＭがきちゃあ俺もお手上げだねぇ（激藁失笑核爆）
>>413
>君は管理した事ないでしょ？人は理論では動かないのだよ。
>人を動かす場合、目的達成する場合に行う説明の為の理論は後付けでいいんだよ。
がこんなこと言う前は一応のルールはあったけど
さすがに理論は後付けのＰＭがきちゃあ俺もお手上げだねぇ（激藁失笑核爆）
>>438
？？？
？？？
>>414
ちょっと残念な結果だな。
413は、やらば出来る子だと思ってたのに。
効果やコストは不明です。
根拠もありませんが、コードレビューを行うことにより、品質の向上・トータルコストの
減少が実現できます。
てな、熱い主張が通るイカシタ会社にお勤めって事だ。
うらやましい限りだな。
ちょっと残念な結果だな。
413は、やらば出来る子だと思ってたのに。
効果やコストは不明です。
根拠もありませんが、コードレビューを行うことにより、品質の向上・トータルコストの
減少が実現できます。
てな、熱い主張が通るイカシタ会社にお勤めって事だ。
うらやましい限りだな。
441 ：仕様書無しさん：05/01/10 02:14:15
>>436
人を動かす場合に関しての話だ。管理全般じゃない。
理論で人動かす場合は理論の内容は然程重要ではない。
話す内容の内、理論の重要性はたった数行の話で事が足りる。
後は演出の為の話が相当割合を占める。
例えば、ビジョンを示し共感させる方法を考えれば解るよ。
>>440
おいおい、実状があれば想定効果や予想コストは出せるが、
仮想の状況提示しても意味が無い事位は理解出来るよな？
掲示板でいえる技法の性質だけって理解出来ない？
これ管理技法だけに留まらないよ？
反論があるんらば、何か一つ技法に関するコストや効果を提示してみろ。学生君。
煽りが無能や無知を晒す結果になると恥ずかしいな。
そして指摘が図星な為に、自分の正当化を補正する為、更なる無知さを晒す。
それが2chのパターンか。ここにも議論相手はいないな。残念！
人を動かす場合に関しての話だ。管理全般じゃない。
理論で人動かす場合は理論の内容は然程重要ではない。
話す内容の内、理論の重要性はたった数行の話で事が足りる。
後は演出の為の話が相当割合を占める。
例えば、ビジョンを示し共感させる方法を考えれば解るよ。
>>440
おいおい、実状があれば想定効果や予想コストは出せるが、
仮想の状況提示しても意味が無い事位は理解出来るよな？
掲示板でいえる技法の性質だけって理解出来ない？
これ管理技法だけに留まらないよ？
反論があるんらば、何か一つ技法に関するコストや効果を提示してみろ。学生君。
煽りが無能や無知を晒す結果になると恥ずかしいな。
そして指摘が図星な為に、自分の正当化を補正する為、更なる無知さを晒す。
それが2chのパターンか。ここにも議論相手はいないな。残念！
442 ：仕様書無しさん：05/01/10 02:31:49
２ｃｈでは、議論なんかしてませんから〜！！ ＰＭ斬り！あげ
>>441
はぁ？つーか今まさに人を動かせるかどうかのことをいってんじゃん。
俺はコードレビューは必要ないっていってるのに対して、
君はコードレビューは必要だっていってるんだよ？
現場で俺と君があったらどっちかの主張が通ってどっちかの主張は通らないんだよ。
これが人を動かすことじゃなくてなんだっていうの？
で「理論は後付けでいいんだよ」とか言い出すし、馬鹿かひっこんでろ。
もうこなくていいよｗ
はぁ？つーか今まさに人を動かせるかどうかのことをいってんじゃん。
俺はコードレビューは必要ないっていってるのに対して、
君はコードレビューは必要だっていってるんだよ？
現場で俺と君があったらどっちかの主張が通ってどっちかの主張は通らないんだよ。
これが人を動かすことじゃなくてなんだっていうの？
で「理論は後付けでいいんだよ」とか言い出すし、馬鹿かひっこんでろ。
もうこなくていいよｗ
>>441
コードレビューの優位性を証明するには、何らかの計算をするわけでしょ。
その計算式を提示してくれればいいのよ。
実状ってのは入力パラメータに過ぎないわけなんだから。
ただ、どんなパラメータがあって、どう判断してるの聞いてるだけだよ。
まあ、難しかったら、実例でもいいよ。
コードレビューの優位性を証明するには、何らかの計算をするわけでしょ。
その計算式を提示してくれればいいのよ。
実状ってのは入力パラメータに過ぎないわけなんだから。
ただ、どんなパラメータがあって、どう判断してるの聞いてるだけだよ。
まあ、難しかったら、実例でもいいよ。
445 ：コードレビューの計算（1/2）：05/01/10 11:57:26
例えば５人プロジェクトで各メンバーのスキル（＝品質としとく）をこう置く。
Ａ：10skl Ｂ：8skl Ｃ：6skl Ｄ：4skl Ｅ：2skl
ここで、生成済みコードに対する作業の生産性は作成者のスキル比率で表すとする。
つまり同じ程度の仕様変更を組み込む場合、
Ａのコードを直すよりＥのコードを直す方が10/2＝5倍かかるとする。
バグ発生〜回収も同様。要は後工程の作業比率全部に影響すると考える。
ここで、コードレビューを行うと、レビュアーに対して品質が平均化するとする。
つまりＡがＥをレビューすればＥのコードは(10+2)/2=6sklになるとする。
Ａ：10skl Ｂ：8skl Ｃ：6skl Ｄ：4skl Ｅ：2skl
ここで、生成済みコードに対する作業の生産性は作成者のスキル比率で表すとする。
つまり同じ程度の仕様変更を組み込む場合、
Ａのコードを直すよりＥのコードを直す方が10/2＝5倍かかるとする。
バグ発生〜回収も同様。要は後工程の作業比率全部に影響すると考える。
ここで、コードレビューを行うと、レビュアーに対して品質が平均化するとする。
つまりＡがＥをレビューすればＥのコードは(10+2)/2=6sklになるとする。
446 ：コードレビューの計算（2/2）：05/01/10 11:58:19
さて、全員が1ks（キロステップ）ずつ実装した場合、
全部で5ks、品質の平均は6skl/ks。
全てＡがレビューした場合は8skl/ks。
つまり製造後のコストが75％に減ると考えられる。
ここで設計完了から２ヶ月のプロジェクトを想定し、
１ヶ月実装１ヶ月テストとすると、テスト期間の25%、
つまり1週間以内でコードレビューを行えるならコストが下がる。
つまり製造工程の20%をコードレビューが占めない限りは意義がある。
あくまで例えばね。
全部で5ks、品質の平均は6skl/ks。
全てＡがレビューした場合は8skl/ks。
つまり製造後のコストが75％に減ると考えられる。
ここで設計完了から２ヶ月のプロジェクトを想定し、
１ヶ月実装１ヶ月テストとすると、テスト期間の25%、
つまり1週間以内でコードレビューを行えるならコストが下がる。
つまり製造工程の20%をコードレビューが占めない限りは意義がある。
あくまで例えばね。
どのレベルをコードレビューって言ってるの？
単体テストが終わっていて、パッと見モジュール化されてるか程度のチェックで十分じゃないのか？
１０００ステップでも数分見ればメンテ性は判ると思うんだが。
単体テストが終わっていて、パッと見モジュール化されてるか程度のチェックで十分じゃないのか？
１０００ステップでも数分見ればメンテ性は判ると思うんだが。
448 ：仕様書無しさん：05/01/10 19:02:17
>>447
なんで単体テストの後？
もしそれで修正になったら、関連する単体テストをもう一度
やりなおすことになるんだけど。
デグレードのこととか考えてないでしょ？
個人的には、コードレビューはサンプルチェックを行い、
コーダーの力量及び問題点の横展開を早期段階で行う物だと
思うんだけどなぁ。
なんで単体テストの後？
もしそれで修正になったら、関連する単体テストをもう一度
やりなおすことになるんだけど。
デグレードのこととか考えてないでしょ？
個人的には、コードレビューはサンプルチェックを行い、
コーダーの力量及び問題点の横展開を早期段階で行う物だと
思うんだけどなぁ。
449 ：仕様書無しさん：05/01/10 19:08:45
誰もソース見て処理内容が解るレベルまでレビューしないだろ．．．
ソースレビューはプログラム構造の目視検査が目的だから、
１実行モジュール分のソースでも10分もあれも充分、普通は1分で終わらせる。
時間がかかるのは、指摘と改善方法の指定を教える事だけど．．．
まさか、、処理内容が解るレベルのレビューを想定して話をしていたのか？？？？？
であれば、否定者の意見もうなずけるけど、逆にソースレビューは何をするか知らないのは痛いネ。
ソースレビューはプログラム構造の目視検査が目的だから、
１実行モジュール分のソースでも10分もあれも充分、普通は1分で終わらせる。
時間がかかるのは、指摘と改善方法の指定を教える事だけど．．．
まさか、、処理内容が解るレベルのレビューを想定して話をしていたのか？？？？？
であれば、否定者の意見もうなずけるけど、逆にソースレビューは何をするか知らないのは痛いネ。
>>449
うわ、やべぇ、こいつ、程度問題で上げ足とりはじめたぞ。
うわ、やべぇ、こいつ、程度問題で上げ足とりはじめたぞ。
>>449
> 誰もソース見て処理内容が解るレベルまでレビューしないだろ．．．
簡単に断言しますね。
しかし1分で終わらせるソースレビューって一般的なの？
「この人の1実行モジュール」が分からないと何も言えないけど。
> 誰もソース見て処理内容が解るレベルまでレビューしないだろ．．．
簡単に断言しますね。
しかし1分で終わらせるソースレビューって一般的なの？
「この人の1実行モジュール」が分からないと何も言えないけど。
ソースレビューやるとしたら、初期段階でしょ？
こんな感じで作成していきましょうってノリで。
その後は、やってもたいへんだから、大体、経験ある人がエディタ上で確認することは
あってもプリントアウトしてレビューなんてよほどのことがないとやらないね。
単体テスト後とか1分なんて言っているのは、板が間違ってるんじゃないかな？
こんな感じで作成していきましょうってノリで。
その後は、やってもたいへんだから、大体、経験ある人がエディタ上で確認することは
あってもプリントアウトしてレビューなんてよほどのことがないとやらないね。
単体テスト後とか1分なんて言っているのは、板が間違ってるんじゃないかな？
印刷強要される人は自分が低スキルで問題視されてる事に気付いた方がいいな。
昔の人はしゃーないね。
457 ：仕様書無しさん：05/01/10 20:45:37
皆ソースレビューって二人で話あってやってんの？
後ツールとか活用してないの？
後ツールとか活用してないの？
458 ：仕様書無しさん：05/01/10 20:47:09
>>450
程度じゃない定義だろ。
程度じゃない定義だろ。
つうかさ、ソースレビューってPMの話じゃないだろ？
チームリーダーとかその手の仕事。
チームリーダーとかその手の仕事。
PM = リーダーの場合も多いけどな
461 ：仕様書無しさん：05/01/10 22:14:17
だからソースレビューの話はここでもう不要でしょ？
【テスト】品質管理について語ろう【QA】
http://pc5.2ch.net/test/read.cgi/prog/1088135300/l50
こっちでやってくれ。うざい。
【テスト】品質管理について語ろう【QA】
http://pc5.2ch.net/test/read.cgi/prog/1088135300/l50
こっちでやってくれ。うざい。
463 ：仕様書無しさん：05/01/10 22:37:45
なんか熱い２〜３名が同じことの繰り返ししてるように見えるけどな。
全然進歩無いじゃん。
どの業界でも品質確保は、全量へのテストに加えて、抜き取りの
インスペクションを併用する。これは常識。
結合テストや性能テストで同じ問題が各モジュールに発生したら、
手戻りが大きく、品質・コスト・納期を達成できないから。
効果を定量化できない、というのは事実だが、それは全てのテストにも言える。
インスペクションは本来はＰＭの作業では無いが、
各種の品質確保手法は、ＰＭが効果を見ながら旗振りすべきではある。
（効果が無いなら止める、別の手法を適用する、とかの判断が重要。形式主義はいかん。）
全然進歩無いじゃん。
どの業界でも品質確保は、全量へのテストに加えて、抜き取りの
インスペクションを併用する。これは常識。
結合テストや性能テストで同じ問題が各モジュールに発生したら、
手戻りが大きく、品質・コスト・納期を達成できないから。
効果を定量化できない、というのは事実だが、それは全てのテストにも言える。
インスペクションは本来はＰＭの作業では無いが、
各種の品質確保手法は、ＰＭが効果を見ながら旗振りすべきではある。
（効果が無いなら止める、別の手法を適用する、とかの判断が重要。形式主義はいかん。）
>>462
取捨選択の議論だから問題無いでしょ。
取捨選択の議論だから問題無いでしょ。
465 ：仕様書無しさん：05/01/10 23:24:23
>>462
次のネタ振り頼む！
次のネタ振り頼む！
466 ：仕様書無しさん：05/01/10 23:27:11
客の要求は、営業の話と違うから、ＰＭ降りるって言ったら
会社、辞めてくれって言われたけど。（遠まわしにだが）
そういうもんか？
会社、辞めてくれって言われたけど。（遠まわしにだが）
そういうもんか？
比較的低スキルな人ってどう扱ってる？
２、３ヶ月のプロジェクトで教育しても意味無いし、
契約上辞めさせる事も出来ないし。
２、３ヶ月のプロジェクトで教育しても意味無いし、
契約上辞めさせる事も出来ないし。
>客の要求は、営業の話と違うから、ＰＭ降りる
試験問題が、模擬試験と違うから、受験やめる
．．．こちらがお願いします。辞めろ
試験問題が、模擬試験と違うから、受験やめる
．．．こちらがお願いします。辞めろ
471 ：仕様書無しさん：05/01/10 23:39:09
>>467
アサインの問題。
誰でもできる作業を振って、他の人の仕事を楽にするとか、
グループ作業にしてそのグループ内でヘルプしてもらうとか。
何かさせてれば、意外な面で役に立ったりもするし。
技術が無くても几帳面なら資料整理とか。
アサインの問題。
誰でもできる作業を振って、他の人の仕事を楽にするとか、
グループ作業にしてそのグループ内でヘルプしてもらうとか。
何かさせてれば、意外な面で役に立ったりもするし。
技術が無くても几帳面なら資料整理とか。
472 ：仕様書無しさん：05/01/10 23:46:56
>>466
程度の問題じゃないか？
どの会社でも、話が同じなんて幸福な場合はほとんど無い。
ただ、実現性がゼロで、引き受けた場合は客にも迷惑がかかるような
場合は、上層部へ主張して履歴は残すべきだろう。
（結果がどうなるかは別として）
程度の問題じゃないか？
どの会社でも、話が同じなんて幸福な場合はほとんど無い。
ただ、実現性がゼロで、引き受けた場合は客にも迷惑がかかるような
場合は、上層部へ主張して履歴は残すべきだろう。
（結果がどうなるかは別として）
会社にもよるけど、営業の話とか客の話なんて最初から正しいなんてことはない。
客だって業務はわかっていても実現方法がわかってないなんて当然。
営業なんてそれ以下。
それをどうにかするのがPMというかSEの仕事の楽しい部分だと思うんだが。
相手の予算とかこっちの事情を考えて、いろいろ調整するのがおもしろいわけで。
客だって業務はわかっていても実現方法がわかってないなんて当然。
営業なんてそれ以下。
それをどうにかするのがPMというかSEの仕事の楽しい部分だと思うんだが。
相手の予算とかこっちの事情を考えて、いろいろ調整するのがおもしろいわけで。
>>449
プログラム構造の目視検査で保障される物って何なんだろう。
これが分からんのよ。
俺は、処理内容が解るレベルまでレビューしないと、後工程の工数削減に寄与する
事はできんと思うのだが。
また、プログラマの能力把握の為の切り抜きインスペクション（カコイイ言い方だ
な、頂きます）てのも一理あるが、コーディングを始めた段階では手遅れっぽい。
能力の把握はリスク管理に対する投資になるが、能力が劣っていたからといって、
この段階では打つ手があまりない。（ただ、自分の目の節穴ぷりを嘆くだけ）
仕様追加でもあれば、担当選択では役に立つと思うのだが。
プログラム構造の目視検査で保障される物って何なんだろう。
これが分からんのよ。
俺は、処理内容が解るレベルまでレビューしないと、後工程の工数削減に寄与する
事はできんと思うのだが。
また、プログラマの能力把握の為の切り抜きインスペクション（カコイイ言い方だ
な、頂きます）てのも一理あるが、コーディングを始めた段階では手遅れっぽい。
能力の把握はリスク管理に対する投資になるが、能力が劣っていたからといって、
この段階では打つ手があまりない。（ただ、自分の目の節穴ぷりを嘆くだけ）
仕様追加でもあれば、担当選択では役に立つと思うのだが。
475 ：仕様書無しさん：05/01/11 00:12:57
>>474
>プログラム構造の目視検査で保障される物って何なんだろう。
だから、誰も保証する話なんてしてないのでは？
>俺は、処理内容が解るレベルまでレビューしないと、後工程の工数削減に寄与する
>事はできんと思うのだが。
処理内容というよりは、機能は把握した上でレビューするのでは？
ここはhogehoge処理です。って具合で。
・コーディング規則にあっているか。
・必要な機能は実装されているか。
・エラー処理はちゃんとやってるか。
問題があるようなら、別のモジュール（＆人）も同じような
ことやってる可能性があるから、展開する。
これがソースレビューってもんだと思うけど。
>また、プログラマの能力把握の為の切り抜きインスペクション（カコイイ言い方だ
>な、頂きます）てのも一理あるが、コーディングを始めた段階では手遅れっぽい。
手遅れかどうかなら、手遅れではないのでは？
先にやれという意見も、それはそれで理想的だけど、業務（開発）と
関係ないコーディングを前もってさせて力量を把握というのは
現実的じゃないような気が。
それこそ、それが今回の業務（開発）とマッチしてるか、その内容が
ベンチマークに利用できるかは怪しいと思う。
まぁ、開発計画の段階で、過去の要因のスキルをフィードバックできる
のならば、適材適所を考えるのは基本だけど。
PMBOKでいう所の要因手配と過去の情報ってとこ。
少なくても、完璧じゃないから後工程に回すって考え方は、問題の後回し
だと思うなぁ〜
>プログラム構造の目視検査で保障される物って何なんだろう。
だから、誰も保証する話なんてしてないのでは？
>俺は、処理内容が解るレベルまでレビューしないと、後工程の工数削減に寄与する
>事はできんと思うのだが。
処理内容というよりは、機能は把握した上でレビューするのでは？
ここはhogehoge処理です。って具合で。
・コーディング規則にあっているか。
・必要な機能は実装されているか。
・エラー処理はちゃんとやってるか。
問題があるようなら、別のモジュール（＆人）も同じような
ことやってる可能性があるから、展開する。
これがソースレビューってもんだと思うけど。
>また、プログラマの能力把握の為の切り抜きインスペクション（カコイイ言い方だ
>な、頂きます）てのも一理あるが、コーディングを始めた段階では手遅れっぽい。
手遅れかどうかなら、手遅れではないのでは？
先にやれという意見も、それはそれで理想的だけど、業務（開発）と
関係ないコーディングを前もってさせて力量を把握というのは
現実的じゃないような気が。
それこそ、それが今回の業務（開発）とマッチしてるか、その内容が
ベンチマークに利用できるかは怪しいと思う。
まぁ、開発計画の段階で、過去の要因のスキルをフィードバックできる
のならば、適材適所を考えるのは基本だけど。
PMBOKでいう所の要因手配と過去の情報ってとこ。
少なくても、完璧じゃないから後工程に回すって考え方は、問題の後回し
だと思うなぁ〜
>>475
>・コーディング規則にあっているか。
>・必要な機能は実装されているか。
>・エラー処理はちゃんとやってるか。
この程度だったらレビューなんぞ開かんで
そいつがサーバーにソース上げたときにこっちでパパっとみちゃうけどね。
おーガンバッとるね○○君。って感じでちょいちょいっと
なってなけりゃ、即注意（ただしやんわりと）。
おーい○○君。ここなっとらんけどどうよ？って感じでちょいちょいっと。
って普通のコミュニケーションじゃねぇかよ！
自分の部下のソースぐらいその日その日で確認しろよ！
>・コーディング規則にあっているか。
>・必要な機能は実装されているか。
>・エラー処理はちゃんとやってるか。
この程度だったらレビューなんぞ開かんで
そいつがサーバーにソース上げたときにこっちでパパっとみちゃうけどね。
おーガンバッとるね○○君。って感じでちょいちょいっと
なってなけりゃ、即注意（ただしやんわりと）。
おーい○○君。ここなっとらんけどどうよ？って感じでちょいちょいっと。
って普通のコミュニケーションじゃねぇかよ！
自分の部下のソースぐらいその日その日で確認しろよ！
>自分の部下のソースぐらいその日その日で確認
それ、ＰＭの仕事ではないな
それ、ＰＭの仕事ではないな
478 ：仕様書無しさん：05/01/11 00:50:36
>>470
>試験問題が、模擬試験と違うから、受験やめる
こんなのことするヤツいないよ。たとえが悪すぎる。
分かりやすく言えば、客の要求は１００人月、営業が受けた
と主張する作業範囲と金額は５０人月分。で、おれが登場して客と
話し合うにつれてやっぱ１００人月じゃん。１００人月を５０人月
分の金額でやれだぞ。
契約後付の仕事にありがちだけど、こう開きが大きいとな。
営業が強い会社だからこのままやらされんだぜ。
降りる宣言したくなるよ、ご同輩たちさよッ。
>試験問題が、模擬試験と違うから、受験やめる
こんなのことするヤツいないよ。たとえが悪すぎる。
分かりやすく言えば、客の要求は１００人月、営業が受けた
と主張する作業範囲と金額は５０人月分。で、おれが登場して客と
話し合うにつれてやっぱ１００人月じゃん。１００人月を５０人月
分の金額でやれだぞ。
契約後付の仕事にありがちだけど、こう開きが大きいとな。
営業が強い会社だからこのままやらされんだぜ。
降りる宣言したくなるよ、ご同輩たちさよッ。
>478
>１００人月を５０人月分の金額でやれ
となるのがおかしいだろ
a.受けたのは５０人月分だからそれに見合う分をやるように進める
b.どうしても１００人月分必要なら契約変更
ってのがＰＭの仕事だろ？
>１００人月を５０人月分の金額でやれ
となるのがおかしいだろ
a.受けたのは５０人月分だからそれに見合う分をやるように進める
b.どうしても１００人月分必要なら契約変更
ってのがＰＭの仕事だろ？
480 ：仕様書無しさん：05/01/11 01:13:18
>>479
そりゃ〜、営業の仕事だぞ。
その営業が、今のまま（５０人月分）で１００人月やれ、っていうから、
ジ・エンドよ。
オーライ、オーライ。やめりゃーいいんだ。議論の相手じゃいんよ。
うちの営業たちは。
就職活動に頭使うわ。
付き合ってくれて、サンクス。
そりゃ〜、営業の仕事だぞ。
その営業が、今のまま（５０人月分）で１００人月やれ、っていうから、
ジ・エンドよ。
オーライ、オーライ。やめりゃーいいんだ。議論の相手じゃいんよ。
うちの営業たちは。
就職活動に頭使うわ。
付き合ってくれて、サンクス。
>480
>そりゃ〜、営業の仕事
へ〜、そこはそんな事までも営業がやるんだ．．．
どうりでいわゆる「デスマ」になるわけだw
>そりゃ〜、営業の仕事
へ〜、そこはそんな事までも営業がやるんだ．．．
どうりでいわゆる「デスマ」になるわけだw
482 ：仕様書無しさん：05/01/11 01:35:10
>>478
悪いが、その程度なら良くある話だよ。工数が倍くらいなら。
それにそれが引き受ける前に明確になったなら、かなりハッピーだ。
仮に辞めないなら、「それでは実現できないから、こういう要件・仕様に
してください。これならできるし、業務もそれなりに回る筈です」と対案するしか無いね。
まずは現場同士で。次に相手の上司と、こちらの営業と一緒に。
悪いが、その程度なら良くある話だよ。工数が倍くらいなら。
それにそれが引き受ける前に明確になったなら、かなりハッピーだ。
仮に辞めないなら、「それでは実現できないから、こういう要件・仕様に
してください。これならできるし、業務もそれなりに回る筈です」と対案するしか無いね。
まずは現場同士で。次に相手の上司と、こちらの営業と一緒に。
>>475
>・コーディング規則にあっているか。
>・必要な機能は実装されているか。
>・エラー処理はちゃんとやってるか。
っていうのを保障するのが目的って事を知りたかったわけ。
そういう意味での保障ですよ。
で、必要な機能が実装されているか、エラー処理はちゃんとやってるかという判定を、
コードレビューという形をとると、どの精度まで行えたのかって説明できないと思うの。
頭の中の話だから。
機能を把握しているなら、きちんと文書として提示してあげれば、このコードは、
こういう動作（機能と例外処理）が保障されてますとはっきり言えると思う。
だから、単体テストだけでいいんじゃないと思うわけ。
あとコーディング規約は、フィルタ通せばいいんじゃない。
＞手遅れかどうかなら、手遅れではないのでは？
えーとこれはね、仕事をふっちゃた後に、能力を把握しても手遅れって事なの。
ずば抜けてダメダメでない限り、チェンジとか言えないじゃん。
もうコーディングが済んでるんだもん。
能力の把握・判定は、納品完了後ぐらいでいいんじゃないってくらいの意味ね。
>・コーディング規則にあっているか。
>・必要な機能は実装されているか。
>・エラー処理はちゃんとやってるか。
っていうのを保障するのが目的って事を知りたかったわけ。
そういう意味での保障ですよ。
で、必要な機能が実装されているか、エラー処理はちゃんとやってるかという判定を、
コードレビューという形をとると、どの精度まで行えたのかって説明できないと思うの。
頭の中の話だから。
機能を把握しているなら、きちんと文書として提示してあげれば、このコードは、
こういう動作（機能と例外処理）が保障されてますとはっきり言えると思う。
だから、単体テストだけでいいんじゃないと思うわけ。
あとコーディング規約は、フィルタ通せばいいんじゃない。
＞手遅れかどうかなら、手遅れではないのでは？
えーとこれはね、仕事をふっちゃた後に、能力を把握しても手遅れって事なの。
ずば抜けてダメダメでない限り、チェンジとか言えないじゃん。
もうコーディングが済んでるんだもん。
能力の把握・判定は、納品完了後ぐらいでいいんじゃないってくらいの意味ね。
どうでもいいが
ほ‐しょう【保証】
[名](スル)
間違いがない、大丈夫であると認め、責任をもつこと。
「品質を―する」「彼の人柄については―する」
[大辞泉]
ほ‐しょう【保証】
[名](スル)
間違いがない、大丈夫であると認め、責任をもつこと。
「品質を―する」「彼の人柄については―する」
[大辞泉]
485 ：仕様書無しさん：05/01/11 02:03:28
>>483
>っていうのを保障するのが目的って事を知りたかったわけ。
>そういう意味での保障ですよ。
それは、テストでその項目が保証できるのかと同じだと思うんだけど。
結局は水掛け論になっちゃうと思うんだけど如何？
例えば、
レビューアーの能力がダメならコーディングレビューの意味がない
→ テスト項目作成者の能力がダメならテストの意味がない
→ テスト実施者の能力がダメならテストの意味がない
テストやレビューの方式は、結局は方式論。
別のスレ立てて議論（ごっこ？）してみますか？
>機能を把握しているなら、きちんと文書として提示してあげれば、このコードは、
>こういう動作（機能と例外処理）が保障されてますとはっきり言えると思う。
>だから、単体テストだけでいいんじゃないと思うわけ。
色々な人が書いてると思うけど、詳細レベルの仕様書が個々の例外
ケースまで明記されていて（例えばメモリ確保失敗時の処理、
極論だとprintfでエラーが発生した時の処理）、
テストが全ケースを網羅できればその話は通用する。
しかし、実際はそこまで設計書が細かく書かれてることは
ないのではと思います。
（私の経験上、スパコンOSのドライバならそのレベルで
書かれてるの見たことあるけど）
でも、そのようなケースだと、サンプルチェックだけではなく
全ソースのソースレビューなんかもやりましたけど・・・
>っていうのを保障するのが目的って事を知りたかったわけ。
>そういう意味での保障ですよ。
それは、テストでその項目が保証できるのかと同じだと思うんだけど。
結局は水掛け論になっちゃうと思うんだけど如何？
例えば、
レビューアーの能力がダメならコーディングレビューの意味がない
→ テスト項目作成者の能力がダメならテストの意味がない
→ テスト実施者の能力がダメならテストの意味がない
テストやレビューの方式は、結局は方式論。
別のスレ立てて議論（ごっこ？）してみますか？
>機能を把握しているなら、きちんと文書として提示してあげれば、このコードは、
>こういう動作（機能と例外処理）が保障されてますとはっきり言えると思う。
>だから、単体テストだけでいいんじゃないと思うわけ。
色々な人が書いてると思うけど、詳細レベルの仕様書が個々の例外
ケースまで明記されていて（例えばメモリ確保失敗時の処理、
極論だとprintfでエラーが発生した時の処理）、
テストが全ケースを網羅できればその話は通用する。
しかし、実際はそこまで設計書が細かく書かれてることは
ないのではと思います。
（私の経験上、スパコンOSのドライバならそのレベルで
書かれてるの見たことあるけど）
でも、そのようなケースだと、サンプルチェックだけではなく
全ソースのソースレビューなんかもやりましたけど・・・
486 ：485：05/01/11 02:04:37
（続き）
>えーとこれはね、仕事をふっちゃた後に、能力を把握しても手遅れって事なの。
>ずば抜けてダメダメでない限り、チェンジとか言えないじゃん。
>もうコーディングが済んでるんだもん。
全コーディングが終わるまで、コーディングレビューをやらなければね。
でも、サンプルチェックなら、１モージュールができた時点でやればいいので、
コーディングの初期段階でチェックアウトできるけど。
設計書のレビューも全部終わるまで見ないわけではないでしょ？
それと同じです。
>えーとこれはね、仕事をふっちゃた後に、能力を把握しても手遅れって事なの。
>ずば抜けてダメダメでない限り、チェンジとか言えないじゃん。
>もうコーディングが済んでるんだもん。
全コーディングが終わるまで、コーディングレビューをやらなければね。
でも、サンプルチェックなら、１モージュールができた時点でやればいいので、
コーディングの初期段階でチェックアウトできるけど。
設計書のレビューも全部終わるまで見ないわけではないでしょ？
それと同じです。
マ板なのに全角が当たり前のスレはここですか？
>>488
そんなことに一々こだわんなや。ちっさい人間やのう。
そんなことに一々こだわんなや。ちっさい人間やのう。
490 ：仕様書無しさん：05/01/11 19:54:16
低スキル者のリスク軽減するなら早い方が良いと思う。
492 ：仕様書無しさん：05/01/11 21:44:53
コードを見るのはコードレビューだよ。
わざわざ製造と単体テスト分離する意味は無いし。
タイミングは単体テスト終了時で良いはず。
わざわざ製造と単体テスト分離する意味は無いし。
タイミングは単体テスト終了時で良いはず。
494 ：仕様書無しさん：05/01/11 21:57:45
495 ：仕様書無しさん：05/01/11 21:57:54
>>494
スコープ管理はPMの仕事ですが？
スコープ管理はPMの仕事ですが？
497 ：仕様書無しさん：05/01/11 22:20:23
レビューが不要と思う人はもう少し質問の仕方を変えた方が良いんじゃない。
話のズレは前提条件とか、作業や言葉の定義、目的意思がズレている事が大半なんだから。
例えば、
非オブジェクト指向言語での開発時は設計書で構造定義（関数の列挙）を記述する事は殆ど無い為、
レビューで構造確認する事は品質予想判断で非常に重要な訳です。
それに対しオブジェクト指向言語ではUML（クラス図）とUMLツール、そして統合開発環境の発展により、
構造定義しないと逆に開発（オブジェクト指向に成らない）が出来ない為、
構造定義をする事が当たり前になり、レビュー意義が薄くなっている側面がある。
と、まあ〜この様な話す前提認識の違いを原因として意見が食い違っているかもしれない。
そういう事を認識するスレで行きましょうよ。
管理について話てんだからさ。技法と結果の方程式で御話する様な事じゃ無いでしょ。
話のズレは前提条件とか、作業や言葉の定義、目的意思がズレている事が大半なんだから。
例えば、
非オブジェクト指向言語での開発時は設計書で構造定義（関数の列挙）を記述する事は殆ど無い為、
レビューで構造確認する事は品質予想判断で非常に重要な訳です。
それに対しオブジェクト指向言語ではUML（クラス図）とUMLツール、そして統合開発環境の発展により、
構造定義しないと逆に開発（オブジェクト指向に成らない）が出来ない為、
構造定義をする事が当たり前になり、レビュー意義が薄くなっている側面がある。
と、まあ〜この様な話す前提認識の違いを原因として意見が食い違っているかもしれない。
そういう事を認識するスレで行きましょうよ。
管理について話てんだからさ。技法と結果の方程式で御話する様な事じゃ無いでしょ。
前提満たせない奴大勢居るけどね。
突然だけどプログラム設計書書いた人間と
プログラム組む人間が別って辞めねぇ？
プログラム設計書書いた人間の
抜けとか全部こっちで吸収しなくちゃならないじゃん。
しかも、完成したあとで改めてみるとはじめの設計書の原型留めてないのが大半だし。
どう考えても書いた人間が責任を放棄してしまうのはずるい。
プログラム組む人間が別って辞めねぇ？
プログラム設計書書いた人間の
抜けとか全部こっちで吸収しなくちゃならないじゃん。
しかも、完成したあとで改めてみるとはじめの設計書の原型留めてないのが大半だし。
どう考えても書いた人間が責任を放棄してしまうのはずるい。
プログラム設計書書くのが馬鹿だろ。
501 ：仕様書無しさん：05/01/11 22:47:28
>>499
PGさんかな？ちょっと職場環境や開発道具によって話が異なるけど、
業務系を前提に話をするとですね
確かにプログラム設計書と実装者が別なのはオープン系では不適切。
昔は、データ加工するにも大変だった。それが今じゃSQL文でポンと終わる。
つまりプログラム設計行為と実装行為の目的が被っている訳で、相当近い距離にある。
こう記述すれば「だったら、工程の見直しが必要なんじゃね〜の？」と普通は思うんだけど。
ただ、話に在るように人間が別だから、その様な問題意識が働かない。
また、流石のベンダーも実装やプログラム設計の２艘跳びで基本設計担当を
させる訳に行かないから、設計鍛錬、実装知識の両兎狙いで
プログラム設計は手放さないでしょね。
つまり業界の構造問題が潜んでいるから、その問題は解決し難い。
崩れるならば、開発最適を意図した所からでは無いと思われ。
PGさんかな？ちょっと職場環境や開発道具によって話が異なるけど、
業務系を前提に話をするとですね
確かにプログラム設計書と実装者が別なのはオープン系では不適切。
昔は、データ加工するにも大変だった。それが今じゃSQL文でポンと終わる。
つまりプログラム設計行為と実装行為の目的が被っている訳で、相当近い距離にある。
こう記述すれば「だったら、工程の見直しが必要なんじゃね〜の？」と普通は思うんだけど。
ただ、話に在るように人間が別だから、その様な問題意識が働かない。
また、流石のベンダーも実装やプログラム設計の２艘跳びで基本設計担当を
させる訳に行かないから、設計鍛錬、実装知識の両兎狙いで
プログラム設計は手放さないでしょね。
つまり業界の構造問題が潜んでいるから、その問題は解決し難い。
崩れるならば、開発最適を意図した所からでは無いと思われ。
503 ：仕様書無しさん：05/01/11 23:32:27
>>492
>阿呆な奴はまだコンパイルも通っていないもんをレビューしたがる。
コンパイル通ってからやればいいのでは？
もしかして、リンケージとコンパイルをごっちゃにしてない？
>>493
変なソースで単体テストするのって無駄だと思わない？
>>496
スコープ管理は立派なPMの仕事です。
PMBOKだとね。
実際のところも、ＰＭがスコープ管理しなきゃ誰がするの？
って思うけど。
>阿呆な奴はまだコンパイルも通っていないもんをレビューしたがる。
コンパイル通ってからやればいいのでは？
もしかして、リンケージとコンパイルをごっちゃにしてない？
>>493
変なソースで単体テストするのって無駄だと思わない？
>>496
スコープ管理は立派なPMの仕事です。
PMBOKだとね。
実際のところも、ＰＭがスコープ管理しなきゃ誰がするの？
って思うけど。
>495
世の中、単体テスト終了時にコードレビューなんて言ってるPGが結構いるのね。
それって、単体テスト仕様書作ってるんだよね？
レビューで問題発覚したら、またやり直すのかなあ？
プログラム仕様書って2度手間だよね。
ソース逆生成してそのまま納品して許されるならいいけど。
世の中、単体テスト終了時にコードレビューなんて言ってるPGが結構いるのね。
それって、単体テスト仕様書作ってるんだよね？
レビューで問題発覚したら、またやり直すのかなあ？
プログラム仕様書って2度手間だよね。
ソース逆生成してそのまま納品して許されるならいいけど。
コンパイル前にソースを見直すというのは、PSP等でも推奨されている品質向上策だが、
フォーマルなレビューまでやるのかい。
っていうかプロジェクトマネジメントと全然関係ないだろ。
ソフトウェア開発手法とプロジェクト管理手法をごっちゃにしてる。
フォーマルなレビューまでやるのかい。
っていうかプロジェクトマネジメントと全然関係ないだろ。
ソフトウェア開発手法とプロジェクト管理手法をごっちゃにしてる。
506 ：仕様書無しさん：05/01/12 01:28:14
いやプロジェクトマネジメントは、品質、コスト、リリースの三つの側面があり、全てが重要だ。
508 ：仕様書無しさん：05/01/12 02:01:42
509 ：仕様書無しさん：05/01/12 08:52:31
>>499
詳細設計とプログラミングを同一の人が行うなら、正直詳細設計書はいらないと思う。
大まかなメモ書いて、考えまとめて自分で作ってくれと。
最終的にソースから詳細設計書に類するものをジェネレートしてくれるJAVADOCなりHotDocなりで作ればいい。
そうじゃなく、詳細設計書を作るなら、作ったものは他人が見て理解できるものをきちんと作るべき。
それと関連する文書を見れば、誰が見てもコードが完成するもの。
>>504
もう、その話は平行線になるからクローズでしょ。そもそもPMの領域じゃないし。
実施するしないはPMの判断としても方法論はミクロすぎ。
詳細設計とプログラミングを同一の人が行うなら、正直詳細設計書はいらないと思う。
大まかなメモ書いて、考えまとめて自分で作ってくれと。
最終的にソースから詳細設計書に類するものをジェネレートしてくれるJAVADOCなりHotDocなりで作ればいい。
そうじゃなく、詳細設計書を作るなら、作ったものは他人が見て理解できるものをきちんと作るべき。
それと関連する文書を見れば、誰が見てもコードが完成するもの。
>>504
もう、その話は平行線になるからクローズでしょ。そもそもPMの領域じゃないし。
実施するしないはPMの判断としても方法論はミクロすぎ。
「プロジェクトは千差万別」には同意だけど
PMだからこそ結論に置いてしまうべきではないね。
PMだからこそ結論に置いてしまうべきではないね。
512 ：仕様書無しさん：05/01/12 11:02:36
作ることしか考えてない人もいるようだけど、
保守用の詳細設計書は、まともな仕事なら必須でしょ。
客にとっては、使い続けてなんぼだから、保守を考えないシステムは、
手抜き突貫工事と同じだよ。
保守用の詳細設計書は、まともな仕事なら必須でしょ。
客にとっては、使い続けてなんぼだから、保守を考えないシステムは、
手抜き突貫工事と同じだよ。
保守用の詳細設計書よりも保守性の高いソースコードだろ。
どうせ詳細設計所なんて保守出来ないんだから。
どうせ詳細設計所なんて保守出来ないんだから。
514 ：仕様書無しさん：05/01/12 11:09:18
コンパイルの前でもソースレビューは有効だよ。
目的は、細かい記述ミスのレビューじゃなくて、
記述の流れ、例外処理の考慮範囲、コメント量の適正さ、標準化などなど。
特に新人君とか。逆に馴れてる人ばかりなら、減らしていい。
これをコンパイラー通過後に直すと、すごい作業量になって、
記述ミスも出てコンパイルエラーも出て、結局二度手間。
ただ、全量を早期ソースレビューするかは判断が必要。
各担当者とか各機能単位で、１〜３ソースやるだけで、
後々の品質や手戻りが格段に違うよ。
目的は、細かい記述ミスのレビューじゃなくて、
記述の流れ、例外処理の考慮範囲、コメント量の適正さ、標準化などなど。
特に新人君とか。逆に馴れてる人ばかりなら、減らしていい。
これをコンパイラー通過後に直すと、すごい作業量になって、
記述ミスも出てコンパイルエラーも出て、結局二度手間。
ただ、全量を早期ソースレビューするかは判断が必要。
各担当者とか各機能単位で、１〜３ソースやるだけで、
後々の品質や手戻りが格段に違うよ。
516 ：仕様書無しさん：05/01/12 11:12:04
>>513
両方にきまってんだろ。こんな奴がいるから皆、保守で苦労するんだよ。
仮に継続保守できないとしても、当初のドキュメントがまともなら、
後から追う事もできるが、最初からまともに作る気が無いんじゃ処置なし。
両方にきまってんだろ。こんな奴がいるから皆、保守で苦労するんだよ。
仮に継続保守できないとしても、当初のドキュメントがまともなら、
後から追う事もできるが、最初からまともに作る気が無いんじゃ処置なし。
517 ：仕様書無しさん：05/01/12 11:12:59
>>515
あんたも作る事しか考えてない、手抜き工事要員だね
あんたも作る事しか考えてない、手抜き工事要員だね
Eclipse使ってる奴にコンパイル前とか言うと馬鹿にされるぞ。
519 ：仕様書無しさん：05/01/12 11:14:45
>>518
そりゃ、ツールが内部的にどう動いてるかだけの話
そりゃ、ツールが内部的にどう動いてるかだけの話
詳細設計書にコーディングと同じ期間掛ける意義は薄い。
521 ：仕様書無しさん：05/01/12 11:18:23
ちゃんと設計してからコーディングしないから、
後から「考慮漏れ」で修正しまくりになるんだが．．．
反省しないPGが多いこと。
後から「考慮漏れ」で修正しまくりになるんだが．．．
反省しないPGが多いこと。
>>514
二度手間ねぇ。・・・それは、各担当者の技能が、
「コンパイルエラーを除去する工数が無視出来るほど少ない」か否かに依存しているのでは？
新人君にはその種の配慮が必要かも知れないけど、私の場合はﾍﾞﾃﾗﾝに面倒をみさせているぞ。
#「コンパイルも通らない落書きを読みたくない」という個人的な希望もｗ
二度手間ねぇ。・・・それは、各担当者の技能が、
「コンパイルエラーを除去する工数が無視出来るほど少ない」か否かに依存しているのでは？
新人君にはその種の配慮が必要かも知れないけど、私の場合はﾍﾞﾃﾗﾝに面倒をみさせているぞ。
#「コンパイルも通らない落書きを読みたくない」という個人的な希望もｗ
>>519
まーつまりコードレビューのタイミングなんて千差万別って事だよ。
コンパイルに10分かかるならコンパイル前だろうし、
テスティングフレームワークでテストファーストしてたら単体テスト後だろうし。
ツールは使いこなせば開発工程を変化させる力がある。
まーつまりコードレビューのタイミングなんて千差万別って事だよ。
コンパイルに10分かかるならコンパイル前だろうし、
テスティングフレームワークでテストファーストしてたら単体テスト後だろうし。
ツールは使いこなせば開発工程を変化させる力がある。
524 ：仕様書無しさん：05/01/12 11:26:30
まーでも、話が互いに堂々巡りしてるみたいだけど、
結局は「何を主眼にレビューやインスペクションするか」に尽きるのでは。
１．「コンパイルエラーを事前に発見する」は、ツールが便利な現代では必要性薄い。
２．標準化・拡張性の事前チェックは重要だが、ベテランばかりなら必要性薄い
３．ツールで簡単に発生できないケース(大量とか基盤障害系)は、重点的にソースレビューが必要
「コンパイルも通って動く」のと「標準化・性能・拡張性を含めて品質が高い」のは違うからね。
結局は「何を主眼にレビューやインスペクションするか」に尽きるのでは。
１．「コンパイルエラーを事前に発見する」は、ツールが便利な現代では必要性薄い。
２．標準化・拡張性の事前チェックは重要だが、ベテランばかりなら必要性薄い
３．ツールで簡単に発生できないケース(大量とか基盤障害系)は、重点的にソースレビューが必要
「コンパイルも通って動く」のと「標準化・性能・拡張性を含めて品質が高い」のは違うからね。
526 ：仕様書無しさん：05/01/12 11:52:10
「できました。テストも通りました」といってプロジェクトを去り、
・システムテストで大量データでは性能が出ない
・例外処理は運用に即さない
・設計書はメンテしてない
こういうのを撲滅するのがＰＭの地道な仕事。
でもＰＧは楽をして「一丁あがり〜」で去りたがる。
だからＰＭはＰＧに嫌われる面があるのも仕方ない。
使えるシステムを作るのがＰＭの目標だから。
・システムテストで大量データでは性能が出ない
・例外処理は運用に即さない
・設計書はメンテしてない
こういうのを撲滅するのがＰＭの地道な仕事。
でもＰＧは楽をして「一丁あがり〜」で去りたがる。
だからＰＭはＰＧに嫌われる面があるのも仕方ない。
使えるシステムを作るのがＰＭの目標だから。
527 ：仕様書無しさん：05/01/12 11:53:01
>>525
あんたの周囲がひどいからって、世間全部を同じと思ってはいけないよ。
あんたの周囲がひどいからって、世間全部を同じと思ってはいけないよ。
>>527
フーン。経験は必然性を教えないってやつか。
「ひどい」だなんて思ってはいないよ。「それが普通なのだ」と思っているだけだよ。
貴方の周囲は、貴方の言う「ひどい」では無いのだろうね。
#個人的には単なる「貴方の脳内現実に過ぎない」と思うけどね。
よかったら「どの様にしたらそれを実現可能か」を披露してみて欲しいが
フーン。経験は必然性を教えないってやつか。
「ひどい」だなんて思ってはいないよ。「それが普通なのだ」と思っているだけだよ。
貴方の周囲は、貴方の言う「ひどい」では無いのだろうね。
#個人的には単なる「貴方の脳内現実に過ぎない」と思うけどね。
よかったら「どの様にしたらそれを実現可能か」を披露してみて欲しいが
業務時間中に２ちゃんに書き込むＰＭ達のスレか・・・
>>530
時間で管理される仕事では無いからね
時間で管理される仕事では無いからね
集中力が求められる仕事でもなさそうだな
533 ：デフォルトの名無しさん：05/01/13 00:42:31
新人PGです。
明日コードレビューなのですが、
コードレビューではいったい何が審査されるのでしょうか？
設計ならUMLのクラス図やシーケンス図を使うと思うのですが、
ソースになると規約ぐらいしか見るとこないような気がします。
>>522
エラーコードをレビューすることとかってあるんですか･･･？
ﾏｼﾞｯすか？それって意味がないような･･･
明日コードレビューなのですが、
コードレビューではいったい何が審査されるのでしょうか？
設計ならUMLのクラス図やシーケンス図を使うと思うのですが、
ソースになると規約ぐらいしか見るとこないような気がします。
>>522
エラーコードをレビューすることとかってあるんですか･･･？
ﾏｼﾞｯすか？それって意味がないような･･･
>>533
随分粗末な釣りだな。
随分粗末な釣りだな。
535 ：仕様書無しさん：05/01/13 06:48:59
馬鹿ばっかだな。
昔はコンパイルに数十分〜数時間かかり、端末を共有していた。そう言う時代はソースレビューする事は当り前だった。
しかし、時代の移り代わりでここの判断は難しい。だから無条件に、ソースレビューが必要と云うのは現状認識が出来ていない。
ただ、この昔の人達はある法則をしっている。コンパイルのリトライ回数が多く懸かったモジュールは、やっつけで作成されている為、テスト工程回す事は非効率的である。
実際、今でも各基本機能が動く所まで即時デバッグしてから、テスト項目の消化に取り掛かるだろ。
ツールに依存している所で、誇っても仕方が無い。コンパイルのリトライ回数が少ないと言うのは、ソース全体が見渡せていると云う事であり基本的な設計技術が身についていると云う事だ。
基本的な設計技術が身についていない人は、自分の判断で記述したソースに対する検証が出来ないつう事だ。
その行為の意義、その裏に存在する非意図的な意義を考えねばならん。それが管理者だ。
昔はコンパイルに数十分〜数時間かかり、端末を共有していた。そう言う時代はソースレビューする事は当り前だった。
しかし、時代の移り代わりでここの判断は難しい。だから無条件に、ソースレビューが必要と云うのは現状認識が出来ていない。
ただ、この昔の人達はある法則をしっている。コンパイルのリトライ回数が多く懸かったモジュールは、やっつけで作成されている為、テスト工程回す事は非効率的である。
実際、今でも各基本機能が動く所まで即時デバッグしてから、テスト項目の消化に取り掛かるだろ。
ツールに依存している所で、誇っても仕方が無い。コンパイルのリトライ回数が少ないと言うのは、ソース全体が見渡せていると云う事であり基本的な設計技術が身についていると云う事だ。
基本的な設計技術が身についていない人は、自分の判断で記述したソースに対する検証が出来ないつう事だ。
その行為の意義、その裏に存在する非意図的な意義を考えねばならん。それが管理者だ。
536 ：仕様書無しさん：05/01/13 07:35:41
またぬるぽ？
538 ：仕様書無しさん：05/01/13 22:49:35
最近はコンパイル気にせず掛けまくる。
ばーとエラーが出たら２，３個つぶしてコンパイル、疲れてるときは
1個つぶしてコンパイル。ものによって、１個つぶすとガクンと減るしね。
あと、テスト時にgoodなツールが無い場合は、コメントとか、手作りの
スナップショットとかあちこち入れて、消して、入れて、消して、入れて・・・・
で、コンパイル。
めんどーくさいＰＧのとき、２００回コンパイルやったら、ＰＭにけちょん、ケチョン
言われた。でも、開発マシン余裕あるしオレ的には問題なし。
かなり落とし穴的なバグつぶせたからいいんでないの、って感じよ。
ばーとエラーが出たら２，３個つぶしてコンパイル、疲れてるときは
1個つぶしてコンパイル。ものによって、１個つぶすとガクンと減るしね。
あと、テスト時にgoodなツールが無い場合は、コメントとか、手作りの
スナップショットとかあちこち入れて、消して、入れて、消して、入れて・・・・
で、コンパイル。
めんどーくさいＰＧのとき、２００回コンパイルやったら、ＰＭにけちょん、ケチョン
言われた。でも、開発マシン余裕あるしオレ的には問題なし。
かなり落とし穴的なバグつぶせたからいいんでないの、って感じよ。
539 ：仕様書無しさん：05/01/13 23:12:49
>>537
>コードレビューの必要性に時代の移り変わりは関係無い
あなたのコードレビューの目的は何ですか？
>例えばXPは全ソースコードのレビューがプラクティスに組み込まれているし。
初耳。ペアプログラミングの効果としての話では無く？
>コードレビューの必要性に時代の移り変わりは関係無い
あなたのコードレビューの目的は何ですか？
>例えばXPは全ソースコードのレビューがプラクティスに組み込まれているし。
初耳。ペアプログラミングの効果としての話では無く？
>>539
＞あなたのコードレビューの目的は何ですか？
コードの品質を高め、品質の低いコードに関するリスクを軽減する事です。
＞>例えばXPは全ソースコードのレビューがプラクティスに組み込まれているし。
＞初耳。ペアプログラミングの効果としての話では無く？
そうだよ。効果っていうか手段そのものだけどね。初耳じゃないじゃん。
＞あなたのコードレビューの目的は何ですか？
コードの品質を高め、品質の低いコードに関するリスクを軽減する事です。
＞>例えばXPは全ソースコードのレビューがプラクティスに組み込まれているし。
＞初耳。ペアプログラミングの効果としての話では無く？
そうだよ。効果っていうか手段そのものだけどね。初耳じゃないじゃん。
541 ：仕様書無しさん：05/01/14 00:08:39
しぇんしぇい！
XPのプラクティスとして全ソースコードのレビューを定義している
その間抜けな本やサイトを教えて下さい。
XPのプラクティスとして全ソースコードのレビューを定義している
その間抜けな本やサイトを教えて下さい。
542 ：仕様書無しさん：05/01/14 00:11:42
コードレビューを否定してる僕ちゃん達って
恥ずかしがり屋さんなのかな？
それとも、自分の作るウンコなプログラムが余程自信がないのかなｗ
恥ずかしがり屋さんなのかな？
それとも、自分の作るウンコなプログラムが余程自信がないのかなｗ
>>541
間抜けな君は一度くらい本やサイトを眺めて下さい。
間抜けな君は一度くらい本やサイトを眺めて下さい。
ちゃんとしたレビュアーがいるならいいが。Ｆの仕事だとこれが．．．．．以下略。
プロジェクトメンバーの最高スキル者が大した事無いなら、
どっちみち大した仕事出来ないんだから諦めて泥沼のように頑張れ。
どっちみち大した仕事出来ないんだから諦めて泥沼のように頑張れ。
546 ：仕様書無しさん：05/01/14 00:47:20
コードレビューは、コードの品質（メンテナンス性）を確保するのが目的。（※）
→バグの回収や保守、派生開発を行う人に対して
テストは、実装した機能や動作を保障するのが目的。
→顧客やプログラムを利用する人に対して
だと思うんだが、どうでしょう。
方向性（目的）が違うと思う。
だから、テストがんばるから、コードレビューしないってのは的外れかなあ。
ただ、コードレビューだけがコードの品質を確保する唯一の方法ではないと思うし
（コーディング規約の提示だけでも、メンバーによれば十分の時もある）、プロジ
ェクトによっては、メンテナンス性をあまり考慮する必要がない場合もあると思う
ので、コードレビューを導入しないって選択はありだと思う。
（※）
まあ、コードレビューでも、実装した機能や動作を保障ができないわけではな
いが、それは単体テストで確認したほうが確実で早いと思う。
→バグの回収や保守、派生開発を行う人に対して
テストは、実装した機能や動作を保障するのが目的。
→顧客やプログラムを利用する人に対して
だと思うんだが、どうでしょう。
方向性（目的）が違うと思う。
だから、テストがんばるから、コードレビューしないってのは的外れかなあ。
ただ、コードレビューだけがコードの品質を確保する唯一の方法ではないと思うし
（コーディング規約の提示だけでも、メンバーによれば十分の時もある）、プロジ
ェクトによっては、メンテナンス性をあまり考慮する必要がない場合もあると思う
ので、コードレビューを導入しないって選択はありだと思う。
（※）
まあ、コードレビューでも、実装した機能や動作を保障ができないわけではな
いが、それは単体テストで確認したほうが確実で早いと思う。
レビューの過程で「自分で」ミスに気づいたり
仕様への誤解が解けたり、逆に理解が深まったり
そういったことはないのかね？
仕様への誤解が解けたり、逆に理解が深まったり
そういったことはないのかね？
レビューの目的は個人攻撃では無い
>>550
承知してるけど、実態と理想とは大きく違うもんだからね
承知してるけど、実態と理想とは大きく違うもんだからね
554 ：仕様書無しさん：05/01/14 23:42:35
XPの話は、537が個人解釈をXPの定義として語っているのは問題ですね
レビューの話は、繰返処理の脱出条件が前か後ろかでテストケースが変動しますよね
その様な構造に即したテストケースの必要性を考える事もありでは。
レビューの話は、繰返処理の脱出条件が前か後ろかでテストケースが変動しますよね
その様な構造に即したテストケースの必要性を考える事もありでは。
>>554
どちらかと言えばXP作った人の解釈かも。
どちらかと言えばXP作った人の解釈かも。
レビューは「みんなが承認した」と後で開きなおるためのものですよ。
…書いてて悲しくなってきた。
…書いてて悲しくなってきた。
557 ：仕様書無しさん：05/01/15 13:25:28
>>555
であれば、その引用元を提示してあればいいんじゃない？
発言元を明確にしないのは管理者として最低だ。
よく「それでは皆が納得しない」「会社が了承せんよ」と云う奴いるだろ、これは無責任の現れ。
管理責務を考えているならば、
「それではｘｘｘさんが納得しない」（エスカレーション先の明確化）
「ｘｘｘの規則に一致しない」（問題箇所の明確化）
「周囲から反論があった場合、私にはその意見では抑える事が出来ない」（予測課題の明確化）
を行う必要がる。
それと君達は同じ事をしているのは？
仮にXPにて、全ソースのレビューをしろと明言されていなくても、そう個人が受止める事は間違いじゃ無い。
しかし、それがXPだからと云って自己の考えや責務を放棄する姿勢は問題があるんじゃないの？
ま、掲示板だからいいけどさ、そう言う管理者が現実に多くてね．．．
であれば、その引用元を提示してあればいいんじゃない？
発言元を明確にしないのは管理者として最低だ。
よく「それでは皆が納得しない」「会社が了承せんよ」と云う奴いるだろ、これは無責任の現れ。
管理責務を考えているならば、
「それではｘｘｘさんが納得しない」（エスカレーション先の明確化）
「ｘｘｘの規則に一致しない」（問題箇所の明確化）
「周囲から反論があった場合、私にはその意見では抑える事が出来ない」（予測課題の明確化）
を行う必要がる。
それと君達は同じ事をしているのは？
仮にXPにて、全ソースのレビューをしろと明言されていなくても、そう個人が受止める事は間違いじゃ無い。
しかし、それがXPだからと云って自己の考えや責務を放棄する姿勢は問題があるんじゃないの？
ま、掲示板だからいいけどさ、そう言う管理者が現実に多くてね．．．
558 ：仕様書無しさん：05/01/15 13:54:40
このスレでずっと続いてる会話
ただのPGの愚痴「レビューは不要」「ツールで十分」「俺はそうやってきた」
「ドキュメントはメンテしない」「どうせ他だって同じだろう」．．．
こんなの相手にしても仕方ないね :-P
まともなPGは自分のソースの説明も、人のソースのレビューやコメントもできるって
事を知らないで「管理者の陰謀だ」と思ってるだけみたい。
ただのPGの愚痴「レビューは不要」「ツールで十分」「俺はそうやってきた」
「ドキュメントはメンテしない」「どうせ他だって同じだろう」．．．
こんなの相手にしても仕方ないね :-P
まともなPGは自分のソースの説明も、人のソースのレビューやコメントもできるって
事を知らないで「管理者の陰謀だ」と思ってるだけみたい。
559 ：仕様書無しさん：05/01/15 13:59:43
>>558
逆も似たようなもん。
「コードレビューは必要」「その理由はよくわからない」
「コードレビューの必要性がわからない奴は馬鹿」
「でもそれを人に説明することはできないの」
やっぱりＰＭなんてアホなんだなｗ
逆も似たようなもん。
「コードレビューは必要」「その理由はよくわからない」
「コードレビューの必要性がわからない奴は馬鹿」
「でもそれを人に説明することはできないの」
やっぱりＰＭなんてアホなんだなｗ
560 ：仕様書無しさん：05/01/15 14:47:24
>>559
コーダー君は引っ込んでろってことだ
コーダー君は引っ込んでろってことだ
561 ：仕様書無しさん：05/01/15 14:55:52
563 ：仕様書無しさん：05/01/15 16:47:17
>>562
そうだぜ！
家につくまでが遠足だぜ！
遠足の帰り道。俺の幼馴染の菜穂ちゃんが「お腹痛い・・・」とかいいだして
くさむらでウンコしたのは俺と菜穂ちゃんだけの秘密だ。
まあ、いまでは結婚もして旦那もいるらしいがな！
そうだぜ！
家につくまでが遠足だぜ！
遠足の帰り道。俺の幼馴染の菜穂ちゃんが「お腹痛い・・・」とかいいだして
くさむらでウンコしたのは俺と菜穂ちゃんだけの秘密だ。
まあ、いまでは結婚もして旦那もいるらしいがな！
565 ：仕様書無しさん：05/01/15 19:11:22
566 ：仕様書無しさん：05/01/15 19:13:03
とあるサイトを見てみました。（＾◇＾）
プログラマーらしいホムペの仕上がり。
雑誌なども出版していてネット販売もしています。
素晴らしい人です。中で疑問がわいてきました。
IPだのアクセスポイントだのと言うわりには独自ドメイン取ればいいのにと思います。
ネットを利用している人って、商用や会社、団体以外ドメインって取らないの？
素朴な疑問ですので中傷はいけません。素晴らしいプログラマーに失礼ですから。
http://wanichan.way-nifty.com/blog/2004/02/ip.html
プログラマーらしいホムペの仕上がり。
雑誌なども出版していてネット販売もしています。
素晴らしい人です。中で疑問がわいてきました。
IPだのアクセスポイントだのと言うわりには独自ドメイン取ればいいのにと思います。
ネットを利用している人って、商用や会社、団体以外ドメインって取らないの？
素朴な疑問ですので中傷はいけません。素晴らしいプログラマーに失礼ですから。
http://wanichan.way-nifty.com/blog/2004/02/ip.html
567 ：仕様書無しさん：05/01/15 19:36:02
568 ：仕様書無しさん：05/01/15 19:39:52
話題とずれてすみません。質問。とあるサイトを見てみました。（＾◇＾）
プログラマーらしいホムペの仕上がり。
雑誌なども出版していてネット販売もしています。
素晴らしい人です。中で疑問がわいてきました。
IPだのアクセスポイントだのと言うわりには独自ドメイン取ればいいのにと思います。
ネットを利用している人って、商用や会社、団体以外ドメインって取らないの？
素朴な疑問ですので中傷はいけません。素晴らしいプログラマーに失礼ですから。
http://wanichan.way-nifty.com/blog/2004/02/ip.html
プロが発言！！自分の地域に自信を持ちましょうと言ってました。
素晴らしい。けど何で独自ドメイン取らないの？
プログラマーらしいホムペの仕上がり。
雑誌なども出版していてネット販売もしています。
素晴らしい人です。中で疑問がわいてきました。
IPだのアクセスポイントだのと言うわりには独自ドメイン取ればいいのにと思います。
ネットを利用している人って、商用や会社、団体以外ドメインって取らないの？
素朴な疑問ですので中傷はいけません。素晴らしいプログラマーに失礼ですから。
http://wanichan.way-nifty.com/blog/2004/02/ip.html
プロが発言！！自分の地域に自信を持ちましょうと言ってました。
素晴らしい。けど何で独自ドメイン取らないの？
569 ：仕様書無しさん：05/01/15 22:48:25
そうだね、コーダ君に解り易く云えばPG脳でPM概念を理解しようとする事が
根本的間違いだという事に早く気付いて欲しいね。
これからは、コーダ君無視って事で。
根本的間違いだという事に早く気付いて欲しいね。
これからは、コーダ君無視って事で。
>>569
PMだけで開発できると思ってるバカですか?、キミ
PMだけで開発できると思ってるバカですか?、キミ
571 ：仕様書無しさん：05/01/15 23:10:34
>> 570
確かにPMだけじゃ開発できないね。
569が言うとおり、PGとPMじゃ立場が違うから
「無能なPG」とか「PMは使えない」とか、お互いを
罵り合ってるようじゃ、話はずっと平行線なんだろうね。
でも、ここはPMのスレだから、例えPGでもPMの立場で話ができる人に
きてもらいたいね。
確かにPMだけじゃ開発できないね。
569が言うとおり、PGとPMじゃ立場が違うから
「無能なPG」とか「PMは使えない」とか、お互いを
罵り合ってるようじゃ、話はずっと平行線なんだろうね。
でも、ここはPMのスレだから、例えPGでもPMの立場で話ができる人に
きてもらいたいね。
>>557
君はXPについて学んだ事が無いんだよねｗ
それだけハッキリすれば引用元貼るのは何ら問題無いよ。
http://www.objectclub.jp/community/XP-jp/xp_relate/whatisxp-j#pair
例えば↑に「すべての製品コードが少なくとも1人の他のプログラマによってレビューされ」
とあるけど、こんなもんXPについて書かれた、ありとあるあらゆるサイト・書籍に
当たり前のように名言されている事だよ。Kent Beckの本にも書いてあるよ。
ちなみに俺は君の管理者じゃなくて、ここは無責任な掲示板だから、
「質問する時は自分である程度調べてから」というネットの質問マナーを優先しただけ。
プロジェクトメンバーは保護するよ。その為に高いお金貰ってるんだから。
今回は２行目に”ｗ”を書く事が目的だったので特別。
感謝しつつ自分を見直して下さい。
君はXPについて学んだ事が無いんだよねｗ
それだけハッキリすれば引用元貼るのは何ら問題無いよ。
http://www.objectclub.jp/community/XP-jp/xp_relate/whatisxp-j#pair
例えば↑に「すべての製品コードが少なくとも1人の他のプログラマによってレビューされ」
とあるけど、こんなもんXPについて書かれた、ありとあるあらゆるサイト・書籍に
当たり前のように名言されている事だよ。Kent Beckの本にも書いてあるよ。
ちなみに俺は君の管理者じゃなくて、ここは無責任な掲示板だから、
「質問する時は自分である程度調べてから」というネットの質問マナーを優先しただけ。
プロジェクトメンバーは保護するよ。その為に高いお金貰ってるんだから。
今回は２行目に”ｗ”を書く事が目的だったので特別。
感謝しつつ自分を見直して下さい。
PG経験無いPMは殆ど居ないからね。
PM、PG分かってるPM
PG分かってるPG
どっちの見識広いかは一目瞭然・・・
PM、PG分かってるPM
PG分かってるPG
どっちの見識広いかは一目瞭然・・・
574 ：仕様書無しさん：05/01/15 23:18:37
>>573
相応の実力があったらの話ねｗ
相応の実力があったらの話ねｗ
少なくともPMの仕事が見えてないPGは例外無く視野が狭い。
576 ：仕様書無しさん：05/01/15 23:25:55
>>575
上司がアホだからだなｗ
上司がアホだからだなｗ
PGに成り下がった人とその成れの果てが罵り合ってるｲﾝﾀｰﾈｯﾂはここでつか?
578 ：仕様書無しさん：05/01/16 00:11:29
>>561
リリース後に仕様変更（法律変更などで）がある様なシステム
をやっていた人がレビュー必要と言っていて、リリース後には
仕様変更がない（ゲームなどのパッケージ）をやっていた人
たちがレビューは不要と言っているだけじゃないかな？
そもそもプロジェクトの前提が違うから話がかみ合っていない気が。
あと、良く知っている同じ会社の仲間だけで作り上げるなら
メンバによってはレビューは不要とかも思ったりする場合も
あるが、外注に出すとき（オフショアだとなおさら）レビューは
不可欠だと個人的に思っている。
リリース後に仕様変更（法律変更などで）がある様なシステム
をやっていた人がレビュー必要と言っていて、リリース後には
仕様変更がない（ゲームなどのパッケージ）をやっていた人
たちがレビューは不要と言っているだけじゃないかな？
そもそもプロジェクトの前提が違うから話がかみ合っていない気が。
あと、良く知っている同じ会社の仲間だけで作り上げるなら
メンバによってはレビューは不要とかも思ったりする場合も
あるが、外注に出すとき（オフショアだとなおさら）レビューは
不可欠だと個人的に思っている。
579 ：仕様書無しさん：05/01/16 00:36:57
>>576
やだやだ。
自分の無能さを他人のせいにしたいのですね。
有能な人はどんな環境に居ても自力でなんとかするし、
本当にしょうもない所なら、とっとと出ていきます。
それすらもしないで自分の無能さを他人のせいにしてる人。
きっと精神的に大人になれないのですね。
いつまでもママンのおっぱいでも吸っててください。
やだやだ。
自分の無能さを他人のせいにしたいのですね。
有能な人はどんな環境に居ても自力でなんとかするし、
本当にしょうもない所なら、とっとと出ていきます。
それすらもしないで自分の無能さを他人のせいにしてる人。
きっと精神的に大人になれないのですね。
いつまでもママンのおっぱいでも吸っててください。
PMが野心家でなおかつヒステリックだとたまらないよなあ。
>>581
PGを人間的にも見下してるPMとかSEって多いからね
PGを人間的にも見下してるPMとかSEって多いからね
584 ：仕様書無しさん：05/01/16 00:56:50
>>581
ま、ここは2chだからね。互いに９割は便所の落書きてな前提で書かないと。
在日叩き、高卒叩き、COBOLer叩き、紺猿叩きと同様、
PM叩きやPG叩きを続けたい人も永遠にいるだけ。
諭しても酒飲みの発散と同じで繰り返しだし。
それでもこのスレ、この板では珍しくまともだと思うよ。
ま、ここは2chだからね。互いに９割は便所の落書きてな前提で書かないと。
在日叩き、高卒叩き、COBOLer叩き、紺猿叩きと同様、
PM叩きやPG叩きを続けたい人も永遠にいるだけ。
諭しても酒飲みの発散と同じで繰り返しだし。
それでもこのスレ、この板では珍しくまともだと思うよ。
585 ：仕様書無しさん：05/01/16 01:34:02
違うな、誰もＰＧを馬鹿にしていない。
偶々ＰＧという職種についている無能者がＰＭから的確な指摘を受けた結果、
自己防衛本能で、自分では無くＰＧ職種が攻撃された自動判断をしたのだ。
つまり、「お前ってアホだからあっちいけ！」と云われて
「日本人を馬鹿にしましたね！」とイチャモンを付けているだけだ。
上記が理解出来ない奴、投稿するな。
ＰＭにとってＰＧが気持ち良く働いてもらう環境を整備する事は重要課題だ。
偶々ＰＧという職種についている無能者がＰＭから的確な指摘を受けた結果、
自己防衛本能で、自分では無くＰＧ職種が攻撃された自動判断をしたのだ。
つまり、「お前ってアホだからあっちいけ！」と云われて
「日本人を馬鹿にしましたね！」とイチャモンを付けているだけだ。
上記が理解出来ない奴、投稿するな。
ＰＭにとってＰＧが気持ち良く働いてもらう環境を整備する事は重要課題だ。
>>585
で?、なんでキミが仕切ろうとするのかな?、ここはキミの職場でも無ければ、
キミのプロジェクトでも無いんだけどな。
>偶々ＰＧという職種についている無能者がＰＭから的確な指摘を受けた結果、
>自己防衛本能で、自分では無くＰＧ職種が攻撃された自動判断をしたのだ。
根拠は?( ´_ゝ｀)
そう思いこんでる時点で、キミに見下してる感情が欠片も無いと証明できる?
で?、なんでキミが仕切ろうとするのかな?、ここはキミの職場でも無ければ、
キミのプロジェクトでも無いんだけどな。
>偶々ＰＧという職種についている無能者がＰＭから的確な指摘を受けた結果、
>自己防衛本能で、自分では無くＰＧ職種が攻撃された自動判断をしたのだ。
根拠は?( ´_ゝ｀)
そう思いこんでる時点で、キミに見下してる感情が欠片も無いと証明できる?
587 ：仕様書無しさん：05/01/16 06:41:29
588 ：仕様書無しさん：05/01/16 10:41:36
実は最初っから非PMerの脳内議論だったりするｗ
>>588
中にはそういう奴も混じってるだろうな
中にはそういう奴も混じってるだろうな
591 ：仕様書無しさん：05/01/16 13:44:01
>>590
アンカー間違えてるのか頭が悪いのかどっちなの！？
アンカー間違えてるのか頭が悪いのかどっちなの！？
592 ：仕様書無しさん：05/01/16 22:34:02
なんか、変な人達集まってきちゃったよね。
ＰＭのスレなんだから、関係ない人たちは荒らさないで欲しい
ＰＭのスレなんだから、関係ない人たちは荒らさないで欲しい
593 ：仕様書無しさん：05/01/16 22:51:35
594 ：仕様書無しさん：05/01/16 22:55:48
......なんか、また2〜3名だけで燃えてるな。自作かもそれんが。
どっちも低レベルな荒らし。
どっちも低レベルな荒らし。
595 ：仕様書無しさん：05/01/16 22:58:47
>>594
絶妙な煽りだなｗ
絶妙な煽りだなｗ
596 ：仕様書無しさん：05/01/16 23:06:13
597 ：仕様書無しさん：05/01/16 23:53:10
>>596
学生かよｗ
学生かよｗ
週末だったのでちょっと前の話を蒸し返すが、１人で全工程って勉強になるよ。
ツールとか１０画面程度の仕事がたまにあるところだと、そんなの１人で全部ってことになる。
客先逝って要件聞いて、マシン構成から何から調整して、作って、テストして、納品する。
人月で５人月未満のあたりでたまにやっていた。
正直、こういう仕事をやると責任がずっしり来るし、全体を見渡す基本的な部分はできると思う。
ただ、それと同時に自分１人の力じゃどうしようもないような大きい案件（数十人以上の開発規模）もやっておきべき。
そういうところで、組織内での振舞い、分業制の意味も勉強する。
ツールとか１０画面程度の仕事がたまにあるところだと、そんなの１人で全部ってことになる。
客先逝って要件聞いて、マシン構成から何から調整して、作って、テストして、納品する。
人月で５人月未満のあたりでたまにやっていた。
正直、こういう仕事をやると責任がずっしり来るし、全体を見渡す基本的な部分はできると思う。
ただ、それと同時に自分１人の力じゃどうしようもないような大きい案件（数十人以上の開発規模）もやっておきべき。
そういうところで、組織内での振舞い、分業制の意味も勉強する。
599 ：なぎさっち ◆Nagi/FmYMM ：05/01/17 10:47:34
いいからオマエラageんな。
600 ：仕様書無しさん：05/01/17 15:46:04
【質問】
契約にもよるけど、受託開発時の
納品物に「ソースコード一式」ってのが入ってる場合
請負価格どのくらいアップさせますか？
技術のコアであるかどうかってのもあると思うけど
その算定根拠はなんにしてますか？
（１から作った場合の人月とか、それプラス技術の付加価値とか）
契約にもよるけど、受託開発時の
納品物に「ソースコード一式」ってのが入ってる場合
請負価格どのくらいアップさせますか？
技術のコアであるかどうかってのもあると思うけど
その算定根拠はなんにしてますか？
（１から作った場合の人月とか、それプラス技術の付加価値とか）
>>600
そもそも何故アップさせる必要があるのでしょうか？
大体において、受託開発はソース提示が前提だろ。契約上著作権を放棄しているはず。
なので、もしアップするのであれば、アップしない場合のあなたが得ると思う利益分を単純に乗せればいいんじゃないの？
隠すことによるメンテが来るとか、そういう文化圏ってあるのかな？
（ソース開示してそれらのメンテが来ないという”メリット”もあるんだけどね。ｗ）
そもそも何故アップさせる必要があるのでしょうか？
大体において、受託開発はソース提示が前提だろ。契約上著作権を放棄しているはず。
なので、もしアップするのであれば、アップしない場合のあなたが得ると思う利益分を単純に乗せればいいんじゃないの？
隠すことによるメンテが来るとか、そういう文化圏ってあるのかな？
（ソース開示してそれらのメンテが来ないという”メリット”もあるんだけどね。ｗ）
602 ：仕様書無しさん：05/01/17 16:16:23
>>601
ということは、いわゆる業務系では
ソース提供ってむしろ一般的なんですか・・
いや、いままで受託でwin用のパッケージ作ったり
ゲーム系の請負なんかをしてたんですが
ソース納品ってなかったんで・・
以前、他の部署で社内独自のライブラリ使ったwinアプリの
カスタマイズ版を請け負ったときに
ソース提供でもめたりしてんのは聞いたことありましたが・・
なんだろ文化圏の違いなのかな
ということは、いわゆる業務系では
ソース提供ってむしろ一般的なんですか・・
いや、いままで受託でwin用のパッケージ作ったり
ゲーム系の請負なんかをしてたんですが
ソース納品ってなかったんで・・
以前、他の部署で社内独自のライブラリ使ったwinアプリの
カスタマイズ版を請け負ったときに
ソース提供でもめたりしてんのは聞いたことありましたが・・
なんだろ文化圏の違いなのかな
>>602
業務系の場合、開発者、開発元会社がなくなっても、システムメンテナンスできないと
困るのは発注元側ですからね。
一般アプリの場合でも、サポート切れとかのリスクはあるけど、
業務系の場合、それが許されない場合がある、というかそんなの当然だわな。
開発元がなくなったから、明日からうちの工場なりは動きませんなんてありえん。
なので、ソースを開示するのは当然といえば当然・・・だと思ってた。
そういう場合、既存ライブラリ等に関しても開示は必要です。
そのソース含めてお客様のものになるわけですから。
業務系の場合、開発者、開発元会社がなくなっても、システムメンテナンスできないと
困るのは発注元側ですからね。
一般アプリの場合でも、サポート切れとかのリスクはあるけど、
業務系の場合、それが許されない場合がある、というかそんなの当然だわな。
開発元がなくなったから、明日からうちの工場なりは動きませんなんてありえん。
なので、ソースを開示するのは当然といえば当然・・・だと思ってた。
そういう場合、既存ライブラリ等に関しても開示は必要です。
そのソース含めてお客様のものになるわけですから。
604 ：仕様書無しさん：05/01/17 18:17:39
>>600-603
ソースを開示するか、開示した場合のは契約や著作権による。
パッケージ販売はオブジェクトのみの提供が多い。
Windows本体、Solaris本体、大半の市販アプリ...
ほとんどの場合、所有権は開発元にあり、使用許諾契約を販売しているだけ。
だから、転売禁止とか逆アセ禁止とかの制約の反面、サポート契約がある。
大半のシステム開発は、支援契約（法律上は準委任）などで、
「作業を手伝ってる」だけで、所有権は発注側にある場合が多い。
ただ、業務固有というより汎用的ツールなどは、開発側が使いまわせる契約に
なってる場合もある。
SIなどの請負契約だと、ここらの契約はかなり慎重に個々違う。
...とかかな？ 正確にはPM試験以来、忘れちゃったぜ。
ソースを開示するか、開示した場合のは契約や著作権による。
パッケージ販売はオブジェクトのみの提供が多い。
Windows本体、Solaris本体、大半の市販アプリ...
ほとんどの場合、所有権は開発元にあり、使用許諾契約を販売しているだけ。
だから、転売禁止とか逆アセ禁止とかの制約の反面、サポート契約がある。
大半のシステム開発は、支援契約（法律上は準委任）などで、
「作業を手伝ってる」だけで、所有権は発注側にある場合が多い。
ただ、業務固有というより汎用的ツールなどは、開発側が使いまわせる契約に
なってる場合もある。
SIなどの請負契約だと、ここらの契約はかなり慎重に個々違う。
...とかかな？ 正確にはPM試験以来、忘れちゃったぜ。
605 ：仕様書無しさん：05/01/17 19:44:23 ,
ソースを公開してしまうと、それを他の会社のﾋﾄにみられてしまうので、技術が盗まれてしまう。
と、深刻に悩んでいるPMを見たことがある。
目を覆いたくなるようなソースを書くﾋﾄでも、羞恥心ってのがあるんだなぁて思た。
と、深刻に悩んでいるPMを見たことがある。
目を覆いたくなるようなソースを書くﾋﾄでも、羞恥心ってのがあるんだなぁて思た。
心配しなくても受託開発じゃ青色発光ダイオードなんて永久に生まれないのにね。
608 ：仕様書無しさん：05/01/17 23:07:04
著作権は著作者に自動的に発生する。つまり基本的にベンダーが著作権を持つ。
あと著作権と所有権は別の権利は別だぞ！！！
あと著作権と所有権は別の権利は別だぞ！！！
まー客に不利な法律があれば契約書に書いて逃げてるだろうけど。
610 ：仕様書無しさん：05/01/18 01:06:06
情報処理技術者試験のプロジェクトマネージャ試験ってみんな取ってるの？
>>612
PMPってどんなの？
PMPってどんなの？
モダンPMを実践してるのはどのくらい？
615 ：仕様書無しさん：05/01/19 10:42:29
>>614
モダンPMってどんなの？
モダンPMってどんなの？
>>615
大正浪漫のかほりがするPMじゃないか？
大正浪漫のかほりがするPMじゃないか？
プロジェクト管理とは肚でするものだ
by Tom DeMarco
by Tom DeMarco
>>613
あまり美味しくないです。
あまり美味しくないです。
ソフトウェアの品質向上は今日のシステム開発ではごくあたりまえの要求と
なっており、その実現には効果的なテストプロセスの確立が重要です。
プロジェクトの成熟度によって実践レベルはさまざまですが、あらゆるシーンで
常に中心的な役割を担うのは開発者でしょう。
そこで、開発者を軸にしたテストプロセスの実践方法として、
優れた機能と高い実績を持つテストツールの使い勝手のよさが
システムの品質向上や短期開発にインパクトをもたらしていきます。
なっており、その実現には効果的なテストプロセスの確立が重要です。
プロジェクトの成熟度によって実践レベルはさまざまですが、あらゆるシーンで
常に中心的な役割を担うのは開発者でしょう。
そこで、開発者を軸にしたテストプロセスの実践方法として、
優れた機能と高い実績を持つテストツールの使い勝手のよさが
システムの品質向上や短期開発にインパクトをもたらしていきます。
【テスト】品質管理について語ろう【QA】＠プログラマー
http://pc5.2ch.net/test/read.cgi/prog/1088135300/168
時刻、文体からみて同一人物だと思うが・・・テキスト写して嬉しい？
http://pc5.2ch.net/test/read.cgi/prog/1088135300/168
時刻、文体からみて同一人物だと思うが・・・テキスト写して嬉しい？
「年々厳しさは増すばかり。でも、今さら別の仕事もできないし」とあきらめ顔
日本に来て働くのは、税金を納めながら
意見を言ってはならない『ロボット』になるということです
意見を言ってはならない『ロボット』になるということです
>>623
（有能な人間は除く）
（有能な人間は除く）
「これが、私が考えた職場だ。労働環境についていろいろ言う人も
いるかもしれない。それはシステムをつくるプログラマやＳＥが、
この仕様に合わせてもらうしかない」
「労働時間はこれ以上小さくしたくないし、残業手当もこれ以上
大きくしたくなかった。過労で倒れるのも狙ったもの、それが仕様。これは僕が
作ったもので、そういう仕様にしている。
明確な意思をもっているのであって、間違ったものではない。世界で一番
美しいものを作ったと思う。著名建築家が書いた図面に対して門の位置が
おかしいと難癖をつける人はいない。それと同じこと」
いるかもしれない。それはシステムをつくるプログラマやＳＥが、
この仕様に合わせてもらうしかない」
「労働時間はこれ以上小さくしたくないし、残業手当もこれ以上
大きくしたくなかった。過労で倒れるのも狙ったもの、それが仕様。これは僕が
作ったもので、そういう仕様にしている。
明確な意思をもっているのであって、間違ったものではない。世界で一番
美しいものを作ったと思う。著名建築家が書いた図面に対して門の位置が
おかしいと難癖をつける人はいない。それと同じこと」
コードレビューの話が落ち着いたら
急にスレに勢いがなくなっちゃってるね。
急にスレに勢いがなくなっちゃってるね。
最近、仕事は順調なんだけど、ハイペース＆結構仕事も正確な開発会社に
合わせて、仕事が早朝になってるよ・・・・4時に起きて、昨晩までの設計＆開
発の進捗を整理して、クライアントに投げて寝、12時に起きてクライアントと
電話で打ち合わせ、夕刻できるだけ早いうちに開発会社に仕様書投げてまた
寝て・・・・
あまりハイペースだと苦労の割りに工数安くなりそうで怖い。困ったもの。
合わせて、仕事が早朝になってるよ・・・・4時に起きて、昨晩までの設計＆開
発の進捗を整理して、クライアントに投げて寝、12時に起きてクライアントと
電話で打ち合わせ、夕刻できるだけ早いうちに開発会社に仕様書投げてまた
寝て・・・・
あまりハイペースだと苦労の割りに工数安くなりそうで怖い。困ったもの。
628 ：仕様書無しさん：05/03/03 00:36:10
生活時間をズラすのは得策とは言えない。
629 ：仕様書無しさん：05/03/03 23:22:36
ちょっと質問していいですか？
私は研究室で管理者やっています。クライアントの皆さんが音楽聞き
ながら研究してたんですが、最近容量がいっぱいになってきたんで
（HDDの共有容量が80GBしかないので）音楽ファイルすら置けない
状況なんですね。貧乏研究室なんで安いバルクのHDDを購入して
/junkという名前でジャンクなデータ専用領域を作成したんです。
そしたら他の管理者に”管理がダルい”とか言われたんですよ。
管理って/etc/fstabを書き直すだけなのに orz
管理者やってる皆さんどう思います？ユーザの希望を実現した
だけなのに...
私は研究室で管理者やっています。クライアントの皆さんが音楽聞き
ながら研究してたんですが、最近容量がいっぱいになってきたんで
（HDDの共有容量が80GBしかないので）音楽ファイルすら置けない
状況なんですね。貧乏研究室なんで安いバルクのHDDを購入して
/junkという名前でジャンクなデータ専用領域を作成したんです。
そしたら他の管理者に”管理がダルい”とか言われたんですよ。
管理って/etc/fstabを書き直すだけなのに orz
管理者やってる皆さんどう思います？ユーザの希望を実現した
だけなのに...
630 ：629：05/03/03 23:24:59
スレタイの管理者とはちょっと意味合いが違ってましたね。ｽﾏｿ orz
PMな方でもいいんですが、ユーザの意見を聞いたら管理者に
ケチつけられる。こんな状況の時どうしますか？
PMな方でもいいんですが、ユーザの意見を聞いたら管理者に
ケチつけられる。こんな状況の時どうしますか？
、『在庫』『経費』『スループット』の３つの指標がある。マネジメントの手段は明らかだ。『在庫を減らし、経費を減らし、スループットを増やす』。これが、マネジメントの全て
>>630
管理者ボコって追い出す
管理者ボコって追い出す
>>631
それは所謂、製造業の場合だね。
ソフトウエア開発／保守業の場合、『在庫』『経費』『スループット』の３つの指標が
それぞれ何に該当するのかを書かなければわからない人には全然わからないのでは？
それは所謂、製造業の場合だね。
ソフトウエア開発／保守業の場合、『在庫』『経費』『スループット』の３つの指標が
それぞれ何に該当するのかを書かなければわからない人には全然わからないのでは？
俺はＰＭもＰＧもどちらもこなせてしかも一流。
人間性も抜群で言うことなし。
なのでこのスレの住人のような悩みはない。
．．．と、そう思いこめば、何があっても乗り越えられる。
人間性も抜群で言うことなし。
なのでこのスレの住人のような悩みはない。
．．．と、そう思いこめば、何があっても乗り越えられる。
636 ：仕様書無しさん：05/03/06 10:22:47
裏切られる前に裏切れ、これ鉄則。
637 ：仕様書無しさん：05/03/06 14:34:42
638 ：仕様書無しさん：05/03/06 17:03:09
PM勃起
PM、PGと言う前に、まず一人のサラリーマンであることを忘れるな。
by ウチの会社の上司
by ウチの会社の上司
PS
>>641
IBMには昔、マジにPSが職種としてあった。
IBMには昔、マジにPSが職種としてあった。
643 ：仕様書無しさん：2005/06/01(水) 12:28:14
作業の進捗状況を％で報告してるんだけど、あれって意味あるの？
なんか 0%→90% の時間より 90%→100% の方が明らかに長いんだけど。
なんか 0%→90% の時間より 90%→100% の方が明らかに長いんだけど。
格言: いつでも「90%完了」と言える。
二次曲線方式なんだろ
予定通り逝くものなんかあるわけないが、大雑把な把握の役には立つ。
それと、進捗報告の見得の張り方で、その担当のキャラが掴める。
それと、進捗報告の見得の張り方で、その担当のキャラが掴める。
>作業の進捗状況
それ時間なの？成果物のできぐあいでしょ
それ時間なの？成果物のできぐあいでしょ
648 ：仕様書無しさん：2005/06/02(木) 19:09:13
ＰＭが会社から脱走しました。
どうしたらいいのでしょうか？このままだと俺がＰＭになっちゃう・・・・
どうしたらいいのでしょうか？このままだと俺がＰＭになっちゃう・・・・
649 ：仕様書無しさん：2005/06/02(木) 19:41:08
いまどきパーセンテージで進捗管理しているほうが問題
最近おもうんだがPMこそプロパーがやるべきでないと思う
プロジェクト焦がしたPMは実名報道してブラックリストに入れる
そのかわり莫大な報酬を貰う本当のプロの職業
とかってどうよ？
ｻﾗﾘｰﾏﾝPMってさぁ大きい会社だとプロジェクト焦げ付かせて
会社が数千万単位で損しても軽く左遷されたりする位で重い処分じゃない
そんな責任感のやつが仕切ってそもそも上手くいくはずも
技術者の生活も守れるはずがない希ガス
プロジェクト焦がしたPMは実名報道してブラックリストに入れる
そのかわり莫大な報酬を貰う本当のプロの職業
とかってどうよ？
ｻﾗﾘｰﾏﾝPMってさぁ大きい会社だとプロジェクト焦げ付かせて
会社が数千万単位で損しても軽く左遷されたりする位で重い処分じゃない
そんな責任感のやつが仕切ってそもそも上手くいくはずも
技術者の生活も守れるはずがない希ガス
なんか、付き合いのある会社の元に放り込まれて
無理無理なスケジュールで面倒な処理ばっかり担当になってる。
死にそうなのでつが・・・。
無理無理なスケジュールで面倒な処理ばっかり担当になってる。
死にそうなのでつが・・・。
652 ：仕様書無しさん：2005/06/21(火) 22:50:56
昔々、会社Ａに社内でカスタマイズをしたアプリケーションを導入したとさ。
時は流れて、、、会社ＢにもＢ用にカスタマイズしたアプリケーションを導入したとさ。
Ａ社もＢ社もバグも無く幸せに稼動していたとさ。
ところが、、、、ある日、、、、会社Ａと会社Ｂが合併したとさ！！！！（社名はＣとしよう）
困ったのは、Ａ社とＢ社に同じコンセプトのアプリを導入した俺の会社だ。
当然、経営統合の効率化で似たようなシステムを使いつづける必要はないと
Ｃ社からかシステム統合して欲しいと依頼があったとさ・・・・
I/Fも内部仕様も全く違うが、表面のユーザインタフェイスのみ似ている。
会社の社内関係も微妙に影響しているんだが。。。
Ａ社に導入した時俺は、ノータッチ。ＰＭは今、部長している。
Ｂ社に導入した時おれはＰＭだった。
自分のやったプロジェクトのアプリベースでプロジェクト進めたいが、
どうやって主導権取ればいいんだ。。。。旧Ａ社チームも主導権狙ってるらしい。
おら、どうしたらいいんだ？
時は流れて、、、会社ＢにもＢ用にカスタマイズしたアプリケーションを導入したとさ。
Ａ社もＢ社もバグも無く幸せに稼動していたとさ。
ところが、、、、ある日、、、、会社Ａと会社Ｂが合併したとさ！！！！（社名はＣとしよう）
困ったのは、Ａ社とＢ社に同じコンセプトのアプリを導入した俺の会社だ。
当然、経営統合の効率化で似たようなシステムを使いつづける必要はないと
Ｃ社からかシステム統合して欲しいと依頼があったとさ・・・・
I/Fも内部仕様も全く違うが、表面のユーザインタフェイスのみ似ている。
会社の社内関係も微妙に影響しているんだが。。。
Ａ社に導入した時俺は、ノータッチ。ＰＭは今、部長している。
Ｂ社に導入した時おれはＰＭだった。
自分のやったプロジェクトのアプリベースでプロジェクト進めたいが、
どうやって主導権取ればいいんだ。。。。旧Ａ社チームも主導権狙ってるらしい。
おら、どうしたらいいんだ？
>652
B社に導入したのをメインにすればコストが安くなることを示すとか
B社に導入したのをメインにすればコストが安くなることを示すとか
654 ：仕様書無しさん：2005/06/21(火) 23:06:30
親戚の吉藤君が一年ぶりに家に来ましたが何か？
>652
A社でもB社でもない版で統合にゃ!
[旧Ａ社チーム]対[もまえ]の問題の構造から[旧Ａ社チーム+もまえ]対[問題]の構造に汁！
A社でもB社でもない版で統合にゃ!
[旧Ａ社チーム]対[もまえ]の問題の構造から[旧Ａ社チーム+もまえ]対[問題]の構造に汁！
657 ：仕様書無しさん：2005/07/08(金) 20:54:02
役職ないのにPMやっっています。。。
というかいつの間にかPMに祭られていました。。。
PLが４人いる結構大き目のプロジェクトです。
大丈夫なのか？俺で・・・・
というかいつの間にかPMに祭られていました。。。
PLが４人いる結構大き目のプロジェクトです。
大丈夫なのか？俺で・・・・
パルプンテマスターが集うスレはここでつか？
そうですが、何か？
まて。ここは何が起こるか判らない呪文マスターのｽﾚなのか。
私のような真面目なPMはどこに行ったらイイのだｗ
私のような真面目なPMはどこに行ったらイイのだｗ
天国
663 ：６５７：2005/07/08(金) 22:37:46
>>662
PM 俺
PL A・・・PG4 ・・・５人
PL Ｂ・・・PG2 ・・・３人
PL Ｃ・・・PG4 ・・・５人
PL Ｄ・・・PG6 ・・・７人
１つの顧客に対して全部で４つのプロジェクトが平行で同時進行。
全部で最大２１人体制。カットオーバーは2006/05です。
GWなしは決定事項。
俺がPMに選ばれた理由は、２年間このプロジェクトで参加してて、
一番古株になったから。もともとのPMやPLは逃走や退職で皆消えた。
今度は俺が蒸発する番なのか？
PM 俺
PL A・・・PG4 ・・・５人
PL Ｂ・・・PG2 ・・・３人
PL Ｃ・・・PG4 ・・・５人
PL Ｄ・・・PG6 ・・・７人
１つの顧客に対して全部で４つのプロジェクトが平行で同時進行。
全部で最大２１人体制。カットオーバーは2006/05です。
GWなしは決定事項。
俺がPMに選ばれた理由は、２年間このプロジェクトで参加してて、
一番古株になったから。もともとのPMやPLは逃走や退職で皆消えた。
今度は俺が蒸発する番なのか？
書き忘れ。。。ちなみにPM手当てとして来年の５月まで毎月５万円支給されるそうです。
PLにはPL手当てとして１〜３万円。
あと終了時の利益率でPMに最大５０万円の特別賞与もあるとのことでした。
その他に最大でプロジェクト全体で２００万円の特別賞与もあり。
他の会社のPMもこんな感じ？
PLにはPL手当てとして１〜３万円。
あと終了時の利益率でPMに最大５０万円の特別賞与もあるとのことでした。
その他に最大でプロジェクト全体で２００万円の特別賞与もあり。
他の会社のPMもこんな感じ？
665 ：仕様書無しさん：2005/07/09(土) 03:07:04
>>663
ちいさっ
ちいさっ
それ言うなよ
そっとしておいてやれっつーに
そっとしておいてやれっつーに
おいおい、20人くらいのプロジェクトが、ちょうどいいってこと知らんのか？
100人200人のプロジェクトになってみろ。70%以上のメンバーはカスだぞ、カス。
下手したら80%超えるって。
100人200人のプロジェクトになってみろ。70%以上のメンバーはカスだぞ、カス。
下手したら80%超えるって。
>>661
「地獄」と言わない優しさが身に染みるぜ
「地獄」と言わない優しさが身に染みるぜ
669 ：仕様書無しさん：2005/07/09(土) 20:43:59
昨今、最低最悪の職業とみなされてます。
670 ：仕様書無しさん：2005/07/09(土) 20:46:04
PMになるくらいならパッケージソフトでも作ったほうが
苦しみがいがあるぞ。
苦しみがいがあるぞ。
>>670
パッケージソフトのＰＭやってますが何か？
プレスリリースしちゃってるので、洒落にならない状態ですが何か？
８月中に出ることになってるけど、まだ作ってますが何か？
営業が、わけのわからんことを言っちゃって、必死につじつま合わせようと
していますが何か？
今更、機能追加しようとしていますが何か？
パッケージソフトのＰＭやってますが何か？
プレスリリースしちゃってるので、洒落にならない状態ですが何か？
８月中に出ることになってるけど、まだ作ってますが何か？
営業が、わけのわからんことを言っちゃって、必死につじつま合わせようと
していますが何か？
今更、機能追加しようとしていますが何か？
>671
とりあえず無能なPMと煽られると思う
とりあえず無能なPMと煽られると思う
673 ：仕様書無しさん：2005/07/09(土) 23:21:22
営業を相手にするとこがDQNかと。
>671
何も。
何も。
何も。
何も。
何も。
何も。
何も。
何も。
何も。
何も。
営業使えねぇ・・・・なんで俺が価格交渉までしなきゃいけないんだよ
676 ：仕様書無しさん：2005/07/09(土) 23:44:21
PMは最低な職業です。
犬死に、早死にに最も近い職業です。
犬死に、早死にに最も近い職業です。
677 ：仕様書無しさん：2005/07/09(土) 23:48:20
>>100
zaregoto? nanigaiitai.
itibuno dekiru hito to sonota dekinai hito,
dono gyoukai mo onaji desyou.
konnakotomo wakarazuni PM toha maji waraeru.
kaihatu kibo ni kakawarazu souiu mononanndesuyo.
zaregoto? nanigaiitai.
itibuno dekiru hito to sonota dekinai hito,
dono gyoukai mo onaji desyou.
konnakotomo wakarazuni PM toha maji waraeru.
kaihatu kibo ni kakawarazu souiu mononanndesuyo.
678 ：仕様書無しさん：2005/07/09(土) 23:52:27
PMの大半は実は馬鹿が多いです。
１万人軍勢に１００人で立ち向かうような馬鹿が。
１万人軍勢に１００人で立ち向かうような馬鹿が。
679 ：仕様書無しさん：2005/07/10(日) 00:08:01
なんといっても、部下を過労に連れ込むのに罪を感じないのは超越論的馬鹿です。
680 ：仕様書無しさん：2005/07/10(日) 07:35:06
PM張るなら仕事の吟味からはじめろ。
つまり、会社側と戦え。バーーーーカ。
つまり、会社側と戦え。バーーーーカ。
681 ：仕様書無しさん：2005/07/10(日) 07:44:55
PMとはピーマン・マンでした。
682 ：仕様書無しさん：2005/07/10(日) 08:14:47
PMは会社にとってお得な人達です。
いっぱい働いて、お荷物になる前に身体壊してやめてくれるから。
やめるときに、会社の冷たさを知って初めて自分の大馬鹿さを知る。
いっぱい働いて、お荷物になる前に身体壊してやめてくれるから。
やめるときに、会社の冷たさを知って初めて自分の大馬鹿さを知る。
683 ：仕様書無しさん：2005/07/10(日) 08:36:42
お前らは、どんな傾向のＰＭ？
Ａ・・・定時になるとすぐに帰る。
口癖は「残業代一切出さないから、定時で帰れ！」
人付き合い良くない。毎日、朝と夕方の進捗確認がウルサイ。
※基本的な考えが残業しなきゃ終わらないプロジェクトはＰＭは無能。
Ｂ・・・プロジェクトメンバーが全員帰るまで、必ず最後まで残っている。
口癖は「どんなに残業してもいいから、進捗の遅れはだすな！」
人付き合いがイイ。月一程度でプロジェクトメンバに飲み会の話を持ってくる。
※基本的な考えが、顧客の要望には残業しても答えなければならない。
俺は、Ａの方がプロジェクトメンバとして加わった方が良かったな。
他のプロジェクトのメンバが残業なのを尻目にキッチリ定時で帰れたし。
ただ、プロジェクト終わった後に残業できない体になっていたのと
残業無くて残業代がでないから月５万円程度収入減ったのが痛かった。
Ａ・・・定時になるとすぐに帰る。
口癖は「残業代一切出さないから、定時で帰れ！」
人付き合い良くない。毎日、朝と夕方の進捗確認がウルサイ。
※基本的な考えが残業しなきゃ終わらないプロジェクトはＰＭは無能。
Ｂ・・・プロジェクトメンバーが全員帰るまで、必ず最後まで残っている。
口癖は「どんなに残業してもいいから、進捗の遅れはだすな！」
人付き合いがイイ。月一程度でプロジェクトメンバに飲み会の話を持ってくる。
※基本的な考えが、顧客の要望には残業しても答えなければならない。
俺は、Ａの方がプロジェクトメンバとして加わった方が良かったな。
他のプロジェクトのメンバが残業なのを尻目にキッチリ定時で帰れたし。
ただ、プロジェクト終わった後に残業できない体になっていたのと
残業無くて残業代がでないから月５万円程度収入減ったのが痛かった。
自分はＡなのだが
会社からＢになれと言われていて激しく鬱だ
会社からＢになれと言われていて激しく鬱だ
俺もＡだな。
しかし、俺のやり方がチームに浸透し、開発速度がどんどんあがり、そのスピードを前提に
スケジューリングしたときに、少しでも遅れると「お前のチームは残業しないから遅れるのだ」とか
言われるかもしれないという、諸刃の剣。
しかし、俺のやり方がチームに浸透し、開発速度がどんどんあがり、そのスピードを前提に
スケジューリングしたときに、少しでも遅れると「お前のチームは残業しないから遅れるのだ」とか
言われるかもしれないという、諸刃の剣。
686 ：仕様書無しさん：2005/07/10(日) 15:55:15
Aなんて存在するんすか？
>>685
工数増大のリスク管理を怠らない様にすれば(ry
>>686
とても良い質問だ。
他社を凌駕する開発力があると顧客が認識しているような会社ならありうる。
としか答えられないが。
私も、ＡだというＰＭになぜそれが可能かをたずねたい
工数増大のリスク管理を怠らない様にすれば(ry
>>686
とても良い質問だ。
他社を凌駕する開発力があると顧客が認識しているような会社ならありうる。
としか答えられないが。
私も、ＡだというＰＭになぜそれが可能かをたずねたい
A(残業しないプロジェクト)を可能にする方法は、、
スケジュールを本来より、20%程余裕を持っておけば大丈夫なんじゃない？
工数が増えた分は顧客負担になってしまうが・・・・・
スケジュールを本来より、20%程余裕を持っておけば大丈夫なんじゃない？
工数が増えた分は顧客負担になってしまうが・・・・・
689 ：仕様書無しさん：2005/07/10(日) 20:21:23
20%→2,000%の誤りなら賛成します。
690 ：仕様書無しさん：2005/07/11(月) 00:13:09
PMの真の勝利は４０歳前に（できれば３５歳前に）PMを卒業すること。
つまり、長くやるものではあーーーーりません。
つまり、長くやるものではあーーーーりません。
そうでもないと思うぞ
内装系は夜遅くやらされたりするみたいだし
監督する人はデスクワークもあるから現場終わってからも作業あるとかなんとか
内装系は夜遅くやらされたりするみたいだし
監督する人はデスクワークもあるから現場終わってからも作業あるとかなんとか
693 ：仕様書無しさん：2005/07/13(水) 20:17:40
さてと上司をこき使う平社員PMの俺がきましたよ！
いいんじゃないの？
立ってるものは親でも使えっていうから。
立ってるものは親でも使えっていうから。
695 ：仕様書無しさん：2005/07/15(金) 23:08:22
PMじゃ人生棒なし
696 ：仕様書無しさん：2005/07/15(金) 23:26:19
気づいたときには病院のＩＣＵって人多そうだよな。
そのままあの世か、半身不随か、ああああああいやな職業だ。
そのままあの世か、半身不随か、ああああああいやな職業だ。
ガンダムのテレビに見入る児は六才 戦死とは何ぞ我に問いたり
698 ：仕様書無しさん：2005/07/16(土) 14:14:23
PMって見方によっては負け犬かも。
699 ：仕様書無しさん：2005/07/16(土) 14:32:42
キャンキャン、キャンキャンうるせいよな。
それに、ときどき客に尻尾振ってるしな。
それに、ときどき客に尻尾振ってるしな。
>>695 「棒に振る」と「台無し」を複合した高度な冗談？
701 ：仕様書無しさん：2005/07/16(土) 22:35:09
ピンチ・マン
ピアノ・マン
703 ：仕様書無しさん：2005/07/18(月) 09:01:59
パー・マン
パニック・マン
パンツ・マン
パーセント・マン
パニック・マン
パンツ・マン
パーセント・マン
専務の息子がＰＭやってて、納期の二日前に入院した。
引き継がされたら未完成のバグだらけ、結局一ヶ月オーバーで納入。
ボーナス大幅カット、査定も大幅マイナスになった。
苦情を言ったら「現在の責任者は君だ」なんて言われた。
翌日にはkey logger入れられた…。
そこまでは許容してもいいとして、専務の息子にボーナス満額って何？
辞表叩き付けたい。
ただのプログラマにもどりたい。
でも、オファーがＰＭでしか来ない。
プロポーズ受けて事務所でも手伝おうかな？
引き継がされたら未完成のバグだらけ、結局一ヶ月オーバーで納入。
ボーナス大幅カット、査定も大幅マイナスになった。
苦情を言ったら「現在の責任者は君だ」なんて言われた。
翌日にはkey logger入れられた…。
そこまでは許容してもいいとして、専務の息子にボーナス満額って何？
辞表叩き付けたい。
ただのプログラマにもどりたい。
でも、オファーがＰＭでしか来ない。
プロポーズ受けて事務所でも手伝おうかな？
プロポーズ受けて事務所でも手伝おうか
そうしなさい
そうしなさい
706 ：仕様書無しさん：2005/07/19(火) 22:57:17
（脳or心臓の血管）プッツン・マン
707 ：仕様書無しさん：2005/07/21(木) 00:58:19
PM以外に結局儲け口がない生活破綻者がPMです。
最悪の仕事を選ばざるを得ない悲しい性格破綻者でもあります。合掌
最悪の仕事を選ばざるを得ない悲しい性格破綻者でもあります。合掌
708 ：仕様書無しさん：2005/07/21(木) 01:46:15
PMは午後出社だよな?
中小企業診断士の資格を取って
コンサルタントに転身します。
コンサルタントに転身します。
711 ：仕様書無しさん：2005/07/21(木) 21:37:43
コンサルは逃げるのうまくないとやってられない。
712 ：仕様書無しさん：2005/07/21(木) 21:53:10
>>709はホームレスへの王道を行く人か、とチョンが訊いた。
そうです、とチャンが応えた。
そうです、とチャンが応えた。
713 ：仕様書無しさん：2005/07/21(木) 23:54:59
比較的女の多いプロジェクトの
PMになったが、仕様を聞きにくる子がなぜか皆、
ひざつく感じで、俺の横にかがむんで、
胸元オーパイ丸見え。
ヤバス！
PMになったが、仕様を聞きにくる子がなぜか皆、
ひざつく感じで、俺の横にかがむんで、
胸元オーパイ丸見え。
ヤバス！
>713
俺もそのプロジェクトに混ぜてくれ
俺もそのプロジェクトに混ぜてくれ
715 ：仕様書無しさん：2005/07/22(金) 01:01:30
>715
> 普通の男には相手にされなさそうな子ばかりですが。
あ、んじゃいいや
がんばってくれたまい
> 普通の男には相手にされなさそうな子ばかりですが。
あ、んじゃいいや
がんばってくれたまい
持論、この業界は女の子のほうが優秀な確率が高い。
野郎に比べて目的意識をきちんともってこの仕事選んでるから。
野郎の場合、他に選択の余地がなく、パソコンとだけ対話できるからこの業界ってのが多くて。ｗ
野郎に比べて目的意識をきちんともってこの仕事選んでるから。
野郎の場合、他に選択の余地がなく、パソコンとだけ対話できるからこの業界ってのが多くて。ｗ
いやー、女の子、確かにその通りなんだけど
その分自己肥大しちゃってる手合いも居たりしてマイッタ。
最終的には泣いちゃうし。
その分自己肥大しちゃってる手合いも居たりしてマイッタ。
最終的には泣いちゃうし。
プロジェクト管理者からライン管理者へ話題がシフトしつつあるような
720 ：仕様書無しさん：2005/07/23(土) 00:13:07
話題だけじゃなく実質がそのようですが。
最近のビジネス書とか見たほうがよろしいようで。
最近のビジネス書とか見たほうがよろしいようで。
721 ：仕様書無しさん：2005/07/23(土) 00:58:44
中規模なデータベース開発の話。
糞客が納期2週間前にレコードフォーマットの変更を要求。
営業経由で糞上司が「やれ。対応するんだ」とそのまま要求をスルー。
従ったら、せっかくデバッグも終わりかけていたシステムがバグバグバグの嵐。
納期は破綻して糞客は激怒。上司も糞客に合わせて激怒。
納品後にもトラブル発生。俺は連日客先に呼び出されて罵倒の限りを尽くされた。
朝から夜までノンストップ罵倒に晒される日も少なくなかった。
「お願いです。仕事に戻らせてください。」
「何甘いこと言ってるんだよ。俺達の言いたいことはまだ1/10も伝えてないぞ」
缶詰＋罵倒で一日を過ごし、帰り際に翌朝期限の宿題を山盛り。
事務所に帰ると上司に捕まって監禁罵倒攻撃。
「し、仕事を、取り掛からせてください」
「お前には言いたい事が山ほどある」深夜12時に解放された。
課長は俺が独断で仕様変更した事にして部長に報告していたらしい。
そんな生活を何ヶ月も続けて、トラブルの責任を被せられてボーナスは
3/4をカットされてしまった。夏のボーナス10万円。PMなのに10万円。
明日は糞客が乗り込んできて一日罵倒攻撃を加えると、さっき電話で言ってきた。
上司の保身の為に弁解用資料の作成を明日の朝までにと押し付けられた。
宿題を山ほど押し付けてその実行時間を罵倒攻撃で奪い尽くす。その結果を
更に更に責め立てる。毎日毎日、弁護士のいない裁判だ。
糞客に「バイタの子」なんて言われる毎日だ。
こんな職場でココロを壊されずに生き抜く方法はあるのだろうか？
糞客が納期2週間前にレコードフォーマットの変更を要求。
営業経由で糞上司が「やれ。対応するんだ」とそのまま要求をスルー。
従ったら、せっかくデバッグも終わりかけていたシステムがバグバグバグの嵐。
納期は破綻して糞客は激怒。上司も糞客に合わせて激怒。
納品後にもトラブル発生。俺は連日客先に呼び出されて罵倒の限りを尽くされた。
朝から夜までノンストップ罵倒に晒される日も少なくなかった。
「お願いです。仕事に戻らせてください。」
「何甘いこと言ってるんだよ。俺達の言いたいことはまだ1/10も伝えてないぞ」
缶詰＋罵倒で一日を過ごし、帰り際に翌朝期限の宿題を山盛り。
事務所に帰ると上司に捕まって監禁罵倒攻撃。
「し、仕事を、取り掛からせてください」
「お前には言いたい事が山ほどある」深夜12時に解放された。
課長は俺が独断で仕様変更した事にして部長に報告していたらしい。
そんな生活を何ヶ月も続けて、トラブルの責任を被せられてボーナスは
3/4をカットされてしまった。夏のボーナス10万円。PMなのに10万円。
明日は糞客が乗り込んできて一日罵倒攻撃を加えると、さっき電話で言ってきた。
上司の保身の為に弁解用資料の作成を明日の朝までにと押し付けられた。
宿題を山ほど押し付けてその実行時間を罵倒攻撃で奪い尽くす。その結果を
更に更に責め立てる。毎日毎日、弁護士のいない裁判だ。
糞客に「バイタの子」なんて言われる毎日だ。
こんな職場でココロを壊されずに生き抜く方法はあるのだろうか？
723 ：721：2005/07/23(土) 01:12:04
プロジェクト開始の時は
「無茶な客に無理言われるかもしれないが、何かあったら俺達が守ってやる」
と部長と課長に言われたのが嘘のようだ。それでも正社員の肩書きを失いたく
なくて、俺は半年以上ろくな休みも取らずに働いている。
俺の願いは只一つ。
人生の負け組みになりたくない。
それだけなんだ。
「無茶な客に無理言われるかもしれないが、何かあったら俺達が守ってやる」
と部長と課長に言われたのが嘘のようだ。それでも正社員の肩書きを失いたく
なくて、俺は半年以上ろくな休みも取らずに働いている。
俺の願いは只一つ。
人生の負け組みになりたくない。
それだけなんだ。
724 ：仕様書無しさん：2005/07/23(土) 05:58:23
>>721ほどひどくないが、似たようなものがあったとき、おれは客と課長と公然と喧嘩した。
そして社内で負け組みに入れられた。もちろん、降格人事を受けた。
人手が必要になった新しい技術のほうの仕事にまわされて新入社員扱いされた。
それがよかったのだ。今は先端の仕事で名誉が回復しつつある。でも、あの課長
と客には未だに敵がい心がある（当然である）。それなのに会社から何度もまわ
されそうになり、断ってばかりいたら、またあの課長が怒り出した。
結論は、辞めました。
壊れた客と壊れた課長によって人生が壊されました。
そして社内で負け組みに入れられた。もちろん、降格人事を受けた。
人手が必要になった新しい技術のほうの仕事にまわされて新入社員扱いされた。
それがよかったのだ。今は先端の仕事で名誉が回復しつつある。でも、あの課長
と客には未だに敵がい心がある（当然である）。それなのに会社から何度もまわ
されそうになり、断ってばかりいたら、またあの課長が怒り出した。
結論は、辞めました。
壊れた客と壊れた課長によって人生が壊されました。
>>721
リーマンだから、上の命令に従うのはやむを得ないが、
「この時期に変更するのは作業量的に無理ですし、費用効果的にも合いません！
いったんは現在の仕様で納品して改善要件にするか、それとも納期を
１ヶ月延ばすかのどちらかしかできません。さもないとプロジェクトが破綻します！」
とかいえなかったのか？
事前にそう伝えておけば随分違ったと思うけど。
「はい、やります！」と安請け合いして後で周囲に迷惑をかけてしまうよりも、
出来ないことは断わるほうが周囲もお前も幸せだと気づきなよ。
リーマンだから、上の命令に従うのはやむを得ないが、
「この時期に変更するのは作業量的に無理ですし、費用効果的にも合いません！
いったんは現在の仕様で納品して改善要件にするか、それとも納期を
１ヶ月延ばすかのどちらかしかできません。さもないとプロジェクトが破綻します！」
とかいえなかったのか？
事前にそう伝えておけば随分違ったと思うけど。
「はい、やります！」と安請け合いして後で周囲に迷惑をかけてしまうよりも、
出来ないことは断わるほうが周囲もお前も幸せだと気づきなよ。
>従ったら、せっかくデバッグも終わりかけていたシステムがバグバグバグの嵐。
ここがおかしいだろ
フォーマット変更対応がなんで全体に影響すんだw
ここがおかしいだろ
フォーマット変更対応がなんで全体に影響すんだw
>>726
それ思ったけど。
フォーマットって呼んでるのが外部インターフェースなのか、内部テーブルなのか。
外部だとしたら、その変更程度で崩れるシステムは作りが糞。
内部なら、その決定権がないなんて開発じゃなくてコーダーじゃん。
それ思ったけど。
フォーマットって呼んでるのが外部インターフェースなのか、内部テーブルなのか。
外部だとしたら、その変更程度で崩れるシステムは作りが糞。
内部なら、その決定権がないなんて開発じゃなくてコーダーじゃん。
728 ：仕様書無しさん：2005/07/23(土) 14:36:55
コードの桁直しだけでも、でかい作業になることあるよ。
若いとき、経験した。
経験のない人は、気をつけよう。
おれも、二つ返事で安受けあいしたのです。
若いとき、経験した。
経験のない人は、気をつけよう。
おれも、二つ返事で安受けあいしたのです。
729 ：721：2005/07/23(土) 15:28:23
とにかく上司が俺を憎んで憎んで憎んでたまらないらしい。
今日も出社したら午前中一杯嫌味を言われ続けた。
「お前が勝手に仕様を変更したのが悪いんだ。俺達が止めたのにって事に
しておけよな。お前一人の問題だ。だったらこの顛末の覚悟は出来ている
だろうな？」
と言う意味の話を、表現変えて何度も言われ続けた。昼飯食いに出かける
ついでにノートＰＣから書き込んでいる。
随分前に日曜日に１日休んだ。その時は家に置いた携帯に課長からの着信
が連続で数え切れないほど入っていた。マナーモードにしてあったためか、
電池が切れていたんだ。着信記録を見てびっくり。その課長からの連続
リダイヤル攻撃が１時間半に渡って機関銃のように入っていた。間髪いれず
に連続して入っていたんだ。どんな形相で事務所からコールしたのか想像が
付いた。
上との人間関係が少しばかりぎくしゃくしているんだけど、皆はこんな時どう
しているんだろうか？
今日も出社したら午前中一杯嫌味を言われ続けた。
「お前が勝手に仕様を変更したのが悪いんだ。俺達が止めたのにって事に
しておけよな。お前一人の問題だ。だったらこの顛末の覚悟は出来ている
だろうな？」
と言う意味の話を、表現変えて何度も言われ続けた。昼飯食いに出かける
ついでにノートＰＣから書き込んでいる。
随分前に日曜日に１日休んだ。その時は家に置いた携帯に課長からの着信
が連続で数え切れないほど入っていた。マナーモードにしてあったためか、
電池が切れていたんだ。着信記録を見てびっくり。その課長からの連続
リダイヤル攻撃が１時間半に渡って機関銃のように入っていた。間髪いれず
に連続して入っていたんだ。どんな形相で事務所からコールしたのか想像が
付いた。
上との人間関係が少しばかりぎくしゃくしているんだけど、皆はこんな時どう
しているんだろうか？
見なかったことにして寝る
731 ：522：2005/07/23(土) 18:21:59
>729
> 上との人間関係が少しばかりぎくしゃくしているんだけど、
「少し」どころじゃないように見える。
> 上との人間関係が少しばかりぎくしゃくしているんだけど、
「少し」どころじゃないように見える。
732 ：仕様書無しさん：2005/07/23(土) 18:45:02
734 ：仕様書無しさん：2005/07/23(土) 19:07:26
729の話が本当なら、それで転職しないのはマゾの域だぞ。
俺だったら刑事事件を起こしてまた捕まってしまうだろーな。
俺だったら刑事事件を起こしてまた捕まってしまうだろーな。
また？
737 ：仕様書無しさん：2005/07/23(土) 21:33:09
遅ればせながらJavaでデザインパターンを応用できるようになった。
PMにチラッと話したら下らんことやる暇あったらさっさと効率よく
プログラム組めと言われた。（爆沈）
PMにチラッと話したら下らんことやる暇あったらさっさと効率よく
プログラム組めと言われた。（爆沈）
739 ：仕様書無しさん：2005/07/24(日) 11:08:42
>>729
おいらも>>733にはげしく賛同します。
そのままいるようなとこじゃない（いたら本当に死ぬ）
だったら、即やめる。
会社側は、終わらせてからやめろと言うだろうが、
１時間でも早くやめなさい。
問題がこじれたら、出社しないこと。
あとは、転職探しすること。
円満退社は不要です。
おいらも>>733にはげしく賛同します。
そのままいるようなとこじゃない（いたら本当に死ぬ）
だったら、即やめる。
会社側は、終わらせてからやめろと言うだろうが、
１時間でも早くやめなさい。
問題がこじれたら、出社しないこと。
あとは、転職探しすること。
円満退社は不要です。
>>721
耳栓でもしていけ(嘘)
それか君が労災でも申請しなさい。
良心的な病院だと心労性の病気ですとお情けで出してくれるところもある。
状況が状況だけに逃げちゃえw
金ないみたいだけど技術あるんだし派遣でもやれw
まあ上司は完全に病気だな 南無
くれぐれも手は出すなよ。会社内で殴られたら倒れて動けないフリしなさい。
上司が逆に飛ぶからw
耳栓でもしていけ(嘘)
それか君が労災でも申請しなさい。
良心的な病院だと心労性の病気ですとお情けで出してくれるところもある。
状況が状況だけに逃げちゃえw
金ないみたいだけど技術あるんだし派遣でもやれw
まあ上司は完全に病気だな 南無
くれぐれも手は出すなよ。会社内で殴られたら倒れて動けないフリしなさい。
上司が逆に飛ぶからw
741 ：仕様書無しさん：2005/07/24(日) 11:44:35
>>721
かわいそうに。１年前の俺を見てるようだ。
俺は問題が収束してから辞めたけど、ココロとカラダを壊しちまった。
へへへへｈ
俺の経験からは、完全に壊れた方が辞めやすいと思うな。
壊れてから半年ほどブラブラして、休憩取るのもあり。
かわいそうに。１年前の俺を見てるようだ。
俺は問題が収束してから辞めたけど、ココロとカラダを壊しちまった。
へへへへｈ
俺の経験からは、完全に壊れた方が辞めやすいと思うな。
壊れてから半年ほどブラブラして、休憩取るのもあり。
742 ：仕様書無しさん：2005/07/24(日) 14:49:14
>>721
辞めることになるのは確実でしょう。
だったらすぐに辞めてその上司を吹っ飛ばすべきです。
辞めるときは倒れた振りしなさい。
過労だといえば医者は診断書出してくれます。
私は入院させてもらってデスマ途中で辞めました。
辞めることになるのは確実でしょう。
だったらすぐに辞めてその上司を吹っ飛ばすべきです。
辞めるときは倒れた振りしなさい。
過労だといえば医者は診断書出してくれます。
私は入院させてもらってデスマ途中で辞めました。
743 ：仕様書無しさん：2005/07/24(日) 14:50:33
ちなみに上司は何もできない人でしたから即首だったらしいです。
744 ：仕様書無しさん：2005/07/24(日) 16:17:47
つーかさ。優秀なPMにしてもPGにしても
風呂に入った時に必ずちんちんを洗ってるよ。
それにつきるんじゃないか？
風呂に入った時に必ずちんちんを洗ってるよ。
それにつきるんじゃないか？
745 ：仕様書無しさん：2005/07/24(日) 16:29:00
746 ：仕様書無しさん：2005/07/24(日) 17:45:16
○優秀なPMはちんちん洗う。
×ちんちんを洗うPMは優秀なPMである。
○ちんちんを洗うPMだからといって優秀なPMとは限らない。
×優秀なPMはちんちんを洗わない。
お前等さあ、きちんと洗えって。まずはそこからだよ
ちょっとつばつけるだけでもかなり違うはず。
×ちんちんを洗うPMは優秀なPMである。
○ちんちんを洗うPMだからといって優秀なPMとは限らない。
×優秀なPMはちんちんを洗わない。
お前等さあ、きちんと洗えって。まずはそこからだよ
ちょっとつばつけるだけでもかなり違うはず。
＞ちょっとつばつけるだけでもかなり違うはず。
どうよ？それ。
どうよ？それ。
748 ：仕様書無しさん：2005/07/24(日) 20:35:55
このカンリーシャはつーかえないーず
721 は既に入院中か上司からの説法中か？
おれなら携帯水に入れる
おれなら携帯水に入れる
751 ：721：2005/07/26(火) 15:48:43
糞客に尻尾を振って俺に罪を被せた糞上司が
糞客に俺の携帯と固定電話の番号を教えたらしい。
辛くても普通に出社しているのに、俺がプロジェクト放棄して
逃亡して行方不明だと、糞客に吹き込んだらしい。部下のPGが
言いにくそうに教えてくれた。
帰る度に糞客からの苦情が留守電にたっぷりと溜まっている。
そういや、この１週間ばかり糞客からかかってきた電話が俺に
渡される事が無い。
今日どうにも我慢できなくなって上司に確認したら
「あと１ヶ月もすればほとぼりが冷めるが、お前は逃亡した事になっている。
だから、相応の覚悟はしてもらうぞ。いいな」
と一方的に言われた。破綻プロジェクトから手を引く為に、俺は捨て駒に
されてしまった。今日はどういう訳か有給を取らされた。昨夜
「お前、いろいろと大変だろうから明日は休め」
と携帯に上司が欠けてきた。何か裏がありそうだったが、寝不足が溜まって
フラフラだったので、俺は今日休んだ。さっき起きたところだ。
今日も客先からの留守電が３件入ってるな。もう聞かずに消してるけど。
糞客に俺の携帯と固定電話の番号を教えたらしい。
辛くても普通に出社しているのに、俺がプロジェクト放棄して
逃亡して行方不明だと、糞客に吹き込んだらしい。部下のPGが
言いにくそうに教えてくれた。
帰る度に糞客からの苦情が留守電にたっぷりと溜まっている。
そういや、この１週間ばかり糞客からかかってきた電話が俺に
渡される事が無い。
今日どうにも我慢できなくなって上司に確認したら
「あと１ヶ月もすればほとぼりが冷めるが、お前は逃亡した事になっている。
だから、相応の覚悟はしてもらうぞ。いいな」
と一方的に言われた。破綻プロジェクトから手を引く為に、俺は捨て駒に
されてしまった。今日はどういう訳か有給を取らされた。昨夜
「お前、いろいろと大変だろうから明日は休め」
と携帯に上司が欠けてきた。何か裏がありそうだったが、寝不足が溜まって
フラフラだったので、俺は今日休んだ。さっき起きたところだ。
今日も客先からの留守電が３件入ってるな。もう聞かずに消してるけど。
辞めたほうがイイと思う
つうか上司スレにいけよ。
いい加減すれ違いだし、悲惨自慢はウザイ。
いい加減すれ違いだし、悲惨自慢はウザイ。
>>751
個人情報保護法違反で提訴できるんじゃない？
個人情報保護法違反で提訴できるんじゃない？
>>751が事実なら、個人情報云々とか言わなくても
もっとストレートな訴え方ができるんでは？
もっとストレートな訴え方ができるんでは？
756 ：721：2005/07/30(土) 10:07:54
今年になって初めて有給を1日取得したんだけど、
その日は糞客が事務所に乗り込んできたらしい。圧迫ミーティングでは
課長も部長も必死になって都合の悪い事を俺に被せていたらしい。
これまではそれで済んだのだが、俺が休むとプロジェクトが完全に停止
してしまう実態を糞客に気付かれたらしい。
俺は逃亡したことになっているんで、後輩の一人が、まだコーダーな
奴が、PM代理に仕立て上げられてしまい、糞客に携帯の番号を押さえ
られたという。後輩が今にも辞めそうな口調で夜に電話をかけてきた。
その夜、糞上司から電話があった。
「お前、有給使ったつもりでいるかもしれないけどな、今はそんな状況
じゃないって事分かってるよな？だから有給申請は却下したぞ。勝手
にサボるんじゃないぞ」
と一方的に言って切られてしまった。
今日は、「糞上司が糞客に仕切り直しの仕様提案をする為の資料」を
代筆する為に出社を命じられている。こうなったのも全て俺一人の
責任だと喚いていた。いい加減面倒くさくなってきたので、目覚まし時
計は仕掛けなかった。今起きた。
留守番電話には糞上司と糞客から交互に罵声が詰まっていたが、
初めの2件ぐらい聞いてあとは聞かずに消した。今日の出勤？行く
気が失せたので、遊びに出かける事にした。
俺はこれからオーストラリア旅行のツアーでも探しに、旅行代理店
へ向かうつもりだ。キャンセル空きがあれば、明日にでも2週間の
旅に出ると思う。そうだ、後輩も誘おう。
その日は糞客が事務所に乗り込んできたらしい。圧迫ミーティングでは
課長も部長も必死になって都合の悪い事を俺に被せていたらしい。
これまではそれで済んだのだが、俺が休むとプロジェクトが完全に停止
してしまう実態を糞客に気付かれたらしい。
俺は逃亡したことになっているんで、後輩の一人が、まだコーダーな
奴が、PM代理に仕立て上げられてしまい、糞客に携帯の番号を押さえ
られたという。後輩が今にも辞めそうな口調で夜に電話をかけてきた。
その夜、糞上司から電話があった。
「お前、有給使ったつもりでいるかもしれないけどな、今はそんな状況
じゃないって事分かってるよな？だから有給申請は却下したぞ。勝手
にサボるんじゃないぞ」
と一方的に言って切られてしまった。
今日は、「糞上司が糞客に仕切り直しの仕様提案をする為の資料」を
代筆する為に出社を命じられている。こうなったのも全て俺一人の
責任だと喚いていた。いい加減面倒くさくなってきたので、目覚まし時
計は仕掛けなかった。今起きた。
留守番電話には糞上司と糞客から交互に罵声が詰まっていたが、
初めの2件ぐらい聞いてあとは聞かずに消した。今日の出勤？行く
気が失せたので、遊びに出かける事にした。
俺はこれからオーストラリア旅行のツアーでも探しに、旅行代理店
へ向かうつもりだ。キャンセル空きがあれば、明日にでも2週間の
旅に出ると思う。そうだ、後輩も誘おう。
できるところまでやればいいんじゃないか？出来ない物は出来ないんだし。
顧客に怒られて反論出来ない場合の対処を教えようか？
「本当に困った振り」しとけばいいんだよ。
挑発に乗って無理したり、本気で気にしたりしたらダメ。
結局失敗してクビになるのは上司だし、プログラムが動かなくても人類の存続には影響ないし。
顧客に怒られて反論出来ない場合の対処を教えようか？
「本当に困った振り」しとけばいいんだよ。
挑発に乗って無理したり、本気で気にしたりしたらダメ。
結局失敗してクビになるのは上司だし、プログラムが動かなくても人類の存続には影響ないし。
759 ：仕様書無しさん：2005/07/30(土) 14:14:23
そこまでいくと、今更だけど、
上司や営業者が安請け合いできないように、
事前に、ある程度できた段階で、
「ここから先は、〜の変更はできません」
と手を打っておかなければいけないのかね。
そのうえで、どうしても、と言う場合のために、未実装機能を盛り込んでおく、
また、あらかじめ、見積もりにそれを盛り込むことで、顧客も、あぁこういうところなら追加が効きそうだなと分かったりするし。
そこまでできれば、磐石な体制がつくれるんだろうけど。
また、マネージャなら、顧客にいきなり自らをすっとばされて、上司に要求されないようにコミュニケーションをしっかり計っていくとか。
万が一、そうなった場合も、上司に
「どうして、顧客から要求があったとき、確認せずに受けたんですか？」
と公式の場で、しっかり明言しておくことも必要だったのかも。
どれもこれも、いまさら何を、みたいになったけど、
人生完全に順風満帆なんて、そうそうあるもんじゃないよ。
落ちてははいあがり、落ちてははいあがりで、仕事としても人生としても充実させていく人間もいるんだしね。
それと、次の会社に行く時も、このデスマの失敗を次に繋げて、次は防ぐ為にこうしようと、明確に言えるようになれば、いいところも見つかるんだと思う。
上司や営業者が安請け合いできないように、
事前に、ある程度できた段階で、
「ここから先は、〜の変更はできません」
と手を打っておかなければいけないのかね。
そのうえで、どうしても、と言う場合のために、未実装機能を盛り込んでおく、
また、あらかじめ、見積もりにそれを盛り込むことで、顧客も、あぁこういうところなら追加が効きそうだなと分かったりするし。
そこまでできれば、磐石な体制がつくれるんだろうけど。
また、マネージャなら、顧客にいきなり自らをすっとばされて、上司に要求されないようにコミュニケーションをしっかり計っていくとか。
万が一、そうなった場合も、上司に
「どうして、顧客から要求があったとき、確認せずに受けたんですか？」
と公式の場で、しっかり明言しておくことも必要だったのかも。
どれもこれも、いまさら何を、みたいになったけど、
人生完全に順風満帆なんて、そうそうあるもんじゃないよ。
落ちてははいあがり、落ちてははいあがりで、仕事としても人生としても充実させていく人間もいるんだしね。
それと、次の会社に行く時も、このデスマの失敗を次に繋げて、次は防ぐ為にこうしようと、明確に言えるようになれば、いいところも見つかるんだと思う。
761 ：仕様書無しさん：2005/07/30(土) 18:58:02
762 ：756：2005/07/31(日) 01:19:21
ついにやってしまった。
俺が逃亡を誘った後輩が、このスレをテキスト保存してそれをメールに添付して
糞客に送ってしまった。
「大丈夫です。自分、もう失うものないですから！」
と言ってその事実を俺に打ち明けてくれた。先々の再就職に苦労するかもしれないが、
俺はその後輩との仲を一生の付き合いとして大切にしたいと思う。
でも、後輩のやった行為は、俺の糞上司への社会的引導になるであろう。奴にとっては
自業自得ということで、再就職不可能な年齢で修羅場を味わって欲しい。
来週の後半からオーストラリアへ後輩と遊びに行くことに決まった。その後のことは日本に
帰ってからゆっくりと考えよう。
独立もいいかもしれない。デスマ経験者だからこそできるITコンサルだってあるわけだしな。
それでは、このスレでは煙たがられてきたようなので、さらば。
皆さんの多幸を祈ります。
俺が逃亡を誘った後輩が、このスレをテキスト保存してそれをメールに添付して
糞客に送ってしまった。
「大丈夫です。自分、もう失うものないですから！」
と言ってその事実を俺に打ち明けてくれた。先々の再就職に苦労するかもしれないが、
俺はその後輩との仲を一生の付き合いとして大切にしたいと思う。
でも、後輩のやった行為は、俺の糞上司への社会的引導になるであろう。奴にとっては
自業自得ということで、再就職不可能な年齢で修羅場を味わって欲しい。
来週の後半からオーストラリアへ後輩と遊びに行くことに決まった。その後のことは日本に
帰ってからゆっくりと考えよう。
独立もいいかもしれない。デスマ経験者だからこそできるITコンサルだってあるわけだしな。
それでは、このスレでは煙たがられてきたようなので、さらば。
皆さんの多幸を祈ります。
763 ：仕様書無しさん：2005/07/31(日) 12:52:05
ネタかよwwww
ネタだよね。
これだけレスもらってるのに誰にも返してないし。
これだけレスもらってるのに誰にも返してないし。
つまらん。
途中までは良かったのにオチにリアリティーがなさ杉。
つまらんネタだ。
つまらんネタだ。
767 ：756：2005/07/31(日) 17:52:45
つまらん、つまらんって
ゆーーーな！
ゆーーーな！
会社名と顧客企業名と上司実名を晒せるかい
769 ：756の上司：2005/08/01(月) 22:55:56
コラー！765！
現場ほったらかして逃げんじゃねーぞ。
お客様もカンカンに怒ってるぞ！どーしてくれるんだ？お？
明日からお客様のところへ監禁される俺の盆休みはどうなるんだよ？
何とか言えよ。
全て全て全て全てお前が悪い。
憎んで憎んで憎んでも足りねーぞ。
現場ほったらかして逃げんじゃねーぞ。
お客様もカンカンに怒ってるぞ！どーしてくれるんだ？お？
明日からお客様のところへ監禁される俺の盆休みはどうなるんだよ？
何とか言えよ。
全て全て全て全てお前が悪い。
憎んで憎んで憎んでも足りねーぞ。
770 ：756：2005/08/12(金) 20:27:50
行って来たぞ。オーストレイリア！！２週間遊び放題。
一緒に行った後輩も元気に蘇った。旅先で遊んでる風景をデジカメに撮って、
毎日糞上司と糞客にメールで送り付けてやったんだ。１週間たったら糞客の担当が
メアド変えていやんの。プゲラ、プゲラ・・・
すっかり楽しんできたんで月曜は会社に手続きにいかなきゃなーー。
糞上司と糞客からのメールの返事をここに晒したい。極限の怒りを文章に表現したら
こんなになるんだろなあ（プゲラ）ってメールだったぞ。
俺ってハジケてるかーい？
一緒に行った後輩も元気に蘇った。旅先で遊んでる風景をデジカメに撮って、
毎日糞上司と糞客にメールで送り付けてやったんだ。１週間たったら糞客の担当が
メアド変えていやんの。プゲラ、プゲラ・・・
すっかり楽しんできたんで月曜は会社に手続きにいかなきゃなーー。
糞上司と糞客からのメールの返事をここに晒したい。極限の怒りを文章に表現したら
こんなになるんだろなあ（プゲラ）ってメールだったぞ。
俺ってハジケてるかーい？
ハローワークでは間違っても「プゲラ」とか言っちゃいけませんよ。
ﾌﾟｹﾞﾗ
>>770
I shall give you an aussie greeting: Good die!
I shall give you an aussie greeting: Good die!
要するに逃亡して、遊んだ、ってことね。
776 ：と○ ◆qCjTLcPX1U ：2005/12/01(木) 13:14:45
ITの仕事がしたくてここまで読んだんですが・・・。
どうやっていけばいいんだぁぁ。
卒業まで悩むとするか。今から先生と面談でつ
どうやっていけばいいんだぁぁ。
卒業まで悩むとするか。今から先生と面談でつ
E・∇・ﾖﾉｼ ＜777ｹﾞｯﾄ♪♪
零細企業のシステム系SE兼PGですが、来月から大手ベンダの人間としてPLを
やることになりました。
PLなんて初めてです。
やることになりました。
PLなんて初めてです。
PLがやっちゃいかんのはプログラミングだけだ
社外に出てPLやるならいろいろ気をつけて
783 ：仕様書無しさん：2006/03/32(土) 15:43:54
おれはコンピュータシステムのプロジェクト管理してんだ、
元大工や元運送配達を補充部員につれてくるんじゃねぇ
パソコン使ったことありますくらいでプログラマ認定するな
元大工は大工の仕事をしろ、元運送配達は宅急便配ってろ
うがーっ
786 ：仕様書無しさん：2006/04/21(金) 12:02:04
>778
どうなった？
どうなった？
787 ：仕様書無しさん：2006/04/21(金) 23:55:57
デスマーチ突入と見た。
能力がない上を持つと下は苦労する.....
能力がない上を持つと下は苦労する.....
>788
なげえ
要点をまとめてくれないか
なげえ
要点をまとめてくれないか
790 ：仕様書無しさん：2006/04/28(金) 15:08:48
仕事しない（ネットサーフィン、居眠り、長時間休憩）外注を
どうしたらいい？
どうしたらいい？
捨てれば？
仕事しない（ネットサーフィン、居眠り、長時間休憩）元請けを
どうしたらいい？
こちとら、全部丸投げされてるのに、連中は定時で帰りやがる。
どうしたらいい？
こちとら、全部丸投げされてるのに、連中は定時で帰りやがる。
>795
元請けからの金で給料貰ってるんだからしょうがないじゃん。
作業に支障をしたしているのなら文句を言えばいいだけ。
元請けからの金で給料貰ってるんだからしょうがないじゃん。
作業に支障をしたしているのなら文句を言えばいいだけ。
>>790
派遣からの安給でコキ使われてるんだからしょうがないじゃん。
作業に支障をしたしているのなら時給上げればいいだけ。
時給上げて責任自負させれば50％の社員が２倍以上の性能になる。
それでも仕事できなきゃ見合わないと諦めさせればいいだけ。納得してもらえる。
ライブラリ使いとかオープンソースの人とか色々来るのでマジでお勧め。
派遣からの安給でコキ使われてるんだからしょうがないじゃん。
作業に支障をしたしているのなら時給上げればいいだけ。
時給上げて責任自負させれば50％の社員が２倍以上の性能になる。
それでも仕事できなきゃ見合わないと諦めさせればいいだけ。納得してもらえる。
ライブラリ使いとかオープンソースの人とか色々来るのでマジでお勧め。
798 ：仕様書無しさん：2006/06/06(火) 17:53:34
来月から稼動の業務システムなんだけど、元請が到底使えないマスタデータを
そのまま持ってきやがる。データ形式とかはいいんだけど、業務の方が素人の
俺でも金額が合わない、品物が足りない、住所等のデータが入力されてないものばかり。
こんなんで俺にどうしろと。
そのまま持ってきやがる。データ形式とかはいいんだけど、業務の方が素人の
俺でも金額が合わない、品物が足りない、住所等のデータが入力されてないものばかり。
こんなんで俺にどうしろと。
799 ：仕様書無しさん：2006/06/06(火) 18:59:05
_ _
( ﾟ∀ﾟ)
( ∩ミ ﾃｨﾑﾎﾟ！ﾃｨﾑﾎﾟ！
| ωつ,ﾞ
し ⌒Ｊ
( ﾟ∀ﾟ)
( ∩ミ ﾃｨﾑﾎﾟ！ﾃｨﾑﾎﾟ！
| ωつ,ﾞ
し ⌒Ｊ
愚痴。
なんか知らないけどPMまがいのことやらされてる。
スケジュール組んだり、調整したり。
とりあえず、チームに著しくコミュニケーション能力の低い子がいてこまる。
39の女なんだが、さっきソースコードに変なところを見つけたから
「これって何でこうなってるの？ こうなるべきところを間違えてるの？それとも何か意図があるの？」
って普通に聞いただけなのに3分くらい沈黙した後、「すっ すいませんでした！」って言って
去って行った。
頼むから人並みにコミュニケーションしてくれ。
そして俺の月給、手取りで16.5万円
なんか知らないけどPMまがいのことやらされてる。
スケジュール組んだり、調整したり。
とりあえず、チームに著しくコミュニケーション能力の低い子がいてこまる。
39の女なんだが、さっきソースコードに変なところを見つけたから
「これって何でこうなってるの？ こうなるべきところを間違えてるの？それとも何か意図があるの？」
って普通に聞いただけなのに3分くらい沈黙した後、「すっ すいませんでした！」って言って
去って行った。
頼むから人並みにコミュニケーションしてくれ。
そして俺の月給、手取りで16.5万円
グチ。
なんか知らないけどうざい自称"リーダー"がいる。
「スケジュール組んだ」といっては作業のやり直しを命じ、朝令暮改がちゃめし事。
とりあえず、チームに頻繁に「コミュニケーション不足解消!」と称したジャマするのがこまる。
ついさっきも、リファクタリング途中のソースを見つけては、
「これって何でこうなってるの？ こうなるべきところを間違えてるの？それとも何か意図があるの？」
って沈黙して無視してたけど3分たっても解放してくれないので「すいません、用事を思い出しました！」って言って
その場から立ち去ってどうにか逃げ出せた。
頼むから作業に専念させてくれ。
そして何も価値を生まない奴にまで給料払ってるなんてつくづく慈善家揃いだなぁって思う。
なんか知らないけどうざい自称"リーダー"がいる。
「スケジュール組んだ」といっては作業のやり直しを命じ、朝令暮改がちゃめし事。
とりあえず、チームに頻繁に「コミュニケーション不足解消!」と称したジャマするのがこまる。
ついさっきも、リファクタリング途中のソースを見つけては、
「これって何でこうなってるの？ こうなるべきところを間違えてるの？それとも何か意図があるの？」
って沈黙して無視してたけど3分たっても解放してくれないので「すいません、用事を思い出しました！」って言って
その場から立ち去ってどうにか逃げ出せた。
頼むから作業に専念させてくれ。
そして何も価値を生まない奴にまで給料払ってるなんてつくづく慈善家揃いだなぁって思う。
>>802 自称リーダーっていうけどなー やりたくねーんだよー こんなの。
下っ端が一番楽だよ、下っ端になりてぇよ。
下っ端が一番楽だよ、下っ端になりてぇよ。
804 ：仕様書無しさん：2006/09/25(月) 21:32:37
age
すみません、うん百万規模の実質一人プロジェクトをやったおいらもPMを騙ってよいでつか？
807 ：仕様書無しさん：2006/10/23(月) 21:35:04
心配で心配で仕事にならねーのがPM。
心配事が無く仕事しねーのがSﾖ。