C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[18]: 業界標準を作ろう! [2]


(過去ログ 39 を表示中)

[トピック内 55 記事 (41 - 55 表示)]  << 0 | 1 | 2 >>

■20376 / inTopicNo.41)  Re[6]: 業界標準を作ろう!
  
□投稿者/ シャノン (466回)-(2008/06/09(Mon) 23:29:14)
No20371 (シャノン さん) に返信

電気料金については(最近では石油価格がそうですが)寡占状態にあり、どれだけ高くとも言い値で買わざるを得ないという、極めて特殊な形態だと思います。
これをソフトウェア開発に持ち込むのは無理だろうなぁ。
引用返信 編集キー/
■20378 / inTopicNo.42)  Re[7]: 業界標準を作ろう!
□投稿者/ ネタ好き (413回)-(2008/06/09(Mon) 23:35:15)
No20376 (シャノン さん) に返信
確かにそうですね。電気料金は価格競争が無いから言値に近い状態ですね。
うーん。健全な価格競争がシステム開発にも行われて欲しいですね。
引用返信 編集キー/
■20403 / inTopicNo.43)  Re[8]: 業界標準を作ろう!
□投稿者/ ネタ好き (416回)-(2008/06/10(Tue) 14:09:45)
余暇にこの件を考えていました。
その空想の中で私は、価格.comのようなサイトを作り、公平なシステムアナリストが用意できればいけると思ったのですが、なにぶん「公平なシステムアナリスト」がいない気がしますorz
うーん難しい。適切な価格ってそもそも何なんだろう・・・
引用返信 編集キー/
■20410 / inTopicNo.44)  Re[9]: 業界標準を作ろう!
□投稿者/ 鶏唐揚 (184回)-(2008/06/10(Tue) 15:07:02)
いまさらログ読んで、名前呼ばれた気がするのでいまさらレス

No20403 (ネタ好き さん) に返信
>身近すぎて気付きませんでしたが鶏唐揚さんです
いあいあ、あれは企画が立ってから実践(ブログ開設)までに期間がかなりあったため
下調べの成果です。私自身はそこまでセンスよくありません。
劇的に異なる文法であればセンスの光どころですが、最近の似たり寄ったりな言語は
結局基礎がわかっていればあとは個別の特徴なりを覚えればなんとなく使えてしまうものです。
(その個別の特徴が大きすぎて壁となる場合も多々ありますが…)

あとはTry&Error!!だと思ってますw


で、本題
価格に関しては、業界標準を決めるのは非常に難しいと思います。

価格付けするための要素は様々で、単一(あるいは少数)の要素で価格を決め打ちするのはおそらくブーイングの嵐になると思いますw
というのも、同じようなソフトでも状況によって価値というものは変わってきます。
業界標準を決めると、その標準では価値を決めることのできない分野が必ず出てきます(ソフトウェア業界といったって様々な分野があるため)
かといって条件細分化すると結果的に複雑な取り決めとなって混乱が起き、理解不足による(意図的ではない)違反企業とかが出てきてしまいます。
あるいは、美味しい価格決定条件に認定されるよう、「表向き」条件を満たしているよう見せかけるような悪質な企業も出てきてしまうと思います。

また既出ですがパッケージソフトウェアなら、見た目・機能その他もろもろ価格を判断するための要素がある程度揃っていますが
受注ともなればどのような機能を要求されるかわからないため、たとえ「機能別価格表」なんかがあっても対応しきれないと思います。
まさに「見積もり」で工数や人手から算出するしか(現時点では)方法がないように思えます。

#機能オプション一覧表があり、その中の機能しか付けれませんというBTOのようなソフト受注方式なら
ある程度価格規定が作れそうですが。
引用返信 編集キー/
■20413 / inTopicNo.45)  Re[10]: 業界標準を作ろう!
□投稿者/ ネタ好き (417回)-(2008/06/10(Tue) 15:16:23)
そうなんですよね。私自身も言っておいてなんですが、非常に難しいと思っております。
しかし、良いコードと悪いコードがあるのも事実で、人月単価は明らかに間違いと言う事はみんなの同意を得られると思います。
やっぱり業界標準をするとなれば、C++国際標準規格の様な厳密なものでなくて、情報粒度によっては可能な気がします。例えば、損益分岐点を算出する機能は「正しい損益分岐点を出力する」と言う事は決まっているはずです。となれば、価値は「損益分岐点を出す価値」を基礎価格として、「速さ」「バッファーオーバーフローに対する耐性などのセキュリティ要件」、「コードの行数」、「使用したプログラム言語」、「動作環境」(メインフレームで動く、量子コンピューターで動くなど)が価格決定の要因になりうるのではないかと考えております。
そういう観点は無理なのでしょうか?
是非皆様のご意見を聞きたいです。

