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

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

共通部品のせいでプロジェクトが破綻

1 :名無しさん:04/09/23 00:12:24
共通部品をきちんとつくらないで開発者毎に同じような機能のコードを
書いてるプロジェクトはだいたい成功するんだけど、
共通部品化が進んでるプロジェクトは共通部品を適用するのが面倒だったり、
共通部品ができるのが遅かったり、共通部品自体に致命的な欠陥があって
一部のエンジニアは分かってるんだけど、面倒くさくて黙ってることが多いので、
プロジェクトが破綻する場合が多い。
従って、共通部品化なんてしないで開発者毎にそれぞれ書かせた方がよいと思うけどどう思う?

2 :仕様書無しさん:04/09/23 00:17:49
破綻するのはお前のところだけじゃね?

3 :名無しさん:04/09/23 00:23:38
ぼくはいろんな会社のいろんなプロジェクトに参加したけど、
共通部品とかフレームワークの独自拡張とか、そういう部分を担当する班があるせいで
失敗してる場合が多い。
そういう班があると、その班にある程度優秀なエンジニアがいても、
完璧なバランス感覚を持ったエンジニアはなかなかいないもので、
その優秀なレベルがチャレンジングな共通部品を作ってしまったりして、
周囲のチームで理解できないエンジニアが発生してしまったりしてる場合もままあるし、
そういう班が作ったものに致命的な問題があったとしても、
まわりのチームがクレームをつけるメリットがなかったり、
どうせその班の責任になるので、問題を抱えたままプロジェクトが進行して
失敗してるケースがけっこうある。

4 :仕様書無しさん:04/09/23 00:26:30
共通部品をきちんとつくらないで開発者毎に同じような機能のコードを
そういう班があると、その班にある程度優秀なエンジニアがいても、
どうせその班の責任になるので、問題を抱えたままプロジェクトが進行して
まわりのチームがクレームをつけるメリットがなかったり、
共通部品ができるのが遅かったり、共通部品自体に致命的な欠陥があって
書いてるプロジェクトはだいたい成功するんだけど
一部のエンジニアは分かってるんだけど、面倒くさくて黙ってることが多いので、
破綻するのはお前のところだけじゃね?
ぼくはいろんな会社のいろんなプロジェクトに参加したけど、
共通部品化が進んでるプロジェクトは共通部品を適用するのが面倒だったり、
共通部品とかフレームワークの独自拡張とか、そういう部分を担当する班があるせいで
失敗してる場合が多い。
プロジェクトが破綻する場合が多い。
その優秀なレベルがチャレンジングな共通部品を作ってしまったりして、
従って、共通部品化なんてしないで開発者毎にそれぞれ書かせた方がよいと思うけどどう思う?
周囲のチームで理解できないエンジニアが発生してしまったりしてる場合もままあるし、
そういう班が作ったものに致命的な問題があったとしても、
完璧なバランス感覚を持ったエンジニアはなかなかいないもので、
失敗してるケースがけっこうある。

5 :仕様書無しさん:04/09/23 00:26:52
何が言いたいのかさっぱりわからん

6 :仕様書無しさん:04/09/23 00:30:01
とりあえず、お前がどうしようもないほどの能無しであることは解った。
国語を小学生から勉強し直せ。

7 :仕様書無しさん:04/09/23 00:30:52
>>1
この手の話題はアンチパターンの部類に入る。
クラスや関数単位のミニマムな部品の共通化はうまくいかない。
このパターンに陥るのは責任の分離の仕方が悪いことを示しているので、
モジュールなどの意味のある単体テストが可能な、
やや大きい単位に分割することで解決する場合がある。
まず最初にモジュール間のスタブやインターフェースを作成し、
各モジュールの開発は1〜2人の責任にしてやればうまくいく。


8 :仕様書無しさん:04/09/23 00:50:35
>従って、共通部品化なんてしないで開発者毎にそれぞれ書かせた方がよいと思うけどどう思う?

ならそう提案でもしたら良いじゃないか。
こんなところでぐだぐだ言ってないで。


9 :仕様書無しさん:04/09/23 00:54:28
>>1的な言葉で言う「共通部品班」の遅延とかなんたら・・・って何?
そんなのプロジェクト始動時にインターフェイス決めさせろよ。
こんなトコで愚痴るより建設的だろ。

10 :仕様書無しさん:04/09/23 01:03:42
>>7
ネタにマジレス。
1よ、もっとスパークしまくってくれ。
燃料が足りねーよ。

