素晴らしい問題提起だと思います。
人月単価は本当に非合理的な方式だと思います。
私もこの業界に入ってから直ぐにこの問題に疑問を持ち、自営業になってからは商品価値でシステムを販売するようにしております。
価格の決め方はお客様と話し合い、その都度決めております。
その際には、合理的根拠を示して価格を提示していますので、値引き交渉はあるものの、おおむね納得してもらえています。
価格交渉は非常に骨が折れますが、それ故にお客様の満足度も高くなるのでやりがいがあります。
人月単価とは違い、価格交渉は定まった計算式がありませんが、それはオーダーメイドだから当たり前の事だと思います。
その「当たり前」を経営的に行うのが難しいのでしょう。
実際に組織全体で価格交渉の基準を設定するのは困難です。
結局のところ、オーダーメイドのシステムを企業で受注する自体に無理があるのでしょう。
少数精鋭で開発をした方がいいシステムが作れますから、それを組織的な商売にする時点で無理があると思えてなりません。
Ahfさんはどう思われますか？

Ahfさん>そうなると、支払われる報酬は「期待する水準を満たしていない」という理由のもとに更に減少する事が予想されます。
Ahfさん>すると技術者は徐々にこの世界から去り、高レベルな人達だけが残ることになると思われます。
Ahfさん>これを良しとするか否かは、色々な考え方があるかと思います。

まだ、ここが日本で、日本語でビジネスが行われているから良かったのでしょうね。

アメリカで最近ウォール街などの反格差デモが盛んに報道されるようになりました。アメリカのIT技術者の多くがインド等の英語圏の比較的低コスト、高レベルな技術者と直接競争にさらされ、収入を落としたり、失業の憂き目にあったりして、99%の側の人間としてデモに参加したり賛同したりと云った状況のようです。

ビジネスなので、顧客と一対一の交渉だけで済むなら話は簡単なのですが、競争という状況の下、どう考えていけば良いのか。日本でもそのうち、そうした状況を検討しないといけないのかもしれませんね。

似たような構造の業種で思いつくのは、デザイナーや作詞家、作曲家などの芸術系技術者かなと思います。
その人達は、金額と価値をどのように思っているんでしょうね。

お金は、財物の中で唯一、それを対価として差し出すなら「何でもいいからやれ」と命令しても違法な奴隷扱いとならないという特徴を持った価値です。
それがIT産業に携わる人間にはとても相性の悪い事になっています。
かなりの事が何とかなってしまうため、過剰にいいなりになってしまうからです。

おなじ仕事のあいだならお金で無い（知識とかの）貸し借りも利くかも知れませんが、 第三者がからむと、お金しかなく、奴隷扱いに歯止めになるのは、（有限な）時間をお金にリンクさせるのが苦肉の策と言えると思います。

将来的には「お金しか出さない人」を関係者から排除する事も有効かも知れません。

パッケージ販売のものは、今でも製作側の価値観と市場の相場で値段が決定していますよね？
「人月」に関係するのは、受託開発、カスタマイズ、保守かな？
で、その場合の「価値」をどう考えるかによってイメージが大分違うのではないかと思います。
「人月」の問題点として、「商品価値」が一緒に語られる場合って、多くの場合は、

「このソフトは価値があるから、もっと高いはず！」

と思っているのではないでしょうか？
逆の場合、つまり

「このソフトは価値がないから、もっと安いはず！」