引用返信 編集キー/
■20436 / inTopicNo.46)  Re[11]: 業界標準を作ろう!
□投稿者/ こあら (8回)-(2008/06/10(Tue) 17:08:27)
こ:かつ丼1つ下さい。

店:3,000円になります。

こ:え゛っ?ちょ、高くね?

という程度には算出できるかもしれませんね。> 基礎価格


ソフトウェアは工業製品の域まで洗練されていません。
そして属人的な要素の方が大きいうちは「システムの価値」=「価格」という式は成り立たないと思います。

引用返信 編集キー/
■20441 / inTopicNo.47)  Re[11]: 業界標準を作ろう!
□投稿者/ シャノン (468回)-(2008/06/10(Tue) 17:28:53)
No20413 (ネタ好き さん) に返信

ネタ好きさんの主眼は「プログラマの評価」にあるように思われます。
そのため、「顧客の要望を如何にエレガントに満たすことが出来(る|た)か」によって高得点がつくのだと思います。
しかし、もう一方で、「顧客の要望を数字に直すと何点なのか」というのがないと、個々のプロジェクトの工数は出せないと思います。
そっちも頭の痛い問題です。
# って、前にどこかで誰かが絶対書いてるよな。
引用返信 編集キー/
■20450 / inTopicNo.48)  Re[12]: 業界標準を作ろう!
□投稿者/ ネタ好き (422回)-(2008/06/10(Tue) 18:11:56)
シャノンさんへ返信
その通りです。私自身このテーマを扱いきれてなくて、難しいので皆様と一緒に考えれば何か出てくると思って書いています。その際、技術者個人の評価と、商品そのものの単価が切り離させない話題なので私自身も戸惑っています。
技術者として評価が高くとも、お客様は商品しか興味が無いわけで、商品の品質でお金を支払います。
だけど、経営者としては評価が高い技術者に(多分)高い給与を支払うと思うのです。
それにフリーエンジニアとしては自分の価格を売り込みたいわけですし・・・
一番難しいのはどの粒度で価格を設定するかで、これさえ上手くいけば人月単価を捨て、お客が無茶な仕様変更してきても「相場から言って〇〇円追加」といいやすくなると思います。
これがデスマーチを防げるのではないかな?と考えております。
引用返信 編集キー/
■20469 / inTopicNo.49)  Re[13]: 業界標準を作ろう!
□投稿者/ ネタ好き (425回)-(2008/06/10(Tue) 23:15:33)
2008/06/10(Tue) 23:16:18 編集(投稿者)

みなさんご存知だと思いますが、ここ最近@ITで工事進行基準が連載されていますよね?
この方法一見いいように見えるし、今よりもこの業界がよくなるかもしれないと感じるのですが、
その一方で何か違和感があります。直感なので言葉で表しにくいのですが、一言で言うとお役所主義みたいになる恐れがあると思うのです。この連載を読んだ時から何か心にひっかかりを感じ、今さっきじゃんぬさんの「見える化」の現実を読んでやっぱり何かがおかしいと強く思いました。
皆様はこの工事進行基準が私達が今話し合っている業界の改善に繋がると思いますか?
引用返信 編集キー/
■20489 / inTopicNo.50)  Re[14]: 業界標準を作ろう!
□投稿者/ 中 博俊 (1回)-(2008/06/11(Wed) 09:59:44)
中 博俊 さんの Web サイト
すごくいいことですね。
ユーザは工事進行基準で支払いも実行すべきです。

何よりコストのかかり具合が会計上透明になるのはいいです。

引用返信 編集キー/
■20491 / inTopicNo.51)  Re[15]: 業界標準を作ろう!
□投稿者/ じゅで (34回)-(2008/06/11(Wed) 10:08:22)
> 何よりコストのかかり具合が会計上透明になるのはいいです。

ただ、システムの開発費が、仕様変更などに伴い、増減するので、
たとえば、100万のシステムで50万つかったら50%の進捗になりますが、
その後、仕様変更で200万に見積もりが変わると、50万だと進捗が25%になります。

なので、常に、見積もりを行っていきながら開発を進めるのも、
結構難しいところがあるかもしれません。