11 :仕様書無しさん:04/09/23 01:04:54
共通化と言っている割に視点が低すぎる(実装に近すぎる)ような…

12 :仕様書無しさん:04/09/23 01:40:44
>>1の知能が低過ぎるからだろう。

13 :仕様書無しさん:04/09/23 01:49:45
香ばしいな
共通部品もフレームワークも無しで作るのか
北の国からみたいでいいな
がんばれよ















おれはやだけど

14 :仕様書無しさん:04/09/23 02:00:30
共通化しないのなら、

言語から、OS から、マシン部品から、開発者毎にやったらどうだ?

などと言ってみる。

15 :仕様書無しさん:04/09/23 02:41:59
PMとか上の奴、基本設計の奴が、突如
「そうだ、共通部品つくるだろ、おまえ(実装担当)作れよ」
と口だしするんだよな。
「それは、無理でちょ、基本設計の段階でキチンと機能洗い出ししないと」
「じゃー、おまえ何すんだよ。」
てな状況にはよくなるな。



16 :仕様書無しさん:04/09/23 03:41:38
プロジェクトに関係しない共通部品なら作れるだろ。
基本設計どころか計画すらないプロジェクトをも
対象にした部品なんだから。

17 :仕様書無しさん:04/09/23 04:03:16
>>1
関係しないと言っても、
それを喜んで使う奴はいないんじゃないかな。
ライブラリの様なある程度信頼のおけるもの以外除き、
基本的に他人の即席ルーチンは気持ち悪いもんだし。
数キロステップ程度のライブラリなら無視しても
仕様の把握とかで相殺して効率あまり変わらないし。
プログラマに強制はよくないよ
年期のある人程

18 :仕様書無しさん:04/09/23 04:03:55
すまん>>16

19 :仕様書無しさん:04/09/23 09:54:12
スキルやモラルの低い人が多い場合、共通部品やフレームワークなど作らず、
各自勝手にやらせたほうが「マシ」ということは多い。

20 :仕様書無しさん:04/09/23 09:56:24
>>17
「即席ルーチン」なら積極的に使う気には確かになれんが、それを前提にした話じゃないだろ。
部品の強制はよくないというが、似たようなコードがあちこちにあることこそよくないことじゃないのか。

21 :名無しさん:04/09/23 10:23:19
どんなプロジェクトでも使えそうな共通部品を通常のギャラで作るのはもったいない。
優秀なエンジニアならそんなものは自分のビジネスのために作るはずだ。
従って、やはり、共通部品などなしでやった方がお互いに良い結果になる。

22 :仕様書無しさん:04/09/23 10:26:34
オブジェクト指向でむけ

23 :仕様書無しさん:04/09/23 10:31:10
共通部品化の問題というより、
>>1の職場の開発力や意思疎通の問題ではないか

24 :仕様書無しさん:04/09/23 11:06:22
>>21
共通部品無しが良い理由が生産性等ではなくギャラですか?
素晴らしく分かりやすい論理のすり替えですねw

25 :仕様書無しさん:04/09/23 11:17:02
共通部品を作ろうとしない所は見積もりが甘いね。

見積もりの単位が部品ではなくて、アプリ(実行ファイル)とか
画面とかになっているから、どうしても大まかな見積もりしか出来ない。

一つのアプリや画面をさらに細分化して見積もりをすればより正確になるし、
そうすると自然と共通部品を作るようになる。

26 :仕様書無しさん:04/09/23 11:18:10
>>21 に同意。
論理だけで実務はできん。

27 :仕様書無しさん:04/09/23 11:21:10
そして、細分化した見積もりということを考えないで
今まで通りの見積もりのやり方で、共通部品を作ろうとするから
共通部品にかかる費用を正しく見積もることが出来ず、
どこにどれだけの費用をかけるかがずれてきて見積もりの
コントロールが出来なくなり、プロジェクトが破綻する。

ついでにギャラが適切に払われなくなったりする。
ちゃんと見積もりをしろと。

28 :仕様書無しさん:04/09/23 11:22:47
>>26
どうせ自演だろ。わざとらしい。
>>21には共通部品が悪いということが一つも書かれていない。
これに同意するのは自演か真性馬鹿。

29 :仕様書無しさん:04/09/23 11:34:13
共通部品と入っても、次に使うときにそのまま使えることはめったにない。
ほとんど機能を追加して使うことになる。どんどん追加して、最初の使い方も
残しておかねばならないし、そんなことなら改造してその場限りの使い捨ての
方がよい。