ってのは、問題になりにくいというか・・・問題にする必要がないでしょうねぇ、開発側はｗ
実際問題として、買う側がそのように思ったとしても、開発側のコストがわりに合わなければ商売としては
成立しませんしね(^^;

で、はじめに戻って受託開発などで作成するソフトがもつ「価値」の元はなにかと考えると、「仕様」だと思うのですよ。
多くの場合は、お客の要望というきっかけがあって作成されますよね。
パッケージとは異なり、ソフトが持つ「価値」を開発側が主張できるケースって少ないと思うんですよねぇ(^^;
結局のところ、受託開発などは、お客のかわりにソフトを作成しているというのが本質的なものだと思います。
また、昔と違って、自社で開発できるけど時間がないから他社に発注するってのも増えていると思います。
この場合は、明確に時間を金で買っているわけで、「人月」ってのはそれなりのものさしになりますね。

>IT システムだけがかなり特殊な金額付けを行っているのではないでしょうか。

受託開発の商品はなにか？
ソフトだと考えたいのは開発側でしょうが・・・いまだと、実際には売っているものは労働力が殆どですね。
買っている側は、当たり前のように労働力を買っていると思っているのではないでしょうか？
いまや、ソフトウェア開発は、特別な職業ではないのですよ。
労働力に対して対価が支払われる、普通の仕事です、決して特殊な金額付けを行っているわけではないでしょう。

昔、そうですね、Dos時代かな？
ソフトは一部の人しか作れない、それこそ芸術品などと同じようなものだったと思います。
その時代は製作側が提示する金額が全てでしたし、買う側も選択肢が皆無だったこともありその金額で買っていました。
今は、ソフト開発できる人が増え、買う側が選択できる時代です。
製作側が考えた「価値」という一方的なものに振り回される必要がなくなり、市場に競争も生まれたのだと思います。
そして、パッケージソフトですら製作者側が考えた「価値」が通じにくい時代になっていますね。
スマートフォン市場などでは、低価格の相場ができてしまい、利益を上げるのは難しそうですね。(^^;

人月単価は昨今のビジネス情勢に合わないのでいずれ廃止されると思います。
ビジネスの世界では、国際競争が一般化し「苦労した分だけ報酬をください」は通用しなくなっています。
どの職種も「どれだけ働いたのか」ではなく「どれだけの価値を生み出した」が求められる時代です。
そのビジネス界の常識から考えると、人月単価は非常識な価格設定である事が明確です。
そういった非常識がまかり通るほど世界は甘くないでしょう。
それに加え、ドックイヤーや最先端を売り物にするIT業界が一番遅れているというのは頂けません。
いずずれなるのであれば、如何に非合理的な価格設定から脱却するのかが問題だと私は考えております。

プロ野球の例ですいません。

私らは、バットやグローブを作る立場。
実際にプレーするのは、選手です。

打率の良いバッターのバットを作れたらうれしいですね。

バットを作った人が利益を作るのではなく、バットを振る人が利益を作るのです。
私らはすごいバットを作ったと思っていても、残念ながら、周りはそうは思っていません。
バットを振っている選手が優秀なのだと思っています。

正直なところ、もっとバットの方を注目して欲しいな（お金欲しいなあ）と思いますが、実際にバットを振る人次第で評価が決まるので、人月単価で妥当だと考えています。

はじめまして。いつも楽しく拝見しています。
私は違う業種のサラリーマンですが、給料を含む「報酬」は結局のところ「どれだけ役にたったか」ということだと考えています。
人月がしっくりこないのはこの尺度に沿っていないからでは、と私なりにうけとめました。
サラリーマンが受け取る給料も人月なわけで、高額な給料がもらいたいなら、それだけ役にたつよう心がけねば、と思いました。フリーになるとこの点は考えるという次元でなく、現実として目の前に立ちふさがるのでしょうね。

僕らプログラマが時間いくらでサラリーもらってるのなら、
人月が原価に直結するのは無理もないハナシ。
なんでそんなことになっちゃうかっつーと、「時間いくら」以上に
合理的で妥当で誰もが納得する「プログラマの技量を測るモノサシ」を
手に入れてないから。時間かけるほど/ライン数多いほど価値があるなんて
ナンセンスなことは百も承知なんだけど、それ以外にモノサシを持ちあわせて
いないのでしょう。

もうひとつ、出来上がったモノの売値を決めるファクターとして原価を
無視できないから。そんなこっちゃないすかね。

補足情報です。
お客様は人月なんて興味がなく、システムがもたらす価値に興味があります。
価格交渉を実際にすると分かります。
おまけに、経済産業省が人月単価は止めるように言っています。
それらの事を考慮すると、人月単価は廃止の方向しかないと思います。

> 経済産業省が人月単価は止めるように言っています。

これ、３年も前に言うてるのね。
http://www.meti.go.jp/press/20090731004/20090731004.html

んでもって未だに具体的なアクションが見えてこない。
まだまだ先は長いように思えます。

明けましておめでとうございます。今年も宜しくお願い致します。
そして、たくさんのコメントありがとうございます。

>少数精鋭で開発をした方がいいシステムが作れますから、
>それを組織的な商売にする時点で無理があると思えてなりません。
(インドリさん)

個人的な理想としては、少数精鋭での開発はベターですが、責任等を
考えた場合に企業としての存在が必要になることがあると感じています。
なので全てをチームで、というのは難しいですがほとんどの部分を
チームに権限委譲し企業としては、問題が発生した際のバックアップを
行うにとどめる、といったやや都合のいい状況になれば、と感じます。

>ビジネスなので、顧客と一対一の交渉だけで済むなら話は
>簡単なのですが、競争という状況の下、どう考えていけば良いのか。
>日本でもそのうち、そうした状況を検討しないといけないの
>かもしれませんね。
(ハムレットさん)

そうですね、視野を広くした場合には言われるとおり考慮しなければ
ならない要素が増えますので、もっと考えなければならないと
思います。まだ日本は、フリーや小規模で活躍されているような
方々をのぞけば、その点で保護されているような状況ですよね。

>似たような構造の業種で思いつくのは、デザイナーや作詞家、
>作曲家などの芸術系技術者かなと思います。
(CMPさん)

確かに芸術系の方々がどのように金額設定を考えられているのか、
聞いてみたいですね。私にはその系でつながりがないので、
なおさら聞いてみたいです。

>おなじ仕事のあいだならお金で無い（知識とかの）貸し借りも
>利くかも知れませんが、 第三者がからむと、お金しかなく、
>奴隷扱いに歯止めになるのは、（有限な）時間をお金にリンクさせる
>のが苦肉の策と言えると思います。
(アラファイブさん)

時間をお金にリンクさせるのが苦肉の策、と言われているのがまさしく
その通りだと感じています。この方法以外に、現時点では互いに
納得できるような方式が存在していない、または認知されていないのが
難点ですよね。

>今は、ソフト開発できる人が増え、買う側が選択できる時代です。
>製作側が考えた「価値」という一方的なものに振り回される必要が
>なくなり、市場に競争も生まれたのだと思います。
(Ｓｏｄａさん)

受託開発で開発側から価値を提示できる場面は言われるとおり
少ないですよね。せいぜいレベルアップ時の提案とかくらいではないか
と思います。そして非常に同意したいのが、上記にある「買う側が選択」
できる時代、という点ですね。パッケージは当然選択できているのですが
受託となるとまだまだそれほど選択できる状況にないと感じています。
このあたりも改善していく必要があるのかも知れませんね。

>正直なところ、もっとバットの方を注目して欲しいな（お金欲しいなあ）
>と思いますが、実際にバットを振る人次第で評価が決まるので、
>人月単価で妥当だと考えています。
(まるもりさん)

非常にわかりやすい例ですね。同じように感じています。
私としては人月単価がベターとは思わないのですが、今時点でそれ以上に
互いに共有できる価値観がない、そのため妥当だと思います。
お金、欲しいですよね・・・。

>サラリーマンが受け取る給料も人月なわけで、高額な給料がもらいたい
>なら、それだけ役にたつよう心がけねば、と思いました。フリーに
>なるとこの点は考えるという次元でなく、現実として目の前に
>立ちふさがるのでしょうね。
(はむぱぱさん)

その通りですね。フリーや起業されている方々には当然の問題なのだと
思います。私もサラリーマンですので、これらの方々に比べるととても
保護されている環境にはあるのですが、それでも「もっと役に立つよう
心がけねば」と日々研鑽していきたいと思います。

>時間かけるほど/ライン数多いほど価値があるなんて
>ナンセンスなことは百も承知なんだけど、それ以外にモノサシを
>持ちあわせていないのでしょう。
(επιστημηさん)

そうですよね。恐らくこの業界で働く人たちの多くが何かしらの違和感を
感じているとは思います。また売値を決める際の要素に原価を無視
できない、というのも同意です。このあたりは開発側だけでどうこう
決めることができない領域ですが、将来的には一緒に考えていけるように
変化していきたいと考えます。

>おまけに、経済産業省が人月単価は止めるように言っています。
(インドリさん)
>んでもって未だに具体的なアクションが見えてこない。
>まだまだ先は長いように思えます。
(επιστημηさん)

方向性としては打ち出されているのですが、具体的にどうするか、
という点でもまだまだこれからですよね・・・。一部の企業などでだけ
考えて実行に移されていることとは思いますが、殆どの企業では
「具体的な方針がでてくるまでシラネ」
というのが実態なのかな、と思います。

投稿して気づきましたが、自分のコメント返答が長すぎてヒドイですね・・・。
全く持って申し訳ありません・・・。

Ahfさんへ
返信有難うございます。
>チームに権限委譲し企業としては、問題が発生した際のバックアップを
行うにとどめる
そういう方向がいいですよね。

経済産業省の件
遅い事で有名な行政の対応をさらに上回って、人月単価を維持するその姿勢がおかしい。
この遅い対応で、最先端などと口にする事がおこがましい。
実のところ商売のやり方は一番遅れています。
お客様の立場を考えないと表明しているのに等しい行為です。
本当におかしいですよね。
客商売としてあり得ない。

>自分のコメント返答が長すぎてヒドイですね・・・。
いえいえ。私はおかしいと思いませんでした。
一つのコメントに対して数行は普通です。
また次のコラムを楽しみにしています。

経産省のいう「PBC:パフォーマンスベース契約」は要するに、
人月ベースの価格設定(＝作るために要した労働量の価格換算) じゃなく、
サービスやシステムが創出する価値の価格換算 にしましょーよ、ってことで。

これだと万事うまくいくわけじゃない。だからこそ人月単価が廃れない。
やはりここでも創出する価値とやらを測る合理的/客観的かつ売り手/買い手
双方が納得するモノサシが用意できていないんですな。肉屋/米屋の秤や升が
店ごとにマチマチだったら誰だって文句言います。残念なことに人月単価は
ブレが小さく単純明快。これ以上によいモノサシが作れていないんですな。

人月単価が善しとは思わんが、あてにならないモノサシよりはマシ
ってところじゃないかしら。

マジにPBCが適用されると相当ツラいことになりますよ。原価はほぼ人件費
なわけだから、少数の有能なエンジニアを擁する会社ほど儲かります。
そうなるとフツーのエンジニアは廃棄処分になりゃせんかしら...とかね。
# 天才もアホもサラリーに大差ないてーのが善しとも思わんけども

サービスやシステムが創出する価値の価格換算は、客商売ならば当たり前の事です。
既に実施している私としては何をいまさらと思います。
ものさしはあるものではなく創るものです。
どの業界でも苦労して常に作り続けています。
それが商売であり、それを放棄する事は商売を放棄するのと同じです。
お客満足度の大きな要因が価格と品質です。
お客様を無視して、作品を創らないというのは技術者としても間違っています。
価値を決定しない作品は、「仏作って魂入れず」です。
あと、原価計算が人月単価を基準にするとデスマーチになるのは当たり前です。
人月単価が幸せを生んでいるとはとてもじゃないけど思えません。
唯一得をするのは口だけで商売をする人です。
だから偽装派遣や丸投げが流行ります。
人月単価だと詐欺をしやすいですからね。
なんにせよ、非合理的だと分かっているシステムを変更できないのは技術者ではありませんね。
創造精神なき者には技術者だと呼べません。

>επιστημηさん
>人月単価が善しとは思わんが、あてにならないモノサシよりはマシ
>ってところじゃないかしら。

使う人や使い方などによって「物の価値」なんてものは、変動してしまいますからねぇ。
その変動する「価値」を正確に測ることは、これからもできないでしょう(^^;
・・・というか、できてる業界なんてあるのかなとｗ
いわゆる「特注」ですよね、「原価」＋「手数料」＋αじゃないのかなぁ。

「価値」を元に「価格」を決めた場合、もめるのが見えてるしｗ
そんなくだらない揉め事に時間をかけるよりも、どんぶり勘定して先に進んだほうが、合理的とも思います。
「人月単価」って100万前後という相場があるように感じますが・・・
実際問題として、どういうことで困るんだろう？
時給に比べてはるかに調整が入ってると思うのですが・・・自分が勤めてるのが小さい会社だからかなぁ？
あっ、感情的に「こんだけやってもギャラが一緒」みたいなものはありますけどｗ
それは給料の問題だから別ですなｗ

IT系って歴史が浅いから、物を作ることに対する考え方が、古いというか未成熟なんですかね？
自分たちが生み出したパッケージものに対して「価値」を主張するのはいいとしてー
「受託開発」したものにまで自分たちの「価値」を主張したがるんですよね(^^;
いや、技術的な価値はあるとは思いますよ、でも商品としての価値を扱うのはお客さんだと思うのですよ。
少なくとも自分がやった「仕事」ではあると思いますが「作品」ではないでしょう。

>マジにPBCが適用されると相当ツラいことになりますよ。

主に「価値」を軸に「人月単価」を否定している方々は、自分たちに「価値」があると思っているでしょう。
だから、ツラいことになるのは「できない奴」であり、「淘汰」されれば良いと考えていてもおかしくないですねｗ
コンパイラやハードの性能があがったこともあって、技術力の差って昔と違って、障害になりにくくなってると思うのですよ。
それに、製作側の数が昔とは比べ物にならんぐらいに増えているわけで・・・
「価値」ってのは少ないから高いもので、類似品が増えれば下がってしまいますよね、相対的な感覚として。
まぁ、IT系なら原価割れする会社のほうが多いというか、共倒れで利益をあげれる会社がないような気もするんですがー

自分達は「技術者」と思っているでしょうが、世間では単なる「労働者」になっている時代だと思うのだけど・・・
こんなにも簡単に、にわか職人が生み出される業界は確かになかったでしょうねぇ。
同じようなものを、他人が簡単に作れるようになってきている事実を認められるようにならないと、駄目じゃないかなぁ。

ＰＳ．
それでも自分は「技術者」を目指したいんですよねぇ。
社内に直したいコードがあっても、時間的な問題（まぁ、利益との関係）もあって直せなかったりｗ
正常に動作しているコードを、書き直すチャンスって少ないですよねｗ

勘違いしている人がたまにいますが、受託開発はお客様に言われた事だけをする仕事ではありません。
それだけならばお客様自信が作ればいい話しであって、そんな商品に価値はありません。
お客様の要望／願望を叶えるシステムを創る仕事です。
おまけに、人月単価は早くつれば作るほど価格が下がる下策です。
熟練した人がすれば100倍の生産効率の違いがあります。
その場合単純計算すれば価格が100分の1になります。
おまけに、時間をかければ作れる程度のものは、誰でも作れるものなので商品価値は低いです。
普通企業はコストを減らして、商品価値との差額の粗利を得る事を目指しますから、人月単価はその逆を行く非合理的な計算方式です。
これで得をするのは、不成功をする会社と、自分の腕では稼げない人だけです。
正直に商売をすれば儲かり難い価格設定なので、丸投げなどの不正行為に結び付きやすい魔の価格決定法です。
ようするに、お客様を見ようともせず、商売が下手なだけだと思います。

誤：不成功
正：不正行為

> 受託開発はお客様に言われた事だけをする仕事ではありません。
> それだけならばお客様自信が作ればいい話しであって、そんな商品に価値はありません。

そりゃ違うっしょ。

お客さんは漠然としたwhatを持ってるけどhowにつながる具体的なwhat
に落とし込むこと、そしてそのwhatを実現するモノと技をを持たないから
(あるいはそんなことにリソース裂きたくないから/余計に高くつくから)
金払ってわしらに頼むんでしょうに。

晩飯作れてもそんなヒマないなら弁当買ってくるでしょ?
その弁当に価値がないと? タダでよこせと?

> 人月単価は早くつれば作るほど価格が下がる下策です。

ひと山いくらのテキトーな人月単価ならそうなりますわな。

> 熟練した人がすれば100倍の生産効率の違いがあります。
> その場合単純計算すれば価格が100分の1になります。

そんときゃ熟練した人の人月単価を凡人の100倍に設定すりゃいぃんじゃね?
# 実際にはそれができてないから問題なわけなんだが

事実誤認をしている人が受託開発に従事している人を馬鹿にしているコメントを書いているから「お客様に言われた事だけをする仕事ではない」と言っているのですが・・・
どうみてもあのコメントは受託開発をしている会社に対する暴言です。
そもそも話しかけていないし・・・
何時も思うのですが、よく読んで頂きたいです。
何時もちゃんと読まないで勝手に妄想をふくらましてコメントしてくるので、どう対応していいのかわからず困っています。
かといって答えないと騒ぎたてるので、私の意見を再度書きます。
お客様自身が気づかない事を実現出来るから、私達が提供する作品に価値があります。
お客様自身が知っている事だけならば、お客様自身が内製化するか、お客様が望む価値が低くなります。
お客様が満足するのは、その商品の品質と価格のバランスにあります。
人月単価だから納得しているわけではありません。
現に満足度が低いという結果が出ています。
お客様自身に訊いてみればわかりますが、お客様は人月単価に納得していません。
IT業界はなぜ人月単価なのかと頻繁に聞かれます。
ですから、私が価値ベースで価格を提示すると「合理的で信頼できる」と言ってくれます。
私達がしているのは客商売なのですから、お客様の要望を聞くのが基本です。
分からないからと言って人月単価を支持するのは理解できません。
会計的に考えても不合理ですし、プロ意識を持っている技術者にもメリットがありません。
議論がしたいのであれば、人月単価がもたらすお客様のメリットを提示して下さい。
それがなければ議論になりません。
申し訳ないのですが話しが論点が乖離している、話しかけられても答えられません。
その時は騒ぎ立てないでください。

...一体どこ読んでらっしゃいますの?
「お客様自信が作ればいい話しであって、そんな商品に価値はありません。」
に反論してるんですけど。

> そもそも話しかけていないし・・・

なにそれ?

> 人月単価がもたらすお客様のメリットを提示して下さい。

「いくらでできる?」と訊かれたときそれに答えることができます。

PBCは「創出された価値」がベースです。価格を決定するのはお客様です。
お客にそんな難しいことやらすんですか?

「いくらでできる?」て訊かれて
「それはお客様が決めてください」じゃ商売にならんでしょ(現時点では)。

> 分からないからと言って人月単価を支持するのは理解できません。

支持してません。もっと良いやりかたがあるならそうしたい。
けど現実問題としてもっと良いやりかたが未だに見つかっていない。と言ってます。

あなたはうまくやっているのでしょう。みんなそうすればいいのに。
でもそれができていない。その理由を考え議論しないと先に進めません。
あなたのように「人月単位はダメだよね」を連呼するだけじゃ解決にならんです。

>「いくらでできる?」て訊かれて
>「それはお客様が決めてください」じゃ商売にならんでしょ(現時点では)。
誰もそんな事は言っておりません。
お客様の要望を引き出し、それを元に価格を決定します。
それは商売の基本です。
商売の基本が出来ない事は自慢になりませんし、言い訳にもなりません。
ビジネスの世界はそれ程甘いものではありません。
ごく普通に決められる事です。
最初に言った事ですが、それを組織的にするのは難しい。
しかし、だからと言ってしなくてもいいという事ではありません。
する気になれば出来る事です。
不可能ならば、全ての業界が人月単価になっているはずです。
IT業界だけが特別視してくれるほどお客様は甘くありません。
ちなみに、お客様から「商品の価値を聴いているのに、論拠が人月単価だという事はIT業界は人を売っているって事だろ」と言われた事があります。
それがお客様の意見であり、その指摘は正しいと思います。
商品価値を決められないのが根本的におかしいのです。
分からないからそのまま不合理な事を続けようというのは論外です。
なければ創るそれが商売／技術者では普通の事なのです。
価格の決定法そのものがサービスの一部であり、価格を工夫するのは当たり前なのです。
従って、結論は「不合理な人月単価は廃止し、お客様が納得する価格体系を創ろう」しかあり得ません。
結論が出ている事を引き延ばす理由が分かりません。
その結論をひっくり返すには、お客様にとって人月単価が適切だと証明するしかありません。
それが出来ないようですし、なにも有益な意見がないようなので終わりにしたいと思います。

> お客様の要望を引き出し、それを元に価格を決定します。
> それは商売の基本です。

それは人月単価ベースでも同じだってば。
お客の要望を引き出し、それを何人*何ヶ月でできるか見積もり、
人月単価を掛けて価格をはじき出すんだから。

> 結論は「不合理な人月単価は廃止し、お客様が納得する価格体系を創ろう」しかあり得ません。

そのとおりですよ。だから経産省もPBCを提言している。
しかしながら実現には未だ多くの課題があるね。
それは何なんだろうね。どうすりゃ解決できるんだろうね。
って言うてるんでしょうが。

> 結論が出ている事を引き延ばす理由が分かりません。

その結論を実現する"具体的手段"が定まらないうちに闇雲に突進したら
空中分解するですよ。

それともあなたは答をお持ちなのでしょうか。
個人あるいは小さなチームではなく、大規模/大人数で実装する
プロダクトに対して。

失礼ながらεπιστημηさんは、商売の基本的な事をご存じないと感じました。
何度も言っておりますが、「商品は価格を含めたもの」です。
ユニクロの服などの安くて良い商品を買ったら、お客様は「こんなに安いのにいいね♪」と喜びます。
そういった商品の生産体制を創るのがビジネスそのものなのです。
ですから、貴方が言っている事は商売人の私に対して、「企業秘密をただで教えろ」といっているのに等しいのです。
私は商売をしているのですから、利益があって事業展開をしております。
利益の源泉を教えると本気で思っているのでしょうか？
ですから何度も言うように、分からないと連呼されても議論になりません。
それは教えて君であって議論ではありません。
分からないと連呼されても困ります。
そういうとまた陰口を叩いたりするのでしょうが、私もやりようがありません。
ここは大人の社交場です。
もう少し分別をもって振舞って頂きたいです。
私から言える事はそれだけです。

ここまでのやりとりや貴重なご意見を拝見していると、
皆さんの思う方向性は一致しているのですよね。

「現状の方法は望ましいものではない」

そして問題となっているのが「それに変わる方式が用意できるか？」という点だと思います。開発側が考える方式としては色々あるけれど、実際にユーザーの事を考えるとなかなか難しい課題が多いのではないでしょうか。開発側だけの都合であれば、いかようにでも価格を決めることができるのですが、それではユーザーにとっても良いことはないでしょうし。

個人的にこの問題を解決していくためには、まずユーザー側がもっと多くの選択肢から選ぶことが出来るようになるのが「第一に」必要なのかもしれない、と考えます。別の場所で言われたのですが、入札制度はそれに近いのかも知れません。
そのような形ででも競争の場が増えてくることによって、開発側も適正な価格やそのために必要になるであろう評価制度などなど、今よりも良い方向にすすめる手がかりにできるかも知れないなぁ、と漠然とですが思ったりします。

難題は山盛りですよね・・・。

>インドリさん
>どうみてもあのコメントは受託開発をしている会社に対する暴言です。

ネット上で、しかもこのコメント内ならば、引用してくださいな。
そのコメントに対する中傷やいいがかりではないというならね。
直接指摘すれば、あなたと同意見の人、異なる意見の人様々な意見が明確に聞けるでしょうに。

>ユニクロの服などの安くて良い商品を買ったら、お客様は「こんなに安いのにいいね♪」と喜びます。

ソフト業界では、ユニクロの服などを「パッケージ」と呼んでいますよ。
少なくとも「人月単価」は「パッケージ」に関しての話題ではないと思うのですが・・・
IT系だと、「パッケージ」の価格に「人月単価」が関係するような「不思議」な構造があるんですか？

>利益の源泉を教えると本気で思っているのでしょうか？

「自分は知っている」が「他人には教えない」、議論（会話かもしれませんが）にはなりませんね。
それではただの自慢でしかないのではないでしょうか？
ちなみに・・・この手の発言をした場合、「本当は知らない」のではないかと疑われることが多いことも付け加えておきます。
「教えられない」のなら、議論に加わらない、もしくは利益に影響がない範囲で改善案などを提示するなどの配慮が必要ではないでしょうか？

>Ahfさん
>そして問題となっているのが「それに変わる方式が用意できるか？」という点だと思います。

本質的にはないと考えますね。
お客に提供しているのが商品なのか、労働力なのか？
商品だとした場合、その価値を生んでいるのは誰なのか？
上の流れでは、開発側だけでも認識が違いすぎるでしょう(^^;
IT系が、「受託開発」を商品で、しかもその価値は開発側がもっているという認識が一般的なのだとしたらなおさらかなぁ。

あぁ、このコメント内で昔から思っている疑問がありましたー
インドリさんの発言で

>おまけに、人月単価は早くつれば作るほど価格が下がる下策です。

こう思っている人が結構いるんですねぇ。
実際は「利益」があがるわけですが・・・
そんなおかしな「人月単価」で見積もっている企業ってIT系だと多いのかなぁ？
・・・というか、あるの？
επιστημηさんの引用みても、否定的ですよね。
「人月単価」を否定する理由の１つとして存在しているとしたら、「人月単価」を誤解している可能性が高いと思うんだけど・・・

>難題は山盛りですよね・・・。

「人月単価」とはなんなのか？という正しい共通認識を持つところから・・・だと思ったりｗ
誤解から生まれる問題点と、感情から生まれる問題点などが混ざっているような気がしてならないのですよ。
商売として、「人月単価」は、お互いがある程度納得できる状態だと思うのですよ。
そうじゃなければ、とっくに崩壊しているわけで・・・

「人月単価」って「仮想的な材料費」だと思うのだけど、「価値」を絡めたい人は、「人月単価」をなんだと考えているんだろう？

> こう思っている人が結構いるんですねぇ。
> 実際は「利益」があがるわけですが・・・

うははは、いやまったく。
10日で見積もって価格が決定したところで、
5日でこしらえたら残る5日は遊んでてもいいし、
もひとつ受注して倍稼いでもいい。

逆に長引かせれば儲かるかっつーとそんなこたーない。
10日で作ると契約してたら、それを超えたら罰金です。
ヘタすりゃ「あんたんトコには二度と頼まん」て言われます。

形のない商品にどう値付けをするか、なわけだが...

> まずユーザー側がもっと多くの選択肢から選ぶことが出来るようになるのが「第一に」必要なのかもしれない、と考えます。

僕らと同じく「形のない商品」を売ってるお医者様。
保険診療では公的機関が診療行為に応じて単価を決めています。
なのでどこの病院でもお値段はさほどに変わらない。
治り早くて痛くなくて面倒見のいいお医者のとこにはお客様(患者)が集まります。
それで儲かる。

どこのソフト屋に頼んでもお値段は大差ないとなれば、
より早くて、バグ少なくて、サポートの迅速丁寧なとこにお客が集まる。で儲かる。
ある意味極めて健全。儲かりたいなら腕を磨けってことでモチベも上がるっしょ。

> 別の場所で言われたのですが、入札制度はそれに近いのかも知れません。

「安いが勝ち」になっちゃうんでね?
てか現状だっていくつかのソフト屋に"相見積"お願いしていっちゃん安い
とこ選べるよね。これって入札と大差ないよね。公開か否かの違いこそあれ。

>「安いが勝ち」になっちゃうんでね?
>てか現状だっていくつかのソフト屋に"相見積"お願いしていっちゃん安い
>とこ選べるよね。これって入札と大差ないよね。公開か否かの違いこそあれ。

そうなんですよね。現状でも似た形で出来ると言えば出来るのですが、
個人的な感覚としては、都市圏でどうなのかわかりませんが地方都市の場合、
相見積を行うにしてもその割合が少数に感じています。
（私の関わる範囲だけかも知れませんが、とらない方が多い気が・・・）

また「安いが勝ち」ですが、確かに入札形式では防げないですよね。
こうなると体力勝負の世界ですし。
ここももう一つ、何か考えていかなければいけないところなんでしょうね。

安いもの勝ちというのは、オーダーメイドのシステムでは起こり難いと思います。
オーダーメイドシステムの価値は、お客様の抱える問題をどのように捉えるのかによって変わります。
五十歩百歩になる可能性もありますが、安いも生産体制の違いにより差が生まれるものですし、まっとうな商売の競争になります。
相見積もりをするお客様は結構いらっしゃいます。
そのお客様に訊いた事があるのですが、お客様も安さだけで選んでいません。
真偽のほども合わせて判断していると聞いております。
お客様も必死なので相見積もりの弊害も知っておられます。
安ければいいという業者は信じられないというのがお客様の意見です。
仮に安くなった場合、回転率で勝負するのが商売の基本です。
人月単価の場合、早く仕上げると価格が下落してしまいますが、価値ベースだと価格は下がりません。
また、給与の限界もおのずと決まってしまいます。
技術者との相性は非常に悪いです。
従って、人件費と価格の乖離が近代的産業への鍵となると言えます。

余談
また連れてきた。何時も一人で語れないんだね・・・

> 人月単価の場合、早く仕上げると価格が下落してしまいますが

しないよ。

"予定より早くできたから安くしろ"てゴネる客はいないから。
それに応じる営業さんもいないから。

早く仕上げて原価が下がった分利益は増えます。
だらだら仕事するほど儲かるって本気で思ってます?

επιστημηさんがまたごね出した、相変わらず困った人です。
また論点がずれていますが、私が言っているのは商品価値です。
人月単価よりも速く仕上がったら、お客様も大人なので普通に対応します。
ですが、お客様は「人を売ると言っておきながらサバを読んだのか。ならばあの見積もりは何なのか」と不審がります。
そもそも、自社の商品の価格も決められない時点で、お客様にしてみれば不審なのです。
他の業界は自社の商品の価値に自信を持って価格をつけています。
お客様は商品の価値を訊いているのであって、開発側の会社の事情はどうでもいいのです。
従って、貴方が言っている人月単価の操作は論外です。
恐らくお客様と直接会って本心で話をした事がないのでしょう。
自分が分からない話題に首を突っ込み、自分が間違ったらごねる。
おまけに、仲間を呼んで誹謗中傷したり、ブログを荒らしたり・・・
まっとうな社会人の行動ではありません。
悪い事は言いません。
読解能力とコミュニケーション能力をもう少し身につけましょう。
誹謗中傷したり騒いだりするから仕方なく話しをしていますが、貴方はまともな議論ができそうもないので話しかけないでください。
この数年間、非常に迷惑しております。

> お客様は「人を売ると言っておきながらサバを読んだのか。ならばあの見積もりは何なのか」と不審がります。

心配ご無用。お客が不振がることは絶対にないから。

あっとごめんなさい。

× 不振
○ 不審

> 自社の商品の価格も決められない時点で、お客様にしてみれば不審なのです。

通産省の件のドキュメント、お読みになりました?

さて、改めてソフトウェアという極めて異質なモノの値付けを考えてみた。

まずソフトウェアは実体を持たない。
実体がないからどんなに使おうが壊れも擦り減りもしない。劣化しない。
なので実体のある「モノ」と同じ値付けはできそうにない。

おなじく実体を持たないサービス、たとえば公衆電話あるいはバス・タクシーとも異なる。
これらはサービスが持続しないから使った分だけの対価を支払っておしまい。
一方ソフトウェアは実体がないくせにその効果は持続する。
何度でも好きなだけ休むことなくサービスを利用できる。

さらに加えて劣化なしに無限にコピーできる。

こんな珍妙なモノを扱う業界って他にあるだろうか。
そう考えると「他の業界はすべてちゃんと値付けしてるじゃないか」に説得力が乏しい。極めて異質な商品なのだから。

そんな商品に値段をつけろという。
しかたない、作るのに必要とした原価に儲けを乗せよう。

なんか至極まっとうな流れに思えますね。

しかし、しつこいな・・・
返してくるなというのがわからないでしょうか。
あきれるばかりです。
それにしても、結論をどうしたいのだろうか？
結論を考えずにしつこくコメントするのが、コミュニケーション能力の欠如の表れです。
この人が人月単価を支持していても私は一向に構いませんし、何を私に求めているのかわかりません。
やはり嫌がらせ目的としか思えません。

>心配ご無用。お客が不振がることは絶対にないから。
実際に私が聞いたと言っているのがわからないのですか？
いや、いつものごとく都合の悪いことを無視しているだけか（ため息）
やはりお客様とお話しをしたことがないようですね。

>なんか至極まっとうな流れに思えますね。
やはり人月単価を支持しているのですね。
この執拗と自慢げに人月単価の捜査を語っている時点でそうとしかとれません。
ダブルスタンダードではお話しになりません。
この人は何を言ったら通じるのだろうか・・・
明らかに異常です。
どうせ誹謗中傷するのだからもう無視しようかな・・・

誤：捜査
正：操作

追記
商売だからと何度も言っているのですが、それも理解してもらえないようですね。
情報サービスが特殊なのは常識ですが、どの業界の商品もそれぞれ特色があります。
特殊な商品を扱っているから、お客様に妥協させるというのは甘えです。
特に人月単価で商売をしていない私に言うのが間違っています。
やればできるものを言い訳を用意してやらない。
それはプロがとるべき姿勢ではありません。

続けるね。

> そんな商品に値段をつけろという。
> しかたない、作るのに必要とした原価に儲けを乗せよう。
>
> なんか至極まっとうな流れに思えますね。

いやそれはマズいっしょ。「しかたない」を理由にしちゃマズいっしょ。
じゃぁどうする。

お客に値付けをしてもらうというのはどうだ。
もちろん値付けに必要な情報は開示するし、
互いの合議で値付けをしてもかまわん。
互いが納得できるならそれがベストだ。

それが経産省の出したPBCなんだね。
ただしこれの実現には様々な問題があろ。
「やればできる」と簡単に言えるようなシロモノじゃない。
どんな問題があるかも件の報告書に記されている。

>επιστημηさん
>こんな珍妙なモノを扱う業界って他にあるだろうか。

音楽かなぁ。
最終的にはパッケージになってしまいますが、最初の発注部分なら近い・・・かな？
印税はパッケージから発生しているから、抜かないと駄目ですな。

>しかたない、作るのに必要とした原価に儲けを乗せよう。

パッケージと異なり、出荷する数は限定されるので、一回の取引で利益を生み出さないといけないですよねぇ。

仮に・・・ソフトが生み出した利益からのみ代金を頂くとしましょう。
開発側はソフトにより発生する利益に応じて代金が変動します。
あやふやな単位である「人月単価」などという「材料費」を提示しなくてもすみますね。

しかし・・・
ソフトを収めた時点では、利益は発生しないので、代金が振り込まれるのはかなり先になります。
いや、お客が思っていたような利益を生み出さないかもしれません。
もちろん、莫大な利益を生み出し、音楽の印税のように、代金を頂ける可能性もあります。
人件費という原価があるのにも関わらず、収益が不安定なわけです。

「いつ現金が手に入るか？」ってのは中小企業にとっては死活問題なわけで・・・
上記のような形式では、体力（資本）がもたずに倒産する会社が殆どではないでしょうか？

じゃー最初に一括でもらえばいいじゃん。
このソフトはこれだけの利益を生み出すはずですので、これぐらいの代金が欲しいです！
もらえるわけないよね・・・というか、なにかの法律に引っかかりそうなぐらいな商売方法？ｗ

そもそも、「利益」の明細って「人月単価」と同じであやふやですよねぇ。
システム導入したおかげで人件費が二人分減った、彼らの給料は合わせて30万だったから利益は30万？
まてまて、その二人が他の仕事をしているなら、本当に30万でいいの？

会社が継続するには、原価を回収し、利益をあげないといけません。
ソフトが生み出す利益と原価の関連性は皆無なわけで・・・
未知であるソフトの生み出す利益を元に、原価を回収するのは無理があるのではないかと思うわけです。

ＰＳ．
結論って・・・「人月単価」は最良ではないが、良い選択ではあるってことじゃないのかなぁ。
もっといい方法がないかな？と模索しているが、消去法によってやっぱり「人月単価」が残る・・・みたいな。

> 仮に・・・ソフトが生み出した利益からのみ代金を頂くとしましょう。

「あのー...おいくらいただけるんでしょうか」
「あーあれね、先月ソロバン一級のおっちゃん雇ったらぜーんぶやってくれたわ。　だから要らなくなっちゃった。だからお代はナシね。ゴメンね」

真に"創出された価値"をベースに契約するなら、そゆことになりゃせんかね。
ベンダが提示した価値じゃ意味がない。それは提供側が一方的に押し付けた
"創出されるであろう価値"でしかないからね。

ふぅ、また仲間を呼び出して演説を始めましたね。
はた迷惑な行動です。
それで、そこまで執拗に人月単価を支持してどうするつもりかな？
私は既に人月単価を卒業しているし、お客様が納得する価格体系ではありません。
妙な演説をしようが駄目なものは駄目。
ただの見苦しい言い訳です。
ここで演説をしないでよそでして下さい。

> 私は既に人月単価を卒業しているし

「個人ができるから集団でもできる」は間違い。幼稚な発想。
僕らが考えねばならんのは業界を対象としている。
それはあなたが最初のコメントで述べていることだ。違うか?

違います。
何度言っても分かってもらえませんが、客商売はお客様の意見を最優先するのが鉄則です。
それが業界に繁栄をもたらします。
お客様に満足してもらえない業界は発展が望めません。
現に今でもこの業界は不合理な出来事が多いです。
それは、商売の仕方が王道ではない事から生じる弊害です。
そうやって、出来ない理由なんていくらでも考えられますが、ビジネスの世界では通用しません。
プロは言い訳をしないものです。見苦しい。

-- インドリ 2011年12月28日 (水) 18:52
> ......
> 人月単価とは違い、価格交渉は定まった計算式がありませんが、
> それはオーダーメイドだから当たり前の事だと思います。
> その「当たり前」を経営的に行うのが難しいのでしょう。
> 実際に組織全体で価格交渉の基準を設定するのは困難です。

...どこが違うんだ?

...ごめん。
僕の国語力、相当にイカレてるみたいだ。
勉強し直してくる。

# インドリさんは「違う」と断言されたが僕にはその違いがわからん。
# だれか解説してくれないだろうか。

インドリさんへ
人月論は、いつも不毛論になります。
受注者側の経営安定の事情で人月契約を望んでいることを覆すだけの説得力はありますか?
すべて請負契約で仕事が遂行できれば可能でしょう。しかし。
"労働の対価は拘束時間で支払う"という労基法という異なる次元の制約があります。
世の中の大半の仕事は拘束時間で成立しています。
人月制度問題はソフト業界の悪弊ではなく、労働界の根底問題です。
　拘束時間以上の成果を出すか出さないかは、当事者の資質問題です。
8時間分の仕事に12時間費やしたら、4時間のOverになります。
　このとき、4時間追加料金を請求するから「人月制」はおかしいと主張しているのですね。
　でもこれは、対価支払と仕事評価の問題です。　人月制の問題にするのは問題のすり替えです。
残業が付くなら、 8時間の仕事を1時間で終わらせたとき、7時間分減額されて然るべきですが、そうはなりません。
　固定給制度だからです。矛盾を含んでいて、インドリさんの不満の原因にもなっています。
しかし、この矛盾以上に、メリットがあるので矛盾に目を瞑っているのです。

　自己能力の過大評価で残業になったとき、追加料金の発生と請求は、モラルや資質の問題で、人月制とは別問題です。
研究職や開発職など、時間と成果が比例しない業界は多々あります。いずれも、インドリさんの云う所の"人月問題"はあります。
しかし、労働の対価の物差しは、過去の経験から、消去法で「人月契約」「人月評価」が残りました。
他に比べて優れているのではなく、比較的に不具合点が少ないという理由からです。

インドリさんが "人月制は悪だ"と叫ぶのは、崇高な提議ですが、他の人の同調を得られないのは、対案がないからです。
"人月制"を覆す対案と物差しを提示すれば、賛同者は増えます。

賛同者が増えれば、労働界を根底から覆す、大仕事に繋がるかもしれません。
是非、妙案提示を望みます。

少しはマシな代案を考える。
プロダクトの要素ごとに明細をつけるのはどうだ。

画面デザイン、基本設計、モジュール・サブシステム分割、
詳細設計、実装/テスト、保守サポート... それぞれのお値段。
(加えて要素技術、たとえばネットワーク、データベースなどなど)

どんぶり勘定でＮ人月ｘ人月単価よりはマシな気がする。
お客も内訳がはっきりしているのでより納得するだろう。
実際にこんな見積もりをお客に提示するケースも少なくないだろう。

しかしこれは価値をベースとした値付けじゃない。
what(欲しいもの/客の要望)ではなく、how(材料と作り方)に対する値付けだ。
カレー一杯いくらに対して
にんじん・じゃがいも・玉ねぎ・ルーそれぞれいくらと言ってるのと同じ。

従来通り人月ベースで試算し、それを振り分けても同じ明細が作れる。
単に「細かくしただけ」であり、価値ベースとはお世辞にも言えないね。

原価ベースで価格算出は、建築業での積算精算に該当しますね。
経営面でいうと、事故やクレーム対応に費やす経費(以後経費Aと称する)を確保しないといけません。
どこかに潜り込ませることになります。
これが不明瞭会計につながるのですが、顧客に示す明細に記述したら、支払ってくれないのは明白です。
一般店舗でも、商品の劣化による(賞味期限切れ等)機会損卒や、万引き率を考慮して売価を決めます。
どんなに健全経営しても、仕様変更に近いクレームや、手切れの悪いなど、請求できない経費が生じることは避けられません。
リピート顧客であれば、顧客毎に危険率を設定して、手間の掛かる顧客は、原価* 1.5を上乗せしたりします。
他にも、、事務、人事、総務部などの間接要員の経費や、コマーシャル等の広告費が生じます。
このような経費を考えて、直接要員一人当たりの売上基準が算定されます。　
これは正に人月単価につながる構図ですが、他にどのような対案がありますかね。
明確化してないが、消費者も理解していて、"価格設定がおかしい"　とはなりません。
技術力や開発期間や顧客ニーズと満足度や貢献度だけで価格が決まるとしたら、上記の間接経費は何処から調達するのでしょうか。
　人月による価格設定は、IT業界特問題でなく労働界全てに共通する問題です。IT関係だけが特殊だと見ると本質を見失しないます。

対して創出された価値ベースの典型例が印税です。
雑誌なんかの場合はページいくらの買い切りですが、
一般書籍の印税はぶっちゃけ「分け前よこせ」でして、
売上のN％が著者の取り分となります。

文句の言いようのない単純明快なやり方ですが、
これもちょっと無理。
毎月いくらいただけるのかわかんない。
それじゃやっていけないのはわかりきってる。

連投ごめんよ。

で、人月単価に代わる"価値ベース契約"方式があったとしてそれをXとしよう。
また、売り手をV(ベンダ)、買い手をU(ユーザ)と現わす。
Xが満足すべき条件は:

[1] XはU,Vの双方にフェアでなくてはならない。
すなわちU,Vいずれかが一方的に押し付けるものではない。

[2] Xによる最終的な価格決定はリリース後である。
Uの手に渡らない限り、"望んでいた価値"に値するかはわからないから。

[3] リリース後UはVにできる限り速やかに支払わなければならない。
"価値算定中"とか理由をつけて半年も一年も支払いを延ばされちゃかなわん。

必然的に"価値"は速やかに(Uによって)評価できなくてはならない。
現在の商習慣からして一か月がいいとこかな。

そう考えるとXのモノサシはかなり目盛の粗いものになりゃせんだろか。

>επιστημηさん
>[1] XはU,Vの双方にフェアでなくてはならない。

「価値」に対する思惑は双方イロイロあったとしてー
照らし合わせるのは、「売値」と「買値」ですね。
フェアってのを言い換えれば、お互いが「妥協」できる範囲・・・になるのかな。

>[2] Xによる最終的な価格決定はリリース後である。

あぁ、これは、[1]で決定した「価値」の内容しだいで変化しますね。
ソフトが生み出した利益にのみ「価値」を求めた場合は、確かにリリース後にしか「価値」はみえないわけでー
そうすると[1]と矛盾してしまう。
・・・いや、その条件でVがフェアだという認識なら矛盾しないのか？

利益とは別のところに「価値」を見出していた場合・・・って、いっても、最終的にはどこかの利益につながるはずですが(^^;
こういうものが完成する予定だということで、価格決定は可能だと思います。

>[3] リリース後UはVにできる限り速やかに支払わなければならない。

これも[1]によっては、分割払い（サービス料みたいなもの）になったりするんですよねぇ。

・・・正直な感想だけいえば、「人月単価」でも実現可能じゃないかなぁ。
むしろ「人月単価」のほうが柔軟に対応できそうに思えるんだけど・・・

感情的に「人月単価」を否定するのは理解できるんですよ。
でも、現実レベルの運用で「人月単価」を採用して本当に困ることってなにかなと・・・
「時間」に対する「労働力」に対する対価という形式を否定したら、給料なんて殆ど否定されるものでしょうし・・・

売ってるものは「労働力」じゃなくて「製品」なんだーってが「人月単価」を否定する理由だとしたら、なにか違うなと。
やっぱり、「価値ベース契約」が成り立つのはパッケージだけじゃないかなぁ。

> こういうものが完成する予定だということで、価格決定は可能だと思います。

うん、「これこれこーゆー条件を満たしていれば100万円」てな条件付きの価格決定ね。
[2'] んで、出来上がったプロダクトがその条件を満たしているか測定/検証がなされ、
その結果に応じたインセンティブ/ペナルティで支払われる額が増減するかと。
「創出された価値」を価格決定のよりどころとする限り、この過程は外せんと思うです。

>>[3] リリース後UはVにできる限り速やかに支払わなければならない。
> これも[1]によっては、分割払い（サービス料みたいなもの）になったりするんですよねぇ。

うん、これは契約次第。月額使用料とか保守契約とか。

インドリさんは「人月単価を卒業した」言うてはるけど、それがホントに
"お客様にとっての価値"がベースになってるのか正直懐疑的になってます。
僕は上記[2']が必須だと考え、だとするとお客様に"評価"という従来にはない
手間を強いることになりますから。

まさかと思って来てみたら、まだεπιστημηさんグループの人月単価プッシュが続いていたのですね・・・
この人たちが人月単価を信仰していてもどうでもよいからいいけど、人月単価の維持を狙う人の気持ちが見えて興味深いです。
人月単価を必死で維持する人の目的はどうやら、自分の給与を確保したいだけのようです。
悪い意味でのサラリーマン根性です。
証拠

>毎月いくらいただけるのかわかんない。
>それじゃやっていけないのはわかりきってる。

>「時間」に対する「労働力」に対する対価という形式を否定したら、給料なんて
>殆ど否定されるものでしょうし・・・

プロ意識のかけらもない。
そこから考えるに、人月単価が維持されている理由は、惰性と甘えが大きな要因のようです。
お客様は望んでいない、だからこそ国に働き掛けている。
生産力向上を真面目に考えている人も報われない。
利益を得るのは、中抜き会社・丸投げ会社・不真面目な人（真面目な人におんぶにだっこ）です。
しかも、昨今のビジネス情勢も分かっていません。
いまどき働いたら働いた分だけもらうという発想は非常識。
会社運営とサラリーマン感覚をごっちゃにしていますが、お客様を無視すれば結局は倒産し、真面目な人も害をこうむります。
加えてお客様に価値を提供する気が全くない。

>[2] Xによる最終的な価格決定はリリース後である。
>Uの手に渡らない限り、"望んでいた価値"に値するかはわからないから。

商売のこと全然分かっていない上にやるきもない。
そんな人たちが、この業界でやる気のある人達を潰してきたのかと思うと、怒りを覚えます。
こういうのを既得権益者と呼ぶのでしょうね。

意見にケチつけるのはかまわんが
人にケチつけるのはやめようや。
# 何度も警告喰らってるっしょ?

一点だけ。

> お客様は望んでいない、だからこそ国に働き掛けている。

それに応えるべく公開された経産省の件のドキュメント:
「情報サービスのパフォーマンスベース契約に関する調査研究」報告書
を読みました。そこには

　「KPIの測定・評価と見直しはサービスやシステムの調達・実行ののち
　　ユーザ/ベンダが共同で行う」
　# KPI(Key Performance Indicator)
　# 課題や情報サービスの価値を測定する指標

を要請していることが読み取れます。
なればこそ
>[2] Xによる最終的な価格決定はリリース後である。
>Uの手に渡らない限り、"望んでいた価値"に値するかはわからないから。
と書いたわけですが。

...困ったね。
経産省は商売のこと全然分かっていない上にやるきもないのか。

お世話になっております。＠IT自分戦略研究所 編集部の金武です。
エンジニアライフをご利用いただき、ありがとうございます。

議論が白熱しているようですが、コメント欄での攻撃的な発言は、
おやめいただくようお願い申し上げます。

議論をする際に不要である感情的な言葉、
意見そのものではなく発言者を批判・攻撃するコメントは、
本コメント以降のものについては、
議論の流れの有無にかかわらず、削除対象とさせていただきます。

どうぞよろしくお願いいたします。

>...困ったね。
>経産省は商売のこと全然分かっていない上にやるきもないのか。

ちょっと誤解があると思います。
経産省は「価格交渉は双方が行う」と書いてありますし、下記の様な記述もあります。

P13から抜粋
システム開発のみではユーザの事業や業務の成果に結びつけるのは難しいが、シス
テム運用等でのSLA によるインセンティブ（ペナルティ）契約の事例がある。このように運用業務までを含めた契約を行うケースでは、固定＋インセンティブ（ペナルティ）方式の親和性が高いといえるのではないか。

この様に様々な角度から検証されており、人月単価から脱却するように色々な用例を書いております。
他にもアウトプット型とインプット型が提示されております。
ですから、稼働されないと価格を決定できないといのは解釈が違うのではないでしょうか？
確かにインプット型は例として「システム稼働率、バグ数、応答時間、保守時間」が書かれておりますが、それはシステム開発側が想定するものを提示し、後でそれを下回ったらペナルティを支払うと解釈する方が妥当ではないかと思います。
また、人月単価のデメリットも開発サイドの売上減少と社会的地位の低下とはっきりと書かれております。
επιστημηさんが言っておられるのは、納品したシステムの評価（ペナルティもしくはボーナスを決定するかもしれない）であり販売価格を決定する時に行うものではないと思います。

他業種の人がこの一連のコメントを読んだら、「やはりこの人たちはお客を軽視し、自分たちの都合だけを考えている」と誤解するかもしれないので書きます。
確かに人月単価から脱却していない会社があります。
しかしながら、人月単価以外の基準で売買している会社も存在しますし、IT業界が経産省（大多数の意見）を無視しているわけではありません。
未だに経営上の問題から人月単価を採用しているところでも、徐々に移行していくでしょう。
また、大多数の真面目に働いている技術者達は、お客様を軽視しておらず、お客様のお役にたつために日々汗を流して働いております。

> επιστημηさんが言っておられるのは、納品したシステムの評価（ペナルティもしくはボーナスを決定するかもしれない）であり販売価格を決定する時に行うものではないと思います。

だから
> [2] Xによる「最終的な」価格決定はリリース後である。
> 出来上がったプロダクトがその条件を満たしているか測定/検証がなされ、
その結果に応じたインセンティブ/ペナルティで支払われる額が増減するかと。

と"きっちり"書いてますよ。

> 商売のこと全然分かっていない上にやるきもない。

と断じられるほどの欠陥がありましたかね?

>＠IT自分戦略研究所 編集部の金武さん

上のコメントの中ではどれが対象であるかは明示できないし、削除もしないということですね。
でもって、「直接」否定すれば、否定した側が削除されるというルールが追加されたとも考えられますね。
できれば、今後も削除せずに、削除対象だと明示していただきたいです。
そのほうが、どのような内容がＮＧなのか、誰がみてもわかるからです。
それが駄目なら、投稿者名や時刻はそのままに、内容だけを消す方向でお願いしたいです。

//////////////////////////////////////
ここから本編
//////////////////////////////////////

>インドリさん
>プロ意識のかけらもない。

正確に測ることが絶対的に不可能だと思われる、「価値」に対し、「時間」は誰でも理解できる単位です。
そして、高い技術力は「時間節約」という「利益」として明確に現れます。

「人月単価」にも大まかな相場が生まれています、100万前後が相場でしょう。
優秀な技術者を多く持つ会社では、開発時間が短くなり、見積もりに「利益」を盛り込みやすくなります。
ヘッポコさんが多い会社では、その逆で、見積もりに「利益」を盛り込む隙間が少ないですね。

「人月単価」でも技術の差は、価格に反映されるんですよ。

>いまどき働いたら働いた分だけもらうという発想は非常識。

少なくとも、会社であるなら、赤字になるような経営はＮＧですね。
そして、上の例のように、「働いたら働いた分だけもらう」ではないのですよ。
むしろ、求めているのは少ない労働力で大きな利益です。

>加えてお客様に価値を提供する気が全くない。

私は、ソフトの本質的な価値は仕様（アイディア）であると考えています。
仕様打ち合わせの段階でその価値を提供していますが、仕様打ち合わせだけでは報酬をもらえないことが殆どですね。
感情的には、その報酬を請求したいところですが・・・
お客からすれば、ものがあるわけではないですし、実際に運用するまでは、期待していた価値があるかどうかわかりません。
結局、仕様を検討した「時間」を請求することしかできないのが現実ですね。
お客のことを考えれば、妥当だと思っています。

また、そのように考えているため、お客が仕様を用意してある場合は、こちらから提供するのは労働力であると思うのです。

ＰＳ．
>P13から抜粋
επιστημηさんが張ってくれた
http://www.meti.go.jp/press/20090731004/20090731004.html
この資料の中を検索しても、同じ文章が見つからなかったので変だなと思ったらー

http://www.meti.go.jp/press/20080425004/20080425004.html
こっちのP11（ページ番号）ですね。

同じ資料を基に会話しないと話がズレますね(^^;

そか、仕様書作成までを依頼された場合なんかは「創出された価値」の算出が難しいわなぁ。
# 実装/テストは安いオフショア使ったりね。

コンサルタントに支払う額の算出ってば、確かに拘束時間が主軸になりそ。
拘束時間すなわち人月単価だもんね。

>と断じられるほどの欠陥がありましたかね?
はい。いったほどの効果がない場合、ペナルティを受けるという単純な方式を曲解して、価格は決められないとＳｏｄａさんとともに人月単価に誘導しようとしました。
これは曲論すぎます。
人月単価を支持したいがために、経産省が言っていることを曲げるというのはいけない行為です。
国が言っていることを曲げるというのはかなり問題があります。
加えて作ったものの性能が悪ければ、ペナルティを受けるという商売の基本を無視しているからそう言いました。

経産省はコンサルタントについても言及しています。
人月単価を支持したいのは、個人の意見としての勝手だと思うのですが、それを真っ向から反対している経産省（国や大多数の声）を無理やり曲げて、人月単価普及活動に励むのはいかがなものかと思います。

※2012年1月11日10時48分、本コラム内容に関係のないコメント削除

>少なくとも、会社であるなら、赤字になるような経営はＮＧですね。
だから私は人月単価に反対しています。
経産省も人月単価のデメリットとして売上減少を唱えています。
人月単価が売上を下げるのは商売人ならば誰しも考えることです。
このように、経産省の意向を無視するのは非常に問題です。
経産省とは正反対のことを、経産省が導き出しているかのように言うのは非常に問題がある行為です。

わからんなぁ。
インセンティブ/ペナルティを含めないと「最終的な価格」は決まらん言うてます。
インセンティブ/ペナルティはユーザの手に渡るまでは決めようがない言うてます。
これがおかしいですか? どこがおかしいですか?

> 加えて作ったものの性能が悪ければ、ペナルティを受けるという商売の基本を無視しているからそう言いました。

その根拠はどこですか? 引用して示してください。

> 貴方は個人的な攻撃だと言いましたが、

その部分を引用してください。

※2012年1月11日10時53分、本コラム内容に関係のないコメント削除

>わからんなぁ。
価格そのものは販売の時に決定しています。
ですから、性能を偽らければペナルティを受ける筈もありません。
また、ボーナスが発生するのであれば、売上が上がるのですから何ら問題はありません。
私が言っているのはそういったプロ意識です。

>その部分を引用してください。

引用
>意見にケチつけるのはかまわんが
>人にケチつけるのはやめようや。

※2012年1月11日10時54分、本コラム内容に関係のないコメント削除

ご理解いただけていないようなのでもう一度いいます。
経産省の見解を持ち出し、それを使って正反対の結果に誘導するのは非常に問題がある行為です。
「IT業界の人間は非常識」だとか「国に逆らう危ない業界」だと思われるので止めて頂きたいです。

> 価格そのものは販売の時に決定しています。
> ですから、性能を偽らければペナルティを受ける筈もありません。
> また、ボーナスが発生するのであれば、売上が上がるのですから何ら問題はありません。
> 私が言っているのはそういったプロ意識です。

「私は製品に自信を持っています。お客様、どうぞお試しください。
　お値段はお客様がご自身で判断してください。
　気に入らなければ減額してもらってかまいません。
　予想以上の出来ならば増額してください。」
これじゃダメですか? プロ失格ですか?

どっちが正しいとか、そんなんじゃないと思えますが。

※2012年1月11日10時58分、本コラムの内容に関係のないコメント削除

>これじゃダメですか? プロ失格ですか?
それを使って、人月単価に誘導しているということは、それができないということを意味します。
すなわち、あらかじめ価格を設定して、お客様に実際の評価をしてもらうことが問題ならば、それは自信がないということであり、それではおかしいのです。
お客様に評価を強いるなどといい、人月単価のほうがよい（卒業できていない）と言及しています。
ですが、商品を評価するのは当たり前の行為であり、お客様の手間を削減するために業者側も協力をするべきだと経産省が指摘しています。
ですからプロ意識の欠如ではないかと指摘しています。

※2012年1月11日11時01分、本コラムの内容に関係のないコメント削除

お世話になっております。＠IT自分戦略研究所 編集部の金武です。

2012年1月11日11時ごろ、本コラムの内容に関係のないコメントを削除いたしました。

本コラムのコメント欄は、コメント投稿者同士の個人的な言い合いのために
公開されているわけではございません。
本コラムにコメントを投稿する以上、
コラムニストであるAhf氏への敬意を
お忘れいただかないでくださるよう、心よりお願い申し上げます。

「本コラムのテーマに沿ったもの」でないコメントについては
本コメント以降、ご投稿はお控えください。

どうぞよろしくお願いいたします。

誠に失礼いたしました。
Ahfさんはもとより運営スタッフにご迷惑をおかけし、
読者の皆様に不快な思いをさせたことに深くお詫びいたします。

失礼致しました。
そういった行為が今後なければ幸いです。

※2012年19時50分頃、コメント投稿者の希望により一部内容を削除

お世話になっております。アイティメディアの金武です。

ご理解とご協力いただき、心より御礼申し上げます。
また、編集部への貴重なご意見についても、ありがとうございました。
いただいたご意見は真摯に受け止め、
エンジニアライフのサービス向上に努めてまいります。

今後ともどうぞよろしくお願いいたします。

>インドリさん
>>少なくとも、会社であるなら、赤字になるような経営はＮＧですね。
>だから私は人月単価に反対しています。

なんでそうなるのか、わかりませんが・・・
「人月単価」つまり、作成費＋利益を使う場合は、基本的に赤字にはなりませんよね？

>経産省も人月単価のデメリットとして売上減少を唱えています。

「人月単価」だから売り上げが低いというわけではないでしょう。
PBCにすることで、売り上げが上げれるかも？って話ですよね？
これは、

「自分たちが提供するものは、もっと価値があり、価格も高いはずだ！」

という前提ですよね？

「価値」というのは、残酷なほど流動的であり、同じものでも、提供時期が違うだけで大きく変わります。
よくある話で、フリーソフトと比較される例があります。

「とあるフリーソフトと類似した機能が欲しい」

お客が連想する価値は「無料」に近いものですよ。
いや、世間的な価値も「無料」に近いことでしょう。
長く営業に近い位置にいた人なら、一度は経験する話ではないかと思います。
ほんの少しの違いしかない・・・価値は差分で考えられてしまうでしょう。

１０年前や２０年前と違い、ソフトも豊かになりました。
お客や世間がソフトに感じる「価値」は相対的に低くなっているのですよ。
IT系に比べて、比較対象が少ないFA系ですら、ソフトの「価値」は減少傾向だと感じます。

PBCが「人月単価」に比べて、ハイリスク、ローリターンの時代になっているわけです。
だからこそ、生まれたのが「労働力」を売る商売です。
「人月単価」の問題は、

「労働力」を売っているのにも関わらず「商品」を売っていると思っている。

という誤解の元にも発生します。
求人等をみるとわかりますが、IT系だと派遣会社の求人が多いですね。
これはIT系で売っているものは「労働力」が増えているということにならないでしょうか？

「プロ意識」の話が出たけども、高価値のプロダクトを産むのもプロだけど、
一定品質のプロダクトを産むのもプロの心意気やと思うんですわ。
お客の我儘/無理難題、無茶ブリに近い要求にもそれなりに応えるだけの技量というか。
それを提供できるから人月ベースで給料もらえる。
「今月はヒマだったからサラリー半分な」とか言われずに済むのは
人月ベースのおかげです。
その代わりめっちゃ忙しくてもお値段変わらずだけども、
安定した収入は大きなメリットです。それを選ぶのにケチはつけられんでしょう。

売上が下がるメカニズムは、経営者じゃないと分からないと思います。
それと、
>「労働力」を売っているのにも関わらず「商品」を売っていると思っている。
労働力を売りたくないから人月単価は反対だという技術者が沢山います。

価格が減るのは技術力がなくなったからです。
人月単価でお客様に甘え、ぬるい体質から技術力の空洞化が問題になっております。

※2012年1月12日12時45分、感情的な表現部分について一部コメント削除

こういった議論では「感情」は極力排除しましょうよ。

「技術者に対して失礼」「悪い意味のサラリーマン根性」
「プロ意識がありません」などなど、感情をよりどころにされましても...

感情論/精神論は抜きにして「安定した収入はよいことだ」に異論はないでしょう。
毎月末にきちんと約束の額を振り込んでくれるお客様はよいお客様です。

で、「PBC:創出された価値ベース」であるとこれが揺らいでくる。
リリース後のKPI測定/評価の結果次第で翌月(?)に増額/減額されます。
増額なら嬉しいけど減額されるかも。
手にした現ナマを安心して支払いや投資に回せません。

επιστημηさんとの意識のギャップが激しいとお見受けします。
感情論として受け取る自体が事態を把握しておられません。
お金を支払うのは一体誰なのでしょうか？
その大切な人を国に訴えかけるまで不快な気分にさせて儲かると思いますか？
また、プロは誰かにために商品を提供する人の事です。
ご自身の事だけを考えて作るのはアマチュアだと呼ばれます。
επιστημηさんはご存じないようですが、「継続的な安定した収入」が得られないので人月単価は忌避されています。
自営業者の立場から検討しても何のメリットもありません。
経産省の資料にも「売上が減少する」との結論が出ています。

総務省の見解と方向性が同様のAhfさんのコラムの趣旨と正反対の事を述べるのであれば、ちゃんと議論になるようにするべきだったと思います。

※2012年1月12日12時47分、感情的な表現部分について一部コメント削除

> 感情論として受け取る自体が事態を把握しておられません。

だったら感情論として受け取られかねない言い回しは避けてください。

> 総務省の見解と方向性が同様のAhfさんのコラムの趣旨と正反対の事を述べるのであれば、ちゃんと議論になるようにするべきだったと思います。

そうでしょうね。僕は正反対のことを主張するつもりはありません。
むしろAhfさんのコラムに同意しています。

コラムの結語にある:
　「相手ありきの商売ですので、開発側だけの都合でどうこうできるものとは
　　言いがたいですし、使う側だけの都合というわけにもいかないでしょう。」
そのとおりです。人月単価に代わるよりよいやりかたがあるかもしれないし、
そのひとつが経産省の示したPBCなのでしょう。

問題はその「実現可能性」だと考えます。実際にはPBCはなかなか広まっていません。
なぜなんだろう。PBCの持つ問題/課題は何なのか、人月単価の持つメリット
(それがなきゃとっくに駆逐されているはず)は何なのか、そんなこんなを
コメントしているつもりです。きっとＳｏｄａさんも。

>だったら感情論として受け取られかねない言い回しは避けてください。
その様な言い回しをした覚えはありません。

>問題はその「実現可能性」だと考えます。
PBCそのものを採用する必要はありません。
あれはあくまでも資料であって、資料だけを見て普及していないというのはちょっと違うと思います。
デメリットを超える人月単価のメリットはどう考えてもありません。
唯一あるとすれば「いままで通りの方が楽だから」だと思います。
実現指定会社が存在しますし、実現不可能だとの結論には至りえないと思います。
ですから私は何度も、実現可能性ならば実現している会社がいるから可能だという結論が出ていると言っております。
何時減可能性ならば、「実現している会社が存在する」で存在証明されているのですから結論が出ております。
従って、
>この問題への対応は長い時間をかけて、ゆっくりと変化していくのではないかと
>私は思います。
というAhfさんの言葉に集約されると思います。

それはそうと、Ahfさんのコラムのコメント欄で、その様な検討をしてよいのかという疑問があります。
結論が出てからお書きになった方がよろしいのではないでしょうか？
そうしないと、επιστημη 2さんとSodaさんの会話でここが埋まります。

失礼しました。

誤：実現指定会社が存在しますし、
正：実現している会社が存在していますし、

誤：何時減可能性ならば、
正：実現可能性ならば、

誤:επιστημη 2さん
正：επιστημηさん

失礼しました。

>> この問題への対応は長い時間をかけて、ゆっくりと変化していくのではないかと
>> 私は思います。
> というAhfさんの言葉に集約されると思います。

同意します。
「何故にこんなにスローペースなの?」が僕の一連のコメントの源泉です。

> Ahfさんのコラムのコメント欄で、その様な検討をしてよいのかという疑問があります。

その判断はAhfさんに委ねることにしましょうや。

インドリさん、あなたが思っている以上に「感情」が文章に表れています。
少し控えるか、投稿する前にもう一度読み直すクセをつけたほうが良いと思います。

多くのコメント有り難うございます。
紆余曲折あったとは思いますが、私のスタンスとしては
「皆さんが思われている点をぶつけ合うことで、よりよい方向へ進む」
ならば
「わたしは一向にかまわんッッ」
という考え方でいます。勿論、個人的な攻撃など避けて頂きたい点がありますが
そのあたりは皆さん了承されたうえでお願い致します。

「なぜスローペースなのか」に疑問・不満を持つのは私もです。
おかしいと思う人は世の中に多くいらっしゃるのだと思うのですが、なかなか
形になって変化しているとは思えない状況ですよね。
極論すると「会社勤めやめて独立すれ」になってしまうのかも知れませんが
それでは業界としても幸せにはなれないのではないでしょうか。

このあたり、意外と技術的な話題の啓蒙と同じく、根気強く周知させていくのが
求められているのかもしれない、などと考えたりします。

>Ahfさん
>「なぜスローペースなのか」に疑問・不満を持つのは私もです。

それだけ、「人月単価」が実運用では問題ない程度に、ものさしとしての役割を果たしているということじゃないかなと。
変える必要性がないものは変えないってのは、それなりに大事なことですよね。

>おかしいと思う人は世の中に多くいらっしゃるのだと思うのですが

不満として提示しているのは、派遣関係じゃないかなと思うのですよ。
派遣社員は派遣会社から「労働力」として明確に提供されるのに対し、本人たちは技術者であるというプライドもあります。
どちらも間違っていないのですが、結果として認識のズレが生じるのではないかと(^^;

「受託開発」で、開発側がソフトに価値があると思う場合、「人月単価」でも「開発日数」という形で調整可能ですよね。
「通常なら○日かかるはず」という日数で提示し、技術力により、予定よりも早く完成させることで利益を得る。
・・・というか提示日数より早く完成させることでしか利益を得られないわけで、当たり前の方法ですが(^^;

潔癖な人、もしくは、商売というものがどんなものか、わかっていない人には「詐欺」に見えるのでしょうがー
これが、ソフト産業における「企業努力」なわけです。
判り易い例で言えばー

Ａというお客の注文が、Ｂというお客用に開発したシステムと類似していた場合。
規模は同じぐらいだが、Ｂで開発したノウハウがあるので、Ａの開発時間は半分だったとします。
「人月単価」の実体を知らない人達が、この状況を想像した場合・・・

「Ｂの見積もりはＡの半分になり、価値は等しいのに価格が半分になって納得できない」

となって、問題だとされがちですが・・・
実際は、Ａとあまりかわらない日数として見積もられます。
差額の日数は利益になるわけです。
この例で出した価値とは、作成する手間であり、これは開発側が主張可能なものだと思います。

利益 = 売値 - 原価 は曲げようのない原則。
ならば利益を上げるには「高く売る」か「安く作る」のどっちかしかない。

１コ300円のショートケーキ作ってる菓子屋の職人が技と工夫で
今までの半分の手間でいつもと変わらぬケーキを作り出した。
そのおかげで原価が下がる。んで儲かる。

これにお客が文句つけるか?
手間が半分になったことに気づきもしないし、それを知ったところで
ケーキの旨さ(=価値)が変わらぬ限りケチのつけようがない。

# お客様は、「人月単価」というモノサシが字面通りの「人月単価」
# でないのはお見通しじゃないのかな、とも思うなり。

結局、原価の殆どである人件費をどこかで回収できないと赤字になるわけでー
赤字になるかどうかはっきりわかる「人月単価」は、その点が最大の利点になるんですねぇ。

サービス型のシステムで、月額固定料金が設定できれば、類似した予想は可能です。
最低何ヶ月使うという縛りを入れることが可能であれば、原価が保障でき、
さらに、それ以降は利益のみを生み続けることができるはずです。
ただし、お客からの入金は遅くなりますし、この手の料金体制はお客側としても採用しにくいです。
お客は、永続的に発生する経費は避けたいんですよねぇ(^^;

FA系だと、ハードに付属するソフトなどは、ライセンス方式が採用されたりします。
初期経費＋１台ごとのライセンス料です。
ハードが何台ぐらい売れるものなのか予想することで、初期経費やライセンス料を調整します。
初期経費には「人月単価」による作成コスト、ライセンス料にはソフト本来の価値が検討されます。
ハードというものが存在するので、比較的、抵抗なく受け入れられている状況・・・かな。

といっても、ソフトの価値が認められるようになってきたのは、比較的最近だったりも(^^;
昔はソフトなんてハードのオマケでしたから・・・お客からみたらハードに付属して当然なんですよ。
ハードに金を出すのであって、ソフトに出している気は無いわけです。
これは、TVやレコーダーの中身のソフトを想像してもらえばわかりやすいですね。
かなしいことに、末端のお客からみた価値は０に等しいのです。

PBCに移行したいなと思う場合、まずは、価値を認めてもらうところからですね。
ただ、やっと認められた価値も、価値が高いのは、類似品がでるまでです。
他の会社が当たり前のように付けている機能の価値は、付けて当たり前、無ければマイナスになるだけです。
これ、判り易い例は、マウスです。
DOSの時代はマウス対応ってのが１つの機能であり、価値だったんですが・・・
いまやマウス対応の価値は皆無というか、無いと操作できないことも多いですねｗ
逆にキーボード対応のほうが価値として高くなっているのではないでしょうか？

PBCというか、価値を主体に商売ができる状況ってものすごく限られていると思うのですよ。
少なくともIT系にあるような派遣業者ではPBCは実現できないでしょう。
派遣業者が扱う「人月単価」は果てしなく「時給」に近いものですから・・・

あと・・・実力がある個人事業者、いわゆるフリーランサーですかな？
この方々は、「言い値」で商売が可能ですね。
作成側の価値観が全面的に出せるわけですが・・・買う側はその価値が正統なものか判断しにくい。
だから、見積もり詳細として「人月単価」が自然発生したわけですがー
高い信頼関係により詳細が不要とされているケースもありますね。
そうでなくても、一人なわけですから、製作日数、つまり納期がでれば、それが「人月単価」になるわけです。
言い方を変えているだけで、買う側からみたら同じものですね(^^;
2012年1月 8日 (日) 04:49のεπιστημηさんが提示している内容と近似していると思います。

落ち着いたところでしばらく考えていたんだが、
自分の中で答が見出せないトコが少なからずあるわけよね。

> :インドリ 2012年1月11日 (水) 09:58
> ...
> すなわち、あらかじめ価格を設定して、お客様に実際の評価をしてもらうことが
> 問題ならば、それは自信がないということであり、それではおかしいのです。

「お客様が得るであろう価値をわしらが見積もる」ことに正直自信が持てんのですよ。

たとえばね、基本設計までを依頼されたとしましょうか。
それ以降の詳細設計/実装/テストはどっかヨソにお願いする、と。
で、ぼくらはこれにどんな値付けができるんだろう。
お客に提供されるものはぶっちゃけ「紙切れ」じゃないですか。
これを基にコード書いてハコの中に納めて初めて"お客にとっての"価値を
産むわけっしょ。

そんなもん、どう値付けするんだ?
完成品なら1000万くらいだろうからその５割?
んじゃ５割の根拠はなんだよ? 工程の半分までだから?
それってまんま人月単価じゃーん! ってことになりゃせんかしら。

人月単価を卒業したインドリさんがどんな答をお持ちなのか、ヒジョーに興味あります。

またしても連投ごめん。

↑のオハナシ。
基本設計までの前工程が産み出す価値はお客様に対するものじゃないね。
後工程を受け持つヨソ様に提供される価値だよね。
後工程にとってはこれこそが原料なんだから。
ならば前工程にとってのお客様は後工程ね。
さて、どんな価格交渉が行われるんだろう。
# ...同業者間で血みどろの戦いが繰り広げられそうな予感。

επιστημηさんは、人月単価がお客様の不信感を生んでいる事を失念しております。
人月単価でも変わらないと何度も言っておられますが、お客様が不信感を持っている価格設定法でよい筈がありません。
質問の件に関しましては、内容にちょっと無理があるかと思います。
エンドユーザーが設計と実装を分けて発注すると想定されているようですが、無理があります。
システムの価値に応じて投資をしたいお客様が、設計と実装を分けて発注する筈がありません。
設計しかできないもしくは実装しかできない会社に対し、お客様が価値のあるシステムを求めて発注するというのは考えにくいです。
無理があるのでちょっと想像力を広げて、実装会社が設計会社に依頼したケースを想定します。
実装しかできない会社が設計を他社に頼む時点でシステムを分かっていないという事になります。
ということは、実装しかできない会社は、設計も出来ないシステムをお客様に提案した事になります。
その時点でアウトだと思います。
また1000万円ぐらいの小規模のシステムで、他社に依頼するというのは採算が合わないと思います。
※1000万円はシステムでは最低の金額です。
逆の方ならばありえますが、その場合はシステムの価値（儲け）に応じて、依頼をする価格を設定すると思われます。
むしろ他業種ではそれが普通です。

> エンドユーザーが設計と実装を分けて発注すると想定されているようですが、無理があります。

ごく自然ですよ。「ウチは設計しかやりません」てソフト屋はいくらもあります。
# NTTデータは昔それが売り文句でした。

> 実装会社が設計会社に依頼したケースを想定します。

その逆は? うちとこはそうですね、多くの実装を外注さんにお願いしてます。
なんにせよ多種多様な契約形態に対応できないのはまずいよね。

> また1000万円ぐらいの小規模のシステムで...

関係ないでしょ。なんなら10億でもいい。
分け前(配分)をどうやって決めましょうか。

個人のフリーランスは典型例でしょうよ。
「ちょっと人足りなくてさ、コーディングだけ手伝ってくんない?」「喜んでー♪」
コーディングだけ請け負ったフリーランスの分け前は?
このフリーランスはお客(発注元)に出す請求書に何て書くの?

> επιστημηさんは、人月単価がお客様の不信感を生んでいる事を失念しております。

忘れちゃいませんよ。

> 人月単価でも変わらないと何度も言っておられますが、
> お客様が不信感を持っている価格設定法でよい筈がありません。

だーかーらー。
人月単価に代わる/互いに納得できる/契約形態に関わらず広く適用できる
そんなものが作り出せない限り運用できんでしょ。
で、そんなものそう簡単にはいかないよね。と、
想定される"うまくいかない例"を挙げています。

「人月単価はダメだダメだ」じゃ(現時点では)不確かなものに
鞍替えするわけにはいかんでしょ?

うまく運用できている事例もあるでしょうよ。
しかしそれが他の場合にできるという保証はどこにもないでしょ。
「やればできる」じゃダメなのよ。「こうすればできる」じゃないと。

人月単価、難しいですよね。２～３、気になった点を挙げます。

> 金額以上の価値を提供できている事例はかなり少数なのではないか、とも感じます。
　これは、Ahfさんがそうだとおっしゃっていますか？「全体的にそうだ」というのであれば、失礼ではないかと思いました。
　ご存知だと思いますが、開発者が開発にかけるお金の他に、会社の場合は、会社の非生産者、つまり開発者が開発に専念できるように事務や営業を担当する人の経費もかかります。それらもまとめて否定されているように思いました。

> 突き詰めると人月の問題というのは、開発側が提供する価値に対してどのような
> 金額的価値を認めるか、という点に纏められるのではないでしょうか。
　突き詰めて、ここに至る過程が、よく分かりませんでした。私が至ったのは、こちらでした。
↓
> このような状況下で考えられた「人月」という算出方式は、実際のところ非常に
> 簡略化されており、ユーザー・ベンダ双方にとって「なんとなく」イメージしやすい
> ものであると思います。
　ん？私が至ったのは「人月とは」で、Ahfさんが至ったのは「人月を用いることの問題とは」？であっても、わからないですね。

> 　本来であればシステムやソフトウェアの価値に対して金額を決める、
> または決めてもらうというのがあるべき姿なのだとは思います。
> ですが一般に販売されるあらゆる物を見回すと、ITシステムだけが
> かなり特殊な金額付けを行っているのではないでしょうか。
　そうですか？
　例えば、私は事情があって分譲マンションを購入後、それを売却し、中古一戸建てを購入しました。どちらの購入金額も、私が決めたわけではありませんよ？「価値に対して」と言うことでいえば、分譲マンションに対する私の価値と、義父の価値は違っていました。今住んでいる一戸建ても同じ。購入した、お金を出したのは私ですが、その金額は、私が考えている価値よりもはるかに高いです。義父にとっては妥当な金額のようですが。こういう「価値に対する考え方の違い」は、どうしましょうね？人によって違うなら、誰が価値に対して金額を決めるのでしょう？
　それとも、家屋は「店頭販売」の部類に入るのでしょうか。たいていの分譲マンションや、住宅の場合、モノが完成する前に、設計図だけで金額を決めます。できあがったモノが、設計図通りかどうかはわかりません。事実、私が購入した分譲マンションは、設計図通りに造られていないことが、完成から4～5年してからわかりました。これは、IT システムと類似していませんか？というか、建築業界の考え方を、IT 業界に持ってきた、と聞いています。

　「価値」というモノを、どこに、どれほど見いだすかは、人によって変わるのではないでしょうか。住居がわかりやすいと思うので続けますが、電車で通勤する私にとって、駅に近い物件は価値が高いです。しかし、車で通勤する妻は、私と同じ価値をつけません。私は「断熱性」に高い価値を付けますが、義父は「採光性」に高い価値を付けます。この二つも、相反することが多いです。つまり、窓を多くすれば採光性は高まりますが、断熱性は下がります。
　他の例を使いましょうか。野菜。品薄になるから価値が高くなる。これはわかりますね。では、Ａ品とかＢ品とかいう言葉を聞かれたことはありますか？これ、主に形によって分けられます。見栄えがよいのがＡ品。Ｄ品までくると、普通は店頭に並びません。しかし、味や栄養価は同じです。もっとも、加工（皮むきだとか）のし易さ、運搬性という面では、Ａ品の価値は高いです。しかし、形が悪いからといって、食べ物の価値は下がるのでしょうか？桃などの場合、優、秀と、糖度や大きさによって分けるので、こちらは納得がいくかもしれませんね。もっとも、「優れる」と「秀でる」の、どちらが上なのか、よくわかりませんが。
　同じ事は、開発の現場でも発生していませんか？「これこれの備品を買って下さい」「高いからダメ」とか、「こっちの方が安いから、こっちにして」とか。これは、欲しい人と、財布を握っている人との間に、モノの価値に対するズレがあるから発生しているわけですよね。
　あるいは、芸術品、デザイン。これらの価値は、誰が、どうやって決めるのでしょう？絵画の価値など、どうやって決まるのでしょう？というか、「すばらしさ」というのは、誰にとっても同じなのでしょうか？私には、「IT システムだけがかなり特殊」だとは思えません。

↑いいことゆー。

物価ってじわじわ上がっていってますね。
それに伴いそのモノの価値が上がっては...いませんよね。
本当にそれが持つ価値だけで値付けされたものってあるの?
買い手によって変わらない普遍的な価値ってあるの? 思います。

オークションはある意味理想的なカタチに近いかな。
各人がそれぞれの価値観で値を付け、それだけの金を払っても惜しくない!
と思った人が手に入れるのだから。

επιστημη さんへ
>忘れちゃいませんよ。
忘れておられます。何故ならば、自分ベースで「人月単価以外ではやっていけない」と誘導されており、お客様からみた話をされておられないからです。
私はこの点を問題視しております。
人月単価はIT業界側の都合（それ以外思いつかなかった）を押し付けたものです。
そういった押し付けを続けているのが、IT業界が人月単価脱却を果たせない理由だと思います。
経産省に指摘をされ、未だに問題を解決できていないというのは、非常に憂慮するべき事実です。

>このフリーランスはお客(発注元)に出す請求書に何て書くの?
発注する会社が利益率を考えて価格を提案し、プログラマが自分の価値を考えて価格交渉します。
それは普通の事だと思います。
人月単価だと高い生産性がある人が適切な請求をできません。

>うまく運用できている事例もあるでしょうよ。
であるならば、人月単価以外でもやっていけるという事を意味していると思い。
それでよいのではないでしょうか？
何故あなた様が、「人月単価でないとやっていけない」と主張され続けているのかがわかりません。

>想定される"うまくいかない例"を挙げています。
>「やればできる」じゃダメなのよ。「こうすればできる」じゃないと。
貴方は経営者なのですか？
経営者が考えることであって、貴方が考えるべき事ではないと思いますが・・・
それに、価格設定は「各社工夫を凝らすべきもの」です。
全社共通の価格設定を考える事自体が間違いです。
どの業界の人もかなり工夫されておりますよ。

>その逆は? うちとこはそうですね、多くの実装を外注さんにお願いしてます。
>なんにせよ多種多様な契約形態に対応できないのはまずいよね。
外注するのに自信がないというのは凄く問題だと思います。
通常の会社は外注する際に自社の利益率を考え、金額を定めて発注します。
価値ベースだとそれが出来ないと主張されているので、不自然なケースだと感じました。

>価値について
お客様は投資目的でシステムを購入されております。
だから価値という話が出てくるのであって、そういった美術的な物とは違うと思います。
ただ、美術的な価値があるのであれば、それをお客様にご納得していたければよいと思います。
美術的な価値は人月単価では実現できないものです。
それこそ価値ベースであるべきです。

> 人月単価だと高い生産性がある人が適切な請求をできません。

「俺はひと月500万」て言えばよくね?
実際にそれだけのパフォーマンスが出せ、お客が納得するなら。

>> うまく運用できている事例もあるでしょうよ。
> であるならば、人月単価以外でもやっていけるという事を意味していると思い。

ごめん。理解できない。

>> 想定される"うまくいかない例"を挙げています。
>>「やればできる」じゃダメなのよ。「こうすればできる」じゃないと。
> 貴方は経営者なのですか？
> 経営者が考えることであって、貴方が考えるべき事ではないと思いますが・・・

「部外者のお前が口出すな」と。

...なんか言葉の「断片」に反応されてる気が。

>「俺はひと月500万」て言えばよくね?
>実際にそれだけのパフォーマンスが出せ、お客が納得するなら。
いいえ。パフォーマンスベースで、「俺には500万円の価値がある。何故ならば・・・」と価値ベースで価格を設定するのと、「1月働くから50万円だよね」というふうに人月単価の労働力で売るのとは天と地の差があります。

>ごめん。理解できない。
価値ベースで上手く運用できているケースがあるのであれば、それは人月単価でなくてもやっていけると証明されている事になります。
従って、貴方様が「人月単価でしかやっていけない」と主張する意味がないと思います。

>「部外者のお前が口出すな」と。
>...なんか言葉の「断片」に反応されてる気が。
いいえ。貴方様が自分では思いつかないから、人月単価でやっていくしかないと自説を展開しておられますが、実際に価値ベースで経営しているところがあると経産省が指摘しております。
ですから、貴方が思いつかないからと言って、人月単価を脱却できない理由はありません。
ここで永遠とコメントせず、経営者に任せればいいと思います。
経営について知らないのであれば、ここでコメントし続けても分からないと思います。
つまり私が言いたいのは、「Ahfさんの結論で終わりにしておければいいのでは？」という事です。
一度はAhfさんのコラムに同意したのですから、スローペースな理由を探すなどと理由をつけてコメントし続けないで、「Ahfさんの意見に同意する」でとどめておけばいいと思います。

> パフォーマンスベースで、「俺には500万円の価値がある。何故ならば・・・」と価値ベースで価格を設定するのと、「1月働くから50万円だよね」というふうに人月単価の労働力で売るのとは天と地の差があります。

ん? これは「価値をきちんと評価した人月単価なら文句なし」ということですかね?

ビル君 1000[千円/人月] と スティーブ君 1500[千円/人月] のふたりで三ヶ月
仕事してもらうなら　
1000+1500[千円/月] * 3[月] = 7500[千円」
みたいな。

がると申します。
色々と興味深い話が並んでおりましたので、少しお話に参戦させていただければ、と思いました。

> エンドユーザーが設計と実装を分けて発注すると想定されているようですが、無理があります。
これはどうなんでしょうかねぇ？
「エンドユーザが」というよりも、受注者(作成者)である私のほうから、明示的に「契約わけてください」ってお願いしていますが(主として防御的理由で)。
理由は比較的簡単で、どうしても設計は「準委任契約による、時間給」にならざるを得ず。一方で、実装は「受託契約による、完成報酬」のほうが相性がよい、と考えているので。

> 人月単価がお客様の不信感を生んでいる事を失念しております。
さほど「諸手を挙げて歓迎している」とは思っていないのですが、一方で「明示的に"お客様の不信感を生んでいる"というほどの不快感をあらわにされた」経験が、実はあまり(というか全然)ありませんで。
もし詳しいお話など、少し伺えると、とても興味深いです。

> 人月単価だと高い生産性がある人が適切な請求をできません。
と
> 「俺はひと月500万」て言えばよくね?
> 実際にそれだけのパフォーマンスが出せ、お客が納得するなら。
この辺は…「よしあし」の一言では片付けにくいと思うのですが。実際問題として「単価で500万よこせ」は、多分、あんまり通らないですね(苦笑
ただその一方で「それでしたら10人月でのお見積もりになりますので、単価50万として500万になります」で受注して「一人で片付けて総取り」というのは、まぁ数字はともかく、ある程度、あちこちで行われているのではないでしょうか？
ですので。ある程度適切な請求に「なるように」運用している、とも見えますし、一方で「本当に納得させられているのか」については疑問に思うことも少なからずあります。

ただ、それにしても「適切な請求」の基準には、どうしてもどこかで「時間」というファクターが、これは入ってこざるをえないのかなぁ、とは考えているのですが。
(「全面的に時間のみを重要視する」のはおかしいにしても「時間というファクターを完全に無視する」のも難しいと思ってます)。

「人月がまったく絡まない」やり方ですと、個人的には「レベニューシェア」を想起するのですが。
レベニューシェアですと。もし「提供したシステムの価値 == そのシステムが儲けた金額(の一部：営業さんとか運用さんとかのコストもありますし）」という条件式がtrueであるとするのならば、「売り上げを元にした収入」なので、非常にクリアかつみもふたもない、とは思うのですが。
その場合次に「売り上げが上がらなかったばあい、それは企画に問題があったのかシステムが悪かったのかデザイン/UIの責任なのか運用で下手打ったのか」などなど、やっぱり、考察する(あるいは疑う)変数が結構出てきてしまうので。
最低限「企画から運用まで、一通り口が出せる場所にいないと」不満がたまることしきり、だと思います(苦笑

エンジニアの「価値」の問題は、「顧客とエンジニアとの関係性」だけでなく、「エンジニアの内省と成長」という観点からも非常に興味深いテーマだと思うので。
しばらく、コメント欄など拝見できればと思ってます。

以上、主観的な感想が多くて恐縮ですが。

>> 「俺はひと月500万」て言えばよくね?
>> 実際にそれだけのパフォーマンスが出せ、お客が納得するなら。
> この辺は…「よしあし」の一言では片付けにくいと思うのですが。実際問題として「単価で500万よこせ」は、多分、あんまり通らないですね(苦笑

デスヨネー
会社という集団で請け負うなら5人かき集めて「俺たちゃひと月500万」はアリよね。
内実は凄腕の1人とヒヨコ4匹でね。

ただし。お給金が凄腕の総取りにならん、手柄と褒美のアンバランスが生まれることで。
- 凄腕はどんなに手柄立てても褒めてもらえん
- ヒヨコはなーもせんでも凄腕と大差ないお給金をいただけちゃう
問題はそこらへんにあるんだろうな。
# んでもこれってわしらギョーカイに限った問題じゃないしー。

がるさんへ
>これはどうなんでしょうかねぇ？
エンドユーザー（発注側）は価値をあるシステムを求めています。
受注者（技術者）は価値があるものを提供します。
その関係でなければ商売は成り立ちません。
ですから、設計と実装に分ける事態が間違っていると思います。
百歩譲って会社の都合で分けるにしても、お客様にとっては完成品にしか興味がありません。
システムをどのように作るのかは制作側の都合です。
その都合を全面的に押しだす価格設定法は間違いです。
他の業界の人も色々事情がありますが、その都合だけを押し付けて価格設定をしておりません。
> この辺は…「よしあし」の一言では片付けにくいと思うのですが。実際問題として「単価で500万よこせ」は、多分、あんまり通らないですね(苦笑
IT業界が人月単価に縛られているから出る発想ですね。
人月単価（人と時間）に縛られていてはそういう発想になります。
それこそが問題の本質です。
>さほど「諸手を挙げて歓迎している」とは思っていないのですが、一方で「明示
>的に"お客様の不信感を生んでいる"というほどの不快感をあらわにされた」経験
>が、実はあまり(というか全然)ありませんで。
腰が重い経産省が発表したというだけで分かると思います。
実際にお客様と本音を語り合えば分かると思いますが、人月単価は信用に値しないと考えられていますし、人月単価は現実離れしているのは事実です。
そもそも、自分が作る商品の価値を説明できないという時点でおかしいのです。
技術者ならば、時間と品質が必ずしも比例しない事は良くご存じだと思います。

επιστημηさんへ
># んでもこれってわしらギョーカイに限った問題じゃないしー。
なるほど。自分だけじゃないからそのままでも良いとお考えなのですね。
若者のIT業界離れが進むわけだ。
この深刻な状況を把握しておられないと感じました。
業界の問題だと発言されたり、ふざけたりと言動が一貫していませんね。
ようするに、「今のままでいい」としか考えれていないのでは？

>># んでもこれってわしらギョーカイに限った問題じゃないしー。
> なるほど。自分だけじゃないからそのままでも良いとお考えなのですね。

あなたがそう思うのを止められはしませんです。
# 今に始まったことじゃないし。

価値あるシステムを構築するにも当然コストはあるわけで・・・。

インドリさんに素直に聞きます。
「コストってどうやって計算してるの？コストには必ず存在するはずの人件費を、「人月単価を使わない」でどうやってを出してるの？教えて下さい。」

まあ、答えは「企業秘密です」だとは思ってますが、まさか「人件費なんてものは存在しません」って回答はしないですよね？

システムの価格はシステムとしての価値により算出され、そこにコストは関係しない...みたいな話をどこかで聞いたことがあるかな？
突然の上、うろ覚えです...間違ってるかもしれません。
失礼しました。

それはさておき、「人月単価」の話になるといつも思うんですが、そんなに問題なんでしょかね？
技術力が正しく判断されないっつーのは、企業の場合はサラリーの話になるので関係ないかなぁ...と思ったり。
ひと山いくらでどんぶり勘定がまずいのかもですが...。
あー...派遣の人とかいるから複雑なのかな？

επιστημηさんの例にもありますが
>会社という集団で請け負うなら5人かき集めて「俺たちゃひと月500万」はアリよね。
>内実は凄腕の1人とヒヨコ4匹でね。
これはアリだと思うですよ。
作ってもらう側からすれば個々のスペックには興味ないわけですし。

...というか、

そもそも、IT業界っていったい何を「売って」いるんでしょう？
技術なんでしょうか？モノなんでしょうか？労働力なんでしょうか？

技術ならば...アートとか音楽に近いのかなぁ...？
モノならば...？原価＋利益？
労働力ならば...？時給ですかねー。
うーん、わかりません（なんか怒られそうだな...）
なんかこーこのあたりが曖昧で、だからこそ議論が終わらないのかなぁ...。
っつか、全部の要素含んでるのかな？

どれだけ話を聞いても「人月単価」、それ自体に問題があるようには思えないのです。
IT業界にひずみがないとは思いませんが、すべての原因は果たして「人月単価」にあるのでしょうか？

まとまりのない文章ですみません。空気読めてない気もする...。
がんばって推敲してみたのですが限界でした...orz

http://www.meti.go.jp/press/20090731004/20090731004.html

細かく見直してみたけど・・・
ここのコメントで難しいと予想されている部分は、同じように難しいって書いてありますねぇ。
また、PBCのパターンも2/3が開発側の関与が小さいので適応が難しいとあります。(22ページ参照)

この資料、「人月ベース」の価格根拠が適正かどうかわからないという、買い手側の視点で始まってるわけで・・・
まぁ、得たいの知れない製造方法にとらわれないものとしてPBCをピックアップしたって感じですかね。
だからこそ「情報システムのパフォーマンスベース契約に関する調査研究」報告書なわけでー

「PBCっていう買い手側がソフトの適正価格を判断しやすい方法があるみたいだから調べてみたけど、採用するのは難しい」

ってのが、結果ではないだろうか(^^;
PBCが「人月ベース」よりも優れているから、これからは、PBCに変えないと駄目ってな内容じゃないと思うんだが・・・

３ページ目にも明確に

>現行の人月ベースの価格設定では、「製品としての価値（モノへの対価）」に重きを置
>くため、「システムを構築するために要した労働量」を価格に換算する考え方が基本と
>なっている。それに対して、PBC の価格設定では「システムやサービスが生み出す価値
>（価値への対価）」に重きを置くため、「システムやサービスが創出する価値」を価格に
>換算する考え方になる点が人月ベースの価格設定と本質的に異なる。

「人月ベース」は「製品としての価値」として認めていますね。
それを認めていた上で、「システムやサービスが生み出す価値」へ変えたらどうなるのかって話なわけでー
基本概念としてPBCには、製造コストが入らないってことですねぇ。

採用例のほとんどは、サービスで収益を得ているもので、この例の買い手側からみたら、損しないものになってますね。
開発側だって、ちゃんとサービスの利益で製造コストが回収できればＯＫなわけですが・・・
やっぱり、条件として限定されてますよねぇ(^^;
コレ、買い手も限定されますよね、システムを利用すると必ず利益がでないといけないわけですから・・・
システムが直接利益と結びつかない場合は、全部経費になるわけですから・・・厳しいですね(^^;

>επιστημηさん
>オークションはある意味理想的なカタチに近いかな。

パッケージなら可能かもしれないけど、受託の場合は、入札にしかならないようなー

>インドリさん
>いいえ。パフォーマンスベースで、「俺には500万円の価値がある。何故ならば・・・」と価値ベースで価格を設定するのと、
>「1月働くから50万円だよね」というふうに人月単価の労働力で売るのとは天と地の差があります。

「俺には500万円の価値がある」は「俺の作ったソフトには500万円の価値がある」の間違いですよね(^^;
でもって、「1月働くから50万円」は「一ヶ月働くから500万円」かな？
前者はPBCというより、ただの「言い値」ですよね、見積もりの段階では、まだ価値が生み出されていないのですから・・・
また、天と地の差ってどういう意味でつかってます？
文脈からすると価値ベースがよく、「労働力で売る」のが駄目のように見えますが・・・なんで駄目なの？

>nightRavenさん
>そもそも、IT業界っていったい何を「売って」いるんでしょう？

買い手によって変わるんじゃないかなと。
下請けは、労働力を売っているだろうし、お客には完成した製品を売っているのでしょう。
残念ながら、「技術」を売ったり買ったりしている認識で一致しているケースは少数だと思いますね(^^;

> 残念ながら、「技術」を売ったり買ったりしている認識で一致しているケースは少数だと思いますね(^^;

人月単価：脳みそ貸し賃 っていう無茶(?)な解釈すれば技術の量り売りと言えるんでないかなｗｗ

# ネタをまとめて整理して書きゃいいのに勢いで連投、いかんなぁ

> επιστημηさんの例にもありますが
>> 会社という集団で請け負うなら5人かき集めて「俺たちゃひと月500万」はアリよね。
>> 内実は凄腕の1人とヒヨコ4匹でね。
> これはアリだと思うですよ。
> 作ってもらう側からすれば個々のスペックには興味ないわけですし。

実際あるんすよ。うちとこと長い付き合いの外注さんがありましてね、
そこに一人、彼に任せておけば間違いない、とびっきり優秀な方がいらっしゃる。
プロジェクトが始まるとまずその方を狙って発注かけるんす。するとアチラの
営業さん、「アイツが欲しいならあとふたり使ってください」とくる。
ぶっちゃけ"抱き合わせ販売"ですわ。で、僕らはお偉いさんと掛け合って予算
つけてその条件を呑むんです。正直抱き合わせのふたりには期待していない、
優秀なひとりの確保のために三人分のギャラを払います。

>人月単価では駄目な理由
経産省の報告書の経緯と概要をよく読んで下さい。
そこに人月単価では駄目な理由が詳しく書いています。
お客様が不信感を持っている時点で客商売としてはアウトです。

>人件費と人月単価の混同について
人件費を算出できないという意見が目立ちますが、人月単価でないと人件費を算出できないなんて事はあり得ません。
どこの会社も経費を算出しています。

>抱き合わせ販売について
そういう実体を伴わない人月単価の操作がユーザーに不信感を持たれる理由です。

>何を売っているのか
ユーザーが求めるものを売っております。
ユーザーは人が欲しいのではなく、求めるものを買いたいのです。

総論
危機感が足りません。
問題当事者には自覚がないとよく言われますが、今度の件もその原則が当てはまっているようです。
ユッケ事件と同じぐらい深刻だと真摯に受け止めるべきなのにも関わらず、未だにこれだとは情けない限りです。
人月単価の問題は、問題である事を自覚することから始まると思います。
IT業界には問題があるという事を自覚しておきながら、その要因である人月単価を問題ないという人がいる事には驚きです。
お客様に不信感を持たれな、まともな業界になる事を願っています。

・人月単価はお客様のためにならない（←何故かは言えない。人月単価否定教？）
・経産省もPBCと言っている（←それだけが正しいと言っている訳じゃない）
・俺様は当然PBC（←だけど、具体論は教えない）

という中身ゼロのことしか言っていない人がいなければ、もっと良い議論になるのになあと思って読んでおります。
これは個人攻撃ではなく、議論の進め方に関する意見です。

>・人月単価はお客様のためにならない（←何故かは言えない。人月単価否定教？）
「自分が作った商品の価値もしせない時点でアウト。」
「ユーザーに不信感を持たれている。客商売にとって深刻な問題だｊ」
と何度も言っております。
念押しに何度も言いますが、これは大多数の意見です。
人月単価の問題は経産省の報告書にも書かれています。
抜粋

我が国の情報システム市場は、現在、主として「人月ベース」の価格表示を行ってお
り、それに伴う価格の根拠がユーザ側の価格への不信感につながっていることは従来か
ら多数指摘されている※が、残念ながら、この課題は現在まで業界全体として抜本的に解
決されるには至っていない。高い品質や高い効果を創出するシステムを構築できる付加
価値の高いベンダがきちんと評価されるような市場構造が確立されなければ、IT サービ
ス産業全体が健全な発展を遂げることができない。また、人月積算を前提としたFixed
Price（固定価格）のみでは、ベンダの品質向上等へのモチベーションは生まれない。さ
らに、ユーザにとってCEO（Chief Executive Officer：最高経営責任者）を始めとする
経営層に説明できない価格では、投資の妥当性を提示できず、投資意欲そのものを減退
させてしまう。
※1993 年度の産業構造審議会報告書『ソフトウェア新時代』において「人月は単純な
労働量にもとづくプライシングの方法であるために、システムの品質や価値を十分
反映することは困難であり、これが主流を占めている限り、市場の健全な成長は望
めない」「品質や価値を反映したプライシングの方法を導入する必要がある」という
提言がなされている。
また、2006 年度実施された産業構造審議会（情報経済分科会 情報サービス・ソ
フトウェア小委員会）の中間取りまとめにおいても、「情報システムの価値に関する
課題（人月工数単価からの脱却）」として、この問題が取り上げられている。

抜粋終わり
1993年からユーザーに対して価値を示していないと言われています。
これほど問題が多い人月単価を受け入れているのがおかしいのです。
商売をしている事を忘れているとしか思えません。
1993年から19年間も何をしているのでしょうか。
私は直ぐに問題に気付きました。
気付かないというのは、お客様を見ていない証拠だと思います。
お客様に不信感をもられる業界の行く末は見えています。
一刻も早くまともになってほしいです。

次に
>・俺様は当然PBC（←だけど、具体論は教えない）
理由については何度も言っております。
価格は商品の一部であり、各社が努力して創りだすものです。
教えられないというのは当たり前の話しです。
価格設定は、どの業界の人も必死で考えて見出しています。
その当たり前の努力を怠り、ユーザーから不信感を持たれている現状は情けないです。

文章を読めない方と議論する気はありません。

終わり

Ｓｏｄａさん
>買い手によって変わるんじゃないかなと。
>下請けは、労働力を売っているだろうし、お客には完成した製品を売っているのでしょう。
>残念ながら、「技術」を売ったり買ったりしている認識で一致しているケースは少数だと思いますね(^^;

ですよねー(^^;
なんかこー、「人月単価」をまるっと否定することってのは、なんもかんもひとくくりにして一山いくらの人月計算をすることと
結局同じことをやってるようにしか見えなかったりする。
うーん、わかりにくい表現ですね（汗

επιστημηさんの「人月単価：脳みそ貸し賃」にコーヒー噴出ｗ
コンサルタントとかこれにあたるのかなぁ...。

επιστημηさん
>ぶっちゃけ"抱き合わせ販売"ですわ。で、僕らはお偉いさんと掛け合って予算
>つけてその条件を呑むんです。正直抱き合わせのふたりには期待していない、
>優秀なひとりの確保のために三人分のギャラを払います。

○シモトとか○ャニーズとかみたいな感じですかねー。
なるほど、おもしろいなぁ...
名目上は３人分ですけど、実質凄腕さんの値段（ひいてはそれがその会社のスペック？）というわけですよね。
もらう側は３人分、でも払う側は１人分の認識かなぁ...（たぶん違うけど）
それはそれでつじつまあってるような気がするんだが...。
本人達が納得するか否かは売る側の個々に対する評価の問題でしょうし。
わりと適正に個々の技術力は評価されているような気がしないでもない。
かつ、こうすることによって現在は価値０のひよこ君達が成長するための土壌も提供できる...と。

>> 人件費と人月単価の混同について
> 人件費を算出できないという意見が目立ちますが、人月単価でないと人件費を算出できないなんて事はあり得ません。
> どこの会社も経費を算出しています。

ロジックに欠陥。
どこの会社も人月単価をベースにしているからじゃない? と突っ込まれます。
事例を示さないとね。

>> 抱き合わせ販売について
> そういう実体を伴わない人月単価の操作がユーザーに不信感を持たれる理由です。

結果ボロボロだったら次回から門前払いですね。
長い付き合いで十分な信頼関係にあるからやれることですよ。
その分こちらもかなり無理が言える、双方にメリットあればこそです。

「出来上がりがよければ文句ないよ」は
まさに"創出される価値"を評価しているからじゃない。

> かつ、こうすることによって現在は価値０のひよこ君達が成長するための土壌も提供できる...と。

そそ。ヒヨコ達に熟練の技を見せてやれる。
お客さんとこで作業する形態(秘密性の高い案件に多いけど)だと
ヒヨコ集めて教育するのが難しくなるんで、凄腕の傍につけさせようと。
お客はそのスポンサーとなるってことね。

人件費の算出根拠は「人月単価」ですよね...
まー基本給とか、時給とか、言葉はいろいろとありますけど。
お客様に見積もる１ヶ月あたりの人の単価だけが「人月単価」ではないですねぇ...。

経産省の報告書をざざっと斜め読みして思ったこと。
「固定価格」算出のベースって結局コスト（人件費＝人月単価）なんじゃないの？
なんかこー...PBCってボーナスの査定に近い感じによみとれた。
報告書の内容に？？？な部分とか、こじつけ感を感じるのは田舎にすんでるせいかもしれない（苦笑）

>そそ。ヒヨコ達に熟練の技を見せてやれる。
>お客さんとこで作業する形態(秘密性の高い案件に多いけど)だと
>ヒヨコ集めて教育するのが難しくなるんで、凄腕の傍につけさせようと。
>お客はそのスポンサーとなるってことね。

長いおつきあいがあって、かつこれからも続けていこうとするからこそできる関係ですねー。
ある意味PBC？（違うって...）
でも、これが上手くまわっていくと、理想の形に近くなるのかなと思ってみたり。

>ロジックに欠陥。
>どこの会社も人月単価をベースにしているからじゃない? と突っ込まれます。
>事例を示さないとね。
会計処理を知らないのですか？
事例も何もどこの会社も普通に計上しています。
やはり、人月単価と人件費を混同されていますね。
人月単価は価格決定法。
月給とは違います。

>そそ。ヒヨコ達に熟練の技を見せてやれる。
>お客さんとこで作業する形態(秘密性の高い案件に多いけど)だと
>ヒヨコ集めて教育するのが難しくなるんで、凄腕の傍につけさせようと。
>お客はそのスポンサーとなるってことね。
人月単価である必要はありません。
それこそ価値でシステムを提供し、人員育成をする法がスムーズに話しが進みます。
人月単価でないと育てられないという根拠がありますか？

要するに人月単価と自分たちがもらう給与と混同されているわけですね。
会社はお客様が望むものを提供して売上を上げる。
その中から経費をやりくりして、さらなる発展を目指す。
普通の商品が人月単価でない意味を考えれば分かると思います。
どこの業種でもやっている普通の商売を何故知らないのか不思議でなりません。
人月単価に慣れ過ぎて、世間から孤立している事を理解できないのかもしれませんね。
それに加えて、お客様の立場に立った意見が全くない。
「自分たちは月給をもらう。お客様の事なんて関係ない。」と主張されているように思えてなりません。
ちなみに、前にも指摘しましたがコンサルタントも人月単価以外の例が経産省の報告書に書かれています。

>> そそ。ヒヨコ達に熟練の技を見せてやれる。
>> お客さんとこで作業する形態(秘密性の高い案件に多いけど)だと
>> ヒヨコ集めて教育するのが難しくなるんで、凄腕の傍につけさせようと。
>> お客はそのスポンサーとなるってことね。
> 人月単価である必要はありません。
> それこそ価値でシステムを提供し、人員育成をする法がスムーズに話しが進みます。
> 人月単価でないと育てられないという根拠がありますか？

こんなこと書くから「言葉の断片に反応してる」って評されちゃうんですよ。

>こんなこと書くから「言葉の断片に反応してる」って評されちゃうんですよ。
それで根拠は？
答えられないから逃げているようにしか見えませんよ。

ああ...余計なことを言ってしまった...orz

別に給与と混同しているつもりはなかったんですが...。
そして、なにげに失礼な言い方をされている気がしないでもないけど...まぁ...いいか。

「人月単価」が価格決定法というのは知らなかった（汗）
価格を決定するための根拠の一つってイメージだったなー。
単価という名前だけど「単価」ではないってことかー。

> それで根拠は？

「人月単価でなければできないこと」について語っていません
なのでその問いに意味がない。

こんなこと訊くから「言葉の断片に反応してる」って評されちゃうんですよ。

: インドリ 2012年1月21日 (土) 12:24
> 人月単価は価格決定法。
> 月給とは違います。

ここらへんに解釈の違いがあるのかな。
少なくとも僕は人月単価には「単位要員,時間あたりいくら」=[円/人・月]
という単位としか見ていない。

これを使って原価を算出して価格を決めたり、諸経費差し引いて月給決めたり。
コンビニバイト時給900円も人月単価だし
コインパーキング一時間200円も「単位時間当たりいくら」の意味では人月単価
と根は同じ(この場合"人"を1に固定していると見做せる)。

かけた時間/拘束された時間で売値が決まるというのに憤慨するのはわかる。
だらだら仕事するほどお高いとはどういうことだ!? と。

一方、純粋にその商品の価値が算定できたとして、それを人月単価に"換算"する
ことは可能だ。「俺の仕事は１００万[円/人月]の価値がある」ってね。
わかりやすい仮想単位(←ココ重要!)として機能するのは誰もが認めることだろう。

>「人月単価でなければできないこと」について語っていません
>なのでその問いに意味がない。
>こんなこと訊くから「言葉の断片に反応してる」って評されちゃうんですよ。
単文だけを読んで判断されているのですね。
貴方がしきりに人月単価を維持することを言っているから、評価ベースだとだめな理由はないし、人月単価に固辞する必要はないのではないかということを言っているのです。
貴方は何のために書き続けているのですか？

>ここらへんに解釈の違いがあるのかな。
>少なくとも僕は人月単価には「単位要員,時間あたりいくら」=[円/人・月]
>という単位としか見ていない。
そこが違うと思います。
お客様の視点が欠けています。
経産省の報告書にも書いていますが、お客様はシステムの価値を知る必要があります。
下手すれば数十億のシステムを投資するのに、「作り手が価値を説明できない」のでは不安で投資できません。

>かけた時間/拘束された時間で売値が決まるというのに憤慨するのはわかる。
>だらだら仕事するほどお高いとはどういうことだ!? と。
そうです。
経営者からみてそこが重要です。

>一方、純粋にその商品の価値が算定できたとして、それを人月単価に"換算"する
>ことは可能だ。「俺の仕事は１００万[円/人月]の価値がある」ってね。
>わかりやすい仮想単位(←ココ重要!)として機能するのは誰もが認めることだろう。
わかりやすい仮想単価というだけで、お客様から不信感を持たれてもよいというのですか？
仮想はあくまでも仮想。
現実と乖離している時点で無価値な価格算出法です。
価格はお客様に対するメッセージです。
そのメッセージを仮想にするから不信感を買うのです。
お客様もその辺を考慮し、短納期と機能の追加を要求します。
また、経営者としてみれば、単純な価格なんて意味がありません。
どれだけ価値がある商品をいくらで生産できるのか把握したいのです。

それにしてもなぜ貴方は、自分たちが作る商品の価値を提示することに反対なのでしょうか？
作り手としても価値を知ってほしいと考えるのが普通だと思います。
価値を知られてまずいことでもあるのでしょうか？

> >価値について
> お客様は投資目的でシステムを購入されております。
> だから価値という話が出てくるのであって、そういった美術的な物とは違うと思います。
　美術品は、「投資目的」でも購入されていますよ。日本のバブル期に日本人が、“高値で買い漁った”ことが、ニュースに取り上げられたことがありました。
関連：http://media.yucasee.jp/posts/index/2711 http://www.amazon.co.jp/dp/4478620148
　また、美術的なものだけがオークションに出ているわけではありません。家電をオークション形式で販売している所もあります。まぁ、1円から始まって、あっという間に標準的な販売価格になっているので、サクラが頑張っているのでしょうね。そういえば、ペニーオークションが問題になっていましたね。あれも、いろいろなものを売っていますよね。

　あと、何だったっけ。「高技術が評価されない」みたいなことが書いてあったと思いますが。
　さて、ある仕事を、20日（1ヶ月）で出来る人と、15日で出来る人がいます。この二人の“単価”が同じだとします。仮に前者をＡさん、後者をＢさんとして、Ｂさんは、損をしているでしょうか。
　決してそんなことはありません。Ａさんより75％早く仕事を仕上げることが出来るＢさんは、Ａさんより25％多くの仕事をこなすことが出来ます。すると、一定期間における稼ぎは、Ｂさんの方が上ということになります。
　ここで、その仕事に、Ａさんは100万円の値段を付けているとします。Ｂさんが、「15日で出来ます。100万円です。」と言ったとき、「Ａさんより早く終わるのに、なぜ同じ時間なのですか？」という質問があるかもしれません。そこで、Ｂさんは、こうすることもできます。「20日で出来ます。100万円です。」そして、15日で仕上げ、5日間は別の仕事をします。あるいは、こう言うこともできます。「15日で出来ます。80万円です。」単位時間で見るとやや高めです。これに対して、「15日なら、75万じゃないの？」と言われれば、こう返すことが出来ます。「5日という時間を、5万円で買うと思って下さい。これを高いと思うか、安いと思うかは、お任せします。」前者のように行えば、５日間を有償で次の仕事を探すために使えます。後者のように行えば、かかった時間に対して割高な料金をいただくことができます。高い技術により、選択の幅が広がりました。人月単価であっても、技術を評価して頂く方法は様々あります。

> ただその一方で「それでしたら10人月でのお見積もりになりますので、
> 単価50万として500万になります」で受注して
　10人月。つまり、10人がかりで一月かかる、ですよね。これって、「10人」とか、「一月」という“量”を、どうやって求めているのでしょうか。
　建設業界、例えば道路を作るとき。道路のアスファルトの厚さは、ほぼ決まっています。工事を行う箇所の幅、道路の長さが決まれば、使用する資材の量が決まります。運搬用の資材は単位時間あたりに運搬できる量が決まっており、施工場所の広さから一時に携わることが出来る人数も決まります。すると、何人が、何日働けば仕上がるか、ほぼ計算できます。
　プログラミングはどうでしょうか。一応、我々 VDT 作業者は、１時間に１０分の休憩を取らなければならないことになっています。一日８時間の実働時間があるとして、実質的には７時間。一日、７時間の間に、何行のコードが書けるか。最小単位は、ここになっています。ですから、人月単価で計算するには、単位人が単位時間あたりに何行のコードが書けるか、算出されていなければなりません。かつ、お客様の要望から、コード量にきちんと変換できなければなりません。
　人月の問題は、この、「要望を、計算するための単位に変換できない」という所にあるのではないか、と思います。

　人一人が生活するために必要な金額はおおよそ決まっています。物価などを勘案し、都道府県によって「最低賃金」が決められ、おおよそそれだけの時間給があれば、生活ができるだろうと思われます。ちょっと話が飛びますが、テレビに出ているタレント。駆け出しの頃のギャラは安いですが、あちこちから仕事を依頼され、その依頼がかち合う事が多くなれば、高くなります。プログラマも同じではないでしょうか。「この仕事して」「こっちの仕事があるからダメ」「そこの2割増しで払うからやって」とか。会社勤めでは、「2割増し払うから」というのは、上司による評価になるわけですかね。最低賃金に対して、どれくらい上積みできるのか。その上積みの価値は、何によって求まるのしょう？

　つまり、「期間」という問題と、「価値」という問題、二つあるのではないでしょうか。まず、「期間の妥当性」という問題。想定していた期間と実際に費やす期間が違いすぎる、など。そして、「技術者に対する評価」という問題。技術者が正当に評価されているかどうか不明瞭である、そもそも単価の妥当性を検証する方法がない、など。これが問題なのであって、人月という単位には、何ら問題はないと思っています。
　人月は単位なので、変える必要はない、そもそも変えられないと考えます。世界にはドルやウォンなどの単位がありますが、日本で通じるのは円です。ドルやウォンが通じるところもごく少数ありますが、同じように、人月以外の単位が通じるところも、多少あるでしょう。

>>ここらへんに解釈の違いがあるのかな。
>>少なくとも僕は人月単価には「単位要員,時間あたりいくら」=[円/人・月]
>>という単位としか見ていない。
>そこが違うと思います。
>お客様の視点が欠けています。
>経産省の報告書にも書いていますが、お客様はシステムの価値を知る必要があります。
>下手すれば数十億のシステムを投資するのに、「作り手が価値を説明できない」のでは不安で投資できません。

επιστημηさんは、「人月単価」という単語に対する解釈の話をしているわけであって、方法を語っているわけではない。
故に、お客様の視点は関係ないんではないでしょうか？
「商品価格」という「言葉」の「意味」を論じるのに、「お客様」というフレーズは関係ないかと...。
ちなみに、「価格設定」の「方法」ではありません。あくまでも言葉にたいする解釈の話です。
そういった意味で言えば、επιστημηさんの言われることは至極正しい話だと思われるのですが違うのでしょうか？

「人月単価」の額を算出するためとか、それによって導き出される商品価値の算出するための方法論を論じているならば「相手の視点」も考慮に入れる必要があるかもしれませんが...。
「人月単価」という言葉の解釈が違うので、それを元に正しいか間違っているか論じても仕方ないのでは？

>一方、純粋にその商品の価値が算定できたとして、それを人月単価に"換算"する
>ことは可能だ。「俺の仕事は１００万[円/人月]の価値がある」ってね。
>わかりやすい仮想単位(←ココ重要!)として機能するのは誰もが認めることだろう。

「単位」が「仮想」であれば、そこからはじき出される価値までもが仮想なのでしょうか？
現実と乖離していなければ、正しく「評価」された「価値」は存在するのではないでしょうか。
επιστημηさんは、そういった意味で「仮想単位」として機能している、って言ってると理解したのですが解釈間違ってますかね？

>美術品は、「投資目的」でも購入されていますよ。日本のバブル期に日本人が、“高値で買い漁った”ことが、ニュースに取り上げられたことがありました。
明らかに価値ベースですね。
人月単価で評価する美術なんて聞いた事がないです。

>高い技術により、選択の幅が広がりました。人月単価であっても、技術を評価して頂く方法は様々あります。
お客様が求めているのは、「投資効果があるシステム」です。
技術者一人の技術力を知りたいのではありません。
そんなことよりも、システム全体の価値を知りたいのです。

>人月は単位なので、変える必要はない、そもそも変えられないと考えます。
人月単価以外の価格決定法を使っている業種の方が多いという事実を忘れています。
19年以上も（経産省が言うまでタイムラグがある）お客様から不信感を持たれて、それがいいという考えはビジネスの世界では通用しません。

「貴方が売っているシステムの価値は？」そんな基本的な事も答えられない業界は信用されません。
自分が作る商品の価値を知らなくてもいいというのは、作り手として非常に不思議な考え方ですね。
でも、貴方がそういう考え方を変えないというのであれば、しかたがないですね。

※2012年1月24日10時、攻撃的なコメントを削除

言い忘れていたので追記します。

>「単位」が「仮想」であれば、そこからはじき出される価値までもが仮想なので
>しょうか？
>現実と乖離していなければ、正しく「評価」された「価値」は存在するのではないでしょうか。
>επιστημηさんは、そういった意味で「仮想単位」として機能してい
>る、って言ってると理解したのですが解釈間違ってますかね？
単位が仮想なのに、総合計が仮想にならないというのは理論的ではないと思います。
基礎単位が間違っていれば、正確な計算は出来ません。
仮に総合計が仮想でなく現実にマッチしていると主張するのであれば、その現実の価値をお客様に対して言えばいいだけです。
そもそも人月単価による計算法は、現実と乖離していると随分前から言われています。

>>人月は単位なので、変える必要はない、そもそも変えられないと考えます。
>人月単価以外の価格決定法を使っている業種の方が多いという事実を忘れています。
>19年以上も（経産省が言うまでタイムラグがある）お客様から不信感を持たれて、それがいいという考えはビジネスの世界では通用しません。
>貴方は自分の給与にしか興味がないようですが、システムを使うお客様の事を考えないその考え方は、技術者としてもしくは人として如何なものかと思います。

Jittaさんもεπιστημηさんも「人月単価」は「単位」であるとの解釈。
対してインドリ氏は「価格決定法」であると解釈。
もともとまったく違う言葉にたいして間違っているというのはナンセンスかと。

※編集部：本論と関係のないコメントの一部を削除しました。

がるです。

To インドリさん
> ですから、設計と実装に分ける事態が間違っていると思います。
「契約」というものの法的側面と実務的側面をご存じないのであろうと推測をいたしましたので、議論は控えさせていただきます。
一応申し上げますと、短期的にも中長期的にも、設計と実装の契約は「切り分けておいた方が」色々とメリットがあります。

> > この辺は…「よしあし」の一言では片付けにくいと思うのですが。実際問題として「単価で500万よこせ」は、多分、あんまり通らないですね(苦笑
> IT業界が人月単価に縛られているから出る発想ですね。
これも全くの見当外れです。「人月単価」と「金額」とは異なるレイヤーの会話である事をご理解ください。

> 実際にお客様と本音を語り合えば分かると思いますが
面白い冗談をありがとうございます。

To nightRavenさん
> システムの価格はシステムとしての価値により算出され、そこにコストは関係しない...みたいな話をどこかで聞いたことがあるかな？
私見恐縮ではあるのですが。
(特に会社において)コストはコストとして存在すると思うのですが、「システムの価値」というのは、コストとは別の所にあるのだろう、と思います。
最近は、マーケティングの世界でも「コストから価格を決めるのやめれ」的な話が出ているみたいですし。

> それはさておき、「人月単価」の話になるといつも思うんですが、そんなに問題なんでしょかね？
> 技術力が正しく判断されないっつーのは、企業の場合はサラリーの話になるので関係ないかなぁ...と思ったり。
> ひと山いくらでどんぶり勘定がまずいのかもですが...。
これもまた私見ですが。
「ひと山いくら」なのと、あと「実際のレベル差が適切に反映されにくい」ところに、痛し痒しなところがあるのかなぁ、と思っています。

To επιστημη さん
> 人月単価：脳みそ貸し賃 っていう無茶(?)な解釈すれば技術の量り売りと言えるんでないかなｗｗ
「脳みそ」が、「知識」以外の、例えば「経験によって得られる習熟度や知恵」なんかも含むのであれば、さほど無茶な見解でもないように読み取れました(笑

> > かつ、こうすることによって現在は価値０のひよこ君達が成長するための土壌も提供できる...と。
> そそ。ヒヨコ達に熟練の技を見せてやれる。
> お客さんとこで作業する形態(秘密性の高い案件に多いけど)だと
> ヒヨコ集めて教育するのが難しくなるんで、凄腕の傍につけさせようと。
> お客はそのスポンサーとなるってことね。
これ、ものすごく「大切だし重要な流れ」だと思うです。
で、これは実は「お客様にもメリットのあるお話」。なんでかっていうと、育った「元ひよこ」なニワトリたちを、お客様は将来「使うことができる」から。
それこそ、営業レイヤーであれば「うちの案件で育てたんだからうちの案件を優先的にやらせろ」くらいの強権をお客様が発動するは、ありだと思います(笑

To 残念さん
> ・人月単価はお客様のためにならない
の部分を、まずはもうちょっと「真摯かつ丁寧に」考察する必要が、きっと、あるんだと思います。

To Jittaさん
> つまり、「期間」という問題と、「価値」という問題、二つあるのではないでしょうか。まず、「期間の妥当性」という問題。想定していた期間と実際に費やす期間が違いすぎる、など。そして、「技術者に対する評価」という問題。技術者が正当に評価されているかどうか不明瞭である、そもそも単価の妥当性を検証する方法がない、など。これが問題なのであって、人月という単位には、何ら問題はないと思っています。
うん多分、ここ、なんでしょうねぇ。

おそらく、επιστημηさんが書いていた「仮想単位」という言い方が、一番的を射てる気がします。
あとは、そこを基軸に、もう一度「人月単価」について考察をすると…色々と、問題点を含め、思いつくのですが。
さすがに人様の庭先で展開する文章量ではないので(苦笑)、そこは控えさせていただきたく思います。

To コメントを書かれたみなさまと、なによりもAhfさま
このあたり、考えている時期ではあったのですが、とてもよいヒントときっかけと刺激になりました ＾＾
まだまだ議論はされていくと思うのですが、ひとまず、心からの御礼をいわせてください。
ありがとうございます。

がるさんへ

>「契約」というものの法的側面と実務的側面をご存じないのであろうと推測をいたしましたので、議論は控えさせていただきます。
一応申し上げますと、短期的にも中長期的にも、設計と実装の契約は「切り分けておいた方が」色々とメリットがあります。

それは、会社間のトラブルの話しですよね。
ちゃんとしたシステムと作ればいいだけの話しです。
お客様サイドの話しではなく、開発側の会社が責任の所在をなすりつけ合うためにする事ですね。

>これも全くの見当外れです。「人月単価」と「金額」とは異なるレイヤーの会話である事をご理解ください。
単価だと貴方が言ったからそういったのですが・・・
金額の話しならば人月単価と何の関係もない話しです。
それこで人月単価にしなくてもいい。

>面白い冗談をありがとうございます。
お客様と話しあえないのですね。
お客様から本音を引き出すのは商売の基本です。
それが出来ないのは自慢になりませんよ。

ちょっと、分かり難いと思いましたので書きます。

>これも全くの見当外れです。「人月単価」と「金額」とは異なるレイヤーの会話である事をご理解ください。
これについてなのですが、がるさんが「1人に500万円渡すなんてありえない」と言われたから、価値よりも人数で判断している点で人月単価で縛られていると言いました。
人月単価の発想がなければ、商品がいくらであっても価値があればそれでいいと考える筈です。

こー話がループしているような気がしてならないというか、不毛すぎるんだが・・・
19年前の不満を今に当てはめても意味ないでしょう・・・

少なくとも、今は買い手が有利な市場でしょう。
昔と違って、ソフト屋は沢山ある、選べることができる状態。
提示した見積もりに納得できなければ、他を選ぶことが可能な時代ですよ。
「不信感」をもたれるような会社は選定されないだけです、買い手もバカじゃない。

さらに、相場というものが生まれているわけです。
がるさんがεπιστημηさんの提示した「500万」が通らないねっていったのは相場があるからこそ出た意見ですね。
「人月単価」の問題が、「価格への不信感」だとしたら、現在においては、ほぼ解決しているような気がします。
他社の見積もりに対して、「高い/安い」が判断できる時点で、「価格の妥当性」は判別されるでしょう。
これが、コメント欄の最初のほうにある「ものさし」ですね。
つまり、現実社会では、

「一ヶ月で500万レベルのものを一人では作れない」

という、価値観がお客に存在しているということですよ。

そして、PBCは「人月ベース」に置き換われるものではないでしょう。
買い手側の都合もあり、PBCのように、永続的に経費がかかるものよりも、買い切り型にしたい場合もある。
・・・というか、買い切り型の要望のほうが多いんじゃないかな？

・・・というか、経済産業省の報告書に書かれているPBCと、インドリさんがいう価値ベースって明らかに違いますよね。

報告書にあるPBCは、出荷したソフトを使って生み出される価値を基準にしています。
インドリさんのいう価値ベースは、ソフトの価値でしょ？
多くの場合、製造側が主張できる価値ってのは、ソフトの性能、品質などソフトそのものの価値まで。
PBCにおける価値の決定権は、使う側にあるわけです。
いや、価値という言葉で両方混ぜて使っているんだとは思いますが・・・似て非なるものですよね。

でもって、ここのコメント欄を読めばわかるように「人月ベース」でもソフトの価値は反映できるし、しているのが現状。
お客が望み、製造コストを回収できる見込みがあれば、PBCでもかまわないわけです。
もちろん、入金されるまでの間もなんとかなるって前提ですが(^^;

全部混ぜて、「人月ベース」が駄目で、「価値ベース」に変えないといけないと論じているから、疑問をぶつけられるわけでー
誰も、PBCを採用している企業を批判していないし、「人月単価」じゃないと駄目といってないわけです。
置き換えができるものではないという説明がされているだけですよ。

>インドリさん
>仮に総合計が仮想でなく現実にマッチしていると主張するのであれば、その現実の価値をお客様に対して言えばいいだけです。

お客に製作にかかる手間をわかりやすく表現するために使われているのですよ。
私が、最初のほうのコメントで「仮想的な材料費」と表現しているのはそのためです。

欲しい金額が先にあり、人数や日数は後から調整されて決まるのが、「人月ベース」の実体です。

人月単価×人数×時間　＝　請求額

というのが、典型的な「人月単価」に対する誤解です。

請求額÷人月単価　＝　人数×時間

こういう式のほうが、「人月ベース」の実運用に近いと思います。
だから、技術力が高いほど、人数や日数にゆとりが生まれ、技術力が低いほど、ゆとりがなくなるわけです。
お客のために、材料費の内訳を作業時間に例え、そこで生まれたのが「人月単価」という表現です。
でもって、時間以外に判り易く、使い勝手のよいものがあれば、他のものでもいいのですよ。

>人月単価の発想がなければ、商品がいくらであっても価値があればそれでいいと考える筈です。

いや、価値と金額が釣り合わなければ、買ってくれませんよ。
だからこそ、ものさしが必要なわけです。
今の時代、「いくらであっても」なんていうお客は皆無でしょう。
そんなお客がいたのは、バブル時代・・・かなぁｗ

ＰＳ．２
私を含め、説明に使っている部分が多くなっているのがいけないんですかねぇ。
類似した説明をまとめると、かなり圧縮されるような気がしてならないｗ
誤読の説明をすると、さらに誤読されるパターンというかｗ
いやーそれでも説明したくなるってのは、職業病なんですかねｗ
結果的に、第三者からは、すごくわかりやすい内容になっているような気がします＜コメント欄
コラムニストのAhfさんが介入しにくい状況で、申し訳ないとは思いますが(^^;;;;
コメント入れるタイミングが計れないだろうし、コメントする内容も既に沢山でてしまっているだろうしｗ

※2012年1月24日13時、一部コメント削除

>> ここらへんに解釈の違いがあるのかな。
>> 少なくとも僕は人月単価には「単位要員,時間あたりいくら」=[円/人・月]
>> という単位としか見ていない。
> そこが違うと思います。

この文脈で「違うと思います」は「あなたは間違っていますね」だね。
あちこちのコメント欄であなたの意見がことごとく他と衝突する理由が垣間見えます。

> 人月単価で評価する美術なんて聞いた事がないです。

ところがあるのですよ。美術商は画家のカタログを持っています。
画家ごとの人気や実力で付けられたランクが記されています。
画商はそのカタログを基に１号(キャンバスの面積単位)あたりの価格
で買い付けの基準価格とします。ホントだよ。

↑なんて書くとまたつっかかってくるんだろうなぁ。
人月単価じゃないよ。
絵画が面積あたりいくらで"量り売り"されているのは人月単価と根は同じてこと。

επιστημηさんへ
多額の投資をされるお客様に対して、誠意ある対応をするべきだという意見に反対する理由を教えて下さい。
多額の投資をされるお客様が根拠を求めるのは至極当然です。
どの業界でもそうだと思うのですが、技術者はお客様のために物を作っております。
その「お客様に役立つものを作る」という技術者／商売人の心を暗に否定するというのは如何なものかと思います。

19年以上も経産省が指摘している問題を無視しても、我々IT業界のイメージが悪くなるだけです。
お客様が不快に感じている人月単価の操作を止め、真に価値あるシステムを作るべく汗水を流して働きましょうよ。
私は世間に恥ずかしくない仕事をしたいです。
そして、自分が働いていて恥ずかしくない業界になってほしいです。
「お客様に対して価値を示す」そんな当たり前の事が何故できないのか不思議でなりません。

※2012年1月24日13時、一部コメント削除

> 多額の投資をされるお客様に対して、誠意ある対応をするべきだという意見に反対する理由を教えて下さい。

僕が「多額の...という意見に反対」と述べている(もしくはそう判断される)部分を引用してください。
# 投稿日時も添えてもらえると助かります。

>> かけた時間/拘束された時間で売値が決まるというのに憤慨するのはわかる。
>> >だらだら仕事するほどお高いとはどういうことだ!? と。
> そうです。
> 経営者からみてそこが重要です。

実際にはそう簡単には「だらだら仕事して値を釣り上げる」ことはできませんね。
理由は簡単、締切のない仕事は存在しないから。
お客様は「約束の期日に要望通りのモノが納入される」のを条件に金払ってくれます。
遅れたら罰金、目に余れば出入り禁止喰らいます。

客商売はみんなそうでしょ。
だらだらしてたら客は怒って帰っちゃう。
だらだらしてたら注文さばけない。つまり売り上げが伸びない。

だらだら仕事できないようフィードバックがかかるから人月単価が使えるんだな。
そうでなかったらとっくに廃れてますよ。

επιστημη さんへ

>僕が「多額の...という意見に反対」と述べている(もしくはそう判断される)部分を引用してください。
# 投稿日時も添えてもらえると助かります。

第一に、経産省の報告書にもあるように、「人月単価はシステムの価値を表していない」という揺るぎない事実があります。
ですから、Ａhfさんも

　もちろん私はできた人間には程遠いので、「金銭を頂く事自体に抵抗がある」とかそのような類ではなく、提供しているシステムに見合った価格なのか、という点において感じています。

と仰られています。
ですから、このコラムではそこが前提となります。
この前提から物事を考えた場合、何らかの「システム価値を表す価格」が必要となります。
その価格とは人月単価ではない事は明らかです。
従って、人月単価を支持する貴方様のコメントは「システムの価値をぼやかす」事を意味しています。
色々な書き込みからそれが分かります。

>επιστημη 2012年1月 8日 (日) 04:49
従来通り人月ベースで試算し、それを振り分けても同じ明細が作れる。
単に「細かくしただけ」であり、価値ベースとはお世辞にも言えないね。

このあたりから、人月単価でもいい（仕方がない）と誘導し始めましたね。
これ以降のコメントを読むと、「技術者は労働者に過ぎないだから人月単価でいい」、「自社が好きな価格を決めて価格操作をすればいい」という持論を持つSoda氏達とともに「人月単価でもよい」という方向性に誘導している様が分かります。
しかしながら自覚されていないかもしれません。
そこで私は、経営者でない貴方様が人月単価以外の高度な価格決定法を思いつかなくても仕方がないから、人月単価で仕方がないと言わずに、お客様に対して価値を示す方向性になればいいとAhfさんの意見に同意すればいいのではないかと言いました。
ですが貴方様は、それ以降も「人月単価で仕方がない」との持論を他者との会話という形で展開しています。
たとえば、お客様の立場で見ればこのコメントは酷いと思います。
επιστημη 2012年1月21日 (土) 16:33
お客様に対して商品価値を示すという視点が一切ありません。
それどころか、人月単価が現実から乖離した仮想のものだと認めた上で、人月単価は分かりやすくていいと暗示しております。
「現実のお客様が得られる価値を明示すること」を避けておられる様子が伺えます。
また、私が初めから言っているお客様視点で物事を考えるという事を一切しておりません。
お客様に対して誠意を示さないという姿勢がくみ取れます。
本当にAhfさんの意見に同意し、人月単価を問題視しているならば、貴方はコメントを書き続ける意味がない筈です。
それに加えて、自分たちの給与から考えている事が伺えます。

最後のコメントを読むとまだ人月単価に拘っておられるようですが、人月単価で商品販売していない会社でも人の評価は出来ます。
また、人月単価による弊害により人を正しく評価しないIT業界の構造を考慮しておりません。
一例をあげると、プログラマがこれに相当します。
人月単価には職位が使われる場合が多いです。
SE:200万円
プログラマ：100万円
この職位制度から考えると、会社側としては「いつまでもプログラマでいてもらっては困る」という事になります。
ちなみに、人月単価を採用していない他の業種の方はより精密な評価制度をしております。

誤解されているから言いますが、心配しなくても人月単価でなくても給料はちゃんと支給される筈です。
余程ブラックな会社でない限り給与は支払われます。
販売価格と給与は別物です。
お客様に不信感を持たれている価格体系を必死で庇う理由はありません。
人月単価が不信感を呼んでいる現実を謙虚に受け止めて、「人月単価はおかしい」でいいではありませんか。
経営者でない貴方様が、人月単価に替わる価格決定法を考えださなくても、おかしいものはおかしいと素直に言えばよいのではないでしょうか？
価格決定法については複雑な事項であり、全てを貴方様が背負う必要はありません。

人月単価がすたれないのは経営者の怠惰によるものです。
お客様の事を考えての前向きな行動の結果ではありません。
しかしながら、ビジネスの世界は変化が速いです。
私の様に人月単価脱却活動をしている方々は他にもいると思いますから、いずれよくなりますよ。

がるです。

個人的には「価値とはなんぞや？」が、一つおおきなキーワードであるように感じられました。
この「価値」の部分を、ある程度「システマティックに」算出できるかどうか、或いは「価値をシステマティックに算出した」場合に、どのような弊害がおきるか。
或いは価値を「個別に丁寧に」算出した場合にどれくらいのコストがかかり、それは「作成物のコストの一部として」みなして問題ない程度のコストなのか、金額的に馬鹿にならない(或いはしゃれにならない)ほどの金額になるのか。

そのあたりは、よい考察のネタになるのではないでしょうか？

或いはもうちょっと身近にいくとしたら。
例えば普段、皆さんが「駄菓子」を買うときに「果たしてこれは、この金額に見合う価値があるだろうか？ もっと金額はｎ円であるべきではなかろうか？」って、どれくらい考えるもんなんでしょうか？
それがランチなら？ ちょっと奮発したディナーなら？ ガジェットなら？ 不動産なら？
＆
「個人が支払う1000万円」と「法人格が支払う1000万円」って、多分、感覚としては大分と違うと思うのですが(で、法人格の場合、規模によっても相当に)。
では、システムに1000万支払ったとして、それは「一世一代の買い物」？ 「とりあえず予算消化の一端程度の、比較的軽微なもの」？

そんなあたりの側面も、考察のネタとしては一つ、面白いものなのではないでしょうか？

個人的には。
もちろん「価値に見合った対価を払う」ってのは大切だと思うのですが、一方で「このモノに見合う価値はいくらか？」を、あまり丁寧に考えすぎると、ちょっとコストがかかると思ってるんですよね(苦笑
その「コスト」がもし価格にのっかれば、お客様的にうれしくないですし。
その「コスト」がもし技術者側の負担になれば、技術者が潰れた結果として、結局は共倒れになるんじゃないか、って思ってます。

がるさんのコメントは興味深いですね。
結論が特に気になります。
人月単価でなければ共倒れという事はありませんから、その心配はありません。
システムの価値は創った人が一番知っています。
創った人が価値を提示できないなんて事ありませんから、価値ベースでの取引に何ら問題はありません。
私自身も問題だと感じた事がありません。
オーダーメイドなシステムは、「お客様に価値をもたらす」事を前提として作ります。
従って、価値を決めるなんて事にコストはかかりません。
信頼を得られると契約もスムーズに進みますし、人月単価で不信がられるよりも、信頼してもらって商売をする方が営業しやすいです。
価値ベースの価格決定は何の問題もありません。
人月単価（架空計上）をしているとお互い不信を抱き産業が沈下します。
今のままではお互い疑い合い共倒れします。

>「現実のお客様が得られる価値を明示すること」を避けておられる様子が伺えます。

その通りです。避けています。
「お客がいくらで欲しがってるかなんてわかるわけねーだろ」が理由。

とある"切迫した状況"により僕のポケットに入ってるティッシュに一万円の値を付ける人もいますよきっと。
ティッシュが手に入らないことによって引き起こされる重大な損失に比べれば一万円でも惜しくないのでしょうね(笑

客の頭ん中のこと僕がわかるわけねー。
客は僕の提示した値段に納得すれば買う。
客は僕の提示した値段が妥当かを知りたい、納得するための判断材料としてね。
そこで僕は明細を示す。そこには人月単価×使ったリソースの量(=人月)が記されている。
「ひと月100万円の脳みそ持ったエンジニアが５人がかりで２か月かかるのか、じゃぁ確かに1000万円だね。あんたの値付けは妥当だね」
と客が納得すれば問題はないよね。

それじゃ納得しない客がいる? 別の料金体系を示せ?
目下必死こいて考えてるんですけどね、どれもイマイチなんですよ。
できそこないの料金表でもよければ出しますが、それでいいですか?
...お客がウンと言うわけねーだろ、と思うてます。

創出される価値の話してないよ。あくまで売る側が提示した価値/価格ね。
あんたのオナカの具合などわかるもんか。
「お客によって変わる売値なんてつけられねーよ、商談させてよお客さん」
が僕の基本的スタンス。経産省のPBCも同じこと言うてます。

がるです。

> 創出される価値の話してないよ。あくまで売る側が提示した価値/価格ね。
個人的には「価値は価値」だと思っているです。或いは、そこにあるのは「売る側が(とりあえず概算で)提示して、お客様が"まぁこれなら売り上げ立つんじゃね？"程度に妥協していただける」価格、だけだと思っています。

で、システムの「(価格ではなくて)価値」ってなんじゃらほい？ って考えたときに。それはおそらく「そのシステムがあることによって売りあがった利益」ないし「そのシステムによって削減することができた社内コスト」なんじゃなかろうか、と思います。
んで、もし上述がtrueであると仮定すると、正直なところ「システムを提供する側」はおろか「お客様ですら」その価値なんて分かるはずがない。なんでかといえば、上述の定義による価値は「結果論にすぎない」ので。
かつ、んじゃ例えば「ECサイトを納品した」として、売りあがったとして。そのうちの「何割がシステムに起因していて」「何割が、商品を引っ張ってきた営業に起因していて」「何割が、サイトのデザインに起因していて」「何割が、商品説明文に起因している」のかなんて、そうそう判断が付くもんじゃない、と思ってます。

なので。最終的に「システムの価値」が見えてくるのは「事後」で。
故に、そもそも論として、本来的には「事前にシステムの価値なんか見えるわけがない」と思ってます。

ただ、現実問題として「とはいえ、購入時なり発注時なりに、何がしかの判断基準」というものは必要なので。
したがってお客様は「客は僕の提示した値段に納得すれば買う。」というロジックが、trueとして成り立つのであろう、と。
おそらく、お客様的には「この市場規模で、うちの実績がこれくらいで類似サイトの実績がこれくらいだから、システムにいくらまでのコストなら、これくらいで損益分岐点がくるからペイできて…」って考えます。

とはいえ問題なのは、上述の予測は「安く上げると精度があらっぽすぎて」「精度を上げていくと、しゃれにならないほど高額なコストがかかる」ので。
だとすると、お客様としては「よい感じの落としどころ」にせざるを得ないだろう、と予想されます。

余談。
上述を「そのビジネスに精通しているお客様」がやってですら、高額困難な状態で、それを「システム屋がどこまでできるのか？」と。
個人的には「お客様より低レベルな判断しか出来ない」と思ってます。
それはまぁ当然でしょうむこうさんは「その道の専門家」で、一方の我々は、少なくともそこまでではないので。
そこでもし「出来る」とか言える人は、おそらく「相手の専門性や、相手の専門性取得にかけた時間、などを軽視している」のだろうとしか思えません。

閑話休題

上述を考えると、「システムの価値」というものは、結果論としてはもちろん存在すると思うのですが、事前につかめるものか？ と考察をしていくと、どうも非常に「怪しい」ように感じられるわけです。
また、それゆえに実際の「営業/契約レイヤー」において(つまり「開発対象システムの価格を決める」タイミングにおいて)、そのシステムの「価値」とかいうものを「どのように推し量るのか」というと、おそらくは、非常に難易度が高いと予想されるわけです。
もちろん「難易度が高く、故にコストとして高額である」状態においてなお「そのシステムがもたらすであろうと予測される価値」を予測する必要があり、その「予測される価値」に基づく金額設定が必要であろうシステム、というのも、あろうかとは思うのですが。
一方で「もう少し価値予測コストをさげて」妥当な落としどころを探す必要があるシステムも、おそらくはあって。
で、その「妥当な落としどころ」の見つけ方として「作成コストによる値付け」という、これはどこの業界でも普通にやっていることを考えて。
で、たまたま「原材料費は限りなく０に近く、人件費が占める割合が圧倒的に大きい」ことから「時間給と作成コストが限りなく相関している」人月、という発想が、出てきたのだろうと思うです。

もちろん「人月」という数値に抽象化したことで、捨象されたものの中に「結構大事」なものが何気にあって、その部分での問題ってのは山積していると思うのですが。
現状、議論を見ていたりそこから考察してみたり、といった中で考えていると、「人月をすっぱりと捨てる」よりは「問題点にパッチをあてつつ運用する」ほうが、当面、現実的なんじゃなかろうか？ って思うに至るです。

んで、そこから、大本の主文である
> 突き詰めると人月の問題というのは、開発側が提供する価値に対してどのような金額的価値を認めるか、という点に纏められるのではないでしょうか。
につながると思ってます。
個人的には、お客様に提供できる(かつ説明できる)価値は「明示的に金額に落とせる」ものである必要がある、と思ってます。

わりと良く使う具体例ですと「美しいソースコード」に対する、技術側と経営側の乖離が、わりとわかりやすいかとおもってますが。
「なにを持って美しいとするか」には各種議論もあろうかとは思いますが、とはいえエンジニアとして「明らかに美しいソース」と「殺意が沸きそうになるほど小汚く腐ったソース」が世の中に存在すること、については、あまり異論がなかろうか、と思います。
また、その場合に「小汚い腐れソース」よりも「美しいソース」のほうが、圧倒的に「意味も価値もある」というのも、おおむねコンセンサスの取れるところかと思います。

では質問です「綺麗なソースというのは、金額にしていくらのメリットがあるのですか？ また、その算出根拠は？」

正直、大抵のエンジニアはここで撃沈します(苦笑
ただ、ここで撃沈している限り、経営層に対して、説得どころかそもそも「会話」をさせてもらえないです。
きちんと、それこそ「経営会計」レベルの用語なりをきちんとつかったエビデンスが展開できて、初めてそこに意味も価値もあろうというものだ、と思います。

あぁ一応念のため。「きちんと数値根拠が出せるレベルで」美しいソースコードには、意味があります。

そのあたりの「お客様に提供できる価値を、きちんと会計レベルで説明できる」のであれば「詳細な分析結果とともに、対象システムが生み出すであろうと予想される価値金額を基準にした価格設定」でもいいでしょうし「過去の分析から近似値が得られると考えられる人月計算を基準にした価格設定」でもいいでしょうし。
一方で「お客様が享受できる価値について、きちんとした説明ができない」ものであれば、たとえそれが「このシステムが提供できるとシステム屋が主張する価値金額を基準にした価格設定」であろうとも「このシステムを作成するためにかかる時間のみを変数にした人月計算を基準にした価格設定」であろうとも、お客様的には「まてやこら」になると思います。

ただおそらくその場合「妄想としか思えないようなシステム屋の見解のみ」よりは「とりあえず(どのみち妄想レベル程度の精度でしかないにせよ)一見どうにかなっているっぽく見える」人月のほうが、まだしも受け入れられやすく(元々、会計も経営も「すべてを数値化して扱いたがる」人種なので)。

…ということを考えると、やはり議論は「人月か否か」ではなく、もうちょっと別のところに本来はあるんじゃないかなぁ？ とか考えてみますが、どんなもんでしょうかね？

長々書かせていただいたわりに、落ちているところはエピさんが書かれている内容と対して変わらんような気はするのですが(苦笑

>> 創出される価値の話してないよ。あくまで売る側が提示した価値/価格ね。
> 個人的には「価値は価値」だと思っているです。或いは、そこにあるのは「売る側が(とりあえず概算で)提示して、お客様が"まぁこれなら売り上げ立つんじゃね？"程度に妥協していただける」価格、だけだと思っています。

うん。同意。「このへんから交渉始めね?」って売り手が提示する価値でおｋ。

>「妄想としか思えないようなシステム屋の見解のみ」よりは「とりあえず(どのみち妄想レベル程度の精度でしかないにせよ)一見どうにかなっているっぽく見える」人月のほうが、まだしも受け入れられやすく(元々、会計も経営も「すべてを数値化して扱いたがる」人種なので)。

これにも同意。

> 長々書かせていただいたわりに、落ちているところはエピさんが書かれている内容と対して変わらんような気はするのですが(苦笑

激しく同意(誘爆
相当に感覚的(あるいは感情的)な僕の思いをカタチにしていただきました。
ありがとさまです。

ユーザ「...こんなのあれば年間300万の利益増(orコストダウン)が見込まれるんだが」
ベンダ「(人月単価でちゃっちゃと電卓叩いて)ざっくり1000万で作れます。二年ちょいでペイできますね」
ユーザ「んじゃお願いしようか。ちょっと勉強してよ」
ベンダ「あっざーす!! 5パー引きでいかがっすか♪」

...問題ないねぇ。
時間(orコスト)かけずにそこそこ(かなり?)正確な売値の提示。

>επιστημη 2012年1月22日 (日) 11:34
このコメントは非常に問題ですね。
やはり口ではAhfさんに同意すると言いながら正反対の本音を隠して、反対意見でコメント欄を埋めという事ですね。
堂々と「お客様の事を考えない」と宣言されたとなると、非常に問題だと言わざるをえません。
エンジニアライフでこの様な本音が書かれる事は、IT業界のマイナスイメージとなります。
お客様が偶然目にするかもしれません。
その時、この手の人が「エンジニアの本音」だと受け取られると思うと、憂慮せずにはいられません。
ましてや、人月単価以外の手段を見つけ出し、お客様に対して価値あるシステムを提供したいというまっとうな趣旨の内容のコラムを荒らしてまで、「IT業界の人間はお客様のなんて考えていない」と宣言するなんて事は非常に問題です。
お客様が求めるものを分からずにシステムを提供し、その価格は自分たちの都合で架空計上して請求する。
そんな胡散臭い商売を支持している人がIT業界の実体だと思われたくありません。
システムを購入して頂いているお客さま方と、お客様の要望を満たすために真面目に働いている人々を侮辱するこの発言は許せません。
誤解されないように、この手の人は一部の人であり、普通に働いている人々の意見ではない事を明言します。
真実を書いている経産省の報告まで無視し、お客様を愚弄した商売をするのは、一部の悪い人間であって、大多数は真面目に働いています。
現在人月単価を採用しているところでも、お客様の意見は真摯に受け止め、努力しています。
その努力が一刻も早く実る事を祈っております。

ちょっとミスった。もう一度。

「まだ世の中に存在しないものの価値を、ましてや使う側にとっての"創出される価値"を、作る側が推し量ることなどできない。できたとしてもコスト的に見合わない」

のどこをどう解釈すれば「お客様の事を考えない」になるのか説明を求む。

またループにはまりそうなので先手を打っておく。

Ａ「まだ世の中に存在しないものの価値を、ましてや使う側にとっての"創出される価値"を、作る側が推し量ることなどできない。できたとしてもコスト的に見合わない」

Ｂ「お客様の事を考えない」

Ａの真偽を問うているんじゃないからね。
「ＡならばＢである」が真であるというあなたの論拠を示してほしい。

>「ＡならばＢである」が真であるというあなたの論拠を示してほしい。

予想される回答
「私は『not B ならば not A』を実現している。ゆえに対偶をとって、『A ならば B』は正しい」

>がるさん
>個人的には「価値とはなんぞや？」が、一つおおきなキーワードであるように感じられました。

まず、大きく２種類の視点があるわけですねぇ。

１、作ったソフトの価値
　製造元が保障できる価値はコレですね。
　また、製造元が妥当な利益として考える値段の根源でもあります。
　「このソフトならこれだけの利益を生み出すはずだ」と考え、利益を考えるのも有りだと思います。
　製作技術が同じなら、作る時間に比例して価値が高いものができると仮定しても良いでしょう。
　（これが人月単価の基礎的な概念ですよね？）

２、ソフトを利用した結果生まれる価値
　買う側が求めたいのはこちらですね。
　使うことにより発生する利益を価値として感じるでしょう。
　その特性上、使ってからじゃないと、正確な価値はわかりません。

同列で語るには無理がありますね、性質が違い過ぎるから。
どちらも、どのようなものに価値を感じるかで、大きくかわってしまいます。
ですから、価値自体を厳密に計ることはできない・・・ってことは、コメント欄で何回も登場してますね。

他の業種も同じだと思うんだけど、特注ってほとんど言い値じゃないですかね。
でもって、買う側がその金額に納得するかどうかでしょ？
作る側の考える価値と買う側の考える価値に折り合いが付けばそれでいいわけです。
でもって、売る側の努力として、買う側が納得できる根拠を提示すると。
いくら言い値でも、相場から大きく外れていたら納得しないわけでｗ
・・・まあ、これもコメント欄で何回も登場してますなｗ

それぞれの考える価値の内容が一致するのは理想だけど、完全に一致することはなかなかないでしょうねぇ。
むしろ、商売の基本である「安く仕入れて高く売る」で考えれば、買う側は「価値の内容」を伏せる場合もあるでしょう。
売ったものをどう扱うかは買う側の自由って考え方のほうが多いでしょうし・・・
だから、永続的に利益が発生するようなものは、PBCの例であるように一緒に売るような形態を作ったりするんでしょうね。

ＰＳ．
>人月単価には職位が使われる場合が多いです。
>SE:200万円
>プログラマ：100万円
>この職位制度から考えると、会社側としては「いつまでもプログラマでいてもらっては困る」という事になります。

あれ？IT系の人月単価ってこんなに個別に提示するんだ？
大きい会社だとそうなるの？
個別にしちゃう意味がわからないというか・・・個別に出すと揉め事の元になるような・・・
チーム開発だから、まとめ役が何人とかいう意味であえてわけるのかなぁ？

その謎は置いておいて、単価が低くてなにが困るのか真面目にわからないんだが・・・
その・・・なんだ・・・やっぱり派遣関係の話なんかなぁ(^^;

※2012年1月24日12時、一部コメント削除

>「私は『not B ならば not A』を実現している。ゆえに対偶をとって、『A ならば B』は正しい」

織り込み済みですｗ

- そこから導き出せるのは　「私に対し『A ならば B』である」 だし、
- 判定不能な命題を根拠としていいなら、いかなる結論も導き出せる。

誤：書く計上
正：架空計上
です。

「反社会的なお客様をないがしろにするその意見」であるなら
Ahfさん、運営さん、その他のオーディエンスから総スカン食って
ボコボコにされるだろうから心配しないで。

>生みだす価値を想定しない（結果論でしかわからない）という事は、初めからお客様の意向を無視する行為です。
できないというのであれば技術者でないので問題外です

PBCなんざ客がシステム使ってから価格が決まるっつー結果論の最たるもんやがな。
技術者ってなんだろね。

がるです

To Ｓｏｄａさん
> まず、大きく２種類の視点があるわけですねぇ。
はい。で…正直なところ、私は「作ったソフトの価値」というのを、あまり信用していません、というか、これは「かかったコスト」ではあっても「価値ではない」と思ってます。
なので、個人的には、１番は「作ったソフトの作成コスト」、２番が「このソフトの価値」だと思ってます。
「100万円かけて作ったから100万円の価値があるんだ」は、意味がない上に誤謬を招きやすいので、個人的には非常に「否定的な見方」をしています(苦笑

なので、私の書いてある中での「価値」というのは、徹頭徹尾「２番」を指しています。

で…おそらく。
お商売的には「受注側は、作成コストである１番は認識できていて、そこを基準に価格を設定し」「発注側は、２番を予測し、価格設定の妥当性を判断するのだろう」と思うです。
あとはまぁ、受注側としては(おいちゃんはこっち側なので)「２番の予測がより高くなるように、色々なビジネスの方向とか膨らませ方とか将来性とかコラボネタとか」を提案させていただいて、それが通ると「比較的高めの作成費用」でも通るんじゃないかなぁ？ と、営業的努力をしていくわけです(笑
＆
お客様が「うちが作ったソフトで儲かれば」また次のシステムの発注とか納めたシステムの改修とかでうちのお仕事が増えるので、だからこそ彼らの成功を心から祈るわけです。

> 他の業種も同じだと思うんだけど、特注ってほとんど言い値じゃないですかね。
> でもって、買う側がその金額に納得するかどうかでしょ？
知っている限りにおいては、おおむね。
もちろん相場はあると思いますが、その辺の相場観って非常に曖昧ですし、その「相場観」は、なんとなく、このITの市場でも形成されてきているんじゃないか、って思います。よしあしは置いておくにしても。
あとは…この辺、被服の世界が面白いのですが。
・フルオーダー
・イージーオーダー
・パターンオーダー
・レディ・メイド
と、特注具合にも色々とあるので。この辺は、或いは考察の一助になるかもしれません。

追記
「あたりまえ」なんて、世の中のどこにいっても存在はしない、と、おいちゃんは思ってるです。或いは「あたりまえが(に)ある」と物事を考えた時点から、色々と、不和疑念怒り苦しみの種が、あちこちに蒔かれるのではなかろうか、と。
どちらかというと「なにもない」状態で、もしあったらそれはとても「有り難い」こと、なのではなかろうか、と。

そういえば、ものすごく興味があるので、エピさんに質問です。

エピさんは、多分お仕事で
・お客様のニーズのヒアリングをして
・そのニーズにあった要求分析をして
・場合によっては逆提案とかもして、その辺を分析結果に盛り込んで
・分析やら設計やらをお客さんに説明をしてご理解ご納得いただく
というタスクをこなし、その費用計算の根拠として「人月を使っている」んですよね？

という単純な疑問。

↑ですね。

事と次第によっちゃ「もっと安く/簡単にやれるよ」なんつー、
わざわざてめぇの儲けを削ぐよなことまで言っちゃいます。
# 営業さんが渋い顔するけどねー

懲りもせず人月単価支持活動していますね。

>事と次第によっちゃ「もっと安く/簡単にやれるよ」なんつー、
わざわざてめぇの儲けを削ぐよなことまで言っちゃいます。
# 営業さんが渋い顔するけどねー

必死でフォローしていますが、「お客様の求める価値なぞ知らん」といった人が言っても説得力がありません。
この人たちは、お客様が求めるものを知らずに、架空計上して作ろうとしています。
こういう人達がいるとなると、お客様に不信感を持たれても仕方がありませんね。
ただ、見ての通りの一部の仲良しグループであるという点を考慮して下さい。

IT業界の個件に関わるのでもうひとつ言います。
この一部の人達は必死で、「システムは導入しないと価値が分からない」と主張していますが、そんな事はありません。
できなればプロでありません。
そんなあやふやなものに投資できるはずがありません。
お客様が求める価値を作り出すのが我々の仕事であって、「動かないと分からない」などといったいい加減なものを売る商売ではありません。
くれぐれも誤解しないでください。

>> 事と次第によっちゃ「もっと安く/簡単にやれるよ」なんつー、
>> わざわざてめぇの儲けを削ぐよなことまで言っちゃいます。
>「お客様の求める価値なぞ知らん」といった人が言っても説得力がありません。

「作り手のエゴ」と思ってもらってもかまわんですよ。
安くすれば"買ってくれる率"が上がるし、なにより僕らが楽できるからね♪

>なにより僕らが楽できるからね♪
やはりそうですか。ここが本音ですよね。
お客様の要望を聞くという当たり前の事をさぼって、安い値段で架空計上する。
※もし聞く気ならば、架空計上や「お客様の事なんて知らない」と発言しません。
もう貴方達の悪徳商法を書くのを止めて下さい。
IT業界全体が悪徳だと誤解されてしまいます。
貴方を雇っている会社に対しても、お客様に対しても、真面目に働いている大多数の技術者にとっても迷惑です。
貴方様の心は変えられませんが、せめてIT業界の信用に関わるような言動は控えて下さい。
Ahfさんのコラムに書かないで、自分たちのたまり場で書いて下さい。

> IT業界の個件に関わるのでもうひとつ言います。

× 個件
○ 沽券

> この一部の人達は必死で、「システムは導入しないと価値が分からない」と主張していますが、そんな事はありません。

「御社のビジネスとその仕組みを精査したところ、
　本システムの導入で年間1000万の利益増が見込まれますっ」

...どこのスパイだ?

>> なにより僕らが楽できるからね♪
> やはりそうですか。ここが本音ですよね。

そうですよ。お客様は安く買える/僕らは楽に提供できる。
Win-Win じゃないか。すばらしい。

当然その逆も。
「お客さん、そりゃちょっと甘いですわ。端末増えたらパンクしますぜ」
などなど。

「スケーラビリティを確保した上で、スモールスタートしましょうよ」
なんてのも。

To επιστημηさん

> 事と次第によっちゃ「もっと安く/簡単にやれるよ」なんつー、
> わざわざてめぇの儲けを削ぐよなことまで言っちゃいます。
> # 営業さんが渋い顔するけどねー
多分ここが一つ、非常に「考えなければならないところ」だと思っています。

んと…レオナルド・ダヴィンチの、この話を前提に、少し。
＞＞
レオナルド・ダヴィンチが注文主に、「短時間で仕上た作品に、どうしてこんなに金がかかるのか」と言われた時に、
「あなたはお忘れになっているのです。短時間で仕上げれるようになるまで私が費やした時間の事を。」
と返したそうです。
＜＜

上述なのですが、もしかすると「もっと安く、もっと簡単に出来る」ことに気付けたのは、設計できたのは「エピさんだから」なのかも、しれないです。
で…だとすると、おそらく対外的には「もっと高値を取るべき」かもしれず、ただおそらく、エンジニアってそこで「高値を付けられない」人種が多いんじゃなかろうか、って思います。
…おいちゃんも、よく下の子にこの辺は怒られます(苦笑
ちなみに「もっと安く、簡単に」組めるということは、おそらく設計が「シンプルで美しい」可能性が予見されるので。
その場合「運用や改修のコストが安い可能性」が想起されます。
# 一方で「高スキルでないと扱えない難易度」だとすると、技術者の「調達コスト」が高い可能性もまた、当然ながら想起されます。

一方で、もちろん「スキルが低いことによって」非常に高額で面倒な「小汚い設計」にしてしまうこともあり。
この場合「お客様は、きっと納品後に運用で苦労するであろう」システムであることが予見されます。
技術者の調達コストは多分安いのですが、実質的な部分で「汚いまま」なので、結局「ものすごいコストがかかる」ことは用意に予見されます。

このあたりを真摯に考えたときに、今一度「本当に、かけた時間のみを変数として、システムの値段を設定してもよいのか？」という考察は、非常に意味があるのではないか、と思います。

で…おそらく。
その辺で「設計にも自信があるしある程度企画にもかめる」のであれば、契約形態としての「パフォーマンスベース契約」という考え方(の中にある「収益向上型」、言い換えると、いわゆるレベニューシェア)もまた、一つの選択肢として「考慮するにやぶさかでない」方向が、あると思うんですね。
ただ「開発のみで企画にかかわれない」とすると、 http://www.meti.go.jp/press/20090731004/20090731004-2.pdf のP22にも在るとおり
「また、第２章で整理した想定ケースのうち、システム開発におけるPBC の適用（ユ
ーザが検討するケース）では、事業や業務に対するベンダの関与が小さいため、収益向
上型やコスト削減型、CS 向上型、業務品質向上型の適用は難しい。」
となってしまうんじゃなかろうか、と思うです。

…ただ、この見解って「純粋にシステム開発のみをやりますよ」で、そのビジネスモデルって、すでに大分と怪しくなっていると思うのですが(苦笑

そんなこんなを考えたあたりで、おそらく本来的に鍵になってくるのは「そのシステムによってお客様が享受できる売り上げ、及びそれに密接にかかわると考えられるシステムの質」について、どのように推し量るのか？ というのが、なんとなく議論の向かっていく方向なのかなぁ？ とか考えてみます。
実際問題として「お客様が欲しい」のは「そのシステム使ったらなんぼ儲かるのん？」でしょうし、ただそのために「必要な品質」はあるでしょうし(また逆に「儲かるためには不要な品質」もまた存在しますし)。

そのあたりを考察していくと
・まぁとはいえ、会社ごと人ごとに係数(人月単価)は異なるにしても、作成にかかる時間をベースにコスト換算しても近似値にはなるよねぇ
なのか
・どうみても乖離がはなはだしいので、もうちょっとなんか考えなきゃいけない
になるのか(まぁ「どっちか」ではなくて最終的には「ケースbyケース」なのでしょうが)が、見えてくるんじゃないか、って思います。

「手の内明かすつもりないけど僕出来る」とかいう妄言には興味がないので(そも、「手の内明かさないけど出来る」では、本当に出来るのか、出来ている"つもり"なのか、検証することが不可能なので、論じるだけ無駄です)。
きちんと「手の内をさらしつつ」会話と議論と提案とが出来る方々で、この辺について、少しやり取りをしてみたいような。

多分、その先に、もしかしたら「システムの価値」と「エンジニアの評価」という命題が、また少しクリアになる何かがみつかるんじゃないかなぁ？ っておいちゃんは思います。

> 上述なのですが、もしかすると「もっと安く、もっと簡単に出来る」ことに気付けたのは、設計できたのは「エピさんだから」なのかも、しれないです。

外注さんの中に"DB使い隊"がありましてね、もうなんもかんもDBに突っ込みたがる。
レコード数高々ン十でもDBにテーブル起こす。んなもんベタなテキストでいーぢゃん! なのも。
DB扱わせればピカイチなのは認めるけど、なんか技に溺れてね? みたいな。
# 早晩これがン万に膨れ上がりそうなら"DB使い隊"に一任すっけどさ

> で…だとすると、おそらく対外的には「もっと高値を取るべき」かもしれず、ただおそらく、エンジニアってそこで「高値を付けられない」人種が多いんじゃなかろうか、って思います。

うんうん。「簡単にできたから安くていいよ」って言っちゃいますねー ^^;
「俺の脳みそのおかげで楽ができたんだから、俺の脳みそもっと高く買えよ!」
って主張は十分通るハズなんですけどねー

> ・まぁとはいえ、会社ごと人ごとに係数(人月単価)は異なるにしても、作成にかかる時間をベースにコスト換算しても近似値にはなるよねぇ
なのか
> ・どうみても乖離がはなはだしいので、もうちょっとなんか考えなきゃいけない

「人月単価で荒っぽく換算し、"別のナニか"で微調整」かも知れんですしね。
# "別のナニか"がはたしてナニかがわからず歯がゆいんだけども ^^;

がるです。

先にこねたを。
> > この一部の人達は必死で、「システムは導入しないと価値が分からない」と主張していますが、そんな事はありません。
> 「御社のビジネスとその仕組みを精査したところ、
> 　本システムの導入で年間1000万の利益増が見込まれますっ」
> ...どこのスパイだ?
正確には「御社のビジネスにおいて、本システムの導入で初年度に1000万、次年度に1200万、その次の年度で700万がみこまれますが、その後＊＊国の経済状態の悪化により50万程度の利益増となり、本システムがcloseされます。そのため、本システムは最終的に、４年間で2910万円の利益増を生み出す価値があります」ですねぇ。
スパイってよりはもはや預言者レベルかと。
もちろん「マクロ経済論の応用で、ある程度の精度でそれが可能なのです！」というのを特に否定できるだけの手持ちもないのですが。
せめても「今までこれくらいの案件で実際に価値を計って、精度の算術平均はどれくらいで偏差分布的にはこれくらい、で売り上げについて見通せたので、自分はシステムの価値を判断可能である、といえるだけの手法を持っていると考えてます」とかいう話があれば別なのですが。
それがない以上「凄いんだかスゴイんだか区別が付かない」のが、多分これを読んでいるほとんどの方の本音、なんじゃないでしょうかね？
まぁ正直、現状においては、いずれにせよあまり興味が持てないのですが(検証不能なものに労力突っ込むほどの余裕はないので)。

で、本題。

> うんうん。「簡単にできたから安くていいよ」って言っちゃいますねー ^^;
> 「俺の脳みそのおかげで楽ができたんだから、俺の脳みそもっと高く買えよ!」って主張は十分通るハズなんですけどねー
多分これって、結構重要かつ「現状がまずい」一端だと思ってます。
エピさんのスキルって、例えば「書籍を数冊読んで、数本プログラム書いたらたどり着ける」領域からは、確実にいろんなものがかけ離れてますよね？
どれくらい、書籍やら考察やら実務経験やら執筆やらその他諸々の「投資をしてきたのか」と考えると…結構なボリュームがあると思ってます。
で、その「投資」に見合った「報酬」が、もし得られないとすると。エンジニアとしては「自らのスキルアップに投資をする」理由が、なくなっちゃうんですよね。
わりと燦々たる状況を想像するに、わりとダイレクトに寒気がします。

もちろん、その逆もしかり。
だからこそ、本来的には「技術者が生み出すもの」が作り出す「価値(==売上総利益)」について、もっともっと、真摯に取っ組み合う必要がある、と思ってます。

> 「人月単価で荒っぽく換算し、"別のナニか"で微調整」かも知れんですしね。
> # "別のナニか"がはたしてナニかがわからず歯がゆいんだけども ^^;
個人的には「単価の微調整」が、割合とその「なにか」に近いことができるんじゃないかなぁ、と思ってます。
んと…前述で出てきた「プログラマ100万、SE200万」なんてのは、下策の最たるものではあるのですが(そもそも、プログラマとSEの定義すら明らかでないし、２段階ってちょっと粒度が荒すぎます)。
コストとの兼ね合いもあるのではありますが、ちょっと「精度高め、コスト高め」にふりますと「社内では、一人ごとに人月単価が違い、かつ、それは１～３ヶ月ごとに細かく査定される」とか。
で、実際にお外に売り出すときは「組み合わせて地ならしして」平均値で持っていくと、多分お客様的には「比較的分かりやすい」見積書になるんじゃなかろうか、と。
「標準パック(一般的な金額のエンジニアの組み合わせです)」「高品質特急パック(ハイレベルなエンジニアの組み合わせなので、仕事速いですがお金高いです)」「教育兼任パック(新人が混ざるので、人数に比較してお安めです。ハイレベルエンジニアが入ってますので、最終的なシステム品質は保証をいたしますが、通常より少し長い工期がかかります)」とか。
…いやまぁ、これが「ある程度の人数」のところで、どこまで(近似値にせよ)できるか？ ってのはあるのですが。

あとは、別の切り口として。
それこそ話しにあがっている「パフォーマンスベース契約」が、(微)調整要素として、ありなのかもしれません(というか、PDF見ているかぎり、調整要素としての印象を強く受けましたし)。
「とりあえず手を動かしてもらったし、最低限としていくらは払う。ただ、このKPI指針を越えたものであれば、一定の比率で追加の料金を支払う」とか。
それはそれで「KPI指針とお金との紐付けかた」とかトラブルが起きそうではあるのですが、システムのお値段をつける方法の一つ、として、手持ちのカードにある分には、おもしろいんじゃないか、って考えてます。

>「あたりまえ」なんて、世の中のどこにいっても存在はしない、と、おいちゃんは思ってるです。或いは「あたりまえが(に)ある」と物事を考えた時点から、色々と、不和疑念怒り苦しみの種が、あちこちに蒔かれるのではなかろうか、と。
>どちらかというと「なにもない」状態で、もしあったらそれはとても「有り難い」こと、なのではなかろうか、と。
わりとよく使っちまう言葉なことに気づいて愕然とした。
んで、どこかの本に書かれていた言葉を思い出してちょっと笑った。
「○○の常識、△△の非常識」（あたりまえ＝常識ではないですが）

>事と次第によっちゃ「もっと安く/簡単にやれるよ」なんつー、
>わざわざてめぇの儲けを削ぐよなことまで言っちゃいます。
># 営業さんが渋い顔するけどねー
これって...
>・お客様のニーズのヒアリングをして
>・そのニーズにあった要求分析をして
>・場合によっては逆提案とかもして、その辺を分析結果に盛り込んで
>・分析やら設計やらをお客さんに説明をしてご理解ご納得いただく
といったフェーズをきっちりやってないと言えない言葉ではないかと思ってみたり。

>うんうん。「簡単にできたから安くていいよ」って言っちゃいますねー ^^;
>「俺の脳みそのおかげで楽ができたんだから、俺の脳みそもっと高く買えよ!」
>って主張は十分通るハズなんですけどねー
あー、なんでうちの会社の発注先にはこーゆー人がいないんだろうと...（苦笑）
ま、それはさておき。
がるさんとかεπιστημηさんの会話をみるにつけ、とりあえず「価値」の話は棚上げして「質」に焦点をあてると結局は「人」になるんでしょうか？
発注側から一番見えにくい部分...かもしれない、とふと思った。

議論できるだけの素材をもってないのでとりあえずあとはうぉちゃに転身。

To nightRavenさん

> わりとよく使っちまう言葉なことに気づいて愕然とした。
そうなんですよね。自分も結構ありました(苦笑
自分は、数年前から結構読み倒している「禅語」で、このあたりを読みまして「あぁなるほど」と、妙に腑に落ちました。

他人に期待をしてしまうと「＊＊をしてくれてあたりまえ」「＊＊はできて当然」となって。
で、その「脳内の一方的な期待」に反すると、本当は「自分の想定に誤りがあったはず」なのに、その責を相手に転嫁して「＊＊をしてくれないなんてなんて酷いひとなんだ」「＊＊ができないなんてなんで愚かな人なんだ」となってしまう、と。
だから「あたりまえはどこにもないんだよ」と思うことで、もうちょっと状況がフラットに見えるんだなぁ、ってのを、学びました ＾＾

> とりあえず「価値」の話は棚上げして「質」に焦点をあてると結局は「人」になるんでしょうか？
> 発注側から一番見えにくい部分...かもしれない、とふと思った。
多分、どうしても「属スキル」になる部分はある程度避けられず、んで、その「スキル」は、どうしても(ある程度)人に依存してしまうと思うので。
ただ一方で、あんまり「人」にスポットライトをあてすぎると、お客様的に「…いやまぁその人すごいんだろうけどさぁ今回そのスキルいらないんだけどなんでいらないものにまでお金払わなきゃいけないのよ？」ってなると思うので(苦笑
「人」のもつ「スキル群」のうち「今回売り出して値が付きそうなもの」を、いかに適価で売りに出すか？ ってのが、やはり根本にあるのだろうと思います。

で、「一山いくらの人月勘定」だと、その「スキル」部分あるいは「スキルによってもたらされ、お客様が享受できる価値」部分に対して、金額が「そぐわないんじゃなかろうか？」ってのが、このコラムのお話だと思っているので。
その辺が、なんかうまいこといくといいなぁ、ってのが、多分その辺はみなさんの偽らざる本音なんじゃなかろうか、って思います。

なので。
おいちゃん的には、まぁもちろん「近似値」程度ではあろうと思うのですが、その人のスキル(或いは作ったシステム)の「質」をはかるものさしは、一つ、この辺の会話に重要だろうと思ってます。
ただ…実はおいちゃんがその辺をはかるものさしの一つは「お客様が実際に売り上げた金額」とかだったりするので、実は真面目に話しだすと、色々とloopしていくのですが(苦笑

なかなか難しい問題なだけに、議論を重ねることができるのを、とてもうれしく思っています ＾＾

>「投資」に見合った「報酬」が、もし得られないとすると。エンジニアとしては
>「自らのスキルアップに投資をする」理由が、なくなっちゃうんですよね。

うーん、ここらへんはなんつーか職人気質つかエンジニアの性つーか、
うまいことさくさくーっとこしらえて一人悦に入るエクスタシーつーか、
ちゃかちゃかちゃかとキーボード叩いて最後の改行"パッカーン！"の快感つーか。

「投資に見合う報酬が得られない」については
「好きじゃなきゃやってらんねーよ」ってヤツかしらねぇ。
好き故に我慢できるならそれで善しとは思わんけども。

あ、その代わり、おシゴトとはなーんの関係もないコードいぢくってても黙認してくれます。
いつか必要となる(かもしれない)手駒を貯めてると思ってくれてんでしょか。
# 肩越しにスクリーン覗いてもおシゴトか遊びか判断できないだけかもですが ^^;

あぁ、もう書かないつもりだったのに、どうしても興味の方が先に立ってしまった...すみません。

がるさん
「あたりまえ」の話、深いですね...。
確かに時々そういう思考に陥ってる自分に気づきます。

>ただ…実はおいちゃんがその辺をはかるものさしの一つは「お客様が実際に売り上げた金額」とかだったりするので、実は真面目に話しだすと、色々とloopしていくのですが(苦笑
「お客様が実際に売り上げた金額」というものさしはどういった状況で使用されるんでしょうか？
さしつかえなければ聞いてみたいなぁ...と思いまして。
導入後のシステム評価、くらいしか思いつかなかった...というのがありますです...orz

επιστημηさん
>うーん、ここらへんはなんつーか職人気質つかエンジニアの性つーか、
>うまいことさくさくーっとこしらえて一人悦に入るエクスタシーつーか、
>ちゃかちゃかちゃかとキーボード叩いて最後の改行"パッカーン！"の快感つーか。
昔気質の職人さんのイメージだったんですが、間違ってなかったようですｗ
その分、営業さんが結構苦労してるのかなぁ...と思ってみたり。

> その分、営業さんが結構苦労してるのかなぁ...と思ってみたり。

営業さんに迷惑かけんよう、技術的なトコしか口を挟まないと誓ってんですけど
ついポロリと...べ、別にアンタのこと嫌いじゃないんだからねっ > 営業さん

To επιστημηさん

> うーん、ここらへんはなんつーか職人気質つかエンジニアの性つーか、
> うまいことさくさくーっとこしらえて一人悦に入るエクスタシーつーか、
> ちゃかちゃかちゃかとキーボード叩いて最後の改行"パッカーン！"の快感つーか。
>
> 「投資に見合う報酬が得られない」については
> 「好きじゃなきゃやってらんねーよ」ってヤツかしらねぇ。
> 好き故に我慢できるならそれで善しとは思わんけども。
わっはっは、基本的には「すげぇよく」分かります(笑
多分、一定のレベルを超えて「離陸している」と、だいたいこんな境地ですよね。
「好きこそ物の上手なれ」とはよぉいうたもんだ、と、しみじみ感じるときが多々あります。
# それで気付いたのですが、おいちゃんは多分「ゲーム作ってる」のが、一番向いているぽいです(苦笑

ただ、まだ「滑走路をえっちらおっちら」走っているような、けつの殻が取れていないひよっこたちにとっては「食えるか食えないか」って、結構大事で。
なので、ある程度のレベルまでは「ちゃんと、学べば収入が付いてくるんだよ」って道を付けてあげたいんですよね。
ちゃんと食えるようになったらあとは「好きな事やって、金じゃ買えない満足を得にいってらっしゃ～い」ってなるのですが。

まぁ、この辺は、おいちゃんの「欲」です(笑

> あ、その代わり、おシゴトとはなーんの関係もないコードいぢくってても黙認してくれます。
> いつか必要となる(かもしれない)手駒を貯めてると思ってくれてんでしょか。
> # 肩越しにスクリーン覗いてもおシゴトか遊びか判断できないだけかもですが ^^;
そのコードを「適切に理解した上で」「営業手段考えて」「そろばんを弾いてる」ような敏腕つか辣腕な営業さんだと、それはそれで怖いですがｗ

To nightRaven さん

> 「お客様が実際に売り上げた金額」というものさしはどういった状況で使用されるんでしょうか？
> さしつかえなければ聞いてみたいなぁ...と思いまして。
> 導入後のシステム評価、くらいしか思いつかなかった...というのがありますです...orz
わりとそのまんま、になります(笑
仲のよいお客様限定ですが。納品したシステムの「利益」を大まかうかがって、システム起因をとりあえず５割と仮定。
あとは「利益」を「自分の分担したタスク量」で割って、評価ポイントのベースに。
システムが複数あると、多少なり「個々人ごとに異なる」評価ポイントが、とりあえず、数字で出るです。
で、ポイントはどちらかというと「その後」にあって。
「んじゃ、なにをやったら自分の評価が上がると思う？」って質問をすると、「利益」が自分の真横にある分、わりと真剣に考えるので、逆提案のスキルが磨かれます(笑
ポイントは「売り上げ」ではなくて「利益」をベースにすること。売り上げベースでは、意味が薄くなるので。

もう一つは、うち(自分がやってる会社)の場合「実装量にそって支払う金額が決まる」ので。
システムの金額は、言ってみれば「お客様が"支払ってもいい"と思ってくださった金額」なので。そこから「自分が一定期間に作業できた量」を掛け算すると、自動的に「得るべき収入/稼いだ金額」が算出されてきます。
結構みもふたもない数字になるので、大変に露骨で気に入っております(笑

…という上述も、一式「人月」ベース、ではあるのですがね。
見積もりのときは「大まか平均的スキルとしてこれくらいであろう」という仮想のエンジニアを一人想定して、そこから「その人が作成にかかるであろう日数」の想定で、見積もりとかをしている感じです。

ここまで自分が出来ない事を前提にして、人月単価を維持する方向で話しを進めるのはある意味凄いですね。
預言者などと変な事を言っておりますが普通にできる事です。
お客様に価値をもたらすことを前提にシステムを提案／設計／実装しているのですからできて当たり前です。
嘘をついてシステムを販売している事になるので、できないといのは商売にならないレベルです。
どんな価値があるのか分からないものに投資する経営者はいません。
商売にならないレベルの技術力で商売しようとするから、システムの価値を誤魔化すために人月単価で架空計上するしかなくなるのです。
個人の技術力の低さをIT業界全体の用に表現するのは止めて下さい。
普通の会社はそれぐらい出来て当たり前です。
それが出来ないのであれば、そのシステムには投資する価値がありません。
お客様を甘く見ているようですが、ITバブルはもう終わりました。
今まで通りに甘い基準で投資してもらえると思ったら大間違いです。
投資価値が分からないシステムに投資するなんて事は続きません。
よく考えたら、お客様に提案する能力がないがない人は市場原理に従って自然淘汰されますね。
それに、一部の悪い人である事を明記したので、良識あるお客様には伝わるでしょう。
議論にならない（最初から議論ではなく注意をしている）ので自然淘汰されるのを待つ事にします。

>納品したシステムの「利益」を大まかうかがって、システム起因をとりあえず５割と仮定。
>あとは「利益」を「自分の分担したタスク量」で割って、評価ポイントのベースに。
>システムが複数あると、多少なり「個々人ごとに異なる」評価ポイントが、とりあえず、数字で出るです。

ええと、理解が遅くて（というか、ぶっちゃけ頭悪くて）非常に申し訳ないのですが...（冷や汗）
顧客に発生した利益を個々（技術者）の評価に反映させてる、ということでしょうか？

>で、ポイントはどちらかというと「その後」にあって。
>「んじゃ、なにをやったら自分の評価が上がると思う？」って質問をすると、「利益」が自分の真横にある分、わりと真剣に考えるので、逆提案のスキルが磨かれます(笑

επιστημηさんの話にあった「凄腕」さんの話じゃないけど、次につなげるための土壌って感じがします。

>ポイントは「売り上げ」ではなくて「利益」をベースにすること。売り上げベースでは、意味が薄くなるので。
んと、その場合、利益がすぐに上がらないものとかに対してはどのようにしてるんでしょうか？
半年に１回とか定期的にやっていくってことになるのでしょか？（まんまボーナスの査定みたいだけど...）

>「実装量にそって支払う金額が決まる」
ええと、これはシステムの価格ということでしょか？
ちょっと「実装量」の単位がよくわからない...。
ここ読んでる人はみんなわかってることだったりするんだろうか...（汗）

>そこから「自分が一定期間に作業できた量」を掛け算すると、自動的に「得るべき収入/稼いだ金額」が算出されてきます。
>結構みもふたもない数字になるので、大変に露骨で気に入っております(笑
んんん...？
なんとなく、ひと山いくら？で曖昧になってる部分を明確にしてみました、みたいに読めるんですが...。

>…という上述も、一式「人月」ベース、ではあるのですがね。
>見積もりのときは「大まか平均的スキルとしてこれくらいであろう」という仮想のエンジニアを一人想定して、そこから「その人が作成にかかるであろう日数」の想定で、見積もりとかをしている感じです。
「大まか平均的スキルとしてこれくらいであろう」という仮想のエンジニア＝その技術集団のスペック...というか
Ｓｏｄａさんの言われる「仮想的な材料費」とかεπιστημηさんの言われる「仮想単位」ということ...かな？

なんかものすごく「教えてくん」みたいで申し訳ないです...。

余談
επιστημηさんは実は結構ツンデレだった...と...ｃ⌒っﾟдﾟ)っφ　ﾒﾓﾒﾓ...

To nightRavenさん
ちぃと長くなりそうなのですが…コンパクトにまとめつつ、本来の趣旨である「このコラムへのコメント」という立ち位置を踏み外さないようにがんばってみます。

> ええと、理解が遅くて（というか、ぶっちゃけ頭悪くて）非常に申し訳ないのですが...（冷や汗）
> 顧客に発生した利益を個々（技術者）の評価に反映させてる、ということでしょうか？
おおむねYesです。実際には「評価に反映」ってほど、何か(金額とか)に反映させるわけではないのですが。
ん…言ってしまうと、これも一つの「ゲーミフィケーション」なのかも。
数字になると、その数字が「特になにも影響しない」としても、高いところ狙いたくなりません？(笑

> επιστημηさんの話にあった「凄腕」さんの話じゃないけど、次につなげるための土壌って感じがします。
あぁ…言われて逆に気付きました。
おいちゃん、多分「次につなげる、をしない」ことが、念頭に存在していないので(苦笑
基本、あらゆる行動は「可能な限り、今と次とを等しく見つめる」ようにしてるです。

> んと、その場合、利益がすぐに上がらないものとかに対してはどのようにしてるんでしょうか？
> 半年に１回とか定期的にやっていくってことになるのでしょか？（まんまボーナスの査定みたいだけど...）
１年に１回くらいっすね。実際、半期とか四半期ごとにその辺弾いてるところも少ないので(苦笑

> ちょっと「実装量」の単位がよくわからない...。
あぁ、まんま見積もりの人月(っつか人日)っすね(笑
アジャイルとかその辺だと、見積もりって、とても丁寧にやっていると思うんですね。
「見積もりゲーム」とかもあるし、まずそもそも見積もりは「実装者」がやる、とか、あとは「皆で数値が一致するまで見積もりを何回もやり直す」とか。ベロシティなんてのもありますね。
そうすると、うちの場合Web系が多いので、lineという単位(「入力 -> 確認 -> 完了」とか「検索項目入力 -> 検索結果出力」とか)で細かく見積もるのですが、個々の機能ごとに「この機能は何人日」っていう数値が決まるので。
したら、後はシステムの納品時に
・実際に消化した機能、が持っている人日の合計
を単純に合算して、後はそれに金額を掛け算すると
・実際に自分が着手できたものに対する収入
が手に入るです。

実際、一ヶ月かけて10人日分もできない新人さん、一ヶ月で40人日分くらい片付けたベテラン、などが存在しますんで。
割合とダイレクトに、報酬に反映されます(笑

> んんん...？
> なんとなく、ひと山いくら？で曖昧になってる部分を明確にしてみました、みたいに読めるんですが...。
ん…どうなんでしょうかねぇ？
もちろん、おいちゃん的には「その部分をできるだけ明確にするため」という目標にそって、この手法を考えはしたのですが。
ただ「どの程度できているか」と問われると…まだまだ、懐疑的なところが多々(苦笑
なので「ひと山いくら？で曖昧になってる部分を明確に」するための山を登山中、くらいに見てもらえると、すげぇうれしいです ＾＾

> 「大まか平均的スキルとしてこれくらいであろう」という仮想のエンジニア＝その技術集団のスペック...というか
> Ｓｏｄａさんの言われる「仮想的な材料費」とかεπιστημηさんの言われる「仮想単位」ということ...かな？
うい、まさにその通りかと。
後ついでに、新人さんはまずなによりも「その仮想エンジニアと同レベルにならべるようになる」ことを、ベテランは「その仮想エンジニアの、５～10倍以上、くらいの性能値が出せるようになること」を、とりあえず目標に出来るので。
その辺の「目標用の目印」にも使ってます ＾＾

上述のような運用をすると。
「若干偏りがあるんじゃないか？」という疑念はあるにせよ、ある程度「技術に沿った報酬」を出せるようになると思っていて。
それは「開発側が提供する価値に対してどのような金額的価値を認めるか」の、一端にはなるんじゃないか、って思うです。

ちなみに「提案と良質な設計」は、どちらかというと「遅効性」だと思っていて。
つまり「適切な逆提案と素晴らしい設計」が提示できると、金額は高くならないにしても「たくさんのお客様と密につながることが出来る」一方で、「唯々諾々な受注と唾棄すべき設計」の提示は「お客様離れ」を招くので、結果、営業フィーがすげぇかさむ、と。
その辺が、高スキルに対する報酬の一つなんじゃなかろうか？ って思ってるです。

＆
余談。
> επιστημηさんは実は結構ツンデレだった...と...ｃ⌒っﾟдﾟ)っφ　ﾒﾓﾒﾓ...
知らなかった。
しっかりと心に刻んでおきましょう(笑

> 預言者などと変な事を言っておりますが普通にできる事です。
> お客様に価値をもたらすことを前提にシステムを提案／設計／実装しているので> すからできて当たり前です。

「手の内明かすつもりないけど僕出来る」とかいう妄言には興味がないので(そも、「手の内明かさないけど出来る」では、本当に出来るのか、出来ている"つもり"なのか、検証することが不可能なので、論じるだけ無駄です)。

>「実装量にそって支払う金額が決まる」

「雇ってるプログラマに支払う額」はそいつが書いたドキュメントなり
コードなりの量に応じて...と解釈したですが。そうだとして:
コードについて言えば知恵を絞ってコンパクトに実装するほど手取りが減るのはなんとも...

> επιστημηさんは実は結構ツンデレだった...と...ｃ⌒っﾟдﾟ)っφ　ﾒﾓﾒﾓ...

ばっバカ! 違うって言ってるでしょ! 謝りなさいよ!

>> ちょっと「実装量」の単位がよくわからない...。
> あぁ、まんま見積もりの人月(っつか人日)っすね(笑

あ、そかそか。さばくことのできた「お仕事カードの枚数」か。

To επιστημηさん

をを巨大な誤解を招く文章でした。申し訳ない。

> >「実装量にそって支払う金額が決まる」
> 「雇ってるプログラマに支払う額」はそいつが書いたドキュメントなり
> コードなりの量に応じて...と解釈したですが。そうだとして:
> コードについて言えば知恵を絞ってコンパクトに実装するほど手取りが減るのはなんとも...
「実装量」の単位は「機能」です。間違っても、行数とかではないです(苦笑
なので、１つの機能を「コンパクトに速やかに」実装したら、その分だけ(最終的に片付ける機能量が増えると予想されるので)手取りが増えるです。

> ばっバカ! 違うって言ってるでしょ! 謝りなさいよ!
…ここでまっすぐ誤ったら、どんなデレが見れるのだろう？ とか妄想をたくましくしてみる(笑

>「実装量」の単位は「機能」です。

えーと...んじゃこれを売値に適用すれば
「こんなことできたらいいなカード(重みつき)」の枚数 × カード一枚のお値段
なんてのはどぉじゃろね?

白皿10万/金皿50万でそれぞれ何枚食ったからいくら、みたいな。

επιστημηさん

ごっ...ごめんなさいっ！！！

↑そんなミエミエの釣りに俺様が引っかかると思ってクマーー

エピさんとnightRavenさんのステキなやり取りをニヤニヤしながら眺めつつ(笑

> えーと...んじゃこれを売値に適用すれば
> 「こんなことできたらいいなカード(重みつき)」の枚数 × カード一枚のお値段なんてのはどぉじゃろね?
>
> 白皿10万/金皿50万でそれぞれ何枚食ったからいくら、みたいな。
うい。わりと日常茶飯事に(笑

実際、お客さんの「ほしい機能」を全部盛りにすると、結構肥大化するので。
まぁそんだけご予算が出ればいいのですが(或いはご予算が出てもなおやめておいたほうがいい可能性があるのですが)、やっぱりある程度「選ぶ」作業って、必要だと思うです。
言い方を変えると「削る」作業。

なので、うちは大抵お見積もりを「機能ごとに」ある程度数字出して。
「この機能、いやまぁこの金額でいいんならいいですが、多分売り上げにそんなに影響しなさそうだし、一端切っちゃいません？」とかってやりながら、プロジェクトスコープを足したり減らしたり、ってやるです。

おいちゃんはよく「レストランのメニュー」って比喩を使うですね。
「とりあえず定食」は用意するんだけど、アラカルトもたくさんあるし、コースから「いくつか抜いて」金額を減らしてもいい、と。
ただまぁシステムなんで「これは削れません」っていう機能ももちろんありますが(苦笑
# あと「この機能を削ると、この機能が前提になっているその機能もろとも動かなくなりますよ」とか。

とはいえ、お客様が「懐具合で」選択できるので、比較的自由度も高く、やり取りもしやすいって思ってるです。

…わりとふつ～の手法なのかなぁって思ってたですが、もしかして、少し珍しいんですかねぇ？

がるさん

>ちぃと長くなりそうなのですが…コンパクトにまとめつつ、本来の趣旨である「このコラムへのコメント」という立ち位置を踏み外さないようにがんばってみます。
ありがとうございます。
自分も立ち位置を見失わないようにせねば...と思いつつ、そのまま疑問を垂れ流しているという...。

>ん…言ってしまうと、これも一つの「ゲーミフィケーション」なのかも。
>数字になると、その数字が「特になにも影響しない」としても、高いところ狙いたくなりません？(笑
ふむ...わかるなぁ...（笑
影響しないとわかっていても高スコアだしてニヤッとしたい感覚☆

>おいちゃん、多分「次につなげる、をしない」ことが、念頭に存在していないので(苦笑
>基本、あらゆる行動は「可能な限り、今と次とを等しく見つめる」ようにしてるです。
すべからく点ではなく線で考えるということかなぁ...。あれ...なんか違うような...
次を意識するのでなく、過去現在未来が同時はいってる感じかなぁ...。

>したら、後はシステムの納品時に
>・実際に消化した機能、が持っている人日の合計
>を単純に合算して、後はそれに金額を掛け算すると
>・実際に自分が着手できたものに対する収入
>が手に入るです。
あああああ、なるほど。
前出の仮想単位で10日の見積もりの機能があって、それを半日で片付ける人と１ヶ月で片付ける人がいるのでダイレクトに反映されるってことか...。
これが正しく運用されるためには、仮想エンジニアのスキルレベルが正しくチーム全体のスペックの平均値である必要があって、かつその前提の上で
きちんとした日数が見積もれないと...かな？

>白皿10万/金皿50万でそれぞれ何枚食ったからいくら、みたいな。
仕様書が船にのって回ってるのを想像。
金と欲にくらんで背伸びして痛い目に遭う自分も想像できて欝。

ああ、いろいろ考えてる間に話は進んでたり（汗）

>…わりとふつ～の手法なのかなぁって思ってたですが、もしかして、少し珍しいんですかねぇ？
んー...
がるさんのところほど細かいわけではなかったと思いますが、見積もりの基本は機能毎だったような...。
予算とあわなくてさんざん機能削った記憶がありまする。（結局あとで追加することになってまぁ、いろいろと...）

επιστημηさん
>↑そんなミエミエの釣りに俺様が引っかかると思ってクマーー
もちろん（´(ｪ)｀）
...たまにいろいろ拾い損なうのは仕様です...orz

議論が正常化してきたので、大変良かったです。

空理空論を話してもしょうがないので、事例を紹介させていただきますね。
まずは、システムの価値を算出するのが、あまり意味を持たない例です。

世の中には法令順守というものがあります。
法令を守るためにシステムを修正しなければならないということは普通にあり（例えば、消費税の総額表示対応）、私の会社ではそのような仕事を引き受けることが、ままあります。

このようなケースでも、システムを導入しないことによるマイナスというのは当然存在します。

しかし、そんなマイナス価値など算出している場合ではなく、一般にお客様は一定限度のコストであれば、無条件に出費されるようです。
（もちろん、その機に乗じてボッタくったりはしません）

マイナスの価値を算出するとすれば、法令順守しないことによるクレーム対応量＋罰金＋監督官庁に逆らうことによる有形無形の損害などを積み上げると計算できるのでしょうが、こんなものを算出して、費用対効果をはかりにかけている場合じゃないですよね。
（おそらく、監督官庁ににらまれるということは、算出できないくらい大変なものなのだろうと思います）

しかも、こういうことをお客様以上にできると思う人がいたら…
あまりお客様の事を良く知っていると思い込むと、とんだ大恥をかくことになるかと思います。

連投失礼します。

パフォーマンスベース契約の実例についてもあげてみます。

自分の会社でやっていながら、あまり詳しくは知らないのですが、いわゆる「宝くじ」のシステムを作ったと思ってください。
この案件では、お客様と弊社で初期費用を折半し、「宝くじ」っぽいものによる利益を、ある分配率で折半しているようです。

しかしこの案件、当初は社内でもかなりの成功事例として紹介されていたのですが、段々利益が下がってきてしまったのですね。
この場合、その「宝くじ」自体の魅力がなくなってきたのか、システムのユーザビリティが悪くてお客様が遠ざかったのか、
広告などを積極的に打たないのがいけないのか、非常に原因分析が難しいわけです。

この商売では、新たに射幸心を盛り上げるような、新しいメニューを提供することになり、再度システムの機能改修が
発生しました。結果として、その新メニューは売れ行きがまた好評だったので、商売の枠組みとしては今も成立しているのですが、
分配率にも調整が必要だし、実際問題としては非常に難しいものだったのだろうと思います。

また、初期費用の算出はおそらくハードウェア費用＋人月ベースのコストを合意の上、折半したと思われます。
いかに創出価値が計算できると言い張っても、会社的には単年度利益を出さなければ苦しい部分もあります。
創出価値が確定されるまで待っているのは、無理なんですよ。

そして、そのことは当然お客様も理解しているため、初期費用を折半して、ある程度のコストを支払うということにも合意して頂ける訳です。

かなり抽象化した事例紹介しかできませんが、最低限、この程度の情報をださずに「できる！できる！」では、お話にならないのかなと思います。

> おいちゃんはよく「レストランのメニュー」って比喩を使うですね。

なるほどね。メインディッシュは必須だけどもサラダとコーヒーは要らないよ、
サイドディッシュに鶏唐とライス大盛り、と。

麻雀の役みたいなのもいいかな。二飜縛りで点数計算して。
機能によらない横断的な
ポータビリティ/スケーラビリティ/マルチコア対応
の三役乗せてハネ満。お客ハコかぶり、と。

> お客様と弊社で初期費用を折半し、「宝くじ」っぽいものによる利益を、ある分配率で折半しているようです。
> ...

修正版レベニュー・シェアですかしら。
コレができるのはかなり幸運というか、アチラとコチラの信頼関係があって、
それ故ある程度お互いの手の内を晒して(読めて)...
なんてな条件を満たせばこそ、なのかと。
両者の"体力"や"基礎代謝量"みたいなもんも必要に感じます。

全部が全部コレで行こ! にはちとツラそうなんだけど、いかがなもんでしょ。

がるです。

To nightRavenさん
> >おいちゃん、多分「次につなげる、をしない」ことが、念頭に存在していないので(苦笑
> >基本、あらゆる行動は「可能な限り、今と次とを等しく見つめる」ようにしてるです。
> すべからく点ではなく線で考えるということかなぁ...。あれ...なんか違うような...
> 次を意識するのでなく、過去現在未来が同時はいってる感じかなぁ...。
ん…基本的には「線でつなげている」だけ、ではあるのですが。
「今」に重きを置きすぎると先につながらないし、「先」に重きを置きすぎると、足下でこけるので。
武術の「八方目」ではないですが、どちらにも重きをおき、どちらにも偏らない、ように気をつけてるです。

> 前出の仮想単位で10日の見積もりの機能があって、それを半日で片付ける人と１ヶ月で片付ける人がいるのでダイレクトに反映されるってことか...。
うい。

> これが正しく運用されるためには、仮想エンジニアのスキルレベルが正しくチーム全体のスペックの平均値である必要があって、かつその前提の上できちんとした日数が見積もれないと...かな？
ここは、以外とそうでもなくて。
ある程度運用していくなかで「内部のエンジニアと仮想エンジニアのレベル差が、あまりにも乖離しすぎるようであれば」その時点での調整、で、間に合うと思うです。
どのみち「平均化」できるほど、スキルのばらつきって、小さくないので(苦笑

あとはまぁ。そうはいっても、同じ「１」の見積もりで「多分軽微だろう」と「多分重いだろう」ってのは、多少なりあるので。
重いのをベテランに、軽いのを新人に割り振るのは、基本中の基本でございます(笑

> 金と欲にくらんで背伸びして痛い目に遭う自分も想像できて欝。
割と見かける光景です(笑
まぁそれで「先輩エンジニアにヘルプだして助けてもらって」、さらなるスキルアップへの道しるべとしてるですよ ＾＾

To 残念さん
> しかし、そんなマイナス価値など算出している場合ではなく、一般にお客様は一定限度のコストであれば、無条件に出費されるようです。
そうですねぇ時々「あいみつ取って」なんてのもあるかとは思うのですが、この辺は「一定のコスト」として、お客様が「飲まざるを得ない」ところ、ではあるんですよね。
こゆ時に「改修が容易」なソフトを納めておくと、改修費用が安くあがるので、割といい感じで win-winになれたりするです ＾＾

To επιστημηさん
> なるほどね。メインディッシュは必須だけどもサラダとコーヒーは要らないよ、
> サイドディッシュに鶏唐とライス大盛り、と。
うい。
で、この辺から「お客様の本音」とか「お客様所属の業界の風潮」とかが見えるのですが…時々、びっくりするような話もあって、とても刺激的だったりします。

残念さん

>まずは、システムの価値を算出するのが、あまり意味を持たない例です。
>世の中には法令順守というものがあります。
>法令を守るためにシステムを修正しなければならないということは普通にあり（例えば、消費税の総額表示対応）、私の会社ではそのような仕事を引き受けることが、ままあります。

私もこの部分てちょっと気になってまして...。
システムを入れる＝利益を得るじゃない場合ってやはりあると思うんですよね。
まー、私の貧困な想像力だと、つい最近も話題になったかもですがOSのアップグレードによるシステム対応とか...。
現状のシステムに満足してるけど、ハードのサポートがきれちゃうのでリプレースを余儀なくされる場合とか？
この程度です...orz
でも確かに法改正による対応って、あるなぁ...と。
こういった場合、「システムの価値」っていったいどこにあるんでしょう？
マイナスを０にする価値？になるのかなぁ？
でも、ぶっちゃけそこに必要なのは「労働力」に近いのかと思ったり...

＃なんとなくお名前を呼ぶのがちょっと心苦しかったりして...。

>パフォーマンスベース契約の実例についてもあげてみます。
>この案件では、お客様と弊社で初期費用を折半し、「宝くじ」っぽいものによる利益を、ある分配率で折半しているようです。

初期費用の負担額（折半したので初期費用の半分？かな）が、PDFにもかかれてた「最低金額（固定金額）」にあたるのかな？

επιστημη さんのコメントにもありますが、
>修正版レベニュー・シェアですかしら。
>コレができるのはかなり幸運というか、アチラとコチラの信頼関係があって、
>それ故ある程度お互いの手の内を晒して(読めて)...
>なんてな条件を満たせばこそ、なのかと。

けっこうな深度でお互いをわかってないとけっこうもめる原因になりそうなんですが...。
以前にSodaさん...だったかな...もコメントされてましたけど、わりと使えるシチュエーションが限定されるのかなぁと思います。

＃あ、かなり他人様のふんどしで相撲をとってる気がする。自分の意見はどこに？

επιστημηさん、こんばんは。

>両者の"体力"や"基礎代謝量"みたいなもんも必要に感じます。

ご推察の通りで、話を複雑にしないために「自分の会社」と書いていましたが、実は親会社の話でして。
親会社の体力なくしては、これは成り立たないなあと思われます。

がるさん、こんばんは。

>この辺は「一定のコスト」として、お客様が「飲まざるを得ない」ところ、ではあるんですよね。
>こゆ時に「改修が容易」なソフトを納めておくと、改修費用が安くあがるので、
>割といい感じで win-winになれたりするです ＾＾

そうですね。
ずっと保守しているシステムだと、自分達の手の内にある半面、昔やっちゃった品質の悪さも何とかするしかないというところがあります。
何とかお客様に一定のコストを了解してもらい、こっちも常識はずれなことはできないというのが、保守・運用系の宿命ではないでしょうか。

nightRavenさん、こんばんは。

>こういった場合、「システムの価値」っていったいどこにあるんでしょう？
>マイナスを０にする価値？になるのかなぁ？

そうなんです。私の仕事はこういう仕事が非常に多いものですから、「価値」と高らかに言われてもピンと来なかったりします。
お客様とも「まあ、○人で△か月ですかね」と言ったような、対応人数×期間で話をするしかなかったりするんですね。

>けっこうな深度でお互いをわかってないとけっこうもめる原因になりそうなんですが...。
>わりと使えるシチュエーションが限定されるのかなぁと思います。

この仕事の現場にいないので想像になってしまいますが、取り分決めるのに揉めそうですよね。
しかも、最初のうちは「新ビジネス万歳！」でお客様も喜びそうですが、何年か立ってくると「なぜ、あの会社に一定の金額を払わなければならんのだ？」という気持ちになりそうです。
そうなると、何年か経過後にはシステムの償却が済んだことにして、契約を見直さざるを得ないのでしょうね（運用費用は別として）。

※自分に変な名前つけてしまって、心苦しくさせてすみません

ま、このようにいろいろなシーンというのは考えられるというのが、事例を挙げさせていただいた趣旨でした。
お付き合いありがとうございました。
（また、明日から保守のお仕事に戻ることにしましょう）

>> 両者の"体力"や"基礎代謝量"みたいなもんも必要に感じます。
> ご推察の通りで、話を複雑にしないために「自分の会社」と書いて
> いましたが、実は親会社の話でして。
> 親会社の体力なくしては、これは成り立たないなあと思われます。

あー。親会社/子会社の関係ならばお互いの手の内晒すのも
抵抗なさげなんで分け前の配分もさほどに揉めないのかな。

επιστημηさん

>あー。親会社/子会社の関係ならばお互いの手の内晒すのも
>抵抗なさげなんで分け前の配分もさほどに揉めないのかな。

書き方が悪くてすみません。
親会社とお客様の間の事例を、子会社（体力なし）の私がこっそり報告してみました。

とまぁ、このように「それもアリだよねー」とお互いが半歩下がれば
話もはずむってもんさ。

> 親会社とお客様の間の事例

あ、そゆこと?　勘繰りすぎちゃいましたか^^;
レベニュー・シェアてやつ、利益が短いスパンで/明確に/継続的に出るなら
契約形態としてはまんざらでもなさそうで。

今はやりのソーシャルゲームとか、レベニュー・シェアに向いてるポいけど、
実際のとこどーなんでしょね。

がるです。

「保守とシステムの価値」が出ていたか、と思うのですが。
まぁ…平均取るのも難しいとは思うのですが、という前提で。

改修が「わりとあっさりと」終わった場合。それは、元々のシステムに価値があったんだと思うです。
数字的には「平均的にかかるであろう改修コスト - 今回の改修コスト」の金額が、対象システムの「価値」だと思うです。

で、もしそれが「今はダメぽなつくり」で、今回改修を「少し大掛かりにして、今後改修しやすいようにした」場合。
それは、ある程度のコストを消費して「システムの価値を上げた」んじゃなかろうか、って思うです。
数字的には「(今までならかかっていたであろう改修コスト - 改修した結果、かかるようになった改修コスト)＊改修した回数」。

＆
「大変な改修」を開発系のエンジニアにやらせると、よい教育になります。
「雑に作ると後々大変」ということが、骨身にしみますので。
そういう意味では、丁寧な保守は「教育効果」も高い、と思ってます。

だから、保守運用って、とても大切だと思うです。

> 今はやりのソーシャルゲームとか、レベニュー・シェアに向いてるポいけど、実際のとこどーなんでしょね。
うん確かに向いていると思うのですが…あんまり、見たことないですねぇ。
少しばかり(ドス)黒い予想なら、いくつかできるのですが(苦笑

「システムというモノ」と「保守」ってのがわりと切り離せない現状を考えると「保守しやすいシステム」というのは確かに「価値」としてあるのかなぁ
ただ、そのシステム自体がもっている「価値」ではあるんだけども、「保守」というファクタがあって初めて算出できる「価値」なんですよね。
...あー、利益とかも一緒か。結果論になっちゃうような気が...。
ただこー、ずっとおつきあいのある相手とかだとそこそこ判断できたりはしますが...。

コメント欄をずーっと見てて思ったんですけど、なんかこー「いいね！」的な手法を目にするときってあるキーワードがついてることがあるような気がします。
「おつきあいの長い相手」「仲の良いお客さん」
なんかそのあたりもハードルを高くしてる一因なのかなぁ...と思ったり。

がるさん

>「大変な改修」を開発系のエンジニアにやらせると、よい教育になります。
>「雑に作ると後々大変」ということが、骨身にしみますので。
>そういう意味では、丁寧な保守は「教育効果」も高い、と思ってます。
まぁ、いままさに骨身にしみてたりするんですけどね（苦笑）
せっかくの「教育効果」のあるタイミングですけど、さっぱり生かせていないのがちょっと残念。

>ん…基本的には「線でつなげている」だけ、ではあるのですが。
んー、割とそういう発想で日々やっていきたいとは思ってるんですが、点になっちゃうことは多いかなぁ...。

>ある程度運用していくなかで「内部のエンジニアと仮想エンジニアのレベル差が、あまりにも乖離しすぎるようであれば」その時点での調整、で、間に合うと思うです。
>どのみち「平均化」できるほど、スキルのばらつきって、小さくないので(苦笑
なるほどです。
たしかに、簡単に「平均化」してスペックだせるようなものでもない...か。

新システムを導入することによって、「コストが圧縮されることによって生まれる利益」と「コストは変わらずに売り上げが向上することによって生まれる利益」は同じ土俵で語るものなのでしょうか。
もちろん、前提として「利益＝そのシステムの価値」であるならばの話ですが。

↑うーん...

利益 = (売値 - 原価)×数量 って式に対し(売値は固定して):
「コストが圧縮されることによって生まれる利益」→ 原価を下げた
「コストは変わらずに売り上げが向上することによって生まれる利益」→ 数量増やした

ですねぇ。コストダウンつっても固定費↓か変動費↓かで意味が異なるかも知れず。
...ごめん、オノレの答が見当たらんす。

>がるさん
>これは「かかったコスト」ではあっても「価値ではない」と思ってます。

コストとは別に、利益分があるわけで、その利益分に該当する隙間に「価値」が入り込むのではないかと。
まぁ、主に技術的な価値になるとは思いますが、中には他社では作れないというプレミア価格もあるのかなと。
どちらかといえば、こちらのほうが、「人月単価」の否定要素として挙げられることが多いような気がします。
私の最初のコメントで書いているのはコレです。

こーなんていうか、生み出される価値に対しては、やっぱり買う側の範疇だと思うのですよ。
ソフト産業が作っているのは、道具だと思うんですねぇ。
お客の意見を聞いて、お客が気に入る道具を作るのがメインであって、その道具が生み出すものに関して口を出すのは
なにか違うような気がするというか・・・

↑あ、「道具」てのはすっごくわかる。
ソフト屋は芸術家よりははるかに職人寄りだし。
# お客に見えないコードを覗けばartな部分もあるけどね。

がるです。

To nightRavenさん
> コメント欄をずーっと見てて思ったんですけど、なんかこー「いいね！」的な手法を目にするときってあるキーワードがついてることがあるような気がします。
> 「おつきあいの長い相手」「仲の良いお客さん」
> なんかそのあたりもハードルを高くしてる一因なのかなぁ...と思ったり。
これはまぁ、ありますねぇ(苦笑
なので、よく身内に話をするのは「だから、自分でBtoCやれ」と。
そうすると「イヤでもお付き合いが長くなるお客さん」に、自分がなれるから。作るのも自分だけど(笑

To CMPさん
> もちろん、前提として「利益＝そのシステムの価値」であるならばの話ですが。
を前提trueであるとして。

> 新システムを導入することによって、「コストが圧縮されることによって生まれる利益」と「コストは変わらずに売り上げが向上することによって生まれる利益」は同じ土俵で語るものなのでしょうか。
興味深いので経理の人にも聞いたのですが。
「中長期的にはYes。短期的あるいは目的によっては乖離することもある」だそうです。
あとはまぁ…ぶっちゃけると、システム屋的には「売り上げが上がる」よりも「コストが圧縮される」ほうが、「間違いなくシステムの手柄だ」って言いやすい部分は、少しあるんですがね(苦笑

To Ｓｏｄａさん
> コストとは別に、利益分があるわけで、その利益分に該当する隙間に「価値」が入り込むのではないかと。
ん…これは「コスト」を、どの立ち位置から見るか、だと思ってます。
システム屋的には「システム作成コスト＋利益」が、売価になるのですが。
その「システム屋の(システム作成コスト＋利益)」が、お客様的には「システム作成コスト」になるので。

> まぁ、主に技術的な価値になるとは思いますが、中には他社では作れないというプレミア価格もあるのかなと。
> どちらかといえば、こちらのほうが、「人月単価」の否定要素として挙げられることが多いような気がします。
> 私の最初のコメントで書いているのはコレです。
ものすごくシビアな話をしてしまうと、その「他社では作れないプレミアなシステム」が、具体的に「いくらになるのか」っていう数字がちゃんと算出できないと、なかなか、売り値に影響させるのは難しいのかなぁ、と思ってます。
で…「どちらかといえば、こちらのほうが、「人月単価」の否定要素として挙げられることが多いような」は、肯定否定の両方の側面から、おいらも「そうだなぁ」って思ってます。

興味深いところなので、少し噛み砕いて。
まず、わりと真っ先に否定するのが「エンジニアの自己満足的にはすげぇ面白い技術なんだけど、お金に変換する方法が現状思いつかないもの」。個人の趣味だったり自分の経営している会社だったりするとまだよいのですが、会社員の状態で「これは素晴らしいから高値で売って来い」って話をしても、多分、蹴られて終わります。
ただ、難しいのが、実はそれらのうちのいくつかは「そもそも値段が付かない」んじゃなくて、「うまく使いこなせるところ(とか営業)だといい金になるんだけど、使いこなすのが難しい」技術。
この場合、本質的には「敏腕あるいは辣腕な営業さん」と組むのが確実なのですが、そうでない場合が、難しい(苦笑

で、この話につなげていくのですが。

> こーなんていうか、生み出される価値に対しては、やっぱり買う側の範疇だと思うのですよ。
> ソフト産業が作っているのは、道具だと思うんですねぇ。
> お客の意見を聞いて、お客が気に入る道具を作るのがメインであって、その道具が生み出すものに関して口を出すのはなにか違うような気がするというか・・・
本来的にはYes「であって欲しいなぁ」とは、おいちゃんも思うです。それが分業ってもんだと思いますし。
ただ、現実問題として、うちらの作る「道具」を適切に用いて営業できる人が、世の中に「潤沢にあふれかえっているか」と問われると、必ずしもそうとばかりは言いにくい現実があって orz
そうすると、どうしてもコンサルティング的なことやらをやって「自分が作った道具が、適切に用いられる」土壌を、自分で耕さないといけないケースが、あると思うです orz

なので、結果的に「エンジニアが、その辺まで含めてやっていかなきゃいけない」状況"も"、場所によってはあるんじゃないかなぁ、と。

…ちょっと熱が高いので、文章がいつも以上に散らかっている可能性がありますが orz

なんかふと気付いたので、一言だけ。

「突き詰めると人月の問題というのは、開発側が提供する価値に対してどのような金額的価値を認めるか」という大本のお題ですが。
もしかすると、「我々の人月は、提供している価値(==利益を生み出す可能性)に対して、数値がちゃんと近似しているのだろうか」ではなくて。
「我々の提示する金額が、ちゃんと提供している価値に近似するように、適切な営業なりコンサルティングなり提案なりをする」のが、大切なのかなぁ？

というのはまぁ「すべて」ではなくて「一つの考え方」程度、だとは思うのですが。
「一つの方向性」としては、ありなのかなぁ、と。

本文とは、直接関係ありません。

私はリーベルGさんの新連載、「冷たい方程式」を読んでいて、その後にこのエントリの存在に気がつきました。「おお、ナイス連動」と思ったのですが、よく見ると、こちらのエントリの方が、はるかに早いですね。失礼しました。

>がるさん
>まず、わりと真っ先に否定するのが「エンジニアの自己満足的にはすげぇ面白い技術なんだけど、お金に変換する方法が現状思いつかないもの」。

買い手がいなければ商売的にはゴミどころか、マイナスですねぇ(^^;
まぁ、先に書いてあるように、実際には、目に見える技術的な差というか、特定の会社しか作れないものってのは少なくなってると思うのですよ。
だから、「価値あるものを作ってる」と思っているのは、結構な確率で思い込みというか井の中の蛙みたいな感じではないかと。
そういう思いが、自分たちは特別な職業についているという錯覚を起こしてないかなーと思うんですよねぇ(^^;

>なので、結果的に「エンジニアが、その辺まで含めてやっていかなきゃいけない」状況"も"、場所によってはあるんじゃないかなぁ、と。

小さい会社だと、営業も兼ねてるわけで・・・自分で作って自分で売るみたいな(^^;

>「我々の提示する金額が、ちゃんと提供している価値に近似するように、適切な営業なりコンサルティングなり提案なりをする」のが、大切なのかなぁ？

どうなんだろう、どちらかといえば、請求できる金額は相場によってある程度縛られているのが現状かなと思ったり。
お客の欲しいもの＋αを作るのは当たり前で、後はいかに早く、安く提供できるか？って時代かなーと。

「人月」の問題をみると思うのは、ソフト産業が「まだ特別」だと思っている人が結構いるんだなと・・・
ごく普通の・・・一般的な職業だと考えられるようになれば、「人月」が問題とは思わないのではないか？と思うわけです。
逆の視点で考えると、「特別」でいたいから、「人月」では駄目ってこともあるのかなと・・・

がるです。

To Ｓｏｄａさん
> 買い手がいなければ商売的にはゴミどころか、マイナスですねぇ(^^;
ですねぇ(苦笑
会計的には「負の資産」になっちゃいます。

> まぁ、先に書いてあるように、実際には、目に見える技術的な差というか、特定の会社しか作れないものってのは少なくなってると思うのですよ。
まぁ、それでもちゃんと「技術的な差」が、時として「露骨に会計レベルで」存在するケースもあるから、それはそれで、考察要素から外せないのですが(苦笑

> 自分たちは特別な職業についているという錯覚を起こしてないかなーと思うんですよねぇ(^^;
あぁ…これは…あるんですかねぇ？
なんとなく、それが仄見える瞬間も、ちらほら(苦笑
おいちゃんは、お仕事は「前の人からバトンもらって自分の仕事加えて次の人にバトン渡す」もんだと思ってるので、その辺、あんまり高低差を感じてないのですが。

> お客の欲しいもの＋αを作るのは当たり前で、後はいかに早く、安く提供できるか？って時代かなーと。
うい。これはあると思うですよ。やっぱり速度は武器ですから。
後は、やはり「メンテナンス性のよさ」とか「機能追加や改修のしやすさ」なんてのは、TOCに露骨にまつわるもんじゃないかなぁ、と。

> 「人月」の問題をみると思うのは、ソフト産業が「まだ特別」だと思っている人が結構いるんだなと・・・
まぁ「オレの仕事は誰にも理解出来ないのだすごいのだ」ってのは、一部、あるとは思うんですが(苦笑
ただ「誰にも理解出来ない」と、それは「お客様にも理解ができない」ので、お金にならない、と。

「オレはすごいんだ～」とオオカミ少年をするよりは。
手の内を一通りさらして「出来るんならどんぞ」と言われ、一見簡単そうなんだけどやってみたら檄ムズで…なんていうほうが、おいちゃん的には好みだったりしますｗ
いやまぁ「一見簡単そうで、実際やってみたら結構簡単」なものも多くて、それは普通に共有していけば良いと思うのですが。

おいちゃんは、OSSの海に育てていただいて、今があるのでｗ
知識の出し惜しみとか、好みではないのですだよ。
# 「出し惜しむほどの知識ねぇじゃん」とかいう突っ込み禁止ｗ

> 「人月」の問題をみると思うのは、ソフト産業が「まだ特別」だと思っている人が結構いるんだなと・・・

扱ってるモノはまだまだ特別かもしんないけど、
やってるコトはもはや特別じゃない
図面引いて材料探して組み立ててるだけ、
職人だもの ── みつを

>「オレはすごいんだ～」とオオカミ少年をするよりは。

どっかで見かけた名言:
「認められるために最も効果的な方法は、
　認められることを必要としないこと」

"すげー!"って言ってもらいたいなら すげーところを晒せばいい。
「"すげー!"って言って」は逆効果、と。

PBC をざっくり読みましたが、「金額の根拠が不明瞭である」という点は、変わらないですね。

] 売り上げを伸ばそうと、新しいシステムを導入した。
] しかし、世界的な不景気で、売り上げは落ちた。

なんてことになったら、システムの価値はどうやって計るの？とか。
詰まるところ、「双方が納得できる方法を模索しましょう」って事で、そういうことなら、「これこれが出来る技術者の原価はいくら」という基準が出来れば、半分解決、って事ですかね。
で、期間についてですが、これは、数社に見積を取ればいいですね。

　スーパーと八百屋では、同じものでも値段が違います。
これは、八百屋の場合、卸や仲買を通って来るのに対して、スーパーでは自分のところで一括して購入するので、原価を安くできるためですね。
また、野菜の場合、たいてい、原価の倍の値段で小売りされます。
これは、売れ残ったときに損をしないためです。
つまり、「半分近く売れ残る」という前提がある、と。
文房具などでは、「万引きされて損をする分」が、価格に含まれています。

ええ～、人件費だけのシステム開発の方が、よっぽど納得し易いやん。