@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
お詫び
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-09-09 18:53
私の発言が不快と感じられた方々、どうもすみませんでした。
各位、私の発言を消してください。 [ メッセージ編集済み 編集者: samurai 編集日時 2005-09-10 12:40 ] [ メッセージ編集済み 編集者: samurai 編集日時 2005-09-10 12:47 ] [ メッセージ編集済み 編集者: samurai 編集日時 2005-09-10 12:48 ] | ||||||||||||
|
投稿日時: 2005-09-09 18:56
[ メッセージ編集済み 編集者: samurai 編集日時 2005-09-10 12:41 ] | ||||||||||||
|
投稿日時: 2005-09-09 19:07
どの会社が一番仕事が速いか競争させた場合のリスク管理はどのように考えていますか。 この場合に競争原理を持ってくると詐称、契約闘争などを管理、統制する為に必要な 管理側の工数負担が増加すると思いますが。 ドライに考えるならばこういう部分って絶対必要になると思ったので。 ドライにはドライで対応されますからねぇ〜。 (出来るだけ建設的なスレッドになれば良いなぁ〜) | ||||||||||||
|
投稿日時: 2005-09-09 19:32
[ メッセージ編集済み 編集者: samurai 編集日時 2005-09-10 12:41 ] | ||||||||||||
|
投稿日時: 2005-09-09 19:52
えっと・・・管理工数の増加を契約によって対応するのですか? 管理側の工数が増加すれば管理側のリソースを増やすのが常套な対応だと思いますが。 常套手段は効果があるので常套となります。 常套手段を外れた対応をして問題に対処するにはかなりの能力や特殊能力を必要とされると思いますが? それを用意する手段はいかがします? かなり難しい事だと愚考いたします。 また、話は変わりますが、 競争原理を用いた場合に協力会社側の人間への負担は増大します。 この事により、たださえ転職がしやすい業界であるソフトウェアで 人がやめた場合の人的リソースの補充手段を用意していらっしゃいますか? 経験上、辞めた人より能力がある人が来る事はまれだと思っています。 なぜならいわゆる出来る人というのはそれぞれの会社で出来る限り囲い込むという事をしてるからです。 XPなどの開発手法できちんと人として対応しようという標語(?うろ覚えですが)は伊達じゃなく、こういう現象を想定してのものだと認識しています。 また、こういった時に人的リソースを人材派遣会社などを用いる場合にもドライな対応をされると思われます。 この場合も先程と同じように相手の詐称などの対処をする為に普通の場合より工数が大きくなります。 なぜなら上で論じてるように競争原理を用いた場合には人的リソースの枯渇は慢性的に発生するので、つねに人不足の状態では詐称と分かっていてもとらざる得ない場合などが発生すると思われるからです。 長文・乱文失礼しました。 | ||||||||||||
|
投稿日時: 2005-09-09 19:53
加納正和、というものです。
コンピュータシステムで特に難しいとされるのが (1)インターフェイス縮退(とでもいうのか?) (2)システム評価 です。「形」なるものが建築業や法律家と違い固定できません。 本質的に相対するのは「顧客」や「ビジネス」なので、そもそもの 前提が変わります。 よって「純技術的」に言うなら以下の二つが状況に適合しません。 まず間違いなくそのシステムは開発終了する前に破棄されます。 >サブシステムごとに協力会社を分けて、 インターフェイス縮退、と勝手に名づけましたが、要はインターフェイスが 合わないってやつです。コンピュータシステムの場合、各サブシステム間 のインターフェイスは全システムから見渡した場合、変更される場合がありえます。 そもそもの設計がおかしい場合もありますが、それはないと仮定しても システムは状況によって形が変わります。例えば。 Aサブシステム 販売 Bサブシステム 仕分け などと分けた場合、経営陣が勝手に多品種を少量生産に変えるかも知れません。 そうすると契約後に販売と仕分けのインターフェイスが変わるとすると 「契約だから」ということで作ったAサブシステムは結局使えない、でも「A」を 作れといったじゃないか、ということで逆に作らせて大損するわけです。 >どの会社が一番仕事が速いか競争させる。 例えば1〜100まで足した計算結果を表示する「サブシステム仕様」があったとします。 ある会社Aが int a() { return 5050; } ある会社Bが int b() { for ( int = 1 ; i < 100 ; i++ ) { i += i; } } どういう意味でも「速い」(1行作成だし計算も速い。仕様も合ってる) のはA()関数です。が、真っ当にシステム評価を「すれば」、「速い」 に意味はありません。でもそれはシステムを評価すれば、という 「たら、れば」です。ビジネスでは「たら、れば」が出たら終わりです。 ということでA()会社ばかりが生き残り、さぁいざ仕様変更のときに どうしようもなくなるでしょう。 上記のは一行だから見れば分かるかもしれませんが、複雑な仕様だったら どうしますか?何を「評価」するおつもりで?行数?移植性?拡張性?保守性?性能? それとも営業の口約束かな? どれにせよ、ソフトウェア開発において一大テーマの「ソフトウェアメトリクス」 をそう簡単には導入できません。 「ソフトウェアメトリクス」を「真っ当に」導入できたところをほとんど見たことが ありません。 唯一、「真っ当」といえるのはバージョン5ぐらいなミドルウェアの簡単な機能追加 ぐらいですね。もちろん三年ぐらいかかって、ですが。 | ||||||||||||
|
投稿日時: 2005-09-09 21:02
また「類似品にご注意ください」な、スレですか。
消さないでくださいよ。
こういうことが許されるビジネスなんてないです。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||
|
投稿日時: 2005-09-09 23:43
どもです。がるです。
えっと…ちと引用前後しますが。
これはまぁいいと思うです。ってか、本来再契約ってのは Mustではないので、個人的にはむしろ「出来がよければ 再契約します」って方向性だと思っているのですが。 ただ、
この場合に複数の問題がありまして。 まず ・各サブシステムは「同じ能力の人間」なら「同じ速度で」出来上がるものなのか? (比較対照が異なればそもそも比較に意味がなくなります) ・速度以外の評価項目はないのか? (バグの有無からセキュリティ、保守性やら拡張性、 スケーラビリティにユーザビリティ等は全て無考慮なのか?) ってあたりがストレートに疑問です。 そのあたりを「協力会社(技術者)が納得できる基準」で判定する 手段ってのはお持ちなんでしょうか? あと。
とりあえず「協力会社を最大限に利用する」前に「やる気を そがない」ことが大切なのではないでしょうか? # っつか「利用する」って発想している時点ですでに # 赤信号が点滅しているような… |