もっとも、仕様変更の取り込み時に、見積もりはやっているはずなので、
普通は、そんなに難しくはないですが、精度が求められるのが大変ですよね。
引用返信 編集キー/
■20504 / inTopicNo.52)  Re[16]: 業界標準を作ろう!
□投稿者/ ネタ好き (429回)-(2008/06/11(Wed) 11:33:22)
>何よりコストのかかり具合が会計上透明になるのはいいです。
確かにその通りです。

>もっとも、仕様変更の取り込み時に、見積もりはやっているはずなので、
>普通は、そんなに難しくはないですが、精度が求められるのが大変ですよね。
この意見もその通りだと思います。

二人とも有難う。お二人の意見を聞いて、あやふやな自分の意見もみえてきました。
工事進行基準で支払いが行われるのは凄くいいことです。これは進歩といえます。
しかし、私は精度の求め方のところが不安なのです。
じゃんぬさんの記事の例のように、精度を求める書類だけが華美にされ実態が疎かにならないか心配です。
皆さんはどう思いますか?
引用返信 編集キー/
■20507 / inTopicNo.53)  Re[17]: 業界標準を作ろう!
□投稿者/ じゅで (37回)-(2008/06/11(Wed) 12:04:18)
No20504 (ネタ好き さん) に返信
> じゃんぬさんの記事の例のように、精度を求める書類だけが華美にされ実態が疎かにならないか心配です。
> 皆さんはどう思いますか?

まったく同感です。
今現在の開発でもそういった事が多々あります。

そういった管理資料と実態が追いつかないのを、どう追いつかせるか。
または、どう無駄な資料を取り除くかが問題なのですが、
たいていは、お客さんからあれもこれもと、見もしない資料請求で
大変な事になります。

上の管理の人間が、その辺がわかっていないのか、どうにも書類を作る事が仕事の全てだと
思っているような人が居るので困ります。

上としては、見えないと評価が出来ないというのは、わかるのですがねぇ〜
引用返信 編集キー/
■20567 / inTopicNo.54)  Re[2]: 業界標準を作ろう!
□投稿者/ biac (1回)-(2008/06/12(Thu) 15:38:43)
biac さんの Web サイト
遅ればせながら、 最初のほうにレス f(^^;


No20280 (ネタ好き さん) に返信
> この業界の一番の問題点は私の勘違いかもしれませんが「単価や時間の標準が決定されていない」だと思うのです。

違う業界でも、 そんなものは聞いたことがないですよ。 f(^^;

・製造業
新製品の開発に掛る費用や時間の標準 --- ありません

・建築土木
クライアントが望むデザインで設計図を完成させるまでの費用や時間の標準 --- ありません
※ プレハブ住宅だとか、工法が決まってる注文住宅とかだと、会社ごとに持ってるようですが。

たとえば建築だと、 工事に入ってからは、 基礎の鉄筋 1本に何分、 壁の釘打ち 1平米あたり何分… といったような細かいレベルで、 業界としての標準時間が確立しているようです。
※ それこそ公共事業だと、 お国からこんなのが出てます。
http://www.mlit.go.jp/gobuild/kijun/touitukijyun/s_hyoujyun_bugakari.htm
> 公共建築工事標準単価積算基準

しかし、 それは僕たちの仕事で言えば、 コンパイル〜ビルドしている間のことです。
僕たちの仕事の大部分を占めている、 設計図を完成させる ( 設計しソースコードとして表現する ) までの部分については、 よその業界だって標準単価や標準時間は持ってないんです。
ちなみに、 建築・土木では総工費の X% が設計費、 というどんぶり勘定でやってるようです。

だからといって、 僕らもそんな標準は持たなくていい、 ってことじゃないですよ。
人月幾らの世界を変えるためにも、 そういう標準はぜひ欲しいところです。

ただ、 よその業界でもやったことがないことを、 僕らが先頭を切ってやらねばならん、 ってことです。
引用返信 編集キー/
■20580 / inTopicNo.55)  Re[18]: 業界標準を作ろう!
□投稿者/ ネタ好き (435回)-(2008/06/12(Thu) 16:45:08)
biacさんコメント有難うございます。他の業種でもそうなのですか・・・
でも我々は常に進化する情報処理技術を扱っています。
biacさんも仰っていますが、私達が先頭をきってやる事が出来ると思います。
引用返信 編集キー/

<前の20件
トピック内ページ移動 / << 0 | 1 | 2 >>

このトピックに書きこむ

過去ログには書き込み不可

管理者用

- Child Tree -