30 :仕様書無しさん:04/09/23 11:37:58
ほとんど機能を追加して使うことになる・・・から共通部品の方がいいんだろ。
各人バラバラに作っていたら追加する機能までバラバラになる。

と釣りにマジレス。プゲラ



31 :仕様書無しさん:04/09/23 11:39:58
共通部品はCOMがお勧め
そうすると>>29な奴を強制排除可能

32 :仕様書無しさん:04/09/23 11:47:11
別にCOM以外でもなんでもいいと思うが。
まあ共通部品が有効って点では意見は同じようなので
これ以上深く突っ込まないが。

33 :仕様書無しさん:04/09/23 11:52:48
エクストリームでむけ

34 :仕様書無しさん:04/09/23 13:09:07
あるプロジェクトがあった。
共通部品のリーダーは院卒の若造だった。

メンバーの害虫を馬鹿にしまくっていた。

契約更新の時期が来た。
害虫は皆、他のプロジェクトに逃げた。

そして、誰も使わない共通部品とリーダーだけが残った。

35 :仕様書無しさん:04/09/23 13:14:50
なんだ低学歴の僻みスレか

36 :仕様書無しさん:04/09/23 15:17:31
>>34-35
自演乙

37 :仕様書無しさん:04/09/23 16:11:19
>>34
あるプロジェクトがあった。
院卒の若造がXPを提案した。


とかいろんな応用が利きそうだなw



38 :仕様書無しさん:04/09/23 17:38:10
>>37
この業界の院卒は生きる価値無しという結論でOK?
専門卒の方が優秀じゃね?この業界だと

39 :仕様書無しさん:04/09/23 17:45:24
専門卒の方が優秀じゃね?この業界だと
専門卒の方が優秀じゃね?この業界だと
専門卒の方が優秀じゃね?この業界だと
専門卒の方が優秀じゃね?この業界だと


40 :仕様書無しさん:04/09/23 17:47:52
>>37は学歴コンプレックスを皮肉った書き込みだということも読み取れない奴がいるのか

41 :仕様書無しさん:04/09/23 18:02:30
>>38の言ってるのはコーダ業界のことじゃないかな


42 :仕様書無しさん:04/09/23 18:11:44
引率PGって時点で負け組だろ

43 :仕様書無しさん:04/09/23 18:15:18
業務系ならな

44 :仕様書無しさん:04/09/23 18:21:48
そうかなー、うちの会社には院卒が何人かいるけど、
どいつも理屈ばっかりで使えないよ?
専門卒の方が素直に仕事をするというか、
設計や分析でも専門卒の方が院卒よりも優秀だと思うよ

45 :アホが使うテンプレート!!!:04/09/23 18:25:09
俺の知り合いの○○は
俺の知り合いの□□より使える。

使用例)
俺の知り合いの高卒は
俺の知り合いの大卒より使える。



46 :仕様書無しさん:04/09/23 18:28:25
自分よりレベルの低い香具師には、なかなか従えんからな。

47 :仕様書無しさん:04/09/23 20:15:40
うちのプロジェクトの共通部品チームでは、
完成していない共通部品を「完成した」とか言っている
で、実装した後で仕様変わったとか言ってきやがる
あふぉ

48 :Do:04/09/23 22:54:00
たった3行のソースなのに部品化されていた!!
最悪は部品から部品が呼び出され、追っていくと最後には
元の部品に戻った!!「なんじゃこりゃー」
※即この部品群を自プロジェクトで使用するのを強制的に
 禁止!社内からは冷たい目で見られたが、プロジェクト
 は無事期限内に終了。「怖かったぞ」


49 :仕様書無しさん:04/09/23 22:56:31
言うまでも無いが、それは部品化が悪いのではなく、
単にその部品がわるいだけ。

50 :仕様書無しさん:04/09/23 23:02:20
いや、一番悪いのは、たかが再帰呼び出しを一回使ったぐらいで
「なんじゃこりゃー」
なんて言われてしまう会社に入ってしまった
>>48 のコードを書いた奴の先見の明のなさと思われ。


51 :仕様書無しさん:04/09/23 23:04:21
部品作り直した方が早くね?
他のプロジェクトでも使えるんだろうし。

