2012/02/20

値段の決め方

独立して10年、いまだに価格交渉は苦手だけれど、 これは、だいたい同意。

Left Side Story経由で 『Ameroadが生まれてから売却するまでの五日間まとめ』

値段というのは、商品価値で決めるものではない。買って頂ける人を想定し、その人の財布に合わせて決めるものだと思う。

財布に合わせてというか、まあ最終的には向こうもこっちも「得した」と思えるポイントを 見つけるってことだと思うけど。

自分は子供の頃にどういうわけか「値段というのは、原価と経費に利益を足して決めるものだ」と 思い込んでしまって、ハタチ前後までそのナイーブな誤謬に気づかなかった。 需要供給曲線とか学校でやってるのにね。 でも同じような思い込みをしてる人は珍しくないような気がする。

もちろん式としては 価格=原価+経費+利益 だけど、これは単なる制約を表す式で、 「価格を決める式」ではない。むしろイメージとしては、需要と供給の関係から価格が決まり、 そこから利益が出るように原価や経費を調整する、というのが近い。 現実には制約を満たすように行ったり来たりして均衡状態に落ち着くものなので、 はっきりした向きがあるわけじゃないけど。

買い手も売り手もたくさんいて、材料や労働力もコモディティであるような商品なら、 競争の結果として、「原価と経費にちょっと色をつけて値段を決める」というのが 均衡価格を予測するショートカットになるから、 それをどっかで読んで「これが価格の決め方だ」って勘違いしたのかもしれない。

でも一品ものの受注生産みたいに、買い手や売り手が極めて限定される状況では、 この予測式の前提は成り立たない。

プログラミングだと経費のほとんどは人件費なわけで、それを労働時間に比例させると、 経費+利益積み上げ式では時給とか人月で価格を決めることになる。 それはプログラミングがコモディティであることを前提としてるってことだ。 でもプログラマというのは、一定時間かければ誰でも同じように出来る作業は自動化せずにはおれない 人種なので、「コモディティなプログラマ」は形容矛盾だ。

とはいえ、価格の算定根拠として時給計算とか人月計算を求められることは多いんだけどね。 そういう時は仕方ないから、価格から逆算して時給と労働時間を出してるけど、 できれば総額で話を進めたい。 自分としては時間を切り売りするんじゃなく作ったものを喜んで欲しいし、 お客さんだって欲しいのは「私の時間」ではなく「目的に使えるシステム」なんだから。

Tag: 仕事