52 :51:04/09/23 23:12:20
>>50
なるほど。そういうことなら、前言撤回。
仕様通り動いてるなら、下手に手を加えるのは×だな。

53 :仕様書無しさん:04/09/23 23:14:33
>>52
リファクタリング

54 :仕様書無しさん:04/09/24 05:15:06
>>53
リリースした共通部品の話だろ
リリース後の改変はリファクタリングとは言わない

共通部品のソースを見ようとする事自体、間違い
共通部品は機能だけ理解すればよろしい、何の為の共通部品か
何の為のオブジェクト指向か

55 :仕様書無しさん:04/09/24 05:17:50
出来が悪いとそうも行かない場合があって困るね。

56 :仕様書無しさん:04/09/24 10:18:35
>リリース後の改変はリファクタリングとは言わない

まじっすか?

57 :仕様書無しさん:04/09/24 11:19:25
リファクタリング 【refactoring】
読み方 : リファクタリング

 プログラムの振る舞いを変えることなくソースコードを変更すること。


58 :仕様書無しさん:04/09/24 11:32:01
54が窮地に追い込まれました

59 :仕様書無しさん:04/09/24 11:57:34
> リリース後の改変はリファクタリングとは言わない
合ってると思うよ。
リファクタリングなのに改変したら駄目でしょ。

60 :仕様書無しさん:04/09/24 12:16:03
ポイントはそこではないと思われw


61 :仕様書無しさん:04/09/24 18:08:29
リリースした後ソースを修正も改造も見る必要も無いのなら
誰も文句は言わないんですよ。

文句を言っているということは、すなわちソースを編集する
必要があるということ。そして再リリースする必要があるということ。
(再)リリース前なのでリファクタリングで間違いない。

62 :仕様書無しさん:04/09/24 18:59:19
リファクタリングの話題はスレ違い

ここはそれ以前の話

63 :仕様書無しさん:04/09/24 19:06:38
要は…>>1は無能てことでしょ?
そうとしか思えない。

64 :仕様書無しさん:04/09/24 19:11:28
ここは1の職場を叩き直すスレに早変わりしました

  r;;;;;ノヾ
  ヒ =r=;'
  ヽ二/
    ⊂彡☆))Д´) >>1

65 :仕様書無しさん:04/09/25 12:40:59
部品を作るのは開発時のみならず、再利用とか保守のための方が主眼なんだが。

66 :仕様書無しさん:04/09/25 12:44:07
>>1の会社って共通ライブラリってわりに独立してなかったり、
全然ロジックがクソだっただけじゃねーのか?
オブジェクト指向言語が登場してから、より一層ライブラリ化は薦めたいのだが。

67 :66:04/09/25 12:47:30
っていうのは、漏れも上位会社の作ったクソライブラリが、
クソみたいなソースで使えなくて、デスマったことがあった。
何か、共通ライブラリなのに、お互いのモジュールを意識してんのよ(w
何のためにライブラリ化してあんだ??

68 :仕様書無しさん:04/09/25 12:54:33
うーん、よくある(笑)
”このモジュールを呼ぶ前に必ずfuncB()が呼ばれていること”
って、なんじゃそりゃーーー!

69 :66:04/09/25 13:06:19
>>68
よくあっちゃいけないことなんですけどね。
痛い会社(PG)は痛いものでして...
だから、>1もそういう目にばかり遭ってるからの意見なのかと思うと、同情したくなるなぁ。

>>65
同意。そういう意味でも独立してなきゃいけないんだよね。
その機能だけ欲しければ1FileコピればOKなように。

70 :仕様書無しさん:04/09/25 13:11:34
>>68
それに関してだけ言えば、あるメソッドを呼ぶ前には別なメソッドを呼ぶ必要があるケースは
普通にあるだろ?

71 :仕様書無しさん:04/09/25 13:29:04
>>70
多分その「別なメソッド」が、ユニークに対応できないケースを言ってると思われ。

72 :仕様書無しさん:04/09/25 15:01:42
>>70
一般的にあるツール郡を使用する為に初期化として1つだけ呼ぶ場合は多いが。
1つの機能のために1つの初期化や設定があってたら、それは共通部品としては
失格に当たるな。
ただし、通信系はその性質上、その様な物はある。

73 :仕様書無しさん:04/09/26 00:17:12
まあfreadの前にはfopen参照するわな。
ただ>>68みたいに部品間のIFが明白で無いのはダメダメだ

74 :仕様書無しさん:04/09/26 02:51:04
>共通部品を適用するのが面倒

適用するな


>共通部品ができるのが遅かったり

待つな


>共通部品自体に致命的な欠陥

三菱かよ(w


どーも試作と量産の区別がついてないヨーダな

75 :仕様書無しさん:04/09/26 12:12:15
共通部品部隊のリーダーが出社拒否になってプロジェクトの進行がメチャクチャになったです


76 :仕様書無しさん:04/09/26 13:02:15
>>75
それ原因は共通化部品とはぜんぜん関係が無い。
人事管理の問題で、共通化部品でなくとも重要な部分の担当者が仕事しなければ
小さいプロジェクトは大変になる。
しかしそれも規模が小さいか、その人以外が無能である時もそうなる。
大規模でしっかり管理されていれば、誰が抜けても影響は少ない。
誰が抜けてもまったく影響の無いプロジェクトをやっていると、
つくづく自分がただのサラリーマンだと自覚するよ。

77 :仕様書無しさん:04/09/26 13:09:59
サラリーマンでも有能な奴は重要な仕事をまかされるけどな

78 :仕様書無しさん:04/09/26 13:12:05
>>77よ、どんな重要な事をやっても、何時居なくなってもOKな
プロジェクトをやった事が無いだろ。w

79 :仕様書無しさん:04/09/26 13:23:33
>>78は日本語勉強中ですか?

80 :仕様書無しさん:04/09/26 13:25:35
つまらんレスだな、ガッカリなので漏れは終わる。

81 :仕様書無しさん:04/09/26 14:26:53
>>78
77ではないが、ない。
かけ声は立派でも、実際そうである所にお目にかかった事はない。
にわかには信じがたい。
実は「重要なことをやってる」つもりなだけなのではないかと(ry

82 :仕様書無しさん:04/09/26 14:32:56
>>81
かけ声ではないが実際にある。が。
>実は「重要なことをやってる」つもりなだけなのではないかと(ry
こんなひねくれた事を言う奴に説明するつもりは無い。
悪いが自分だけを見て、誰が居なくなっても問題ないと判断できると
思っているのか小1時(ry

83 :仕様書無しさん:04/09/26 14:47:24
抜けられても全然困らない人はいる。
抜けられると非常に困る人もいる。←これはこれで困ったちゃん
私が抜けるとプロジェクトが困るかどうかは、自分では判断できない。

84 :仕様書無しさん:04/09/26 14:51:37
プロジェクト全体を人も含めて見渡す事ができれば、
誰が抜けたらどのような事が起こるかの判断が出来る。
また、自分が抜けた場合どのような迷惑が掛かるかも判断できなければ
プロとは言えない、>>83は素人。

85 :仕様書無しさん:04/09/26 14:56:04
プッ
おまえの方がよっぽど素人だろ
相手してやれば、何か出てくるかと思えば、その程度か

86 :仕様書無しさん:04/09/26 14:57:49
自分が抜けるとどういう影響があるかすらわからないようなやつは、抜けたところで
困らないだろうな。
というか、抜けて欲しいと思われてるだろうなw

87 :仕様書無しさん:04/09/26 14:58:12
なんだかんだで>>1に能力がないだけの話だな。

88 :仕様書無しさん:04/09/26 14:58:31
またそれかよ、つまらん奴だな、そんなに教えてもらえないのが寂しいのか?
しかし、漏れはもう完全に止めにする。一人で考えな。

89 :仕様書無しさん:04/09/26 15:00:39
>>88>>85へのレスです。

90 :仕様書無しさん:04/09/26 15:01:36
誰が何を教えてもらいたいと思ってるんだろう?
ただの誤爆?

91 :仕様書無しさん:04/09/26 15:03:29
「重要」と「困難」を混同してる奴がいるなw
抜けられると困るのは、同一水準以上の人間がなかなか見つからないからだろ。
作業の属人性を解消出来ないのは、品質管理が不充分なのが原因さ

92 :仕様書無しさん:04/09/26 15:48:35
まぁ、抜けられて迷惑なのと、抜けられて困るのでは、随分と意味は違うがな

迷惑と言われる奴の場合、本心は抜けて欲しいと思われてる奴だと思うんだが

93 :仕様書無しさん:04/09/26 16:59:19
マ板でプロジェクト管理がどーのこーの言ってもな

94 :仕様書無しさん:04/09/26 17:00:32
テスト部隊のバイトが出社拒否になってもプロジェクトの進行はあんま変わんなかったです

95 :仕様書無しさん:04/09/26 17:01:15
>>94
それ原因は共通化部品とはぜんぜん関係が無い。
人事管理の問題で、共通化部品でなくとも重要な部分の担当者が仕事しなければ
小さいプロジェクトは大変になる。
しかしそれも規模が小さいか、その人以外が無能である時もそうなる。
大規模でしっかり管理されていれば、誰が抜けても影響は少ない。
誰が抜けてもまったく影響の無いプロジェクトをやっていると、
つくづく自分がただのサラリーマンだと自覚するよ。

96 :仕様書無しさん:04/09/26 17:19:41
サラリーマンでも有能な奴は重要な仕事をまかされるけどな


97 :仕様書無しさん:04/09/27 01:06:03
>>96よ、どんな重要な事をやっても、何時居なくなってもOKな
プロジェクトをやった事が無いだろ。w

98 :仕様書無しさん:04/09/27 09:37:53
ところで
>プロジェクトをやった事が無いだろ。w
って面白い言い方だね。仕事で開発をするなら、殆どがプロジェクトであるはずなのだが。

99 :仕様書無しさん:04/09/27 10:14:26
適当なプロジェクトも経験していたほうが良いぞ。
良い感じに人生にも仕事にも諦めらめがつくからw
まあ、二・三年にいちどは大きな仕事もしたほうが良い。
そうでないと今度は逆にぬるま湯に慣れきり、
チャンスが来ても動けなくなってしまうからw

100 :仕様書無しさん:04/09/27 10:19:03
>>98
よく読め。「何時居なくなってもOKな」プロジェクトだろ。

脊髄反応恥ずかしいw

101 :仕様書無しさん:04/09/27 10:34:23
>>98-100
20ほどさかのぼってスレ読んでみろ

脊髄反応恥ずかしいw

102 :仕様書無しさん:04/09/27 10:40:02
おまいら、バカばかりですか??

103 :仕様書無しさん:04/09/27 11:05:44
共通化できるレスの塊があるな

104 :仕様書無しさん:04/09/27 11:37:10
つまらんレスだな、ガッカリなので漏れは終わる。

105 :仕様書無しさん:04/09/27 11:42:46
>>103
お前最高。

106 :仕様書無しさん:04/09/27 12:48:24
プロジェクト全員でメンバーの中の唯一の女性を共通化しました。
つまり全員穴兄弟。

107 :仕様書無しさん:04/09/27 12:54:17
>>106
で、その共通部品の品質が悪くてプロジェクトは破綻したわけだ

108 :仕様書無しさん:04/09/27 12:55:18
>>106
ファイアーエムブレム 聖戦の系譜ごっこは外でやんな。

109 :仕様書無しさん:04/09/27 13:46:57
>>106
その娘が病気持ちで全員ウィルス感染w。

110 :仕様書無しさん:04/09/27 14:20:38
>>109

×その娘が病気持ちで全員ウィルス感染w。
       ↓
○その娘がラクチェで流星剣で皆殺しw。

111 :仕様書無しさん:04/09/27 15:08:03
何このスレ。底辺の人間が戯れると気持ち悪い。

112 :仕様書無しさん:04/09/27 16:19:01
>>111
で、そういうことを我慢できずにレスしちゃう、お前が1番底辺っぽいんだがな。

113 :仕様書無しさん:04/09/27 22:48:56
皆、似たようなものだろ。気にするな。
下から一番目も二番目も底辺には変わりない。

114 :仕様書無しさん:04/09/28 01:21:11
>>113
それ問題は底辺とはぜんぜん関係が無い。
人事管理の問題で、底辺でなくとも重要な部分の長さが仕事しなければ
小さいプロジェクトは大変になる。
しかしそれも上辺が小さいか、その人以外が対角線である時もそうなる。
面積でしっかり管理されていれば、誰が抜けても影響は少ない。
誰が抜けてもまったく影響の無いプロジェクトをやっていると、
つくづく自分がただのサラリーマンだと自覚するよ。

115 :仕様書無しさん:04/09/28 08:59:44
サラリーマンでも有能な奴は重要な仕事をまかされるけどな

116 :仕様書無しさん:04/09/28 09:04:23
職業なんて今の世の中関係無いんだよ。
ひとくくりにできないんだから、でも皆くくりたがるね。
安心できるからだろうけど。日本は不況と言っても、
同時に儲けている会社はそれなりにある。
同じ職業でも昔に比べれば上と下でものすごい差がある。
「自分は」で答えないといけないのに。
「給料どれくらい?」「普通だよ」は、
本当にただの社交辞令になってしまった。
以前なら相手の職業と肩書きと能力でだいたい予想できたのが、
今は自分と同じくらいだと思ってたら倍以上あったり、
全然違うからね。これからの子供はそれが当たり前だから良いけど、
変わり目にあたったおじさん世代には辛いですな。

117 :仕様書無しさん:04/09/28 10:44:39
何でこのスレは急に延びたのだ?

118 :仕様書無しさん:04/09/28 11:02:38
成長期なんだろ。

119 :仕様書無しさん:04/09/28 12:10:06
成長なんてしたくないよ。
このまま時が止まれば良いのに。

120 :仕様書無しさん:04/09/28 12:20:39
>>119
君自身の時ならとめられるんじゃないw

121 :仕様書無しさん:04/09/28 12:22:57
座・ワールド

122 :仕様書無しさん:04/09/28 12:29:41
なるほど ・ >>121

123 :仕様書無しさん:04/09/28 17:21:43
それにしても「共通部品」という言い方がなんとも。

124 :仕様書無しさん:04/09/28 17:53:31
部品と呼ぶなら当然、共通であるはず
という意味かな

125 :名無しさん:04/10/02 09:35:41
同じような機能を別の人がそれぞれコーディングしても全然問題ない。
なぜなら、運用に入ってから修正依頼が来て修正する場合、それらは別の機能なので、
別々に修正して別々にテストするからだ。寧ろ、共通化などされていない方が修正しやすい。
もし共通化されていたら、他の部分に影響するとまずいので迂回するように共通化を崩さないといけない。
このように業務システムにおける共通部品は開発時点における一部のエンジニアによる感覚で
共通化されたものが多く、運用後の修正を意識したユーザーの視点から見た共通化ではない場合がほとんどだ。
従って、共通化などやはりしない方が良い。

126 :仕様書無しさん:04/10/02 09:54:24
>>125
>なぜなら、運用に入ってから修正依頼が来て修正する場合、それらは別の機能なので、
>別々に修正して別々にテストするからだ。寧ろ、共通化などされていない方が修正しやすい。

お前の様な考え方を持った人間って、
もし買ったズボンが自分の丈に合っていなかった時なんかでも
そのズボンを作った会社全体の構造改革をしそうだな。

何故、丈を詰める事を考えないんだ?


127 :仕様書無しさん:04/10/02 10:07:23
>>126
125ではないが、それを全面否定する気にはなれないです。
ズボンの丈の問題なんかは実際にそんな事をしている所もあります。
ユニクロなどかそうなのですが、全部の丈を揃えて、流通パワーで解決する。
これにより各店舗での丈の修正を省いてコストダウンを図るという方法もあります。

何処に巨大コストがあるかというの考えずに、共通化することそのものを目的にすると問題を引き起こす事があります。
あくまで殆どのケースで通じるという事であって、全部のケースに通じる銀の弾丸はありません。
宗教化は良くないです。

128 :仕様書無しさん:04/10/02 10:26:06
>他の部分に影響するとまずいので迂回するように共通化を崩さないといけない。
こうして同じ様なモジュールを大量に生産した挙句、システムがメンテ不能になっていくわけだが。
プロジェクト毎の仕様変更で共通化を維持できなくなるのは、共通部品の設計が悪いせい。

129 :仕様書無しさん:04/10/02 10:30:24
>>127
>>125 の話って、全部の丈を揃えて、流通パワーで解決しようとした
ユニクロで働いている店員が、客に丈を詰めろとせがまれて
「やっぱり服は"オートクチュール"じゃなきゃ駄目だね」
ってぼやいている様なものだと思うが?


130 :仕様書無しさん:04/10/02 10:32:49
そりゃ
>一部のエンジニアによる感覚で共通化されたものが多く
ならそういうことになるわな。
そんな共通部品を作る方が間違ってるんだが。


131 :仕様書無しさん:04/10/02 10:35:09
>>128
>こうして同じ様なモジュールを大量に生産した挙句、システムがメンテ不能になっていくわけだが。

それがシステムのライフサイクルであり、
システムの寿命なのです。

最近の若い人にはそれが分からんのです。


132 :131:04/10/02 10:44:33
そして、そのような開発スタイルこそが、
最近はやりの「あーじゃいる」というものであり、
既に我らCOBOLerが長年実践してきた開発方法なのです。


133 :仕様書無しさん:04/10/02 12:14:35
馬鹿か。寿命は延ばすもんだろ。
糞システムを作って寿命を短くしてそれが当然?
アフォアフォアフォ。
寿命をできるだけ長くして、それでも限界がきたときが本当の寿命。


134 :仕様書無しさん:04/10/02 12:47:33
システムなんてものは、本質的に「使い捨て」なのです。
ダイソーの100円ショップの品と同じです。
最初の1,2回使えれば客は文句を言わないものです。

綻びが出てきたら、直ぐに新たなシステムを売り込むのです。


135 :仕様書無しさん:04/10/02 12:51:31
いまも動いている最古のコードってなんだろう?
IBM汎用機のOS?UNIXカーネル?
・・・いや、ソフトの寿命が決定されるに当たって、
「コードの質」と「プログラムの実行される環境」のどちらの影響が大きいのかな
とふと思ったもので。

136 :仕様書無しさん:04/10/02 12:52:33
>>133
アホダナァ。
ソフトウェアはあくまでビジネス・生活・研究・娯楽の道具。
道具として役に立たなくなったときが寿命。

137 :134:04/10/02 12:56:54
なぜならば、「製品の寿命」等という項目は、
仕様書に書かれていないからです。

共通化なんぞに頭を使わない。
手を抜くべきところはトコトン手を抜く。

これこそが、「あーじゃいる」であり、
ひいては顧客満足度を上げる結果に繋がるのです。


138 :仕様書無しさん:04/10/02 13:33:53
アージャイルに関して変なイメージを植え付けようと必死ですねw

139 :仕様書無しさん:04/10/04 11:06:59
>125の会社ではDBへアクセスなんかの部分も各個人が好きに書いていそうだな。
DBユーザ名が変更になっただけで修正が数十箇所に及びそうで楽しげw

140 :仕様書無しさん:04/10/04 18:36:29
>>139
その分、客からしっかり
お金を貰うから無問題。


141 :仕様書無しさん:04/10/04 21:22:32
いや「そのぶんしっかりお金をもらっておきながら、直すのは1箇所」
であるのが美味しい。

142 :仕様書無しさん:04/10/04 22:10:05
>>141
それでは営業が勝手に値引きしてしまいます。


143 :仕様書無しさん:04/10/09 01:12:53
>>142
PGは忙しい振りして内職でもしてれば?
どうせちょっとソース見ただけじゃわからないだろうからばれないよ。

144 :仕様書無しさん:04/10/09 07:55:22
>>143
そうすると上司が
「なんでそんなに忙しいんだ!共通化して生産性を上げる努力をしろ!」と言います。


145 :仕様書無しさん:04/10/09 11:11:31
それ原因は共通化部品とはぜんぜん関係が無い。
人事管理の問題で、共通化部品でなくとも重要な部分の上司が仕事しなければ
小さい会社は大変になる。
しかしそれも規模が小さいか、その人以外が無能である時もそうなる。
大規模でしっかり管理されていれば、上司が抜けても影響は少ない。
上司が抜けてもまったく影響の無い会社でやっていると、
つくづく自分がただのサラリーマンだと自覚するよ。


146 :仕様書無しさん:04/10/10 22:04:53
>>960
サラリーマンでも有能な奴は重要な仕事をまかされるけどな

147 :名無し:04/12/18 21:18:48
>>1-146 >>148-1000

         ,.. -──- ..,_
        /        \_
      /`'ー─-、-─'''二二__ヽ
     |´ _ニ-‐´ ̄ __   |
      |´  __ニ二..,,,,__ ̄ ̄}
ヽ`'ニ-、_レ' ̄   ‐、 /    ̄ヽ{_,.-‐'´/
 `l  `ヽ'‐'T'‐- _ |  _ -‐-、__/ /! /
  `l,  <.| l____・>‐<・___/ .//  /       きさまら 死ねや
   `l、 ヽ|   -‐´ |、`‐-  ./ | / 
    `l_|     lノ    /_,.‐'´
       l'、.  ´ ̄`   /´
      /\___ ,... /、`\
     / __     /´>  )
     (___)   / (_/
      |       /
      |  /\ \
      | /    )  )  
      ∪    (  \
            \_)

デフォルメ ピーコロ
名無しさん(ピッコロ)


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

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

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